/srv/irclogs.ubuntu.com/2017/11/30/#snappy.txt

=== chihchun_afk is now known as chihchun
mborzeckimorning05:58
zyga-ubuntuhi06:03
zyga-ubuntumborzecki: man, I need more sleep06:03
mborzeckizyga-ubuntu: hey06:03
mborzeckiseen the snow outside?06:03
zyga-ubuntuyes06:04
zyga-ubuntumy kids are happy06:04
zyga-ubuntumy wife is not, the car is all covered with snow06:04
mborzeckihaha, same here :)06:05
mborzeckii see Chipaca fixed #429106:06
zyga-ubuntuman06:06
mupPR #4291: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <https://github.com/snapcore/snapd/pull/4291>06:06
zyga-ubuntuour logs are too long06:06
mborzeckii'm slightly confused, there's 'syscall' package and 'golang.org/x/sys/unix', looks like 'syscall' is covered by go's stable api promise but x/sys/unix is not, so any fixing if 'syscall' actually happens in x/sys/unix06:14
mborzeckis/if 'syscall'/of 'syscall'/06:14
zyga-ubuntumborzecki: and x/sys/unix is not ported to all arches06:18
zyga-ubuntumborzecki: anyway, I'm happy with https://github.com/snapcore/snapd/pull/432406:18
mupPR #4324: cmd/snap-confine: discard stale mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/4324>06:18
zyga-ubuntuneeds small rework but it is worth it06:18
mborzeckilet me have a quick look06:20
zyga-ubuntumborzecki: if you have backlog from yesterday midnight it's sensible to look06:23
zyga-ubuntuwell, 22:04 -> 2306:23
zyga-ubuntusmall coffee06:30
ogra_zyga-ubuntu, thats called espresso06:43
zyga-ubuntuogra_: no, I wasn't honest06:46
zyga-ubuntuafter my wife made me de-snow the car in flip flops06:46
zyga-ubuntuI want a 1L jug of tea06:46
zyga-ubuntuand a bit coffee with lots of warm water06:47
zyga-ubuntumaaan06:47
zyga-ubuntuit's winter :D06:47
zyga-ubuntumborzecki: how would you feel about migrating away from indent onto clang-format?06:47
ogra_dont tell me ... i have a broken ankle and have to fly home in flip/flops on sat.06:47
ogra_not yet sure how i'll manage to get from frankfurt to kassel without proper shoes then06:48
mborzeckizyga-ubuntu: sounds good to me, have you checked if 14.04 (or do we need it there for the unit tests?)06:48
mborzeckiclearly I have not had a morning coffee yet06:48
zyga-ubuntumborzecki: I'll check everything in detail, I only saw it failed on core (where it reboots so there's no need for this)06:49
zyga-ubuntulooking at 14.04 log again06:49
zyga-ubuntuthough06:49
mborzeckizyga-ubuntu: uncrustify if a simpler alternative though06:49
zyga-ubuntuI'll have to rewrite this a bit after yesterday's discussion06:49
zyga-ubuntubut first06:50
zyga-ubuntushower and tea06:50
mvoogra_: uh, did you break it during the sprint? sorry to hear that, get well!06:50
ogra_mvo, yeah, directly on monday evening ... only a micro fracture but really annoying when you cant walk around the city a lot in the evenings06:51
mvoogra_: :(06:51
mvoogra_: indeed. get well!06:51
zyga-ubuntuogra_: you need more structural integrity ;_)06:51
ogra_OTOH i had an exciting day at the taipei hospital06:51
zyga-ubuntu(sorry, bad humor in the morning perhaps)06:51
ogra_quite an experience ...06:52
zyga-ubuntumvo: https://github.com/snapcore/snapd/pull/432406:52
mupPR #4324: cmd/snap-confine: discard stale mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/4324>06:52
mvoogra_: heh, at least you got a good story out of it06:52
ogra_zyga-ubuntu, tsk ... thats exactly the same my GF said !06:52
mvozyga-ubuntu: yeah, I saw it06:52
zyga-ubuntumvo: will need a small change (more forking to avoid kernel bugs)06:53
ogra_mvo, yeah, and i could see some of the city by daylight even ... which i normally dont during a sprint :)06:53
mvohaha, so truuuueeee06:53
zyga-ubuntuogra_: so "break a leg" will now mean "enjoy the sprint outside of the office"? :D06:54
ogra_yeah !06:54
mvomborzecki: you triggered a build 2h ago? man, you are up early :)06:58
mupPR snapd#4319 closed: tests: add support for autopkgtests on s390x <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4319>07:00
mupPR snapd#4326 opened: interfaces/builtin: blacklist zigbee dongle <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4326>07:06
zyga-ubunture07:10
ogra_mvo, if i want to add a new config option to core now, where do i do it ? still in the core snap source or somewhere hidden in snapd ?07:42
mvoogra_: its now in snapd, one sec07:44
mvoogra_: https://github.com/snapcore/snapd/tree/master/corecfg07:44
ogra_configstate/configcore/ ?07:44
ogra_ah07:45
mvoogra_: yeah, that is the final one07:45
mvoogra_: but the PR is iirc not quite merged07:45
mvoogra_: I was about to point you to the PR :) what option do you need?07:45
ogra_mvo, https://forum.snapcraft.io/t/disabling-the-assertion-auto-import-job-on-core-should-be-possible/292307:45
ogra_(for a customer, not super urgent but soon it will be, so i wanted to check how it works now)07:46
ogra_hmm07:47
ogra_the question is if the service managing works on things in multi-user-target too ...07:47
* zyga-ubuntu runs tests and hopes for the best07:47
* ogra_ wonders if systemd is clever enough07:47
ogra_mvo, hmm, i see Disable in  https://github.com/snapcore/snapd/blob/master/systemd/systemd.go but i dont see mask used anywhere, didnt we switch to mask because of writable transitions ?07:54
ogra_(to force linking to /dev/null)07:54
zyga-ubuntumvo: offtopic, did you consider changing the display on your x250?07:54
mvoogra_: oh, that is possible that this got lost during the transition, that is a must-fix, let me double check07:54
ogra_grepping for "ask" doesnt reveal anything in https://github.com/snapcore/snapd/blob/master/systemd/systemd.go or https://github.com/snapcore/snapd/blob/master/corecfg/services.go07:55
ogra_so i think it got lost07:55
mvozyga-ubuntu: I have not considered that just yet, is it worth it?07:55
zyga-ubuntumvo: I'm lookin at it and I think it is07:55
zyga-ubuntumvo: I have a slightly broken panel07:55
zyga-ubuntumvo: and considering swapping it for a new one07:55
zyga-ubuntumvo: the HD TN panel is half the price07:56
mvoogra_: do you remember the original PR?07:56
zyga-ubuntubut it really looks like crap when compared side-by-side07:56
mvozyga-ubuntu: heh, yeah, I think I would go for the best available one07:56
ogra_mvo,   https://github.com/snapcore/core/pull/6107:56
mupPR core#61: Also "mask" services when disabling them <Created by mvo5> <Merged by ogra1> <https://github.com/snapcore/core/pull/61>07:56
mvozyga-ubuntu: given that its a lot of your time that you need to invest into fixing it07:56
mvoogra_: nice, thank you!07:56
zyga-ubuntumvo: well, it's open already :D07:56
mvozyga-ubuntu: heh07:57
zyga-ubuntumvo: I sent you three photos07:57
zyga-ubuntuthe 2nd laptop is a music box while I wait for parts :)07:57
zyga-ubuntuthe viewing angles on that TN panel are horrid07:57
mborzeckitn?07:58
zyga-ubuntumborzecki: x240 with TN panel vs x250 with IPS07:58
mborzeckiiirc x250 had full hd ips panels too07:58
mvozyga-ubuntu: heh07:58
zyga-ubuntuthe current TN panel is broken a little and I'm just considering which to replace07:58
mvoogra_: thanks for the link, I will add code to corecfg today to fix this. good catch!07:58
ogra_mvo, hmm, but mask for snapd.autoimport.service just creates a /dev/null symlink in /etc/systemd/system ... /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service still exists and points to the old target07:59
ogra_so that might be a bit trickier than just calling mask/stop/etc ...08:00
zyga-ubuntu(fingers crossed guys:)08:00
ogra_:/08:00
mborzeckizyga-ubuntu: http://allegro.pl/matryca-lenovo-x240-x250-1920x1080-fhd-ips-04x3922-i7010276242.html ?08:00
zyga-ubuntumborzecki: right, I was looking at ebay but the prices there are similar08:01
zyga-ubuntumborzecki: I was a bit tempted to see if there is a FHD + touch model08:02
zyga-ubuntumborzecki: but I didn't check if the motherboard for non-touch model accepts that08:02
zyga-ubuntumborzecki: since this laptop is for my mother, she could probably use touch as extra-intuitive input method08:02
zyga-ubuntumborzecki: though she will mainy use it for writing books08:02
ogra_hmm, but it seems systemctl is clever enough here ...08:03
ogra_ogra@pi3:~$ sudo systemctl list-unit-files|grep autoimport08:03
ogra_snapd.autoimport.service                   enabled08:03
ogra_ogra@pi3:~$ sudo systemctl mask snapd.autoimport.service08:03
ogra_Created symlink from /etc/systemd/system/snapd.autoimport.service to /dev/null.08:03
ogra_ogra@pi3:~$ sudo systemctl list-unit-files|grep autoimport08:03
ogra_snapd.autoimport.service                   masked08:03
ogra_.... even though /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service still exists and points to the old target08:04
mupPR snapd#4327 opened: release: merge 2.30~rc1 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4327>08:04
mvopstolowski: hey, good morning. do we have a forum topic for the post-refresh hook? I'm updating the roadmap right now08:12
mupPR snapd#4328 opened: wrappers: fix unit tests to use dirs.SnapMountDir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4328>08:14
mborzeckitrivial review ^^08:14
pstolowskimvo, hey! there was something, but I'm not sure if it's useful to anyone. i need to search it08:14
pstolowskimvo, ok, that was https://forum.snapcraft.io/t/install-remove-hooks/478 but it's not really covering post- and pre- which we ended up with08:16
pstolowskimvo, I'll respond in this thread with up-to-date info08:17
mborzeckimvo: thanks for the review08:18
zyga-ubuntumborzecki: doing08:19
zyga-ubuntudone08:19
mborzeckizyga-ubuntu: thanks08:20
mvopstolowski: ta08:22
zyga-ubuntusmall simplification and another run08:24
zyga-ubuntumaybe last one :)08:24
KristijanZicHi, I'm having trouble downloading Ubuntu Core 16 for RPi3 (edge) image. I get the Apache 403 sever error. Can somebody configure that real quick?08:54
KristijanZichere is the link: http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz08:55
zyga-ubuntuKristijanZic: works for me08:55
zyga-ubuntuKristijanZic: maybe you have a transparent proxy?08:55
KristijanZiczyga-ubuntu: thanks, it was my adblock08:57
mborzeckianyone wants to take a stab at reviewing #4313?08:59
mupPR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>08:59
zyga-ubuntumborzecki: I'll look but I want to finish this invalidation first09:01
zyga-ubuntuoohh09:06
zyga-ubuntudarn09:06
zyga-ubuntu1 vs 0 typo09:06
zyga-ubuntunow it works09:06
zyga-ubuntuffss..09:06
mborzecki:)09:07
mborzeckidamn my back hurts09:07
mborzeckicame back to playing badminton again after one month pause, wasn't able to walk up and down the stairs yesterday09:08
zyga-ubuntumborzecki: man, did you exert yourself too much?09:09
zyga-ubuntumborzecki: or did you have some accident during the game?09:09
zyga-ubuntu(tests rolling now)09:09
mborzeckiguess it just was a bit too much, rally after rally ;) badminton is really fast, lost of movement back and forth at full speed down to full stop09:11
mupPR snapd#4329 opened:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>09:13
zyga-ubuntuso09:13
zyga-ubuntumvo: what shall we do with indent09:13
zyga-ubuntumvo: the version in artful produces different "canonical" representation than the version of indent in xenial09:13
mvozyga-ubuntu: meh, that is sad09:14
zyga-ubuntumvo: I'm inclined to kill it09:14
zyga-ubuntumvo: and go to clang-format which is a bit better09:14
zyga-ubuntumvo: (flag day to run make fmt)09:14
mvozyga-ubuntu: can we change gradually? what I hate is that we lose the history09:14
zyga-ubuntumvo: not that I see09:14
zyga-ubuntumvo: we can disable the check09:14
mvozyga-ubuntu: well, not loose totally but it makes things harder09:15
mvozyga-ubuntu: lets do that then09:15
zyga-ubuntumvo: kk09:15
mupPR snapd#4330 opened: cmd: disable check-syntax-c <Created by zyga> <https://github.com/snapcore/snapd/pull/4330>09:18
zyga-ubuntumvo: ^^09:18
pedronisthat is :(09:21
zyga-ubuntupedronis: ?09:23
zyga-ubuntupedronis: are you talking about 433009:23
zyga-ubuntumvo: I'm a bit sleepy and tired, I have to stop working till midnight09:31
zyga-ubuntumvo: when stale base v2 patch is green I'll break and get a long walk in the sno09:31
zyga-ubuntumvo: I'll be back to discuss this with jdstrand and jjohansen as actually, the workaround we discussed last night is still showing the kernel bug09:31
zyga-ubuntumvo: so whatever we end up doing, I think we need more jjohansen's eyes on this09:32
mvozyga-ubuntu: ok, thanks for the headsup09:32
* zyga-ubuntu sees green ^_^09:37
zyga-ubuntulet's run 14.0409:38
pedroniszyga-ubuntu: yes, when do we run it? in our unit tests? when we build the deb?09:38
zyga-ubuntupedronis: it's a part of "make check"09:38
zyga-ubuntupedronis: so it affects unit tests, package builds and everything09:39
zyga-ubuntupedronis: I kept the target, just detached it from make check09:39
pedroniseven manually we need to decide where to run it? no?09:39
pedronisotherwise it will be a whack-a-mole09:39
zyga-ubuntupedronis: I think unless we figure out how to make indent behave, it's useless09:39
zyga-ubuntupedronis: we can run "make fmt"09:40
zyga-ubuntupedronis: (as an informal requirement for C code changes)09:40
zyga-ubuntupedronis: the output will look mostly consistent but there will be small changes between xenial and artful09:40
zyga-ubuntuI think we are mostly all on artful (or equivalently recent indent)09:40
pedronisyes, but if one runs make fmt with one versio and the next person with another09:40
zyga-ubuntupedronis: yes, so as long as this is reasonably consistent inside the team (few people touch this code) then I think it's not a problem09:41
pedronisthat sounds optimistic to me09:41
pedronismaybe we should code a version in fmt and just warn, do nothing if it is not that one09:42
zyga-ubuntupedronis: I'll look into this09:44
zyga-ubuntupedronis: maybe there's a new knob in indent09:44
zyga-ubuntupedronis: and we don't control it so it fluctuates09:44
zyga-ubuntubut this assumes that we can still make a profile that won't die on xenial09:44
zyga-ubuntuman, I should have used clang-format years ago09:45
zyga-ubuntu14.04 is good too09:49
zyga-ubuntuthis looks like a winner09:49
zyga-ubuntuhttps://github.com/snapcore/snapd/pull/4329 if someone wants to go down there and examine dragons09:50
mupPR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>09:50
mupPR snapd#4291 closed: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4291>09:52
pedronismvo: can you create the 2_31 tag in the forum09:53
mupPR snapd#4331 opened: systemd: add support for the mask/unmask operations <Created by mvo5> <https://github.com/snapcore/snapd/pull/4331>09:53
mvopedronis: let me try, I think I can09:53
mvopedronis: anything specific I should tag?09:53
pedronisthere are at least things to move09:53
mvopedronis: +109:54
pedronisbecause they didn't make it for 2.3009:54
mvopedronis: updated09:54
pedronisthank you09:55
pedronisnow when 2.30 goes to stable09:56
pedroniswe can cleanup upcoming stuff10:10
mupPR snapd#4332 opened: corecfg: also "mask" services when disabling them  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4332>10:15
mupPR snapd#4328 closed: wrappers: fix unit tests to use dirs.SnapMountDir <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4328>10:17
zyga-ubuntuman10:45
zyga-ubuntuI will never go out10:45
zyga-ubuntuslooow tests10:45
mborzeckigot this: error: cannot list snaps: cannot list local snaps! cannot find publisher details: snap-declaration (99T7MUlRhtI3U0QFgl5mXXESAiSwt776; series:16) not found10:45
mborzeckiany idea where this is coming from?10:45
zyga-ubuntuhmmm, looks like missing assertion10:45
zyga-ubuntuno idea10:45
zyga-ubuntu(why)10:45
mborzeckithat's `snap list`10:46
mborzeckifunny, if I do `snap install core` then it complains that core is installed, but there no core in /var/lib/snapd/snap10:47
zyga-ubuntuwhat did you do to get there?10:47
pedronisthat is a weird state10:49
mupPR snapd#4333 opened: packaging/arch: add bash-completion as optional dependency <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4333>10:49
mborzeckihmm must have borked something when playing locally with the package10:50
Chipacaniemeyer: “2017-11-30 10:45:02 Error debugging qemu:ubuntu-14.04-32:tests/main/snap-confine-privs : EOF” <- probably not the network10:51
Chipacaniemeyer: the thing that stands out is that the first line of output of the failing test output is 'stdin: is not a tty'10:55
zyga-ubuntueh11:08
zyga-ubuntuok11:08
zyga-ubuntuthat's it11:08
* zyga-ubuntu -> walk11:12
* sergiusens waves11:26
mborzeckisergiusens: hey11:29
mvoniemeyer: if 4322 captures your suggestion from some days ago, please merge, I have work on topic of it but I wanted to double check with you first that the name is what you had in mind11:38
mupPR snapcraft#1778 opened: Add sentences to error when registering name <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1778>11:44
zyga-ubunture11:48
sergiusensmpt hey there, it's me again and I have a small request, can you look at https://github.com/snapcore/snapcraft/pull/1778/files ? It is an error message improvement and the author created it from a Google code-in task11:48
mupPR snapcraft#1778: Add sentences to error when registering name <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1778>11:48
zyga-ubuntuman, I need polish-weather-proof shoes11:48
Chipacazyga-ubuntu: https://i.imgur.com/R2Iwz6G.jpg11:50
zyga-ubuntuChipaca: you laugh but I was using that for 80% of the year back in spain11:52
Chipacazyga-ubuntu: oh, i'm laughing alright11:53
zyga-ubuntuChipaca: my "winter shoes" were just that + small outer layer11:53
zyga-ubuntuI want back!11:53
cachioniemeyer, I'll be 5 minutes late today11:53
mptlooking11:54
zyga-ubuntueh12:15
zyga-ubuntuI wish it was xmas12:15
mupPR snapd#4327 closed: release: merge 2.30~rc1 back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4327>12:15
zyga-ubuntutests would be happier12:15
zyga-ubuntueverybody is happier on xmas12:15
zyga-ubuntuand there's more green12:15
niemeyercachio: Ack, and hellos12:16
niemeyerI am late myself today as well12:16
niemeyerzyga-ubuntu: Well, just pretend it is! It's not too different from the 25th.. it's just more people pretending..12:17
niemeyerChipaca: Is it the same test?12:18
niemeyermvo: Will look, thanks12:18
Chipacaniemeyer: http://pastebin.ubuntu.com/26080210/12:19
zyga-ubuntuniemeyer: hey12:19
zyga-ubuntuniemeyer: I was wishing for more green tests :)12:19
zyga-ubuntuat some point we'll talk about eco-tests12:20
mupPR snapd#4322 closed: corecfg: rename package to overlord/configstate/configcore <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4322>12:20
niemeyermvo: It's in.. good branch name too :)12:20
niemeyerzyga-ubuntu: Some good discussions here from last night.. a bit too long to jump in without context, but curious to hear your thoughts on it during or after the standup12:21
Chipacai might be missing the standup today: the cops said they'd come by at 12 but they haven't yet, and if it's any later than it'll overlap12:21
Chipacas/than/then/12:21
niemeyerChipaca: Cops?  Are you okay?12:21
zyga-ubuntuniemeyer: gladly12:22
Chipacaniemeyer: bullying at the boys school escalated12:22
Chipacathere's now apparently a video on youtube12:22
niemeyerChipaca: Oh my.. what are we doing with our society12:22
mborzeckiomg, kids12:23
mborzeckibut then adults are not that much better12:23
niemeyerNo, more like OMG people overvaluing kids actions12:23
niemeyerWell, or maybe not12:24
niemeyerIt really depends on what's going on, and I'm inferring from recent experiences.. so I'll just shut up.12:24
mborzeckiniemeyer: can i ask you for a review of #4313?12:26
mupPR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>12:26
niemeyerChipaca: The stdin is indeed not a tty..12:27
niemeyerChipaca: Nor the stdout12:27
niemeyerChipaca: Unless the shell is used, obviously12:28
Chipacaniemeyer: but wherefore the message?12:29
niemeyer(TIL a new word)12:30
Chipacaniemeyer: it's an old word :-)12:30
niemeyerChipaca: Because it's indeed not.. it's a pipe in this case12:30
niemeyerChipaca: Something was trying to do something and failed12:31
niemeyerChipaca: This wouldn't justify a disconnection, even more considering that the output did continue12:31
niemeyerChipaca: Did you manage to reproduce it predictably?12:32
niemeyerChipaca: If the other end is managing to disconnect reliably, it has to do with either networking or ssh12:32
Chipacaniemeyer: i'll answer that in a few minutes when it runs again12:32
=== chihchun is now known as chihchun_afk
niemeyerChipaca: Note that networking is indeed involved in qemu, despite being local12:32
niemeyer(still ssh)12:32
Chipacaniemeyer: yeah but it's not some network op along the route toggling a box12:33
niemeyerChipaca: Killing sshd would also have a similar effect12:33
Chipacaniemeyer: (i'm only involving you because they're weird enough they might be indicative of something more obscure; i'll continue continuing)12:34
niemeyerChipaca: Yeah, it will be something more interesting, like a bug in Spread's client or something inside the VM poking the system state12:34
niemeyerChipaca: Thanks, glad to continue investigating12:34
niemeyermborzecki: Yeah, let me just finish a review and will pick that one next12:34
zyga-ubuntudran you travis12:35
zyga-ubuntutravis is penalizing us for having many long tests12:35
niemeyerChipaca: Did you update your Spread from the tarball recently?12:36
niemeyerAs in, late last week12:36
Chipacaniemeyer: aug 2412:37
niemeyerzyga-ubuntu: Huh?12:37
niemeyerChipaca: Okay, not a bug in the zlib thing then12:37
zyga-ubuntuniemeyer: I went for a walk after one of my tests timed out12:37
zyga-ubuntuniemeyer: it's still "waiting to start"12:37
zyga-ubuntuniemeyer: that was ~2 hours ago12:37
niemeyerzyga-ubuntu: That's not Travis penalizing us.. that's usually Travis constraining how much they are willing to give us (for free!) at once12:38
zyga-ubuntuyes, that's true12:38
niemeyerzyga-ubuntu: Right *now* we have 8 branches waiting to be tested12:39
niemeyerzyga-ubuntu: If you push something to test *now*, it will take about 8*30min/312:40
jdstrandzyga-ubuntu: hey, it may be because of the unconditional sc_reassociate_with_pid1_mount_ns() in main.c12:40
niemeyerzyga-ubuntu: Which is about 1h30mins12:40
jdstrandzyga-ubuntu: so I think we were doing a triple setns(). -> 1, -> inside to verify -> 1 as needed12:41
jdstrandzyga-ubuntu: curious if you comment that out in your current refactored branch if you see the issue12:42
jdstrand(as a temporary test)12:42
zyga-ubuntujdstrand: but that doesn't do anything12:42
zyga-ubuntujdstrand: that just stats and does nothing more12:42
zyga-ubuntujdstrand: we _dont_ setns there12:42
zyga-ubuntujdstrand: (hey)12:42
jdstrandmaybe I misread something. hold on12:43
zyga-ubuntujdstrand: comment out what exactly?12:43
zyga-ubuntujdstrand: the code in sc_reassociate_with_pid1_mount_ns doesn't ns unless it has to, and in this case it doesn't12:44
zyga-ubuntujdstrand: I can comment that out and see if the confusion goes away12:44
zyga-ubuntujdstrand: note that I also use absolute paths, not fchdir + relative paths12:45
zyga-ubuntujdstrand: IMO apparmor is confused by something we do, but it's not just setns12:45
jdstrandzyga-ubuntu: I'm reading sc_reassociate_with_pid1_mount_ns() in ns-support.c. I see only one return. where is it deciding not to setns to pid 1?12:47
jdstrandzyga-ubuntu: I was suggesting just commenting out the line in main.c: // sc_reassociate_with_pid1_mount_ns();12:48
jdstrandoh the memcmp. let me read more carefully12:49
* jdstrand is not completely awake yet12:49
zyga-ubuntu:)12:50
zyga-ubuntujdstrand: no worries12:50
zyga-ubuntujdstrand: I'm happy to experiemnt to see what is breaking it12:51
zyga-ubuntujdstrand: I also devised a way to not setns and measure12:51
zyga-ubuntujdstrand: it's a bit more contrived but will work12:51
jdstrandzyga-ubuntu: commenting that out is certainly a fast test12:51
zyga-ubuntujdstrand: test in progress12:52
jdstrandzyga-ubuntu: nice. I thought of a rather crude way to not setns from devmode too. fork/exec snap-confine from snap-confine. still want to think through that12:52
zyga-ubuntujdstrand: look at freezer cgroup, look at each pid, look at its mountinfo12:53
zyga-ubuntujdstrand: as long as any process is there, we can see the mountinfo12:53
jdstrandzyga-ubuntu: oh, that's good12:53
zyga-ubuntujdstrand: so this gives us two values: we know if it's empty12:53
jdstrandyep12:53
zyga-ubuntu(but we don't know if it's stale then, that's a downside)12:53
zyga-ubuntujdstrand: and we know if it's active and then which root is used12:53
pstolowskihey guys, i'm gonna be 5 minutes late to standup12:53
zyga-ubuntujdstrand: I haven't founda way not to setns to measure if it is really empty12:54
zyga-ubuntujdstrand: so I didn't implement that as it reduces to current problem in worst-case12:54
m4sk1ncreated bug #1735410 for l10n support, should I start doing it?12:55
mupBug #1735410: Localization support <l10n> <Snapcraft:New for m4sk1n> <https://launchpad.net/bugs/1735410>12:55
zyga-ubuntuwoot, thank you m4sk1n12:55
m4sk1n(for snapcraft)12:55
jdstrandzyga-ubuntu: well, the fork/exec into the freezer/setns into the mount namespace would do it12:55
zyga-ubuntujdstrand: fork + exec as opposed to just fork?12:56
zyga-ubuntujdstrand: I really want to get to the bottom of this bug in the kernel12:56
jdstrandit doesn't have to be a full on helper though.12:56
zyga-ubuntujdstrand: as I feel like we're walking on a minefield with our eyes closed12:56
zyga-ubuntujdstrand: we could fexec /bin/cat12:56
zyga-ubuntujdstrand: to cat mountinfo12:56
jdstrandzyga-ubuntu: the fork may be enough, but would need jjohansen to confirm12:58
zyga-ubuntujdstrand: hold on, we fork now12:58
zyga-ubuntujdstrand: it's not enough12:58
m4sk1nok, so I'll start today12:59
zyga-ubuntum4sk1n: yes, I think so12:59
zyga-ubuntum4sk1n: kalikiana is a snapcrafter so he can help you out12:59
zyga-ubuntum4sk1n: I will gladly review the translation as I'm familiar with the language and the topic12:59
zyga-ubuntujdstrand: confirmed, that has no impact13:04
mupPR snapd#4333 closed: packaging/arch: add bash-completion as optional dependency <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4333>13:04
zyga-ubuntujdstrand: I commented out both the extra apparmor rule and the optional reassociation13:04
* jdstrand nods13:05
jdstrandzyga-ubuntu: well, this is good info for jjohansen13:05
* mvo hugs Son_Goku 13:12
Son_Gokuwhat brought this on?13:12
sergiusenszyga-ubuntu niemeyer we moved over to using travis stages, overall the whole suite can take longer, but it is mitigated as the fast tests are what usually fail not needing to wait for all the jobs to end (jobs from the next stage won't pass if the previous one isn't completely green)13:20
sergiusensthis has saved us plenty of wait13:20
niemeyersergiusens: We need to wait for tests to end either way, because we're limited on the number of worker machines too13:21
zyga-ubuntujdstrand: I have a suspicion about what _may_ be going on, I'll write a small C program and apparmor profile to help jjohansen13:25
zyga-ubuntujdstrand: I'll keep you posted13:25
zyga-ubuntujdstrand: in the end we need some idea if the workaround I implemented in both PRs is acceptable13:26
zyga-ubuntujdstrand: and if we can roll with it13:26
jdstrandzyga-ubuntu: note that the double setns is not desirable regardless13:27
jdstrandzyga-ubuntu: but maybe there is something else that can be done to your current attempt after jjohansen looks at it13:28
zyga-ubuntujdstrand: we don't do double setns now13:33
jdstrandzyga-ubuntu: I know13:33
zyga-ubuntuah,o k13:34
jdstrandzyga-ubuntu: I wasn't sure if you were saying that you wanted to go back to what you had yesterday13:34
jdstrandzyga-ubuntu: and I was simply saying what you did today was good on its own, even if there is still something else going on13:35
sergiusenszyga-ubuntu did you make any progress on that non ubuntu kernel snap-confine die issue which makes me disable apparmor completely?13:36
mptsergiusens, done13:38
zyga-ubuntujdstrand: no, no I mean I just need some advice on what to do next13:45
zyga-ubuntujdstrand: I see, thank you for clarifying that13:45
zyga-ubuntusergiusens: no, sorry, still entangled in bugs13:46
jdstrandzyga-ubuntu: jjohansen would be able to provide that, there is just a question of timing. I'll let him comment-- he may need to talk to tyhicks/ratliff if it requires deep investigation13:53
zyga-ubuntujdstrand: I reproduced this13:54
zyga-ubuntujdstrand: reducing it to a small C program13:54
zyga-ubuntujdstrand: woot :)13:54
zyga-ubuntuniemeyer: ^ I was right abount my hunch I said during the call :)13:55
jdstrandzyga-ubuntu: a small reproducer will be super helpful13:55
zyga-ubuntujdstrand: yep, just writing a README file now13:56
jdstrandmvo: hey, curious if the 'include -> #include' fix will be in 2.29.4?13:56
cachiojdstrand, hey14:02
cachiojdstrand,  I am working in a PR to test the netlink connector interface14:02
cachiojdstrand, #432514:02
mupPR #4325: Adding test for netlink-connector interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4325>14:02
cachioI am getting an error "Bad system call" when I try to use the interface and the plug is disconnected14:03
cachiojdstrand, not sure if it is expected or not?14:03
matiasbkyrofa, o/ hey, thanks for the comments in the PR (https://github.com/snapcore/snapcraft/pull/1774), pushed some updates for when you get some minutes; let me know if you have any other comments14:05
mupPR snapcraft#1774: Push binary metadata to the Store <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/1774>14:05
zyga-ubuntujdstrand: I think it will be in 2.3014:17
zyga-ubuntujdstrand: I don't recall any backports done to that PR14:17
ikeywhen is 2.30ish?14:28
zyga-ubuntuikey: next week14:33
ikeyoo nice14:33
ikeythats when ill do my call for testing then14:33
=== pbek_ is now known as pbek
mvojdstrand: the include fix is not in 2.29.4, do you need it? it is in 2.30 and we could pull it in to the 2.29 branch *if* we need to do another 2.29 (which I hope we don't need to :)14:54
jdstrandmvo: I thought someone mentioned it as a regression in bionic, which means the sru would be halted, no?14:55
jdstrandmaybe it wasn't bionic specific. let me reread the bug14:56
jdstrandmvo: actually, it affects 17.10: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/173370014:57
mupBug #1733700: aa-enforce fails due to syntax error in snapd.snap-confine profile <snapd (Ubuntu):Triaged by zyga> <https://launchpad.net/bugs/1733700>14:57
jdstrandI thought there was another bug...14:57
mvojdstrand: uhh, ok15:00
jdstrandok, yes 173403815:01
* jdstrand reads15:01
mvojdstrand: this is very annoying, I will pull it into branches/2.29 and we need to discuss what to do15:01
jdstrandyes, 1734038 mentions artful as well15:02
mvozyga-ubuntu: silly question but why is it     #include "/var/lib/snapd/apparmor/snap-confine" in master vs ".../snap-confin.d" in 2.29?15:05
mvojdstrand: or maybe you know the answer -^15:05
jdstrandmvo: I think we need a spread test to do 'apparmor_parser -QTK /path/to/snap-confine/profile'15:05
jdstrandmvo: that will make sure that the policy is good everywhere15:06
jdstrandmvo: the fact that cache files masked the issue is unfortunate15:06
jdstrandmvo: let me look15:07
mvojdstrand: ok, let me write a test for this15:07
jdstrandmvo: note that as of recent PRs, the interfaces-many spread test I added achieves the same result for snaps15:08
jdstrandso it will be nice to ohave that for snap-confine itself15:08
om26ersergiusens: Hi! re: snapcraft 2.35 on xenial, its been 7 days today, so I guess we can move that from xenial-proposed to -updates ?15:10
zyga-ubuntumvo: niemeyer asked us to drop the .d15:10
mvozyga-ubuntu: aha, ok. can/should this happen in 2.29 as well? we are a bit inconsistent right now between 2.29 and 2.30+15:11
jdstrandzyga-ubuntu: does the move away from .d cleanup the .d directory? if so, are reverts handled ok?15:12
sergiusensom26er you can help with the SRU process by adding a comment on the SRU bug, elopio did a call for testing a while back15:12
sergiusenshe's on holidays so it is taking longer than usual15:13
zyga-ubuntumvo: not sure15:13
zyga-ubuntujdstrand: not sure either15:13
zyga-ubuntuman15:14
zyga-ubuntujdstrand: I can trigger the bug with a small C program15:14
zyga-ubuntujdstrand: but only if snap-confine first produces a namespace15:14
zyga-ubuntujdstrand: if I use a simple tool that produces a namespace I don't get that bug15:14
zyga-ubuntujdstrand: I wonder which of the things we are doing is causing it15:15
mupPR snapd#4334 opened: tests: ensure snap-confine apparmor profile is parsable <Created by mvo5> <https://github.com/snapcore/snapd/pull/4334>15:15
zyga-ubuntujdstrand: my mini-tool now does unshare + pivot_root15:15
om26ersergiusens: ok, I added my comments there as well. I hope that gets promoted to -updates soon.15:17
jdstrandmvo: oh right, so the apparmor -QTK test is absolutely valid, but wouldn't have caught this (I forgot, the parser is fine, it is the apparmor python tools that are not, which is why users see this and qrt kernel failures). let me give you an additional test for -QTK15:17
jdstrandto -QTK15:18
jdstrandmeh, let me give you the userspacec tools test too15:18
jdstrandmvo: before I right that, this is tricky15:19
jdstrandmvo: cause say you fix this. the previously broken revision is still on the system15:19
jdstrandmvo: and the userspace tools will still fail15:20
zyga-ubuntujdstrand: what's the problem?15:20
zyga-ubuntujdstrand: is it the #include vs include?15:21
jdstrandzyga-ubuntu: yes15:21
jdstrandso, apparmor_parser is fine15:21
zyga-ubuntujdstrand: can we fix the userspace tools15:21
jdstrandso snaps work15:21
zyga-ubuntujdstrand: this is IMO a bug in the tools15:21
jdstrandbut apparmor python tools don't understand 'include' and the tools read all profiles that are in /etc/apparmor.d15:22
zyga-ubuntujdstrand: sure, can we fix those tools to understand the same language that the other tools do?15:22
jdstrandso if someone has a broken revision and gets the new unbroken revision, then the userspace tools will still be broken until the broken revision rotates out15:23
jdstrandI think we have to15:23
zyga-ubuntujdstrand: yes, I think this is the correct way to deal with this15:23
jdstrandmvo: I think the spread test is valuable. I don't think the 2.29 respin is required15:24
jdstrandtyhicks: we need to update the userspace tools everywhere for 1734038 and 173370015:24
jdstrandman, that sucks15:24
jdstrandmvo: in addition to 'apparmor_parser -QTK /path/to/profile', please also do 'apt-get install apparmor-utils && aa-enforce $ sudo aa-enforce /path/to/profile'15:26
* zyga-ubuntu hugs jdstrand 15:29
zyga-ubuntuit's not too bad, just one gazillion packages15:29
oSoMoNwould it be valid to refer to/copy files from partA in partB's install scriptlet using a relative path (e.g. ../../partA/install/some/file.ext), provided I declare that partB is built after partA, or is that discouraged?15:30
jdstrandmvo: when it doesn't fail, it simply will compile the profile and load it into the kernel15:30
jdstrandmvo: but aa-enforce will (weirdly) pull in all the profiles, just like logprof and genprof15:30
oSoMoNsergiusens, you probably know? ^15:31
sergiusensoSoMoN not until I read what this is all about :-)15:32
oSoMoNsergiusens, just that one question 3 lines above15:32
sergiusensoSoMoN discouraged, parts are private, think of it like using private headers, you can, but if it breaks you get to keep the pieces15:33
zyga-ubuntujdstrand: ok, I have a reproducer in C, separate form snapd15:33
zyga-ubuntu*from15:33
oSoMoNsergiusens, right, that's what I feared15:33
sergiusensoSoMoN it would be more convenient to stage the files from partA and consume them in partB from $SNAPCRAFT_STAGE15:33
oSoMoNsergiusens, ah, I didn't know of $SNAPCRAFT_STAGE, that sounds like what I need15:34
sergiusensoSoMoN or if you have a plugin `self.project.stagedir` iirc15:34
sergiusensone sec, an example to arrive15:34
oSoMoNgreat15:34
oSoMoNbut I need to run a scriptlet on those files, isn't it too late for that at the stage phase?15:34
sergiusensoSoMoN https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/integration/snaps/stage_env/snapcraft.yaml15:36
mvojdstrand: ok, will do.15:36
sergiusensoSoMoN if a part depends on another, the dependant part goes all the way to staging as that is the only place a dependency can be consumed (in the for of a library, runnable or whatever other artifact)15:37
mvojdstrand: silly question, could you do something like s/include/#include/ in your python tools as a quick fix?15:37
oSoMoNsergiusens, great, so that should do the trick15:37
oSoMoNthanks!15:37
jdstrandmvo: that is what I was saying-- we have to sru apparmor everywhere to do that (or backport the actual patch)15:39
mvojdstrand: ok, thank you15:40
mvojdstrand: PR updated to include aa-enforce15:43
zyga-ubuntujdstrand: where can I share the program?15:43
zyga-ubuntujdstrand: actually, I'll just add that to the bug report15:43
niemeyermvo: The point about .d was that all of these are .d-irectories.. :)15:46
niemeyermvo: There's nothing special about that one15:46
niemeyermvo: I did originally ask back then, quite a while ago actually, whether this was already released.. the answer was no15:46
zyga-ubuntujjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/173545915:48
mupBug #1735459: Incorrect denial on umount with bind-mounted mount namespace <AppArmor:New> <https://launchpad.net/bugs/1735459>15:48
zyga-ubuntuniemeyer: ^ that bug with small C reproducer15:49
zyga-ubuntuniemeyer: I said it wasn't AFAIK, I must have made a mistake there15:49
pedronismvo: btw I checked, snap install lxd  lxd   really creates twice the tasks, and then they confuse each other15:50
pedronisrunning at the same time15:50
niemeyerzyga-ubuntu: I do remember grepping the code and finding no uses either, so at the very least I made the same mistake15:52
jdstrandzyga-ubuntu: we could work around that denial if needed, but I defer to jjohansen15:53
zyga-ubuntuniemeyer: I looked at git tags15:53
niemeyerpedronis: This demonstrates the issue, but it's an obvious case that we don't in fact want to reach that code.. this should drop duplicates very early on.. in the API itself15:53
zyga-ubuntujdstrand: the example contains a workaround as well15:53
zyga-ubuntujdstrand: but I'd like jjohansen to analyze and figure it out15:53
zyga-ubuntujjohansen: I'm happy to help15:54
zyga-ubuntujjohansen: (with the kernel side)15:54
popeyAnyone tried snapd on fedora 27 recently? It just hangs, and I get messages in the journal about selinux blocking access to /proc/<pid>/stat15:54
zyga-ubuntupopey: no :/15:54
popeyI have never knowingly disabled selinux on fedora before.15:54
niemeyerjdstrand, jjohansen: We just need something that works soon, and we need an ack that we can trust it not to break in the foreseeable future.. if you guys have a different suggestion, we can go with anything else too.. we just need to get this working and out of the way.15:54
popeyI just booted it and updated the machine and now snaps don't work15:54
zyga-ubuntuSon_Goku: ^ is that something we can fix for 2.30?15:54
niemeyerpopey, zyga-ubuntu: Yes, we did try recently, as in last week.. we've just built images for it15:55
niemeyercachio will have more details15:55
zyga-ubuntuniemeyer: ah, indeed!15:55
popeyI don't understand. I had snaps working here previously15:56
popeysuddenly since an update, i cant install snaps15:56
pedronisniemeyer: yes, it's really a different kind of issue/bug, anyway it's there atm15:56
cachiopopey, last week I executed the snapd test suite on fedora 27 and just 1 test failed15:57
cachiopopey, we are using the image fedora-27-64 on linode, that will be ready next week15:58
zyga-ubuntucachio: is selinux enabled on our image?15:58
zyga-ubuntu(worth having a spread test for it)15:58
cachiozyga-ubuntu, I need to check that15:59
popeyDo I need to file a bug somewhere? Because right now Fedora 27 users can't install snaps (AFAICT)16:00
jdstrandniemeyer (cc jjohansen and zyga): that is what we all want and are working towards16:03
niemeyerjdstrand: I'm talking pragmatically about the specific code that zyga-ubuntu posted today16:03
niemeyerjdstrand: One of them works, the suggested approach doesn't16:04
cachiopopey, yes please16:04
niemeyerjdstrand: We cannot use a suggested approach that doesn't work, of course.. so either we need a +1 on the approach that does work, or we need a third approach that you and jj can vouch for and does work too16:04
cachiopopey, I'll be researching that16:04
jdstrandmvo: is bug #1734038 marked as a blocker for sru? in thinking about it, it probably should be because if 2.29 goes to stable releases, the offending rule will be on disk for everyone, regardless of if they use snap install and get a new core, meaning all stable release users who use apparmor-utils will break whether they use snaps or not16:04
mupBug #1734038: utils don't understand «include "/where/ever"» (was: Potential regression found with apparmor test on Xenial/Zesty) <apport-bug> <package-from-proposed> <regression-proposed> <s390x> <xenial> <zesty> <AppArmor:New> <apparmor (Ubuntu):New> <linux (Ubuntu):Confirmed> <snapd16:05
mup(Ubuntu):Invalid> <https://launchpad.net/bugs/1734038>16:05
popeycachio: where should I file it? forum / launchpad / github?16:05
cachiopopey, in the forum please16:05
niemeyerjdstrand: This has been coming for some time and I understand we all want to reach the same goal.. but we need to get it through and move on16:06
jdstrandniemeyer: I understand. what zyga posted today may be fine and just a bug that can be worked around in policy as opposed to what was there yesterday that went against the grain of how namespaces are intended to function16:06
jdstrandniemeyer: we need jjohansen to comment. I just wanted you to know that it is understood that this is a priority and no one wants to block16:07
mvojdstrand: 1734038 is not a blocker yet, I can update 2.29 and do a new SRU if needed, we probably also need to update the core snap though as this will also write include (and not #include)16:07
niemeyerjdstrand: Thanks a lot, and please don't take my words as "we need to move on anyway".. the point is just that we do need to move on, so we need to investigate and get to an understanding and agreement that a given approach solves the problem and is reliable in terms of the implementation not changing behind us tomorrow16:08
jdstrandniemeyer: understood (cc jjohansen ^)16:08
niemeyerjdstrand: zyga-ubuntu produced a smaller test case which hopefully will make things easier for you and jj to discuss and find a workable agreement in those terms16:08
jdstrandtyhicks, ratliff: do note the above ^ (since I can't just assign jjohansen to something :)16:09
jdstrandniemeyer: yes16:09
ratliffzyga-ubuntu: did you send your test case to jjohansen with a brief description? I don't think that it is optimal for him to try to read through this backscroll16:15
zyga-ubunturatliff: better: https://bugs.launchpad.net/apparmor/+bug/173545916:18
mupBug #1735459: Incorrect denial on umount with bind-mounted mount namespace <AppArmor:New> <https://launchpad.net/bugs/1735459>16:18
ratliffzyga-ubuntu: excellent, thanks!16:18
jdstrandjjohansen (cc niemeyer, ratliff, tyhicks): re bug #1735459, the question is whether that approach is sane or not. if so, we can add a workaround rule and treat it like a regular bug. if not, we should recommend an approach to zyga16:23
mupBug #1735459: Incorrect denial on umount with bind-mounted mount namespace <AppArmor:New> <https://launchpad.net/bugs/1735459>16:23
mupPR snapd#4335 opened: snap-confine: use #include in snap-confine.apparmor.in <Created by mvo5> <https://github.com/snapcore/snapd/pull/4335>16:26
mvojdstrand: -^16:27
jdstrandmvo: approved. where is the pr for the -QTK/aa-enforce spread test?16:30
zyga-ubuntumvo: hmm16:30
zyga-ubuntumvo: we merged https://github.com/snapcore/snapd/pull/4335/files before!?!16:30
mupPR #4335: snap-confine: use #include in snap-confine.apparmor.in <Created by mvo5> <https://github.com/snapcore/snapd/pull/4335>16:30
zyga-ubuntumvo: what am I missing?16:30
zyga-ubuntumvo: I pushed this yesterday or two days ago16:30
jdstrandzyga-ubuntu: release/2.2916:30
zyga-ubuntuahh16:31
zyga-ubuntusorry16:31
zyga-ubuntuall good16:31
* zyga-ubuntu had panic moment16:31
mupPR snapd#4335 closed: snap-confine: use #include in snap-confine.apparmor.in <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4335>16:41
mupPR snapd#4330 closed: cmd: disable check-syntax-c <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4330>16:45
cachiozyga-ubuntu, after double check status on fedora 2716:46
cachiozyga-ubuntu, selinux is enabled16:47
cachioand we are using kernel 4.13.15-300.fc27.x86_6416:47
cachiopopey, please read this16:47
popeyok16:48
zyga-ubuntucachio: perhaps popey's machine uses different kernel16:48
zyga-ubuntucachio: or perhaps the workstation image contains some different defaults16:48
popeyits a vm16:48
zyga-ubuntucachio: would be good to check a full workstation VM16:48
popeyjust a plain vanilla fedora 27 vm16:48
cachiozyga-ubuntu, I think this is the real diff16:48
popeynothing special.16:48
zyga-ubuntupopey: correction *workstation* vm16:48
zyga-ubuntupopey: fedora has workstation, server and atomic editions AFAIK16:48
popeyyeah, it's workstation16:48
zyga-ubuntupopey: our CI is done on cloud images16:49
zyga-ubuntupopey: I don't fully understand how they differ16:49
popeyOne of them doesn't work, that's a key difference ;)16:50
mupPR snapd#4336 opened: Adding fedora 27 and rawhide to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>16:53
* zyga-ubuntu goes to test vlc and that amd gpu for popey 16:59
zygapopey: oy, doing that test now, man, I haven't booted this in a while17:08
zygaI' got a gazillion updates17:08
zygapopey: that bunny movie is hard to download, from the blender website at least17:11
popeyI hear there are free movies on the internet17:12
zygayes, but all over 1817:13
zygaI'm trying blender mirrors17:13
zygapopey: well17:18
zygapopey: it works17:19
zygapopey: not sure if this is hw accelerated17:19
zygapopey: any hints on how to check17:19
popeyit should tell you on the console17:19
popeyprobably mentioning VDPAU or VAAPI17:19
zyga[00007f782801a800] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding17:19
zygaso yep17:19
popeyand that it's trying to load a vdpau or va-api module17:19
popeyoooooh17:19
zygabutter smooth17:19
zyga:-)17:19
popeythat's freaking awesome17:19
zygayep17:19
zygaI'll comment on the forum17:19
zygathank you!17:19
zygaand VLC looks great17:19
popeyawesome17:19
zygapopey: done17:24
popeythanks.17:24
zygamy pleasure17:25
zygait was surprisingly flawless :)17:25
popeyi should hope so after the effort that went into making that snap! :D17:26
zygapopey: do you need a Nvidia test?17:26
Chipacazyga: so... i'm getting very weird errors from the spread suite, and i thought maybe you knew something (seeing as you'd spent some time hating it this week)17:26
popeyno, got that covered thanks17:26
zygapopey: I don't have anything recent, I have one old laptop with nvidia gpu17:26
zygaChipaca: yes?17:27
popeyme and wimpy both have nvidia by default, so easy to cover that17:27
zygapopey: great, thank you for doing this17:27
Chipacazyga: there's a test that fails every time, but never if i run it on its own17:27
zygaChipaca: want to help me figure it out?17:27
Chipacazyga: and when it fails i get no debug info, and i can't -debug it by hand, because it's just EOF17:27
zygaoh17:27
zygahmm17:27
zygawell17:27
zygaI'd start with this:17:27
zygaChipaca: install this copy of spread https://github.com/snapcore/spread/pull/4717:28
mupPR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47>17:28
zygaChipaca: add measure-each: to spread.yaml, I do something like this:17:28
zygaChipaca: something-to-measure > /tmp/now.log17:28
zygaChipaca: if [ ! -e /tmp/vanilla.log ]; cp /tmp/now.log /tmp/vanilla.log; fi17:29
zygaChipaca: diff -u /tmp/vanilla.log /tmp/now.log17:29
zygaChipaca: start small, something that few tests break17:29
zygaChipaca: and iterate with -seed set17:29
zygaChipaca: I made some things that help:17:29
Chipacazyga: uh... but17:29
Chipacazyga: i don't see anything broken :-/17:29
zygaChipaca: run this on linode to save network if you want to avoid that17:30
zygaChipaca: sure17:30
Chipacait just dies17:30
zygaChipaca: my point is that _something_ messes up17:30
zygaChipaca: and over time, as we measure more things17:30
zygaChipaca: one more idea17:30
zygaChipaca: patch spread to don't do headless qemu17:30
zygaChipaca: when it breaks, log in from the window and see what you get17:30
zygaChipaca: I didn't do this but it's useful17:30
zygaChipaca: maybe something rm -rf's /17:30
zygaChipaca: another idea, run each possible combination of (n, test_that_eofs) where n is each test in the suite17:33
zygaChipaca: unless the bug is a combination of more than one cleanup going wrong17:34
* zyga reboots to get new kernel17:38
niemeyerpedronis: Hey, which specific test case where you referring to the whole time in our call?17:40
niemeyerSorry, not the case, condition17:40
niemeyerSorry, not test case, condition17:40
niemeyerpedronis: I'm now wondering whether we were talking across each other the whole time.. that would explain why it took us a while17:40
=== anta_ is now known as kw
zygaChipaca: I hope my messages were not grim17:47
zygapopey: I got one denial17:49
zyga[  262.410700] audit: type=1400 audit(1512064138.223:71): apparmor="DENIED" operation="open" profile="snap.vlc.vlc" name="/etc/xdg/QtProject/qtlogging.ini" pid=3902 comm="vlc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=017:49
zygalooks harmless17:49
popeynot seen that before, thanks17:49
zygaI wish we had a way to deny things per-snap17:49
zyga"silence those denials"17:49
niemeyermvo: I'm pretty sure this was the case..17:49
zygapopey: another one [  328.556164] audit: type=1400 audit(1512064204.370:72): apparmor="DENIED" operation="open" profile="snap.vlc.vlc" name="/etc/vdpau_wrapper.cfg" pid=3902 comm="vlc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=017:50
zygapopey: ohh, subtitles are broken17:50
popeyyeah, i get that one, it's fine17:50
popeyooh17:50
zygapopey: I ran a anime movie and it shows garbage17:50
popeybroken how?17:50
popeyfonts probably?17:50
zyga"the wind raises"17:50
zygaprobably17:51
zygaor17:51
zygaencoding/locale17:51
zygamore likely17:51
zygathe movie is in japanese with english subs17:51
zygaand I'm not sure if we ship an UTF-8 capable locale by default17:51
niemeyermvo: Which would be super ironic, and somewhat telling about how easy it is to discuss the wrong thing :)17:51
popeyugh17:51
zygaI can attach a photo17:52
popeyk17:52
popeyis it an mkv?17:53
popeyi have some which have subtitles so can probably test here17:53
zygayes17:53
zygahey, even the appindicator works :D17:54
Chipacahuh, that's interesting17:58
ChipacaNov 30 17:57:11 autopkgtest rngd[3413]: read error17:58
zygaout of randomness?17:58
Chipacasomehow17:58
Chipacaprobably qemu doesn't have /dev/hwrng17:59
zygaChipaca: hmm18:02
zyga           -object rng-random,id=id,filename=/dev/random18:02
zyga               Creates a random number generator backend which obtains entropy from a device on the host. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. The18:02
zyga               filename parameter specifies which file to obtain entropy from and if omitted defaults to /dev/random.18:02
zygaChipaca: I can search for random strings in qemu man page18:02
zyga(pun intended :)18:02
zygaoh, I didn't mention: I'm off tomorrow, burning holidays18:03
zygajjohansen: do you need anything from me, I'll be back for part of next week18:03
Chipacarunning htop inside the qemu doing the spread tests is interesting18:03
Chipacaalso: boring18:03
Chipacaalso: EOD time here, but i'll be around async18:03
jdstrandzyga, popey: we should allow /etc/vdpau_wrapper.cfg I think. what happens if you add it?18:04
zygajdstrand: checking18:05
* jdstrand adds it to todo for the next policy updates for 2.3018:05
zygajdstrand: it still works18:06
jdstrandzyga: cool. I'll get that into 2.3018:06
zygajdstrand: thank you :)18:06
zygajdstrand: in case this is interesting:18:07
zyga$ cat /etc/vdpau_wrapper.cfg18:07
zygaenable_flash_uv_swap=118:07
zygadisable_flash_pq_bg_color=118:07
jdstrandthanks18:08
zygapopey: where is the sublime text snap?18:09
zygapopey: AFAIK we had some18:09
popeynews to me18:09
zygaaha18:09
zygaI saw some chatter on the forum18:09
popeyit was desired18:09
cachiomvo, starting sru, do you have the lp link?18:13
mvocachio: bad news, we need a respin18:13
mvocachio: I just uploaded 2.29.4.2 to beta18:14
zygamvo: uh18:14
mvocachio: if you could validate so that we can push to candidate tomorrow(ish) that would be great18:14
mvocachio: and then I push new SRUs18:14
mvozyga: yeah, include ftw :(18:14
mvozyga: but it breaks people so we need to fix it18:14
zygamvo: but didnt jdstrand say this is a bug that needs to be fixed in apparmor18:15
cachiomvo, sure18:17
cachiomvo, which is the issue fixed?18:17
jdstrandzyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1734038/comments/1518:21
mupBug #1734038: snap-confine profile uses 'include' instead of '#include' which breaks apparmor-utils python tools <apport-bug> <package-from-proposed> <regression-proposed> <s390x> <xenial> <zesty> <snapd (Ubuntu):In Progress by mvo> <snapd (Ubuntu Trusty):New> <snapd (Ubuntu Xenial):New> <snapd18:21
mup(Ubuntu Zesty):New> <snapd (Ubuntu Artful):New> <snapd (Ubuntu Bionic):In Progress by mvo> <https://launchpad.net/bugs/1734038>18:21
jdstrandzyga: the problem is that if the sru goes through without the updated rule, all non-snap users that use apparmor-utils will regress (ie, server/cloud users)18:22
jdstrandso we either need to delay the snapd sru to depend on the apparmor sru, or fix the snapd sru and do apparmor sru separately18:22
jjohansenzyga: so you can't currently do that, see bug18:24
zygajjohansen: looking18:24
zygajjohansen: that's okay then18:25
zygajjohansen: I think we can land https://github.com/snapcore/snapd/pull/432918:25
mupPR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>18:25
mvocachio: sorry for the slow answer, I just pushed the new packages into -propsed but they need SRU approval first, the only change is to change "include" to "#include" in our snap-confine apparmor file18:40
cachiomvo, great, thanks18:41
cachiomvo, ok, I am creating beta images to run beta validation18:41
cachiobut my internet connection is slow today18:42
mvocachio: thank you, much appreciated18:42
mvocachio: sorry for this last minute change :/18:42
cachiomvo, np18:42
mupPR snapcraft#1779 opened: catkin-tools plugin: use stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1779>18:55
kyrofacratliff, if you could give that ^ a test when you're able I'd very much appreciate it!18:59
kyrofaIt looks big, but that's only because I added that integration test19:03
cratliffkyrofa, Yeah, I'll give it a look.19:17
lundmarit would be nice if anyone whould like to review and +1 this request: https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 . Thanks.20:23
jdstrandzyga: hey, I just noticed that we are calling a nmber of things after sc_create_or_join_ns_group() (the setns() to the snap's mount namespace). this isn't wrong per se since we are mounting things like /sys into the namespace, but feels a bit weird. eg, shouldn't we be setting up the snap's freezer cgroup before we setns?20:50
zygajdstrand: hmm20:56
zygajdstrand: I think the freezer needs to be set just before we exec, at any time20:57
zygajdstrand: I wanted to avoid snap-confine getting frozen by accident in the more critical aprts20:57
zyga*parts20:57
zygajdstrand: not sure if that answers your question, please ask again if needed20:57
jdstrandzyga: really I'm not asking for you to do anything right this second but maybe add to your todo to consider that we should probably setns() as late as possible20:58
jdstrandzyga: and do as much management of the snap in the default mount namespace as possible, to avoid subtle bugs down the line20:59
zygajdstrand: noted21:00
zygajdstrand: I added two points to your description on the v2 patch21:00
zygajdstrand: (fantastic description btw, worth saving in a README)21:01
kyrofasnappy-m-o, autopkgtest 1779 xenial:amd6421:02
snappy-m-okyrofa: I've just triggered your test.21:02
jdstrandzyga: thanks21:02
kyrofaHey niemeyer, are you around? Would you mind taking a quick look through #4323?21:04
mupPR #4323: interfaces: add gpio-memory-control interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/4323>21:04
niemeyerkyrofa: Hey21:08
niemeyerkyrofa: Not entirely, but I have a quick window now.. let me look21:08
kyrofaniemeyer, really just need your input on the name21:09
niemeyerkyrofa: Do you have docs for the kernel?21:12
niemeyerkyrofa: On that device21:13
kyrofaniemeyer, the link there is all I have: https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/char/broadcom/bcm2835-gpiomem.c21:13
niemeyerkyrofa: LGTM21:20
kyrofaThanks niemeyer, I appreciate your time :)21:20
zygaok, time to sleep!21:53
zyganight night everone21:53
zygaeveryone21:53
mupPR snapd#4323 closed: interfaces: add gpio-memory-control interface <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/4323>22:46
lundmaris the build.snapcraft.io not triggering amd64/i386 builds anymore? I just triggered a build but only arm gets built.23:23
lundmarsomething is wrong with build.snapcraft.io23:25
mupPR snapcraft#1780 opened: cli: add export-login command <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1780>23:59

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