| luk3yx | Does anyone know if I can publish an unofficial MT snap based on the snapcraft.yaml in the snappy playpen? | 01:00 |
|---|---|---|
| luk3yx | (By MT I meant Minetest) | 01:01 |
| luk3yx | I have a question about the snappy playpen licensing. | 01:08 |
| mup | PR snapcraft#954 closed: pluginhandler: convert to package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/954> | 03:18 |
| mup | PR snapcraft#956 closed: tests: idempotent store installs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/956> | 03:21 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| liuxg | can anyone tell me what are really there in the Ubuntu Core OS? a Ubuntu core OS has kernel, Ubuntu Core OS, Gadget and snaps. thanks | 07:02 |
| dholbach | hey hey | 07:55 |
| didrocks | good morning dholbach! | 08:02 |
| dholbach | salut didrocks | 08:03 |
| mup | PR snapd#2465 opened: snap: show apps in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2465> | 08:06 |
| venkat_ | JOIN | 08:20 |
| venkat_ | I tried to create a kernel snap for dragonboard | 08:20 |
| venkat_ | using snapcraft.yaml | 08:21 |
| venkat_ | It is created by snapcraft command | 08:21 |
| venkat_ | then I tried to create a gadget snap for my board | 08:21 |
| venkat_ | by using gadget.yaml and snap.yaml | 08:21 |
| venkat_ | here also created a gadget snap | 08:22 |
| venkat_ | but when try to create a ubuntu image it is showing the error like | 08:22 |
| venkat_ | error: cannot decode model assertion eragon.model: assertion content/signature separator not found | 08:23 |
| venkat_ | I just created a .json file for my board and used $ cat eragon-model.json | snap sign -k default &> eragon.model command | 08:24 |
| venkat_ | It asked me to enter password, entered then succeed | 08:24 |
| mup | PR snapd#2466 opened: debian: fix Pre-Depends on dpkg <Created by mvo5> <https://github.com/snapcore/snapd/pull/2466> | 08:25 |
| venkat_ | But When I use $ sudo /snap/bin/ubuntu-image -c devmode -o eragon410-SDtest.img eragon.model command for image creation, it fails and showing above error | 08:25 |
| venkat_ | Do you the reason Why? | 08:25 |
| venkat_ | Please update if knows | 08:26 |
| eyelash | is it not possible for a snap in devmode to access programs outside the snap? | 08:51 |
| didrocks | eyelash: hum, there are some tricky way to do, but you can't execute other snaps though (there is a bug for that) | 08:52 |
| eyelash | didrocks: but if it's installed as a deb it should be possible? | 08:52 |
| didrocks | eyelash: yeah, if you add the correct LD_LIBRARY_PATH yourself (as the hostfs is in /var/lib/snapd/hostfs/) | 08:54 |
| eyelash | I was trying to create a snap package for the Meson build system and it obviously needs to access the compilers that are installed on the system | 08:54 |
| didrocks | yeah, I guess some people asked for a compiler interface though | 08:54 |
| didrocks | that will be great to have that, I'm pretty sure a bug was filed, but if you want to double check (and +1 on this) | 08:55 |
| eyelash | didrocks: oh nice | 08:55 |
| eyelash | I could not find anything with the keyword 'compiler' | 08:58 |
| eyelash | seems to be this bug: https://bugs.launchpad.net/snappy/+bug/1618004 | 09:07 |
| mup | Bug #1618004: Need a classic-bin interface to see classic binaries <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1618004> | 09:07 |
| mup | PR snapd#2467 opened: many: improve support for trusty <Created by mvo5> <https://github.com/snapcore/snapd/pull/2467> | 09:25 |
| mup | PR snapcraft#958 opened: Add source name to error message <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/958> | 09:27 |
| tsdgeos | i think i need to adapt tests for this one | 09:28 |
| mup | PR snapd#2466 closed: debian: fix Pre-Depends on dpkg <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2466> | 09:28 |
| tsdgeos | btw could someone press the "merge" button for https://github.com/snapcore/snapcraft/pull/951 ? | 09:29 |
| mup | PR snapcraft#951: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951> | 09:29 |
| mup | PR snapd#2468 opened: tests: add debug output to see why autopkgtests are failing <Created by mvo5> <https://github.com/snapcore/snapd/pull/2468> | 09:41 |
| mup | PR snapd#2374 closed: snap: tweak snap install output as designed by Mark <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2374> | 09:45 |
| grome55 | hi | 09:59 |
| grome55 | hi i request your help to guide me to install snap on debian | 10:05 |
| mup | PR snapd#2469 opened: interfaces: upower-observe: refactor to allow snaps to provide a slot <Created by morphis> <https://github.com/snapcore/snapd/pull/2469> | 10:48 |
| mup | PR snapd#2455 closed: many: implement alias command <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2455> | 10:56 |
| tsdgeos | sergiusens: i don't understand what you mean with "Please also remember to affect the bug this fixes" | 10:58 |
| mardy | t1mp: hi! The ubuntu-app-platform snap, in which distro should it be built? xenial? | 11:21 |
| kalikiana_ | mardy: xenial with overlay | 11:37 |
| kalikiana_ | See also https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ | 11:38 |
| mardy | kalikiana_: thanks! | 11:49 |
| sergiusens | tsdgeos all PRs are required to have a bug on launchpad per https://github.com/snapcore/snapcraft/blob/master/CONTRIBUTING.md | 11:53 |
| === chihchun_afk is now known as chihchun | ||
| tsdgeos | sergiusens: nice way to make me not fix small issues like this :D | 11:54 |
| tsdgeos | aaaaaaaaaand we live in the 1960 | 12:00 |
| tsdgeos | E501 line too long (84 > 79 characters) | 12:00 |
| tsdgeos | oh noes it won't fit in my 800x600 screen | 12:01 |
| mup | PR snapd#2467 closed: many: improve support for trusty <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2467> | 12:02 |
| mup | Bug #1649569 opened: Make plugin/source error reporting a bit more useful <Snappy:New> <https://launchpad.net/bugs/1649569> | 12:06 |
| tsdgeos | sergiusens: d1ad166365dfc2b934d2f28bebe31a99b1dd332f didn't have a LP bug linked :o | 12:16 |
| mardy | tsdgeos: revert it! ;-) | 12:22 |
| mup | PR snapd#2470 opened: notifications, daemon: kill the unsupported events endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/2470> | 12:33 |
| mardy | I'm getting this error after running snapcraft to build ubuntu-app-platform: E:Unable to correct problems, you have held broken packages. | 12:37 |
| mardy | any idea on how to debug this? | 12:37 |
| mardy | I don't have any held packages in my system | 12:37 |
| Chipaca | maybe "you have held broken packages" means snapcraft refuses to work with anybody that has ever handled a broken package | 12:38 |
| Chipaca | :-) | 12:38 |
| mardy | Chipaca: still, this is a rather clean installation... | 12:42 |
| Chipaca | mardy, I'll let people that know snapcraft give you serious answers now | 12:43 |
| mardy | Chipaca: thanks :-) | 12:44 |
| Chipaca | anybody know what http://autopkgtest.ubuntu.com/ is running? | 12:51 |
| mup | PR snapd#2415 closed: overlord/ifacestate: no interface checks if no snap id <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2415> | 13:04 |
| === elfgoh_ is now known as elfgoh | ||
| abeato | ogra_, hi, where could I find the sources for uboot used for rpi3? | 13:29 |
| ogra_ | abeato, they are the upstream sources with the patch thats in the gadget tree | 13:31 |
| abeato | ogra_, is that lp:~snappy-dev/snappy-hub/snappy-systems ? | 13:31 |
| ogra_ | abeato, the gadgets moved to https://github.com/snapcore | 13:32 |
| ogra_ | https://github.com/snapcore/pi3-gadget actually | 13:33 |
| abeato | ogra_, oh, ok | 13:33 |
| abeato | ogra_, I am trying to do boot from USB | 13:33 |
| abeato | ogra_, the issue I see is that uboot is not finding the right enviroment and it tries to use the default | 13:34 |
| ogra_ | note that the ROM change you have to do for that is irreversible ... afaik you wont be able to switch your Pi back to Sd onyl in case you care | 13:34 |
| abeato | ogra_, it apparently cannot load uboot.env | 13:34 |
| * abeato does not core :) | 13:34 | |
| abeato | *care | 13:34 |
| ogra_ | right, that is the patch .... | 13:34 |
| ogra_ | in the prebuilt subdir in above tree | 13:34 |
| ogra_ | you need to tell the config to use uboot.env instead of uEnv.txt | 13:35 |
| abeato | ogra_, ok... how do you build uboot btw? | 13:36 |
| ogra_ | uff... i havent done it in ages ... make config-rpi3 or some such and then just make ... with the armhf cross compiler installed | 13:36 |
| abeato | ogra_, will give that a try, thanks! | 13:37 |
| ogra_ | (i would have to look up the exact lines upstream as well ... ) | 13:37 |
| abeato | nv | 13:38 |
| ogra_ | ppisati can surely help you too ... | 13:38 |
| * ogra_ goes back into vacation mode :) | 13:38 | |
| madprops | besides games, are there other kinds of applications that would benefit from delta updates? | 13:38 |
| abeato | enjoy, sorry :) | 13:38 |
| ogra_ | why sorry, i dont need to answer :) | 13:38 |
| abeato | that's true too ;) | 13:39 |
| === hikiko is now known as hikiko|ln | ||
| ogra_ | madprops, why would only games benefit ? everything benefits from tiny downloads ;) | 13:41 |
| madprops | you should be drinking a pina colada and ignoring me :( | 13:41 |
| ogra_ | haha | 13:41 |
| madprops | but yeah i think video games are the biggest forms of this | 13:42 |
| madprops | and this is handled by systems like steam | 13:42 |
| ogra_ | well, if you have a system that is competely built from snaps and upgrade 50 of them it sums up :) | 13:43 |
| ogra_ | and there are browsers ... office suites ... theme packs ... language packs ... the yall are huge by default | 13:43 |
| ogra_ | *they all | 13:44 |
| madprops | well not really when 50 of those download the same libs | 13:44 |
| madprops | just saying | 13:44 |
| ogra_ | they wont ... | 13:44 |
| ogra_ | (becaue they hopefully use the content sharing interface for the libs ;) ) | 13:44 |
| ogra_ | *because | 13:44 |
| madprops | of you're going to do that | 13:45 |
| madprops | why not just have a good unviersal package manager | 13:45 |
| ogra_ | erm ... that is what snap is | 13:45 |
| ogra_ | just a lot more secure | 13:45 |
| madprops | hmm | 13:46 |
| ogra_ | (securer enough that you wont have to worry that your webcam that runs snappy becomes part of a botnet ;) ) | 13:46 |
| ogra_ | *secure | 13:46 |
| madprops | well language packs and stuff are already their own packages | 13:47 |
| madprops | i don't know about the security, except for the isolation, but i think it's biggest plus is it's convenience | 13:47 |
| madprops | to developers | 13:47 |
| ogra_ | debs give every package maintainer 100% root on your box | 13:48 |
| madprops | well and users (except for bigger download sizes) | 13:48 |
| ogra_ | there isnt much security in them beyond the fact that you should use a trusted archive | 13:48 |
| ogra_ | as soon as you use a package from a PPA or one you download from a website, the person owning that package has full root access to your system | 13:49 |
| ogra_ | snaps fix this | 13:49 |
| madprops | hmm | 13:49 |
| madprops | but | 13:49 |
| madprops | what if it's an application designed to make system changes | 13:49 |
| madprops | how is it going to do them without root access | 13:50 |
| ogra_ | then it uses a snappy interface to talk to the system side ... | 13:50 |
| ogra_ | which will require your authorization for critical bits | 13:50 |
| ogra_ | by design a snap can not do any harm unless you as the system owner explicitly allow it to | 13:51 |
| madprops | "snappy interface" this is sounding like it's going to control the system a lot ala systemd | 13:52 |
| ogra_ | well, a snap runs in a sandbox ... an interface is the outside connection to other snaps or the system for your snap | 13:53 |
| madprops | but if i don't run a normal application with sudo .. how does it have sudo powers? | 13:54 |
| madprops | root powers | 13:54 |
| ogra_ | say you have a music player app you snap ... it wouldnt be able to play any sound without you allowitn to access the interface the pulseaudio snap provides | 13:55 |
| mup | PR snapcraft#892 closed: Catch PermissionError when attempting to replace contents in a readonly file. (LP: #1640305) <Created by larryprice> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/892> | 13:55 |
| madprops | that sounds terrible | 13:55 |
| madprops | like every application that controls sound has to ask for permission first | 13:55 |
| ogra_ | and why is that terrible ? | 13:55 |
| madprops | something as basic as playing sound | 13:56 |
| ogra_ | (you only allow it once at package install time indeed) | 13:56 |
| madprops | ok so the permission is implied by installing it | 13:56 |
| madprops | a la android permissions | 13:56 |
| ogra_ | more like IOS | 13:56 |
| ogra_ | but yeah, similar concept | 13:57 |
| bossie__ | Hi! Any tips on where I can get info on the different Snap "types" -> type: app | core | gadget | kernel ? | 13:59 |
| bossie__ | Either I'm blind or the docs arern't that clear on it | 13:59 |
| ogra_ | https://docs.ubuntu.com/core/en/ | 14:00 |
| sergiusens | ogra_ I think android moved to this model too since 5.0 | 14:01 |
| mup | PR snapcraft#958 closed: Add source name to error message <Created by tsdgeos> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/958> | 14:01 |
| mup | Bug #1649569 changed: Make plugin/source error reporting a bit more useful <Snapcraft:Fix Committed by aacid> <https://launchpad.net/bugs/1649569> | 14:01 |
| ogra_ | bossie__, under "build a device" | 14:01 |
| ogra_ | and very specific https://docs.ubuntu.com/core/en/guides/build-device/board-enablement | 14:02 |
| ogra_ | sergiusens, ah ... havent used android for so long :P | 14:02 |
| bossie__ | ogra, thanks! I've been searching under the snapcraft.io docs.... :/ | 14:02 |
| tsdgeos | sergiusens: what do you think about https://github.com/snapcore/snapcraft/pull/951 ? | 14:04 |
| mup | PR snapcraft#951: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951> | 14:04 |
| sergiusens | tsdgeos let me comment there | 14:05 |
| tsdgeos | stupid github should send comments to the address i made the commit with and not to my main github address | 14:16 |
| tsdgeos | meh | 14:16 |
| mup | PR snapd#2454 closed: client: only allow Dangerous option in InstallPath <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2454> | 14:23 |
| mup | PR snapd#2470 closed: notifications, daemon: kill the unsupported events endpoint <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2470> | 14:25 |
| pbek | tsdgeos: I guess they can't because they haven't confirmed that you own that email address ;) | 14:28 |
| tsdgeos | pbek: they have | 14:29 |
| tsdgeos | since it's one of my confirmed email addresses in github | 14:29 |
| tsdgeos | just not the main one | 14:29 |
| pbek | tsdgeos: didn't know that they were able to do that... maybe you should open a feature request... | 14:30 |
| mup | PR snapd#2464 closed: cmd/snap: mock terminal.ReadPassword instead of using /dev/ptmx <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2464> | 14:32 |
| tsdgeos | pbek: do they accept feature requests? | 14:32 |
| pbek | tsdgeos: I've no idea to be frank... | 14:33 |
| pbek | GitLab does... | 14:33 |
| sergiusens | tsdgeos they do; I have made many and at least received replies (some are implemented). | 14:34 |
| sergiusens | tsdgeos you can configure email per project under your personal settings | 14:34 |
| tsdgeos | sergiusens: Notifications -> Custom routing ? | 14:35 |
| bossie__ | Anyone know of a snap or mechanism which will allow my snap to access a USB drive plugged into my device? - Ubuntu Core Pi 2 environment | 14:37 |
| === hikiko|ln is now known as hikiko | ||
| mup | PR snapcraft#951 closed: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <Closed by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951> | 14:40 |
| sergiusens | tsdgeos I think that's the one; Chipaca gave me the wisdom, he might recall better | 14:43 |
| tsdgeos | sergiusens: that looks like what i'd like, but i only have one organization there, (which is not canonical or ubuntu) so doesn't seem to be per project sadly :/ | 14:43 |
| Chipaca | I did nothing of the sort! | 14:53 |
| * Chipaca reads about it | 14:53 | |
| Chipaca | ah! I don't remember it being called custom routing, let me check | 14:53 |
| Chipaca | yep, that's the one | 14:54 |
| Chipaca | tsdgeos, AFAIK you need to be a member of the organization | 14:55 |
| Chipaca | i.e. it's per org | 14:55 |
| tsdgeos | meh | 14:55 |
| Chipaca | which makes sense to me | 14:56 |
| Chipaca | I'd say something about free software web services, but i'd sound bitter | 14:56 |
| mup | PR snapcraft#959 opened: Make plugins be an alias of list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/959> | 15:10 |
| kyrofa | bossie__, the snap in question needs to use the removable-media plug | 16:03 |
| kyrofa | madprops, ogra_ FYI android nowadays prompts the first time the app requests said feature instead of at install time | 16:04 |
| madprops | kyrofa, that could be annoying maybe | 16:09 |
| kyrofa | I quite like it. As a side effect, I can deny it | 16:09 |
| kyrofa | So now I can use an app minus a few features if I don't want to grant the permissions | 16:09 |
| kyrofa | madprops, note that it doesn't prompt every time, just the first time | 16:10 |
| madprops | yeah denying certain features is cool | 16:15 |
| bossie__ | thanks kyrofa I'll check it out | 16:21 |
| === shuduo is now known as shuduo-afk | ||
| mup | PR snapd#2471 opened: interfaces: add new boot-config interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2471> | 16:57 |
| mup | PR snapd#2472 opened: tests: update custom core snap with the freshly build snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/2472> | 17:00 |
| mup | Bug #1625805 changed: dragonboard: history daemon dereferences a rogue pointer <Canonical System Image:Fix Committed> <history-service (Ubuntu):Fix Committed by boiko> <linux (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1625805> | 17:08 |
| Riotela | I am on Arch Linux and wondering if I am supposed to see http://sprunge.us/ePQQ (snapd.refresh.service fails, Dec 13 19:07:28 sedric snap[3541]: - Download snap "ubuntu-core" (423) from channel "stable" (cannot authenticate to snap store: Provided email/password is not correct.)) | 17:11 |
| mup | PR snapcraft#947 closed: Add 'aliases' support to 'apps' <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/947> | 17:31 |
| mup | PR snapd#2473 opened: overlord,overlord/snapstate: implement snapstate.Unalias by generalizing the "alias" task <Created by pedronis> <https://github.com/snapcore/snapd/pull/2473> | 18:07 |
| Seblai | hi everyone. I would like to know if anyone has a link to share, tutorial, or reference on to how to develop a snap for rpi.GPIO. Basically, how to import the plugin.. thanks!!! | 18:15 |
| kyrofa | Seblai, no example that I know of, but there is a gpio interface described here: https://github.com/snapcore/snapd/wiki/Interfaces#gpio | 18:20 |
| cachio | I am trying to access to dbus from a python script in my snap | 18:25 |
| cachio | and I am getting -> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied when I do bus = dbus.SystemBus(mainloop=DBusGMainLoop()) | 18:26 |
| cachio | any idea how to fix it? | 18:26 |
| mup | PR snapd#2378 closed: interfaces: misc openstack snap enablement <Created by javacruft> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2378> | 18:44 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | pedronis: hey, wondering if you'll have a chance to review https://github.com/snapcore/snapd/pull/1613 ? (I'm told that it needs one more review and you were asked to do it. please correct me if I'm wrong) | 19:37 |
| mup | PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 19:37 |
| jdstrand | niemeyer: hi! friendly reminder about my open question to you on https://github.com/snapcore/snapd/pull/2450 | 19:38 |
| mup | PR snapd#2450: interfaces: add network-namespace-control (LP: #1624675) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2450> | 19:38 |
| niemeyer | jdstrand: Thanks for the reminder | 19:39 |
| pedronis | jdstrand: I was told to look a it | 19:39 |
| pedronis | at | 19:39 |
| jdstrand | pedronis: ack, I'll leave you to it then | 19:39 |
| jdstrand | niemeyer: note, the flurry of activity surrounding the testsuite failure in 2450 was mvo and I discovering a test infrastructure issue with the recent snap-confine merge (changes to snap-confine from PRs isn't getting properly applied to all snaps images) | 19:41 |
| jdstrand | niemeyer: he's working on that | 19:41 |
| popey | is there a store problem right now? I am trying to setup a device (pi2) and it's just sat at "Contacting store..." after I enter my email address. | 19:43 |
| jdstrand | niemeyer: also, I just referenced you in a couple (few?) reviews requesting your input on the name of the interface | 19:43 |
| jdstrand | niemeyer: (just within the last couple hours) | 19:43 |
| popey | wow, finally finished... that console setup takes an _age_ | 19:44 |
| niemeyer | jdstrand: Thanks for the poke | 19:49 |
| niemeyer | jdstrand: I'm not sure it makes much sense to have network-namespace-control separated, as you point out there | 19:52 |
| niemeyer | jdstrand: The question is this: what are we protecting against? | 19:53 |
| niemeyer | jdstrand: Can someone with network-control re-reoute traffic from other parties inside the system? | 19:53 |
| niemeyer | jdstrand: If so, we're just adding complexity for little gain.. network-control already allows abuse regardless, and network-namespace-control wouldn't work on its own | 19:54 |
| niemeyer | jdstrand: If network-namespace-control could work on its own, without network-control, then there might be some gain | 19:54 |
| niemeyer | jdstrand: In other words, if we could give some the ability to _just_ create a namespace, without being able to touch the network otherwise, then that might be justifiable | 19:55 |
| niemeyer | jdstrand: Off for some exercising.. back later | 19:59 |
| jdstrand | niemeyer: we can create _just_ the namespace, but then we can't configure it without network-control | 19:59 |
| === devil is now known as Guest88459 | ||
| jdstrand | niemeyer: based on your comments, I'm going to put it in network-control and circle back. if I need to undo it, that's fine. I prefer it in network-control after working with it for a bit | 20:00 |
| jdstrand | niemeyer: thanks for the feedback! :) | 20:03 |
| pedronis | jdstrand: does that dbus branch has a +1 from tyler? | 20:47 |
| jdstrand | pedronis: not formally. I know he looked at it at one point | 20:56 |
| pedronis | jdstrand: did somebody review the snippets? I was asked to look at it, but I generally don't/cannot review those | 20:57 |
| * pedronis is a bit confused | 20:57 | |
| jdstrand | pedronis: Gustavo and Zygmunt looked at them. I'll ask tyhicks to look at the security policy. I think Gustavo just wanted to make sure it made sense code wise | 20:58 |
| jdstrand | tyhicks: can you look at the security policy in https://github.com/snapcore/snapd/pull/1613 ? | 20:59 |
| mup | PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 20:59 |
| jdstrand | tyhicks: actually, nm, I forgot you looked at that once | 20:59 |
| jdstrand | tyhicks: meh, I forgot, you looked at the proposal, not the implemented code. | 21:00 |
| jdstrand | tyhicks: so, can you mind again and take a quick peek at the security policy? we can chat on irc about the policy if you have questions | 21:00 |
| mup | PR snapd#2471 closed: interfaces: add new boot-config interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2471> | 21:03 |
| tyhicks | jdstrand: what do you mean by "snapd does not allow ###DBUS_NAME### to end with '-[0-9]+', so this is ok."? | 21:10 |
| pihole | New to snapcraft: How do you get a simple daemon to start automatically? | 21:10 |
| tyhicks | jdstrand: if snapd doesn't allow it, what good is allowing it in the policy? | 21:11 |
| kyrofa | pihole, all you have to do is declare it as a daemon in the YAML | 21:11 |
| kyrofa | pihole, do you have a snapcraft.yaml you could share? | 21:11 |
| pihole | Sure hang on | 21:11 |
| pihole | help | 21:13 |
| pihole | OK, not sure how to format the code in here | 21:15 |
| pihole | d | 21:15 |
| tyhicks | jdstrand: on line 83, the comment says "allow unconfined clients talk to ###DBUS_NAME### on classic" but the rule doesn't contain ###DBUS_NAME### | 21:17 |
| pihole | kyrofa: apps: dnsmasq: command: bin/dnsmasq daemon: simple plugs: - network - network-bind - network-control | 21:19 |
| kyrofa | pihole, yeah, use pastebin.ubuntu.com | 21:20 |
| tyhicks | jdstrand: same with the comment/rule on line 125 | 21:20 |
| tyhicks | (that one is less worrisome because the rule specifies the peer label) | 21:21 |
| pihole | kyrofa: http://pastebin.ubuntu.com/23625639/ | 21:21 |
| kyrofa | pihole, yeah that looks fine-- the `daemon: simple` tells snapd to run it as a daemon | 21:22 |
| kyrofa | pihole, are you not seeing that behavior? Is the daemons perhaps erroring out? | 21:22 |
| pihole | kyrofa: I checked journalctl -u and it shows it starts, but then stops shortly after. Also tried it without the custom config file. Load up fine either way when done manually | 21:23 |
| jdstrand | tyhicks: re '-[0-9]+', see the regex at line 218 | 21:24 |
| pedronis | jdstrand: added some comments | 21:24 |
| jdstrand | tyhicks: what is happening is that a snap developer can request org.foo. snapd will create rules for org.foo and org.foo-[1-9]... | 21:25 |
| jdstrand | tyhicks: therefore we do not allow a developer to request org.foo-1 | 21:25 |
| tyhicks | jdstrand: got it, thanks | 21:25 |
| jdstrand | tyhicks: line 83 needs to be updated | 21:26 |
| jdstrand | tyhicks: well, really the comment is correct from a certain perspective, but I'll make it clear | 21:27 |
| jdstrand | pedronis: thanks! | 21:27 |
| kyrofa | pihole, perhaps it's not a simple daemon? | 21:30 |
| kyrofa | pihole, does it fork? | 21:30 |
| pihole | kyrofa: good point. Maybe I'll just try that. | 21:33 |
| pihole | kyrofa: thank you very much | 21:33 |
| kyrofa | pihole, of course | 21:33 |
| mup | PR snapcraft#957 closed: sources: refactor base sources into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/957> | 21:52 |
| Mritunjai | Hi All | 21:52 |
| tyhicks | jdstrand: thanks for clarifying the comments | 21:53 |
| tyhicks | jdstrand: my final concern is that the rules on lines 86 and 94 essentially allow the snap to communicate with any unconfined application | 21:54 |
| mup | PR snapcraft#960 opened: pluginhandler: install scriptlet support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/960> | 21:55 |
| Mritunjai | I am very new to snappy. My requirement is that i have one app already working for x86 and arm. Now what i want to do is to have the stripped version of my exisitng app and make a snap of it and distribut it to the vendors so that they can play with it. Can anyone please gudie me how to start with the same? | 21:56 |
| jdstrand | tyhicks: it can only do it via that interface or path | 21:56 |
| jdstrand | tyhicks: the idea is to let this work within a traditional desktop environment (ie, classic) | 21:57 |
| jdstrand | tyhicks: so, say have some application that is a deb but knows about rhythmbox. I have a rhythmbox snap installed | 21:58 |
| jdstrand | tyhicks: the snap can use either the dbus interface that matches or the dbus path that matches. I was thinking that would make the other side not work so well, but thinking at last about the path one, maybe that should be a rec | 22:00 |
| jdstrand | receive | 22:00 |
| mup | PR snapcraft#961 opened: sources: refactor local source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/961> | 22:01 |
| mup | PR snapd#2473 closed: overlord,overlord/snapstate: implement snapstate.Unalias by generalizing the "alias" task <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2473> | 22:05 |
| mup | PR snapcraft#962 opened: sources: refactor bazaar source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/962> | 22:13 |
| mup | PR snapcraft#963 opened: sources: refactor deb source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/963> | 22:22 |
| jdstrand | tyhicks: did you see my response? | 22:22 |
| jdstrand | tyhicks: in case not: | 22:23 |
| jdstrand | tyhicks: it can only do it via that interface or path | 22:23 |
| jdstrand | tyhicks: the idea is to let this work within a traditional desktop environment (ie, classic) | 22:23 |
| jdstrand | tyhicks: so, say have some application that is a deb but knows about rhythmbox. I have a rhythmbox snap installed | 22:23 |
| jdstrand | tyhicks: the snap can use either the dbus interface that matches or the dbus path that matches. I was thinking that would make the other side not work so well, but thinking at last about the path one, maybe that should be a receive | 22:23 |
| jdstrand | least* | 22:23 |
| tyhicks | I didn't see it (I apparently disconnected for a moment) | 22:24 |
| jdstrand | tyhicks: I could remove send from those two rules | 22:24 |
| jdstrand | I wonder how much it is needed for the interface rule though | 22:24 |
| tyhicks | I mean it just depends if the snap is going to be only replying to messages or if it needs to actually send a method_call or signal message | 22:25 |
| pedronis | jdstrand: how does things fail if bus or name don't match? you get an connection but it doesn't work? | 22:26 |
| jdstrand | tyhicks: we don't know. this is a generic interface. let's think of this in terms of say, talking to download manager | 22:26 |
| jdstrand | pedronis: you get too many things matching. see the test for this here: https://github.com/snapcore/snapd/pull/1613/files#diff-c5f8555bf0fa0810f5d9dbd039036112R530 | 22:28 |
| mup | PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 22:28 |
| mup | PR snapcraft#964 opened: sources: refactor git source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/964> | 22:28 |
| jdstrand | pedronis: in that, the slot offers two well-known names but the plug only plugs one | 22:28 |
| jdstrand | pedronis: we want to connect the right ones. that little bit does that | 22:29 |
| pedronis | jdstrand: I don't understand what you are saying at all | 22:29 |
| pedronis | :) | 22:29 |
| jdstrand | pedronis: look at the test | 22:29 |
| jdstrand | pedronis: the slotYaml has 'this' and 'that' | 22:29 |
| pedronis | the test calls ConnectedPlugSnippet | 22:30 |
| pedronis | and gets what you told it to do | 22:30 |
| jdstrand | pedronis: look at the plugYaml, it only plugs 'that' | 22:30 |
| tyhicks | jdstrand: yeah, I appreciate that it is generic - I just wanted to point out that the rules with send perms grant a lot more than intended and it'd be nice if we could remove the send perms | 22:30 |
| jdstrand | pedronis: without this code, things go wrong | 22:30 |
| tyhicks | jdstrand: IMO, there's no use in removing the send perms on the interface related rule but not the path related rule | 22:30 |
| pedronis | jdstrand: sorry, I don't understand, that tests proves that the code does what you told it to do | 22:31 |
| jdstrand | tyhicks: I was thinking the other way around | 22:31 |
| pedronis | I don't understand how it relates to the higher levels | 22:31 |
| jdstrand | pedronis: ok, let me look at this again. two conversations at once is difficult | 22:31 |
| jdstrand | tyhicks: consider the snap has both rules | 22:32 |
| jdstrand | tyhicks: then it tries to talk to the session ubuntu-download-manager (udm) that is unconfined | 22:32 |
| jdstrand | tyhicks: so, the interface rule allows it to talk to the well-known name (name=udm) using the snap's interface (eg, org.foo) | 22:33 |
| jdstrand | tyhicks: wouldn't dbus just reject that rule cause udm doesn't have the org.foo interface? | 22:33 |
| barry | hey snappy folks, i'm seeing recent failures autopkgtests of ubuntu-image (both locally and via gh pull request) when trying to build the pc-i386-model.assertion here: https://github.com/CanonicalLtd/ubuntu-image/blob/master/debian/tests/models/pc-i386-model.assertion | 22:34 |
| barry | here is a log for example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-canonical-foundations-ubuntu-image/yakkety/amd64/u/ubuntu-image/20161213_220817_0caf6@/log.gz | 22:34 |
| barry | scroll to the bottom. snap prepare-image can't find the pc-kernel snap on the beta channel | 22:34 |
| tyhicks | jdstrand: no, the message will be delivered and it is up to the receiving connection to reject that rule based on the invalid interface | 22:34 |
| jdstrand | tyhicks: the path rule is similar. the snap can talk to udm using path=/org/foo. I feel like that is maybe problematic and perhaps it should have the receive rule | 22:34 |
| barry | afaict, pi2, pi3, dragonboard, and pc-amd64 all all fine | 22:35 |
| barry | just the pc-i386 one is failing. has something changed here recently? | 22:35 |
| tyhicks | jdstrand: many dbus libraries will reject the message but the message is still delivered | 22:35 |
| jdstrand | tyhicks: ok, well, then the question becomes if on *classic* that is acceptable | 22:35 |
| barry | like, the i386 arch of pc-kernel went away? | 22:35 |
| tyhicks | jdstrand: yeah, I agree that's the question | 22:35 |
| jdstrand | tyhicks: this is an environment with x11 | 22:36 |
| * tyhicks nods | 22:36 | |
| jdstrand | though, this also support system | 22:36 |
| jdstrand | how about I remove 'send' and we see how it goes? if it needs to integrate with unity7 then the unity7 interface could gain whatever it needed | 22:37 |
| tyhicks | I would prefer that but can't say whether or not 'send' will just have to be added shortly after to make the interface useful in a classic environment | 22:38 |
| elfgoh | Can i double confirm that I can't login to the Ubuntu core via password? | 22:38 |
| tyhicks | I just haven't profiled enough dbus services to know for sure :/ | 22:38 |
| elfgoh | i.e., if i connect a monitor, i can't login. I can login via ssh tough | 22:38 |
| elfgoh | *though | 22:38 |
| jdstrand | tyhicks: we don't have concrete examples for this part of the ruleset | 22:39 |
| jdstrand | so, let's remove send and see what happens | 22:39 |
| tyhicks | tyhicks: I like the sound of that - it definitely improves the security properties of the policy so I think it is worth waiting and seeing | 22:40 |
| mup | PR snapcraft#965 opened: sources: refactor mercurial source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/965> | 22:40 |
| pedronis | barry: it's on snapd side, calling the api directly it seems there's no i386 beta kernel anymore in the store | 22:40 |
| pedronis | barry: it's *not* on the snapd side | 22:41 |
| tyhicks | jdstrand: fyi, this was the crux of the kdbus authors' argument against our fine-grained dbus mediation | 22:41 |
| barry | pedronis: that's what i suspected. do you know if that's intentional? who owns/owned the i386 kernel snap? | 22:41 |
| pedronis | I don't know | 22:42 |
| barry | ogra_: perhaps? | 22:42 |
| pedronis | it might also be a store bug (wrong channel inheritance) | 22:42 |
| jdstrand | tyhicks: hmm? | 22:42 |
| tyhicks | jdstrand: they claimed that if a dbus client could send *any* message to a dbus service, that service must be smart enough to reject invalid/unexpected paths, interfaces, and method names | 22:42 |
| pedronis | barry: afaict as I get from the api, there's a kernel in edge, and the same in stable and candidate, but nothing in beta | 22:43 |
| pedronis | for i386 | 22:43 |
| tyhicks | jdstrand: and that filtering out certain values of paths, interfaces, and/or method names in security policy was not worthwhile | 22:43 |
| jdstrand | tyhicks: I see. well, obviously we disagree | 22:43 |
| tyhicks | yeah | 22:44 |
| jdstrand | tyhicks: the same could be said of seccomp | 22:44 |
| barry | pedronis: so there is one in stable? maybe i should just switch the tests over to that. i suppose at one point they were only available in beta which is why the tests used that. /me tries | 22:44 |
| tyhicks | jdstrand: good point | 22:44 |
| jdstrand | it is reducing attack surface | 22:44 |
| tyhicks | jdstrand: ok, that was mostly useless knowledge - I'll let you get back to the PR | 22:44 |
| tyhicks | :) | 22:44 |
| pedronis | barry: yes, stable and candidate have 44, edge has 48 | 22:44 |
| pedronis | no beta | 22:45 |
| barry | pedronis: if it's in stable, you'd expect it to be in beta too then right? | 22:45 |
| pedronis | well it's in candidate | 22:45 |
| pedronis | but yes | 22:45 |
| pedronis | so as I said might be store issue | 22:45 |
| pedronis | worth poking store people | 22:46 |
| barry | pedronis: ok, thanks | 22:46 |
| pedronis | anyway amd64 has something explicit in beta fwiw | 22:47 |
| elfgoh | Is it possible for me to modify the scheduled rebootreboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c' | 22:50 |
| elfgoh | "reboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c'" | 22:50 |
| cachio | jdstrand, hi, I am creating a tests where I am creating some methods in dbus and I call them from python calls in my snap | 22:55 |
| cachio | jdstrand, is it needed for that to create a new interface? | 22:56 |
| cachio | jdstrand, the process is the following, first I add policies in /etc/dbus-1/system.d, then register a method to be called | 22:58 |
| cachio | then I call this methods with some parameters and this method will spam signals depending on the parameters used. | 22:58 |
| cachio | I am doing this to measure dbus performance | 22:59 |
| cachio | jdstrand, but I am still getting this error > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'com.canonical.kpi.signal': no such name | 23:00 |
| cachio | any guess? | 23:00 |
| mup | PR snapcraft#966 opened: sources: refactor rpm source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/966> | 23:04 |
| pedronis | barry: I poked, seems indeed a glitch, there should be something there | 23:07 |
| jdstrand | pedronis: well, it seems something higher is doing the right thing. if I comment out that 'ensure' area and then install a snap with two slots and a slot with one plug, I get the right policy | 23:08 |
| barry | pedronis: thanks | 23:08 |
| jdstrand | pedronis: I thought I observed different behavior before which is what prompted the test, but I don't recall specifically | 23:08 |
| pedronis | jdstrand: nothing higher level consider that method | 23:08 |
| pedronis | jdstrand: afaik it will either find too many, or if you are explicit enough | 23:08 |
| jdstrand | pedronis: I just mean if I try to snap connect the wrong slot, it doesn't | 23:09 |
| pedronis | it connect but things will not work | 23:09 |
| pedronis | jdstrand: with what kind of error? | 23:09 |
| jdstrand | no error | 23:09 |
| pedronis | ? | 23:09 |
| pedronis | so the connection is there? | 23:09 |
| pedronis | but doesn't work | 23:09 |
| jdstrand | pedronis: consider | 23:10 |
| jdstrand | snap interfaces | 23:10 |
| jdstrand | foo:bar | 23:10 |
| jdstrand | meh | 23:10 |
| jdstrand | foo: bar - | 23:10 |
| jdstrand | meh | 23:10 |
| jdstrand | foo:bar - | 23:10 |
| jdstrand | foo:baz - | 23:10 |
| jdstrand | - norf:bar | 23:10 |
| jdstrand | sudo snap connect norf:bar foo:bar | 23:10 |
| jdstrand | that works fine (expected) | 23:11 |
| jdstrand | sudo snap connect norf:bar foo:baz | 23:11 |
| jdstrand | no error, no issues | 23:11 |
| jdstrand | (policy is correct | 23:11 |
| jdstrand | ) | 23:11 |
| pedronis | ?? | 23:11 |
| pedronis | but snap interfaces | 23:11 |
| pedronis | will say they are connect no? | 23:11 |
| jdstrand | tpedsnap interfaces show it as connected | 23:12 |
| pedronis | so you can connect things that will do nothing | 23:12 |
| jdstrand | yes | 23:12 |
| pedronis | maybe it's the best we can get | 23:12 |
| pedronis | but is not that great | 23:12 |
| jdstrand | well, I could error there | 23:13 |
| jdstrand | in the 'ensure' section | 23:13 |
| jdstrand | this is with that code commented out | 23:13 |
| pedronis | but then it's too late | 23:13 |
| pedronis | I think | 23:13 |
| jdstrand | if I put it back, I think it will work correctly since we return nil, nil | 23:13 |
| jdstrand | let me check | 23:13 |
| pedronis | as far as I know | 23:14 |
| pedronis | nothing checks that first nil | 23:14 |
| pedronis | it just get ignored | 23:14 |
| jdstrand | ok, putting it back it is the same behavior. snap interfaces shows it as connected, but the policy doesn't have it | 23:16 |
| jdstrand | let me error in there | 23:16 |
| jdstrand | return nil, err | 23:16 |
| jdstrand | pedronis: yes, if I put an err there then snap connect shows the message, but snap interfaces still shows it as connected | 23:18 |
| pedronis | jdstrand: the problem with the error is that if there's a 2nd interface that should work it will get in a strange state possibly | 23:20 |
| jdstrand | pedronis: I don't know what to do at this point | 23:20 |
| pedronis | there's not place atm for that check afaict | 23:20 |
| pedronis | so the nil, nil | 23:21 |
| pedronis | is the best we can do | 23:21 |
| jdstrand | ok, so what I had | 23:21 |
| pedronis | (also error handling in there is not very graceful) | 23:21 |
| cachio | jdstrand, any suggestion about the comment I did before? | 23:24 |
| jdstrand | cachio: you are going to need to have security policy that handles that. currently there is none | 23:26 |
| jdstrand | cachio: I suggest devmode for the time being | 23:26 |
| jdstrand | cachio: then finish your snap and then I can take a look at it | 23:26 |
| cachio | I am getting this error | 23:27 |
| cachio | dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'com.canonical.kpi.signal': no such name | 23:27 |
| jdstrand | cachio: there is likely an apparmor denial in syslog | 23:27 |
| cachio | jdstrand, I just see apparmor="ALLOWED" | 23:29 |
| cachio | jdstrand, is it ok to copy the dbus config file to /etc/dbus-1/system.d ? | 23:30 |
| jdstrand | cachio: ah, it is in devmode | 23:30 |
| cachio | jdstrand, yes in devmode | 23:30 |
| jdstrand | cachio: right, so devmode isn't going to cover dbus bus policy, just seccomp, device cgroups, apparmor, etc | 23:30 |
| jdstrand | cachio: so you are going to need to put something in there. as it happens, the dbus interface I am working on would give you a bus policy that would work with devmode | 23:31 |
| jdstrand | cachio: see https://github.com/snapcore/snapd/pull/1613/files#diff-715ebbcbcd440b44a1e536f154ca6138R108 | 23:31 |
| mup | PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 23:31 |
| jdstrand | cachio: eg, $ cat /etc/dbus-1/system.d/snap.test-hello-dbus.test-hello-dbusd-system.conf | 23:32 |
| jdstrand | <!DOCTYPE busconfig PUBLIC | 23:32 |
| jdstrand | "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" | 23:32 |
| jdstrand | "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> | 23:32 |
| jdstrand | <!-- This file was automatically generated by snappy --> | 23:32 |
| jdstrand | <busconfig> | 23:32 |
| jdstrand | <policy user="root"> | 23:32 |
| jdstrand | <allow own="com.canonical.HelloDBus"/> | 23:32 |
| jdstrand | <allow send_destination="com.canonical.HelloDBus"/> | 23:32 |
| jdstrand | </policy> | 23:32 |
| jdstrand | <policy context="default"> | 23:32 |
| jdstrand | <allow send_destination="com.canonical.HelloDBus"/> | 23:32 |
| jdstrand | </policy> | 23:32 |
| jdstrand | </busconfig> | 23:32 |
| jdstrand | cachio: create a bus policy like that ^ (adjust for your well-known name and interface of course) and that will allow any one to talk to your service | 23:33 |
| jdstrand | well | 23:33 |
| jdstrand | any unconfined process | 23:33 |
| jdstrand | (or devmode) | 23:33 |
| cachio | jdstrand, nice, but it would work when your change is landed, right? | 23:34 |
| pedronis | jdstrand: it's late here, if you get a +1 from tyler it's mergeable I think | 23:34 |
| jdstrand | cachio: for devmode, yes. in strict might need some adjustments | 23:35 |
| jdstrand | it may work | 23:35 |
| cachio | jdstrand, good, so I'll need to wait | 23:36 |
| * pedronis => rest | 23:36 | |
| cachio | jdstrand, any guess about when it is gonna be landed? | 23:36 |
| jdstrand | pedronis: thanks so much! | 23:36 |
| cachio | aprox | 23:36 |
| jdstrand | cachio: it is what I've been talking about with people in this channel today | 23:36 |
| cachio | jdstrand, we are talking about days, weeks? | 23:36 |
| jdstrand | cachio: it is targeted for 2.20. it will hopefully land tomorrow | 23:37 |
| jdstrand | 2.20 is for thursday I think | 23:37 |
| cachio | jdstrand, awesome | 23:37 |
| pedronis | it will get in candidate thu or fri | 23:37 |
| cachio | jdstrand, it works for me if it is on this week | 23:37 |
| pedronis | (stable is in January though) | 23:37 |
| jdstrand | cachio: note pedronis' comment | 23:39 |
| jdstrand | cachio: if you need something sooner, you are going to need to hack up your bus policy manually | 23:39 |
| cachio | jdstrand, it is ok, I am using daily builds for testing | 23:39 |
| cachio | jdstrand, so I'll test it as soon as possible once it is landed | 23:40 |
| pedronis | barry: there should be again something in beta (for pc-kernel i386) | 23:40 |
| cachio | jdstrand, thanks for the support | 23:42 |
| jdstrand | cachio: np! :) | 23:43 |
| jdstrand | tyhicks: thanks for your review! :) | 23:51 |
| mup | PR snapcraft#967 opened: sources: refactor script source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/967> | 23:55 |
| tyhicks | jdstrand: no problem! | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!