| mup | PR snapd#2054 closed: client,daemon,cmd/snap: improve create-user APIs <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2054> | 00:29 |
|---|---|---|
| === j is now known as Guest16612 | ||
| mwhudson | is it possible to get snapd to forget about an assertion? | 03:42 |
| === King_InuYasha is now known as Son_Goku | ||
| zyga | hey | 06:54 |
| zyga | mwhudson: I think only with a new assertion | 06:54 |
| zyga | mwhudson: (or with rm -f) | 06:54 |
| mup | PR snapd#2056 opened: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2056> | 07:25 |
| mwhudson | morning | 07:40 |
| mup | PR snapd#2056 closed: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2056> | 08:03 |
| mup | PR snapd#2057 opened: docs: remove references to removed buying features <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2057> | 08:16 |
| mup | PR snapd#2058 opened: interfaces: add ofono interface <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2058> | 08:17 |
| hikiko | hello :) | 08:21 |
| hikiko | I need some help with an error message during dist-upgrade on X | 08:21 |
| hikiko | http://pastebin.com/HUcC3wWg | 08:21 |
| hikiko | the initial problem I was trying to solve was this: | 08:22 |
| hikiko | I have 2 graphics cards intel and nvidia, but I work on the intel, the nvidia is there for testing features and during the last dist-upgrades the nvidia drivers and several other packages were automatically installed and messed up my xorg configuration so I couldn't use any of the cards. everytime I remove the nvidia drivers and the other packages they are reinstalled as a dependency of libcuda1-361 and every time I try to remove | 08:25 |
| hikiko | it I receive that error message... | 08:25 |
| hikiko | any ideas? :) | 08:25 |
| mup | PR snapd#2059 opened: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <https://github.com/snapcore/snapd/pull/2059> | 08:32 |
| didrocks | hikiko: no package I can see contain this file, I guess it's snapd creating it dynamically for system mount point. It's a question for mvo or zyga ^ | 08:34 |
| hikiko | thanks didrocks :) | 08:39 |
| mup | PR snapd#2060 opened: many: change Connect to take ConnRef instead of strings <Created by zyga> <https://github.com/snapcore/snapd/pull/2060> | 09:28 |
| mup | PR snapd#2061 opened: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <https://github.com/snapcore/snapd/pull/2061> | 09:52 |
| didrocks | zyga: hey! It seems that if a service fails to start at installation time, the snap is removed | 09:55 |
| didrocks | zyga: that makes it hard for debugging, any tip about it? | 09:55 |
| didrocks | davidcalle: FYI (on the doc) | 09:55 |
| zyga | didrocks: hey | 10:30 |
| zyga | hikiko: looking | 10:30 |
| zyga | hikiko: that's something that was only available in -proposed | 10:31 |
| zyga | hikiko: this is something that has to be fixed in the nvidia packaging but I believe it was removed already | 10:32 |
| zyga | hikiko: can you check if you can downgrade to the non-proposed package and see if the problem goes away | 10:32 |
| zyga | didrocks: I wasn't aware of it | 10:32 |
| zyga | didrocks: I don't know what is the plan about this, sorry | 10:32 |
| hikiko | zyga, how can I downgrade it? | 10:33 |
| zyga | hikiko: I think you can try to install it with "apt install package=version" | 10:39 |
| zyga | hikiko: alternatively edit the dpkg maintainer script on your disk not to touch that mount unit | 10:40 |
| zyga | hikiko: but really, I don't fully know what is required; you probably want to ask alberto milone or mvo (try alberto first please) | 10:40 |
| hikiko | zyga, and where can I find the version to which I have to downgrade? | 10:40 |
| zyga | hikiko: try apt-cache policy package | 10:40 |
| zyga | this will show you available versions | 10:41 |
| hikiko | thanks zyga :) I'll try | 10:41 |
| zyga | (the package in question is the one that fails because of the maintianer script) | 10:41 |
| zyga | *maintainer | 10:41 |
| mup | PR snapd#2062 opened: interfaces/policy: introduce InstallCandidate and its checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/2062> | 10:51 |
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapd#2063 opened: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063> | 11:46 |
| zyga | jdstrand: hey, you may want to review this one ^6 | 11:47 |
| didrocks | zyga: hikiko|ln: btw, easier for downgrading, you can do apt install package/<distropocket> (like package/yakkety for instance) | 12:04 |
| hikiko|ln | didrocks, if I try to do that the proposed are selected | 12:05 |
| didrocks | no | 12:06 |
| didrocks | if you don't set yakkety-proposed, and only yakkety, it will select yakkety | 12:06 |
| didrocks | (with -f to force a downgrade ofc) | 12:06 |
| hikiko|ln | # apt install libcuda1-361/xenial -f | 12:07 |
| hikiko|ln | Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB] | 12:07 |
| didrocks | this is the nvidia package | 12:08 |
| didrocks | not libcuda1-361 | 12:08 |
| hikiko|ln | yup it's a dependency | 12:08 |
| didrocks | so ofc, the other packages follow the general scheme | 12:08 |
| hikiko|ln | oh ok :) | 12:08 |
| didrocks | so, you need to list it | 12:08 |
| didrocks | # apt install libcuda1-361/xenial nvidia-367/xenial -f | 12:08 |
| didrocks | and so on… :) | 12:08 |
| hikiko|ln | I need to remove the dependencies and libcuda didrocks | 12:09 |
| hikiko|ln | should I first downgrade then remove? | 12:09 |
| didrocks | I would say yeah, first downgrade everything to remove -proposed components | 12:09 |
| didrocks | and then remove | 12:09 |
| didrocks | (get in a consistent state first) | 12:09 |
| hikiko|ln | ~# apt install libcuda1-361/xenial nvidia-367/xenial nvidia-opencl-icd-367/xenial nvidia-prime/xenial nvidia-settings/xenial -f | 12:10 |
| hikiko|ln | Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB] | 12:10 |
| hikiko|ln | it seems to ignore my setting | 12:11 |
| didrocks | hum… that's weird | 12:11 |
| didrocks | what if you only do apt install nvidia-367/xenial -f only? | 12:11 |
| hikiko|ln | https://paste.ubuntu.com/23269943/ didrocks | 12:12 |
| didrocks | hikiko|ln: I think you have another package that forces you to get that version | 12:16 |
| hikiko|ln | I've purged nvidia* didrocks | 12:17 |
| hikiko|ln | can I see which package it is somehow? | 12:17 |
| didrocks | and here we go | 12:17 |
| didrocks | https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-367 | 12:17 |
| didrocks | -367 is only available in -proposed | 12:17 |
| didrocks | that's why he didn't follow your guidance to prefer the /xenial one :p | 12:17 |
| hikiko|ln | and I didn't have it installed | 12:17 |
| hikiko|ln | so what should I do? | 12:18 |
| didrocks | I'm pretty sur eyou have something like libcuda1-367 or anything depending on it | 12:18 |
| didrocks | well, you did purge it, right? | 12:18 |
| hikiko|ln | the initial problem is to remove libcuda1-361 | 12:18 |
| hikiko|ln | yup | 12:18 |
| didrocks | apt-cache rdepends nvidia-367 | 12:18 |
| didrocks | anything there? ^ | 12:18 |
| hikiko|ln | Reverse Depends: | 12:18 |
| hikiko|ln | libcuda1-367 | 12:18 |
| hikiko|ln | nvidia-opencl-icd-367 | 12:18 |
| hikiko|ln | nvidia-367-dev | 12:18 |
| hikiko|ln | nvidia-361 | 12:18 |
| didrocks | yeah, so you need to remove any of those installed | 12:18 |
| didrocks | just purge them | 12:19 |
| hikiko|ln | 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. | 12:21 |
| hikiko|ln | they seem purged | 12:21 |
| didrocks | good :) | 12:21 |
| hikiko|ln | maybe rdepends libcuda1-361? | 12:21 |
| didrocks | you was able to delete it as well? | 12:21 |
| didrocks | now, try to remove it | 12:21 |
| didrocks | as it's what you wanted IIRC | 12:21 |
| hikiko|ln | same | 12:22 |
| hikiko|ln | E: Sub-process /usr/bin/dpkg returned an error code (1) | 12:22 |
| didrocks | maybe zyga telling to downgrade nvidia on the proposed didn't indicate the right package | 12:23 |
| didrocks | (I didn't follow closely) | 12:23 |
| didrocks | ensure you don't have snapd from proposed from what I understand | 12:23 |
| hikiko|ln | mmm how? | 12:24 |
| didrocks | apt-cache policy snapd | 12:24 |
| didrocks | do you have the proposed version installed? | 12:24 |
| hikiko|ln | yes | 12:24 |
| didrocks | so, same | 12:24 |
| didrocks | revert to the one on xenial | 12:24 |
| hikiko|ln | same :/ | 12:25 |
| hikiko|ln | if I purge snapd | 12:25 |
| hikiko|ln | remove the package and reinstall it? | 12:26 |
| === hikiko|ln is now known as hikiko | ||
| hikiko | still :p just tried that | 12:27 |
| lool | ogra_: Hey, around? | 12:31 |
| lool | ogra_: were you the one implementing the dragonboard boot support? :-) | 12:31 |
| ara | zyga, ping | 12:33 |
| mup | PR snapd#2064 opened: Adding new AutopilotIntrospectionInterface <Created by heber013> <https://github.com/snapcore/snapd/pull/2064> | 12:40 |
| zyga | ara: hey | 13:02 |
| zyga | ara: how can I help you | 13:02 |
| ara | zyga, hey! I was wondering how the snap-confine SRU to xenial was going | 13:02 |
| ara | zyga, any news? | 13:02 |
| ara | zyga, (what's the bug report to track it?) | 13:03 |
| zyga | ara: the status is that we landed one SRU last week but we need to go through all the bugs and verify those | 13:18 |
| zyga | ara: I won't have time for this today as we're freezing now and I need to finish features first | 13:18 |
| ara | zyga, where is the bug that tracks the SRU? | 13:19 |
| zyga | ara: if you can help by asking anyone to go through all the SRU bugs on launchpad for snap-confine, we can do this faster | 13:19 |
| zyga | ara: there's no one bug, each bug has SRU data now | 13:19 |
| ara | zyga, perfect, I will check on the report page | 13:19 |
| zyga | ara: look at milestones .40, .41 an.42 | 13:19 |
| zyga | ara: .42 has two bugs that don't have SRU data but I can add that quickly; this was a tiny release | 13:19 |
| zyga | ara: if you can get me someone to work on validation I will save a lot of time | 13:20 |
| ara | zyga, are you sure that the SRU landed in -proposed? I don't see it in the http://people.canonical.com/~ubuntu-archive/pending-sru.html | 13:20 |
| zyga | ara: no, ah, sorry, too many facts lately, .41 was in -proposed but we removed it and someone should upload .42 now | 13:20 |
| zyga | ara: (there's .42.1 but it doens't have to be released now) | 13:21 |
| ara | zyga, can you organize uploading it, please? I can help verifying it | 13:21 |
| zyga | ara: yes, I can | 13:22 |
| zyga | ara: thank you :) | 13:22 |
| ara | zyga, thanks you! | 13:22 |
| ara | zyga, *thank | 13:22 |
| zyga | joc: ok, branch comig up, just a simple unit test to tie it together | 13:33 |
| zyga | joc: I will need you to add this udev rule manually to your device and see if it does the right thing | 13:33 |
| zyga | joc: (no need to build/alter snapd) | 13:34 |
| ogra_ | lool, http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files ... there is a README ... gadget code is at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/dragonboard/ | 13:40 |
| * ogra_ goes back to uniting :) | 13:41 | |
| joc | zyga: ack | 13:41 |
| zyga | joc: ok, pull request is up, mup will share the link in a sec | 13:45 |
| mup | PR snapd#2065 opened: interfaces/builtin: use udev to export GPIOs to userspace <Created by zyga> <https://github.com/snapcore/snapd/pull/2065> | 13:45 |
| zyga | joc: look at tests, get the rule there and stick it into /lib/udev/rules.d/foo.rules | 13:46 |
| zyga | joc: look at journal and run: | 13:47 |
| zyga | joc: udevadm control --reload-rules | 13:47 |
| zyga | joc: udevadm trigger | 13:47 |
| zyga | joc: the first one should not be required but it's safe to run anyway | 13:47 |
| zyga | joc: if I got this right it will export one GPIO to userspace | 13:47 |
| zyga | joc: if not, well, iterate :) | 13:47 |
| joc | zyga: got it, i'll just tidy up some testing i've been doing of netplan then get right on it | 13:48 |
| oparoz | Hello, is there a solution in the works to upgrade from one Snap to another? | 13:50 |
| zyga | joc: thanks, ping me when you got something | 13:50 |
| zyga | oparoz: ? | 13:50 |
| zyga | oparoz: can you explain what you mean by this | 13:50 |
| oparoz | zyga myappv1 to myappv2 | 13:50 |
| zyga | oparoz: and what are myappv1 and myappv2? | 13:51 |
| zyga | oparoz: snap names, snap versions, something else? | 13:51 |
| oparoz | zyga, we can't force people to upgrade to v2, so we need a new snap, but then how do people migrate for v1 to v2? | 13:51 |
| zyga | oparoz: why do you need a new snap? | 13:51 |
| zyga | oparoz: and what do you mean by "we cannot force people to upgrade" | 13:51 |
| oparoz | zyga, let's say I offer 3 years support for v1 and every time I release a new version | 13:52 |
| zyga | oparoz: ah I see what you mean now | 13:52 |
| oparoz | I mean every year, I release a new version | 13:52 |
| zyga | oparoz: right now you'd have to indeed offer a second snap if you want to have a different snap that can be concurrently updated (or not) | 13:53 |
| oparoz | zyga, so some users will want to stay on v1 for a long time and we can't just push v2 to the current dsnap | 13:53 |
| zyga | oparoz: using the content interface you could offer data migration | 13:53 |
| zyga | oparoz: I actually added support for this just now: https://github.com/snapcore/snapd/pull/2063 | 13:53 |
| mup | PR snapd#2063: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063> | 13:53 |
| oparoz | zyga, ah interesting, I'll look into that | 13:53 |
| oparoz | Thanks | 13:54 |
| Mirv | stupid questions again, if I extend make plugin, with eg. command.extend("INCLUDEPATH ..., why do I get "make I N C L U D E P A T H + = " / h " type of output? ... | 13:54 |
| cjwatson | Because you probably meant command.append | 13:54 |
| cjwatson | command.extend takes a sequence | 13:54 |
| zyga | yep | 13:55 |
| cjwatson | So either command.append("...") or command.extend(["...", "...", ...]) | 13:55 |
| Mirv | ah, thank you, I'm happy someone endures me :) | 13:55 |
| niemeyer | jdstrand: ping | 14:16 |
| jdstrand | niemeyer: hey | 14:16 |
| niemeyer | jdstrand: Heya | 14:17 |
| niemeyer | jdstrand: Today it's a bit of a critical day for us.. we want to get all the PRs to the freeze in place by the EOD | 14:17 |
| niemeyer | jdstrand: How're things looking on your end? | 14:17 |
| niemeyer | jdstrand: Would you be able to prioritize work that is freeze-related today? | 14:18 |
| jdstrand | niemeyer: those PRs pedronis mentioned already are prioritized. is there anything beyond that? | 14:18 |
| pedronis | jdstrand: I should get a couple more | 14:19 |
| pedronis | but nothing atm | 14:19 |
| niemeyer | jdstrand: These are the top ones | 14:19 |
| niemeyer | e.g. #2053 might be a good starting point | 14:20 |
| niemeyer | snapd#2053 | 14:20 |
| mup | PR snapd#2053: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2053> | 14:20 |
| jdstrand | niemeyer: that is next on the list | 14:21 |
| niemeyer | jdstrand: Thanks! | 14:21 |
| mup | PR snapd#2061 closed: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2061> | 14:22 |
| zyga | joc: any updates | 14:31 |
| joc | zyga: done with netplan switching over now | 14:35 |
| mup | PR snapcraft#846 closed: Release changelog for 2.19 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/846> | 14:35 |
| zyga | joc: thanks! | 14:35 |
| elopio | kyrofa: can you help me understand when to use SNAP_USER_DATA and when to use SNAP_USER_COMMON? | 15:04 |
| kyrofa | Hey elopio! I'd be happy to | 15:04 |
| kyrofa | What kind of app are we talking, here? | 15:05 |
| kyrofa | Or just generic? | 15:05 |
| elopio | kyrofa: I have two. syncthing, which is peer to peer file synchronization. And the mysql database of nylas sync-engine, which is an imap thing. | 15:06 |
| kyrofa | elopio, so obviously since snaps are often made up of many components, you often find yourself with a few different datasets that need to be saved | 15:08 |
| kyrofa | elopio, for each one, think about what should happen to it when an upgrade occurs | 15:08 |
| kyrofa | You want to make sure the stuff you save won't get in the way of upgrades or rollbacks | 15:08 |
| kyrofa | For example: does my dataset need to be mutated in some way for a few version? | 15:09 |
| kyrofa | Or is it just raw data that isn't really modified? | 15:09 |
| kyrofa | If new versions need to modify it, it's possible that the modifications aren't backward-compatible. Such datasets should probably go into SNAP_USER_DATA instead of COMMON, since each version has its own copy of that data | 15:10 |
| kyrofa | And rollbacks will work, even if you mutate the data in newer versions | 15:10 |
| elopio | it's hard, because I think the distinction is not designed in the tools. For example, syncthing has a home folder, where it stores the files to sync, and metadata. | 15:11 |
| kyrofa | elopio, another aspect to consider is how much space is taken by the dataset. Is it massive? Does it make sense to copy it for every upgrade? | 15:11 |
| elopio | I think the files to sync should be in common, the metadata in user_data, but I can't split them. | 15:11 |
| === om26er is now known as om26er1 | ||
| === om26er1 is now known as om26er | ||
| kyrofa | elopio, indeed | 15:12 |
| kyrofa | elopio, is it like the owncloud client? Where you add directories to a gui client? | 15:12 |
| elopio | kyrofa: yes. | 15:13 |
| kyrofa | elopio, or does it have only one directory? | 15:13 |
| elopio | you have one default directory, which probably should be in SNAP_USER_COMMON/Sync, and then you can add additional | 15:13 |
| kyrofa | And it saves metadata specific to that folder within each folder being synced? | 15:14 |
| kyrofa | It doesn't have any sort of central database? | 15:14 |
| elopio | kyrofa: it has a central config xml, and some certificates. | 15:15 |
| kyrofa | elopio, where does that central config go? | 15:16 |
| elopio | kyrofa: you start the server with synchting --home=$DIR. | 15:16 |
| elopio | the config ends in that dir. | 15:16 |
| kyrofa | elopio, could that not be SNAP_USER_DATA, then? | 15:17 |
| elopio | yes, but then the default SYNC dir would also end up in ~/snap/syncthing/rev/. | 15:19 |
| elopio | kyrofa: maybe you can comment here: https://github.com/syncthing/syncthing/pull/3636#discussion_r81488374 | 15:19 |
| mup | PR syncthing/syncthing#3636: Add the packaging metadata to build the syncthing snap <Created by elopio> <https://github.com/syncthing/syncthing/pull/3636> | 15:19 |
| elopio | I'm sure you can explain it better than me. | 15:19 |
| kyrofa | elopio, hmm... yeah, you probably don't want files accumulating there | 15:21 |
| kyrofa | elopio, it's too bad they're so tightly coupled! | 15:21 |
| elopio | kyrofa: the guy is really nice, I thing. So if we explain the thing, probably he can add a separate flag for default sync dir. | 15:22 |
| kyrofa | elopio, this looks like an old diff. What is SNAP_USER_DIR? | 15:23 |
| elopio | but as I understand, the answer to his question is: the config should be in SNAP_USER_DATA, just like it's currently doing. | 15:23 |
| elopio | kyrofa: a mistake. I just removed it. | 15:23 |
| kyrofa | Ah, now there's no flags | 15:23 |
| elopio | if you don't pass -home, it will use $HOME. | 15:23 |
| kyrofa | Okay, I'll make a comment here | 15:24 |
| elopio | thank you. | 15:24 |
| kyrofa | Argh, firefox! I had a comment all written out... | 15:26 |
| kyrofa | Oh it saved it. Nice | 15:27 |
| sergiusens | elopio hint, snapcraft/xenial-proposed ;-) | 15:30 |
| elopio | sergiusens: \o/ | 15:31 |
| elopio | ah, I don't have the tests prepared this time. | 15:31 |
| mup | PR snapd#2063 closed: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2063> | 15:34 |
| Croepha | hi, in core 16, can you disable nplan and use the older /etc/network/interfaces.d/... files? | 15:47 |
| kyrofa | Croepha, probably a question for ogra_ | 15:51 |
| mup | PR snapd#2057 closed: docs: remove references to removed buying features <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2057> | 15:55 |
| Croepha | on core is /etc/passwd supposed to be writeable ? | 15:55 |
| Croepha | kyrofa, thanks, but I think i figured out the nplan thing, it seems that if you just delete the nplan config, it will use the old config | 15:58 |
| Croepha | now im having a dfferent issue, on reboot, I cant login or change passwd, debug console works though, so I got a root terminal of sorts | 15:59 |
| mup | PR snapd#2041 closed: daemon: add `snap create-user --force-managed` support <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2041> | 16:06 |
| joc | zyga: it doesnt look like the command is being run | 16:18 |
| joc | zyga: it may be because there isnt an "add" event | 16:19 |
| joc | i don't see one if i use udevadm monitor | 16:19 |
| mup | PR snapd#2047 closed: snap: auto mount block devices and import assertions <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2047> | 16:25 |
| Croepha | ok, so after digging, it looks like core now uses pam_extrausers, so setting root passwd isn't going to be possible under this plan, and adding a user is adduser --extrausers ... | 16:25 |
| mup | PR snapd#2060 closed: many: change Connect to take ConnRef instead of strings <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2060> | 16:34 |
| modprobe__ | What plug should I use to get access to /dev/{,u}random? | 16:51 |
| mup | PR snapcraft#824 closed: Add `snapcraft create-key` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/824> | 17:08 |
| elopio | ogra_: are you around? There's a new snapcraft release in proposed. | 17:18 |
| sergiusens | marcoceppi or here if rocket is not possible :-) | 17:23 |
| zyga | pitti: hey | 17:24 |
| zyga | pitti: I'm trying to write an udev rule that will export a gpio by writing to /sys/class/gpio/export | 17:25 |
| zyga | pitti: the constraint is that after that I call "udevadm trigger" | 17:25 |
| zyga | pitti: is there anything sensible I can put into my rule to tie it into an event? | 17:25 |
| zyga | pitti: it should work both immediatly after "udevadm trigger" returns and on boot | 17:26 |
| zyga | joc: ^^ | 17:26 |
| kyrofa | jdstrand, it doesn't look lik /dev/random (and similar) are contained in the default profiles. Are they not safe for access? | 17:26 |
| zyga | kyrofa: you can easily consume all entropy | 17:26 |
| kyrofa | jdstrand, though getrandom is available | 17:26 |
| zyga | kyrofa: and DOS other programs | 17:26 |
| kyrofa | zyga, ah, sure. Do we have an interface for such things, then? | 17:27 |
| jdstrand | kyrofa: they are safe and available in all profiles via the base abstraction | 17:27 |
| kyrofa | jdstrand, ah ha, okay | 17:27 |
| zyga | kyrofa: ah, jdstrand knows better :) | 17:27 |
| jdstrand | kyrofa: you may want to look at 'apparmor_parser -p /path/to/profile' to see all the policy with the abstractions | 17:27 |
| * kyrofa needs to read the base abstraction | 17:27 | |
| zyga | jdstrand: so I _can_ write a heatdeathoftheuniverse snap? | 17:27 |
| kyrofa | Or that! Thanks jdstrand :) | 17:27 |
| mup | PR snapd#2053 closed: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2053> | 17:33 |
| mup | PR snapd#2051 closed: many: setup snapd macaroon for local users <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2051> | 17:34 |
| joc | zyga: yep that is the question i was trying to ask, bad English on my part! | 17:39 |
| joc | zyga: i just tried by removeing the ACTION= altogether | 17:39 |
| joc | (can't spell now either) | 17:40 |
| joc | zyga: it made sure the gpio was always exported, but you couldnt unexport as the rule was always matched | 17:40 |
| zyga | jdstrand: hey, can you please upload .42 from yakkety to xenial, ara's team will do the valiation and work on SRU | 17:43 |
| zyga | jdstrand: the lack of "undo" is fine for now | 17:44 |
| jdstrand | ok | 17:44 |
| zyga | jdstrand: thanks | 17:45 |
| mup | PR snapd#2066 opened: many: abbreviated forms of disconnect <Created by zyga> <Conflict> <https://github.com/snapcore/snapd/pull/2066> | 17:47 |
| mup | PR snapd#2067 opened: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2067> | 17:54 |
| elopio | kyrofa: sorry, you told me to test. I have this for you: | 18:07 |
| elopio | https://bugs.launchpad.net/snapcraft/+bug/1629955 | 18:07 |
| elopio | https://bugs.launchpad.net/snapcraft/+bug/1629957 | 18:07 |
| mup | Bug #1629955: rosdistro is not documented in the catkin plugin help <Snapcraft:Triaged> <https://launchpad.net/bugs/1629955> | 18:07 |
| mup | Bug #1629957: When I try to build a snap with the wrong catkin rosdistro, there is no good error <Snapcraft:Triaged> <https://launchpad.net/bugs/1629957> | 18:07 |
| kyrofa | elopio, ah, very good! | 18:08 |
| kyrofa | elopio, this is why I ask you to test ;) | 18:08 |
| kyrofa | Man, rosdistro has been around forever, I didn't even check the docs assuming they were good :P | 18:08 |
| kyrofa | elopio, blocking, you think? Or no? | 18:08 |
| elopio | sometimes I get depressed. No piece of software ever works for me on the first try. /o\ | 18:09 |
| kyrofa | (I don't think these are new bugs) | 18:09 |
| elopio | kyrofa: no, medium and low. To fix when you have some time. | 18:09 |
| kyrofa | elopio, well good find, thank you! | 18:09 |
| kyrofa | elopio, you're QA. Finding bugs should make your day! | 18:10 |
| elopio | that's ok when I try to break it on purpose. Not so nice when I'm just trying to use things. | 18:10 |
| mup | PR snapd#1970 closed: interface/builtin: add ptrace support to system-trace <Created by niedbalski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1970> | 18:12 |
| mup | PR snapd#1945 closed: debian, tests: add trusty tests <Reviewed> <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1945> | 18:14 |
| modprobe__ | jdstrand, kyrofa: Does that mean /dev/urandom is available by default? It appears not to be working, though I don't know of an easy way to pop a shell in the sandbox to find out for sure. | 18:29 |
| modprobe__ | As to consuming all available entropy, random has that issue, but not urandom, and I understand that urandom is regarded as every bit as good of a CSPRNG as random (better, since it should always work) | 18:31 |
| mup | PR snapd#2055 closed: interfaces/policy,overlord: check connection requests against the declarations in ifacestate <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2055> | 18:35 |
| mup | PR snapd#2062 closed: interfaces/policy: introduce InstallCandidate and its checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2062> | 18:35 |
| kyrofa | modprobe__, indeed, it should work | 18:39 |
| mup | PR snapd#2044 closed: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044> | 18:42 |
| modprobe__ | kyrofa: Hmm... Well my program indicates pretty clearly that it doesn't. Botan throws an exception saying "System_RNG failed to open RNG device" and looking at its source, the only way that exception gets thrown is if opening /dev/urandom fails. | 18:45 |
| kyrofa | modprobe__, I'm not claiming you aren't running into issues, I'm just saying confinement shouldn't be causing it :) . Do you see apparmor denials in syslog (or from snappy-debug)? | 18:47 |
| modprobe__ | kyrofa: Ahh yes, I see this in dmesg: audit: type=1400 audit(1475513126.687:37): apparmor="DENIED" operation="open" profile="snap.stakeweightedvoting.app" name="/dev/urandom" pid=6341 comm="VotingApp" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0 | 18:54 |
| kyrofa | modprobe__, it's trying to _write_ to it? | 18:54 |
| kyrofa | Indeed, the profile is only r | 18:54 |
| modprobe__ | https://botan.randombit.net/doxygen/system__rng_8cpp_source.html (line 77) apparently, it is... | 18:55 |
| kyrofa | modprobe__, I can't imagine why... ? | 18:55 |
| modprobe__ | Looks like a bug in botan. | 18:56 |
| kyrofa | Agreed | 18:56 |
| modprobe__ | I'm reporting it to them. In the meantime, can you think of any workaround I can use until they release a fix? | 19:05 |
| kyrofa | modprobe__, would it be an easy patch? | 19:06 |
| modprobe__ | Yeah, I could just use a custom build of botan... | 19:06 |
| kyrofa | modprobe__, yeah, that's what I'd recommend | 19:06 |
| modprobe__ | Should literally just be changing that one line. | 19:06 |
| kyrofa | modprobe__, as a plus, you can propose it back upstream ;) | 19:06 |
| modprobe__ | Yeah, I just made an issue on their github repo and I'll follow it up with a pull request soon, assuming it passes the smoke test. :) | 19:09 |
| elopio | cprov: I don't quite understand the sign-build --local. It always replies that "A signed build assertion for this snap already exists." | 19:12 |
| elopio | ah, I think that a previous command left the -build file. But it was empty. | 19:14 |
| elopio | I'll try to reproduce that. | 19:14 |
| sergiusens | elopio you only sign once per build | 19:16 |
| elopio | sergiusens: cprov: https://bugs.launchpad.net/snapcraft/+bug/1629984 | 19:19 |
| mup | Bug #1629984: trying to sign-build without keys leaves a -build file, empty <Snapcraft:Triaged> <https://launchpad.net/bugs/1629984> | 19:19 |
| modprobe__ | kyrofa: Apparently writing to random or urandom is a way to add entropy to the kernel pool. Maybe the AppArmor profile should be updated? | 19:21 |
| kyrofa | modprobe__, hmm interesting, jdstrand is the guy to consider that. Not sure what the ramifications would be | 19:21 |
| jdstrand | we'd need a new interface for that | 19:22 |
| jdstrand | I think. please file a bug | 19:23 |
| kyrofa | modprobe__, regardless, the fact that the thing dies if it can't add entropy still seems like a bug | 19:24 |
| mup | PR snapd#2059 closed: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2059> | 19:25 |
| modprobe__ | kyrofa: Very true. | 19:25 |
| elopio | cprov: now without a body, I get: "no assertion found in request body". Tried on staging and production with a test user. | 19:25 |
| elopio | is that because my user is not allowed, or something? | 19:26 |
| modprobe__ | jdstrand: Is that a bug on snapd? | 19:28 |
| kyrofa | modprobe__, indeed | 19:31 |
| modprobe__ | Alright, I'll file that soon | 19:33 |
| cprov | elopio: thanks for filing the bug, the stray/empty -build should not be there. | 19:48 |
| elopio | np | 19:49 |
| elopio | ralsina: I'm getting this: | 19:49 |
| elopio | $ snapcraft validate u1test20161003 ubuntu-core=1 | 19:49 |
| elopio | Getting details for u1test20161003 | 19:49 |
| elopio | Snap 'u1test20161003' was not found in the 'stable' channel. | 19:49 |
| elopio | But I've just released the snap to stable on staging. Am I doing something wrong herE? | 19:49 |
| elopio | sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1629472/comments/3 | 19:51 |
| mup | Bug #1629472: [SRU] New stable micro release 2.19 <verification-needed> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1629472> | 19:51 |
| elopio | I'm going for lunch. I'm just missing the happy paths of gated and validate. | 19:51 |
| marcoceppi | sergiusens: o/ | 19:52 |
| marcoceppi | sergiusens: I'm technically not working today, so I haven't been around my computer as much | 19:53 |
| cprov | elopio: ralsina is off today, can you run `snapcraft gated u1test20161003` ? | 19:53 |
| elopio | cprov: $ snapcraft gated u1test20161003 | 19:54 |
| elopio | Name Approved | 19:54 |
| elopio | prints nothing. I reported a bug about that, too. | 19:54 |
| elopio | https://bugs.launchpad.net/snapcraft/+bug/1629991 | 19:54 |
| mup | Bug #1629991: snapcraft gated prints no message when there are no gated snaps <Snapcraft:New> <https://launchpad.net/bugs/1629991> | 19:54 |
| cprov | elopio: I can see your rev. 1 in stable, curl -s -H 'X-Ubuntu-Series: 16' https://search.apps.staging.ubuntu.com/api/v1/snaps/details/u1test20161003?channel=stable | jq-cprov.jq '.revision' | 19:59 |
| elopio | cprov: yes. But the message says it's not found. | 20:00 |
| cprov | elopio: can you try `snapcraft validate u1test20161003 ubuntu-core=1` again, so we can confirm it was hitting bad-caching in staging CPI | 20:00 |
| elopio | cprov: done. Same error. | 20:00 |
| cprov | elopio: okay, it will need some code changes as well, I've mentioned multiple time in the review that gating snap-id would be better resolved via the SCA account-info, somehow it slip and the code in trunk is using CPI. I will get into this asap | 20:02 |
| cprov | elopio: is it blocking snapcraft release ? | 20:02 |
| elopio | cprov: thanks. And I don't know if it should block it. It's ugly to release a command that doesn't work, but sergiusens can just not mention it in the release notes. | 20:03 |
| elopio | sergiusens: your call. | 20:03 |
| mup | PR snapd#2046 closed: cmd, disconnect: abbreviated forms of disconnect <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2046> | 20:04 |
| modprobe__ | kyrofa, jdstrand: Bug report filed at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1629996 | 20:06 |
| mup | Bug #1629996: Cannot open /dev/random and /dev/urandom for write <snapd (Ubuntu):New> <https://launchpad.net/bugs/1629996> | 20:06 |
| sergiusens | cprov yeah, big branches can cause that ;-) | 20:06 |
| mup | PR snapd#1874 closed: snap: support assertion references in `snap prepare-image` <Reviewed> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1874> | 20:06 |
| cprov | sergiusens: good point | 20:06 |
| mup | PR snapd#1767 closed: overlord, daemon: add collect attribute hooks <Reviewed> <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1767> | 20:07 |
| mup | PR snapd#1613 closed: interfaces/builtin: add dbus-app interface <Blocked> <Reviewed> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1613> | 20:09 |
| mup | PR snapd#2067 closed: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2067> | 20:10 |
| lool | ogra_: thanks, description of the boot files is pretty slick | 20:11 |
| jgdx | what's the status on Ubuntu Core on RP3? Google returns a AskUbuntu link which is not super up to date | 20:11 |
| jgdx | ogra_, you know? ^ | 20:11 |
| lool | ogra_: I was actually pinging because of the upcoming dragonboard 600 that you might have seen announced recently | 20:12 |
| lool | jgdx: pi ? | 20:12 |
| lool | jgdx: there's a beta image for rpi3 like for the other supported platforms: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ | 20:12 |
| jgdx | lool, cool, thank you | 20:14 |
| mup | PR snapd#2068 opened: many: preparations for switching most of autoconnect to use the declarations <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/2068> | 20:16 |
| lool | ogra_: the 600 doesn't have an u-boot port, so we can't follow the same path | 20:17 |
| lool | ogra_: and there's worth, there might be boards requiring UFS too; at which point we will need a much more complete u-boot | 20:17 |
| lool | *worse | 20:17 |
| elopio | cprov: sergiusens: also branches without staging integration tests ;) | 20:20 |
| cprov | elopio: yeah, it will definitely serve a lesson. | 20:22 |
| mup | PR snapd#2069 opened: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <https://github.com/snapcore/snapd/pull/2069> | 20:53 |
| sergiusens | elopio cprov from the point of view of the project, it is already released, so not much we can do as soon as it lands on master | 20:56 |
| sergiusens | elopio I propose to you to do this testing now for history and status ;-) | 20:57 |
| jgdx | pi3 using that beta image gives me four berries, but nothing more | 20:58 |
| cprov | elopio: you have to set a new env var for staging UBUNTU_STORE_SEARCH_ROOT_URL='https://search.apps.staging.ubuntu.com/' to make validation work :-/ | 21:18 |
| cprov | elopio: that's why you gating snap was not found. | 21:19 |
| mup | PR snapd#2069 closed: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2069> | 21:27 |
| mwhudson | niemeyer: hey, am i right to think that console-conf should not run if the device is managed? | 21:36 |
| mwhudson | niemeyer: there is a potential hole where if you use a autoload.assert file to add a user that only has ssh keys and no password and the default network config doesn't work for whatever reason you'll be stuck | 21:37 |
| mwhudson | the alternative is that console-conf still runs but only presents the network config screen, not the "please enter email" screen | 21:38 |
| mup | PR snapd#2070 opened: all: move from ubuntu-core to core by default, but still support ubuntu-core as core <Created by chipaca> <https://github.com/snapcore/snapd/pull/2070> | 21:47 |
| mup | PR snapcraft#847 opened: Implementing channel-closing <Created by cprov> <https://github.com/snapcore/snapcraft/pull/847> | 21:50 |
| kgunn | kyrofa: you about? | 21:56 |
| kyrofa | kgunn, I am, what's up? | 21:56 |
| kgunn | kyrofa: curious, what is the philosophy behind something becoming an official snapcraft part ? | 21:56 |
| kgunn | https://wiki.ubuntu.com/snapcraft/parts | 21:57 |
| kgunn | i had someone ask about qtmir and mirclient libs becoming "snapcraft parts" | 21:57 |
| kgunn | but unsure it makes sense | 21:57 |
| kgunn | as these are something that are currently in the archive and can easily be listed as a part | 21:57 |
| kgunn | in the yaml | 21:58 |
| kgunn | under a nil plugin | 21:58 |
| kyrofa | kgunn, anything that seems generally useful. If building qtmir for snappy takes a lot of weird config flags, for example, you could make it a part so other people could just say "build qtmir" instead of "ack, how do I build qtmir" | 21:58 |
| kgunn | kyrofa: hmm, yeah i don't think there's anything special there... | 21:58 |
| kgunn | definitely not weird | 21:59 |
| kyrofa | Yeah, if they can just use the archive packages then it's less useful. Still potentially useful from the point of view that it's less typing, but it's of limited usefulness, certainly | 21:59 |
| kyrofa | kgunn, nothing wrong with adding it, but don't feel obligated | 21:59 |
| kyrofa | kgunn, now, if you find yourself constantly asking "how do I get mir in a snap," then you could save yourself some time | 22:00 |
| kyrofa | Not asking, answering | 22:00 |
| sergiusens | cprov elopio fwiw, it is in the instructions and I was succesful gating and validating a bunch of snaps (even private ones iirc) | 22:01 |
| Pharaoh_Atem | zyga: this could be quite interesting for fedora's snappy stuff: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FUWLJQYQJAGNGSSFTCA3ZEHAX43LJ7UU/ | 22:01 |
| kgunn | kyrofa: so it can be used as a template aswell ? | 22:02 |
| kgunn | i mean the mir-client snap is a template of sorts...but the qtmir and libmirclient are just pkg listings under parts | 22:02 |
| kgunn | the only thing of interest is the helper file | 22:03 |
| kgunn | that sets environ flags | 22:03 |
| kgunn | like http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/client-start | 22:04 |
| mwhudson | wheee funtimes https://github.com/snapcore/snapd/pull/2044#issuecomment-251241964 | 22:09 |
| mup | PR snapd#2044: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044> | 22:09 |
| mup | Bug #1630036 opened: auto import of assertions fails for devices present at boot <Snappy:New> <https://launchpad.net/bugs/1630036> | 22:43 |
| jdstrand | zyga: fyi, filed bug #1630040 | 23:11 |
| mup | Bug #1630040: [SRU] update to 1.0.42 <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress by zyga> <snap-confine (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1630040> | 23:11 |
| jdstrand | zyga: will upload in a bit | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!