mborzeckisnap instance user directory mappings are a bummer07:25
mvomborzecki: is it hard to do?07:26
mvomborzecki: btw, does 5561 need a sameule/gustavo review or could this go in with two reviews?07:27
mborzeckimvo: the setup is ugly, it already relies on SNAP_USER_DATA being set, now it's even worse07:27
mborzeckimvo: it'd be great if someone did a 2/3rd review perhaps07:28
mvomborzecki: ok07:35
mvomborzecki: I hope to find time for reviews today/tomorrow07:35
mborzeckimvo: thanks07:35
mborzeckimeanwhile 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 getpewnt07:36
mvomborzecki: sounds good07:37
mborzeckimvo: 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 scary07:37
Chipacamoin moin07:46
Chipacamborzecki: 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/558007:47
mborzeckiChipaca: looking07:47
Chipacamborzecki: thanks07:48
mborzeckiChipaca: high order math, +2 < 2 +1 :)07:50
Chipacamborzecki: IKR07:50
Chipacathe maths was there because the +6 was rather mysterious07:51
Chipacabut, not that much, i dunno07:51
Chipacai add comments when requested :-)07:51
mvokyrofa: 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:06
mvokyrofa: master merge to make tests great^Wgreen again08:07
mvosome easy wins: 5548 and 5450 (both relatively short)08:10
mborzeckiopened https://github.com/snapcore/snapd/pull/5594 for snapenv, i suppose it might be a bit controversial08:16
Chipacamvo: in looking at #5450, I saw a bit of code that looked suspicious08:34
Chipacamvo: in Put, if the Chtimes fails with an IsNotExist, we re-link the file08:34
Chipacamvo: but we don't re-Chtimes the file08:35
mvoChipaca: aha, let me have a look08:44
Chipacamvo: a few more comments there08:55
Chipacamvo: overall looks good though08:55
mvoChipaca: yeah, nice one on the hardLinkCount, thats indeed a bit silly08:57
Chipacamvo: that's the one that stopped me from +1'ing it :-)08:58
Chipacathe others are a non-rhetoric question, and a nit08:58
mvoChipaca: yeah, on it. thank you!08:59
Chipacamvo: the cache's Count isn't used outside of tests, right?09:00
mvoChipaca: correct, we can probably unexport it09:01
Chipacamvo: was the cache size a config?09:01
Chipacamvo: i was more worried about it being used in a loop somewhere, as it's not particularly efficient if the cache is arbitrarily sized09:02
Chipacaif the cache size is not configurable, it's less of a worry09:02
mvoChipaca: it is not configurable right now (the cache count)09:03
mvoChipaca: aha, yes, building a list of the content for the size is silly if the size is large09:04
mvoChipaca: I can: a) add a FIXME b) rework09:04
Chipacamvo: (a) is fine -- and it'll only be an issue if the list is big09:04
Chipacamvo: OTOH09:04
Chipacamvo: why even count n>1 files in the cache size?09:05
mvoChipaca: heh, yeah, maybe it should simply be "cacheTooBig() bool" instead of count09:05
mvo(well, proper name of course)09:05
Chipacamaybe we want to invert that: first step, remove n>1 files from fis; _then_ see if it's too big, sort it, etc09:06
mvoChipaca: hm, not sure I get the idea but let me first address the other comments and then I read it again and ponder about it09:08
Chipacamvo: i mean https://pastebin.ubuntu.com/p/wnrzqp72Gb/09:16
Chipacaer, except the last loop should be on filtered :-)09:16
Chipacaof course, as hardLinkCount is just an accessor, it probably makes more sense to do that twice instead of copying all the file infos over09:18
Chipacalovely morning for bikeshedding, isn't it?09:18
mvoChipaca: aha, I see what you mean, let me poke at it a bit more09:19
mvoChipaca: it is lovely! and the cache gets better with every iteration :)09:20
Chipacamvo: https://pastebin.ubuntu.com/p/H9fwdVrb7d/09:20
mvoChipaca: yeah, feel free to pull and commit, this looks nice09:21
Chipacamvo: and the 'are we ready yet' condition further down would need a tweak also09:21
Chipacamvo: ah ok, will do09:21
mvoChipaca: I would keep the comment about the link count and that we get stuff for free if the link count is > 109:21
mvoChipaca: but other than that I think this is nice and clean09:21
Chipacamvo: yeah, i was trying to explain the idea, not provide a diff :-D09:21
Chipacamvo: is "numOwned" the right name for that count?09:22
mvoChipaca: 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:25
mvoChipaca: yeah, I think numOwned is good, trying to think of anything more descriptive09:26
mvoChipaca: I think this is a good name09:26
Chipacamvo: 550d714b179733cc8e96bd2c91a1890af3613d6909:30
Chipacaoh wait, it's already there09:31
Chipacamvo: I pushed it to your repo :-D09:31
ChipacaI thought I could only do that when it was a PR09:31
Chipacagah, github needs to refresh my gpg keys09:32
mvoChipaca: tests are unhappy now - not sure if that is a bug in the tests or in the code. off by one it seems09:32
Chipacamvo: a bug? in code I wrote?! inconceivable!09:35
=== cjwatson_ is now known as cjwatson
Chipacamvo: ah, not a bug, just tests not updated for the smarter cache :-D09:47
mvoChipaca: oh? whats the issue with the test?09:50
mvoChipaca: aha, count needs an update as well? to return just unowned? or what is the best fix?09:54
Chipacamvo: looking09:55
mvomborzecki: when you have some spare cycles, 5540 is probably another easy win, just needs a second review09:56
mborzeckimvo: ack09:57
Chipacamvo: this might actually be a bug somewhere09:59
Chipacamvo: in TestPutMany, I print the Nlink of every file, and the last one is always 209:59
Chipacamvo: https://pastebin.ubuntu.com/p/rZFjtd39Sw/10:00
Chipacamvo: so it doesn't get cleaned up, so Count() > maxItems10:00
Chipacamvo: but the question is why is nlink>110:00
Chipacais something holding the file open?10:01
mvoChipaca: hm, let me double check iirc its using iotutil.WriteFile() for the temp file creation10:01
Chipacaactually holding it open doesn't increase nlink10:02
mvoChipaca: 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 it10:02
mvoChipaca: the remove of the test file is after the put10:02
mvoChipaca: so probably just a confusing test10:02
Chipacaoh drat10:03
Chipacamvo: i'm counting before the remove10:03
* Chipaca is dumb :-)10:03
* Chipaca moves it and tries again10:03
mvoChipaca: its complicated10:03
mvoChipaca: I mean life and computers and all that10:03
Chipacamvo: relationships also10:03
mvoChipaca: *cough* wise words!10:04
Chipacamvo: so, yes, it's that at Put time the count is 210:04
mvoChipaca: so all good, we just need to update the test and add a comment I guess10:05
Chipacamvo: should I, or will you?10:06
mvoChipaca: either way is fine, let me do it, I pulled you deep enough into this rabbithole already10:06
* Chipaca puts down his "100 ways of cooking rabbit" book10:06
mvoChipaca: update pushed, I will merge once tests are green10:11
mvo5576 is also a trivial win10:12
Chipacamvo: '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 time10:12
mvoChipaca: hm, good point, let me try to correct this10:18
mvoChipaca: I force pushed an updated version10:19
Chipacamvo: s/has/had/, s/its/it's/, but only because I'm at nit central and it's nit breeding season10:20
Chipacamvo: s/its is/it's/10:21
mvoChipaca: heh, force pushed again10:22
* Chipaca is busy with a technical issue involving biscuits and coffee in a mug that is too narrow for dunking10:23
mvodown to 36 PRs and counting!10:25
mborzeckihm 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?10:56
Chipacamvo: 3511:33
cachiomvo, https://paste.ubuntu.com/p/rWZNvyVXpc/11:36
cachioI was taking a look to the PR which fix that11:38
cachiomvo, #544011:38
xnox2018-08-01 20:43:25 Failed tasks: 111:40
xnox    - autopkgtest:ubuntu-18.10-arm64:tests/main/auto-refresh11:40
xnoxi hope this is a fluke, retrying cosmic snapd autopkgtest11:40
ograxnox, yo ... how good is your journald fu ? (i'm looking for someone who has some insight into it)11:43
Chipacamvo: mborzecki: https://gist.github.com/chipaca/911a8a4905b091c10caa9854bf7ea4b411:44
ogranot sure you saw my questions in the backlog in #ubuntu-devel from last night11:44
xnoxogra, nothing beyond what the manpage says..... but you can try11:44
ograxnox, 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 set11:45
mborzeckiaare expert needed, @{HOME}/snap/*_*/ does not match /home/test/snap/test-snapd-tools_foo/ ?11:50
mvomborzecki: thats surprising - jdstrand will know why @{HOME}/snap/*_*/ does not match /home/test/snap/test-snapd-tools_foo/ ?11:52
mborzeckii 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:53
mvocachio: is the fix for  refresh.timer=managed incomplete?11:54
Saviqhmm refreshing a snap just now, snapd seems stuck at "Copy snap... data" (there's a whole of 512 bytes in $SNAP_DATA...)11:57
Saviqthat a known issue?11:57
cachiomvo, well, it is not working12:00
cachiowe received an email yesterday about this issue12:00
cachiomvo, sudo snap set system refresh.timer=managed12:00
cachioit is not working neither12:01
mborzeckiSaviq: can you do snap change --last=refresh? maybe its waiting for some dependency12:01
mvocachio: thanks, checking12:02
cachiomvo, thanks12:06
mvocachio: will send a pr shortly, quite annoying, the validation is in the way12:09
cachiomvo, thanks12:11
cachiomvo, I could make a new spread test for that, or update one12:13
mvocachio: I'm updating the existing one as part of the fix12:13
cachiomvo, great :)12:13
mvocachio: but yeah, that was the problem, the previous change lacked a full end-to-end test12:13
mvocachio: I think I missed the mail from yesterday about this, who send it?12:14
Saviqmborzecki: sorry, missed it, seems to have refreshed after all12:14
cachiomvo, it was a reply for the announcement which I did saying the 2.34.3 was promoted to candidate12:15
cachiomvo, Tony Espy sent it12:15
mborzeckiSaviq: can you post the output nonetheless? it's interesting if there was some dep after all12:15
Saviqmborzecki: http://paste.ubuntu.com/p/c8cXZhTRv3/12:16
mborzeckiSaviq: when that happens (i mean a task is waiting for some dep), the prompt is seemingly stuck, probably bad ux on our side12:16
Saviqso it took 16 mins12:17
mborzeckiChipaca: do you remember of 'ready' column is when the task is done?12:18
Chipacamborzecki: yes12:18
Chipacaspawntime is when the task was created, readytime is when it's finished12:19
mborzeckiso maybe it did take that long after all12:19
Chipacamborzecki: well, maybe12:20
Chipacawe're probably missing a 'start time' to know exactly what happened12:21
ChipacaOTOH if you run with SNAPD_DEBUG=1 you'd know more12:21
jdstrandmborzecki: can you show me the full denial and the full rule that doesn't match?12:21
jdstrand(for the '_')12:21
ChipacaSaviq: were you running with SNAPD_DEBUG=1?12:22
mborzeckijdstrand: https://github.com/bboozzoo/snapd/commit/07de54fe9b126923dbc15251a09fbda0a8f84204 and https://paste.ubuntu.com/p/y4kNfM734Y/12:22
mborzeckijdstrand: the other 2 rules for /snap/*_* and /var/snap/*_* seem to match, i was getting denials before and now they are gone12:23
SaviqChipaca: I'm afraid no12:24
mborzeckiheh weird failure with MATCH https://paste.ubuntu.com/p/M3rXxHD35Y/, obviously works if running in the debug shell12:27
jdstrandmborzecki: you are hitting https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/161239312:27
mborzeckijdstrand: so just /home/*/snap.. ?12:28
threshneat, gcloud packaged in snap12:28
* thresh apt removes it12:28
mvocachio: 5595 fixes the refresh.timer issue for real this time12:30
jdstrandmborzecki: 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 location12:30
jdstrandmborzecki: 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 comment12:32
cachiomvo, great, thanks, I'll take a look now12:32
jdstrandmborzecki: and move on12:32
mborzeckijdstrand: had to use 'mount options=(rw rbind) /home/*/snap/*_*/ -> /home/*/snap/*/,'12:32
mborzeckijdstrand: and it sort of works, thanks for the help! :)12:33
jdstrandoh right, you aren't mounting on /home/*/snap/*/12:33
jdstrandyou aren't mounting on /home/*/snap/*_*/12:33
jdstrandyou are mount from foo_parallel to foo12:33
jdstrandso that makes sense12:33
ograjdstrand, regarding the device-tree/model access i think it should live in the same interface that allows /proc/cpuinfo (whichever that is)12:34
ograIMHO they are equivalent12:35
jdstrandogra: that is allowed by default in the base abstraction because it is used by glibc's sysconf12:37
ograbah ... damned :)12:37
ograi thought i found a clever criteria ;)12:37
mborzeckiparallel installs integration branch https://github.com/snapcore/snapd/pull/559612:38
Chipacamvo: I'm looking at 559212:38
ogra*criterion ??12:38
jdstrandogra: 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
Chipacamvo: without this, would the broken snapd snap install succeed?12:38
Chipacaogra: critteropolis12:39
ograjdstrand, nothing fails, thats really optional but allows you to i.e. distinguish on which specific Pi model you run12:39
jdstrandogra: it seems like very few things fail otherwise we would have heard about it much sooner12:39
ograyeah, nothing fails ... but it would be good to be able to get to that info12:40
jdstrandit'll be added12:40
jdstrand$ cat /proc/device-tree/model12:40
jdstrandTI AM335x BeagleBone Black12:40
ogra(i'm working towards a unified Pi image that runs on all Pi's and there it would be come ore important)12:40
jdstrandok, that isn't very sensitive12:40
* jdstrand nods12:41
jdstrandI saw the thread. sounds neat12:41
ograits the same as "Hardware:" in /proc/cpuinfo in most cases i think12:41
jdstrandHardware: Generic AM33XX (Flattened Device Tree)12:41
ograah, k ... so it is actually more secific12:41
ograHardware: BCM270912:42
ograon a pi312:42
jdstrandhuh, on pi 2 it is quite different12:43
jdstrandbarely*$ grep Hardware /proc/cpuinfo12:43
jdstrandHardware: BCM270912:43
jdstrand$ grep Hardware /proc/cpuinfo12:43
jdstrandHardware: BCM270912:43
jdstrand$ cat /proc/device-tree/model12:43
jdstrandRaspberry Pi 2 Model B Rev 1.112:43
ograwell, they use the same CPU core ... but differet SoC peripherials12:43
jdstrandbut obviously someone can create a map having only BCM270912:43
ograso here the devicetree model is actually helpful12:44
jdstrandogra: this doesn't sound sensitive at all with the things that we already allow by default12:44
ograah, you mean we could allow it without interface12:44
ografine with me as well12:44
jdstrandthat is what I'm thinking12:44
mvoChipaca: yes12:44
ograif cpuinfo is accessible the model should be too12:44
jdstrandogra: is it generally useful? like, will a library ever look at that to try to optimize something?12:45
mvoChipaca: so without 5592 a broken (or empty) snapd snap would lead to snapd stopping but no new snapd in place12:45
ogradunno, i guess they'd rather use cpabilities from /sys or some such ...12:45
jdstrandogra: well, I'll do some more investigating12:46
ograat least on a deb/distro evel you typically dont have per cpu optimization but have the binaries rather look up single capabilities12:46
ograt is definitely useful info for i.e. wrapper scripts in snaps12:46
jdstrandogra: oh, it is actually already allowed by hardware-observe12:48
jdstrand@{PROC}/device-tree/{,**} r,12:48
ograoh, wow ... it allows all of it even12:48
jdstrand(it was added to support 'lshw -quiet')12:49
Chipacamvo: conflcits in 5592 fwiw12:55
mvoChipaca: yeah, on it12:56
mvoChipaca: just testing locally a bit12:57
Chipacaouf, 2pm and i haven't had lunch13:00
mborzecki https://paste.ubuntu.com/p/M3rXxHD35Y/13:03
jdstrandmvo: 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 since13:08
jdstrandmvo: I'm still looking to see if it is local13:09
ograthere wasnt much ... probably because most people in europe are simly melting and not sitting on computers :)13:14
jdstrandogra: ok, that confirms it at least isn't local (I couldn't find it to be either)13:22
jdstrand2 emails over night. that is unprecedented :)13:22
ograi dont have cnstant emailing set up (only for direct notifications/mentions) but in general there wasnt much traffic tonight13:22
jdstrandI have constant13:25
mborzeckimvo: Chipaca: replaced MATCH with grep -qE in the first line the test failed and it failed on the next line13:31
Chipacamborzecki: remind me what was the pr?13:40
Chipacamborzecki:  Ran for 1 hr 1 min 13 sec !13:42
* Chipaca runs the test by hand13:43
mborzeckiChipaca: https://github.com/snapcore/snapd/pull/559413:47
mborzeckiChipaca: tests/main/snap-env13:47
mvomborzecki: hm, maybe a subtle bug in the new MATCH since it got fixed?13:54
mvomborzecki: are you in a debug shell? if so, what do you get with declare -f MATCH?13:55
mvomborzecki: the fact that there is no echo at all is a bit strange13:56
Chipacamvo: running MATCH by hand works13:56
Chipacathat is, it passes13:57
mborzeckimvo: Chipaca: added set -x in MATCH https://paste.ubuntu.com/p/fRbXRQFVKk/ and it's not failing now13:57
mborzeckii'll try an earlier commit in spread14:01
mvomborzecki: yeah, try the one before "echo | grep" was replaced with <<<14:04
mborzeckimvo: mhm, doing this right now14:04
mborzeckimvo: older revision is also failing14:09
mvomborzecki: "good" I guess14:09
mvomborzecki: also WTH?14:10
mvomborzecki: what exit code do you get when it fails?14:10
mvomborzecki: I mean right after match failure what is $? ?14:10
Chipacamborzecki: you say ou added 'set -x' and it started passing?14:11
Chipacamborzecki: because I  overwrote MATCH in task.yaml itself, and it failed because of the wc -l test14:12
Chipacabecause snap-vars.txt has 18 lines, now, not 1214:12
mborzeckiChipaca: yes, in MATCH()  https://paste.ubuntu.com/p/fRbXRQFVKk/14:12
mborzeckiChipaca: yup, so it went throught the MATCH lines that were failing previously14:12
Chipacaah, yes14:12
mborzeckiChipaca: what do you mean you rewrote it? copy & paste to task.yaml directly?14:13
Chipacabut, i can reproduce the failure14:16
mvolocal stdin=\"$(cat) <- this failing might make the script fail without any message14:16
Chipacaby 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
Chipacaand the ( set -eux; source execute.sh )14:17
Chipacaand i see it fail in the same way14:17
mvoChipaca: you see it always failing the same way?14:18
mvoChipaca: you say "-x" there, does that yield anything useful?14:19
Chipacamvo: if I overwrite MATCH with one that doesn't +x, the tests pass14:20
Chipacamvo: if I add a add -v, the tests pass14:20
mvoChipaca: can you add strace?14:20
mvoChipaca: i.e. strace the entire beast with -f -s102414:21
mvoChipaca: and then we can look for execve and wait and sigchild14:21
mborzeckimvo: your favourite topic https://lwn.net/Articles/760584/14:21
mvoChipaca: and hopefully get a clue14:21
mvomborzecki: *garrr*14:21
Chipacamvo: if I add "echo HELLO" at the top of MATCH, I see 11 HELLOs, even when it fails14:22
* cachio afk14:22
mvoChipaca: *cough* wuut? 11?14:23
Chipacamvo: so the MATCHes are passing14:24
Chipacamvo: we're just not seeing the output14:24
Chipaca11 is where the first known-to-fail test is14:24
mvoChipaca: 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 strace14:25
Chipacamvo: the first one that fails is not a MATCH but the test14:25
Chipacatest $(wc -l < snap-vars.txt) -eq 1214:25
Chipaca^ that one14:25
mvoChipaca: 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
mvoChipaca: if you add an "echo" before the test, is that visible in the failure output?14:27
Chipacamvo: before the "test $(wc -l < snap-vars.txt) -eq 12" line?14:29
mvoChipaca: yeah, just curious if the echo (and possible output) is also eaten up14:30
Chipacamvo: echo HELLO, and echo HELLO STDERR >&2, both work14:30
Chipacaright before the test line14:30
mvoChipaca: interessting14:31
Chipacamvo: things that also work: making the funciton run in a subshell (i.e. MATCH() ( …  )  instead of  MATCH() { … }14:31
kyrofamvo, interesting, no, that box is checked14:32
mvokyrofa: 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
mvoChipaca: confusing14:33
kyrofamvo, happy to do it, the button isn't showing up for me either so I'll do it manually14:33
kyrofaGithub might be a little sad right now14:33
kyrofamvo, done14:35
mvokyrofa: ta14:36
mvoChipaca: do you have a reproducer that you could pastebin for lazy people like me to just run? or is it complicated?14:36
Chipacamvo: working on it14:38
mvoChipaca: ta!14:40
mborzeckihttps://pastebin.com/EBFtyBnr 'not seen' is actually seen, but after the first match the second one does not appear14:44
Chipacamvo: got a reproducer14:47
Chipacamvo: now working on minimising it a bit14:48
mborzeckiChipaca: https://pastebin.com/raw/4nzDYLRf14:49
Chipacamborzecki: https://pastebin.ubuntu.com/p/D3nbpBtvMw/14:49
Chipacamvo: ^14:50
mvoChipaca: nice14:51
mvomborzecki: nice as well :)14:51
mvoChipaca: ok, so without "<<<" (replaced that with pipes) things seems to work14:53
Chipacamvo: https://pastebin.ubuntu.com/p/7kyVQ373hy/14:53
Chipacamvo: changing 'gep <<< "$(cat)"' to 'cat | grep' fails in the same way14:54
mvoChipaca: removing " {14:55
mvo        set +ux14:55
mvo    } 2> /dev/null" fixes it for me14:55
Chipacamvo: as does dropping the x from that,  or doing a set -v14:55
mvoChipaca: egon@bod:~/devel/go/src/github.com/snapcore/snapd.mvo$ pastebinit /tmp/lala4.sh http://paste.ubuntu.com/p/GDJZCGz2CY/14:55
Chipacamvo: wa14:56
Chipacahaha lel14:56
Chipacais this a new feature in bash14:56
Chipacamborzecki: you mean maciej14:57
mborzeckishall we fix it in spread then?14:58
Chipacamborzecki: fix it how?14:58
Chipacathat bit of code is to avoid having debug output from MATCH itself14:58
Chipacaeasiest fix is probably to do the subshell thing14:58
Chipacabehaviour-preserving fix i mean14:58
mvohm, hm, let me check something14:59
mborzeckimeanwhile pushed to fix to change 12 to 18, higher order algebra15:00
mborzeckibtw. funny quote from the entropy pool article15:01
mborzecki> 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
mvoChipaca: yeah, I was wondering if we need shopt or something but subshell seems least intrusive15:01
mvomborzecki: yeah, I was reading this too, sad sad15:02
Chipacamborzecki: wrt your PR, fix the wc -l test and it should pass15:11
mborzeckiChipaca: yup15:11
Chipacathe MATCH bug should not affect successful test results15:11
mborzeckihttps://i.imgur.com/CB7qWD6.jpg 45C15:11
mvoChipaca: interesstingly http://paste.ubuntu.com/p/h72s4vVyB4/ works, so the pipe seems to trigger some cleanup in the stderr redirect15:12
Chipacamvo: I'm pretty sure this counts as a bug in bash, fwiw15:13
ChipacaOTOH given how it behaves the same in 14.04 through 18.04, they might say it's working as intended (somehow)15:13
ChipacaOTO²H it wouldn't be the first antediluvian bug we've found15:14
mvoChipaca: fun, looks like their bugtracker is a mailinglist15:24
mvoChipaca: 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:31
mvomborzecki: your input on the above is of course appreciated as well15:32
mvomborzecki: 45°C?!? uhhh15:32
Chipacamvo: makes sense15:33
mvoChipaca: which means the fix is more () (you can never have enough): http://paste.ubuntu.com/p/jZJ5ySrCpV/15:34
Chipacamvo: I meant: MATCH() ( … )15:34
Chipacamvo: instead of MATCH() { … }15:35
mvoChipaca: aha, yes!15:35
mvoChipaca: are you on it already? or shall i do a spread fix?15:35
Chipacamvo: go for it15:35
mvoChipaca: thanks15:35
mvoChipaca: I guess this is what you had in mind all along when you said "lets just use a subshell" earlier?15:36
Chipaca<Chipaca> mvo: things that also work: making the funciton run in a subshell (i.e. MATCH() ( …  )  instead of  MATCH() { … }15:36
Chipacamvo: ^there? :-)15:36
mvoChipaca: yes15:36
Chipacamvo: yes15:36
mvoChipaca: *cough* I should read more carefully :) thank you, nice that we have yet another bug squashed15:37
cachiomvo, https://paste.ubuntu.com/p/Xn2vN9N7hz/15:42
cachiohere: https://travis-ci.org/snapcore/snapd/builds/411259659?utm_source=github_status&utm_medium=notification15:42
mvocachio: this looks like an empty reply, no?15:43
* mvo needs to be afk for some minutes15:43
cachiodon't know15:44
cachiobecause mborzecki saw the same in another test15:44
cachiomborzecki, empty reply or we are not managing well in MATCH function15:45
cachioI am trying to reproduce it locally15:45
cachiomvo, I'll keep you updated15:45
mvocachio: you may want to try my latest spread PR16:13
cachiomvo, sure16:23
cachiomvo, I was wondering if it is already possible to create a core-18 image on edge?16:24
cachiousing ubuntu-image16:24
kyrofanoise][, I'm getting a 504 trying to get snap metrics, status seems all green16:49
noise][kyrofa: what URL?16:52
kyrofanoise][, https://snapcraft.io/account/snaps/nextcloud/metrics16:55
noise][looks like it's timing out, working on other snaps. Can you please file a bug?16:56
kyrofanoise][, done: https://bugs.launchpad.net/snapstore/+bug/178509416:58
noise][thx, we'll dig in.16:59
cachiomvo, I could reproduce the issue using your spread PR17:09
FreeBDSMsnap is too complex17:14
FreeBDSMI use mozilla's script that built firefox esr 60+17:14
FreeBDSMI've used it to build 52.9.0-esr17:14
FreeBDSMit built fine, it runs and works, but instead of pages I see nothing17:14
kyrofamvo, yikes: https://api.travis-ci.org/v3/job/411316584/log.txt17:44
kyrofamvo, that's https://github.com/snapcore/snapd/pull/5569 after merging with master :P17:45
=== Caelum_ is now known as Caelum
ads20000popey Wimpress is it possible to use custom Wine patches within your tmnationsforever Wine schema? :)19:34
ads20000(well, I guess it is possible, just wondering if there's an easy way of doing that... presumably I bundle the .patch files in the repo and then put in patch -pi < foo.patch somewhere in the .yaml but I don't know where...)19:35
mvocachio: sorry for the delay. hm, sad to hear that spread MATCH still has the same issue19:48
mvocachio: re core18 image, let me mail you some details19:48
cachiomvo, np19:48
cachiomvo, nice, thanks19:48
mvocachio: see /msg19:50
roadmrmvo: you're still up! can I trouble you a bit?19:53
mvoroadmr: sure20:06
roadmrmvo: two things! 1) I checked that seeds repository seb pointed me to, but can't find where snap:core is included. Is that implicit somewhere if the image has any snap:whatevers?20:07
roadmrand 2) how is the revision of the snap that gets baked in the image determined? is it mentioned anywhere, or a simple snapshot of what was currently on stable when the image was built?20:08
mvoroadmr: I haven't looked at the seed but I'm pretty sure its implicit20:08
roadmrok... yes, that sounds plausible for core20:08
mvoroadmr: (2) not 100% sure but about 80% that its whatever is in stable at the image building time20:08
roadmrmvo: the reason we want this is: we want to know which revisions of snaps are included in images (isos and maybe cloud images) so we can ensure deltas to go from that version to the latest stable are always available20:09
mvoroadmr: everything else would also be difficult because the builder cannot access snaps by revision20:09
roadmrmvo: right - oh that's a very good point.20:09
mvoroadmr: aha, I see20:09
roadmrthen I guess it's what's on stable... which leads to - do you know if there's a build log or something which tells us which version ended up in the image?20:09
mvoroadmr: the images usually have a manifest, let me see if I can find the LP builders20:09
roadmrah exactly :) thanks!!20:09
mvoroadmr: I need to find it :) but yeah, there is one20:10
roadmrmvo: for example - the download to upgrade an 18.04 image's core was 91 MB; yesterday we built the deltas and download size went down to 27 mb20:10
roadmranyone booting 18.04 and waiting until the snaps refresh will benefit from this, starting yesterday20:10
roadmrmvo: no rush/problem, if you happen to remember where they are that'd be useful20:11
roadmrmvo: as is, we have to look at our metrics and react when we see lots of misses for a snap. Not intractable but we'd like something more preemptive/authoritative.20:11
mvoroadmr: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntu has the builds and the build logs20:18
roadmrmvo: marvelous :) thanks!20:18
mvoroadmr: my pleasure20:18
mvohas anyone seen "- Fetch and check assertions for snap "core" (5183) (cannot get device session from store: store server returned status 400 and body "{\"error_list\":[{\"code\":null,\"message\":\"Nonce is missing or invalid.\"}],\"errors\":[\"Nonce is missing or invalid.\"],\"result\":\"error\"}\n")"20:21
roadmrmvo: hmm is that reproducible? when a device gets a session from the store, it does a handshake that includes a nonce and it has to send that back as part of the dance20:24
roadmrmvo: it usually just works, but if this is happening consistently it might need a look20:24
mvoroadmr: thanks! its the first time I saw it, probably a one-off issue then, I retriggered the test now20:26
* mvo crosses finggers20:26
roadmrmvo: hope it works, but let me know if not.20:26
roadmr(might have been a memcached hiccup; but that hasn't been an issue in ages)20:26
robert_ancellHas anyone talked to Gitlab about making snaps? It would be pretty awesome to 'snap install gitlab-runner'23:01

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!