/srv/irclogs.ubuntu.com/2017/08/23/#snappy.txt

=== JoshStrobl is now known as JoshStrobl|zzz
mupPR snapd#3782 closed: client: fix go vet 1.7 errors <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3782>05:35
mvojamesh: hey, I added some small comments for 3581, very excited that this can land07:33
jameshmvo: okay.  I was just writing a reply to niemeyer's last comment.07:33
mvojamesh: great!07:34
mvopedronis: how are things looking from your side for 2.28 - did we need to make the tweaks you mentioned yesterday?07:36
ChipacaBuon giorno, principesse e principi!08:02
zyga-susegood morning08:04
zyga-susehey Chipaca, good to see you08:04
zyga-susehow were your holidays?08:04
Chipacatiring :-)08:04
Chipacahow were things?08:04
zyga-suseI think mostly okay08:04
pedronismvo: hi, not we didn't  yet08:05
zyga-susetests are greener than earlier08:05
Chipacaanything igneous that shouldn't be?08:05
zyga-suseChipaca: haha, yes, mystery of my VM with high error rate08:05
zyga-suseChipaca: I have a VM that when I run tests on, things massively fail, randomly08:05
zyga-suseChipaca: (in unit tests)08:05
pedronismvo: I need to prepare a PR with a change this morning08:05
mvopedronis: ok, please tag with 2.28 then08:06
Chipacazyga-suse: is it accidentally a Win10 vm?08:06
zyga-suseChipaca: haha, no, it's my Arch VM08:06
mvopedronis: I went over the open ones to see what we want for 2.28 and milestoned a bunch08:06
zyga-suseChipaca: tests failures are pretty odd, like "cannot parse this constant yaml string"08:06
zyga-suseChipaca: the host has good memory (tested)08:07
Chipacazyga-suse: how big is the vm image?08:07
zyga-suseChipaca: let me look08:07
zyga-suse14GB08:07
zyga-suseChipaca: note that it fails randomly but mostly so when I unpack the release tarball again08:07
zyga-suseso feels like something gets corrupted randomly08:07
zyga-suseChipaca: the releast tarball md5sum checks out (weak but useful)08:08
pedronisChipaca: buon giorno08:08
Chipacazyga-suse: and it's a regular VM thing like kvm?08:09
zyga-suseyes08:09
Chipacazyga-suse: you're not emulating ryzen or something08:09
zyga-suseChipaca: no, on a 3rd gen core i508:10
zyga-suseand this machine has loads of other VMs with nothing failing anywhere08:10
zyga-suseChipaca: the kernel there is fresh, I forgot how fresh08:10
zyga-suseChipaca: the golang bits are 1.8.308:10
zyga-suseChipaca: if you want I can show you08:11
Chipacazyga-suse: can you build a fresh arch vm of the same version and compare checksums?08:11
zyga-suseChipaca: checksums of all the files on disk?08:11
Chipacayes08:11
zyga-suseChipaca: arch is hand made (early parts) so I bet things will turn out different08:11
Chipacawell, not _all_, but say /lib08:11
zyga-suseChipaca: I could reinstall all packages08:11
zyga-suseChipaca: one thing I did08:11
zyga-suseChipaca: that is interesting08:11
mvopstolowski: 3569 is ready, right? test look a bit unhappy right now, but I can baby sit, I think we wan tthis for 2.28 :)08:11
zyga-suseChipaca: is to save yaml to /tmp/FAILING.yaml whenever I cannot parse it08:11
zyga-suseChipaca: and I got the string ` - : `or something like that08:12
zyga-suseo_O08:12
zyga-suseI should do incremental files to see what other strings may fail08:12
zyga-suseand note that it is not random at all08:12
zyga-suseer08:12
zyga-suseit **is** random08:12
mvozyga-suse: do you always get the same yaml? hexdump -C on the file would be great08:12
zyga-susemvo: so far yes but as I said, I only save one file08:12
zyga-susemvo: so I could get the same one because it's the first/last08:12
mvozyga-suse: but that file is always the same?08:12
zyga-suseyes08:12
zyga-suseeach time I saw it (~1008:13
mvozyga-suse: thats a good start08:13
jameshmvo: I've pushed some changes based on your review comments.  Assuming CI is happy with it, can you merge it?08:13
zyga-suseand note that since I built the package so I managed to run everything at least once without any failures08:13
Chipacazyga-suse: ` - :` probably is bad yaml tho08:13
Chipaca:-p08:13
zyga-susespeaking of which, I wanted to upload that package08:13
zyga-suseChipaca: I figure :)08:13
mvopstolowski: does 3526 needs a review from gustavo? or just a second review?08:13
zyga-suselet me get more facts08:13
zyga-suseI find it annoying and curious at the same time08:13
mvojamesh: \o/ thank you08:14
mvojamesh: I have a look and if CI is green I will merge it, really nice to see this sorted, this is a huge win for usability08:14
pstolowskimvo, hey, yes 3569 is ready but has been failing tests for random reasons unrelated to the PR itself, i restarted it a couple of times in the last few days08:14
mvozyga-suse: you sure its ` - :` and not `( - :` ;) ?08:14
zyga-susemvo: hahahaha08:14
jameshmvo: I've got more I'd like to do w.r.t. polkit support: this was just a minimal change to get the foot in the door.08:15
mvopstolowski: yeah, I pushed master, maybe today is a good day08:15
zyga-susemvo: yaml-smiley-virus-201708:15
pstolowskimvo, and yes, 3526 needs a review from Gustavo08:15
zyga-susemvo: replaces random in-memory yaml with a non-parsing smile08:15
zyga-suse:D08:15
mvojamesh: anything that is ready or almost ready that we want for 2.28 (which we plan to tag in the next few days)?08:15
pstolowskimvo, :) yes let's hope today is THE DAY ;)08:15
mvopstolowski: I added gustavo for 3526, lets poke him in the standup :)08:16
pstolowskimvo, thanks@08:16
jameshmvo: It's probably best not to wait.  I'd like to add polkit auth for a few more APIs, but I understand that is somewhat controversial08:16
jameshmvo: less controversial is having the snap client support the textmode polkit agent and indicate whether it is interactive08:17
mvojamesh: ok, sounds good! what is needed for the textmode polkit agent? I assumed this is transparent for the API user, no?08:17
mvomorphis_: want me to have a look at the open comments for 3260? it seems its almost there08:18
jameshmvo: essentially just have it fork "pkttyagent --fallback", like systemctl does08:18
zyga-archre08:19
zyga-archChipaca: have a look08:19
jameshmvo: this would let you run privileged operations without sudo, having pkttyagent prompt if needed08:19
zyga-archhttps://paste.gnome.org/pecbkpb4e08:19
morphis_mvo: if you have spare cycles for that, that would awesome08:19
zyga-archthis is from08:19
zyga-archhttps://paste.gnome.org/prw9lmfbx08:19
mvojamesh: aha, nice!08:19
morphis_mvo: but more in general I still waiting for niemeyer to approve this from an architectural point08:19
zyga-archChipaca: ideas appreciated, I can patch and rebuild easily08:20
mvojamesh: if this PR is there before 2.28 is taged I will milestone it so that it gets at least priority reviews :)08:20
jameshmvo: okay08:21
mvomorphis_: I can raise it in the standup, I was uner the impression he is happy with it now but I have not talked with him in detail08:21
morphis_mvo: that was my guess too, but he still has his denial on the PR08:21
morphis_mvo: otherwise let me try to get through zyga-arch's comments this afternoon08:22
mvomorphis_: I tagged it for 2.28, lets see if that helps speeding it along. I also check the open question and will push changes08:22
morphis_:-)08:22
Chipacazyga-arch: and which test is it that fails with this?08:22
mvomorphis_: lets make a deal, I look at things now and what is left you can have in the afternoon :)08:22
morphis_sounds good :-)08:22
zyga-archChipaca: *any* tests that touches yaml, I saw it fail all over the source code08:22
Chipacazyga-arch: an example?08:23
zyga-archessentially any that calls snap.InfoFromSnapYaml for insatance FirstBootTestSuite.TestPopulateFromSeedHappyMultiAssertsFiles08:26
zyga-arch(note that this is a first that I saw this particular test failing)08:26
zyga-archmvo: question, did you upgrade your laptop to >> xenial?08:28
zyga-arch(hence the spellchcek and govet changes)08:28
zyga-archChipaca: I just patched it to collect each failure, let's see what we get08:33
zyga-archhttps://paste.gnome.org/pjiw7rerp08:45
zyga-archmore interesting failure log08:45
Chipacazyga-arch: what filesystem is this on?08:46
* Chipaca thinks "lardfs"08:47
zyga-archChipaca: ext408:48
zyga-archas boring as it gets, right?08:48
zyga-archLinux archlinux 4.12.8-2-ARCH #1 SMP PREEMPT Fri Aug 18 14:08:02 UTC 2017 x86_64 GNU/Linux08:48
zyga-archthe kernel is fresh though08:48
Chipacazyga-suse: can you try with a kernel that isn't newer than the host's? (not that it should matter)08:50
zyga-archChipaca: not sure, I don't know how to get old arch kernels08:52
Chipacazyga-arch: snap install linux-2.0.4308:53
Chipacano?08:53
Chipacaaw :-(08:53
zyga-archheh, not yet08:54
zyga-archI improved logging to save the failing yaml and the error message08:54
zyga-archmaybe some of those are genuine errors from the test suite08:54
Chipaca“snap set core locales en_GB.UTF-8”, WTDT?08:54
ChipacaWDYT*08:54
ogra_Chipaca, wont work08:55
Chipacaogra_: wy?08:55
ogra_because there is no locale-gen08:55
=== tinwood_ is now known as tinwood
Chipacaogra_: not _yet_ :-)08:56
ogra_Chipaca, i wont add 20MB (or what was the locales stuff)08:56
* ogra_ forgot the exact size but it wasnt small iirc08:56
Chipacaogra_: oooh, we can discuss this like civilized people, or we can fight!08:57
* Chipaca gets his gloves08:57
zyga-arch*ding* FIGHT08:57
zyga-archand you konw08:57
* Chipaca runs the fastest08:57
zyga-archthe finishing move will be called LOCALITY!08:57
* Chipaca makes chicken noises and waves his elbows while running08:58
* ogra_ throws a de_DE.UTF-8 ... in a perl variant !08:58
* Chipaca is in a perl hackers list somewhere on the internet still08:58
* Chipaca mutates the glob behind the variant and throws it back08:59
zyga-archChipaca: on the interenet nobody knows you are a perl interpreter08:59
ogra_Chipaca, i'll trade though ... find something that compensates enough for the added stuff and we can talk ;)08:59
Chipacaogra_: but, serioulsy, if it's 20MB i'd agree, but i think what we want is the locale-gen, not the locales themselves08:59
ogra_there is definitely still other stuff we can drop09:00
zyga-archogra_: here's $0.01 for the flash cost ;)09:00
zyga-archChipaca: here's another interesting failure09:00
zyga-arch----------------------------------------------------------------------09:00
zyga-archPANIC: firstboot_test.go:445: FirstBootTestSuite.TestPopulateFromSeedMissingBootloader09:00
zyga-arch... Panic: cmd: "mksquashfs . /tmp/check-717607699634245797/61/snapsrc/core_1.0_all.snap -noappend -comp xz -no-xattrs" failed: exit status 1 ("Parallel mksquashfs: Using 4 processors\nCreating 4.0 filesystem on /tmp/check-717607699634245797/61/snapsrc/core_1.0_all.snap, block size 131072.\n\r[===================================================================|] 1/1 100%writer: Lseek on destination failed because Bad file descri09:00
zyga-archptor, offset=0x60\nFATAL ERROR:Probably out of space on output filesystem\n\n\nExportable Squashfs 4.0 filesystem, xz compressed, data block size 131072\n\tcompressed data, compressed metadata, compressed fragments, no xattrs\n\tduplicates are removed\nFilesystem size 0.35 Kbytes (0.00 Mbytes)\n\t101.72% of uncompressed filesystem size (0.34 Kbytes)\nInode table size 98 bytes (0.10 Kbytes)\n\t100.00% of uncompressed inode table09:00
zyga-archsize (98 bytes)\nDirectory table size 55 bytes (0.05 Kbytes)\n\t100.00% of uncompressed directory table size (55 bytes)\nNumber of duplicate files found 0\nNumber of inodes 3\nNumber of files 1\nNumber of fragments 1\nNumber of symbolic links  0\nNumber of device nodes 0\nNumber of fifo nodes 0\nNumber of socket nodes 0\nNumber of directories 2\nNumber of ids (unique uids + gids) 1\nNumber of uids 1\n\tzyga (1000)\nNumber of gid09:00
zyga-archs 1\n") (PC=0x458E88)09:00
zyga-arch /dev/sda2        20G  9,5G  9,1G  52% /09:01
Chipacahmmmm09:01
Chipacazyga-arch: how09:01
Chipaca's space doing?09:01
zyga-archtmpfs           1,5G  2,1M  1,5G   1% /tmp09:01
Chipacaah09:01
zyga-archnot bad09:01
Chipacazyga-arch: what does dmesg say?09:01
zyga-archreally weird, right?09:01
ogra_did you add locales back ?09:02
ogra_:P09:02
zyga-archnothing at all09:02
zyga-archhttps://paste.gnome.org/psa6vgmnj09:02
zyga-archthe last timestamp is old there09:02
mvozyga-arch: yeah, I run on zesty09:02
zyga-archmvo: I'm tempted to update my xenial x25009:02
mupPR snapd#3569 closed: snapd,snapctl: decode json using Number <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3569>09:02
zyga-archany issues?09:02
mvozyga-arch: its doing fine on my x25009:02
Chipacazyga-arch: i'll move this weirdness to the backburner for a bit09:03
Chipacalet see if something percolates09:03
zyga-archChipaca: yeah, me too; thank you for the time!09:04
Chipacais it my machiine, or are the travis logs so slow they're almost unusable?09:04
zyga-archmy network is shitty enough not to handle 2 IRC connections (and music streaming :P)09:07
pstolowskiyay! thanks mvo :)09:09
mvopstolowski: thank you :)09:09
zyga-archjanisozaur: hey, around?09:58
janisozauro/09:59
zyga-archhey :)09:59
zyga-archdo you have a moment to help me out?09:59
janisozaurwith?09:59
morphiszyga-arch: I am seeing https://paste.ubuntu.com/25375579/ right now on my production system10:00
zyga-archjanisozaur: I'd like you to build a package for me a few times10:00
zyga-archI'm seeing random bugs that feel like kernel memory corruption or something similar10:00
zyga-archand I need 2nd opinions10:00
janisozauron Arch?10:00
zyga-archyes10:00
zyga-archmorphis: oh that's a new thing, feels I dind't patch the apparmor profile10:01
zyga-archmorphis: where are you seeing this?10:01
morphiszyga-arch: Ubuntu 16.0410:01
janisozaurI don't have access to my system right now, maybe in the evening?10:01
morphisI think with proposed enabled10:01
zyga-archjanisozaur: that's ok, thank you!10:01
zyga-archmorphis: I think we need to fix this, mvo ^^^10:01
zyga-archmvo: we may need to patch 2.27.x10:01
zyga-archlet me check though10:01
morphis2.27.3 is the version of the snapd deb10:01
janisozaurzyga-arch: that's on fully updated system, right?10:02
zyga-archyes10:02
zyga-archmorphis: can you look at your apparmor profile10:03
zyga-archmorphis: look for     mount options=(rw bind) @SNAP_MOUNT_DIR@/{,ubuntu-}core/*/etc/nsswitch.conf -> /tmp/snap.rootfs_*/etc/nsswitch.conf,10:03
zyga-archmorphis: this should be in /etc/apparmor.d/10:03
morphisyeah, it's there10:03
zyga-archmorphis: can you check that it is present for the core snap version as well10:03
morphiszyga-arch: hm, an apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real fixed it10:04
zyga-archmorphis: !!!10:04
morphiszyga-arch: the core snap is at 16-2.26.1410:04
zyga-archmorphis: can you please open a forum topic10:04
zyga-archI think we've seen it before10:04
zyga-archbut now it's a smoking-gun-bug10:04
zyga-archmorphis: and please save your journal10:04
morphissure, but can't share that in the public10:04
zyga-archas there are log entries for each time the profiles are loaded10:05
zyga-archjdstrand: ^10:07
zyga-archmvo: ^ (possible bug in our packaging or in dh_apparmor in general)10:07
morphiszyga-arch: mvo: https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/182010:09
morphiszyga-arch: if I remember right I've rebooted in between10:10
mvozyga-suse: ok, we need to figure out if its a regression, fortunately its not too late yet to do another 2.2710:10
zyga-archmvo: I don't think so, we've seen this randomly a few times10:11
mvomorphis: what is the timeline, i.e. did you apt upgrade and after that the snapd services did stop working?10:11
zyga-archmvo: but it is serious, it means we are running on a broken configuration10:11
mvozyga-arch: or did a reboot happen in between?10:11
zyga-archmvo: I don't know, it's morphis that is affected10:11
mvozyga-arch: yeah, definitely serious10:11
morphismvo: if I remember right, I did a manual apt upgrade10:12
morphisdid a reboot and then after some time wondered why specific services coming from a snap were not running10:12
* zyga-arch wonders where to upload the binary release for Arch10:12
zyga-arch:/10:12
mvomorphis: can you please add the info that there was a reboot in between? that might be useful to know10:13
morphisdone10:13
mvomorphis, zyga-*: I think we want the input from jdstrand on https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/182010:13
janisozaurzyga-arch: github releases?10:13
zyga-archjanisozaur: oh, good idea10:14
zyga-archmvo: can I add a file to our 2.27.3 github release page?10:14
mvozyga-arch: I bet its apparmor cache related10:15
zyga-archmvo: I checked that the debhelper scripts uses an option to skip the cache10:15
mvomorphis: silly question, but another reboot will not bring the problem back, right? I assume apparmor_parser -r will update all caches10:15
mvozyga-arch: oh? woah10:15
morphismvo: didn't tried yet10:15
zyga-archmvo: not sure, caches are writen to explicitly10:15
mvozyga-arch: so the file on disk is correct but the wrong profile is loaded even after reboot?10:15
zyga-archI think the early startup script that loads profiles10:16
zyga-archmvo: not sure how it uses or not uses caches10:16
mvozyga-arch: re file for release> what file exactly?10:16
zyga-archmvo: binary build for arch10:16
zyga-archand a source package for arch10:16
mvozyga-arch: sure10:16
zyga-archthank you10:16
mvozyga-arch, morphis: so just to double check - the apparmor profile on disk is correct, the reboot has happend and yet the kernel has an incorrect profile loaded?10:16
morphismvo: yes, that is what happened10:17
morphiscan it be a problem that the core snap was still at 2.26?10:17
zyga-archmorphis: next time, don't reload the profile10:17
zyga-archmorphis: please collect the loaded profile from sysfs10:17
mvomorphis: would you mind also putting this as a TL;DR in the forum post :) ?10:17
zyga-archmorphis: no, each profile is distinct10:17
zyga-archit applies to a specific binary via path10:18
mvomorphis: this makes it also sound as alarming as it should sound :)10:18
zyga-archmorphis: profiles can be extracted from memory10:18
zyga-archmorphis: via /sys/kernel/apparmor/profiles/10:18
zyga-archmorphis: but you need to copy the raw policy10:18
mvozyga-arch: 3260 is ready for a re-review10:18
zyga-archmorphis: you cannot tarball the directory10:18
zyga-arch(or you may need to give tar a smart option to ignore size)10:18
zyga-archmvo: noted, I'll open it now10:18
mupPR snapd#3581 closed: daemon: add polkit support to /v2/login <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3581>10:19
* mvo hugs jamesh10:19
jameshmvo: thanks!10:20
morphismvo, zyga-arch: btw. shouldn't I better file a bug report on launchpad for this?10:20
zyga-archmorphis: I prefer the forum really10:21
zyga-archmorphis: people look there x10 more often10:21
morphiszyga-arch: so is that were you now track bugs?10:21
zyga-archmorphis: track TODOs really, bugs and other10:21
zyga-archmorphis: a bug is fine as well but my point is that exposure there is low10:22
* zyga-arch spends $ETERNITY to upload the release10:22
morphisjust wondering what the actual policy is10:22
zyga-archmorphis: no idea10:22
morphis:-D10:22
zyga-archmorphis: forum >> bug for sure but bugs are used too10:22
zyga-archI'll focus on the review from mvo/morphis now, ping me for attention10:26
=== jospoortvliet is now known as jospoortvliet_
=== jospoortvliet_ is now known as jospoortvliet
=== ShalokShalom_ is now known as ShalokShalom
mupPR snapd#3784 opened: cmd/snap: in "snap info', don't print a newline between tracks <Created by chipaca> <https://github.com/snapcore/snapd/pull/3784>10:31
mvomorphis: quick question - there is code in cmd_userd.go that looks like you created unittests, there is no cmd_userd_test.go on your hdd that is not git added ;)10:37
Chipacamvo: the bigger question is, how can you see morphis' hdd10:38
mupPR snapd#3785 opened: asserts,overlord/devicestate: accept generic serials only if the model has generic-serials: true <Created by pedronis> <https://github.com/snapcore/snapd/pull/3785>11:14
pedronismvo:  this is the PR ^ ,  marked for 2.28  and needs Gustavo to look at it11:15
morphismvo: need to check but I guess I never ported them over from the former implementation when it was snapd --user11:21
morphismvo, zyga-arch: there seems to be another problem, I am now seeing seccomp enabled for my devmode snaps with 2.27.311:22
zyga-archmorphis: can you please collect as much stuff as you can11:24
morphissure11:24
zyga-archmorphis: can you look at the bpf profile11:24
morphiszyga-arch: how do I see if a process is running with seccomp attached?11:24
zyga-archmorphis: and at the legacy profiles that we don't remove11:24
zyga-archmorphis: let me check, I don't know11:24
zyga-archmvo: devmode snaps get an ALLOW bpf, right?11:25
zyga-archmvo: or nothing at all?11:25
morphishm, the profile has @complain11:25
zyga-archmorphis: which specific file has this?11:25
zyga-archmorphis: note that we have new profile location now so you may be looking at the old palce11:26
morphiszyga-arch: the profile for my snap app11:26
zyga-archplace11:26
zyga-archmorphis: right, _which_ file? :-)11:26
morphis /var/lib/snapd/seccomp/profiles/snap.anbox.container-manager11:26
zyga-archthat's the old file11:26
zyga-archit's not used anymore11:26
zyga-archand not removed either11:26
zyga-archmorphis: look at seccomp/bpf11:26
zyga-archthere are two files per profile11:26
zyga-archbinary and source11:26
zyga-archthose are compiled with snap-seccomp11:27
morphishm, /var/lib/snapd/seccomp/bpf/snap.anbox.container-manager.src has @complain too11:27
zyga-archokay so _so far_ so good11:27
zyga-archmvo: is the person to talk as he wrote that part11:27
morphisbut I see a lot denials in dmesg: https://paste.ubuntu.com/25375999/11:27
zyga-archI'll return to your code review11:27
zyga-archmq_timedreceive ?11:28
zyga-archor is this an i386 binary?11:28
morphisit's x86_6411:28
zyga-archso this is mq_timedreceive, weird11:28
zyga-archI'll leave that to mvo for now11:28
zyga-archbut feels like another forum topic to open11:29
morphiszyga-arch: can I reliable switch back to the older snapd or will that break things even more?11:30
zyga-archyou should be11:30
zyga-arch(able to)11:30
morphisok, but lets wait for mvo before I do that11:31
pedronisseems there are still issues with the fakestore sometimes11:36
pedroniswe probably want to print the logs there11:39
zyga-susemorphis: I commented on the 3260 PR about one aspect of the spread test11:39
zyga-susemorphis: can you look please11:39
zyga-suseI'm looking at the rest11:39
morphiszyga-suse: when I get to it today, I will for sure :-)11:47
morphiszyga-suse: thanks11:47
mvozyga-suse, morphis: seccomp is allow all mode12:02
zyga-susemvo: aha, then something wonky is going on12:03
mvomorphis: strange, @complain should be fine and should not kill anything, the generated bpf file ".bpf" would be nice, could you mail that to me?12:04
mvozyga-suse, morphis: I can look at the test issue in 3260, I'm keen to land that, will also look at the cmd_userd.go bits and see if I can come up with a test12:05
pedronismvo: Chipaca: as I told Gustavo yesterday I have errands today that overlap with the standup so I won't be there12:06
mvopedronis: ok, thank you12:07
morphismvo: sure12:11
morphismvo: sent12:12
morphismvo: so these messages in dmesg are no denials?12:12
zyga-susemorphis: those are hard denials12:14
zyga-suse(SIGKILL)12:14
zyga-susethere's no complain mode for seccomp being used yet12:14
morphisgood, that is what I thought12:15
mvomorphis: bpf disassembled looks ok, what architecutre is this? amd64?12:18
morphisyes, amd6412:19
morphismvo: installed with snap install --devmode --edge anbox12:19
mvomorphis: ok, let me try that12:20
mvomorphis: I just did a snap install --devmode --edge anbox and systemctl status snap.anbox.container-manager is happy12:22
mvomorphis: what should I see?12:22
ogra_ppisati, ".config:9871:warning: override: reassigning to symbol ARCH_MEDIATEK" what does that mean ?12:34
ogra_(building a patched arm64 mediatek kernel here, is the above fatal in any way ? i have never seen it before)12:34
jdstrandmorphis: fyi, syscall 243 is mq_timedreceive and that isn't included in any interfaces. the denial indicates you are not actually in complain mode12:41
jdstrandmvo, zyga-arch: ^12:42
jdstrandalso, I commented in the forum topic12:42
jdstrandmorphis: ^ questions for you there12:42
zyga-archjdstrand: looking12:42
jdstrandmvo: based on morphis' denial, it seems clear that seccomp.NewFilter(seccomp.ActAllow) isn't being run12:47
jdstrandmvo: that should be a very small bpf based on lines 616-624 (as you know)12:48
jdstrandmorphis: can you paste the entirety of /var/lib/snapd/seccomp/bpf/snap.anbox.container-manager.src?12:49
mvojdstrand: morphis mailed me the bpf and it looks like this http://paste.ubuntu.com/25376337/12:53
zyga-suseI get a change after running get-deps.sh12:53
mvojdstrand: so it looks like the normal allow bpf12:53
zyga-susegolang.org/x/sys/unix changes checksum12:53
mupPR snapd#3786 opened: vendor: update vendor.json after (presumed) manual edits <Created by zyga> <https://github.com/snapcore/snapd/pull/3786>12:57
zyga-susemvo: ^12:57
jdstrandmvo: that's interesting. seems that the old non-bpf profile is being preferred, which suggests a problem with the reexec code12:57
mvojdstrand: oh, that is interessting12:59
mvomorphis: what do you get with `snap version` on the system that has the anbox problem?12:59
zyga-susejdstrand: yes, I was thinking the same thing13:00
zyga-susejdstrand: the old profile gets used because the old snap-confine runs13:01
jdstrandzyga-suse: based on the forum topic, it looks like morphis has the stable core installed (16-2.26.14) and upgraded to 2.27.3. I tried that exact upgrade path and couldn't reproduce the apparmor bits13:11
jdstrand(upgraded t 2.27.3 deb)13:11
zyga-susejdstrand: I haven't been able to reproduce that13:11
zyga-susejdstrand: but I've seen it happen once in front of my eyes13:11
morphismvo, jdstrand: back now, let me read through the messages13:12
morphismvo: snap version output is on the forum thread13:13
jdstrandzyga-suse: based on the forum topic alone, it looks like the system (not the reexec'd) snap-confine is used13:14
zyga-suseyes, I agree13:14
jdstrandzyga-suse: I wonder if it is a race between the snapd restart and the deb packaging13:15
zyga-susemmmm13:15
zyga-susere-execing snap (as in snap run) will always use the new snap-confine13:16
jdstrandzyga-suse: but in this case, new is the deb (2.27 deb vs 2.26 snap)13:16
zyga-suseriiiight13:17
zyga-suseso there's no reexec13:17
zyga-suseso there should be stuf from the distro13:17
zyga-suseaha13:17
zyga-suseI see13:17
jdstrandso re-exec should not be in effect (indeed, the denial clears shows /usr/lib/snapd/snap-confine has the denial, not /snap/core/.../snap-confine13:17
zyga-suseso half-way unpacked snap-confine binary?13:17
jdstrandclearly*13:17
zyga-suseyes, I noticed that13:17
jdstrandI'm trying to think through that. let me look at the postinst again13:18
morphisjdstrand: mvo: added requrested details to the forum post13:21
jdstrandzyga-suse: so, looking at postinst, snapd looks to be started *before* the dh_apparmor hooks13:25
zyga-suseoh,13:25
zyga-susein the maintainer script13:25
jdstrandzyga-suse: line 125: deb-systemd-invoke start snapd.service >/dev/null || true13:26
jdstrandzyga-suse: line 160:  apparmor_parser -r -T -W "$APP_PROFILE" || true13:26
mvomorphis: the `snap version` output of the anbox issue13:28
mvomorphis: that is the bit I care most about13:28
mvojdstrand: ohhhh, ok. will you do a PR or shall I?13:28
jdstrandzyga-suse: now, the new profile should be on disk so, technically, snapd would load the new profile and it shouldn't matter. *but* if there was a problem there with snapd using the wrong profile and updating the cache, by the time apparmor_parser dh postinst is run, it wouldn't update the cache, so on reboot, it would be out of date13:28
jdstrandzyga-suse: *if* the start won the race that is13:29
jdstrandsince we are seeing some reexec issues with seccomp, I'm not sure we can say for sure that snapd is doing the right thing here, so perhaps the postinst ordering exposes something13:30
jdstrandmorphis, zyga-suse: it does seem most correct to have the dh bits for apparmor before the dh bits for systemd, but I don't know if it will fix this issue13:31
zyga-suseI'll read your conversation with focus in a moment (on a call)13:31
morphismvo: it's on the thread13:32
morphismvo: within the first post: https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/1820?u=morphis13:33
mvomorphis: I mean, you mentioned an "anbox" problem and seccomp not being in @complain mode but in enforce mode. that was a different issue, no?13:34
morphismvo: ah, I have both issues I've reported today (apparmor + seccomp) on the same system after the deb upgrade to 2.27.313:34
morphisso snap version output is the same for both13:35
mupPR snapd#3784 closed: cmd/snap: in `snap info`, don't print a newline between tracks <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3784>13:35
mupPR snapd#3787 opened: cmd/snap-repair: filter also on models and architecture <Created by pedronis> <https://github.com/snapcore/snapd/pull/3787>13:47
zyga-suse+ curl -sS -o - https://codeload.github.com/snapcore/snapd/tar.gz/2.2713:51
zyga-susegzip: stdin: not in gzip format13:51
zyga-suseunhappy github?13:51
zyga-suseonly half of spread tests finished13:51
zyga-susein https://travis-ci.org/snapcore/snapd/builds/267571170?utm_source=github_status&utm_medium=notification13:51
=== JoshStrobl|zzz is now known as JoshStrobl
Chipacazyga-suse: i got that one too for a lil' bit14:00
Chipacaseems to be better now14:00
Chipacai'm assuming network hiccup14:00
zyga-susehttps://plus.google.com/114015603831160344127/posts/MdNjzwKvknX14:09
zyga-susejdstrand: ^ perhaps something to keep an eye out for14:09
zyga-susejdstrand: specifically https://bugs.freedesktop.org/show_bug.cgi?id=10135414:10
mupPR snapd#3788 opened: cmd/snap-repair: ignore superseded revisions like the rest of the assertion infra <Created by pedronis> <https://github.com/snapcore/snapd/pull/3788>14:12
jdstrandzyga-suse: thanks14:17
zyga-susejdstrand: were you familiar with those efforts?14:23
mvozyga-suse: 3260 should now address all questions/suggestions14:33
mvozyga-suse: why the question about artful?14:33
zyga-susemvo: run xdg-open on artful14:33
zyga-suselast time I looked it was a broken shell script14:33
zyga-suse(that didn't work)14:33
zyga-suserecommending to switch to gio-open or something like it14:34
zyga-suseit feels like an upstream change that will go our way sooner or later14:34
mvozyga-suse: looks ok to me (xdg-utils 1.1.1-1ubuntu2) - what system did you try this on?14:35
zyga-susemvo: maybe it was fixed14:35
zyga-susemvo: what happens when you run it? (note: artful, not zesty)14:36
zyga-susemvo: does it print any advice?14:36
mvozyga-suse: I only tested it in a chroot so far but it look like the normal xdg-open. version is the same as the zesty version14:36
zyga-susemvo: is it a shell script?14:37
mvozyga-suse: yes14:37
mvozyga-suse: it always was one14:37
ogra_are oyu surte you are not looking at snapd-xdg-open ?14:37
mvo(afaik)14:37
ogra_*you sure14:37
zyga-suseogra_: no14:37
ogra_(awful shell script talking about being replaced sounds exactly like it)14:38
zyga-suseogra_: no, that was a 4 line script14:38
zyga-suseogra_: that had a typo that made it broken14:38
zyga-suseogra_: maybe this update was pulled from artful since, I saw it on my desktop at home14:38
zyga-suse(I cannot check that now)14:38
mvozyga-suse: xdg-open prints helpful advice in my cloudvm as well14:38
zyga-suseit printed a message and ran something else14:38
zyga-susemvo: if it works and will stay working then fine14:39
mvozyga-suse: we can always tweak further, but if xdg-open is broken we have a bigger problem in artful14:39
zyga-susemvo: I was worried since it felt like it is going away14:39
hallyn...  say, the snappy vagrant box, is there a default username/pwd? vagrant wants those to get in to setup authkey14:39
mvozyga-suse: lots of 3rd party things use it14:39
zyga-suseI see it even supports flatpak now14:39
jdstrandzyga-suse: I wasn't, no. Simon, the submitter, is active with apparmor so I'm hopeful it won't conflict with anything. I haven't looked at any of this yet (I created a card)14:39
zyga-susethank you jdstrand14:40
* zyga-suse experiences dial-up speeds :/14:41
ogra_use LTE !14:44
Chipacaogra_: i agree! Liquid Tension Experiment makes everything better. Evidence: https://www.youtube.com/watch?v=edqH0ofRQrM14:48
Chipacaof course, zyga can't watch that because he's on GPRS14:48
Chipacazyga-suse: it could be worse: you could be tethered over bluetooth to an GPRS nokia. rfcomm still haunts me.14:49
mupPR snapd#3786 closed: vendor: update vendor.json after (presumed) manual edits <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3786>14:49
zyga-suseChipaca: and the nokia might be wrapped in plastic and connected to usb power pack14:49
zyga-suseChipaca: out there glued to a tree14:49
zyga-suseChipaca: in the rain14:50
zyga-suseChipaca: to get the signal14:50
zyga-suseChipaca: that's close to how I'm connected14:50
Chipacazyga-suse: outside? you'd get several kbps more from that!14:50
Chipacalike, 20% more! or 3kbps14:50
zyga-susehaha14:50
zyga-susemy network is so slow14:50
zyga-susethat I see a merged branch (3786) in the list of open PRs14:50
zyga-suseand that list has just loaded :D14:50
ogra_lol14:58
=== cachio is now known as cachio_lunch
jdstrandmorphis (cc mvo and zyga-suse): https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/1820/815:15
* zyga-suse looks15:15
morphisjdstrand: just read it, interesting15:15
jdstrandmorphis: if you wanted to propose a PR, I'd be happy to review it15:21
jdstrandmorphis: maybe mvo or zyga-suse would want to propose that...15:22
morphisjdstrand: sadly not enough time to do that15:22
mvojdstrand, morphis I can look at this in a bit15:22
zyga-suseI can look15:22
jdstrandok, thanks guys15:22
zyga-susewow, git push takes noticeable time15:22
morphismvo: jdstrand: the other issue is seccomp being in enforce mode for devmode snaps15:23
mvozyga-suse: I take a break now, so feel free15:23
morphismvo: you found anything in the profiles I've sent you?15:23
mvomorphis: its using the wrong profile, that seems to be the issue, does reloading the unit fixes the issue?15:23
mupPR snapd#3789 opened: cmd/snap-confine: genearlize apparmor profile for various lib layout <Created by zyga> <https://github.com/snapcore/snapd/pull/3789>15:23
mvomorphis: the profile looks correct, its the normal allow profile15:23
morphismvo: you mean restarting the systemd unit?15:24
mvomorphis: I suspect what happens is that the old profile is loaded or was loaded15:24
zyga-susejdstrand: I'll propose a small PR with the order of calls in the maintainer script changed15:24
mvomorphis: yeah, the systemd unit for the failing service15:24
morphismvo: nope, that doesn't help15:25
morphislet me try to remove and install the snap again15:25
jdstrandmvo: keep in mind seccomp doesn't work like apparmor-- snap-confine loads what is on disk into the kernel on each invocation (ie, there is no binary attachment or anything). either an old snap-confine that doesn't know bpf is parsing the profiles/* file, or the new snap-confine is preferring profiles/8 over bpf/*.bin for some reason15:27
zyga-susehmm, this debian packaging change will require some more surgery it seems15:27
jdstrandmvo: the only other possibility would be *if* bpf/* on disk at the time snap-confine ran was strict mode, then updated after the fact for devmode15:27
zyga-susejdstrand, mvo: it seems that all of the magic is in #DEBHELPER# expanding, I wonder how we can fix that15:28
pedroniszyga-suse: what's the status of snapd#3617, wasn't it split in a lot of smaller PRs ? or is still wip ?15:28
mupPR snapd#3617: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617>15:28
zyga-susepedronis: it's good for review I think, all the small PRs were merged and integrated there now15:29
zyga-susepedronis: I haven't checked where things go15:29
zyga-suse(as in what needs doing there)15:29
jdstrandzyga-suse: so, if you put dh_apparmor before dh-installinit, it still ends up after?15:29
zyga-susejdstrand: no, I mean that there is no explicit dh_apparmor there, it's all done at build time15:30
jdstrandzyga-suse: ie, all in override_dh_installint15:30
zyga-susejdstrand: quickly looking at that file shows that it is post-processed during the build to contain the actual "meta"15:30
zyga-suse"meat"15:30
jdstrandzyga-suse: ?? I'm looking at debian/rules from xenial-- line 188 has dh_apparmor15:30
zyga-suseI was looking at .postinst in packaging/ubuntu*/15:31
jdstrandzyga-suse: if you are talking about packaging/*...15:31
jdstrandzyga-suse: you have to look at packaging/ubuntu*/rules15:32
zyga-suseok, I have that open15:33
jdstrandzyga-suse: you can change things in there to affect #DEBHELPER# in postinst15:33
zyga-suseI see, I'm not familiar with that, let me experiment15:33
jdstrandzyga-suse: alternatively, you can just drop dh_apparmor, then modify snapd.postinst directly to put what dh_apparmor would put in #DEBHELPER# before #DEBHELPER#15:33
jdstrandzyga-suse: looking at that file, you just need to make it so dh_apparmor happens before dh_systemd_start -psnapd data/systemd/snapd.service15:35
jdstrandcause it is deb packaging, you have lots of choices :)15:35
zyga-suseyes :-)15:36
* jdstrand notes that the xenial Uuntu archive packaging does not seem to be derived from packaging/ubuntu*15:36
jdstrandUbuntu*15:36
zyga-suseif that's the case we should fix that for 2.2815:37
jdstrandI don't know what is used where, so to fix this in SRU, just make sure things are updated everywhere it needs to be15:37
jdstrandzyga-suse: that might violate the SRU process. I'm not familiar with the agreements there. please discuss with mvo before transitioning 2.28 in the Ubuntu archive to packaging/ubuntu*15:38
zyga-suseah, indeed... man this stuff is so hairy15:38
zyga-susemvo:  I thought that each upload to xenial proposed was using this packaging15:38
zyga-suseare you maintaining a separate package somewhere for xenial?15:38
jdstrandoh, maybe it is15:40
Pharaoh_Atemmvo is using packaging/ubuntu*15:40
jdstrandI looked at the one from -updates rather than -proposed15:40
Pharaoh_Atemthat's why he's got the weird symlink for gbp15:40
jdstrandthe one from -proposed looks like packaging/ubuntu*15:41
jdstrandzyga-suse: ^15:41
zyga-suseaha15:41
jdstrandzyga-suse: ie, I think you are good with updating packcaging/ubuntu*15:41
zyga-susewell, that's nice then15:41
jdstrandyeah, sorry for the brief noise15:41
zyga-susejdstrand: can you look at https://github.com/snapcore/snapd/pull/3789 while I'm fiddling with debian please?15:42
mupPR snapd#3789: cmd/snap-confine: genearlize apparmor profile for various lib layout <Created by zyga> <https://github.com/snapcore/snapd/pull/3789>15:42
jdstrandzyga-suse: so, you can move 'dh_apparmor --profile-name=usr.lib.snapd.snap-confine.real -psnapd' from override_dh_installdeb to the top of override_dh_systemd_start, *or* modify postinst to put what dh_appamor would do up above #DEBHELPER# in snapd.postinst15:43
jdstrandthe former is probably best, since you will benefit from bug fixes to dh_apparmor15:44
jdstrandzyga-suse: yes, I can do that15:46
jdstrandzyga-suse: you dropped a rule (libdl is specified in one but not the other)15:58
zyga-suseoh, ineede15:59
zyga-susecorrected16:00
zyga-suseI just pasted your earlier rules from solus PRs16:00
zyga-susegood catch!16:01
jdstrandzyga-suse: yes, but you pasted only one of the comments :) there were two comments, one for each section :)16:02
=== cachio_lunch is now known as cachio
jdstrandzyga-suse: approved16:03
zyga-susethank you16:05
zyga-suseI see, I will recheck that comment then16:05
zyga-susejdstrand: can you please look at the topmost three patches in https://github.com/zyga/snapd/commits/tweak/opensuse-snap-confine-aa-profile16:06
zyga-suseI think the deeper two are okay16:06
zyga-susebut the topmost one is surely not landable16:06
zyga-suseideas welcome16:06
zyga-suseI will post them later today (I need to break now)16:06
mupPR snapd#3790 opened: cmd/snap-confine: allow reading /proc/filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/3790>16:12
pedronisniemeyer: both me and noise][ added some comments on the 'generic'/generic-serials topic,  I made the PR but I marked it blocked because it's a bit unclear whether is really what we want atm16:12
niemeyerpedronis: Thanks, will follow up there16:13
* zyga-suse -> off for supper/break16:13
pedronismvo: I reviewed a couple fo small 2.28 PRs,  as I said mine is blocked atm,  I also created some small repair PRs, OTOH snapd#3616 is the next important unreviewed one16:15
mupPR snapd#3616: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616>16:15
Chipacazyga-suse: how do i fix the “cannot update snap namespace: cannot switch mount namespace: invalid argument” again?16:17
mvopedronis: does 3616 needs a normal review or a gustavo reivew?16:20
mvomorphis, jdstrand: I'm very confused about the seccomp issue, what does "SNAPD_DEBUG=1 snap run anbox" show? this should print some re-exec related debug16:21
mupPR snapd#3756 closed: corecfg: deal with system.power-key-action="" correctly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3756>16:23
mupPR snapd#3754 closed: corecfg: fix proxy.* writing and add integration test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3754>16:24
Chipacaniemeyer: why does “N** become “write: (N-1)” and not “write: N”?16:36
Chipacathe forum takeover of ^F stopping from doing actual useful in-page search is annoying16:36
niemeyerChipaca: Re. forum, sometimes it indeed feels awkward, but the thinking is probably that things both load and unload dynamically on the page, so CTRL-F is not super useful as it is either16:37
niemeyerChipaca: About the **, I suggest seeing the video on the first message16:37
Chipacai know -- still annoying :-)16:37
niemeyerIt is16:37
morphismvo: 2017/08/23 18:37:15.673897 cmd.go:103: DEBUG: core snap (at "/snap/core/current") is older ("2.26.14") than distribution package ("2.27.3")16:38
niemeyerChipaca: It explains in detail what it's supposed to do and why it's sort of a unique case16:38
niemeyerChipaca: I'd guess it's about half-way through the video16:38
Chipacafair 'nuf (i thought i knew, but ¯\_(ツ)_/¯)16:38
niemeyerChipaca: CTRL-F won't help on the video either, unfortunately :P16:38
Chipacaniemeyer: but “play at 2× speed” does :-)16:39
niemeyerChipaca: Yeah, love it as well16:40
Chipacaniemeyer: also love “play at 0.75×” when learning music16:40
niemeyerChipaca: Recently I also used /2 for the first time16:40
Chipacaniemeyer: also: mplayer -af scaletempo=scale=1.0 -speed 0.7516:41
niemeyerChipaca: It was a super dense topic, and the speaker felt like speaking at 3x naturally16:42
niemeyerChipaca: I actually doubted he was able to speak with so much precision about so many things so fast, and thought the video was sped up.. but looking at other hints the video, no.. the guy was just inhuman..16:42
niemeyerChipaca: Nice, I didn't know about scaletempo16:44
pedronismvo: both16:44
Chipacaniemeyer: the order of -af and -speed is important in that (if you set the speed before doing the scale, it's does the opposite and you need to specify speed=pitch16:45
niemeyerAha, makes sense16:46
niemeyerChipaca: This is the one if you're curious: https://www.youtube.com/watch?v=j-A0mwsJRmk16:46
pedronismvo: it has zero reviews atm16:46
Chipacaniemeyer: yeah, as i understand it 1** meant “reads 0 and 1, writes 0 and/or 1”16:51
niemeyerChipaca: Yeah, I'm trying to avoid [0, 1], but so far no good ideas have shown up16:52
niemeyerPerhaps we don't need to avoid it.. this is really an extremely atypical case and I expect a handful of snaps to use it16:52
Chipacaniemeyer: “and/or” is perhaps too handwavy to codify though16:53
Chipacaniemeyer: is there a resason read is an ordered array instead of two endpoints?16:53
niemeyerChipaca: Yeah, the thinking will need to change from write N to write compatible with N16:53
Chipacado we really want to support a snap reading 1, 2 and 4 but not 3/16:53
Chipacato me an epoch/read_{min,max} and epoch/write, epoch/compat, would cover how it's in my head16:54
niemeyerChipaca: We went from a simplistic view of the world to one that respects its craziness while keeping a way to represent it simplistically.. we should probably not give up on acking that the world is crazy :)16:56
niemeyerChipaca: e.g.16:56
niemeyerChipaca: epoch 1 is a stable, epoch 2 was an alpha revision that broke the format, epoch 3 is the new stable16:57
niemeyerChipaca: It's quite plausible to have a 3 that can handle read 1 but not 216:57
Chipacaniemeyer: true dat16:58
Chipacaniemeyer: wrt crazy, thinking about people that actually want a version of “master@87da2fcf1d0925f489985323303531507b5ed537”16:58
mvomorphis: do you get output or is anabox immediately killed when you run the above command?17:00
niemeyerChipaca: I don't think we should allow those17:01
Chipacaniemeyer: i agree -- we want them human readable17:02
niemeyerYeah, this is clearly oriented for a machine to read17:02
mvomorphis: fwiw, this debug output looks sane SNAP_CONFINE_DEBUG=1 snap run anabox17:02
niemeyerand will corrupt the output of everybody else if shown entirely17:02
morphismvo: https://paste.ubuntu.com/25377571/17:03
morphismvo: no, the process doesn't get killed17:03
morphisthe process will spawn an LXC container17:03
morphisand processes inside that will get killed later on17:03
Chipacamvo: is test-snapd-dbus-service yours?17:06
mvoChipaca: I think so17:19
Chipacamvo: i was going to ask you to build it for i386, but i changed my test instead17:20
Chipacamvo: because i'm lazy _and_ impatient17:20
mvomorphis: oh, that is interessting, so it does not get killed but the daemon part of it is?17:20
mvoChipaca: heh, ok17:20
mvoChipaca: I think we just need to upload it to LP to make it build there17:20
mupPR snapcraft#1501 closed: tests: use assertThat instead of assertEqual <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1501>17:24
mvomorphis: I think we need to continue to debug this tomorrow morning, I will ping you if thats ok17:26
niemeyermorphis, mvo: Provided some feedback on the userd PR..17:56
niemeyerSome simple recommended changes and one issue to think through17:56
zyga-susere18:18
zyga-suseChipaca: hmmmm, not sure, is this on 14.04?18:18
* zyga-suse gives up on backlog18:19
zyga-suseChipaca: did you resolve that issue?18:20
kyrofaroadmr, any idea what's happening here? https://pasteboard.co/GH176X7.png18:20
mupPR snapd#3789 closed: cmd/snap-confine: genearlize apparmor profile for various lib layout <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3789>18:21
mupPR snapd#3791 opened: cmd/snap-confine: allow using additional libraries required by openSUSE <Created by zyga> <https://github.com/snapcore/snapd/pull/3791>18:22
zyga-susejdstrand: ^ a small PR with extra libraries for snap-confine18:22
kyrofaroadmr, I can't upload that snap again, but I should not have to request manual review18:23
zyga-susejdstrand: thank you for the review18:27
zyga-susejdstrand: last of the trivial PRs that' s likely to go in is https://github.com/snapcore/snapd/pull/379018:27
mupPR snapd#3790: cmd/snap-confine: allow reading /proc/filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/3790>18:27
zyga-susejdstrand: this is the RFC branch that I don't expect to land https://github.com/snapcore/snapd/pull/379218:28
mupPR snapd#3792: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/3792>18:28
* zyga-suse gets back to layout18:29
mupPR snapd#3792 opened: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/3792>18:29
jdstrandroadmr: can you sync r919? (fix for 1712476, unrelated to my previous request to you)18:29
zyga-suseI just found a huge downside of using snaps :-(18:33
zyga-susewhen you are working on snap-confine and other lower parts18:33
zyga-suseand you tweak things18:33
zyga-suseand your music player or video player breaks18:33
zyga-suseman that is annoying18:33
zyga-suse(those apps are snaps)18:33
roadmrjdstrand: sure, I'll put it in the queue18:34
roadmrkyrofa: let me see18:34
jdstrandzyga-suse: done18:34
jdstrandzyga-suse: you should use a vm :)18:34
zyga-susejdstrand: thank you again18:34
zyga-susejdstrand: I have plenty but I also like to work natively18:34
roadmrkyrofa: which snap is this?18:34
kyrofaroadmr, revisions 2692, 2678, and 2684 of nextcloud18:35
jdstrandzyga-suse: play music from your vm :P18:38
jdstrandroadmr: thanks!18:38
zyga-suseman, did you try that? it's terrible18:38
zyga-susechoppy and no video acceleration that works18:38
roadmrjdstrand: btw the latest update (913, right?) was deployed earlier today \o/18:38
mupPR snapd#3790 closed: cmd/snap-confine: allow reading /proc/filesystems <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3790>18:39
jdstrandroadmr: awesome, thanks! :)18:40
jdstrandzyga-suse: I was joking :)18:40
jdstrandI've gotten to where I don't do any dev work on my system except for the occasional live policy updates18:41
Chipacazyga-suse: no, i just used a different snap to test18:41
jdstrandeverything is vm18:41
jdstrands18:42
zyga-suseChipaca: I'd appreciate if you could run that again18:42
zyga-suseChipaca: with SNAP_CONFINE_DEBUG=118:42
Chipacasure, 1 sec18:42
Chipacazyga-suse: SNAP_CONFINE_DEBUG=1 doesn't seem to have changed anything18:44
Chipacazyga-suse: what a i looking for?18:44
zyga-suseChipaca: what's the last few things18:44
Chipacazyga-suse: where18:44
zyga-suseand did you get any denials/messages logged?18:44
zyga-suselike nothing at all?18:44
zyga-suseSNAP_CONFINE_DEBUG=yes hello18:44
zyga-suseor whatever that snap was18:45
Chipacazyga-suse: "hello"?18:45
Chipacai mean18:45
Chipacathe snap is not installed18:45
Chipacazyga-suse: http://pastebin.ubuntu.com/25378106/18:45
zyga-suseChipaca: any snap that you ran this with before that failed with EINVAL18:45
zyga-suseI see18:46
zyga-susehmm hmm hmm18:46
zyga-suseI see18:46
Chipaca(as per usual, this might be me needing to install the right thing)18:46
* zyga-suse assumed something else18:46
Chipaca(but i thought we'd fixed that)18:46
zyga-suseis this a make-hack experience?18:46
Chipacait is18:46
zyga-suseI think it was a different case before18:46
zyga-susewait18:46
=== JanC_ is now known as JanC
Chipacazyga-suse: you want me to see if doing this with stock snapd works?18:46
zyga-suseunless it's one of the versions18:46
zyga-susejust install snap-update-ns in distro location18:47
zyga-suseand see if that fixes it18:47
Chipaca1 sec18:47
roadmrjdstrand: ironic :) "Store upload scan failed for review-tools [...] Unexpected output from click-review.18:47
roadmrjdstrand: (which btw looks very similar to what kyrofa reported)18:47
kyrofaroadmr, jdstrand yeah I just got several more emails about it as well. Something is busted18:48
Chipacalel18:48
roadmrkyrofa: indeed18:48
Chipacazyga-suse: yes that fixed it18:48
* zyga-suse wants that release to go out one day18:48
Chipacazyga-suse: i thought we'd changed 'make hack' to copy that one as well?18:48
* Chipaca makes a note to push a PR for this18:48
zyga-suseno, I don't think we did18:48
zyga-susewe should18:48
zyga-susethanks!18:48
Chipacaok, i'll do it18:48
Chipacabut after dinner and dogwalk18:48
jdstrandroadmr: that is probably the cleanup code. it will output stuff if there are lingering things to clean18:54
roadmrjdstrand: aha. Is that in r913?18:54
roadmrjdstrand: it happened in your snap and kyrofa's but not on mine, which is a trivial minimal snap... which kinda makes sense18:55
jdstrandroadmr: yes, 913 (also 919)18:56
jdstrandroadmr, kyrofa: r2698 passed review18:56
roadmryep, that's slightly suspicious - why some and not others?18:57
jdstrandroadmr: you have more than one review machine?18:57
Chipacazyga-suse: how do i rebuild the makefile?18:57
roadmrjdstrand: yes, reviews run on app servers and there are 4 of them18:57
Chipacajust ./autogen.sh?18:57
zyga-suseChipaca: automake18:57
zyga-suseChipaca: I _may_ have a nicer  build system on the horizon18:58
jdstrandroadmr: right, so the one that tried the libreoffice snap will have a directory that didn't get cleaned18:58
zyga-suseChipaca: but for now you just need automake18:58
jdstrandroadmr: (the bug r919 fixes)18:58
roadmrclick-review returned unexpected output for package /tmp/tmplOHGz7/nextcloud.nextcloud_master-2017-08-23_i386.click: ERROR: Could not find '/tmp/review-tools-p1e8wr9d' Removing old review '/tmp/review-tools-skxfgd28'18:58
Chipacain my experience "nicer build system" just means "build system that is more naive about the twisted ways of the world"18:58
roadmrjdstrand: that's for kyrofa's package, this is for yours: click-review returned unexpected output for package /tmp/tmpwU84wp/review-tools.jdstrand_0.47+git_i386.click: ERROR: Could not find '/tmp/review-tools-skxfgd28'18:58
jdstrandroadmr: so it will try to clean it. until r919 is rolled out, it will fail eith PermissionError. when r919 hits, a msg() to stdout will state it is being cleaned18:59
zyga-suseno, just it doesn't have a 5000 line shell crap in case you are on that broken release of AIX on this 36 bit processor using that non-ascii encoding18:59
jdstrandroadmr: I don't understand the review-tools one... that is suggesting the directory went away19:00
roadmrjdstrand: interestingly, note that both log messages mention /tmp/review-tools-skxfgd2819:00
roadmrhm, but that doesn't seem to be it. This is another nextcloud one:   click-review returned unexpected output for package /tmp/tmpF5KzHz/nextcloud.nextcloud_11-2017-08-23_i386.click: ERROR: Could not find '/tmp/review-tools-7p_jt1us'19:01
roadmrclick-review returned unexpected output for package /tmp/tmpbFMjHa/zeronet-js.mkg20001_0.0.1-alpha17_armhf.click: ERROR: Could not find '/tmp/review-tools-vuwvtkw3' ??19:01
jdstrandroadmr: do multiple reviews happen concurrently on these servers?19:01
roadmrjdstrand: hm, potentially, yes19:02
roadmrare they racing each other? :(19:02
jdstrandroadmr: ok, r919 fixes that19:02
roadmrjdstrand: yay :) well it's already in the pipeline, if so, the fastest way is to just stay the course until I can roll out r91919:02
* roadmr checks for clean runway and so on19:02
jdstrandroadmr: I'll get rid of that msg() too and turn it into debug() for r92019:03
roadmrthanks... ugh I hope it doesn't continue to output spurious stuff which confuses sca :(19:03
jdstrandroadmr: that is what r920 will address. r919 fixed a short-circuit value for 'maxage' in the reaping code. it should've been 'only reap if the stale review dir is older than 3 hours'19:05
jdstrandroadmr: I can up that to anything. I figured a review that was 3 hours old was clearly hung19:05
roadmryes, I agree19:05
roadmrjdstrand: so is it that two concurrent reviews are trying to reap the same temporary dir?19:06
jdstrandroadmr: in r913, yes19:07
jdstrandroadmr: in r919, no. but, please hold off r913 for a moment19:07
jdstrandI'll have an r920 in just a moment19:08
roadmroh you meant "hold off r919" :)19:08
jdstrandroadmr: yes. want to test the use of debug()19:09
roadmrok19:09
Chipacazyga-suse: comme çi? https://github.com/snapcore/snapd/compare/master...chipaca:make-hack-update-ns19:15
zyga-susemmm19:15
zyga-susenice use of $(or)19:16
zyga-suseyou want to use $(wildcard *.go) I think19:16
zyga-susesame for others19:16
zyga-suseI don't think *.go does what you want19:17
zyga-suseand I think you want to use 75519:17
zyga-susenot 644 :D19:17
roadmrjdstrand: merges are kinda fire-and-forget, I did my best to try and stop r919 from landing so we don't waste time testing/building that. Not sure I succeeded :)19:17
zyga-suseother than that I think it looks ok19:17
jdstrandroadmr: no big deal. that will fix the concurrency issue (sorry about that)19:18
Chipacazyga-suse: lel19:19
Chipacazyga-suse: about the 75519:19
Chipacazyga-suse: about *.foo AIUI it works in prereq's19:19
jdstrandroadmr: r920 is now committed. it will fix the output to not confuse SCA and should properly cleanup the bad libreoffice snap review directory19:19
zyga-suseI somewhat dobut that (in automake many things are weridly broken)19:19
zyga-susethough... let mecheck19:20
roadmrjdstrand: woohoo, I'll propose the r920 merge19:20
zyga-suseChipaca: ah, you are corret19:20
zyga-suse*correct19:20
zyga-suseChipaca: globs work when used directly19:21
Chipacayup19:21
zyga-suseChipaca: don't work when using variables, hence the function $(wildcard)19:21
Chipacazyga-suse: if i'm editing a makefile, i have 'info make' open :-)19:21
zyga-susehaha, guess what I did19:21
Chipacabecause otherwise i've got to _remember_ this stuff19:21
zyga-suseI love make though19:22
zyga-suseeven if it sucks19:22
roadmrhaha19:22
* Chipaca is not arguing19:22
kyrofaroadmr, can you let me know when it's deployed? I don't know which snap goes into which channel, so I'll need to re-spin all my builds19:22
jdstrandroadmr: it is weird that the bum libreoffice snap happened at the same time as the r913 rollout, but it is good that it did-- it made it clear what was happening there19:23
roadmrkyrofa: sure thing. Sorry about that :( it'll be about 2 hours but I'll ping here19:23
kyrofaThank you19:23
roadmrjdstrand: I saw that error in a bunch of units (I think all of them actually) - so unless libreoffice built e.g. 4 snaps and they all hit different units, I think it was more about the race condition (the "unexpected output" thing, I mean)19:24
roadmrat least I do get visibility on that unexpected output via kibana19:24
jdstrandroadmr: yes, there were two issues. one was concurrent, one was the lo snap19:25
roadmrjdstrand: when it rains it pours eh? :) (and 2 drops constitute a downpour haha)19:25
mupPR snapd#3793 opened: cmd: "make hack" now also installs snap-update-ns <Created by chipaca> <https://github.com/snapcore/snapd/pull/3793>19:25
jdstrandbut both would've given unexpected output19:25
Chipacazyga-suse: ^19:25
jdstrandanyway, r920 should fix that19:26
roadmrgreat :)19:26
zyga-susethank you19:26
Chipacanow let's go walk that hound19:27
* roadmr barks in approval19:27
Chipacaroadmr: I only have the short lead for you i'm afraid19:28
Chipacaalso, i'm not picking up your poo19:28
Chipacajust FYI19:28
* roadmr wags tail19:29
roadmrhaha19:29
mupPR snapd#3794 opened: asserts,overlord/devicestate: revert allowing 'generic'-signed serials <Created by pedronis> <https://github.com/snapcore/snapd/pull/3794>20:02
mupPR snapd#3526 closed: hooks: support for refresh hook <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3526>20:24
janisozaurzyga-arch: sorry, can't help today20:46
zyga-suseikey: hey, offtopic, how to debug solus getting no keyboard input when installed in gnome-boxes?21:02
zyga-suseikey: could it be related to my locale (pl)?21:02
mupPR snapcraft#1504 opened: project loader: refactor into package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1504>21:21
roadmrkyrofa: that rollout you're waiting for is in progress, should be about 10-15 mins. I'll confirm when it's done21:32
kyrofaGreat, thanks roadmr21:33
roadmrkyrofa: ok, done - let it rip.21:42
roadmrjdstrand: ^^ same21:42
jdstrandroadmr: thanks!21:49
jdstrandroadmr: fyi, there is r922 which is not urgent. It makes it so any error during the reap results in a syslog entry (instead of a traceback)21:51
roadmrnice!21:51
roadmrI'll make a note to put in a merge for that tomorrow; I'm almost EOD and don't want to leave it dangling today :(21:51
jdstrandroadmr: r921 has a new yaml check (ie, standard stuff)21:52
jdstrandroadmr: sure, np at all. thanks for doing it! :)21:52
jdstrandstgraber: fyi ^21:52
stgraberjdstrand: sounds good22:00
=== ondra_ is now known as ondra
=== zarcade_droid is now known as Guest88117
=== Guest88117 is now known as ^arcade_droid

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