| mup | PR snapcraft#1052 closed: Make git pulls less error prone due to history changes <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1052> | 00:01 |
|---|---|---|
| mup | Bug #1645445 changed: Turtlebot needs /dev/kobuki <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1645445> | 00:19 |
| mup | PR snapd#2806 opened: interfaces/io-ports-control: use /dev/port, not /dev/ports <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2806> | 00:21 |
| mup | Bug #1646559 changed: should periodically refresh ssh keys that were obtained from SSO/store for local users <snapd:Confirmed> <https://launchpad.net/bugs/1646559> | 00:22 |
| mup | Bug #1662723 opened: Removing a snap with `snap remove <app>` doesn't remove everything <Snappy:New> <https://launchpad.net/bugs/1662723> | 00:40 |
| mup | Bug #1662723 changed: Removing a snap with `snap remove <app>` doesn't remove everything <Snappy:Invalid> <https://launchpad.net/bugs/1662723> | 01:22 |
| === markusfluer1 is now known as markusfluer | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1116 opened: Changed "snappy try" to "snap try" <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/1116> | 03:49 |
| mup | Bug #1634890 changed: File system not resized in some devices <Snappy:Expired> <https://launchpad.net/bugs/1634890> | 04:17 |
| mup | PR snapcraft#1117 opened: [wip] build and push the API docs to github pages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1117> | 06:04 |
| mup | Bug #1662772 opened: systemd[1]: Failed to start Set the hostname to the value stored on the writable partition <snappy-set-hostname.service> <Snappy:New> <https://launchpad.net/bugs/1662772> | 06:27 |
| mup | PR snapcraft#1075 closed: travis: allow to pass --channels parameter to generate proper config <Created by 3v1n0> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1075> | 06:31 |
| mup | PR snapcraft#1118 opened: Trigger beta tests on travis every day <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1118> | 06:31 |
| mup | PR snapcraft#1109 closed: meta: allow `post-stop-command` for an app entry in `apps` <Created by elespike> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1109> | 06:40 |
| stub | Snaps don't install in lxd containers unless the squashfuse package is installed, but I can't find the relevant bug report to link. | 08:10 |
| stub | Found it: Bug #1628289 (although it claims to be FIX COMMITTED in xenial, comments indicate otherwise) | 08:14 |
| mup | Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Triaged> <squashfuse (Ubuntu):Confirmed for doko> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289> | 08:14 |
| kalikiana | Hrm. Issues like bug 1652643 make a snappy life tedious at times. Bonus points for letting a non-tech-aficionado use LibreOffice on one of my machines. | 08:33 |
| mup | Bug #1652643: LibreOffice Snap: unable to access documents in some nested direcotries <libreoffice> <snap> <Snappy:Confirmed> <https://launchpad.net/bugs/1652643> | 08:33 |
| mup | Bug #1612453 changed: `snap connect` requires me to type ubuntu-core <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1612453> | 08:37 |
| jamespage | morning all | 08:56 |
| jamespage | I have a question re auto-aliases and conflicts with other snaps | 08:56 |
| jamespage | jdstand kindly setup auto-aliases for the openstackclients snap yesterday | 08:57 |
| jamespage | however that had a slightly un-intended side effect that now the glance, nova etc snaps are not co-installable with the openstackclients snap, as it ships aliases for commands with the same name as those sanps | 08:58 |
| jamespage | for example | 08:58 |
| jamespage | error: cannot install "glance": snap "glance" command namespace conflicts with enabled alias "glance" for "openstackclients" | 08:58 |
| jamespage | however the glance snap does not provide a 'glance' command :-) | 09:00 |
| pedronis | jamespage: well it could at some point | 09:05 |
| pedronis | because is its snap name | 09:05 |
| jamespage | pedronis, I guess my question is what is the conflict resolution strategy for this type of thing? | 09:05 |
| jamespage | if this is always enforced in this way, we should have policy that means one snap can't auto-aliase a command with the name of another snap right? | 09:06 |
| pedronis | jamespage: yes, that was the idea | 09:06 |
| pedronis | jamespage: I understand this is annoying, the issue here is that in theory any snap has the right to a command called like it | 09:09 |
| jamespage | pedronis, I'm ok with that, I guess my challenge is how that and auto-aliases should be managed | 09:10 |
| jamespage | ideas - when you install the glance snap on a system that already has openstackclients, we might un-alias a conflicting glance command/aliase, and let glance own it. | 09:11 |
| pedronis | jamespage: but is annoying if server/client snap have pairs where we call server foo and client has a command foo | 09:11 |
| jamespage | pedronis, yup that's this use-case | 09:11 |
| jamespage | pedronis, I'll raise a bug so we can track this better | 09:12 |
| zioproto | hello there | 09:12 |
| zioproto | jamespage, unalias sounds bad | 09:13 |
| zioproto | usually people on the openstack controller have both the glance-api that comes with the glance snap and the glance client utility | 09:14 |
| zioproto | they need to work both at the same time | 09:14 |
| jamespage | zioproto, oh I agree | 09:15 |
| jamespage | zioproto, its common todo that | 09:15 |
| jamespage | letme raise this bug | 09:15 |
| pedronis | jamespage: the problem is that well known aliases are also for scripts so random unaliasing them is bad | 09:15 |
| zioproto | paste here the bug link so I can subscribe to it | 09:15 |
| pedronis | mmh, what I mean is more that we need predictable behavior | 09:16 |
| jamespage | https://bugs.launchpad.net/snapd/+bug/1662815 | 09:16 |
| mup | Bug #1662815: conflicts between auto-aliases and real snap names <snapd:New> <https://launchpad.net/bugs/1662815> | 09:16 |
| jamespage | pedronis, agreed | 09:16 |
| jamespage | zioproto, ^^ | 09:16 |
| kw | zyga: I got the point of "version" What if, for example, everyone upload their "version" of vim and actually they are almost the same just uploaded by different person and have different namespace | 09:19 |
| zyga | kw: nothing | 09:20 |
| zyga | kw: as long as they have different snap name this is all right | 09:20 |
| kw | zyga: I see. interesting :) | 09:21 |
| zyga | kw: there were some ideas about how to let pepole get an official vim or a fork of vim from a given user (vim being just an example) but there was no agrement on what the semantics would be | 09:23 |
| zyga | kw: but it is possible we will re-visit this | 09:23 |
| kw | zyga: I suppose that people would prefer a copy from author or official one which makes them comfortable | 09:27 |
| mup | Bug #1662817 opened: some snaps stop working after revert the core snap <Snappy:New> <https://launchpad.net/bugs/1662817> | 09:29 |
| === kw is now known as anta | ||
| === anta is now known as kw | ||
| mup | PR snapd#2806 closed: interfaces/io-ports-control: use /dev/port, not /dev/ports <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2806> | 09:39 |
| === ackkk is now known as ackk` | ||
| === leftyfb_ is now known as leftyfb | ||
| === DavidDuffey is now known as dduffey | ||
| === chihchun_ is now known as chihchun | ||
| === StoneTable is now known as aisrael | ||
| === iahmad_ is now known as iahmad | ||
| === ackk` is now known as ackk | ||
| mup | PR snapd#2766 closed: tests: improve snap-env test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2766> | 10:02 |
| cos- | is there a plugin or other way to build and install a debian package from source? running debuild and dpkg -i would be enough.. | 10:18 |
| ogra_ | cos-, a rather ugly way is https://github.com/ogra1/packageproxy/blob/master/Makefile | 10:20 |
| ogra_ | from https://github.com/ogra1/packageproxy | 10:20 |
| ogra_ | (it works though) | 10:20 |
| ogra_ | https://github.com/ogra1/laidout is another one | 10:21 |
| ogra_ | (the latter only uses a binary, the former builds a deb from the upstream source) | 10:22 |
| cos- | ok, no clean way to do that :-( | 10:25 |
| ogra_ | dont judge by my hacks :) | 10:26 |
| ogra_ | this is all very old stuff, perhaps there is a cleaner way nowadays | 10:27 |
| ogra_ | i just tend to abuse makefiles as scripts for quick results | 10:28 |
| popey | cos-: why do you need to rebuild the deb? can't you just suck it in? | 10:28 |
| ogra_ | yeah, then you would just put it in stage-packages | 10:28 |
| cos- | popey: if it exists only in a private git repo | 10:29 |
| kw | why is some snap namespace reserved? e.g. i7z | 10:41 |
| stub | Will we get to the point of being able to guarantee that a Xenial or later machine has the snapd package installed when it is provisioned? | 10:54 |
| stub | I've got a problem with /snap/bin not being in the $PATH of processes spawned before the snapd package got installed (lxd containers in this case) | 10:54 |
| stub | I don't know if I should file an lxd bug (because it provisioned a machine without snapd and handed it to Juju),or a Juju bug because it asked for the wrong thing, or an Ubuntu bug because /snap/bin should be on the $PATH in /etc/profile no matter what | 10:57 |
| stub | Or if I should be handling it myself, and rebooting the machine after installing the snapd package to get the /etc/profile.d changes in effect everywhere | 11:00 |
| popey | kw: so the upstream developer can 'claim' it. | 11:00 |
| popey | or someone working with the upstream developer | 11:00 |
| mup | PR snapd#2805 closed: snap: improve message after `snap refresh pkg1 pkg2` <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2805> | 11:17 |
| mup | PR snapd#2807 opened: snap: add new `snap switch` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/2807> | 11:18 |
| vigo | ogra_, ping | 11:26 |
| === cmars` is now known as cmars | ||
| ogra_ | vigo, yo | 11:57 |
| vigo | ogra_, what does this mean? | 12:09 |
| vigo | 2017-02-08T12:08:04Z INFO snap "core" has bad plugs or slots: core-support (unknown interface) | 12:09 |
| ogra_ | when do you get this ? | 12:09 |
| vigo | I get this refreshing core from candidate | 12:09 |
| vigo | well stable-> candidate | 12:10 |
| ogra_ | well, it is an info message telling oyu that the running core does not have the interface (the new core after the install finished will have it) | 12:11 |
| ogra_ | the question is here if snapd is clever enough to re-run any potential config settings that use this interface once the new core is running | 12:11 |
| ogra_ | if not, that would be a bug | 12:12 |
| === hikiko is now known as hikiko|ln | ||
| vigo | ogra_, great, thanks | 12:24 |
| om26er | Hello! where can I download model assertion for rpi2 ? need to build an image with default user | 12:34 |
| om26er | I have the one for pc right now but want to build for rpi2/db | 12:35 |
| Chipaca | jdstrand, any reason you can think to not let strict snaps read /usr/share? | 12:37 |
| Chipaca | jdstrand, if yes, what about just /usr/share/bash-completion/bash_completion :-) | 12:37 |
| === hikiko|ln is now known as hikiko | ||
| mup | PR snapd#2804 closed: interfaces/core-support: allow modifying systemd-timesyncd and sysctl configuration <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2804> | 13:17 |
| mup | PR snapd#2774 closed: interfaces/mount: add dedicated mount entry type <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2774> | 13:30 |
| mup | PR snapd#2808 opened: interfaces: use mount.Entry instead of string snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/2808> | 13:30 |
| jdstrand | Chipaca: this is going to be a can of worms. in general, we should only allow what is required. ok, so for bash completion that is /etc/bash_completion* and /usr/share/bash_completion/*. however, on classic, /etc is mounted in the snap but /usr/share is from core, and core doesn't ship /usr/share/bash-completion/bash_completion, so there is a potentional mismatch, especially when using different cores | 13:37 |
| ogra_ | jdstrand, core ships it now | 13:38 |
| jdstrand | Chipaca: assuming you fix that (or defer caring), then all the commands in /usr/share/bash-copmpletion/completions/* are probably going to access the filesystem in new and exciting ways | 13:38 |
| ogra_ | ogra@localhost:~$ ls /usr/share/bash-completion/bash_completion | 13:39 |
| ogra_ | /usr/share/bash-completion/bash_completion | 13:39 |
| ogra_ | added last week :) | 13:39 |
| jdstrand | that's find, but the /etc vs /usr bit on classic may cause problems and I'm positive will cause problems with say, a fedora core | 13:39 |
| * jdstrand wonders why he doesn't have an updated core | 13:40 | |
| mvo | jdstrand: what do you see in snap changes? | 13:40 |
| mvo | jdstrand: anything that indicates why core is not updating? | 13:40 |
| jdstrand | maybe it didn't go to stable? | 13:40 |
| ogra_ | yeah, far from that | 13:40 |
| mvo | jdstrand: oh, you are using stable :) consider switching | 13:41 |
| jdstrand | I have r888 | 13:41 |
| ogra_ | edge and (not sure) perhaps candidate | 13:41 |
| jdstrand | well, my laptop I won't, but I can do that somewhere else | 13:41 |
| * jdstrand notes that adding bash_completion was the least of his concerns-- that's easy :) | 13:42 | |
| jdstrand | (the file, not the functionality) | 13:43 |
| Chipaca | jdstrand, core does ship bash completion as of now (on edge) | 13:50 |
| Chipaca | jdstrand, all I really need is /usr/sahre/bash-completion/bash_completion, not the completion scripts | 13:50 |
| ogra_ | Chipaca, well, on classic you might want them | 13:51 |
| Chipaca | ogra_, not from inside confinement | 13:53 |
| Chipaca | ^ strict | 13:54 |
| ogra_ | ah,. k | 13:55 |
| jdstrand | mvo: have you given this bug more thought: hsearch_r failed: No such process? | 13:55 |
| mvo | jdstrand: yes | 13:55 |
| jdstrand | mvo: I updated core and now nothing starts (cause of old snap-confine) | 13:56 |
| mvo | jdstrand: in the standup right now, I have something but we need to talk more because reverts of core are probably broken right now too | 13:56 |
| mvo | jdstrand: I have a branch that is still a bit messy | 13:56 |
| jdstrand | mvo: I would be interested in seeing that branch when you're ready for me to look at it | 13:56 |
| zioproto | hey when you have a syntax like git+https://github.com/zioproto/kolla-ansible how do I select a specific branch ? | 13:57 |
| zioproto | I mean in python-packages: in the snapcraft.yaml | 13:58 |
| mvo | jdstrand: preview (slightly messy) https://github.com/snapcore/snapd/compare/master...mvo5:feature/snap-confine-from-core?expand=1 | 13:58 |
| mvo | jdstrand: but its essentially what we discussed via mail, i.e. snapd wil create correct apparmor profiles for the snap-confine on core | 13:58 |
| === stokachu_ is now known as stokachu | ||
| zioproto | managed ! #branch=name | 14:00 |
| br4nd0m | Hi guys, I am using /snap/bin/snappy-debug.security scanlog my_first_app | 14:08 |
| sergiusens | zioproto: yeah, same semantics as with pip | 14:08 |
| br4nd0m | to see why AppArmor is blocking it | 14:09 |
| popey | br4nd0m: awesome, how's it working out? | 14:09 |
| br4nd0m | and I get:* adjust snap to ship 'ip' * adjust program to use relative paths if the snap already ships 'ip' | 14:09 |
| br4nd0m | hi popey, it's going OK, just got stuck there | 14:09 |
| rvr | ogra_: Serial console on the Pi is the best invention since the sandwich :) | 14:11 |
| ogra_ | haha | 14:11 |
| rvr | ogra_: Do you know why the wifi is not working on the Pi3 yet? | 14:11 |
| === tsdgeos_ is now known as tsdgeos | ||
| ogra_ | rvr, driver bug, not sure if ppisati ever got around reserching it more (i didnt) | 14:15 |
| ogra_ | rvr, it works if you first configure wired, then reboot and call sudo console-conf via ssh ... you can then turn off wired, configure wlan and reboot | 14:16 |
| rvr | ogra_: I see | 14:16 |
| rvr | ogra_: I just re-checked during the first boot, and of course failed | 14:16 |
| ogra_ | righ, second boot is the key :) | 14:17 |
| * Mirv notes that tsdgeos_ should get a shell account or fix internets | 14:18 | |
| tsdgeos_ | Mirv: oh no | 14:19 |
| tsdgeos_ | it's that snap is hardlocking my system | 14:19 |
| tsdgeos_ | that's what shoudl be fixed :D | 14:19 |
| Mirv | it cannot be, ogra_ says snappy fixes stuff, not breaks | 14:19 |
| jdstrand | mvo: http://paste.ubuntu.com/23954598/ | 14:21 |
| jdstrand | mvo: would be nice if I could comment on your branch before the PR... | 14:21 |
| mvo | jdstrand: oh, nice | 14:21 |
| mvo | jdstrand: thank you! | 14:21 |
| mvo | jdstrand: I can make it into a PR, then you can comment | 14:22 |
| jdstrand | mvo: there is one other fun wrinkle that I thought of. /etc/apparmor.d/abstractions vs /var/snap/core/current/etc/apparmor.d/abstractions | 14:22 |
| jdstrand | mvo: this is something that has always been there but I don't think we ever considered | 14:22 |
| jdstrand | mvo: today I think we are lucky cause the core snap is pulling from the archive and so is the classic host and we haven't made changes to the abstractions, so they are in sync | 14:23 |
| mvo | jdstrand: yeah, good point | 14:24 |
| jdstrand | mvo: but it is easy to imagine scenarios when they may be out of sync | 14:24 |
| jdstrand | mvo: I don't think that has to be fixed here | 14:24 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/2809/files | 14:25 |
| mup | PR snapd#2809: cmd/snap-confine-tests: reformat test to pass shellcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/2809> | 14:25 |
| mup | PR snapd#2809 opened: cmd/snap-confine-tests: reformat test to pass shellcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/2809> | 14:25 |
| mvo | jdstrand: https://github.com/snapcore/snapd/pull/2810 <- so that you can comment more easily | 14:25 |
| mup | PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810> | 14:25 |
| mvo | jdstrand: I work on that now | 14:25 |
| jdstrand | zyga: speaking of shellcheck. I noticed that my build environment was complaining (non-fatally) that shellcheck wasn't there. I then installed it, and it still complained | 14:26 |
| mup | PR snapd#2810 opened: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810> | 14:26 |
| tsdgeos_ | not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.21 2.21]): older than "/usr/bin/snap" (2.22.2+17.04) | 14:26 |
| tsdgeos_ | what does this mean? | 14:26 |
| tsdgeos_ | is it bad? | 14:26 |
| mvo | tsdgeos_: totally harmless - where do you see that? | 14:30 |
| tsdgeos_ | mvo: /var/log/syslog | 14:30 |
| mvo | tsdgeos_: ok, that is expected. it just means your deb version of snapd is newer than the version in the stable core snap. on zesty that is pretty much always the case because zesty is very ahead :) | 14:31 |
| tsdgeos_ | ok, tx | 14:31 |
| pedronis | mvo: we are missing in ver[1] in the printing that message :) | 14:33 |
| pedronis | s/in// | 14:33 |
| stokachu | how do i see what applications are available in the core snap | 14:33 |
| ogra_ | stokachu, we onyl guarantee /bin/sh (and recently python) | 14:34 |
| stokachu | ogra_, ok cool, makes it easy | 14:34 |
| mvo | pedronis: indeed, the message is not as nice as it should be | 14:34 |
| ogra_ | stokachu, while theer are indeed a lot more binaries included they can always drop out | 14:34 |
| stokachu | ogra_, ack | 14:35 |
| ogra_ | Mirv, since you are here ... | 14:36 |
| ogra_ | ogra@localhost:~$ snap install ubuntu-app-platform | 14:36 |
| ogra_ | error: cannot install "ubuntu-app-platform": snap not found | 14:36 |
| ogra_ | do we not build it for armhf ? | 14:36 |
| jdstrand | mvo: commented | 14:36 |
| === rumble is now known as grumble | ||
| ogra_ | (i can actually install the terminal app butz not the needed platform for it) | 14:36 |
| zyga | jdstrand: re-run autogen, that should fix shellcheck | 14:37 |
| zyga | jdstrand: it's a configure-time decision | 14:37 |
| mvo | jdstrand: thank you! | 14:37 |
| zyga | ogra_: we guarantee a bit more | 14:38 |
| ogra_ | zyga, well, libc | 14:38 |
| zyga | ogra_: look at what the apparmor profile allows for various interfaces | 14:38 |
| zyga | ogra_: if we say that interface "foo" can run /usr/bin/fooctl then that is what we allow | 14:38 |
| ogra_ | zyga, well, thats definitely wrong then | 14:38 |
| zyga | ogra_: we really do that | 14:38 |
| zyga | jdstrand: I added a review to mvo's branch | 14:38 |
| ogra_ | unless we dropped all our policies | 14:38 |
| zyga | jdstrand: please read it as well as it is very tricky business | 14:39 |
| ogra_ | any binary in the core can drop out at any time | 14:39 |
| zyga | guys, I need to run to buy some food | 14:39 |
| zyga | I'll be back in one hour | 14:39 |
| ogra_ | we always said we dont give any guarantee for them to be there | 14:39 |
| jdstrand | zyga: any reason why we don't build-depends on shellcheck? | 14:39 |
| jdstrand | ogra_: is ubuntu-app-platform only in --edge? | 14:41 |
| ogra_ | jdstrand, i tried all channels and with/without --devmode | 14:42 |
| zyga | jdstrand: 14.04 | 14:42 |
| ogra_ | zyga, huh ? | 14:43 |
| zyga | jdstrand: and immense pain on gentoo :) | 14:43 |
| ogra_ | shellcheck is in ubuntu since ages ... | 14:43 |
| zyga | ogra_: it wasn't available last time I looked | 14:43 |
| ogra_ | it definitely is | 14:43 |
| ogra_ | https://launchpad.net/ubuntu/+source/shellcheck | 14:43 |
| ogra_ | hmm | 14:43 |
| ogra_ | backports ... thats weird ... i knwo i used it in code in 10.04 | 14:44 |
| jdstrand | zyga: I'm talking about Ubuntu's debian/ directory | 14:44 |
| jdstrand | zyga: there is no reason Ubuntu's snapd couldn't BuildDepends on shellcheck. am I missing something? | 14:44 |
| ogra_ | jdstrand, well, it isnt in 14.04 | 14:45 |
| zyga | jdstrand: yeah, now it can; it was hard before | 14:45 |
| zyga | jdstrand: I'll make that so | 14:45 |
| ogra_ | as zyga just proved to me ... | 14:45 |
| * ogra_ is still baffled | 14:45 | |
| jdstrand | ogra_: oh, I took your 'ages' comment to include 14.04 :) | 14:45 |
| ogra_ | jdstrand, well, as i said above, i'm sure i used shellcheck in 10.04 projects | 14:45 |
| jdstrand | well, whatever, I have a note now for it | 14:46 |
| ogra_ | so thats super confusing | 14:46 |
| ogra_ | but LP doesnt lie | 14:46 |
| ogra_ | (i assume) | 14:46 |
| zyga | jdstrand: can you please approve https://github.com/snapcore/snapd/pull/2811 | 14:48 |
| mup | PR snapd#2811: cmd: add sc_is_debug_enabled <Created by zyga> <https://github.com/snapcore/snapd/pull/2811> | 14:48 |
| mup | PR snapd#2811 opened: cmd: add sc_is_debug_enabled <Created by zyga> <https://github.com/snapcore/snapd/pull/2811> | 14:48 |
| zyga | jdstrand: trivial and I plan to use it to avoid debugging-only code in new stuff | 14:48 |
| zyga | jdstrand: feel free to request name changes, I will follow up if you want that | 14:48 |
| * zyga -> shopping | 14:49 | |
| mup | PR snapcraft#1119 opened: tests: skip the tests that can't be run in arm64 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1119> | 14:50 |
| Son_Goku | sergiusens, hey did you manage to take a crack at refactoring the build/stage-packages backend? | 15:04 |
| mterry | didrocks: thanks for quick merge on the desktop helper :) | 15:30 |
| didrocks | mterry: yw! :-) | 15:31 |
| Flint | Hi guys | 15:32 |
| === Flint is now known as Guest45206 | ||
| Guest45206 | Quick question, is there a snap packages offering maas-region controller and maas-rack controller or even a maas meta snap package? | 15:32 |
| === Guest45206 is now known as Fl1nt | ||
| Fl1nt | cls | 15:35 |
| Fl1nt | lol | 15:35 |
| Fl1nt | ok, so: Here I'm back: Quick question, is there a snap packages offering maas-region controller and maas-rack controller or even a maas meta snap package? | 15:36 |
| === chihchun is now known as chihchun_afk | ||
| victorbjelkholm | Is there any way I can provide a mirror for snaps? Basically, a rsync endpoint I could download all the snaps for, then configure snap to fetch the packages from my endpoint instead? | 15:39 |
| zyga | re | 15:55 |
| tsdgeos_ | snap is all unhappy if you try to remove the same thing twice :D | 16:01 |
| tsdgeos_ | http://paste.ubuntu.com/23955037/ | 16:02 |
| tsdgeos_ | and the spinner stays there foreeeeeeeeeeeever | 16:02 |
| mup | PR snapd#2811 closed: cmd: add sc_is_debug_enabled <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2811> | 16:03 |
| tsdgeos_ | ah. not forever | 16:05 |
| tsdgeos_ | finished eventaully | 16:05 |
| mup | PR snapd#2809 closed: cmd/snap-confine-tests: reformat test to pass shellcheck <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2809> | 16:07 |
| mup | PR snapd#2680 closed: interfaces: shutdown: also allow shutdown/reboot/suspend via logind <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2680> | 16:08 |
| ppisati | ogra_: even with the modules and firmware directory in /, a freshly created image stops at "Running /scripts/local-premount ..." | 16:11 |
| ogra_ | ppisati, squashfs compiled in or as module in the initrd ? | 16:12 |
| ppisati | ogra_: module, but part of initrd (at least if i trust snapcraft haven't manually checked though) | 16:13 |
| ogra_ | hmm | 16:13 |
| ppisati | ... | 16:13 |
| ppisati | - CONFIG_SQUASHFS=m | 16:13 |
| ppisati | kernel-initrd-modules: | 16:13 |
| ppisati | - squashfs | 16:13 |
| ogra_ | and you have a proper label on the writable partition ? | 16:13 |
| jdstrand | Chipaca: http://paste.ubuntu.com/23955092/ | 16:13 |
| ogra_ | thats the only two things i could imagine making it stop there | 16:13 |
| ppisati | ogra_: i dd the image, let me check | 16:13 |
| ogra_ | oh, also dont forget we have two console= args nowadays | 16:14 |
| ogra_ | might be the output switches to tty (in case you are watching serial) | 16:14 |
| jdstrand | Chipaca: note, with that I can get command tab completion to work and then argument completion to try to work. but things aren't going to be great. eg, | 16:14 |
| jdstrand | $ . /etc/bash_completion | 16:14 |
| jdstrand | bash-4.3$ fdisk bash: /bin/lsblk: Permission denied | 16:14 |
| ppisati | ogra_: i was watching serial and the lcd screen | 16:14 |
| ogra_ | ah, k | 16:14 |
| ppisati | ogra_: indeed the "Running local-premount" only shows on lcd | 16:15 |
| jdstrand | Chipaca: (where after 'fdisk ' I pressed <tab> | 16:15 |
| ppisati | ... | 16:15 |
| ppisati | /dev/sdc8: LABEL="system-boot" UUID="2638-BE3F" TYPE="vfat" PARTLABEL="system-boot" PARTUUID="67822573-51a0-4e57-af2a-7f675ff35f0e" | 16:15 |
| ppisati | /dev/sdc9: LABEL="writable" UUID="e0364375-0ae8-4459-8462-2745dfe933a0" TYPE="ext4" PARTLABEL="writable" PARTUUID="fdaaa4cd-7a8e-4f1f-a0f1-4bbb0ea622a8" | 16:15 |
| ppisati | and it appears the correct partition label is there | 16:15 |
| ogra_ | looks fine | 16:15 |
| ogra_ | well, thats the only thing i could imagie apart from missing kernel config | 16:15 |
| ogra_ | though i wouldnt know what could be missing | 16:16 |
| jdstrand | Chipaca: but it works fine for things that are allowed in teh policy. eg: | 16:16 |
| jdstrand | bash-4.3$ dmesg -- | 16:16 |
| jdstrand | --buffer-size --ctime --human --read-clear | 16:16 |
| jdstrand | ... | 16:16 |
| ppisati | ogra_: let me do some more debugging | 16:16 |
| ogra_ | if you boot with break=premount, does /proc/filesystems have squashfs ? | 16:16 |
| ogra_ | perhaps there is more broken in the kernel plugin | 16:16 |
| Chipaca | jdstrand, this is for tab completing of snap apps | 16:16 |
| * ppisati tries | 16:16 | |
| Chipaca | jdstrand, so the completion script itself would be shipped in the snap (hypothetically; i'm still at the proof-of-concept step) | 16:17 |
| Chipaca | jdstrand, that's why it was only bash-completion (which granted does ship a lot of completers itself; maybe i need to cut that down and ship our own version of it for this?) | 16:18 |
| ppisati | ogra_: ah, i can't stop it at boot prompt | 16:18 |
| ppisati | lovely | 16:18 |
| ogra_ | oh | 16:18 |
| zyga | ppisati: did you enable the correct compression options for squashfs? | 16:18 |
| jdstrand | Chipaca: I know tyhicks represented the concerns regarding this since something the snap ships is running outside of confinement (unless we do something to confine it, which I gather is what you are working on) | 16:18 |
| ogra_ | ppisati, even with break=top ? | 16:18 |
| ogra_ | (that should kick in before *anything runs) | 16:19 |
| Chipaca | jdstrand, exactly, what i'm working on is having the completion itself running confined | 16:19 |
| ppisati | zyga: http://pastebin.ubuntu.com/23955117/ | 16:19 |
| cholcombe | anyone willing to take a look at my amd64 build log for rust: https://launchpadlibrarian.net/305573480/buildlog_snap_ubuntu_xenial_arm64_ceph-safe-disk_BUILDING.txt.gz ? It's failing but I'm not entirely sure why | 16:19 |
| jdstrand | Chipaca: so, there is a choice. I just demonstrated tab completion can work for commands on the system. I think there will be issues with different cores and on classic with host /etc mounted in the snap, but it works in principle | 16:20 |
| zyga | ppisati: yes, looks good; though you may want to check how this compares to ubuntu kernel on amd64, we changed some things after realizing the settings we used consume gobs of ram | 16:20 |
| ppisati | ogra_: i can't break to the uboot prompt (counter is 0), so i need to regenerate uboot.env with tha option appended | 16:20 |
| zyga | ppisati: there was a bug about that on the kernel package | 16:20 |
| ppisati | zyga: yeah, that was the parallel decompressor | 16:20 |
| ogra_ | zyga, ppisati http://paste.ubuntu.com/23955121/ ... from the current pi2 | 16:20 |
| ppisati | yeah, i'll do some debugging | 16:21 |
| ogra_ | ppisati, you dont need to break at the uboot prompt | 16:21 |
| ogra_ | just edit cmdline.txt | 16:21 |
| * zyga -> some quick food and back to PRs | 16:21 | |
| ppisati | ogra_: dragonboard unfortunately | 16:21 |
| ogra_ | and ? | 16:21 |
| ogra_ | SD is SD | 16:21 |
| ogra_ | just plug it over to your lpatop/PC | 16:21 |
| ppisati | ogra_: there's no cmdline.txt there, does it load automagically? | 16:22 |
| jdstrand | Chipaca: I think to make this work for /snap/bin commands to only the user on the system (not in snaps), you could probably extend what is there | 16:22 |
| ogra_ | oh | 16:22 |
| ogra_ | crap, yeah | 16:22 |
| ogra_ | sorry | 16:22 |
| Chipaca | jdstrand, I'm possibly missing something, you mind if we PM for a bit? | 16:22 |
| ogra_ | commandline is indeed in uboot.env only there | 16:22 |
| ppisati | yep | 16:22 |
| jdstrand | Chipaca: to makes shells in snaps use it (eg, make it work with what I pasted), might have to think about that a bit more | 16:22 |
| ppisati | and there's no text versiobn of that uboot.env | 16:22 |
| ppisati | ogra_: do you know where i can find the text version of it? | 16:23 |
| ogra_ | ppisati, https://github.com/snapcore/dragonboard-gadget/tree/master/prebuilt | 16:23 |
| ppisati | ogra_: nice, ta | 16:23 |
| ogra_ | elopio, so lool has to sign the CLA to use non-canonical addresses for signing on github ? could we fix that so that people in core-dev on LP are automatically included ? | 16:25 |
| ogra_ | that seems a bit strange to demand from people that have full commit rights to all of ubuntu already | 16:26 |
| lool | ogra_: it's copyright assignment to Canonical, so perhaps people in some ~canonical team should be exempt | 16:31 |
| ogra_ | lool, yeah, that then ... | 16:31 |
| ogra_ | i just find it silly that people already being covered have to sign it again | 16:32 |
| ogra_ | and i'm personally reluctant to use my @canonical address for anything else than business mail (i.e. on something like github) | 16:32 |
| mup | PR snapd#2812 opened: tests: fix "snap managed" output check and supress output from expect in the authenticated login tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2812> | 16:32 |
| ogra_ | mvo, uuuh ... i'm hitting the "hsearch_r failed" on my laptop ! i thought that happened only during upgrades | 16:37 |
| ogra_ | ogra@styx:~/Devel/branches/snapd/interfaces/builtin$ telegram-sergiusens.telegram | 16:37 |
| ogra_ | hsearch_r failed: No such process | 16:37 |
| * ogra_ blames sergiusens | 16:37 | |
| ogra_ | (running the edge core here though) | 16:38 |
| elopio | ogra_: from travis, there is no way to check who is in the canonical team in launchpad. | 16:44 |
| ogra_ | elopio, well, then this check should be postponed until there is | 16:45 |
| elopio | ogra_: the script is only an aid. If it fails, we have to check manually | 16:45 |
| elopio | it's not a blocker for merging the pr. | 16:45 |
| ogra_ | or it should not make commits fail | 16:45 |
| ogra_ | ah, the conversation looked like it was | 16:45 |
| elopio | ogra_: that's because sergiusens says that all contributions from canonical employees should be made with the canonical address. I think he read it in some guidelines, but not sure. | 16:46 |
| elopio | kgunn: did you get my email? | 16:46 |
| ogra_ | well | 16:47 |
| ogra_ | agaik we are free to use our ubuntu.com address ... unless we commit to external projects | 16:47 |
| ogra_ | *afaik | 16:47 |
| ogra_ | where it is indeed important that you use cnonical.com when doing commits in your work time | 16:47 |
| ogra_ | canonical.com | 16:47 |
| ogra_ | for our own projects thats moot | 16:48 |
| elopio | I don't know, I had my personal address as the main one configured everywhere. | 16:48 |
| ogra_ | also being an employee means you have signed the CLA with your contract :) | 16:48 |
| mup | PR snapd#2813 opened: tests: filter ubuntu-core systems for authenticated find-private test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2813> | 16:48 |
| elopio | ogra_: I started a thread in canonical-snapcraft about how to check the CLA in a nicer way. Feel free to vent all your frustration there, maybe we get something done. | 16:51 |
| ogra_ | heh, no frustration here ... | 16:51 |
| ogra_ | just slight disconcert | 16:52 |
| elopio | ogra_: :) we need an agry mob | 16:56 |
| mvo | ogra_: sorry, its a general problem with edge, #2810 has a fix | 16:56 |
| mvo | ogra_: but still some work required before that can land :/ | 16:57 |
| ogra_ | elopio, http://i.imgur.com/GX5tSki.jpg | 16:57 |
| ogra_ | mvo, i noticed i was not on the latest ... a snap refresh fixed it ... | 16:57 |
| * ogra_ unblames sergiusens | 16:57 | |
| mvo | ogra_: interessting | 16:57 |
| ogra_ | well, in fact a snap refresh core --beta ... which failed complaining about teh configure bits ... then a snap refresh core ... which just got me updated fine | 16:58 |
| ogra_ | so i tried to roll back first | 16:58 |
| ogra_ | perhaps that was the bit making it behave | 16:59 |
| mup | Bug #1662962 opened: 'snap find' does not allow channel specification <Snappy:New> <https://launchpad.net/bugs/1662962> | 17:05 |
| mup | PR snapcraft#1120 opened: Update rustup link. Bug: 1662960 <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/1120> | 17:05 |
| lool | woudl someone have an example of a gadget.yaml with interface autoconnection handy? | 17:08 |
| ogra_ | lool, morphis perhaps (but he just said goodbye for the day in another channel) | 17:08 |
| === DanChapman_ is now known as DanChapman | ||
| === linuxhiker2 is now known as linuxhiker | ||
| mup | PR snapcraft#1112 closed: core: setup core to support classic confinement <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1112> | 17:32 |
| mup | Bug #1662899 opened: Snap packages install but can't be run <isv> <Linux Mint:New> <Snappy:New> <https://launchpad.net/bugs/1662899> | 17:35 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/2814 | 17:35 |
| mup | PR snapd#2814: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814> | 17:35 |
| zyga | jdstrand: the mount/umount command helpers, with better buffer handling and with past issues fixed | 17:35 |
| mup | PR snapd#2814 opened: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814> | 17:36 |
| zyga | jdstrand: if you can review that today I'll propose the actual useful cleanup of snap-confine that uses sc_mount/sc_umount and doesn't log manually | 17:36 |
| zyga | jdstrand: I was also wondering how to progress on the big update-ns branch, I think that the mount entry helpers PR is the first one to land there | 17:36 |
| zyga | jdstrand: namely this branch: https://github.com/snapcore/snapd/pull/2775 | 17:37 |
| mup | PR snapd#2775: cmd: add functions to load/save fstab-like files <Created by zyga> <https://github.com/snapcore/snapd/pull/2775> | 17:37 |
| oky | how would something like an /etc/ file be handled with snappy packaged programs? i want a config file that can be edited by someone outside the snap | 17:37 |
| zyga | oky: store it in $SNAP_DATA or $SNAP_USER_DATA | 17:37 |
| zyga | oky: or use snappy configuration system (using the configure hook) | 17:37 |
| zyga | oky: and snap get/set commands | 17:37 |
| zyga | oky: normal /etc is off-limits | 17:38 |
| zyga | oky: and is mostly read only | 17:38 |
| oky | zyga: alright, i understand. i was hoping there'd be another option available (like readwrite mounts into the snap) | 17:39 |
| oky | zyga: or like a particular dir in the snap that is exposed as RW (where i can place configs) | 17:40 |
| zyga | oky: you just described $SNAP_DATA | 17:40 |
| zyga | oky: as for mounts, that may come but not in the next few releases | 17:40 |
| zyga | oky: and it would still be a poor UX for users | 17:40 |
| zyga | oky: that mount would be visible only to the snap, at runtime | 17:40 |
| zyga | oky: (to that particular snap) | 17:40 |
| zyga | oky: and users would still have to edit $SNAP_DATA/$SNAP_USER_DATA | 17:40 |
| oky | zyga: sure. i'll need to look to see how i can pre-populate the SNAP_DATA dir with my configs | 17:41 |
| zyga | oky: you should use a wrapper around your real app | 17:42 |
| zyga | oky: I think this is the only reliable way today | 17:43 |
| zyga | oky: configure hook runs after services start | 17:43 |
| zyga | oky: (or doens't always run before) | 17:43 |
| oky | i've already made several (maybe 5 or more) changes to my program to work with snap (specifically around using SNAP_DATA and SNAP_USER_DATA), now realizing that i need a configurable /etc/ system, it seems like i need to make some more | 17:43 |
| oky | thanks for the guidance, zyga - i'll be exploring the options you outlined | 17:44 |
| zyga | oky: good luck | 17:46 |
| Fl1nt | guys, is there someone working on maas snaps? | 17:49 |
| zyga | Fl1nt: I bet but I think you should ask on the maas mailing list or ping the maas developers directly | 17:51 |
| Fl1nt | ok, thanks a lot zyga | 17:52 |
| * ogra_ bets someone like stokachu would know | 17:52 | |
| ogra_ | (or at leats be able to point in the right direction) | 17:52 |
| Fl1nt | zyga: got my answer \o/ They made my day :D | 18:02 |
| Fl1nt | see ya guys, thanks a lot for your support. | 18:04 |
| jkridner | call for participation in #beagle-gsoc: http://bbb.io/gsoc | 18:06 |
| jdstrand | zyga: I'll try | 18:16 |
| rogpeppe1 | just checking: if I want my snap to have some configuration options, is this the mechanism I should use? https://developer.ubuntu.com/en/snappy/guides/config/ | 18:24 |
| rogpeppe1 | also, how is that related to https://github.com/snapcore/snapd/wiki/Configuration ? | 18:27 |
| rogpeppe1 | niemeyer: ^ | 18:28 |
| === rogpeppe1 is now known as rogpeppe | ||
| rogpeppe | niemeyer: (hiya BTW!) | 18:28 |
| niemeyer | rogpeppe: Heya | 18:29 |
| niemeyer | rogpeppe: The former is completely out of date.. the "snappy" command doesn't even exist anymore | 18:29 |
| rogpeppe | niemeyer: ok - that's the first result that google gives me when googling for "ubuntu snap configuration" | 18:30 |
| niemeyer | rogpeppe: The latter is the current mechanism | 18:30 |
| niemeyer | rogpeppe: We should kill it | 18:30 |
| rogpeppe | niemeyer: ok, great | 18:30 |
| rogpeppe | niemeyer: i'm glad i asked :) | 18:30 |
| rogpeppe | niemeyer: BTW my snappy-based domestic power control system has been coming along a lot in the last week. | 18:31 |
| rogpeppe | niemeyer: lots of "things" on the net here | 18:31 |
| niemeyer | @rogpeppe Sweet, that's great to hear! | 18:31 |
| nothal | niemeyer: No such command! | 18:31 |
| niemeyer | @nothal sshh! | 18:31 |
| nothal | niemeyer: No such command! | 18:31 |
| rogpeppe | lol | 18:32 |
| rogpeppe | niemeyer: one stumbling block has been lack of rtc integration | 18:32 |
| rogpeppe | niemeyer: but i managed to work around it by making a systemd unit to set the time before the snap unit starts | 18:32 |
| === Skuggen_ is now known as Skuggen | ||
| ogra_ | rogpeppe, well, did you try to follow the raspbian howto and try to hack the things they use to get it working into a core image ? | 18:35 |
| ogra_ | rtc integration is fine ... just third-party rtc isnt :) | 18:35 |
| rogpeppe | ogra_: i added the usual dtoverlay to the boot config, if that's what you mean | 18:35 |
| rogpeppe | ogra_: it even worked once | 18:35 |
| ogra_ | well, there is more to it than the dtoverlay i guess | 18:36 |
| rogpeppe | ogra_: but not ever again | 18:36 |
| rogpeppe | ogra_: i don't really understand the kernel internals of how /dev/rtc is provided tbh | 18:36 |
| rogpeppe | ogra_: s/really understand/understand a thing about/ :) | 18:36 |
| ogra_ | https://www.abelectronics.co.uk/kb/article/22/rtc-pi-on-a-raspberry-pi | 18:37 |
| ogra_ | i fear we still have a bug with i2c not being enabled in config.txt ... | 18:37 |
| ogra_ | that would be your first step | 18:37 |
| ogra_ | we dont blacklist the i2c modules so you can skip that bit | 18:38 |
| ogra_ | but i guess you will definitely need step 4 from the tutorial | 18:39 |
| rogpeppe | ogra_: almost none of those instructions work as is in snappy | 18:39 |
| rogpeppe | ogra_: no i2cdetect | 18:40 |
| ogra_ | yeah skip that | 18:40 |
| ogra_ | but make sure to have i2c enabled in config.txt | 18:40 |
| rogpeppe | ogra_: the device works ok | 18:40 |
| rogpeppe | ogra_: i have a program that talks to it fine | 18:40 |
| ogra_ | on snappy ? | 18:41 |
| rogpeppe | ogra_: yeah | 18:41 |
| rogpeppe | ogra_: https://github.com/rogpeppe/misc/blob/master/cmd/pirtc/rtc.go | 18:41 |
| ogra_ | hmm, so whats the exact issue now | 18:41 |
| rogpeppe | ogra_: /dev/rtc doesn't exist | 18:41 |
| rogpeppe | ogra_: so timedatectl can't use it | 18:42 |
| ogra_ | well, the device should be created when the module is loaded | 18:42 |
| rogpeppe | ogra_: the rtc module? | 18:42 |
| ogra_ | does lsmod show rtc-ds1307 ? | 18:42 |
| rogpeppe | ogra_: no | 18:42 |
| ogra_ | aha | 18:43 |
| ogra_ | well, so modprobe it ;) | 18:43 |
| ogra_ | then check dmesg | 18:43 |
| rogpeppe | ogra_: ok. i've not used modprobe before. | 18:44 |
| ogra_ | sudo modprobe rtc-ds1307 | 18:44 |
| ogra_ | ;) | 18:44 |
| ogra_ | then check the end of dmesg and see if it created some device | 18:45 |
| rogpeppe | ogra_: lsmod now shows the module | 18:45 |
| ogra_ | good | 18:45 |
| zyga | rogpeppe: see, I told you to talk to ogran :) | 18:45 |
| zyga | well, ogra even | 18:45 |
| ogra_ | ogra[n] | 18:45 |
| ogra_ | :) | 18:45 |
| rogpeppe | ogra_: no device though | 18:45 |
| ogra_ | one of my many personalities | 18:45 |
| rogpeppe | ogra_: and nothing in /var/log/dmesg | 18:45 |
| ogra_ | rogpeppe, ok ... | 18:46 |
| rogpeppe | ogra_: is modprobe persistent? | 18:46 |
| ogra_ | not over reboots ... | 18:46 |
| ogra_ | rogpeppe, so now ... sudo -s | 18:46 |
| ogra_ | echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device | 18:46 |
| ogra_ | then check dmesg again | 18:46 |
| kalikiana | Hmmmm no package snapcraft on trusty? | 18:47 |
| rogpeppe | ogra_: still nothing in dmesg | 18:47 |
| ogra_ | any /dev/rtc now ? | 18:47 |
| rogpeppe | ogra_: yup! | 18:47 |
| === JanC is now known as Guest64203 | ||
| === JanC_ is now known as JanC | ||
| ogra_ | aha | 18:47 |
| rogpeppe | ogra_: my pirtc command now no longer works (2017/02/08 18:48:36 cannot open: error opening the address (104) on the bus (/dev/i2c-1): device or resource busy) - that's probably healthy though. | 18:49 |
| ogra_ | rogpeppe, so as a quick hack: create a file /etc/modules-load.d/modules-rtc.conf ... and add rtc-ds1307 to it | 18:49 |
| mup | PR snapcraft#1059 closed: pluginhandler: support more complex stage-packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1059> | 18:50 |
| rogpeppe | ogra_: just "rtc-ds1307" as a single word on its own line? | 18:50 |
| ogra_ | long term this requires the new snappy config setup for core which does not knwo about modules yet though | 18:50 |
| ogra_ | yeah | 18:50 |
| ogra_ | only that | 18:50 |
| ogra_ | i'm not sure how we can add the "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device" though ... | 18:51 |
| ogra_ | normally you woould do that through a line in /etc/rc.local but we do not make that writable on purpose | 18:51 |
| rogpeppe | ogra_: ok, done | 18:51 |
| rogpeppe | ogra_: so should that have fixed my issue? | 18:51 |
| ogra_ | well, you need that echo line before it works apparently | 18:52 |
| rogpeppe | ogra_: if so, i'll reboot and check | 18:52 |
| ogra_ | the module is only half the solution, the other half is the "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device" | 18:52 |
| ogra_ | after that hwclock -s and -r should just work | 18:54 |
| ogra_ | err | 18:54 |
| ogra_ | hwclock -r and -w | 18:54 |
| rogpeppe | ogra_: ok, so to get things straight, on a new device, to get rtc working, i add "dtoverlay=i2c-rtc,ds1307" to /boot/uboot/config.txt; i run "modprobe rtc-ds1307; echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device" | 18:54 |
| rogpeppe | ogra_: sound about right? | 18:54 |
| rogpeppe | ogra_: i'm thinking that timedatectl should just use it when it's there, right? | 18:54 |
| ogra_ | yeah, that is how i read the vendor page :) | 18:54 |
| ogra_ | right | 18:55 |
| * rogpeppe reboots | 18:55 | |
| ogra_ | but it wont work on boot since you will have to manually do the echo bit still | 18:55 |
| ogra_ | and without rc.local being writable that will be a bit tricky to get going | 18:56 |
| rogpeppe | ogra_: oh | 18:56 |
| rogpeppe | ogra_: right, so it actually doesn't solve my issue, unfortunately, 'cos it must be done on boot | 18:57 |
| ogra_ | (and i also suspect rc.local might be a bit late, the hwclock start job runs before that i fear) | 18:57 |
| rogpeppe | ogra_: i guess at least now i can dispense with my pirtc command) | 18:57 |
| ogra_ | rogpeppe, we need to find a solution for that though :) please file a bug | 18:57 |
| * ogra_ wonders how we can solve that ... thats really a bit tricky | 18:58 | |
| rogpeppe | ogra_: where's the right place to file this kind of bug? | 18:58 |
| ogra_ | see the channel topic | 18:58 |
| ogra_ | image realted bugs are fine on the snappy project | 18:58 |
| rogpeppe | ogra_: in fact, i think you might be better to file the bug because i don't actually know what the underlying issue is here but you do | 18:59 |
| mup | PR snapd#2815 opened: release: don't force devmode on LinuxMint "serena" <Created by zyga> <https://github.com/snapcore/snapd/pull/2815> | 18:59 |
| rogpeppe | ogra_: i.e. is the problem because the device isn't being created or because the module's not being detected or... | 19:00 |
| ogra_ | rogpeppe, because the addon board needs the echo line for initialization | 19:00 |
| rogpeppe | ogra_: or i could just file a bug that says "h/w RTC doesn't work on raspberry Pi" | 19:00 |
| ogra_ | the module loads obviously and we also have the devicetree file but you can do the last step | 19:00 |
| ogra_ | no, rtc works ... generically ... thats specific to the addon board initialization | 19:01 |
| ogra_ | i'm filing one | 19:01 |
| rogpeppe | ogra_: thanks | 19:01 |
| rogpeppe | ogra_: that's why it's better you file it :) | 19:01 |
| mup | Bug #1662899 changed: Snap packages install but can't be run <isv> <Linux Mint:Invalid> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1662899> | 19:02 |
| mup | Bug #1663001 opened: rc.local not writable, but i2c addon board needs special treatment <Snappy:New> <https://launchpad.net/bugs/1663001> | 19:06 |
| ogra_ | rogpeppe, ^^ | 19:06 |
| ogra_ | would be nice if you could "me too" that one :) | 19:06 |
| ogra_ | i might have further questions and since you are the only one owning that HW .... | 19:06 |
| rogpeppe | ogra_: done | 19:07 |
| ogra_ | thx | 19:07 |
| ogra_ | and sorry for not getting back to you on the ML yet | 19:07 |
| ogra_ | (and thanks for hunting me down here now) | 19:07 |
| rogpeppe | ogra_: FWIW that seems like the most obvious h/w for anyone that might use an RTC on a pi | 19:07 |
| rogpeppe | ogra_: np, thanks for helping out now | 19:08 |
| rogpeppe | ogra_: one difficulty i have with using snappy is that it's not clear how much in the system is snappy-specific and how much is generic linux stuff. | 19:09 |
| ogra_ | just forget about generic linux stuff and assume its all new :) | 19:10 |
| ogra_ | i.e. all the above we just did are hacks in the light of snappy ... | 19:10 |
| cholcombe | this is a silly question but how do i unit test just the rust plugin and not the entire world? I've tried a bunch of different patterns and I can't seem to hit the right one | 19:21 |
| kyrofa | cholcombe, python3 -m unittest snapcraft.tests.plugins.test_rust | 19:23 |
| cholcombe | kyrofa, thanks :) | 19:23 |
| cholcombe | so it's the python path not the directory | 19:23 |
| kyrofa | cholcombe, nothing magical there. The ./runtests.sh essentially just does that plus the discover module | 19:23 |
| kyrofa | cholcombe, right | 19:24 |
| cholcombe | kyrofa, does sources.Script default to setting the name of the file it downloads to the same name as the link? | 19:27 |
| kyrofa | cholcombe, I'm not sure off the top of my head | 19:27 |
| cholcombe | ok | 19:28 |
| kyrofa | cholcombe, but you can look, it's in snapcraft/internal/sources/ | 19:28 |
| pmcgowan | kyrofa, is there a way to reinitialize my state.json on a device | 19:29 |
| kyrofa | pmcgowan, I've never tried. Did you try stopping snapd and renaming that file? | 19:30 |
| pmcgowan | kyrofa, not yet | 19:31 |
| kyrofa | pmcgowan, that's really my only idea :P | 19:31 |
| pmcgowan | I saw an old post that said to restart the firstboot service, but thats not there any mre | 19:31 |
| kyrofa | pmcgowan, zyga would probably know better | 19:31 |
| kyrofa | pmcgowan, or ogra_ perhaps? | 19:31 |
| zyga | pmcgowan: hmm, on a device | 19:31 |
| zyga | pmcgowan: why do you want to do that? | 19:32 |
| pmcgowan | zyga, yeah, still playing around with my stuck dragonboard | 19:32 |
| zyga | pmcgowan: the store was just fixed | 19:32 |
| zyga | pmcgowan: can you try to refresh now? | 19:32 |
| pmcgowan | zyga, oh? | 19:32 |
| pmcgowan | one sec | 19:32 |
| pmcgowan | zyga, its working on the first snap I tried | 19:33 |
| zyga | pmcgowan: sounds promising, try to refresh core | 19:34 |
| pmcgowan | zyga, it started to refresh automagically | 19:34 |
| pmcgowan | its working woot | 19:35 |
| zyga | woot :) | 19:35 |
| pmcgowan | zyga, what was the issue? | 19:35 |
| zyga | pmcgowan: store-side bug, according to pedronis the store was asking to refresh the wrong macaroon so the client refreshed but was back to square one | 19:36 |
| pmcgowan | great glad its fixed | 19:37 |
| ogra_ | pmcgowan, whee ! here too ! | 19:39 |
| * zyga EODs | 19:41 | |
| zyga | ttyl | 19:41 |
| pedronis | pmcgowan: ogra_: great | 19:41 |
| pmcgowan | pedronis, why only certain devices? | 19:42 |
| ogra_ | matter of them having been off for a while | 19:42 |
| pedronis | pmcgowan: first it needed to be core (it doesn't affect classic), 2nd it depends when the last time the macarron was created/refreshed | 19:42 |
| ogra_ | zyga saw it on a pi today ...so it wasnt actually drafgonboard specific | 19:42 |
| pmcgowan | ok | 19:42 |
| pedronis | pmcgowan: the bug was introduced unoticed in the store a little bit ago | 19:42 |
| pedronis | pmcgowan: but it triggered only once the macaroon were starting to expire and need refreshing | 19:43 |
| pmcgowan | gotcha | 19:43 |
| pmcgowan | pedronis, is there a bug # for that? I can close the snapd one | 19:44 |
| pedronis | we are also looking how to tests these paths a bit more (it's a bit complicated because of the expiry side of this, normally it's relatively long) | 19:44 |
| pedronis | pmcgowan: not yet, we'll do some bug gardening tomorrow | 19:45 |
| pmcgowan | ok | 19:45 |
| ogra_ | woah | 19:49 |
| ogra_ | 2017-02-08T19:46:49Z ERROR cannot remove snap file "core", will retry in 3 mins: [--root / disable snap-core-533.mount] failed with exit status 1: Failed to execute operation: Structure needs cleaning | 19:49 |
| pmcgowan | whered ya see that | 19:49 |
| ogra_ | after the snap refresh core | 19:49 |
| ogra_ | smells a bit like my SD is borked | 19:50 |
| ogra_ | ogra@dragon:~$ sudo reboot | 19:50 |
| ogra_ | sudo: error in /etc/sudo.conf, line 0 while loading plugin `sudoers_policy' | 19:50 |
| ogra_ | sudo: unable to load /usr/lib/sudo/sudoers.so: /usr/lib/sudo/sudoers.so: cannot read file data: Input/output error | 19:50 |
| ogra_ | sudo: fatal error, unable to load plugins | 19:50 |
| pmcgowan | oops | 19:50 |
| pedronis | pmcgowan: I moved this one to store | 19:50 |
| pmcgowan | pedronis, perfect | 19:50 |
| pedronis | now there's snapstore project for those | 19:50 |
| pedronis | pmcgowan: the other strange message about needing to buy core, is that after removing creds the stuck download got a 401 and there's a bit of lack of details there atm, so snapd assumed is a non-free snap | 19:52 |
| pedronis | that one needs a bit of work both in store and snapd | 19:52 |
| pmcgowan | pedronis, right I saw that commentary | 19:52 |
| ogra_ | yay | 19:53 |
| ogra_ | ogra@dragon:~$ snap refresh | 19:53 |
| ogra_ | All snaps up to date. | 19:53 |
| ogra_ | so after reboot it is back in order | 19:53 |
| pmcgowan | nice | 19:53 |
| pedronis | it's a cosmetic/UX issue though, nothing fundametally broken, but bad error reporting | 19:53 |
| pmcgowan | right | 19:53 |
| ogra_ | ogra@dragon:~$ snap info core|grep installed | 19:53 |
| ogra_ | installed: 16.04.1 (1133) 67MB - | 19:53 |
| pmcgowan | now to remember what I was doing | 19:55 |
| mup | PR snapcraft#1121 opened: cleanbuild: allow talking to a remote <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1121> | 20:05 |
| mup | PR snapd#2802 closed: snap-confine: make sc_map_search/read_number take const const char * arguments <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2802> | 20:10 |
| mup | PR snapd#2816 opened: interfaces/builtin/core-support: Allow modifying logind configuration from the core snap <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2816> | 20:13 |
| mup | PR snapcraft#1108 closed: store: add support for tracks in channels <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1108> | 20:20 |
| zyga | jdstrand: re, regarding strncmp I thin we ought to compare strlen()+1 characters | 20:34 |
| zyga | jdstrand: otherwise this happens: | 20:34 |
| zyga | printf("%d\n", strncmp("noneofyourbusiness", "none", 5)); | 20:35 |
| zyga | jdstrand: comparing 4 characters means they are equal | 20:35 |
| zyga | jdstrand: we should compare 5, | 20:35 |
| zyga | jdstrand: do you agree? | 20:35 |
| jdstrand | zyga: using 5 is fine. note my comments mentioned that | 20:35 |
| zyga | jdstrand: right (start with) | 20:35 |
| jdstrand | not 5 specificially, but that nothing should be noneofyourbusiness | 20:35 |
| zyga | jdstrand: I just wanted to be on the safe side | 20:35 |
| jdstrand | that's fine | 20:36 |
| zyga | jdstrand: thanks | 20:36 |
| === victorbjelkholm_ is now known as victorbjelkholm | ||
| zyga | jdstrand: hmm, thinking about it some more, I think that strncmp and strcmp with one constant string is identical | 20:39 |
| zyga | jdstrand: I already made the change but we will compare at most 5 characters in both cases | 20:40 |
| jdstrand | zyga: that would be implementation-specific. strcmp may use a strlen() on a non-terminated string | 20:44 |
| victorbjelkholm | Is there any way I can provide a mirror for snaps? Basically, a rsync endpoint I could download all the snaps for, then configure snap to fetch the packages from my endpoint instead? | 20:44 |
| zyga | jdstrand: hmm, indeed, thanks for the insight! | 20:49 |
| zyga | victorbjelkholm: not at present | 20:49 |
| victorbjelkholm | zyga: thanks. "not at present" referring to a rsync endpoint? There is some other way I could have my own mirror? | 20:50 |
| zyga | victorbjelkholm: no | 20:54 |
| zyga | victorbjelkholm: you may try to write a proxy for the snap store | 20:54 |
| zyga | victorbjelkholm: that should be doable today | 20:54 |
| victorbjelkholm | ooh... I see... So where are the snaps hosted today? | 20:54 |
| zyga | victorbjelkholm: you can then point snapd at your proxy and have it mirror or cache stuff | 20:54 |
| zyga | victorbjelkholm: in a CDN, I don't know the details | 20:54 |
| victorbjelkholm | yeah, that makes sense | 20:54 |
| victorbjelkholm | ah, so I guess it's a CDN hosted by/owned by Canonical? | 20:55 |
| zyga | jdstrand: can you re-review the sc_u?mount_cmd branch please | 20:55 |
| victorbjelkholm | hm, maybe the snaps will never be mirrorable if so... | 20:55 |
| zyga | jdstrand: minimal changes as instructed | 20:55 |
| zyga | victorbjelkholm: I believe someone will come up with a proxy | 20:55 |
| zyga | victorbjelkholm: as for mirroring it is not clear as snaps don't have to be FOSS | 20:56 |
| zyga | victorbjelkholm: and may require license | 20:56 |
| zyga | victorbjelkholm: the free snaps should be possible to mirror but I don't know if anyone works on this | 20:56 |
| victorbjelkholm | ah, yeah, wouldn't be too hard, I'm just afraid of installing things from a central repository I have no idea where it comes from or where it's hosted | 20:56 |
| zyga | victorbjelkholm: as the API stands today snapd asks the store for the URL | 20:56 |
| zyga | victorbjelkholm: why? | 20:56 |
| victorbjelkholm | so in the end snaps would be the same as .deb packages today, multiple repositories with different requirements and uses | 20:57 |
| victorbjelkholm | I'm not sure I can trust it, might be a CDN running on some randoms computer, I have no information at this point and I'm having troubles finding it as well | 20:57 |
| zyga | victorbjelkholm: because each snap is signed and there is a root of trust there's a different approach to repositories | 20:57 |
| zyga | victorbjelkholm: one store can aggregate other stores | 20:57 |
| victorbjelkholm | ah, where can I see this chain of trust? | 20:57 |
| zyga | victorbjelkholm: but you cannot use multiple stores | 20:57 |
| zyga | victorbjelkholm: in github.com/snapcore/snapd look at the asserts package | 20:58 |
| zyga | victorbjelkholm: and the overlord/assertstate package | 20:58 |
| zyga | victorbjelkholm: one store design solves many issues in a natural way (name authority for instance) | 20:59 |
| * zyga gets back to his family | 20:59 | |
| zyga | jdstrand: if you +1 it I'll get a 2nd +1 from the rest of the team tomorrow | 20:59 |
| victorbjelkholm | hm, not sure I understand. But yeah, have dinner here as well so maybe we'll speak later | 20:59 |
| zyga | jdstrand: thank you for the detailed review, I need to stamp strNfoo on my screen | 20:59 |
| zyga | :-) | 21:00 |
| jdstrand | heh | 21:00 |
| jdstrand | well, strNfoo aren't always the answer, but they can be helpful in certain situations | 21:00 |
| zyga | yeah but I rarely think about them | 21:00 |
| mup | PR snapd#2817 opened: many: switch channels on refresh if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2817> | 21:03 |
| === verterok` is now known as verterok | ||
| jdstrand | zyga: I think I am being dense: http://paste.ubuntu.com/23956602/ | 21:14 |
| jdstrand | zyga: I couldn't reconcile your comment to what I was thinking. can you enlighten me? | 21:15 |
| mup | PR snapcraft#1122 opened: repo: cache stage packages for faster future use <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1122> | 21:20 |
| mup | PR snapcraft#1119 closed: tests: skip the tests that can't be run in arm64 <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1119> | 21:47 |
| mup | PR snapd#2812 closed: tests: fix "snap managed" output check and supress output from expect in the authenticated login tests <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2812> | 21:48 |
| cholcombe | elopio, that PR i put in should fix my build problems on arm64 and ppc64 i hope :) | 21:50 |
| mup | PR snapcraft#1123 opened: Adding Fish she'll source and IDEA IDE to gitignore <Created by joedborg> <https://github.com/snapcore/snapcraft/pull/1123> | 21:53 |
| zyga | jdstrand: hey | 21:53 |
| zyga | jdstrand: you are currect, it is just the case that MS_REC has no meaning alone | 21:53 |
| zyga | jdstrand: so your code is closer to ideal but the difference does not matter here | 21:54 |
| jdstrand | zyga: right. in the 'what I expected' code, it never would be | 21:54 |
| zyga | jdstrand: the goal of that variable is to collect flags we've used so that we don't repeat them | 21:54 |
| zyga | jdstrand: since they use special syntax | 21:54 |
| jdstrand | zyga: well, but isn't it with the current code at least possible for MS_REC to be set when it should not? | 21:54 |
| zyga | jdstrand: yes but that is harmless, we use that as a mask to filter out stuff not to show again | 21:55 |
| zyga | jdstrand: yes, you can call mount (..., MS_REC) | 21:55 |
| zyga | jdstrand: and that will show | 21:55 |
| zyga | jdstrand: if you couple that with MS_PRIVATE it won't show again but you will see --make-rprivate | 21:55 |
| zyga | jdstrand: it's subtle | 21:55 |
| zyga | jdstrand: because we don't filter invalid arguments | 21:55 |
| zyga | jdstrand: if you want I can be precise there | 21:55 |
| zyga | jdstrand: but I don't think it matters (in this specific case) | 21:56 |
| cholcombe | sergiusens, i don't get why it's still looking for rustup.sh. I changed the unit tests. Maybe there's some test i missed? | 21:56 |
| jdstrand | zyga: I think either being precise or adding a comment as to why you don't need to be precise would be good, cause the way it reads (at least a quick reading) is that MS_BIND alone will set MS_REC and you'll get --rbind | 21:57 |
| zyga | jdstrand: wait, that shoud not be the case | 21:57 |
| zyga | jdstrand: you will get --bind | 21:57 |
| zyga | https://github.com/snapcore/snapd/pull/2814/files#diff-380b7bd2738396bc92ee5a2bd7f81d11R191 (I'm sure you know this now but just to be clear, we unset the bits seen in used_special_flags) | 21:58 |
| mup | PR snapd#2814: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814> | 21:58 |
| zyga | jdstrand: and this is tested: https://github.com/snapcore/snapd/pull/2814/files#diff-70758630224dcb7ba3963d1fa05bb69aR102 | 21:59 |
| mup | PR snapd#2814: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814> | 21:59 |
| jdstrand | actually, I missed the one's complement | 22:00 |
| jdstrand | zyga: ok, I responded. couple of small things but feel free to pass along | 22:14 |
| cholcombe | anyone want to take a quick peek at my pr and see where i goofed: https://github.com/snapcore/snapcraft/pull/1120 ? I looked at the download function and it uses os.path.basename for the link you give it. My change should work but the units are still failing | 22:16 |
| mup | PR snapcraft#1120: Update rustup link. Bug: 1662960 <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/1120> | 22:16 |
| cholcombe | i deleted the pyc files just to see if that was it but it's not | 22:16 |
| cholcombe | i see it. thank you grep :D | 22:17 |
| mup | PR snapcraft#1121 closed: cleanbuild: allow talking to a remote <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1121> | 22:23 |
| mup | PR snapcraft#1113 closed: repo: cache stage packages for faster future use <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1113> | 22:35 |
| === foli_ is now known as foli | ||
| === plars is now known as plars-away | ||
| mup | PR snapcraft#1124 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1124> | 23:29 |
| mup | PR snapcraft#1124 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1124> | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
