| === Conan_Kudo is now known as Pharaoh_Atem | ||
| mborzecki | morning | 05:14 |
|---|---|---|
| mborzecki | super trivial PR https://github.com/snapcore/snapd/pull/7057 | 06:26 |
| zyga | good morning | 06:30 |
| mborzecki | zyga: hey | 06:30 |
| mborzecki | zyga: super simple PR to start your day ^^ | 06:30 |
| zyga | already +1 | 06:30 |
| mborzecki | zyga: thanks! | 06:30 |
| zyga | mborzecki: I merged the master version of https://github.com/snapcore/snapd/pull/7056 a second ago | 06:31 |
| mborzecki | zyga: yay ;) | 06:31 |
| zyga | should I just merge the 2.40 backport? | 06:32 |
| mborzecki | zyga: did mvo look at it yet? | 06:33 |
| zyga | at the original yes +1 | 06:33 |
| zyga | the backport is the same for 2.40 branch | 06:33 |
| zyga | nobody looked at the backport | 06:33 |
| zyga | but it's just cherry-pick of a range | 06:33 |
| mborzecki | zyga: looks like nothing was missed there | 06:42 |
| mborzecki_ | mvo: hey | 06:46 |
| === mborzecki_ is now known as mborzecki | ||
| zyga | mvo: hey, 2.40 backport of base migration is merged | 06:56 |
| zyga | mvo: as is the master version | 06:56 |
| zyga | brb | 06:57 |
| mvo | hey mborzecki and zyga | 06:59 |
| mvo | zyga: excellent | 07:00 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:13 |
| mborzecki | pstolowski: hey | 07:18 |
| mvo | hey pstolowski | 07:18 |
| zyga | re | 07:20 |
| mvo | zyga: re 7053> I updated the description, feel free to update as you want, just wanted to do a draft to give an idea what I had in mind with my comment | 07:22 |
| zyga | mvo: sure, I'll look shortly, just making a commit message | 07:22 |
| mvo | zyga: no rush | 07:22 |
| zyga | mvo: this is what we discussed on Monday https://github.com/snapcore/snapd/pull/7058 | 07:30 |
| zyga | mvo: not sure if you want it in 2.40 - but at least now it is up and we can discuss it | 07:30 |
| pedronis | sounds it needs a jdstrand review anyway | 07:31 |
| pedronis | also I heard the motivation but not the details of what it entails | 07:32 |
| zyga | pedronis: this is based on the discussions in lyon and montreal, jamie was +1 on this | 07:33 |
| zyga | pedronis: how should I proceed on that? | 07:33 |
| pedronis | may recollection of lyon wasn't so clear that jamie was +1 | 07:34 |
| pedronis | my | 07:34 |
| pedronis | we need a meeting with him next to go over the consequences of this again | 07:34 |
| pedronis | *next week | 07:35 |
| zyga | pedronis: we discussed this more in montreal | 07:35 |
| zyga | ah, right, he's off this week | 07:35 |
| pedronis | I was not there | 07:35 |
| pedronis | so, I fear, you'll have to bear with me | 07:35 |
| zyga | sure no worries :) | 07:35 |
| mvo | I can setup a meeting, early next week? | 07:36 |
| pedronis | yes | 07:36 |
| mvo | gustavo as well? | 07:37 |
| pedronis | mvo: not in the first meeting, he was mostly +1 in lyon | 07:38 |
| mvo | cool | 07:38 |
| mvo | zyga, pedronis meeting setup | 07:38 |
| zyga | thank you! | 07:39 |
| mvo | (and now even added conferencing - oh I wish there was a way to make this default) | 07:39 |
| diddledan | that one caught me out in Montreal - I'm using a mainline kernel for Microsoft Surface out of tree patches | 07:41 |
| diddledan | I've filed a PR on the linux-surface repo to hopefully add the required bits for their kernel to support snaps out of the box on Ubuntu | 07:42 |
| diddledan | I think the bit missing was the apparmor patch for "legacy network" stuff (apparmor uses the feature flag "network" as opposed to their new "network_v8") | 07:43 |
| zyga | diddledan: thanks, that's interesting | 07:46 |
| diddledan | specifically apparmor in mainline exposes network_v8 not network. the patch re-adds network so Apparmor exposes both feature flags | 07:46 |
| diddledan | this is the patch that Apparmor carries out of tree: https://gitlab.com/apparmor/apparmor/commit/aa42e338600ab6b5a1368dc5c4920974192adfd1 | 07:47 |
| zyga | diddledan: I'll discuss this with jdstrand when he is back | 07:49 |
| diddledan | cool | 07:49 |
| diddledan | https://forum.snapcraft.io/t/proposal-to-change-the-channels-display-of-snap-info/12134 | 08:14 |
| Chipaca | no wonder you all were quiet :-) | 08:40 |
| mvo | Chipaca: how do you mean? | 08:48 |
| Chipaca | mvo: irc client had quietly disconnected | 08:48 |
| Chipaca | or quietly never connected? | 08:49 |
| mvo | Chipaca: haha - now it makes sense :) | 08:49 |
| diddledan | "accident" my foot! | 08:55 |
| Chipaca | diddledan: I'll have you know I have no IRC clients in my foot. | 09:01 |
| Chipaca | diddledan: I'll have you know I have no *IRC* clients in my foot. | 09:02 |
| Chipaca | diddledan: I'll have you know I have no IRC *clients* in my foot. | 09:02 |
| Chipaca | diddledan: I'll have you know I have no IRC clients *in* my foot. | 09:02 |
| Chipaca | diddledan: I'll have you know I have no IRC clients in *my* foot. | 09:02 |
| Chipaca | diddledan: I'll have you know I have no IRC clients in my *foot*. | 09:02 |
| * Chipaca stops before doing combinations | 09:02 | |
| diddledan | you have other clients in your foot? | 09:02 |
| Chipaca | I can't comment | 09:04 |
| * zyga is sleepy | 09:15 | |
| Chipaca | zyga: amen | 09:15 |
| Chipaca | my watch reckons i got 5h of sleep | 09:15 |
| Chipaca | i think it's about right | 09:15 |
| pedronis | you merged some things fairly late, I saw | 09:17 |
| Chipaca | and then rebased the followup | 09:17 |
| Chipaca | which was fun | 09:17 |
| Chipaca | and then did the bi-weekly supermarket shop while waiting for spread | 09:17 |
| Chipaca | amazon linux is sad :-( | 09:18 |
| Chipaca | # github.com/snapcore/snapd/cmd/snap | 09:19 |
| Chipaca | src/github.com/snapcore/snapd/cmd/snap/cmd_info.go:93:13: undefined: strings.Builder | 09:19 |
| Chipaca | error: Bad exit status from /var/tmp/rpm-tmp.wKuf9u (%build) | 09:19 |
| Chipaca | hmmmmm | 09:19 |
| zyga | Chipaca: too old go | 09:19 |
| zyga | cannot use strings.Builder yet | 09:19 |
| * zyga takes a 15 minute break | 09:20 | |
| Chipaca | why aren't the unit tests catching this :-( | 09:20 |
| Chipaca | … because they're run on 1.10 | 09:20 |
| Chipaca | why are we running the unit tests on 1.10? | 09:21 |
| mvo | I thought all our downstreams now are on go-1.10 is this not the case? if so we need to go back to 1.9 there :/ | 09:21 |
| Chipaca | I thought so as well | 09:22 |
| zyga | Chipaca: which os was this on? | 09:23 |
| zyga | amazon? | 09:23 |
| zyga | zOMGon | 09:23 |
| Chipaca | https://api.travis-ci.org/v3/job/553521524/log.txt | 09:23 |
| Chipaca | it's on 1.9.4 apparently | 09:24 |
| pedronis | we run on 1.10 because fmt changed I think | 09:24 |
| pedronis | mborzecki might remember the exact reason | 09:25 |
| mborzecki | hm hm? | 09:25 |
| Chipaca | BuildRequires: %{?go_compiler:compiler(go-compiler)}%{!?go_compiler:golang >= 1.9} | 09:25 |
| Chipaca | we're just asking for 1.9 in amazon | 09:25 |
| Chipaca | wait that's fedora spec | 09:25 |
| Chipaca | :-| | 09:25 |
| pedronis | we can run the static tests on 1.10 | 09:25 |
| pedronis | and the unit on 1.9 ? | 09:25 |
| Chipaca | mborzecki: it seems #6799 was premature | 09:26 |
| zyga | ancient linux | 09:26 |
| mborzecki | hm let me check something | 09:26 |
| Chipaca | pedronis: mborzecki: I'll push a pr to bump it down to 1.9 unless mborzecki finds something interesting :-) | 09:27 |
| pedronis | Chipaca: I remember we had a reason | 09:27 |
| pedronis | but I don't think it applied to all tests | 09:27 |
| mborzecki | pedronis: yeah, there's a pr from jdstrand mentioning 1.10 | 09:28 |
| Chipaca | but it's ok | 09:28 |
| Chipaca | it uses something that's there from 1.7 | 09:28 |
| Chipaca | user.LookupGroup | 09:28 |
| pedronis | anyway my vague recollection is that go fmt output changed at some point | 09:29 |
| Chipaca | i can easily split static and unit tests | 09:30 |
| mborzecki | pedronis: gofmt too, though it's 1.11 i belive that broke it | 09:31 |
| mborzecki | heh so centos gets a newer golang than amazon linux 2 now? | 09:32 |
| mborzecki | centos 7 via epel - 1.11, amzn2 via amazon core repo 1.9 :/ | 09:38 |
| mborzecki | Chipaca: so, switching back to 1.9? | 09:38 |
| Chipaca | ye | 09:39 |
| zyga | mborzecki: https://bugzilla.redhat.com/show_bug.cgi?id=1726382 do you understand what this is about? | 09:40 |
| mborzecki | zyga: doesn't make any sense | 09:42 |
| pstolowski | preliminary results of optimization of connects wrt setup-profiles, with lxd snap that connects 4 interface: old snapd - https://paste.ubuntu.com/p/5ZVNkBxVqQ/ ; new snapd - https://paste.ubuntu.com/p/F69TGbWWtg/ ; almost 3x faster (sum of connect+final setup profiles timings) | 09:43 |
| diddledan | \o/ | 09:43 |
| Chipaca | pstolowski: try something beefier, like vlc | 09:44 |
| mborzecki | zyga: i'll check what's going on there | 09:44 |
| Chipaca | pstolowski: just to show off :-) | 09:44 |
| pstolowski | :D | 09:44 |
| pstolowski | good idea | 09:44 |
| mvo | pstolowski: woah, thats sooo nice | 09:46 |
| pstolowski | yeah, install of lxd snap feels much faster now | 09:46 |
| pstolowski | and this is what we had in the past before, cough cough, interface hooks | 09:47 |
| mvo | heh | 09:47 |
| pedronis | pstolowski: are you moving setting up profiles to one call to setup-profiles after the connects ? | 09:58 |
| pstolowski | pedronis: yes, final setup-profiles after connects (but before connect-plug|slot hooks). existing setup-profiles after link-snap remains untouched. | 10:00 |
| Chipaca | pedronis: have you seen https://forum.snapcraft.io/t/bug-1809708-allow-snaps-to-query-interface-connection-status-directly-from-snapd/9147?u=chipaca ? | 10:01 |
| pedronis | pstolowski: ok, it's important to know because the plan was to drop setup-profiles | 10:01 |
| pedronis | when is merged with link-snap | 10:01 |
| pedronis | we need that anyway | 10:01 |
| pstolowski | pedronis: hmm wrt what Chipaca was about to do? | 10:01 |
| pedronis | but it's orthogonal issue | 10:01 |
| pedronis | but we need to know if we need to merge the logic into the other as well | 10:01 |
| pedronis | but keep it around otherwise | 10:02 |
| pedronis | pstolowski: yes, Chipaca's work | 10:02 |
| pstolowski | right | 10:02 |
| pedronis | Chipaca: we have had similar requests already, I think it's in our backlog but not scheduled, needs also a final design | 10:03 |
| pstolowski | vlc installation: 4300ms vs 1600ms (connects+setup profiles only) | 10:08 |
| pstolowski | that's on a vm | 10:10 |
| mborzecki | zyga: added needinfo from the reporter, things seem to work fine on my end | 10:14 |
| zyga | thanks | 10:14 |
| zyga | mvo: I created https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139 | 10:16 |
| mborzecki | Chipaca: https://github.com/snapcore/snapd/pull/7060 is failing unit tests due to build ID | 10:17 |
| mborzecki | Chipaca: so the details are coming back a bit, iirc 1.10+ adds Go BuildID by default | 10:18 |
| mborzecki | earlier versions would only get it iff built with external linker that was configured to add it (didn't we have question about that regarding gentoo in the forums?) | 10:19 |
| * zyga spawns a pair of spread runs and goes to make coffee | 10:19 | |
| zyga | mborzecki: another fedora fun https://bugzilla.redhat.com/show_bug.cgi?id=1675023 | 10:24 |
| mborzecki | zyga: golang-github-gosexy-gettext? haha | 10:26 |
| mborzecki | zyga: i'd like to see people behind corporate filters trying to access github page of that package | 10:27 |
| zyga | yeah | 10:27 |
| zyga | https://www.tomshardware.com/news/india-shakti-cpu-processors-sdk-risc-v,39781.html <- maybe more risc v boards soon? | 10:27 |
| Chipaca | mborzecki: an easy & lazy fix would be to tag the build id checking tests as not-short | 10:29 |
| mvo | zyga: we don't use gosexy-gettext anymore, do we? | 10:32 |
| zyga | mvo: but I am the package maintainer | 10:32 |
| zyga | need to do something about it | 10:33 |
| mvo | zyga: oh, ok | 10:33 |
| diddledan | RISC-V is intriguing. I'm curious how soon we'll see someone try to make a workstation with one | 10:34 |
| diddledan | I kinda think though that x86(64) is too entrenched for consumer migration in any meaningful numbers | 10:36 |
| diddledan | in terms of IoT though I can see it breaking through | 10:36 |
| mborzecki | Chipaca: i think the problem is actually osutil dropping the need for import C more than go version switch, that's just a side effect | 10:37 |
| Chipaca | diddledan: what is the talos workstation | 10:37 |
| diddledan | that's powerpc IIRC | 10:38 |
| diddledan | power9? | 10:38 |
| Chipaca | ah, yes | 10:38 |
| Chipaca | sorry | 10:38 |
| Chipaca | power8 | 10:38 |
| diddledan | it's suffering an off-by-one ;-p | 10:38 |
| Chipaca | same | 10:39 |
| Chipaca | hmm, i'm going to go lie down for a bit | 10:42 |
| * Chipaca not improving with time | 10:43 | |
| * zyga has coffee now | 10:46 | |
| zyga | mvo: let me know when you have a chance to look at https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139 | 10:48 |
| pedronis | zyga: I'll have to look at it too | 11:00 |
| zyga | thank you | 11:00 |
| zyga | pedronis: any more ideas are welcome, this captures what we discussed during the call on monday | 11:01 |
| pedronis | interesting | 11:02 |
| zyga | perhaps there is an easier way to fix it that we did not think about | 11:02 |
| pstolowski | mvo, pedronis: long overdue - https://forum.snapcraft.io/t/snap-debug-timings/12141 | 11:05 |
| zyga | I made some small typos/formatting changes | 11:06 |
| zyga | mainly commas | 11:06 |
| pstolowski | will ask Graham for proof-reading as well when he is back | 11:06 |
| pstolowski | zyga: thanks, re-reading myself again | 11:06 |
| pstolowski | 56455ms - Save data of snap "lxd" in automatic snapshot set #1 | 11:07 |
| pstolowski | yuk | 11:07 |
| mvo | zyga: yes, I have a look once I am finished with my current uc20 part | 11:12 |
| mborzecki | https://forum.snapcraft.io/t/segmentation-fault-running-snapcraft-on-arch-linux/12142/2 hm python3 segfaulting on arch | 11:12 |
| zyga | mvo: super, thank yuo | 11:12 |
| zyga | *you | 11:12 |
| * pstolowski lunch | 11:16 | |
| pedronis | Chipaca: there is something strange in the diff of 6878, it seems to be adding back (again) maybePrintType etc ? | 11:34 |
| pedronis | some merge artifact? | 11:34 |
| Chipaca | pedronis: merge artifact indeed | 11:43 |
| Chipaca | pedronis: I'll clean it up, and address your other points | 11:43 |
| Chipaca | pedronis: indeed at some point i forgot we meant health to be multi-line in info | 11:44 |
| pedronis | Chipaca: I don't have a strong opinion about not-verbose, but for verbose it should be | 11:44 |
| Chipaca | for some reason i thought git would do a proper job of merging things given I started from the thing that then caused conflicts everywhere | 11:44 |
| mvo | cmatsuoka: I hope I will have the updated recovery dir layout ready by the standup, mostly fyi, fighting with the last small issues | 11:59 |
| ogra | Chipaca, just switch to bzr | 11:59 |
| cmatsuoka | mvo: great, I'm running some tests to check the stability issues with the updated core20 snap | 12:00 |
| mvo | cmatsuoka: thank you | 12:01 |
| mvo | cmatsuoka: is it updated already? iirc I just proposed a pr. anyway we can talk after my lunch :) | 12:01 |
| cmatsuoka | mvo: not updated, I'm building it locally | 12:02 |
| Chipaca | ogra: alias git='bzr --rotated-90-degrees --extra-complicated --zippy' | 12:04 |
| ogra | haha | 12:05 |
| ogra | (so true) | 12:06 |
| mborzecki | is glibc locale archive a memory dump of structures? | 12:07 |
| cmatsuoka | mvo: but my build just failed, this snap seems to be a bit tricky to build | 12:07 |
| === ricab is now known as ricab|ricab | ||
| * zyga goes for lunch | 12:28 | |
| Chipaca | pedronis: wrt health's position in the struct, it seemed like the sensible place to put it, looking at the types of the things | 12:34 |
| pedronis | Chipaca: I shall look at the full struct then | 12:34 |
| Chipaca | pedronis: txs | 12:35 |
| ijohnson | hey mvo, could you add me to the SU meeting invite? I don't have it on my calendar yet | 12:41 |
| zyga | I'm online but having lunch with family at the seaside | 12:54 |
| zyga | and sending updates to spread.zygoon.pl | 12:54 |
| zyga | over that uncapped LTE | 12:54 |
| ijohnson | morning zyga | 12:56 |
| zyga | hey ijohnson :) | 12:56 |
| zyga | ijohnson: I'm semi afk but I can read updates once in a while | 12:57 |
| mvo | ijohnson: sure, done | 12:57 |
| zyga | mvo: and perhaps the github team, if not done already | 12:58 |
| ijohnson | zyga: ok, np. did you see my post at https://forum.snapcraft.io/t/mount-namespace-walkthrough-wip/12127 ? it's still a wip but I've gotten most of the way through snap-confine at least | 12:58 |
| zyga | ijohnson: I did not, queued | 12:58 |
| mvo | zyga: I think I did that, hope added to all the right places :) | 12:58 |
| ijohnson | the only thing I'm still missing I think is spread access | 12:58 |
| zyga | looks good | 12:58 |
| zyga | I will read the details and comment | 12:59 |
| ijohnson | great, thanks | 12:59 |
| ijohnson | mvo: got it thanks! | 12:59 |
| zyga | ijohnson: I'm trying to build a new flow, with snap-boostrap-ns, reusing snap-update-ns, where C does less stuff and snap-update-ns has only one entry point that is stricter than now (from snapd) | 12:59 |
| mvo | yay | 12:59 |
| ijohnson | zyga: I need to dig in a bit more, but the whole preinit_array thing with cgo I've seen done in pure go with a docker package called re-exec | 13:00 |
| ijohnson | (for bootstrap.c in snap-update-ns) | 13:00 |
| zyga | ijohnson: one motivation is to remove C from snap-update-ns as well | 13:00 |
| zyga | ijohnson: anyway, that's for later, I'm just sharing thoughts | 13:00 |
| zyga | ijohnson: the goal is to streamline snap-update-ns and remove C as much as we can | 13:00 |
| zyga | ijohnson: the new binaries would be easier to understand than the multi-purpose one we currently have | 13:02 |
| * zyga focuses on the food now | 13:02 | |
| ogra | ogra@pi4:~ $ grep ^NAME /etc/os-release | 13:03 |
| ogra | NAME="Raspbian GNU/Linux" | 13:03 |
| ogra | ogra@pi4:~ $ snapcraft --version | 13:03 |
| ogra | snapcraft, version 3.6 | 13:03 |
| ogra | :D | 13:04 |
| ogra | oh ... something is broken ! | 13:05 |
| ogra | ogra@pi4:~ $ sudo snap install lxd | 13:05 |
| ogra | [sudo] Passwort für ogra: | 13:05 |
| ogra | Warning: /snap/bin was not found in your $PATH. If you've not restarted your session since you | 13:05 |
| ogra | ... | 13:05 |
| ogra | ogra@pi4:~ $ echo $PATH | 13:05 |
| ogra | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/snap/bin | 13:06 |
| ogra | ... | 13:06 |
| ogra | thast definitely a flashe positive | 13:06 |
| ogra | *false | 13:06 |
| zyga | ogra: nice | 13:06 |
| zyga | ogra: sudo | 13:06 |
| zyga | ogra: sudo changes PATH | 13:06 |
| ogra | is debian different here ? | 13:06 |
| ogra | i have never seen that on ubuntu | 13:07 |
| ogra | ogra@pi4:~ $ sudo echo $PATH | 13:07 |
| ogra | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/snap/bin | 13:07 |
| zyga | yes | 13:07 |
| zyga | sudo -s | 13:07 |
| zyga | echo $PATH | 13:07 |
| zyga | otherwise PATH is expanded by the non-root shell | 13:08 |
| ogra | ah, right | 13:08 |
| ogra | yeah | 13:08 |
| ogra | now i wish i had a u-boot tree :( i want core ! | 13:08 |
| zyga | how does it boot? | 13:09 |
| ogra | rpi firmware boots a kernel.img directly | 13:09 |
| ogra | (and nop initrd at all as far as i can see) | 13:10 |
| ogra | *no | 13:10 |
| ogra | (like all other pi's essentially ... ) | 13:11 |
| zyga | ogra: that's interesting | 13:11 |
| ogra | whats interesting about it ? it is the same bootprocess they use since day one | 13:12 |
| ogra | and as usual we have to wait for a u-boot port before we can move on with core | 13:12 |
| ogra | i'm sure something will show up within the next weeks | 13:12 |
| zyga | ogra: but you can have an initrd, right? | 13:13 |
| ogra | you can hack one into config.txt yeah | 13:13 |
| ogra | there is an option for defining one | 13:14 |
| zyga | and that firmware is still closed-source, right? | 13:14 |
| ogra | yup ... it the graphics driver | 13:14 |
| ogra | *it's | 13:14 |
| ogra | the pi boots by first firing up the GPU ... the GPU then turns on the arm SoC | 13:15 |
| ogra | thats why you for example dont really need an extra graphics driver at all ... just some userspace libs | 13:15 |
| ogra | they interface dircetly with the GPU driver/bootloader blob | 13:16 |
| ogra | *directly | 13:16 |
| ogra | ogra@pi4:~ $ free -m|grep ^Mem | 13:18 |
| ogra | Mem: 3906 105 3299 8 500 3668 | 13:18 |
| mborzecki_ | ogra: sudo -i should work too | 13:18 |
| ogra | i like that one :) | 13:18 |
| === mborzecki_ is now known as mborzecki | ||
| ogra | mborzecki_, yeah, i was just not aware that debians sudo is different to ours ... i'm used to sudo not making a mess out of my env :) | 13:19 |
| mborzecki | ogra: fedora's sudo does the same | 13:19 |
| ogra | yep ... i bet suse's too | 13:19 |
| ogra | (or upstream FWIW ... but if you are used to userfriendlyness it is confusing :) ) | 13:20 |
| mborzecki | Chipaca: maybe we could just skip a test in osutil for go < 1.10 and mock buildid in api and system-key tests? | 13:23 |
| mborzecki | Chipaca: unless there's a way to pass build flags to go test via //go:<somethingsomething>, though I'm no aware of anything like that | 13:24 |
| Chipaca | mborzecki: go test -tags=yadda and then //+build yadda | 13:26 |
| mborzecki | Chipaca: right, we'd need to update run-checks for that hmm | 13:27 |
| === ricab|ricab is now known as ricab | ||
| mborzecki | Chipaca: move the test to separate file with //+build go1.10 so that we don't need to guess the format of runtime.Version()? :) | 13:36 |
| Chipaca | mborzecki: I closed the PR, instead. That also worked. | 13:36 |
| * Chipaca takes practicality to a new level | 13:36 | |
| mborzecki | Chipaca: haha ;) ok, i can look into that | 13:37 |
| Chipaca | mborzecki: oh, i can too | 13:37 |
| Chipaca | but it needed more work and i didn't have the bandwidth to look so i closed it before wasting people's time | 13:37 |
| Chipaca | mborzecki: how full is your plate? | 13:37 |
| mborzecki | Chipaca: gadget updates & random ramblings, but I can look into working around that 1.9 quirk | 13:39 |
| mborzecki | pulseaudio -k a day keeps the insanity at bay | 13:41 |
| ogra | geez ... this snapshot default feature is very annoying | 13:50 |
| mborzecki | maybe we should ask the user the first time? | 13:54 |
| ogra | either that or make it opt in | 13:57 |
| ogra | snap remove --keep-data ... or whatnot | 13:58 |
| pedronis | it really depends on the size of the data, but yes the current UX is not great in some cases | 13:58 |
| Chipaca | ^C should still stop the removal and let you try again with --purge | 13:58 |
| ogra | i just installed snapcraft on this pi4 raspbian install ... forgot about the fact that this now needs multipass ... so the forst snapcraft run downloads multipass ... this then fails after creating a VM image for 10-20min ... | 13:59 |
| ogra | i then uninstall multipass (and snapcraft since it is uselass in that setup) ... and snapd keeps the rotten multipass VM image around | 13:59 |
| pedronis | Chipaca: does it work atm? | 13:59 |
| pedronis | I mean ^C | 13:59 |
| ogra | i could ^C out of it and it complained with an error | 14:00 |
| ogra | ogra@pi4:~/linux-generic-allwinner $ sudo snap remove multipass | 14:00 |
| ogra | Save data of snap "multipass" in automatic snapshot set #1 |error: cannot perform the following tasks: | 14:00 |
| ogra | - Save data of snap "multipass" in automatic snapshot set #1 (tar failed: context canceled) | 14:00 |
| ogra | ogra@pi4:~/linux-generic-allwinner $ | 14:00 |
| ogra | thats what i got with ^C ... | 14:00 |
| ogra | still, the experience is quite a mess | 14:01 |
| ogra | and indeed multipass is still around ... | 14:01 |
| ogra | snap help doesnt really talk about how to not have a snapshot taken on remove ... it only tells about how to manage snapshots | 14:01 |
| ogra | (i guess the info i'd be looking for is in the details of snap remove's help) | 14:02 |
| Chipaca | pedronis: it should | 14:02 |
| Chipaca | and yes abort is never pretty to see | 14:03 |
| mborzecki | mvo: got a lead on python3 segfaulting on arch | 14:03 |
| ogra | hrm ... | 14:03 |
| ogra | and snap remove help doesnt mention --purge at all | 14:03 |
| Chipaca | ogra: then you don't have a new enough snapd | 14:03 |
| Chipaca | ogra: disable it globally, instead | 14:03 |
| Chipaca | ogra: https://docs.snapcraft.io/system-options#heading--snapshots-automatic-retention | 14:04 |
| mborzecki | mvo: when i drop mymachines from /etc/nsswitch.conf it does not segfault anymore | 14:04 |
| zyga | mborzecki: time to top sharing /etc/ | 14:05 |
| zyga | and provide crafted view | 14:05 |
| zyga | but then classic snaps are ... complex to say the least | 14:05 |
| ogra | Chipaca, i'm finding my way around (and wont keep that raspbian anyway) ... but i'm trying to take this experimant like a snap-illiterate user ... and now i'm already sitting here with a mess :P | 14:05 |
| ogra | btw ... i have 2.39.3 according to snap version | 14:07 |
| ogra | $ sudo snap remove --purge multipass | 14:07 |
| ogra | error: unknown flag `purge' | 14:07 |
| ogra | $ snap version|grep snapd | 14:08 |
| ogra | snapd 2.39.3 | 14:08 |
| ogra | should that not have --purge already ? | 14:08 |
| Chipaca | that's an mvo question, i always get lost | 14:09 |
| ogra | heh | 14:09 |
| Chipaca | my snapd here has purge, but it also has set-health and 'snap info' shows health information | 14:10 |
| Chipaca | ¯\_(ツ)_/¯ | 14:10 |
| mborzecki | zyga: mvo: left a note https://forum.snapcraft.io/t/segmentation-fault-running-snapcraft-on-arch-linux/12142/6 | 14:11 |
| zyga | mmm | 14:12 |
| mvo | mborzecki: thank you | 14:20 |
| ogra | stgraber, https://paste.ubuntu.com/p/XGmFsskzHK/ ... lxd on raspbian ... do you think we could quieten the errors ? they look scary | 14:28 |
| ogra | (it seems to run find otherwise ... but if the errors ate "ignored" we could as well not show them at all) | 14:28 |
| ogra | *fine | 14:28 |
| stgraber | those messages come from the linker, not much we can do about it | 14:29 |
| ogra | hmm, k | 14:29 |
| stgraber | also we're not seeing those on other arm platforms, so that suggests there's something odd with raspbian | 14:29 |
| ogra | thats buster fwiw ... perhaps too new ? | 14:29 |
| ijohnson | ogra, stgraber: I see the same linker messages on stretch raspbian for a long time (since at least last year) so I don't think it's buster specific | 15:11 |
| ogra | ah ... its my first direct debian contact in years | 15:20 |
| ogra | (well, not true, i used armbian for 1h or so a while ago ... but not significant enough to notice issues) | 15:21 |
| pedronis | cachio: so I tried again, I'm not getting it to fail where I would expect, I'm getting this, notice the PAM errors | 15:42 |
| pedronis | cachio: https://paste.ubuntu.com/p/FX25MJhHWz/ | 15:42 |
| pedronis | cachio: I can push my test changes to the PR if it helps, or somewhere else | 15:44 |
| pedronis | Chipaca: I looked at the struct | 15:50 |
| Chipaca | pedronis: wdyt? | 15:52 |
| Chipaca | pedronis: ah ok | 15:53 |
| Chipaca | pedronis: and type? | 15:53 |
| Chipaca | asked there | 15:54 |
| Chipaca | going afk now for a bit | 15:54 |
| zyga | ijohnson: https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139/2 | 15:54 |
| pedronis | Chipaca: type can stay first field | 15:58 |
| pedronis | answered also in the PR | 15:59 |
| pedronis | cachio: I pushed my debugging tweaks (on top of my PR) here: https://github.com/pedronis/snappy/commit/9ef3d3b6cd8cd775110472346e5a00e9ecb729da | 16:03 |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | pedronis: (for later) - I played a bit in image.go, I wonder if something along the lines of http://paste.ubuntu.com/p/TFtXTX9FPz/ makes sense? | 16:25 |
| mvo | http://paste.ubuntu.com/p/TFtXTX9FP | 16:25 |
| mvo | pedronis: no rush, I have dinner now and we can talk later/tomorrow | 16:25 |
| cachio | pedronis, nice, taking a look now | 16:56 |
| cachio | pedronis, the tweaks seem to be well | 17:03 |
| cachio | are you creating a PR with those? | 17:03 |
| pedronis | cachio: they might be good, but if I try your repeat it doesn't die on the exit 1 | 17:26 |
| pedronis | but at other places | 17:26 |
| pedronis | which confuses me | 17:26 |
| cachio | pedronis, it is branking on snap pack? | 17:26 |
| pedronis | mvo: what about seed.yaml in that code? | 17:27 |
| pedronis | it doesn't exist in the new world | 17:27 |
| pedronis | cachio: it seems to be breaking at random points, sometimes | 17:32 |
| pedronis | but maybe is just spread not getting the full log back | 17:32 |
| pedronis | but I would expect to not break before the install | 17:32 |
| pedronis | but it seems to | 17:32 |
| cachio | pedronis, ok, I am testing the this | 17:35 |
| cachio | also there is a spread issue on reboots which I already fixed and I am using to check the failover test | 17:36 |
| cachio | are you merging that change in failover test with the #7020? | 17:37 |
| mvo | pedronis: yeah, its a first step, I did not touch seed.yaml just yet. its mostly about how to make this less messy, i.e. having a central place that defines where the snaps/assertions/... go into without springling if/else | 17:41 |
| mvo | pedronis: definitely more work here :) will poke more tomorrow | 17:41 |
| pedronis | mvo: are you planning to merge this to master? or is just spike stuff' | 18:04 |
| pedronis | ? | 18:04 |
| pedronis | cachio: I can merge if it helps or can open another PR, given that is not failing usefully, I'm not sure | 18:05 |
| mvo | pedronis: I was hoping to work on something that is master material | 18:09 |
| pedronis | mvo: that's ok, my feeling is that we have reached a point where master material should try to fix the FIXME | 18:10 |
| pedronis | there | 18:10 |
| pedronis | also I fear because of seed.yaml etc, that this too low granularity as the final solution for master | 18:10 |
| pedronis | also we don't have yet the new model syntax | 18:10 |
| mvo | pedronis: yeah | 18:12 |
| mvo | pedronis: its a first step only but I think its the right direction (or something like it) | 18:12 |
| mvo | pedronis: the seed.yaml will come next, some of seed.yaml will just go away, some will the options.yaml but we can cross that bridge when we reach it | 18:13 |
| mvo | pedronis: I can work further and remove the "dirs.SetRootDir" in bootloader config writing, I think that will be straightfoward. anyway, happy to talk more friday, I don't want to burden you in the evening with this stuff :) | 18:14 |
| mvo | (as its not really urgent) | 18:14 |
| pedronis | mvo: it's fine, I just feel it might be slightly premature | 18:16 |
| pedronis | still | 18:16 |
| zyga | re | 18:16 |
| pedronis | mvo: my worry is to write something targeting master, think to land it in 2 days and it takes 1week+ | 18:20 |
| pedronis | mvo: there's a lot of logic about unasserted/local snaps as well | 18:22 |
| pedronis | there | 18:22 |
| mvo | pedronis: right, happy to ignore it for now | 18:26 |
| pedronis | mvo: unclear why to target master though | 18:27 |
| pedronis | then | 18:27 |
| pedronis | sorry, I'm probably misunderstanding something here | 18:27 |
| mvo | pedronis: well, I was mostly thinking that we need to refactor this code anyway so I was thinking of doing it now because I was already working in this area for uc20 (so have some context in my head). its a bit fugly right now because of history messiness and now it got more if/else. I was hoping that with some small refactoring it would get a bit better. but if you feel its premature thats fine, I can ignore for now | 18:31 |
| pedronis | mvo: let me put this way, I'm not conviced yet that targetDirs is the right level of abstractions for what we need in the end | 18:32 |
| pedronis | it seems we have lots of details that are not just which dirs to use | 18:32 |
| pedronis | can we refactor 2 or 3 times, yes | 18:34 |
| pedronis | just not sure it's wise to setup to have to do that | 18:34 |
| mvo | ok | 18:35 |
| pedronis | mvo: sorry, I'm not trying to be negative, but so far we discussed not to try to hit master, and now we are considering it, and I have to raise my concerns | 18:40 |
| mvo | pedronis: its okay, no worries. fine to learn more first and then try to find the right level of abstraction. its true that there will be more changes needed regarding seed.yaml/options.yaml and the new model assertion so thats fine | 18:43 |
| cachio | pedronis, after 1 hour ef tests with your fix the error is not reproduced anymore | 18:44 |
| cachio | pedronis, that's relly promosing | 18:44 |
| pedronis | mvo: for example, I'm not sure the current assertion writing code is using case-insentive names | 18:47 |
| pedronis | for the files | 18:47 |
| pedronis | cachio: you mean my PR + the test change ? | 18:47 |
| mvo | pedronis: indeed, the coming abstraction will need to take this into account for uc20 it will write a stream in a reasonable filename for example. so yes, it seems to be fine to postpone until this is ready too | 18:51 |
| cachio | pedronis, sorry, didn't see your comment, yes that PR | 20:08 |
| cachio | pedronis, or the idea is to have 2 different PRs? | 20:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!