[02:09] <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:10] <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:11] <rbasak> The underlying problem I'm trying to solve is: https://pastebin.ubuntu.com/p/7yknPXQG7G/
[02:12] <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:15] <mup> PR snapd#6316 opened: tests: skip snapd snap on reser for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6316>
[07:03] <mborzecki> morning
[07:35] <zyga> Hello
[07:36] <zyga> I will be in the office shortly, just need to take the dog out
[07:37] <mborzecki> zyga: hey
[07:47] <zyga> re :)
[07:47] <zyga> hey hey
[07:47] <zyga> I feel *much* better than yesterday
[07:48] <zyga> mborzecki: was the sky overcast last night around your place?
[07:49] <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:53] <mborzecki> zyga: or super cold weather
[07:58] <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:59] <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> heyas
[07:59] <zyga> this means that core snap is empty
[08:00] <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:01] <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:02] <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:03] <zyga> (and it is not getdents)
[08:03] <pstolowski> zyga: :D
[08:08] <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:09] <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:11] <zyga> mborzecki: tweeting with a rant actually solved a problem :)
[08:16] <mborzecki> zyga: nice
[08:24] <zyga> FK
[08:25] <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:31] <zyga> mborzecki: release page updated
[08:32] <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:33] <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:34] <zyga> dunno
[08:35] <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:36] <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:37] <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:38] <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:46] <zyga> pedronis: that was not my point :)
[09:00] <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:01] <mborzecki> zyga: just on .3?
[09:01] <zyga> yep
[09:02] <zyga> mborzecki: happens each time
[09:03] <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:04] <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:05] <zyga> mborzecki: note, it happens in osc build
[09:05] <zyga> I don't see this in "go test ./..."
[09:06] <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:07] <zyga> hmmmm
[09:08] <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:09] <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:10] <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:14] <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:16] <pstolowski> uhm
[09:19] <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:20] <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:21] <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:22] <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:37] <pedronis> pstolowski: zyga: we already have a test like that somewhere else
[09:37] <pedronis> we don't skip generically
[09:39] <pedronis> pstolowski: see TestDoRequestSerialErrorsOnNoHost  in devicestate_test.go
[09:40] <pedronis> zyga: ^
[09:40] <zyga> looking
[09:40] <pstolowski> ah!
[09:40] <pstolowski> pedronis: nice
[09:40] <zyga> yep
[09:40] <zyga> +1
[09:41] <zyga> though I would really argue those are not unit tests
[09:41] <zyga> but camouflaged integration tests
[09:45] <pedronis> zyga:  we have some _test.go files with integration tests (of various kind), yes
[09:46] <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:47] <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:48] <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:50] <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:51] <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:52] <zyga> I did see this a few  times
[09:52] <zyga> let me think
[09:53] <zyga> unit test failure https://www.irccloud.com/pastebin/5TCsf2ae/
[09:55] <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:56] <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:57] <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: ^^
[10:01] <pstolowski> pedronis: i'll work on that snapctl get bug if that's ok?
[10:02] <pedronis> pstolowski: are you blocked on hot plug?
[10:03] <pstolowski> pedronis: 2 hotplug PRs need reviews (i'm deconflicting one of them atm)
[10:04] <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:05] <pstolowski> pedronis: that's all implemented in the big hotplug branch already (i'm not deconflicting it until the smaller ones land though)
[10:06] <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:07] <pedronis> ok
[10:08] <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:09] <pstolowski> pedronis: ah, and the gadget-declared slots discussed last week
[10:10] <pedronis> yes
[10:13]  * 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:14] <Chipaca> pedronis: I suspect this bit won't pass review: https://pastebin.ubuntu.com/p/QDbNMmmWh2/
[10:15] <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:16] <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:17] <Chipaca> bonus :-)
[10:17] <Chipaca> anyway, walk to clear head, bbiab
[10:20] <mup> PR snapd#6318 opened: release-tools: display self-help <Created by zyga> <https://github.com/snapcore/snapd/pull/6318>
[10:23]  * pstolowski gets xmax haircut, bbl
[10:25] <pstolowski> *xmas even
[10:36] <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:37] <pedronis> mborzecki: yes
[10:37] <mborzecki> zyga: any clue what that might be?
[10:39] <pedronis> mborzecki: are we removing /dev somehow?
[10:45] <mborzecki> pedronis: not that i know of
[10:45] <pedronis> or is some cgroup handling problem?
[10:49] <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:50] <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:51] <zyga> pedronis: hmmmm, let me think
[10:51] <zyga> I don’t mind reverting that now
[10:52] <zyga> I have enough state to work locally
[10:52] <pedronis> given where we have are timewise, I would revert it
[10:53] <pedronis> s/have//
[10:53] <pedronis> mborzecki: can you prepare a revert?
[10:53] <mborzecki> pedronis: ok, let's do this
[10:55] <pedronis> mborzecki: if the revert itself fails that way we learn something either way
[11:02] <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:09] <pedronis> let's see how it goes
[11:10] <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:17] <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:18] <Chipaca> popey: couldn't risk it
[11:25] <ogra> popey, what hardware ?
[11:26] <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:27] <popey> I would appreciate someone else confirming this. I spent hours on this last night and it should not be this hard.
[11:28] <ogra> it is quite a while ago that i tested pulse (about  year) and there it used to work ... something might have changed
[11:29] <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:30] <popey> which also doesnt work on core
[11:30] <Chipaca> popey: I can confirm the DENIEDs
[11:31] <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:32] <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:33]  * 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:35] <Chipaca> popey: so
[11:35] <Chipaca> popey: I installed pulseaudio
[11:35] <Chipaca> popey: and mpv
[11:36] <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:37] <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:38] <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:39] <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:40] <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:42] <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:43] <popey> paplay farts that it needs root
[11:43] <popey> "This script must be run as root"
[11:43] <niemeyer> Heya
[11:44] <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:45] <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:46] <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:47] <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:48] <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:51] <ogra> popey, btw, you could take a look at my video-kiosk snap ...
[11:52] <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:53] <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:54] <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:55] <ogra> well, that sounds like a bug ... with confinement or confinement integration
[11:56] <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:59] <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
[12:00] <mborzecki> a revision which uses core18 as base is somewhat better
[12:00] <zyga> mborzecki: we need to implement better driver support
[12:01] <zyga> mborzecki: it would help if core{16,} got updated driver stack but that's probably unlikely
[12:02] <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:05] <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:06] <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:10] <pedronis> it cannot make things worse
[12:23] <Chipaca> pedronis: https://pastebin.ubuntu.com/p/mKhGh4rGcr/ with conflict resolution back on \o/
[12:24]  * Chipaca ~> lunch
[12:26] <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:27] <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:31] <pedronis> afaict it was only for interface hooks
[12:32] <pstolowski> zyga, Chipaca: we did, but for interface hooks only
[12:32] <zyga> mmm
[12:32] <zyga> thanks
[12:33] <pstolowski> since these had the most impact (4 extra task for every connect)
[12:34] <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:35] <pedronis> zyga: I expect you need some combination of tests and bad restore
[12:35] <pedronis> if the casue was really that PR
[12:36] <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:38] <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:41] <pedronis> pstolowski: what's the status of this: https://trello.com/c/KCMZcd5F/74-fix-for-kr-pretty-diff-memleak-affecting-our-tests
[12:57] <sergiusens> rbasak I am off until Thursday. An email will certainly remind me to get back to you.
[12:58] <pedronis> zyga: master failed but on a pull and the mount bug, not anymore on the /dev issue
[12:59] <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
[13:03] <pstolowski> pedronis: radio silence from upstream; he has a bunch of PRs pending reviews..
[13:05] <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:13] <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:15] <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:18] <Facu> ogra, can I do that with a whole dir? /snap/foobar/current/lib/python3.5/site-packages/foobar/
[13:19] <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:20] <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:21] <Chipaca> the new-style build-in-a-vm snapcraft doesn't leave a 'prime' :-/
[13:21] <ogra> well, if you have the source :)
[13:22] <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:24] <pedronis> Facu: you can do snap try --classic
[13:27] <Facu> pedronis, worked great, thanks!
[13:28] <pedronis> np
[13:29] <Chipaca> Facu: snap try --dwim
[13:30] <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:31] <zyga> no snapcraft
[13:31] <zyga> ergo
[13:31] <zyga> sucks :/
[13:32] <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:33] <mborzecki> zyga: yes, that should be fixed in edge i think
[13:34] <zyga> ah, perfect
[13:36] <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:57] <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>
[14:00] <cachio> pedronis, it is ok, it is not  high prioriry
[14:01] <pedronis> zyga: are you joining or skipping?
[14:01] <zyga> diddledan: hello
[14:01] <zyga> oh
[14:01] <zyga> joining!
[14:03] <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:04] <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:05] <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:06] <zyga> no changes in that area
[14:07] <diddledan> or maybe I can't?
[14:07] <diddledan> weirder and weirder
[14:09] <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:10] <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:11] <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:12] <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:13] <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:14] <zyga> I still think there was more to it
[14:14] <zyga> not that specific revision of core
[14:14] <zyga> but perhaps?
[14:15] <diddledan> yeah, I can't reproduce it after reverting core18
[14:16] <Chipaca> Facu: snap refresh --amend thesnap
[14:26] <zyga> diddledan: thank you for checking
[14:26] <Facu> Chipaca, wonderful, thanks!
[14:38] <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:39] <zyga> we need to measure leaks
[14:39] <zyga> we leak a lot of stuff
[14:40] <mborzecki> zyga: hm simple df -h in debug could be useful
[14:43] <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:44] <mborzecki> zyga: iff we see a 4k /tmp we'll know :P
[14:49] <zyga> 4k is too small
[14:50] <mup> PR snapd#6321 opened: spread: show free space in debug output <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6321>
[14:52] <mborzecki> zyga: ^^
[15:02] <Son_Goku> mborzecki, I'm building 2.36.3 now
[15:06] <zyga> Son_Goku: thank you :)
[15:06] <Son_Goku> ugh, everything is a bloody mess right now
[15:08] <mborzecki> Son_Goku: yay!
[15:09] <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:12] <pstolowski> cachio: that issue with nightly test you pasted during the standup, was it against 2.36.2?
[15:18] <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:19] <cachio> pstolowski, it is called install-snaps
[15:21] <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:22] <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:23] <cachio> pstolowski, you can try running this test with -debug
[15:23] <cachio> not sure if it is 100% reproduceable
[15:24] <zyga> I'm in a debug session, test failed on random network fluke
[15:24] <zyga> but maybe not really random
[15:25] <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:26] <zyga> we leaked iptables across tests
[15:27] <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:30] <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:31] <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:32] <pstolowski> zyga: econnreset is the other test where we have iptables
[15:32] <pstolowski> nah, it has different rules as well
[15:34] <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:37] <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:38] <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:39] <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:40] <pstolowski> zyga: i don't see the dns rule from s-n-errors test there?
[15:41] <zyga> REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
[15:41] <zyga> isn't that it?
[15:42] <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:43] <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:48] <mborzecki> Son_Goku: seems to work fine, +1 karma :)
[15:48] <Son_Goku> excellent
[15:58] <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>
[16:00] <cachio> pedronis, preparing lunch
[16:00] <cachio> pedronis, core has been promoted to stable
[16:01] <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:02] <Wimpress> Afternoon snapd team :-)
[16:03]  * 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:04] <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:05] <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:06] <pstolowski> Wimpress: did you manage to find a reproducer for the issue with snap remove taking forever?
[16:07] <Wimpress> @sergiusens When will Snapcraft grow support for this capability?
[16:07] <Wimpress> pstolowski: I think so. Let me just comfirm the steps.
[16:09] <Wimpress> Typically, I can't reproduce the issue now.
[16:09] <Wimpress> pedronis: What is the ETA for snapd 2.37?
[16:12] <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:13] <niemeyer> cachio: The proposed reboot command looks a bit suspect
[16:16] <niemeyer> cachio: The exit on background doesn't do much.. it should be equivalent to doing nothing
[16:17] <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:18] <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:30] <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:31] <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:32] <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:56] <cachio> niemeyer, sure
[16:56] <cachio> I'll split it
[17:34] <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:35] <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:36] <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:37] <zyga> fingers crossed, I really want to understand that test failure
[17:41] <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:42] <ogra> *HDMI
[17:43] <popey> pactl list cards lists none
[17:45] <popey> on raspbian, it lists one
[17:46] <ogra> hmm, what gadget is that ?
[17:47] <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:48] <ogra> ogra@localhost:~$ cat /proc/asound/cards
[17:48] <ogra>  0 [ALSA           ]: bcm2835 - bcm2835 ALSA
[17:48] <ogra>                       bcm2835 ALSA
[17:49] <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:50] <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:51] <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:52] <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:53] <popey> dtparam=audio=on  in config.txt, right?
[17:53] <ogra> yeah
[17:56] <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:57] <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:58] <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:59] <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
[18:00] <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:23] <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>
[19:06] <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:08] <zyga> The file "-" has text "core (bogus/stable) 16-2.36.3+git1063.bbf4a49 from Canonical✓ refreshed"
[19:09] <zyga> in any case that test is borken
[19:33] <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:34] <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:35] <smoser> any ideas?
[19:35] <smoser> also nit pick... there are two entries for 'GNU General Public License v2.0 or later'
[19:56] <cachio> niemeyer, update done
[20:01] <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:02] <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:05] <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:08] <cachio> niemeyer, the command reboot was not returning
[20:08] <cachio> is not returning
[20:08] <cachio> so ssh command is getting stuck
[20:09] <cachio> with the & we make sure the ssh finished the execution
[20:12] <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:20] <cachio> niemeyer,  I also added the & to make it work on devices
[20:21] <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:24] <pedronis> I see various PR failing with it
[20:26] <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:29] <pedronis> I don't see any recent change that would correlate with that failing
[20:31] <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:41] <pedronis> zyga: I think I know why it's failing
[20:41] <zyga> oh, do tell please
[20:42] <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:43] <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:44] <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:50] <cachio> niemeyer, it doesn't
[20:50] <cachio> it failed with debian
[20:50] <cachio> just with -f it fails in the boards
[20:51] <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:52] <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:53] <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:56] <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:57] <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:58] <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:59] <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
[21:00] <cachio> niemeyer, ok
[21:01] <cachio> I'll work on this
[21:01] <niemeyer> cachio: Thanks!
[21:01] <cachio> niemeyer, to you


[15:46] <paultag> jcastro: yo man, got your reddit comment last night, do you mean filter based on where the stuff's coming from or what?


[22:36] <redfive> hi, anyone around who's familiar with line 6 products?
[22:59] <redfive> line 6, anyone? D:


[11:34] <SimonK> hi there :), anyone here who can tell me, how to check out a (mainline-) kernel?
[11:36] <SimonK> It seems like kernel 3.9.* has only candidates up to "v3.9.7", but in the kernel-ppa is a "v3.9.11-saucy" version ("git checkout v3.9.11" says that git dosn't know this version)
[11:39] <smartboyhw> SimonK, quite certain that 3.9.11 is a vaild version
[11:40] <SimonK> hm, just to be on the safe side: if i am able to check out 3.10-rc1, that means 3.9.11 should be in my git-tree?
[11:41] <SimonK> the highest number i can find is "2ea699d98cd6f9e9b813c24542d581dedacdc659 refs/tags/v3.11-rc6"
[11:41] <smartboyhw> SimonK, you checked out http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=summary right?
[11:42] <smartboyhw> Well, "master" only bases on Linus' tree
[11:42] <smartboyhw> i.e. does not include any stable releases from upstream Linux
[11:45] <smartboyhw> SimonK, mainline actually means https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/ (for stable kernels)
[11:45] <SimonK> I cloned "git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git"
[11:46] <SimonK> kernel.org didn't let me clone (it stopped at 13% every time, probably because of my dsl-speed)
[11:47] <SimonK> well, then i do a bisect between 3.9.7 and 3.10-rc1.
[11:48] <smartboyhw> SimonK, ubuntu-saucy != mainline.............
[11:49] <SimonK> so I have to clone from kernel.org? Well, thats unfortunate.
[12:40] <hggdh> SimonK, smartboyhw: the Ubuntu kernel versions are slightly different from upstream git (given that we usually start with the devel kernels)
[12:40] <hggdh> an easy way to find that out is by looking at /proc/version_signature -- there you will see the Ubuntu version and the upstream version
[12:41] <SimonK> I see... I'm trying to download from kernel.org at the moment *fingers crossed*
[12:41] <SimonK> I'll never understand why you have to restart a cloning if you abrot it bevore :/
[12:47] <hggdh> we do have mainline kernels build for Ubuntu
[12:47] <hggdh> SimonK: see https://wiki.ubuntu.com/Kernel/MainlineBuilds
[12:49] <SimonK> Yes, I know which version is the last good (3.9.11) and the first bad (3.10-rc1) my problem now just comes down to bad internet-connection, git cloning from *.kernel.org is aborting every time i tried so far
[18:02] <TheLordOfTime> anyone able to tell me what happens if an SRU goes to verification-failed ?
[18:06] <hggdh> TheLordOfTime: the package should be removed from the -proposed pocket, and the bug should be put back into triaged
[18:06] <TheLordOfTime> hggdh: should i let sponsors do those changes, or can I bump it back to Triaged myself?
[18:06] <TheLordOfTime> because E: Bug 1206878 VERIFICATIONFAILED because E: New Bug
[18:06] <ubot2> Launchpad bug 1206878 in nginx (Ubuntu Precise) "[SRU] Configuration should be purged only in nginx-common" [Critical,Fix committed] https://launchpad.net/bugs/1206878
[18:07] <hggdh> TheLordOfTime: you can bump it back to triaged yourself; removal from the -proposed will have to be done by someone with archive authority
[18:08] <TheLordOfTime> hggdh: done, now, if I were to try and fix this, and actually fix the newly-introduced-bug from what's in 1.1.19-1ubuntu0.3, do I bump the version to -1ubuntu0.4, or...?
[18:08] <TheLordOfTime> (this is the first patch I've actually had fail o.O)
[18:10] <hggdh> good question... I think it would remain 0.3, but this might conflict with an already-uploaded source.
[18:11] <TheLordOfTime> so... i should wait until I can go poke someone, like bdmurray who actually sponsored the upload, to explain what to do in this case?
[18:11] <hggdh> yeah. Or -motu, or -devel, or -packaging
[18:11] <TheLordOfTime> -MOTU's been nonresponsive
[18:11] <TheLordOfTime> hence me asking here about the verification-failed thing
[18:11] <TheLordOfTime> -devel will be my next target probably.
[18:11] <TheLordOfTime> unless someone wakes up on the MOTUs
[18:11] <hggdh> yeah, I saw your comment in -servers
[18:12]  * hggdh goes afk for a bit
[18:21] <bdmurray> -1ubuntu0.4 because the previous version of the package already existed in the archive
[18:21] <bdmurray> TheLordOfTime:, hggdh ^^
[18:22] <TheLordOfTime> bdmurray: so, I have the -1ubuntu0.3 package I pulled from proposed with dget, do i just add code modifications to that, add a new changelog entry for -1ubuntu0.4, and attach another debdiff, or do i start from -1ubuntu0.2, do changes, and then new changelog -1ubuntu0.4 ?
[18:23] <TheLordOfTime> basically, which package do I base the updated debdiff from.
[18:24] <bdmurray> -1ubuntu0.3
[18:25] <TheLordOfTime> okay, so work off what's already in proposed, fix the newly-introduced-bug, test, and then attach the debdiff...
[18:25] <TheLordOfTime> cool.
[18:25] <TheLordOfTime> (this was the first patch that has been for nginx that verification-failed o.O)
[18:25] <TheLordOfTime> (at least, that i've worked on)
[18:27] <hggdh> bdmurray: yeah, I wondered about an already-uploaded debdiff. So the process is base on the failed fix, and add the fix's fix
[18:31] <TheLordOfTime> bdmurray: for -1ubuntu0.4, though, do I also need to put in (closes LP: #bugnumber) that was referenced in -1ubuntu0.3 ?
[18:32] <bdmurray> TheLordOfTime: yes
[18:32] <TheLordOfTime> ok
[19:58] <TheLordOfTime> bdmurray: if you're not busy, can you perhaps guide me to a resolution of a bug issue?  I'm stuck between Invalid/Wishlist and actually poking someone in a position to make a decisive answer on the bug, and that plus the emails I"m getting about it are driving me to the point of telling everyone to die in a fire... o.o
[20:00] <bdmurray> TheLordOfTime: I'm not terribly involved in anything at the moment
[20:00] <TheLordOfTime> hggdh: you know the bug, i briefly discussed it here
[20:00] <TheLordOfTime> bdmurray: okay, one moment
[20:00] <TheLordOfTime> (btw, i'll need you to also sponsor a new debdiff for 1206878, that fixes the issues)
[20:00] <TheLordOfTime> bdmurray: this is the one driving me insane: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1170586
[20:00] <ubot2> Launchpad bug 1170586 in nginx (Ubuntu) "Naxsi package lacking Stub Status" [Undecided,Incomplete]
[20:01] <TheLordOfTime> bdmurray: it's stuck between Invalid/Wishlist (because although the code for that module exists, its rules file never included it)...
[20:01] <TheLordOfTime> and trying to figure out whether there's any way to get an approved change to the package to build the module's code, as it exists in the 1.1.19 source
[20:02] <TheLordOfTime> quantal and later all have the module's code compiled in the rules
[20:02] <TheLordOfTime> as it stands i'm leaving it Incomplete/Undecided until someone more... senior... can make a decision on how to proceed
[20:03] <TheLordOfTime> the whole initial issue was based on research the OP found that pointed at 1.2.1 (on Debian's wiki page)
[20:03] <TheLordOfTime> comment 4, i narrowed the criterion for the issue to be specific to the package, and not what debian's saying, but nginx's debian maintainers can't give me a clear answer
[20:03] <TheLordOfTime> so... this is now in the point where someone wants the thing, but activating it isn't SRU worthy
[20:04] <TheLordOfTime> and I don't see a backport being relevant in this case either because they want something that wasn't activated in the rules, but is actually in the source code.
[20:04] <TheLordOfTime> so... i'm stuck :/
[20:06] <TheLordOfTime> bdmurray: hggdh: anyone else: i welcome any guidance on how to tackle this to get everyone off my case about this... o.o
[20:10] <bdmurray> TheLordOfTime: everyone?  I see only one person affected by it.
[20:11] <TheLordOfTime> bdmurray: direct emails to me are causing the stress
[20:11] <TheLordOfTime> not on the bug
[20:11] <TheLordOfTime> either way, the bug is stuck in triager limbo until someone can figure it out
[20:11] <TheLordOfTime> on the one hand, activating the module is as simple as one line of code, on the other, doing that wouldn't fit into SRU or backport
[20:12] <TheLordOfTime> so... kinda stuck
[20:12] <TheLordOfTime> (part of me wants to Invalid that bug but... i'm in too high a stress level to do so sanely)
[20:17] <TheLordOfTime> bdmurray: on a more sane, not-as-stressful note, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1206878 has a new debdiff ready for sponsoring
[20:17] <ubot2> Launchpad bug 1206878 in nginx (Ubuntu Precise) "[SRU] Configuration should be purged only in nginx-common" [Critical,Triaged]
[20:17] <TheLordOfTime> that apparently fixes the issue introduced in 1.1.19-1ubuntu0.3 (that was in -proposed)
[20:18] <TheLordOfTime> at least, from my testing with the testcases specified, it works as expected, and doesn't trigger installation or purge errors
[20:18] <bdmurray> I'd prefer no to sponsor that since I'll may be the SRU team member reviewing it.
[20:18] <bdmurray> Do you know what the patch for the other bug would look like?
[20:18] <TheLordOfTime> okay, i'll have to go find a sponsor then...
[20:19] <TheLordOfTime> bdmurray: you mean the one that's driving me to wanting to tell people to burn?
[20:19] <TheLordOfTime> bdmurray: i can probably slap up an example patch in a few minutes
[20:19] <TheLordOfTime> but for all intents and purposes... Bug 1206878 is a much higher priority than 1170586
[20:19] <ubot2> Launchpad bug 1206878 in nginx (Ubuntu Precise) "[SRU] Configuration should be purged only in nginx-common" [Critical,Triaged] https://launchpad.net/bugs/1206878
[20:19] <TheLordOfTime> because config removal on a non-common-files purge is just bad.
[20:25] <TheLordOfTime> bdmurray: a diff for LP Bug 1170586 would look something along the lines of this: http://paste.ubuntu.com/6189724/
[20:25] <ubot2> Launchpad bug 1170586 in nginx (Ubuntu) "Naxsi package lacking Stub Status" [Undecided,Incomplete] https://launchpad.net/bugs/1170586
[20:25] <TheLordOfTime> (note because of convenience, I built that off of the -1ubuntu0.4 package I uploaded a debdiff for which fixes 1206878)
[20:26] <TheLordOfTime> note i tend to testbuild before I submit a debdiff...
[20:26] <TheLordOfTime> so unless someone's actually going to approve adding in that line to build the module, i'm not even going to test-build
[20:26] <TheLordOfTime> (although in theory it should build)
[20:27] <bdmurray> and I think that fits in this part of the "When" for SRUs
[20:27] <bdmurray> Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
[20:28] <TheLordOfTime> bdmurray: then, if i were to upload a debdiff for that and propose it for SRU under that criterion...
[20:28] <bdmurray> but I'm pretty sure I'm still the new guy on that team
[20:28] <TheLordOfTime> then perhaps someone would look at it?
[20:28] <TheLordOfTime> ehh, where are the SRU team anyways
[20:29] <TheLordOfTime> or, rather, would you mind poking them and seeing what they say :P
[20:29]  * TheLordOfTime yawns
[20:29] <TheLordOfTime> i need to go beat my head against the wall for a bit
[20:29] <TheLordOfTime> but the good news is that annoying bug that removes a user's configs when nginx-light or nginx-full or nginx-naxsi or nginx-extras is purged is (hopefully) in the queue to fix it
[20:30] <TheLordOfTime> bdmurray: last question, do i leave the verification-failed tag on 1206878 since i uploaded a new debdiff, and wait for someone from sponsors and SRU team to take a look?
[20:32] <bdmurray> TheLordOfTime: yes, because we don't want it showing up as verified on the pending sru report
[20:35] <TheLordOfTime> okay, done.  if sponsors need to be resubscribed, can you do that for me, bdmurray?  i'm going to go take a warm shower to try and calm down... for some reason that's relaxing... *shrugs*


[09:12] <ryoohki> i'm trying to use my laptop to share my internet on wlan0 with eth0.  many howto and such recommend using firestarter and that's what i've done but it still won't work
[09:14] <ryoohki> the device is connecting, dhcp is working( i can see it with tcpdump, i ran "sysctl -w net.ipv4.ip_forward=1", it should work as far as i know.
[09:14] <ryoohki> i'm guess i may need to set up dns-masq or a nat rule in iptalbes


[13:53] <tjaalton> hmm, dragging a pdf image with evince crashes compiz
[20:37] <soren> tjaalton: Don't do that then.
[20:37] <soren> tjaalton: Troublemaker.
[21:32] <tjaalton> soren: :P


[05:27] <teamxar> hi all
[05:27] <teamxar> does ubuntu have a 2.6 kernel option when putting in the live cd?
[05:31] <teamxar> i see the lights are on but nobody's home here