[02:09] 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:10] 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:11] The underlying problem I'm trying to solve is: https://pastebin.ubuntu.com/p/7yknPXQG7G/ [02:12] Upstream aren't sure that it's correct to include an == for setuptools in requirements.txt. [02:12] 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:15] PR snapd#6316 opened: tests: skip snapd snap on reser for core systems [07:03] morning [07:35] Hello [07:36] I will be in the office shortly, just need to take the dog out [07:37] zyga: hey [07:47] re :) [07:47] hey hey [07:47] I feel *much* better than yesterday [07:48] mborzecki: was the sky overcast last night around your place? [07:49] zyga: idk, didn't pay much attention, probably yes [07:49] I want to take a chance to see the comet [07:49] but lights and clouds make it hard to do so :/ [07:49] zyga: hah, the worst time of year if you ask me [07:49] right? [07:49] mid summer would be awesome [07:53] zyga: or super cold weather [07:58] mborzecki: any highlights from yesterday? [07:58] the test suite is givig headaches [07:58] zyga: couldn't even get https://github.com/snapcore/snapd/pull/6314 to land [07:58] PR #6314: cmd/snap-discard-ns: fix umount(2) typo [07:59] yeah, I'm looking at taht now [07:59] but that's hardly new problem :/ [07:59] and it's a damn typo [07:59] + test-snapd-udev-input-subsystem.slot [07:59] cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_tdsBnR//dev: No such file or directory === pstolowski|afk is now known as pstolowski [07:59] heyas [07:59] this means that core snap is empty [08:00] which probably signifies another bug in test restore somewhere [08:00] eh [08:00] pstolowski: hey [08:00] pstolowski: did you see the comet? [08:00] 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] uh? [08:00] :| [08:00] new vega firmware? [08:00] zyga: oh, no; did you? [08:00] maybe it requires new kernel too [08:01] pstolowski: no, sky is totally covered with clouds [08:01] pstolowski: but I want to [08:01] zyga: i'm at 4.19.9 [08:01] pstolowski: I learned a thing yesterday [08:01] zyga: tought the kernel update was botched, but reverting firmware was enough to make it work again [08:02] 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] :) [08:03] (and it is not getdents) [08:03] zyga: :D [08:08] zyga: can you upload the source tarballs to github releases page? [08:08] mborzecki: yeah, I'm looking into that now [08:08] zyga: thanks! [08:09] mborzecki: btw, some good stuff over weekend [08:09] I, by accident, got the attention of the suse golang stack maintainer [08:09] and they will remove the global environment variables [08:09] which means we will not only get fixed go in suse [08:09] but have a simple way out of the current problem [08:09] (just unset the damn GO* mess) [08:11] mborzecki: tweeting with a rant actually solved a problem :) [08:16] zyga: nice [08:24] FK [08:25] firefox ate my release page [08:25] f***** [08:25] went "back" [08:25] moronic feature [08:25] nom nom nom [08:31] mborzecki: release page updated [08:32] I'll do opensuse next [08:32] then look at bugfixes for layout bug [08:32] I would love if we did 0 features and made the test suite stable [08:32] any ideas apply [08:32] zyga: thanks [08:33] 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] uhh [08:34] dunno [08:35] zyga: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/backend/link.go#L62..L94 i think this is wrong [08:35] I low how we ship TODO/XXX but discuss ad infinitum about variable names [08:36] mborzecki: can you walk me through your thought process [08:36] zyga: it's using CommandFromCore, which does mountDir+core/current, but the symlink is updated only at the end [08:36] zyga: so it's trying to call fc-cache-v6 from the old 'current' of the core snap [08:37] indeed! [08:37] uh [08:37] please file a bug [08:37] zyga: only visible when switching between !edge & edge [08:38] zyga: I don't know of anything that isn't tiny that doesn't ship with TODOs [08:38] zyga: better yet, i'll open a PR :P [08:46] pedronis: that was not my point :) [09:00] pstolowski: is this expected? 2.36.3 https://www.irccloud.com/pastebin/Yxx3gjEC/ [09:00] PR snapd#6314 closed: cmd/snap-discard-ns: fix umount(2) typo [09:00] PR snapd#6316 closed: tests: skip snapd snap on reset for core systems [09:01] zyga: just on .3? [09:01] yep [09:02] mborzecki: happens each time [09:03] zyga: hm don't see this here [09:03] "osc build" [09:03] 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] yes [09:03] each time [09:03] interesting [09:03] zyga: let me look [09:04] mborzecki: I sent this to obs [09:04] it will fail there [09:04] zyga: go version? [09:04] https://build.opensuse.org/package/show/system:snappy/snapd [09:04] 1.11.2 [09:05] mborzecki: note, it happens in osc build [09:05] I don't see this in "go test ./..." [09:06] zyga: wasn't there something with network being disabled in obs builds and that causing some werid issues? [09:06] I don't know [09:06] presumably maybe so [09:06] zyga: i recall something like this when you were updating snapd with that other opensuse community guy [09:07] hmmmm [09:08] http://nonexistingserver909123.com/ [09:08] zyga: i'm looking at this test right now. running in httputil/ tests in a loop, so far no failure, so perhaps flaky? [09:09] pstolowski: no [09:09] perhaps flaky assumption [09:09] it fails each time in obs build [09:09] https://build.opensuse.org/package/show/system:snappy/snapd [09:10] we are assuming a specific answer for a domain name [09:10] the problem is that the test can run in arbitrary environment, including one with proxies [09:10] not a unit test [09:10] we test the system [09:14] zyga: i see. also looking at comments in e3db0504f5b28029e4a253614782244150ebeb50, go versions introduce variances here... [09:14] pstolowski: https://build.opensuse.org/package/show/system:snappy/snapd failed across all suse versions [09:16] uhm [09:19] zyga: i think we should c.Skip this test then for the time being, and try come up with a better one [09:19] pstolowski: agreed [09:20] pstolowski: perhaps we should spawn our own server and return the expected error code [09:20] otherwise we can really see anything the system crafts [09:20] +1 [09:20] zyga: shall i prep quick PR against 2.36? [09:21] pstolowski: I can cherry pick as well, thank you for looking [09:21] if you can, please try to improve the test [09:21] zyga: ok [09:21] sorry, that came out confusing and ambiguous [09:21] zyga: ok, for master then [09:21] I mean I will do the skip [09:21] ah ok [09:21] and you can look at changing the test properly for master [09:21] I will carry a distro patch [09:22] zyga: perhaps c.Skip conditional on suse? [09:22] pstolowski: no, I mean I will just skip this unconditionally in distro packaging [09:22] we should not special case any distribution here [09:37] pstolowski: zyga: we already have a test like that somewhere else [09:37] we don't skip generically [09:39] pstolowski: see TestDoRequestSerialErrorsOnNoHost in devicestate_test.go [09:40] zyga: ^ [09:40] looking [09:40] ah! [09:40] pedronis: nice [09:40] yep [09:40] +1 [09:41] though I would really argue those are not unit tests [09:41] but camouflaged integration tests [09:45] zyga: we have some _test.go files with integration tests (of various kind), yes [09:46] uh, heads up: I need to go and do paperwork (today and tomorrow) for the car that has finally arrived [09:46] perhaps I can skip today [09:46] I'll learn more soon [09:47] zyga: heh, two full days of papework? that sounds annoying [09:47] no, just two instances [09:47] insurance today [09:47] and final pickup tomorrow [09:48] I just need to be there to sign the papers [09:48] though we're trying to do the insurance remotely to avoid going there for really silly reason [09:50] 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] zyga: ^ any idea? [09:51] yes [09:51] so this fails if either of the things happen [09:51] yeah i just see it as well [09:51] a /tmp/snap.rootfs_niWil9/dev (which we make ourselves just prior to that call) doesn't eixst [09:51] or if /dev doesn't exist [09:52] I did see this a few times [09:52] let me think [09:53] unit test failure https://www.irccloud.com/pastebin/5TCsf2ae/ [09:55] btw were we sure this was solid now: https://github.com/snapcore/snapd/pull/6217 [09:55] PR #6217: tests: reset snapd state on tests restore [09:56] 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] 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:57] 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] PR snapd#6317 opened: overlord/snapstate/backend: call fontconfig helpers from the new 'current' [09:57] zyga: pedronis: ^^ [10:01] pedronis: i'll work on that snapctl get bug if that's ok? [10:02] pstolowski: are you blocked on hot plug? [10:03] pedronis: 2 hotplug PRs need reviews (i'm deconflicting one of them atm) [10:04] pstolowski: we need to write the main respond to events? handle enumeration? is that right? [10:04] is that work blocked? [10:04] mborzecki: I'm wondering about something [10:04] your patch looks good [10:04] I wonder if we should release an update with this in distro patches [10:05] pedronis: that's all implemented in the big hotplug branch already (i'm not deconflicting it until the smaller ones land though) [10:06] pstolowski: so the idea is to shrink that? and then ask for a review of it? [10:06] pedronis: yes, i'd like the smaller ones to land, otherwise it's constant battle with de-conflicting [10:07] ok [10:08] pedronis: otherwise what remains todo is the open questions (camera etc.), polishing around naming, better summaries (what we discuessed ~yesterday) [10:08] naming = slot naming [10:08] ok, sounds good [10:08] I'll see if I get to review a bit more of those open ones [10:09] pedronis: ah, and the gadget-declared slots discussed last week [10:10] yes [10:13] * Chipaca shakes his fist at conflict detection, and goes for more coffee [10:13] actually scratch that, i'll go for a walk instead [10:13] bbiab [10:14] pedronis: I suspect this bit won't pass review: https://pastebin.ubuntu.com/p/QDbNMmmWh2/ [10:15] Chipaca: indeed, but there is probably something we can [10:15] do [10:15] Chipaca: we can have a quick chat once you are back if it can help [10:16] pedronis: I think I need to generalise doInstall to take a current-change, and pass that in to the conflict checker [10:16] pedronis: hopefully I can do it without breaking all the doInstall tests :-) [10:16] we don't have direct doInstall tests I think [10:17] bonus :-) [10:17] anyway, walk to clear head, bbiab [10:20] PR snapd#6318 opened: release-tools: display self-help [10:23] * pstolowski gets xmax haircut, bbl [10:25] *xmas even [10:36] cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_Nb69ea//dev: No such file or directory [10:36] this thing pops up quite often [10:37] mborzecki: yes [10:37] zyga: any clue what that might be? [10:39] mborzecki: are we removing /dev somehow? [10:45] pedronis: not that i know of [10:45] or is some cgroup handling problem? [10:49] 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:50] \/dev is in core, there's probably one on the host too [10:50] mborzecki: zyga: I fear but it seems it started with landing of #6217 [10:50] PR #6217: tests: reset snapd state on tests restore [10:51] pedronis: hmmmm, let me think [10:51] I don’t mind reverting that now [10:52] I have enough state to work locally [10:52] given where we have are timewise, I would revert it [10:53] s/have// [10:53] mborzecki: can you prepare a revert? [10:53] pedronis: ok, let's do this [10:55] mborzecki: if the revert itself fails that way we learn something either way [11:02] PR snapd#6319 opened: Revert "Merge pull request #6217 from sergiocazzolato/tests-reorg-prepare-restore" [11:09] let's see how it goes [11:10] mborzecki: thx [11:10] Has *anyone* actually got audio (alsa or pulse) working on core? [11:10] I have tried everything i can, and never get any audio over either [11:10] Followed every tip / trick I can, and am losing the will to live [11:17] popey: have some chocolate, go for a walk, play some music or draw something! don't lose your will to live [11:17] :) [11:17] Figure of speech :) [11:18] popey: couldn't risk it [11:25] popey, what hardware ? [11:26] ogra: a pc [11:26] it should definitely work through pulse if you installed the pulse snap and connected all inerfaces properly [11:26] 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] it does not [11:27] I would appreciate someone else confirming this. I spent hours on this last night and it should not be this hard. [11:28] it is quite a while ago that i tested pulse (about year) and there it used to work ... something might have changed [11:29] what was the name of the mixer that mate ships by default as a snap? [11:29] pulsemixer [11:29] 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:30] which also doesnt work on core [11:30] popey: I can confirm the DENIEDs [11:31] popey: 'snap logs pulseaudio' talks about cookies [11:31] popey: hmm! [11:31] popey: I can open the mixer just fine with sudo though [11:32] 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] ogra: when you say 'the pulse snap', is it called "pulseaudio"? [11:33] * Chipaca assumes so [11:33] yes [11:33] https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/pulseaudio/tree/snapcraft.yaml [11:33] k [11:35] popey: so [11:35] popey: I installed pulseaudio [11:35] popey: and mpv [11:36] popey: and copied a music file to /root/snap/mpv/current/ [11:36] popey: and mpv plays it [11:36] I get nothing out the speakers but that might be me sucking at kvm [11:36] using sudo? [11:36] popey: yes [11:36] popey: my user isn't part of the audio group [11:37] that shouldnt matter ... you talk to the daemon, not to the device [11:37] popey: note that the home interface doesn't auto-connect on core [11:38] you should use paplay for testing [11:38] ogra: can that play oggs? [11:38] (comes with the pulseaudio snap( [11:38] i think it should [11:39] 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] (I had to copy the audio file to /root/snap/pulseaudio/current ) [11:39] either that or pulse uses the wrong audio device [11:40] yeah that could be happening [11:40] popey: has this helped, or are you in the same place still? [11:40] core has nothing to select a device as default [11:40] so you might need some pactl tinkering frst [11:42] I cannot get mpv working as user or root either [11:42] Chipaca, kvm should just need "-soundhw ac97" btw [11:42] so no, no further forward [11:42] 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] popey, use paplay [11:43] paplay farts that it needs root [11:43] "This script must be run as root" [11:43] Heya [11:44] popey: how does mpv fail? [11:44] popey: what are you trying :-) [11:44] Are there any failing tests I could look at that would be fixed by spread#70, or is that random? [11:44] PR spread#70: Reboot on backgraound to avoid spread wait for long time [11:45] Chipaca: error opening/initializing the selected video_out (--vo) device. [11:45] is what I get from mpv playing an mp3 in root home folder [11:45] popey, -vo null [11:45] or --vo [11:45] popey: do you have x or something? mine didn't even try [11:45] popey: if you do, you might need to connect the x11 interface [11:45] and equivalently ... --ao pulse [11:46] Chipaca: x11 on core? [11:46] heh [11:46] popey: it exist [11:46] s [11:46] ok, as sudo, mpv can play audio now. yay [11:46] yeah [11:46] if you install some snap that provides it [11:46] popey: i mean: there's an x11 snap somewhere [11:46] Sorry, rewind. [11:46] we added support for running the x server as a snap, on core [11:46] anyway, woo [11:47] User, wants to install a snap that plays audio. [11:47] Currently we have to copy files to a root owned folder, and run as root? [11:47] 1 sec [11:47] popey, well, core is more focused on headless and userless i guess so nobody thought about that before [11:48] popey: i killed my kvm, need to do the dance again to test something [11:48] (all clients you'd normally use would run as daemons as well in that case) [11:51] popey, btw, you could take a look at my video-kiosk snap ... [11:52] it spawns mplayer as a daemon that uses pulse from the pulseaudio snap and offers a web-ui to play files [11:52] I added a check for unmounted base snap [11:52] let's see if I can hit this [11:52] Interesting, thanks ogra. [11:52] I hadn't even considered doing everything as root. [11:53] This gets me further forward, thanks Chipaca / ogra :) [11:53] https://github.com/krpors/wasp [11:53] (and https://github.com/ogra1/video-kiosk-snap) [11:54] It does moan that "failed to create secure directory (/run/user/0/snap.(snapname)/pulse: No such file or directory [11:54] but that seems to not be a massive problem, as audio does play [11:55] well, that sounds like a bug ... with confinement or confinement integration [11:56] sudo pulsemixer also works, as a bonus for fiddling the volumes [11:56] and shows the client connected too. [11:56] * popey is happy [11:56] :) [11:59] so i'm playing with my gl debugging snap on a system with a vega cards, and there's no gl support at all [12:00] a revision which uses core18 as base is somewhat better [12:00] mborzecki: we need to implement better driver support [12:01] mborzecki: it would help if core{16,} got updated driver stack but that's probably unlikely [12:02] zyga: we have a task for opengl and nvidia, but mesa is in bad shape too [12:02] yes [12:02] but doing it for nvidia will open up the path for generic support [12:02] I fully agree though [12:05] mborzecki: zyga: that revert is green [12:05] let's merge it [12:05] or maybe another travis run? [12:05] I wonder if there's some interplay with another branch [12:06] PR snapd#6319 closed: Revert "Merge pull request #6217 from sergiocazzolato/tests-reorg-prepare-restore" [12:06] depending on pressure, we can run this several times more if you prefer [12:10] it cannot make things worse [12:23] pedronis: https://pastebin.ubuntu.com/p/mKhGh4rGcr/ with conflict resolution back on \o/ [12:24] * Chipaca ~> lunch [12:26] 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] if we did, should that just say "running configure hook..." [12:26] https://pastebin.ubuntu.com/p/H6vJfTZRQN/ [12:26] ^ two refreshes with epoch changes in parallel [12:26] zyga: ¯\_(ツ)_/¯ no idea [12:27] pstolowski: ^? [12:27] * Chipaca ~> really lunch [12:27] Chipaca: :) [12:27] zyga: don't think that patch was for all hooks [12:31] afaict it was only for interface hooks [12:32] zyga, Chipaca: we did, but for interface hooks only [12:32] mmm [12:32] thanks [12:33] since these had the most impact (4 extra task for every connect) [12:34] hmm [12:34] the failure with /dev is a bit hard to reproduce [12:34] we can maybe apply this optimization everywhere [12:35] zyga: I expect you need some combination of tests and bad restore [12:35] if the casue was really that PR [12:36] didn't this happen on the PR that was fixing a typo as well? [12:36]