| niemeyer | Forum update coming... | 01:16 |
|---|---|---|
| niemeyer | It's back up | 01:24 |
| === chihchun_afk is now known as chihchun | ||
| === JanC is now known as Guest104 | ||
| === JanC_ is now known as JanC | ||
| elfgoh | ogra_: any idea if the i2c interface is enabled on the Raspberry Pi? | 05:51 |
| zyga | good morning | 06:13 |
| abeato | zyga, hey, regarding https://github.com/snapcore/snapd/pull/3324 , if you strongly think that the file vars should be ordered, I can do that... tbh not that I agree, but I do not want to block on that. There is another PR that I need to push on top of this one. | 06:49 |
| mup | PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324> | 06:49 |
| zyga | abeato: hey | 07:23 |
| abeato | zyga, o/ | 07:24 |
| zyga | abeato: it's just my preference for deterministic behavior but I can merge it right away | 07:24 |
| * zyga looks | 07:24 | |
| abeato | zyga, yes, I understand that but also I think that some times not being completely deterministic is good, so programs that read the file are not tempted to rely on deterministic content, which would be bad if, say, a new var is added | 07:31 |
| abeato | zyga, and if that comes at the price of a (slightly) more complex code, then it is something I would usually not do | 07:31 |
| abeato | zyga, but anyway, not that I mind changing it, just different POVs imo :) | 07:31 |
| zyga | abeato: done | 07:31 |
| mup | PR snapd#3324 closed: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3324> | 07:31 |
| abeato | zyga, thanks! | 07:31 |
| zyga | abeato: I agree | 07:32 |
| zyga | abeato: so what's the next step? | 07:32 |
| abeato | zyga, gimme a minute and you'll see it :) | 07:32 |
| mup | PR snapd#3352 closed: interfaces/log-observe: allow using journalctl from hostfs for classic distro <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3352> | 07:33 |
| * zyga looks at https://github.com/snapcore/snapd/pull/3349 | 07:35 | |
| mup | PR snapd#3349: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349> | 07:35 |
| zyga | hmm | 07:37 |
| zyga | actually, not at that one | 07:37 |
| zyga | at https://github.com/snapcore/snapd/pull/3222/files | 07:37 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 07:37 |
| === chihchun is now known as chihchun_afk | ||
| abeato | zyga, hmm, I see compile errors in current master: http://paste.ubuntu.com/24603514/ | 07:40 |
| pedronis | abeato: you need to update deps | 07:40 |
| abeato | pedronis, ah, thanks | 07:41 |
| pedronis | get-deps.sh | 07:41 |
| abeato | zyga, this: https://github.com/snapcore/snapd/pull/3353 | 07:46 |
| mup | PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353> | 07:46 |
| mup | PR snapd#3353 opened: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353> | 07:47 |
| zyga | abeato: thanks! | 07:54 |
| abeato | np | 07:54 |
| abeato | Does anybody know why run-checks could be producing these errors: http://paste.ubuntu.com/24603574/ ? | 08:03 |
| abeato | in a clean master checkout, I mean | 08:03 |
| zyga | abeato: maybe more recent shellcheck | 08:04 |
| zyga | Chipaca: ^^ | 08:04 |
| zyga | abeato: what kind of reboot parameters are we going to see typically? | 08:05 |
| zyga | abeato: I'm not too fond of the C parts, I may choose to rewrite that a little | 08:05 |
| zyga | Chipaca: good morning :) | 08:06 |
| Chipaca | abeato: that's shellcheck from zesty | 08:06 |
| abeato | zyga, "recovery". It could be "bootloader" too. they are typical android partitions/modes | 08:06 |
| elfgoh | Does anyone know if the i2c interface works in Ubuntu core on the Raspberry Pi3? | 08:06 |
| zyga | abeato: I'd much rather see an enum to be honest | 08:06 |
| zyga | elfgoh: hey | 08:06 |
| zyga | elfgoh: I know for a fact that it may work :) | 08:06 |
| Chipaca | abeato: if it's blocking you i can fix | 08:07 |
| zyga | elfgoh: but I didn't update my snap in a while | 08:07 |
| zyga | elfgoh: I made a snap that used i2c to talk to some LED controller | 08:07 |
| elfgoh | Great. Do you have your snap on github? | 08:07 |
| abeato | zyga, note that the way the parameter is passed is the one used by systemd, not something I worked out | 08:07 |
| zyga | elfgoh: and tested it on pi2 and pi3 | 08:07 |
| abeato | Chipaca, nw, just found it surprising | 08:07 |
| zyga | abeato: can you document that please? | 08:07 |
| zyga | elfgoh: yes | 08:07 |
| elfgoh | I would like to refer to the snapcraft.yml | 08:07 |
| abeato | zyga, sure | 08:07 |
| zyga | elfgoh: https://github.com/zyga/snappy-pi2-piglow | 08:07 |
| zyga | elfgoh: note that this is very old (it talks about skills, not interfaces) | 08:08 |
| abeato | zyga, it is coded so systemd command "reboot recovery" works as expected too | 08:08 |
| zyga | elfgoh: you can update it and I'll happily take pull requests | 08:08 |
| elfgoh | Oops. I have never heard about skills :o | 08:08 |
| zyga | elfgoh: those are "interfaces" now | 08:08 |
| zyga | elfgoh: just when snappy was very young :) | 08:09 |
| elfgoh | Actually, I am trying to get a humidity sensor working via i2c | 08:09 |
| zyga | elfgoh: do you have the datasheet for that? | 08:09 |
| elfgoh | Hang on a min | 08:09 |
| elfgoh | But I do know for a fact that the program works outside of a snap | 08:10 |
| elfgoh | zyga: this is the datasheet http://www.silabs.com/documents/public/data-sheets/Si7021-A20.pdf | 08:10 |
| elfgoh | But one thing for sure, when we booted Ubuntu Core, i2c is in the list when running "$ snap interfaces" | 08:11 |
| zyga | elfgoh: nice, | 08:11 |
| elfgoh | Is that expected? | 08:11 |
| zyga | elfgoh: yes, i2c is supported now | 08:11 |
| zyga | elfgoh: on a given device, it's not universal | 08:11 |
| elfgoh | sorry correction. i2c isnt in the list | 08:12 |
| zyga | elfgoh: can you pastebin "snap interfaces" on your device? | 08:12 |
| zyga | elfgoh: and snap version | 08:12 |
| elfgoh | So i2c is supported, but not necessarily on the rpi? | 08:12 |
| elfgoh | Ok hang on | 08:12 |
| zyga | elfgoh: it depends on gadget | 08:13 |
| zyga | elfgoh: ppisati and ogra_ can fix that if needed | 08:13 |
| ogra_ | i think we dont have tegh interface in the gadget ... | 08:13 |
| zyga | ogra_: can we add one quickly? | 08:13 |
| ogra_ | elfgoh, can you access i2c from the cmdline without having the app in a snap ? | 08:14 |
| ogra_ | (i.e. install the classic env to get apt support and access it from there) | 08:14 |
| elfgoh | zyga: this is the output of interfaces | 08:14 |
| ogra_ | zyga, if we know the kernel has all bits we can indeed enable it quickly in edge | 08:15 |
| elfgoh | snap version | 08:15 |
| elfgoh | snap 2.26.3+201705181256.git.035e139~ubuntu16.04.1 | 08:15 |
| elfgoh | snapd 2.26.3+201705181256.git.035e139~ubuntu16.04.1 | 08:15 |
| elfgoh | series 16 | 08:15 |
| elfgoh | kernel 4.4.0-1051-raspi2 | 08:15 |
| zyga | ogra_: well, that's a question for you and ppisati :) | 08:15 |
| zyga | ogra_: but I think it does | 08:15 |
| ogra_ | zyga, well, thats a question i was just asking elfgoh :) | 08:15 |
| zyga | elfgoh: ok, you are on the latest edge | 08:15 |
| ogra_ | if the kernel provides all he needs we can just turn it on | 08:16 |
| zyga | ogra_: we should test and enable it, it's a ref platform and the snapd part is in place | 08:16 |
| ogra_ | zyga, yes | 08:16 |
| elfgoh | ogra: yes we can access i2c from cmdline in classical snap | 08:16 |
| zyga | ogra_: sounds like a yes :) | 08:16 |
| ogra_ | zyga, obviouslly elfgoh has a usecase to test :) | 08:16 |
| elfgoh | Yup most certainly! | 08:16 |
| ogra_ | great | 08:17 |
| elfgoh | Actual hardware here | 08:17 |
| elfgoh | Working outside of snap, giving humidity and temperature readings | 08:17 |
| Chipaca | abeato: so in androidboot reboot is always equivalent to 'systemctl reboot recovery'? | 08:20 |
| abeato | Chipaca, correct. But unfortunately "shutdown +time recovery" does not work the same, the parameter is ignored | 08:21 |
| elfgoh | ogra_: quick question I have a colleague who created a snap that execs a command and is able to run ps command | 08:21 |
| elfgoh | Is this expected? | 08:21 |
| abeato | Chipaca, systemd bug I'd say | 08:22 |
| abeato | Chipaca, https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L8262 | 08:22 |
| Chipaca | shutdown isn't documented as taking 'recovery' as an arg | 08:22 |
| elfgoh | ogra_: fwiw this colleague is using docker as a reference point | 08:22 |
| abeato | Chipaca, it is not "recovery", it is a generic argument that the syscall accepts | 08:22 |
| Chipaca | shutdown isn't documented as taking any argument beyond time or 'now' | 08:23 |
| abeato | well, yes, but "reboot" command takes it | 08:23 |
| ogra_ | zyga, https://github.com/snapcore/pi3-gadget/pull/7 | 08:23 |
| mup | PR pi3-gadget#7: add i2c interfaces <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/7> | 08:23 |
| Chipaca | abeato: "systemctl reboot" does | 08:24 |
| Chipaca | abeato: reboot on its own does as well? | 08:24 |
| ogra_ | elfgoh, yes, but ps will only show the processes realted to the snap AFAIK | 08:24 |
| zyga | ogra_: approved :) | 08:24 |
| Chipaca | abeato: anyway, my quesiton is, in androidboot, all reboots are reboots into recovery? | 08:24 |
| Chipaca | that seems wrong to me, which is why i ask | 08:24 |
| abeato | Chipaca, yep, it is just a symlink to systemctl | 08:24 |
| zyga | Chipaca: it's the design | 08:24 |
| zyga | abeato: I think it should be documented there | 08:24 |
| zyga | abeato: it's not obvious | 08:24 |
| abeato | Chipaca, no, only when we are updating kernel/core | 08:25 |
| zyga | abeato: I only know this because I paid attention to some internal traffic | 08:25 |
| Chipaca | abeato: the PR you have up always does recovery reboot in androidboot | 08:25 |
| Chipaca | in fact, it always does 'reboot recovery' no matter how you tell systemd to shut down | 08:25 |
| abeato | Chipaca, so maybe the code is wrong there :) How can I know when I want to reboot because of a kernel/core update? I thought that was the only case in daemon.go call | 08:25 |
| Chipaca | ah! | 08:26 |
| Chipaca | might be getting confused because of that | 08:26 |
| Chipaca | heh | 08:26 |
| abeato | zyga, sure will add that to the PR | 08:26 |
| abeato | Chipaca, maybe I couls change the name from Reboot() to RebootAndUpdate() or something like that | 08:27 |
| elfgoh | zyga: ogra_ woot! Thanks! when will the pi3 gadget snap be update with the merge? | 08:27 |
| Chipaca | abeato: or RebootForCoreUpdate or whatever | 08:27 |
| elfgoh | ogra_: let me get additional details about the implementation | 08:27 |
| Chipaca | i'm bad at names, but yes, Reboot misguided me there | 08:27 |
| ogra_ | elfgoh, https://code.launchpad.net/%7Ecanonical-foundations/+snap/pi3 should start building in a minute | 08:27 |
| abeato | Chipaca, ok, will change it :) | 08:27 |
| zyga | elfgoh: yes, soon | 08:27 |
| elfgoh | \o/ | 08:27 |
| morphis | zyga, mvo: can we get https://github.com/snapcore/snapd/pull/3307 merged? | 08:28 |
| mup | PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307> | 08:28 |
| morphis | ogra_: would the i2c slots make sense for the pi2 gadget too? | 08:28 |
| ogra_ | morphis, as soon as i know everything works for elfgoh i'll add them there too | 08:29 |
| morphis | ogra_: great! | 08:29 |
| ogra_ | the dragonboard will really need that stuff too ... its rather lacking ... | 08:29 |
| * zyga needs to go to the bank | 08:29 | |
| ogra_ | Chipaca, abeato yes, in androidboot all reboots should be recovery reboots ... (recovery will hold the rollback and upgrade mechanisms, all reboots shoudl go through that) | 08:31 |
| ogra_ | abeato, i was about to ask, why you not just hardcode it :) | 08:31 |
| abeato | ogra_, well, if the systemd mechanism is already there, better to use it, so we additionally have "reboot bootloader" working too, for instance ;) | 08:32 |
| ogra_ | there is no need too make a difference ... recovery serves the same purpose as the uboot shell (scripting and recovery mode) | 08:32 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | so any reboot should be a recovery reboot ... | 08:33 |
| Chipaca | ogra_: hold on | 08:33 |
| Chipaca | ogra_: there's two parts to it | 08:33 |
| ogra_ | i wonder if we cant do that on a systemd level instead and leave out snapd completely | 08:33 |
| Chipaca | ogra_: one is the part in snapd that triggers a reboot because of core/kernel/gadget change | 08:33 |
| ogra_ | Chipaca, right, there is no need to make any difference here | 08:34 |
| Chipaca | ogra_: the other is shutdown-helper, which is called unconditionally by systemd on any shutdown/reboot/halt/kexec | 08:34 |
| ogra_ | it could be a hardcoded thinng on systemd level instead | 08:34 |
| abeato | ogra_, we need to modify system-shutdown command for sure | 08:34 |
| Chipaca | ogra_: shutdown-helper cannot be hardcoded in the way you describe | 08:34 |
| Chipaca | ogra_: but snapd can (and is) | 08:34 |
| ogra_ | Chipaca, doesnt it just call reboot | 08:34 |
| ogra_ | ? | 08:34 |
| ogra_ | and hand off to systemd | 08:35 |
| Chipaca | ogra_: no, systemd execve's into it | 08:35 |
| Chipaca | ogra_: it runs as pid 1 | 08:35 |
| Chipaca | ogra_: there is no systemd | 08:35 |
| ogra_ | ah | 08:35 |
| abeato | ogra_, writes "recovery" to "/run/systemd/reboot-param", then calls sysnted reboot | 08:35 |
| ogra_ | yes, i see the code | 08:35 |
| ogra_ | my point is ... there is no need to make a difference | 08:35 |
| ogra_ | every reboot should go through recovery | 08:35 |
| Chipaca | ogra_: on androidboot | 08:36 |
| ogra_ | Chipaca, yes | 08:36 |
| Chipaca | ogra_: but not on uboot | 08:36 |
| abeato | wel, I think we are better modifying snapd instead of systemd, which would mean a patch | 08:36 |
| Chipaca | ogra_: (system-shutdown doesn't know what bootloader you're on; snapd does) | 08:36 |
| ogra_ | Chipaca, right ... but our gadget knows that ... so it could ship a systemd config that always makes it "reboot recovery" | 08:36 |
| abeato | also, I would prefer reboot command to work in a normal way too | 08:37 |
| ogra_ | uh | 08:37 |
| ogra_ | but that means you will be able to reboot without the safety new | 08:37 |
| ogra_ | *net | 08:37 |
| Chipaca | ogra_: is it really just a systemd config? | 08:37 |
| ogra_ | Chipaca, in my imagination it is :P i dont know ... but it should | 08:37 |
| Chipaca | :-) | 08:38 |
| Chipaca | it's possible it is, but i don't know | 08:38 |
| Chipaca | (there is a unit for reboot) | 08:38 |
| ogra_ | right | 08:38 |
| abeato | ogra_, not sure what you mean... if we are upgrading, then yes, go to recovery. But we want plain reboot or "reboot booloader" commands to work | 08:38 |
| abeato | from command line | 08:38 |
| ogra_ | abeato, why ? | 08:38 |
| ogra_ | and what cmdline | 08:38 |
| abeato | well, for developers | 08:38 |
| abeato | shell | 08:39 |
| fgimenez | good morning zyga, i've just updated the revert test in snapd#3348, if you could have a look when you have some time that would be great, there are some refactors in there, the test itself is https://github.com/snapcore/snapd/pull/3348/files#diff-4825fd024a235e7895b109ad37072e68 | 08:39 |
| mup | PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348> | 08:39 |
| ogra_ | the shell is the recovery env | 08:39 |
| ogra_ | like you have a uboot chell on uboot installs or a grub shell in grub installs | 08:39 |
| ogra_ | the only moment you boot without recovery is a cold boot | 08:40 |
| abeato | disagreed, I would like to reboot to bootloader to flash a new kernel image using fastboot as a developer | 08:41 |
| abeato | for instance | 08:41 |
| ogra_ | the only moment you need the bootloader is when you flash | 08:41 |
| ogra_ | i.e. the initial flashing | 08:41 |
| ogra_ | abeato, if you want to manually replace the kernel you dd it from the recovery shell | 08:41 |
| morphis | ogra_, abeato: btw do we have the full process documented somewhere? | 08:42 |
| elfgoh | Got the edge pi3 snap. Giving it a go | 08:42 |
| ogra_ | i donmt really want fastboot to work on production devices by default so that random people passing by could replace your image | 08:42 |
| ogra_ | morphis, we have that forum thread | 08:43 |
| morphis | .. | 08:43 |
| morphis | I mean a structured document which covers the latest agreed process | 08:43 |
| morphis | could easily go on docs.ubuntu.com | 08:43 |
| abeato | ogra_, honestly I do not think we should ardcor reboot to recovery in systemd | 08:43 |
| ogra_ | thats all we have atm ... | 08:43 |
| abeato | *hardcore | 08:44 |
| abeato | *hardcode | 08:44 |
| ogra_ | abeato, well, how else do we want to make sure that every boot goes through the rollback mechanism ? | 08:44 |
| ogra_ | we want the same behaviour as in any other snap install ... | 08:45 |
| pstolowski | zyga, hey, commented on the upgrade-all-dependencies PR | 08:45 |
| pstolowski | zyga, also, +1 on iface metadata, so it has two reviews and can land; not sure if you want Gustavo to review this change | 08:46 |
| ogra_ | pedronis, i just refreshed my gadget snap on the pi3 ... shouldnt i get an auto-reboot ? | 08:46 |
| pedronis | ogra_: no | 08:46 |
| abeato | ogra_, when there is a panic, we go to recovery, that is hard-coded in the kernel | 08:46 |
| pedronis | ogra_: we don't reboot on gadget changes so far | 08:46 |
| pedronis | we will need to do if we change assets I suppose | 08:47 |
| ogra_ | abeato, and when we upgrade ... and when someone tinkers for development ... and ... and ... | 08:47 |
| pedronis | ogra_: so far only core and kernel trigger restart/reboots | 08:47 |
| ogra_ | pedronis, oh, i see ... interface changes get applied without reboot! | 08:47 |
| ogra_ | thats sweet! | 08:47 |
| pedronis | if it works it is :) | 08:48 |
| ogra_ | ogra@pi3:~$ snap interfaces|grep i2c | 08:48 |
| ogra_ | pi3:i2c-0 - | 08:48 |
| ogra_ | pi3:i2c-1 - | 08:48 |
| ogra_ | pi3:i2c-2 - | 08:48 |
| ogra_ | pi3:i2c-2 -.d | 08:48 |
| ogra_ | oops | 08:48 |
| ogra_ | :D | 08:48 |
| elfgoh | @ogra_ zyga : glad to report that the new pi3 gadget works well with i2c :D | 08:50 |
| nothal | elfgoh: No such command! | 08:50 |
| ogra_ | elfgoh, \0/ | 08:50 |
| elfgoh | ogra_ zyga : glad to report that the new pi3 gadget works well with i2c :D | 08:50 |
| ogra_ | awesome | 08:50 |
| * ogra_ prepares the same change for pi2 | 08:50 | |
| elfgoh | Quick question: my humidity snap currently needs sudo in order to get my snap reading humidity via i2c. What is the way to remedy that? | 08:51 |
| abeato | ogra_, you cannot forsee all cases, one of the things that was clear in the thread is that this solution would not be 100% safe until we had devices with 2 boot partitions. What about the case of somebody powering off the device after something bad happened instead of rebooting? In next boot, things would go wrong | 08:51 |
| ogra_ | abeato, well, how would you overcome that case ? | 08:52 |
| ogra_ | (without access to the bootloader) | 08:52 |
| ogra_ | even two boot partitions wont help there | 08:52 |
| abeato | ogra_, you can't, the point is that anyway this solution is limited | 08:52 |
| abeato | ogra_, 2 partitions would help as you would actually boot using the old one, as you would not hae switched yet the main partition if something went wrong... but you cannot do that if there is only one | 08:54 |
| ogra_ | zyga, https://github.com/snapcore/pi2-gadget/pull/7 | 08:54 |
| mup | PR pi2-gadget#7: add i2c interfaces <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/7> | 08:54 |
| ogra_ | abeato, i dont get that ... how would you switch without having support for that in the bootloader ? | 08:54 |
| abeato | ogra_, I understand that if you get 2 boot partitions you also get that sort of support from the bootloader, would not make much sense otherwise (maybe ondra knows about this?) | 08:55 |
| ogra_ | well, if the bootloader is designed for such a setup | 08:56 |
| * ogra_ hasnt seen that before ... | 08:56 | |
| ogra_ | typically you can only toggle between recoovery and normal boot | 08:56 |
| elfgoh | ogra_: I believe it may be a similar issue for serial port interface, since it didnt come out on the list of interfaces | 08:56 |
| ogra_ | and there you want to go through recovery if any possible in our setup ... rercovery replaces the bootloader shell and scriptery in this case | 08:57 |
| abeato | ogra_, yes, but one thing that ondra mention is that newer devices with android 7 have two boot partitions for safer upgrades, and in that case you need a way to tell the bootloader to use one or another when powering on the device | 08:58 |
| abeato | (can have) | 08:58 |
| ogra_ | abeato, so we dont support anything with a base older than android 7 ? | 08:58 |
| abeato | ogra_, we do, but we assume that the solution is not 100% sage | 08:58 |
| abeato | *safe | 08:58 |
| ogra_ | (also ... how would we integrate that bootloader behaviour with our setup) | 08:59 |
| ogra_ | (this seems very bootloader internal, how wuld we manage the rollback and such ?) | 08:59 |
| abeato | we will tackle that when we get to it, usual bussiness ;) | 09:00 |
| ogra_ | right, and until then i'D like to have the safest mechanism through recovery ... | 09:00 |
| ogra_ | which holds exactly that part of the logic | 09:00 |
| elfgoh | With regards to process isolation, this is what my colleague tried and it seems like one snap can view another snap's processes https://gist.github.com/choonkeat/a398244e3ce406ad1ee27448f383c7aa | 09:01 |
| ogra_ | elfgoh, i think you can view them but not get any additional data about them | 09:02 |
| ogra_ | elfgoh, hmm, also ... sudo ? | 09:03 |
| ondra | ogra_ I assume there is some higher level api which will unify all bootloader implementations | 09:03 |
| ogra_ | ondra, yes, in a not yet existing version :) | 09:04 |
| ondra | ogra_ as this should be inherited feature of android 7 onwards and it's controlled by OS | 09:04 |
| ogra_ | ondra, we need to deal with the existing one ;) | 09:04 |
| ondra | ogra_ in already existing | 09:04 |
| ogra_ | well you knwo what i mean | 09:04 |
| ondra | ogra_ there are already phones with this setup | 09:04 |
| ogra_ | fine for these phones ... are there customers with boards that use it ? | 09:05 |
| ondra | ogra_ that's different topic :) | 09:05 |
| ogra_ | and are you sure there will only be boards with 7 onwards ? | 09:05 |
| ogra_ | ondra, well, the current topic is the current setup ... what android based boards do we have right now ? | 09:05 |
| ogra_ | (what version) | 09:05 |
| ondra | ogra_ I just mentioned this feature, to make sure we do not choose solution which we will need to re-engineer once we start seeing those boards :) | 09:06 |
| ogra_ | ondra, well, we need to see how we can blen in our setup with that bootloader then ... if at all ... | 09:06 |
| ogra_ | *blend | 09:06 |
| ogra_ | but for now we dont have that and need an implementation that deals with the existing situation | 09:07 |
| elfgoh | ogra_: is it possible to evaluate if being able to view other processes is really necessary? This "feature" causes discomfort | 09:07 |
| ogra_ | wasnt there actually a way to set the boot reason on cmdline ? | 09:07 |
| Chipaca | abeato: “It is defined by snapd:” <- i think you meant systemd | 09:07 |
| abeato | Chipaca, yep, lust corrected :) | 09:08 |
| ondra | ogra_ there is way | 09:08 |
| abeato | *just | 09:08 |
| ondra | ogra_ but it's not persistent | 09:08 |
| Chipaca | :-) ok | 09:08 |
| ondra | ogra_ so does not do for cold boot | 09:08 |
| ogra_ | elfgoh, thats a jdstrand question i fear ... you might need to wait til he gets up (US timezone) | 09:08 |
| ondra | ogra_ therefore I suggested to use recovery as test path | 09:08 |
| ogra_ | ondra, why not ? if it is in boot.img does it get re-written there ? | 09:09 |
| elfgoh | ogra_: Ok got it will nudge jdstrand when he is awake | 09:09 |
| ondra | ogra_ you prepare update files, reboot to recovery with cmd line boot reason, and if it boots, you move that image to boot partition | 09:09 |
| ondra | ogra_ no it's just in memory | 09:09 |
| ogra_ | ondra, after modifying it | 09:09 |
| ondra | ogra_ it sets flag which bootloader can read | 09:10 |
| ogra_ | ondra, recovery will modify the cmdline befiore flashing boot,img | 09:10 |
| ogra_ | ondra, right and we could just have that in every boot.img | 09:10 |
| ogra_ | that would make sure we always go through recovery | 09:10 |
| ogra_ | ondra, if we update core the cmdline needs to carry the new snap_core ... if we need to modify it anyway we can also always add the bootreason | 09:11 |
| ogra_ | that is why i want it to go through recovery with any reboot ... | 09:12 |
| ondra | ogra_ but boot reason is not in cmdline | 09:13 |
| ondra | ogra_ that is too late | 09:13 |
| ogra_ | that was my initial question ;) | 09:13 |
| ogra_ | thanks :) | 09:14 |
| ondra | ogra_ boot reason is read by bootloader, to determine from which partition to load next boot step | 09:14 |
| ogra_ | right | 09:14 |
| ondra | ogra_ boot/ recovery | 09:14 |
| elfgoh | ogra_ zyga: sorry to nudge you again. Was wondering if the serial-port interface is ready to be supported on the pi3? | 09:15 |
| elfgoh | I have a use case for it too :) | 09:15 |
| ondra | ogra_ therefore I suggested, using boot reason for test boot, will always put us back to working (boot partition) case by nature of it, as for next/cold/crash reboot we have no boot reason -> boot partition | 09:15 |
| ogra_ | elfgoh, what kind of serial ... on the pi3 ttyAMA0 is already taken by the BT interface | 09:15 |
| ogra_ | elfgoh, would that be any additional serial device = | 09:15 |
| ogra_ | ? | 09:15 |
| ogra_ | ondra, what if the boot partition holds a broken version | 09:16 |
| ogra_ | ondra, i want to always go to recovery first | 09:16 |
| elfgoh | ogra_: it would be under /dev/serial | 09:16 |
| ogra_ | elfgoh, thats taken by the console by default | 09:16 |
| elfgoh | https://www.irccloud.com/pastebin/qXSDL82F/ | 09:16 |
| ogra_ | (or will soon be, ondra suggested some cvhanges there that i didnt add yet) | 09:17 |
| ogra_ | elfgoh, i fear that wouldnt work ... since we have console=ttyS,... (or later console=serial,...) on the kernel cmdline ... so that device is occupied in our default setup ... | 09:18 |
| ogra_ | elfgoh, you would need your own gadget that drops console=(serial,ttyS0) and add your own serial interface to snapcraft.yaml | 09:19 |
| ogra_ | we cant really drop that console in our developer images | 09:19 |
| ogra_ | oh, i should have looked at your paste first ... | 09:20 |
| ogra_ | so you use a USB dongle there | 09:20 |
| elfgoh | yup yup :) | 09:21 |
| elfgoh | Oh sorry. didnt know how irccloud snippet is showing up in other clients | 09:21 |
| ondra | ogra_ no that is the point, boot will hold verified version, you test in recovery partition new update, only if recovery version boots fine, it will be moved to boot partition | 09:21 |
| ogra_ | well, thats also something you will need your own gadget for ... iirc the USB serial interface wants vendor ID and product ID | 09:21 |
| ondra | ogra_ so version in boot partition is always good verified one | 09:21 |
| ogra_ | ondra, but we only verify by having a successfully finished boot | 09:22 |
| ogra_ | ondra, to boot the new img you first need to flash it into the boot partition and then reboot without recovery ... and only if the boot succeeds the boot img is deemed good | 09:23 |
| elfgoh | ogra_: pardon if i have any wrong assumptions, but would it be sensible to have the pi3 gadget have an interface that opens up /dev/serial? | 09:23 |
| ogra_ | ondra, now ... if you have a broken reboot and dont finish because core was broken or your kernel paniced you neerd to go back to recovery and re-flash the former version | 09:23 |
| ogra_ | ondra, there will be a point where the boot partition holds a broken boot.img and the only way to auto-fix that is to go through recovery and re-flash | 09:24 |
| ogra_ | elfgoh, yes, for tewh internal serial device *if* that isnt used as console | 09:25 |
| ondra | ogra_ no, not this way. you get new image, you flash it to recovery, and do test boot, you do not touch boot partition, only of you have sucessfull boot through recovery then you move it to boot partition | 09:25 |
| ondra | ogra_ so at any time boot partition is always verified boot option | 09:25 |
| ogra_ | ondra, thats notr what we discusssed | 09:25 |
| ogra_ | ondra, something needs to have the scriptery for rollback of core and kernel | 09:25 |
| ogra_ | thwe only way to have that is recovery | 09:25 |
| pedronis | Chipaca: hi, how it's going with your PR ? | 09:25 |
| ondra | ogra_ if you invent some different way to do it, then do not ask me, why it's not working :) | 09:26 |
| ogra_ | and if you assume that the only thing that can actually boot otherwiose is the boot partition, it is the oone that always holds the running kernel | 09:26 |
| ogra_ | ondra, we have a long thread on the forum where that was discussed | 09:26 |
| ogra_ | ondra, recovery needs to always hold our logic ... | 09:26 |
| Chipaca | pedronis: need moar coffee | 09:26 |
| ondra | ogra_ I thought logic is in snapd | 09:27 |
| ogra_ | if you just dump a boot.img into the recovery partition, where would you put the rollback logic (that needs to run *before boot* | 09:27 |
| ogra_ | ondra, half of it | 09:27 |
| ogra_ | ondra, the oother half is "before booting" | 09:27 |
| ondra | ogra_ boot/recovery is just kernel + initrd | 09:27 |
| ondra | ogra_ so you gonna add logic to initrd? | 09:27 |
| ondra | ogra_ and bootloader will load kernel from that partition, no logic there | 09:28 |
| ogra_ | ondra, righ, buit recovery has the original kernel the board was initially flashed with and additional scripts (translated from the grubn/uboot ones) | 09:28 |
| ogra_ | ondra, exactly ... the recovery initrd has the script logic we usually have in uboot/grub | 09:28 |
| ondra | ogra_ where do you have those additional scripts? in initrd? | 09:28 |
| ogra_ | ondra, and will never be touched so we have a guarantee you can always boot into that mode ... like you can always intercept autoboot in uboot or grub | 09:29 |
| ondra | ogra_ ok then we if we are adding logic to initrd, I'd suggest to unify and use that inird logic for all platforms | 09:29 |
| ogra_ | ondra, we do ... in the uboot hush shell or in the grub shell scripts | 09:29 |
| ondra | ogra_ something I mentioned before I don't see reason why u-boot should be handling versions for core snap | 09:29 |
| ogra_ | ondra, because it needs to be able to roll back when a boot failed | 09:30 |
| ogra_ | *before* booting | 09:30 |
| ondra | ogra_ and initrd would not be able to do roollback? | 09:30 |
| ondra | ogra_ or you are assuming update of core + kernel in one go? | 09:30 |
| ogra_ | it would but you would have to re-design the whole process from the groound up | 09:30 |
| elfgoh | ogra_: we are a bit confused. Are we talking about the same console? The one at /dev/ttyS0? Are you saying that there will be plans to change it to use /dev/serial? | 09:31 |
| ogra_ | and have twop different implementations for kernel vs core | 09:31 |
| ondra | ogra_ that's only case I can think of when you don't reach even to initrd | 09:31 |
| ogra_ | ondra, there are a muillion cases where you cant reach initrd ... your kernel panics ... your initrd is messed up etc etc | 09:31 |
| ondra | ogra_ yes some rework, but then you have one implementation for all u-boot/grub/android, core revisions will be always handled in one place | 09:32 |
| ogra_ | ondra, also dont forget that one day our initrd comes from core | 09:32 |
| ogra_ | (if i ever find the time for the split initrd) | 09:32 |
| ondra | ogra_ and you leave kernel revision handling to bootloader | 09:32 |
| ondra | ogra_ ha? | 09:32 |
| ondra | ogra_ initrd from core? | 09:32 |
| ogra_ | ondra, seriously ... that isnt really relevant for the stuff here | 09:32 |
| ogra_ | you can propose to move the core handling to initrd ... but that wont change the kernel initrd side | 09:33 |
| ogra_ | it will just add additional code and logic in the end ... | 09:33 |
| ondra | ogra_ ogra again, if you made up your mind how to implement it, there is no way somebody will convince you otherwise, but then don't ask me why it's not working :D | 09:33 |
| ogra_ | but wont fix the probelm we are currently trying to solve | 09:33 |
| pedronis | Chipaca: :) ( still need a review for snapd#3322 :) ) | 09:33 |
| mup | PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322> | 09:33 |
| elfgoh | ogra_: let me try again. the "serial-port" interface is supported, but not enabled on pi3 gadget. Correct? | 09:33 |
| ogra_ | elfgoh, right | 09:34 |
| Chipaca | pedronis: on it! | 09:34 |
| pedronis | Chipaca: it's big but mostly the tests | 09:34 |
| ogra_ | elfgoh, and console= occupies the device on a booted system | 09:34 |
| elfgoh | ogra_: doesnt console=/dev/ttyS0 on pi3 on Ubuntu Core? | 09:35 |
| ogra_ | elfgoh, yes | 09:36 |
| ogra_ | elfgoh, so the internal serial is taken ... for your usb serial you need to add anothert interface to snapcraft.yaml | 09:36 |
| ogra_ | ondra, i dont get how the initrd is relevant here ... it wouldnt fix the problem | 09:37 |
| elfgoh | ogra_: i am assuming that you are referring to the snapcraft.yml of a gadget snap? | 09:37 |
| ogra_ | elfgoh, exactly | 09:38 |
| ogra_ | to enable the interface you need your own gadget snap | 09:38 |
| ondra | ogra_ it would not fix it, it will make various bootloader support easier, as we will only worry about kernel revision, but as you said initrd will be coming from core, so I guess this is off the table anyway | 09:38 |
| ogra_ | ondra, well, half of the initrd :) | 09:40 |
| ogra_ | (the relevant half though) | 09:41 |
| elfgoh | ogra_: based on our understanding devices populated /dev/serial/, eg eg $ ls /dev/serial/* | 09:41 |
| elfgoh | /dev/serial/by-id: usb-FTDI_FT230X_Basic_UART_DM007FNY-if00-port0 usb-FTDI_FT230X_Basic_UART_DM007X1O-if00-port0, can change their device names unpredictably. Therefore it seems unfeasible to hardcode the interface path in snapcraft.yml. Or is there another way to handle such dynamic interfaces? | 09:41 |
| ogra_ | elfgoh, well ... dio you have a /dev/ttyUSB* ? | 09:41 |
| ogra_ | assuming you only ever have one USB dongle attached you should be able to use a rather simple interface definition | 09:42 |
| ogra_ | (same as bt-serial in https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml but with your own name and pointing to /dev/ttyUSB0 (or whatever number your sevide gets)) | 09:43 |
| elfgoh | ogra_: we have multiple usb serial devices. The device enumeration gets randomised unfortunately. So that's why we used /dev/serial/by-id it | 09:44 |
| ogra_ | elfgoh, ok, that gets more tricky then ... | 09:45 |
| elfgoh | Yup. We dont have a scalable interface definition | 09:45 |
| ogra_ | elfgoh, line 157ff has the other way ... using udev vendor and product id's https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port_test.go#L162 | 09:45 |
| ogra_ | with that you should also be able to use by-id i think | 09:46 |
| elfgoh | ogra_: have clarity we have multiple of the same USB serial devices, ie having the same vendor and product id :( We are not kidding | 09:47 |
| ogra_ | elfgoh, well, i fear thats a limitation of the serial interface ... mind starting a forum thread about it ? i guess we could extend the path /dev/serial/by-id/<identifier> | 09:49 |
| ogra_ | but thats not in my hands :) | 09:49 |
| ogra_ | *extend the path to | 09:50 |
| elfgoh | ogra_: fair enough. Will do that | 09:50 |
| ogra_ | thx | 09:50 |
| ogra_ | lets see what gustavo and the security guys say :) | 09:50 |
| Saviq | should I (and collaborators) be able to install a private snap from the store? | 09:53 |
| elfgoh | ogra_: but nevertheless, thank you for hearing our complicated use case out :D | 09:53 |
| ogra_ | elfgoh, heh, no problem :) | 09:53 |
| mup | PR snapd#3322 closed: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3322> | 10:01 |
| pedronis | Chipaca: thanks | 10:04 |
| mup | PR snapd#3355 opened: tests/main/snap-info: don't use named parameter for print statement <Created by morphis> <https://github.com/snapcore/snapd/pull/3355> | 10:06 |
| mup | PR snapd#3356 opened: tests/lib: allow SRU validation only on ubuntu type systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3356> | 10:08 |
| elfgoh | ogra_: started the conversation here https://forum.snapcraft.io/t/usb-serial-port-access-for-snap-apps/693 | 10:11 |
| ogra_ | elfgoh, perfect,. thanks | 10:11 |
| mup | PR snapd#3357 opened: tests/lib: abstract build dependency installation a bit more <Created by morphis> <https://github.com/snapcore/snapd/pull/3357> | 10:12 |
| mup | PR snapd#3358 opened: tests/main/snap-info: use proper pkgdb functions to install distro packages <Created by morphis> <https://github.com/snapcore/snapd/pull/3358> | 10:14 |
| morphis | fgimenez, zyga: submitted many tiny PRs for our test setup, would be nice if you can have a look | 10:15 |
| fgimenez | morphis: sure thanks, already reviewed one of them | 10:16 |
| morphis | nice! | 10:16 |
| mup | PR snapd#3359 opened: tests/lib: use mktemp instead of tempfile to work cross-distro <Created by morphis> <https://github.com/snapcore/snapd/pull/3359> | 10:16 |
| mup | PR snapd#3360 opened: tests/libs: add distro_auto_remove_packages function <Created by morphis> <https://github.com/snapcore/snapd/pull/3360> | 10:16 |
| pedronis | oh, no, more than 25 PRs , :) | 10:26 |
| mup | PR core#45 opened: allow rsyslog disabling <Created by ogra1> <https://github.com/snapcore/core/pull/45> | 10:34 |
| zyga | re | 10:50 |
| zyga | ogra_: approved pi2 i2c interfaces | 10:51 |
| * ogra_ hugs zyga | 10:51 | |
| ogra_ | merged | 10:52 |
| * zyga hates doing tax paperwork but ... well | 10:52 | |
| zyga | pstolowski: thank you! | 10:59 |
| mup | PR snapd#3349 closed: many: model and expose interface meta-data <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3349> | 10:59 |
| zyga | pstolowski: I was thinking about the problem of security setup for core/kernel revision change | 11:00 |
| zyga | pstolowski: are you familiar with that discussion | 11:00 |
| zyga | pstolowski: I wanted to know your view, especially since we're about to have hook attributes that, I think, complicate the prblem | 11:00 |
| pstolowski | zyga, i wasn't following that discussion, do you have a link? | 11:01 |
| zyga | pstolowski: yes I was actually looking for it :) | 11:01 |
| zyga | pstolowski: so part of it is in https://forum.snapcraft.io/t/providing-system-settings-to-snap-confine/665/13 | 11:02 |
| zyga | pstolowski: but the real problem is separate, there's no thread yet | 11:02 |
| zyga | pstolowski: I want to open one but I wanted to chat with you to get the full picture | 11:02 |
| zyga | pstolowski: the problem is that on kernel/core change, just after reboot, the services start with security profiles written by old snapd based on old kernel | 11:02 |
| zyga | pstolowski: CE hit this problem, I can share a link to a private bug | 11:02 |
| ogra_ | pedronis, do we have any docs for that gadget config option ? (is it the old way we used to have in 15.04 ?) i'd actually like to default our images to have rsyslog off | 11:32 |
| pedronis | ogra_: is still in the wiki: https://github.com/snapcore/snapd/wiki/Gadget-snap#gadgetyaml notice the key is the snap-id , not the name | 11:34 |
| ogra_ | pedronis, i.e. http://paste.ubuntu.com/24604351/ | 11:34 |
| ogra_ | ah | 11:35 |
| ogra_ | so close ... but different to 15.04 :) | 11:35 |
| pedronis | ogra_: I plan to do a quick branch soon to show that in snap info | 11:35 |
| pedronis | (that == snap-id) | 11:35 |
| pedronis | because of this among other reasons | 11:36 |
| ogra_ | does the prepare-device hook accept snap names btw ? | 11:37 |
| pedronis | ? | 11:37 |
| pedronis | I don't understand the question | 11:37 |
| pedronis | accept where/how ? | 11:37 |
| ogra_ | loking at the bottom of https://github.com/snapcore/snapd/wiki/Gadget-snap#gadgetyaml at the example ... | 11:37 |
| ogra_ | could that call "snapctl set foo bar.baz=true" ... for the preinstalled foo snap ? | 11:38 |
| pedronis | ah | 11:38 |
| ogra_ | or is it only applying to some generic defaults | 11:38 |
| pedronis | no | 11:38 |
| ogra_ | k | 11:38 |
| pedronis | something to discuss if needed | 11:38 |
| pedronis | snapctl set/get are about the snap of the hooks | 11:38 |
| pedronis | in general | 11:38 |
| pedronis | you need snapd-control to set other snaps config | 11:39 |
| ogra_ | well, it just struck me as a way to get around the snap-id if it had worked :) | 11:39 |
| ogra_ | <- cheating ;) | 11:39 |
| pedronis | ogra_: there is some argument to be made that we should support names at least for things listed in the model assertion, otoh there were vague discussion about allowing snap-ids in the model as well | 11:43 |
| pedronis | anyway nothing that will happen soon, high prio | 11:44 |
| === koza is now known as koza|away | ||
| ogra_ | well, as long as the id is predictable and known ... | 11:44 |
| ogra_ | (and doesnt change randomly) | 11:45 |
| ogra_ | it makes it a bit harder for devs ... but nothing that would block the feature | 11:45 |
| ogra_ | (we should publish the id's for the core snaps though ... until the snap info bit is there) | 11:46 |
| ogra_ | (an external developer wont easily get the id unless he builds a test image and looks at the snap-declarations first) | 11:48 |
| zyga | gee, some code reviews are tedious | 12:01 |
| * Chipaca slinks off | 12:03 | |
| abeato | zyga, are you suggesting to add "sc_" prefix to all function declarations in system-shutdown-utils.h? | 12:05 |
| abeato | zyga, also, why "sc_"? | 12:05 |
| ogra_ | abeato, stands for supercool ... makes the functions more special ;) | 12:10 |
| abeato | ogra_, that is definetely a +1 to adding it :p | 12:11 |
| ogra_ | :D | 12:11 |
| morphis | zyga: so, LXD works on suse | 12:13 |
| morphis | zyga: however you have to run $ lxc config set next-snipe raw.lxc "lxc.aa_allow_incomplete = 1" for every container | 12:13 |
| morphis | zyga: need to file a bug on lxd for that | 12:14 |
| zyga | morphis: what is next-snipe? | 12:14 |
| morphis | zyga: the container name | 12:15 |
| zyga | abeato: it's just a prefix from all the snap-confine function but I sometimes think of it as 'snapd-c-code' | 12:15 |
| niemeyer | Moin moin | 12:15 |
| morphis | niemeyer: moin! | 12:15 |
| abeato | zyga, I guess we can apply the second :p | 12:15 |
| zyga | morphis: I commented on https://github.com/snapcore/snapd/pull/3222 - I'm inclined to LGTM but my head is dizzy from all the indirection | 12:15 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 12:15 |
| abeato | zyga, in all funtxions in the header? | 12:16 |
| morphis | zyga: :-) | 12:16 |
| zyga | abeato: just the new ones, | 12:16 |
| zyga | abeato: we can do the rest separately, no need to cloud what is going on in this PR | 12:16 |
| Son_Goku | morphis, you packaged lxd for suse? | 12:16 |
| abeato | zyga, ok, fine for me | 12:16 |
| morphis | Son_Goku: no, its the snap :-) | 12:16 |
| Son_Goku | bah | 12:17 |
| morphis | Son_Goku: ? | 12:17 |
| Son_Goku | I thought you had done something cool :) | 12:17 |
| morphis | Son_Goku: :-D | 12:17 |
| zyga | morphis: what are the three iota constants in content.go? | 12:17 |
| Son_Goku | zyga: that distrolibexecdir PR makes my brain hurt | 12:17 |
| morphis | zyga: ? | 12:17 |
| zyga | https://github.com/snapcore/snapd/pull/3222/files/9b771dd09d80ef950160a1fffcd1d4b8a7ce7c80#r117467086 | 12:18 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 12:18 |
| Son_Goku | I'm not used to Go as it is, and it's really complicated to follow for me :( | 12:18 |
| zyga | Son_Goku: yes, I feel the same; it's not morphis fault in any way, it's just the variables do make it hard to guess what is going on sometimes | 12:18 |
| Son_Goku | I don't like saying this, but all the tests pass, can we please just merge it | 12:18 |
| morphis | Son_Goku: +1 | 12:19 |
| morphis | zyga: let me drop these | 12:19 |
| lazyPower | Is there a reason i'm nothinking of as to why the root user doesn't have /snap/bin added to $PATH by default on ubuntu-server/desktop distributions? Because to me it just seems like a papercut. | 12:28 |
| Croepha | i know i have asked this before, but i cant find my notes, and its not readily available via google, how can I know what version of a package was used to make the core snap? i remember that there was some kind of manifest on launchpad but i cant find it? | 12:29 |
| lazyPower | Croepha: https://launchpadlibrarian.net/283317939/buildlog_snap_ubuntu_xenial_arm64_ubuntu-core_BUILDING.txt.gz - does something like that help? | 12:30 |
| Croepha | lazyPower, yes thanks, i can make that work | 12:31 |
| lazyPower | not the most straight forward way but you should be able to grep that build log for what went into it. | 12:31 |
| lazyPower | *note, thats for the arm64 core snap. you may need to swap projects respectively | 12:31 |
| Croepha | so, where is the link to that link? | 12:31 |
| Croepha | like, how can I find more links like that? | 12:32 |
| lazyPower | aha Croepha https://launchpadlibrarian.net/316771673/core_16-2_amd64.manifest | 12:32 |
| lazyPower | there IS a manifest file | 12:32 |
| lazyPower | cited: https://forum.snapcraft.io/t/inspecting-package-differences-across-core-base-snaps/378 | 12:32 |
| cjwatson | Start from https://code.launchpad.net/~snappy-dev/+snap/core - each build has a link to the manifest | 12:34 |
| cjwatson | Unfortunately it's hard to find older builds there, but it can be done through the LP API | 12:35 |
| Croepha | thanks cjwatson | 12:37 |
| ogra_ | lazyPower, http://people.canonical.com/~ogra/core-builds/ is an overview but only logs the automatically built daily snaps ... not the manual triggered builds | 12:37 |
| Croepha | any ideas on how to translate revision number (like 1689) into build id? | 12:37 |
| Croepha | oh! | 12:38 |
| lazyPower | :) sorry jsut trying to be helpful. I actually have very little insight into how the core snaps are built so i was grepping around google searches/forums. | 12:38 |
| Croepha | that ogra link is gold | 12:38 |
| ogra_ | (i need to update the code to handle the new version strings ... but you cn just click on the "Launchpad (...)" thing to get to the menifest) | 12:38 |
| lazyPower | haha typical day for ogra_ ;) | 12:38 |
| cjwatson | the store revision is available over the LP API so it would be possible to correlate that way | 12:38 |
| cjwatson | store_upload_revision | 12:39 |
| cjwatson | would involve walking back over the full list though | 12:39 |
| cjwatson | ogra's link is easier :) | 12:39 |
| morphis | zyga: ok, updated the PR | 12:39 |
| ogra_ | but also incomplete ... | 12:39 |
| ogra_ | (it parses the clogfile for auto-builds ... pretty hackish) | 12:39 |
| ogra_ | *logfile | 12:39 |
| cjwatson | lp-shell production devel | 12:40 |
| cjwatson | In [1]: for build in lp.load('/~snappy-dev/+snap/core').builds: | 12:40 |
| cjwatson | ...: if build.store_upload_revision == 1689: | 12:40 |
| cjwatson | ...: print(build.web_link) | 12:40 |
| cjwatson | ...: break | 12:40 |
| cjwatson | ...: | 12:40 |
| cjwatson | https://launchpad.net/~snappy-dev/+snap/core/+build/32410 | 12:40 |
| ogra_ | yeah ... one day i'll find the time to make it based on proper lp-lib | 12:41 |
| cjwatson | leads to https://launchpadlibrarian.net/315255992/core_16-2_amd64.manifest | 12:41 |
| Croepha | cjwatson++ thanks! | 12:45 |
| Croepha | build.getFileUrls() will give the manifest | 12:46 |
| cjwatson | yep | 12:48 |
| zyga | Chipaca: https://forum.snapcraft.io/t/anomalous-snap-list-devmode-flag/699 | 12:55 |
| morphis | zyga: there we go, docker works now too | 13:15 |
| morphis | zyga: time to give the packages from https://build.opensuse.org/package/show/home:mrmorph:branches:system:snappy/snapd a try? | 13:16 |
| abeato | zyga, pedronis, Chipaca, morphis https://github.com/snapcore/snapd/pull/3353 ready again | 13:17 |
| mup | PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353> | 13:17 |
| morphis | zyga: otherwise: https://build.opensuse.org/request/show/496769 | 13:17 |
| morphis | Son_Goku: btw. you may want to add https://build.opensuse.org/package/view_file/home:mrmorph:branches:system:snappy/snapd/0003-cmd-snap-confine-do-not-share-etc-ssl-with-the-host.patch?expand=1 to the snapd packages on Fedora until 2.27 is out | 13:18 |
| morphis | Son_Goku: also I will look onto the bodhi requests on monday | 13:18 |
| Son_Goku | why would I do that? | 13:18 |
| Son_Goku | the Ubuntu Core snap expects /etc/ssl/certs, right? | 13:19 |
| Son_Goku | well, in Fedora, /etc/ssl/certs is a valid location | 13:20 |
| Son_Goku | it's a symlink to /etc/pki/tls/certs | 13:20 |
| Son_Goku | oh, lemme guess | 13:21 |
| * zyga hugs morphis :-) | 13:21 | |
| Son_Goku | you don't pull in /etc/pki, right? | 13:21 |
| zyga | morphis: I'll definitely try today | 13:21 |
| * Son_Goku grumbles | 13:21 | |
| morphis | Son_Goku: this is a tricky and not easy to solve situation we're in | 13:22 |
| morphis | the best we can do today is to rely on the core snap | 13:22 |
| Son_Goku | :( | 13:22 |
| morphis | in a next step we will merge this somehow with what the host provides | 13:22 |
| morphis | Son_Goku: why does that make you sad? | 13:22 |
| Son_Goku | because for example, I can't access things that I have imported my certs into | 13:23 |
| morphis | right but that is a problem we will solve | 13:23 |
| Son_Goku | I have a number of private CA certs imported into my computer, so this would break | 13:23 |
| Son_Goku | then again, it wasn't working before, was it? | 13:23 |
| Son_Goku | thankfully Fedora infra no longer requires it | 13:23 |
| Son_Goku | it used to be one of those I needed | 13:24 |
| Son_Goku | they moved to Krb auth | 13:24 |
| === chihchun is now known as chihchun_afk | ||
| morphis | Son_Goku: it was horrible broken until we did this small fix | 13:25 |
| morphis | there will be work to make /etc sharing better | 13:26 |
| morphis | including CA stuff | 13:26 |
| morphis | in one or another way | 13:26 |
| zyga | Chipaca: given that devmode is now just a flag (not confinement type) can we just do this: http://paste.ubuntu.com/24604770/ | 13:27 |
| morphis | Son_Goku: btw. I will need you on Monday to have a look at a PR which introduces the rpm build stuff for our spread setup | 13:28 |
| Son_Goku | okay | 13:29 |
| Chipaca | zyga: yes. And there's code for determining jailMode based on devmode that also needs to go | 13:29 |
| zyga | Chipaca: right | 13:29 |
| Chipaca | zyga: as our metadata gets richer our black magic can be more relaxed | 13:31 |
| zyga | yes, I was thinking that the transformations in snap list are unfortunate and it'd be nicer if we could just give simple facts from the daemon | 13:31 |
| zyga | (perhaps even the notes) | 13:31 |
| morphis | zyga: can you merge https://github.com/snapcore/snapd/pull/3307 ? | 13:46 |
| mup | PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307> | 13:46 |
| zyga | morphis: in a sec | 13:46 |
| morphis | aye | 13:46 |
| mup | PR snapd#3361 opened: cmd/snap: correct devmode note for anomalous state <Created by zyga> <https://github.com/snapcore/snapd/pull/3361> | 13:47 |
| zyga | Chipaca: check out https://github.com/snapcore/snapd/pull/3361 please | 13:49 |
| mup | PR snapd#3361: cmd/snap: correct devmode note for anomalous state <Created by zyga> <https://github.com/snapcore/snapd/pull/3361> | 13:49 |
| Chipaca | zyga: yep, was already reviewing | 13:50 |
| Chipaca | +1 | 13:50 |
| Chipaca | and now, friday school run | 13:50 |
| Chipaca | ttyl! | 13:50 |
| fgimenez | zyga, if you could have a look at snapd#3348 when you have some time that would be great, there are some refactors in there, the test itself is https://github.com/snapcore/snapd/pull/3348/files#diff-4825fd024a235e7895b109ad37072e68 probably i'm missing something but it seems to work fine (ie, the network connection is up after reverting) | 13:52 |
| mup | PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348> | 13:52 |
| zyga | fgimenez: sure, gladly | 14:17 |
| elopio | ahoneybun: do you know if that bug is already reported? | 14:17 |
| fgimenez | zyga: thanks! | 14:17 |
| zyga | morphis: done | 14:18 |
| mup | PR snapd#3307 closed: tests: abstract common dirs which differ on distributions <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3307> | 14:18 |
| morphis | zyga: thanks | 14:18 |
| morphis | zyga: can you look at https://github.com/snapcore/snapd/pull/3358 too? | 14:19 |
| mup | PR snapd#3358: tests/main/snap-info: use proper pkgdb functions to install distro packages <Created by morphis> <https://github.com/snapcore/snapd/pull/3358> | 14:19 |
| morphis | zyga: and https://github.com/snapcore/snapd/pull/3359 | 14:19 |
| mup | PR snapd#3359: tests/lib: use mktemp instead of tempfile to work cross-distro <Created by morphis> <https://github.com/snapcore/snapd/pull/3359> | 14:19 |
| zyga | morphis: yes | 14:25 |
| mup | PR snapd#3359 closed: tests/lib: use mktemp instead of tempfile to work cross-distro <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3359> | 14:25 |
| zyga | morphis: done | 14:26 |
| mup | PR snapd#3358 closed: tests/main/snap-info: use proper pkgdb functions to install distro packages <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3358> | 14:26 |
| morphis | great! | 14:26 |
| morphis | zyga: https://github.com/snapcore/snapd/pull/3360 too? | 14:34 |
| mup | PR snapd#3360: tests/libs: add distro_auto_remove_packages function <Created by morphis> <https://github.com/snapcore/snapd/pull/3360> | 14:34 |
| morphis | and https://github.com/snapcore/snapd/pull/3357 would be nice too | 14:34 |
| mup | PR snapd#3357: tests/lib: abstract build dependency installation a bit more <Created by morphis> <https://github.com/snapcore/snapd/pull/3357> | 14:34 |
| morphis | on the last one just a review | 14:34 |
| mup | PR snapcraft#1307 closed: cli: new UI and internal refactor <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1307> | 14:35 |
| ahoneybun | elopio: I don't know tbh | 14:37 |
| elopio | ahoneybun: I can't find it. This sounds like a good topic for the forum, would you mind making a post in forum.snapcraft.io? | 14:41 |
| ahoneybun | elopio: I'll see if this wifi lets me | 14:42 |
| ahoneybun | https://forum.snapcraft.io/t/snaps-list-as-loop-devices-in-file-manager/701 | 14:45 |
| ahoneybun | elopio: ^ | 14:45 |
| elopio | ahoneybun: thanks! | 14:45 |
| Croepha | i made a little toy script, to grab all debug symbols for a core snap: https://gist.github.com/croepha/0185fa264a1fb3b454469cd3c7419a09 | 15:04 |
| Croepha | it still chokes on ones that have been updated since core came out | 15:05 |
| Croepha | not sure how to fix that | 15:05 |
| niemeyer | Lunch, back in a bit.. | 15:05 |
| Croepha | also, for some reason there are man pages and doc stuff in the debug files | 15:05 |
| ogra_ | Croepha, note that the manifest doesnt reflect what was removed du4ring the core snap build ... there is a lot less in it than the manifest lists after all | 15:10 |
| ogra_ | (we can only generate the manifest file before we remove things like apt and dpkg) | 15:10 |
| Croepha | well, with everything (well at least with the packages I can get the right versions for) its all only 323MB so if I have too much then its not that big of a deal | 15:11 |
| Croepha | my main concern is that I can guarantee that i can read backtraces for cores after deployment | 15:12 |
| Croepha | because it hard to find the debug symbols later | 15:12 |
| ogra_ | Croepha, if you want to debug on a device, i'd rather recommend using the classic snap and then install the symbols there ... the classic snap re-creates the env with apt, dpkg and all other bits that have been removed | 15:12 |
| ogra_ | snap install classic --devmode --edge; sudo classic | 15:13 |
| elfgoh | jdstrand: ogra_ : I have raised the issue with regards to the visibility of processes in external snaps here https://forum.snapcraft.io/t/visibility-of-processes-originating-from-other-snaps/703 | 15:13 |
| ogra_ | (obn any core device) | 15:13 |
| ogra_ | elfgoh, yes, and i pinged niemeyer and jdstrand in the thread ... they will answer eventually :) | 15:13 |
| ogra_ | elfgoh, oops, sorry ... that was the other thread | 15:14 |
| Croepha | ogra_, well im thinking about the longterm, being able to get support info for the older binaries... like im thinking that I'll just tar up all the debug info for a specific release, so i can have it for later if i need to figure out what happened from core dump pulled from a customer down the road.... For my normal day to day development cycle im just using ubuntu desktop, and I can test and debug the snap there | 15:17 |
| ogra_ | Croepha, right, just dont be surprised if half the libs and binaries you expect ate actually not really there | 15:18 |
| ogra_ | the manifest is only a snapshot mid-build | 15:18 |
| Croepha | ogra_ ahh ok | 15:19 |
| ogra_ | we only use debs for the initial rootfs but then mangle it a lot | 15:19 |
| ogra_ | (to cut down size ...) | 15:20 |
| * ogra_ shakes fist towards people that base new product u-boot on upstream branches from 2013 | 15:21 | |
| ogra_ | *new products | 15:21 |
| ogra_ | such a pain | 15:21 |
| mup | PR snapd#3361 closed: cmd/snap: correct devmode note for anomalous state <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3361> | 15:24 |
| fgimenez | niemeyer: i've verified the scenario i mentioned in the standup and it seems that it can refresh after the revert to the previous version, so after reverting it seems that when autorefresh kicks in you would be back to the previous state | 15:31 |
| fgimenez | niemeyer: to give you more context, start from stable, "snap refresh --candidate core", "snap revert", now "snap list" shows the revision at stable but snap info shows "tracking: candidate" and, indeed, "snap refresh core" installs the latest revision in candidate | 15:33 |
| === sergiusens_ is now known as sergiusens | ||
| pedronis | fgimenez: manual refresh and auto refresh don't work the same in that scenario | 15:36 |
| pedronis | fgimenez: with auto-refresh we send blocked revisions, we a manual refresh we don't | 15:36 |
| pedronis | fgimenez: this is the relevant code: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L491 | 15:37 |
| zyga | morphis: hey, can you tell me more about why you are making this change https://github.com/snapcore/snapd/pull/3355/files | 15:38 |
| mup | PR snapd#3355: tests/main/snap-info: don't use named parameter for print statement <Created by morphis> <https://github.com/snapcore/snapd/pull/3355> | 15:38 |
| zyga | morphis: is this a 2-vs-3 thing? | 15:38 |
| zyga | morphis: note that print adds implicit newline so this actually changes semantics soo | 15:38 |
| zyga | too | 15:38 |
| morphis | zyga: AFAIK fedory python3 couldn't deal with the file= argument | 15:40 |
| fgimenez | pedronis: aha, thanks a lot, looking | 15:41 |
| zyga | morphis: that is very unlikely, can you give me a backtrace? | 15:41 |
| pedronis | fgimenez: to be precise what is different is auto-refresh and "snap refresh" VS "snap refresh NAMES" | 15:42 |
| morphis | zyga: yes, let me check that again once my fedora system is free | 15:42 |
| zyga | morphis: thank you | 15:42 |
| fgimenez | pedronis: autorefresh doesn't use names, right? | 15:42 |
| pedronis | right | 15:42 |
| * zyga does last round of reviews | 15:50 | |
| elfgoh | Perhaps not the right place to ask, but relative to Docker, I am guessing that there have been less people trying to break snap security. So where is Snap with regards to security compared to Docker? (perhaps not most elegantly articulated, but it is my best effort) | 15:55 |
| nacc | elfgoh: iirc, there is a white paper on the website | 15:55 |
| zyga | elfgoh: hey | 15:55 |
| nacc | https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ ? | 15:56 |
| zyga | elfgoh: we have a security whitepaper | 15:56 |
| zyga | nacc: thanks! | 15:56 |
| nacc | zyga: np :) | 15:56 |
| zyga | elfgoh: it's a complex questions as it is an apples-to-oranges comparison in many ways | 15:56 |
| zyga | elfgoh: there are many things that have nice properties but I'm about to join a hangout on air so I cannot tell you about them | 15:56 |
| zyga | elfgoh: I can tell you keywords to look up or discuss later | 15:57 |
| zyga | elfgoh: assertions, core snap shared by everything, separate updates, automatic confinement | 15:57 |
| morphis | zyga: if I have an reported oops id from snapd, where can I see that reported error? | 16:00 |
| ogra_ | pfft ... apples ... oranges .... | 16:00 |
| ogra_ | take pears !!! | 16:00 |
| pedronis | morphis: an error tracker one? or a store oops? | 16:09 |
| morphis | pedronis: error trackker | 16:09 |
| zyga | morphis: I'm in a call | 16:10 |
| pedronis | morphis: https://errors.ubuntu.com/oops/ID if you have access | 16:12 |
| morphis | pedronis: doesn't look like | 16:12 |
| niemeyer | fgimenez: Yeah, that looks sane | 16:29 |
| fgimenez | niemeyer: pedronis yep, i've just tried "snap refresh" and it gives first an error about network-manager's aliases http://paste.ubuntu.com/24605592/ (not sure if it's related to network-manager itself) after, removing network-manager returns "All snaps up to date" (core is not updated to the tip of candidate) | 16:33 |
| pedronis | fgimenez: what version is this? | 16:35 |
| pedronis | of snapd | 16:35 |
| pedronis | (me has lost rack) | 16:36 |
| pedronis | fgimenez: ah, you reverted core ? | 16:36 |
| fgimenez | pedronis: yes, now it is at the current stable, 2.24 | 16:37 |
| pedronis | yea, aliases and reverting core will not be happy | 16:37 |
| mup | PR snapcraft#1324 opened: Revert "tests: remove the reusable parts tour test (#1321)" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1324> | 16:38 |
| fgimenez | ok thanks pedronis | 16:39 |
| pedronis | I mean that errors comes fromr 2.24 | 16:39 |
| pedronis | I think | 16:39 |
| mup | PR snapcraft#1325 opened: cli: proper error for failed snap command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1325> | 16:56 |
| Chipaca | signs I should probably take a break: in two lines of code, type a variable name three different ways | 17:16 |
| davhou | ogra_ Hi, a followup question related to "snap run hello" error I was getting yesterday | 17:28 |
| davhou | ogra_, https://paste.ubuntu.com/24605885/ | 17:28 |
| davhou | ogra_, Any suggestions? | 17:28 |
| davhou | ogra_, or debugging techniques to help solve the problem... | 17:28 |
| ogra_ | davhou, "snap version" ? | 17:28 |
| ogra_ | (just paste it here ... only 4 lines) | 17:29 |
| ogra_ | (or 5) | 17:29 |
| davhou | david@david-VirtualBox:~⟫ snap --version | 17:29 |
| davhou | snap 2.25 | 17:29 |
| davhou | snapd 2.25 | 17:29 |
| davhou | series 16 | 17:29 |
| davhou | ubuntu 16.04 | 17:29 |
| davhou | kernel 4.4.0-75-generic | 17:29 |
| ogra_ | looks all fine | 17:29 |
| davhou | odd thing is, I am pretty certain I was once able to run that snap w/out an error | 17:30 |
| davhou | at least once | 17:30 |
| davhou | when I initially tried it out | 17:30 |
| ogra_ | if you just type "hello" and hit enter ... does it behave the same ? | 17:30 |
| davhou | i installed simplenote to try it and that's when I saw it the first time | 17:30 |
| davhou | that works! | 17:31 |
| Chipaca | pedronis: any idea why PlaceInfo has e.g. DataHomeDir but not UserDataDir? | 17:31 |
| davhou | david@david-VirtualBox:~⟫ hello | 17:31 |
| davhou | hello, world | 17:31 |
| ogra_ | yeah, looks fine | 17:31 |
| davhou | what's that mean? | 17:31 |
| davhou | is that how i should run all the snaps? | 17:32 |
| nacc | davhou: you don't use `snap run` to run a snap, normally | 17:32 |
| pedronis | Chipaca: it's not used a lot, so new things might have not be added to it | 17:32 |
| ogra_ | both should work | 17:32 |
| davhou | ok | 17:32 |
| Chipaca | pedronis: ah ok | 17:32 |
| ogra_ | (they do here) | 17:32 |
| davhou | was just following the docs from online | 17:32 |
| nacc | davhou: /snap/bin is in your PATH and then the app provided by the snap is available | 17:32 |
| ogra_ | normally ... like nacc said ... you run the binary directly ... snap apps get added to your path | 17:32 |
| nacc | davhou: (on ubuntu, iirc) | 17:32 |
| ogra_ | but the snap run command should still work nontheless | 17:33 |
| pedronis | Chipaca: anything that can be derived just by name and revision should be ok for it, if you need it | 17:33 |
| ogra_ | it indicates that theer is some issue with that specific code path | 17:33 |
| nacc | fwiw, on 17.04, i don't have a /run/snapd :) and those permissions look weird | 17:33 |
| Chipaca | pedronis: i don't need it, but was looking at adding tests while i'm in the neighborhood | 17:34 |
| davhou | you mean the root:david permissions on /run/snapd look weird? | 17:34 |
| nacc | davhou: yeah, it's a strange combination -- i'd have to spin up a 16.04 to compare though | 17:34 |
| davhou | i'll try installing another snap and run it directly | 17:35 |
| nacc | davhou: well, the ownership in combination with the actual permissions | 17:35 |
| davhou | oh, ok | 17:35 |
| pedronis | Chipaca: it's mostly undo and remove stuff that uses it, to be sure they don't depend too much on having a fully sane snap | 17:35 |
| nacc | davhou: i'm not sure why /run/snapd would be owned by a user's group | 17:35 |
| pedronis | (because they migh well not) | 17:35 |
| nacc | davhou: as it's a system directory (it seems like) | 17:35 |
| ogra_ | nacc, it is here as well ... | 17:35 |
| nacc | ogra_: interesting | 17:36 |
| ogra_ | so i guess thats fine ... | 17:36 |
| nacc | ogra_: same permissions? | 17:36 |
| davhou | Hmm, simplenote does not work as well as hello does.... | 17:36 |
| davhou | david@david-VirtualBox:~⟫ sudo snap install simplenote | 17:36 |
| davhou | simplenote 1.0.8 from 'flexiondotorg' installed | 17:36 |
| davhou | david@david-VirtualBox:~⟫ simplenote | 17:36 |
| davhou | cannot create lock directory /run/snapd/lock: Permission denied | 17:36 |
| Chipaca | sigh. our user home layout is so simplistic i'm surprised it isn't biting people more | 17:36 |
| Chipaca | (i guess everybody has homes in the same place :-) ) | 17:36 |
| nacc | ogra_: it seems like /run/snapd/lock would be created by snapd, not by `snap`? | 17:37 |
| ogra_ | nacc, yeah, sorry, the permissions of the lock files are root:ogra | 17:37 |
| ogra_ | not the dirs | 17:37 |
| nacc | ogra_: ah ok | 17:37 |
| zyga | davhou: hey | 17:37 |
| zyga | nacc: that directory is made by snap-confine and snapd alike | 17:38 |
| davhou | ogra_, so what is are your owners x:X on /run/snapd ? | 17:38 |
| zyga | davhou: can you tell me more about your environment | 17:38 |
| nacc | zyga: ah i see, but i assume files in it are created by snapd? | 17:38 |
| zyga | davhou: when this error happens | 17:38 |
| zyga | nacc: nope, unless you are using edge | 17:38 |
| davhou | zyga, what would you like to know? | 17:38 |
| ogra_ | davhou, better go with zyga than me ... he is deeper into snapd stuff | 17:38 |
| zyga | davhou: also, can you share 'dmesg | grep DENIED' | 17:38 |
| nacc | zyga: ok, just funny to see a directory called /run/snapd not contain files ... from snapd? :) | 17:39 |
| zyga | nacc: snapd and snap-confine are both from the same project, different programs though | 17:39 |
| nacc | zyga: ah i see | 17:39 |
| Chipaca | zyga: can I kill NoneSecurityTag? nothing uses it | 17:39 |
| zyga | nacc: (there are more) | 17:39 |
| zyga | Chipaca: are you sure? I bet it is used by udev) | 17:39 |
| davhou | last two lines... | 17:39 |
| davhou | [105316.495420] audit: type=1400 audit(1495213933.488:79): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/lock/" pid=76593 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 | 17:39 |
| davhou | [106747.330295] audit: type=1400 audit(1495215368.207:84): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/lock/" pid=96954 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 | 17:39 |
| zyga | Chipaca: it was made for udev | 17:39 |
| ogra_ | nacc, and you have any snaps installed ?? | 17:39 |
| zyga | davhou: ok, can you tell me which distribution are you using | 17:40 |
| zyga | davhou: or better | 17:40 |
| zyga | davhou: share "snap version" please | 17:40 |
| Chipaca | zyga: grep says no | 17:40 |
| Chipaca | $ grep -r NoneSecurityTag | 17:40 |
| Chipaca | snap/info.go:// NoneSecurityTag returns the security tag for interfaces that | 17:40 |
| Chipaca | snap/info.go:func NoneSecurityTag(snapName, uniqueName string) string { | 17:40 |
| nacc | ogra_: hrm, `snap list` says core is installed but not sure that counts | 17:40 |
| zyga | Chipaca: very odd, please keep it, we had uses for it (real uses) | 17:40 |
| ogra_ | nacc, core should have a lock file i guess | 17:40 |
| Chipaca | zyga: it's untested >:-( | 17:40 |
| ogra_ | it does here | 17:40 |
| Chipaca | zyga: :-) | 17:40 |
| davhou | zyga, Check above at 13:29:17 for 'snap --version' | 17:41 |
| zyga | davhou: can you also check what does ls /etc/apparmor.d/usr.lib.snapd.snap-confine.real* return? | 17:41 |
| nacc | ogra_: yeah, it seems oddly inconsistent. Not a big deal to debug right now, as I think davhou's issue is presumably more pressing :) | 17:41 |
| zyga | davhou: thanks, looking | 17:41 |
| zyga | aha, I see | 17:41 |
| ogra_ | everything pretty recent and sane there | 17:41 |
| zyga | davhou: give me a sec, checking something | 17:42 |
| davhou | david@david-VirtualBox:~⟫ ls /etc/apparmor.d/usr.lib.snapd.snap-confine.real* | 17:42 |
| davhou | sorry, trying again | 17:42 |
| davhou | david@david-VirtualBox:~⟫ ls /etc/apparmor.d/usr.lib.snapd.snap-confine.real* | 17:42 |
| davhou | /etc/apparmor.d/usr.lib.snapd.snap-confine.real /etc/apparmor.d/usr.lib.snapd.snap-confine.real.dpkg-new | 17:43 |
| zyga | aha!!! | 17:44 |
| zyga | davhou: can you diff -u those two files | 17:44 |
| zyga | davhou: and pastebin this | 17:44 |
| zyga | davhou: this is the reason it failed | 17:45 |
| zyga | davhou: but I must ask, did you edit the file before? | 17:45 |
| davhou | which file? | 17:45 |
| zyga | davhou: or perhaps, did you run an upgrade that failed/did not complete? | 17:45 |
| zyga | davhou: /etc/apparmor.d/usr.lib.snapd.snap-confine.real | 17:45 |
| zyga | davhou: if you run: sudo dpkg --configure -a | 17:45 |
| davhou | i did an upgrade recently to 16.0.2 | 17:45 |
| zyga | davhou: what does that do? | 17:45 |
| davhou | 16.04.2 | 17:45 |
| zyga | davhou: that file looks like a partial update occured | 17:45 |
| davhou | ok, so you want a diff of those 2 files you asked me to ls ? | 17:46 |
| zyga | yes, please! | 17:46 |
| davhou | ok | 17:46 |
| zyga | and then do the dpkg --configure -a | 17:46 |
| davhou | coming up in pastebin, one sec | 17:46 |
| zyga | I suspect it will finish configuring snap-confine | 17:46 |
| davhou | ok | 17:46 |
| zyga | and the issue will go away | 17:46 |
| zyga | or you had a prompt during upgrade | 17:46 |
| zyga | and it asked you what to do | 17:46 |
| zyga | (which is terrible) | 17:46 |
| nacc | zyga: nice catch | 17:46 |
| zyga | then you got a default reply 'keep the locally installed file' | 17:46 |
| davhou | I suspect you are right | 17:46 |
| zyga | which is equal to "break snapd" | 17:47 |
| davhou | nice | 17:47 |
| davhou | those are not easy ?s to answer... | 17:47 |
| zyga | yep | 17:47 |
| zyga | we should move this file out out etc | 17:47 |
| zyga | it's a constant pain | 17:47 |
| zyga | jdstrand: ^^ FYI | 17:47 |
| davhou | https://paste.ubuntu.com/24606043/ | 17:48 |
| zyga | looking | 17:48 |
| zyga | ha | 17:48 |
| zyga | :) | 17:48 |
| zyga | so | 17:48 |
| zyga | to fix your immediate issue | 17:48 |
| zyga | sudo dpkg --configure -a | 17:49 |
| zyga | and see if that does anything | 17:49 |
| davhou | it's setting up and processing a bunch of things... | 17:49 |
| zyga | your upgrade was interrupted somewhere | 17:49 |
| davhou | ok | 17:49 |
| zyga | davhou: it can cause your system not to boot in extreme cases | 17:50 |
| zyga | davhou: once that is done | 17:50 |
| zyga | davhou: follow up with "sudo apt-get dist-upgrade" | 17:50 |
| zyga | davhou: as more packages are bound to be updated | 17:50 |
| zyga | davhou: this is just finishing what was started, updated partially, and not finished | 17:50 |
| davhou | i was experiencing some odd video scaling that i could not explain | 17:50 |
| davhou | hopefully this will help that also | 17:50 |
| zyga | I bet it will | 17:50 |
| davhou | ok, will follow up as asked when this is done | 17:51 |
| zyga | davhou: good luck :) | 17:51 |
| davhou | thanks for all your help zyga and ogra_ | 17:51 |
| zyga | o/ :-) | 17:52 |
| adfad666 | pardon the interruption, can someone point me towards a device repo that also builds u-boot, i'm used to bringing up android devices but ubuntu snappy is a whole new world for me, looking for something to study | 17:52 |
| zyga | adfad666: I think you want to talk to ogra_ ::) | 17:52 |
| zyga | adfad666: look at github.com/snapcore/pi2-gadget | 17:53 |
| zyga | adfad666: but that is not building it from source _I think_ | 17:53 |
| zyga | anyway, ogra is the man to talk to | 17:53 |
| adfad666 | thanks, i'll take a look at that | 17:54 |
| davhou | noticed this during --configure -a | 17:54 |
| davhou | Installing new version of config file /etc/apparmor.d/usr.lib.snapd.snap-confine.real ... | 17:54 |
| zyga | davhou: see :") | 17:54 |
| zyga | davhou: that will fix your snapd | 17:54 |
| davhou | awesome | 17:55 |
| zyga | davhou: this is essentially telling you that the file that was unpacked is now moved to the place where it was supposed to be | 17:55 |
| davhou | ok | 17:55 |
| zyga | davhou: but because the binaries were done earlier it was all broken | 17:55 |
| davhou | makes sense | 17:55 |
| zyga | davhou: dpkg cannot handle that better unfortunately | 17:55 |
| davhou | not sure why I didn't realize the upgrade was interrupted somehow | 17:56 |
| davhou | guess the hammer was too small : - ) | 17:56 |
| * zyga needs to help with the kids, ttyl | 17:56 | |
| davhou | if there was one | 17:56 |
| davhou | k | 17:56 |
| davhou | zyga, I had success with running 'snap run simplenote' after 'dpkg --configure -a' & 'sudo apt-get dist-upgrade' ! | 18:12 |
| davhou | zyga, Again, thanks for all your help in helping me to resolve the issue | 18:13 |
| mcphail | Is there a plugin for a repo with a "debian" directory to automatically resolve dependencies etc in snapcraft, or does it always have to be done by hand? | 18:27 |
| Chipaca | davhou: FWIW if you can train yourself to use "apt" instead of "apt-get", things are much better (plus it's nicer in a lot of other ways) | 18:27 |
| Chipaca | kyrofa: ^ mcphail's is for you :-D (I think?) | 18:28 |
| Chipaca | as for me, I'm EOW'ing | 18:28 |
| mcphail | Chipaca: have a good weekend | 18:29 |
| Chipaca | mcphail: you too! | 18:30 |
| Chipaca | I've got a new guitar to play with, so the weekend is looking good | 18:30 |
| Chipaca | :-D | 18:30 |
| mcphail | What did you get? | 18:30 |
| Chipaca | my first electric! | 18:31 |
| mcphail | Ha! You'll find it so much more fun than acoustic, and much easier to play. Enjoy! | 18:32 |
| Chipaca | an ibañez S521 | 18:32 |
| Chipaca | went in looking at a fender telcaster thinline, but ended liking this one better | 18:33 |
| mcphail | One of my mates used to swear by ibanez. He could make it make ridiculous sounds. Have a lot of fun and turn it up to 11 | 18:34 |
| kyrofa | mcphail, Chipaca sorry I missed your ping! Busy day! | 18:36 |
| kyrofa | mcphail, you mean if the snapcraft.yaml is in the same tree as the debian dir? | 18:37 |
| mcphail | kyrofa: yes. is it possible to cheat and use the debian dir? | 18:39 |
| kyrofa | mcphail, not by default, but you can probably write something really simple that uses python-debian to do it | 18:40 |
| mcphail | kyrofa: ok. Cheers | 18:40 |
| mcphail | kyrofa: i'm really just being lazy ;) | 18:41 |
| kyrofa | mcphail, snapcraft depends on python3-debian, so it should always be there | 18:41 |
| kyrofa | mcphail, well, who wants to maintain that list in two places? I hear ya | 18:41 |
| mcphail | I thought there was chat about a tool to automagically snappify debian packages, but I may be misremembering | 18:43 |
| kyrofa | mcphail, I think that was taking an already-built deb, which is easy | 18:44 |
| mcphail | aah. ok. | 18:44 |
| niemeyer | Need to step out for an errand and school run.. will be back later today | 18:51 |
| mup | PR snapcraft#1325 closed: cli: proper error for failed snap command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1325> | 18:59 |
| mup | PR snapcraft#1324 closed: Revert "tests: remove the reusable parts tour test (#1321)" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1324> | 19:50 |
| mup | PR snapcraft#1326 opened: Release changelog for 2.30 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1326> | 20:47 |
| mup | PR snapd#3362 opened: Timedatectl <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3362> | 22:04 |
| mup | PR snapd#3363 opened: cmd: test everything (100% coverage \o/) <Created by chipaca> <https://github.com/snapcore/snapd/pull/3363> | 22:28 |
| mup | PR snapd#3362 closed: Allow snaps to use the timedatectl utility <Created by tyhicks> <Closed by tyhicks> <https://github.com/snapcore/snapd/pull/3362> | 23:13 |
| mup | PR snapd#3364 opened: Allow snaps to use the timedatectl utility <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3364> | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!