[00:29] PR snapd#2054 closed: client,daemon,cmd/snap: improve create-user APIs === j is now known as Guest16612 [03:42] is it possible to get snapd to forget about an assertion? === King_InuYasha is now known as Son_Goku [06:54] hey [06:54] mwhudson: I think only with a new assertion [06:54] mwhudson: (or with rm -f) [07:25] PR snapd#2056 opened: interfaces: add Plug/Slot/Connection reference helpers [07:40] morning [08:03] PR snapd#2056 closed: interfaces: add Plug/Slot/Connection reference helpers [08:16] PR snapd#2057 opened: docs: remove references to removed buying features [08:17] PR snapd#2058 opened: interfaces: add ofono interface [08:21] hello :) [08:21] I need some help with an error message during dist-upgrade on X [08:21] http://pastebin.com/HUcC3wWg [08:22] the initial problem I was trying to solve was this: [08:25] 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] it I receive that error message... [08:25] any ideas? :) [08:32] PR snapd#2059 opened: interfaces: add repo.ResolveConnect that handles name resolution [08:34] 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:39] thanks didrocks :) [09:28] PR snapd#2060 opened: many: change Connect to take ConnRef instead of strings [09:52] PR snapd#2061 opened: interfaces: add dummy implementation of ResolveConnect [09:55] zyga: hey! It seems that if a service fails to start at installation time, the snap is removed [09:55] zyga: that makes it hard for debugging, any tip about it? [09:55] davidcalle: FYI (on the doc) [10:30] didrocks: hey [10:30] hikiko: looking [10:31] hikiko: that's something that was only available in -proposed [10:32] hikiko: this is something that has to be fixed in the nvidia packaging but I believe it was removed already [10:32] hikiko: can you check if you can downgrade to the non-proposed package and see if the problem goes away [10:32] didrocks: I wasn't aware of it [10:32] didrocks: I don't know what is the plan about this, sorry [10:33] zyga, how can I downgrade it? [10:39] hikiko: I think you can try to install it with "apt install package=version" [10:40] hikiko: alternatively edit the dpkg maintainer script on your disk not to touch that mount unit [10:40] 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] zyga, and where can I find the version to which I have to downgrade? [10:40] hikiko: try apt-cache policy package [10:41] this will show you available versions [10:41] thanks zyga :) I'll try [10:41] (the package in question is the one that fails because of the maintianer script) [10:41] *maintainer [10:51] PR snapd#2062 opened: interfaces/policy: introduce InstallCandidate and its checks === hikiko is now known as hikiko|ln [11:46] PR snapd#2063 opened: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface [11:47] jdstrand: hey, you may want to review this one ^6 [12:04] zyga: hikiko|ln: btw, easier for downgrading, you can do apt install package/ (like package/yakkety for instance) [12:05] didrocks, if I try to do that the proposed are selected [12:06] no [12:06] if you don't set yakkety-proposed, and only yakkety, it will select yakkety [12:06] (with -f to force a downgrade ofc) [12:07] # apt install libcuda1-361/xenial -f [12:07] Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB] [12:08] this is the nvidia package [12:08] not libcuda1-361 [12:08] yup it's a dependency [12:08] so ofc, the other packages follow the general scheme [12:08] oh ok :) [12:08] so, you need to list it [12:08] # apt install libcuda1-361/xenial nvidia-367/xenial -f [12:08] and so on… :) [12:09] I need to remove the dependencies and libcuda didrocks [12:09] should I first downgrade then remove? [12:09] I would say yeah, first downgrade everything to remove -proposed components [12:09] and then remove [12:09] (get in a consistent state first) [12:10] ~# apt install libcuda1-361/xenial nvidia-367/xenial nvidia-opencl-icd-367/xenial nvidia-prime/xenial nvidia-settings/xenial -f [12:10] Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB] [12:11] it seems to ignore my setting [12:11] hum… that's weird [12:11] what if you only do apt install nvidia-367/xenial -f only? [12:12] https://paste.ubuntu.com/23269943/ didrocks [12:16] hikiko|ln: I think you have another package that forces you to get that version [12:17] I've purged nvidia* didrocks [12:17] can I see which package it is somehow? [12:17] and here we go [12:17] https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-367 [12:17] -367 is only available in -proposed [12:17] that's why he didn't follow your guidance to prefer the /xenial one :p [12:17] and I didn't have it installed [12:18] so what should I do? [12:18] I'm pretty sur eyou have something like libcuda1-367 or anything depending on it [12:18] well, you did purge it, right? [12:18] the initial problem is to remove libcuda1-361 [12:18] yup [12:18] apt-cache rdepends nvidia-367 [12:18] anything there? ^ [12:18] Reverse Depends: [12:18] libcuda1-367 [12:18] nvidia-opencl-icd-367 [12:18] nvidia-367-dev [12:18] nvidia-361 [12:18] yeah, so you need to remove any of those installed [12:19] just purge them [12:21] 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. [12:21] they seem purged [12:21] good :) [12:21] maybe rdepends libcuda1-361? [12:21] you was able to delete it as well? [12:21] now, try to remove it [12:21] as it's what you wanted IIRC [12:22] same [12:22] E: Sub-process /usr/bin/dpkg returned an error code (1) [12:23] maybe zyga telling to downgrade nvidia on the proposed didn't indicate the right package [12:23] (I didn't follow closely) [12:23] ensure you don't have snapd from proposed from what I understand [12:24] mmm how? [12:24] apt-cache policy snapd [12:24] do you have the proposed version installed? [12:24] yes [12:24] so, same [12:24] revert to the one on xenial [12:25] same :/ [12:25] if I purge snapd [12:26] remove the package and reinstall it? === hikiko|ln is now known as hikiko [12:27] still :p just tried that [12:31] ogra_: Hey, around? [12:31] ogra_: were you the one implementing the dragonboard boot support? :-) [12:33] zyga, ping [12:40] PR snapd#2064 opened: Adding new AutopilotIntrospectionInterface [13:02] ara: hey [13:02] ara: how can I help you [13:02] zyga, hey! I was wondering how the snap-confine SRU to xenial was going [13:02] zyga, any news? [13:03] zyga, (what's the bug report to track it?) [13:18] 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] ara: I won't have time for this today as we're freezing now and I need to finish features first [13:19] zyga, where is the bug that tracks the SRU? [13:19] 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] ara: there's no one bug, each bug has SRU data now [13:19] zyga, perfect, I will check on the report page [13:19] ara: look at milestones .40, .41 an.42 [13:19] ara: .42 has two bugs that don't have SRU data but I can add that quickly; this was a tiny release [13:20] ara: if you can get me someone to work on validation I will save a lot of time [13:20] 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] ara: no, ah, sorry, too many facts lately, .41 was in -proposed but we removed it and someone should upload .42 now [13:21] ara: (there's .42.1 but it doens't have to be released now) [13:21] zyga, can you organize uploading it, please? I can help verifying it [13:22] ara: yes, I can [13:22] ara: thank you :) [13:22] zyga, thanks you! [13:22] zyga, *thank [13:33] joc: ok, branch comig up, just a simple unit test to tie it together [13:33] joc: I will need you to add this udev rule manually to your device and see if it does the right thing [13:34] joc: (no need to build/alter snapd) [13:40] 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:41] * ogra_ goes back to uniting :) [13:41] zyga: ack [13:45] joc: ok, pull request is up, mup will share the link in a sec [13:45] PR snapd#2065 opened: interfaces/builtin: use udev to export GPIOs to userspace [13:46] joc: look at tests, get the rule there and stick it into /lib/udev/rules.d/foo.rules [13:47] joc: look at journal and run: [13:47] joc: udevadm control --reload-rules [13:47] joc: udevadm trigger [13:47] joc: the first one should not be required but it's safe to run anyway [13:47] joc: if I got this right it will export one GPIO to userspace [13:47] joc: if not, well, iterate :) [13:48] zyga: got it, i'll just tidy up some testing i've been doing of netplan then get right on it [13:50] Hello, is there a solution in the works to upgrade from one Snap to another? [13:50] joc: thanks, ping me when you got something [13:50] oparoz: ? [13:50] oparoz: can you explain what you mean by this [13:50] zyga myappv1 to myappv2 [13:51] oparoz: and what are myappv1 and myappv2? [13:51] oparoz: snap names, snap versions, something else? [13:51] 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] oparoz: why do you need a new snap? [13:51] oparoz: and what do you mean by "we cannot force people to upgrade" [13:52] zyga, let's say I offer 3 years support for v1 and every time I release a new version [13:52] oparoz: ah I see what you mean now [13:52] I mean every year, I release a new version [13:53] 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] 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] oparoz: using the content interface you could offer data migration [13:53] oparoz: I actually added support for this just now: https://github.com/snapcore/snapd/pull/2063 [13:53] PR snapd#2063: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface [13:53] zyga, ah interesting, I'll look into that [13:54] Thanks [13:54] 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] Because you probably meant command.append [13:54] command.extend takes a sequence [13:55] yep [13:55] So either command.append("...") or command.extend(["...", "...", ...]) [13:55] ah, thank you, I'm happy someone endures me :) [14:16] jdstrand: ping [14:16] niemeyer: hey [14:17] jdstrand: Heya [14:17] 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] jdstrand: How're things looking on your end? [14:18] jdstrand: Would you be able to prioritize work that is freeze-related today? [14:18] niemeyer: those PRs pedronis mentioned already are prioritized. is there anything beyond that? [14:19] jdstrand: I should get a couple more [14:19] but nothing atm [14:19] jdstrand: These are the top ones [14:20] e.g. #2053 might be a good starting point [14:20] snapd#2053 [14:20] PR snapd#2053: interfaces/policy: implement snap-id/publisher-id checks [14:21] niemeyer: that is next on the list [14:21] jdstrand: Thanks! [14:22] PR snapd#2061 closed: interfaces: add dummy implementation of ResolveConnect [14:31] joc: any updates [14:35] zyga: done with netplan switching over now [14:35] PR snapcraft#846 closed: Release changelog for 2.19 [14:35] joc: thanks! [15:04] kyrofa: can you help me understand when to use SNAP_USER_DATA and when to use SNAP_USER_COMMON? [15:04] Hey elopio! I'd be happy to [15:05] What kind of app are we talking, here? [15:05] Or just generic? [15:06] 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:08] 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] elopio, for each one, think about what should happen to it when an upgrade occurs [15:08] You want to make sure the stuff you save won't get in the way of upgrades or rollbacks [15:09] For example: does my dataset need to be mutated in some way for a few version? [15:09] Or is it just raw data that isn't really modified? [15:10] 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] And rollbacks will work, even if you mutate the data in newer versions [15:11] 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] 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] I think the files to sync should be in common, the metadata in user_data, but I can't split them. === om26er is now known as om26er1 === om26er1 is now known as om26er [15:12] elopio, indeed [15:12] elopio, is it like the owncloud client? Where you add directories to a gui client? [15:13] kyrofa: yes. [15:13] elopio, or does it have only one directory? [15:13] you have one default directory, which probably should be in SNAP_USER_COMMON/Sync, and then you can add additional [15:14] And it saves metadata specific to that folder within each folder being synced? [15:14] It doesn't have any sort of central database? [15:15] kyrofa: it has a central config xml, and some certificates. [15:16] elopio, where does that central config go? [15:16] kyrofa: you start the server with synchting --home=$DIR. [15:16] the config ends in that dir. [15:17] elopio, could that not be SNAP_USER_DATA, then? [15:19] yes, but then the default SYNC dir would also end up in ~/snap/syncthing/rev/. [15:19] kyrofa: maybe you can comment here: https://github.com/syncthing/syncthing/pull/3636#discussion_r81488374 [15:19] PR syncthing/syncthing#3636: Add the packaging metadata to build the syncthing snap [15:19] I'm sure you can explain it better than me. [15:21] elopio, hmm... yeah, you probably don't want files accumulating there [15:21] elopio, it's too bad they're so tightly coupled! [15:22] 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:23] elopio, this looks like an old diff. What is SNAP_USER_DIR? [15:23] 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] kyrofa: a mistake. I just removed it. [15:23] Ah, now there's no flags [15:23] if you don't pass -home, it will use $HOME. [15:24] Okay, I'll make a comment here [15:24] thank you. [15:26] Argh, firefox! I had a comment all written out... [15:27] Oh it saved it. Nice [15:30] elopio hint, snapcraft/xenial-proposed ;-) [15:31] sergiusens: \o/ [15:31] ah, I don't have the tests prepared this time. [15:34] PR snapd#2063 closed: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface [15:47] hi, in core 16, can you disable nplan and use the older /etc/network/interfaces.d/... files? [15:51] Croepha, probably a question for ogra_ [15:55] PR snapd#2057 closed: docs: remove references to removed buying features [15:55] on core is /etc/passwd supposed to be writeable ? [15:58] 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:59] 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 [16:06] PR snapd#2041 closed: daemon: add `snap create-user --force-managed` support [16:18] zyga: it doesnt look like the command is being run [16:19] zyga: it may be because there isnt an "add" event [16:19] i don't see one if i use udevadm monitor [16:25] PR snapd#2047 closed: snap: auto mount block devices and import assertions [16:25] 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:34] PR snapd#2060 closed: many: change Connect to take ConnRef instead of strings [16:51] What plug should I use to get access to /dev/{,u}random? [17:08] PR snapcraft#824 closed: Add `snapcraft create-key` [17:18] ogra_: are you around? There's a new snapcraft release in proposed. [17:23] marcoceppi or here if rocket is not possible :-) [17:24] pitti: hey [17:25] pitti: I'm trying to write an udev rule that will export a gpio by writing to /sys/class/gpio/export [17:25] pitti: the constraint is that after that I call "udevadm trigger" [17:25] pitti: is there anything sensible I can put into my rule to tie it into an event? [17:26] pitti: it should work both immediatly after "udevadm trigger" returns and on boot [17:26] joc: ^^ [17:26] jdstrand, it doesn't look lik /dev/random (and similar) are contained in the default profiles. Are they not safe for access? [17:26] kyrofa: you can easily consume all entropy [17:26] jdstrand, though getrandom is available [17:26] kyrofa: and DOS other programs [17:27] zyga, ah, sure. Do we have an interface for such things, then? [17:27] kyrofa: they are safe and available in all profiles via the base abstraction [17:27] jdstrand, ah ha, okay [17:27] kyrofa: ah, jdstrand knows better :) [17:27] 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] jdstrand: so I _can_ write a heatdeathoftheuniverse snap? [17:27] Or that! Thanks jdstrand :) [17:33] PR snapd#2053 closed: interfaces/policy: implement snap-id/publisher-id checks [17:34] PR snapd#2051 closed: many: setup snapd macaroon for local users [17:39] zyga: yep that is the question i was trying to ask, bad English on my part! [17:39] zyga: i just tried by removeing the ACTION= altogether [17:40] (can't spell now either) [17:40] zyga: it made sure the gpio was always exported, but you couldnt unexport as the rule was always matched [17:43] jdstrand: hey, can you please upload .42 from yakkety to xenial, ara's team will do the valiation and work on SRU [17:44] jdstrand: the lack of "undo" is fine for now [17:44] ok [17:45] jdstrand: thanks [17:47] PR snapd#2066 opened: many: abbreviated forms of disconnect [17:54] PR snapd#2067 opened: cmd/snap: trivial auto-import and download tweaks [18:07] kyrofa: sorry, you told me to test. I have this for you: [18:07] https://bugs.launchpad.net/snapcraft/+bug/1629955 [18:07] https://bugs.launchpad.net/snapcraft/+bug/1629957 [18:07] Bug #1629955: rosdistro is not documented in the catkin plugin help [18:07] Bug #1629957: When I try to build a snap with the wrong catkin rosdistro, there is no good error [18:08] elopio, ah, very good! [18:08] elopio, this is why I ask you to test ;) [18:08] Man, rosdistro has been around forever, I didn't even check the docs assuming they were good :P [18:08] elopio, blocking, you think? Or no? [18:09] sometimes I get depressed. No piece of software ever works for me on the first try. /o\ [18:09] (I don't think these are new bugs) [18:09] kyrofa: no, medium and low. To fix when you have some time. [18:09] elopio, well good find, thank you! [18:10] elopio, you're QA. Finding bugs should make your day! [18:10] that's ok when I try to break it on purpose. Not so nice when I'm just trying to use things. [18:12] PR snapd#1970 closed: interface/builtin: add ptrace support to system-trace [18:14] PR snapd#1945 closed: debian, tests: add trusty tests [18:29] 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:31] 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:35] PR snapd#2055 closed: interfaces/policy,overlord: check connection requests against the declarations in ifacestate [18:35]