[06:00] <mborzecki> morning
=== chihchun_afk is now known as chihchun
[06:39] <zyga> Hey mborzecki
[06:42] <mborzecki> zyga: hey
[06:42] <mborzecki> zyga: see you've had a productive weekend?
[06:49] <zyga> Busy on my bije
[06:49] <zyga> Bike
[06:49] <zyga> I did 27km yesterday
[06:49] <zyga> Other than that just house work :-)
[06:51] <zyga> How was your weekend
[07:05] <mborzecki> zyga: quite packed, didn't manage to do do anyting i planned, but did plenty of unplanned stuff
[07:09] <mborzecki> zyga: oh, and finally was able to try the kimchi i made, turned out quite good :)
[07:10] <zyga> This week is bug fix week for me
[07:10] <zyga> Plenty of little things to resolve
[07:10] <zyga> I will be in the office before 9:30, I still have one kid to handle and send to school
[07:11] <mborzecki> btw. shouldn't we update the opensuse images to 15.1 now?
[07:12] <zyga> Yeah
[07:15] <mborzecki> again, 2019-03-25 06:27:04 Error preparing google:opensuse-15.0-64 :
[07:15] <mborzecki> it'd gcc now, https://paste.ubuntu.com/p/KRpjVpwndT/ wtf?
[07:16] <mborzecki> we're using zypper in -y, that should be non interactive
[07:16] <mborzecki> maybe we should allow downgrades?
[07:35] <mborzecki> mvo: morning
[07:36] <mvo> hey mborzecki
[07:36] <mborzecki> https://github.com/snapcore/snapd/pull/6644 simple PR <--- should fix opensuse package installs
[07:36] <mborzecki> btw. github triggers don't work anymore?
[07:36] <mvo> mborzecki: looking
[07:36] <mvo> mborzecki: oh?
[07:36] <mvo> mborzecki: how do you mean they don't work anymore? manual trigger? or travis picking up tests on changed prs?
[07:37] <mborzecki> mvo: or just mup_ is silent
[07:38] <mvo> mborzecki: aha, mup probably unhappy
[07:38] <mvo> mup_: hi
[07:39] <mvo> mborzecki: yeah, I think mup_ needs a restart, maybe niemeyer can restart mup for us :)
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[08:04] <pstolowski> morning
[08:05] <mborzecki> pstolowski: hey
[08:11] <zyga> back in the office
[08:11] <zyga> how are you chaps?
[08:14] <mvo> hey zyga and pstolowski
[08:14] <mvo> zyga: good, good!
[08:17] <mborzecki> https://status.opensuse.org/ says there is partial outage of mirroring infra, but it's nto clear what that means exactly
[08:18] <mborzecki> isn't opensuse using metalink now?
[08:19] <mvo> iirc yes
[08:21] <mborzecki> ehh, so zypper times out on gcp, but works just fine locally, either a different mirror, or gcp has some caching behind the scenes
[08:26] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6485/files#r268526837
[08:28] <abeato> mvo, morning! is the fix for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728 in the core snap already?
[08:29] <mborzecki> zyga: adding the file is too simple :)
[08:29] <zyga> mborzecki: wrong coment
[08:29] <zyga> mborzecki: the one at the top
[08:29] <zyga> I'm not talking about the one 20 days ago
[08:29] <mborzecki> ah, i see now
[08:33] <mvo> abeato: it was initially, the backport of #8803 - however when we did a SRU validation we noticed that it breaks (segfaults) under some circumstance, this is an upstream bug and lead to PR#11121 which was a bit harder to backport. I just finished the xenial build and will now run the package against our autopkgtests, if that is successful I will push to the PPA and for the SRU
[08:33] <mvo> abeato: sorry that it takes a bit, its delicate code and the "heart" of systemd (deeep in the job handling) so we are a bit cautious
[08:34] <abeato> mvo, nw, indeed it is something to be very careful about, thanks
[08:34] <mvo> abeato: do you already get asked? I will update the bug with the info here
[08:35] <mborzecki> zyga: hm maybe i should just drop that last commit, too many things to check to find out whether snapd or core is used, extracting directly from source does away with all this
[08:35] <abeato> mvo, not yet, but maybe today they were going to ask, so I wanted to know the current status
[08:35] <zyga> mborzecki: shall we prototype "snap tool snap-{confine,seccomp,discard-ns}
[08:35] <zyga> I would love not to have to source dirs.sh
[08:38] <mvo> abeato: yeah, the updated debdiff for xenial should be in the SRU bug today and I think we will push it to the "edge" core snap for testing
[08:38] <abeato> mvo, nice!
[08:38] <mborzecki> zyga: would that work reliably with core.experimental.snapd-snap?
[08:40] <mvo> abeato: I will also test i386 with spread, for 8803 this was the one where the segv manifested itself
[08:43] <mborzecki> hmmm https://forum.snapcraft.io/t/gadget-snaps-for-mtd-devices/10554
[08:43] <zyga> mborzecki: I saw that
[08:43] <abeato> hm, interesting that it was in i386, was that second issue something provoked by the first change or something completely unrelated?
[08:44] <zyga> afaik not supported :/
[08:44] <mborzecki> zyga: yeah, we had a similar issue with mender, started with just block device support, but then people came asking for mtd
[08:45] <zyga> the only way I would see this work is ubifs or something simialar to map mdt to block devices
[08:45] <mborzecki> mhm
[08:45] <mborzecki> even some of the implicit structure labels would make sense if aplied to volumes
[08:50] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6629#pullrequestreview-218199245
[08:51] <pstolowski> zyga: ty!
[08:51] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6634#issuecomment-476095124
[09:11] <mborzecki> arrrgh Package glibc-32bit-2.26-lp150.11.9.1.x86_64 (openSUSE-Leap-15.0-Update) seems to be corrupted during transfer. Do you want to retry retrieval?
[09:12] <pedronis> pstolowski: hi, I had to contracdict a comment zyga made in 6629
[09:12] <pstolowski> pedronis: just saw it, sure, thanks!
[09:39]  * Chipaca ⇝ more coffee
[09:41]  * tobias_ says hi
[09:51] <thresh> Wimpress, ping rpi & vlc
[09:52] <Wimpress> thresh: o/
[09:53] <Wimpress> Building VLC for the Pi requires two things.
[09:53] <mborzecki> just me or does github feel slow adding comments today?
[09:54] <Wimpress> libraspberry-dev and libraspberry0, only available for armhf.
[09:54] <Wimpress> And the MMAL patches for VLC, which currently only available for VLC 3.0.6
[09:56] <thresh> that's weird it needs patches, since we do ship mmal in the code
[09:56] <thresh> in 3.0, that is, and in 4.0 (the upcoming version)
[09:56] <Wimpress> thresh: Patches are here - https://github.com/RPi-Distro/vlc in debian/patches
[09:57] <thresh> that's a big patch
[09:57] <Wimpress> Yep.
[09:58] <niemeyer> mvo: I'm off today, but will give mup some love when I get back home later today
[09:58] <niemeyer> sorry for the trouble there
[10:00] <mvo> niemeyer: thank you and sorry for bothering you on your day off
[10:01] <niemeyer> mvo: np, thanks for letting me know
[10:08] <dot-tobias> What's the best way to debug snap hooks? I'm adding some commands to a post-install hook and would like to identify thinkos or unexpected errors without the whole “install old rev, build new rev, install new rev, repeat”. I found “snap run --hook”, but since my hook contains “snapctl stop --disable my-snap.my-service”, it complains about “unknown flag: disable”. I presume it's something to do how the hook is called by
[10:08] <dot-tobias>  “snap run”, the same command in my install hook runs without complaints.
[10:11] <Chipaca> dot-tobias: it looks like snapctl stop doesn't have a --disable
[10:12] <Chipaca> the help might be wrong though
[10:12]  * Chipaca looks inside
[10:12] <Chipaca> ah look at that, it does
[10:13] <dot-tobias> Chipaca: That's what I've been wondering as well (comparing “snapctl help” with “snap help stop”), got it from here: https://forum.snapcraft.io/t/support-for-snapctl-stop-start-restart-services/1908/17?u=tobias
[10:13] <dot-tobias> And the disable flag works fine in an install hook; presumably as well in the post-refresh – just throws the error if called with “snap run --hook=post-refresh my-snap”
[10:15] <dot-tobias> Chipaca: And if I interpret https://github.com/snapcore/snapd/pull/5777 correctly, the fix that keeps disabled services disabled after refresh is not in yet, right?
[10:15] <Chipaca> correct
[10:22] <zyga> pstolowski: https://bugs.launchpad.net/snapd/+bug/1606674 is something you could assign to yourself
[10:22] <dot-tobias> Chipaca: As for my initial question, just figured out that I can run “snap try” over an already mounted try snap and it will run like a refresh – including hooks. The snapctl command works fine with --disable.
[10:22] <zyga> pstolowski: the serial port hotplug work seems like good test case for desktop users
[10:23] <Chipaca> dot-tobias: 'run --hook' is internal, AFAIK without the context setting up that's done by snapd before calling it, things will fail
[10:24] <Chipaca> dot-tobias: but yes both 'snap try' and 'snap install --dangerous ./some-local.snap' are actually refreshes
[10:24] <Chipaca> dot-tobias: i mean of a previously installed thing with the same name
[10:28] <dot-tobias> Chipaca: Noted 😊 http://www.addletters.com/pictures/bart-simpson-generator/bart-simpson-generator.php?line=I+won%27t+assume+undocumented+CLI+flags+are+always+public.
[10:29] <Chipaca> dot-tobias: undocumented are probably fine; undocumented and explicitly hidden, are … who knows :-)
[10:29] <Chipaca> OTOH the completion thing doesn't hide hidden flags
[10:29] <Chipaca> … or does it
[10:29]  * Chipaca checks
[10:29] <zyga> mborzecki: perhaps something you can update https://bugs.launchpad.net/snapd/+bug/1750872 :)
[10:30] <mborzecki> haha
[10:30]  * zyga mvo: this is probably fixed now, right? https://bugs.launchpad.net/snapd/+bug/1791182
[10:30] <Chipaca> mborzecki: an excellent opportunity to use "whelm"
[10:33]  * zyga pstolowski: wasn't this fixed already? https://bugs.launchpad.net/snapd/+bug/1806447
[10:33] <thresh> Wimpress, doesnt look mergeable in such a form, I mean thousands lines of code, copied avcodec.c plugin, zero commit logs...
[10:34] <thresh> maybe if split properly, and submitted by someone who cares and who wrote it, we can go forward
[10:34] <mvo> zyga: yes, I think this is fixed
[10:34] <zyga> mvo: should I update it or will you?
[10:38]  * zyga Chipaca: UX bug on snap info: https://bugs.launchpad.net/snappy/+bug/1814971 I believe this should be fixed now?
[10:38]  * zyga pstolowski: I believe this is fixed now, right? https://bugs.launchpad.net/snappy/+bug/1812751
[10:38] <mvo> zyga: please do
[10:38] <zyga> sure
[10:39] <Chipaca> zyga: fixed how?
[10:39] <zyga> Chipaca: isatty vs pipe
[10:39] <zyga> the arrows become ^ when piped
[10:39] <zyga> so ... parsable )
[10:39] <zyga> :)
[10:39] <Chipaca> zyga: that's not what that bug is about
[10:40] <Chipaca> it even mentions carets as equivalently unparsable
[10:40] <zyga> ah, I see now
[10:40] <Chipaca> and I agree, the channel map is not meant to be parseable
[10:40] <Chipaca> (the bug calls them carrots, which I refuse to edit)
[10:40] <MattJ> :)
[10:40] <zyga> thanks, I'll leave it as is
[10:40] <Chipaca> zyga: in fact just last week I was saying "yeah that is not meant to be parseable really"
[10:41] <Chipaca> or words to that effect
[10:41] <pedronis> Chipaca: yes, the only solution to that bug is --format
[10:41] <Chipaca> or talk-to-the-hand^Wsocket
[10:41] <Wimpress> thresh: I was in a meeting.
[10:41] <Chipaca> talking to the socket is really not hard nor unfriendly
[10:42] <Wimpress> thresh: I have good contacts at the Raspberry Pi Foundation. I'll see if I can get them to submit clean PRs upstream.
[10:42] <zyga> we have a loooot of bugs to go through
[10:43] <Chipaca> zyga: https://forum.snapcraft.io/t/use-of-snap-command-line-in-scripts-other-programs/10471/2 fwiw
[10:43]  * Chipaca hugs zyga 
[10:43]  * zyga looks
[10:43]  * zyga hugs Chipaca back :)
[10:43] <Chipaca> zyga: we don't have bugs! we have … features that are trying their best
[10:45] <thresh> Wimpress, np, and thanks!
[10:52] <pstolowski> zyga: i've updated the two bugs you asked (both fixed)
[10:53] <zyga> pstolowski: super, thank you!
[10:54] <zyga> mborzecki: a small bug you could assign to yourself for tracking
[10:54] <zyga> mborzecki: https://bugs.launchpad.net/snappy/+bug/1574103
[10:54] <zyga> I think your work will fix it
[10:56] <zyga> pstolowski: does this ring a bell? I recall something similar happening recently: https://bugs.launchpad.net/snappy/+bug/1805170
[10:57] <zyga> degville: a typo in docs, probably stale by now but perhaps you can have a quick look? https://bugs.launchpad.net/snapd/+bug/1801735
[11:02] <pstolowski> zyga: yes, we've been considering enhancing snapctl to show changed values for current transaction. no concrete plan as far as snapctl is concerned. should be easy to add
[11:08] <degville> zyga: yep, of course - looking now.
[11:10] <mvo> hey degville! nice to see you :)
[11:11] <degville> mvo: thanks! good to be back :)
[11:13] <pedronis> Chipaca: some small comments on 6635
[11:17] <mborzecki> so the opensuse install fix PR did not fail on opensuse, but this failed instead: https://paste.ubuntu.com/p/XWMd4vMGVw/
[11:18] <mborzecki> isn't there a ticket about that?
[11:20]  * pstolowski lunch
[11:24] <zyga> mborzecki: yes, mvo is working on that
[11:25] <zyga> mvo: https://bugs.launchpad.net/snapd/+bug/1769669 looks like something that was fixed now, shall I mark it as such?
[11:25] <zyga> (at least based on the forum chatter)
[11:31] <Chipaca> pedronis: on it
[11:32] <mvo> zyga: yeah, this should be more robust now
[11:32] <zyga> mvo: shall I close the bug?
[11:33] <mvo> zyga: +1
[11:38] <zyga> mvo: halp
[11:39] <zyga> mvo: do we have a regression?
[11:39] <zyga> https://www.irccloud.com/pastebin/8c8TlMgh/
[11:39] <zyga> --extrausers broke on core
[11:39] <zyga> (core16)
[11:44] <mvo> zyga: this is edge? let me check
[11:44] <mborzecki> zyga: i'm guesing this is where it broke https://people.canonical.com/~mvo/core-changes/html/edge/2.38r6678_2.38+git1203.52b6d65~ubuntu16.04.1r6685.html
[11:45] <zyga> mvo: that's the critical pr that fixes master
[11:45] <zyga> mvo: from maciej
[11:45] <mvo> mborzecki: indeed
[11:45] <mvo> zyga: yeah on it
[11:45] <zyga> mborzecki: when exactly?
[11:45] <mborzecki> 6673 seem sok
[11:45] <mborzecki> seems ok
[11:45] <zyga> mborzecki: before 1:4.2-3.1ubuntu5.4
[11:45] <zyga> (version from hell)
[11:46] <mvo> zyga: let me sort this out
[11:46] <zyga> super, thank you!
[11:47] <mvo> zyga: there must be some confusion, my original SRU added all the missing patches :/
[11:47] <zyga> yeah
[11:47] <zyga> that's why I'm puzzled
[11:47] <zyga> maybe CVE fix dropped them?
[11:47] <mvo> zyga: anyway, fix should be there soon
[11:47] <zyga> or maybe image ppa woe?
[11:47] <zyga> I don't get it
[11:57] <mvo> zyga: I think the PPA is confused, I manually uploaded a no-change version to hopefully fix it
[11:58] <mvo> zyga: this version was briefly in ppa:snappy-dev/image but then I removed it again because I wanted to SRU the full version with all pending changes to the real archive instead of the PPA (I did that on friday but iirc no sru review yet)
[11:58] <mvo> zyga: anyway, hopefully a gentle kick will fix it
[11:59] <mborzecki> ok, so this, then opensuse branch, then merge master to the PRs and we can finally start seeing some green :P
[11:59] <zyga> mvo: ideally the fix is that the main version in the archive is ok
[11:59] <zyga> mvo: and we can drop this from the ppa forever
[11:59] <Chipaca> mborzecki: things are broken right now?
[12:00]  * Chipaca was about to push
[12:00] <mborzecki> Chipaca: yeah
[12:00] <zyga> mvo: shadow failed to upload in the snappy-dev/ubuntu/image ppa just now
[12:00] <zyga> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/16527935
[12:01] <Chipaca> mborzecki: I'll hold back then :-)
[12:01] <Chipaca> maybe i should have lunch
[12:05] <pedronis> pstolowski: I mand an high-level remark in 6629
[12:05] <pedronis> *made
[12:08] <mvo> zyga: yeah, its more confused, I uploaded anohter fix
[12:09] <mvo> zyga: main archive>yeah, I was working on exactly that, i.e. SRU our two pending patches plus the new userdel one
[12:09] <mvo> zyga: its iirc in unapproved
[12:09] <zyga> mvo: there's a thing I need to discuss with you
[12:09] <zyga> mvo: maybe after you are done with this you could give me a ping?
[12:09] <mvo> zyga: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= (fwiw)
[12:10] <mvo> zyga: we can talk in ~2min, just want to double check the build and then trigger core rebuild
[12:13] <mvo> zyga: I'm in the standup channel
[12:13] <zyga> joining
[12:26] <pstolowski> pedronis: thanks
[12:30] <mvo> new core build triggered, should be ready in some minutes with fixed useradd
=== ricab is now known as ricab|lunch
[12:39] <cachio> Chipaca, hey
[12:39] <Chipaca> cachio: 'sup
[12:39] <cachio> I am testing the core revert test
[12:39] <Chipaca> cachio: ok
[12:39] <cachio> perhaps you can help me
[12:39] <cachio> after I refresh the core snap
[12:40] <cachio> it cannot make a snap refresh
[12:40] <Chipaca> did it reboot after refreshing?
[12:40] <cachio> I see an error like https://paste.ubuntu.com/p/nJkkcVhVWy/
[12:40] <Chipaca> cachio: is this on core, or on classic?
[12:40] <cachio> yes
[12:40] <cachio> it is core
[12:40] <cachio> core 16
[12:41] <Chipaca> cachio: ah, that looks like a network issue
[12:41] <cachio> could it be related to the catalog refresh?
[12:41] <Chipaca> cachio: what's in the log? (is it running with DEBUG_SNAPD_HTTP)
[12:41] <Chipaca> or was it SNAPD_DEBUG_HTTP
[12:41] <cachio> I added core to ping api.snapcraft.io before make the refresh
[12:42] <cachio> and it can reach the endpoint
[12:42] <Chipaca> the logs should have more info about what's going on
[12:42] <Chipaca> if debug is on
[12:42] <cachio> it I wait like a minute the snap refresh command does not fail anymore
[12:43] <cachio> I'll add the debug in that case
[12:43] <Chipaca> cachio: you're not running with SNAPD_DEBUG already?
[12:43] <cachio> no
[12:43] <cachio> Chipaca, the test is running in a vm inside other vm in google
[12:44] <cachio> Chipaca, it is part of the nested test suite
[12:44] <Chipaca> cachio: what's in the logs _without_ debug?
[12:44] <Chipaca> or does the vm die
[12:45] <cachio> it is running without debug beacuse I test the core which I get from edge
[12:45] <cachio> on that suite
[12:49] <Chipaca> cachio: but can you get the logs?
[12:50] <cachio> Chipaca, yes
[12:50] <Chipaca> cachio: please do
[12:50] <Chipaca> cachio: even without debug there might be something useful
[12:51] <cachio> Chipaca, I am running again the test
[12:51] <cachio> I'll have the logs in 5 minutes
[12:53] <pstolowski> cachio: hey, #6491 fails repeatedly on google:ubuntu-14.04-64:tests/main/interfaces-daemon-notify and it's unclear why (it's completely unrelated to the PR); do you have a moment to help with that?
[12:54] <cachio> pstolowski, hi, checking
[12:59] <mborzecki> off to pick up the kids
[13:13] <cachio> pstolowski, I see errors related to opensuse which I am trying to fix
[13:14] <cachio> pstolowski, I think best is disable it until the solution is in place
[13:14] <pstolowski> cachio: yes, this time opensuse failed as well. but the problem is that test i mentioned, it failed many times in a row
[13:15] <cachio> I am executing it now
[13:15] <cachio> seems to be something new
[13:16] <cachio> pstolowski, I am trying to reproduce it here
[13:17] <pstolowski> cachio: ta! it seems something with journal cursor? but it's unclear why it's failing on the PR which adds this nested vm test
[13:19] <cachio> pstolowski, it is not related to your change
[13:32] <cachio> Chipaca, the logs are not good :( https://paste.ubuntu.com/p/GFtrm7TWYf/
[13:32] <Chipaca> cachio: sigh
[13:32] <cachio> I have a debug session on that machine
[13:33] <cachio> could I get something else?
[13:36] <Chipaca> cachio: if you do the refresh agian does it work?
[13:37] <pedronis> cachio: both mvo and me made some comments in 6625
[13:38] <cachio> Chipaca, yes
[13:39] <Chipaca> cachio: sounds like actual network hiccup, then
[13:39] <Chipaca> cachio: can you turn on debug permanently in the nested tests? (you can do it by just adding a file)
[13:41] <cachio> pedronis, I saw those, I'll answer and start a new test for ssh config
[13:43] <cachio> Chipaca, Environment=SNAPD_DEBUG_HTTP=7 SNAPD_DEBUG=1 is ok for the config¡
[13:43] <cachio> ?
[13:44] <Chipaca> cachio: yes
[13:44] <Chipaca> cachio: it goes in a [Service] section
[13:45] <cachio> Chipaca, /etc/systemd/system/snapd.service.d/local.conf ?
[13:45] <Chipaca> cachio: y
[14:05] <cachio> niemeyer, hey, could you please take a look to https://github.com/snapcore/spread/pull/75
=== ricab|lunch is now known as ricab
[14:19] <zyga> pedronis: can you ack / change https://github.com/snapcore/snapd/pull/6636#discussion_r268661433 after the call please?
[14:21] <pedronis> zyga: done
[14:33] <mborzecki> cachio: https://github.com/snapcore/snapd/pull/6644
[14:34] <cachio> mborzecki, I'll try that
[14:34] <cachio> thanks
[14:37] <cachio> Chipaca, https://paste.ubuntu.com/p/Dw4vPh9PpY/
[14:38] <cachio> Chipaca, api.snapcraft.io works before make snap refresh
[14:40] <zyga> I need to grab lunch and maybe exercise a bit, I will be back later
[14:40] <mborzecki> off to pick up the kids
[14:40] <mborzecki> damn, wrong terminal
[14:41] <niemeyer> cachio: Heya
[14:41] <niemeyer> Will look tomorrow.. off today
[14:43] <mborzecki> mvo: restarted #6644 too early probably as it failed with --extrausers again, running it again
[14:44] <Chipaca> cachio: it looks like the network wasn't fully up?
[14:46] <Chipaca> cachio: dns was failing at 14:22:19, and still at 14:22:23, then that came up by 14:22:24 but still not healthy
[14:46] <mvo> mborzecki: ok
[14:46] <Chipaca> cachio: how are you testing you can reach api.snapcraft.io?
[14:47] <cachio> Chipaca, https://paste.ubuntu.com/p/KKHXZgxJCm/
[14:50] <cachio> Chipaca, does it make sense?
[14:50] <Chipaca> cachio: the output of 'snap debug connectivity' would be helpful, if you could
[14:51] <Chipaca> cachio: and you could 'while ! snap debug connectivity; do sleep 1; done'
[14:51] <cachio> Chipaca, https://paste.ubuntu.com/p/3JfKfZb4wc/
[14:51] <cachio> this is what I have
[14:52] <cachio> I could print all the output, but I need to rexecute
[14:54] <Chipaca> cachio: I mean, with what you have, my veredict is the network had a hiccup
[14:54] <Chipaca> cachio: it happening every time makes me think it's actually something in the vm that hasn't finished coming up
[14:54] <Chipaca> cachio: but I don't know
[14:58] <cachio> Chipaca, ok, makes sense
[14:59] <cachio> I'll try to install a snap and see if it works or fail
[15:00] <mborzecki> mvo: fwiw, i ran google:ubuntu-core-16-64:tests/main/ubuntu-core-create-user separately now, so i expect #6644 to be green this time :)
=== chihchun is now known as chihchun_afk
[15:08] <mvo> mborzecki: cool
[15:08] <cachio> mborzecki, seems to work well the change for opensuse
[15:09] <cachio> I'm updating the image now
[15:09] <cachio> in this case we dont need to diable opensuse
[15:19] <mborzecki> 6644 landed
[15:19] <Chipaca> mborzecki: is that the fix-all-the-things one?
[15:23] <pedronis> zyga: there's a conflict as well in #6636
[15:24] <mborzecki> Chipaca: yeah, it should make things green again
[15:30]  * cachio lunch
[15:33]  * zyga returned home, rain + bike != fun
[15:41] <Chipaca> zyga: not with that attitude
[16:17] <zyga> pedronis: does https://github.com/snapcore/snapd/pull/6636 look good now or do you want to see some changes around the go part?
[16:19] <zyga> ups, bad push :/
[16:19] <pedronis> zyga: I need to go have a walk, will look when I'm back
[16:20] <zyga> ok
[16:27] <mvo> zyga: 6642 has conflicts now
[16:29] <Chipaca> pedronis: wrt common-id search, should I make it reject q+cid searches?
[16:29] <zyga> mvo: yes, expected
[16:29] <zyga> I just fixed the base branch
[16:29] <mvo> ta
[16:32] <zyga> I need to mend the network again
[16:32] <zyga> time to actually connect that backup modem I have
[16:32] <zyga> brb
[16:44] <zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/6597
[16:44] <zyga> mvo, mborzecki ^
[16:46] <cachio> pedronis, hey, #6625 updated
[16:47] <cachio> but it fails with ssh.disable: true
[16:47] <cachio> pedronis, is it expected, right?
[16:48] <mvo> zyga: I can check tomorrow, need to play hockey soon(ish) :)
[16:48] <zyga> sure
[17:09] <mborzecki> heh, so now spread jobs hit the travis time limits
[17:11] <cachio> mborzecki, do you have a link¡
[17:12]  * Chipaca knows cachio's keyboard layout, and hates it
[17:12] <cachio> :)
[17:12] <Chipaca> https://www.dsi-keyboards.com/wp-content/uploads/2015/03/KA-Latin-American-20867.jpg
[17:13] <Chipaca> hate hate hate
[17:13] <Chipaca> how can you program on that
[17:13] <Chipaca> :-)
[17:13] <Chipaca> having the logical not right there is cool tho
[17:13] <cachio> Chipaca, I don't know, well perhaps because I use it since long time :):)
[17:13] <Chipaca> cachio: obvs :-)
[17:14] <Chipaca> i just never could get used to it
[17:14] <cachio> Chipaca, I used to work for argentinian clients
[17:14] <cachio> Chipaca, I needed the ñ
[17:15] <cachio> Chipaca, :)
[17:15] <Chipaca> cachio: i'm still upset there never was ubuntu ñoño ñandú
[17:15] <cachio> Chipaca, and i also used to share the computer with my wife
[17:15] <Chipaca> cachio: my condolences
[17:15] <cachio> hehehe
[17:16] <Chipaca> anyhoo, back to breaking stuff
[17:16] <Chipaca> actually, no
[17:16] <Chipaca> i'm going for a walk before the sunshine goes
[17:16]  * Chipaca afk
[17:19] <pedronis> cachio: actually, not, I thought it would work with recent code changes, we'll need to dig
[17:22] <pedronis> Chipaca: I don't have a strong opinion, do we think the store will drop support for that? on our side it's easier to add things than to remove them
[17:22] <pedronis> which is an argument to not allow it unless there's a strong use case
[17:22] <Chipaca> pedronis: yeah, that's what i was thinking, particularly with rob saying they're not goingt o use it
[17:23] <Chipaca> I'll drop support for the combo
[17:23] <Chipaca> but first i'll walk
[17:23]  * Chipaca really afk now
[17:26] <cachio> pedronis, this is the output https://paste.ubuntu.com/p/KbxSxbYGZP/
[17:28] <pedronis> cachio: that is weird,  we probably need pstolowski to help debug that
[17:40] <cachio> pedronis, this ire the defaults that we use
[17:40] <cachio> https://github.com/snapcore/snapd/blob/8c8af3731b6feeb781bb477208c526755ac435a3/tests/main/ubuntu-core-gadget-config-defaults/gadget-ssh-oneline.yaml
[17:40] <cachio> pedronis, is it ok?
[17:42] <pedronis> cachio: yes, it was asked, we'll discuss tomorrow with pstolowski
[17:42] <pedronis> sorry, it is what I asked
[17:42] <cachio> pedronis, nice
[17:42] <pstolowski> Im afk, will check tomorrow morning
[17:43] <cachio> pedronis, thanks
[19:06]  * zyga EODs
[19:12] <zyga> cachio, pedronis: feels like missing path in handleServiceDisableConfiguration, specifically when output is ""
[19:13] <cachio> zyga, nice, thanks for take a look to that
[19:15] <juliank> I finally decided to start building the apt snap: https://paste.ubuntu.com/p/XvgPpKGgqQ/ :D
[19:15] <juliank> I think I had a problem with an unclean rebuild in between, as the apt snap ended up with
[19:15] <juliank> E: The method driver /apt/lib/apt/methods/mirror+file could not be found.
[19:15] <juliank> but let's see what the next revision brings
[19:17] <juliank> Hmm, so it builds the snap to install to the snap's /, but then apt looks up methods in /lib/apt, when it should be looking in /snap/apt/<id>/lib/apt
[19:21] <juliank> so I guess I can specify - -DCMAKE_INSTALL_LIBEXECDIR=/snap/apt/current but I'd like the id instead of current
[19:24]  * cachio afk
[19:34] <juliank> How do other classic snaps handle running helpers from their own libexecdir?
[20:47] <zyga> jdstrand: updated https://github.com/snapcore/snapd/pull/6642
[20:47] <zyga> jdstrand: I kept the permission as they were, I will discuss this with pedronis tomorrow
[20:48] <zyga> jdstrand: but everything else should be good now
[21:07]  * zyga really EOD now
[21:07] <zyga> juliank: that's not an ID
[21:07] <zyga> juliank: that's a revision that changes  with each build
[21:27] <jdstrand> zyga: ack, thanks
[22:32] <juliank> zyga: well, yes
[22:32] <juliank> zyga: that's where it should look for its helper programs
[22:33] <juliank> Currently I'm snapping a caldav server, but I don't feel safe having the root daemon, so I think maybe not ship a daemon, and just the command in the snap. oh well...
[23:00] <pgnd> I've installed snapd on Opensuse, per instructions here: https://forum.snapcraft.io/t/installing-snap-on-opensuse/8375
[23:00] <pgnd> There, degville mentions the need to "systemctl enable snapd.apparmor".
[23:01] <pgnd> Afaict, there's no such service installed ...  Is that^^ still current instruction, and a dep has changed?