[05:03] morning [07:25] snap instance user directory mappings are a bummer [07:26] mborzecki: is it hard to do? [07:27] mborzecki: btw, does 5561 need a sameule/gustavo review or could this go in with two reviews? [07:27] mvo: the setup is ugly, it already relies on SNAP_USER_DATA being set, now it's even worse [07:28] mvo: it'd be great if someone did a 2/3rd review perhaps [07:35] mborzecki: ok [07:35] mborzecki: I hope to find time for reviews today/tomorrow [07:35] mvo: thanks [07:36] meanwhile i'll try to find a way to do user mappings in s-c that does not invovlve exploding the number of env vars passed from snap and does not call getpewnt [07:37] mborzecki: sounds good [07:37] mvo: the silly thing about this part is that since it's bind mounting stuff it needs to run with elevated privs, this makes relying too much on env vars is a bit scary [07:46] moin moin [07:47] mborzecki: if you could take a look at https://github.com/snapcore/snapd/pull/5591 it'd be great: it's a fix for a bug found in spread tests of https://github.com/snapcore/snapd/pull/5580 [07:47] Chipaca: looking [07:48] mborzecki: thanks [07:50] Chipaca: high order math, +2 < 2 +1 :) [07:50] mborzecki: IKR [07:51] the maths was there because the +6 was rather mysterious [07:51] but, not that much, i dunno [07:51] i add comments when requested :-) [08:06] kyrofa: hey, 5569 probably needs a master merge. I tried to do that for you but it appears that you disabled the ability for maintainers to push to your branches(?) [08:07] kyrofa: master merge to make tests great^Wgreen again [08:10] some easy wins: 5548 and 5450 (both relatively short) [08:16] opened https://github.com/snapcore/snapd/pull/5594 for snapenv, i suppose it might be a bit controversial [08:34] mvo: in looking at #5450, I saw a bit of code that looked suspicious [08:34] mvo: in Put, if the Chtimes fails with an IsNotExist, we re-link the file [08:35] mvo: but we don't re-Chtimes the file [08:44] Chipaca: aha, let me have a look [08:55] mvo: a few more comments there [08:55] mvo: overall looks good though [08:57] Chipaca: yeah, nice one on the hardLinkCount, thats indeed a bit silly [08:58] mvo: that's the one that stopped me from +1'ing it :-) [08:58] the others are a non-rhetoric question, and a nit [08:59] Chipaca: yeah, on it. thank you! [09:00] mvo: the cache's Count isn't used outside of tests, right? [09:01] Chipaca: correct, we can probably unexport it [09:01] mvo: was the cache size a config? [09:02] mvo: i was more worried about it being used in a loop somewhere, as it's not particularly efficient if the cache is arbitrarily sized [09:02] if the cache size is not configurable, it's less of a worry [09:03] Chipaca: it is not configurable right now (the cache count) [09:04] Chipaca: aha, yes, building a list of the content for the size is silly if the size is large [09:04] Chipaca: I can: a) add a FIXME b) rework [09:04] mvo: (a) is fine -- and it'll only be an issue if the list is big [09:04] mvo: OTOH [09:05] mvo: why even count n>1 files in the cache size? [09:05] Chipaca: heh, yeah, maybe it should simply be "cacheTooBig() bool" instead of count [09:05] (well, proper name of course) [09:06] maybe we want to invert that: first step, remove n>1 files from fis; _then_ see if it's too big, sort it, etc [09:08] Chipaca: hm, not sure I get the idea but let me first address the other comments and then I read it again and ponder about it [09:16] mvo: i mean https://pastebin.ubuntu.com/p/wnrzqp72Gb/ [09:16] er, except the last loop should be on filtered :-) [09:18] of course, as hardLinkCount is just an accessor, it probably makes more sense to do that twice instead of copying all the file infos over [09:18] lovely morning for bikeshedding, isn't it? [09:19] Chipaca: aha, I see what you mean, let me poke at it a bit more [09:20] Chipaca: it is lovely! and the cache gets better with every iteration :) [09:20] mvo: https://pastebin.ubuntu.com/p/H9fwdVrb7d/ [09:21] Chipaca: yeah, feel free to pull and commit, this looks nice [09:21] mvo: and the 'are we ready yet' condition further down would need a tweak also [09:21] mvo: ah ok, will do [09:21] Chipaca: I would keep the comment about the link count and that we get stuff for free if the link count is > 1 [09:21] Chipaca: but other than that I think this is nice and clean [09:21] mvo: yeah, i was trying to explain the idea, not provide a diff :-D [09:22] mvo: is "numOwned" the right name for that count? [09:25] Chipaca: I can take your diff and run with it as well, I did not want to make you work, just had the impression it was "done" [09:26] Chipaca: yeah, I think numOwned is good, trying to think of anything more descriptive [09:26] Chipaca: I think this is a good name [09:30] mvo: 550d714b179733cc8e96bd2c91a1890af3613d69 [09:31] oh wait, it's already there [09:31] mvo: I pushed it to your repo :-D [09:31] I thought I could only do that when it was a PR [09:32] gah, github needs to refresh my gpg keys [09:32] Chipaca: tests are unhappy now - not sure if that is a bug in the tests or in the code. off by one it seems [09:35] mvo: a bug? in code I wrote?! inconceivable! === cjwatson_ is now known as cjwatson [09:47] mvo: ah, not a bug, just tests not updated for the smarter cache :-D [09:50] Chipaca: oh? whats the issue with the test? [09:54] Chipaca: aha, count needs an update as well? to return just unowned? or what is the best fix? [09:55] mvo: looking [09:55] ok [09:56] mborzecki: when you have some spare cycles, 5540 is probably another easy win, just needs a second review [09:57] mvo: ack [09:59] mvo: this might actually be a bug somewhere [09:59] mvo: in TestPutMany, I print the Nlink of every file, and the last one is always 2 [10:00] mvo: https://pastebin.ubuntu.com/p/rZFjtd39Sw/ [10:00] mvo: so it doesn't get cleaned up, so Count() > maxItems [10:00] mvo: but the question is why is nlink>1 [10:01] is something holding the file open? [10:01] Chipaca: hm, let me double check iirc its using iotutil.WriteFile() for the temp file creation [10:02] actually holding it open doesn't increase nlink [10:02] hmm [10:02] Chipaca: is this maybe simply an ordering problem? the last file is put in and it exists as a test file. now put sees it has a link count of 2 (one the test file and the file in the cache) and skips it [10:02] Chipaca: the remove of the test file is after the put [10:02] Chipaca: so probably just a confusing test [10:03] oh drat [10:03] mvo: i'm counting before the remove [10:03] * Chipaca is dumb :-) [10:03] * Chipaca moves it and tries again [10:03] Chipaca: its complicated [10:03] Chipaca: I mean life and computers and all that [10:03] mvo: relationships also [10:04] Chipaca: *cough* wise words! [10:04] mvo: so, yes, it's that at Put time the count is 2 [10:05] Chipaca: so all good, we just need to update the test and add a comment I guess [10:06] mvo: should I, or will you? [10:06] Chipaca: either way is fine, let me do it, I pulled you deep enough into this rabbithole already [10:06] * Chipaca puts down his "100 ways of cooking rabbit" book [10:11] Chipaca: update pushed, I will merge once tests are green [10:12] 5576 is also a trivial win [10:12] mvo: 'has a link count of 2 because it still exists outside of the cache dir so its is not counted' sounds like you're talking about Count(), when the link count of 2 and it not being counted is at Put time [10:18] Chipaca: hm, good point, let me try to correct this [10:19] Chipaca: I force pushed an updated version [10:20] mvo: s/has/had/, s/its/it's/, but only because I'm at nit central and it's nit breeding season [10:21] ah [10:21] mvo: s/its is/it's/ [10:21] :) [10:22] Chipaca: heh, force pushed again [10:23] * Chipaca is busy with a technical issue involving biscuits and coffee in a mug that is too narrow for dunking [10:25] down to 36 PRs and counting! [10:56] hm i'm missing a bit about apparmor, `aa-complain /snap/core/5183/usr/lib/snapd/snap-confine` should be enough to put it in complain mode for snap-confine right? [11:33] mvo: 35 [11:36] mvo, https://paste.ubuntu.com/p/rWZNvyVXpc/ [11:38] I was taking a look to the PR which fix that [11:38] mvo, #5440 [11:40] 2018-08-01 20:43:25 Failed tasks: 1 [11:40] - autopkgtest:ubuntu-18.10-arm64:tests/main/auto-refresh [11:40] i hope this is a fluke, retrying cosmic snapd autopkgtest [11:43] xnox, yo ... how good is your journald fu ? (i'm looking for someone who has some insight into it) [11:44] mvo: mborzecki: https://gist.github.com/chipaca/911a8a4905b091c10caa9854bf7ea4b4 [11:44] not sure you saw my questions in the backlog in #ubuntu-devel from last night [11:44] ogra, nothing beyond what the manpage says..... but you can try [11:45] xnox, well, so i always thought journald uses a ringbuffer in ram by default ... but found out that this isnt true ... it actually logs to a file in /run ... and by default has no upper limit set [11:50] aare expert needed, @{HOME}/snap/*_*/ does not match /home/test/snap/test-snapd-tools_foo/ ? [11:52] mborzecki: thats surprising - jdstrand will know why @{HOME}/snap/*_*/ does not match /home/test/snap/test-snapd-tools_foo/ ? [11:53] i get apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/snap/core/5183/usr/lib/snapd/snap-confine" name="/home/test/snap/test-snapd-tools/" pid=24324 comm="snap-confine" srcname="/home/test/snap/test-snapd-tools_foo/" flags="rw, rbind" [11:54] cachio: is the fix for refresh.timer=managed incomplete? [11:57] hmm refreshing a snap just now, snapd seems stuck at "Copy snap... data" (there's a whole of 512 bytes in $SNAP_DATA...) [11:57] that a known issue? [12:00] mvo, well, it is not working [12:00] we received an email yesterday about this issue [12:00] mvo, sudo snap set system refresh.timer=managed [12:01] it is not working neither [12:01] Saviq: can you do snap change --last=refresh? maybe its waiting for some dependency [12:02] cachio: thanks, checking [12:06] mvo, thanks [12:09] cachio: will send a pr shortly, quite annoying, the validation is in the way [12:11] mvo, thanks [12:13] mvo, I could make a new spread test for that, or update one [12:13] cachio: I'm updating the existing one as part of the fix [12:13] mvo, great :) [12:13] cachio: but yeah, that was the problem, the previous change lacked a full end-to-end test [12:14] cachio: I think I missed the mail from yesterday about this, who send it? [12:14] mborzecki: sorry, missed it, seems to have refreshed after all [12:15] mvo, it was a reply for the announcement which I did saying the 2.34.3 was promoted to candidate [12:15] mvo, Tony Espy sent it [12:15] Saviq: can you post the output nonetheless? it's interesting if there was some dep after all [12:16] mborzecki: http://paste.ubuntu.com/p/c8cXZhTRv3/ [12:16] Saviq: when that happens (i mean a task is waiting for some dep), the prompt is seemingly stuck, probably bad ux on our side [12:17] so it took 16 mins [12:18] Chipaca: do you remember of 'ready' column is when the task is done? [12:18] mborzecki: yes [12:19] spawntime is when the task was created, readytime is when it's finished [12:19] so maybe it did take that long after all [12:20] http://paste.ubuntu.com/p/DRWwF5hptt/ [12:20] mborzecki: well, maybe [12:20] 280MB... [12:21] we're probably missing a 'start time' to know exactly what happened [12:21] OTOH if you run with SNAPD_DEBUG=1 you'd know more [12:21] mborzecki: can you show me the full denial and the full rule that doesn't match? [12:21] (for the '_') [12:22] Saviq: were you running with SNAPD_DEBUG=1? [12:22] jdstrand: https://github.com/bboozzoo/snapd/commit/07de54fe9b126923dbc15251a09fbda0a8f84204 and https://paste.ubuntu.com/p/y4kNfM734Y/ [12:23] jdstrand: the other 2 rules for /snap/*_* and /var/snap/*_* seem to match, i was getting denials before and now they are gone [12:24] Chipaca: I'm afraid no [12:27] heh weird failure with MATCH https://paste.ubuntu.com/p/M3rXxHD35Y/, obviously works if running in the debug shell [12:27] mborzecki: you are hitting https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1612393 [12:28] jdstrand: so just /home/*/snap.. ? [12:28] neat, gcloud packaged in snap [12:28] * thresh apt removes it [12:30] cachio: 5595 fixes the refresh.timer issue for real this time [12:30] mborzecki: by default, /home/*/snap/*_*/ and /root/snap/*_*/. but see /etc/apparmor.d/tunables/home (and home.d/*) if the user updated the tunables for some other location [12:32] mborzecki: that said, snap-confine itself falls over if people use an alternate location for home (ie, they tried to adjust home.d/something so probably should mention LP 1612393 and also that snap-confine doesn't support other locations for home.d in a code comment [12:32] mvo, great, thanks, I'll take a look now [12:32] mborzecki: and move on [12:32] jdstrand: had to use 'mount options=(rw rbind) /home/*/snap/*_*/ -> /home/*/snap/*/,' [12:33] jdstrand: and it sort of works, thanks for the help! :) [12:33] oh right, you aren't mounting on /home/*/snap/*/ [12:33] err [12:33] you aren't mounting on /home/*/snap/*_*/ [12:33] you are mount from foo_parallel to foo [12:33] so that makes sense [12:34] jdstrand, regarding the device-tree/model access i think it should live in the same interface that allows /proc/cpuinfo (whichever that is) [12:35] IMHO they are equivalent [12:37] ogra: that is allowed by default in the base abstraction because it is used by glibc's sysconf [12:37] bah ... damned :) [12:37] i thought i found a clever criteria ;) [12:38] parallel installs integration branch https://github.com/snapcore/snapd/pull/5596 [12:38] *criterium [12:38] mvo: I'm looking at 5592 [12:38] *criterion ?? [12:38] hmm [12:38] ogra: I mean, we can add it anywhere we want. there are basically two questions: what fails if it isn't allowed? how sensitive is the information? [12:38] mvo: without this, would the broken snapd snap install succeed? [12:39] ogra: critteropolis [12:39] jdstrand, nothing fails, thats really optional but allows you to i.e. distinguish on which specific Pi model you run [12:39] ogra: it seems like very few things fail otherwise we would have heard about it much sooner [12:39] ok [12:40] yeah, nothing fails ... but it would be good to be able to get to that info [12:40] sure [12:40] it'll be added [12:40] thx [12:40] $ cat /proc/device-tree/model [12:40] TI AM335x BeagleBone Black [12:40] (i'm working towards a unified Pi image that runs on all Pi's and there it would be come ore important) [12:40] ok, that isn't very sensitive [12:41] * jdstrand nods [12:41] I saw the thread. sounds neat [12:41] its the same as "Hardware:" in /proc/cpuinfo in most cases i think [12:41] Hardware: Generic AM33XX (Flattened Device Tree) [12:41] ah, k ... so it is actually more secific [12:42] *specific [12:42] *barerly* [12:42] Hardware : BCM2709 [12:42] barely* [12:42] on a pi3 [12:43] huh, on pi 2 it is quite different [12:43] barely*$ grep Hardware /proc/cpuinfo [12:43] Hardware : BCM2709 [12:43] meh [12:43] $ grep Hardware /proc/cpuinfo [12:43] Hardware : BCM2709 [12:43] $ cat /proc/device-tree/model [12:43] Raspberry Pi 2 Model B Rev 1.1 [12:43] well, they use the same CPU core ... but differet SoC peripherials [12:43] but obviously someone can create a map having only BCM2709 [12:44] so here the devicetree model is actually helpful [12:44] ogra: this doesn't sound sensitive at all with the things that we already allow by default [12:44] ah, you mean we could allow it without interface [12:44] fine with me as well [12:44] that is what I'm thinking [12:44] yeah [12:44] Chipaca: yes [12:44] if cpuinfo is accessible the model should be too [12:45] ogra: is it generally useful? like, will a library ever look at that to try to optimize something? [12:45] Chipaca: so without 5592 a broken (or empty) snapd snap would lead to snapd stopping but no new snapd in place [12:45] dunno, i guess they'd rather use cpabilities from /sys or some such ... [12:46] ogra: well, I'll do some more investigating [12:46] at least on a deb/distro evel you typically dont have per cpu optimization but have the binaries rather look up single capabilities [12:46] t is definitely useful info for i.e. wrapper scripts in snaps [12:47] yep [12:48] ogra: oh, it is actually already allowed by hardware-observe [12:48] @{PROC}/device-tree/{,**} r, [12:48] oh, wow ... it allows all of it even [12:49] perfect [12:49] (it was added to support 'lshw -quiet') [12:55] mvo: conflcits in 5592 fwiw [12:56] Chipaca: yeah, on it [12:57] Chipaca: just testing locally a bit [13:00] ouf, 2pm and i haven't had lunch [13:03] https://paste.ubuntu.com/p/M3rXxHD35Y/ [13:08] mvo: hey, is the forum ok? I got only 2 emails from it last night. nothing after 01:29 UTC until 09:25 UTC. then got one at 09:58 UTC and then nothing since [13:09] mvo: I'm still looking to see if it is local [13:14] there wasnt much ... probably because most people in europe are simly melting and not sitting on computers :) [13:22] ogra: ok, that confirms it at least isn't local (I couldn't find it to be either) [13:22] 2 emails over night. that is unprecedented :) [13:22] i dont have cnstant emailing set up (only for direct notifications/mentions) but in general there wasnt much traffic tonight [13:25] I have constant [13:31] mvo: Chipaca: replaced MATCH with grep -qE in the first line the test failed and it failed on the next line [13:40] mborzecki: remind me what was the pr? [13:42] mborzecki: Ran for 1 hr 1 min 13 sec ! [13:43] * Chipaca runs the test by hand [13:47] Chipaca: https://github.com/snapcore/snapd/pull/5594 [13:47] Chipaca: tests/main/snap-env [13:54] mborzecki: hm, maybe a subtle bug in the new MATCH since it got fixed? [13:55] mborzecki: are you in a debug shell? if so, what do you get with declare -f MATCH? [13:56] mborzecki: the fact that there is no echo at all is a bit strange [13:56] mvo: running MATCH by hand works [13:57] that is, it passes [13:57] mvo: Chipaca: added set -x in MATCH https://paste.ubuntu.com/p/fRbXRQFVKk/ and it's not failing now [13:57] hmm [14:01] i'll try an earlier commit in spread [14:04] mborzecki: yeah, try the one before "echo | grep" was replaced with <<< [14:04] mvo: mhm, doing this right now [14:09] mvo: older revision is also failing [14:09] mborzecki: "good" I guess [14:10] mborzecki: also WTH? [14:10] mborzecki: what exit code do you get when it fails? [14:10] mborzecki: I mean right after match failure what is $? ? [14:11] mborzecki: you say ou added 'set -x' and it started passing? [14:12] mborzecki: because I overwrote MATCH in task.yaml itself, and it failed because of the wc -l test [14:12] because snap-vars.txt has 18 lines, now, not 12 [14:12] Chipaca: yes, in MATCH() https://paste.ubuntu.com/p/fRbXRQFVKk/ [14:12] Chipaca: yup, so it went throught the MATCH lines that were failing previously [14:12] ah, yes [14:13] Chipaca: what do you mean you rewrote it? copy & paste to task.yaml directly? [14:14] yah [14:16] but, i can reproduce the failure [14:16] local stdin=\"$(cat) <- this failing might make the script fail without any message [14:17] by which I mean: python3 -c $'import yaml;y=yaml.load(open("task.yaml"));\nfor i in ("execute","prepare","restore"):\n if i in y: open(i+".sh", "w").write(y[i])' [14:17] and the ( set -eux; source execute.sh ) [14:17] and i see it fail in the same way [14:18] Chipaca: you see it always failing the same way? [14:18] yes [14:19] Chipaca: you say "-x" there, does that yield anything useful? [14:20] mvo: if I overwrite MATCH with one that doesn't +x, the tests pass [14:20] mvo: if I add a add -v, the tests pass [14:20] Chipaca: can you add strace? [14:21] Chipaca: i.e. strace the entire beast with -f -s1024 [14:21] Chipaca: and then we can look for execve and wait and sigchild [14:21] hmmmmmmmmm [14:21] mvo: your favourite topic https://lwn.net/Articles/760584/ [14:21] Chipaca: and hopefully get a clue [14:21] mborzecki: *garrr* [14:22] mvo: if I add "echo HELLO" at the top of MATCH, I see 11 HELLOs, even when it fails [14:22] * cachio afk [14:23] Chipaca: *cough* wuut? 11? [14:24] mvo: so the MATCHes are passing [14:24] mvo: we're just not seeing the output [14:24] 11 is where the first known-to-fail test is [14:25] Chipaca: hm, ok. if you remove the fist 11 that work, I assume nothing changes and the 12th still fails? can that one be straced :) ? [14:25] * mvo would love to see the strace [14:25] mvo: the first one that fails is not a MATCH but the test [14:25] test $(wc -l < snap-vars.txt) -eq 12 [14:25] ^ that one [14:27] Chipaca: oh, sorry, I misunderstood this then. so match is fine for some reason we just don't see that it is "test $(wc -l)" that is failing? [14:27] Chipaca: if you add an "echo" before the test, is that visible in the failure output? [14:27] heh [14:29] mvo: before the "test $(wc -l < snap-vars.txt) -eq 12" line? [14:30] Chipaca: yeah, just curious if the echo (and possible output) is also eaten up [14:30] mvo: echo HELLO, and echo HELLO STDERR >&2, both work [14:30] right before the test line [14:31] Chipaca: interessting [14:31] mvo: things that also work: making the funciton run in a subshell (i.e. MATCH() ( … ) instead of MATCH() { … } [14:32] mvo, interesting, no, that box is checked [14:33] kyrofa: aha, then I was maybe just confused (its very hot here). anyway, I can merge master for you or you can do it, that should fix the spread tests (they were a bit unhappy in the past days) [14:33] Chipaca: confusing [14:33] mvo, happy to do it, the button isn't showing up for me either so I'll do it manually [14:33] Github might be a little sad right now [14:35] mvo, done [14:36] kyrofa: ta [14:36] Chipaca: do you have a reproducer that you could pastebin for lazy people like me to just run? or is it complicated? [14:38] mvo: working on it [14:40] Chipaca: ta! [14:44] https://pastebin.com/EBFtyBnr 'not seen' is actually seen, but after the first match the second one does not appear [14:47] mvo: got a reproducer [14:48] mvo: now working on minimising it a bit [14:49] Chipaca: https://pastebin.com/raw/4nzDYLRf [14:49] mborzecki: https://pastebin.ubuntu.com/p/D3nbpBtvMw/ [14:50] mvo: ^ [14:51] Chipaca: nice [14:51] mborzecki: nice as well :) [14:53] Chipaca: ok, so without "<<<" (replaced that with pipes) things seems to work [14:53] mvo: https://pastebin.ubuntu.com/p/7kyVQ373hy/ [14:54] mvo: changing 'gep <<< "$(cat)"' to 'cat | grep' fails in the same way [14:55] Chipaca: removing " { [14:55] set +ux [14:55] } 2> /dev/null" fixes it for me [14:55] mvo: as does dropping the x from that, or doing a set -v [14:55] Chipaca: egon@bod:~/devel/go/src/github.com/snapcore/snapd.mvo$ pastebinit /tmp/lala4.sh http://paste.ubuntu.com/p/GDJZCGz2CY/ [14:56] mvo: wa [14:56] haha lel [14:56] is this a new feature in bash [14:56] magic [14:57] mborzecki: you mean maciej [14:58] shall we fix it in spread then? [14:58] mborzecki: fix it how? [14:58] that bit of code is to avoid having debug output from MATCH itself [14:58] easiest fix is probably to do the subshell thing [14:58] behaviour-preserving fix i mean [14:59] hm, hm, let me check something [15:00] meanwhile pushed to fix to change 12 to 18, higher order algebra [15:01] btw. funny quote from the entropy pool article [15:01] > Laura Abbott was set to test the patch on a Fedora Rawhide kernel, but found that the hang at boot time waiting for random numbers .. [15:01] Chipaca: yeah, I was wondering if we need shopt or something but subshell seems least intrusive [15:02] mborzecki: yeah, I was reading this too, sad sad [15:11] mborzecki: wrt your PR, fix the wc -l test and it should pass [15:11] Chipaca: yup [15:11] the MATCH bug should not affect successful test results [15:11] https://i.imgur.com/CB7qWD6.jpg 45C [15:12] Chipaca: interesstingly http://paste.ubuntu.com/p/h72s4vVyB4/ works, so the pipe seems to trigger some cleanup in the stderr redirect [15:13] mvo: I'm pretty sure this counts as a bug in bash, fwiw [15:13] OTOH given how it behaves the same in 14.04 through 18.04, they might say it's working as intended (somehow) [15:14] OTO²H it wouldn't be the first antediluvian bug we've found [15:24] Chipaca: fun, looks like their bugtracker is a mailinglist [15:31] Chipaca: hm, let me quickly run an idea by you: this is our bug: we do "set +ux" in MATCH which is a function so no subshell. we run MATCH foo <<< foo which will also not create a subshell. at this point we did set +x which means we truned of tracing globally. when doing "echo foo|MATCH something" this will run match inside a subshell which means the traceing that is turned off does not affect our main shell. makes sense? [15:32] mborzecki: your input on the above is of course appreciated as well [15:32] mborzecki: 45°C?!? uhhh [15:33] mvo: makes sense [15:34] Chipaca: which means the fix is more () (you can never have enough): http://paste.ubuntu.com/p/jZJ5ySrCpV/ [15:34] mvo: I meant: MATCH() ( … ) [15:35] mvo: instead of MATCH() { … } [15:35] Chipaca: aha, yes! [15:35] Chipaca: are you on it already? or shall i do a spread fix? [15:35] mvo: go for it [15:35] Chipaca: thanks [15:36] Chipaca: I guess this is what you had in mind all along when you said "lets just use a subshell" earlier? [15:36] mvo: things that also work: making the funciton run in a subshell (i.e. MATCH() ( … ) instead of MATCH() { … } [15:36] mvo: ^there? :-) [15:36] Chipaca: yes [15:36] mvo: yes [15:37] Chipaca: *cough* I should read more carefully :) thank you, nice that we have yet another bug squashed [15:42] mvo, https://paste.ubuntu.com/p/Xn2vN9N7hz/ [15:42] here: https://travis-ci.org/snapcore/snapd/builds/411259659?utm_source=github_status&utm_medium=notification [15:43] cachio: this looks like an empty reply, no? [15:43] * mvo needs to be afk for some minutes [15:44] don't know [15:44] because mborzecki saw the same in another test [15:45] mborzecki, empty reply or we are not managing well in MATCH function [15:45] I am trying to reproduce it locally [15:45] mvo, I'll keep you updated [16:13]