| === chihchun is now known as chihchun_afk | ||
| === wolflarson_ is now known as wolflarson | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#948 opened: Use testtools as the base of all unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/948> | 04:32 |
|---|---|---|
| === pbek_ is now known as pbek | ||
| === stub` is now known as stub | ||
| === Guest32050 is now known as macnibblet | ||
| === macnibblet is now known as mac_nibblet | ||
| mac_nibblet | Can someone please explain the workflow when developing stuff with snapcraft ? | 06:06 |
| mac_nibblet | I find it rather tedious to run a clean, download everything again and then install just to test changes to our application | 06:06 |
| === JanC_ is now known as JanC | ||
| mac_nibblet | Anybody up for some paid support | 06:21 |
| mac_nibblet | ? | 06:21 |
| Omou | ? | 07:10 |
| Omou | is here somebody | 07:10 |
| === Guest64506 is now known as ahasenack | ||
| === ahasenack is now known as Guest79511 | ||
| === rgogunskiy_ is now known as rgogunskiy | ||
| mup | PR snapd#2401 closed: snap: abort install with ctrl+c <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2401> | 08:29 |
| ogra_ | mvo, hmm, there was just a new set of kernels released | 09:44 |
| zyga | ogra_: hey :) | 09:45 |
| ogra_ | yo | 09:45 |
| mvo | ogra_: cool, did the new lp script tell you? or some other way? | 09:45 |
| ogra_ | mvo, my mail client did :P | 09:45 |
| mvo | ogra_: new -update? if so, I think we want that in beta and then candidate | 09:45 |
| mvo | ogra_: heh | 09:45 |
| ogra_ | ok, i'll take care | 09:46 |
| mvo | ta | 09:49 |
| mup | PR snapd#2412 opened: snap: add description to `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2412> | 09:51 |
| mup | PR snapd#2413 opened: interfaces/apparmor: allow access to core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2413> | 10:03 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | mvo, all kernels in beta, do we have any specific criteria before releasing to candidate atm ? | 10:59 |
| ogra_ | (the store is so sloooow) | 10:59 |
| mvo | ogra_: a smoke test for now, I think we want something better long term but for now booting all supported boards with the new kernel is the sufficient | 11:00 |
| ogra_ | ok | 11:00 |
| mup | PR snapd#2414 opened: store: switch default delta format from xdelta to xdelta3 <Created by wgrant> <https://github.com/snapcore/snapd/pull/2414> | 11:08 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/2413 | 11:25 |
| mup | PR snapd#2413: interfaces/apparmor: allow access to core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2413> | 11:25 |
| mup | PR snapd#2415 opened: overlord/ifacestate: no interface checks if no snap id <Created by chipaca> <https://github.com/snapcore/snapd/pull/2415> | 11:32 |
| zyga | jdstrand: ^^ | 11:34 |
| mup | PR snapd#2406 closed: many: add support for classic confinement <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2406> | 11:37 |
| mup | PR snapd#2416 opened: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416> | 11:52 |
| liuxg | ogra_, ping | 12:14 |
| ogra_ | yo | 12:14 |
| liuxg | ogra_, I just followed your suggestion to extract the arm64 file at http://cdimage.ubuntu.com/ubuntu-base/xenial/daily/current/, I unziped the file, and now when I use "sudo chroot rootfsarm64". it gives me an error like http://paste.ubuntu.com/23588275/ | 12:15 |
| liuxg | ogra_, what could be the problem for it? thanks | 12:15 |
| ogra_ | liuxg, did you copy the qemu-$arch-static binary in place ? | 12:16 |
| liuxg | ogra_, yeah, I just realized that. thanks for your reminding :) | 12:16 |
| ogra_ | this isnt different from using debootstrap ;) | 12:16 |
| ogra_ | (just that you save all the deb unpacking and configuring time) | 12:16 |
| liuxg | ogra_, yes, it works now. thanks. I will try to explore it and see how it works :) | 12:17 |
| ogra_ | :) | 12:17 |
| mup | PR snapd#2417 opened: Add uhid interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2417> | 12:17 |
| liuxg | ogra_, after I enter the chroot, some things are not there. for example, vi is not in the package. I need to install more things | 12:33 |
| mup | PR snapcraft#931 closed: parser: add support for origin-{branch,commit,tag} <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/931> | 12:35 |
| mup | PR snapcraft#946 closed: meta: support classic confinment <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/946> | 12:35 |
| ogra_ | liuxg, hmm, vi should definitely be in there, thats weird | 12:37 |
| ogra_ | oh, no, it shouldnt, since thats a buildd tarball | 12:38 |
| liuxg | ogra_, http://paste.ubuntu.com/23588349/, this is what looks like here. | 12:38 |
| ogra_ | yeah | 12:38 |
| ogra_ | it is what you would get using debootstrap --minbase | 12:38 |
| ogra_ | a typical build chroot | 12:38 |
| Chipaca | didrocks, could you strace the 'plain' schmurl? | 12:39 |
| Chipaca | didrocks, (hello! etc :-/) | 12:39 |
| liuxg | ogra_, also I got some installation issues like http://paste.ubuntu.com/23588353/. it looks not so predicable :) | 12:39 |
| didrocks | Chipaca: hey! sure, do we have a snap ready with it? I think I will just copy the armhf binary there if not | 12:40 |
| Chipaca | didrocks, i've always just copied the binary | 12:40 |
| didrocks | ok! | 12:40 |
| didrocks | you want a full strace, no option? | 12:40 |
| ogra_ | liuxg, did you "apt update" first (thats not different to how you should do debootstrap) | 12:40 |
| liuxg | ogra_, yes, I did that in the first place | 12:41 |
| Chipaca | didrocks, -f -s 4096, i think | 12:41 |
| ogra_ | weird | 12:41 |
| mup | PR snapd#2418 opened: snapstate/backend: add backend methods to manage aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2418> | 12:41 |
| didrocks | Chipaca: will give it to you in a few minutes | 12:42 |
| ogra_ | (given that all our build machines use these tarballs ...) | 12:42 |
| Chipaca | didrocks, perfect | 12:42 |
| liuxg | ogra_, yeah, it looks like it is not so doable in this method. :) | 12:42 |
| ogra_ | well, looks like not all components are switched on in sources.list (perhaps only main ?) | 12:43 |
| ogra_ | it is definitely the cleaner way ... but if it starts getting to complex to explain in the howto better go with debootstrap | 12:43 |
| liuxg | ogra_, if I try to use apt-get -f install, I get http://paste.ubuntu.com/23588370/. yeah, I think you have a point. A lot of things are commented out there. | 12:44 |
| liuxg | ogra_, in fact, the installation is very straightforward, just extract it, and that's it. could it be that it is not daily build? | 12:45 |
| ogra_ | oh, you need to mount /sys and /proc (and if you feel like also devpts), but thats not different with the debootstrap chroot | 12:45 |
| ogra_ | without these dirs mounted any chroot will have issues | 12:46 |
| ogra_ | (regarding package installs at least) | 12:46 |
| ogra_ | the "current" tarballs are definitely from tonight | 12:46 |
| didrocks | Chipaca: here we go: http://paste.ubuntu.com/23588377/ | 12:46 |
| Chipaca | ah | 12:47 |
| popey | sergiusens: bug 1612818 - Is there any plan to up the priority of this from wishlist? | 12:47 |
| mup | Bug #1612818: Ruby breaks when snapped <isv> <new-plugin> <Snapcraft:Triaged> <https://launchpad.net/bugs/1612818> | 12:47 |
| Chipaca | didrocks, could you do it again, but this time redirecting stdout? | 12:47 |
| didrocks | Chipaca: sure | 12:48 |
| Chipaca | didrocks, so i don't need to wade through the pretty progress bar thing :-) | 12:48 |
| popey | sergiusens: we have software we've rejected snapping because of the lack of ruby plugin) | 12:48 |
| * Chipaca lazy | 12:48 | |
| liuxg | ogra_, yeah, I think it is better go with the debootstrap solution :) | 12:48 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | liuxg, wqell, 80% of the above needs to be solved there too ... you always need to mount /proc and /sys if you enter a chroot (and unmount it when you leave) etc ... but yeah, missing bits in sources.list is indeed bad | 12:49 |
| didrocks | Chipaca: wait, I didn't take it in the first place to the logs so that you are not bothered with it | 12:49 |
| didrocks | Chipaca: so, you meant, you want me to redirect stdout to /dev/null so that you don't have the write()/ioctl? | 12:49 |
| Chipaca | didrocks, the progress bar addds ioctl()s and weird prints to the log | 12:49 |
| Chipaca | exactly | 12:49 |
| didrocks | yeah, you detect the output type and disable it | 12:50 |
| didrocks | got it :) | 12:50 |
| Chipaca | as all progress bars should :-D | 12:50 |
| didrocks | Chipaca: don't force me to give some examples of python modules I know of :) | 12:50 |
| Chipaca | didrocks, there's a reason i wrote this progress bar myself :-) | 12:51 |
| didrocks | Chipaca: btw, what's the name of the go progressbar project you are using? I'm interesting for some personal projects :) | 12:51 |
| didrocks | ah, it's yours ;) | 12:51 |
| Chipaca | didrocks, i think next weekend i'll be publishing it | 12:51 |
| Chipaca | it's not "there" yet | 12:51 |
| didrocks | great! keep me posted | 12:52 |
| didrocks | Chipaca: http://paste.ubuntu.com/23588390/ | 12:52 |
| didrocks | (file is a little bit bigger as the download went further down) | 12:52 |
| liuxg | ogra_, anyway, thanks for your tips :) | 12:54 |
| Chipaca | didrocks, and i have a bug in progress where it's still doing ioctls :-) darnit | 12:54 |
| ogra_ | np, sad it doesnt work out for you | 12:54 |
| Chipaca | didrocks, anyway, thank you; this is what i needed | 12:54 |
| liuxg | ogra_, anyway, I still learn a lot out of it :) | 12:55 |
| didrocks | Chipaca: yeah, I noticed it ;) at least, you don't have the write() | 12:55 |
| * Chipaca nods | 12:56 | |
| ogra_ | :) | 12:56 |
| Chipaca | didrocks, it's just checking whether the fd suddenly became a terminal, by magic | 12:56 |
| Chipaca | didrocks, it should do that check once at the start methinks -- unless file descriptors can suddenly become terminals :-) | 12:56 |
| didrocks | "suddenly" :-) | 12:56 |
| didrocks | yeah, only once will make sense :) | 12:57 |
| ogra_ | everything is a file ! | 12:57 |
| Chipaca | didrocks, could you also strace curl? | 12:59 |
| didrocks | yep, doing | 12:59 |
| didrocks | Chipaca: hum, logs are 50M | 13:03 |
| Chipaca | hehe | 13:03 |
| Chipaca | didrocks, gzip it and put it on p.c.c? | 13:04 |
| didrocks | Chipaca: yep, ofc, you have the 30M snap in it :) | 13:04 |
| didrocks | with the write() ops | 13:04 |
| sergiusens | popey well we need someone who knows ruby, lately all the plugins have been externally contributed except for the python a go ones which I've catered for; also wishlist is the status only because it is not a bug, it is a feature request | 13:05 |
| Chipaca | didrocks, ah, you can drop the -s option there if you want | 13:06 |
| Chipaca | didrocks, :-/ | 13:06 |
| popey | sergiusens: so we basically need someone who knows python + ruby? | 13:06 |
| didrocks | Chipaca: ok, doing, will be easier for you to read | 13:06 |
| sergiusens | popey if we can get someone that knows ruby I can work on the plugin code itself | 13:06 |
| popey | ok | 13:07 |
| didrocks | Chipaca: less than 2 Megs: http://paste.ubuntu.com/23588441/ | 13:08 |
| mup | PR snapcraft#949 opened: project: support building classic snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/949> | 13:14 |
| === hikiko is now known as hikiko|ln | ||
| renato__ | mvo, hey, could you review the pending reviews for package: 6453 | 13:18 |
| kalikiana_ | snapd master seems to be aborting instantly on startup for me - could there be a regression? Or something changed that'd require updating something else? | 13:20 |
| zyga | kalikiana_: can you share any error messages or logs please? | 13:23 |
| kalikiana_ | zyga: None, except for "Terminated" as far as I can see | 13:23 |
| zyga | kalikiana_: anything in journalctl -u snapd | 13:23 |
| kalikiana_ | -- No entries -- | 13:24 |
| kalikiana_ | Non-snapd entries are there for failing to connect to snapd | 13:25 |
| kalikiana_ | (Because it's not running, obviously) | 13:25 |
| kalikiana_ | zyga: ^^ | 13:26 |
| zyga | interesting and odd | 13:26 |
| kalikiana_ | I tried going back some revisions but even a half month makes no difference | 13:27 |
| kalikiana_ | So I suspect something in the system other than snapd changed | 13:27 |
| kalikiana_ | zyga: There was a dependency change that required "go get" at one point, any idea if that might be related? | 13:29 |
| kalikiana_ | It's the only change I'm aware of | 13:29 |
| kalikiana_ | Other than whatever might've changed in an update of the base system | 13:30 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | didrocks, in the curl strace with the big -s, could you grep for HTTP/ (including the /) please? | 13:40 |
| === hikiko|ln is now known as hikiko | ||
| didrocks | Chipaca: no result | 13:41 |
| jdstrand | zyga: I don't really understand the motivation for 2413 | 13:41 |
| Chipaca | didrocks, are you sure that's in the big trace? | 13:41 |
| Chipaca | didrocks, ah, case-insensitively please | 13:41 |
| jdstrand | zyga: basically, we have the default template that allows certain reads, and this rule that allows reading everything | 13:42 |
| didrocks | Chipaca: ah, case-insensitivity returns 2 results: | 13:42 |
| didrocks | send(4, | 13:42 |
| didrocks | "\26\3\1\1\21\1\0\1\r\3\3XF\277\341\302\237M\257\205\355\207\344\36\372i\307\21\250\350d\246\257\357\307\17oxUl\303\324m\0\0l\300+\300,\300\206\300\207\300\t\300#\300\n\300$\300r\300s\300\254\300\255\300\10\300/\3000\300\212\300\213\300\23\300'\300\24\300(\300v\300w\300\22\0\234\0\235\300z\300{\0/\0<\0005\0=\0A\0\272\0\204\0\300\300\234\300\235\0\n\0\236\0\237\300|\300}\0003\0g\0009\0k\0E\0\276\0\210\0\304\30 | 13:42 |
| didrocks | 0\236\300\237\0\26\1\0\0x\0\27\0\0\0\26\0\0\0\5\0\5\1\0\0\0\0\0\0\0\33\0\31\0\0\26public.apps.ubuntu.com\377\1\0\1\0\0#\0\0\0\n\0\f\0\n\0\27\0\30\0\31\0\25\0\23\0\v\0\2\1\0\0\r\0\26\0\24\4\1\4\3\5\1\5\3\6\1\6\3\3\1\3\3\2\1\2\3\0\20\0\v\0\t\10http/1.1", 278, MSG_NOSIGNAL) = 278 | 13:42 |
| didrocks | send(5, "\26\3\1\1\32\1\0\1\26\3\3XF\277\260\330B\204g\307@\n(\271\22\31\257I\n\312\335\21\7 | 13:42 |
| didrocks | \n\256\341L\264\f\347\17\222\0\0l\300+\300,\300\206\300\207\300\t\300#\300\n\300$\300r\300s\300\254\300\255\300\10\300/\3000\300\212\300\213\300\23\300'\300\24\300(\300v\300w\300\22\0\234\0\235\300z\300{\0/\0<\0005\0=\0A\0\272\0\204\0\300\300\234\300\235\0\n\0\236\0\237\300|\300}\0003\0g\0009\0k\0E\0\276\0\210\0\304\300\236\300\237\0\26\1\0\0\201\0\27\0\0\0\26\0\0\0\5\0\5\1\0\0\0\0\0\0\0$\0\"\0\0\037068ed04f2 | 13:42 |
| didrocks | 3.site.internapcdn.net\377\1\0\1\0\0#\0\0\0\n\0\f\0\n\0\27\0\30\0\31\0\25\0\23\0\v\0\2\1\0\0\r\0\26\0\24\4\1\4\3\5\1\5\3\6\1\6\3\3\1\3\3\2\1\2\3\0\20\0\v\0\t\10http/1.1", 287, MSG_NOSIGNAL) = 287 | 13:42 |
| Chipaca | thx | 13:42 |
| didrocks | I guess it's the first request + redirect? | 13:42 |
| jdstrand | zyga: and why do classic snaps care about about this? if they do care, can't we add this rule conditionally on jailmode (plus, I thought that we didn't support jailmode with --classic) | 13:43 |
| Chipaca | didrocks, yep | 13:43 |
| mup | PR snapd#2419 opened: store: retry downloads on io.Copy errors <Created by stolowski> <https://github.com/snapcore/snapd/pull/2419> | 13:44 |
| Chipaca | didrocks, are you in a position to wireshark the pi's connection? | 13:45 |
| Chipaca | didrocks, forget it, https. Let me think some more. | 13:47 |
| ahasenack | is there a way to prevent snaps from auto-upgrading? | 13:50 |
| zyga | jdstrand: because gustavo argued to have --jailmode that turns classic snaps into regular confined snaps | 13:51 |
| Chipaca | didrocks, could you run it again, the very first schmurl, pointing at http://lenticularis.chipaca.com/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap please? | 13:52 |
| alex-abreu | Chipaca, quick question, ... the List & Find snapd client results dont contains the list of plugs & slots requested & defined by the snap, I was thinking about creating a PR to add them to the snapinfo as strings, wdyt? | 13:54 |
| mup | PR snapd#2268 closed: many: merge snap-confine into snapd <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2268> | 13:55 |
| Chipaca | alex-abreu, what for? | 13:55 |
| didrocks | Chipaca: 3 downloads in a row, they all completed with success. So clearly a store <-> client interaction | 13:55 |
| Chipaca | didrocks, not so quick, little one :-p | 13:55 |
| alex-abreu | Chipaca, they are required in snapweb, as snap met ainfo | 13:56 |
| didrocks | ;) | 13:56 |
| Chipaca | didrocks, and now https://people.canonical.com/~john/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap | 13:59 |
| didrocks | Chipaca: success as well | 14:02 |
| Chipaca | alex-abreu, how would you get the ones from the store? | 14:02 |
| Chipaca | didrocks, and https://068ed04f23.site.internapcdn.net/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?t=2016-12-07T13:58:28Z&h=35c698e528ac75d574ed395ecc3144ebff6a238b ? (don't forget to quote it) | 14:03 |
| alex-abreu | Chipaca, the store lists the plugs & slots | 14:03 |
| Chipaca | alex-abreu, but you don't talk to the store | 14:04 |
| alex-abreu | Chipaca, maybe I am missing your point, but snapd/client/packages.go Find does in the backend ... | 14:05 |
| didrocks | Chipaca: dropping after few Kb or Mb downloaded | 14:05 |
| didrocks | with the same reset by peer | 14:05 |
| Chipaca | didrocks, and https://public.apps.ubuntu.com/anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?cdn=local | 14:06 |
| zyga | jdstrand: snap-confine is in snapd now :) | 14:08 |
| zyga | :) | 14:08 |
| didrocks | Chipaca: works with the local cdn parameter (so internapcdn.net is behaving in some unexpected fashion?) | 14:09 |
| didrocks | let me try to curl that one (in case curl is redirected to another one) | 14:09 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/2416 | 14:09 |
| mup | PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416> | 14:09 |
| didrocks | (curl worked) | 14:10 |
| Chipaca | alex-abreu, sorry, my point is that it's going to be a big branch, because not only client doesn't know it, neither does daemon, nor store, nor state | 14:11 |
| Chipaca | alex-abreu, and I don't understand the design that would benefit from including this information, but I'm not inherently opposed to the idea | 14:12 |
| alex-abreu | Chipaca, yes I had a quick look at it and yes, ... the overlord needs to be updated etc. | 14:12 |
| Chipaca | noise][1, ping | 14:14 |
| alex-abreu | Chipaca, it is not a super high prio, but having it seems like a strong requirement for them | 14:14 |
| noise][1 | Chipaca: so we have curl->internap OK, snapd->internap not, snapd->elsewhere OK ? | 14:14 |
| Chipaca | noise][1, go http client, not snapd, but yes | 14:15 |
| Chipaca | i took snapd out of the equation to make it simpler | 14:15 |
| Chipaca | just a regular `http.Get(...)` | 14:15 |
| noise][1 | yeah, have you tweaked any tcp options yet? | 14:15 |
| Chipaca | noise][1, not usefully, why? | 14:16 |
| noise][1 | mostly thinking timeouts, keepalives | 14:16 |
| Chipaca | noise][1, keepalives are to keep the connection alive, aren't they? | 14:17 |
| Chipaca | anyway gustavo had me set keep alives to a very small time and nothing changed | 14:18 |
| noise][1 | in that strace - is getting a read timeout? | 14:18 |
| Chipaca | no, a ECONNRESET | 14:18 |
| noise][1 | ah, missed that, yeah | 14:20 |
| Chipaca | I'll write something to dump the whole request we make | 14:20 |
| Chipaca | let's see what gives | 14:20 |
| renato__ | mvo, could you upload the first version of this package to store? https://code.launchpad.net/~phablet-team/+snap/mediaplayer-app | 14:25 |
| noise][1 | Chipaca: trying to think what curl might be doing differently than go here | 14:26 |
| noise][1 | any consistency on the timing from start to conn reset? | 14:26 |
| noise][1 | didrocks: ^^ | 14:26 |
| didrocks | noise][1: no, can be 1s or up to 4s of download | 14:26 |
| didrocks | (mostly between 1 & 2s though) | 14:27 |
| noise][1 | didrocks: and this is mainly happening on your pi2? routed/nat'd through your desktop? | 14:28 |
| didrocks | noise][1: indeed, I never have any issue on my desktop | 14:28 |
| kgunn | morphis hey wanted to catch you before your eod, i cloned the master of pulseaudio snap, built local, installed on a series16 Core running as a kvm/qemu vm....and i'm having trouble getting it to work, when i call | 14:30 |
| kgunn | pulseaudio.paplay somfile.ogg | 14:31 |
| kgunn | it acts like there's no server up to connect to so | 14:31 |
| kgunn | i didn't know if i need to start a server ? | 14:31 |
| ogra_ | ps ax ? | 14:31 |
| mvo | renato__: sure | 14:31 |
| mvo | renato__: btw, nice to see that the snaps are quite small now | 14:32 |
| renato__ | mvo, yes, thanks to ubuntu-app-platform | 14:32 |
| mvo | indeed | 14:32 |
| * zyga solicits code reviews for https://github.com/snapcore/snapd/pull/2416 | 14:32 | |
| mup | PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2416> | 14:32 |
| zyga | tvoss, lool: ^^ maybe interested | 14:33 |
| zyga | this is for the release tomorrow | 14:33 |
| jdstrand | zyga: it sounds like jailmode for classic is strict plus read of all of the core snap. is that accurate? | 14:33 |
| renato__ | mvo, please review the notes app too if possible | 14:33 |
| zyga | jdstrand: yes | 14:33 |
| Chipaca | didrocks, can you get https://people.canonical.com/~john/schmurl_arm_verbose and try again? | 14:33 |
| zyga | jdstrand: that's exactly right | 14:33 |
| Chipaca | didrocks, (no strace, just the regular output) | 14:33 |
| === chihchun_afk is now known as chihchun | ||
| didrocks | Chipaca: http://paste.ubuntu.com/23588841/ | 14:37 |
| Chipaca | didrocks, and you had the verbose curl output with all headers somewhere, yes? | 14:38 |
| didrocks | I can redo one anyway | 14:40 |
| didrocks | Chipaca: http://paste.ubuntu.com/23588854/ | 14:40 |
| kgunn | morphis sorry, browser crashed bad...had to get it back up...here's the pastebin | 14:41 |
| kgunn | http://pastebin.ubuntu.com/23588855/ | 14:41 |
| kgunn | of the issue i'm experiencing | 14:41 |
| Chipaca | didrocks, and if you add -H "Accept-Encoding: gzip" -H "Accept;" ? | 14:42 |
| didrocks | Chipaca: download still succeeded | 14:44 |
| Chipaca | didrocks, I suddenly understand people that drink during work hours | 14:52 |
| Chipaca | I think a cup of tea would work | 14:52 |
| * Chipaca goes | 14:52 | |
| didrocks | Chipaca: ahah, sounds sane! ;) | 14:53 |
| kalikiana_ | zyga: FYI it seems using "kill" is a bad idea. After using "sudo systemctl stop snapd.service snapd.socket" I got a go stacktrace - turns out there was an extra space in basedeclarations.go | 14:54 |
| mup | PR snapcraft#950 opened: tests: Use a more stable ftp source <Created by elopio> <https://github.com/snapcore/snapcraft/pull/950> | 15:02 |
| Chipaca | jdstrand, ping | 15:08 |
| jdstrand | Chipaca: hey | 15:11 |
| Chipaca | jdstrand, i'm told you're the person to talk with about http being non-installable | 15:14 |
| jdstrand | Chipaca: I need more context, but maybe? | 15:15 |
| Chipaca | jdstrand, - Mount snap "http" (19) (installation not allowed by "snapd-control" plug rule of interface "snapd-control") | 15:15 |
| jdstrand | Chipaca: what is 'http'? | 15:16 |
| Chipaca | jdstrand, httpie, in a snap | 15:16 |
| jdstrand | Chipaca: it sounds like a webserver. why does it need snapd-control? | 15:16 |
| Chipaca | jdstrand, so you can do http snapd:///v2/etc | 15:16 |
| jdstrand | Chipaca: ok I think you may be missing some context of my questions | 15:17 |
| Chipaca | jdstrand, sorry :-) | 15:17 |
| Chipaca | it's a web client, not a server | 15:17 |
| jdstrand | Chipaca: currently, http would need a snap declaration to be able to use the privileged snapd socket | 15:17 |
| Chipaca | like curl but written in python | 15:17 |
| Chipaca | pretty-prints and colorizes json and other neat things | 15:18 |
| jdstrand | Chipaca: I'm trying to understand if that access is legitimate | 15:18 |
| jdstrand | Chipaca: is this a Canonical snap? is it used by snappy developers for debugging, etc? | 15:18 |
| Chipaca | jdstrand, it's a chipaca snap, not a canonical snap | 15:18 |
| Chipaca | it is used by me to talk to snapd directly, yes | 15:19 |
| Chipaca | but it's also just regular httpie, so you can http google.com and such | 15:19 |
| jdstrand | it seems reasonable that a snappy developer would be able to use a snappy tool to talk to the snapd socket, so I'll say as much in a comment in the snap and grant the snap declaration | 15:19 |
| Chipaca | hmm. I'll take it. I'd like to think somebody not working on snappy could still do this if they cared about it enough, though. | 15:21 |
| jdstrand | jeez, why is the store taking so long | 15:21 |
| Chipaca | jdstrand, that's noise][1's middle name these days, i hear | 15:21 |
| jdstrand | hmm, searching for 'http' in the store doesn't yield great results... | 15:22 |
| ogra_ | try google then :P | 15:22 |
| jdstrand | lol | 15:22 |
| jdstrand | Chipaca: this https://myapps.developer.ubuntu.com/dev/click-apps/3675/ ? | 15:22 |
| Chipaca | jdstrand, sorry for the delay (2fa...) | 15:23 |
| Chipaca | jdstrand, yes | 15:23 |
| jdstrand | Chipaca: ok done | 15:23 |
| Chipaca | woo, it works again :-D | 15:24 |
| lutostag | I can't seem to get lxd to work on core-16, due to https://bugs.launchpad.net/snappy/+bug/1606510, is that truly the case or am I missing something? | 15:34 |
| mup | Bug #1606510: Mechanism to create system groups <lxd> <Snappy:New> <https://launchpad.net/bugs/1606510> | 15:34 |
| lutostag | any help would be appreciated | 15:35 |
| ogra_ | lutostag, seen my last comment on that bug ? | 15:35 |
| lutostag | ogra_: sweet, I did not, I will see if that works, thanks! | 15:36 |
| ogra_ | sadlyx there is still manual work required, but we'll fix that | 15:36 |
| mup | PR snapd#2420 opened: overlord/snapstate: setup/remove aliases as we link/unlink snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/2420> | 15:50 |
| lutostag | ogra_: ok, I no longer see that error in syslog (but after a reboot the error reappears). And I can never seem to get the lxd daemon to start properly | 15:53 |
| ogra_ | hmm | 15:54 |
| lutostag | (started with clean kvm image & rpi2) | 15:55 |
| ogra_ | stgraber, any idea why using extrausers might confuse lxd ? even thjough it works before reboot ? | 15:55 |
| ogra_ | do we need any extra pam or nss magic here ? | 15:55 |
| stgraber | ogra_: lxd just calls getgrnam which should go through the usual NSS stack | 15:57 |
| ogra_ | hmm | 15:57 |
| stgraber | does "getent group lxd" succeed on such a system? | 15:58 |
| lutostag | errorcode 2 | 15:58 |
| lutostag | (no output) | 15:58 |
| ogra_ | ogra@pi3:~$ sudo grep lxd /var/lib/extrausers/* | 16:01 |
| ogra_ | ogra@pi3:~$ getent group lxd; echo $? | 16:01 |
| ogra_ | 2 | 16:01 |
| ogra_ | ogra@pi3:~$ | 16:01 |
| ogra_ | grr | 16:01 |
| stgraber | good, so not my fault :) | 16:01 |
| ogra_ | ogra@pi3:~$ sudo grep lxd /var/lib/extrausers/* | 16:01 |
| ogra_ | /var/lib/extrausers/group:lxd:x:112: | 16:01 |
| ogra_ | /var/lib/extrausers/group-:lxd:x:112: | 16:01 |
| ogra_ | /var/lib/extrausers/gshadow:lxd:!:: | 16:01 |
| ogra_ | /var/lib/extrausers/gshadow-:lxd:!:: | 16:01 |
| ogra_ | ogra@pi3:~$ getent group lxd; echo $? | 16:01 |
| ogra_ | 2 | 16:01 |
| ogra_ | ogra@pi3:~$ | 16:01 |
| ogra_ | so the getent lies ... | 16:02 |
| stgraber | something must be busted with your nss setup somehow | 16:04 |
| stgraber | what do you have in nsswitch.conf? | 16:04 |
| ogra_ | passwd: compat extrausers | 16:04 |
| ogra_ | group: compat extrausers | 16:04 |
| ogra_ | shadow: compat extrausers | 16:04 |
| ogra_ | gshadow: files | 16:04 |
| ogra_ | hmm | 16:04 |
| ogra_ | gshadow doesnt look right | 16:04 |
| stgraber | yeah, not sure that it'd cause that problem, but maybe | 16:04 |
| stgraber | should be easy enough to try, just bind-mount a fixed file onto it and try again :) | 16:04 |
| ogra_ | ogra@pi3:~$ sudo getent group lxd; echo $? | 16:06 |
| ogra_ | 2 | 16:06 |
| ogra_ | nope, no change | 16:06 |
| mup | PR snapd#2421 opened: tests: add basic test for docker <Created by mvo5> <https://github.com/snapcore/snapd/pull/2421> | 16:30 |
| qamar | hi all | 16:30 |
| === topi` is now known as topi | ||
| === topi is now known as topi` | ||
| zyga | jdstrand: hey | 18:02 |
| zyga | jdstrand: will you have the time to review https://github.com/snapcore/snapd/pull/2416 today? | 18:02 |
| mup | PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2416> | 18:02 |
| kyrofa | Hey ogra_, do you know where our kernel snapcraft.yaml is maintained? | 18:08 |
| zyga | kyrofa: hehe | 18:08 |
| zyga | kyrofa: I do | 18:08 |
| zyga | kyrofa: I asked the kernel team if we can move it | 18:09 |
| zyga | https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/snapcraft.yaml?h=pc | 18:09 |
| zyga | (in a galaxy far far away) | 18:09 |
| kyrofa | zyga, ah, thanks! | 18:09 |
| zyga | kyrofa: reviews welcome ^ (for snapd) | 18:13 |
| ogra_ | kyrofa, note that the actual building happens with the Makefile that is in the tree under source: ... it has nothing at all in common with a snapcraft kernel plugin created kernel snap | 18:14 |
| kyrofa | ogra_, indeed, I noticed that | 18:14 |
| kyrofa | ogra_, is that overcoming a shortcoming, or just using something that was already there? | 18:15 |
| ogra_ | (it is a chroot that grabs a bunch of binaries from the archive and pulls the binaries out of there) | 18:15 |
| ogra_ | it is a necessity | 18:15 |
| ogra_ | we need a bunch of userspace bits and these bits need to come from stable packages | 18:15 |
| kyrofa | ogra_, ah, it's not "just" the kernel, huh? | 18:15 |
| ogra_ | and we need the kernel binaries signed with the ubuntu archive key for secure boot | 18:15 |
| ogra_ | no, rthe official kernel snap has not much in common with a plain kernel snap from a snapcraft plugin build | 18:16 |
| ogra_ | we do not build anything from source | 18:16 |
| ogra_ | due to the key requirement that wouldnt work outside of the archive | 18:16 |
| ogra_ | we need to use the same secure-boot key for UEFI secure boot as the desktop kernel | 18:17 |
| ogra_ | kyrofa, also, ppisati owns all this now | 18:17 |
| kyrofa | ogra_, ah, very interesting, okay | 18:18 |
| kyrofa | ogra_, yeah I just curious what it looked like, no problems with it or anything | 18:18 |
| kyrofa | Thanks for the info! | 18:18 |
| ogra_ | np | 18:20 |
| jdstrand | zyga: I wasn't planning on it. this looks like the code churn stuff I thought we were not going to make a high prioirty (with tyhicks) | 18:21 |
| zyga | ogra_: AFAIK all kernel snaps are owned wholly by the kernel team | 18:21 |
| zyga | jdstrand: we have today and part of tomorrow still | 18:22 |
| zyga | jdstrand: I can still prepare alt branches but I wrote this super carefully and I'd love to land if it we can review it on time | 18:22 |
| jdstrand | zyga: why is this important? it is code churn? snap-confine works fine without it | 18:23 |
| jdstrand | tyhicks: do you want me to continue to put off my work for this ^ | 18:23 |
| zyga | jdstrand: churn in some way, it's making something that was kind of ad-hoc more reliable | 18:23 |
| zyga | jdstrand: if you don't have the time to review this it's fine but at some point we may need to just land stuff without being reviwed by security | 18:24 |
| zyga | jdstrand: if you collectively agree that's okay | 18:24 |
| jdstrand | zyga: that sounds like a threat :) | 18:24 |
| zyga | jdstrand: no no, I didn't mean it to sound like that | 18:24 |
| zyga | jdstrand: I mean we may need to reorg stuff as we have conflicting requirements | 18:24 |
| zyga | jdstrand: and not enough time to do everything | 18:25 |
| zyga | jdstrand: e.g. I'll likely work on the live namespace changes code soon and that will involve lots of new stuff | 18:26 |
| jdstrand | I don't know what you are referring to with reorg, but I'm still on snappy full time. anyway, resourcing is something for ratliff, et al. let's see what tyhicks says | 18:26 |
| zyga | jdstrand: with reorg I meant that perhaps we could land some pull requests without a security review | 18:26 |
| zyga | jdstrand: and really put your time where it matters most | 18:27 |
| jdstrand | zyga: sure, and I'd like to finish dbus-app, network-namespace, get seccomp arg policy in place, and like 20 other snappy cards :) | 18:27 |
| zyga | jdstrand: I don't think the parser code is particilarly security sensitive | 18:27 |
| zyga | jdstrand: and I write stuff as defensively as I can now | 18:27 |
| zyga | jdstrand: right, I undertand, and from my perspective you have to ack almost everything I write :) | 18:27 |
| jdstrand | zyga: it is sensitive. it is running before privileges are dropped. if something bad happens there, priv escalation | 18:27 |
| zyga | jdstrand: yep, you are right | 18:28 |
| tyhicks | yes, it is sensitive | 18:28 |
| jdstrand | zyga: this is nothing against your coding btw | 18:28 |
| zyga | jdstrand: (and thus I prefer my super defensive and tested code to the stuff that's in main now :) | 18:28 |
| jdstrand | there is very little in main that is setuid root | 18:28 |
| jdstrand | this launcher is ridiculously complex for a setuid executable. I understand it has to be so, but... | 18:29 |
| zyga | jdstrand: I think parsing was | 18:29 |
| zyga | jdstrand: I agree but I think we made it as simple as it can | 18:29 |
| zyga | jdstrand: (be) | 18:29 |
| jdstrand | sure, hence the 'but' | 18:29 |
| jdstrand | err | 18:30 |
| jdstrand | hence the 'understand' | 18:30 |
| * zyga nods | 18:30 | |
| zyga | jdstrand: could emily review some of my branches? | 18:30 |
| jdstrand | that would be for ratliff and tyhicks to decide | 18:31 |
| tyhicks | zyga: why is this PR critical? | 18:31 |
| jdstrand | honestly, I'd love to get to a point where the launcher is constantly changing | 18:31 |
| jdstrand | isn't* | 18:31 |
| tyhicks | me too | 18:31 |
| tyhicks | closely reviewing PRs to a setuid-root executable takes considerable time | 18:32 |
| jdstrand | Tyler gave the +1 on the error handling one (which is fine), but I'm starting to feel like I'm losing context with each review | 18:32 |
| tyhicks | I'd like us to not make changes just for the sake of rewriting existing code | 18:33 |
| zyga | tyhicks: it's on the critical path for classic confinement, there's just two branches after that (short ones) | 18:33 |
| tyhicks | that PR only adds new code so I can't see what it is simplifying/hardening/improving | 18:33 |
| jdstrand | again, changing arg parsing isn't critical to that | 18:34 |
| jdstrand | I gave an easy path for classic | 18:34 |
| zyga | tyhicks: the code that changes main is in a separate branch | 18:34 |
| jdstrand | just modify the current parsing | 18:34 |
| jdstrand | I'm not saying this should not ever be merged. I'm just saying it isn't critical to classic | 18:34 |
| jdstrand | and therefore maybe we can land small changes fast as opposed to big changes fast | 18:35 |
| zyga | ok, I'll adjust after feedback from gutavo and propose a small branch that just adds another strcmp for --classic | 18:35 |
| * jdstrand notes that tyhicks did not weigh in on if one of us should move away from what we are doing to this | 18:36 | |
| tyhicks | my preference is to not preempt all of our current work with this PR | 18:36 |
| tyhicks | zyga seems to have agreed with a way forward that doesn't need us to do that | 18:36 |
| zyga | jdstrand, tyhicks: I think at the root of the problem is the fact that I implicitly assume I can get a review from one of you at any time | 18:37 |
| zyga | and that's not the case | 18:37 |
| jdstrand | ok. unless told otherwise, I will postpone reviewing this PR | 18:37 |
| zyga | tyhicks: well, still but to a smaller degree :) | 18:37 |
| tyhicks | zyga: yeah, that's probably a bad assumption | 18:38 |
| zyga | tyhicks: so what do you think we should do? | 18:38 |
| tyhicks | zyga: I thought you said that you'd go the strcmp() route for --classic? | 18:38 |
| zyga | tyhicks: yes, I mean in general | 18:39 |
| zyga | tyhicks: what do we do the next time? | 18:39 |
| tyhicks | zyga: we have to prioritize all of the work that we have on our plates - critical snappy PRs rank extremely high | 18:39 |
| jdstrand | zyga: I think that the stakeholder process is not being observed | 18:40 |
| tyhicks | zyga: we'll make time for those | 18:40 |
| zyga | jdstrand: what process wasthat? | 18:40 |
| tyhicks | zyga: PRs that move code around fall below ubuntu security updates, some feature development, etc., and that's the situation that we're facing now | 18:40 |
| jdstrand | it's assumed that I can do anything asked of me for snappy at any time. this results in the security team's snappy lane not getting enough attention | 18:40 |
| jdstrand | cause everything gets preempted all the time | 18:41 |
| zyga | tyhicks: should I be allowed to land such PRs with regular reviews? | 18:41 |
| zyga | jdstrand: right, I see the bad side effects, I'm looking at what to do in general | 18:42 |
| tyhicks | zyga: I would hope not. Like we discussed, this code will end up being used in the most critical sections. | 18:42 |
| jdstrand | zyga: I think what tyhicks is saying is that critical PRs will always be treated with critical priority. a PR that just moves stuff around as part of a critical feature isn't really the same thing. We can get to that PR too, but it needs to be prioritized alongside other items | 18:42 |
| tyhicks | yes, that's what I'm saynig | 18:42 |
| * zyga nods | 18:43 | |
| tyhicks | please have a good reason to make a code reorgnization PR as a prereq of a critical feature | 18:43 |
| jdstrand | for example, people are being driven crazy because setpriority isn't using arg filtering | 18:43 |
| zyga | one thing I'd like to figure out is how we can do refactorings like this one over time, perhaps we should not do it at random time but I would argue that we should have time and space for refactoring code in s-c | 18:43 |
| jdstrand | and having that and 20 other seccomp arg filtering bugs should be higher priority than an arg parsing pr | 18:43 |
| zyga | I see | 18:44 |
| jdstrand | zyga: we can, it just needs to be prioritized alongside the other stuff | 18:44 |
| zyga | ack | 18:44 |
| jdstrand | to date, the other stuff is constantly deprioritized | 18:44 |
| zyga | I'll just keep proposing them and when you have time just review them | 18:44 |
| zyga | and I'll try minimalistic branches for everything ele | 18:44 |
| * jdstrand nods | 18:44 | |
| zyga | else | 18:44 |
| tyhicks | I think that would work out well | 18:45 |
| jdstrand | zyga: if something is blocking you, it is totally fine to raise that with tyhicks and ratliff | 18:45 |
| jdstrand | that is the stakeholder process | 18:45 |
| zyga | ack | 18:45 |
| tyhicks | thanks zyga | 18:45 |
| zyga | tyhicks, jdstrand: FYI, after the merge into snapd I'll spend time on adjusting spread tess to work with and feel more like the snapd tests | 18:46 |
| zyga | and I'll do some small reorg to have a static library shared by snap-confine, snap-discard-ns, snap-system-shutdown and the upcoming snap-modify-ns (working name) | 18:46 |
| jdstrand | zyga: for you arg parsing pr... since the code will be more involved, perhaps temporarily drop privs before and raise after like we do a little later | 18:46 |
| zyga | hopefully just autotools changes though | 18:47 |
| zyga | jdstrand: sure, I can do that easily | 18:47 |
| tyhicks | heh, I was going to suggest the same thing that jdstrand just suggested | 18:47 |
| jdstrand | zyga: it isn't bulletproof to be sure, but adds a hurdle | 18:47 |
| zyga | yes | 18:47 |
| tyhicks | I'd like to see a temporary drop of privs | 18:47 |
| zyga | I can even switch hats | 18:47 |
| jdstrand | switching hats is an interesting concept | 18:47 |
| zyga | so I'm all up to do all of that in a nice and tested fashion :) (you know I love to code) | 18:48 |
| jdstrand | yes! :) | 18:48 |
| jdstrand | I'd say start with priv dropping for that-- it is super easy | 18:48 |
| zyga | +1 | 18:49 |
| tyhicks | if you change hats, I wouldn't suggest doing it the way that aa_change_hat() is already used | 18:49 |
| zyga | tyhicks: what would you suggest? | 18:49 |
| jdstrand | changing hats, using privilege separation in another process, using a crazy restrictive seccomp sandbox for that process are all things that could possibly be done, but would need to be designed to make sure the benefit outweighs the complexity | 18:49 |
| tyhicks | zyga: well we currently fork and then change hats and never return back | 18:49 |
| mup | PR snapd#2422 opened: tests: re-enable snap-confine unit tests via spread <Created by zyga> <https://github.com/snapcore/snapd/pull/2422> | 18:49 |
| zyga | tyhicks: ah | 18:50 |
| zyga | tyhicks: I thought you meant that we should use something other than aa_change_hat | 18:50 |
| tyhicks | zyga: you wouldn't want to fork - you'd just change to a hat and then change back | 18:50 |
| tyhicks | cool, sounds like we're on the same page | 18:50 |
| zyga | yes, I think so | 18:50 |
| tyhicks | ok, I'm off to hack on seccomp some more | 18:51 |
| * jdstrand goes off to reviews and dbus | 18:51 | |
| zyga | thanks guys! | 18:53 |
| zyga | and if I can review something for you, ask any time! | 18:53 |
| * jdstrand hugs zyga :) | 18:53 | |
| zyga | I'd like to help :) | 18:53 |
| jdstrand | thanks! | 18:53 |
| * zyga hugs jdstrand and tyhicks :) | 18:53 | |
| * tyhicks hugs zyga and jdstrand :) | 18:54 | |
| mup | PR snapd#2423 opened: overlord,overlord/snapstate: implement snapstate.Alias <Created by pedronis> <https://github.com/snapcore/snapd/pull/2423> | 19:16 |
| mup | PR snapcraft#948 closed: Use testtools as the base of all unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/948> | 19:27 |
| mup | PR snapcraft#950 closed: tests: Use a more stable ftp source <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/950> | 19:27 |
| mup | PR # opened: snapd#1613, snapd#2083, snapd#2128, snapd#2129, snapd#2209, snapd#2226, snapd#2230, snapd#2236, snapd#2251, snapd#2256, snapd#2274, snapd#2277, snapd#2302, snapd#2328, snapd#2345, snapd#2347, snapd#2359, snapd#2360, snapd#2365, snapd#2368, snapd#2370, snapd#2374, snapd#2377, | 20:09 |
| mup | snapd#2378, snapd#2380, snapd#2391, snapd#2392, snapd#2394, snapd#2395, snapd#2397, snapd#2407, snapd#2410, snapd#2411, snapd#2412, snapd#2413, snapd#2414, snapd#2415, snapd#2416, snapd#2417, snapd#2418, snapd#2419, snapd#2420, snapd#2421, snapd#2422, snapd#2423 | 20:09 |
| qengho | dang. | 20:10 |
| kyrofa | jdstrand, the apparmor needed by snappy isn't available upstream, correct? | 20:43 |
| tyhicks | kyrofa: the userspace bits are all available upstream | 20:44 |
| tyhicks | kyrofa: not all of the kernel bits are available upstream | 20:44 |
| kyrofa | tyhicks, right sorry, should have specified the kernel | 20:45 |
| kyrofa | tyhicks, alright just wanted to double check. Thanks! | 20:45 |
| tyhicks | kyrofa: upstreaming those bits is something that we'll have someone working on very soon | 20:45 |
| kyrofa | tyhicks, makes sense for the long haul, but I'm sure there are higher priorities at the moment | 20:46 |
| tyhicks | yes :/ | 20:47 |
| kyrofa | zyga, do we still have a classic dimension in the new Ubuntu Core images? | 20:52 |
| kyrofa | ogra_, I seem to remember you demoing the classic stuff, but don't remember how to do it | 20:55 |
| mup | PR snapcraft#908 closed: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/908> | 21:12 |
| ogra_ | kyrofa, sudo snap install classic --devmode --edge; sudo classic | 21:13 |
| kyrofa | ogra_, thank you :) | 21:14 |
| mup | Bug #1647849 opened: Ubuntu Snappy Core on Raspberry Pi 3 Wi-Fi fails on first boot <Snappy:New> <https://launchpad.net/bugs/1647849> | 21:18 |
| zyga | kyrofa: yes, but it's called clasisc snap | 21:21 |
| zyga | classic* | 21:21 |
| kyrofa | zyga, difficult to discover. Do we plan on documenting that further, or integrate further with snapd itself? | 21:22 |
| zyga | kyrofa: maybe via motd? | 21:22 |
| zyga | kyrofa: I think we should document it on the snapd wiki | 21:22 |
| zyga | kyrofa: in "first steps" perhaps, (a find-your-way-around tutorial) | 21:22 |
| kyrofa | Indeed | 21:30 |
| kyrofa | motd is also a good idea | 21:30 |
| mup | Bug #1609322 changed: snap firstboot can run before /sys/class/net/ is populated <Snappy:Fix Released> <https://launchpad.net/bugs/1609322> | 22:16 |
| mup | PR snapd#2424 opened: interfaces/builtin: add physical-memory-* and io-ports-control <Created by tonyespy> <https://github.com/snapcore/snapd/pull/2424> | 23:10 |
| mup | Bug #1647849 changed: Ubuntu Snappy Core on Raspberry Pi 3 Wi-Fi fails on first boot <Snappy:New> <https://launchpad.net/bugs/1647849> | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!