| === zigford_ is now known as zigford | ||
| === zigford_ is now known as zigford | ||
| mborzecki | morning | 05:04 |
|---|---|---|
| mvo | hey mborzecki ! good morning | 05:05 |
| mborzecki | mvo: hey | 05:06 |
| mborzecki | mvo: can you also cherry pick https://github.com/snapcore/snapd/pull/7188 ? | 05:10 |
| mvo | mborzecki: sure thing | 05:12 |
| mborzecki | mvo: thanks | 05:12 |
| mvo | mborzecki: thank *you* and done | 05:12 |
| mborzecki | mvo: oh, and a PR to spread with workarounds for bash 4.3 is open https://github.com/snapcore/spread/pull/85 | 05:14 |
| mborzecki | this will unblock https://github.com/snapcore/snapd/pull/7198 | 05:14 |
| mvo | zyga: does 7194 look good now? | 05:14 |
| mvo | mborzecki: nice, let me have a look | 05:15 |
| mvo | mborzecki: do you have more background on 7192, i.e. why not just use curl in bin/download-file? or was this discussed already? | 05:16 |
| mborzecki | mvo: nope | 05:17 |
| mvo | mborzecki: thats fine, I asked in the PR | 05:17 |
| mvo | mborzecki: did you see the question of samuele in 7087? | 05:57 |
| mvo | mborzecki: this is super close otherwise it seems | 05:57 |
| mborzecki | mvo: yes, i'll be adding a unit test there | 06:02 |
| mborzecki | snapd on rhel8 https://paste.ubuntu.com/p/Qdd9btRB6m/ :) | 06:07 |
| zyga | good morning | 06:10 |
| mborzecki | zyga: hey | 06:11 |
| * zyga is waking up | 06:15 | |
| mborzecki | and lxd from snaps works on rhel8 too | 06:19 |
| mvo | mborzecki: nice | 06:20 |
| zyga | simple one https://github.com/snapcore/snapd/pull/7247 | 06:30 |
| zyga | simple but not as trivial https://github.com/snapcore/snapd/pull/7248 | 06:30 |
| zyga | mvo: I'd like to discuss this idea with you and Samuele today https://github.com/snapcore/snapd/pull/7205 | 06:31 |
| zyga | ERROR: Conflicting profiles for /usr/lib/snapd/snap-confine defined in two files: | 06:37 |
| zyga | - /etc/apparmor.d/usr.lib.snapd.snap-confine | 06:37 |
| zyga | - /etc/apparmor.d/usr.lib.snapd.snap-confine.real | 06:37 |
| zyga | something is leaking .real vs plain profile | 06:37 |
| mborzecki | zyga: https://github.com/snapcore/snapd/pull/7249 asked neal for a review too | 06:40 |
| zyga | +1 | 06:43 |
| mvo | zyga: the conflicting profiles one I did see before | 06:45 |
| mvo | zyga: it seems random? or conistent? | 06:46 |
| zyga | I think it is deterministic if a pair of tests run in the right order | 06:48 |
| zyga | I’ll try to track it down | 06:48 |
| mvo | zyga: let me have a quick look, I have an idea | 06:50 |
| mvo | zyga: do you have a link to the log wit hthe conflicting profile? or remember on what distro release this happend? | 07:07 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:08 |
| pedronis | hello | 07:09 |
| mvo | hey pstolowski and pedronis ! | 07:10 |
| zyga | mvo: in a moment | 07:15 |
| mborzecki | pedronis: pstolowski: hey guys | 07:19 |
| mvo | 7250 will unbreak master | 07:35 |
| ondra | zyga ping | 07:46 |
| mvo | zyga: I have a theory about the snap-confine profile duplications, digging deeper right now | 07:46 |
| pedronis | mvo: zyga: either of you should do a pass over #7111 as well | 08:07 |
| ondra | zyga remember that update error we looked at, it seems to be persistent over reboots and pulling in PR #7248 did not change this | 08:07 |
| zyga | mvo: re, sorry, I had an interrupt at home | 08:10 |
| zyga | https://www.irccloud.com/pastebin/dU2IZcA2/ | 08:10 |
| zyga | pedronis: looking at 7111 now | 08:10 |
| zyga | ondra: which one? | 08:11 |
| mvo | zyga: thanks! I am testing a possible fix right now | 08:11 |
| mvo | pedronis: thanks, will look at this | 08:11 |
| zyga | pstolowski: huh, I just saw this failure in unit tests | 08:11 |
| zyga | https://www.irccloud.com/pastebin/4BaGpA43/ | 08:11 |
| pedronis | pstolowski: #7250 is probably something you can +1 quickly | 08:12 |
| pedronis | zyga: mvo has a PR for that | 08:12 |
| pstolowski | pedronis: looking | 08:13 |
| pedronis | mvo: I did a pass on most 2.41 things, quite a few of them now need work from the authors though | 08:21 |
| pedronis | couple are from me and need more reviews | 08:21 |
| mvo | zyga: 7251 should fix the snap-confine duplicated profiles error (it seems this one was real :( | 08:22 |
| mborzecki | GpioControlInterfaceSuite.TestSanitizeSlot unit test failing locally here, does that happen for anybody else too? | 08:28 |
| mvo | mborzecki: there is a PR to fix this | 08:28 |
| mvo | mborzecki: 7250 | 08:28 |
| mborzecki | mvo: thx | 08:28 |
| mvo | sry, too much got merged in a short time | 08:29 |
| ondra | zyga or is that wrong PR I used? | 08:30 |
| ondra | zyga was it #7205? | 08:30 |
| pedronis | mvo: 7251 is a bit :( | 08:33 |
| mvo | pedronis: yes, its pretty terrible | 08:34 |
| mvo | pedronis: this is a bug for ages :( | 08:34 |
| pedronis | looks like we fix this many times but never tested properly? | 08:35 |
| pedronis | or am I missing something | 08:35 |
| ondra | zyga sorry I tested with #7205 | 08:36 |
| mborzecki | duh, spread tests failed in 7250 :/ | 08:38 |
| mvo | pedronis: yes, it looks like this was lacking a proper test | 08:38 |
| mborzecki | and restarted now | 08:39 |
| ondra | zyga here is the error https://paste.ubuntu.com/p/ZMBh53Tqdp/ | 08:39 |
| ondra | zyga sorry I had to scramble snap names | 08:40 |
| jamesh | there's something to be said for having a bot perform the actual merges to master | 08:40 |
| jamesh | to avoid these race conditions | 08:40 |
| zyga | ondra: ah, I remember now, I'm debugging it already | 08:46 |
| zyga | ondra: it was re-reported yesterday in the public | 08:46 |
| ondra | zyga ah cool | 08:46 |
| ondra | zyga anything more I can provide? | 08:47 |
| zyga | ondra: track https://bugs.launchpad.net/snapd/+bug/1808821 for updates | 08:47 |
| pstolowski | mborzecki: what failed with 7250? | 08:48 |
| zyga | mvo: *nice* | 08:51 |
| zyga | mvo: so the maintainer script was always buggy?! | 08:51 |
| mborzecki | pstolowski: timeout accessing the store api | 08:54 |
| pstolowski | mborzecki: right.. | 08:54 |
| mvo | zyga: yes, it looks like it :( | 09:02 |
| zyga | mvo: amazing | 09:02 |
| zyga | thank you for finding it | 09:02 |
| mvo | zyga: thanks, I was a bit depressed when I discovered it | 09:03 |
| zyga | in other news, debian packaging is easy | 09:04 |
| mvo | haha | 09:04 |
| * zyga resumes system-usernames review | 09:04 | |
| pstolowski | zyga: lol | 09:10 |
| pstolowski | @debian packaging | 09:11 |
| mborzecki | Eighth_Doctor: updated the rhel8 PR | 09:11 |
| pstolowski | fingers crossed for 7250 | 09:11 |
| Eighth_Doctor | uhh, yeah, no, debian packaging sucks | 09:11 |
| Eighth_Doctor | the thing that makes it "easy" is that there's only a single distribution to worry about | 09:12 |
| Eighth_Doctor | but the actual packaging mechanism? holy crap, someone should burn it with fire | 09:12 |
| zyga | Eighth_Doctor: that's what I meant :D | 09:13 |
| zyga | Eighth_Doctor: it's not easy at all | 09:13 |
| mborzecki | Eighth_Doctor: slackware packaging is obviously superior :) | 09:13 |
| Eighth_Doctor | ... | 09:13 |
| zyga | I miss those days | 09:13 |
| zyga | when you had floppy disks | 09:13 |
| zyga | with nice graphical installers | 09:13 |
| Eighth_Doctor | I think we can all agree that scripts suck | 09:13 |
| zyga | that copied the three files in a few minutes | 09:13 |
| Eighth_Doctor | haha | 09:13 |
| zyga | or those floppies that still had dozen programs on them | 09:13 |
| zyga | but those days are gone | 09:14 |
| Eighth_Doctor | yep... Red Hat Linux days where you could find about 1/10 of the distro on a single floppy | 09:14 |
| Eighth_Doctor | that's pretty much gone :( | 09:14 |
| Eighth_Doctor | I haven't seen a package in a while that would fit on a floppy | 09:14 |
| zyga | Eighth_Doctor: but on the upside, 8bit/16bit programming is re-surging in its own niche | 09:15 |
| zyga | not just in artwork style but in actual 64K programs | 09:15 |
| Eighth_Doctor | well, I had fun doing stuff like that when I was part of the Sonic scene | 09:15 |
| mborzecki | Eighth_Doctor: 3.5'' floppies could fit a bit, 5.25 were more fun | 09:15 |
| zyga | as things one can do in limited environment are on equal footing with everyone else | 09:15 |
| zyga | Eighth_Doctor: I have a *box* of unopened floppies on a shelf here | 09:16 |
| zyga | I had a USB 3.5 floppy drive but I think it was tossed a few years back | 09:16 |
| zyga | it did work though :) | 09:17 |
| Eighth_Doctor | I still have the USB floppy drive | 09:17 |
| zyga | I would love to find it | 09:17 |
| zyga | go with my 15"MBP to a cafeteria | 09:17 |
| zyga | and use floppy disks, while looking after my beard ;D | 09:17 |
| zyga | ok, back to reviews | 09:17 |
| Eighth_Doctor | and I had to open the box of floppies I had for a thing... https://twitter.com/austinmcchord/status/646113834198003712 | 09:20 |
| Eighth_Doctor | hooking up that old 386 laptop to the internet was an... interesting experience | 09:21 |
| === pedronis_ is now known as pedronis | ||
| pedronis | pstolowski: does the new suggestion in #7209 make sense? | 09:31 |
| Chipaca | is master broken right now? I'm getting a unit test failure in master: FAIL: gpio_control_test.go:67: GpioControlInterfaceSuite.TestSanitizeSlot | 09:35 |
| pstolowski | pedronis: yes, i like that (not that i didn't like the first suggestion) | 09:35 |
| Chipaca | or is it a govendor thing | 09:35 |
| pstolowski | Chipaca: yes, 7250 fixes it | 09:35 |
| Chipaca | ah | 09:35 |
| mborzecki | pstolowski: left some comments under https://github.com/snapcore/snapd/pull/7005 | 09:46 |
| pstolowski | mborzecki: yep just looking, thanks | 09:46 |
| mborzecki | pstolowski: unit tests in that PR are failing on travis | 09:46 |
| mborzecki | pstolowski: ah, because of the gpio unit test, ok, that's fine then | 09:46 |
| zyga | https://github.com/snapcore/snapd/pull/7250 is yellow | 10:10 |
| zyga | pedronis: I reviewed jamie's branch, resuming work on bugfixes from yesterday | 10:10 |
| pedronis | zyga: thank you | 10:11 |
| Chipaca | hmm, 7250 at 45' already | 10:22 |
| Chipaca | t'internets are extra slow? | 10:22 |
| zyga | hmmmm | 10:26 |
| * zyga debugged and needs to think about how to solve it | 10:26 | |
| zyga | I think it's time for coffee to think | 10:26 |
| zyga | brb | 10:26 |
| zyga | if this was an office I'd offer you some | 10:26 |
| zyga | you can always come and visit tho :) | 10:26 |
| pstolowski | ..aaaand 7250 failed | 10:29 |
| zyga | mvo: can you use your superpowers | 10:29 |
| zyga | and merge it? | 10:29 |
| zyga | I think we're just wasting time now | 10:30 |
| pstolowski | +1 | 10:30 |
| mborzecki | heh, so i'm looking at the log | 10:30 |
| mborzecki | it failed early, preparing ubuntu-16.04-32 host, but it ran the other tests anyway | 10:31 |
| zyga | why did xenial 32bit fail? | 10:31 |
| mborzecki | zyga: kill timeout, last log was +gdebi --quiet --apt-line ./debian/control | 10:32 |
| pstolowski | we should really make spread fail asap | 10:34 |
| mborzecki | pstolowski: i guess it depends on the phase, eg. failing early in project prepare sounds ok, but aborting the whole run when a task prepare fails is not useful | 10:35 |
| zyga | mborzecki: I think it is | 10:35 |
| zyga | it's not useful anyway | 10:35 |
| zyga | you can run spread all you like locally | 10:35 |
| zyga | but in travis, it's just wasting the time shared across the team | 10:35 |
| mvo | zyga: sure, will do | 10:36 |
| mvo | merged | 10:36 |
| zyga | thanks! | 10:36 |
| pedronis | pstolowski: mvo: I mentioned in https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769/3 that it has landed for 2.41 , it should probably be linked from the roadmap | 10:46 |
| pstolowski | pedronis: ah, i need to prepare a followup for snap info to report latest/.., it needs to land too | 10:48 |
| cachio | mvo, hey | 10:55 |
| * pstolowski lunch | 11:01 | |
| zyga | mborzecki: what was that magic randomness thing you used in the past? | 11:05 |
| zyga | that package to get | 11:05 |
| mborzecki | zyga: haveged? | 11:05 |
| zyga | yep, thanks | 11:05 |
| zyga | yesss | 11:39 |
| zyga | two layout bugs fixed | 11:46 |
| zyga | that's neat :) | 11:46 |
| * zyga is happy today | 11:46 | |
| zyga | ondra: I think this includes a bug you reported now | 11:47 |
| zyga | fired spread, writing proper docs and more unit tests | 11:59 |
| zyga | brb | 12:03 |
| === ricab is now known as ricab|lunch | ||
| Chipaca | zyga: is that two layout bugs that diddledan caused? | 12:14 |
| diddledan | hello :-) | 12:15 |
| diddledan | I should stop breaking things :-p | 12:15 |
| zyga | Chipaca: yeah, those :) | 12:15 |
| zyga | diddledan: the snap you reported, two bugs working in tandem :) | 12:16 |
| diddledan | nice | 12:16 |
| zyga | though either one is crippling | 12:16 |
| diddledan | obscure, but nice | 12:16 |
| diddledan | well done for getting them fixed :-) | 12:17 |
| diddledan | I presume the fixed code will land in 2.41 | 12:18 |
| Chipaca | diddledan: hahahaha! landing. Ha. | 12:21 |
| diddledan | I want 2.41 already for other reasons, too :-) (makemkv should finally be able to be strictly confined in 2.41) | 12:29 |
| pedronis | #7130 needs a 2nd review, #7131 should also be reviewable now | 12:47 |
| cmatsuoka | ondra: do you know if one can chainboot grub from littlekernel? | 12:49 |
| ondra | cmatsuoka yes and no, in theory you can chain load grub from lk, but that would assume there is grub supported on that hw, and if that would be the case, one would use grub instead | 12:53 |
| ondra | zyga good times! if you give me PRs I can test this right aways, as we are still using custom snapd anyway | 12:54 |
| zyga | ondra: in 5 minutes, adding last unit test | 12:54 |
| ondra | zyga sure thing :) | 12:54 |
| Chipaca | pedronis: does we never have a model on classic? | 12:54 |
| pedronis | Chipaca: we do | 12:55 |
| Chipaca | hmm | 12:56 |
| pedronis | always actually these days | 12:56 |
| ijohnson | morning folks | 12:56 |
| pedronis | because we carry a fallback | 12:56 |
| pedronis | Chipaca: is that about your work? or one of my PRs? | 12:57 |
| Chipaca | pedronis: 7130 | 12:57 |
| pedronis | we do have models on classic if we first boot at all | 12:58 |
| pedronis | yes | 12:58 |
| zyga | ondra: opening now | 12:59 |
| Chipaca | pedronis: commented there | 12:59 |
| pedronis | Chipaca: classic: true and base != "" is prohibitied | 13:00 |
| Chipaca | ahhhhh | 13:00 |
| pedronis | that at the level of assertions | 13:00 |
| ondra | zyga nice! | 13:00 |
| Chipaca | pedronis: how likely is that to change? | 13:00 |
| pedronis | very unlikely if it's up to me | 13:00 |
| pedronis | base: means a root fs base | 13:01 |
| pedronis | there is no such thing on classic | 13:01 |
| pedronis | the root fs comes from the host | 13:01 |
| Chipaca | right | 13:01 |
| zyga | ondra: https://github.com/snapcore/snapd/pull/7254 | 13:08 |
| zyga | diddledan: ^ | 13:08 |
| zyga | ondra: I'd love to know if this really does help you out | 13:09 |
| zyga | ondra: so if you test this against your systems please let me know (either way) | 13:10 |
| ondra | zyga yeah I will do it right now and let you know | 13:12 |
| cmatsuoka | ondra: so to run core20 on e.g. the speaker all the dual-bootloader strategy would have to be bypassed and run LK instead, is that correct? | 13:13 |
| === ricab|lunch is now known as ricab | ||
| ondra | cmatsuoka yep, with lk we can only use bootloader->kernel path | 13:32 |
| ondra | cmatsuoka I know u-boot can chain boot, but I have not done it before | 13:33 |
| ondra | cmatsuoka also be aware of some systems like Pi3, where pre u-boot bootloader constructs dtb, which does limit what you can do within u-boot | 13:34 |
| ondra | cmatsuoka you are essentially committing to kernel version before u-boot is even loaded | 13:34 |
| ogra | chainloading uboot from uboot is gambling .... it only works if both binaries come from identical source etc | 13:35 |
| ondra | cmatsuoka example, you current kernel version is 4.15, chain loading into recovery system with 4.4 kernel will not boot, as early stage broadcom bootloader already constructed DTB for 4.15 kernel | 13:36 |
| ondra | ondra and on Pi3, pre u-boot constructed DTB adds additional complication | 13:36 |
| ondra | ogra hope you still have highlight on ondra, to make communication easier :P | 13:37 |
| ogra | note that you *can* actually just load a different dtb from u-boot even on the Pi ... but you lose some bits that might be important for users (like the serial number that is used for paid mp2 codecs on that HW) | 13:37 |
| ogra | ondra, ping :P | 13:38 |
| ogra | yeah, still works :P | 13:38 |
| ondra | ogra lol | 13:38 |
| zyga | ondra: tell me if it works please, I'm hyped to know | 13:38 |
| ondra | ogra yeah you can overide it of course | 13:38 |
| ondra | zyga building :) | 13:39 |
| ogra | right ... but the proprietary BL seeds some bits artificially into the devicetree in ram ... you can even read them out and then re-inject them into the new loaded dtb | 13:39 |
| ogra | but thats a hell lot of scriptery | 13:39 |
| ogra | and likely very error prone in the end | 13:39 |
| joeubuntu | This week jdstrand is on the Ubuntu Security Podcast talking about snap security if you want to give it a listen: https://ubuntusecuritypodcast.org/episode-42/ | 13:42 |
| jdstrand | hope it's good! | 13:43 |
| ondra | ogra remember I do have solution for this as well :) | 13:43 |
| ogra | hacks hacks hacks :) | 13:43 |
| ondra | ogra but you know how that story ended :P | 13:43 |
| ogra | yeah | 13:43 |
| ondra | ogra you call me hacker??????? Careful :P | 13:43 |
| ogra | lol | 13:43 |
| jdstrand | mvo: fyi, seeing that the snapd-master snap is failing review due to external symlink | 13:44 |
| ondra | zyga still 20mins to build :( | 13:44 |
| jdstrand | mvo: hi btw :) | 13:44 |
| zyga | ondra: 20 minutes? ok | 13:44 |
| roadmr | you hax0r you | 13:44 |
| ondra | but will test as soon as built | 13:44 |
| zyga | jdstrand: external symlink? | 13:44 |
| ondra | zyga yeah building in lp | 13:44 |
| ogra | jdstrand, btw, did you see abeato's comment wrt screen/tmux yesterday ... seems he actually has a pressing use-case for picking screen (bluetooth initialization and debugging as well as GSM modems) | 13:45 |
| jdstrand | ogra: I did. thought bluetooth initialization suggests a snap trying to use it. maybe that would be in the gadget... another reason to have it in core | 13:47 |
| jdstrand | s/thought/though/ | 13:47 |
| ondra | zyga trying local build on my arm now as well, but not sure if it will build as I have snapcraft from snap | 13:48 |
| popey_ | joeubuntu: ooh! I'll share it on our social channels | 13:49 |
| joeubuntu | Thanks popey_ ! | 13:51 |
| ogra | jdstrand, yeah, i think it was more about debugging BT stuff via AT commands (which you need to do via "virtual" serial device) | 13:52 |
| ogra | i guess alfonso can explain it better ... | 13:53 |
| jdstrand | popey_: perhaps listen to it first? ;) | 13:54 |
| popey_ | lets say i did | 13:54 |
| roadmr | AT commands!!!! | 13:54 |
| ogra | the predecessor of everything internet ! | 13:55 |
| mvo | jdstrand: hi! oh? I need to check that | 13:56 |
| mvo | jdstrand: thanks for letting me know | 13:56 |
| jdstrand | np | 13:56 |
| abeato | jdstrand, ogra well, I was just pointing out that I do use screen for that sort of stuff quite often. If I had to choose between tmux and screen I would prefer the former because of that additional funcionality | 13:56 |
| abeato | but I also understand is not such a usual use case :) | 13:56 |
| ogra | like mine ... (talking to addon boards via serial during development/debugging ... yet i think it is a usual use-case for embedded stuff) | 13:57 |
| ogra | oh ah uh ! | 13:58 |
| ogra | there is a tool from the rpi foundation that loows loading overlays from userspace now !! | 13:58 |
| ogra | https://github.com/raspberrypi/userland/tree/master/host_applications/linux/apps/dtoverlay | 13:58 |
| ogra | *allows | 13:58 |
| ondra | zyga yep with snap from snapcraft it fails with missing '/etc/apt/trusted.gpg' | 13:59 |
| ondra | zyga so 10 minutes to go in lp | 13:59 |
| jdstrand | zyga: yes, snap squashfs aren't allowed to have dangling symlinks pointing outside of the snap areas | 13:59 |
| zyga | jdstrand: ahh | 14:07 |
| abeato | s/former/later/ | 14:09 |
| * zyga broke for quick lunch | 14:10 | |
| Saviq | zyga: hey, when back, is it now safe to go core16 → core18 in a snap? | 14:21 |
| diddledan | it wasn't before? | 14:23 |
| zyga | Saviq: in 2.40, yes | 14:29 |
| zyga | Saviq: some small issues remain but nothing major | 14:29 |
| Saviq | w00t | 14:30 |
| pstolowski | mborzecki, zyga: since you commented on #7081 some time ago, can you take another look at it? | 14:30 |
| zyga | pstolowski: sure | 14:30 |
| mborzecki | pstolowski: at, the MarkEdge bit | 14:36 |
| pstolowski | mborzecki: what about it? | 14:37 |
| mborzecki | pstolowski: 7081 | 14:37 |
| ondra | zyga hmmmm | 14:38 |
| ondra | zyga did not fix it | 14:38 |
| ondra | zyga rebooting to double check | 14:39 |
| pstolowski | mborzecki: ? any problem there? | 14:40 |
| ondra | zyga ha, after reboot it worked | 14:40 |
| cachio | mvo, hey | 14:41 |
| cachio | I see this error -> iptables: match "tcp" has version "libxtables.so.11", but "libxtables.so.12" is required | 14:42 |
| cachio | I have libxtables.so.12 in the snap lib | 14:42 |
| cachio | but it iptables snap is using the lib from the core snap | 14:42 |
| cachio | I suppose that a dependency in the core is using this lib | 14:42 |
| mvo | cachio: that is core or core18? | 14:43 |
| cachio | mvo, core | 14:43 |
| cachio | not tested on core18 yet | 14:43 |
| cachio | mvo, should I? | 14:43 |
| mvo | cachio: ok - does fiddling with LD_LIBRARY_PATH help? | 14:43 |
| mvo | cachio: i.e. making sure that the snap path is before the system lib path? | 14:43 |
| cachio | mvo, is not by default? | 14:44 |
| cachio | ok | 14:44 |
| cachio | I'll try tht | 14:44 |
| cachio | :) | 14:44 |
| diddledan | snapd doesn't set LD_LIBRARY_PATH by default | 14:44 |
| diddledan | IIRC | 14:44 |
| diddledan | if you have libraries you need to set them :-) | 14:45 |
| diddledan | it might actually to $SNAP/usr/lib thinking about it but subfolders need to be added manually | 14:45 |
| cachio | diddledan, ok, yes the rest of the libs are being used from the snap | 14:45 |
| diddledan | do* | 14:46 |
| cachio | but I think in this case it is getting the core ones because the caller is the core | 14:46 |
| pedronis | jdstrand: I did a pass on the snap_daemon first couple of PRs (cc mvo) | 14:46 |
| mborzecki | pstolowski: btw. i'm thinking, the edge markings can be done always, can't they? | 14:47 |
| cachio | diddledan, I see the wrapper with export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu" | 14:48 |
| cachio | I think the problem with this lib is that is also included in the core snap | 14:48 |
| diddledan | that should cover it then | 14:48 |
| cachio | the others dont | 14:48 |
| pstolowski | mborzecki: yeah.. but what do you mean? | 14:49 |
| cachio | mvo, diddledan thanks for your replies | 14:49 |
| cachio | it should be easy to fix | 14:49 |
| abeato | zyga, hey, could you retrigger the tests for https://github.com/snapcore/snapd/pull/7173 ? - that one should be ready for merging once they pass :) | 14:50 |
| zyga | sure | 15:05 |
| * cachio lunch | 15:13 | |
| pstolowski | Chipaca: wrt to what i brought up in the standup, it seems to be this is the only change needed: https://paste.ubuntu.com/p/63DP8hmsSM/ , then http://localhost/v2/find?name=lxd gives channels such as https://paste.ubuntu.com/p/SVBdrKw9p3/ | 15:23 |
| pstolowski | Chipaca: and here is what store gives us, for reference https://paste.ubuntu.com/p/rNSvgcw8pN/ | 15:23 |
| pstolowski | Chipaca: so it's the store giving short channel name if track is "latest" | 15:23 |
| pstolowski | Chipaca: i see no explicit chopping on our side - except for our client side in cmd_info which special-cases "latest" | 15:24 |
| pstolowski | Chipaca: makes sense? | 15:25 |
| Chipaca | pstolowski: it does, I'd go hunting for something with branches to see how that is shown if at all | 15:25 |
| Chipaca | pstolowski: (after the standup i took a quick look and agree with your findings) | 15:26 |
| Chipaca | pstolowski: actually, nm about branches | 15:27 |
| Chipaca | pstolowski: it's already the key of the map | 15:27 |
| Chipaca | pstolowski: so just build it the once, and use it for both things :) | 15:27 |
| Chipaca | pstolowski: ie chName := ch.Track+"/"+ch.Risk, then info.Channels[chName] = &snap.ChannelSnapInfo{ …, Channel: chName, … } | 15:28 |
| Chipaca | pstolowski: makes sense? | 15:29 |
| pedronis | Chipaca: seems you didn't address this comment https://github.com/snapcore/snapd/pull/7185/files#r310180105 | 15:31 |
| Chipaca | ah | 15:32 |
| Chipaca | pedronis: missed it wrt the embedding | 15:32 |
| pstolowski | Chipaca: yep. thanks for checking | 15:32 |
| pedronis | Chipaca: left a couple nitpicks more | 15:34 |
| Chipaca | pedronis: got it, thanks | 15:35 |
| === pstolowski is now known as pstolowski|afk | ||
| jdstrand | pedronis: ack, thanks | 17:20 |
| pedronis | jdstrand: we are trying to cut 2.41 this week (cc mvo) | 17:31 |
| jdstrand | roadmr: fyi, store still giving 504 | 17:52 |
| jdstrand | pedronis: ok, I had the bigger PR 6258 (dbus activation) and cgroupv2 PR I was going to do today, but I'll respond to the feedback in my PRs I got today/yesterday first | 17:54 |
| jdstrand | pedronis: those two aren't 2.41 milestoned, so that should be ok | 17:54 |
| jdstrand | pedronis: I did the other 2.41 milestoned reviews and quite a few others yesterday. I *think* it is just those two that are on outstanding for me to review | 17:54 |
| cachio | pedronis, hey, google:ubuntu-14.04-64:tests/main/auto-refresh-private failed after "support seeding a classic system with ..." was merged | 18:00 |
| cachio | pedronis, did it fail the test before? | 18:01 |
| pedronis | cachio: no | 18:01 |
| cachio | ok, I'll take a look in that case | 18:02 |
| cachio | tx | 18:02 |
| sergiusens | Hi there, question, is this error `- Download snap "u1test-snap-with-tracks" (5) from channel "test-track-1/beta" (stream error: stream ID 1; PROTOCOL_ERROR)` something you see often? | 18:04 |
| cachio | sergiusens, there is a fix for this already merged on master | 18:05 |
| cmatsuoka | sergiusens: I see it in tests | 18:06 |
| sergiusens | great, that is where I am seeing it too | 18:06 |
| cachio | cmatsuoka, mvo made a fix for that | 18:06 |
| cachio | sergiusens, ~ | 18:06 |
| sergiusens | thanks for the quick response :-) | 18:06 |
| jdstrand | pedronis: I responded to your comments in PR #7111 | 18:19 |
| jdstrand | pedronis: I need some clarification (https://github.com/snapcore/snapd/pull/7111) | 18:19 |
| jdstrand | is the bot not around? I don't seem to be able to get it to spit out urls lately... | 18:20 |
| mvo | jdstrand: thank you for prioritzing 2.41 - let us know if we can help, we could do trivial changes for you in our mornings if you are ok with that | 18:25 |
| mvo | jdstrand: mup is quiet for some time | 18:25 |
| mvo | jdstrand: I talked to gustavo he wants to tweak some code first iirc, its related to the spam attacks that happend on freenode a while ago and now unregistered users are muted by default and (iirc) that code needs tweaks | 18:26 |
| jdstrand | mvo: ok, cool. I thought maybe I forgot the handshake | 18:26 |
| mvo | jdstrand: hhaha | 18:26 |
| niemeyer | Yeah, sorry about that | 18:27 |
| niemeyer | The issue is mup doesn't have code to self-identify to nickserv | 18:27 |
| niemeyer | If I do that manually it works | 18:28 |
| niemeyer | But I need to automate it so it happens on reconnection | 18:28 |
| niemeyer | mup: Right? | 18:28 |
| mup | niemeyer: I apologize, but I'm pretty strict about only responding to known commands. | 18:28 |
| mvo | niemeyer: thanks! no worries, a clear case of soo-much-to-do-so-little-time :/ | 18:29 |
| niemeyer | Yeah, it just sucks that it's taking that long to get to it | 18:29 |
| * mvo hugs niemeyer | 18:30 | |
| * mvo noticed there weren't many hugs since dholbach stopped joining this channel, a shame! | 18:31 | |
| mvo | btw tests are a bit on the red side still, any particular culprits? if not I will investigate in my morning | 18:31 |
| jdstrand | niemeyer: hello :) | 18:31 |
| niemeyer | jdstrand: o/ | 18:32 |
| pedronis | jdstrand: I tried to answer, but likely one of us is confused | 18:44 |
| pedronis | jdstrand: it seems you have the order of things happening in snapstate vs snap/info.go wrong | 18:45 |
| pedronis | snap/info.go stuff happens first | 18:46 |
| pedronis | or I'm misreading you | 18:46 |
| jdstrand | pedronis: for the first comment about key, I understand your point and will fix. for the other, yes, I understood the order to be the other way. I can adjust and move it | 18:51 |
| pedronis | jdstrand: there you have a bit of a choice whether to do it always, or do it under Validate | 18:52 |
| pedronis | it seems we tend to do that kind of checks in Validate | 18:53 |
| pedronis | like for slot/plug names etc | 18:53 |
| pedronis | but not so late as in check_snap.go | 18:53 |
| jdstrand | I would lean towards that I think too | 18:53 |
| jdstrand | thanks | 18:53 |
| jdstrand | I think the comment somewhere made me think check_snap.go was sooner than later, but not a problem | 18:54 |
| jdstrand | s/the comment/a comment/ | 18:54 |
| pedronis | we need to parse the yaml before acting on it | 18:55 |
| pedronis | so one of the Read is always in the path | 18:55 |
| jdstrand | sure. the parse check I thought was different from a value check, but again, not a problem to move | 18:56 |
| * cachio afk | 18:59 | |
| pedronis | jdstrand: I clarified my comments in 7112, two things are probably follow up material, need more thinking to decide what to do, but one point still is relevant | 19:26 |
| mup | PR snapcraft#2661 closed: deltas: code cleanup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2661> | 19:28 |
| zyga | degville: https://twitter.com/zygoon/status/1161720375962681344 | 19:32 |
| jdstrand | pedronis: ok, with PR 7111, I moved only IsValidUsername() to info_snap_yaml.go: https://github.com/snapcore/snapd/pull/7111/commits/0cc9ac7c514a48ac409a04d5b27393a96cec456e | 19:35 |
| mup | PR #7111: many: support system-usernames for 'snap_daemon' user <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7111> | 19:36 |
| jdstrand | pedronis: which is what you said in the PR and that is all fine. when discussing here, I thought you meant all of the supportedSystemUsernames checks, but you didn't mean that, correct? Ie, I think I'd like to keep the supportedSystemUsernames in overlord since eventually we'll get the map from the store, not hardcoded in snapd, so hardcoding it for now in where it is feels better than in | 19:38 |
| jdstrand | info_snap_yaml.go | 19:38 |
| jdstrand | pedronis: beyond that, I think I addressed all comments for 7111 | 19:39 |
| jdstrand | erf... unit tests failing with "Could not obtain seccomp compiler information: fork/exec /tmp/check-3892727285590088690/593/usr/lib/snapd/snap-seccomp: no such file or directory" | 20:41 |
| mup | PR snapcraft#2663 opened: elf: handle invalid elf files <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2663> | 21:13 |
| cmatsuoka | cachio: are you experiencing repeated fedora-30-64 test failures? | 22:10 |
| cachio | cmatsuoka, mmm | 22:18 |
| cachio | which errors? | 22:18 |
| cmatsuoka | cachio: mostly in preparation, I just restarted my tests because they seemed random but if they happen again I'll get the full log | 22:19 |
| cachio | cmatsuoka, do you have a log? | 22:19 |
| cachio | I just finished a fix for interfaces-contacts-service | 22:19 |
| cmatsuoka | cachio: I'll get it in the next run | 22:19 |
| cachio | cmatsuoka, nice, thanks} | 22:20 |
| jdstrand | oh, I found the issue I saw in the testsuite (my fault) | 22:26 |
| cachio | cmatsuoka, I am leaving now, please, leave here the link, I'll take a look when I am back | 22:28 |
| mup | PR snapd#7256 opened: tests: adding retry command and use it to delete $XDG directory <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256> | 22:29 |
| cmatsuoka | cachio: the ubuntu tests failed too, but the cause seems to be pretty random as well: Cannot allocate google:ubuntu-18.10-64: cannot allocate new Google server for ubuntu-18.10-64: the resource 'projects/ubuntu-os-cloud/global/images/family/ubuntu-1810' was not found | 22:40 |
| cmatsuoka | I'll repeat it to see if it's deterministic | 22:41 |
| cmatsuoka | cachio: ok, now the fedora systems are provisioned, but they're failing when looking for vendored dependencies during rpm package build | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!