rbasak | sergiusens: around? I'm having trouble with the python plugin, setting requirements.txt. Documentation says it's a string, but the code says it's a list. I can't seem to give it a list. | 02:09 |
---|---|---|
rbasak | I tried using override-pull to dynamically create a requirements.txt concatenating my own list, but snapcraft seems to fail to read a generated requirements.txt _before_ override-pull runs, even though it complains after (based on what strace says). | 02:10 |
rbasak | The underlying problem I'm trying to solve is: https://pastebin.ubuntu.com/p/7yknPXQG7G/ | 02:11 |
rbasak | Upstream aren't sure that it's correct to include an == for setuptools in requirements.txt. | 02:12 |
rbasak | But it might work for me here. Except I can't figure out how to get snapcraft to let me interfere with the requirements.txt before it uses it. | 02:12 |
mup | PR snapd#6316 opened: tests: skip snapd snap on reser for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6316> | 02:15 |
mborzecki | morning | 07:03 |
zyga | Hello | 07:35 |
zyga | I will be in the office shortly, just need to take the dog out | 07:36 |
mborzecki | zyga: hey | 07:37 |
zyga | re :) | 07:47 |
zyga | hey hey | 07:47 |
zyga | I feel *much* better than yesterday | 07:47 |
zyga | mborzecki: was the sky overcast last night around your place? | 07:48 |
mborzecki | zyga: idk, didn't pay much attention, probably yes | 07:49 |
zyga | I want to take a chance to see the comet | 07:49 |
zyga | but lights and clouds make it hard to do so :/ | 07:49 |
mborzecki | zyga: hah, the worst time of year if you ask me | 07:49 |
zyga | right? | 07:49 |
zyga | mid summer would be awesome | 07:49 |
mborzecki | zyga: or super cold weather | 07:53 |
zyga | mborzecki: any highlights from yesterday? | 07:58 |
mborzecki | the test suite is givig headaches | 07:58 |
mborzecki | zyga: couldn't even get https://github.com/snapcore/snapd/pull/6314 to land | 07:58 |
mup | PR #6314: cmd/snap-discard-ns: fix umount(2) typo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6314> | 07:58 |
zyga | yeah, I'm looking at taht now | 07:59 |
zyga | but that's hardly new problem :/ | 07:59 |
mborzecki | and it's a damn typo | 07:59 |
zyga | + test-snapd-udev-input-subsystem.slot | 07:59 |
zyga | cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_tdsBnR//dev: No such file or directory | 07:59 |
=== pstolowski|afk is now known as pstolowski | ||
pstolowski | heyas | 07:59 |
zyga | this means that core snap is empty | 07:59 |
zyga | which probably signifies another bug in test restore somewhere | 08:00 |
zyga | eh | 08:00 |
zyga | pstolowski: hey | 08:00 |
zyga | pstolowski: did you see the comet? | 08:00 |
mborzecki | zyga: on a side not, pulled in the latest updates today, linux-firmware got updated to 20181216 version and my vega stopped working :/ | 08:00 |
zyga | uh? | 08:00 |
zyga | :| | 08:00 |
zyga | new vega firmware? | 08:00 |
pstolowski | zyga: oh, no; did you? | 08:00 |
zyga | maybe it requires new kernel too | 08:00 |
zyga | pstolowski: no, sky is totally covered with clouds | 08:01 |
zyga | pstolowski: but I want to | 08:01 |
mborzecki | zyga: i'm at 4.19.9 | 08:01 |
zyga | pstolowski: I learned a thing yesterday | 08:01 |
mborzecki | zyga: tought the kernel update was botched, but reverting firmware was enough to make it work again | 08:01 |
zyga | pstolowski: downloaded mojave installer app, rebooted (required somehow), created a new vm with fusion and the mojave installer, clicked through everything, rebooted, held command+r to enter recovery, disabled system integrity protection (root is real root now), rebooted back to the system, now I can dtrace system binaries or use dtruss to see the system calls; I wanted to understand what fuels readdir on macos, and I found out | 08:02 |
zyga | :) | 08:02 |
zyga | (and it is not getdents) | 08:03 |
pstolowski | zyga: :D | 08:03 |
mborzecki | zyga: can you upload the source tarballs to github releases page? | 08:08 |
zyga | mborzecki: yeah, I'm looking into that now | 08:08 |
mborzecki | zyga: thanks! | 08:08 |
zyga | mborzecki: btw, some good stuff over weekend | 08:09 |
zyga | I, by accident, got the attention of the suse golang stack maintainer | 08:09 |
zyga | and they will remove the global environment variables | 08:09 |
zyga | which means we will not only get fixed go in suse | 08:09 |
zyga | but have a simple way out of the current problem | 08:09 |
zyga | (just unset the damn GO* mess) | 08:09 |
zyga | mborzecki: tweeting with a rant actually solved a problem :) | 08:11 |
mborzecki | zyga: nice | 08:16 |
zyga | FK | 08:24 |
zyga | firefox ate my release page | 08:25 |
zyga | f***** | 08:25 |
zyga | went "back" | 08:25 |
zyga | moronic feature | 08:25 |
mborzecki | nom nom nom | 08:25 |
zyga | mborzecki: release page updated | 08:31 |
zyga | I'll do opensuse next | 08:32 |
zyga | then look at bugfixes for layout bug | 08:32 |
zyga | I would love if we did 0 features and made the test suite stable | 08:32 |
zyga | any ideas apply | 08:32 |
mborzecki | zyga: thanks | 08:32 |
mborzecki | i'm seeing this on arch: gru 18 09:29:09 galeon snapd[24323]: link.go:75: cannot update fontconfig cache: cannot get fc-cache-v6 from core: open /var/lib/snapd/snap/core/current/bin/fc-cache-v6: no such file or directory | 08:33 |
mborzecki | uhh | 08:33 |
zyga | dunno | 08:34 |
mborzecki | zyga: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/backend/link.go#L62..L94 i think this is wrong | 08:35 |
zyga | I low how we ship TODO/XXX but discuss ad infinitum about variable names | 08:35 |
zyga | mborzecki: can you walk me through your thought process | 08:36 |
mborzecki | zyga: it's using CommandFromCore, which does mountDir+core/current, but the symlink is updated only at the end | 08:36 |
mborzecki | zyga: so it's trying to call fc-cache-v6 from the old 'current' of the core snap | 08:36 |
zyga | indeed! | 08:37 |
zyga | uh | 08:37 |
zyga | please file a bug | 08:37 |
mborzecki | zyga: only visible when switching between !edge & edge | 08:37 |
pedronis | zyga: I don't know of anything that isn't tiny that doesn't ship with TODOs | 08:38 |
mborzecki | zyga: better yet, i'll open a PR :P | 08:38 |
zyga | pedronis: that was not my point :) | 08:46 |
zyga | pstolowski: is this expected? 2.36.3 https://www.irccloud.com/pastebin/Yxx3gjEC/ | 09:00 |
mup | PR snapd#6314 closed: cmd/snap-discard-ns: fix umount(2) typo <Simple 😃> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6314> | 09:00 |
mup | PR snapd#6316 closed: tests: skip snapd snap on reset for core systems <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6316> | 09:00 |
mborzecki | zyga: just on .3? | 09:01 |
zyga | yep | 09:01 |
zyga | mborzecki: happens each time | 09:02 |
mborzecki | zyga: hm don't see this here | 09:03 |
zyga | "osc build" | 09:03 |
pstolowski | zyga: no, failures are not expected ;). i don't know, looks like mvo touched this test a few days ago. do you see it consistently? | 09:03 |
zyga | yes | 09:03 |
zyga | each time | 09:03 |
pstolowski | interesting | 09:03 |
pstolowski | zyga: let me look | 09:03 |
zyga | mborzecki: I sent this to obs | 09:04 |
zyga | it will fail there | 09:04 |
mborzecki | zyga: go version? | 09:04 |
zyga | https://build.opensuse.org/package/show/system:snappy/snapd | 09:04 |
zyga | 1.11.2 | 09:04 |
zyga | mborzecki: note, it happens in osc build | 09:05 |
zyga | I don't see this in "go test ./..." | 09:05 |
mborzecki | zyga: wasn't there something with network being disabled in obs builds and that causing some werid issues? | 09:06 |
zyga | I don't know | 09:06 |
zyga | presumably maybe so | 09:06 |
mborzecki | zyga: i recall something like this when you were updating snapd with that other opensuse community guy | 09:06 |
zyga | hmmmm | 09:07 |
zyga | http://nonexistingserver909123.com/ | 09:08 |
pstolowski | zyga: i'm looking at this test right now. running in httputil/ tests in a loop, so far no failure, so perhaps flaky? | 09:08 |
zyga | pstolowski: no | 09:09 |
zyga | perhaps flaky assumption | 09:09 |
zyga | it fails each time in obs build | 09:09 |
zyga | https://build.opensuse.org/package/show/system:snappy/snapd | 09:09 |
zyga | we are assuming a specific answer for a domain name | 09:10 |
zyga | the problem is that the test can run in arbitrary environment, including one with proxies | 09:10 |
zyga | not a unit test | 09:10 |
zyga | we test the system | 09:10 |
pstolowski | zyga: i see. also looking at comments in e3db0504f5b28029e4a253614782244150ebeb50, go versions introduce variances here... | 09:14 |
zyga | pstolowski: https://build.opensuse.org/package/show/system:snappy/snapd failed across all suse versions | 09:14 |
pstolowski | uhm | 09:16 |
pstolowski | zyga: i think we should c.Skip this test then for the time being, and try come up with a better one | 09:19 |
zyga | pstolowski: agreed | 09:19 |
zyga | pstolowski: perhaps we should spawn our own server and return the expected error code | 09:20 |
zyga | otherwise we can really see anything the system crafts | 09:20 |
pstolowski | +1 | 09:20 |
pstolowski | zyga: shall i prep quick PR against 2.36? | 09:20 |
zyga | pstolowski: I can cherry pick as well, thank you for looking | 09:21 |
zyga | if you can, please try to improve the test | 09:21 |
pstolowski | zyga: ok | 09:21 |
zyga | sorry, that came out confusing and ambiguous | 09:21 |
pstolowski | zyga: ok, for master then | 09:21 |
zyga | I mean I will do the skip | 09:21 |
pstolowski | ah ok | 09:21 |
zyga | and you can look at changing the test properly for master | 09:21 |
zyga | I will carry a distro patch | 09:21 |
pstolowski | zyga: perhaps c.Skip conditional on suse? | 09:22 |
zyga | pstolowski: no, I mean I will just skip this unconditionally in distro packaging | 09:22 |
zyga | we should not special case any distribution here | 09:22 |
pedronis | pstolowski: zyga: we already have a test like that somewhere else | 09:37 |
pedronis | we don't skip generically | 09:37 |
pedronis | pstolowski: see TestDoRequestSerialErrorsOnNoHost in devicestate_test.go | 09:39 |
pedronis | zyga: ^ | 09:40 |
zyga | looking | 09:40 |
pstolowski | ah! | 09:40 |
pstolowski | pedronis: nice | 09:40 |
zyga | yep | 09:40 |
zyga | +1 | 09:40 |
zyga | though I would really argue those are not unit tests | 09:41 |
zyga | but camouflaged integration tests | 09:41 |
pedronis | zyga: we have some _test.go files with integration tests (of various kind), yes | 09:45 |
zyga | uh, heads up: I need to go and do paperwork (today and tomorrow) for the car that has finally arrived | 09:46 |
zyga | perhaps I can skip today | 09:46 |
zyga | I'll learn more soon | 09:46 |
pedronis | zyga: heh, two full days of papework? that sounds annoying | 09:47 |
zyga | no, just two instances | 09:47 |
zyga | insurance today | 09:47 |
zyga | and final pickup tomorrow | 09:47 |
zyga | I just need to be there to sign the papers | 09:48 |
zyga | though we're trying to do the insurance remotely to avoid going there for really silly reason | 09:48 |
pedronis | we are seeing this kind of error often: cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_niWil9//dev: No such file or directory | 09:50 |
pedronis | zyga: ^ any idea? | 09:50 |
zyga | yes | 09:51 |
zyga | so this fails if either of the things happen | 09:51 |
pstolowski | yeah i just see it as well | 09:51 |
zyga | a /tmp/snap.rootfs_niWil9/dev (which we make ourselves just prior to that call) doesn't eixst | 09:51 |
zyga | or if /dev doesn't exist | 09:51 |
zyga | I did see this a few times | 09:52 |
zyga | let me think | 09:52 |
zyga | unit test failure https://www.irccloud.com/pastebin/5TCsf2ae/ | 09:53 |
pedronis | btw were we sure this was solid now: https://github.com/snapcore/snapd/pull/6217 | 09:55 |
mup | PR #6217: tests: reset snapd state on tests restore <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6217> | 09:55 |
pedronis | zyga: do we need more logging around that error? to know which it is? /dev or the directory we just created (that sounds scary) | 09:56 |
zyga | pedronis: I think it was okay, the problem is that our test suite has interlocking issues that sometimes mask each other, fixing something has impact that uncovers another thing that is broken; it's not good because we have no way to measure anything | 09:56 |
zyga | pedronis: ish, logging anything is notoriously difficult in snap-confine because of fear of string ops; I spent about a month discussing how to do it with jdstrand with no result other than "only in debug builds, too scary in production builds" | 09:57 |
mup | PR snapd#6317 opened: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6317> | 09:57 |
mborzecki | zyga: pedronis: ^^ | 09:57 |
pstolowski | pedronis: i'll work on that snapctl get bug if that's ok? | 10:01 |
pedronis | pstolowski: are you blocked on hot plug? | 10:02 |
pstolowski | pedronis: 2 hotplug PRs need reviews (i'm deconflicting one of them atm) | 10:03 |
pedronis | pstolowski: we need to write the main respond to events? handle enumeration? is that right? | 10:04 |
pedronis | is that work blocked? | 10:04 |
zyga | mborzecki: I'm wondering about something | 10:04 |
zyga | your patch looks good | 10:04 |
zyga | I wonder if we should release an update with this in distro patches | 10:04 |
pstolowski | pedronis: that's all implemented in the big hotplug branch already (i'm not deconflicting it until the smaller ones land though) | 10:05 |
pedronis | pstolowski: so the idea is to shrink that? and then ask for a review of it? | 10:06 |
pstolowski | pedronis: yes, i'd like the smaller ones to land, otherwise it's constant battle with de-conflicting | 10:06 |
pedronis | ok | 10:07 |
pstolowski | pedronis: otherwise what remains todo is the open questions (camera etc.), polishing around naming, better summaries (what we discuessed ~yesterday) | 10:08 |
pstolowski | naming = slot naming | 10:08 |
pedronis | ok, sounds good | 10:08 |
pedronis | I'll see if I get to review a bit more of those open ones | 10:08 |
pstolowski | pedronis: ah, and the gadget-declared slots discussed last week | 10:09 |
pedronis | yes | 10:10 |
* Chipaca shakes his fist at conflict detection, and goes for more coffee | 10:13 | |
Chipaca | actually scratch that, i'll go for a walk instead | 10:13 |
Chipaca | bbiab | 10:13 |
Chipaca | pedronis: I suspect this bit won't pass review: https://pastebin.ubuntu.com/p/QDbNMmmWh2/ | 10:14 |
pedronis | Chipaca: indeed, but there is probably something we can | 10:15 |
pedronis | do | 10:15 |
pedronis | Chipaca: we can have a quick chat once you are back if it can help | 10:15 |
Chipaca | pedronis: I think I need to generalise doInstall to take a current-change, and pass that in to the conflict checker | 10:16 |
Chipaca | pedronis: hopefully I can do it without breaking all the doInstall tests :-) | 10:16 |
pedronis | we don't have direct doInstall tests I think | 10:16 |
Chipaca | bonus :-) | 10:17 |
Chipaca | anyway, walk to clear head, bbiab | 10:17 |
mup | PR snapd#6318 opened: release-tools: display self-help <Created by zyga> <https://github.com/snapcore/snapd/pull/6318> | 10:20 |
* pstolowski gets xmax haircut, bbl | 10:23 | |
pstolowski | *xmas even | 10:25 |
mborzecki | cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_Nb69ea//dev: No such file or directory | 10:36 |
mborzecki | this thing pops up quite often | 10:36 |
pedronis | mborzecki: yes | 10:37 |
mborzecki | zyga: any clue what that might be? | 10:37 |
pedronis | mborzecki: are we removing /dev somehow? | 10:39 |
mborzecki | pedronis: not that i know of | 10:45 |
pedronis | or is some cgroup handling problem? | 10:45 |
mborzecki | idk, this comes from s-c, looking at things, we have a scratch dir (otherwise it'd die earlier), the we mount the rootfs (core in this case), and proceed to setup individual mounts, /dev is the first one | 10:49 |
mborzecki | \/dev is in core, there's probably one on the host too | 10:50 |
pedronis | mborzecki: zyga: I fear but it seems it started with landing of #6217 | 10:50 |
mup | PR #6217: tests: reset snapd state on tests restore <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6217> | 10:50 |
zyga | pedronis: hmmmm, let me think | 10:51 |
zyga | I don’t mind reverting that now | 10:51 |
zyga | I have enough state to work locally | 10:52 |
pedronis | given where we have are timewise, I would revert it | 10:52 |
pedronis | s/have// | 10:53 |
pedronis | mborzecki: can you prepare a revert? | 10:53 |
mborzecki | pedronis: ok, let's do this | 10:53 |
pedronis | mborzecki: if the revert itself fails that way we learn something either way | 10:55 |
mup | PR snapd#6319 opened: Revert "Merge pull request #6217 from sergiocazzolato/tests-reorg-prepare-restore" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6319> | 11:02 |
pedronis | let's see how it goes | 11:09 |
pedronis | mborzecki: thx | 11:10 |
popey | Has *anyone* actually got audio (alsa or pulse) working on core? | 11:10 |
popey | I have tried everything i can, and never get any audio over either | 11:10 |
popey | Followed every tip / trick I can, and am losing the will to live | 11:10 |
Chipaca | popey: have some chocolate, go for a walk, play some music or draw something! don't lose your will to live | 11:17 |
popey | :) | 11:17 |
popey | Figure of speech :) | 11:17 |
Chipaca | popey: couldn't risk it | 11:18 |
ogra | popey, what hardware ? | 11:25 |
popey | ogra: a pc | 11:26 |
ogra | it should definitely work through pulse if you installed the pulse snap and connected all inerfaces properly | 11:26 |
popey | the best I can get is apparmor failure on /run/pulse/native which leads to https://forum.snapcraft.io/t/pulseaudio-in-daemon-mode/6606 | 11:26 |
popey | it does not | 11:26 |
popey | I would appreciate someone else confirming this. I spent hours on this last night and it should not be this hard. | 11:27 |
ogra | it is quite a while ago that i tested pulse (about year) and there it used to work ... something might have changed | 11:28 |
Chipaca | what was the name of the mixer that mate ships by default as a snap? | 11:29 |
popey | pulsemixer | 11:29 |
ogra | you might need to switch to the right output device though ... i dont think core picks a proper default | 11:29 |
* Chipaca installs that | 11:29 | |
popey | which also doesnt work on core | 11:30 |
Chipaca | popey: I can confirm the DENIEDs | 11:30 |
Chipaca | popey: 'snap logs pulseaudio' talks about cookies | 11:31 |
Chipaca | popey: hmm! | 11:31 |
Chipaca | popey: I can open the mixer just fine with sudo though | 11:31 |
ogra | popey, the pulse snap ships pactl ... (way more low level than pulsemixer and way more cryptic to use but has the same powers) | 11:32 |
Chipaca | ogra: when you say 'the pulse snap', is it called "pulseaudio"? | 11:32 |
* Chipaca assumes so | 11:33 | |
ogra | yes | 11:33 |
ogra | https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/pulseaudio/tree/snapcraft.yaml | 11:33 |
Chipaca | k | 11:33 |
Chipaca | popey: so | 11:35 |
Chipaca | popey: I installed pulseaudio | 11:35 |
Chipaca | popey: and mpv | 11:35 |
Chipaca | popey: and copied a music file to /root/snap/mpv/current/ | 11:36 |
Chipaca | popey: and mpv plays it | 11:36 |
Chipaca | I get nothing out the speakers but that might be me sucking at kvm | 11:36 |
popey | using sudo? | 11:36 |
Chipaca | popey: yes | 11:36 |
Chipaca | popey: my user isn't part of the audio group | 11:36 |
ogra | that shouldnt matter ... you talk to the daemon, not to the device | 11:37 |
Chipaca | popey: note that the home interface doesn't auto-connect on core | 11:37 |
ogra | you should use paplay for testing | 11:38 |
Chipaca | ogra: can that play oggs? | 11:38 |
ogra | (comes with the pulseaudio snap( | 11:38 |
ogra | i think it should | 11:38 |
Chipaca | it doesn't error out, but as i said i don't have sound in the kvm for whatever reason (might be a core issue -- but might be me sucking at kvm) | 11:39 |
Chipaca | (I had to copy the audio file to /root/snap/pulseaudio/current ) | 11:39 |
ogra | either that or pulse uses the wrong audio device | 11:39 |
Chipaca | yeah that could be happening | 11:40 |
Chipaca | popey: has this helped, or are you in the same place still? | 11:40 |
ogra | core has nothing to select a device as default | 11:40 |
ogra | so you might need some pactl tinkering frst | 11:40 |
popey | I cannot get mpv working as user or root either | 11:42 |
ogra | Chipaca, kvm should just need "-soundhw ac97" btw | 11:42 |
popey | so no, no further forward | 11:42 |
Xceed | I've also observed the following... https://forum.snapcraft.io/t/snapcraft-python-plugin-install-wrong-pip-version-during-snap-build/5445 ... however, the thread/issue was never answered/fixed, and I can't seem to find a how-to update pip for building. | 11:42 |
ogra | popey, use paplay | 11:42 |
popey | paplay farts that it needs root | 11:43 |
popey | "This script must be run as root" | 11:43 |
niemeyer | Heya | 11:43 |
Chipaca | popey: how does mpv fail? | 11:44 |
Chipaca | popey: what are you trying :-) | 11:44 |
niemeyer | Are there any failing tests I could look at that would be fixed by spread#70, or is that random? | 11:44 |
mup | PR spread#70: Reboot on backgraound to avoid spread wait for long time <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70> | 11:44 |
popey | Chipaca: error opening/initializing the selected video_out (--vo) device. | 11:45 |
popey | is what I get from mpv playing an mp3 in root home folder | 11:45 |
ogra | popey, -vo null | 11:45 |
ogra | or --vo | 11:45 |
Chipaca | popey: do you have x or something? mine didn't even try | 11:45 |
Chipaca | popey: if you do, you might need to connect the x11 interface | 11:45 |
ogra | and equivalently ... --ao pulse | 11:45 |
popey | Chipaca: x11 on core? | 11:46 |
ogra | heh | 11:46 |
Chipaca | popey: it exist | 11:46 |
Chipaca | s | 11:46 |
popey | ok, as sudo, mpv can play audio now. yay | 11:46 |
ogra | yeah | 11:46 |
ogra | if you install some snap that provides it | 11:46 |
Chipaca | popey: i mean: there's an x11 snap somewhere | 11:46 |
popey | Sorry, rewind. | 11:46 |
Chipaca | we added support for running the x server as a snap, on core | 11:46 |
Chipaca | anyway, woo | 11:46 |
popey | User, wants to install a snap that plays audio. | 11:47 |
popey | Currently we have to copy files to a root owned folder, and run as root? | 11:47 |
Chipaca | 1 sec | 11:47 |
ogra | popey, well, core is more focused on headless and userless i guess so nobody thought about that before | 11:47 |
Chipaca | popey: i killed my kvm, need to do the dance again to test something | 11:48 |
ogra | (all clients you'd normally use would run as daemons as well in that case) | 11:48 |
ogra | popey, btw, you could take a look at my video-kiosk snap ... | 11:51 |
ogra | it spawns mplayer as a daemon that uses pulse from the pulseaudio snap and offers a web-ui to play files | 11:52 |
zyga | I added a check for unmounted base snap | 11:52 |
zyga | let's see if I can hit this | 11:52 |
popey | Interesting, thanks ogra. | 11:52 |
popey | I hadn't even considered doing everything as root. | 11:52 |
popey | This gets me further forward, thanks Chipaca / ogra :) | 11:53 |
ogra | https://github.com/krpors/wasp | 11:53 |
ogra | (and https://github.com/ogra1/video-kiosk-snap) | 11:53 |
popey | It does moan that "failed to create secure directory (/run/user/0/snap.(snapname)/pulse: No such file or directory | 11:54 |
popey | but that seems to not be a massive problem, as audio does play | 11:54 |
ogra | well, that sounds like a bug ... with confinement or confinement integration | 11:55 |
popey | sudo pulsemixer also works, as a bonus for fiddling the volumes | 11:56 |
popey | and shows the client connected too. | 11:56 |
* popey is happy | 11:56 | |
ogra | :) | 11:56 |
mborzecki | so i'm playing with my gl debugging snap on a system with a vega cards, and there's no gl support at all | 11:59 |
mborzecki | a revision which uses core18 as base is somewhat better | 12:00 |
zyga | mborzecki: we need to implement better driver support | 12:00 |
zyga | mborzecki: it would help if core{16,} got updated driver stack but that's probably unlikely | 12:01 |
mborzecki | zyga: we have a task for opengl and nvidia, but mesa is in bad shape too | 12:02 |
zyga | yes | 12:02 |
zyga | but doing it for nvidia will open up the path for generic support | 12:02 |
zyga | I fully agree though | 12:02 |
pedronis | mborzecki: zyga: that revert is green | 12:05 |
zyga | let's merge it | 12:05 |
mborzecki | or maybe another travis run? | 12:05 |
zyga | I wonder if there's some interplay with another branch | 12:05 |
mup | PR snapd#6319 closed: Revert "Merge pull request #6217 from sergiocazzolato/tests-reorg-prepare-restore" <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6319> | 12:06 |
zyga | depending on pressure, we can run this several times more if you prefer | 12:06 |
pedronis | it cannot make things worse | 12:10 |
Chipaca | pedronis: https://pastebin.ubuntu.com/p/mKhGh4rGcr/ with conflict resolution back on \o/ | 12:23 |
* Chipaca ~> lunch | 12:24 | |
zyga | Chipaca: "Done today at 12:23 GMT today at 12:23 GMT Run configure hook of "test-snapd-epoch" snap if present" - didn't we have a patch that makes hooks run if they are really present?] | 12:26 |
zyga | if we did, should that just say "running configure hook..." | 12:26 |
Chipaca | https://pastebin.ubuntu.com/p/H6vJfTZRQN/ | 12:26 |
Chipaca | ^ two refreshes with epoch changes in parallel | 12:26 |
Chipaca | zyga: ¯\_(ツ)_/¯ no idea | 12:26 |
Chipaca | pstolowski: ^? | 12:27 |
* Chipaca ~> really lunch | 12:27 | |
pedronis | Chipaca: :) | 12:27 |
pedronis | zyga: don't think that patch was for all hooks | 12:27 |
pedronis | afaict it was only for interface hooks | 12:31 |
pstolowski | zyga, Chipaca: we did, but for interface hooks only | 12:32 |
zyga | mmm | 12:32 |
zyga | thanks | 12:32 |
pstolowski | since these had the most impact (4 extra task for every connect) | 12:33 |
zyga | hmm | 12:34 |
zyga | the failure with /dev is a bit hard to reproduce | 12:34 |
pstolowski | we can maybe apply this optimization everywhere | 12:34 |
pedronis | zyga: I expect you need some combination of tests and bad restore | 12:35 |
pedronis | if the casue was really that PR | 12:35 |
zyga | didn't this happen on the PR that was fixing a typo as well? | 12:36 |
zyga | I can switch to any ref it someone has an idea | 12:36 |
pedronis | zyga: yes | 12:36 |
pedronis | afaik it happened in some form in all of the master runs | 12:36 |
pedronis | since that PR was merged | 12:36 |
zyga | I'll run one more go | 12:38 |
zyga | and write a spread test for the extra check | 12:38 |
zyga | we can propose it regardless of current occurrence | 12:38 |
pedronis | pstolowski: what's the status of this: https://trello.com/c/KCMZcd5F/74-fix-for-kr-pretty-diff-memleak-affecting-our-tests | 12:41 |
sergiusens | rbasak I am off until Thursday. An email will certainly remind me to get back to you. | 12:57 |
pedronis | zyga: master failed but on a pull and the mount bug, not anymore on the /dev issue | 12:58 |
zyga | so back to where we were, thank you | 12:59 |
pedronis | the mount bug we have ideas | 12:59 |
pedronis | pull of repos, life is hard | 12:59 |
pstolowski | pedronis: radio silence from upstream; he has a bunch of PRs pending reviews.. | 13:03 |
mborzecki | off to pick up the kids | 13:05 |
zyga | I guess during my "holidays" I could and should fix the debian package | 13:05 |
zyga | unless there are any takers I will do it | 13:05 |
zyga | but first | 13:05 |
zyga | lunch | 13:05 |
Facu | Hi all! Is there a simple way to make the installed snap "writable"? I just want to debug a Python tool installed through snap... add a couple of "print"s inside the code and run it | 13:13 |
ogra | Facu, you can "cp /snap/foobar/current/bin/my-script ." and then "sudo mount -bind my-script /snap/foobar/current/bin/my-script" ... that gives you an overalyed writable version of the script | 13:15 |
ogra | *overlayed | 13:15 |
Facu | ogra, can I do that with a whole dir? /snap/foobar/current/lib/python3.5/site-packages/foobar/ | 13:18 |
Chipaca | Facu: unsqashfs /var/lib/snapd/snaps/the-snap.snap | 13:19 |
Facu | (the script doesn't really do much, all what really happens is inside own libs) | 13:19 |
Chipaca | Facu: snap try squashfs-root | 13:19 |
ogra | you have to copy the whole dir content and it gets really confusing to handle multiple files that way i guess ... | 13:19 |
Chipaca | Facu: squashfs-root is the directory unsquashfs creates (unless you tell it otherwise), it will have the (now rw) contents of the snap | 13:20 |
ogra | but technically you can indeed also overlay a dir that way ... though Chipaca has the better option here | 13:20 |
Chipaca | ogra: if this is your own snap, you can just 'snap try' the prime directory, if you're using an old-style snapcraft.yaml | 13:20 |
Chipaca | the new-style build-in-a-vm snapcraft doesn't leave a 'prime' :-/ | 13:21 |
ogra | well, if you have the source :) | 13:21 |
Facu | Chipaca, it complains that - Montar snap "snapcraft" (unset) (snap "snapcraft" requires classic confinement) | 13:22 |
Facu | Chipaca, I'll try ogra's solution with just the couple of files that I think I need to debug | 13:22 |
pedronis | Facu: you can do snap try --classic | 13:24 |
Facu | pedronis, worked great, thanks! | 13:27 |
pedronis | np | 13:28 |
Chipaca | Facu: snap try --dwim | 13:29 |
Facu | Chipaca, "dwim"? I don't see it in `snap help try` | 13:30 |
Chipaca | Facu: https://en.wikipedia.org/wiki/DWIM | 13:30 |
Facu | ja | 13:30 |
zyga | eh | 13:30 |
zyga | multipass doesn't work on opensuse | 13:30 |
zyga | no group "sudo" | 13:30 |
zyga | ergo | 13:30 |
zyga | no snapcraft | 13:31 |
zyga | ergo | 13:31 |
zyga | sucks :/ | 13:31 |
jdstrand | zyga (pedronis): re logging> that's probably overstating things a bit. it is quite true that we want to be careful sending arbitrary strings, but that doesn't mean we can't send anything | 13:32 |
mborzecki | zyga: yes, that should be fixed in edge i think | 13:33 |
zyga | ah, perfect | 13:34 |
mup | PR snapd#6320 opened: tests: install core and save it as part of snapd state <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6320> | 13:36 |
=== ricab is now known as ricab|lunch | ||
rbasak | sergiusens: thanks. I'm off from tomorrow until the new year. I'll follow up with you in the new year then. Enjoy your time off! | 13:57 |
pedronis | cachio: we had to revert #6217, we really need to go about this much much more carefully, I am also not sure how much of a priority it is | 13:57 |
mup | PR #6217: tests: reset snapd state on tests restore <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6217> | 13:57 |
cachio | pedronis, it is ok, it is not high prioriry | 14:00 |
pedronis | zyga: are you joining or skipping? | 14:01 |
zyga | diddledan: hello | 14:01 |
zyga | oh | 14:01 |
zyga | joining! | 14:01 |
zyga | 2fa | 14:03 |
zyga | ready | 14:03 |
zyga | diddledan: so I spent some time on the layout issue | 14:03 |
zyga | and I cannot reproduce it | 14:03 |
zyga | can you still get to that point where it breaks? | 14:03 |
diddledan | weird | 14:03 |
diddledan | yes | 14:03 |
zyga | can you collect /var/lib/snapd/mount/*.fstab file (for layout-test) | 14:04 |
zyga | as well as /run/snapd/ns/*.fstab | 14:04 |
zyga | and lastly | 14:04 |
diddledan | you need to be running on a system that isn't i386 (x86_64, for example) and you need to run the app every install to ensure the mount namespace is set-up | 14:04 |
zyga | I did that | 14:04 |
zyga | lastly nsenter -m/run/snapd/ns/layout-test.mnt | 14:05 |
zyga | and then cat /proc/self/mountinfo | 14:05 |
zyga | (and exit to quit the shell) | 14:05 |
diddledan | which step do you want these from? when it's got to the broken stage, or before? | 14:05 |
zyga | when it is in a broken state | 14:05 |
diddledan | kk | 14:05 |
zyga | thank you | 14:05 |
zyga | I tested with 2.36.3 | 14:05 |
zyga | though this should be the same as .2 | 14:05 |
zyga | no changes in that area | 14:06 |
diddledan | or maybe I can't? | 14:07 |
diddledan | weirder and weirder | 14:07 |
diddledan | ok, I can't reproduce it any more with my test snap | 14:09 |
zyga | did you perhaps snap-try before | 14:09 |
diddledan | fooey | 14:09 |
zyga | on similar snap name | 14:09 |
diddledan | nope | 14:09 |
zyga | hmmm | 14:09 |
zyga | do you have snap changes | 14:09 |
zyga | that go all the way back when this failed? | 14:09 |
zyga | did core18 refresh in the meantime? | 14:09 |
diddledan | you can see all my testing in this paste (next message) | 14:10 |
diddledan | https://www.irccloud.com/pastebin/7NgxTerq/ | 14:10 |
Facu | Chipaca, I finished "trying" my unsquashed snap ... how do I tell snap to resume normal refresh behaviour? (that is, when a new snap is available, to use that one instead the one I was trying) | 14:10 |
diddledan | the ones from yesterday are my attempts that were showing the failure after each third time, and the ones from today aren't failing | 14:10 |
zyga | Chipaca: one small bug related to snap state: https://bugs.launchpad.net/snapd/+bug/1807512 | 14:11 |
mup | Bug #1807512: Classic snaps used in --jailmode still use real home directory <snapd:Triaged> <https://launchpad.net/bugs/1807512> | 14:11 |
diddledan | looks like core18 did change overnight https://www.irccloud.com/pastebin/8q3GPA3v/snap-tasks-189 | 14:12 |
zyga | ha | 14:12 |
zyga | I bet this is a factor | 14:12 |
zyga | but I cannot explain how this fixed it for you | 14:12 |
diddledan | probably need to mark the bug as resolved for now, and revisit it if it resurfaces? | 14:13 |
zyga | can you revert core and reproduce it? | 14:13 |
zyga | just as a last resort? | 14:13 |
* diddledan tries | 14:13 | |
zyga | thank y ou | 14:13 |
zyga | I still think there was more to it | 14:14 |
zyga | not that specific revision of core | 14:14 |
zyga | but perhaps? | 14:14 |
diddledan | yeah, I can't reproduce it after reverting core18 | 14:15 |
Chipaca | Facu: snap refresh --amend thesnap | 14:16 |
zyga | diddledan: thank you for checking | 14:26 |
Facu | Chipaca, wonderful, thanks! | 14:26 |
mborzecki | zyga: about no space left on device, take a look at this: https://github.com/snapcore/snapd/blob/master/tests/main/install-store-laaaarge/task.yaml#L3..L17 specifically `umount /tmp || true` | 14:38 |
zyga | or true ;) | 14:38 |
mborzecki | yeah | 14:38 |
zyga | I also worry that we may leak a mount namespace | 14:38 |
zyga | or something equally non obvious | 14:38 |
zyga | that can keep any number of bytes in flight | 14:38 |
zyga | we need to measure leaks | 14:39 |
zyga | we leak a lot of stuff | 14:39 |
mborzecki | zyga: hm simple df -h in debug could be useful | 14:40 |
zyga | mborzecki: yes | 14:43 |
mborzecki | zyga: ok, let me do a quick pr | 14:43 |
zyga | mborzecki: but we should have something that says "this test was not cleaned up correctly: this is what leaked" too | 14:43 |
zyga | mborzecki: but that is harder | 14:43 |
mborzecki | zyga: iff we see a 4k /tmp we'll know :P | 14:44 |
zyga | 4k is too small | 14:49 |
=== ricab|lunch is now known as ricab | ||
mup | PR snapd#6321 opened: spread: show free space in debug output <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6321> | 14:50 |
mborzecki | zyga: ^^ | 14:52 |
Son_Goku | mborzecki, I'm building 2.36.3 now | 15:02 |
zyga | Son_Goku: thank you :) | 15:06 |
Son_Goku | ugh, everything is a bloody mess right now | 15:06 |
mborzecki | Son_Goku: yay! | 15:08 |
Son_Goku | I'm going to deal with the mess of updating F28 and F29 later | 15:09 |
Son_Goku | but at least rawhide and epel7 will be done right now | 15:09 |
pstolowski | cachio: that issue with nightly test you pasted during the standup, was it against 2.36.2? | 15:12 |
cachio | it uses master | 15:18 |
cachio | pstolowski, ~ | 15:18 |
cachio | pstolowski, it is part of the snapd main suite | 15:18 |
pstolowski | cachio: i see, thanks | 15:18 |
cachio | pstolowski, it is called install-snaps | 15:19 |
Son_Goku | mborzecki, 2.36.3 built and attached to update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b240f3418f | 15:21 |
Son_Goku | you'll have to grab the rpms from here to test for now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1174149 | 15:21 |
pstolowski | cachio: ack | 15:21 |
pstolowski | i'm trying to reproduce manually (with 2.36.2 atm), of course after removing gnome and gtk-common-themes snaps, so far no luck | 15:22 |
cachio | pstolowski, you can try running this test with -debug | 15:23 |
cachio | not sure if it is 100% reproduceable | 15:23 |
zyga | I'm in a debug session, test failed on random network fluke | 15:24 |
zyga | but maybe not really random | 15:24 |
zyga | core snap is not installed | 15:25 |
zyga | and all stuff I try times out | 15:25 |
zyga | what was the magic sequence to dump iptables? | 15:25 |
zyga | https://www.irccloud.com/pastebin/x6lNrfPW/ | 15:25 |
zyga | aha | 15:25 |
zyga | we leaked iptables across tests | 15:26 |
zyga | google:ubuntu-16.04-64:tests/main/interfaces-many google:ubuntu-16.04-64:tests/main/remove-errors google:ubuntu-16.04-64:tests/main/install-errors:withreexec google:ubuntu-16.04-64:tests/main/try-snap-goes-away:test_snapd_service google:ubuntu-16.04-64:tests/main/interfaces-gpg-keys google:ubuntu-16.04-64:tests/main/snap-service-after-before google:ubuntu-16.04-64:tests/main/snap-run-alias:testsnapdtoolscat | 15:27 |
zyga | google:ubuntu-16.04-64:tests/main/classic-ubuntu-core-transition-auth google:ubuntu-16.04-64:tests/main/proxy-no-core google:ubuntu-16.04-64 .../tests/runtime-state# | 15:27 |
zyga | one of those tests leaked it | 15:27 |
zyga | or is that expected somehow? | 15:27 |
zyga | pstolowski: is this related to your work recently>? | 15:27 |
pstolowski | zyga: no, the test i added recently added the following rule "iptables -I OUTPUT -p udp --dport 53 -j REJECT --reject-with icmp-port-unreachable" | 15:30 |
pstolowski | zyga: (snap-network-errors test) | 15:30 |
zyga | mmmm | 15:30 |
pstolowski | zyga: iptables-save > ... dumps the rules | 15:31 |
mborzecki | zyga: proxy-no-core does this | 15:31 |
zyga | yeah | 15:31 |
zyga | I just git grepped | 15:31 |
pstolowski | zyga: econnreset is the other test where we have iptables | 15:32 |
pstolowski | nah, it has different rules as well | 15:32 |
zyga | restore is broken? | 15:34 |
zyga | + iptables -D OUTPUT -m owner --uid-owner 12345 -j ACCEPT -p tcp | 15:34 |
zyga | iptables: Bad rule (does a matching rule exist in that chain?). | 15:34 |
zyga | main/snap-network-errors/task.yaml also didn't restore correctly | 15:37 |
pstolowski | zyga: hmm looks identical to the one that inserts the rule, except for the order of args | 15:37 |
zyga | I don't think it's just the restore logic | 15:37 |
zyga | it's not a test that always fails | 15:37 |
zyga | it's something that triggers the castle to fall apart | 15:38 |
mborzecki | Son_Goku: i've installed the packages, will try with some random snaps now | 15:38 |
pstolowski | zyga: where do you see a leftovers from snap-network-errors? | 15:39 |
zyga | pstolowski: just iptables -L | 15:39 |
zyga | https://www.irccloud.com/pastebin/8TX9Hu77/ | 15:39 |
zyga | all tests fail so -debug shell is very chatty about it | 15:39 |
pstolowski | zyga: i don't see the dns rule from s-n-errors test there? | 15:40 |
zyga | REJECT all -- anywhere anywhere reject-with icmp-port-unreachable | 15:41 |
zyga | isn't that it? | 15:41 |
pstolowski | no | 15:42 |
pstolowski | zyga: s-n-errors has iptables -I OUTPUT -p udp --dport 53 -j REJECT --reject-with icmp-port-unreachable (narrowed down to udp, port 53), and in OUTPUT chain, not FORWARD | 15:42 |
zyga | so something went south | 15:42 |
zyga | anywy | 15:43 |
zyga | that's not what I was looking at | 15:43 |
zyga | restarted to see | 15:43 |
zyga | to see if I can reproduce the issue I'm after | 15:43 |
mborzecki | Son_Goku: seems to work fine, +1 karma :) | 15:48 |
Son_Goku | excellent | 15:48 |
pedronis | cachio: having lunch? are you going to work on core promotion after? | 15:58 |
pedronis | mborzecki: I review #6317 | 15:58 |
mup | PR #6317: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6317> | 15:58 |
cachio | pedronis, preparing lunch | 16:00 |
cachio | pedronis, core has been promoted to stable | 16:00 |
cachio | pedronis, but store team was dealing with some infra issues | 16:01 |
pedronis | cachio: yes, sorry, I somehow missed in the logs | 16:01 |
cachio | pedronis, np | 16:01 |
Wimpress | Afternoon snapd team :-) | 16:02 |
* cachio lunch | 16:03 | |
Wimpress | I remember a pending PR that would make it possible to expose access to defined dot file/directories via an interface. | 16:03 |
Wimpress | What is the status of that? | 16:03 |
pstolowski | Wimpress: hey, this https://github.com/snapcore/snapd/pull/5845 ? | 16:04 |
mup | PR #5845: interface: add new `{personal,system}-files` interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845> | 16:04 |
pedronis | Wimpress: it will be in 2.37, it will need store declaration approval for use tough | 16:04 |
Wimpress | Yep, that is the PR pstolowski 👍 | 16:05 |
Wimpress | pedronis: OK, no problem. | 16:05 |
Wimpress | I've got some ISVs who are keen to take advantage of this. | 16:05 |
pstolowski | Wimpress: did you manage to find a reproducer for the issue with snap remove taking forever? | 16:06 |
Wimpress | @sergiusens When will Snapcraft grow support for this capability? | 16:07 |
Wimpress | pstolowski: I think so. Let me just comfirm the steps. | 16:07 |
Wimpress | Typically, I can't reproduce the issue now. | 16:09 |
Wimpress | pedronis: What is the ETA for snapd 2.37? | 16:09 |
pedronis | Wimpress: after the break for sure, bit hard to give a precise date right now, core18 work and bug fixes for 2.36.x have delayed it somewhat | 16:12 |
niemeyer | cachio: The proposed reboot command looks a bit suspect | 16:13 |
niemeyer | cachio: The exit on background doesn't do much.. it should be equivalent to doing nothing | 16:16 |
niemeyer | cachio: Then, the reboot isn't being nohup'd, which means if the terminal actually exits it might be killed | 16:17 |
niemeyer | cachio: So I wonder what the actual fix really is | 16:17 |
niemeyer | cachio: The two relevant differences is the use of -f, and the redirect of stdout.. I wonder which of these fixed your problem | 16:18 |
zyga | Re, had to help the kids in the kitchen | 16:18 |
niemeyer | cachio: Ah, it also puts it in background, although it's not clear what effect that has given that we keep the shell alive | 16:30 |
niemeyer | cachio: The force is also unclear.. systemctl's manual says "When used with halt, poweroff, reboot or kexec, execute the selected operation without shutting down all units." | 16:31 |
niemeyer | cachio: Unclear we want that during testing | 16:31 |
niemeyer | cachio: Would you mind to break down this change and do only a single modification at a time, and see which one actually fixed the problem? | 16:32 |
cachio | niemeyer, sure | 16:56 |
cachio | I'll split it | 16:56 |
=== pstolowski is now known as pstolowski|afk | ||
popey | ogra: got audio working in core on x86 laptop, but pi shows "Dummy Output" like there's no audio card? | 17:34 |
popey | https://usercontent.irccloud-cdn.com/file/LuF1hBWY/Screenshot%20from%202018-12-18%2017-33-53.png | 17:34 |
zyga | images on irc | 17:34 |
zyga | must be 1995 | 17:34 |
popey | get off my lawn | 17:34 |
zyga | popey, ogra: not that I should try, I would be interested in alsa status on raspbian | 17:35 |
popey | I am not touching alsa with a 10 foot pole, thanks :) | 17:35 |
pedronis | zyga: "Precious Logs" means do not re-run? | 17:36 |
zyga | yeah | 17:36 |
zyga | I just did that because I wanted the seed written down | 17:36 |
zyga | I'll remove the label now | 17:36 |
zyga | fingers crossed, I really want to understand that test failure | 17:37 |
popey | on raspbian pulsemixer / pulseaudio snaps work | 17:41 |
ogra | popey, you need to set the right output device with pactl | 17:41 |
popey | https://usercontent.irccloud-cdn.com/file/HnIcoVqh/Screenshot%20from%202018-12-18%2017-41-18.png | 17:41 |
popey | ahhh | 17:41 |
ogra | the default is HDMIM out on the pi iirc | 17:41 |
ogra | *HDMI | 17:42 |
popey | pactl list cards lists none | 17:43 |
popey | on raspbian, it lists one | 17:45 |
ogra | hmm, what gadget is that ? | 17:46 |
popey | pi2 16.04-0.17 29 stable canonical✓ gadget | 17:47 |
popey | on raspbian sys/devices/platform/soc/soc\:audio/bcm2835_alsa/sound/card0/ exists | 17:47 |
popey | it doesn't exist on core | 17:47 |
ogra | ogra@localhost:~$ cat /proc/asound/cards | 17:48 |
ogra | 0 [ALSA ]: bcm2835 - bcm2835 ALSA | 17:48 |
ogra | bcm2835 ALSA | 17:48 |
popey | proc asound doesn't exist | 17:49 |
ogra | popey, does your gadget have: | 17:49 |
ogra | ogra@localhost:~$ grep audio= /boot/uboot/config.txt | 17:49 |
ogra | dtparam=audio=on | 17:49 |
popey | no | 17:50 |
ogra | aha... | 17:50 |
ogra | the curse f gadgets not updating payload data | 17:50 |
ogra | *of | 17:50 |
zyga | it is scheduled to be fixed this 6-month cycle | 17:50 |
ogra | i assume this is an older installation ? | 17:50 |
popey | i have a pile 'o' pies, no idea which one this is | 17:51 |
popey | it could be, how can I tell when it was installed? | 17:51 |
zyga | you should be able to look at the seed | 17:51 |
zyga | the seed is what was made by ubuntu-image | 17:51 |
zyga | including the revisions | 17:51 |
ogra | (the latest pi gadget has all this fixed ... but config.txt doesnt get upgraded after first install) | 17:51 |
popey | snap changes only goes up to 40 | 17:51 |
zyga | ls /var/lib/snapd/seed | 17:51 |
popey | so not that old | 17:51 |
ogra | popey, well, make sure the above line is in confog.txt and reboot | 17:51 |
ogra | *config | 17:52 |
popey | that'll fix it? | 17:52 |
ogra | yes | 17:52 |
ogra | that enables the audio device | 17:52 |
zyga | popey: broken=no | 17:52 |
zyga | ;) | 17:52 |
popey | dtparam=audio=on in config.txt, right? | 17:53 |
ogra | yeah | 17:53 |
popey | ok, now i see proc/asound | 17:56 |
popey | but pulseaudio didn't start | 17:56 |
popey | ah, i was just impatient :D | 17:56 |
popey | Pi's take a while to boot :) | 17:56 |
popey | \o/ pulsemixer shows the device now \o/ | 17:57 |
* ogra just got his first "your month in snaps" | 17:57 | |
ogra | so awesome ! | 17:57 |
ogra | though it is worrying how many users my experimental snaps that are not ready for public yet do have ... | 17:58 |
ogra | seems people dont care if something is in edge only :) | 17:58 |
popey | \o/ spotify playing on my core \o/ | 17:58 |
ogra | \o/ | 17:58 |
ogra | on the pi ?!? | 17:58 |
Wimpress | Thanks for the assist ogra :-) | 17:59 |
ogra | np :) | 17:59 |
popey | https://usercontent.irccloud-cdn.com/file/Oh3iN6Ux/Screenshot%20from%202018-12-18%2017-59-08.png | 17:59 |
popey | Yes, controlled from my desktop, pi connected to speaker | 17:59 |
ogra | awesome ! | 17:59 |
popey | yes :D | 17:59 |
popey | blog post coming :D | 17:59 |
ogra | popey, make sure to recommend the most recent image for it, that will have the fixed config.txt | 18:00 |
popey | yeah, will do :D | 18:00 |
mup | PR snapd#6311 closed: image: do not write empty etc/cloud <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6311> | 18:23 |
zyga | chipaca: does this make any sense to you? https://www.irccloud.com/pastebin/ZfOqgk4D/ | 19:06 |
zyga | Chipaca: (in case case sensitive notification) | 19:06 |
zyga | also perhaps unexpected file name :) | 19:06 |
zyga | https://www.irccloud.com/pastebin/z2xkvTgz/ | 19:06 |
zyga | The file "-" has text "core (bogus/stable) 16-2.36.3+git1063.bbf4a49 from Canonical✓ refreshed" | 19:08 |
zyga | in any case that test is borken | 19:09 |
smoser | o/ | 19:33 |
smoser | hey. | 19:33 |
smoser | i'mi trying to update the license at | 19:33 |
smoser | https://snapcraft.io/image-status/listing | 19:33 |
smoser | i click 'simple'. hit 'x' on the "Proprietary" tag that is currently there. | 19:34 |
smoser | then type 'GPL' and click the provided "GNU General Public License v2.0 or later" | 19:34 |
smoser | hit 'Save' | 19:34 |
smoser | it says | 19:34 |
smoser | Invalid symbols sequence such as (A B) for token: "-" at position: 7 | 19:34 |
smoser | any ideas? | 19:35 |
smoser | also nit pick... there are two entries for 'GNU General Public License v2.0 or later' | 19:35 |
cachio | niemeyer, update done | 19:56 |
niemeyer | cachio: What was the outcome of the test? | 20:01 |
cachio | this test is updating the debian image and running snapd tests on the new one | 20:01 |
cachio | in case the tests pass then that image is promoted to be used on google tests | 20:02 |
cachio | niemeyer, it is also failing on fedora and amazon images | 20:02 |
cachio | I reduced the reboot expression as mucha as possible | 20:05 |
niemeyer | Sorry, I meant to ask what was the actual reason the change done fixed the tests? | 20:05 |
niemeyer | Considering that there were several bundled changes | 20:05 |
cachio | niemeyer, the command reboot was not returning | 20:08 |
cachio | is not returning | 20:08 |
cachio | so ssh command is getting stuck | 20:08 |
cachio | with the & we make sure the ssh finished the execution | 20:09 |
cachio | niemeyer, just to clarify, by doing "reboot" the reboot is done but the ssh command does not finish | 20:12 |
cachio | this is the log https://paste.ubuntu.com/p/x3cyDFZ2nb/ | 20:12 |
cachio | niemeyer, I also added the & to make it work on devices | 20:20 |
cachio | because just with -f is was failing on rpi | 20:21 |
pedronis | zyga: I'm also very confused why that test started failing | 20:21 |
zyga | it failed once | 20:21 |
zyga | I'm running on a loop with the seed from the failure earlier | 20:21 |
pedronis | I see various PR failing with it | 20:24 |
zyga | oh? | 20:26 |
zyga | that's unexpected | 20:26 |
zyga | I mean | 20:26 |
zyga | I think the failure is genuine | 20:26 |
zyga | the redirect is bogus | 20:26 |
zyga | or some fancy shell syntax I'm unfamiliar with | 20:26 |
zyga | and I see a file with "-" in the name | 20:26 |
zyga | so it must be something bad | 20:26 |
zyga | but not sure why it fails | 20:26 |
pedronis | I don't see any recent change that would correlate with that failing | 20:29 |
zyga | I see the same thing, I cannot explain it | 20:31 |
zyga | I would start undoing the layers of the onion | 20:31 |
zyga | let's fix the syntax woes | 20:31 |
pedronis | zyga: I think I know why it's failing | 20:41 |
zyga | oh, do tell please | 20:41 |
Son_Goku | zyga: snapd updates for f28 and f29 | 20:42 |
Son_Goku | https://bodhi.fedoraproject.org/updates/FEDORA-2018-b66c5e0d53 | 20:42 |
Son_Goku | https://bodhi.fedoraproject.org/updates/FEDORA-2018-0aaf48e196 | 20:42 |
zyga | Son_Goku: thank you, I will test it tomorrow | 20:42 |
zyga | Son_Goku: any surprises? | 20:42 |
Son_Goku | nah, this just brings us in sync with the epel7 update | 20:42 |
zyga | that's good | 20:42 |
zyga | uneventful stuff is best | 20:43 |
Son_Goku | I had to wait for go-systemd update to be available in f28 buildroot override | 20:43 |
Son_Goku | 2.37 will hopefully be the exciting update | 20:43 |
Son_Goku | I'll be closing somewhere around 50 SELinux policy bugs with that one | 20:43 |
niemeyer | cachio: Does it work with & alone and no other change? | 20:44 |
Son_Goku | not necessarily because they're fixed, but because the policy is rewritten too much to apply anymore | 20:44 |
cachio | niemeyer, it doesn't | 20:50 |
cachio | it failed with debian | 20:50 |
cachio | just with -f it fails in the boards | 20:50 |
cachio | I don't know why the ssh command is getting stuck | 20:51 |
niemeyer | Why? | 20:51 |
cachio | same issue | 20:51 |
niemeyer | Have you read the docs for -f? | 20:51 |
cachio | ssh command does not finish | 20:51 |
niemeyer | Debian systems shouldn't require it for not failing | 20:52 |
niemeyer | cachio: We need to know what the actual issue is | 20:52 |
cachio | ok, I'll continue researching | 20:52 |
cachio | any idea what to look in the debian system? | 20:53 |
cachio | I already checked logs and there is nothing | 20:53 |
cachio | the reboot is done | 20:53 |
niemeyer | cachio: If the reboot is done, it can't possibly be about the -f flag.. this is just a way to force it and ignore what services think about the process | 20:56 |
niemeyer | cachio: It's most likely a matter of timing | 20:56 |
cachio | niemeyer, I mean the reboot is done with -f and without | 20:57 |
cachio | it is allways done | 20:57 |
niemeyer | That's what I mean too | 20:57 |
cachio | ahh | 20:57 |
cachio | sorry | 20:57 |
niemeyer | The -f flag is irrelevant | 20:57 |
niemeyer | Sounds like just shooting stuff on the wall to see what sticks | 20:58 |
cachio | niemeyer, you mean that -f make it reboots slower | 20:58 |
niemeyer | cachio: step zero is understanding *why* it's not working.. | 20:58 |
niemeyer | cachio: No, I mean this is one of many possibilities.. we need to not guess and actually understand the real reason | 20:59 |
cachio | niemeyer, ok | 20:59 |
niemeyer | cachio: If the machine is rebooting, the problem is much easier to debug | 20:59 |
cachio | niemeyer, ok | 21:00 |
cachio | I'll work on this | 21:01 |
niemeyer | cachio: Thanks! | 21:01 |
cachio | niemeyer, to you | 21:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!