| === devil is now known as Guest194 | ||
| === genious is now known as genios | ||
| === chihchun_afk is now known as chihchun | ||
| === Guest194 is now known as devil_ | ||
| svij | is there no "snap update" command, or will it update automagically? | 07:39 |
|---|---|---|
| zyga | svij: it's snap refresh | 07:40 |
| svij | ah I see, is there no command to update all snaps, rather than one single with refresh? (I don't need it right now, just curious) | 07:41 |
| zyga | svij: it will be refresh, just not implemented yet | 07:43 |
| svij | zyga: ah okay | 07:43 |
| svij | thx | 07:43 |
| dholbach | kyrofa, sergiusens: once you're both up, can we chat about the snapcraft sessions at UOS and get them scheduled? | 07:57 |
| slvn | jdstrand, zyga, about SDL2 failling with UDEV for Initialization of INIT_Joystick. That happens when calling "udev_monitor_new_from_netlink", and apparmor says : audit: type=1400 audit(1461830101.683:1127): apparmor="DENIED" operation="create" profile="snap.MyApp.app" pid=11228 comm="MyApp" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create" | 08:02 |
| slvn | (maybe I need to use the plug network ?) | 08:02 |
| zyga | slvn: I suspect that will stay denied for a while unless netlink support in apparmor is improved, for now I'd compile joystick support out | 08:02 |
| slvn | zyga, it's not blocking anyway.. joystick is just not initialized.. just report the issue | 08:03 |
| zyga | ah, ok | 08:03 |
| slvn | zyga, also audio was failing, but it's not *killing* the apps, it just stays not initialized. | 08:06 |
| slvn | zyga, just correcting myself, in fact, audio pulse if really failling (.shm_open() failed: Permission denied). So I need to desactivate it. | 08:13 |
| zyga | slvn: we know about audio, we'll get something supported, if you check the backlog we discussed this issue last night | 08:17 |
| zyga | slvn: there are still a few things to decide before that can happen but we do know about it | 08:17 |
| slvn | zyga, ok | 08:19 |
| ysionneau | about Mark shuttleworth's email : what's "GA" ? | 08:45 |
| zyga | ysionneau: general release? | 08:48 |
| ysionneau | A for Release ? :o | 08:48 |
| zyga | availability? :) | 08:51 |
| zyga | globally awesome release :) | 08:54 |
| Gunther_ | hehe we also discussed the meaning of "GA" here :) | 08:55 |
| ysionneau | :) | 08:59 |
| vijaikumar | General Availability | 09:00 |
| ysionneau | thanks | 09:05 |
| Gunther_ | latest allsnaps: sudo snap remove trionet error: can't remove "trionet": cannot find mounted snap "trionet" at revision 100001 | 09:29 |
| Gunther_ | :( | 09:29 |
| Gunther_ | did work before, but at one time complained about: sudo snap remove trionet [-] Remove snap "trionet" from the system error: cannot perform the following tasks: - Remove snap "trio | 09:31 |
| Gunther_ | and after reboot I am stuck | 09:31 |
| zyga | Gunther_: it's known broken for now | 09:32 |
| zyga | Gunther_: will be fixed with the next SRU | 09:32 |
| zyga | Gunther_: you can use my script to reset snap state: github.com/zyga/devtools | 09:32 |
| zyga | Gunther_: look at reset-state | 09:33 |
| Gunther_ | ok thanks | 09:33 |
| zyga | Sorry for the bad experience | 09:33 |
| Gunther_ | no problem, I am developer myself | 09:33 |
| Gunther_ | zyga: worked great ;-) all snaps removed including the kernel (ooops) | 09:38 |
| zyga | Gunther_: ooops | 09:38 |
| zyga | Gunther_: this was tested on the desktop | 09:38 |
| zyga | Gunther_: it would need some love on devices | 09:39 |
| zyga | Gunther_: can you look at what would be needed to make it work there and fix it please | 09:39 |
| Gunther_ | zyga: I ll try | 09:39 |
| dpm | oh, I just discovered a nice snap trick: https://bugs.launchpad.net/snappy/+bug/1574829/comments/1 | 09:40 |
| ubottu | Launchpad bug 1574829 in Snappy "snappy install requires root or login, but doesn't tell you so" [Wishlist,Triaged] | 09:40 |
| dpm | snap without sudo | 09:40 |
| asac | pitti: where is the rename of wlan0 to wlxXXXXXX done? I couldnt find the matching rule in udev | 09:53 |
| pitti | asac: in xenial release it is still /lib/systemd/network/90-mac-for-usb.link | 09:54 |
| asac | ahh... /me was already thinking maybe its in systemd | 09:55 |
| pitti | asac: however, that will change soon (also in xenial) to /lib/udev/rules.d/73-special-net-names.rules due to bug 1574483 | 09:55 |
| ubottu | bug 1574483 in systemd (Ubuntu Xenial) "assigns MAC-based names for devices with locally administered MAC address" [High,In progress] https://launchpad.net/bugs/1574483 | 09:55 |
| asac | ok gotcha... let me study the .link file a bit though so i know how that works | 09:55 |
| pitti | asac: see /usr/share/doc/udev/README.Debian.gz | 09:56 |
| pitti | that still refers to a wrong name (01- instead of 90-) | 09:56 |
| qengho | My gnome-disks UI looks pretty hilarious after using snappy for a while. | 09:57 |
| zyga | _morphis: hey, you should be able to rebase n-m interface on top of https://github.com/ubuntu-core/snappy/pull/1078 now | 10:53 |
| _morphis | zyga: awesome! | 10:53 |
| _morphis | will do, thanks a lot for that! | 10:53 |
| zyga | _morphis: https://github.com/ubuntu-core/snappy/pull/1078/files#diff-939866a2238749d2c6989a8a757f430f | 10:54 |
| keestu | Hi, I use ubuntu since last 5 years. I came across about the snappy. I have dev embedded board, and i have a question now. Is it possible to get ubuntu core into the this embedded device ? | 10:54 |
| zyga | keestu: yes, you need a kernel that works there and a supported bootloader | 10:55 |
| zyga | keestu: though right now devices (boards) are in rapid development after 16.04 release so expect a lot of changes in the next few weeks | 10:55 |
| keestu | zyga, thanks, my knowledge is petty limited to this. I have a board, where we port android, linux with qt, how snappy is going to be different ? | 10:56 |
| zyga | keestu: if you have a working kernel, it should be not much different | 10:57 |
| zyga | keestu: the only requirement is a supported arch, what SoC | 10:57 |
| zyga | keestu: (you don't build snappy entirely from source,) | 10:57 |
| zyga | keestu: you just buld the kernel and gadget snaps, the rest is stock and shared by all devices | 10:58 |
| keestu | so, snappy is a way to get the customized desktop feel in embedded device ? | 10:58 |
| zyga | keestu: snappy has no desktop feel | 10:58 |
| zyga | keestu: anyway, please familiarize yourself with the documentation on snappy that's available on ubuntu.com now | 10:58 |
| keestu | zyga, i am looking at the business perspective. We see the customers demanding porting android to our embedded device. | 10:59 |
| keestu | zyga, sure. | 10:59 |
| * zyga -> lunch | 11:00 | |
| keestu | :) | 11:00 |
| === oparoz_ is now known as oparoz | ||
| keestu | bon appetit | 11:00 |
| slvn | zyga, another issue snap+SDL2+x11. At first install (after reset-state), it doesn't connect to x11. I need to remove the snap, then reinstall it. then it can connect to x11. The syslog error was "apparmor="DENIED" operation="connect" profile="snap.MyApp.app" pid=22559 comm="MyApp" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" | 11:15 |
| slvn | peer="unconfined" | 11:15 |
| ogra_ | ppisati, have you seen bug 1574103 ? | 11:20 |
| ubottu | bug 1574103 in Snappy "Raspberry Pi 2 image LEDs are swapped." [Medium,New] https://launchpad.net/bugs/1574103 | 11:20 |
| ogra_ | and bug 1574075 might also be interesting | 11:20 |
| ubottu | bug 1574075 in Snappy "Snappy does not detect Sagem wifi dongle" [Medium,New] https://launchpad.net/bugs/1574075 | 11:20 |
| sergiusens | dholbach I will have to rain check on that and ask for it to be in a couple of hours; both kyrofa and myself are unavailable right now | 12:03 |
| seb128 | sergiusens, can parts/files have dynamic values? | 12:08 |
| seb128 | like "somelib: /usr/lib/$(ARCH)/somelib"? | 12:08 |
| seb128 | sergiusens, hey btw :-) | 12:08 |
| jdstrand | slvn: fyi, you need to plugs either unity7 or x11. did it not autoconnect? | 12:19 |
| slvn | jdstrand, both are in the plugs list (and also opengl) of the snapcraf.yaml file | 12:25 |
| slvn | maybe the reset-state script is incomplete ? | 12:26 |
| jdstrand | slvn: would you mind filing a bug for that? show your snapcraft.yaml, how you installed, the denial and the policy in /var/lib/snapd/apparmor/profiles/snap.MyApp.app | 12:26 |
| slvn | first install -> x11 doesn't work. then remove, and install again. it works | 12:27 |
| jdstrand | slvn: and please add that detail :) | 12:27 |
| slvn | jdstrand, yep. I go away now, but I will re-try that later and fill a report. | 12:28 |
| jdstrand | slvn: thanks. others have seen this but I don't think there is a bug | 12:28 |
| slvn | jdstrand, if first install always fail to launch, it's kind of problematic for me :) | 12:29 |
| jdstrand | slvn: very much indeed :) | 12:29 |
| bencc | can I package an erlang app with snappy and do hot code upgrade? | 12:29 |
| slvn | jdstrand, but i'll double check later and let you know! ++ | 12:30 |
| bencc | upgrade the code while the app is till running? | 12:30 |
| dholbach | sergiusens, I'll have to leave at 16:00 or 16:15 UTC today - it'd be good if we could talk about it before | 12:30 |
| zyga | slvn: you can always connect manually but I'm wondering why auto-connect did not work | 12:42 |
| zyga | slvn: thanks, I'll investigate this | 12:42 |
| wesleymason | Snapcraft Q: is there a variable representing the install stage path that I can, for example, pass to a makefile to tell the target where to install into | 13:05 |
| wesleymason | ? | 13:05 |
| kgunn | zyga: just confirm, if i change something in snap, go build it and snapd, copy over and fire up snapd...i should see the change i made in snap? | 13:07 |
| * kgunn swears he saw this before, hopes he's not going crazy | 13:08 | |
| zyga | kgunn: in a meeting, you need to copy snapd (and restart it, devtools helps) | 13:08 |
| zyga | kgunn: for security changes disconnect and reconnect | 13:08 |
| kgunn | zyga: was doing pkill -9 snapd, then starting | 13:08 |
| oparoz | wesleymason, $SNAPCRAFT_STAGE | 13:08 |
| zyga | not really | 13:09 |
| zyga | kgunn: try github.com/zyga/devtools | 13:09 |
| zyga | there are more bits and magic there | 13:09 |
| zyga | and it's all made for this use case | 13:09 |
| wesleymason | oparoz: great, cheers | 13:09 |
| kgunn | zyga: ok | 13:09 |
| kgunn | so i can't just go build snap/snapd, copy over? | 13:09 |
| zyga | you can but you need more, devtools does all that | 13:10 |
| zyga | and more :-) | 13:10 |
| zyga | try it | 13:10 |
| kgunn | ok, i may need help, cause my vm i use for mir isn't the standard one | 13:10 |
| zyga | syure | 13:10 |
| zyga | sure* | 13:10 |
| kgunn | mainly ssh config i suppose | 13:10 |
| oparoz | Is there a recommended way to use start-stop-daemon in init scripts? Default policy doesn't allow scripts to call it | 13:11 |
| ogra_ | first of all you would have to ship it in your snap :) | 13:12 |
| ogra_ | (and then i dont think it would be accepted or used at all in the end ... given we use systemd in snappy ) | 13:13 |
| oparoz | ogra_, I get "access denied", so it must be there, just not allowed. The way I understand it is that systemd calls whatever start script is given to it, so it shouldn't be an issue to call this command, no? | 13:14 |
| kgunn | zyga: actually...i got it....devtools talking to my vm, i see devtools.snap in there :) | 13:15 |
| kgunn | relying on magic now | 13:15 |
| ogra_ | oparoz, it is a tool from sysvinit scripts ... it should really not be used at all in systemd envs | 13:15 |
| ssweeny | jdstrand, zyga, is there a recommended way to do service logging in snappy? My location-service snap is trying to create /var/log/location-service which obviously isn't going to work | 13:16 |
| zyga | kgunn: cool, just use refresh-bits (it has --help and is trivial to read) | 13:16 |
| zyga | ssweeny: I don't think there is one, maybe just let systemd manage logging | 13:16 |
| zyga | ssweeny: but I don't really know | 13:16 |
| ssweeny | zyga, ok, thanks | 13:16 |
| ogra_ | ssweeny, "snappy service logs" used to do that ... | 13:16 |
| zyga | kgunn: I will gladly take patches for new features | 13:16 |
| kgunn | zyga: hmmm, with latest tools...do i have to sudo snap for such things as "snap list" ? | 13:16 |
| ogra_ | i would expect that to be back once the snap service command comes back | 13:16 |
| zyga | kgunn: yes, because the socket is root-owned | 13:16 |
| zyga | kgunn: or chmod 666 /path/to/socket (/var/snapd.socket AFAIR) | 13:17 |
| zyga | kgunn: it's not handled by devtools because I was always lazy and using sudo | 13:17 |
| kgunn | that's right...i see a note | 13:17 |
| kgunn | ok, fully relying on devtools...and i still don't see my mod | 13:17 |
| zyga | kgunn: if you get it supported, just send me a patch please, I was annoyed by this once and there was one bug hidden by this already | 13:17 |
| zyga | kgunn: what's the mod about? policy change? | 13:17 |
| zyga | kgunn: you should connect/disconnect or remove/install the snap because there is no logic that detects interface implementation changes yet | 13:18 |
| zyga | kgunn: you should also check generated profiles (/var/lib/snapd/{apparmor,seccomp}/profiles | 13:18 |
| jdstrand | ssweeny: if you want your own log, you need to change the path to somewhere in SNAP_DATA | 13:19 |
| ssweeny | jdstrand, yeah that was my other thought | 13:19 |
| zyga | jdstrand: hey, gustavo recommended that we work on making n-m interface supported on the desktop; it would also unblock a bunch of prospective snaps; can you tell me if the current policy there is safe for desktop use? | 13:20 |
| jdstrand | ssweeny: (if you don't want systemd to handle it-- with systemd it will capture stdout and stderr and you can use journalctl to see the output from your service) | 13:20 |
| kgunn | jdstrand: isn't there a command line to list interfaces? | 13:20 |
| zyga | jdstrand: (just comment on the pull request anytime you have a moment to look at it) | 13:20 |
| kgunn | i thot i recalled that...couldn't find the email | 13:20 |
| zyga | kgunn: snap interfaces | 13:20 |
| kgunn | dang it...soo simple | 13:20 |
| kgunn | shoulda guessed | 13:20 |
| zyga | :-) | 13:20 |
| seb128 | does anyone know if parts/files have dynamic values? | 13:21 |
| seb128 | like "somelib: /usr/lib/$(ARCH)/somelib"? | 13:21 |
| ssweeny | jdstrand, ah so I can just change logging to stdout and stderr and systmd will take care of it for me? cool | 13:21 |
| zyga | seb128: I don't think they do | 13:21 |
| seb128 | :-( | 13:21 |
| zyga | seb128, kyrofa: or sergiusens would know | 13:21 |
| zyga | seb128: what are you trying to build? | 13:21 |
| seb128 | they are not around though | 13:21 |
| seb128 | a GTK app | 13:21 |
| zyga | seb128: you can use $SNAP_ARCH | 13:21 |
| zyga | seb128: it's an env variable we set | 13:21 |
| seb128 | to install thing? | 13:21 |
| jdstrand | ssweeny: note, it will also show up in syslog, but yes | 13:21 |
| zyga | seb128: you'd have to do a wrapper for it though | 13:21 |
| zyga | (or patch gtk) | 13:21 |
| seb128 | at build time? | 13:21 |
| zyga | seb128: no, at runtime | 13:21 |
| seb128 | that doesn't interet me | 13:22 |
| zyga | seb128: for build-time i don't know | 13:22 |
| zyga | (I'm hacking on the other side) | 13:22 |
| zyga | seb128: I'd recommend starting with amd64, then working with snapcraft hackers to generalize | 13:22 |
| jdstrand | zyga: re nm-- we had a rather lengthy discussion on that at the eod yesterday but I didn't think we came to a conclusion. but to specifically answer your queston, no, the nm policy is not safe for confined apps-- it grants too much privilege | 13:22 |
| zyga | seb128: for the runtime part I think we should perhaps explore patching some bits to understand snap runtime layout | 13:23 |
| zyga | jdstrand: ok, could we do a simple version for now that still works on the desktop and land that, iterating on a broader one using some other ways (attributes, more ifaces) | 13:23 |
| seb128 | zyga, I'm on i386 so starting with amd64 is not going to work for me :p | 13:23 |
| zyga | jdstrand: I think the key is to ensure that we don't leave the desktop as we progress | 13:23 |
| zyga | seb128: oh, sorry | 13:24 |
| zyga | seb128: i386 is fine though, it's just a suggestion to try to solve the simpler problem first | 13:24 |
| seb128 | right | 13:24 |
| seb128 | well I've the arch coded | 13:24 |
| seb128 | but I wanted to push that so jdstrand and others can play with it | 13:24 |
| jdstrand | zyga: I feel like I am missing context. we left it yesterday that we need more discussion for the desktop case | 13:24 |
| seb128 | but it sucks if everyone needs to sed the arch before building | 13:24 |
| zyga | jdstrand: I just talked about this in the standup, gustavo recommended that we ensure it works on the desktop before it lands | 13:25 |
| jdstrand | well, then I need to understand the direction | 13:25 |
| jdstrand | zyga: did niemeyer_ comment in the pr? | 13:25 |
| zyga | jdstrand: checking | 13:25 |
| zyga | jdstrand: nope | 13:27 |
| zyga | there's the community sync in 3 minutes | 13:27 |
| zyga | let's continue that after if you have time, otherwise let's do it by email | 13:27 |
| jdstrand | zyga: email is probably best so everyone has context | 13:28 |
| seb128 | did anyone look at snap and translations? | 13:31 |
| seb128 | what would be the right place to discuss the topic/put notes? | 13:31 |
| seb128 | list? launchpad pad? spec? | 13:31 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | seb128, UOS ? :) | 13:34 |
| ppisati | ogra_: ack | 13:39 |
| seb128 | ogra_, right, because that's going to be useful if nobody of the snappy team is interested and joining | 13:40 |
| seb128 | is there any plan to mount some part of the snaps to normal system locations? | 13:41 |
| seb128 | rather than trying to make everything reallocatable? | 13:41 |
| seb128 | mvo, hey, do you know if it somebody discussed making locales part of the core image before? | 13:42 |
| ogra_ | i think that was discussed and deemed to be to space hungry | 13:43 |
| ogra_ | (given it was designed for embedded without actual users) | 13:44 |
| zyga | seb128: I doub't that | 13:44 |
| zyga | (not relocatable) | 13:44 |
| seb128 | zyga, :-( | 13:44 |
| ogra_ | seb128, i suspect we're moving into -pd territory ... | 13:44 |
| seb128 | ogra_, are such gaps documented somewhere? launchpad bugs? | 13:44 |
| ogra_ | not that i know of ... | 13:44 |
| zyga | seb128: I think that would be against the idea of snappy | 13:45 |
| ogra_ | but i personally wouldnt see locales as something to have in core ... | 13:45 |
| seb128 | ogra_, you would see each application needing to ship the libc locale definition? | 13:45 |
| seb128 | + to patch glib to allow relocating those | 13:46 |
| caio1982 | hi there, i am snapping a system monitor tool and i wonder what plugs would be necessary to access /proc/vmstat and a given /etc file like /etc/mtab... is there one? | 13:47 |
| ogra_ | seb128, well, a snap *has to be* completely inependend from the core system,. they always need to be separately upgradeable ... | 13:49 |
| ogra_ | thats one of the base definitions of snappy | 13:49 |
| seb128 | ogra_, with, snaps don't have to ship their own libc, do they? | 13:50 |
| ogra_ | they can | 13:50 |
| seb128 | but don"t have to? | 13:50 |
| ogra_ | thats the one thing they could use ... but nothing stops you to ship your own | 13:50 |
| seb128 | well, shipping your translations, fine | 13:51 |
| seb128 | having to ship the glibc locale definitions | 13:51 |
| seb128 | I doubt it's something any appdev is going to want | 13:51 |
| seb128 | also glibc doesn't support relocating those | 13:51 |
| ogra_ | well, but shipping them in core means you add a dependency | 13:52 |
| seb128 | depends to what? | 13:52 |
| seb128 | snaps depends on the core anywhy | 13:52 |
| seb128 | anyway | 13:52 |
| ogra_ | between the system and the snap | 13:52 |
| ogra_ | i.e. what if glibc locale handling code changes in incompatible ways in the system snap | 13:53 |
| ogra_ | you would need something liek a versioned dependency | 13:53 |
| seb128 | ogra_, you are saying "what if glibc changed in an incompatible way", but that's already an issue since you don't force snaps to ship a copy of glibc | 13:59 |
| ogra_ | sure | 14:00 |
| seb128 | if you have this stance it's fine, but then be consistent and force snaps to include a libc copy | 14:01 |
| dholbach | niemeyer, which time between 14 and 20 UTC would work for you for an interface session next week (3-5 May)? | 14:01 |
| dholbach | zyga, ^ too | 14:01 |
| seb128 | if you allow them to rely on the core one there is no point to say that can only be for some parts of libc | 14:01 |
| zyga | dholbach: any except standups but I'm flexible | 14:02 |
| ogra_ | seb128, right, the "it is useless on headless IoT systems without users" thing is still valid though ... | 14:02 |
| ogra_ | we'd need two core setups | 14:02 |
| seb128 | unsure | 14:02 |
| seb128 | you might want your ls, etc to be in german | 14:03 |
| ogra_ | which ls ? | 14:03 |
| seb128 | your commands on the core | 14:03 |
| ogra_ | on my router i only have that web UI :P | 14:03 |
| seb128 | well, you might want that webui in german | 14:03 |
| ogra_ | on my drone i even only have that mobnile app that talks to it | 14:03 |
| * zyga checks backlog | 14:03 | |
| ogra_ | sure, but for that i dont need glibc locales necessarily | 14:04 |
| seb128 | right | 14:04 |
| seb128 | we need frameworks :p | 14:04 |
| ogra_ | good idea ! | 14:04 |
| zyga | seb128: though ogra was spot on on pocket-desktop area, I think on personal the core snap could provide you with a gtk runtime interface | 14:04 |
| ogra_ | uh | 14:04 |
| zyga | seb128: so if you want that runtime to be something you depend on, great, but I don't know if that's exactly what we want to do with gkt | 14:04 |
| ogra_ | a whiole runtime is to much imho | 14:04 |
| zyga | seb128: perhaps for SDK runtime first | 14:04 |
| zyga | seb128: we don't need frameworks, we need interfaces | 14:05 |
| zyga | seb128: anything that a framework could do is doable with a new interface | 14:05 |
| seb128 | can an interface snap add files to /var and /lib in your snap mount? | 14:05 |
| zyga | seb128: an interface can let a snap do this | 14:06 |
| zyga | seb128: we still don't have hooks, when we get them from new state engine we'll be able to react to all actions (connect, etc) | 14:06 |
| zyga | seb128: if you tell me more about the problem perhaps I could suggest a solution | 14:06 |
| seb128 | zyga, trying to get translations working in my snap | 14:07 |
| seb128 | which requires to have locales generated in /usr/lib/locale/locale-archive | 14:07 |
| seb128 | that can be relocated | 14:08 |
| seb128 | by then gettext tries to read from /usr/share/locale:/usr/share/langpack-locale | 14:08 |
| seb128 | which can't be relocated | 14:08 |
| seb128 | but as an appdev I don't want to have to learn how to generate libc locales | 14:08 |
| zyga | seb128: the appdev part should be solved with snapcraft support | 14:09 |
| seb128 | I guess we could teach snapcraft to generate those though | 14:09 |
| seb128 | that still doesn't solve the fact that glibc doesn't let you relocate/specify another dir to load the .mo | 14:09 |
| seb128 | out of patching glibc's code and rebuilding glibc as part of your snap | 14:10 |
| zyga | seb128: doesn't textdomaindir do that? | 14:10 |
| seb128 | no | 14:10 |
| seb128 | it works only for the gettext command line | 14:10 |
| zyga | I mean | 14:10 |
| seb128 | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114461 | 14:10 |
| ubottu | Debian bug 114461 in gettext "gettext: there is no way to control where message catalogs are found at run time" [Normal,Open] | 14:10 |
| zyga | bindtextdomain | 14:10 |
| seb128 | zyga, no | 14:10 |
| zyga | why not? it seems to do just that? | 14:10 |
| zyga | (assuming you build an app from source) | 14:11 |
| seb128 | well | 14:11 |
| seb128 | right, I'm repackaging a deb | 14:11 |
| zyga | ah, right | 14:11 |
| seb128 | but then if you do that | 14:11 |
| zyga | for deb-repacking I agree | 14:11 |
| seb128 | what if need also strings from libc | 14:11 |
| seb128 | +you | 14:11 |
| zyga | what is the domain used by libc? | 14:11 |
| zyga | this feels like a SDK runtime problem | 14:11 |
| zyga | locale generation is perhaps more subtle | 14:11 |
| seb128 | libc.mo | 14:12 |
| seb128 | SDK sort of | 14:12 |
| zyga | but I think a snap developer should just end up with a bunch of .mo files | 14:12 |
| zyga | that they can even filter out if they want | 14:12 |
| seb128 | gettext() is not specific to a SDK | 14:12 |
| zyga | yes, but SDK should just solve it for people | 14:12 |
| zyga | for just fishing parts of binary debs, it feels tricky | 14:12 |
| seb128 | it could | 14:12 |
| zyga | so back to interfaces | 14:12 |
| zyga | we could design an interface that lets you do bind mounts and other magic | 14:12 |
| zyga | I just wonder if that's a solution (it doesn't feel like one) | 14:13 |
| seb128 | yeah, maybe not | 14:14 |
| seb128 | maybe we just make those part of pd | 14:14 |
| seb128 | and declare that core users can't have translations | 14:14 |
| zyga | basic locales? I would say yes | 14:14 |
| zyga | core users will probably use webapps | 14:14 |
| zyga | and if not, they can bundle the world if they want a custom kiosk localized GUI | 14:14 |
| seb128 | well, I guess as long as we provide easy tools to help them to bundle the world... | 14:15 |
| seb128 | it still feels to me that locales are a base feature of the OS and shouldn't have to be bundle | 14:15 |
| zyga | I think we should explore both sides, patching sources to understand snap runtime layout and environment variables and reach for low-hanging fruit | 14:15 |
| seb128 | but it's a good point that they take space and are not needed on a core | 14:15 |
| zyga | eventually I would hope that all important upstream projects have a getenv("SNAP") somewhere | 14:16 |
| seb128 | is having the deb repackaging case working a goal | 14:16 |
| zyga | and that they just work | 14:16 |
| seb128 | or just something hacking we play with? | 14:16 |
| zyga | that depends on if the upstreams support snap internally :) | 14:16 |
| === _morphis is now known as morphis | ||
| seb128 | yeah, I don't agree with that | 14:16 |
| zyga | I think our patches to n-m weren't merged | 14:17 |
| seb128 | projects shouldn't have to getenv for platform specifc hacks | 14:17 |
| zyga | but if they were ,you could repackage nm (or be closer to) instead of having to build it | 14:17 |
| zyga | seb128: I somewhat disagree, this is a big shift | 14:17 |
| zyga | seb128: relocatability | 14:17 |
| zyga | seb128: nothing really supports that out of the box yet | 14:17 |
| zyga | perhaps it is not SNAP, perhaps SNAP Is in some common platform glue | 14:17 |
| morphis | sergiusens: ping | 14:17 |
| zyga | but patching upstreams for native relocatability would be worth-while IMHO | 14:18 |
| qengho | Spin up a new autopkgtest machine that uses "dpkg --instdir=/relocated/" to install. | 14:22 |
| popey | jdstrand: I have an app doing "Bad system call" inside a snap, in dmesg I see an apparmor failure with sig=31 arch=40000003 syscall=45 compat=1 ip=0xf77e3547 code=0x0 - is this something I can work around, a bug, or something else? | 14:24 |
| * zyga looks | 14:24 | |
| qengho | Oh, popey. So innocent. | 14:24 |
| popey | wat wat wat | 14:25 |
| zyga | that's shmctl | 14:25 |
| ogra_ | scmp_sys_resolver 45 | 14:25 |
| ogra_ | run that | 14:25 |
| jdstrand | popey: on the device do 'scmp_sys_resolver 45' | 14:25 |
| kyrofa | Hey seb128 dholbach I'm around now | 14:25 |
| ogra_ | zyga, how do you know ? it varies between arches ;) | 14:25 |
| jdstrand | popey: it must be on the device/vm | 14:25 |
| zyga | ogra_: yes, true, I checked for amd64 | 14:25 |
| popey | jdstrand: inside the snap? | 14:26 |
| zyga | brb | 14:26 |
| ogra_ | :) | 14:26 |
| popey | this is on my laptop | 14:26 |
| ogra_ | zyga, it is brk on armhf | 14:26 |
| jdstrand | zyga, ogra_: note the syscall numbers are different depending on the arch | 14:26 |
| popey | (amd64) | 14:26 |
| jdstrand | popey: ok, on amd64 that should be recvfrom | 14:26 |
| popey | yes | 14:26 |
| jdstrand | popey: you need to plug one of network, x11 or unity7 | 14:27 |
| jdstrand | popey: if you are, autoconnecting isn't working for you | 14:27 |
| popey | I have all 3 | 14:27 |
| popey | plugs: [x11, network, network-bind, unity7, opengl] | 14:27 |
| jdstrand | popey: right, my understanding is that removing and installing again will get it to connect | 14:27 |
| jdstrand | popey: otherwise you can manually connect | 14:27 |
| jdstrand | zyga: I asked slvn to file a bug for that, but I think he had to step away. do you have a bug for this? ^ is it known to you? | 14:28 |
| popey | jdstrand: removing "it" as in, the snap? | 14:28 |
| jdstrand | popey: yes | 14:28 |
| seb128 | jdstrand, that's 32 bits code on amd64, unsure if that makes a difference? | 14:29 |
| jdstrand | zyga: in other news, I figured out why the unintended bluez change ended up in my branch and have adjusted my processes | 14:29 |
| seb128 | if I understood popey correctly | 14:29 |
| jdstrand | seb128: I think you just confused me :) | 14:29 |
| jdstrand | he had a seccomp denial | 14:29 |
| seb128 | right, I'm just saying that he's multiarching | 14:30 |
| jdstrand | so I just asked that he run scmp_sys_resolver on whatever architecture logged the denial | 14:30 |
| seb128 | k | 14:30 |
| jdstrand | multiarch doesn't matter | 14:30 |
| seb128 | I was mentioning in case | 14:30 |
| jdstrand | thanks | 14:30 |
| seb128 | np | 14:30 |
| popey | bah! got into the state where I have to nuke and pave again :( | 14:31 |
| seb128 | :-( | 14:31 |
| seb128 | hey kyrofa | 14:31 |
| seb128 | is there a way to tell snapcraft to rebuild without wipping out the deb cache? | 14:32 |
| popey | seb128: I ended up installing apt-cacher-ng on my laptop | 14:32 |
| seb128 | popey, :-( | 14:32 |
| popey | seb128: feel free to point your apt at my laptop as a proxy ã‹› | 14:32 |
| seb128 | but thanks for the tip | 14:32 |
| kyrofa | seb128, you can clean individual steps of the lifecycle-- would that help? | 14:32 |
| popey | (I appreciate you may not want to) | 14:33 |
| kyrofa | seb128, instead of cleaning the pull, just clean back to build | 14:33 |
| seb128 | kyrofa, I ended up reworking my yaml but that feels like a workaround | 14:33 |
| seb128 | kyrofa, oh ok | 14:33 |
| kyrofa | seb128, essentially instead of cleaning everything, you say "don't wipe out the pulled stuff." | 14:33 |
| seb128 | I ended up having 2 parts | 14:33 |
| seb128 | and cleaning only one | 14:33 |
| seb128 | I didn't know that my issue was due to "cleaning the pull" | 14:34 |
| seb128 | or that was a thing | 14:34 |
| seb128 | thanks | 14:34 |
| kyrofa | seb128, no problem! Yeah try `snapcraft clean -s build` (by default it cleans everything, including the pull step) | 14:34 |
| seb128 | that sounds like a poor default :p | 14:34 |
| seb128 | kyrofa, thanks! | 14:34 |
| dholbach | kyrofa, thanks... I was wondering if sergiusens, you and I could pick dates/times for the snapcraft UOS sessions | 14:36 |
| dholbach | we're still very much free to pick times between 14 and 20 UTC on 3-5 May | 14:37 |
| kyrofa | dholbach, yeah sounds good. sergiusens is running a few errands right now and I have a meeting in a few minutes, but after that I'm free all day | 14:37 |
| popey | Argh, "sudo snap install mylocalfoo.snap" on a clean box will download ubuntu core, fail to install it, fail to download my local snap from the store, but install my local one anyway, without ubuntu-core. So next time I try something it tries to download ubuntu-core again! | 14:43 |
| ogra_ | uh | 14:43 |
| ogra_ | popey, so your snap is i386 ? | 14:44 |
| ogra_ | i wonder if it tries to download the matching core | 14:44 |
| popey | nope | 14:45 |
| ogra_ | hmm, k | 14:45 |
| ogra_ | i wonder why it fails then | 14:45 |
| popey | also, you have to remove snaps before installing them again, or you get a broken snap installed. | 14:46 |
| popey | repeatedly installing the same snap over and over leads to a non-functioning snap | 14:46 |
| jdstrand | popey: between those two and not autoconnecting, it sounds like you are hitting 3 bugs :\ | 14:47 |
| popey | \o/ | 14:47 |
| jdstrand | popey: 4 now :\ | 14:47 |
| roadmr | a bug trifecta | 14:47 |
| jdstrand | popey: would you mind filing them? | 14:47 |
| popey | sure thing | 14:47 |
| jdstrand | I don't think any are filed | 14:47 |
| jdstrand | thanks! | 14:47 |
| * zyga confused signal number with syscall number | 14:51 | |
| ogra_ | mvo, ricmm, http://paste.ubuntu.com/16095818/ should we start with that ? | 14:51 |
| slvn | jdstrand, zyga : I have just retried this "auto-connect" issue with new package name, and it worked. then I did a "reset-state". the first new install was longer (installation of 64 MB ? whereas the snap is 2 Mo ...). and x11 didn't connect. re-install, it worked. To me, the issue seems something missing in the script "reset-state". Since this is non-official, should I make be a bug report ? | 14:52 |
| zyga | slvn: interesting | 14:52 |
| zyga | slvn: no, I'll experiment, thanks | 14:52 |
| zyga | slvn: the first time when you installed the snap it bundled ubuntu-core with it | 14:52 |
| zyga | slvn: when you installed the snap, was that side-loaded (locally on your FS) or from the store? | 14:52 |
| zyga | slvn: snap install ./foo.snap or snap install foo | 14:52 |
| zyga | ogra_, jdstrand: How do you lookup syscalls? | 14:53 |
| ogra_ | scmp_sys_resolver | 14:53 |
| jdstrand | zyga: signal vs syscall> easy to do | 14:53 |
| zyga | jdstrand: I know how to lookup signal numbers | 14:53 |
| * jdstrand wants to get to fixing snappy-debug to help people in this regard but has a few more things to tend to first | 14:54 | |
| zyga | jdstrand: but not syscall numbers | 14:54 |
| jdstrand | scmp_sys_resolver ... | 14:54 |
| zyga | ahhh | 14:54 |
| jdstrand | (on the device) | 14:54 |
| jdstrand | always on the device :) | 14:54 |
| zyga | thanks! | 14:54 |
| jdstrand | (unless you know your archs are the same of course) | 14:55 |
| zyga | yeah, I had an index somewhere but I lost it now | 14:55 |
| jdstrand | seb128: hey, I saw you mention something about trying to get the tree together for me and others to test-- what is the status (just wondering if I should move to the next thing on my list and circle back or not-- no big rush) | 14:56 |
| seb128 | jdstrand, I'm about to push | 14:58 |
| slvn | zyga, I have always installed the snap from my FS. I haven't played with the store yet. | 15:00 |
| dholbach | kyrofa, ok | 15:01 |
| jdstrand | seb128: thanks | 15:07 |
| seb128 | jdstrand, ok, lp:~ubuntu-desktop/+junk/gnome-calculator-snap updated | 15:09 |
| jdstrand | seb128: thanks! | 15:09 |
| seb128 | jdstrand, yw! | 15:09 |
| seb128 | jdstrand, I'm going to file some bugs now about the issues we had/have and the workaround we did | 15:10 |
| seb128 | jdstrand, btw got https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1576066 filed about the 32bits issue | 15:10 |
| ubottu | Launchpad bug 1576066 in glibc (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,New] | 15:10 |
| zyga | jdstrand: just curious, what's the outlook on non-enforcing seccomp landing in the kernel? | 15:11 |
| seb128 | jdstrand, "justincornack" says that updating libseccomp to 2.3.0 should fix it | 15:11 |
| jdstrand | zyga: I need to work with them on it. we have a good relationship with them, it is just devmode is a couple places down the list atm | 15:12 |
| zyga | jdstrand: sure understood | 15:13 |
| zyga | jdstrand: is there a place where I can look at the list? | 15:13 |
| jdstrand | zyga: at my list? | 15:13 |
| jdstrand | the security team trello board | 15:13 |
| zyga | jdstrand: do you have a link handy by any chance? | 15:13 |
| jdstrand | seb128: oh interesting | 15:14 |
| jdstrand | seb128: thanks! | 15:14 |
| seb128 | jdstrand, yw! | 15:14 |
| seb128 | jdstrand, I guess we should SRU https://github.com/seccomp/libseccomp/commit/73d83e45efbe8c31067c97155162f17ca51b7435 | 15:16 |
| seb128 | desrt, ^ | 15:16 |
| desrt | this won't help | 15:16 |
| seb128 | oh :-( | 15:17 |
| desrt | this only helps if the C library is indeed calling those new functions | 15:17 |
| slvn | zyga, not sure you got the message : I have always installed the snap from my FS. I haven't played with the store yet. | 15:17 |
| zyga | slvn: ah, thanks | 15:18 |
| zyga | slvn: perhaps there's some interesting bug in that case, I'll give it a try | 15:18 |
| desrt | actually, i may take that back. i have no idea what this does =) | 15:18 |
| desrt | and maybe it does contain/improve demuxing for that call, indeed | 15:18 |
| zyga | slvn: I know for a fact that there are plenty of related bugs fixed in master (to be released very soon) | 15:18 |
| zyga | slvn: perhaps tomorrow it will be in the archive | 15:18 |
| seb128 | jdstrand, desrt, there are also other commits in trunk that might help in fact, our version is old | 15:19 |
| slvn | zyga, I used the same SDL2/snap of the other bug to test it. | 15:19 |
| ogra_ | you have high hopes about our SRU process it seems :) | 15:19 |
| seb128 | e.g https://github.com/seccomp/libseccomp/commit/d32c3bfa4b07add90dcd04292eb4ba278dd103ba | 15:19 |
| zyga | slvn: right, we had a bug that didn't auto-connect in some cases, I suspect it is that, I'll check again when I have power | 15:20 |
| seb128 | though pitti backported some of those changes already it seems | 15:20 |
| zyga | slvn: I'll ping you tomorrow, after the release is out | 15:20 |
| slvn | zyga, I'll also tomorrow if there is some update: | 15:20 |
| desrt | https://github.com/seccomp/libseccomp/commit/983835f3e0fd000a42c8beaea9d7fbe726ffff65 | 15:20 |
| desrt | this is the one that will really help | 15:20 |
| desrt | " + * Convert a multiplexed pseudo socket syscall into a direct syscall " | 15:21 |
| zyga | jdstrand: there's a micro task for home to auto-connect | 15:21 |
| zyga | jdstrand: do you think we should set it to auto-connect and let the store flag that for review? | 15:21 |
| * ogra_ wonders if we should prehaps grow the reviwers team | 15:22 | |
| zyga | gahh, sorry, battery dies | 15:23 |
| * zyga orders a new battery, power cuts are annoying | 15:23 | |
| zyga | ttyl | 15:23 |
| jdstrand | zyga: I think autoconnecting is fine-- the store currently flags for manual review. But the topic overall has an unclear path. sabdfl said to do one thing with x11/unity7 and niemeyer another. home to me is the same sort of thing. | 15:26 |
| mvo | ogra_: I like that, lets do it | 15:31 |
| ogra_ | mvo, ok, will upload then | 15:32 |
| seb128 | jdstrand, what's the right component to file the bug about "unity7 plug profile needs updating for menus" | 15:33 |
| jdstrand | seb128: snapd. add the snapd-interface tag | 15:34 |
| seb128 | jdstrand, thanks | 15:34 |
| mvo | ogra_: nice, let us try to test today/tomorrow and see how it goes | 15:37 |
| ogra_ | yeah | 15:37 |
| ogra_ | well, we need someone who has a uboot gadget snap for i386 | 15:37 |
| ogra_ | i was hoping ricmm has something like that handy | 15:37 |
| seb128 | jdstrand, bug #1576287 | 15:38 |
| ubottu | bug 1576287 in snapcraft (Ubuntu) "unity7 plug needs to be updated to allow menus export" [Undecided,New] https://launchpad.net/bugs/1576287 | 15:38 |
| jdstrand | seb128: thanks | 15:46 |
| sborovkov | Hello, how do I enable classic shell now? snap enable-classic does not work | 15:53 |
| jdstrand | mvo: hey, does being a member of ubuntu-core on github give me commit access? | 15:57 |
| mvo | jdstrand: hm, I actually don't know, commit access to snappy on github? just create your branch and send a pull-request | 16:02 |
| jdstrand | mvo: I did that, but I also got an invite not long ago nad just accepted. my branch is tagged Reviewed. I wasn't sure if I should wait or commit and wanted to ask what the commit policy was | 16:03 |
| mvo | jdstrand: oh, ok. I think I saw that there was one outstanding question on the branch. or did that get resolved? if resolved one of us will merge it | 16:04 |
| jdstrand | mvo: I resolved it and made two reverts based on mailing list and bug feedback | 16:05 |
| mvo | jdstrand: nice, let me have a look then, I can merge it | 16:06 |
| mvo | jdstrand: usually (but not always) its branch-owner != person-who-merges | 16:06 |
| jdstrand | I see | 16:06 |
| mvo | jdstrand: we also have no separate branch for xenial and yakkety (love the name) | 16:07 |
| mvo | (yet) | 16:07 |
| jdstrand | ok | 16:07 |
| seb128 | jdstrand, mvo, just for the record that's some bug reports about the issues we hit when playing with gnome-calculator https://bugs.launchpad.net/ubuntu/+bugs?field.tag=snap-desktop-issue | 16:07 |
| jdstrand | nice | 16:08 |
| seb128 | jdstrand, I guess there is already one for the gsettings proxy work? | 16:09 |
| seb128 | or is it only in specs like https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement? | 16:10 |
| seb128 | opened one, we can close it if needed | 16:12 |
| jdstrand | seb128: the proper confinement for gsettings is a separate thing. snaps on classic could utilize that, but we'll likely simply need to add it and say it is a limitation of the mediation (much like X is) | 16:13 |
| jdstrand | s/need to add it/need to add the rules for the global gsettings/ | 16:14 |
| seb128 | jdstrand, right, good, thank we can use bug #1576308 | 16:14 |
| ubottu | bug 1576308 in snapd (Ubuntu) "gsettings doesn't work with snap confinement" [Undecided,New] https://launchpad.net/bugs/1576308 | 16:14 |
| wililupy | Good morning ogra_, mvo. | 16:15 |
| ogra_ | wililupy, good evening :) | 16:17 |
| seb128 | jdstrand, the libseccomp issue, gnome-calculator on i386 hits the bug (it needs to download currency info from internet), I can test patchs if you want, just ping me with commits or debs | 16:19 |
| wililupy | I got the system to boot today after adding ahci to the initrd modules in snapcraft, but I still had to edit the grubenv file on /dev/sda2 to point to my kernel snap to boot up properly. | 16:21 |
| jdstrand | seb128: thanks | 16:22 |
| ogra_ | wililupy, right, and that bit is out of my territory of knowledge ... mvo might be a better counterpart here | 16:24 |
| wililupy | ogra_ Thank you so much for your assistance on this. I now have a working Kernel snap with the modules in it, so now all I have to do is snap up the application and test it and I could be back on schedule. I still need to work on the grubenv so that install is easy and doesn't require user intervention. | 16:25 |
| mvo | wililupy: hm, is your kernel called vmlinuz and the initird.img ? the code currently assumes that | 16:26 |
| wililupy | mvo, do you know why the grubenv doesn't update with the snappy_kernel= variable? | 16:26 |
| mvo | wililupy: a symlink is probably fine | 16:26 |
| wililupy | let me check mvo. | 16:26 |
| mvo | wililupy: it should if the kernel snap is of type: kernel, could you paste your meta/snap.yaml please? I need to look what is going on | 16:27 |
| wililupy | definitely mvo. | 16:27 |
| mvo | wililupy: and please pastebin the output of grub-editenv right after you installed your kernel | 16:27 |
| wililupy | sure. | 16:27 |
| mvo | (but before you manually adjusted something) | 16:27 |
| mvo | cool, thank you! | 16:27 |
| wililupy | mvo: meta/snap.yaml: https://pastebin.canonical.com/155478/ | 16:30 |
| ogra_ | oha | 16:32 |
| wililupy | mvo: (hd,2)/EFI/ubuntu/grub.d/grubenv: https://pastebin.canonical.com/155479/ | 16:32 |
| ogra_ | why doesnt snapcraft set "type: kernel" ? | 16:33 |
| mvo | wililupy: could you please add "type: kernel" and see if that helps? | 16:33 |
| * ogra_ guesses there is your issue | 16:33 | |
| mvo | aha ogra_ was faster :) | 16:33 |
| * mvo hugs ogra_ | 16:33 | |
| ogra_ | heh | 16:33 |
| * ogra_ hugs mvo | 16:33 | |
| wililupy | I can post my snapcraft.yaml | 16:33 |
| mvo | just add this one line first, that sounds very likely to be the culprit | 16:34 |
| ogra_ | but it is weird, given the snapcraft kernel plugin was used | 16:34 |
| ogra_ | i woudl actually expect that it sets that | 16:34 |
| wililupy | https://pastebin.canonical.com/155480/ | 16:35 |
| wililupy | type: kernel before the parts: section? | 16:35 |
| ogra_ | in meta/snap.yaml | 16:35 |
| wililupy | gotcha ogra_ | 16:36 |
| ogra_ | and then just "snapcraft snap" the dir | 16:36 |
| kyrofa | It seems /snap/bin is not in the PATH if I try to run with sudo. This worked in rolling-- is it a bug, or is it supposed to work this way? | 16:37 |
| sergiusens | popey I logged bugs about install/remove/install/remove/.../.../install | 16:38 |
| wililupy | snapcrafting now. | 16:38 |
| sergiusens | seb128 log a bug about the ARCH thing, we can support it easily | 16:39 |
| seb128 | sergiusens, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576232 | 16:39 |
| ubottu | Launchpad bug 1576232 in snapcraft (Ubuntu) "Doesn't allow dynamic file install targets ('usr/lib/$arch')" [Undecided,New] | 16:39 |
| jdstrand | mvo: thanks for the merge. I'm not sure who is doing release notes, but one of those commits fixes bug #1575914 | 16:40 |
| ubottu | bug 1575914 in Snappy "snaps using home interface have full access to SNAP_USER_DATA of other snaps" [High,In progress] https://launchpad.net/bugs/1575914 | 16:40 |
| mvo | jdstrand: uh, thanks. a "Closes: LP#1575914" in the commit picks it up automatically | 16:42 |
| sergiusens | seb128 thanks, I love bugs! :-) | 16:43 |
| seb128 | yw! | 16:43 |
| jdstrand | mvo: oh, whoops | 16:43 |
| jdstrand | mvo: I'll know for next time | 16:43 |
| wililupy | mvo, ogra_ same error, I have to modify the grubenv to boot up properly. | 16:44 |
| * jdstrand updates his notes for autoclosing snappy bugs | 16:44 | |
| mvo | jdstrand: no worries, I will add it later manually | 16:45 |
| wililupy | weird, it didn't update the snap.yaml... | 16:47 |
| wililupy | I updated it in the snap directory and then re-ran snapcraft snap.... hmmmm | 16:47 |
| ogra_ | E: config/hooks/15-remove-grub-common.chroot failed (exit non-zero). You should check for errors. | 16:47 |
| ogra_ | P: Begin unmounting filesystems... | 16:47 |
| ogra_ | P: Saving caches... | 16:47 |
| ogra_ | GRRR ! | 16:47 |
| wililupy | looks like snapcraft snap overwrote my meta/snap.yaml with the one without type:kernel. | 16:49 |
| ogra_ | hmm, it shouldnt do that | 16:50 |
| kyrofa | wililupy, the snap folder it _output_, not input | 16:51 |
| kyrofa | is* | 16:51 |
| wililupy | kyroga, the snap directory, correct? | 16:52 |
| wililupy | kyrofa ^ | 16:52 |
| kyrofa | wililupy, right | 16:53 |
| ogra_ | kyrofa, we only wannt to check a one line change in snap.yaml .. and not re-build anything but the snap | 16:53 |
| om26er | stgraber, Hi! ChrisTownsendwas helping me debug an lxc container not starting, he suggested me to show the logs to you. Can you please take a look at these logs ? http://paste.ubuntu.com/16102061/ | 16:53 |
| wililupy | I modified the snap/meta/snap.yaml there, then went back to my source directory and ran snapcraft snap. | 16:54 |
| kyrofa | ogra_, try `snapcraft snap snap` then? | 16:54 |
| kyrofa | ogra_, tell snapcraft to use the snap directory to create the snap rather than going through its lifecycle to do so | 16:54 |
| wililupy | I'll t ry that, can't hurt | 16:54 |
| ogra_ | kyrofa, yeah, thats what i mean abover with <ogra_> and then just "snapcraft snap" the dir | 16:55 |
| ogra_ | :) | 16:55 |
| ogra_ | i should have written "snapcraft snap snap" :) | 16:55 |
| kyrofa | wililupy, ogra_ it's also worth noting that snapcraft will re-generate the meta/ directory each time, even if the rest of the lifecycle has already run | 16:55 |
| ogra_ | oh | 16:55 |
| kyrofa | wililupy, ogra_ i.e. you don't need to rebuild the project just to change the meta/ dir | 16:55 |
| ogra_ | well, he could just move the snapcraft.yaml away :) | 16:56 |
| ogra_ | then it will just roll the dir into a snap | 16:56 |
| ogra_ | without regenerating anything | 16:56 |
| wililupy | meta/snap/snap.yaml still has my changes after running snapcraft snap snap | 16:57 |
| wililupy | Another u-d-f and a burn in on the device... | 16:57 |
| ogra_ | mvo, hmm, not sure why but seems my changes to live-build/ubuntu-core/hooks/15-remove-grub-common.chroot make the world explode (on all arches) | 16:58 |
| * ogra_ doesnt understand why ... very weird | 16:59 | |
| ogra_ | http://paste.ubuntu.com/16103786/ | 17:01 |
| * ogra_ scratches head | 17:01 | |
| wililupy | ogra_, mvo, kyrofa: That did it!! | 17:01 |
| ogra_ | wililupy, well, we still dont know why snapcraft.yaml doesnt add the type field | 17:01 |
| ogra_ | it should do that by default with the kernel plugin | 17:01 |
| wililupy | yeah, should I put in a bug? | 17:02 |
| ogra_ | sergiusens, ^^^ is that a bug ? (kernel plugin not setting type: kernel in snap.yaml) | 17:05 |
| sergiusens | ogra_ you have to do that in your snapcraft.yaml | 17:06 |
| ogra_ | sergiusens, https://pastebin.canonical.com/155480/ | 17:07 |
| ogra_ | does it need extra mentioning of type: kernel ? | 17:07 |
| sergiusens | ogra_ yes | 17:12 |
| ogra_ | ah ! | 17:12 |
| * ogra_ didnt know :) | 17:12 | |
| sergiusens | ogra_ we have no contract for plugins changing top level things | 17:12 |
| ogra_ | pfft :P | 17:13 |
| sergiusens | ogra_ it is a constant discussion we have internally as it would be ideal to also create apps and commands | 17:13 |
| ogra_ | yeah | 17:13 |
| sergiusens | ogra_ but then what happens when the use wants to do something special :-) | 17:13 |
| ogra_ | well, if it is set at the top level you dont touch it ... if nothing is set at the toplevel the plugin takes over | 17:15 |
| sergiusens | ogra_ what if you want to payload a kernel in a normal snap app? | 17:15 |
| sergiusens | for some weird reason | 17:15 |
| ogra_ | notmal snaps dont have a type ? | 17:16 |
| ogra_ | *normal | 17:16 |
| sergiusens | ogra_ implicit type 'app' | 17:17 |
| wililupy | sergiusens, so where in my snapcraft.yaml to I tell it that it is a type: kernel snap? | 17:24 |
| sergiusens | wililupy same level as name, summary, ... | 17:25 |
| wililupy | sergiusens: so after description: add type: kernel before parts: | 17:26 |
| sergiusens | wililupy order doesn't matter in yaml, just make it at the same level | 17:27 |
| wililupy | sergiusens: ack. Going to try it now. | 17:27 |
| sergiusens | ubottu hey | 17:41 |
| sergiusens | kyrofa hey, can you reach nodejs.org? | 17:42 |
| kyrofa | sergiusens, yessir | 17:42 |
| sergiusens | darn, what happened to my DNS? | 17:42 |
| * sergiusens reboots router | 17:42 | |
| sergiusens | kyrofa here you go https://github.com/ubuntu-core/snapcraft/pull/490 | 18:10 |
| sergiusens | kyrofa that is the one you thought of when you thought you thought incorrectly | 18:11 |
| sergiusens | elopio do you know the status of https://github.com/ubuntu-core/snapcraft/pull/480 ? | 18:14 |
| sergiusens | ogra_ so I push this (https://launchpad.net/snapcraft/+milestone/2.8.5) to yakety; wait for it to go in smoothly and then tag every bug in there to hint the SRU and then dput to xenial and wait? | 18:17 |
| sergiusens | is that it in a nutshell? | 18:17 |
| kyrofa | sergiusens, ah, you're right :P | 18:17 |
| ogra_ | sergiusens, yeah | 18:38 |
| ogra_ | there is a wikipage too for it | 18:38 |
| sergiusens | ogra_ I read the wiki page, twice; it assumes I know a bunch of things already :-) | 19:00 |
| sergiusens | ogra_ thanks | 19:00 |
| ogra_ | heh | 19:00 |
| ogra_ | bah ... | 19:00 |
| ogra_ | so i cant remove /boot/grub on the os snap because there is a file in it ! | 19:01 |
| ogra_ | silly stuff ... | 19:01 |
| ogra_ | unicode.pf2 | 19:01 |
| * ogra_ removes it anyway | 19:01 | |
| oparoz | Is there a particular reason the command wrapper changes the working dir to SNAP_DATA? | 19:09 |
| ogra_ | it is the writable dir the snap provides .... | 19:09 |
| ogra_ | (the default writable dir) | 19:09 |
| sergiusens | oparoz afaik it doesn't unless you tell it to | 19:10 |
| oparoz | Sure, but isn't it the user's responsibility to call commands from SNAP_DATA? | 19:10 |
| oparoz | sergiusens, maybe it's because I'm still on an older rolling Snappy then | 19:10 |
| ogra_ | the user would call from SNAP_USER_DATA ;) | 19:10 |
| sergiusens | oparoz yeah, not seeing it http://paste.ubuntu.com/16118454/ | 19:11 |
| ogra_ | SNAP_DATA is somewhere in /var/lib ... it is the writable bit your snap knows about and if executed without any cotext that is the place where binaries can write | 19:11 |
| kyrofa | sergiusens, the wrapper cds into it | 19:11 |
| sergiusens | kyrofa not from what I am seeing here though | 19:12 |
| sergiusens | look at my pastebin | 19:12 |
| ogra_ | if you execute a snap app in context of a user, then SNAP_USER_DATA is your place | 19:12 |
| sergiusens | unless you are talking about a daemon | 19:12 |
| oparoz | ogra_, let's say the user wants to wget something from a folder in SNAP_DATA, the files end up in the root of SNAP_DATA instead of the folder | 19:12 |
| sergiusens | kyrofa the qtlaunch script does iirc | 19:13 |
| sergiusens | but it is meant for UI apps, launched from a desktop file, so it should not really matter | 19:13 |
| kyrofa | sergiusens, oh, it was services with a workingdir I think | 19:13 |
| ogra_ | oparoz, that shouldnt happen, the stuff should end up in SNAP_USER_DATA in such a scenario ... | 19:13 |
| ogra_ | (i know it did in the past by default when i used my unconfined wget) | 19:14 |
| oparoz | ogra_, sergiusens that's the wrapper that gets created https://paste.ubuntu.com/16118505/ | 19:14 |
| oparoz | Just before ubuntu-core-launcher, there is a cd $SNAP_DATA | 19:15 |
| oparoz | sergiusens, ogra_ could it be because of the security policy? | 19:15 |
| kyrofa | oparoz, probably an old version, I don't see it in the current: https://github.com/ubuntu-core/snappy/blob/master/snappy/binaries.go#L62 | 19:15 |
| oparoz | I mean does it have an influence on the wrappers? | 19:15 |
| ogra_ | it could well be that i'm not up to date ... | 19:15 |
| * zyga smells 15.04 snappy | 19:16 | |
| ogra_ | regarding my knowledge | 19:16 |
| zyga | oparoz: that's 15.04 right? | 19:16 |
| kyrofa | zyga, nah, not 15.04 | 19:16 |
| oparoz | Thanks kyrofa | 19:16 |
| oparoz | zyga, thats the mvo image from february | 19:16 |
| zyga | ah | 19:16 |
| zyga | ancient stuff then | 19:16 |
| kyrofa | zyga, so rolling stable | 19:16 |
| oparoz | Indeed | 19:16 |
| zyga | SNAP_APP_doesn't exist anymore | 19:16 |
| ogra_ | february ? | 19:17 |
| ogra_ | you should really update | 19:17 |
| kyrofa | ogra_, to what? A 16 image? :P | 19:17 |
| ogra_ | yeah ... | 19:17 |
| oparoz | :) | 19:17 |
| ogra_ | feb is definitely before 2.0 | 19:17 |
| kyrofa | Indeed | 19:17 |
| zyga | oparoz: you can use my script to build a new image using mvo's udf | 19:18 |
| zyga | oparoz: github.com/zyga/devtools | 19:18 |
| ogra_ | for 16.04 only the images from the last two weeks are actually ok | 19:18 |
| zyga | oparoz: though images are not fully supported now, you may have to re-flash periodically as we stabliize | 19:18 |
| zyga | ogra_: full of bugs, the next set will be okay (with next version of snapd) | 19:18 |
| oparoz | Thanks zyga, the problem is that all users of the ownCloud snap are still on that image, so I can't update yet | 19:18 |
| ogra_ | sure, full of bugs, but up to date with the right concepts at least | 19:19 |
| ogra_ | while all older images are simply broken | 19:19 |
| zyga | oparoz: I see | 19:19 |
| oparoz | But thanks for confirming that the change of dir doesn't happen any more | 19:19 |
| zyga | ogra_: I agree | 19:19 |
| zyga | there were more changes in the last month than in the year before | 19:19 |
| oparoz | ogra_, we have enough trouble getting people to test the image. If they need to re-flash every week, we're going to lose all of them | 19:20 |
| ogra_ | yeah, understood | 19:20 |
| zyga | oparoz: it would be nice to at least switch to 2.0 snappy because that old image feels like tech debt personified, it's going to bite you more the longer you wait | 19:20 |
| oparoz | But yeah, it's problemtic because some problems don't apply any more | 19:20 |
| ogra_ | it is just that any development you do on them is moot ... since the design of snappy changed a lot | 19:20 |
| zyga | you probably require an interface, you won't find that on that old image | 19:20 |
| kyrofa | zyga, still using old-security there. Fortunately the interfaces required are simple (network and network-bind) | 19:21 |
| zyga | I think you have a tough choice ahead | 19:21 |
| zyga | kyrofa: cool, nothing fancy to access hdds? | 19:21 |
| kyrofa | zyga, we're splitting partitions | 19:21 |
| zyga | kyrofa: ah, interesting | 19:21 |
| oparoz | We're going to have to switch in the next 2 weeks anyway | 19:22 |
| kyrofa | So the upgrade path is actually pretty easy. It's just that 16 a) isn't stable and b) doesn't seem to support preinstalling snaps so we can't generate a factory image | 19:22 |
| kyrofa | Unless mvo's new u-d-f fixed the --install and it works on 16 | 19:23 |
| zyga | we're working on making udf saner again but it's still a roadmap | 19:23 |
| ogra_ | i thought that was fixed a while ago | 19:23 |
| zyga | I mean a permanent fix | 19:23 |
| zyga | not another layer of duct tape | 19:23 |
| * ogra_ doesnt know what everyone has against duct tape ... | 19:24 | |
| * oparoz agrees :D | 19:24 | |
| oparoz | except when it comes to software development ;) | 19:25 |
| zyga | I'd hear what you say if I dind't have duct tape over my ears ;) | 19:25 |
| ogra_ | well, at least you'll get rid of these hairs in your ears then :P | 19:25 |
| kyrofa | zyga, anyway, we'd love to jump to 16. But we need those things | 19:26 |
| kyrofa | So rolling stable is at least giving people something to test | 19:26 |
| zyga | kyrofa: those things? | 19:26 |
| kyrofa | stability and preinstalled snaps | 19:26 |
| zyga | kyrofa: I'm not sure I know what you refert to now | 19:27 |
| zyga | ah | 19:27 |
| zyga | stability as in debian stable, that I understand | 19:27 |
| zyga | preinstalled snaps, soon :) | 19:27 |
| zyga | ish | 19:27 |
| * zyga loves 'ish' | 19:27 | |
| * ogra_ used to work for "ish" | 19:27 | |
| oparoz | zyga, weeks? | 19:27 |
| zyga | oparoz: ask me after the next sprint | 19:27 |
| oparoz | zyga, OK | 19:27 |
| zyga | oparoz: now I can reliably predict by looking at coffee leftovers or other wizardy | 19:28 |
| kyrofa | oparoz, which is in 10 days | 19:28 |
| zyga | ish | 19:28 |
| zyga | yep | 19:28 |
| ogra_ | https://de.wikipedia.org/wiki/Ish_%28Unternehmen%29 | 19:28 |
| ogra_ | (not even available in english ) | 19:28 |
| kyrofa | ogra_, wait.. you were serious? :P | 19:28 |
| zyga | LOL | 19:28 |
| ogra_ | yeah :) | 19:28 |
| zyga | that explains a lot ;) | 19:28 |
| zyga | hehe | 19:28 |
| zyga | lovely company name | 19:29 |
| ogra_ | that was my last job before canonical ... leading a tech team of 15 ppl | 19:29 |
| * zyga recalls the company that makes light bulbs "osram", which is very popular in poland despite the name | 19:29 | |
| ogra_ | cable internet was the new thing in germany back then | 19:29 |
| kyrofa | I can hear the promo now: "Stable... fast.. _ish_" | 19:29 |
| oparoz | (kyrofa, 10 days is good, we can make a decision then) | 19:30 |
| kyrofa | Hey sergiusens I figured out what was wrong with the ROS example | 19:43 |
| kyrofa | sergiusens, it's a locale issue-- setting LC_ALL=C fixes it | 19:44 |
| kyrofa | sergiusens, I guess something changed on xenial? | 19:44 |
| ogra_ | should be C.UTF-8 nowadays | 19:44 |
| ogra_ | (and iirc thats the default fallback in xenial) | 19:44 |
| kyrofa | ogra_, setting that works too, but without it it barfs | 19:45 |
| kyrofa | ogra_, but my ignorant american self doesn't know very much about locales :( | 19:45 |
| ogra_ | yeah, you're i ascii-land | 19:45 |
| ogra_ | wow, snapcraft grew some solid dependencies ... | 19:47 |
| * ogra_ notes while reading image build logs that it pulls in 30 packages and eats 10MB nowadays | 19:47 | |
| ogra_ | (50MB installed) | 19:48 |
| oparoz | IF I want to add "reload to a daemon, I simply add reload-command to the "app" in the yaml? | 19:56 |
| zyga | oparoz: not sure | 19:57 |
| zyga | gimme a sec | 19:57 |
| oparoz | https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/ | 19:57 |
| oparoz | No mention or reload, so I gues not... | 19:57 |
| zyga | one sec :) | 19:59 |
| zyga | checking now | 19:59 |
| oparoz | Thanks zyga :) | 19:59 |
| zyga | oparoz: so there's restart condition | 20:00 |
| zyga | but there is no restart command | 20:00 |
| zyga | wait | 20:00 |
| zyga | checking services | 20:00 |
| oparoz | zyga, I've noticed that restart works out of the box, but reload doesn't, so I thought I needed to add something to the yaml | 20:00 |
| * ogra_ sighs ... livecd-rootfs doesnt like me today | 20:01 | |
| zyga | there are ExecStop | 20:01 |
| zyga | ExecStopPost | 20:01 |
| zyga | ExecStart | 20:01 |
| zyga | and that's it | 20:01 |
| oparoz | :( | 20:01 |
| zyga | there's also Restart | 20:01 |
| zyga | what are you looking for exactly? | 20:01 |
| ogra_ | cant you send a HUP to the process if it is in the same snap ? | 20:02 |
| oparoz | zyga, in quite a few situations, you just want to reload a config without having to bring everything down and up again | 20:02 |
| zyga | oparoz: do what ogra_ said | 20:02 |
| oparoz | OK, I will give it a go | 20:03 |
| oparoz | pkill didn't work, but kill did, thanks ogra_ | 20:16 |
| ogra_ | good | 20:17 |
| wililupy | ogra_ adding the type: kernel to the snapcraft.yaml makes it work as designed! | 20:22 |
| ogra_ | yay | 20:22 |
| wililupy | No need to change anything manually. | 20:22 |
| ogra_ | good you finally got everything working :) | 20:22 |
| wililupy | Yes! | 20:23 |
| wililupy | Now on to building the app snap. This should be a little more straight forward. | 20:23 |
| zyga | oparoz: pkill would need /proc access | 20:23 |
| wililupy | Thank you so much ogra_, mvo, sergiusens, kyrofa! | 20:24 |
| zyga | morphis: any updates on https://github.com/ubuntu-core/snappy/pull/1036 | 20:24 |
| ogra_ | np | 20:24 |
| oparoz | Ah, thanks zyga. That was a question I had. Any daemon requesting access to /proc is hutdown, correct? | 20:24 |
| zyga | oparoz: not really, just denied access to pkill wound't be able to find all the details probably | 20:24 |
| zyga | oparoz: (depending on how pkill is written) | 20:24 |
| * zyga should finish the current post on snappy security | 20:25 | |
| oparoz | zyga, OK, so denied access which some "app" may not be too happy about | 20:26 |
| ogra_ | yay, finally ... | 20:40 |
| * ogra_ has the images building again | 20:40 | |
| zyga | ogra_: cool :-) | 20:43 |
| ogra_ | silly stuff ... | 20:43 |
| ogra_ | something like: | 20:43 |
| ogra_ | [ -d /boot/grub ] && rm -f /boot/grub | 20:43 |
| ogra_ | makes everything explode ... | 20:44 |
| ogra_ | because on all arches where that dir doesnt exist the test exits non-zero and tears down live-build | 20:44 |
| * ogra_ hates that common sense doesnt apply in some cases ... | 20:45 | |
| zyga | ogra_: like almost always? | 20:46 |
| ogra_ | heh | 20:46 |
| zyga | ogra_: note that common sense is just that, common, it's not really always sensible :) | 20:46 |
| kgunn | zyga: i was just wondering, when hacking on snap/snapd and using your tools...i was just doing refresh-bits snap/snapd/run-snapd...but should i be doing 'refresh-bits setup' first ? | 20:46 |
| ogra_ | so true | 20:46 |
| kgunn | i'm still not seeing any of my changes applied when i run the tools | 20:47 |
| kgunn | fwiw, i did try doing refresh-bits setup...but didn't make a diff | 20:47 |
| zyga | kgunn: setup is needed once per vm boot | 20:48 |
| zyga | kgunn: it ensures that regular snapd doesn't start by accident | 20:48 |
| zyga | kgunn: I run setup snapd run-snapd; then only snapd run-snapd | 20:48 |
| zyga | kgunn: what were you hoping to happen? | 20:49 |
| zyga | kgunn: what changes? | 20:50 |
| zyga | kgunn: after you push the new snapd to your VM you should uninstall/reinstall your mir snap | 20:52 |
| zyga | kgunn: and observe interfaces reported by snap interfaces | 20:52 |
| zyga | kgunn: and observe generated apparmor/seccomp profiles | 20:52 |
| kgunn | zyga: so question...if i don't install mir snap at all, and only run the mod'd snapd...and i type snap interfaces...i should see the mod correct? | 20:53 |
| zyga | what mod? | 20:53 |
| kgunn | zyga: mod== addition of an interface called mir | 20:53 |
| zyga | what were you expecting to see exactly, from what I remember from your branch you woundn't see anything new | 20:53 |
| zyga | there is no way to see the list if interfaces | 20:54 |
| zyga | just the list of plugs and slots | 20:54 |
| zyga | those come from snaps | 20:54 |
| zyga | note that the OS snap would *not* offer the mir slot | 20:54 |
| zyga | it would be offered by mir itself | 20:54 |
| zyga | so you'd have to install new snapd, install mir (snap) and see what the rsult is | 20:54 |
| kgunn | ok | 20:54 |
| zyga | does that make sense? | 20:55 |
| zyga | snapd would contain the implementation of mir interface | 20:55 |
| zyga | but that would only show up when you install the mir snap | 20:55 |
| zyga | normally snappy logs and ignores unknown interfaces on snaps | 20:55 |
| zyga | but with your patches, mir snap would really gain the mir slot | 20:56 |
| zyga | and would really gain the permanent permissions resulting from that slot | 20:56 |
| zyga | right? | 20:56 |
| kgunn | zyga: ok, maybe i've been trying to see something that simply won't happen | 20:56 |
| kgunn | i'll fiddle a bit more later with this...good to know on the setup run first time on vm tho | 20:57 |
| sergiusens | kyrofa sadly saying please is mandatory | 21:46 |
| ogra_ | you could also friendly say please though | 21:49 |
| ogra_ | :P | 21:49 |
| sergiusens | ogra_ not to a build system that decides to fail :-P | 21:55 |
| sergiusens | ogra_ imagine saying please to livecd rootfs ;-) | 21:55 |
| ogra_ | i did, it helped ! | 21:55 |
| thekeymaker | if you are building snaps using snapcraft on ubuntu 16.04, is there a easy way to try(run) them instead of installing them with the command snap install ./my-snap? | 22:15 |
| zyga | thekeymaker: not yet | 22:53 |
| zyga | thekeymaker: though installing them is very lightweight | 22:54 |
| zyga | thekeymaker: we just copy and mount them | 22:54 |
| zyga | there are plans to add a new command that will be even better but that's not finalized | 22:54 |
| zyga | thekeymaker: and also note that unless you run master you should remove the snap first, this will avoid hitting a number of known, fixed but (not released) bugs | 22:55 |
| oparoz | zyga are symlinked followed when a snap is removed or purged? | 23:10 |
| oparoz | *symlinks | 23:10 |
| zyga | I'm not sure, probably | 23:10 |
| zyga | but I don't really know and it's rather too late for me to check now | 23:10 |
| zyga | (and give you an accurate answer) | 23:11 |
| oparoz | yeah, no worries, was surprised to still see you here ;) | 23:11 |
| * zyga is writing a very long article | 23:11 | |
| oparoz | Ah :) | 23:11 |
| Domi | Hello, does anyone use Python in a snap? | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!