[00:51] <mup> PR snapcraft#1598 opened: recording: do not crash when snapd is not installed <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1598>
[01:16] <mup> PR snapd#4006 closed:  snap-exec: update tests to follow main_test pattern  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4006>
[02:30] <mup> PR snapcraft#1589 closed: Update default node engine to 6.11.3 <Created by flexiondotorg> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1589>
[02:58] <mwhudson> if someone is bored (ha, ha), they could look into why classic snap builds on artful fail like this: https://launchpadlibrarian.net/340314110/buildlog_snap_ubuntu_artful_ppc64el_subiquity_BUILDING.txt.gz
[02:58] <mwhudson> on ppc64el only, i should add
[06:49] <zyga-solus> good morning
[06:50] <zyga-solus> today is another cgroup day, hopefully one with fewer disappointments
[07:04] <kalikiana> good morning
[07:04] <zyga-solus> o/
[07:05] <kalikiana> hmmm two of my PRs have landed, this is a good start
[07:06] <kalikiana> zyga-solus: how's your poleflu? (I think that's what you called it :-P)
[07:10] <zyga-solus> kalikiana: thank you, I feel much better now
[07:10] <zyga-solus> kalikiana: getting into the habit of using longe sleeves and other warm-keeping stuff helps
[07:11] <zyga-solus> kalikiana: I really miss the sun, it's almost winter here
[07:11] <zyga-solus> kalikiana: rain will just turn to snow one day (any day)
[07:12] <kalikiana> yeah, sunny days are over it seems :-(
[08:06] <kalikiana> sergiusens: I'm very confused. I thought you merged https://github.com/snapcore/snapcraft/pull/1348 https://github.com/snapcore/snapcraft/pull/1382 but you just closed them? Some discussion would be helpful here
[08:06] <mup> PR snapcraft#1348: repo: setup a foreign arch and sources <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1348>
[08:06] <mup> PR snapcraft#1382: rust plugin: make libc configurable <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1382>
[08:17] <mup> PR snapd#3964 closed: many: implement our own ANSI-escape-using progress indicator <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3964>
[09:26] <naveed> help
[09:27] <ackk> hi, is there a way in snapd to perform operations when a plug is connected/disconnected? I mean perform actions in snapd itself, not something like external scripts
[09:27] <naveed> i am using Dell gateways 5000 and try to connect my mobile via bluetooth for sending data
[09:28] <naveed> but when i enter connect it gives error "org.bluez.error failes"
[09:28] <naveed> fasorry failed
[09:34] <mup> PR snapcraft#1599 opened: Fixed StoreReleaseError format for BAD REQUEST error <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1599>
[09:42] <zyga-ubuntu> ackk: hey
[09:42] <zyga-ubuntu> ackk: it's coming along but it's not ready
[09:42] <zyga-ubuntu> ackk: pstolowski is working on interface hooks that fire when you connect/disconnect things
[09:44] <ackk> zyga-ubuntu, ah, I see
[09:44] <ackk> zyga-ubuntu, ok, so for now I guess the socket activation stuff will need to be started/stopped on snap start/stop, it can't be done when the network-bind plug is actually connected/disconnected
[09:45] <ackk> that's fine
[09:49] <zyga-ubuntu> yes
[09:49] <ackk> zyga-ubuntu, ok, thanks
[10:44]  * kalikiana short break
[11:03]  * zyga-ubuntu -> break 
[11:31] <kalikiana> sliff
[11:47] <zyga-ubuntu> re
[11:59] <spineau> jamesh: hello, I'd like to know if the polkit support added to 2.28 allows pkexec to work from the snap (and obeys to the policy file(s)  installed in /usr/share/polkit-1/actions/)
[12:18] <mup> PR snapd#4015 opened: run-checks: use nakedret to check for naked returns on long functions <Created by chipaca> <https://github.com/snapcore/snapd/pull/4015>
[12:33] <cjwatson> mwhudson: investigated: https://github.com/snapcore/snapcraft/pull/1600
[12:33] <mup> PR snapcraft#1600: options: fix core-dynamic-linker on ppc64el/s390x <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1600>
[12:34] <mup> PR snapcraft#1600 opened: options: fix core-dynamic-linker on ppc64el/s390x <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1600>
[13:02] <zyga-ubuntu> __chip__: standup?
[13:02] <mvo> __chip__: we had a test failure from the new progress bar in the ppa builds, I can give you details in a sec
[13:02] <mvo> __chip__: also, whats up with this nick? is this the new default
[13:11] <Eighth_Doctor> Yo
[13:11] <Eighth_Doctor> man, it sucks not having my main laptop
[13:11] <Eighth_Doctor> I have to remember all the IRC channels I'm active in and add them
[13:11] <ikey> and worse than that you're not even the 9th or 10th..
[13:11]  * ikey feels for you.
[13:12] <ikey> erm. i mean *hi :)
[13:12] <Eighth_Doctor> haha
[13:12] <Eighth_Doctor> well, at least you got it :)
[13:12] <ikey> aye :]
[13:13] <Eleventh_Doctor> this laptop is configured with an older version of my profile
[13:13] <Eleventh_Doctor> I carried it forward from various IRC clients and various laptops before I started over on the new laptop
[13:15] <Eleventh_Doctor> my Linux laptop has always used some variation of this nick ;)
[13:16] <Eleventh_Doctor> I've never been a huge fan of the 9th
[13:16] <Eleventh_Doctor> the 10th is awesome, though
[13:16] <ogra_> the elleventh is still my favourite
[13:16] <Eleventh_Doctor> mine too
[13:17] <sergiusens> kalikiana closed them because they had no changes in 2 weeks++ and failing tests
[13:17] <kalikiana> sergiusens: That's not true. They had commits in the last few days
[13:20] <sergiusens> kalikiana "kalikiana added some commits 18 days ago "
[13:21] <sergiusens> on both of those
[13:21] <Eleventh_Doctor> sergiusens: it lists by author date
[13:21] <Eleventh_Doctor> which is irrelevant
[13:21] <Eleventh_Doctor> if you amend commits, that date doesn't change
[13:22] <sergiusens> ah, that can make sense Eleventh_Doctor
[13:23] <Eleventh_Doctor> I learned after the last couple of times my PR has been closed for looking out of date that people read the GH web interface and take it literally
[13:23] <sergiusens> kalikiana you still have many PRs open, focus on fixing them one by one instead of all at once
[13:23] <Eleventh_Doctor> so I rewrite the author dates every time now
[13:23] <sergiusens> as you may be eating up the travis qutoa for everyone else
[13:23] <sergiusens> kalikiana or do them all in parallel, but run the suite locally
[13:23] <sergiusens> the full suite
[13:23] <Eleventh_Doctor> zyga-solus: ping
[13:24] <kalikiana> sergiusens: Well, the local runs aren't the problem, I'm getting killed by false negatives...
[13:24] <sergiusens> Eleventh_Doctor it is so hard to keep track of your irc handles! ;-)
[13:24] <Eleventh_Doctor> well, I really don't use this laptop very much
[13:24] <Eleventh_Doctor> so these nicks don't show up often
[13:24] <sergiusens> Eleventh_Doctor finally off the mac ;-)
[13:25] <Eleventh_Doctor> oh, this is a Mac
[13:25] <Eleventh_Doctor> it just runs Linux ;)
[13:25] <mvo> Chipaca: https://launchpadlibrarian.net/340343990/buildlog_ubuntu-xenial-arm64.snapd_2.28.1+git425.72389e7~ubuntu16.04.1_BUILDING.txt.gz is the link, I can extract the failure for you in a sec to a pastebin
[13:25] <Eleventh_Doctor> this MacBook has been running Fedora for the last two years
[13:25] <mvo> Chipaca: http://paste.ubuntu.com/25713767/
[13:25] <Eleventh_Doctor> it's much more performant than it was when it ran Mac OS X
[13:25] <mvo> Chipaca: fwiw, the error looks "interessting"
[13:26] <sergiusens> kalikiana document that analysis in the PR so everyone is aware of it then and find the root cause
[13:26] <mvo> Chipaca: I mean, something with the bytes download counting is wrong 95B vs 99B
[13:26] <Chipaca> hah
[13:26] <Chipaca> i wondered about that while writing the test
[13:26] <zyga-ubuntu> Eleventh_Doctor: hey
[13:27] <Chipaca> and then thought "nah, it can't be so slow as to be less than this"
[13:27] <Eleventh_Doctor> zyga-ubuntu: I pushed snapd updates, I need karma!
[13:27] <zyga-ubuntu> Eleventh_Doctor: aha, I'll look at F26 then
[13:27] <zyga-ubuntu> Eleventh_Doctor: what's this nickname about? :D
[13:28] <Chipaca> mvo: easy to fix. Will fixing master be enough?
[13:28] <Eleventh_Doctor> zyga-ubuntu: this is my Linux laptop
[13:28] <zyga-ubuntu> Eleventh_Doctor: oh, nice, a new one?
[13:28] <Eleventh_Doctor> with more or less my original IRC configuration carried through various laptops/clients
[13:28] <Eleventh_Doctor> actually, this is my oldest laptop that still works
[13:28] <Eleventh_Doctor> a 2009 MacBook Pro
[13:28] <Eleventh_Doctor> but instead of Mac OS X, it runs Fedora
[13:29] <Eleventh_Doctor> I wiped it as soon as the warranty ran out
[13:29] <ogra_> pffft warranty
[13:30] <Eleventh_Doctor> well, with the proprietarization of laptop components, it's gotten really hard to service them myself :(
[13:30] <Eleventh_Doctor> and a lot of laptop warranties void on changing the OS
[13:31] <Eleventh_Doctor> (which is dumb and potentially illegal, but there's not a lot I can do)
[13:32] <mvo> Chipaca: yes
[13:32] <Eleventh_Doctor> zyga-ubuntu: snapd v2.28.1 with the backport of the distro check fixes
[13:33] <Eleventh_Doctor> https://bodhi.fedoraproject.org/updates/?packages=snapd
[13:33] <zyga-ubuntu> Eleventh_Doctor: huh? and is apple really doing thaT?
[13:33] <Eleventh_Doctor> zyga-ubuntu: Yes
[13:33] <zyga-ubuntu> Eleventh_Doctor: can you point me to where it says so?
[13:33] <zyga-ubuntu> because that's definitely not legal in EU
[13:34] <Eleventh_Doctor> it may be US specific :(
[13:34] <Eleventh_Doctor> it's not legal per-se in the US either
[13:34] <Eleventh_Doctor> but Apple retains the right to refuse servicing for any reason
[13:34] <Eleventh_Doctor> my next go around, I'm probably picking up a Dell XPS
[13:35] <Eleventh_Doctor> they're turning into nice beefy laptops while remaining really lightweight
[13:35] <Eleventh_Doctor> they ship with Ubuntu or Windows, but that can be easily fixed :)
[13:36] <zyga-ubuntu> Eleventh_Doctor: I'd be surprised if apple really refused that but IDK
[13:36] <Eleventh_Doctor> it's usually not Apple directly that refuses
[13:36] <Eleventh_Doctor> but the service centers that aren't operated by Apple
[13:37] <Eleventh_Doctor> also, removing macOS removes the necessary bits for service center diagnostics to run
[13:37] <Eleventh_Doctor> because apparently that's a thing
[13:37] <Eleventh_Doctor> which is why they ask for admin credentials to the laptop :/
[13:38] <zyga-ubuntu> Eleventh_Doctor: eh, I know that last bit, I refused
[13:38] <zyga-ubuntu> (and they did service me)
[13:41] <Eleventh_Doctor> I used to leave it dual-booted with an empty and useless macOS
[13:47] <sergiusens> ppisati_ hey, what was your bug again? I will have time to fix it today
[13:55] <Chipaca> mvo: snapd#4016 is the fix
[13:55] <mup> PR #4016: progress: be more flexible in testing ansimeter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4016>
[13:55] <mvo> Chipaca: thanks a bunch
[13:55] <mup> PR snapd#4016 opened: progress: be more flexible in testing ansimeter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4016>
[13:56] <mvo> Chipaca: eh, thanks a lot
[13:56] <mvo> Chipaca: sorry, I learned the difference between "thanks a bunch" and "thanks a lot" only recently. anyway, thanks :)
[13:57] <zyga-ubuntu> you know
[13:57] <zyga-ubuntu> I find it hard to name test snaps
[13:57] <mvo> test1
[13:57] <mvo> test2
[13:58] <mvo> :P
[13:58] <zyga-ubuntu> I think it would help if we could have a local name in the directory with the task
[13:58] <zyga-ubuntu> right, if those were local and would not compete with other "snap testing interfaces" it'd be easier
[13:58] <cachio> mvo, this is the error in zesty https://launchpadlibrarian.net/340372113/buildlog_ubuntu-zesty-ppc64el.snapd_2.27.6+17.04_BUILDING.txt.gz
[13:59] <cachio> on ppc
[13:59] <cachio> the rest is working properly
[13:59] <mvo> cachio: yeah, I just tried to find the root cause but failed so far
[13:59] <jamesh> spineau: it won't make any difference there: my changes were all about getting snapd to talk to polkit to provide access control to its own API.  Allowing confined services to talk to polkit (and install default policies) is a different matter.
[14:00] <jamesh> spineau: it isn't on my radar, but it would be worth bringing up on the forum.
[14:00] <spineau> jamesh: ok, I see. thanks
[14:11] <Chipaca> mvo: what difference between thanks a bunch and a lot have you learned?
[14:12] <mvo> Chipaca: someone from the uk explained that often "thanks a bunch" is ironic/sarcastic. I had no idea before and I think I confused a lot of native speakers :)
[14:13] <mvo> Chipaca: but maybe its just specific parts of the world where it is used like this
[14:13] <Eleventh_Doctor> mvo: it has different meanings depending on tone
[14:13] <Eleventh_Doctor> in the US, it's primarily not used sarcastically
[14:13] <Eleventh_Doctor> but in the east coast, it is
[14:13] <mvo> Eleventh_Doctor: aha, that is interessting
[14:13] <jamesh> mvo: both can be used sarcastically.  It depends on the tone
[14:13] <Eleventh_Doctor> thanks is often used sarcastically
[14:13] <mvo> geh, english is a complicated language :)
[14:13] <jamesh> something irc doesn't convey very well
[14:13] <mvo> thanks jamesh
[14:13] <Eleventh_Doctor> :/
[14:14] <mvo> jamesh: yeah, irc lacks the nuances :-D
[14:14] <Eleventh_Doctor> if you think English is bad, Japanese is way worse
[14:14] <Eleventh_Doctor> the *whole* reason for emoji is to deal with that problem
[14:14] <mvo> Eleventh_Doctor: heh, fun!
[14:15] <Eleventh_Doctor> and of course, emoticons have been used in text long before computers for the same reason
[14:15] <Eleventh_Doctor> but Japanese has the special problem of conveying meaning and feeling almost entirely through tone
[14:16] <Eleventh_Doctor> they don't have emotion words, per se like English does
[14:16] <Eleventh_Doctor> so there's not an explicit set of "profane" words
[14:16] <Eleventh_Doctor> the *way* you say it turns certain words "profane"
[14:20] <Chipaca> mvo: yeah, the tone is important; otherwise it's mostly used interchangeably (and "thanks a lot" can be and does get used sarcastically as well)
[14:21] <Chipaca> OTOH, https://en.wiktionary.org/wiki/thanks_a_bunch
[14:21] <Eleventh_Doctor> "thanks a lot" is the American equivalent to "thanks a bunch"
[14:21] <Chipaca> says UK usage is unambiguously sarcastic, which is news to me (but then maybe i should go out more)
[14:21] <Eleventh_Doctor> UK uses thanks a bunch entirely sarcastically
[14:21] <Eleventh_Doctor> but outside of the east coast in the US, it's not necessarily so
[14:22] <Eleventh_Doctor> the *only* reason it is that way in the east coast is due to the stronger European heritage there
[14:22] <Eleventh_Doctor> but "thanks a lot" is unambiguously sarcastic in most of the US
[14:22] <Chipaca> silly UKans, going over there, UKing the place up
[14:23] <Eleventh_Doctor> this is primarily because "a bunch" is rarely used in the US
[14:23] <Eleventh_Doctor> "a lot" is the primary form
[14:23] <Eleventh_Doctor> the UK reverses this, since "a lot" isn't used very much there
[14:23] <Chipaca> the bottom line is: never thank anybody for anything
[14:24] <mvo> yeah, it sounds like it - meh :/
[14:24] <mvo> I guess a simple "thanks" is what I should remember
[14:24] <Eleventh_Doctor> ;)
[14:24] <Chipaca> mvo: go with "gramercy"
[14:25] <Eleventh_Doctor> "thanks", "thank you" work well enough
[14:25] <Chipaca> then everybody will have to look it up, giving you time to run away
[14:28] <niemeyer> o/
[14:28] <mvo> hey niemeyer! how are you?
[14:28] <niemeyer> mvo: Did we land the squashfs-fuse thing?  I recall we talked about it and agreed to land it, but I don't recall actually shipping it
[14:29] <niemeyer> mvo: Pretty good, thanks
[14:29] <niemeyer> mvo: Had the internal session this morning.. almost uneventful.. roadmap remains mostly the same, with one critical item added above others which we need to discuss
[14:30] <mvo> niemeyer: squashfs-fuse did not land, lets push it high on the stack
[14:30] <mvo> niemeyer: will you update the roadmap with the new item(s)?
[14:30] <niemeyer> mvo: I'd like to talk about it first
[14:30] <Eleventh_Doctor> mvo: wait, what?
[14:30] <Eleventh_Doctor> what's this about squashfuse support not landing?
[14:30] <niemeyer> mvo: As it's a bit of a high-level requirement right now.. would like to build ideas so we can write down something more concrete
[14:31] <niemeyer> mvo: Ugh.. man.. how did we forget that again :(
[14:31] <niemeyer> Shame on us
[14:31] <mvo> niemeyer: high-level> sounds good
[14:31] <mvo> niemeyer: yes :(
[14:32] <mvo> niemeyer: I finish my current task (should not take long) and get to it, if we rush it it can still go into 2.29
[14:32] <niemeyer> Eleventh_Doctor: It's just about making it easier to work with.. won't affect you
[14:32] <mvo> mostly for lxd
[14:32] <Eleventh_Doctor> ah
[14:32] <niemeyer> mvo: Thank you! 2.29 it is then
[14:33] <Eleventh_Doctor> well, that already landed for Fedora snapd ;)
[14:33] <Eleventh_Doctor> mainly because kyrofa asked for it and actually did the work to make it possible in Fedora
[14:33] <mvo> Eleventh_Doctor: nice - btw, is that you Neal? if so, you have too many nicks ;)
[14:33] <Eleventh_Doctor> yes
[14:33] <ogra_> is kyrofa secretly using fedora now instead of ubuntu ?
[14:33] <ogra_> :)
[14:33] <ogra_> (because he gets the features faster there)
[14:33] <Eleventh_Doctor> :D
[14:34] <Eleventh_Doctor> he's also working on packaging LXD for Fedora
[14:34] <ogra_> whee !
[14:34] <Eleventh_Doctor> so that we have it properly integrated with container-selinux
[14:34] <mvo> Eleventh_Doctor: heh, do you have more nicks that I should be aware of :) ?
[14:34] <Eleventh_Doctor> umm...
[14:34] <cachio> mvo, niemeyer zyga-ubuntu pstolowski this is the doc for the core snap built as part of the spread-cron run https://forum.snapcraft.io/t/building-and-testing-the-core-snap-on-edge-channel/2419
[14:34] <ogra_> mvo, evey nick you dont recognize :)
[14:34] <Eleventh_Doctor> just check my netmask
[14:34] <ogra_> just assume it is neal
[14:34] <Eleventh_Doctor> it should always say ngompa/fedora
[14:34] <Eleventh_Doctor> err, fedora/ngompa
[14:35] <pstolowski> cachio, thanks!
[14:35] <Eleventh_Doctor> I also submitted a PR to container-selinux to add LXD support: https://github.com/projectatomic/container-selinux/pull/42
[14:35] <mup> PR projectatomic/container-selinux#42: Add support for LXD <Created by Conan-Kudo> <https://github.com/projectatomic/container-selinux/pull/42>
[14:35] <niemeyer> mvo: Just recalling, we'll do it as a "snapfs" right?
[14:36] <mvo> cachio: fwiw, I think the ppc64el issue we have right now should not halt hte 2.28.1 core snap release, we need to figure out what is going on there but core for ppc64el is ready at 2.28.1 so the build is fine
[14:36] <cachio> mvo, niemeyer zyga-ubuntu pstolowski, it is related to the PRS; https://github.com/snapcore/spread-cron/pull/49 and https://github.com/snapcore/spread-cron/pull/48
[14:36] <mup> PR spread-cron#49: Task to build core snaps in launchpad <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/49>
[14:36] <mup> PR spread-cron#48: Adding commits information on snapd-vendor launchpad repo <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/48>
[14:36] <mvo> niemeyer: yeah, iirc we agreed on snapfs
[14:36] <kyrofa> ogra_, haha, no, but the way I test stuff on fedora is running fedora instances via lxd
[14:36] <ogra_> :)
[14:36] <kyrofa> ogra_, that experience was not great
[14:36] <mvo> niemeyer: did we ever write a forum post or something?
[14:36] <ogra_> i can imagine
[14:37] <cachio> mvo, ok, so we should go first to stable with the 2.28.1?
[14:37] <Eleventh_Doctor> kyrofa: I'll get you to switch to Fedora yet :P
[14:39] <Eleventh_Doctor> anyway guys, I gotta get going
[14:39] <Eleventh_Doctor> my day job awaits
[14:39] <mvo> cachio: I think it should not hold back core, I will investigate, we probably need a 2.28.2 for the SRU for zesty but that should be ok
[14:43] <niemeyer> mvo: I don't think so.. :(
[14:48] <diddledan> does snapd set the order of snaps to be mounted when it starts up? I appear to be seeing my system try to connect interfaces to core before core has been started and thus the interfaces are not present yet
[14:48] <pstolowski> niemeyer, hello! i hope you have a good sprint!
[14:49] <Eleventh_Doctor> WOO!
[14:49] <Eleventh_Doctor> my laptop is now repaired!
[14:49] <pstolowski> niemeyer, i've addressed the main point you had for #3972 and left some comments
[14:49] <mup> PR #3972: repo: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
[14:50] <cachio> mvo, ok, I'll promote to stable the 2.28.1 in that case
[14:51] <ikey> sooo i might've created the child of satan but
[14:51] <diddledan> :-o
[14:51] <ikey> i made a magic script that seems to be able to create a dist vendor tarball for snapd..
[14:52] <diddledan> devil child!
[14:52] <ppisati_> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1718886
[14:52] <mup> Bug #1718886: snapcraft.yaml: add dpkg-dev to the build deps <patch> <linux (Ubuntu):Confirmed> <snapcraft (Ubuntu):New> <linux (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Xenial):New> <https://launchpad.net/bugs/1718886>
[14:52] <ikey> diddledan, https://hastebin.com/fafolohoma.sql :P
[14:52] <ppisati_> sergiusens: actually i already found what the problem was, and there's a patch attached
[14:52] <ppisati_> sergiusens: but i'm not entirely sure of the fix
[14:57] <cachio> mvo, core snap 2.28.1 promoting to stable
[14:57] <mvo> cachio: thanks! time for a forum post - niemeyer do you want to do the forum post that announces 2.28.1?
[15:04] <mup> PR snapd#4017 opened: store: add download caching <Created by mvo5> <https://github.com/snapcore/snapd/pull/4017>
[15:05] <cachio> mvo, niemeyer promotion completed
[15:05] <mvo> cachio: \o/
[15:05] <cachio> mvo, testing the refresh on my machine
[15:07] <cachio> working \o/
[15:08] <sergiusens> ppisati_ thanks
[15:10] <sergiusens> ppisati_ weren't you having a problem with the `source` entry the week before last?
[15:16] <ppisati_> sergiusens: the build dir, src is ok, it's decompressed correctly there, but .config i thought wasn't being copied to the build dir
[15:16] <ppisati_> sergiusens: but it turned out it was copied, it's just that the kbuild plugin doesn't expect the .config to be already there
[15:17] <ppisati_> sergiusens: ah crap
[15:17] <ppisati_> sergiusens: i pasted you the wrong lp bug
[15:17] <ppisati_> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1722494
[15:17] <mup> Bug #1722494: .config disappears from build dir <Snapcraft:New> <https://launchpad.net/bugs/1722494>
[15:17] <ppisati_> sergiusens: sorry :(
[15:20] <kyrofa> Hey elopio, you around?
[15:20] <elopio> Hello
[15:21] <kalikiana> o/
[15:21] <kyrofa> elopio, good morning! I want to figure out a good solution for the slow ROS tests, one that scales
[15:22] <kyrofa> You mentioned labeling it as slow so that it doesn't run on travis, seems reasonable. But then they'd run on autopkgtests?
[15:22] <kyrofa> Or is that something that we still need to develop?
[15:23] <elopio> kyrofa: I'm exploring options. Trying to launch tests on the PPA daily, with some help in #ubuntu-release
[15:24] <kyrofa> elopio, okay good deal. Just let me know what to do on that ament PR once you've settled on a path?
[15:24] <elopio> kyrofa: that's my idea, not yet implemented because I don't yet know how. If you need to run a slow test, the bot can trigger it in a PR for you, no problem there.
[15:25] <kyrofa> Oh, we do have that today? That works fine for me
[15:25] <elopio> The problem is when you forget or don't know that you should trigger the.slow test.
[15:25] <elopio> Currently, the beta branch takes care of it, but poorly.
[15:25] <kyrofa> Fortunately the ros-related stuff is pretty obvious. I could see that being an issue with other stuff, of course
[15:26] <kyrofa> elopio, okay so I could label that test as "slow" today and just run the autopkgtests?
[15:26] <elopio> kyrofa I haven't pushed anything about slow tests yet. But can do it quickly after my two autopktests prs land.
[15:26] <elopio> Tomorrow
[15:26] <kyrofa> Ah ha, okay, sorry! P:
[15:27] <kyrofa> elopio, perfect
[15:27] <kyrofa> elopio, no huge rush, just trying to get a clear picture of what I can do
[15:27] <elopio> kyrofa would you like to comment on he pr "slow" or poke the bot in the chat?
[15:27] <kyrofa> elopio, definitely. You guys have been busy
[15:32] <elopio> kyrofa, sorry, I don't understand your answer. So you would like both?
[15:33] <kyrofa> elopio, haha, we're completely missing each other here, I'm not sure what "both" is :D
[15:34] <kyrofa> elopio, as I understand it, you're working on two things: daily autopkgtests on the daily PPA to replace the beta PR, and a "slow" filter to not run stuff on Travis. Right?
[15:34] <ackk> it seems some unittests fail if you have squasfuse installed
[15:35] <sborovkov> Hi, where is network config file on ubuntu core? (Want to check if interface is using dhcp or not from inside the snap)
[15:35] <ackk> because of Type=squashfs vs Type=fuse.squashfuse in systemd configs
[15:39] <elopio> kyrofa right. My question is how would you like to trigger the slow tests in your PR.
[15:39] <kyrofa> elopio, ohhh
[15:39] <kalikiana> ackk: what tests are those?
[15:40] <kalikiana> are you running in a container?
[15:40] <kyrofa> kalikiana, snapd ones I assume
[15:40] <kyrofa> elopio, I would rather have something on github than the chat, personally
[15:40] <elopio> sergiusens it seems I need to have upload permissions to trigger snapcraft PPA tests. I think I will apply to be per-package uploader for snapcraft.
[15:41] <elopio> kyrofa OK, I will add that to the todo
[15:41] <kalikiana> elopio: kyrofa Something akin to "Fixes: #1234" maybe? But probably more than just the word "slow"
[15:41] <mup> PR #1234: debian: make snapd get its environ from /etc/environment <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1234>
[15:41] <elopio> And probably, I should move the bot here.
[15:41] <kalikiana> +1
[15:42] <kyrofa> elopio, yeah something like that. Thinking that through, what would that do exactly: just trigger the autopkgtests?
[15:42] <kyrofa> elopio, is there a way to filter the autopkgtests? So that I could say "please run exactly THESE slow tests" rather than every single one?
[15:42] <elopio> Yup, and the autopkgtest will have an env var slow=true
[15:43] <elopio> Nop, filter specific tests is more work. Maybe next week ;)
[15:44] <elopio> I can add env vars for suite=snapd filter=ros
[15:47] <kyrofa> elopio, yeah, that would be cool
[15:47] <mup> PR snapd#4018 opened: interfaces: fix udev rules for tun <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4018>
[15:48] <kyrofa> But yeah, just being able to trigger from the commit would be nice. What happens when I push a new commit though, is there a way to remember "oh yeah, I need to run autopkgtests on this too" ?
[15:48] <kalikiana> ^^ I would've thought you can put it in the PR description
[15:49] <kalikiana> GitHub reads both comments and the description
[15:49] <kyrofa> kalikiana, yeah that would work
[15:49] <kyrofa> elopio, one last question: snapcraft#1591, do we agree that it doesn't buy us anything?
[15:49] <mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
[15:49] <Son_Goku> Hey
[15:49] <Son_Goku> mvo_, do you plan to put simplified highlights in the GitHub releases?
[15:50] <kalikiana> kyrofa: the better solution was the wait script, no?
[15:50] <kyrofa> kalikiana, no, it was stuuuupid
[15:50] <kalikiana> I saw another Pr timing out today
[15:50] <kyrofa> kalikiana, it just masks _all_ output
[15:51] <kyrofa> kalikiana, wait, timing out because it took more than ten minutes with no output?
[15:51] <kyrofa> kalikiana, i.e. stalled?
[15:51] <kyrofa> Son_Goku, I typically just look at the debian/changelog :P
[15:52] <Son_Goku> that's too verbose for updateinfo
[15:52] <Son_Goku> and mvo_ already publishes that as changelog entries for me ;)
[15:53] <Son_Goku> I guess I'll just make up something
[15:53] <Son_Goku> but I already have the "full" changes: https://koji.fedoraproject.org/koji/buildinfo?buildID=981596
[15:54] <sergiusens> elopio for adt? is that a new thing?
[15:54] <kalikiana> kyrofa: It was `test_stage_rust_with_source_subdir (test_rust_plugin.RustPluginTestCase) test_rust_plugin.RustPluginTestCase.test_stage_rust_with_source_subdir ... The job exceeded the maximum time limit for jobs, and has been terminated.`
[15:55] <kyrofa> kalikiana, yeah that's different
[15:55] <kyrofa> kalikiana, we can't fix that
[15:55] <kyrofa> kalikiana, that's Travis' maximum time for free service
[15:55]  * Son_Goku sighs
[15:55]  * Son_Goku wishes we used GitLab
[15:56] <kyrofa> Son_Goku, I dumped an annoying amount of time trying to see if I could tie github to gitlab ci
[15:56] <Son_Goku> I did it for one of my projects that's hosted on GitHub still
[15:56] <sergiusens> wait, not the PR description, we do not want to trigger them before the travis tests are green
[15:56] <sergiusens> elopio ^
[15:56] <Son_Goku> basically, set it up to mirror and let it run CI on mirror pulls
[15:56] <kalikiana> kyrofa: So... how come these work otherwise? Should we be splitting these up?
[15:56] <sergiusens> should be a comment, and the general practise should be, after the travis tests are green
[15:57] <kyrofa> kalikiana, if Travis' network barfs momentarily, it'll push some over the edge
[15:57] <Son_Goku> you can also write a custom webhook service to pull and push automatically
[15:57] <kyrofa> sergiusens, that's not something the bot can wait for?
[15:57] <sergiusens> kyrofa maybe
[15:57] <kyrofa> sergiusens, just talking idealisms here :P
[15:58] <kyrofa> sergiusens, elopio, kalikiana perhaps we should throw together a quick doc of our ideal, and then see what we can accomplish?
[15:58] <kyrofa> Rather, what we require, and how ideally it would work
[15:58] <sergiusens> forum post please
[15:58] <kalikiana> btw elopio can you please re-review? https://github.com/snapcore/snapcraft/pull/1577 https://github.com/snapcore/snapcraft/pull/1587 kyrofa maybe you can also have a look, a second reviewer is still needed
[15:58] <mup> PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
[15:58] <mup> PR snapcraft#1587: lifecycle: clean after deleting container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1587>
[15:59] <kyrofa> sergiusens, alright I'll put that on my TODO after pip/reviews
[15:59] <sborovkov> How to check if interface is using dhcp on snappy? anyone?
[16:00] <kalikiana> sergiusens: kyrofa This one needs a re-review from the two of you https://github.com/snapcore/snapcraft/pull/1412
[16:00] <mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
[16:03] <kyrofa> kalikiana, can you please write a description for snapcraft#1577 ? I'm not sure what problem it's solving/feature it's adding
[16:03] <mup> PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
[16:03] <kalikiana> sergiusens: I also addressed your comments on https://github.com/snapcore/snapcraft/pull/1546 though maybe it needs more discussion? Running define and search "locally" wasn't explicitly talked about I think. I don't know if there's potential conerns here
[16:03] <mup> PR snapcraft#1546: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546>
[16:04]  * zyga-ubuntu watches catalan news 
[16:04] <elopio> kyrofa yes, I think print stdout might be good, but not very useful right now. For container tests is probably a must have.
[16:04] <elopio> sergiusens it's for triggering autopktest on demand, tied to a PPA, not a PR.
[16:06] <elopio> And the bot can probably wait until Travis is done. Not sure how, but sounds doable. First iteration will be a human poller 😃
[16:08] <kalikiana> kyrofa: Oops, that was meant to have a forum link. I added the link and a summary of the issue now.
[16:10] <ikey> just seen this. https://git.launchpad.net/~osomon/+git/chromium-snap/commit/?id=0c573c3da6957d868f830fd923728dc13eba4e8d
[16:10] <ikey> bless
[16:11] <kalikiana> I read `Clear Santa` there, wondering for a moment what that meant
[16:12] <ikey> hah
[16:17] <niemeyer> mvo_: I have a bunch of happy people here about 2.28 :)
[16:18] <niemeyer> zyga-ubuntu: Review on #3999
[16:18] <mup> PR #3999: cmd/snap-confine: add detection of stale mount namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/3999>
[16:18] <niemeyer> Will follow on when I find another break
[16:19] <mvo_> niemeyer: yay! great to hear
[16:19] <zyga-ubuntu> niemeyer: thank you
[16:19] <niemeyer> zyga-ubuntu: np, and as I said there, happy to see this moving forward, thanks!
[16:23] <zyga-ubuntu> niemeyer: thanks, I'll update the PR and will land it shortly
[16:24]  * zyga-ubuntu is super nervous to see what is going on in catalonia now, worried about friends :/
[16:26] <zyga-ubuntu> mvo_: 4018 merged now, can be cherry-picked
[16:27] <mup> PR snapd#4018 closed: interfaces: fix udev rules for tun <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4018>
[16:29] <ackk> niemeyer, finally managed to update https://github.com/snapcore/snapd/pull/3916 with the changes you requested
[16:29] <mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
[16:32] <zyga-ubuntu> mvo_: do you need a backport for 2.28?
[16:32] <zyga-ubuntu> or will you do locally
[16:36] <kalikiana> FYI going to wrap up for the day in the next 30min
[16:38] <mvo_> zyga-ubuntu: I can do it locally (cherry-pick). looks like the tests are stuck right now :/
[16:38] <mvo_> zyga-ubuntu: aha, not the tests the travis display, thanks for merging it
[16:46] <mup> PR snapd#4016 closed: progress: be more flexible in testing ansimeter <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4016>
[16:47] <mvo_> zyga-ubuntu: 2.28.2 is uploaded to the PPA with the fix for https://github.com/snapcore/snapd/pull/4018
[16:47] <mup> PR #4018: interfaces: fix udev rules for tun <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4018>
[16:48]  * zyga-ubuntu hugs mvo_ 
[16:48] <zyga-ubuntu> thank you :)
[16:49] <mup> PR snapd#4019 opened: release: snapd 2.28.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4019>
[16:50] <mvo_> zyga-ubuntu: *thank you* and koza of course
[16:53] <mvo_> zyga-ubuntu: I get dinner now, once the build finishes  Iwill build a new core
[16:54] <zyga-ubuntu> ok
[16:54] <zyga-ubuntu> I'm working on more spread test
[17:19] <kalikiana> elopio: I got `exceeded the maximum time limit for jobs` twice in a row here... https://github.com/snapcore/snapcraft/pull/1512 :-(
[17:19] <mup> PR snapcraft#1512: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512>
[17:21]  * kalikiana leaving it at that for now
[17:27] <elopio> kalikiana: yes, that job is now too big. We have to improve it.
[17:30] <elopio> sergiusens: please land this: https://github.com/snapcore/snapcraft/pull/1598
[17:30] <elopio> and then this: https://github.com/snapcore/snapcraft/pull/1595
[17:30] <mup> PR snapcraft#1598: recording: do not crash when snapd is not installed <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1598>
[17:30] <mup> PR snapcraft#1595: tests: fix the skip of snapd integration tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1595>
[17:30] <elopio> sergiusens: and I think we are good to release. Or at least, good to find any other blockers.
[17:31] <sergiusens> elopio great
[17:32] <mup> PR snapcraft#1598 closed: recording: do not crash when snapd is not installed <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1598>
[17:33] <kalikiana> elopio:  Do you have a plan for that yet? It looks to be blocking my PR now
[17:34] <elopio> kalikiana: we have to review all the tests in that suite. Some can be demoted to unit tests, some are better in the snapd integration suite. Some are just running more steps than needed.
[17:35] <elopio> I don't think we have any tests that take more than 10 minutes in there, but if we do, they should be tagged as slow.
[17:35] <elopio> and, if everything fails, ask for money to pay for more travis time.
[17:43] <kalikiana> I guess by adding another Go integration test I'm just causing the kettle to bubble over...
[17:45] <kalikiana> Actually no, I'm not even adding one there, just modifying the check
[17:45] <kalikiana> Hrm
[17:50] <mvo_> cachio: snapd 2.28.2 is ready in the beta channel for a new round of testing. fixes a tiny issue in the tun udev rules and a bugfix in the dhcp code on core when the IP address changes between dhcp leases
[17:52] <cachio> mvo_, perfect
[17:53] <cachio> I'll start now
[17:55] <mvo_> cachio: thanks a bunch
[17:55] <mvo_> cachio: I will do a SRU upload based on this one now, I don't see the ppc64 compile error with 2.28.2 in my test ppa so fingers crossed
[17:56] <cachio> mvo_, perfect
[18:45] <elopio> snappy-m-o help
[18:45] <snappy-m-o> All commands
[18:45] <snappy-m-o>  AutopkgtestGithub
[18:45] <snappy-m-o>  Trigger the autopkgtests for GitHub pull requests.
[18:45] <snappy-m-o> • snappy-m-o /autopkgtest - (undocumented)
[18:45] <snappy-m-o>  Backup
[18:45] <snappy-m-o>  Backup related commands.
[18:45] <snappy-m-o> • snappy-m-o /backup - Backup everything.
[18:45] <snappy-m-o>  ChatRoom
[18:45] <snappy-m-o>  This is a basic implementation of a chatroom
[18:45] <snappy-m-o> • snappy-m-o /room join - Join (creating it first if needed) a chatroom.
[18:45] <snappy-m-o> • snappy-m-o /room leave - Leave a chatroom.
[18:45] <snappy-m-o> • snappy-m-o /room topic - Get or set the topic for a room.
[18:45] <snappy-m-o> • *snappy-m-o /room invite
[18:45] <snappy-m-o> • • Invite one or more people into a chatroom.
[18:45] <snappy-m-o> • snappy-m-o /room occupants - List the occupants in a given chatroom.
[18:45] <snappy-m-o> • snappy-m-o /room list - List chatrooms the bot has joined.
[18:45] <snappy-m-o> • snappy-m-o /room destroy - Destroy a chatroom.
[18:45] <snappy-m-o> • snappy-m-o /room create - Create a chatroom.
[18:45] <snappy-m-o>  Flows
[18:45] <snappy-m-o>  Management commands related to flows / conversations.
[18:45] <snappy-m-o> • snappy-m-o /flows status - Displays the list of started flows.
[18:45] <snappy-m-o> • snappy-m-o /flows start - Manually start a flow within the context of the c
[18:45] <snappy-m-o> alling user.
[18:45] <snappy-m-o> - snappy-m-o /flows stop - Stop flows you are in.
[18:45] <snappy-m-o> - snappy-m-o /flows kill - usage: flows_kill [-h] user flow_name
[18:45] <snappy-m-o> - snappy-m-o /flows show - Shows the structure of a flow.
[18:45] <snappy-m-o> - snappy-m-o /flows list - Displays the list of setup flows.
[18:45] <snappy-m-o>  Health
[18:45] <snappy-m-o>  Core plugin for bot lifecycle and health related commands.
[18:45] <snappy-m-o> • snappy-m-o /restart - Restart the bot.
[18:45] <snappy-m-o> • snappy-m-o /uptime - Return the uptime of the bot
[18:45] <snappy-m-o> • snappy-m-o /status gc - shows the garbage collection details
[18:45] <snappy-m-o> • **
[18:45] <snappy-m-o> snappy-m-o /status load - shows the load status
[18:45] <snappy-m-o> - snappy-m-o /status - If I am alive I should be able to respond to this one
[18:45] <snappy-m-o> - snappy-m-o /shutdown - usage: shutdown [-h] [--kill] [--confirm]
[18:45] <snappy-m-o> - snappy-m-o /status plugins** - shows the plugin status
[18:45] <snappy-m-o>  Help
[18:45] <snappy-m-o>  Core plugin of help related functions.
[18:45] <snappy-m-o> • snappy-m-o /apropos - Returns a help string listing available options.
[18:45] <snappy-m-o> • snappy-m-o /about - Return information about this Errbot instance and version
[18:45] <snappy-m-o> • snappy-m-o /help - Returns a
[18:45] <snappy-m-o> help string listing available options.
[18:45] <snappy-m-o>  Plugins
[18:45] <snappy-m-o>  Commands to manage the plugins of the bot by chatting.
[18:45] <nacc> elopio: fun.
[18:45] <snappy-m-o> • snappy-m-o /repos install - install a plugin repository from the given source or a known public repo (see...
[18:45] <snappy-m-o> • snappy-m-o /plugin blacklist - Blacklist a plugin so that it will not be loaded automatically during bot sta...
[18:45] <snappy-m-o> • snappy-m-o /repos search - Searches the repo index.
[18:45] <snappy-m-o> • snappy-m-o /plugin config - configure or get the configuration / configuration template for a specific
[18:45] <snappy-m-o> pl...
[18:45] <snappy-m-o> - snappy-m-o /repos update - update the bot and/or plugins
[18:45] <snappy-m-o> - snappy-m-o /plugin activate - activate a plugin. [calls .activate() on the plugin]
[18:46] <snappy-m-o> - snappy-m-o /plugin unblacklist - Remove a plugin from the blacklist
[18:46] <snappy-m-o> - snappy-m-o /plugin deactivate - deactivate a plugin. [calls .deactivate on the plugin]
[18:46] <snappy-m-o> - snappy-m-o /plugin reload - reload a plugin: reload the code of the plugin leaving the activation status ...
[18:46] <snappy-m-o> - snappy-m-o /repos - list the current active plugin repositories
[18:46] <snappy-m-o> • snappy-m-o /repos uninstall - uninstall a plugin repository by name.
[18:46] <snappy-m-o>  SnapcraftGithub
[18:46] <snappy-m-o>  Handle GitHub webhooks from the snapcraft repository.
[18:46] <snappy-m-o> • snappy-m-o /github build - usage: github_build [-h] pull_request_number
[18:46] <snappy-m-o> • snappy-m-o /github subscribe - usage: github_subscribe [-h] pull_request_number
[18:46] <snappy-m-o>  Utils
[18:46] <snappy-m-o>  Core Errbot utils commands.
[18:46] <snappy-m-o> • snappy-m-o /render test - Tests / showcases the markdown rendering on your current backend
[18:46] <snappy-m-o> • snappy-m-o /history - display the command his
[18:46] <snappy-m-o> tory
[18:46] <snappy-m-o> - snappy-m-o /whoami - A simple command echoing the details of your identifier. Useful to debug iden...
[18:46] <snappy-m-o> - snappy-m-o /echo - A simple echo command. Useful for encoding tests etc ...
[18:46] <snappy-m-o> - snappy-m-o /log tail - Display a tail of the log of n lines or 40 by default
[18:46]  * nacc wonders why Drone hasn't kicked in yet :)
[18:46] <elopio> wow, I didn't know it was that long.
[18:46] <elopio> snappy-m-o /autopkgtest 1583 xenial:amd64
[18:46] <snappy-m-o> Command "" / " /autopkgtest" not found.
[18:46] <snappy-m-o>  Did you mean "snappy-m-o /autopkgtest" ?
[18:47] <elopio> what???
[18:47] <elopio> snappy-m-o autopkgtest 1583 xenial:amd64
[18:47] <snappy-m-o> @elopio: I've just triggered your test.
[18:47] <nothal> snappy-m-o: No such command!
[18:47] <snappy-m-o> Command ":" / ": No" not found.
[18:47] <nacc> lol
[18:47] <elopio> ok, almost there :D
[18:48] <nacc> This definitely reads like a HAL9000 problem.
[18:52] <elopio> snappy-m-o subscribe 1583
[18:52] <snappy-m-o> Command "" / " subscribe" not found.
[18:52] <snappy-m-o>  Did you mean "snappy-m-o /github subscribe" ?
[18:52] <elopio> yes, I meant that, but without the slash apparently
[18:53] <elopio> snappy-m-o github subscribe 1583
[18:53] <snappy-m-o> You're not allowed to access this command from this user
[18:58] <elopio> snappy-m-o github subscribe 1583
[18:58] <snappy-m-o> elopio: I'll send you a message if a test fails in the pull request #1583 (ament plugin: new plugin).
[18:58] <mup> PR #1583: snap: remove meta/kernel.yaml again <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1583>
[18:58] <elopio> snapcraft#1583
[18:58] <mup> PR snapcraft#1583: ament plugin: new plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1583>
[19:17] <mup> PR snapcraft#1601 opened: snapcraft.yaml: don't die if build dir exists <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1601>
[19:17] <kyrofa> elopio, easiest review on the planet ^^ . Enables building the snap from src
[19:32] <kyrofa> sergiusens, the snapcraft snap contains both python3.5 and 3.6. Is there a forgotten filter on the 3.5 coming from the snapcraft part?
[20:27] <mup> PR snapcraft#1602 opened: tests: add the slow tag for ros snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1602>
[20:30] <elopio> kyrofa: almost there ^ I have to wait 10 minutes every time I make a typo, so I pushed it for you to review.
[20:30] <kyrofa> Hahaha
[20:49] <mwhudson> cjwatson: awesome, thanks
[20:49] <mwhudson> !
[20:55] <Peyam> hi
[20:55] <jdstrand> niemeyer: hey, stgraber has a stop the line issue I think with lxd and 2.28 regression
[20:55] <Peyam> Im trying to uninstall qucs-s from my distro
[20:55] <Peyam> nothing happens
[20:55] <jdstrand> niemeyer: he can give the details
[20:56] <stgraber> niemeyer: with the latest stable core snap update, the "lxd:lxd" interface is now considered invalid, causing anything that would otherwise be connected to it to be dropped
[20:57] <Peyam> this is what Happen when I try to uninstall qucs-spice in software center: Detailed errors from the package manager follow:
[20:57] <Peyam> snapd returned status code 400: Bad Request
[20:57] <stgraber> I just noticed it when the Ubuntu Core server running the backend for the online LXD demo dropped offline, investigating the reason I saw it rebooted an hour ago for a core snap change and lxd-demo-server couldn't connect to lxd anymore
[20:58] <stgraber> as a workaround I just upgraded that server to the edge channel for the core snap which gives me a git build of snapd that includes jdstrand's fix
[20:59] <Peyam> anyone?
[21:06] <jdstrand> niemeyer: that fix was https://github.com/snapcore/snapd/pull/4004
[21:06] <mup> PR #4004: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004>
[21:09] <AlbertA> is there a way to specify lightweight checkouts for bzr source types?
[21:10] <elopio> kyrofa: any idea why ros-example.launch-project --help could be failing on that test? I might be a little tired now, but I don't understand the problem.
[21:10] <elopio> manually it works.
[21:10] <kyrofa> elopio, I see no failures at the moment, you must have restarted it. However, I notice that you removed the absolute path. Could that have anything to do with it?
[21:10] <elopio> ohh, I see  cannot change current working directory to the original directory:
[21:11] <kyrofa> Oh, in /tmp?
[21:13] <elopio> yes, we are in /tmp
[21:17] <kyrofa> How does anything _else_ work?
[21:20] <elopio> kyrofa: I don't know. Sometimes things work on tmp, sometimes they don't
[21:21] <elopio> ```/tmp$ ros-example.launch-project --help
[21:21] <elopio> Usage: roslaunch
[21:21] <elopio> ```
[21:22] <elopio> oh well, I have no idea how to paste this from riot to irc. But the idea is that it works manually, when I'm in /tmp. Now trying with the test after chdir to home.
[21:26] <zyga-solus> jdstrand: so PR 4004 needs to go into 2.28.3?
[21:26] <mup> PR #4004: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004>
[21:27] <kyrofa> Huh. I can never do stuff out of /tmp
[21:39] <mup> PR snapcraft#1603 opened: tests: add /snap/bin to PATH in autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1603>
[21:51] <elopio> snappy-m-o autopkgtest 1603 xenial:amd64
[21:51] <snappy-m-o> elopio: I've just triggered your test.
[21:58] <nacc> elopio: nice
[21:58] <nacc> elopio: although snappy-m-o said that before too :)
[22:12] <Chipaca> snappy-m-o: dance for me
[22:12] <snappy-m-o> Command ":" / ": dance" not found.
[22:12] <Chipaca> snappy-m-o: improve your error messages
[22:12] <snappy-m-o> Command ":" / ": improve" not found.
[22:12] <Chipaca> snappy-m-o: ok, ok, so: first, improve your sentience
[22:12] <snappy-m-o> Command ":" / ": ok," not found.
[22:12] <nacc> Chipaca: heh
[22:12] <elopio> you are breaking him. :'(
[22:12]  * Chipaca knows the singularity will be averted by a misquoted string
[22:13] <Chipaca> snappy-m-o: how many tests would autopkgtest test if autopkgtest could test tests?
[22:13] <snappy-m-o> Command ":" / ": how" not found.
[22:14]  * Chipaca ~> z
[22:31] <elopio> snappy-m-o autopkgtest 1602 xenial:amd64 xenial:armhf xenial:arm64 artful:amd64
[22:31] <snappy-m-o> elopio: I've just triggered your test.
[22:31] <elopio> thank you my friend!
[22:39] <kyrofa> snappy-m-o, it's nice to see you here. You were so annoying in telegram
[22:39] <snappy-m-o> Command "," / ", it's" not found.
[22:39] <elopio> not less annoying here :)
[22:40] <cjwatson> any reason why people who don't actively need to use its services shouldn't ignore the bot?
[22:40] <cjwatson> (I already ignore several other bots)
[22:40] <elopio> this room is full of bots, so I couldn't just let it take the / commands. And apparently, it's not prepared for any of the alternatives.
[22:41] <elopio> cjwatson: it's a phase, it will pass...
[22:43] <cjwatson> elopio: sure; what I want to know is does it provide anything useful to people who aren't actively driving it
[22:43] <cjwatson> if it doesn't I will ignore it
[22:45] <elopio> cjwtason: you can just ignore until you have to test a snapcraft pull request in arm.
[22:57] <elopio> snappy-m-o autopkgtest 1595 xenial:armhf xenial:arm64 xenial:amd64
[22:57] <snappy-m-o> elopio: I've just triggered your test.