| mup | PR snapcraft#1044 closed: tests: use python2 to check the CLA <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1044> | 01:58 |
|---|---|---|
| mup | PR snapcraft#1032 closed: Use more secure temporary directory for parser runs <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1032> | 02:01 |
| === madprops_ is now known as madbot | ||
| === StoneTable is now known as aisrael | ||
| === mup_ is now known as mup | ||
| === tedg__ is now known as tedg_ | ||
| === madbot is now known as madprops | ||
| === dobey_ is now known as dobey | ||
| mup | Bug #1657633 opened: console-conf shows the previous IP address after reconfiguration <Snappy:New> <https://launchpad.net/bugs/1657633> | 03:26 |
| === chihchun_afk is now known as chihchun | ||
| Gcode | Help | 08:51 |
| Gcode | i want to learn python, for ethic hacking and sockts | 08:52 |
| === faenil_ is now known as faenil | ||
| === faenil is now known as faenil_ | ||
| morphis | ogra_: is https://code.launchpad.net/~snappy-dev/core-snap/trunk the right place to look for the core snap? | 09:29 |
| ogra_ | morphis, yep | 09:30 |
| ogra_ | morphis, what do you need ? | 09:31 |
| morphis | ogra_: we're close to add a configure hook to the core snap, so just checking where the source for it is :-) | 09:31 |
| ogra_ | oh | 09:31 |
| ogra_ | the backend needs to go into some deb ... probably ubuntu-core-config | 09:32 |
| ogra_ | from the image PPA | 09:32 |
| morphis | ogra_: so what assembles the core snap then? | 09:34 |
| ogra_ | live-build | 09:34 |
| ogra_ | (with livecd-rootfs holding the config and possible hacks) | 09:34 |
| morphis | and how can we get the meta/hooks/configure script added | 09:35 |
| ogra_ | hmm, you want to put the whole of it there ? uncludion the binaries you need ? | 09:37 |
| ogra_ | *uncluding | 09:37 |
| ogra_ | bah | 09:37 |
| ogra_ | *including | 09:37 |
| morphis | ogra_: it will be a simple bash script | 09:37 |
| ogra_ | ah, k | 09:37 |
| ogra_ | yeah, that might be fine | 09:37 |
| morphis | we just need one option to enable/disable sshd | 09:37 |
| mup | PR snapd#2660 closed: cmd: fix typo (thanks to jdstrand!) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2660> | 09:37 |
| ogra_ | morphis, that will need more i guess | 09:38 |
| * ogra_ tries to touch /etc/ssh/sshd_not_to_be_run on a running system | 09:39 | |
| ogra_ | ah, no, seems fine, it is writable | 09:39 |
| morphis | :-) | 09:39 |
| morphis | ogra_: I guess that the configure hook within the core snap should have rights to do anything or is it run inside a confined environment too? | 09:40 |
| ogra_ | i thought we had only made individual files writable in that dir ... then you are fine just add or remove the file (and stop/start with systemctl) | 09:40 |
| ogra_ | morphis, how would it if the file is in the squashfs ? | 09:40 |
| ogra_ | it cant physically write to it then | 09:40 |
| morphis | that is true | 09:41 |
| ogra_ | but here we're fine, all of /etc/ssh is writable so you can just touch and remove it as you need | 09:41 |
| morphis | good | 09:41 |
| morphis | ogra_: so where is ubuntu-core-conf these days, still a single deb package sitting in the ppa or is a there a repository for it? | 09:42 |
| ogra_ | i dont think there is a repo | 09:42 |
| ogra_ | just grab the source deb from the ppa, make your changes and give it to someone who can upload | 09:43 |
| morphis | ogra_: aye | 09:45 |
| ogra_ | :) | 09:45 |
| ogra_ | morphis, you probably want to add some checks that a user exists and has a local password to not make it possible that the admin completely locks out himself | 09:46 |
| ogra_ | you are quite screwed if you disable ssh and have no local console access either | 09:46 |
| morphis | yeah | 09:47 |
| morphis | ogra_: what do we have to change in livecd-rootfs then? | 09:47 |
| ogra_ | nothing, meta/hooks/configure should be fine unless you need additional stuff from the image itself | 09:48 |
| morphis | so meta/hooks/configure inside ubuntu-core-conf, correct? | 09:48 |
| ogra_ | hmm | 09:49 |
| ogra_ | well, livecd-rootfs might work too ... i'm not sure if the build will respect an existing /meta dir inside the chroot though, might be that snapcraft ignores it | 09:50 |
| morphis | ogra_: so you're using snapcraft to build the final snap? | 09:51 |
| ogra_ | or that we actually delete it ... need to check the code ... there was something about old /meta | 09:51 |
| Kaleo | mvo, the ubuntu-core to core transition patch will be part of the next snapd release? | 09:51 |
| ogra_ | morphis, http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/Makefile ... line 26 :/ | 09:52 |
| * ogra_ goes to check the bug, perhaps we can drop that nowadays | 09:53 | |
| morphis | :-) | 09:53 |
| mvo | Kaleo: that is the goal, you can test the ppa that I gave to pat the other day if you want, I think the transition code is ok, I'm currently working on robustness and some warts but I think the core (no pun intended) is ok, so if you tst it I would appreciate results | 09:53 |
| morphis | ogra_: I will tell whoever will add the configure hook from our team to check with you first :-) | 09:53 |
| Kaleo | mvo, superb | 09:53 |
| Kaleo | mvo, I already manually migrated unfortunately | 09:53 |
| mup | PR snapd#2549 closed: cmd/snap-confine: add shutdown helper <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2549> | 09:54 |
| ogra_ | morphis, iirc the issue was that snapcraft didnt create anything in meta/ if the dir already existed ... so i'm not sure we can actually use that | 09:55 |
| morphis | ogra_: you could use a new part in snapcraft.yaml with the dump plug | 09:55 |
| ogra_ | we need to try what happens i fear | 09:55 |
| morphis | s/plug/plugin/ | 09:55 |
| Kaleo | mvo, is there any way for a single snap to be installable in either classic or devmode confinement? | 09:55 |
| morphis | then we don't have to maintain the hook inside ubuntu-core-conf at all | 09:55 |
| ogra_ | well, feel free to try it ... we can do tests in edge, that is what it is for ;) | 09:56 |
| morphis | good | 09:56 |
| ogra_ | in any case that line from the Makefile will likely need to go | 09:56 |
| mup | PR snapd#2449 closed: overlord/patch: patch to flag in the state required snaps from model <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2449> | 09:56 |
| mup | PR snapd#2650 closed: also include system-shutdown helper in snapd.install <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2650> | 09:56 |
| mvo | Kaleo: I think there is no way for a single snap to be installable in either classic or devmode confinement. but Chipaca might have ideas here | 09:59 |
| Kaleo | mvo, thanks | 09:59 |
| Chipaca | i'm not sure i understand the question | 09:59 |
| Kaleo | Chipaca, let's say I have an app snapped up | 10:00 |
| ogra_ | you can only install them in pairs ? | 10:00 |
| ogra_ | :P | 10:00 |
| Kaleo | Chipaca, and I'd like to be able to install it forcing either classic confinement or devmode confinement | 10:00 |
| Kaleo | Chipaca, why? because IIUC you cannot install an app with classic confinement in an all snaps image, right? | 10:01 |
| ogra_ | yeah | 10:01 |
| Chipaca | Kaleo, there isn't a way to do that today | 10:02 |
| Kaleo | ogra_, Chipaca, mvo: at the core of the issue, think about how you would go about snapping gnome-terminal | 10:03 |
| Kaleo | with the goal to make it one day work fine in an all snaps image | 10:03 |
| Kaleo | Chipaca, right, to do that, you can use classic confinement | 10:03 |
| Kaleo | Chipaca, ok | 10:03 |
| ogra_ | make it use a gazillion interfaces ? | 10:04 |
| Chipaca | Kaleo, in general however that's not something that makes sense | 10:04 |
| Chipaca | i mean, installing a classic snap on an all-snaps image | 10:04 |
| Chipaca | classic snap means it needs all the accoutrements of a classic system | 10:05 |
| Kaleo | ogra_, right | 10:05 |
| Kaleo | Chipaca, yeah, I'd like to install it confined, ie. override the classic confinement | 10:05 |
| Chipaca | which are not present in all-snaps | 10:05 |
| Kaleo | Chipaca, so let me explain | 10:05 |
| Kaleo | Chipaca, the main reason you want to use classic confinement for a terminal is to have / be / | 10:05 |
| Kaleo | Chipaca, and let the user of terminal have access to all commands available on the base system | 10:06 |
| ogra_ | which is probably not such a good idea in an all-snaps image anyway | 10:06 |
| ogra_ | (have / be / ) | 10:06 |
| Kaleo | ogra_, it depends if you envision say desktop users using an all snaps version of ubuntu or not | 10:06 |
| ogra_ | well, 96% of / will be readonly | 10:07 |
| Kaleo | ogra_, readonly is good | 10:07 |
| Kaleo | ogra_, it's not about writing on / | 10:07 |
| Kaleo | ogra_, it's about reading | 10:07 |
| ogra_ | and for the other 4% you want no user to touch the majority of it since it is managed via the system tools internally | 10:07 |
| Kaleo | ogra_, yep, I don't want anyone to write | 10:08 |
| ogra_ | so changing stuff underneath might break things badly | 10:08 |
| Kaleo | ogra_, no writes | 10:08 |
| Kaleo | ogra_, readonly / | 10:08 |
| pedronis | but with classic you can write there assuming you have sudo | 10:08 |
| Kaleo | pedronis, yes | 10:08 |
| Kaleo | pedronis, and that's a side effect I don't care for | 10:08 |
| ogra_ | i guess for that you could special case the apparmor rules | 10:08 |
| ogra_ | and have manual approval for that one package | 10:09 |
| Kaleo | ogra_, pedronis, what I just need for a terminal is / to be / | 10:09 |
| Kaleo | without / being writable | 10:09 |
| ogra_ | indeed thats a major security issue | 10:09 |
| pedronis | I really think that if the end goal is working on all-snaps, is better to start thinking what you need there | 10:09 |
| ogra_ | since you can see what other processes do | 10:09 |
| Chipaca | Kaleo, on all-snaps / is already / | 10:10 |
| ogra_ | Chipaca, but you cant look at all of it | 10:10 |
| ogra_ | i guess that is what he wants | 10:10 |
| ogra_ | which defeats security ... kind of | 10:11 |
| pedronis | so it's a bit of ther reverse problem, on classic / is not / unless classic | 10:11 |
| Chipaca | Kaleo, there's nothing stopping you from installing an 'strict' snap with --classic btw | 10:12 |
| ogra_ | Chipaca, on an all-snaps image ? | 10:13 |
| Chipaca | no, on classic | 10:13 |
| ogra_ | oh, you mean the other way around | 10:13 |
| ogra_ | yeah, ignore me ... coin took a bit to drop :P | 10:13 |
| morphis | Chipaca: for installation but I guess for running apps from it there is as from what I've heard from zyga | 10:13 |
| Chipaca | zyga, ^? | 10:15 |
| Chipaca | morphis, it's possible we've got bugs there :-) | 10:16 |
| Chipaca | I know of at least one | 10:16 |
| Kaleo | Chipaca, oh my god | 10:16 |
| Kaleo | Chipaca, how come I did not realise that | 10:16 |
| Kaleo | Chipaca, / is / with all snaps | 10:16 |
| Kaleo | Chipaca, " there's nothing stopping you from installing an 'strict' snap with --classic btw" | 10:16 |
| Kaleo | Chipaca, I was testing that just now | 10:16 |
| mup | PR snapd#2417 closed: interfaces/builtin: add uhid interface <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2417> | 10:16 |
| Kaleo | Chipaca, http://pastebin.ubuntu.com/23827096/ | 10:17 |
| Chipaca | Kaleo, it's a devmode snap, devmode+classic won't work | 10:17 |
| Chipaca | note i said strict | 10:17 |
| Kaleo | Chipaca, yep | 10:17 |
| Chipaca | k | 10:18 |
| Kaleo | Chipaca, though I need it to be devmode on all snaps because? | 10:18 |
| ogra_ | yeah, devmode wont buy you much if you want to use the store and snap find to find it | 10:18 |
| Kaleo | ogra_, you mean devmode makes it non visible in the store? | 10:18 |
| ogra_ | devmode cant go to the stable channel ... | 10:18 |
| mup | PR snapd#2546 closed: overlord: use a ticker for the pruning <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2546> | 10:18 |
| Chipaca | can't go to any stable-grade channel even | 10:18 |
| ogra_ | yeah | 10:19 |
| Kaleo | ok | 10:19 |
| Chipaca | Kaleo, you sure you need it devmode in all-snaps? | 10:19 |
| Kaleo | maybe not | 10:19 |
| Kaleo | I need to think that through | 10:19 |
| Kaleo | let's imagine that I don't | 10:19 |
| Chipaca | Kaleo, look at the things the htop snap uses | 10:20 |
| Kaleo | 1) is there a way to upload a strictly confined snap and have it be installed with --classic on classic automatically? | 10:20 |
| ogra_ | well, that only accesses parts of proc | 10:20 |
| Kaleo | 2) is there a programmatic way to detect what confinement we are under? | 10:20 |
| Chipaca | Kaleo, (1), no | 10:20 |
| Chipaca | Kaleo, (2), no | 10:20 |
| Chipaca | (2) should be easy to implement iffen jdstrand thinks it's a good idea (i'm not too sure it is) | 10:21 |
| Chipaca | (1) is a bad idea | 10:21 |
| Kaleo | (2) I'm not sure I will need it | 10:21 |
| Kaleo | (1) right, but then I need some other tool | 10:21 |
| Kaleo | (1) cause people really need / to be / for their terminal on a classic ubuntu | 10:21 |
| ogra_ | 2 -> grep snap_core /proc/cmdline ... | 10:21 |
| Kaleo | ogra_, nice | 10:22 |
| ogra_ | the prob is that you might not be able to access that | 10:22 |
| ogra_ | (at least not before manually connecting an interface ... so you wont be able to automate) | 10:22 |
| Chipaca | today you can | 10:22 |
| ogra_ | Chipaca, from a strict snap ? | 10:23 |
| Chipaca | yes | 10:23 |
| ogra_ | oh | 10:23 |
| ogra_ | i thought most of /proc was blocked by default | 10:23 |
| Chipaca | less is blocked than we want | 10:23 |
| ogra_ | except for /proc/self/ | 10:23 |
| Chipaca | because of issues | 10:23 |
| ogra_ | ah | 10:23 |
| mup | PR snapd#2661 opened: tests: skip on untrusted keys <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2661> | 10:23 |
| Chipaca | so i wouldn't count on it without checking with people that know more than me | 10:23 |
| ogra_ | yeah | 10:24 |
| timp | is this the correct channel to ask questions about snapcraft? | 10:24 |
| ogra_ | i'm pretty sure long term we dont want that | 10:24 |
| ogra_ | timp, try asking one and you will see ;) | 10:24 |
| timp | the store tells me for my snap: desktop interfaces (unity7) specified without meta/gui/*.desktop. Please provide a desktop file via setup/gui/*.desktop if using snapcraft or meta/gui/*.desktop otherwise. It should reference one of the 'apps' from your snapcraft/snap.yaml. lint-snap-v2_meta_gui_desktop | 10:24 |
| Kaleo | Chipaca, I switched the snap to strict then installed it with snap install --classic --dangerous ubuntu-terminal-app_0.11_amd64.snap | 10:24 |
| Kaleo | Chipaca, it looks like / is not / | 10:24 |
| Kaleo | Chipaca, even though it installation went fine | 10:25 |
| timp | in which step is this desktop file checked? I wonder if I need to have this desktop file available for the first step, or it can be there later. My snap is built from downloaded debs that already include desktop files | 10:25 |
| Kaleo | Chipaca, checking | 10:25 |
| Chipaca | Kaleo, in what sense is / not /? (not saying you're wrong, but wondering) | 10:25 |
| Kaleo | Chipaca, as in the / inside the snap environment is not the same filesystem as the / outside | 10:25 |
| Kaleo | Chipaca, double checking now | 10:25 |
| Chipaca | timp, it needs to be there in prime/ as far as i know | 10:26 |
| Chipaca | zyga, you here? | 10:26 |
| Kaleo | Chipaca, right, for example the contents of /bin are different inside of the snap and outside | 10:27 |
| timp | Chipaca: okay, thanks | 10:27 |
| Chipaca | Kaleo, but confinement lets you do pretty much everything? | 10:27 |
| Kaleo | Chipaca, checking | 10:27 |
| Chipaca | Kaleo, probably just something we need to do | 10:27 |
| Kaleo | Chipaca, (I think so) | 10:27 |
| Chipaca | (that's what i checked, that confinement seemed to be as expected) | 10:28 |
| pedronis | Kaleo: / is / doesn't mean we don't bind mount thing on top | 10:28 |
| Kaleo | pedronis, agreed | 10:28 |
| Kaleo | pedronis, but there is _less_ stuff | 10:28 |
| Chipaca | pedronis, yeah, but classic means don't do as much of that | 10:28 |
| Chipaca | i think? | 10:28 |
| Chipaca | paging dr zyga | 10:28 |
| zyga | hey | 10:29 |
| pedronis | Chipaca: we do less, but I think it still defeats the goal, though there is probably some way out of that | 10:29 |
| zyga | sorry, I don't get notifications for IRC | 10:29 |
| Kaleo | pedronis, knowing that when the same snap was built with confinement: classic instead of confinement: strict, there was way more content accessible | 10:29 |
| Kaleo | pedronis, even though both were installed with --classic | 10:29 |
| * zyga still needs to make a system that takes stuff from irssi on one VM and pushes it somewhere (say a lava lamp) | 10:29 | |
| zyga | so how can I help? | 10:29 |
| Chipaca | zyga, installing a strict snap with --classic | 10:30 |
| Chipaca | zyga, the mounts seem to be wrong | 10:30 |
| Kaleo | zyga, let's take it from the core of the issue: trying to have a terminal (say gnome-terminal) snapped and still useful on both classic ubuntu and all snaps ubuntu | 10:30 |
| Kaleo | ok :) | 10:30 |
| mup | PR snapd#2662 opened: interfaces: network-manager: allow rw access to /etc/netplan <Created by morphis> <https://github.com/snapcore/snapd/pull/2662> | 10:30 |
| Kaleo | zyga, strict snap with --classic: / seems to be the core snap, not the / of the classic ubuntu | 10:31 |
| zyga | strict snap with classic is meaningless | 10:34 |
| zyga | it will never work | 10:34 |
| zyga | as strict snaps are not built in a way that allows them to run in classic | 10:34 |
| Kaleo | zyga, ok | 10:34 |
| Kaleo | zyga, that's clear then | 10:34 |
| zyga | Kaleo: FYI, you cannot reuse binary packages easily for classic confinement snaps | 10:34 |
| Chipaca | zyga, we should block it then :-) | 10:34 |
| zyga | Kaleo: IMHO everything should be rebuilt | 10:34 |
| Kaleo | zyga, so back to the core of the matter: trying to have a terminal (say gnome-terminal) snapped and still useful on both classic ubuntu and all snaps ubuntu | 10:34 |
| Kaleo | zyga, Chipaca, or maybe we could publish 2 versions of a snap? | 10:35 |
| Kaleo | zyga, Chipaca, one classic and one strict | 10:35 |
| Chipaca | this is an all-snaps ubuntu that presumably has X somehow? | 10:35 |
| Kaleo | zyga, Chipaca, would the store allow that? | 10:35 |
| Kaleo | Chipaca, yeah | 10:35 |
| Kaleo | Chipaca, or MIR | 10:35 |
| Chipaca | MIR I buy :-) | 10:35 |
| Chipaca | Kaleo, with different names, sure | 10:36 |
| Kaleo | Chipaca, or whatever, just a display and a keyboard :;) | 10:36 |
| Kaleo | Chipaca, ideally with the same name :) | 10:36 |
| Kaleo | Chipaca, different name, I guess it's just a matter of having 2 entirely separate "snaps" | 10:36 |
| Chipaca | niemeyer, you here? | 10:36 |
| Kaleo | Chipaca, it's unpractical from a source code perspective: having 2 snapcraft.yaml | 10:36 |
| Kaleo | Chipaca, and not as nice for the user | 10:37 |
| zyga | Kaleo: the core version would need to snap the whole display stack (or use interfaces) | 10:39 |
| zyga | Kaleo: how do you expect to use it? | 10:39 |
| zyga | Kaleo: FYI, on core I think there's no good way to ship a terminal emulator that would be useful for developers | 10:40 |
| Chipaca | Kaleo, i've pinged niemeyer so we can think about how we *want* this to be | 10:40 |
| Kaleo | zyga, I would rather imagine it would uses interfaces (such as unity8) | 10:40 |
| zyga | Kaleo: interfaces give you permissions | 10:40 |
| zyga | Kaleo: what about all the runtime libraries, gtk, mir | 10:40 |
| Chipaca | Kaleo, as to how things are, today, i'm afraid it's two separate snaps (and i'm not sure you'll get what you expect/want even then) | 10:40 |
| Kaleo | zyga, right | 10:40 |
| zyga | Kaleo: content interface is not supported for snaps using classic confinement | 10:40 |
| zyga | Kaleo: I think the issue at hand is this: | 10:40 |
| zyga | Kaleo: you can make a perfect strictly-confined terminal emulator | 10:41 |
| Kaleo | zyga, that's indeed another issue I bumped into (I have a big snap atm) | 10:41 |
| zyga | Kaleo: but to be useful it must be allowed to run an unconfined shell | 10:41 |
| zyga | Kaleo: otherwise this is somewhat pointless | 10:41 |
| Kaleo | zyga, yeah | 10:41 |
| zyga | Kaleo: AFAIK gnome-terminal has a daemon process and is tied to the session bus | 10:41 |
| zyga | Kaleo: all this makes it a lot more complicated | 10:41 |
| Kaleo | zyga, you need to be able to do something as far as launching gnome-calculator from said terminal | 10:41 |
| niemeyer | o/ | 10:42 |
| Kaleo | zyga, yeah, let's take a simpler terminal to think about it | 10:42 |
| Kaleo | zyga, ubuntu-terminal :) | 10:42 |
| zyga | Kaleo: launching one snap from another is forbidden and there's no interface for that yet | 10:42 |
| Chipaca | running one snap's apps from another snap's app was not supported last time i checked | 10:42 |
| zyga | (and there's a kernel bug that prevents this right now) | 10:42 |
| Chipaca | zyga, have we done the legwork to support swapping profiles like that? | 10:42 |
| zyga | Chipaca: swapping apparmor profile is easy | 10:43 |
| niemeyer | Yeah, it's not | 10:43 |
| niemeyer | supported, that is | 10:43 |
| zyga | Chipaca: there are other things at play and they are broken (the reassociate-fix branch as all the details) | 10:43 |
| zyga | terminal emulators are like desktop environments | 10:43 |
| zyga | they run various apps | 10:43 |
| Chipaca | zyga, crazy to the head? | 10:43 |
| zyga | they feel like having super-powers | 10:43 |
| Chipaca | ah, that also | 10:43 |
| niemeyer | There are reasonable paths for us to support that, but not there yet | 10:43 |
| zyga | yeah | 10:43 |
| Kaleo | zyga, Chipaca, so right now, we can do the following: have 2 separate snaps, one classic, one confined; the classic one can be useful on classic and the confined one will be somewhat of limited usefulness | 10:44 |
| timp | any ideas why for the ubuntu-ui-toolkit-examples snap, I only have the options to release it to beta and edge? No candidate or stable | 10:44 |
| Chipaca | timp, it's devmode? | 10:44 |
| Kaleo | - but better than no terminal in an all snaps image | 10:44 |
| timp | Chipaca: right.... thanks :) | 10:45 |
| zyga | Kaleo: where do you expect to run the confined snap today? | 10:45 |
| zyga | Kaleo: on classic desktop or on something like raspberry pi? | 10:45 |
| Kaleo | zyga, the confined snap, on a desktop type device for which we might have an all snaps image; which I don't know we have | 10:45 |
| zyga | Kaleo: the classic snap would be an interesting thing to try anyway | 10:45 |
| Kaleo | zyga, the classic snap already works | 10:46 |
| zyga | Kaleo: just to see how hard it would be to take a complex real-world codebase and build it for classic | 10:46 |
| zyga | Kaleo: please do that regardless and work with sergio and kyrofa to make them aware of feedback | 10:46 |
| Kaleo | zyga, I switched ubuntu-terminal to classic (from devmode) and it works | 10:46 |
| zyga | Kaleo: how did you build the classic snap? did you try it on 14.04? (I suspect it doesn't work there) | 10:46 |
| Kaleo | zyga, tried on 16.04 | 10:46 |
| zyga | Kaleo: building and testing on 16.04 is somewhat tricky as you may build a broken snap that will only work on 16.04 | 10:47 |
| Kaleo | zyga, I kept all the stage-packages as they were when confined | 10:47 |
| Kaleo | zyga, so I would expect that the right libs are there in the snap and linked | 10:47 |
| zyga | Kaleo: building classic snaps with stage packages is wrong | 10:47 |
| zyga | Kaleo: sadly the only sane way is to build from source | 10:47 |
| zyga | (this is why it is hard) | 10:48 |
| Kaleo | zyga, even to prevent breakages? | 10:48 |
| Kaleo | zyga, I don't understand whyh | 10:48 |
| Kaleo | -h | 10:48 |
| zyga | Kaleo: do you want to? | 10:48 |
| zyga | :-) | 10:48 |
| Kaleo | to understand? :) | 10:48 |
| Kaleo | sure | 10:48 |
| zyga | Kaleo: because that snap transparently relies on your ubuntu system, for a correct snap it should only rely on /snap/core/current and /snap/$SNAP_NAME/current | 10:48 |
| Kaleo | zyga, yeah so you might forget snap-packages or might forget to change some paths | 10:49 |
| zyga | Kaleo: at almost every detail, from the dynamic linker, dynamic libraries, helper executables and data files | 10:49 |
| zyga | Kaleo: if you ever move away from 16.04 it will stop working | 10:49 |
| zyga | Kaleo: no, it's not "some paths" | 10:49 |
| Kaleo | zyga, but since I made the snap work in devmode | 10:49 |
| zyga | Kaleo: prebuilt packages will not work | 10:49 |
| zyga | Kaleo: you *must* built it from source and snapcraft must support classic confinement in each plugin you use | 10:49 |
| Kaleo | zyga, then I don't understand the point of classic snaps | 10:50 |
| zyga | Kaleo: that's the unfortunate reality; I would encourate you to check this on kde or on 14.04 kde for a "good test" | 10:50 |
| zyga | Kaleo: the point is as you thought it to be a moment ago | 10:50 |
| zyga | Kaleo: but the technical reality is that they cannot be built from binary packages | 10:50 |
| Kaleo | zyga, which you said is not reality | 10:50 |
| Kaleo | zyga, so no point :)$ | 10:51 |
| zyga | Kaleo: no, the point is to have no confinement in the way | 10:51 |
| Kaleo | zyga, I see | 10:51 |
| zyga | Kaleo: you can bring in gcc as a classic snap | 10:51 |
| zyga | Kaleo: git, vim | 10:51 |
| Kaleo | zyga, ok | 10:51 |
| zyga | Kaleo: gedit as well, but you must build from source | 10:51 |
| zyga | Kaleo: and all the build bits must do what is required (magic in snapcraft or hand-holding) | 10:51 |
| zyga | Kaleo: e.g. I've built a python0 snap as a classic confinement snap | 10:51 |
| zyga | Kaleo: look at the build system: | 10:51 |
| zyga | https://github.com/snapcore/snapd/pull/2581/files | 10:51 |
| mup | PR snapd#2581: debian: remove trusty specific bits <Created by mvo5> <https://github.com/snapcore/snapd/pull/2581> | 10:51 |
| zyga | I bet you this will work on any system under the sun | 10:52 |
| Kaleo | zyga, so, for right now, I can test the snap on more systems, and publish it only if it works ok; and even then work on a way to make terminals useful when fully confined? | 10:52 |
| zyga | Kaleo: but I had to do stuff manually as snapcraft doesn't support everything yet: https://github.com/zyga/python0/blob/master/python0.Makefile#L10 | 10:52 |
| zyga | Kaleo: not sure which snap you mean, you said you have a few | 10:52 |
| Kaleo | zyga, ubuntu-terminal | 10:53 |
| zyga | Kaleo: (one problem at a time please, I'm somewhat distracted doing a few things already) | 10:53 |
| Kaleo | zyga, ubuntu-terminal-app | 10:53 |
| Kaleo | zyga, it's only the one thing we are talking about | 10:53 |
| Kaleo | zyga, making snapped terminals useful | 10:53 |
| Kaleo | zyga, starting with ubuntu-terminal-app | 10:53 |
| zyga | Kaleo: do you want a confined or classic snap | 10:54 |
| Kaleo | zyga, since you said classic snaps are basically unreliable, it cannot be classic in the long ruin | 10:54 |
| Kaleo | -i | 10:54 |
| Kaleo | zyga, so confined | 10:54 |
| zyga | Kaleo: no, I didn't say that: I said that you must build classic snaps from source and do it correctly, they are 100% reliable then | 10:54 |
| Kaleo | zyga, lol | 10:55 |
| zyga | Kaleo: ok, confined | 10:55 |
| Kaleo | zyga, I mean unreliable for actual end users | 10:55 |
| Kaleo | zyga, (actual end users don't compile their software) | 10:55 |
| zyga | Kaleo: again, I didn't say that | 10:55 |
| zyga | Kaleo: actual users don't build snaps either | 10:55 |
| Kaleo | zyga, so I don't understand | 10:55 |
| zyga | Kaleo: as long as the snap is built correctly it will be reliable | 10:55 |
| zyga | Kaleo: ok | 10:55 |
| mup | PR snapd#2663 opened: run "go test -i" before go test itself <Created by chipaca> <https://github.com/snapcore/snapd/pull/2663> | 10:56 |
| zyga | Kaleo: fact of life: building classic snaps from binary packages is incorrect | 10:56 |
| Kaleo | zyga, "build classic snaps from source" means what? | 10:56 |
| zyga | Kaleo: fact of life: snacpraft doesn't support building everything magically yet | 10:56 |
| zyga | Kaleo: well, you build the .c files and the .cpp files | 10:56 |
| zyga | Kaleo: you cannot download debs and copy them over | 10:56 |
| Kaleo | zyga, of the software? or of the software and all its dependencies? | 10:56 |
| zyga | Kaleo: that's what I mean by "build it from source" | 10:56 |
| zyga | Kaleo: all of it | 10:56 |
| Kaleo | zyga, of all the deps, I see | 10:56 |
| niemeyer | zyga: For the record, the jury is still out on this one | 10:56 |
| zyga | Kaleo: everything you hope to see in your snap | 10:56 |
| niemeyer | zyga: There's no agreement that building from binary packages is incorrect.. | 10:57 |
| niemeyer | zyga: So "fact of life" seems a bit harsh | 10:57 |
| zyga | niemeyer: I'll agree when I see a viable way that works; the only think I can think of are binary editing hacks | 10:57 |
| Kaleo | niemeyer, zyga, ok, so I can start classic with binary packages dependencies, test on a few systems, if it works, publish that as a _first_ step? | 10:57 |
| zyga | niemeyer: you'd have to alter all the hardcoded paths, all the elf parts to look at the new places | 10:57 |
| zyga | Kaleo: sure, don't take what I say as "this is wrong and you cannot publish your snap" | 10:58 |
| zyga | Kaleo: I'm just saying that it may not be what you expected | 10:58 |
| Kaleo | zyga, ok | 10:58 |
| niemeyer | zyga: You can agree or not.. that's not the point.. let's just not purport such ideas as being settled on stone when they are actually just being released and we're still learning to use them ourselves | 10:58 |
| Kaleo | niemeyer, ok | 10:58 |
| zyga | ok, so "using binary packages for snaps using classic confinement is strongly discouraged" is more accurate | 10:58 |
| niemeyer | zyga: Classic snaps were supposed to make things easier.. if we can't use binary packages and it's completely non-intuitive, classic snaps are pointless.. | 10:59 |
| Kaleo | zyga, so step 2, figuring out a way for confined terminals to be more useful | 10:59 |
| zyga | niemeyer: well, that I agree with entirely | 10:59 |
| niemeyer | zyga: So we should do some more research and see how/if we can make them reach their actual goal | 10:59 |
| zyga | niemeyer: though the pointless bit is perhaps too strong, they have a point but their utility is limited | 10:59 |
| Kaleo | zyga, _very_ limited ;) | 10:59 |
| niemeyer | zyga: No, really.. the only reason we worked on this at all is to provide a smooth entrance into confinement | 10:59 |
| zyga | niemeyer: IMHO with my technical knowledge it is super hard if you expect them to work outside of ubuntu 16.04; I can tell you all the technical details why I believe this to be the case | 11:00 |
| Kaleo | zyga, that'd be really great to have a little write up with the details? | 11:00 |
| niemeyer | zyga: If it's _harder_ to build a classic snap than a strict one, I'd argue to kill classic snaps | 11:00 |
| Kaleo | niemeyer, +1 unless it can be fixed | 11:00 |
| zyga | ok, let's discuss that at the standup | 11:00 |
| Kaleo | zyga, so step 2, figuring out a way for confined terminals to be more useful | 11:00 |
| zyga | I'd rather not kill them yet, the only hard part is the building part and I'd say that for some classes of software this is not hard; for some classes it is but killing it now would feel premature | 11:01 |
| zyga | Kaleo: that one is more easy, it feels like an interface | 11:01 |
| niemeyer | Kaleo: Yeah, I wouldn't mind looking into a potential interface for that | 11:01 |
| zyga | Kaleo: that lets you run shells unconfined | 11:01 |
| niemeyer | zyga: Yes, we shouldn't kill them yet, we should make them sane | 11:01 |
| zyga | Kaleo: the details can be ironed out but this feels well-defined and doable quickly | 11:01 |
| zyga | niemeyer: I think the difficulty is now on the snapcraft side; | 11:01 |
| niemeyer | zyga: Asking people to build everything from source when they don't do that for strict snaps isn't reasonable | 11:02 |
| zyga | niemeyer: there's little we can do in snapd IMHO | 11:02 |
| Kaleo | niemeyer, zyga, right, the main thing I noticed is needed: / inside the terminal snap being the actual / of the classic system | 11:02 |
| zyga | niemeyer: well, maybe | 11:02 |
| niemeyer | zyga: Yeah, we should talk to Sergio about these details | 11:02 |
| zyga | +1 | 11:02 |
| Kaleo | niemeyer, zyga, can that be an interface? | 11:02 |
| zyga | Kaleo: perhaps | 11:02 |
| niemeyer | Kaleo: Yes, it can.. not sure if it should yet, but it can | 11:02 |
| niemeyer | Kaleo: It's a pretty different mode of operation, so an interface is a bit misleading | 11:03 |
| zyga | Kaleo: we don't have support to let a confined snap run a process that is both unconfined and uses the normal filesystem | 11:03 |
| Kaleo | niemeyer, right | 11:03 |
| zyga | Kaleo: it would be a combination of an interface (I can run bash unconfined) and a helper that returns to the normal filesystem IMHO | 11:03 |
| zyga | the interface is very easy | 11:03 |
| zyga | the helper is easy but would require some C code | 11:04 |
| Kaleo | niemeyer, zyga, another tricky thing I encountered was that inside the shell of the terminal, the environment variables are those of the terminal snap, including things that disturb operations, instead of being the environment variables of say the parent process that started the terminal | 11:04 |
| zyga | so technically gnome-terminal would run "snap-escape-ns /bin/bash" (names tentative) | 11:04 |
| zyga | Kaleo: can you give us some examples of which variables are problematic? | 11:05 |
| Kaleo | zyga, yes | 11:05 |
| Kaleo | zyga, all the SNAP_* variables | 11:05 |
| niemeyer | Kaleo: It's both, actually | 11:05 |
| Kaleo | zyga, and all the environment variables set by the "desktop helper" | 11:05 |
| zyga | Kaleo: hmm | 11:05 |
| Kaleo | GDK_PIXBUF_MODULEDIR, GIO_MODULE_DIR, etc. | 11:05 |
| niemeyer | Kaleo: env vars do get into the process | 11:05 |
| Kaleo | niemeyer, zyga, right now I have a piece of code that reset the environment to be the same as the parent process of the terminal | 11:06 |
| Kaleo | +s | 11:06 |
| zyga | Kaleo: I believe that (at least for some of those) the snap-escape-ns could dothat | 11:07 |
| Kaleo | zyga, interesting | 11:08 |
| zyga | Kaleo: but it would not know to reset things you just mentioned, like GDK | 11:08 |
| zyga | Kaleo: for those I believe the terminal should be patched to run the shell process without those | 11:08 |
| zyga | Kaleo: (as this is internal implemnetation detail of the snap) | 11:08 |
| zyga | *implementation | 11:09 |
| Kaleo | zyga, it is true that it's technically the terminal setting those vars | 11:09 |
| Kaleo | zyga, even though the code that does that is from snapcraft-desktop-helpers | 11:10 |
| Kaleo | zyga, the main issue with asking the terminal to reset these variables is that we will be asking all terminal packagers/developers to do the same | 11:10 |
| zyga | Kaleo: do you see another way to do this? | 11:11 |
| Kaleo | zyga, the way I do it today | 11:11 |
| zyga | Kaleo: you could run the terminal to run a shell | 11:11 |
| zyga | Kaleo: but the shell would be another helper wrapper | 11:11 |
| zyga | Kaleo: that would undo all the stuff and run the escape tool | 11:11 |
| Kaleo | zyga, right | 11:11 |
| Kaleo | zyga, 1) we could make that code common | 11:11 |
| Kaleo | zyga, but it's not simple because that specific unsetting of variables depends on what kind of desktop helper you used (for example a qt or a gtk one) | 11:12 |
| Kaleo | zyga, or 2) we could have that code be more generic like I do today: copy the environment from the parent process of the terminal | 11:12 |
| Kaleo | zyga, or 3) we could make it somehow possible for the terminal to not fork the shells itself | 11:13 |
| Kaleo | zyga, but have the parent process do that for the terminal | 11:13 |
| zyga | Kaleo: yes but that should live with the helper, I'd rather not mix snapd-the-system and particular-snap boundaries, otherwise things will get out of sync and break | 11:13 |
| zyga | Kaleo: (for 1) | 11:13 |
| Kaleo | zyga, right, that's true | 11:13 |
| zyga | Kaleo: FYI: I'm very glad you are pushing the boundary | 11:14 |
| Kaleo | zyga, 1) something in the helper to unset in a non generic way | 11:14 |
| Kaleo | zyga, :) | 11:14 |
| zyga | Kaleo: as niemeyer said, the point of classic snaps is to make things easy | 11:14 |
| Kaleo | zyga, 2) something generic to reset the variables that could live in snapd | 11:14 |
| zyga | Kaleo: I'm sorry if you regarded my earlier comments as harsh, that was not my intention (this is just the side effect of working on afew things at the same time) | 11:14 |
| Kaleo | zyga, don't worry | 11:15 |
| zyga | Kaleo: I think we should meet with sergio and kyrofa_ to discuss how to make building snaps easier | 11:15 |
| Kaleo | zyga, classic snaps you mean? | 11:15 |
| zyga | Kaleo: snaps using classic confinement | 11:15 |
| Kaleo | yep | 11:15 |
| zyga | (this naming super confusing because we have the actual "classic" snap and we have "classic" distributions as well) | 11:15 |
| Kaleo | zyga, or 3) some kind of facility where the terminal can ask for a binary to be exec | 11:16 |
| Kaleo | zyga, indeed | 11:16 |
| Kaleo | zyga, I think 3) would be fantastic actually, cleaner somehow, more widely useful | 11:17 |
| zyga | Kaleo: can you explain 3 more? | 11:17 |
| Kaleo | zyga, so let me get some code to be concret | 11:17 |
| Kaleo | e | 11:17 |
| zyga | sure | 11:19 |
| zyga | Kaleo: can I ask you do move to rocket | 11:22 |
| zyga | Kaleo: I get notifications there | 11:22 |
| zyga | Kaleo: and diconnets are less of a problem | 11:22 |
| pachulo | elopio: ping | 11:22 |
| zyga | https://rocket.ubuntu.com/channel/snapcraft | 11:22 |
| zyga | Kaleo: ^^ | 11:22 |
| Kaleo | zyga, sure | 11:23 |
| Kaleo | zyga, we can even hangout | 11:23 |
| Kaleo | I mean video chat | 11:23 |
| zyga | Kaleo: rocket could be better for kyle and sergio to catch up with the discussion | 11:23 |
| zyga | (and also lighter on my bandwidth) | 11:23 |
| Son_Goku | sergiusens, I hope you didn't mean to say you broke symlink handling of deb sources in the snapcraft 2.25 release notes | 11:54 |
| Son_Goku | "deb sources are now being handled with python-debian which does incorrecly handle symlinks." | 11:55 |
| * Son_Goku sighs | 11:55 | |
| Son_Goku | python-debian is a new dep? | 11:55 |
| Son_Goku | :( | 11:58 |
| Son_Goku | Git is evil, moving files around causes the history of the file to not show up anymore :( | 11:59 |
| Son_Goku | kyrofa_, though I do like the refactor you've done to sources | 11:59 |
| Son_Goku | it's much easier to figure out and compare sources now | 12:00 |
| Son_Goku | :/ | 12:00 |
| Son_Goku | though I feel like I should add my name to the license header of the Rpm source files... | 12:00 |
| Son_Goku | since the git history no longer shows it anymore :( | 12:00 |
| kalikiana | That's good practice anyway, although not stricyl required so long as you can track down the author via git | 12:02 |
| kalikiana | Unless all commits were rebased by somebody else without your name that is | 12:03 |
| Son_Goku | yep | 12:04 |
| Son_Goku | that pretty much happened | 12:05 |
| Son_Goku | well, sort of | 12:05 |
| Son_Goku | because the original file is deleted, it no longer shows up in Git history | 12:05 |
| Son_Goku | Canonical did not write any of the Rpm stuff, I did... | 12:05 |
| Son_Goku | but it's one of those PRs that some people really don't like | 12:05 |
| Son_Goku | kalikiana, it also looks like the blob history is gone too | 12:06 |
| Son_Goku | so much for Git's object blob tracking | 12:06 |
| kalikiana | Son_Goku: How are you checking it? If that's really what happened it seems very wrong | 12:06 |
| Son_Goku | git blame on the Rpm files | 12:07 |
| Son_Goku | git blame is supposed use the object blob tracking | 12:07 |
| Son_Goku | so that even if you moved stuff around, it should be tracked properly | 12:07 |
| Son_Goku | but it doesn't seem to work :( | 12:07 |
| flexiondotorg | willcooke Perhaps useful for asterisk? http://snapcraft.io/docs/build-snaps/scriptlets | 12:14 |
| kalikiana | Hmm it says Kyle as the author here | 12:14 |
| sergiusens | kalikiana, vbecause e moved the stuff around | 12:15 |
| zyga | Son_Goku: --follow | 12:16 |
| zyga | Son_Goku: it's not default | 12:16 |
| zyga | Son_Goku: git log --follow | 12:16 |
| zyga | (hi btw) | 12:16 |
| Son_Goku | hello | 12:16 |
| Son_Goku | in retrospect, I should have added my name onto the original file | 12:17 |
| kalikiana | Son_Goku: git blame -C seems to try harder | 12:17 |
| Son_Goku | hmm | 12:17 |
| Son_Goku | I did put in the test file, but I didn't in the implementation file | 12:18 |
| Son_Goku | that's my bad :( | 12:18 |
| Son_Goku | sergiusens: would it be okay if I added my name to the Rpm source headers in a PR? | 12:22 |
| sergiusens | Son_Goku, if it means that much to you sure; I'd guess it would be easier to start a CONTRIBUTIONS.md if you don't mind that path instead | 12:23 |
| Son_Goku | hmm | 12:23 |
| Son_Goku | it's not on the top of my list atm, and I think my local git copy of snapcraft is busted :/ | 12:23 |
| sergiusens | Son_Goku, how can that be? we don't change history in master! | 12:24 |
| sergiusens | I hope no one has at least | 12:24 |
| * Son_Goku shrugs | 12:24 | |
| Son_Goku | it's forcing me to do a merge | 12:24 |
| Son_Goku | oh, yay | 12:25 |
| sergiusens | Son_Goku, local commits? | 12:25 |
| Son_Goku | the blob history works with "git blame -C" | 12:25 |
| Son_Goku | sergiusens: *shrugs*, I reset the HEAD to some random earlier time and it worked | 12:25 |
| Son_Goku | it's interesting to see how git treats the blobs, though | 12:26 |
| sergiusens | Son_Goku, yeah -C does the trick and we get to see your kanji, hiragana or katagana (not sure which one it is) :-) | 12:26 |
| Son_Goku | Katakana | 12:26 |
| Son_Goku | though my original commits didn't have that | 12:27 |
| Son_Goku | only my GitHub user has it :) | 12:27 |
| Son_Goku | because you squashed the commits, you got that instead :P | 12:27 |
| Son_Goku | GitHub is weird like that | 12:27 |
| Son_Goku | I don't think that happens when you squash commits locally in git... | 12:27 |
| Son_Goku | anyway... | 12:28 |
| sergiusens | Son_Goku, I am not so much a fan of github in some aspects, but oh well, everyone wants stuff there and not sign up of anything else | 12:28 |
| Son_Goku | sergiusens: I prefer GitLab myself | 12:28 |
| Son_Goku | my personal projects are all over on GitLab instead of GitHub | 12:28 |
| sergiusens | right, well it needs something to base the squash out of | 12:28 |
| Son_Goku | I moved it there two years ago | 12:28 |
| zyga | I don't think how git behaves is related to either hosting solution | 12:28 |
| Son_Goku | sergiusens: though honestly the most compelling reason for picking GitLab vs something like Gogs or Gitea is the awesome CI capabilities | 12:29 |
| Son_Goku | it has first class support for flexible CI built in, and a great API for integrating external CI providers | 12:29 |
| Son_Goku | and has an excellent model for representing CI with internal and external things at once | 12:30 |
| Son_Goku | see for example: https://gitlab.com/osslugaru/lugaru/blob/master/.gitlab-ci.yml and https://gitlab.com/osslugaru/lugaru/commit/b9a46d8e2b7e7e22c706e7dd3734f31015db4408/pipelines | 12:31 |
| Son_Goku | the only weak part of GitLab is git :P | 12:32 |
| Son_Goku | (of course, that's just because I prefer Mercurial) | 12:32 |
| sergiusens | lol | 12:32 |
| sergiusens | everything has ups and downs | 12:33 |
| Son_Goku | yeah, of course | 12:33 |
| Son_Goku | there are weaknesses to GitLab, of course | 12:33 |
| Son_Goku | the most annoying thing is that uploading binaries doesn't work if it's larger than 10MB | 12:33 |
| Son_Goku | which also includes source tarballs | 12:34 |
| Son_Goku | but it's been easier to engage with GitLab about issues than it has with GitHub about the same things | 12:34 |
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapcraft#1055 closed: store: proper error colors for login failures <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1055> | 12:41 |
| mup | PR snapd#2586 closed: daemon: make 201 and 202 responses have a Location header as per doc <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2586> | 12:46 |
| === jdstrand_ is now known as jdstrand | ||
| === chihchun is now known as chihchun_afk | ||
| jdstrand | Kaleo: there is a somewhat ugly way to figure out what confinement you are under: try to read a file that is readable with classic but not in strict | 13:18 |
| === chihchun_afk is now known as chihchun | ||
| Kaleo | jdstrand, smart | 13:20 |
| Kaleo | jdstrand, thax | 13:20 |
| Kaleo | thanks | 13:20 |
| zyga | maybe we should add a variable like SNAP_CONFINEMENT= | 13:20 |
| mup | PR snapcraft#1056 closed: schema: print allowed length for length failures <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1056> | 13:20 |
| jdstrand | ogra_, Chipaca, Kaleo: @{PROC}/cmdline is allowed by default and I don't think we'd remove that one (it isn't problematic). there are a few other /proc accesses I'd like to be limited, but we need kernel side apparmor variables for that (which are planned, but not for the short term) | 13:21 |
| jdstrand | timp: your snap needs to simply have meta/gui/*.desktop. snapcraft provides a way to make that happen | 13:22 |
| Kaleo | zyga, jdstrand, note that I don't think I'll need that anymore given the discussion afterwards | 13:22 |
| jdstrand | sergiusens: did snapcraft change how it does desktop files? I may need to update the review tools message for that | 13:22 |
| Kaleo | jdstrand, timp, I read in the snapcraft release email today that there is a new way to provide the desktop file | 13:22 |
| jdstrand | Kaleo: so, I may have confused what you meant by 'classic'. if you want to see if you are on a classic system, ogra_'s method of checking /proc/cmdline will work. if you want to know if the snap uses 'confinement: classic', you can use the file access method I mentioned | 13:24 |
| Kaleo | jdstrand, yeah, I meant confinement of the snap | 13:25 |
| Kaleo | jdstrand, but don't worry, I won't be needing this | 13:25 |
| ogra_ | yeah, the cmdline is only useful to find out if you are on an all-snap system | 13:25 |
| ogra_ | iirc that was the context i mentioned it in | 13:25 |
| mup | PR snapd#2663 closed: speed up unit test run by doing "go test -i" before go test itself <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2663> | 13:28 |
| oSoMoN | I’m getting a warning from the store automated review when using the new "desktop" key in snapcraft.yaml: | 13:33 |
| oSoMoN | unknown fields for app 'webbrowser-app': 'desktop' lint-snap-v2_apps_unknown (webbrowser-app) | 13:33 |
| oSoMoN | I’m guessing because the field gets copied to meta/snap.yaml | 13:34 |
| oSoMoN | not sure whether the field should not be copied, or whether the review tools need an update? | 13:34 |
| sergiusens | oSoMoN, I fixed that already and will be in 2.26 | 13:35 |
| sergiusens | oSoMoN, https://github.com/snapcore/snapcraft/pull/1053 | 13:36 |
| mup | PR snapcraft#1053: meta: ensure snap.yaml is desktop free <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1053> | 13:36 |
| === hikiko|ln is now known as hikiko | ||
| oSoMoN | sergiusens, thanks, that’s something that I had overlooked indeed | 13:37 |
| oSoMoN | sergiusens, do you know who can approve my snap upload in the store, the warning appears to be blocking | 13:37 |
| === ben_r_ is now known as ben_r | ||
| jdstrand | sergiusens: is 2.26 an emergency release? should the review tools change? at this point, they can't be changed probably until monday on prod, but maybe I could get them to do it sooner | 13:40 |
| jdstrand | sergiusens: wrt desktop and snapcraft. is setup/gui/*.desktop still supported? should I start recommending desktop: usr/share/applications/my-app.desktop? | 13:42 |
| jdstrand | sergiusens: ah, I see from the email it is still supported | 13:42 |
| jdstrand | I'm not going to fix the tools to mention the new method until 2.26 is released since that will only create store approval friction | 13:43 |
| mup | PR snapd#2664 opened: cmd: move seccomp cleanup functionto seccomp-support <Created by zyga> <https://github.com/snapcore/snapd/pull/2664> | 13:46 |
| === Elleo_ is now known as Elleo | ||
| sergiusens | jdstrand, we are going to be moving `setup` stuff into `snap` in the future though and deprecate `setup`, this will consolidate most assets | 13:55 |
| sergiusens | jdstrand, I can cut a new snapcraft release tomorrow, I'll check, but my trusty QA guy is on holidays !! | 13:56 |
| === chihchun is now known as chihchun_afk | ||
| oSoMoN | jdstrand, can you approve my last 3 webbrowser-app snap uploads? the review tools are warning about the desktop key in snap.yaml, afaik this is harmless but I can’t publish | 14:03 |
| jdstrand | oSoMoN: yes. note you could also use the previous method until 2.26 is out ^ | 14:04 |
| oSoMoN | jdstrand, I know, but I’ve been eagerly awaiting for that new feature to avoid having to ship a copy of the generated desktop file in setup/gui, so now that I’ve removed it I’m reluctant to adding it back | 14:06 |
| mup | Bug #1657751 opened: 'snap info' doesn't show price of snap <Snappy:New> <https://launchpad.net/bugs/1657751> | 14:06 |
| mup | Bug #1657752 opened: 'snap find' doesn't tell me the price of a snap I have bought <Snappy:New> <https://launchpad.net/bugs/1657752> | 14:09 |
| jdstrand | oSoMoN: approved | 14:09 |
| oSoMoN | jdstrand, thanks! | 14:09 |
| ogra_ | mterry, FYI .. https://git.launchpad.net/mir-kiosk/commit/?id=7c8c501b67bb9ca2059838947b8eab918779fd36 ... seems it simply hasn't landed in any deb yet (mir-kiosk is built from source directly) ... thats bug 1656164 ... so unity8-session cant work yet it seems | 14:11 |
| mup | Bug #1656164: Black screen with Raspberry Pi 3 VC4 Mesa driver <black-screen> <Mir:Fix Committed by albaguirre> <https://launchpad.net/bugs/1656164> | 14:11 |
| mterry | ogra_: ok cool. So we could also workaround it... is there an urgency to it working for ya? | 14:13 |
| ogra_ | mterry, no urgency, just a personal desire to show off unity on the pi ;) | 14:14 |
| mterry | :) | 14:14 |
| timp | tim@XPS-13-9350:~/src/snaps/ubuntu-ui-toolkit-examples$ ubuntu-ui-toolkit-examples.jokes | 14:26 |
| timp | QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries. | 14:26 |
| timp | file:///snap/ubuntu-ui-toolkit-examples/x1/usr/lib/x86_64-linux-gnu/qt5/examples/ubuntu-ui-toolkit/examples/jokes/jokes.qml:20 plugin cannot be loaded for module "QtMultimedia": Cannot load library /snap/ubuntu-ui-toolkit-examples/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/qml/QtMultimedia/libdeclarative_multimedia.so: (libpulsecommon-8.0.so: cannot open shared object file: No such file or directory) | 14:26 |
| timp | kalikiana: do you think the pulse libs should be in the examples snap, or part of the platform snap? | 14:27 |
| timp | hmm, looks like it tries to get it from the platform snap. | 14:27 |
| kalikiana | timp: Since pulse is considered the standard for audio, intuitively I think it could be in the platform snap. Virtually anything that plays audio can use it | 14:28 |
| kalikiana | Tho you might have a core image w/o pulse, if you do have audio it would be pulse | 14:29 |
| timp | ubuntu-app-platform/22/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so | 14:29 |
| timp | it is there.. but maybe somehow cannot be found. | 14:29 |
| kalikiana | Ah, so it's probably a dependency of QtMultimedia already | 14:29 |
| zyga | the pulseaudio subdirectory is not on search path | 14:29 |
| timp | zyga: right. Should I fix that in the app snap or the platform snap? | 14:30 |
| * zyga is not sure | 14:30 | |
| zyga | can you fix it in the platform snap? | 14:30 |
| ogra_ | if platform ships it ... | 14:30 |
| kalikiana | timp: In the launcher I should think | 14:30 |
| kalikiana | The platform snap can't set the path | 14:30 |
| kalikiana | Until some day it becomes possible to set env vars, that is | 14:31 |
| zyga | btw | 14:31 |
| zyga | is there a card tracking that | 14:31 |
| zyga | we are so able to do that now for ages | 14:31 |
| zyga | feels like a disconnected dot somewhere | 14:31 |
| zyga | and missing docs and tests | 14:31 |
| timp | kalikiana: so you'd say in desktop-launch? I don't see it here https://github.com/ubuntu/snapcraft-desktop-helpers | 14:35 |
| timp | ah it is created from other files | 14:36 |
| kalikiana | timp: Yep, that's the one I mean | 14:37 |
| timp | this looks like a good place to add it https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific | 14:37 |
| timp | kalikiana, zyga: https://github.com/ubuntu/snapcraft-desktop-helpers/issues/37 | 14:43 |
| zyga | thanks | 14:45 |
| timp | hmm, maybe there is a PR already to fix it https://github.com/ubuntu/snapcraft-desktop-helpers/pull/25 | 14:46 |
| mup | PR ubuntu/snapcraft-desktop-helpers#25: Add pulseaudio to the LD_LIBARY_PATH of the platform snap <Created by tjyrinki> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/25> | 14:46 |
| kalikiana | Yeah, looks to be discussing the same issue | 14:50 |
| mup | PR snapd#2665 opened: cmd: more build system cleanups and a small fix <Created by zyga> <https://github.com/snapcore/snapd/pull/2665> | 14:58 |
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| jdstrand | cprov (cc, nessita): I know we talked about this before and I think it is a TODO, but it would be great if the reviewer could click on something to see the snap yaml. with all the kde snaps coming in (which is great), I have to download each one, extract the yaml and find the dbus name so I can update the snap declaration | 16:03 |
| cprov | jdstrand: right, we talked about it and I haven't proposed anything. | 16:05 |
| jdstrand | cprov: do you need a bug? if so, where to file it? | 16:05 |
| cprov | jdstrand: yes, please, https://bugs.launchpad.net/software-center-agent | 16:07 |
| mup | PR snapcraft#1057 opened: godeps plugin: support for go-packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1057> | 16:09 |
| jdstrand | cprov: bug #1657812 | 16:12 |
| mup | Bug #1657812: please provide snap.yaml to reviewer <Software Center Agent:New> <https://launchpad.net/bugs/1657812> | 16:12 |
| cprov | jdstrand: thanks, quick shortcut until it's released `curl -s -H 'X-Ubuntu-Series: 16' https://search.apps.ubuntu.com/api/v1/snaps/details/<SNAP-NAME> | jq '.snap_yaml_raw' | xargs echo -e` | 16:14 |
| cprov | jdstrand: only works for public snaps on stable channel. | 16:15 |
| jdstrand | cprov, pedronis (cc nessita, ratliff_, tyhicks): fyi, I also just filed bug #1657816 and bug #1657825 | 16:30 |
| mup | Bug #1657816: please provide way to see LP group memberships for publisher <Software Center Agent:New> <https://launchpad.net/bugs/1657816> | 16:30 |
| mup | Bug #1657825: please add mechanism to enforce trusted LP builds for snaps <Software Center Agent:New> <https://launchpad.net/bugs/1657825> | 16:30 |
| jdstrand | cprov: and thanks for the curl command! /me adds to his repertoire | 16:30 |
| jdstrand | of course, it doesn't work on any of the 3 snaps I am looking at now :P | 16:33 |
| cprov | jdstrand: let me try, which ones ? | 16:35 |
| jdstrand | cprov: none are released | 16:36 |
| jdstrand | so not in stable channel | 16:36 |
| cprov | jdstrand: yes, only their publisher can see them ... let me work on the review UI quickly. | 16:37 |
| jdstrand | cprov: thanks! | 16:37 |
| jdstrand | mhall119: fyi, apachelogger uploaded several kde snaps that used the dbus interface. I granted the snap declaration and they passed review, but he needs to release them | 16:39 |
| === chihchun is now known as chihchun_afk | ||
| === ratliff_ is now known as ratliff | ||
| mhall119 | jdstrand: ack, thanks | 17:22 |
| mcphail | kyrofa_: hi - is there a bug tracker for the nextcloud snap? I don't think the ".well-known" DAV redirects are being triggered by the .htaccess file | 17:30 |
| kyrofa_ | mcphail, https://github.com/nextcloud/nextcloud-snap | 17:30 |
| mcphail | kyrofa_: thanks | 17:30 |
| kyrofa_ | mcphail, that bug has been logged, though I'm not quite sure how to fix it | 17:30 |
| kyrofa_ | mcphail, since Let's Encrypt uses that path as well | 17:30 |
| kyrofa_ | And they both go through Apache | 17:31 |
| mcphail | kyrofa_: does the .htaccess get read at all? It _should_ work ok | 17:31 |
| kyrofa_ | mcphail, yeah it does, though it's read-only | 17:32 |
| mcphail | that should be fine, I think | 17:32 |
| mcphail | it seems to match my self-installed version | 17:32 |
| kyrofa_ | I just need time to sit down and poke at it. But time is in short supply at the moment | 17:33 |
| mcphail | kyrofa_: :) - I'll try to compare to my setup over the weekend | 17:33 |
| kyrofa_ | mcphail, yeah any help is appreciated :) | 17:34 |
| kyrofa_ | Thank you! | 17:34 |
| mcphail | kyrofa_: I'm fairly sure the <Directory "${SNAP_DATA}/certs/certbot/.well-known"> stanza in your httpd.conf must have a role to play here. I'll need to have a poke around to see how let'sencrypt has been implemented in the snap. Hmm... | 17:56 |
| kyrofa_ | mcphail, indeed | 17:57 |
| kyrofa_ | mcphail, if I understand the .htaccess well enough, it looks like it won't attempt to redirect an acme challenge | 17:59 |
| kyrofa_ | That just needs to get sent to a directory | 18:00 |
| mcphail | kyrofa_: I'm wondering if the acme challenge should be added (whith the specific .well-known/acme-challenge/{token}) path to the htaccess file instead of redireccting all of .well-known (as apache.conf does now) | 18:00 |
| mcphail | The redirect in apache.conf is too greedy at present | 18:01 |
| kyrofa_ | Indeed, when it was written I didn't even realize nextcloud cared about .well-known, heh | 18:01 |
| mcphail | :) | 18:01 |
| kyrofa_ | When that bug was logged I was like "Wha... ?" | 18:01 |
| kyrofa_ | Modifying the .htaccess in the snap won't scale, though, and I expect it'll fail the integrity check as well | 18:02 |
| mcphail | Might be OK to change the Alias in the conf file | 18:02 |
| kyrofa_ | Yeah the conf is fair game | 18:03 |
| mcphail | OK, I'll play around when I get a chance over the weekend. Cheers for the pointer! | 18:03 |
| kyrofa_ | Any time! | 18:03 |
| === faenil_ is now known as faenil | ||
| === jkridner_ is now known as jkridner | ||
| Beato | When trying to install a snap it fails with this error - https://paste.ee/r/F7XfL | 18:44 |
| Beato | any ideas? | 18:44 |
| ogra_ | Beato, is this on ubuntu ? | 18:48 |
| Beato | Yes | 18:48 |
| ogra_ | xenial ? (16.04) | 18:48 |
| Beato | Yes | 18:48 |
| Beato | It is a OpenVZ based VPS though, so maybe it's that | 18:49 |
| ogra_ | ah | 18:49 |
| ogra_ | uname -a ? | 18:49 |
| Beato | Linux PC 2.6.32-042stab120.16 #1 SMP Tue Dec 13 20:58:28 MSK 2016 x86_64 x86_64 x86_64 GNU/Linux | 18:49 |
| ogra_ | lol | 18:49 |
| ogra_ | yeah, that wont ever work with snaps | 18:49 |
| ogra_ | get a kernel thats not antique ... | 18:50 |
| Beato | OpenVZ | 18:50 |
| Beato | Not my call | 18:50 |
| zyga | Beato: hmm, wow, interesting combination; I'm afraid snapd and systemd require a more recent kernel | 18:50 |
| ogra_ | it is really interesting that 16.04 runs at all | 18:51 |
| popey | (arguably not actually Ubuntu) | 18:51 |
| ogra_ | (you will probasbly hit very interesting issdues with such a setup) | 18:51 |
| ogra_ | definitely nothing you should use any production services on | 18:52 |
| zyga | Beato: which provider are you using? | 18:52 |
| Beato | https://openvz.org/Download/template/precreated kek | 18:52 |
| Beato | zyga: http://woothosting.com/ | 18:53 |
| popey | I recommend http://bitfolk.com/ :) | 18:53 |
| popey | (tell them I sent you) :D | 18:54 |
| ogra_ | "Award-winning network that keeps your business ALIVE" ... since 300 years with the same kernel :P | 18:54 |
| ogra_ | zombyism galore ... | 18:54 |
| Beato | That's an OpenVZ thing though. Pretty much all cheap VPS run OpenVZ 6 and they use a custom 2.6 kernel with a lot of stuff backported (that's why I can run systemd for example) | 18:54 |
| popey | yeah | 18:55 |
| ogra_ | well | 18:55 |
| zyga | Beato: interesting | 18:55 |
| popey | Bitfolk uses Xen, which means my vps is running 4.4.0-57-generic | 18:55 |
| * ogra_ remembers a friend telling him "running doesnt necessarily mean working" ... | 18:55 | |
| ogra_ | i guess that applies here | 18:56 |
| zyga | Beato: snapd depends on some recent kernel features so it will be quite hard to even install and run hello-world there | 18:56 |
| ogra_ | not only snapd though | 18:56 |
| Beato | Yeah, Xen, KVM, VMWare and HyperX allow you to load your own kernel so you can just update manually | 18:56 |
| zyga | Beato: I'm afraid there's no better advice than try something that runs genuine xenial kernel | 18:56 |
| ogra_ | i'd be surprised if that ubuntu actually fully behaves | 18:56 |
| popey | sorry about that | 18:56 |
| Beato | ogra_: it does though. Like I said, OpenVZ has backported a lot of the features. | 18:56 |
| Beato | popey: Cheers, was just curious. I'll just install the app manually then. | 18:57 |
| zyga | Beato: if it did you would not have that problem | 18:57 |
| zyga | Beato: technically, what failed? | 18:57 |
| Beato | Well not, all I guess ¯\_(ツ)_/¯ | 18:57 |
| ogra_ | Beato, well, it might seem like it works ... i really wouldnt trust itz | 18:57 |
| ogra_ | *it | 18:57 |
| popey | ogra_ has trust issues | 18:57 |
| * ogra_ has been burned to often | 18:57 | |
| ogra_ | and i know how many userspace bits nowadays rely on kernel features "someone" might have forgotten to port | 18:58 |
| ogra_ | its really a gambling setup ... | 18:58 |
| davmor2 | popey: no he doesn't I have trust issues ogra is just slightly damaged | 18:59 |
| Beato | Well I do use it as my personal playground, so I don't really care too much. | 18:59 |
| ogra_ | fro that it is probably fine | 19:00 |
| ogra_ | just dont run anything serious on it | 19:00 |
| Beato | I wasn't going to, but now... Watch me ;) | 19:00 |
| ogra_ | heh | 19:00 |
| ogra_ | Beato, well, good luck with it ... but forget about snaps on this | 19:02 |
| roadmr | hello folks! what's the story about running snapd inside an lxc container? right now it doesn't work :( | 19:06 |
| zyga | roadmr: hey, I don't know fully, I think that on recent enough everything there are still some cases that don't work | 19:30 |
| roadmr | zyga: oh but it *should* be working? | 19:30 |
| zyga | roadmr: no | 19:31 |
| zyga | roadmr: AFAIK | 19:31 |
| roadmr | zyga: haha :) | 19:31 |
| zyga | jdstrand: ^ correct me if I'm wrong, snapd inside lxd is till a no-go, right? | 19:31 |
| kyrofa_ | zyga, does this answer your question? https://www.stgraber.org/2016/12/07/running-snaps-in-lxd-containers/ | 19:46 |
| zyga | kyrofa_: looking | 19:51 |
| zyga | roadmr: ^^ | 19:51 |
| mhall119 | zyga: jdstrand: hexchat is in the snap store, but for some reason when you install it the Exec= lines in it's .desktop file are being removed | 20:21 |
| mhall119 | http://paste.ubuntu.com/23829632/ | 20:22 |
| mhall119 | what might be causing that? | 20:22 |
| mhall119 | is it because he uses ${SNAP} in the Exec=? | 20:24 |
| jdstrand | mhall119: I don't recall. it has to do with the desktop file rewriting code. I bet if you used bin/hexchat %U it would work | 20:28 |
| roadmr | thanks zyga | 20:32 |
| oh4 | running ubuntu 16.04, when trying to run 'sudo snap install canonical-livepatch', it fails with 'error: cannot communicate with server: Post http://localhost/v2/snaps/canonical-livepatch: dial unix /run/snapd.socket: connect: connection refused' | 20:35 |
| oh4 | snapd is installed but doesn't want to run. Looking at the status of snapd, I see this: | 20:35 |
| oh4 | https://www.irccloud.com/pastebin/v1KfOv5Y/ | 20:36 |
| sergiusens | oh4, dmesg|grep DEN | 20:39 |
| oh4 | https://www.irccloud.com/pastebin/6IXONJOg/ | 20:39 |
| sergiusens | oh4, oh, snapd doeesn't want to start, `journalctl --no-pager -u snapd` | 20:41 |
| oh4 | https://www.irccloud.com/pastebin/lkp5OdCw/ | 20:42 |
| mhall119 | jdstrand: actually, it's probably unhappy about it pointing to a binary inside the snap, rather than the one in /snap/bin/ | 20:45 |
| mhall119 | jdstrand: I was right, using just Exec=hexchat fixed it | 21:50 |
| mhall119 | zyga: sergiusens: ^^ we should give better feedback to the developer on this, rather than silently breaking the .desktop file | 21:50 |
| sergiusens | mhall119, yeah, I logged countless bugs or complaints for the snapd team to fix those silent errors | 21:55 |
| popey | sergiusens: i keep getting errors from snapcraft telling me files are already in the directory when it's staging | 21:58 |
| popey | it's lying because the files aren't in any other part | 21:58 |
| popey | when using the dump plugins mostly | 21:58 |
| === Tercus is now known as Terces | ||
| mup | PR snapd#2579 closed: many: auto-connect plugs and slots symmetrically <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2579> | 22:55 |
| mup | PR snapcraft#1058 opened: Return an error code if an origin is missing a part <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1058> | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!