[00:00] <kyrofa> mwhudson, oh yes that sounds fun
[02:45] <sergiusens> kyrofa about pre and post, there's a very long forum post about that!
[02:46] <sergiusens> kyrofa so what is the veredict on https://github.com/snapcore/snapcraft/pull/1626 ? Or maybe elopio...
[02:46] <mup> PR snapcraft#1626: lifecycle: split into its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1626>
[05:03] <zyga-suse> good morning
[05:06] <zyga-suse> Pharaoh_Atem: I'll start testing 2.28.5 update after breakfast
[05:07] <elopio> snappy-m-o autopkgtest 1630 xenial:amd64:integration
[05:07] <snappy-m-o> elopio: I've just triggered your test.
[05:07] <mup> PR snapcraft#1630 opened: tests: allow to select a suite when running autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1630>
[05:47] <mup> PR snapd#4028 closed: interfaces/mount: don't generate legacy per-hook/per-app mount profiles <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4028>
[05:48] <zyga-suse> hey, good morning mvo
[05:49] <zyga-suse> mvo: heads up, I need to pick up my son from school again at .. 15:00 exactly,
[05:56] <mup> PR snapd#4009 closed: tests: adding test for network-manager interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4009>
[05:59] <mvo> zyga-suse: good morning
[05:59] <zyga-suse> :-)
[05:59] <mvo> zyga-suse: do you mind if I merge 3999?
[05:59] <zyga-suse> looking
[05:59] <mvo> zyga-suse: there is one followup {0,}->{0} for the array init, but otherwise it should be fine, I can do this followup in my 4000 pr
[05:59] <zyga-suse> mvo: I think we need to wait for jamie's review
[06:00] <zyga-suse> as for {0.} vs {0} - I don't mind. whatever indent does is fine
[06:00] <mvo> yeah
[06:02] <zyga-suse> mvo, jdstrand should be back tomorrow AFAIR
[06:02] <mvo> zyga-suse: ok
[07:55] <zyga-suse> mvo: question about .5 promotion
[07:55] <zyga-suse> mvo: when do you envision that will happen
[08:06] <kalikiana> o/
[08:10] <mvo> zyga-suse: hey, not entirely sure, we should discuss in the standup. usually on mondays but given the cirumstance maybe earlier is better
[08:11] <zyga-suse> I think that earlier is better too, given that many people are affected by nvidia
[08:11] <mvo> zyga-suse: yeah, that too
[08:11] <zyga-suse> NB: I won't be at the standup
[08:11] <mvo> zyga-suse: also now that the pi3 mystery is traced to ubuntu-image
[08:14] <zyga-suse> mvo: aha? different versions of embedded tools?
[08:15] <mvo> zyga-suse: yeah, i suspect that
[08:18] <mup> PR snapd#4047 closed: snap-confine: init all arrays with `= {0,}` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4047>
[08:21] <mup> PR snapd#3872 closed: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3872>
[09:43] <c-lobrano> hey kalikiana, sorry for disappearing yesterday. I updated the PR on LP 1722650 using Gentoo's os-release-info, which does not have VERSION_ID (thanks zyga-suse as well)
[09:45] <c-lobrano> ^bug #1722650
[09:45] <mup> Bug #1722650: snapcraft requires optional VERSION_ID in os-release <bitesize> <Snapcraft:In Progress by c-lobrano> <https://launchpad.net/bugs/1722650>
[09:56] <Chipaca> mvo: ping
[09:59] <mvo> Chipaca: pong
[09:59] <Chipaca> mvo: i'm lookinig into the translations thing
[09:59] <Chipaca> mvo: the translations are on the ubuntu package, not the snapd project
[09:59] <Chipaca> mvo: so i can't set up the branch to pull them back in
[09:59] <Chipaca> mvo: who knows this stuff?
[10:00] <mvo> Chipaca: I do
[10:00] <Chipaca> mvo: oh no :-)
[10:00] <mvo> Chipaca: its mostly sorted, expect a pr in a little bit
[10:00] <Chipaca> mvo: ah ok
[10:01] <mvo> Chipaca: I enabled translation on the project now
[10:01] <mvo> Chipaca: it was selected on the 15.04 branch
[10:01] <zyga-suse> Parlez-vous francais?
[10:01] <zyga-suse> will snapd now happily speak esperanto?
[10:02] <mvo> zyga-suse: yes
[10:02] <mvo> Chipaca: I was mostly adding the test we talked about
[10:02] <zyga-suse> mon dieu!
[10:02] <zyga-suse> mvo: will we now get perioidic imports of translations into github?
[10:05] <mvo> zyga-suse: yes, hopefully we can just pull from a LP git branch
[10:05] <mvo> zyga-suse: but that is not done yet
[10:07] <ogra_> pfft esperanto ...
[10:07] <ogra_> ... klingon is what we want !!!
[10:14] <mup> PR snapd#4053 opened: tests,po: sync translations from LP and add regression test for LP:1723974 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4053>
[10:14] <mvo> Chipaca: -^
[10:15] <mvo> Chipaca: fwiw, this panics for other translations as well
[10:15] <mvo> Chipaca: feel free to merge into your branch
[10:30] <kalikiana> c-lobrano: Cool! No worries. I'm testing it now
[10:31] <Chipaca> mvo: you know what would be cool? if i18n could be compiled to look in a non-system dir, for unit-ish testing
[10:31] <mvo> Chipaca: that can be done
[10:31] <Chipaca> mvo: SMOP and all that
[10:31] <mvo> Chipaca: actally vSMOP
[10:31] <mvo> actually
[10:31] <mvo> Chipaca: I can make this happen, sounds like the right task before lunch
[10:32] <Chipaca> mvo: i've merged your branch and am building the package to test it, fwiw
[10:32] <mvo> Chipaca: what do you envision? a unit test for cmd.go?
[10:32] <mvo> Chipaca: in addition to the integration test? or should this supersede it?
[10:33] <mvo> Chipaca: the i18n might be easy, iirc the cmd.go go-flags stuff is harder to re-init, iirc it has some global state that is hard to get rid of :/
[10:33] <Chipaca> mvo: the integration test doesn't seem to do anything that of necessity needs to be integration-y
[10:33] <Chipaca> ah
[10:33] <Chipaca> bah
[10:33] <Chipaca> mvo: maybe it's for another time then
[10:36] <mvo> Chipaca: yeah, the i18n part is "simple", but let me quickly poke at it, maybe I misremember, but I think there is a bunch func init() in go-flags
[10:39] <Chipaca> mvo: it's sort-of-kinda a static check that run-checks could do if it knew how
[10:39] <Chipaca> but might as well leave it in spread ¯\_(ツ)_/¯
[10:40] <Chipaca> who do we know that speaks nb_NO?
[10:41] <Chipaca> fnordahl: ohi
[10:53] <fnordahl> Chipaca: jeg snakker norsk, hva trenger du?
[10:53] <fnordahl> Chipaca: What can I do for you today?
[10:54] <Chipaca> fnordahl: hello. I was just checking if there was a reason (beyond a typo) for “<assertion file>” to have been translated to “forutsetningsfil>”, i.e. for the missing opening <
[10:55] <zyga-suse> Chipaca: I was wondering why you didn't choose to add < > in go
[10:55] <zyga-suse> Chipaca: and just ask the translators to translate the markupless text
[10:55] <Chipaca> ...........................
[10:55]  * zyga-suse implemented overlayfs hole-poking logic now, now the testing 
[10:55] <zyga-suse> *lots* of tests to write
[10:55] <Chipaca> zyga-suse: that's my forehead hitting the keyboard
[10:56] <Chipaca> zyga-suse: I don't know either. Inertia?
[10:56] <Chipaca> OTOH, let's not fix it in that direction _right_ now (and lose the translations)
[10:57] <Chipaca> mvo: when we SRU, does that mean the language pack might also get updated? or is that separate?
[10:59] <fnordahl> Chipaca: the missing character does indeed look like a typo. To say anything about the actual wording used in the translation I need some context. In which files does the referenced sentences reside?
[11:00] <Chipaca> fnordahl: hmm, not sure if this answers your question: https://translations.launchpad.net/ubuntu/artful/+source/snapd/+pots/snappy/nb/+translate?batch=10&show=all&search=forutsetningsfil ?
[11:00] <mvo> Chipaca: its separate, the language-packs follow their own schedule
[11:03] <Chipaca> fnordahl: otherwise this https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_ack.go is the source file for that string
[11:04] <Chipaca> (but that might not help much either)
[11:05] <fnordahl> sure that was helpful, i'll have a look and leave any suggestion I might have on the referenced page and comment here.
[11:05] <ackk> mvo, a couple of autopkgtests still failed on  https://github.com/snapcore/snapd/pull/3916, but I'm not sure it's related to the changes
[11:05] <mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
[11:09] <mvo> ackk: you can ignore those, I will double check but those are unstable today
[11:18] <ackk> mvo, thanks
[11:34] <Son_Goku> zyga-suse: Yo
[11:37] <zyga-suse> Son_Goku: hey ho
[11:37]  * Son_Goku sighs
[11:37] <Son_Goku> I'm disappoint
[11:37] <Son_Goku> I wanted 2.28.5 to be part of the Fedora 27 final freeze
[11:37] <Son_Goku> but no one bothered to give any karma for it
[11:37] <Son_Goku> I *hate* this
[11:38] <zyga-suse> :-/
[11:38] <Son_Goku> no one tests it, and I basically have to wait
[11:38] <Son_Goku> and twice I've been ruined by Ubuntu breakages and having to reset the counter
[11:38] <Son_Goku> because I *have* to move in lockstep or otherwise things break badly
[11:39] <Son_Goku> this is the really *not* fun part of snapd
[11:39] <zyga-suse> I don't disagree with other things but the whole 2.28.x release is not really broken just on ubuntu
[11:39] <Son_Goku> it's not really broken on Fedora
[11:39] <Son_Goku> all the problematic features are disabled
[11:39] <zyga-suse> I'm worried that nobody apart from sometimes me looks at fedora testing
[11:39] <zyga-suse> Son_Goku: udev is equally broken
[11:39] <zyga-suse> Son_Goku: most of the fixes were related to udev in one way or another
[11:39] <Son_Goku> you think you're worried? aside from myself, I don't think anyone actually looks at it or cares
[11:40] <Son_Goku> I have no numbers to prove any usage, since we don't have an equivalent to popcon in Fedora
[11:41] <Son_Goku> I do know that basically no one ever clicks the links on the snapcraft forum
[11:42] <zyga-suse> links for testing?
[11:42] <Son_Goku> yes
[11:43] <Son_Goku> I went through a ton of trouble to diagnose and fix static builds for snap-exec and snap-update-ns
[11:43] <Son_Goku> for base snaps
[11:51] <leocadio> Hello. Does anyone know if it's possible to make changes on the ath9k driver and compile it as a snap to be executed within a Ubuntu Core installation?
[11:56] <zyga-suse> re
[12:00] <Chipaca> leocadio: sounds like something for the forum
[12:01] <Chipaca> leocadio: AFAIK it's currently not possible -- i think currently you need to ship it in the kernel snap
[12:10] <zyga-suse> mvo, Chipaca: I'm going to pick up my son again, will miss standup.
[12:10] <zyga-suse> my update is simple, overlays work but I need to spend time on polishing fine details, fixing and writing tests
[12:10] <Chipaca> zyga-suse: i'm so excited about overlays :-)
[12:11] <zyga-suse> Chipaca: me too, it's a game changer in many ways
[12:11] <zyga-suse> I'm pushing a WIP branch but it's too early to even spread test (especially after what I just pushed)
[12:12] <zyga-suse> feel free to peek though :)
[12:12] <zyga-suse> with that note I'm off
[12:13] <mvo> zyga-suse: see you
[12:16] <Chipaca> mvo: wrt the translations thing, should i patch the nb_NO translation so the tests pass and we can land it?
[12:17] <Chipaca> mvo: or should we wait for launchpad to reflect the fixed translation?
[12:17] <mvo> Chipaca: do you have a link to nb_NO translation?
[12:17] <mvo> Chipaca: maybe I can fix myself or did you suggest a translation already?
[12:18] <Chipaca> mvo: i have suggested it
[12:18] <mvo> Chipaca: I think we should fix in git and land and not wait for LP. do you think you could contact the nb translation team? there must be a way to get in touch so that they can approve it?
[12:18] <Chipaca> mvo: once f.nordahl confirmed it was a sane suggestion :-)
[12:18] <mvo> Chipaca: heh, thanks to fnordahl then :)
[12:18]  * Chipaca should've split that as fnord.ahl
[12:19] <Chipaca> yes indeed
[12:19] <Chipaca> but, launchpad hasn't accepted it yet
[12:19] <Chipaca> hence my question (as opposed to me pestering you to pull them again)
[12:20] <mvo> Chipaca: yeah, lets pester the nb team but also we should not block on it, we have a test so if this gets pullled in again we will know :)
[12:20] <Chipaca> mvo: so I hand edit the nb_NO.po?
[12:20] <Chipaca> nb.po actually
[12:21] <Chipaca> msgid "-r can only be used with --hook"
[12:21] <Chipaca> msgstr "«-r» kan bare brukes sammen med «--hook»"
[12:21] <Chipaca> oooohhhh
[12:22] <Chipaca> we need to fix quoting everywhere, and it always turns out to be huge. I'll probably do it on a plane six months from now :-)
[12:23] <Chipaca> (there's a bug along the lines of “use double quotes for X, single quotes for Y”)
[12:23] <Chipaca> mvo: anyway, unless you say no, i'm pushing a fix to nb.po so my branch looks green again
[12:24] <mvo> Chipaca: +1
[12:26] <Chipaca> ok, i'm going off for a while
[12:40] <mup> PR snapd#4051 closed: many: add integrated snapfuse <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4051>
[12:41] <mup> PR snapcraft#1623 closed: Removed dependency on VERSION_ID in os-release <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1623>
[12:44] <mup> PR snapcraft#1626 closed: lifecycle: split into its own package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1626>
[12:59] <sergiusens> o/
[13:00] <sergiusens> In the end I decided to cancel my day off for today. There is just so much I want to get done
[14:10] <sergiusens> kalikiana mind looking at snapcraft#1480 ? The adt container test errors
[14:10] <mup> PR snapcraft#1480: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1480>
[14:18] <kalikiana> sergiusens: There's already a PR snapcraft#1629 for part of the failures - I'm actually looking into the one it doesn't fix that fails with "no such file or directory"
[14:18] <mup> PR snapcraft#1629: lxd: fix the unit test for the user id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629>
[14:19] <zyga-suse> me is home
[14:19] <zyga-suse> time for a small break, then to attack overlayfs with tests
[14:19] <zyga-suse> :-)
[14:23] <mup> PR snapcraft#1624 closed: kernel plugin: use latest stable core snap <bug> <Created by alfonsosanchezbeato> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1624>
[14:26] <kyrofa> pstolowski, curious to get your thoughts on https://forum.snapcraft.io/t/restarting-services-from-configure-hook-race-condition
[14:27] <pstolowski> kyrofa, are you watching me?
[14:27] <kyrofa> pstolowski, ha!
[14:27] <kyrofa> Yes
[14:28] <ogra_> kyrofa, is that the webcam link you forwarded to me in PM (havent clicked it yet) ?
[14:28] <kyrofa> ogra_, who ELSE would it be?
[14:28] <ogra_> indeed
[14:30] <pstolowski> kyrofa, I was reading it for the 2nd time a moment ago. still thinking - the response you got already was kinda what I thought about too (creating a config file solves the "problem" of transactional nature of the hook; but on the other hand it's against the idea of using snapctl when possible
[14:30] <kyrofa> pstolowski, my thoughts exactly
[14:31] <pstolowski> kyrofa, so, I need to think some more. clearly the introduction of snapctl outside of hooks introduced this kind of issue
[14:32] <kyrofa> pstolowski, well, it exposed it anyway. I would never say that feature wasn't required-- it's one of my favorites actually. Saving a config file felt super hacky
[14:32] <kyrofa> But yeah, making use of it is difficult
[14:32] <pstolowski> kyrofa, right, exposed; bad choice of words on my side
[14:33] <kyrofa> pstolowski, at the same time, what we have is conceptually correct. I like the transactional manner of this
[14:35] <kyrofa> My lockfile is admittedly probably just as hacky as saving config files, haha
[14:37] <pstolowski> kyrofa, would it make sense to be able to commit changes to config explicitely? `snapctl commit`? but it feels suspicious, we loose all the benefit of reverting config changes on failure
[14:38] <pstolowski> feels like a hack too
[14:38] <pstolowski> nah
[14:40] <kyrofa> pstolowski, yeah I considered that as well. I agree that it defeats some of the niceties and adds complexity...
[14:41] <kyrofa> But it feels more intuitive than trying to design a way to queue service restarts
[14:41] <kyrofa> I don't even know what that would look like
[14:42] <kyrofa> It also makes documentation hard. If configuring the port for apache succeeded but configuring the memory limit for PHP failed, the hook fails. I think the user should be able to assume everything they just set failed
[14:44] <kyrofa> pstolowski, here's a question
[14:45] <kyrofa> pstolowski, this problem exists because I can't actually restart the service. I have to kill it, then systemd brings it up in its own env
[14:45] <kyrofa> pstolowski, once snapctl supports restarting services, and I use it inside the hook, won't it get the hook's snapctl transaction?
[14:45] <kyrofa> i.e. its configuration
[14:46] <kyrofa> The context/cookie should be the same
[14:48] <pstolowski> kyrofa, indeed, but it's just going to send a request to snapd to restart the service (which in turn just restarts it via systemd)
[14:49] <kyrofa> Ah, darn
[14:54] <kyrofa> pstolowski, okay, what if snapctl grew the ability to queue generic shell commands that ran after the hook completed successfully
[14:54] <kyrofa> Then one could use `snapctl queue -- snapctl restart apache`
[14:54] <kyrofa> (in the hook)
[14:55] <pstolowski> kyrofa, hmm, maybe.. what about a "post-configure" hook?
[14:56] <kyrofa> That ran when `configure` succeeded? That could work, but requires one to save old values to compare new vs. old and determine what needs to be restarted
[14:56] <kyrofa> i.e. the restart conditions need to be determined out of context
[14:56] <kyrofa> Which is a bit of a buden
[14:56] <kyrofa> burden*
[14:57] <pstolowski> right, good point
[15:00] <Chipaca> linode is being funny again?
[15:01]  * Chipaca hits the AGAIN button
[15:03] <mup> PR snapcraft#1603 closed: tests: add /snap/bin to PATH in autopkgtests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1603>
[15:03] <kyrofa> pstolowski, with the generic commands, we can build up a queue and then only run unique commands, so multiple service restart queues only end up restarting once, etc.
[15:03] <kyrofa> Well... maybe you don't want that as a generic feature. Hmm
[15:07] <pstolowski> kyrofa, atm I'm wondering if there is any way to expose cookie/context to the restarted service, so that it sees same transaction, and sapctl get from the service see yet-uncommited values. not sure that's easily doable though
[15:08] <kyrofa> pstolowski, that seems the simplest from the users point of view, certainly
[15:09] <mup> PR snapcraft#1631 opened: lxd: use FakeFilesystem in test_snap_containerized_remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1631>
[15:09] <kyrofa> pstolowski, although that still breaks the transactional nature of setting a configuration. That means it's possible for a service to be running with a configuration that failed to apply in the end
[15:09] <pstolowski> indeed
[15:11] <kalikiana> sergiusens: snapcraft#1631 is the missing piece to get the autopkg tests green again
[15:11] <mup> PR snapcraft#1631: lxd: use FakeFilesystem in test_snap_containerized_remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1631>
[15:11] <kalikiana> together with elopio's PR
[15:12] <elopio> together with two other PRs. We'll get there :)
[15:14] <kalikiana> Haha, true. I just meant the lxd ones, but yeah
[15:14] <kalikiana> elopio: your branch has conflicts btw
[15:23] <sergiusens> kalikiana can you just update elopio's branch with that PR as he moved the container tests into a new class
[15:23] <sergiusens> ?
[15:26] <kalikiana> sergiusens: That one doesn't test user id's so it wouldn't really benefit from the scenarios...
[15:27] <kalikiana> I can add it to his branch anyway
[15:27] <kalikiana> But not in the new class
[15:28] <elopio> conflict solved.
[15:33] <pstolowski> niemeyer, hey, any thoughts on the above discussion - I summarized it here: https://forum.snapcraft.io/t/restarting-services-from-configure-hook-race-condition/2513/5 ?
[15:33] <niemeyer> Looking
[15:33] <sergiusens> nhandler hey, do you know how long the talks are for ATO?
[15:34] <kyrofa> sergiusens, four hours. You didn't know that?
[15:34] <pstolowski> niemeyer, hold one for a sec, forgot to document one more case
[15:34] <kyrofa> sergiusens, they anticipate between 300-500 slides
[15:35] <sergiusens> kalikiana the thing is, one will have conflicts as soon as the other lands, won't they? They both touch test_snap
[15:35] <sergiusens> kyrofa lol, given that there are 8 talks in parallel I think the combined value would add up to that number
[15:35] <kyrofa> Haha
[15:35] <sergiusens> kyrofa I will just use slides with single words ;-)
[15:36] <kyrofa> sergiusens, those are called CEO talks
[15:36] <sergiusens> heh
[15:37]  * sergiusens leaves the computer for a bit to practise some aikido and get lunch
[15:37] <pstolowski> niemeyer, ok, now, updated with item #4
[15:38] <niemeyer> pstolowski: Thinking
[15:38] <kyrofa> pstolowski, good summary, thank you
[15:45] <niemeyer> pstolowski, kyrofa: Responded
[15:46] <kalikiana> elopio: sergiusens pushed my fix to the existing branch now
[15:48] <mup> PR snapcraft#1631 closed: lxd: use FakeFilesystem in test_snap_containerized_remote <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1631>
[16:04] <elopio> snappy-m-o autopkgtest 1629 xenial:amd64
[16:04] <snappy-m-o> elopio: I've just triggered your test.
[16:09] <pstolowski> niemeyer, thanks
[16:18] <niemeyer> pstolowski: #3972 reviewed again
[16:18] <mup> PR #3972: interfaces: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
[16:18] <niemeyer> pstolowski: LGTM with those details sorted
[16:20] <pstolowski> niemeyer, cool, thank you
[16:25] <facubatista> sergiusens, elopio, how can I see stdout in snapcraft tests after I put a print() in the tests?
[16:30] <elopio> facubatista: in unit tests, there's a self.fake_terminal that swallows all stdout and stderr.
[16:31] <facubatista> elopio, is there an easy way to disable it?
[16:31] <elopio> I wouldn't use print to debug. I would put a self.assertThat to confirm my assumptions. But, you can self.fake_terminal.getvalue()
[16:32] <facubatista> elopio, I can not open a pdb either
[16:32] <facubatista> elopio, I need to start checking the subversion machinery to see why a test fails in my computer
[16:33] <elopio> facubatista: comment it out in the setUp.
[16:33] <facubatista> elopio, is this a standard procedure? how do you debug when run tests?
[16:34] <elopio> I put assertions.
[16:35] <facubatista> elopio, but an assertions is a way to check a variable to a value... how do you just *see* different values when making the machinery move?
[16:35] <elopio> But it's not a happy thing. We need to split our logic from our presentation. One day...
[16:37] <elopio> When I don't understand a test, I put multiple assertions to check if my assumptions are correct until I understand it.
[16:37] <elopio> Not saying that's what you should do. You can disable the setup things that break pdb, and debug
[16:37] <facubatista> elopio, ack, thanks
[16:39] <mup> PR snapd#4017 closed: store: add download caching <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4017>
[16:40] <elopio> Probably sergiusens, kaliakiana and kyrofa have other methods.
[16:40] <facubatista> elopio, oh, subversion tests depends on machine's locale :/
[16:41] <kyrofa> elopio, facubatista yes I use a magical line: raise RuntimeError(<thing i want to see>)
[16:41] <kyrofa> The whole swallowing stdout/stderr for everything is awful
[16:41] <facubatista> kyrofa, that, like elopio's assert, makes possible to see ONE thing, not several
[16:41] <kyrofa> facubatista, you will hear no disagreement from me
[16:41] <elopio> Oh damn. That's a good finding, thanks facubatista
[16:42] <elopio> Please report a bug.
[16:42] <kyrofa> facubatista, sometimes that line becomes more magical: raise RuntimeError('{} {}'.format(<first thing>, <second thing>)) :P
[16:47] <facubatista> kyrofa, too much work error :p
[16:48] <kyrofa> Hahaha
[16:48] <facubatista> kyrofa, elopio, thanks!!
[17:49] <kalikiana> facubatista: You can also use the logger to read the output. Although it's slightly different depending on the test setup.
[17:51] <kalikiana> elopio: let me know if anything else comes up wrt autopkg tests, Travis is sadly slow to confirm... I'm headed to a pub now, but will check IRC later
[17:52] <elopio> Tx kalikiana
[17:53] <sergiusens> elopio you should alias autopkgtest to adt, some contracted and some expanded nouns gets me all the time ;-)
[17:54] <sergiusens> facubatista I use vs code and set breakpoints as a normal person :-P
[17:55] <elopio> Pitti renamed everything to autopktest. Adt is no more
[17:56] <sergiusens> elopio I really wish the unittest for subversion, hg and bzr tests were just removed or have fakes in place for those
[17:57] <sergiusens> facubatista you can blame kyrofa fo all the hidding, he always complained about leaked stdouts in the tests ;-)
[17:57] <sergiusens> kyrofa now that we are using click we could probably just mock the calls to click instead, just a hint for a rainy day :-)
[17:57] <elopio> Fakes + integration tests sounds good to me. Just integration doesn't sound so bad either
[17:59] <mwhudson> hooray for merging #3872  ;)
[17:59] <mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3872>
[18:05] <kyrofa> sergiusens, yes indeed
[18:06] <mup> PR snapcraft#1602 closed: tests: add the slow tag for ros snapd integration test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1602>
[18:08] <sergiusens> kyrofa does my comment on snapcraft#1613 make sense?
[18:08] <mup> PR snapcraft#1613: cross compilation: enable cross compilation of i386 kernel on x86-64 … <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1613>
[18:11] <kyrofa> sergiusens, yeah probably
[18:37]  * zyga-ubuntu fell asleep
[18:37] <zyga-ubuntu> man, I need to sleep more regularly
[18:37] <zyga-ubuntu> just woke up
[18:42] <sergiusens> kyrofa do you have time to test a branch for me on your trustworthy trusty sytem?
[18:42] <sergiusens> *system
[18:43] <kyrofa> sergiusens, haha, I ran out of HD space and blew it away
[18:43] <sergiusens> kyrofa oh, well, I thought you might like this https://github.com/snapcore/snapcraft/compare/master...sergiusens:libc6-and-friends?expand=1
[18:43] <kyrofa> sergiusens, ooo, fancy! Let me shuffle a few files around and get back to you
[18:44] <sergiusens> kyrofa that is, libraries from the past; next the more complicated elf patching, but I am still pondering on that
[19:47] <facubatista> sergiusens, import pdb; pdb.set_trace(), if not commenting out the fake_terminal thing, crashes with TypeError: bad argument type for built-in operation
[20:00] <facubatista> elopio, https://bugs.launchpad.net/snapcraft/+bug/1724674
[20:00] <mup> Bug #1724674: Subversion test fails in a non-english locale <Snapcraft:New> <https://launchpad.net/bugs/1724674>
[20:08] <sergiusens> facubatista yeah, FakeTerminal might need what I mentioned above
[20:08] <sergiusens> kyrofa how is that going? I have a small refactor coming after that ;-)
[20:43]  * sergiusens begins the relocation process
[20:45] <mup> PR snapcraft#1632 opened: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632>
[20:49] <kyrofa> sergiusens, haven't tested yet, clearing space now. Would be nice to be able to test the PR's snap... ;)
[20:51] <kyrofa> elopio, in gitlab ci I can specify artifacts and it displays them on the PR. Do you know if Travis supports somethin similar?
[20:52] <elopio> kyrofa: it does not.
[20:53] <kyrofa> Darn. Well, I discovered something neat today that might prove useful: transfer.sh
[20:53] <kyrofa> elopio, sergiusens we could upload every PR's snapcraft there
[20:54] <elopio> when I asked about sharing files between stages, they said that's the solution. But everything is slow here. After my first project in gitlab, I'm happy to move all our stuff there :D
[20:54] <kyrofa> There's even a snap for it made by someone awesome: snap install transfer
[20:55] <elopio> kyrofa: how much space do we get there for free?
[20:55] <kyrofa> elopio, 10 gigs for each transfer. It stays there for 14 days
[20:56] <elopio> $26 of $2,000 per month
[20:56] <elopio> When I reach $ 2000 a month, we can keep running Transfer.sh.
[20:57] <elopio> it sounds they need more support to be sustainable. I'm happy to change my PR to use that instead of the cache. We can always fall back to the cache if they have to suspend the service.
[20:59] <elopio> actually, we still need the cache to share the file id between stages. But the benefit is that we can manually install and test it. Not bad.
[20:59] <kyrofa> Inded
[20:59] <kyrofa> With another e in there somewhere
[22:14] <stgraber> zyga-suse, jdstrand: we recently noticed this: https://bugs.launchpad.net/snapd/+bug/1724697
[22:14] <mup> Bug #1724697: snap-confine shouldn't setup a seccomp policy if policy is @unrestricted <snapd:New> <https://launchpad.net/bugs/1724697>
[22:15] <stgraber> can you comment on the approach? I may be able to spare a bit of time from one of the LXD devs to change snap-confine.
[22:51] <sergiusens> kyrofa elopio while we can switch CI systems we cannot move away from github without contention
[22:52] <sergiusens> I would push for proper hook design to get PRs into build.snapcraft.io
[22:52] <kyrofa> sergiusens, nah, not making a play for github-ci, just thinking about how to get snaps available from PRs
[22:52] <kyrofa> sergiusens, oh definitely the preferred option. Plan B is just uploading the snap from travis. Moving to gitlab-ci is not on our radar AFAIK as much as I whine
[22:53] <sergiusens> JamieBennet btw, we talked about that during the Sprint but it did not reach any roadmap ^
[22:53] <kyrofa> JamieBennett, please please pretty please
[22:54] <sergiusens> kyrofa we certainly should have proper guidelines for folks on gitlab though
[22:55] <kyrofa> sergiusens, yeah, would be handy to see a build.snapcraft.io integration there, but an `enable-ci gitlab` option would be pretty easy as well
[22:57] <sergiusens> We should work on the latter
[23:47] <zyga-suse> stgraber: ack, checking
[23:49] <zyga-suse> stgraber: the change to what @unrestricted means was done a while ago, along with the introduction to snap-seccomp
[23:49] <zyga-suse> stgraber: before the seccomp profile was parsed each time
[23:49] <zyga-suse> stgraber: now the profile is parsed and compiled only when the policy is prepared
[23:50] <zyga-suse> stgraber: because the compiled policy is a BPF program we didn't have a way to say "don't load anything" without introducing some form of header or other special semantics in interpreting the file content
[23:50] <zyga-suse> stgraber: mvo implemented a permissive policy as a workaround
[23:50] <zyga-suse> stgraber: if this breaks LXD we can definitely change this
[23:51] <zyga-suse> stgraber: e.g. by encoding a little header or by interpreting tuncated file as unconifned
[23:51] <zyga-suse> stgraber: (or perhaps a file containing just the string @unconfined, not to be confused with a truncated file due to another bug)
[23:52] <zyga-suse> stgraber: I commented as such on the bug report now
[23:53] <zyga-suse> stgraber: I'll catch up with mvo tomorrow morning about this
[23:53] <zyga-suse> stgraber: please try to indicate urgency or importance, is this a 2.28.6 material?
[23:53]  * zyga-suse -> EOD