| === JanC_ is now known as JanC | ||
| mup | PR snapcraft#777 opened: go plugin: don't put debugging symbols in generated binaries <Created by teknoraver> <https://github.com/snapcore/snapcraft/pull/777> | 00:50 |
|---|---|---|
| mup | Bug #1621304 opened: In the profile setup, pressing enter after filling the email address does nothing <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621304> | 03:16 |
| liuxg | does anyone have a nodejs snappy sample for reference in addition to the "shout" on in the demos? thanks | 03:22 |
| === chihchun_afk is now known as chihchun | ||
| mup | Bug #1621323 opened: On the all-snaps image, the snapweb interfaces are not connected <Snappy:New> <snapweb:New> <https://launchpad.net/bugs/1621323> | 05:38 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| Kaleo_ | mvo, tvoss, I heard something about dbus session bus support or something. Is there something being baked related to that? | 06:18 |
| mvo | hey Kaleo_ - no dbus session bus work is happening currently from the core team afaik, is that something important for you/your team? | 06:24 |
| Kaleo_ | mvo, I think so | 06:24 |
| Kaleo_ | mvo, wwho is the core team? | 06:24 |
| Kaleo_ | -w | 06:24 |
| mup | Bug #1621339 opened: Unable to complete UC16 beta first boot if ESC is pressed after last step <Snappy:New> <https://launchpad.net/bugs/1621339> | 06:33 |
| didrocks | hey mvo! Great job for yesterday's image! I'm curious if you think we'll have a snapd release today with the "revert fix" we discussed about the other day? As this is the last day for us to prepare the image for Monday's event | 06:33 |
| Kaleo_ | mvo, I've uploaded a i386 snap of test-snapd-thumbnailer-consumer (there was only an amd64 version): is that the right way to support multiple archs? automated review failed, can you let it through? | 06:35 |
| mvo | Kaleo_: the most important person to talk to would be gustavo as he will design the feature. however he/we are busy with the "ga" release | 06:35 |
| Kaleo_ | https://myapps.developer.ubuntu.com/dev/click-apps/5863 | 06:35 |
| mvo | Kaleo_: yes and yes | 06:35 |
| Kaleo_ | thanks | 06:35 |
| Kaleo_ | mvo, great | 06:35 |
| mvo | Kaleo_: feel free to join our standups to talk about specific feature you need | 06:36 |
| mvo | didrocks: pavel was working on this last I checked, give me a minute to look over the open PRs | 06:36 |
| didrocks | thx! | 06:36 |
| mvo | didrocks: I really would love to do something for you, even something cheap and hackish like "revert --devmode" so that it preserves the flag, chippaca was also looking at it, but because of the image rush I did not pay too much attention | 06:37 |
| mvo | Kaleo_: approved, enjoy | 06:37 |
| Kaleo_ | mvo, thank you :) | 06:37 |
| didrocks | mvo: yeah, I guess it. But indeed, I can hide the --devmode typing quickly when doing the revert and that would work (even if snapd is only in -proposed, I can install my image with it) ;) | 06:38 |
| mvo | didrocks: lets keep talking over the course of the day, at this time most people are still sleeping :) at least the relevant ones | 06:39 |
| mvo | Kaleo_: my pleasure! | 06:39 |
| mvo | I will promote the candidate ubuntu-core images to stable very soon, so if people want to do last minute tests on those :) | 06:39 |
| didrocks | mvo: ok, I'll let you just ping me once people are ready for this :) | 06:40 |
| didrocks | mvo: does it has reexec? that case, I'll need to ensure I'm adding the magic variable to /etc/environment in case I have to use snapd from -proposed (and so, the package version) | 06:41 |
| mvo | didrocks: the version in xenial-updates that got promoted yesterday has re-exec disabled | 06:43 |
| mvo | didrocks: because the sru process is now working really well for us and also because it causes some hard to understand behavior | 06:43 |
| didrocks | ok! | 06:43 |
| tvoss | Kaleo_: we don't need the core Team right now to unblock your work, I'm getting a coffee refill right now, will be online in a few | 06:44 |
| Kaleo_ | tvoss, COFEE | 06:45 |
| Kaleo_ | +F | 06:45 |
| tvoss | Kaleo_: the core team, so Jamie specifically is aware of our requirements, let's coordinate a little on what we put on their plate | 07:01 |
| tvoss | Kaleo_: for the time being, we will unblock you and get you a session dbus in a classic environment | 07:01 |
| dholbach | hey hey | 07:02 |
| Kaleo_ | tvoss, sounds good | 07:02 |
| Kaleo_ | tvoss, and that means DBUS_SESSION_BUS_ADDRESS needs to be set right? | 07:03 |
| tvoss | Kaleo_: yeah, we are taking care of that stuff | 07:03 |
| tvoss | Kaleo_: I think we can have something be eow | 07:03 |
| tvoss | by, even | 07:03 |
| Kaleo_ | tvoss, ok | 07:03 |
| mup | PR snapd#1816 closed: libvirt interface to allow snaps to access libvirtd on a classic host <Created by cmars> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1816> | 07:19 |
| ogra_ | hmpf ... so the grade hackery didnt help | 08:07 |
| ogra_ | all ubuntu-core snaps are stuck :( | 08:07 |
| mvo | ogra_: yeah | 08:22 |
| mvo | ogra_: if you could give the pi3 image a quick try, that would rock | 08:22 |
| ogra_ | i'll take a deeper look into patching our snapcraft | 08:22 |
| ogra_ | mvo, both downloading atm ... i only get 200k/s from cdimage for some reason :/ | 08:22 |
| zyga | anyone versed in glib-test, is ther any sanity into how -p and -s options work for selecting tests to run | 08:27 |
| pitti | mvo: guten Morgen | 08:27 |
| zyga | they seem to do nothing sensible at all, I'm trying to follow the source to see what's going on | 08:27 |
| zyga | a simple test on some-unit-test-binary -s /stuff-to-skip/ just does nothing and runs all tests with that prefix | 08:28 |
| zyga | similarly to -p | 08:28 |
| pitti | ogra_, mvo: IIRC you could reproduce bug 1620559, right? would you mind telling your testing result to it, so that we can mark it v-done? | 08:28 |
| mup | Bug #1620559: /etc/resolv.conf is empty on snappy <hw-specific> <verification-needed> <Snappy:New> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Committed by pitti> <https://launchpad.net/bugs/1620559> | 08:28 |
| zyga | some values of -p seem to work but the exact criteria are eluding me, it seems the number of slashes in the test name is relevant | 08:28 |
| pitti | mvo: does networking behave now? | 08:29 |
| ogra_ | pitti, it does | 08:29 |
| pitti | (I guess RTM day wouldn't be the worst day for it to behave :) ) | 08:29 |
| mvo | pitti: its working fine, thanks again | 08:31 |
| ogra_ | pitti, set to verification-done | 08:32 |
| pitti | danke | 08:32 |
| mup | PR snapd#1867 opened: fix incorrect number of implicit interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/1867> | 08:37 |
| mup | Bug #1621378 opened: console-conf should tell the user that the keyboard is US only <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621378> | 08:51 |
| mup | Bug #1621380 opened: console-conf should allow to configure a hostname <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621380> | 08:54 |
| mwhudson | mvo: did you figure out the GOARM problems in the end? | 08:56 |
| mvo | sergiusens: please! https://bugs.edge.launchpad.net/ubuntu/+bug/1621382 | 08:56 |
| mup | Bug #1621382: launchpad building with stage packages broken <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1621382> | 08:56 |
| mvo | mwhudson: which one of them ;) | 08:56 |
| mvo | mwhudson: but yeah, after some mild panic attacks we got a images | 08:57 |
| mvo | mwhudson: network was broken in between and similar but we got it all under control | 08:57 |
| ogra_ | mvo, hmm, why did my pi3 just get an ubuntu-core update in the middle of installing the classic snap ? | 09:00 |
| ogra_ | eeek ! | 09:00 |
| ogra_ | ogra@localhost:~$ snap list | 09:00 |
| ogra_ | Name Version Rev Developer Notes | 09:00 |
| ogra_ | classic 16.04 14 canonical devmode | 09:00 |
| ogra_ | ubuntu-core 16.04.1 424 canonical - | 09:00 |
| ogra_ | ogra@localhost:~$ | 09:00 |
| ogra_ | mvo, something is wrong with the pi3 image | 09:01 |
| mvo | ogra_: no kernel? | 09:02 |
| ogra_ | ogra@localhost:~$ systemctl status snapd.firstboot.service | 09:02 |
| ogra_ | ● snapd.firstboot.service - Run snappy firstboot setup | 09:02 |
| ogra_ | Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled) | 09:02 |
| ogra_ | Active: failed (Result: exit-code) since Wed 2016-09-07 21:07:19 UTC; 11h ago | 09:02 |
| ogra_ | Main PID: 1448 (code=exited, status=1/FAILURE) | 09:02 |
| mvo | ogra_: snap change 1? | 09:02 |
| ogra_ | ogra@localhost:~$ snap change 1 | 09:02 |
| ogra_ | Status Spawn Ready Summary | 09:02 |
| ogra_ | Done 2016-09-07T21:07:20Z 2016-09-08T08:45:05Z Generate device key | 09:02 |
| ogra_ | Done 2016-09-07T21:07:20Z 2016-09-08T08:45:14Z Request device serial | 09:02 |
| mvo | ogra_: snap change 2 :) | 09:03 |
| ogra_ | thats already the "install classic" call | 09:03 |
| ogra_ | no trace of firstboot in snap changes | 09:03 |
| mvo | ogra_: nothing from firstboot? weeeeh | 09:03 |
| ogra_ | also no complaint about a missing model assertion | 09:03 |
| ogra_ | very weird | 09:03 |
| ogra_ | mvo, dragonboard is fine though ... | 09:04 |
| mwhudson | mvo: the hwcap / "please recompile with GOARM=5" one was the one i meant | 09:06 |
| mvo | mwhudson: oh, yes, that is the libc aux vector getting srubed by apparmor and that contains the information about the availabity of a floating point unit | 09:06 |
| mwhudson | ah ok | 09:07 |
| mwhudson | yes, sounds about right | 09:07 |
| mvo | mwhudson: tyler and jamie know the even more gorry details | 09:07 |
| mvo | but I think this is pretty much it and I changed the apparmor confinment to allow this vector to get passed unchanged | 09:07 |
| mwhudson | yeah, go uses it for quite a few things | 09:08 |
| matteo | elopio: I've fixed the tests for PR #777 | 09:48 |
| mup | PR snapd#1867 closed: fix incorrect number of implicit interfaces <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1867> | 10:10 |
| === hikiko is now known as hikiko|ln | ||
| mwhudson | mvo: could you subscribe snappy-dev to https://bugs.launchpad.net/ubuntu/+source/golang-github-coreos-go-systemd pls? (for MIR) | 10:56 |
| gouchi | hi | 11:00 |
| gouchi | I got this error error: cannot find signatures with metadata for snap when I try to test my snap package | 11:00 |
| gouchi | didn't get this error before | 11:00 |
| ogra_ | use the --dangerous option | 11:01 |
| ogra_ | i assume you try to do a snap install ? | 11:01 |
| gouchi | yes | 11:01 |
| ogra_ | yeah, then use that for snaps not signed by the store | 11:02 |
| nhaines | The Ubuntu Core beta image for Rpi2 is pretty fun. :) | 11:02 |
| nhaines | Is there a story for wireless networking yet? | 11:02 |
| gouchi | ogra_: error: unknown flag `dangerous' | 11:03 |
| ogra_ | nhaines, console-conf does not support it yet (it is in the pipe) | 11:03 |
| nhaines | ogra_: "in the pipe" is good to know. | 11:03 |
| nhaines | snapweb didn't work at all for me. | 11:03 |
| nhaines | And 'snap find' is broken now. | 11:03 |
| ogra_ | nhaines, you can cheat indeed and put a config into /etc/netwotrk/interfaces.d/wlan0 (and reboot) | 11:03 |
| ogra_ | broken ? how ? | 11:03 |
| nhaines | ogra_: now *that* is exactly what I wanted to know. :) | 11:03 |
| nhaines | ogra_: it used to list all snaps; now it simply returns an error. | 11:04 |
| ogra_ | thats by design ;) | 11:04 |
| ogra_ | not broken | 11:04 |
| nhaines | It is a regression and probably a bad design. ;) | 11:04 |
| nhaines | Although I'm sure it wasn't scalable. | 11:04 |
| ogra_ | snap find can only show 100 snaps ... but the sotre has more | 11:04 |
| nhaines | This makes it impossible to discover snaps, though. | 11:05 |
| nhaines | (So I hope design is on it sometime.) | 11:05 |
| ogra_ | well, if you have 1mio snaps one day you realyl dont want them listed :) | 11:05 |
| nhaines | ogra_: sure, that's what `less` is for. ;) | 11:05 |
| ogra_ | sure ... but the less would only start after retrieving lines for 2h :P | 11:06 |
| ogra_ | (and probably cause an OOM) | 11:06 |
| nhaines | :) | 11:06 |
| nhaines | So there are problems. But I was able to have Nextcloud running in all of 30 seconds and I didn't have to do any of that pesky installation or dependencies or configuration. So there's that! | 11:07 |
| nhaines | Should snapweb still be listening on port 4200? | 11:08 |
| ogra_ | it should ... but it has bugs and fails to start currently | 11:08 |
| ogra_ | btw... wlan -> http://paste.ubuntu.com/23149789/ | 11:08 |
| nhaines | Okay, currently broken, that's good to know, too. | 11:08 |
| nhaines | I'm not certain that "pull all keys from Launchpad" is a "real world" solution, but I'll be damned if it wasn't absolutely perfect for me. :D | 11:09 |
| ogra_ | it will auto-update to a fixed version ;) | 11:09 |
| nhaines | Yes, benefit of snappy. ;) | 11:09 |
| nhaines | Although I sort of feel like "wireless networking setup and web administration don't work right now" could have been in the release notes. :P | 11:11 |
| nhaines | But I've been having plenty of fun with snapd on the desktop, and seeing Ubuntu Core 16 start to really take shape is very exciting! | 11:12 |
| mwhudson | nhaines: do you want to try a bootleg core snap that might let you configure wifi? :) | 11:12 |
| nhaines | mwhudson: yes, sounds like fun. :) | 11:13 |
| nhaines | Particularly because if it doesn't work I can file a bug and jump back to the beta release. :) | 11:13 |
| ogra_ | well, not sure you can actually sideload ubuntu-core easily | 11:14 |
| ogra_ | i think we block that | 11:14 |
| mwhudson | i think this would be a "make new image and reflash" sort of test | 11:14 |
| nhaines | Not with that attitude! | 11:14 |
| ogra_ | heh | 11:14 |
| mwhudson | builds started on https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot anyway | 11:14 |
| ogra_ | snappy = safety first :) | 11:14 |
| gouchi | now I launch my package and I got "failed: cannot list snaps: access denied" ? | 11:14 |
| ogra_ | gouchi, wow, thats a weird one | 11:15 |
| ogra_ | havent seen that before | 11:15 |
| nhaines | The real fun of snaps is that betatesting is really painless because reverting to known-good images is as fast as your disk controller. | 11:15 |
| ogra_ | yeah | 11:15 |
| nhaines | gouchi: if you're on a classic desktop Ubuntu, try "snap login" again. | 11:15 |
| ogra_ | nhaines, well, that should work without | 11:16 |
| gouchi | there must have been some changes to snapd because I could test my package | 11:16 |
| ogra_ | unless gouchi's snap calls "snap list" | 11:16 |
| ogra_ | internally | 11:16 |
| gouchi | no it doesn't | 11:16 |
| ogra_ | yeah, i assumed so | 11:17 |
| ogra_ | if you just call snap list manually, does it also throw that error ? | 11:17 |
| gouchi | error: cannot list snaps: access denied | 11:17 |
| ogra_ | wow | 11:17 |
| ogra_ | is that on desktop ? | 11:17 |
| gouchi | strange I must have done something wrong during my installation | 11:17 |
| ogra_ | or "classic" | 11:18 |
| gouchi | I am running on ubuntu 16.04 desktop | 11:18 |
| gouchi | I just followed as usual the installation process here : https://github.com/snapcore/snapd | 11:19 |
| ogra_ | you mean you built snapd from source ? | 11:20 |
| mup | PR snapd#1868 opened: Support revert flags <Created by stolowski> <https://github.com/snapcore/snapd/pull/1868> | 11:20 |
| gouchi | ogra_: yes | 11:20 |
| gouchi | ogra_: sorry for the noise there was wrong permission on /run/snapd.socket | 11:20 |
| ogra_ | dont you trust our packages ? :) | 11:21 |
| gouchi | I try time to time the package if it is working but still failed | 11:22 |
| gouchi | I don't understand because opengl software are working | 11:23 |
| gouchi | if somebody wants to look here my snapcraft.yaml and wrapper with the log http://www.hastebin.com/xajesehica.coffee | 11:29 |
| gouchi | I know I should use dump plugin instead of copy ;-) | 11:30 |
| nhaines | ogra_: hmm, /etc/network/interfaces.d/wlan0 didn't seem to work. | 11:35 |
| ogra_ | nhaines, i used it on my pi3 and dragonboard | 11:35 |
| ogra_ | on a WPA2 network | 11:36 |
| nhaines | Quoting my SSID and trying again. :) | 11:38 |
| mup | PR snapd#1869 opened: cmd/snap: serialise empty keys list as [] rather than null <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1869> | 11:38 |
| zyga | jdstrand: hey, around? | 11:40 |
| nhaines | Hmm, still nothing. | 11:42 |
| ogra_ | any errors ? | 11:43 |
| nhaines | I see in dmesg where the devices was renamed from wlan0. But not where to. | 11:43 |
| ogra_ | renamed ? | 11:43 |
| ogra_ | well, use your wired connection to debug :) | 11:43 |
| nhaines | [ 15.286248] rtl8192cu 1-1.3:1.0 wlx74da386871f1: renamed from wlan0 | 11:43 |
| ogra_ | uuuh | 11:43 |
| nhaines | ogra_: yes, that's what I'm doing. Althuogh... | 11:44 |
| ogra_ | realtek | 11:44 |
| nhaines | My ifconfig-fu is now weak. | 11:44 |
| ogra_ | thats a USB wlan card, attached externally, right ? | 11:44 |
| nhaines | Yes, I bought it specifically because it works on the RPi2 with no special drivers--particularly with Ubuntu MATE. | 11:44 |
| nhaines | ogra_: correct. | 11:44 |
| ogra_ | i bet we dont have the firmware | 11:45 |
| nhaines | Hmm, schade. :) | 11:45 |
| ogra_ | check in lsmod if a module is loaded for it | 11:45 |
| ogra_ | and grep in syslog for that module name | 11:45 |
| ogra_ | i bet you find some error about missing firmware files | 11:45 |
| ogra_ | if so, file a bug and let ppisati know about it | 11:45 |
| nhaines | Hmm, rtl8192cu, rtl_usb, rtl9281c_common, and rtlwifi are all loaded. | 11:46 |
| ogra_ | that looks ok then | 11:46 |
| ogra_ | cat /proc/net/dev ? | 11:46 |
| nhaines | No errors in syslog. | 11:46 |
| ogra_ | well, if it was renamed, you need to rename the config file and the name of the device inside | 11:47 |
| nhaines | Oh, it lists wlx74da386871f1. zeros all across. | 11:47 |
| nhaines | Hmpf. :) | 11:47 |
| ogra_ | right .. | 11:47 |
| ogra_ | these are the new "predictable" network interface names :) | 11:47 |
| ogra_ | ask lennart poettering whats predictable about them though :P | 11:48 |
| ogra_ | and indeed, it will only work if you pronounce the name three times in a row aloud | 11:48 |
| nhaines | Well, we'll see in 30 seconds I suppo! | 11:49 |
| nhaines | suppose! | 11:49 |
| === dpm_ is now known as dpm | ||
| nhaines | ogra_: well, that worked! So now my RPi2 running snappy is twice as useful. ;) | 11:54 |
| nhaines | Welll, I suppose I learned something new with /proc/net/dev. Thanks very much for helping me troubleshoot that. :) | 11:55 |
| gouchi | adjust program to write to $SNAP_DATA or $SNAP_USER_DATA because the software needs to read/write in ~/.config | 11:55 |
| nhaines | Also, just imagine me shaking my fist at Lennart Poettering. | 11:55 |
| gouchi | So we need to patch the software to use those env variables ? | 11:56 |
| morphis | mvo, pedronis: where can people who want to generate an image for supported devices (pi, dragonboard) get a model assertion from? Do they have to always generate one on their own or is it possible to fetch the official signed one from somewhere? | 12:01 |
| ogra_ | nhaines, heh, glad it worked | 12:02 |
| ogra_ | morphis, afaik thats still in the works, there will be a way to get it generated via the store or LP or so | 12:02 |
| nhaines | ogra_: now to figure out how to change the hostname. Although I do want to file a bug that nano isn't around. :P | 12:03 |
| morphis | ogra_: ok, so for now I have generate my own one or take it from "somewhere" | 12:03 |
| ogra_ | morphis, if you want to do basic boot testing you can use UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 with ubuntu-image | 12:03 |
| morphis | ah | 12:03 |
| morphis | so I still need one but can use without signature | 12:03 |
| ogra_ | morphis, note though that will only help with boot stuff ... snap commands will not work in the booted image | 12:04 |
| morphis | ogra_: hm | 12:04 |
| ogra_ | (firstboot will refuse to run without a signed model assertion) | 12:04 |
| mvo | morphis: its possible to get it from the store, it will be in the assertion store in a bit, I can mail you one in the mantime | 12:05 |
| morphis | mvo: got the pc.model already from your snapd PR | 12:06 |
| morphis | but was wondering about one for the pi2/pi3 | 12:06 |
| ogra_ | well, we need a way to use self signed ones | 12:10 |
| ogra_ | since what mvo will give you will be the official canonical assertion ... | 12:10 |
| ogra_ | whihc makes your home built images kind of official :) | 12:10 |
| zyga | seb128: hey | 12:12 |
| mup | PR snapd#1870 opened: store: ensure the payment methods method handles auth failure <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1870> | 12:12 |
| zyga | seb128: do you know who manages snapd-xdg-open on github? I have a few things pending there without reply | 12:12 |
| seb128 | zyga, hey, attente did most of the work and mvo helped with review&landing I think | 12:15 |
| seb128 | zyga, I don't understand your "package for <...>" issues reports | 12:18 |
| seb128 | zyga, distributions doing packaging isn't an upstream issue | 12:19 |
| mup | PR snapd#1871 opened: snap: lessen annoyance of implicit interface tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1871> | 12:19 |
| morphis | ogra_: yeah | 12:24 |
| morphis | ogra_, mvo: so what is the one in https://github.com/mvo5/snappy/blob/c230019df76d27ce7c67f3003e1c0ca945030c2d/tests/lib/prepare.sh signed with? | 12:24 |
| morphis | ogra_: and with that we basically require people to create their own model assertion when they want to build an image which is different to the official one | 12:25 |
| ogra_ | exactly | 12:25 |
| mup | PR snapd#1869 closed: cmd/snap: serialise empty keys list as [] rather than null <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1869> | 12:26 |
| morphis | ogra_: good | 12:27 |
| zyga | attente: hey, around? could you please add me to snapd-xdg-open on github / review branches | 12:35 |
| zyga | seb128: the package bugs are just so that we have downstream packages for all the distros | 12:36 |
| seb128 | zyga, that's not an upstream issue... | 12:36 |
| zyga | seb128: I agree it's not an upstream issue but this is an easy way to track it | 12:36 |
| * seb128 sends zyga some postits | 12:36 | |
| ogra_ | with passwords on them ? | 12:36 |
| * seb128 writes "ubuntu/ubuntu" on the postits | 12:37 | |
| zyga | but.. I have all the ubuntu stickers already | 12:39 |
| seb128 | zyga, is there any change you need to commit? I had a look and you don't have anything major there, having an empty README is probably not bothering many people | 12:40 |
| seb128 | or is that to get a 0.1 tarball out? | 12:40 |
| zyga | seb128: correct | 12:40 |
| zyga | seb128: this blocks the fedora package | 12:40 |
| seb128 | why? | 12:40 |
| mup | PR snapd#1872 opened: tests: use in-tree snap{ctl,-exec} for all tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1872> | 12:40 |
| seb128 | they for sure have git snapshot packages | 12:40 |
| zyga | seb128: because snapshot vs release packaing | 12:40 |
| seb128 | that's a lame excuse | 12:40 |
| zyga | seb128: and we should just release | 12:40 |
| jdstrand | zyga: hey | 12:41 |
| seb128 | you could grab the package .tar.gz and claim that a release | 12:41 |
| zyga | jdstrand: hello, nice to see you | 12:41 |
| zyga | seb128: no, that's not how fedora packaging works | 12:41 |
| zyga | seb128: anyway, this is a moot discussion | 12:41 |
| seb128 | right | 12:41 |
| jdstrand | zyga: you too :) | 12:41 |
| zyga | jdstrand: I did plenty of updates to the ns-support module | 12:41 |
| seb128 | zyga, well I know if some desktop packages they have that are git snapshot so it's a lame argument to block things they don't want I guess | 12:42 |
| zyga | jdstrand: there are still a few things but I was wondering if we can merge it and iterate (after a 2nd review with the new changes) | 12:42 |
| seb128 | zyga, but as you said, no point arguing, easy enough to roll a tarball | 12:42 |
| jdstrand | zyga: ok, I'll take a look | 12:42 |
| jdstrand | let me get through email for anything urgent | 12:42 |
| zyga | seb128: I mean, I could do a snapshot realease but I really don't want to, part of what I need to do is to ensure that all the distros ship the same thing and it is easier with versions | 12:42 |
| seb128 | right | 12:43 |
| zyga | jdstrand: I'd like to propose a small branch that actually uses it, along with some simple spread tests, and let people play with the real thing | 12:43 |
| zyga | seb128: I should also ITP snapd-xdg-open in debian | 12:44 |
| mup | Bug #1564369 changed: sudo broken in latest classic <Snappy:Fix Released> <https://launchpad.net/bugs/1564369> | 12:44 |
| zyga | jdstrand: there will be a change to snap-confine and a new executable snap-discard-namespace | 12:44 |
| zyga | jdstrand: (not setuid root!) | 12:44 |
| attente | zyga: hey, sorry, but i don't have write access to that repo either | 12:45 |
| zyga | attente: oh, interesting | 12:46 |
| zyga | so who does? :) | 12:46 |
| zyga | mvo: FYI, I wrote what-is-mounted that prints json with all the details based on mountinfo | 12:46 |
| attente | zyga: should be didrocks and mvo | 12:46 |
| zyga | I think grep and awk are ok but if we ever need something more complex we should perhaps think about it | 12:46 |
| zyga | didrocks: do you have commit access to snapd-xdg-open on github.com/snapcore/snapd-xdg-open? | 12:47 |
| jdstrand | whoa | 12:47 |
| jdstrand | how did the libvirt interface go through without security review? | 12:48 |
| jdstrand | zyga, mvo: ^ libvirt should not auto-connect | 12:48 |
| ogra_ | well, security ... who cares :P | 12:48 |
| jdstrand | it gives a direct path to root | 12:48 |
| jdstrand | just like lxd and docker | 12:48 |
| zyga | jdstrand: should it it auto-connect but be restricted? | 12:49 |
| * ogra_ pushes code for an nsa interface that auto-connects ... lets see :P | 12:49 | |
| zyga | ogra_: make sure it doesn't show in snap interfaces | 12:49 |
| ogra_ | thats indeed the ppurpose :) | 12:49 |
| jdstrand | zyga: there are choices to be made, sure. but there was no discussion or coordination on restricting it | 12:50 |
| jdstrand | zyga: there is nothing in snapd that limits its use to a certain snap atm. there is nothing in the review tools that would limit it (other than the fact that the review tools would warn cause it isn't a known interface yet (thank goodness for defensive tools)) | 12:51 |
| zyga | jdstrand: sure, I don't dispute the no-review part | 12:51 |
| jdstrand | it also doesn't have any comments on how much privilege it gives | 12:52 |
| mvo | jdstrand: sorry, I think this one was my fault. I will push a branch that removes the auto-connect | 12:52 |
| jdstrand | I thought there was an understanding that all security policy went through a member of the security team? | 12:52 |
| jdstrand | ok | 12:52 |
| abeato | mvo, hey, do you know if the issue with rpi/vfp detection has already been solved? | 12:53 |
| mvo | abeato: yes, that is fixed | 12:53 |
| abeato | mvo, nice, thanks | 12:54 |
| jdstrand | mvo: if I comment on the original branch, will you incorporate the changes? (feel free to autoconnect now) | 12:55 |
| cjwatson | Hmm, I think the autopkgtest failures on https://github.com/snapcore/snapcraft/pull/726 are a test infrastructure bug of some kind - I already added snapd to Depends in debian/tests/control, but it doesn't appear to be being installed | 12:55 |
| mup | PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726> | 12:55 |
| jdstrand | mvo: err, feel free to make autoconnect false now | 12:55 |
| mvo | jdstrand: yes, PR on the way | 12:56 |
| mvo | jdstrand: sorry again | 12:56 |
| jdstrand | ok, thanks | 12:56 |
| mup | PR snapd#1873 opened: interfaces: disable auto-connect in libvirt interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/1873> | 12:56 |
| didrocks | zyga: added | 12:57 |
| zyga | didrocks: thank you! | 13:01 |
| === pbek_ is now known as pbek | ||
| didrocks | yw | 13:04 |
| morphis | mvo: shouldn't snapd rexec itself when I install the edge ubuntu-core snap on my desktop? | 13:14 |
| zyga | morphis: AFAIR we disabled this lately | 13:16 |
| ogra_ | unless you have exported the env var that prevents this it should | 13:17 |
| ogra_ | ogra@styx:~/Devel/branches/ubuntu-core-snap$ snap --version | 13:17 |
| ogra_ | snap 2.14.2~16.04+ppa224-1 | 13:17 |
| ogra_ | snapd 2.14.2~16.04+ppa224-1 | 13:17 |
| ogra_ | series 16 | 13:17 |
| ogra_ | ubuntu 16.04 | 13:17 |
| ogra_ | this is definitely not the binary from the installed package | 13:17 |
| ogra_ | but from ubuntu-core | 13:17 |
| morphis | zyga, ogra_: export SNAP_REEXEC=1 ? | 13:18 |
| ogra_ | well, you shouldnt need to export it ... | 13:19 |
| ogra_ | at least on my machines i get the in-ubuntu-core binary without any tinkering | 13:19 |
| ogra_ | if you want to suppress it you need export SNAP_REEXEC=0 though | 13:20 |
| zyga | morphis: I think this is set in the service environment file | 13:20 |
| morphis | ok | 13:20 |
| zyga | morphis: so snapd won't reexec, snap might if you set it in the shell directly | 13:20 |
| morphis | let me try zhat | 13:20 |
| ogra_ | ogra@styx:~/Devel/branches/ubuntu-core-snap$ grep Env /etc/systemd/system/multi-user.target.wants/snapd.service | 13:21 |
| ogra_ | EnvironmentFile=/etc/environment | 13:21 |
| ogra_ | not really | 13:21 |
| ogra_ | ogra@anubis:~/datengrab/devel/branches/snappy-systems$ grep Env /etc/systemd/system/multi-user.target.wants/snapd.service | 13:21 |
| ogra_ | EnvironmentFile=/etc/environment | 13:21 |
| ogra_ | nor on my desktop | 13:21 |
| ogra_ | (both xenial) | 13:21 |
| morphis | Sep 08 15:22:25 nirvana /usr/lib/snapd/snapd[17662]: cmd.go:81: DEBUG: restarting into "/snap/ubuntu-core/current/usr/lib/snapd/snapd" | 13:22 |
| morphis | with SNAP_REEXEC=1 in /etc/environment | 13:23 |
| morphis | ah that gives me snap sign :-) | 13:24 |
| morphis | ogra_: you now have the unsigned model assertion for the pi somewhere? | 13:24 |
| ogra_ | pi2 or 3 ? | 13:27 |
| morphis | both :-) | 13:27 |
| ogra_ | http://paste.ubuntu.com/23150160/ | 13:27 |
| ogra_ | just replace the gadget name :P | 13:27 |
| morphis | aye | 13:28 |
| mvo | morphis: not anymore, re-exec got disabled | 13:31 |
| morphis | mvo: see the log output above | 13:31 |
| morphis | hm, now I only get a: error: cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure | 13:32 |
| morphis | when I try to sign my own model assertion | 13:32 |
| abeato | it looks like it is not possible to run strace now with a snapped command :( | 13:34 |
| ogra_ | mvo, why do i have 2.14.2~16.04+ppa224-1 in "snap ---version" then ? | 13:34 |
| ogra_ | i definitely dont have that package installed | 13:34 |
| ogra_ | mvo, dpkg -l shows snapd 2.13 installed ... snap --version the ppa string ... so i guess if you wanted to prevent re-exec this didnt work | 13:36 |
| zyga | jdstrand: I have a quick branch for working snap-confine with ns-sharing, I am still cooking it to contain the spread tests that I wrote | 13:38 |
| zyga | jdstrand: I didn't do the hat -> profile change update yet | 13:39 |
| morphis | mvo, ogra_: any idea about that error message? | 13:39 |
| zyga | jdstrand: do you know who sends the signal (in terms of apparmor peer) when prctl() set-parent-death-signal happens? | 13:39 |
| morphis | mvo, ogra_: generated a key locally | 13:40 |
| zyga | jdstrand, tyhicks: the relevant commit is: https://github.com/snapcore/snap-confine/commit/865c5dfb9704d71c16fafc2cf42ef95c1fd2933e | 13:40 |
| mvo | morphis: apt list snapd shows you 2.13? this still re-execs, please apt upgrade to 2.14.2 | 13:40 |
| morphis | mvo: I've updated to 2.14.2 | 13:40 |
| jdstrand | zyga: I was actually wondering how that would show up in policy myself. aiui, the kernel will send it, so guessing that our base abstraction will allow it | 13:41 |
| morphis | and added SNAP_REXEC=1 to /etc/environment | 13:41 |
| morphis | mvo: which gives me | 13:41 |
| morphis | Sep 08 15:22:25 nirvana /usr/lib/snapd/snapd[17662]: cmd.go:81: DEBUG: restarting into "/snap/ubuntu-core/current/usr/lib/snapd/snapd" | 13:41 |
| zyga | jdstrand: yes, I was expecting the kernel to send it as well | 13:41 |
| zyga | jdstrand: please comment on the profile there, I'll open a pull requst once I have a few more spread tests | 13:42 |
| mvo | morphis: uh | 13:42 |
| morphis | mvo: don't tell me that shouldn't be possible :-) | 13:43 |
| ogra_ | morphis, nope, i never signed a model assertion ... | 13:43 |
| === ant__ is now known as antdillon | ||
| mvo | morphis: I'm slightly confused - so snapd is re-execing even with 2.14.2 ? SNAP_REEXEC=1 should be the only way to enable this | 13:44 |
| ogra_ | and i dont think you can "just sign" it | 13:44 |
| ogra_ | it must come from a valid store account | 13:45 |
| mvo | morphis: sorry for being a bit thick - do you want it to re-exec or do you want to disable that? | 13:45 |
| morphis | mvo: ok, lets correct this: I've added SNAP_REEXEC=1 to /etc/environment | 13:45 |
| morphis | mvo: and I want rexec | 13:45 |
| ogra_ | mvo, he wants to know whats the default :) | 13:45 |
| mvo | morphis: ok, wit hthat setting it should re-exec | 13:45 |
| morphis | ogra_: I want snapd from edge on my desktop from the edge ubuntu-core snap :-) | 13:45 |
| mvo | morphis: the default is now (with 2.14.2) SNAP_REEXEC=0 unless you set it to something else | 13:45 |
| zyga | jdstrand: (separate topic) do you think snapd-xdg-open should be confined | 13:46 |
| zyga | jdstrand: it processes input from untrusted snaps | 13:46 |
| zyga | jdstrand: I was thinking aobut cooking a profile for it | 13:46 |
| mvo | morphis: so SNAP_REEXEC=1 should give you re-exec - but its not working you say? | 13:46 |
| ogra_ | oh, why didnt i get a new snapd with todays upgrade | 13:46 |
| ogra_ | ogra@styx:~/Devel/branches/ubuntu-core-snap$ snap --version | 13:47 |
| ogra_ | snap 2.14.2~16.04 | 13:47 |
| ogra_ | snapd unavailable | 13:47 |
| ogra_ | series - | 13:47 |
| ogra_ | interesting | 13:47 |
| ogra_ | that output changed a lot now | 13:47 |
| morphis | mvo: it works | 13:47 |
| morphis | mvo: I am now getting error messages when signing a model assertion | 13:48 |
| morphis | $ cat pi3.json| snap sign | 13:48 |
| morphis | error: cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure | 13:48 |
| mvo | morphis: aha, nice. well, not nice but progress. let me check | 13:49 |
| morphis | mvo: created a key with $ snap create-key which I know want to use to sign the model | 13:49 |
| morphis | mvo: yeah, one step forward | 13:49 |
| ogra_ | hmm, so updating to snapd 2.14.2 seems to have killed everything for me | 13:52 |
| ogra_ | error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused | 13:53 |
| ogra_ | ogra@styx:~$ snap --version | 13:53 |
| ogra_ | snap 2.14.2~16.04 | 13:53 |
| ogra_ | snapd unavailable | 13:53 |
| ogra_ | series - | 13:53 |
| ogra_ | ogra@styx:~$ | 13:53 |
| mvo | ogra_: anything in syslog? a crash or something? | 13:53 |
| ogra_ | thats after a simple apt install snapd | 13:53 |
| ogra_ | which got me upgraded | 13:53 |
| ogra_ | mvo, yeah http://paste.ubuntu.com/23150243/ .... seems it is very unhappy that i had an ubuntu-coore from edge running | 13:54 |
| mvo | ogra_: yes, that is tricky | 13:55 |
| gQuigs | what does, snapd.refresh.timer: Adding 53min 43.246331s random time." mean? | 14:11 |
| gQuigs | and could it be messing with the system time (machine ends up off by a lot) | 14:11 |
| zyga | gQuigs: I think it means that systemd added a randomized interval to the refresh timer | 14:12 |
| zyga | gQuigs: there's a bug open on this but it feels like systemd is just very talkative | 14:12 |
| gQuigs | well than that's not the cause, thanks zyga! | 14:13 |
| jdstrand | ogra_: you probably noticed I approved all the ubuntu-core snaps | 14:23 |
| ysionneau | can someone validate (manual review) my tfacedetect snap on Parrot private store please? It's for an emergency demo | 14:23 |
| ogra_ | jdstrand, ah, no i didnt ... did you approve more than 5 ? because we just did a test build to check if cprov's chaneg worked :P | 14:23 |
| ogra_ | *change | 14:24 |
| ysionneau | "parrot_store_demo" | 14:24 |
| jdstrand | ogra_: they were all from 4 hours or more ago. I think it was more than 5 | 14:24 |
| mup | PR snapd#1824 closed: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1824> | 14:24 |
| ogra_ | jdstrand, hmm, so the ones from 3min ago went through automatically then i guess ... great | 14:25 |
| ogra_ | *33min | 14:25 |
| ogra_ | well, let me just start another build ... it only takes 10-15 min | 14:26 |
| ogra_ | cprov, smells like it worked ... but to be sure i'll do another one :) | 14:26 |
| jdstrand | ogra_: https://myapps.developer.ubuntu.com/dev/click-apps/4142/rev/539/ had r739 of the tools and it passed | 14:26 |
| jdstrand | so, yeah, looks good | 14:26 |
| ysionneau | anyone with admin rights on the stores? | 14:27 |
| ogra_ | cprov, and thanks for the timeout fixes ... i can open the uploads overview again \o/ | 14:27 |
| * ogra_ wonders if the stats page also works | 14:27 | |
| ogra_ | ah, well, that still times out | 14:29 |
| morphis | pedronis: already back to work? :-) | 14:32 |
| ogra_ | run pedronis run ! | 14:32 |
| cprov | ogra_: stats page was not worked on yet, revision history and snap-release are quick enough now. | 14:37 |
| ogra_ | yeah, totally ... | 14:38 |
| morphis | mvo: already any idea what could be wrong? | 14:38 |
| ogra_ | thanks so much ! | 14:38 |
| mvo | morphis: sorry, not yet, could you pastebin yourjson? but it might be something for pedronis, he worked on this recently, we don't have a spread test unfortunately so it might simply be not fully working yet | 14:42 |
| morphis | ok | 14:42 |
| morphis | mvo: was just wondering as he gave me a tool to create a set of test keys and with that it works fine | 14:43 |
| morphis | so looks like something with the setup of create-key is wrong | 14:43 |
| morphis | mvo: https://paste.ubuntu.com/23150420/ | 14:46 |
| cjwatson | elopio: can you help me see why the autopkgtests in https://github.com/snapcore/snapcraft/pull/726 are failing? it sort of looks like they might be taking test dependencies from master rather than from the PR branch, but I could be wrong | 14:48 |
| mup | PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726> | 14:48 |
| cjwatson | (assuming you're the right person to ask, I'm not really sure) | 14:48 |
| kyrofa | cjwatson, you're correct, he's the person you want. He may not be in for a little bit yet, though | 14:49 |
| elopio | cjwatson: give me a few minutes | 15:02 |
| elopio | cjwatson: the jenkins job only sends adt-run to the testbed, and it takes care of the installation and dependencies. | 15:10 |
| cjwatson | I can't work out why snapd wouldn't be installed; it's listed in Depends in debian/tests/control | 15:10 |
| elopio | cjwatson: didn't you say that this depends on a feature that's not yet in xenial-updates? If so, we might need to install it before adt-run. | 15:11 |
| mup | PR snapd#1874 opened: snap: support assertion references in `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1874> | 15:11 |
| cjwatson | elopio: it's in xenial-updates as of yesterday | 15:11 |
| cjwatson | so I don't think that explains it | 15:11 |
| elopio | cjwatson: the error is not that snapd is not installed, it's unknown flag json. pexpect sucks when the output is too different from what you expect. | 15:12 |
| elopio | so, as far as I know, this machines should have -updates enabled. Let me check. | 15:12 |
| cjwatson | true; but there's no record of snapd being installed in the console log | 15:12 |
| cjwatson | oh, maybe it's preinstalled and I need to force the version? | 15:13 |
| cjwatson | that could make a certain amount of sense | 15:13 |
| elopio | that makes sense, true. | 15:13 |
| * cjwatson tries that | 15:14 | |
| cjwatson | autopkgtest snaps is I think definitely not my problem | 15:14 |
| elopio | but you have this line in tests/control: snapd (>= 2.14.2~) I thought that would make adt-run update the preinstalled one. | 15:15 |
| elopio | I'm checking if the demos work in master. | 15:17 |
| mup | Bug #1621525 opened: classic environment variables for daemon snaps <Snappy:New> <https://launchpad.net/bugs/1621525> | 15:27 |
| elopio | hah, I undersetand now, you have just added that. Too fast. | 15:27 |
| balloons | zyga, any news on when snap-confine 1.0.40 will hit xenial? | 15:30 |
| elopio | cjwatson: this https://github.com/snapcore/snapcraft/pull/778 and a change in a branch by sergiusens are required to get the snaps suite back to green. | 15:47 |
| mup | PR snapcraft#778: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778> | 15:47 |
| elopio | nothing to do with your change. | 15:47 |
| nacc | is there a direct link to the agreement that needs to be signed before uploading snaps? | 15:47 |
| mup | PR snapcraft#778 opened: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778> | 15:49 |
| cjwatson | elopio: glad to hear it - and indeed autopkgtest integration passes on my branch now | 15:56 |
| === chihchun is now known as chihchun_afk | ||
| elopio | cjwatson: \o/ thanks. sergiusens: so waiting for your review. | 15:58 |
| elopio | nacc: maybe nessita or noise][_` can help you there. | 15:58 |
| nacc | elopio: thanks! | 15:59 |
| cjwatson | nacc: https://myapps.developer.ubuntu.com/dev/tos/ | 16:00 |
| nacc | cjwatson: thanks! | 16:02 |
| cjwatson | nacc: or https://myapps.developer.ubuntu.com/dev/agreements/new/ if what you want is a link that will prompt for a signature if the developer hasn't already signed it rather than just the text (but it redirects to /dev/click-apps/ if they have) | 16:02 |
| nacc | cjwatson: got it, thanks! | 16:05 |
| ogra_ | booo ... | 16:05 |
| nacc | rharper: --^ does that help? :) | 16:05 |
| ogra_ | snapctl breaks autocompletion for the snapcraft command now :P | 16:06 |
| ogra_ | (well, doesnt break but if i need to type snapcr<tab> i can as well type the full thing) | 16:06 |
| kyrofa | ogra_, heh, sorry about that | 16:07 |
| kyrofa | ogra_, hopefully eventually we can move it into /usr/lib/snapd, but snap-confine doesn't currently support updating the PATH | 16:07 |
| ogra_ | ah, cool then | 16:07 |
| mup | PR snapcraft#779 opened: Do not compile pyc files when installing with pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/779> | 16:13 |
| rharper | nacc: thanks! | 16:17 |
| nacc | rharper: np | 16:19 |
| === JanC is now known as Guest38270 | ||
| === JanC_ is now known as JanC | ||
| SamYaple_ | sergiusens: adding in some python stuffs. Was the plan to unify the test suites as well? we are still duping alot between python2 and python3 in the test suites | 16:34 |
| SamYaple_ | sergiusens: my vote would be a new python test and then just test the python2 and python3 bits explicitly to maintain the backwards compat until fully deprecated | 16:34 |
| zyga | balloons: it almost has, we SRU'd most of the patches. my plan is to release .41 soon and SRU that | 16:40 |
| zyga | jdstrand: thanks for spotting another -1 :) | 16:42 |
| zyga | jdstrand: I'll fix that in a moment | 16:42 |
| jdstrand | :) | 16:43 |
| zyga | jdstrand: did you have a look at the real thing? | 16:43 |
| jdstrand | I'm going through the whole thing now | 16:43 |
| zyga | jdstrand: I"m somewhat worried about the cgroup there, feels like we should think how shared mnt namespace + cgroup interact | 16:43 |
| zyga | thanks! I just returned and I'm available | 16:43 |
| * zyga finally emerged haskell toolchain on gentoo, geez that took forever | 16:44 | |
| balloons | zyga, I ask because the issue with juju snap and lxd isn't fixed in the SRU'd patches | 16:51 |
| balloons | so any ETA? Will it be there before next week? Possible? | 16:51 |
| zyga | balloons: can you point me to those issues? | 16:51 |
| balloons | zyga, https://bugs.launchpad.net/snap-confine/+bug/1613845 | 16:52 |
| mup | Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Released by zyga> <https://launchpad.net/bugs/1613845> | 16:52 |
| mup | Bug #1621550 opened: Snappy should detect when running in KVM, specify correct ssh connection line <Snappy:New> <https://launchpad.net/bugs/1621550> | 16:52 |
| zyga | balloons: lxd has a quirk that owrks in devmode | 16:52 |
| zyga | balloons: right, that might not be SRUd | 16:52 |
| balloons | zyga, it's not. But 1.0.40 does solve it | 16:52 |
| zyga | balloons: because we were working on SRUing higher priority tasks | 16:52 |
| balloons | jcastro, ^^ | 16:52 |
| popey | can someone please help with this:- http://paste.ubuntu.com/23150846/ - login there and yaml - the command never runs, seems to barf at the wrapper | 16:54 |
| popey | suggestions welcome | 16:54 |
| balloons | zyga, the charmers summit is next week, and we'd love to highlight using snaps to get juju, but this breaks the story. That's why I was asking | 16:54 |
| popey | (it is a very simple yaml) | 16:54 |
| zyga | balloons: let me check the SRU queue | 16:54 |
| zyga | looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html I see snap-confine but (I'm not super familiar with the report) I don't think it is currently in flight | 16:55 |
| balloons | zyga, https://launchpad.net/ubuntu/+source/snap-confine/1.0.38-0ubuntu0.16.04.10 doesn't have it, which was in proposed | 16:56 |
| zyga | balloons: if you can help with the SRU I'd love to do it | 16:57 |
| zyga | balloons: I cannot dput though (I'm not a core dev) | 16:57 |
| balloons | zyga, ahh. But it would just need sponsered is all | 16:58 |
| zyga | balloons: but I can try to work on the paperwork when it is avaialble | 16:58 |
| zyga | balloons: does it have to be in yakkety fifst? | 16:58 |
| balloons | zyga, is there a reason you would pursue cherrypicking, rather than just sru 1.0.40 that is already in yakkety? | 16:58 |
| zyga | first? | 16:58 |
| zyga | balloons: that's what we did before becasue we couldn't get an effective SRU for many weeks | 16:59 |
| mhall119 | sergiusens: has there ever been a discussion about having an "exec" plugin that would let you run some script or binary at build-time in snapcraft? | 16:59 |
| balloons | zyga, as 1.0.40 is in yakkety, it should just be a matter of uploading it to the xenial queue and asking for an SRU | 16:59 |
| zyga | balloons: so we tried to SRU the essential thing each time so that nothingh would regress and we would not risk any daly | 16:59 |
| zyga | balloons: can you do that? | 16:59 |
| * zyga should apply for per-package upload rights | 17:00 | |
| balloons | yes, you should :-) | 17:00 |
| balloons | I cannot upload, but we can get someone to sponsor | 17:00 |
| zyga | slangasek: could you perhaps sponsor snap-confine from yakkety into xenial-proposed so that we can work on an SRU | 17:01 |
| slangasek | zyga: "so you can work on an SRU" - what do you mean by that? isn't the work of an SRU the preparation of the SRU bug and the preparation of the upload? | 17:07 |
| zyga | slangasek: we just need to get the upload in the queue so that I can work on the paperwork | 17:08 |
| zyga | slangasek: I'd like to do the full process once but I cannot upload | 17:08 |
| zyga | jdstrand: thank you for the review, I'll fix the trivials and work on statfs change | 17:12 |
| nacc | zyga: you can do the SRU paperwork (by which do you mean the bug update?) without the upload being in the queue | 17:16 |
| zyga | nacc: ah, I see, so I should file the bug, document everything (delta from the desired version and proposed)? | 17:18 |
| slangasek | zyga: you should absolutely file the bug first, the bug has to be referenced in the changelog of the SRU | 17:19 |
| sergiusens | mhall119 yes there has, https://github.com/snapcore/snapcraft/pull/727, the general consensus is it wouldn't be in core | 17:19 |
| mup | PR snapcraft#727: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <Conflict> <https://github.com/snapcore/snapcraft/pull/727> | 17:19 |
| zyga | slangasek: understood | 17:20 |
| sergiusens | SamYaple_ yeah, unifying the tests would be good | 17:20 |
| nacc | zyga: yeah, that's my usual approach, get the bug filed first, prep per the template, then subscribe sponsors, etc. | 17:20 |
| mhall119 | thanks sergiusens, I assumed it would have come up before | 17:26 |
| sergiusens | mhall119 that is not the first one, but we kept it open to not repeat ourselves all the time ;-) | 17:28 |
| jdstrand | zyga: thanks for all the changes! I thought your comment changes were great | 17:32 |
| zyga | jdstrand: I'm not sure about this typo; can you please show me where it is? https://github.com/snapcore/snap-confine/pull/126#discussion_r78042899 | 17:37 |
| mup | PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126> | 17:37 |
| mup | Bug #1621568 opened: Unable to access system fonts <Snappy:New> <https://launchpad.net/bugs/1621568> | 17:44 |
| jdstrand | zyga: you have populate*d* | 17:44 |
| jdstrand | zyga: oh wait. you added sc_should_populate_ns_group. please disregard | 17:46 |
| zyga | jdstrand: ah, sorry, yes there was a discrepancy in that function name for a moment | 17:52 |
| zyga | jdstrand: thanks! | 17:52 |
| * zyga learned a lot of cool things while working on snap-confine and its test suite | 17:53 | |
| balloons | zyga, are you all set for the SRU then? It should be a matter of filing the bug, and preparing a source branch to hand off | 17:53 |
| zyga | balloons: filing the bug, yes, preparing source branch, not sure what that entails yet | 17:53 |
| balloons | zyga, it shows you as the creator of 1.0.40 on yakkety -- what branch did you use? | 17:53 |
| zyga | balloons: git.launchpad.net/snap-confine AFAIK | 17:54 |
| zyga | balloons: there's a git repo there with packaging for all ubuntu releases | 17:55 |
| zyga | balloons: this is modeled after fedora's fantastic fedpkg workflow but all it is is the debian directory in a git tree | 17:55 |
| balloons | zyga, did mvo do all the archive work then? I see you as the package uploader | 17:55 |
| zyga | balloons: perhaps, I don't quite know, I did send a source package to him a while ago | 17:56 |
| zyga | balloons: I think it may have been uploaded through debian | 17:56 |
| zyga | balloons: but my memory is very rusty there | 17:56 |
| * zyga promises to work with mwhudson on collab-maint for snap-confine now | 17:56 | |
| balloons | zyga, I suppose to be fair since the yakkety build works as-is on xenial you could reuse the source package | 17:57 |
| balloons | have you filed an SRU before? | 17:58 |
| zyga | balloons: I was working on kernel SRUs in the cert team but I didn't really do an SRU for other things entirly by myself I think | 17:58 |
| zyga | perhaps eons ago for pyotherside | 17:58 |
| balloons | zyga, file a bug like this: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1593396 | 18:00 |
| mup | Bug #1593396: [SRU] 1.0.38-0ubuntu0.16.04.4 <snap-desktop-issue> <verification-needed> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1593396> | 18:00 |
| balloons | zyga, the full procedure and template is here: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure | 18:01 |
| * zyga nods | 18:05 | |
| zyga | I'll look at that first thing tomorrow | 18:05 |
| mup | Bug #1621575 opened: Poorly worded error when installing a local snap without assertions <Snappy:New> <https://launchpad.net/bugs/1621575> | 18:11 |
| mup | Bug #1619718 changed: ubuntu-image created vfat eats itself after a while (mcopy creates wrong subdirs) <verification-needed> <Snappy:Fix Released> <Ubuntu Image:Invalid> <mtools (Ubuntu):Fix Released by vorlon> <ubuntu-image (Ubuntu):Fix Released> <mtools (Ubuntu Xenial):Fix Committed by vorlon> | 18:17 |
| mup | <ubuntu-image (Ubuntu Xenial):Invalid> <https://launchpad.net/bugs/1619718> | 18:17 |
| zyga | jdstrand: does this look good? https://github.com/snapcore/snap-confine/pull/126/commits/40a93a241b1fbfc34c6eb6b9e87f951b218ee1c7 | 18:22 |
| mup | PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126> | 18:22 |
| zyga | jdstrand: all I have to fix left is rm_rf sanity checks | 18:23 |
| zyga | jdstrand: I'd like to merge this and then propose the branch that makes snap-confine use things :) | 18:23 |
| mup | PR snapcraft#780 opened: Organize without removing files on target <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/780> | 18:26 |
| Pharaoh_Atem | zyga: whoa, you're following dist-git style for snap-confine ubuntu packaging? | 18:32 |
| zyga | Pharaoh_Atem: so far :) It's not fully live yet because of lots of things that we had to do ASAP but I was wondering how to use that for packaging more reliably | 18:33 |
| zyga | Pharaoh_Atem: (in debian and ubuntu) | 18:33 |
| zyga | Pharaoh_Atem: if you want to know what I'm up to lately look at the pull request referenced above, it's pretty neat stuff :) | 18:38 |
| elopio | sergiusens: back to green: https://github.com/snapcore/snapcraft/pull/778 | 18:38 |
| mup | PR snapcraft#778: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778> | 18:38 |
| Pharaoh_Atem | zyga: well, I'd definitely be happy to see ubuntu adopt a dist-git style system | 18:40 |
| Pharaoh_Atem | makes it much easier to figure out what's going on :) | 18:40 |
| zyga | well, not ubuntu, it's just me trying but I think I'll stick to it if I can :) | 18:41 |
| zyga | Pharaoh_Atem: snapd-xdg-open was released upstream AFAIK, I'll look at updating my spec files and I think it should be good to go | 18:42 |
| Pharaoh_Atem | did you get around to snapd-glib too? | 18:42 |
| zyga | Pharaoh_Atem: I have what I did before, without the correct package split, if you want I can show you what I got | 18:42 |
| zyga | Pharaoh_Atem: (so no -devel and stuff) | 18:42 |
| Pharaoh_Atem | sure | 18:42 |
| zyga | Pharaoh_Atem: one moment, I ran out of ram with gentoo emering webkit lately so I had to shut everything but gentoo down | 18:43 |
| mup | PR snapcraft#778 closed: Use --force-dangerous when testing the installation of snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/778> | 18:44 |
| kgunn | yo, has anyone ever run into missing socket?...like so... | 18:52 |
| kgunn | kg@kg-MacBookPro:~$ snap list | 18:52 |
| kgunn | error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd-snap.socket: connect: no such file or directory | 18:52 |
| kyrofa | kgunn, are you up-to-date? | 18:53 |
| kgunn | kyrofa: updated 2 days back | 18:54 |
| kgunn | kyrofa: i'm on xenial + stable-phone-overlay enabled | 18:54 |
| kyrofa | kgunn, core snap is up to date as well? | 18:54 |
| kgunn | full disclosure :) | 18:54 |
| kyrofa | kgunn, heh, I always assume you're using that | 18:54 |
| kgunn | kyrofa: let me update real quick | 18:55 |
| kyrofa | kgunn, yeah, make sure. That was an issue last week, but it should be fixed by now | 18:55 |
| zyga | re | 18:59 |
| zyga | Pharaoh_Atem: ok, I got my fedora up | 18:59 |
| zyga | Pharaoh_Atem: http://paste.ubuntu.com/23151324/ | 19:02 |
| zyga | Pharaoh_Atem: (that's not much :) | 19:02 |
| Pharaoh_Atem | it's a good start, at least | 19:03 |
| zyga | Pharaoh_Atem: that's 0.8, 0.10 was released with some fixes (license is one of them) | 19:03 |
| * zyga looks at refreshing that | 19:03 | |
| Pharaoh_Atem | I'm impressed that you're using the common name provides | 19:03 |
| Pharaoh_Atem | it'll enable you to reuse the spec for openSUSE relatively easily | 19:03 |
| zyga | I love them because they speak in the language of the problem | 19:04 |
| zyga | the upstream pkg-confing names | 19:04 |
| zyga | pkg-config* | 19:04 |
| Pharaoh_Atem | the whole reason these things exist is because it's a way for us to guarantee a resource, be it a build dep or a runtime dep | 19:05 |
| Pharaoh_Atem | regardless of packaging style | 19:05 |
| zyga | some of the build-deps there aren't perfect, I don't quite know how vala tooling looks like today and the set I have there is what seems to work but I suspect a smaller set is sufficient | 19:06 |
| Pharaoh_Atem | I usually use the build system as a reference to figure out build deps | 19:06 |
| mup | PR snapd#1815 closed: interfaces: auto-connect interface required by livepatch <Created by arges> <Closed by arges> <https://github.com/snapcore/snapd/pull/1815> | 19:07 |
| kgunn | kyrofa: just sharing, fwiw, not sure how it got goofed...but apt-get install --reinstall snapd, then systemctl start snapd did the trick | 19:07 |
| Pharaoh_Atem | oh good, you are moving from com.canonical.* to io.snapcraft.* | 19:07 |
| kyrofa | kgunn, huh, yeah odd | 19:07 |
| Pharaoh_Atem | I was hoping that would happen | 19:07 |
| zyga | just a little more and I'll have updates for 0.14 | 19:09 |
| Pharaoh_Atem | have you at least tested my selinux policy module for snapd on f24? | 19:11 |
| zyga | Pharaoh_Atem: http://paste.ubuntu.com/23151347/ | 19:12 |
| zyga | Pharaoh_Atem: no, not yet, I really have to finish snap-confine features first | 19:12 |
| zyga | Pharaoh_Atem: I did some work on gentoo but not much either | 19:12 |
| zyga | Pharaoh_Atem: I want to get gentoo overlay up-to-date which is easy, just takes NaN minutes to build | 19:13 |
| zyga | Pharaoh_Atem: I did read your code though | 19:13 |
| zyga | Pharaoh_Atem: it's just that I'm still super-green with selinux in practice, I would not be able to write that my self yet | 19:13 |
| zyga | Pharaoh_Atem: I pushed the partial packaging to my snapcore-fredora repo, I'll look at the proper splitting policy down the week | 19:16 |
| jdstrand | zyga: sorry was in a meeting and had some followups. looking | 19:36 |
| mup | PR snapd#1866 closed: many: add snap configuration to REST API <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1866> | 19:36 |
| zyga | jdstrand: no worries, thanks! | 19:39 |
| zyga | jdstrand: I added a sanity test to ensure my reasoning on nsfs is accurate: https://github.com/snapcore/snap-confine/pull/126/commits/db1a0765f6b058ab24df30931c2f357b57f243f2 | 19:53 |
| mup | PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126> | 19:53 |
| mup | PR snapcraft#726 closed: Implement basic form of `snapcraft register-key` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/726> | 19:56 |
| mup | PR snapcraft#776 closed: Updated the contents of the snapcraft init template <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/776> | 20:02 |
| sergiusens | SamYaple_ still around? | 20:03 |
| sergiusens | SamYaple_ asked a question in snapcraft#779 ; last time they went unnoticed so making sure this one doesn't :-) | 20:03 |
| mup | PR snapcraft#779: Do not compile pyc files when installing with pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/779> | 20:03 |
| jdstrand | zyga: nice | 20:04 |
| zyga | jdstrand: :) I'll fix rm_rf and merge | 20:06 |
| zyga | jdstrand: I'll double check I didn't miss anything | 20:07 |
| SamYaple_ | sergiusens: looking | 20:07 |
| SamYaple_ | sergiusens: i noticed there were still some pyc files, but not all of them. im still not sure why. the fact remains there were less and it did shave of build time | 20:09 |
| SamYaple_ | sergiusens: oh you know what i just had a thought. I wonder if some of the pyc files are getting created when other python packages are getting installed, something importing other python packages on install or somehting | 20:10 |
| jdstrand | zyga: hey, while you are in there, I noticed that snap-confine needs this when running over ssh: /dev/pts/[0-9]* rw, | 20:12 |
| jdstrand | apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" name="/dev/pts/2" pid=28375 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000 | 20:13 |
| jdstrand | zyga: I noticed this ssh'ing into a xenial classic system and using 'hello-world' | 20:13 |
| jdstrand | zyga: I can do a PR if it is easier | 20:14 |
| jdstrand | zyga: hoping you are EOD. I'll do a PR | 20:26 |
| jdstrand | zyga: fyi, https://github.com/snapcore/snap-confine/pull/128 | 20:31 |
| mup | PR snap-confine#128: allow read/write to /dev/pts/[0-9]* needed for running snaps under ssh <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/128> | 20:31 |
| sergiusens | SamYaple_ that might be it | 20:35 |
| zyga | jdstrand: hmm, curious why is that? | 20:37 |
| zyga | jdstrand: I work over ssh all day | 20:37 |
| zyga | jdstrand: and I didn't need it | 20:37 |
| sergiusens | SamYaple_ setup the env with https://docs.python.org/3/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE | 20:37 |
| sergiusens | SamYaple_ maybe even in `env` so we don't get warnings when running from the snap even | 20:38 |
| zyga | jdstrand: could it be ssh + screen or something like that? | 20:40 |
| zyga | jdstrand: (the hint there is "file_inherit" btw) | 20:40 |
| jdstrand | zyga: I suspect it has something to do with it being a classic system. I didn't dive into why. I'm not doing anything special | 20:41 |
| * jdstrand nods | 20:41 | |
| jdstrand | I'm not using screen | 20:41 |
| jdstrand | oh I know | 20:41 |
| jdstrand | it is cause I am using pam-apparmor on that box | 20:41 |
| jdstrand | sshd is confined | 20:42 |
| mup | PR snapcraft#780 closed: Organize without removing files on target <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/780> | 20:42 |
| jdstrand | zyga: ^ | 20:42 |
| zyga | ah, interesting | 20:42 |
| * zyga investigates pam-apparmor | 20:42 | |
| jdstrand | zyga: The inherited fd is mediated since it isn't coming from an unconfined process. | 20:43 |
| jdstrand | that's why | 20:43 |
| jdstrand | so, nothing to do with classic per se | 20:44 |
| * jdstrand modifies the comment | 20:44 | |
| zyga | jdstrand: ah, now I understand | 20:45 |
| zyga | jdstrand: thanks for researching this, I'd like to have a bug for tracking this so that the release can refer to it | 20:45 |
| zyga | jdstrand: I can file one if you wnat | 20:45 |
| jdstrand | I can do it | 20:46 |
| zyga | jdstrand: thanks, please use Fixes: ... in the commit and I'll happily merge it | 20:46 |
| zyga | jdstrand: I can smell 1.0.41 coming out soon :) | 20:46 |
| jdstrand | zyga: does Fixes need to be in the first line or the nody? | 20:46 |
| jdstrand | body* | 20:46 |
| zyga | jdstrand: like signed-off-by | 20:46 |
| mup | PR snapd#1875 opened: Add /dev/net/tun device to network-control apparmor rules <Created by cmars> <https://github.com/snapcore/snapd/pull/1875> | 20:46 |
| zyga | jdstrand: I just use it for easy linking | 20:47 |
| zyga | jdstrand: it's not a standard of any kind I think | 20:47 |
| zyga | (works nicely for x-ref between github and launchpad | 20:47 |
| mup | Bug #1621623 opened: OpenVPN needs access to /dev/net/tun, proposal to add it to network-control interface <Snappy:New> <https://launchpad.net/bugs/1621623> | 20:48 |
| mup | PR snapd#1876 opened: cmd/snap: make "snap find" error nicer <Created by chipaca> <https://github.com/snapcore/snapd/pull/1876> | 20:48 |
| jdstrand | zyga: ok, done | 20:56 |
| zyga | jdstrand: merged | 21:01 |
| jdstrand | thanks! | 21:01 |
| mup | PR snapcraft#773 closed: parser - Handle project name and version variables <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/773> | 21:06 |
| mup | PR snapcraft#781 opened: Workaround bzr with auth proxies <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/781> | 21:12 |
| sergiusens | ogra_ please try that ^ | 21:12 |
| mhall119 | zyga: does /opt/ inside a snap map to the system's /opt/ or is it owned by the snap? | 21:27 |
| kyrofa | mhall119, probably the core snap | 21:37 |
| mhall119 | kyrofa: is there any pre-determined path that equates to ${SNAP}? | 21:42 |
| kyrofa | mhall119, no, though I've used the /snap/snapname/current symlink before | 21:42 |
| mhall119 | ok, I'll go with that then | 21:43 |
| kyrofa | mhall119, beware that isn't standardized across distros | 21:44 |
| kyrofa | I believe it's in a different place in fedora, for instance | 21:44 |
| mhall119 | kyrofa: not from the snap's perspective, zyga says the snap will see /snap/ no matter where it's actually located on the host | 21:44 |
| kyrofa | Hmm... okay | 21:45 |
| mup | PR snapd#1877 opened: many: maintain all snap configurations in state <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1877> | 22:02 |
| elopio | sergiusens: if I have a tar file, but the source is in a subdirectory, I should use source-subdir, right? | 22:25 |
| elopio | I'm having a problem trying to build erlang. The subdir contents are copied to build, but then it tries to compile from build/subdir. | 22:26 |
| elopio | nevermind, sergiusens unping. The problem is that bootstrap exists, but it's a directory. | 22:41 |
| * Son_Goku sighs | 22:45 | |
| Son_Goku | zyga, ping | 22:45 |
| ogra_ | sergiusens neat !!! will try tomorrow | 22:59 |
| qengho | How is one supposed to use $SNAP_USER_COMMON ? | 23:13 |
| qengho | When my app starts, that directory doesn't exist. And I don't have permission to mkdir it, it seems. "mkdir: cannot create directory '/home/username/snap/snapname/common': Permission denied" | 23:15 |
| qengho | snapd v 2.14.1+16.10 | 23:16 |
| qengho | Maybe this next version of snapd .... | 23:17 |
| mup | PR snapcraft#782 opened: Fix gulp plugin's npm install prefix <Created by AlexandreAbreu> <https://github.com/snapcore/snapcraft/pull/782> | 23:21 |
| mup | Bug #1621324 opened: On the all-snaps image, snappy-debug.security can't access syslog <Snappy:Confirmed> <livecd-rootfs (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621324> | 23:22 |
| mup | Bug #1609965 changed: snapweb store is a blank page <Snappy:Fix Released> <snapweb:Fix Released> <https://launchpad.net/bugs/1609965> | 23:31 |
| mup | Bug #1621666 opened: It is possible to install the classic snap in a classic system <classic> <Snappy:New> <https://launchpad.net/bugs/1621666> | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!