mupPR snapd#4199 opened: cmd/snap-confine: Add support for 32-bit NVIDIA on biarch <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4199>00:02
kyrofaelopio,  are you suuuuure that adt installs squashfuse?00:12
kyrofaBecause it doesn't look like it is. Can you point me to where it should be doing that?00:13
kyrofaelopio, it's not in debian/tests/control, for example00:13
sergiusenskyrofa that's done on run_lxd_container.sh00:49
mupPR snapcraft#1726 opened: schema: sources should not have defaults <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1726>01:48
ikeygot my .snap files uploaded to my server for testing, buuuut01:48
ikeyit does require the snapd patches ive put in today01:48
ikeyand also requires --devmode --dangerous..01:49
elopiokyrofa: you are right, it is not installed, I see it failing on my WIP branch.01:56
elopioyou can add --setup-commands02:00
mupPR snapd#4200 opened: Return snap-not-installed error in more cases <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4200>03:04
mupBug #1659106 changed: snap refresh/enable/disable doesn't return snap-not-installed error, returns generic 400 instead <snapd:Fix Committed> <https://launchpad.net/bugs/1659106>03:05
mupPR snapcraft#1724 closed: tests: use the common base handler on the fake snapd server <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1724>04:27
=== JoshStrobl|zzz is now known as JoshStrobl
mborzeckimorning guys06:21
mvohey mborzecki, good morning06:27
mborzeckimvo: o/06:30
mborzeckidid you hear back from lenovo?06:30
mvomborzecki: my machine needs to be send in, will take ~5-7 days or so06:31
mvomborzecki: until then I'm with my crufty old t40006:32
mvo(and my desktop which is decently powerful)06:32
mvomborzecki: but funny (or not) enough my desktop does not boot this morning, just hangs in the bios which is rather unfortunate. the physical world is a pain :/06:32
mborzeckiis your desktop one of the ryzen builds?06:34
mborzeckihmm,2017-11-09 15:44:32 Failed project prepare: 106:38
mborzecki    - linode:fedora-25-64:project06:38
mvomborzecki: the desktop is a whitebox that I built from custom parts, but its not very fancy06:39
mvomborzecki: meh, fedora failed? what in particular? its often a bit unstable in itself, or maybe -25 is eol finally and we need to bump it06:39
mborzecki/home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 14: fw_printenv: command not found06:39
mborzeckithis sounds like a u-boot command06:40
mvomborzecki: yes, that is strange that it would use that on a regular machine06:41
mborzeckihm found nother one that failed like this06:42
mborzecki`if command -v grub-editenv >/dev/null; then` this line failed on fedora06:45
mborzeckimaybe we're missing some bit in fedora cloud image06:46
ikeyis there any reason why inside my snap a .so file might appear to be a directory when shared from home..?06:46
ikeythis seems .. slightly bizarre.06:46
mborzeckiikey: probably a question for zyga-solus, my bet is on some bind mount logic that got it wrong06:48
ikeyok this time its not a directory..06:49
ikeylast time it was06:49
mborzeckimvo: hm there's no grub-editenv in fedora, it's named grub2-editenv there06:51
niemeyerEarly hellos06:51
mborzeckiniemeyer: hi, isn't that like a midnight at your place?06:52
niemeyermborzecki: Almost 5am.. crashed a bit earlier yesterday06:53
niemeyerpedronis: About the open PRs, yeah, I really need to get into reviews.. will send up the board shortly06:54
mvoniemeyer: woah, good morning06:55
ikeyok it wasnt a snap issue incidentally06:57
ikeyits a weird feral thing06:57
mvomborzecki: hm, wonder why the fedora machine suddenly starts failing, but maybe just an update06:58
niemeyermvo: Moin!07:01
zyga-solusikey: what did you do?07:02
ikeyoh i didnt07:02
ikeyso the game has "bin/libpdf.so" and "lib/libpdf.so"07:02
ikeyand "bin/libpdf.so" is actually a directory07:02
ikeyconfused the hell out of me07:02
ikeyand the linker was like "nope i dont even"07:02
mborzeckimvo: so there's a commit from Simon Fels done in may, that adds a workaround for grub2-editenv for fedora/suse in lib/prepare.sh07:06
mborzeckithen, the offending lines in boot.sh were last touched in 201607:06
mborzeckii'll try to fix this07:08
mupPR snapd#4201 opened: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4201>07:20
mborzeckimvo: l got to take care of something so I'll be afk for ~2h, opened an early PR ^^ to see if this will fix the problem07:22
mvomborzecki: thank you07:22
mborzeckiok, talk to you later07:23
* zyga-solus -> quick late breakfast07:27
zyga-solussorry, kids were very stubborn today and were late for school07:27
ikeyoh, breakfast07:28
ikeynot a bad idea07:28
* zyga-solus eats what kids left behind ^_^07:29
* mvo shakes fist at nvidia driver, its in a gdm3 restart loop rightnow07:36
zyga-solusmvo: wrong driver07:37
zyga-solusmvo: did you install it just now or update?07:37
zyga-solusniemeyer: thank you!07:37
niemeyerzyga-solus: np, that part was easy :P07:37
mvozyga-solus: happend out of the blue which is very strange07:37
mvozyga-solus: when I started this morning07:38
zyga-solusmvo: woah07:38
zyga-soluscan you ssh into the machine?07:38
zyga-solussyslog has the details of why x cannot start07:38
zyga-solusfor me it had something like "bla bla bla, use legacy driver, bla bla bla"07:38
mvozyga-solus: yeah, it just says "nvidai: cannot load module", no worries, I will figure it out, its just super annoying07:41
zyga-solusI haven't seen that one07:41
mvozyga-solus: google is very light on it as well07:41
mvozyga-solus: going back to nvidia-340 "fixed" it07:43
zyga-solusmvo: from 37x?07:43
mvofrom 38407:43
zyga-solusmvo: woah, 2.29.3 has plenty of things that are not in master07:53
mvozyga-solus: yes07:53
mvozyga-solus: its very annoying, we need to fix this07:53
zyga-solusI see I will have some merges to do in the full udev hooks branch07:53
mvozyga-solus: should apply cleanly, no?07:54
zyga-solusmvo: not really, I did extra changes after jdstrand's desire to change formatting of udev rules07:54
zyga-solusmvo: mostly just annoying stuff in tests (extra comments and order changes)07:54
mvozyga-solus: but all on top of the exiting commits?07:54
zyga-solusbut that's ok07:54
zyga-solusthat should merge cleanly!07:54
zyga-solusI didn't think about that07:54
mvoyeah, fingers crossed :)07:54
zyga-solusI wonder why is travis so red today07:55
mvo50 open PRs, sounds like work today07:55
zyga-solusmvo: hmmm07:55
zyga-solusmvo: 2.29.3 has failing unit tests07:55
mvozyga-solus: there was a grub-editenv issue on fedora that ma looked into earlier07:55
mvozyga-solus: wuut?07:55
zyga-solusmvo: looks real :/07:55
zyga-solusmvo: https://s3.amazonaws.com/archive.travis-ci.org/jobs/299817751/log.txt?X-Amz-Expires=30&X-Amz-Date=20171110T075518Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171110/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=7dd8a954e140304cfb8fce57b546497414a8a6a4488ec760644b075ff5e54d2307:56
zyga-solusmvo: no idea how07:56
mvozyga-solus: hm, that build in the ppa so it can't be universal07:56
zyga-solusmvo: maybe ungreen PR was merged into 2.2907:56
* mvo looks07:56
mvozyga-solus: https://travis-ci.org/snapcore/snapd/branches show is green and beside fedora packaging its identical07:57
* mvo looks deeper07:57
zyga-solusvery confusing then07:57
zyga-solusmvo: let's see if I can reproduce07:57
zyga-solusmvo: yep07:59
zyga-solusreal failure07:59
zyga-soluslooking at which part is right07:59
mvozyga-solus: can you pastebin it please?07:59
mvozyga-solus: strange, just trying to reproduce (via git checkout upstream/release/2.29) it is ok for me, let me dig deeper08:01
zyga-soluslooks genuinely buggy08:01
zyga-solustest is right, code is wrong08:01
* zyga-solus wonders08:01
zyga-solusmaybe misaligned something08:01
zyga-solusI didn't do that08:01
zyga-solusI did mvo/release-2.29.308:01
zyga-solusI recall those usb interface number PRs were recent08:01
zyga-solusmaybe cross-merged badly08:02
mvozyga-solus: oh, indeed08:02
mvozyga-solus: that is probably it08:02
mvothere I see it as well08:02
zyga-solusikey: I plugged a 2nd monitor to my solus box and now the "dock" at the bottom overlaps windows08:02
* mvo recovers from a brief heart attack08:02
zyga-solusikey: is this a feature I'm not aware of08:03
zyga-solusmvo: wait, so what is in 2.29.3?08:03
zyga-solusmvo: because this is _pre_ merge08:03
zyga-solusmvo: (heart attack may need to come back)08:03
zyga-solusmvo: and this is not right for sure08:04
ikeyzyga-solus, mutter borkified all sane notions of reserved struts :(08:05
zyga-solusmvo: I pushed a patch to that PR08:10
zyga-solusmvo: please look08:10
mvozyga-solus: I just looked at https://github.com/snapcore/snapd/blob/release/2.29/interfaces/builtin/serial_port_test.go and the snippet4 is missing there, i.e. we don't test this condition08:10
zyga-solusmvo: but I'm worried how is this possible08:10
zyga-solusmvo: aha08:10
* ikey agrees with the C udev thingy fwiw08:11
zyga-solusmvo: can you look if the 2.29 release has the other usb-interface-num patches?08:11
zyga-solusis that a feature in this release?08:11
mvozyga-solus: so it looks like this was added in your PR for master later and not backported to 2.29 - does that mean that theere is also a fix missing?08:11
zyga-solusmvo: I don't recall adding that, it may have come from master08:11
mvozyga-solus: aha, it looks like 2.29 does not have the usb-interface-num, at least I can't find it in there08:12
zyga-solusmvo: let me look at the history to find this patch08:12
zyga-solusmvo: I see it in b2991126738db2e9bf041a5da014cadc436e5ae208:13
zyga-solusmvo: which is not in release/2.2908:13
mvozyga-solus: I did a "git grep usb-interface-n" in the release/2.29 tree and nothing there so it looks like we are good08:13
mvozyga-solus: all good then :)08:13
zyga-solusmvo: but how is it in 2.29.3 PR?08:13
zyga-solusmvo: if you released from that branch it's going to be bogus and will fail adt08:14
mvozyga-solus: its 2.29.3 plus master (to fix the conflicts, i.e. to make it mergable into master)08:14
mvozyga-solus: the release/2.29 branch does not contain this snippet, its a new test that was added in master but now fails with the udev snippet work for 2.2908:15
zyga-solusall good08:15
* ikey ponders how he'd go about stracing a process inside of a snap..08:20
zyga-soluswe need to add snap run --strace08:21
zyga-solusit's a common request08:21
zyga-solusit's not super easy unfortunately08:21
ikeydidn't you have some magical super invocation?08:21
* ikey searches forum08:22
zyga-solusno, because it requires doing a few steps08:22
zyga-solusthe profile of the app has to change to allow that08:22
ikeyah yep ive pissed it off08:22
ikeyok yeah need to exclude pselect6 too08:26
zyga-solusoh, nice, autopkgtests are gone now08:35
zyga-solusmvo: do we have a way to trigger them manually?08:35
mvozyga-solus: sort of, cachio is looking into it08:36
=== __chip__ is now known as Chipaca
mupPR snapd#4187 closed: tests: fix xdg-open-compat <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4187>08:58
mupPR snapd#4180 closed: interfaces/many: misc policy updates for browser-support, cups-control and network-status <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4180>09:05
ikeyanyone got experience with running chrome/cef stuff under snap?09:11
ikeyif i install with --classic - cef works (i.e. feral games like Hitman)09:11
ikeyyet if i use --devmode, it doesn't09:11
ikeyget execvp errors with empty argv[0]09:11
zyga-solusikey: no, sorry09:15
zyga-soluswhat is cef?09:15
ikeylike chrome-based apps09:15
ikeyspotify and such09:15
ikeyall have a libcef.so09:15
ikeyrelevant strace portion https://hastebin.com/raw/refijimafu09:16
* mborzecki is back09:16
* ikey can't help but notice the EPERM09:16
mupPR snapd#4157 closed: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4157>09:18
zyga-ubuntumvo: thank you for merging that test, I will merge master into the big udev branch now09:18
* ikey checks 4180 on the magical off chance it fixes the issue09:26
Chipacamborzecki: morning sir. What is, in your view, the plan for group lookup?09:32
pedronisniemeyer: hi and ack09:34
mvohey pedronis and Chipaca - good morning09:36
mvozyga-ubuntu: your udev PR looks fine, once tests are green it can go in I think09:36
niemeyerpedronis: yo09:36
pedronismvo: I though pstolowski requested some test tweaks for it in the 2.29 variant09:40
pedronis*I thought09:40
pstolowskifor which PR?09:41
mupPR snapd#3994 closed: tests: fix revert test when a new core image is pushed <Created by sergiocazzolato> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3994>09:41
mborzeckiChipaca: i'm not strongly biased against cgo (I suppose that's the real root of the problem), and with #4185 we have a fine chance of avoiding group lookups in the code that ends up in `snapd` binary09:41
mupPR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>09:41
Chipacamvo: good morning sir09:42
mborzeckiat this point what's left with cgo is snap-seccomp, and probably some tests, though I have some PRs open that try to workaround this09:42
pstolowskiah, udev pr09:42
Chipacamborzecki: i think cgo is only a potential problem in snapd, which is long-lived; the others shouldn't be as concerned09:42
Chipacamborzecki: so 4188 goes away?09:43
mupPR #4188: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>09:43
mborzeckii'd leave it open for now, and once the bits i needed are merged i'll close it09:44
mborzeckiChipaca: does that sound ok to you?09:46
Chipacamborzecki: i'm not sure what the purpose of leaving it open is if we're not going to merge it, but i don't mind too much09:46
pedronispstolowski: yes, I put a link to them in the non-2.29 one09:47
Chipacabeyond being in review sprint mode (ie reviews before code)09:47
Chipacamvo: what's up with #4122? two +1's and not merged. Just waiting for green?09:47
mupPR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>09:47
mborzeckiChipaca: fair point, let's close it for now then, we can always reopen it if needed09:47
pstolowskipedronis, thanks09:48
Chipacamborzecki: if i were to remove all uses of os/user and SnapDataHomeGlob in favour of a new thing, what would you need from the new thing?09:48
niemeyerChipaca, mborzecki: Avoiding cgo in snap-seccomp is probably impossible with the current design09:50
niemeyerAh, sorry, not seccomp09:50
mupPR snapd#4188 closed: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>09:50
niemeyerChipaca, mborzecki: Ah, and snap-seccomp too, for different reasons (libseccomp)09:51
Chipacaniemeyer: good morning to you too :-) have you even slept?09:51
niemeyerChipaca: Sorry, good morning :)09:51
Chipacaniemeyer: ah, i didn't mean it in that way, but it works :-D09:52
niemeyerChipaca: Yeah, I have.. went to bed earlier than usual yesterday, so started earlier today still, and will probably stop earlier too :)09:52
mborzeckiChipaca: i only needed looking up a group name using its gid, but we have a workaround for this now09:52
Chipacaniemeyer: fair enough09:52
niemeyerChipaca: Still wondering about the cgo issue..09:52
Chipacaniemeyer: pedronis has flagged you for some reviews i see, so you've got your work cut out :-)09:53
niemeyerChipaca: Yeah, we've got the review board too, not sure if you've seen the message earlier today09:53
niemeyerChipaca, mborzecki: As for cgo, I'm on the fence between suggesting dropping and making that interaction more awkward vs. the benefits09:54
niemeyerWe cannot drop glibc completely from the snapd environment due to the external tools we need09:54
niemeyerSo the sole benefit would be a more bullet proof snapd09:55
zyga-ubuntuniemeyer: yet :)09:55
zyga-ubuntuniemeyer: the apparmor_parser thing could run in a tiny tiny tiny base snap09:55
niemeyerzyga-ubuntu: Without further information that's a bit of wishful thinking09:55
Chipacaniemeyer: going down the review board is how i saw you flagged in some09:55
zyga-ubuntuniemeyer: yeah, just saying it's not ultimately impossible09:55
niemeyerzyga-ubuntu: Yeah, but we're not able to do that any time soon09:56
Chipacawe need glibc in the core snap anyway because otherwise we'd have to link systemd against musl or something equally undersupported by upstream systemd09:56
Chipacaso from that pov i don't see the benefit09:56
niemeyerChipaca: That's a bit of a different thing09:56
Chipacaok :-)09:56
niemeyerChipaca: systemd will be in the base09:56
Chipacaniemeyer: uh, no?09:57
niemeyerChipaca: uh, hopefully yes? :)09:57
Chipacaniemeyer: so you can't have more than one base?09:57
Chipacaor there is a base that's special and different?09:57
niemeyerChipaca: Consider this: which systemd is used when the host system is Ubuntu 16.0409:57
Chipacaniemeyer: not the one in the base09:58
niemeyerChipaca: Not the one in any snap09:58
niemeyerChipaca: Right.. so this is not actually a fundamental dependency of the snapd-carrying nsap09:59
Chipacaniemeyer: consider this: what systemd starts snapd in core?09:59
niemeyerChipaca: The one in the base ;)09:59
Chipacaniemeyer: which base?09:59
Chipacain a special base that's baser than the rest?09:59
mvothe base of the snapd snap09:59
niemeyerChipaca: Exactly.. I'm describing the goal09:59
Chipacathe snapd snap will have a base?10:00
Chipacaso we force solus to have a ubuntu 16 base even if none of their snaps use ubuntu 16?10:00
niemeyerChipaca, mvo: We can have a specific base snap that is the one mounted as the root filesystem on core devices10:00
Chipacano i got it10:00
mvoChipaca: yeah, maybe not, probably more something implicit10:01
Chipacaso snapd doesn't have a base, but ubuntu core is a special base10:01
Chipacafedora core would be a different special base10:01
Chipacasolus core would just be ikey, punching donkeys10:01
niemeyerChipaca: It might have a base, but it might not be the one that Ubuntu Core requires10:01
niemeyerChipaca: Not having a base might make the model simpler, though.. so this particular bit is one we still need to decide on10:02
niemeyerThe status quo of base snaps is that we did not yet do the split of core10:02
* mvo nods10:02
niemeyerThis is the second part, and it's independent of support for bases in app snaps10:02
Chipaca's fine, i think we've discussed this "some bases can be root of core some can't" before and i forgot it10:03
niemeyerSo we haven't yet firmly made such decisions, and we also haven't closed any of those doors yet10:03
niemeyerChipaca: Yeah, and np, the conversation is healthy10:03
zyga-ubuntumvo: hmm10:04
zyga-ubuntu● snap-repair.timer not-found failed failed snap-repair.timer10:04
zyga-ubuntumvo: this is from vanilla 16.04 install10:04
zyga-ubuntuwe're shipping the repair timer?10:04
zyga-ubuntuah, sorry, zesty10:04
zyga-ubuntuit seems we are10:04
zyga-ubuntumvo: is this really desirable?10:04
mvozyga-ubuntu: it is disabled, no?10:04
zyga-ubuntuit's failed10:04
zyga-ubuntunot disabled10:04
mvozyga-ubuntu: it makes packaging simpler, it has a condition10:04
Chipacazyga-ubuntu: systemctl status snap-repair.timer ?10:05
Chipacamvo: if you make it an assertion instead of a condition it works the same, but logs the reason10:05
zyga-ubuntuzyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.service10:05
zyga-ubuntu● snapd.snap-repair.service - Automatically fetch and run repair assertions10:05
zyga-ubuntu   Loaded: loaded (/lib/systemd/system/snapd.snap-repair.service; static; vendor preset: enabled)10:05
zyga-ubuntu   Active: inactive (dead)10:05
mvozyga-ubuntu: it should be in "condition failed" state which is not an error (even if it sounds like one)10:05
zyga-ubuntu     Docs: man:snap(1)10:05
zyga-ubuntuzyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.timer10:05
zyga-ubuntu● snapd.snap-repair.timer - Timer to automatically fetch and run repair assertions10:05
zyga-ubuntu   Loaded: loaded (/lib/systemd/system/snapd.snap-repair.timer; enabled; vendor preset: enabled)10:05
zyga-ubuntu   Active: inactive (dead)10:05
zyga-ubuntumvo: it's showing the machine as in degraded status10:05
mvoChipaca: aha, interessting10:05
mvozyga-ubuntu: could you please pastebin it? my irc client garbled it10:06
Chipacazyga-ubuntu: it's snap-repair.timer, not snapd.snap-repair.timer i think?10:06
mvozyga-ubuntu: it should not make the machine degraded10:06
Chipacaat least here it is -- which might mean my local install is messed up :-) dunno10:06
mvozyga-ubuntu: and systemctl --failed please10:07
Chipacazyga-ubuntu: systemctl list-timers10:07
mvozyga-ubuntu: aha, sorry you did that already10:07
mvozyga-ubuntu: it looks like you might have leftover files from an old deb?10:07
mvozyga-ubuntu: or maybe everyone has these (which would be bad)10:07
zyga-ubuntumvo: no, they are part of the package10:08
zyga-ubuntumvo: note: zesty10:08
zyga-ubuntumvo: this is my router, not devbox10:08
zyga-ubuntuso no locally built magic files10:08
zyga-ubuntuI just noticed because I'm about to shut it down10:08
mvozyga-ubuntu: interessting, let me try in a fresh vm. fwiw, I see the "expected" condition failed and nothing in systemctl --failed on my box (but its artful)10:09
mvozyga-ubuntu: or is this 2.27.6 still?10:09
Chipacastrange i seem to have a mix of snapd.snap-repair.timer and snap-repair.timer. Probably need a restart sometime soon?10:09
zyga-ubuntumvo: checking10:09
mvozyga-ubuntu: apt list snapd10:09
mvoyeah, let me try in my VM10:10
zyga-ubuntusnapd/zesty-updates,now 2.28.5+17.04 amd64 [zainstalowany]10:10
zyga-ubuntuzainstalowany is installed10:10
* zyga-ubuntu moves the final network part now, I'll be offline briefl10:11
zyga-ubu1tuactually not much10:11
=== zyga-ubu1tu is now known as zyga-ubuntu
mvozyga-ubuntu: fresh 17.04 does not have the issue, let me try if I upgrade from 2.27 to 2.2810:12
mvozyga-ubuntu: no luck with 2.27 -> 2.28 either on zesty. hmmm10:16
mupPR snapd#4202 opened: cmd: use a preinit_array function rather than parsing /proc/self/cmdline <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4202>10:18
Chipacajamesh: ouch! brand new pr with conflicts10:21
jameshChipaca: gar.  I thought I'd pulled master.  Let me rebase it10:24
Chipacajamesh: ta10:25
Chipacajdstrand: did i understand you right yesterday, that in #4185 we don't actually need the group name? ie g:<gid> works just as well as g:<group name>?10:29
mupPR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>10:29
mborzeckiChipaca: afaik it's g:<group-name> or <gid>10:30
jameshChipaca: fixed.10:30
Chipacamborzecki: ah. any reason not to do it that way?10:31
Chipacait doesn't buy us much, beyond not having to look up the name (i assume apparmor has to then look up the gid from the name again)10:32
Chipacaor seccomp10:32
Chipacajamesh: thanks10:32
Chipacajamesh: and good night :-)10:32
pedronisChipaca: we are the one compiling seccomp, I don't think it can do runtime group lookup I suspect (not sure)10:35
mvoyeah, seccomp bpf is not very smart at all :)10:36
mborzeckiChipaca: #4185 does that, the rule is sent as fchown u:root <gid>10:36
mupPR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>10:36
mborzeckiwe could push a little bit and use 'fchown 0 <gid>` as root user supposedly has uid 0 always10:37
Chipacamborzecki: gah, i got confused then, sorry10:37
mborzeckidamn, got an 'hr introduction' call in 1010:52
mupPR snapd#4178 closed: asserts/assertstest:  fix use of hardcoded value when the passed  or default keys should be used <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4178>10:58
mupPR snapd#4190 closed: cmd/snap-seccomp: do not use group 'shadow' in tests <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4190>11:08
mupPR snapd#4179 closed: tests:  add a spread test for proxy.store setting together with store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4179>11:09
mupPR snapd#4203 opened: tests/set-proxy-store: exclude ubuntu-core-16 via systems: key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4203>11:12
pedronismvo: I was about to do the change requests by cachio to #417911:13
mupPR #4179: tests:  add a spread test for proxy.store setting together with store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4179>11:13
mupPR snapd#4198 closed: release: 2.29.3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4198>11:13
pedronismvo: ah, you made a PR but there is more tor remove11:13
mvopedronis: uh, sorry11:14
mvopedronis: too trigger happy. shall I close my followup then?11:14
pedronismvo: no, let me try to push the proper fix into it11:14
mvopedronis: thank you!11:14
=== andreas is now known as ahasenack
pedronismvo: done11:19
mvopedronis: thanks again11:23
mvopstolowski: 4152 has two (optional) comments from me, I'm inclined to merge it as it is as its really nice but please check and either merge yourself or update11:32
pstolowskimvo, thanks for the review, if there is no pressure i'll address them later today. currently debugging some other issue11:34
mvopstolowski: no pressure at all11:34
zyga-ubuntumvo: hey11:46
zyga-ubuntumvo: I'm back, sorry, was fighting systemd11:46
mupPR snapd#4122 closed: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4122>11:47
zyga-ubuntumvo: I just noticed you worked on that huge conflict11:47
zyga-ubuntumvo: and pushed earlier than I did11:47
zyga-ubuntumvo: I just reslved the same conflicts11:47
mvozyga-ubuntu: hey, meh, I wanted to talk about it first but you not being on irc made me assume you are at lunch11:49
mvozyga-ubuntu: sorry for that11:49
zyga-ubuntumvo: no worries, sorry for dragging you into this11:51
zyga-ubuntumvo: I painfully found out which features are not enabled in systemd in xenial11:51
mvozyga-ubuntu: uh, what is missing?11:51
zyga-ubuntumvo: lunch sounds like a good idea but I have to go out to eat something11:51
zyga-ubuntumvo: iptables11:51
zyga-ubuntumvo: I'm building a local version that supports that11:51
zyga-ubuntumvo: I moved my router from old PC to smaller old PC and decided to stick to LTS11:52
zyga-ubuntumvo: and network routing broke11:52
zyga-ubuntuin the end I found a thread where debian disabled this to save 3500KB11:52
mvooh, woah11:52
zyga-ubuntuit was fixed later and that's why it worked on zesty11:53
zyga-ubuntu(this lets me remove a cable that runs across the house)11:53
zyga-ubuntuwell, hopefulyl11:53
zyga-ubuntuit's building11:53
mupPR snapd#4189 closed: interfaces/builtin/lxd_support: allow discovering of host's os-release <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4189>11:57
mupPR snapd#4159 closed: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4159>12:03
mupPR snapd#4200 closed: daemon,overlord/snapstate: return snap-not-installed error in more cases <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4200>12:08
pstolowskimvo, pedronis can you take another look at #4177?12:12
mupPR #4177: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177>12:12
zyga-ubuntumborzecki: https://github.com/snapcore/snapd/pull/4201 ?12:14
mupPR #4201: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4201>12:14
cachiomvo, hey12:16
cachiodid you see the email I sent yesterday?12:16
mborzeckizyga-ubuntu: can you take a look at https://github.com/bboozzoo/snapd/commits/bboozzoo/tests-grub-editenv-wip ? i haven't pushed the last 3 commits for review yet though12:17
mborzeckibasically replaces `$GRUB_EDITENV list` with `bootenv` as the latter is supposed to dump bootloader env12:18
zyga-ubuntumborzecki: aha, thanks12:19
* Chipaca ~> lunch12:20
pstolowskizyga-ubuntu, can you take another look at #4152 ?12:23
mupPR #4152: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152>12:23
zyga-ubuntupstolowski: I merged and de-conflicted https://github.com/snapcore/snapd/pull/412012:25
mupPR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>12:25
zyga-ubuntupstolowski: I'll merge udev hook fixes as well but won't push until that lands in master12:25
zyga-ubuntupstolowski: then I'll look at cookies12:25
pstolowskizyga-ubuntu, thanks for pushing 4120!12:29
zyga-ubuntupstolowski: let's land fix/udev-hooks first, I already merged the de-conflicted version locally so that it will let your PR land without conflicts soon thereafter12:30
mborzeckipstolowski: https://github.com/snapcore/snapd/pull/4191#pullrequestreview-75471258 not sure I follow, there is no quick return path in XSnapdGID in this case12:30
mupPR #4191: cmd/snap-update-ns: do not assume 'nogroup' exists <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4191>12:30
pstolowskimborzecki, yeah, co my concern is if you change XSnapGID function to match on some other x-snapd string by mistake, you will hit the quick return path instead and test will be happy12:32
pstolowskiroot is just kinda special12:33
mborzeckiok, i see what you mean12:33
pstolowskiin other words, we don't know if we hit the right code path if we ask for roo12:34
pstolowskizyga-ubuntu, do you need anything from me re udev? I think i approved your PRs12:35
zyga-ubuntupstolowski: I think we are waiting for tests now12:36
zyga-ubuntupstolowski: today is a review day, I'll do as little coding as I can :)12:36
pstolowskimborzecki, any other common user we could rely on in this test?12:37
mborzeckino, don't think so12:37
mborzeckiwe need a well known gid12:37
mborzeckiotoh, it's just a test, there should be no harm in calling osutil.FindGid()12:39
mborzeckiso if we'd rather not use 'root' there, we'll just have to try nogroup and nobody and fine which one exists12:39
zyga-ubuntumy daughter forgot her towel at the swimming pool at school12:41
pstolowskizyga-ubuntu, my daughter is notorius for forgetting stuff at school ;). happy seeking12:45
pstolowskimborzecki, commented on xsnapgid PR12:53
mborzeckipstolowski: thanks, right, i've cherry picked 2 commits, missed a 3rd one :/12:56
pstolowskigood ;)12:57
Chipacaniemeyer: stand up13:01
Chipacapedronis: you too13:02
=== JoshStrobl is now known as JoshStrobl|Store
niemeyerChipaca: Trying to join13:03
niemeyer(and not working)13:03
mborzeckipstolowski: pushed a fix, hopefully a last one :)13:04
mborzeckipstolowski: thanks for the review13:08
zyga-ubuntu[   30.633917] audit: type=1400 audit(1489520905.019:12): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/dev/urandom" pid=1508 comm="5" requested_mask="r" denied_mask="r" fsuid=0 ouid=013:10
pstolowskimborzecki, yw13:10
diddledanooh ooh ooh. I got gimp beta compiled13:15
mupPR snapd#4192 closed: osutil: add helper for obtaining group ID of given file path <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4192>13:18
mupPR snapd#4149 closed: tests: new tests for network setup control and observe interfaces <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4149>13:19
zyga-ubuntuniemeyer: https://forum.snapcraft.io/t/systemd-in-ubuntu-16-04-core-snap-doesnt-support-iptables/276813:19
jdstrandChipaca: what I said yesterday is one can use '<gid>' (note, no 'g;') can be used instead of 'g:<group>'13:22
Chipacajdstrand: yeah, mborzecki cleared me up on that, thank you13:22
mupPR snapd#4203 closed: tests/set-proxy-store: exclude ubuntu-core-16 via systems: key <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4203>13:28
pedronismvo: do we have stuff that can be untagged in your upcoming,  or it's all still in progress for 2.29?13:49
pedronis*do you13:49
mvopedronis: let me check13:52
Chipacaniemeyer: could you re-run the review sprint generating script magic thing?13:56
Chipacaniemeyer: (assuming it's cheap for you to do so)13:56
* Chipaca <- lazy13:56
niemeyerChipaca: Of course, churning right now13:56
niemeyerChipaca: Done13:57
mupPR snapd#4144 closed: interfaces: fix udev tagging for hooks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4144>14:01
zyga-ubuntupstolowski: pushed, can you look at https://github.com/snapcore/snapd/pull/4120/files to ensure it's sane14:04
mupPR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>14:04
zyga-ubuntujdstrand: I need 2nd review for https://github.com/snapcore/snapd/pull/416314:05
mupPR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>14:05
pstolowskizyga-ubuntu, will do14:05
zyga-ubuntupstolowski: and some comments on https://github.com/snapcore/snapd/pull/410814:06
mupPR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>14:06
mupPR snapd#4129 closed: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4129>14:06
pstolowskizyga-ubuntu, thank you for both14:08
pedronismvo: did you remove some mvo tags but not the upcoming tag ?  or I'm just confused14:08
zyga-ubuntumvo: some failures to address here https://github.com/snapcore/snapd/pull/406314:08
mupPR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>14:08
zyga-ubuntuChipaca: it's Frida14:08
Chipacayaml's support for sexagesimal numbers is awesome14:08
mvopedronis: meh, sorry, wrong way around, I need a cup of tea I think14:08
zyga-ubuntuChipaca: cannot be that bad14:08
pedronismvo: seems so :)14:09
pedronisit's probably me but I feel we have realistically too many things marked as upcoming14:09
pedronisor upcoming means in the next 6 month, which maybe is ok, but then we need one more tag or something14:10
zyga-ubuntubuilding systemd on atom is ... painful14:10
mborzeckianythin on atom is painful14:11
mborzeckiit's a broken CPU to begin with14:11
Chipacamborzecki: how so?14:12
zyga-ubuntumborzecki: it's not very superscalar AFAIR, like old ARMs14:13
Chipacamvo: is #4049 on your plate, or should i pester somebody else?14:13
mupPR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>14:13
mvoChipaca: me but I'm currently busy and can only look at it next week again14:14
Chipacamvo: ¯\_(ツ)_/¯14:14
Chipacamvo: for the record, i'm fine with that :-)14:14
pedronispstolowski: are install/remove hooks in 2.29 or 2.28 ?14:15
mborzeckizyga-ubuntu: never lived up to the hype, the only advantage bing a familiar instruction set, but performance and power consumption wise it's not very appealing14:16
zyga-ubuntumborzecki: no disagreements there :)14:17
mborzeckicould have been worse though, recall quarks :P14:17
zyga-ubuntumborzecki: quarks aka, that thing running inside ME14:17
mborzeckithis was a nice addition to the gallery of SoC oddities: https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug14:18
mborzeckiiirc that's why they were stuck with some ancient kernels too14:19
pstolowskipedronis, yes, they landed in 2.2714:19
zyga-ubuntumborzecki: not cute embedded nonsense hacks (aka intel)14:20
mborzeckithis is new 'Cannot allocate linode:opensuse-42.2-64: no powered off servers in Linode account exceed halt-timeout'14:21
zyga-ubuntumborzecki: EAGAIN14:22
zyga-ubuntutoo many things in flihg14:23
sergiusenshello everyone! Just getting started here, rough night last night14:23
zyga-ubuntusergiusens: he14:23
zyga-ubuntusergiusens: what's happened?14:23
sergiusenszyga-ubuntu food sickness...14:25
zyga-ubuntusergiusens: ouch, I'm sorry14:26
sergiusensstlll dealing with it, but I now have the energy to get up14:26
sergiusensyeah, me too :-P14:26
cachiomvo, https://paste.ubuntu.com/25932196/14:29
cachiothis is what I see after refresh on db14:29
cachiothe dmesg is the same I sent before14:31
mvocachio: this is very strange "Mar 14 19:48:44 localhost.localdomain systemd[1]: Stopping Snappy daemon...". it almost looks like something outside is stopping snapd on purpose14:34
cachiomvo, I ran the test suite to reproduce it14:36
cachioI could make it manual14:36
pedronispstolowski: we don't have pre-refresh, right?14:36
cachiothe suite is the not stopping it14:36
pedronispstolowski: is it planned?14:36
cachioan it is the same suite we run for pi2 and 314:36
cachiomvo, perhaps it is a problem in the this old stable image14:37
pstolowskipedronis, correct, we don't have it. i've it implemented but got stuck on that issue we discussed on the last sprint where I'm getting tasks in wrong order in the test14:38
jdstrandzyga-ubuntu: ack14:39
pstolowskii've spent a good chunk of time looking at it during the sprint but didn't get to the bottom14:39
zyga-ubuntujdstrand: thank you :)14:39
zyga-ubuntujdstrand: that's just a refactor but I wanted to make sure you see it14:39
jdstrandzyga-ubuntu: this isn't for 2.29, right?14:39
zyga-ubuntujdstrand: no, for master14:40
zyga-ubuntujdstrand: 2.29.x is closed I think (yay)14:40
zyga-ubuntujdstrand: there's also a PR on top that explains why this refactor is needed14:40
zyga-ubuntu(or useful)14:40
pedronispstolowski: is something you will look at again at some point?14:40
mupPR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>14:40
pstolowskipedronis, yes14:41
jdstrandzyga-ubuntu: ok. fyi, I have a couple things ahead of it to clear my desk for these reviews. possible I won't review til monday, but I'll try for today14:41
jdstrandzyga-ubuntu: I've been collecting your requests. 4163, 4166, 4169 and 417014:42
zyga-ubuntujdstrand: thank you, we are trying to close the review sprint (well, eventually, not today) and getting those refactors merged would unblock me on more features :)14:42
jdstrandzyga-ubuntu: are there others I should add to the list for next week or just wait for you to ping me?14:42
=== JoshStrobl|Store is now known as JoshStrobl
* kalikiana hopping on a train, back in a bit14:43
zyga-ubuntujdstrand: no, that's the only one, next week is fine14:43
zyga-ubuntukalikiana: stay safe :)14:43
kalikianazyga-ubuntu: Always. I sit on the roof of the car so nothing inside can harm me :-P14:44
* zyga-ubuntu would not be surprised14:45
zyga-ubuntumborzecki: https://forum.snapcraft.io/t/brave-and-other-apps-dont-launch-on-arch/2770/214:49
zyga-ubuntumborzecki: something for you :)14:49
mupPR core#63 opened: 25-create-generic-initrd.chroot: use symlink instead of copy <Created by mvo5> <https://github.com/snapcore/core/pull/63>14:55
zyga-ubuntumborzecki: one more review on https://github.com/snapcore/snapd/pull/418514:55
mupPR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>14:55
elopiojdstrand: thanks a lot for your comments in the classic request. I have a question, if I run the yarn snap as classic, is it the same as if I download a yarn binary and run it with sudo?14:55
mvocachio: sorry for the delay. maybe, what is confusing to me is is that it looks like something stoped snapd via systemctl stop. there is no setup magic somewhere in our scripts that does that and just forgot to start it again?14:56
zyga-ubuntumvo: review for yuor core pr14:57
zyga-ubuntuconflict on https://github.com/snapcore/core/pull/5814:57
mupPR core#58: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>14:57
sergiusensmariogrip added a testing bit to your PR snapcraft#172314:57
mupPR snapcraft#1723: sources: workaround for ZipFile.extractall not preserving permissions <Created by mariogrip> <https://github.com/snapcore/snapcraft/pull/1723>14:57
sergiusenselopio care to take a look? ^14:57
cachiomvo, I just executed manually and made the reboot manually and snapd service was running after that the14:58
cachionow I am leaving that to autoreboot to see14:58
cachiomvo, I'll have results in 10 minutes15:00
cachioif it works I'll make the promotion15:00
mvocachio: thank you15:00
mvozyga-ubuntu: heh15:01
mvozyga-ubuntu: so the snapctl internal configure-core15:01
mvozyga-ubuntu: will be changed to "rm -f"15:01
mvozyga-ubuntu: because we now really do the configure internally15:01
zyga-ubuntumvo: good :)15:02
zyga-ubunturm -rf on snap set harakiri15:02
mupPR snapd#4197 closed: cmd/snap-confine: Support bash as base runtime entry <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4197>15:11
Chipacaniemeyer: in spread, is SPREAD_REBOOT reset when entering the debug shell?15:19
cachiomvo, core 2.29.3 promoted to candidate15:20
mvocachio: yay, thank you15:20
cachiomvo, now we just need confirmation from qa15:21
cachiohopefully on monday we willl be ready15:21
cachioto go to stable15:21
niemeyerChipaca: Yes, the reboot loop happens entirely inside the client abstraction, which means any snippet at all can reboot, and it also means we can't hook into intermediate state15:22
zyga-ubuntuI cannot believe my machine is _still_ building systemd15:24
zyga-ubuntumborzecki: +1, thanks :)15:26
zyga-ubuntumborzecki: not sure which snaps you have installed but the more you have the better testing we get15:26
Chipacamvo: question for you about #4063: was there anything you expected of pc-kernel storeside for it to pass?15:26
mupPR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>15:26
zyga-ubuntumborzecki: I'm always using telegram as my 1st snap on any system15:26
Chipacamvo: i mean: seems like it'd need different kernels in edge and stable, and that's not the case15:26
zyga-ubuntumborzecki: I'm also using ohmygiraffe for casual GL-works tests15:27
Chipacazyga-ubuntu: strange, for most people it's 'core'15:27
mborzeckinode-red and brave seem to work :) (where work means starts and either a window shows up or i can connect to some web ui)15:27
zyga-ubuntuChipaca: nah, you just have to be very quick15:27
zyga-ubuntuChipaca: or have autofire on your keyboard15:27
mvoChipaca: yes, it needs that (the test) and it was the case sme days ago :/15:27
mvoChipaca: thanks for this feedback15:27
Chipacamvo: yeah, now they're all the same :-/15:28
mborzeckizyga-ubuntu: ohmygiraffe looks like fun15:29
mborzeckino warnings/erorrs popup with LIBGL_DEBUG15:31
zyga-ubuntumborzecki: nice :)15:31
elopiopopey or flexiondotorg: can you please fork this into snapcrafters? https://github.com/elopio/yarn15:32
mvopedronis: the new configure-snapd task has an interessting twist (regarding backwards compat): https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774/115:33
mvoChipaca: its something I will contemplate on monday I think15:34
pedronismvo: ok15:34
mvopedronis: looks like we need to think a bit about a fix before doing 2.3015:35
mvopedronis: I will make a cup of tea and ponder a bit15:36
pedronisit's a bit of a general problem, I mean we need to solve it here but I think we never thought true what unknown tasks means vs revert15:36
pedronis*thought through15:36
mvopedronis: yeah, very good point15:37
zyga-ubuntumborzecki: more posts about arch from popey15:39
pedronismvo: anyway is the last thing the revert needs to do, no?15:39
popeyelopio: doing now15:39
zyga-ubuntupopey: thank you for reporting those!15:39
zyga-ubuntupopey: I think we need to be really loud about the new package15:40
pedronismvo: after a week the change will go away, but you cannot do anything with core in that week15:40
zyga-ubuntupopey: and if we cannot update the community package, burn it with fire15:40
popeyzyga-ubuntu: totally, assuming it works :D15:40
popeyare you saying it's _impossible_ to update the existing snapd package?15:41
popeyThat seems like Arch is designed for Awesome.15:41
mborzeckipopey: did you manage to build the package?15:42
zyga-ubuntupopey: last time I looked the package was abandoned15:42
popeymborzecki: i haven't tried yet.15:42
zyga-ubuntupopey: and to even remark that we need a monthly process initiated by a trusted user15:42
popeyalso had to fix my suse install which broke when I updated it :(15:42
zyga-ubuntupopey: and then more time to maybe replace the package15:42
mborzeckifwiw, trying to install nextcloud now15:42
zyga-ubuntupopey: flexiondotorg knows more15:42
zyga-ubuntupopey: yeah, I noticed15:42
zyga-ubuntupopey: I killed that snapper tool (whatever it does) as I ran out of space myself15:43
popeyelopio: https://github.com/snapcrafters/yarn15:43
popeyelopio: do we need to get the name moved over in the store? If so, can you request it>15:44
popeygah, ?15:44
niemeyerpstolowski: #4108 reviewed15:47
mupPR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>15:47
mborzeckiuhh nextcloud, php-fpm, redis, mysql, apache, omg15:47
niemeyerpstolowski: Let me know if you want to talk about it so you're unblocked15:47
elopiopopey: yes, I will request the transfer. But wanted to wait on the classic assignment first.15:48
elopiothere's a bit of discussion there.15:48
popeyok, great15:49
mvopedronis: its revert and refresh. yeah, things will heal after a week which is great15:49
pstolowskiniemeyer, thanks for the review!15:50
pedronismvo: mmh, it will be aborted first which will undo the revert, that's not great15:51
niemeyerpstolowski: np15:51
pedronismvo: why are we getting a revert btw?15:51
mvopedronis: we are not getting a revert, sorry, my post is not clear about this. it just hangs forever on refresh/revert when the configure-snapd task is there15:51
pedronismvo: it hanges on refresh?15:52
pedroniswhy does it hang on refresh?15:52
mvopedronis: when going from a snapd that add the configure-snapd task to a snapd that does not understand this task after the reboot (second phase of security setup) the task will be in "Do" state but never run by the "old" snapd because it does not know what to do with it (c.f.  https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting )15:53
mvopedronis: so what happend was that edge had a core with configure-snapd support, the snapd 2.29.3 got built which does not know about configure-snapd but landed in edge15:54
mvopedronis: so people refreshing during the time that 2.29.3 was in edge and had a 2.29+git version with configure core strange things happend15:54
pedronismvo: ah, it's a strange case15:55
mvopedronis: does that vaguely make sense?15:55
niemeyerIt does :(15:55
mvopedronis: but its also happening when doing "sudo snap refresh --edge; sudo snap refresh --candiate" for core15:55
pedronisyes, I understand15:55
mvopedronis: just wanted to share it with you, its not omg-criticial as so far only edge is affected but but :)15:56
pedronisas I said we have a concrete problem but also a general question here15:56
=== JanC is now known as Guest54856
pedronisit's also an internal design thing, because we have many taskrunners, nothing really takes care of tasks that aren't registered by anything15:57
zyga-ubuntupedronis: maybe we need a sanity check "manager" that aborts unclaimed tasks in some way?16:02
mborzeckizyga-ubuntu: https://github.com/snapcore/snapd/pull/4185#discussion_r150254354 'internal' as in do it in init(), keep the error around and return it in SecCompConnectedPlut or just panic() in init()?16:04
mupPR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>16:04
zyga-ubuntumborzecki: returning the error feels better16:05
zyga-ubuntumborzecki: panic can bring down snapd in cases we may not want to16:05
ppisatisergiusens: any ETA for 2.35?16:06
zyga-ubuntusergiusens: we should plan to sync numbers :)16:08
zyga-ubuntusergiusens: it'd be awesome if snapd and snapcraft were in sync16:08
zyga-ubu1tusystemd built :D16:10
* zyga-ubu1tu EODs for now, I'll push one more PR for layouts but I need to eat something first :)16:12
niemeyerpedronis, mvo: And that's a bit by design.. there are three things we can do: ignore, fail, or wait16:17
niemeyerIgnore feels like a non-starter16:18
pedronisyea, it's not clear what we should do16:18
pedronisat the moment basically we chose fail (just slowly)16:18
niemeyerFail is probably the best option16:18
niemeyerpedronis: We choose wait..16:18
niemeyerpedronis: Fail after a week16:18
pedroniswell the task will be aborted16:18
niemeyerYeah, but after a week, which for human purposes is really waiting16:19
pedronisno, abort is 24h16:19
pedronisI think16:19
pedronisprune is a week16:19
niemeyerIt's the opposite.. pruning is faster than aborting16:19
niemeyerIIRC at least16:19
pedronisah, yes, sorry16:19
* pedronis is doing too many things at the same time16:20
niemeyerWe'll require some more info to change this, though..16:21
niemeyerAs task runners are really an independent thing today16:21
niemeyerIOW, there's no global knowledge of all handlers available16:21
pedronisthere's no global registry of all known task kinds16:22
niemeyerWe might cheat and track at a package level every known handler16:22
niemeyerand only abort those16:22
niemeyerThat might be cheap16:22
niemeyeronly abort those not known at all, obviously16:22
niemeyerThere is a bit of danger in doing even that, though, as it becomes racy16:23
niemeyerAnother option that might be cheap and saner is timing out based on how long the task is waiting to run without an available handler16:24
niemeyerIOW, try to run it, if there's no handler right now, abort it right away or after N minutes/hours16:26
niemeyerAgain, a bit of care needs to be taken as we've never been worrying about delays between the main loop running and the handler being available16:26
niemeyerSince we wait..16:27
niemeyermvo, pedronis: So.. do we need to do something right now?16:27
mvoniemeyer: I think we need something for 2.30, I think it would be unfortunate if "snap revert core" would basilcy force a 24h wait until the task times out (and then it would undo the revert)16:31
mvo(or am I missing something?)16:31
niemeyermvo: You are missing that it's actually a week.. :D16:31
mvoniemeyer: *cough* thats not making it better ;)16:32
mvoniemeyer: the other thing is that 2.29 cannot be retro-fitted with whatever we come up with16:32
niemeyermvo: Exactly what I was thinking..16:33
mvoniemeyer: I mean, ideally whatever we do would work on a previous snapd :/16:33
niemeyermvo: Even if we change the behavior of 2.30, that won't be fixed unless we get away with the new task altogether16:33
mvoniemeyer: indeed16:33
niemeyermvo: Oh, kind of16:34
* mvo listens16:34
niemeyermvo: Where is the new task being introduced? 2.30?16:34
mvoniemeyer: correct16:34
mvoniemeyer: 2.29.3+git to be pedantic16:34
niemeyermvo: So only tasks generated in 2.30 would present the issue16:35
mvoniemeyer: yes16:35
niemeyermvo: That means an explicit revert of the update itself would not present the issue, at least16:35
mvoniemeyer: yes, from 2.30 we could revert/refresh and generate appropriate tasks, i.e. if we know we go backwards we could DTRT16:36
niemeyermvo: Right.. we might actually change the behavior of snapd so that we never generate configure-snapd on operations of core itself16:37
niemeyermvo: As it's a bit silly anyway16:37
niemeyermvo: We can always reconfigure the core because.. well.. the code is running in the first place :)16:38
mvoniemeyer: heh, I see (I think)16:39
mvoniemeyer: so refresh/revert etc does not generate configure-core tasks. but when snapd starts it does the configure automatically every time? and of course snap set core would trigger the task, did I get this right?16:39
mborzeckiok guys, i need to wrap it up for today16:40
mborzeckienjoy your weekend everyone16:40
niemeyermvo: We may not even trigger the configure automatically for now16:41
niemeyermvo: We literally have the actual code running.. we can always fix data or do whatever else live in the appropriate places16:41
niemeyermvo: Instead of expecting ourselves to call ourselves to reconfigure16:42
niemeyermvo: Sounds like a win in terms of stability, overall, given our experience in core to core updates16:42
mvoniemeyer: I was thinking pushing it into a task is nice as its observable from the outside and it may take some seconds to run potentially at least16:42
mvoniemeyer: but yeah, happy to go taskless :)16:42
niemeyermvo: But what exactly is observable? :)16:43
pedroniswell  snap set needs a task because of the API16:43
niemeyerpedronis: Yeah, no changes there16:43
niemeyerpedronis: This is specifically about snap operations on snapd16:44
niemeyerOr core, for now16:44
mvoniemeyer: I think you are right, we don't really do anything in corecfg.Run() that takes time. I was thinking it might be nice to be able to see that configure core is hanging16:47
mvoniemeyer: but it should never do that and we can internally add safety for that16:47
mvoniemeyer: I like the outcome! will you followup in the forum or shall I try to summarize?16:48
niemeyermvo: Yeah, and if there's no configure core, we won't ever see it hanging :P16:48
niemeyermvo: I mean unless you really want it.. we can always add a sleep like the old days..16:49
* niemeyer still remembers of a previous life where folks added a sleep to slow down rsync, on customer request16:50
niemeyer*inside* rsync16:50
niemeyermvo: Do we have a topic for this already?16:51
mvoniemeyer: yes https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/277416:51
mvoniemeyer: we found it because ondra actually hit the issue16:51
niemeyermvo: I'm summarizing the preliminary discussion and agreements16:52
pedronismvo: I thought we were requesting "base" to the store, is that not the case yet?16:53
mvoniemeyer: brilliant,thank you16:53
mvopedronis: I thought so as well, I even downloaded some bases16:54
mvopedronis: eh, uploaded16:54
pedronismvo: I don't see it in the code16:54
mvopedronis: in our code?16:54
pedronismvo: sorry, I mean the field, not the type16:55
pedronismvo: did you implement the bits needing it, but didn't add the store/ parts yet?16:56
mvopedronis: it looks like it, let me look at the details16:58
niemeyermvo, pedronis: Hopefully I captured it well17:02
pedroniswe need to be a bit careful with firstboot code17:10
=== nacc_ is now known as nacc
pedronisI added a note in the topic17:12
ikeyso ehm17:16
ikeyhow would i go about publishing snaps and controlling channels17:16
ikeywithout snapcraft?17:16
* ikey would like to get his snaps out for edge testing this weekend17:17
Chipacaikey: you should be able to do most of it via the web as well i think17:19
niemeyerikey: snapcraft is just calling the store APIs, but we have no docs for that.. and those APIs are also a bit ancient so please don't expect a polished API at this time17:19
Chipacaikey: you used to, but i haven't checked if that's changed17:19
ikeybut snapcraft is unusable for me17:19
ikeyand i aint switching to ubuntu just to use it17:19
niemeyerikey: You can build the snap without snapcraft, and use snapcraft just to push it17:19
ikeyi built it without snapcraft17:20
mupBug #1731478: Snap of snapcraft fails to run on Solus and openSUSE <Snapcraft:New> <https://launchpad.net/bugs/1731478>17:20
niemeyerikey: Yeah, so you can just snapcraft push17:20
ikeyain't that easy17:20
ikeyits hardwired to debuntu17:20
Chipacaniemeyer: snapcraft won't start for him (see bug)17:20
Chipacaikey: i expect that to get fixed soonish, but, have you tried the web?17:20
ikeyi haven't17:20
ikeyniemeyer, solus != ubuntu17:21
Chipacaikey: dashboard.snapcraft.io17:21
niemeyerikey: I know, I just didn't expect snapcraft to be unable to work at all17:21
ikeyoh lol17:21
ikey"This should be a snap for Ubuntu Core; upload will begin as soon as a valid file is selected."17:21
niemeyernessita: ^17:22
ikeyoh thats another thing btw17:22
ikeysnapd absolutely mandates the presence of core17:22
ikeyeven if you don't need it17:22
ikeyso if you install solus-runtime-gaming you have to install core17:22
Chipacaikey: with bases, we're going to split core into actual core and an ubuntu base, and then things will be happier17:23
Chipacaikey: still on our TODO though17:23
ikeyright but i mean - it still won't need any kind of core17:23
niemeyerikey: That traceback seem related to snapcraft being run in packaging mode17:23
niemeyerikey: Is snapcraft push --help working for you?17:23
Chipacaikey: at that point you still need core, to have snapd inside snaps, but you dont need the rest17:23
ikeywe dont support reexec on solus17:23
ikeyso we don't actually need core17:23
Chipacaikey: ah17:24
ikeyits a subtle nuance but i figured id bring it up :)17:24
ikeyniemeyer, https://hastebin.com/vaparusuha.sql17:24
Chipacaikey: well, it'll get at least a little better when we split core, even if we continue to pretend everybody reexecs17:24
ikeyeven --help doesn't work17:24
ikeyChipaca, sure17:24
Chipacabut, fair point17:25
ikeyon the plus side:17:25
niemeyerikey: Have you tried to just comment out apt_pkg.init()?17:26
ikeyits in a ready only snap17:26
ikeythink about it :p17:26
niemeyerikey: mount --bind?17:26
* ikey blinks17:27
ikeyits a .snap file17:27
ikeyread only squashfs17:27
niemeyerikey: You can bind mount a file into a read-only file17:27
sergiusensikey your bug should be fixed in 2.3617:27
ikeyniemeyer, im not sure you're following here17:27
ikeythe snap is already read-only17:27
ikeyi can't edit the files inside it17:27
ikeythe only way for me to "fix" this is to manually install snapcraft17:27
niemeyerikey: You can literally bind mount a file into a mounted read-only filesystem17:27
niemeyerikey: It doesn't matter if it's zfs or squashfs17:28
ikeystill not getting it17:28
niemeyerikey: Okay, nm.. 2.36 sounds like an easier target.. :)17:28
ikeyi dont have any of the debian support17:28
ikeyso apt_pkg.init is just one call im gonna have to fart with17:28
niemeyerikey: snapcraft should not need any debian support at all to push a snap17:28
ikeythats deep in debian/debian_support.py17:28
ikeyi know :P17:28
niemeyerikey: It sounds like a silly leftover initialization that shouldn't be running until obviously necessary17:29
niemeyer(and which is already fixed)17:29
ikeyis there an edge snap i can move to? :P17:29
ikeyah crap17:29
ikeyim on edge17:29
niemeyersnap info snapcraft says 2.3417:29
niemeyersergiusens: How come?17:29
sergiusensniemeyer changing that legacy choice is a refactor away17:30
niemeyersergiusens: No snapcraft edge?17:30
sergiusenswait, what?17:30
niemeyersergiusens: Yeah?17:32
sergiusensikey wth, we are delayed with the release on the wait of the 40 4 hour each snapd tests on adt; I'll just fix it now17:32
niemeyersergiusens: None of those 2.34 look like 2.36..? :)17:32
niemeyersergiusens: Any reason why edge releases aren't happening daily automatically?17:33
sergiusensniemeyer they happen daily17:33
niemeyersergiusens: That's not 2.36..17:35
sergiusensno, no code for 2.36 exists in a merged state17:35
sergiusenswe don't branch out like you guys do17:35
niemeyersergiusens: I'm clearly missing something.. what do you release daily on edge then?17:36
sergiusensniemeyer master17:36
niemeyersergiusens: Sure.. but clearly master doesn't contain the new things that are being merged..?17:36
sergiusensniemeyer it exactly contains that17:37
=== CodeMouse92 is now known as CodeMouse92__
niemeyersergiusens: Okay, I misunderstood what you meant all along then17:37
niemeyersergiusens: There's no 2.36 release, and there's no fix yet17:37
sergiusensoh, I said I would fix it for 2.36, not that it is fixed in 2.36 :-)17:38
niemeyersergiusens: You actually said it should be fixed in 2.36, and both me and ikey went looking for that17:38
* ikey grins at confuzzlement17:39
ikeywhile reading up on opengl apis -_-17:39
niemeyerAnyway, we understand it now..17:39
sergiusensah, should is a vague word I used; should (pun) have said shall17:39
ikeyfriday, right.17:39
niemeyersergiusens: "will" is the one you're looking for :)17:40
sergiusenswill also works17:40
cjwatsonikey: it would work if apt_pkg were entirely absent, just not when present but broken17:41
* ikey blinks17:41
ikeyi don't have any kind of apt_pkg17:41
cjwatsonI guess it must be in the snapcraft snap17:41
cjwatsonI'm mostly just vocalising my "hmm, I was sure apt_pkg was optional in python-debian" train of thought17:42
ikeyin theory apt_pkg is present in a broken state17:42
ikeybecause of "missing /etc/apt.d"17:42
ikeyor apt/something.d i dk17:42
ikeyi haven't deb'd in a long time :p17:42
niemeyerikey: One possibility is grabbing the snapcraft source code and yanking half of its logic until push works.. in theory push should really not care about anything about the host system at all.. only the snap file is relevant17:44
ikeythat certainly is one possibility17:44
ikeyone id rather avoid17:44
ikeygetting python out of all the nooks on your system again after is like tryna get bird cack out of your hair17:44
ikeyyou just know its still there somewhere17:44
ikeyand id rather follow the snap package in future, without host conflicts17:45
niemeyerikey: If the web works, that's the easiest.. otherwise spending 5-10 minutes on this might be fruitful.. even more considering you know the upstream will fix the issue for you soon17:45
ikey(y'all can keep that mental image for free)17:45
niemeyerikey: Haha, yeah17:45
ikeywhat does series 16 mean on the dashboard..?17:45
sergiusensikey you shouldn't need apt at all; this is related to an if 'linux' as a whole17:46
Chipacaikey: how about this: grab the snapcraft .snap, unsquashfs, enter, and use 'snap try' to have a rw snap17:46
mupPR snapcraft#1654 closed: autotools: cross-compile using --host instead of env <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1654>17:46
ikeysergiusens, eehhhhhhh17:46
ikeydon't get me started on that one mate :P17:46
ikey"linux == ubuntu"17:46
ikeynot while im around :P17:46
* Chipaca hugs ikey 17:46
niemeyeror me17:46
sergiusensikey it was from way way way before we started trying to get snapcraft work on different distros; also, there is no if linux, we have "if win" and "if osx"17:47
Chipacaikey: did the web work?17:47
niemeyersergiusens: You're not making it any better17:47
niemeyersergiusens: saying apt_pkg == linux support is waaaaay too much of a stretch17:47
ikeyChipaca, oh im not gonna upload it immediately immediately, was gonna do it in a few hours once i apply some basic polish to it17:47
sergiusensniemeyer for linux we check os release, but went into a whitelist mode17:47
sergiusensfor apt we check os release17:48
ikeymy problem is nobody can really *use* the snap without having minimum 2.29.2 + my last 2 patches17:48
ikeyis there a way for a snap to say "oi i need this many versions"17:48
ikeylike minimum snapd version17:48
Chipacathere is, but no idea how to use it. niemeyer?17:49
sergiusensbut I don't know what the keywords are17:49
Chipacaassumes: more-magic17:49
ikeyoh jdstrand re: dynamic hotplugging..17:50
cjwatsonif the web works> AIUI the web upload option is due to be removed soon in favour of snapcraft, so perhaps best not to get used to relying on it ...17:50
niemeyerassumes: snapdX.Y17:50
niemeyerIt's a list17:50
ikeydo we have plans for allowing udev rules within snaps ?17:50
niemeyerassumes: [snapdX.Y]17:50
ikeycjwatson, ah i wondered as much, the dashboard looks a bit uhm17:50
ikeywell. tired.17:50
ikeyniemeyer, so assumes: [ snapd2.29.4 ] for example?17:51
cjwatsonit's a codebase with a storied history.  there's some UI rerefresh work going on17:51
niemeyerikey: I don't think it supports micros.. need to double check17:51
ikeyah k17:51
niemeyerDouble checking17:52
ikeycjwatson, well it seems to look/talk about core a lot so i assumed it was from the Old Period17:52
ikeyand snapcraft being the new snapd specific sexy17:52
ikeyvs.. "core"17:52
cjwatsonthat wouldn't be very surprising, indeed17:52
ikeystill i do *like* me some some CLI sexy17:52
sergiusensis there a solus image fox lxd?17:53
ikeyso i can wait17:53
niemeyerikey: It does support micros17:53
ikeyniemeyer, oo shiny17:53
ikeyso i can have a built-in please-dont-even-no-stop17:53
niemeyerYeah, that was the idea all along17:53
ikeyi like17:53
ikeyi just dont wanna put up with the flood of bugs about the runtime17:54
Chipacai think it's a late warning, but it's better than nothing17:54
Chipacaie it's at validation time, once the download is done17:54
ikeysergiusens, ive never made an lxd image17:54
ikeybut like, if one is wanted, i could figure out how to cook one17:54
* ikey doesn't use lxd 17:54
ikeyi just have a "make boot" command for all my ISOs in qemu and thats the extent of my virtualisation work17:55
sergiusensikey I wouldn't mind one :-) if you don't mind, I guess stgraber wouldn't mind adding it to the image repo17:56
niemeyerAlright.. I'll go out for some exercising while the sun still shines17:56
niemeyerSee you soon17:56
ChipacaI'm going to EOW now17:56
ikeyyou have sun?17:56
Chipacaniemeyer: o/17:56
niemeyerChipaca: Have a good one17:56
ikey17:56 here and black as a pint of the good stuff17:56
Chipacaikey: he's in brazil; if he doesn't have sun, we dead17:56
ikeyoh lol17:56
* ikey likes that way of putting it :P17:57
cjwatsonikey: eh, they call it the emerald isle for a reason, right?  never stops raining17:57
ikeypretty much17:57
ikeyother countries have rumours of ghosts, girls hit by cars and such17:57
ikeywe have rumours of dry children walking the streets17:57
ikeyhorrific stuff17:57
sergiusenselopio have time for a quick hangout?18:03
elopiosergiusens: I was finishing your review to go out and find lunch. I can delay that, but I'm a little hungry. Is it urgent? or can we talk by chat?18:18
sergiusenselopio after your lunch18:20
elopiosergiusens: I'll ping you.18:21
jdstrandikey: re udev rules in snaps> there aren't plans (currently) to ship udev rules in app snaps. the udev interfaces backend is meant to be used for that (eg, the modem-manager interface creates the udev rules for modems when a snap implementing the slot is installed)18:51
ikeyhm ok18:51
ikeyso the "issue" that i have is steam ships udev rules18:51
ikeyand thats mostly for the steam controller18:51
ikeyand htc vive18:52
ikeyso right now with the steam snap they'd be bork18:52
jdstrandikey: we could think that through, but the joystick interface could be updated and the steam snap could slot it, or we can create a steam slot18:52
ikeyah thats a good point18:53
ikeyfwiw i do realise this is a fairly specialist case and i dont wanna be unfair on you guys18:53
ikeybut i do suspect the steam snap will be ... somewhat popular18:53
jdstrandor we create a game-controller interface that ships all the different controller udev rules, or something18:53
jdstrandthis wouldn't be difficult at at all. the hard part would be to decide the name and how to organize the controllers. that would be a great forum topic18:54
ikeyfor me i just wanna finally *solve* steam, and i think snap is the best way to accomplish this..18:54
ikeyand i think its some brownie points for snapd too :P18:54
jdstrandthat would be awesome18:54
ikeywe've been doing this stuff for like 2 years now, its actually remarkable seeing it all (literally) squashed down into these two snap files18:55
jdstrandonce the design is in place, I could whip something up for 2.3018:55
jdstrand(for the controller)18:55
ikeyit'd also allow feral to have their udev rules in snapd too18:55
ikeyfor the wheels and such18:56
ikeycentralising it would be nice18:56
* jdstrand nods18:56
ikeyi used to be annoyed with the game porters because of the state of linux gaming, but honestly these days i get it and i feel sorry for them. they didn't ask for the state of the runtime..18:57
ikeywhats the right way to go about doing a call for testing for a snap?18:57
ikeygiven that mine requires patches to snapd18:57
jdstrandyeah. 'linux' is a thousand different things to a thousand different people18:57
ikeythe "actual" steam runtime is painful to look at, ubuntu 12.04 libs and such18:58
jdstrandbut like you said, snaps has the very real potential to fix that18:58
ikeypre C++ ABI breaks18:58
ikeyits why i ran away from appimage and such18:58
ikeythey don't solve ABI problems18:58
ikey(plus the appimage code leaves much to be desired to be frank)18:59
jdstrandI always wondered why the steam ppa was still on an old release18:59
ikeyi get the distinct impression valve trapped themselves18:59
ikeywith their own runtime18:59
ikeywhich, tbf, back in the day it worked18:59
ikeyand then everything changed18:59
ikeyand they never *designed* the runtime18:59
ikeynowadays if you designed it, you'd design ABI profiles19:00
ikeyin this version we have blahblah19:00
ikeyand you'd avoid host contamination19:00
ikeyit doesn't have any of that19:00
ikeyso we're left with the only conclusion19:00
ikeyreplace the runtime *and* the host19:00
ikeymake them one19:00
ikeymuch of LSI is 2 libraries which use LD_AUDIT to hijack the dynamic linker to make things point at system libs all the time, and LD_PRELOAD to unbreak game breaking bugs19:01
ikeybut it still needs the distro work19:01
ikeylike all the libs + emul32 cruft19:01
ikeyits really hard to integrate LSI :)19:01
ikeycase in point, look at all these deps: https://dev.solus-project.com/source/steam/browse/master/package.yml19:02
ikeythey were all enabled just for steam, and their chains..19:02
jdstrandwhat, no wayland?19:03
* jdstrand ducks19:03
ikeyactually we did try19:03
ikeybut the SDL client has X11 specific calls19:03
ikeywe use Steam with our own SDL to alleviate client issues (broken videos etc)19:04
ikeyif you use SDL_VIDEO_DRIVER=wayland it craps out :p19:04
ikeywe now have specialist snapd support in LSI btw19:04
jdstrandnot surprised. some day. I mean, I'm using wayland, but it is far from perfect even for my limited use19:04
ikeyyou can get an idea of what the rest of LSI does just looking at that19:04
ikeyyeah wayland has a ways to go19:05
mupPR snapd#4174 closed: packaging/arch: packaging update <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4174>19:18
mupPR snapd#4204 opened: store: enable "base" field from the store <Created by mvo5> <https://github.com/snapcore/snapd/pull/4204>19:24
=== JoshStrobl is now known as JoshStrobl|Away
sslbI'm having an issue with all snaps on my system - rocketchat-server.rocketchat-mongo[1086]: cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied19:37
sslbWhen trying to run the "hello-world" snap it is giving me the same error19:37
sslbRunning everything as root19:37
mupPR snapcraft#1723 closed: sources: workaround for ZipFile.extractall not preserving permissions <Created by mariogrip> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1723>19:46
zyga-ubuntumvo: I noticed you are still working, how can I help?20:01
ikeyjdstrand, i decided to be "responsible" (ew) and create a forum topic about the controller thing per your suggest20:11
ikey(obviously doesn't demand immediate attn, EOW and all that)20:11
* ikey leaves the channel with a tune to start the weekend to20:13
elopiosergiusens: back20:20
sergiusenselopio going for a walk now, in an hour?20:21
elopiosergiusens: I'll be here.20:22
sergiusenselopio let's do it now; my family gets home soon at it is a lot louder20:30
sergiusenswalk canceled20:30
mupPR snapcraft#1645 closed: ruby plugin: new stable release 2.4.2 <enhancement> <Created by nathanhaines> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1645>20:38
ikeyok this is mighty interesting20:39
ikeyi can "sorta" get steam client working with strict confinement20:39
zyga-ubuntuikey: yeah?20:40
zyga-ubuntuikey: (disclaimer) I'm a bit drained and I plan to debug 14.04 issues early next week but I can look at steam and definitely mvo and me can help with base snaps20:40
mupBug #14: There is no link to the bugtrackers config page <iso-testing> <lp-bugs> <Launchpad itself:Fix Released> <https://launchpad.net/bugs/14>20:40
zyga-ubuntuwhat is that sysfs resource thing?20:41
zyga-ubuntupcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.3/resource: Permission denied20:41
mupPR snapcraft#1530 closed: tests: share the cache dir in the integration suite <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1530>20:41
ikeythis is steam tryna find pci devices20:41
ikeyi.e. GPUs20:41
zyga-ubuntuI see20:41
zyga-ubuntuthat should be ok, it should get access to gpus but not to random stuff20:41
zyga-ubuntuunless it breaks it :)20:41
ikeywe'll find out20:42
ikeyits only breaking parts of the client20:43
ikeyso the web portion is bork obviously20:43
ikeybut ill need to consult other cef/chromium snaps to see how they do it20:43
ikeygames *work*20:43
zyga-ubuntuI think chromium sandbox is the thing20:43
jdstrandikey: thanks!20:43
zyga-ubuntuit requires privilege to setup20:43
ikeyand i think im missing XDG crap20:43
zyga-ubuntuhey jdstrand :)20:43
ikeybut looky https://ibin.co/3gqknFqXOwQo.png20:43
zyga-ubuntuxdg crap?20:43
ikeyyeah XDG vars20:44
ikeybecause "/u1000-" path20:44
ikeybut hey i mean this is mahusive progress20:44
ikeywe know we *can* have strict confinement steam20:44
ikeywhich makes me vury happy because outdated libs that LSI mightn't catch20:44
zyga-ubuntuikey: I think it's very very desirable20:45
zyga-ubuntuespecially for for-profit random binary outdated libs20:45
ikeywell LSI actually does some utter voodoo to alleviate that20:45
ikeywe ban vendored ssl, curl, curl-gnutls, etc20:45
ikeygames just can't use them20:46
ikeyand even for games now using libressl, we have a special shim package and LSI redirects linking to libssl-libressl.so, libcrypto-libressl.so, etc20:46
ikeyso if they're using libs we don't yet handle, we actually forcibly break them20:46
zyga-ubuntuyeah but "mr spongebob and adventures in lalaland can spy on $HOME20:46
ikeyuntil we have a rule to handle their security libs20:46
ikeyor a game could capture credentials20:46
zyga-ubuntuit's a process but getting steam inside the sandbox is a big step in the right direction20:47
ikeythis way we dont need to convince valve to sandbox games or use snaps for games20:47
ikeywe snap the entire execution environment and all children20:47
ikeyso they don't do anything but everyone profits20:47
ikey(except me. this shit costs a lot of money)20:48
* zyga-ubuntu hugs ikey :)20:49
zyga-ubuntuI wish gog were a bit more serious about their dosbox games on linux20:49
zyga-ubuntubut I guess ENOMARKET20:49
zyga-ubuntuwell, little by little20:50
ikeywell, im quite happy with the progress made on this whole steam thing in the last few days20:52
ikeymy apologies for being stressy about the whole zenity thing :p20:52
ikeyive got some minor startup bugs to alleviate too like its reliance on zenity + lsb_release20:52
ikeybut i can have modified versions of both in the snap20:52
ikeyso that they don't try to access /etc/lsb_release20:52
zyga-ubuntuikey: no apologies necessary20:53
zyga-ubuntuikey: thank you for trusting us with snaps and pushing forward :)20:53
ikeywell i figured it was high time i stopped talking about it and actually did it :D20:53
ikeybtw posted to https://plus.google.com/+Solus-Project/posts/NUChGnTk29M if you wanna social medias it or anything20:56
ikeyre the confinement20:56
jdstrandroadmr: hi! can you sync r939 of the review tools?20:56
zyga-ubuntuikey: oh :)20:59
zyga-ubuntuikey: shared :)21:01
mupPR snapd#4205 opened: add spread test for allocating TUN/TAP devices with network-control <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4205>21:02
ikeyta :D21:04
zyga-ubuntuikey: also on twitter21:07
zyga-ubuntujdstrand: reviewing21:10
zyga-ubuntujdstrand: sorry for the nits, I can address those if you want me to21:15
jdstrandI can do it21:18
zyga-ubuntujdstrand: this is not super important in small scripts but I try to encourage everything to pass mypy strict validation21:19
* zyga-ubuntu reads https://lwn.net/Articles/738694/21:20
jdstrandmypy? I do use pyflakes3 and pep821:20
zyga-ubuntujdstrand: I find them orthogonal in many ways21:22
zyga-ubuntujdstrand: mypy is great at giving python a static language feeling21:23
zyga-ubuntuwith that rarely running else statement also being type checked21:23
ikeyzyga-ubuntu, ta :)21:25
ikeyoh clever tweet too21:26
zyga-ubuntu(especially for things that are small and not tested other than the hard way :)21:26
zyga-ubuntuikey: clickbait at its best21:26
ikeylove it21:26
* jdstrand doesn't usually like tracecbacks for error output, but rolls with SystemExit21:26
zyga-ubuntujdstrand: oh, system exit doesnt traceback21:27
* zyga-ubuntu checks21:27
zyga-ubuntuno TB21:27
naccspecifically mentioned in the docs :)21:29
jdstrandit did here with:21:30
jdstrandexcept PermissionError as e:21:30
jdstrand    raise SystemExit(e)21:31
jdstrandyou recommended 'raise SystemExit(...)'21:31
* zyga-ubuntu looks21:31
naccjdstrand: in the docs21:31
naccif it has another type (such as a string), the object’s value is printed and the exit status is one.21:31
naccso i thikn it's printing hte exception object21:32
zyga-ubuntujdstrand: do you see a traceback?21:32
naccimo, you want 'raise SystemExit from e'21:32
zyga-ubuntuI hmm21:32
zyga-ubuntuzyga@fyke:~$ cat foo.py21:32
zyga-ubunturaise SystemExit(ValueError("omg"))21:32
zyga-ubuntuzyga@fyke:~$ python3 foo.py21:32
naccthat's not from the raise, though21:33
* nacc doens't know the code he's looking at, admittedly :)21:33
jdstrandyou're right. I didn't catch this one21:33
zyga-ubuntucould that be contextlib.contextmanager21:34
naccjdstrand: ah ok21:34
jdstrandit is fcntl.ioctl21:34
naccjdstrand: yeah it just looks like an unhandled PermissionError21:34
zyga-ubuntufunky :)21:35
zyga-ubuntujdstrand: in my spare time I used to love adding bindings go glibc21:35
jdstrandwhat I am saying is that I thought that the raise SystemExit() caused it. it did not. it was actually an unhandled PermissionError21:35
zyga-ubuntuto expose each interesting bit in python21:35
zyga-ubuntujdstrand: except Exception: raise ?21:38
zyga-ubuntujdstrand: isn't that a no-op really?21:39
zyga-ubuntujdstrand: valid_device_name is not annotated21:39
jdstrandwell, it isn't a no-op, but it isn't strictly required, sure21:39
zyga-ubuntujdstrand: I mean, in absence of this code we raise anyway21:40
zyga-ubuntujdstrand: so it seems there's no way to observe that this code is or isn't there21:40
zyga-ubuntu(am I missing something?)21:40
jdstrandzyga-ubuntu: that's what I meant. I'll just remove it21:41
jdstrandzyga-ubuntu: if a function returns bool, what should I use in the annotation?21:41
zyga-ubuntu(nitpick) closing_fd could be annotated as (closing_fd(fd: int) -> Iterable[int]21:41
zyga-ubuntu-> bool21:41
jdstrandyou are nitpicking your nitpick now :P21:42
zyga-ubuntujdstrand: I just realized that :)21:42
zyga-ubuntumust be Friday21:42
jdstrandameError: name 'Iterable' is not defined21:43
zyga-ubuntufrom typing import Iterable21:43
zyga-ubuntuit's a part of stdlib now21:43
jdstrandwhat do I need to import for that?21:43
roadmrjdstrand: hi! sure, I'll put that in the pipeline21:57
gps1539Maybe hard to ask for help over irc, but here goes.22:02
gps1539I have a topic on https://forum.snapcraft.io/t/how-to-call-dependencies-in-snapcraft-yaml/2726/922:02
sergiusenszyga-ubuntu I started using mypy last week myself; best next thing to not being able to compile22:02
zyga-ubuntusergiusens: I agree :)22:03
gps1539but it got flagged when I posted my yaml file and setup.py22:03
zyga-ubuntusergiusens: it's worth tracking upstream releases22:03
gps1539where can I go for help>22:03
zyga-ubuntusergiusens: follow jukka on twitter22:03
sergiusensgps1539 look in the prime directory; most likely it is in bin/treepass22:05
gps1539grep -r trespass come up blank, nothing under prime22:08
ikeyheh figured out my ugly zenity issue22:08
ikeyconvert the build to gresource..22:08
gps1539can folks see the topic on the forum? I can not so not sure if it got pulled22:10
gps1539pip install trespass works fine although it installs to /usr/local/bin/trespass and not /usr/bin/trespass (which is does on Arch)22:12
gps1539Any clues to what I'm missing in my yaml22:12
sergiusensthat was a short stay, oh well22:40
elopiosnappy-m-o autopkgtest 1657 xenial:armhf22:59
snappy-m-oelopio: I've just triggered your test.22:59
elopiosnappy-m-o autopkgtest 1716 xenial:armhf23:53
snappy-m-oelopio: I've just triggered your test.23:53

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