=== chihchun_afk is now known as chihchun === chihchun_afk is now known as chihchun === chihchun_afk is now known as chihchun === ben_r_ is now known as ben_r === ben_r_ is now known as ben_r [02:03] has anyone built snaps with private git/npm dependencies? === ben_r_ is now known as ben_r [04:18] Bug #1595987 changed: udev denials === ben_r_ is now known as ben_r === mpontillo_ is now known as mpontillo === mariogrip_ is now known as mariogrip === Tribaal_ is now known as Tribaal === ulkesh_ is now known as ulkesh [06:04] mwhudson: ping [06:23] morphis_: hi [06:24] morphis_: sounds like you know more about wifi details than me, do you want to submit a probert pr? [06:24] mwhudson: I could but not real soon [06:25] PR snapd#1994 opened: snap: add `snap known --store` [06:25] mwhudson: but I think using something like https://pypi.python.org/pypi/libnl/ to talk with the kernel would be a good thing [06:25] morphis_: huh hadn't seen that one [06:26] mwhudson: however I think for the short term not breaking when the error occurs and requesting CONFIG_CFG80211_WEXT enabled in the kernel is a good start [06:26] morphis_: i guess the patch i added is at least better than doing nothing [06:26] yeah [06:26] mwhudson: but we shouldn't close the bug with this [06:27] exactly [06:27] netlink is so very ... the sort of api a kernel developer would think of, i guess [06:27] yeah [06:28] while RTA_OK(hdr, remaining): [06:28] also it's 1930 here and i'm going to try not to work every evening this week :-) [06:29] mwhudson: yeah, I agree with that! [06:29] mwhudson: just one last question [06:30] heh [06:30] mwhudson: I am currently hitting the problem that I can't enter @ anymore in the "Profile setup" screen [06:30] mwhudson: this is on the edge channel [06:30] morphis_: ! [06:30] on beta it works still [06:30] morphis_: it worked on an image i made today [06:30] 738 [06:30] hm [06:30] on a dragonboard [06:30] then it must be my keyboard or so [06:30] this is on a pi3 [06:31] morphis_: over serial or usb? [06:31] i know some keymap related stuff was added to the image recently [06:31] but i didn't think we were doing anything with that yet [06:31] its over a usb keyboard plugged into the dongle [06:31] and having the pi on a hdmi screen [06:32] yeah, that's the setup i was using [06:32] then it seems to be a image problem [06:43] PR snapd#1995 opened: interfaces/builtin: fix resolvconf permissions for network-manager interface [06:46] ogra_: ping [06:47] good mornign [06:47] *morning [06:48] hey hey [06:50] hey dholbach, zyga [06:50] dholbach: snap-codelabs is available FYI [06:51] wow wow wow [06:51] nice work didrocks [06:51] mhall119_, popey_: ^ [06:51] dholbach: based on mhall119_ first snapcraft.yaml, but quite tweaked to make it lightweight then :) [06:52] well done! [06:54] didrocks, hum, which port does it listen on? [06:54] dholbach: see the snap long description :) 8123 [06:55] ah yes, of course [06:55] great [07:02] recently, I use nodejs to compile some project, in some cases, if I add some modules, the compilation fails. I am not sure whether this is related to our nodejs plugin or not. thanks [08:04] pitti: I've updated https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 , can you have another look? [08:05] morphis_: I already did some minutes ago [08:05] morphis_: as I said, this is fine for a PoC in a PPA, but this is not a "solution" === davmor2_ is now known as davmor2 [08:06] packaging a leaf application might have this namespacing, but if you want to provide OS components as snaps they can't have the same restrictions [08:07] the idea was to isolate stuff, not hardcode alternate names for snap OS parts in a hundred places (plus breaking third-party stuff which we can't control) [08:07] pitti: there needs to be a lot more love happening but I still think if netplan is included on ubuntu core it shouldn't come with not functional support for backends [08:07] pitti: I totally agree with that [08:10] pitti: but that is what is giving today with snaps and netplan is included as a first class citizen on Ubuntu Core so it should take care about what it supports today and ask for changes those things solved [08:10] pitti: I see the risk that somebody doesn't know about that patch included in the ppa and then just release a new upstream release and overrides everything [08:15] didrocks: tried to find it on my pi, and it can't find codelabs, is that because it's amd64 only? [08:15] ogra_, mvo: so are you guys accepting not-upstream-patches for the netplan debian package in the ppa which ends up in the OS snap? not sure how the maintenance goes here but there needs be some ensurance that those changes are not overriden by anyone trying to bring in a new release from upstream netplan === popey_ is now known as popey [08:15] morphis_, wll, they need to be gone from the PPA and landed in -updates before november [08:16] pitti: ^^ [08:16] popey: yeah, I didn't build armhf binary (yet) [08:16] ok [08:16] if you guys think thats manageable, sure, lets have it in the PPA til then... the inal release must come from -updates [08:16] *final [08:17] didrocks: I can build it on my pi here if you want, where's the branch? [08:17] well, then you move it from being your responsibility to fix snaps to being my responsibility to ever get rid of this :) [08:17] ogra_: the thing is pitti does not agree with https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 and does not want it in netplan upstream [08:17] and it's certaily not the only place that calls nmcli, like netplan isn't the only package that expects NetworkManager.service or bluez.service or cups.service or whatnot [08:17] right, so the quetion is if it can be a distro patch in xenial ... [08:17] ogra_: so if we can't keep the netplan package in the ppa after the final release then then this needs to be considered differently [08:18] or if you guys find a proper solution before nov. [08:18] yes, a distro patch in the xenial backport would be more bearable [08:18] we will keep it in the PPA, but th btea and stable images wont use the PPA [08:18] although it's still completely wrong [08:18] this has to be fixed properly anyway at some point.. [08:18] ogra_: what do you mean by beta images? [08:18] popey: it's not just a question of snapcraft snap unfortunatly, you need to have a go env ready [08:19] popey: I guess it's quicker if I do it, one sec [08:19] ogra_: ok, I'll start putting together a NetworkManager SRU for the netplan support patches then [08:19] morphis_, https://wiki.ubuntu.com/QATeam/OSSnapPromotion [08:19] ogra_: I guess you currently have that in the PPA? (which one is that?) [08:19] eventually only edge will use the PPA [08:19] all other channels come from proposed or updatess later [08:19] (later = by release) [08:19] not in https://launchpad.net/~snappy-dev/+archive/ubuntu/image [08:19] ogra_: so the current beta images don't use the ppa? [08:20] pitti, we have "a" netplan there [08:20] PR snapd#1996 opened: daemon: add the actual ssh keys that got added to the create-user response [08:20] popey: can I fake a snapcraft snap on some arch? [08:20] didrocks: when you say "long description" for the port number, where's that? [08:20] ogra_: right, but netplan does not work with xenial's NM [08:20] didrocks: dunno [08:20] morphis_, currently they do, but we are workibng on getting all the PPA changes into -updates before release [08:21] didrocks: I just have classic on my pi, so can use it to snapcraft things, works fine [08:21] popey: I think nothing apart from uappexplorer exposes it [08:21] oh, okay [08:21] popey: hum, ok, so, I will need you :) [08:21] I can give you the binary === pedronis` is now known as pedronis [08:21] ogra_, pitti: good then lets keep the patch as a distro one even for -updates [08:21] morphis_, see the wikipage ... within the next two-three weeks wthis will be implemented [08:21] pitti: I know that there will be a discussion to allow snaps shipping things like "nmcli" so they end up with a prefix "network-manager." [08:21] didrocks: i installed it, and see nothing on that port [08:22] popey: http://localhost:8123? [08:22] yes [08:22] weird, did it work for you dholbach? [08:22] pitti, well, i guess it works with the snapped NM ... [08:22] didrocks, yes [08:22] ignore me didrocks [08:22] pilot error [08:22] * didrocks ignores popey FOREVER!!! :) [08:22] \o/ [08:22] ;) [08:23] popey: so, git clone that branch: https://github.com/ubuntu/codelabs [08:23] works now :) [08:23] ogra_: it does [08:23] I'll give you a binary to replace [08:23] phew! [08:23] morphis_, ogra_: ah, ok; so you don't actually need these patches in xenial-updates then, it seems? [08:23] the NM ones, I mean [08:23] we dont ? [08:23] pitti: no, for the snap we don't need the nm patches in the deb package [08:23] ah, right ... i guess we dont use the deb for packaging the snap [08:23] pitti: we're not using the deb package for the snap at all [08:24] btw, will you guys open source build server for snappys? currently it's a bit problematic building snaps for different platforms [08:24] dz0ny_: you can already build snaps on launchpad for any architecture [08:24] oh [08:24] didn't know [08:24] popey: take this binary and replace the one in the root dir with it: http://didrocks.fr/temp/codelabs [08:25] popey: then, you should be able to build the snap [08:25] (for armhf) [08:25] morphis_: care to share link [08:25] didrocks: ok [08:25] dz0ny_: push a branch and look for a "Create snap package" on the overview site [08:25] dz0ny_: like here: https://code.launchpad.net/~morphis/+junk/pi2-kernel-snap [08:25] dz0ny_, upload your tree (bzr or git) to launchpad ... then you can pick "create snap" [08:26] didrocks: what about "server" in that same directory, also an amd64 binary [08:26] ah thx [08:26] popey: silly me [08:26] I didn't copy the right bin [08:26] lulz [08:27] ogra_: so can you upload a new netplan package then to the ppa if I give you one? [08:27] * ogra_ grins about mwhudson and cyphermox playing pingpong with bug 1621550 [08:27] Bug #1621550: Snappy should detect when running in KVM, specify correct ssh connection line [08:27] morphis_, sure, who will work on getting it into update ? you or pitti ? [08:27] *updates [08:28] popey: so, the one you want is http://didrocks.fr/temp/server :) [08:28] I didn't recompile the other one, it's not shipped in the snap [08:28] (it's only to build the metadata) [08:28] ogra_: don't know, I just care to have it in the beta image we're doing for our customer this week at the moment :-) [08:28] :) [08:28] pitti: can you take the -updates one? [08:28] morphis_, well, i care to not lose it once we turn off the PPA :) [08:28] yeah [08:29] morphis_: that's backport netplan with that PR? [08:29] yes [08:30] well, preferably get the one from the PPA into updates [08:30] not ure if there are other changes [08:30] *sure [08:30] (i didnt put it thre) [08:31] * pitti creates an SRU bug [08:31] pitti: thanks! [08:36] ppisati, so i see an oops on the pi3 ... sadly only in the combo of having console=tty0 and HDMI enabld but i think it is somehow related to the wifi card [08:37] i wonder if it is the same thing i saw on the bbb [08:38] ogra_: can fill a bug with the cmdline used to provoke this? [08:39] i can even give you an image that expoes it ... as long as you dont plug in a wire on first boot ... but it scrolls offscreen and there is no wayx to get proper logs before the user is set up ... which need working network [08:39] *needs [08:40] the pi3 image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has it .. [08:40] * ogra_ files bug [08:43] morphis_: tracking in bug 1627641 [08:43] Bug #1627641: Backport netplan to xenial

[08:44] ppisati, bug 1627643 [08:44] Bug #1627643: oops on pi3 (seemingly wlan related) [08:44] pitti: ok, are you going to create a deb package with that patch now too? [08:44] just that we do not do the same work twice [08:45] morphis_: yes; we eventually want to use netplan for cloud-images etc. as well, so at some point we'll need them; and I'd rather have the integration tests actually succeed [08:45] morphis_: (they cannot work without the NM patches) [08:46] pitti: ok, can you hand that package to ogra_ then so that we can include it in the ppa real soon? [08:47] Bug #1627643 opened: oops on pi3 (seemingly wlan related)

[08:49] morphis_: why? AFAIK snappy edge is built with -proposed enabled, so it would suffice to just have it there? (which we can do today still) [08:50] morphis_: I suppose you just backported Read-config-from-run.patch and Read-system-connections-from-run.patch (I'm not aware of anything else that's needed, but I'll verify with nplan's test/integration.py) [08:51] pitti, no, we turned off proposed (it caued skews) [08:52] *caused [08:52] but if you aren't going to use the NM distro package, why do you need it in the PPA then? [08:52] we need it on the image [08:52] which means in the ubuntui-core snap [08:52] oh, nplan doesn't backport as-is, need a pep8 fallback for pycodestyle [08:53] still confused -- if you use an NM snap, you won't need the xenial-updates NM package with the /run patches in the snappy PPA [08:53] and if you use the distro package, then why bother with the snap and that ugly nplan patch? [08:53] no, i will need the xenial-updatess nplan [08:54] oh, this was about nplan, not NM [08:54] regarding NM we only care about the snap ... and that nplan doesnt break it when users install it by accident i guess [08:54] break it -> the NM deb of xenial [08:55] ogra_: i guess that is a 4.4 kernel, right? [08:55] ppisati, whatever is recent in xenial, yeah [08:55] 4.4.0-1023-raspi2 [08:55] ogra_: k [09:02] erk, NM is stuck in xenial-proposed (v-failed), pinging Aron [09:17] pitti: as, those two patches are what we did [09:17] pitti: in edge later today is fine through -proposed but we need it in beta by the end of the week [09:18] pitti: if that is doable with the SRU, then I am fine, if not lets use the ppa [09:18] morphis_: oh, please do use the PPA; I just wanted to start the process for SRUing now [09:18] pitti: ok, we can take the package you push to -proposed and copy it to the ppa [09:18] morphis_: there is a NetworkManager stuck in xenial-proposed (verification-failed), so we can't get NM into -proposed today [09:19] ok [09:19] pitti: can you ping me once the package is in -proposed? [09:20] morphis_: sure; I also subscribed you to the bug so you get updates from that too [09:20] awesome! [09:41] Bug #1624490 changed: Snap access to /dev/uinput

=== cjwatson_ is now known as cjwatson [11:25] PR snapd#1997 opened: tests: added install_local function [11:27] morphis, http://ubunt.eu/zQa7Xs definitelly needs aethercast so you can have it fly while working ;) === jospoortvliet_ is now known as jospoortvliet === sfeole` is now known as sfeole === cpaelzer_ is now known as cpaelzer [12:24] Hello. Anyone knows what's going on with ubuntu store? I can't submit any new snaps. getting unrecoverable error. And bunch of 503 when navigating the page. [12:27] sborovkov: There was a network issue recently, but if that was it it should be recovering now. [12:27] understood, thanks. === chihchun is now known as chihchun_afk === ben_r_ is now known as ben_r === verterok` is now known as verterok === ben_r_ is now known as ben_r [13:00] random thinking which I'm sure has already been considered, but I wanted to mention it anyway: gui snaps can only display text using fonts installed in the snap when it was built from what I can tell with unofficial-hexchat. would be nice to share fonts between system and snaps [13:02] pitti: looks like we should just update the exiting netplan package in the ppa rather than integrating recent new changes === mhall119_ is now known as mhall119 [13:06] jdstrand, hey! can you have another look at https://github.com/snapcore/snapd/pull/1832 ? [13:06] PR snapd#1832: interfaces/builtin: support time and date settings via 'org.freedesktop.timedate1 [13:09] pstolowski: yes === cosmo_ is now known as cos === cos is now known as cos- [13:21] popey: did you build the armhf snap for me to upload? [13:21] I wonder if I can't otherwise, cheat with snapcraft ;) [13:23] didrocks: I did, but I moved location and can't ssh to the pi now :) [13:23] damn firewalls! [13:23] haha! Who did this! :) [13:24] popey: can wait tomorrow then, no worry ;) [13:24] ta [13:24] it installed but I didnt get an open port and didn't have time to check logs before I left, will take a look later [13:24] oki! === sir is now known as andywork [13:39] ökt [13:39] pitti: hi! it looks like we may need sysfsutils as a snapd dependency [13:40] pitti: and therefore make it part of main, so that we can setup bits in /sys at boot time. or is there a different way to ensure /sys values are set on boot? [13:40] mvo: I'm sorry, do you REALLY mean sysfsutils? [13:40] pitti: maybe, so let me start differently. we need something that can set values in /sys [13:40] mvo: this is really not what you are looking for [13:41] pitti: oh, ok - glad I talked to you :) [13:41] pitti: what am I looking for? [13:41] mvo: man sysctl.d :) [13:42] mvo: *phew* :) [13:42] pitti: the man page talks about /proc/sys - it seems like we need /sys however. sorry, I'm sort of the messanger here only, zyga is working on gpio bits and we need to set some bits in /sys to control the right gpio === josepht` is now known as josepht [13:44] mvo: oh yes, that's sysctls for /proc/sys, I thought that's what you actually meant [13:44] mvo: otherwise you want udev rules [13:46] pitti: aha, thanks, udev rules because /sys is too dynamic for the approvach that sysfsutils took? [13:47] zyga: you probably find the above useful -^ :) [13:47] * zyga looks [13:47] mvo: no, but sysfsutils was an evolutionary dead-end [13:47] oh, interesting, thank you pitti! [13:48] pitti: was it related to libsys2 [13:48] mvo: it's completely useless and does not give you anything that you cannot already do with udev rules or just shell scripts, except for being racy [13:48] mvo: and it has been abandoned like 10 years ago [13:48] mvo: hence me being incredulous, sorry :) [13:49] it should be removed from the archive eventually :) [13:49] pitti: totally fine, I was earnest when I said "glad I talked to you" :) [13:49] but I'm also glad we talked, this is much easier [13:52] pitti: so a design question I have, perhaps: if snapd would like to generate such .conf files, should they live in /etc (which the man page reserves for the administrator) or in /run (which would require snapd to start and write them before stuff that may depend on it would) [13:53] pitti: hold that, I just realized I skipped the most essential message about using udev rules [13:53] pitti: so this is all irrelevant, thanks [13:55] zyga: yeah, there's always those two last crappy rdepends which keep it alive (FSVO "live").. [13:56] zyga: I dislike autogenerated files in /etc, as /etc should really/ideally be "settings that the admin did", not something fixed or derived [13:57] i. e. only "primary" configuration [13:57] zyga: so if these get derived from some other/primary config, putting them into /run is much better [13:57] zyga: it also eases your life as then it stays an internal implementation detail which you can change at any time [13:57] mvo: hi, i'm trying to compile nextcloud snap target armhf on pc. then snapcraft --target-arch armhf complains "copy" plugin don't support cross compile. you have helped me on snapcraft 1.x. may i know any solution for 2.x? [13:57] zyga: with /etc it never goes away and you need to deal with it on upgrades [13:59] PR snapd#1998 opened: debian: re-add golang-github-gosexy-gettext-dev [13:59] pitti: is there a nice place we could put files in /run for udev to pick up? [13:59] zyga: /run/udev/rules.d/ ? [14:00] pitti: thanks, I see [14:00] zyga: but, maybe we sohuld take a step back and clarify what you want to do [14:00] pitti: right now I'm not going to change that but it seems like something we may want to explore down the line [14:00] zyga: i. e. which kind of sysfs attrs do you want to change, and at which point in time [14:00] pitti: well snapd has a way to influence various bits of the kernel [14:00] pitti: here we specifically want to export a GPIO pin to userspace [14:00] zyga: I mean, in the simplest case snapd could just open()/write() the attributes at startup and be done with it [14:00] * ogra_ wonders if you rather want a snippet in /etc/sysctl.d in your package [14:01] ogra_: no, because this is dynamic and it depends on interfaces [14:01] ah, that GPIO thing again [14:01] * ogra_ remembers we talked abot it before [14:01] zyga: that doesn't sound like you would need to do that super-early in the boot sequence? [14:01] pitti: currently when an interface needs to use udev rules we just write them to /etc/udev.d/snap.* and reload udev [14:01] but yeah, why not just write to /sys then ? [14:01] zyga: if you need to apply that to "any future hotplugs", then yes, let snapd put udev rules into /run/udev/rules.d/ [14:01] pitti: well, before any snap apps start [14:01] without udev [14:02] future hotplug events, I figure [14:02] pitti: I don't know if GPIO is very hotpluggable [14:02] if that's a thing, write temp udev rules, then trigger those in snapd, and let the rules take care of future events [14:02] pitti: this is more about having a way to influence bits in sysfs [14:03] zyga: what is the problem with the current implementation of the GPIO iface in snapd? [14:06] morphis_: it doesn't work across reboots, it writes to sysfs whenever you ask for a snippet [14:06] right [14:07] zyga: should we add something like InitializeIfaceConnectionOnSnapdStartup() [14:07] for an interface? [14:07] morphis_: for this case we should use udev rules for that [14:07] morphis_: everything else is persistent already [14:07] how would udev rules apply to to sysfs nodes for GPIO's? [14:08] morphis_: 'echo' :) [14:08] morphis_: udev can just run any command [14:08] morphis_: erk, no [14:08] zyga: sure but you need an event, right? [14:08] ATTR{yourattrname}="value" [14:09] yeah, you need to "coldplug" (udevadm trigger) them after writing to apply to existing devices [14:09] pitti: we already do that [14:09] "udevadm trigger --subsystem-match=gpio" or something suhc [14:09] pitti: well, we do a generic one [14:10] dont ... that eats resources ... limit it to the subsystem [14:11] ogra_: we don't know this [14:11] :) [14:11] ogra_: we cannot limit anything at this time [14:11] now you do :) [14:11] hmm [14:11] Hey! I have a newbie problem in a quick python3-app snap I'm creating [14:11] ogra_: no, we don't know this in snapd, the udev code doesn't know what snippets are doing [14:11] ogra_: we'd have to provide richer data [14:11] ogra_: or parse existing data [14:11] but your interface does, doesnt it ? [14:11] ogra_: no [14:12] ogra_: interface has no way to tell [14:12] if i'm the gpio interface i know i want to act on gpio's ... [14:12] ogra_: the author might but the interface API would have to be changed in a somewhat major way to convey that today [14:12] or run it before systemd-udev-trigger.service, but then it must run really early, without many assumptions [14:12] ogra_: it's not something that's easy to change [14:12] ogra_: then you have to combine the changed subsystems [14:12] ogra_: and in the end you might save some memory/whatever or get it wrong :/ [14:12] ogra_: that's not something for this release [14:13] sil2100: hey, what's up with it? [14:13] ok ok [14:13] :) [14:13] PR snapcraft#828 opened: yaml xpath for errors [14:13] My snap is a standard python3 plugin-based snap, it installs some modules and a python script to /usr/bin/ as expected, but... after installing the snap and trying to run it, I em getting an 'exec: : not found' [14:14] Even though when checking the /snap installation place, the script is in the usr/bin/ directory as expected, also the wrappers *should* set the PATH correctly [14:14] But still, the launcher cannot find the script [14:15] interesting… You should have a .wrapper script that the script in /snap/bin points to, correct? [14:15] this is just shell, you can open it and look at what's added to your env [14:15] Yes, examined the wrapper and everything seems to be ok there [14:15] PATH is set? [14:15] to your $SNAP/usr/bin ? [14:16] I examined all the scripts that are executed on the way and it should be all good, with PATHs being set etc. but it doesn't seem to work [14:16] you can try: [14:16] snap run --shell [14:16] Oh [14:16] you will then be dropped in a shell, with the snap parameter [14:16] just before the wrapper is run [14:16] also ... snap install hello-world ... [14:16] and maybe poke from there? [14:16] Yeah, hello-world works fine [14:16] then you can use helo-world.env to get info about the default vars [14:16] Just my snap has some issues with the paths [14:17] or hello-world.sh to spawn a shell inside the snap env [14:17] Oh, ok, thanks for the pointers, let me dig further then [14:17] :) [14:17] :) === charles_ is now known as charles [14:20] I guess snap run --shell will land him in the right context for his snap, with his code nearby and such ;) [14:21] all that new-world stuff ... pfft :P === lutostag_ is now known as lutostag [14:38] pitti: did you upload a new netplan package already somewhere? [14:42] didrocks: this is really strange, I checked the environment variables when in --shell and the $SNAP variable is set correctly, I also hacked inside an echo $PATH right before the exec part in the final wrapper and the PATH also seems to be set correctly [14:42] morphis_: no, I didn't; still working on that networkd regression; but netplan itself needs no change other than adjusting the Breaks: [14:43] pitti: I am going to create just an updated nplan package over the one we already have in ppa to cause no big regressions [14:44] didrocks: and the /snap/landing-team-tools/x1/usr/bin dir has the binary as required, doing a simple PATH=/snap/landing-team-tools/x1/usr/bin:$PATH image-info (which is the command name) works in the same shell [14:44] PR snapd#1999 opened: daemon: add REST API behind `snap get` [14:45] Let me try removing setting the LD_LIBRARY_PATH in the wrapper script [14:47] hm, yeah, it seems that setting the LD_LIBRARY_PATH seems to somehow break the exec line, making it not find the binary [14:50]