[00:51] PR snapcraft#1598 opened: recording: do not crash when snapd is not installed [01:16] PR snapd#4006 closed: snap-exec: update tests to follow main_test pattern [02:30] PR snapcraft#1589 closed: Update default node engine to 6.11.3 [02:58] 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] on ppc64el only, i should add === JoshStrobl is now known as JoshStrobl|zzz [06:49] good morning [06:50] today is another cgroup day, hopefully one with fewer disappointments [07:04] good morning [07:04] o/ [07:05] hmmm two of my PRs have landed, this is a good start [07:06] zyga-solus: how's your poleflu? (I think that's what you called it :-P) [07:10] kalikiana: thank you, I feel much better now [07:10] kalikiana: getting into the habit of using longe sleeves and other warm-keeping stuff helps [07:11] kalikiana: I really miss the sun, it's almost winter here [07:11] kalikiana: rain will just turn to snow one day (any day) [07:12] yeah, sunny days are over it seems :-( [08:06] 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] PR snapcraft#1348: repo: setup a foreign arch and sources [08:06] PR snapcraft#1382: rust plugin: make libc configurable [08:17] PR snapd#3964 closed: many: implement our own ANSI-escape-using progress indicator [09:26] help [09:27] 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] i am using Dell gateways 5000 and try to connect my mobile via bluetooth for sending data [09:28] but when i enter connect it gives error "org.bluez.error failes" [09:28] fasorry failed [09:34] PR snapcraft#1599 opened: Fixed StoreReleaseError format for BAD REQUEST error [09:42] ackk: hey [09:42] ackk: it's coming along but it's not ready [09:42] ackk: pstolowski is working on interface hooks that fire when you connect/disconnect things [09:44] zyga-ubuntu, ah, I see [09:44] 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] that's fine [09:49] yes [09:49] zyga-ubuntu, ok, thanks [10:44] * kalikiana short break [11:03] * zyga-ubuntu -> break [11:31] sliff [11:47] re [11:59] 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] PR snapd#4015 opened: run-checks: use nakedret to check for naked returns on long functions [12:33] mwhudson: investigated: https://github.com/snapcore/snapcraft/pull/1600 [12:33] PR snapcraft#1600: options: fix core-dynamic-linker on ppc64el/s390x [12:34] PR snapcraft#1600 opened: options: fix core-dynamic-linker on ppc64el/s390x === facundo__ is now known as facubatista [13:02] __chip__: standup? [13:02] __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] __chip__: also, whats up with this nick? is this the new default === JoshStrobl|zzz is now known as JoshStrobl [13:11] Yo [13:11] man, it sucks not having my main laptop [13:11] I have to remember all the IRC channels I'm active in and add them [13:11] and worse than that you're not even the 9th or 10th.. [13:11] * ikey feels for you. [13:12] erm. i mean *hi :) [13:12] haha [13:12] well, at least you got it :) [13:12] aye :] === Eighth_Doctor is now known as Eleventh_Doctor [13:13] this laptop is configured with an older version of my profile [13:13] I carried it forward from various IRC clients and various laptops before I started over on the new laptop [13:15] my Linux laptop has always used some variation of this nick ;) [13:16] I've never been a huge fan of the 9th [13:16] the 10th is awesome, though === Eleventh_Doctor is now known as Tenth_Doctor [13:16] the elleventh is still my favourite === Tenth_Doctor is now known as Eleventh_Doctor [13:16] mine too [13:17] kalikiana closed them because they had no changes in 2 weeks++ and failing tests [13:17] sergiusens: That's not true. They had commits in the last few days [13:20] kalikiana "kalikiana added some commits 18 days ago " [13:21] on both of those [13:21] sergiusens: it lists by author date [13:21] which is irrelevant [13:21] if you amend commits, that date doesn't change [13:22] ah, that can make sense Eleventh_Doctor [13:23] 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] kalikiana you still have many PRs open, focus on fixing them one by one instead of all at once [13:23] so I rewrite the author dates every time now [13:23] as you may be eating up the travis qutoa for everyone else [13:23] kalikiana or do them all in parallel, but run the suite locally [13:23] the full suite [13:23] zyga-solus: ping [13:24] sergiusens: Well, the local runs aren't the problem, I'm getting killed by false negatives... [13:24] Eleventh_Doctor it is so hard to keep track of your irc handles! ;-) [13:24] well, I really don't use this laptop very much [13:24] so these nicks don't show up often [13:24] Eleventh_Doctor finally off the mac ;-) [13:25] oh, this is a Mac [13:25] it just runs Linux ;) [13:25] 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] this MacBook has been running Fedora for the last two years [13:25] Chipaca: http://paste.ubuntu.com/25713767/ [13:25] it's much more performant than it was when it ran Mac OS X [13:25] Chipaca: fwiw, the error looks "interessting" [13:26] kalikiana document that analysis in the PR so everyone is aware of it then and find the root cause [13:26] Chipaca: I mean, something with the bytes download counting is wrong 95B vs 99B [13:26] hah [13:26] i wondered about that while writing the test [13:26] Eleventh_Doctor: hey [13:27] and then thought "nah, it can't be so slow as to be less than this" [13:27] zyga-ubuntu: I pushed snapd updates, I need karma! [13:27] Eleventh_Doctor: aha, I'll look at F26 then [13:27] Eleventh_Doctor: what's this nickname about? :D [13:28] mvo: easy to fix. Will fixing master be enough? [13:28] zyga-ubuntu: this is my Linux laptop [13:28] Eleventh_Doctor: oh, nice, a new one? [13:28] with more or less my original IRC configuration carried through various laptops/clients [13:28] actually, this is my oldest laptop that still works [13:28] a 2009 MacBook Pro [13:28] but instead of Mac OS X, it runs Fedora [13:29] I wiped it as soon as the warranty ran out [13:29] pffft warranty [13:30] well, with the proprietarization of laptop components, it's gotten really hard to service them myself :( [13:30] and a lot of laptop warranties void on changing the OS [13:31] (which is dumb and potentially illegal, but there's not a lot I can do) [13:32] Chipaca: yes [13:32] zyga-ubuntu: snapd v2.28.1 with the backport of the distro check fixes [13:33] https://bodhi.fedoraproject.org/updates/?packages=snapd [13:33] Eleventh_Doctor: huh? and is apple really doing thaT? [13:33] zyga-ubuntu: Yes [13:33] Eleventh_Doctor: can you point me to where it says so? [13:33] because that's definitely not legal in EU [13:34] it may be US specific :( [13:34] it's not legal per-se in the US either [13:34] but Apple retains the right to refuse servicing for any reason [13:34] my next go around, I'm probably picking up a Dell XPS [13:35] they're turning into nice beefy laptops while remaining really lightweight [13:35] they ship with Ubuntu or Windows, but that can be easily fixed :) [13:36] Eleventh_Doctor: I'd be surprised if apple really refused that but IDK [13:36] it's usually not Apple directly that refuses [13:36] but the service centers that aren't operated by Apple [13:37] also, removing macOS removes the necessary bits for service center diagnostics to run [13:37] because apparently that's a thing [13:37] which is why they ask for admin credentials to the laptop :/ [13:38] Eleventh_Doctor: eh, I know that last bit, I refused [13:38] (and they did service me) [13:41] I used to leave it dual-booted with an empty and useless macOS [13:47] ppisati_ hey, what was your bug again? I will have time to fix it today [13:55] mvo: snapd#4016 is the fix [13:55] PR #4016: progress: be more flexible in testing ansimeter [13:55] Chipaca: thanks a bunch [13:55] PR snapd#4016 opened: progress: be more flexible in testing ansimeter [13:56] Chipaca: eh, thanks a lot [13:56] Chipaca: sorry, I learned the difference between "thanks a bunch" and "thanks a lot" only recently. anyway, thanks :) [13:57] you know [13:57] I find it hard to name test snaps [13:57] test1 [13:57] test2 [13:58] :P [13:58] I think it would help if we could have a local name in the directory with the task [13:58] right, if those were local and would not compete with other "snap testing interfaces" it'd be easier [13:58] 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] on ppc [13:59] the rest is working properly [13:59] cachio: yeah, I just tried to find the root cause but failed so far [13:59] 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] spineau: it isn't on my radar, but it would be worth bringing up on the forum. [14:00] jamesh: ok, I see. thanks [14:11] mvo: what difference between thanks a bunch and a lot have you learned? [14:12] 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] Chipaca: but maybe its just specific parts of the world where it is used like this [14:13] mvo: it has different meanings depending on tone [14:13] in the US, it's primarily not used sarcastically [14:13] but in the east coast, it is [14:13] Eleventh_Doctor: aha, that is interessting [14:13] mvo: both can be used sarcastically. It depends on the tone [14:13] thanks is often used sarcastically [14:13] geh, english is a complicated language :) [14:13] something irc doesn't convey very well [14:13] thanks jamesh [14:13] :/ [14:14] jamesh: yeah, irc lacks the nuances :-D [14:14] if you think English is bad, Japanese is way worse [14:14] the *whole* reason for emoji is to deal with that problem [14:14] Eleventh_Doctor: heh, fun! [14:15] and of course, emoticons have been used in text long before computers for the same reason [14:15] but Japanese has the special problem of conveying meaning and feeling almost entirely through tone [14:16] they don't have emotion words, per se like English does [14:16] so there's not an explicit set of "profane" words [14:16] the *way* you say it turns certain words "profane" [14:20] 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] OTOH, https://en.wiktionary.org/wiki/thanks_a_bunch [14:21] "thanks a lot" is the American equivalent to "thanks a bunch" [14:21] says UK usage is unambiguously sarcastic, which is news to me (but then maybe i should go out more) [14:21] UK uses thanks a bunch entirely sarcastically [14:21] but outside of the east coast in the US, it's not necessarily so [14:22] the *only* reason it is that way in the east coast is due to the stronger European heritage there [14:22] but "thanks a lot" is unambiguously sarcastic in most of the US [14:22] silly UKans, going over there, UKing the place up [14:23] this is primarily because "a bunch" is rarely used in the US [14:23] "a lot" is the primary form [14:23] the UK reverses this, since "a lot" isn't used very much there [14:23] the bottom line is: never thank anybody for anything [14:24] yeah, it sounds like it - meh :/ [14:24] I guess a simple "thanks" is what I should remember [14:24] ;) [14:24] mvo: go with "gramercy" [14:25] "thanks", "thank you" work well enough [14:25] then everybody will have to look it up, giving you time to run away [14:28] o/ [14:28] hey niemeyer! how are you? [14:28] 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] mvo: Pretty good, thanks [14:29] 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] niemeyer: squashfs-fuse did not land, lets push it high on the stack [14:30] niemeyer: will you update the roadmap with the new item(s)? [14:30] mvo: I'd like to talk about it first [14:30] mvo: wait, what? [14:30] what's this about squashfuse support not landing? [14:30] 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] mvo: Ugh.. man.. how did we forget that again :( [14:31] Shame on us [14:31] niemeyer: high-level> sounds good [14:31] niemeyer: yes :( [14:32] 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] Eleventh_Doctor: It's just about making it easier to work with.. won't affect you [14:32] mostly for lxd [14:32] ah [14:32] mvo: Thank you! 2.29 it is then [14:33] well, that already landed for Fedora snapd ;) [14:33] mainly because kyrofa asked for it and actually did the work to make it possible in Fedora [14:33] Eleventh_Doctor: nice - btw, is that you Neal? if so, you have too many nicks ;) [14:33] yes [14:33] is kyrofa secretly using fedora now instead of ubuntu ? [14:33] :) [14:33] (because he gets the features faster there) [14:33] :D [14:34] he's also working on packaging LXD for Fedora [14:34] whee ! [14:34] so that we have it properly integrated with container-selinux [14:34] Eleventh_Doctor: heh, do you have more nicks that I should be aware of :) ? [14:34] umm... [14:34] 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] mvo, evey nick you dont recognize :) [14:34] just check my netmask [14:34] just assume it is neal [14:34] it should always say ngompa/fedora [14:34] err, fedora/ngompa [14:35] cachio, thanks! [14:35] I also submitted a PR to container-selinux to add LXD support: https://github.com/projectatomic/container-selinux/pull/42 [14:35] PR projectatomic/container-selinux#42: Add support for LXD [14:35] mvo: Just recalling, we'll do it as a "snapfs" right? [14:36] 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] 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] PR spread-cron#49: Task to build core snaps in launchpad [14:36] PR spread-cron#48: Adding commits information on snapd-vendor launchpad repo [14:36] niemeyer: yeah, iirc we agreed on snapfs [14:36] ogra_, haha, no, but the way I test stuff on fedora is running fedora instances via lxd [14:36] :) [14:36] ogra_, that experience was not great [14:36] niemeyer: did we ever write a forum post or something? [14:36] i can imagine [14:37] mvo, ok, so we should go first to stable with the 2.28.1? [14:37] kyrofa: I'll get you to switch to Fedora yet :P [14:39] anyway guys, I gotta get going [14:39] my day job awaits [14:39] 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] mvo: I don't think so.. :( [14:48] 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] niemeyer, hello! i hope you have a good sprint! [14:49] WOO! [14:49] my laptop is now repaired! [14:49] niemeyer, i've addressed the main point you had for #3972 and left some comments [14:49] PR #3972: repo: sanitize plugs and slots early in ReadInfo [14:50] mvo, ok, I'll promote to stable the 2.28.1 in that case [14:51] sooo i might've created the child of satan but [14:51] :-o [14:51] i made a magic script that seems to be able to create a dist vendor tarball for snapd.. [14:52] devil child! [14:52] sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1718886 [14:52] Bug #1718886: snapcraft.yaml: add dpkg-dev to the build deps [14:52] diddledan, https://hastebin.com/fafolohoma.sql :P [14:52] sergiusens: actually i already found what the problem was, and there's a patch attached [14:52] sergiusens: but i'm not entirely sure of the fix [14:57] mvo, core snap 2.28.1 promoting to stable [14:57] cachio: thanks! time for a forum post - niemeyer do you want to do the forum post that announces 2.28.1? [15:04] PR snapd#4017 opened: store: add download caching [15:05] mvo, niemeyer promotion completed [15:05] cachio: \o/ [15:05] mvo, testing the refresh on my machine [15:07] working \o/ [15:08] ppisati_ thanks [15:10] ppisati_ weren't you having a problem with the `source` entry the week before last? === cachio is now known as cachio_lunch [15:16] 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] 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] sergiusens: ah crap [15:17] sergiusens: i pasted you the wrong lp bug [15:17] sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1722494 [15:17] Bug #1722494: .config disappears from build dir [15:17] sergiusens: sorry :( [15:20] Hey elopio, you around? [15:20] Hello [15:21] o/ [15:21] elopio, good morning! I want to figure out a good solution for the slow ROS tests, one that scales [15:22] 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] Or is that something that we still need to develop? [15:23] kyrofa: I'm exploring options. Trying to launch tests on the PPA daily, with some help in #ubuntu-release [15:24] elopio, okay good deal. Just let me know what to do on that ament PR once you've settled on a path? [15:24] 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] Oh, we do have that today? That works fine for me [15:25] The problem is when you forget or don't know that you should trigger the.slow test. [15:25] Currently, the beta branch takes care of it, but poorly. [15:25] Fortunately the ros-related stuff is pretty obvious. I could see that being an issue with other stuff, of course [15:26] elopio, okay so I could label that test as "slow" today and just run the autopkgtests? [15:26] kyrofa I haven't pushed anything about slow tests yet. But can do it quickly after my two autopktests prs land. [15:26] Tomorrow [15:26] Ah ha, okay, sorry! P: [15:27] elopio, perfect [15:27] elopio, no huge rush, just trying to get a clear picture of what I can do [15:27] kyrofa would you like to comment on he pr "slow" or poke the bot in the chat? [15:27] elopio, definitely. You guys have been busy [15:32] kyrofa, sorry, I don't understand your answer. So you would like both? [15:33] elopio, haha, we're completely missing each other here, I'm not sure what "both" is :D [15:34] 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] it seems some unittests fail if you have squasfuse installed [15:35] 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] because of Type=squashfs vs Type=fuse.squashfuse in systemd configs [15:39] kyrofa right. My question is how would you like to trigger the slow tests in your PR. [15:39] elopio, ohhh [15:39] ackk: what tests are those? [15:40] are you running in a container? [15:40] kalikiana, snapd ones I assume [15:40] elopio, I would rather have something on github than the chat, personally [15:40] 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] kyrofa OK, I will add that to the todo [15:41] elopio: kyrofa Something akin to "Fixes: #1234" maybe? But probably more than just the word "slow" [15:41] PR #1234: debian: make snapd get its environ from /etc/environment [15:41] And probably, I should move the bot here. [15:41] +1 [15:42] elopio, yeah something like that. Thinking that through, what would that do exactly: just trigger the autopkgtests? [15:42] 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] Yup, and the autopkgtest will have an env var slow=true [15:43] Nop, filter specific tests is more work. Maybe next week ;) [15:44] I can add env vars for suite=snapd filter=ros [15:47] elopio, yeah, that would be cool [15:47] PR snapd#4018 opened: interfaces: fix udev rules for tun === JoshStrobl is now known as JoshStrobl|Food [15:48] 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] ^^ I would've thought you can put it in the PR description [15:49] GitHub reads both comments and the description [15:49] kalikiana, yeah that would work [15:49] elopio, one last question: snapcraft#1591, do we agree that it doesn't buy us anything? [15:49] PR snapcraft#1591: snapd integration tests: print stdout/stderr [15:49] Hey [15:49] mvo_, do you plan to put simplified highlights in the GitHub releases? [15:50] kyrofa: the better solution was the wait script, no? [15:50] kalikiana, no, it was stuuuupid [15:50] I saw another Pr timing out today [15:50] kalikiana, it just masks _all_ output [15:51] kalikiana, wait, timing out because it took more than ten minutes with no output? [15:51] kalikiana, i.e. stalled? [15:51] Son_Goku, I typically just look at the debian/changelog :P [15:52] that's too verbose for updateinfo [15:52] and mvo_ already publishes that as changelog entries for me ;) [15:53] I guess I'll just make up something [15:53]