[03:41] <mup> PR snapd#3494 opened: tests: Restart rng-tools services after few seconds <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3494>
[04:17] <mwhudson> hey guyz snapcraft fails tests with python 3.6
[04:40] <mup> PR snapcraft#1318 closed: tests: refactor the travis jobs using stages <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1318>
[04:55] <mup> PR snapcraft#1291 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1291>
[06:16] <mup> PR snapcraft#1331 closed: integrations: use the snapcore/snapcraft docker image in travis <Created by filibtester> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1331>
[07:07] <mup> PR snapd#3495 opened: tests: remove snapd before building from branch <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3495>
[07:34] <Chipaca> fgimenez: morphis: I'm running off to physio, but I thought I'd ask you guys if you could look into why spread on debian (when travis gets past the auth issue) is failing with “go: command not found”
[07:34] <morphis> Chipaca: you have a link?
[07:34] <Chipaca> https://travis-ci.org/snapcore/snapd/builds/244733765#L653
[07:35] <fgimenez> Chipaca: sure, looking
[07:36] <fgimenez> Chipaca: morphis maybe the problem happens a bit earlier "Cannot install 'libudev-dev'"
[07:36] <morphis> yes, that looks like what it is
[07:37] <morphis> if the install command in pkgdb gets a list of packages it aborts on the first error
[07:37] <Chipaca> aborts but doesn't return an error?
[07:37] <morphis> ah, but this is really gdebi
[07:38] <morphis> AFAIK it does
[07:38] <Chipaca> anyway, i really need to run
[07:38] <Chipaca> o/
[07:38] <morphis> hm, https://packages.debian.org/sid/libudev-dev is in all debian archives
[07:41] <ogra> version issue ? (we used to have that with the core snap wehn we used too ship our own systemd version, people building something with libudev-dev in build-packages had their builds fall over ... the version is a == one iirc
[07:42] <ogra> )
[08:05] <zyga> re
[08:12] <zyga> ogra: hey
[08:12] <ogra> yo
[08:12] <zyga> ogra: do you have a moment?
[08:12] <ogra> sure
[08:13] <zyga> ogra: how can I run test-init without it being init
[08:13] <zyga> ogra: I don't want to use break=... and then script the shelll that spawns (unreliable)
[08:13] <ogra> zyga,  i meant the other way around
[08:14] <ogra> and no, you shouldnt use break :)
[08:14] <zyga> ogra: can you tell me what you mean then?
[08:14] <ogra> zyga, you boot with boot=/test-init ...
[08:14] <ogra> that simply runs /init
[08:14] <ogra> so that you get all the env bits you need
[08:14] <zyga> aha
[08:14]  * zyga tries
[08:14] <zyga> hmm
[08:15] <ogra> the environment and available devices differ between the stages
[08:15] <ogra> and init makes sure to exec each bit in its assignedf stage
[08:15] <zyga> ogra: so kernel command line would have boot=test-init
[08:15] <ogra> right
[08:15] <zyga> ogra: that wants to run /scripts/test-init
[08:15] <zyga> ogra: how do I pass arguments to my init program?
[08:15] <ogra> and test-init somehow needs toexec the scrip snippets at the step that init would use
[08:16] <ogra> take a look at it ... it read env vars
[08:16] <ogra> *reads
[08:16]  * zyga looks
[08:16] <ogra> every ubuntu install has the script in /usr/share/initramfs-tools/init
[08:16] <ogra> so no need to dig into the source ;)
[08:16] <zyga> TBH the whole exercise only made me want to write /init in C more than anyhting
[08:17] <ogra> well, thats something you should discuss with debian :)
[08:17] <zyga> all the complexity there and all the fragility
[08:17] <zyga> why? is debian doing ubuntu-core? :D
[08:17] <zyga> ogra: btw, I think I found a bug in the script
[08:17] <ogra> no, but we use their inittamfs-tools package
[08:17] <zyga> ogra: have a look at the FIXME I added
[08:17] <ogra> yeah
[08:17] <ogra> we should just fix it ;)
[08:17] <zyga> ogra: I'd like to do a pass and document and test some of those functions better
[08:18] <ogra> (well, we use debians package with ubuntu sauce on top indeed)
[08:18] <zyga> ogra: right but I didn't want to bring that in with this patch, I want this to land
[08:18] <zyga> ogra: I don't know if anyone else is doing this
[08:18] <zyga> ogra: (testing initrd this way)
[08:18] <zyga> ogra: but I wanted to show it is doable
[08:18] <ogra> nope
[08:18] <ogra> and it would be way coooler to actually do it in the distro :)
[08:18]  * zyga was super slow because python3 async was a learning curve and several small details stopped me mid-process
[08:18] <zyga> also I'm sick
[08:19] <ogra> so that we could just use it from there (and have someone else maintain the core part of it ;) )
[08:19] <zyga> and moving out day after tomorrow
[08:19] <zyga> and also sunburned and on painkillers
[08:19] <ogra> :(
[08:19] <zyga> so some adverse factors towards productivity
[08:19] <zyga> ogra: I wrote the code to be modular and reusable, with some more polish this could be used to test any early boot scenario
[08:20] <ogra> well, we're not on a race, are we ?
[08:20] <zyga> ogra: I'm mostly fond of the snapshot approach, which means this is blazingly fast
[08:20] <zyga> ogra: well, I feel some pressure to finish this and move to snapd
[08:20] <ogra> zyga, yeah, and i think you should show it to infinity and slangasek and ask them if they want to take it over into the initramfs-tools package
[08:20] <zyga> ogra: I had a look at a redhat paper describing qemu and kernel optimizations that allows them to boot a kernel i 150ms
[08:21] <zyga> ogra: sounds like a good idea, I will
[08:21] <ogra> (alongside with landing it in our branch)
[08:21] <ogra> if they take over we only need to care for the tests in the end
[08:21] <ogra> and not for the framework
[08:21] <ogra> and they get testing for free ;)
[08:24] <zyga> ogra: yeah
[08:25] <zyga> ogra: well, let me try that change you suggested
[08:26] <ogra> to set the env vars you want executed in /init, just drop a file into /conf/conf.d// with the values set you want ... /init will read them from there
[08:27] <zyga> ogra: I'm not yet sure if that's the approach to take but let me experiment and see what I can come up with
[08:27] <ogra> and if you do that you can drop a lot of your code ... i.e. the bits that populate /dev and mount all the filesystems
[08:28] <ogra> (and use what /init does at the top)
[08:29] <zyga> INFO:qemu:(console) Begin: Mounting root file system ... /init: /scripts//test-init: line 1: syntax error: unexpected word (expecting ")")
[08:29] <zyga> ogra: it seems that boot=test-init assumes everything is written in shell
[08:29] <ogra> it shouldnt, that would be a kernel bug
[08:30] <zyga> INFO:qemu:starting: ['qemu-system-x86_64', '-enable-kvm', '-snapshot', '-m', '64', '-kernel', 'kernel', '-initrd', 'initrd.back-to-back.cpio.gz', '-append', 'console=ttyS0 boot=/test-init -- testio=ttyS1', '-chardev', 'pipe,id=console,path=/tmp/consolefrqqj0e0', '-chardev', 'pipe,id=monitor,path=/tmp/monitoror3qf2oy', '-chardev', 'pipe,id=testio,path=/tmp/testio5zk4mizt', '-display', 'none', '-monitor',
[08:30] <zyga> 'chardev:monitor', '-device', 'isa-serial,chardev=console', '-device', 'isa-serial,chardev=testio', '-device', 'isa-debug-exit,iobase=0xf4,iosize=0x4', '-drive', 'file=disk.img']
[08:30] <ogra> (and systemd wouldnt work either ... unless there is a secret shellscript wrapper we dont know about )
[08:31]  * zyga feels dizzy again
[08:31] <zyga> what a day :/
[08:31] <ogra> take a sick day ...
[08:31] <ogra> seriously
[08:31] <zyga> one sec
[08:32] <ogra> no, one day :P
[08:32] <ogra> not curing it just makes it last longer
[08:32] <zyga> ogra: just sent you a pic
[08:32] <zyga> ogra: everything looks like this around me
[08:32] <zyga> downstairs is mostly packed now
[08:33] <ogra> you picked the angle where i dont see the mountain of napkins around you :)
[08:33] <zyga> ogra: they are behind me in the rubbish bin
[08:33] <ogra> yeah, thought so :)
[08:44] <pstolowski> fgimenez, hey, i'm seeing a bunch of auth errors from linode on travis
[08:47] <fgimenez> hi pstolowski, do you have a link to the errors? sounds like something we can't help with, just to confirm
[08:47] <pstolowski> fgimenez, https://travis-ci.org/snapcore/snapd/builds/244606124?utm_source=github_status&utm_medium=notification
[08:51] <fgimenez> pstolowski: mm that error comes from spread itself, it can be caused by a missing or wrong SPREAD_LINODE_KEY env var, let me check locally using the same spread binary as travis
[08:56]  * zyga de-conflicted https://github.com/snapcore/snapd/pull/3464
[08:56] <mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
[09:01] <fgimenez> pstolowski: the same binary works fine locally with a valid SPREAD_LINODE_KEY, the errors you get can be caused by a transient error on linode, changes in how the binary behaves on travis, changes on the encryption keys... if the errors keep happening you need gustavo to look into this
[09:02] <pstolowski> fgimenez, ack, thanks for looking into this!
[09:03] <fgimenez> pstolowski: yw :)
[09:07] <zyga> hey pstolowski
[09:08] <zyga> how are you doing?
[09:08] <pstolowski> hi zyga! good, thanks! what's up?
[09:08] <zyga> pstolowski: could you have a look at https://github.com/snapcore/snapd/pull/3464
[09:08] <mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
[09:09] <zyga> pstolowski: patch by patch, it should be trivial to review as each diff fits on screen (just moves code from a to b)
[09:11] <pstolowski> zyga, very nice, i will
[09:12] <zyga> pstolowski: dzięki :)
[09:23] <cjwatson> Could somebody please retry the xenial-i386 test on https://github.com/snapcore/snapd/pull/3475 ?  It looks suspiciously not-a-problem-with-my-branch
[09:23] <mup> PR snapd#3475: store: change main store host to api.snapcraft.io <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3475>
[09:27] <mvo> actually, can someone do a second review on 3475 please? should be straightfoward (and an easy win)
[09:31] <zyga> cjwatson: I don't know if anyone can do this easily
[09:32] <zyga> cjwatson: I was talking to mvo about it a few days ago, that it is not easy to re-trigger those tests
[09:32] <pedronis> mvo: I'll look at it in a bit
[09:33] <cjwatson> zyga: What options do I have?
[09:34] <mvo> cjwatson: no worries, once this has a second review it can go in
[09:35] <mvo> cjwatson: the autopkgtests are "extra", the only hard requirement is that travis is green which we have more control over. autopkgtest is still very useful as a canary for problems we may otherwise only see after a snapd deb upload
[09:36] <zyga> cjwatson: force push again, not sure
[09:39] <cjwatson> Ah, sounds like maybe I can just ignore the failing test then ...
[09:40] <mvo> cjwatson: yes, this is our problem, not yours :)
[09:40] <cjwatson> OK :)
[09:40] <cjwatson> I like the sound of that.
[10:02] <mup> PR snapd#3496 opened: cmd/snap-repair:  start of Runner, implement first pass of Peek and Fetch <Created by pedronis> <https://github.com/snapcore/snapd/pull/3496>
[10:06] <pedronis> mvo: ^
[10:07] <mvo> pedronis: yeah, just peeked (no pun intended) at it. I'm looking at debian unstable right now, breaks all our tests
[10:09] <pedronis> mvo: just a heads up really, I understand getting 2.26 out is out first priority
[10:12] <mvo> pedronis: thanks for this
[10:15] <mup> PR snapd#3497 opened: spread: help libapt resolve installing libudev-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/3497>
[10:30] <Chipaca> morphis: fgimenez: any luck with the debian thing?
[10:31] <morphis> Chipaca: can you drop the quiet around that gdebi call so we can see why it fails to install libudev?
[10:32] <Chipaca> morphis: if the gdebi call failed the quiet would print the output. Is it not failing?
[10:32] <Chipaca> or rather, is it not returning with exit_failure?
[10:33] <morphis> it should as it prints out it can't install libudev for whatever reason
[10:33] <Chipaca> i can also disable debian and let you dig; it's not just my PR that's failing in this way
[10:33] <morphis> no, don't disable debian
[10:35] <morphis> so something has changed which breaks this now
[10:36] <Chipaca> ah, you mean the --quiet
[10:36] <fgimenez> Chipaca: morphis snapd#3497 from mvo fixes it
[10:36] <Chipaca> not a prefix quiet but gdebi's --quiet itself
[10:36] <mup> PR snapd#3497: spread: help libapt resolve installing libudev-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/3497>
[10:36] <Chipaca> at what point did we regress prepare to run apt-get install eleventyfour times, once for each package we wanted to install?
[10:37] <morphis> ah!
[10:37] <Chipaca> we'd got it reduced to a single call or two at most :-(
[10:37] <Chipaca> because it added several minutes to the prepare time
[10:38] <morphis> Chipaca: I have a change pending to improve the pkgdb for that
[10:39] <Chipaca> morphis: what's the idea behind pkgdb? i mean, other distros will have differently-named packages for the same thing, yet last i looked at it it was still handling things at the package level
[10:40] <morphis> Chipaca: it abstracts package installation
[10:40] <Chipaca> morphis: yes, i get that
[10:40] <morphis> Chipaca: you give it something "cups" and it will figure out the right thing to do
[10:40] <Chipaca> morphis: but does it make sense, given package names are going to be different?
[10:40] <morphis> it will map "cups" to the right packages for each distro
[10:40] <morphis> based on the set SPREAD_SYSTEM
[10:41] <Chipaca> morphis: is "cups" a target, or a package name?
[10:41] <Chipaca> dunno if "target" is the right name
[10:41] <morphis> it's a name of a thing you want to install
[10:41] <morphis> it can be a package name
[10:41] <Chipaca> so we're going to carry around a table of package names per distro?
[10:41] <morphis> yes
[10:42] <morphis> that keeps these distro specific things out of the test cases
[10:42] <morphis> and you just have to express "I want cups"
[10:46] <morphis> Chipaca: but doing more than on apt-get call per distro_install_package call isn't what we should do
[11:09] <mup> PR snapd#3498 opened: hooks: support for install and remove hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3498>
[11:12] <mup> PR snapd#3497 closed: spread: help libapt resolve installing libudev-dev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3497>
[11:23] <morphis> mvo: btw. what is the state of the 2.26 release?
[11:36] <pedronis> Chipaca: I'm getting repeated mail from github all the time about this checkin of yours: osutil: unexport KillProcessGroup until we have a use case (f67bedb)
[11:36] <pedronis> are you doing anything strange?
[11:36] <pedronis> or it's a github bug
[12:03] <mvo> morphis: seccomp-bpf needs to get merged, then we are unstuck again
[12:03] <morphis> mvo: ah
[12:03] <morphis> mvo: any timeline for this?
[12:04] <mvo> morphis: jamie and I are working on this as quick as possible, the goal is before the end of this week
[12:04] <mvo> hopefully sooner
[12:04] <morphis> ok
[12:04] <morphis> not pressure from my site, was just curious :-)
[12:04] <morphis> mvo: would be good to have an update on https://forum.snapcraft.io/t/in-progress-snapd-2-26-4/514/15 so everyone else knows too
[12:07] <zyga> pstolowski: small review of 3498
[12:07] <pedronis> cjwatson: reviewed that PR, +1  , couple small remarks
[12:17] <niemeyer> Mornings
[12:18] <niemeyer> How's Travis behaving this morning?  Still issues?
[12:18] <zyga> hey niemeyer
[12:18]  * zyga hasn't seen any issues yet
[12:19] <zyga> niemeyer: have you seen this?
[12:19] <zyga>   
[12:19] <zyga>   
[12:19] <zyga> This job ran on our Trusty, sudo: required environment which will be updated on Wednesday, June 21st. Please add group: edge to your .travis.yml file to try the new images and check our blog for more details about this update.
[12:20] <niemeyer> zyga: Yeah, but that's just a note.. we were having some issues yesterday about authentication issues on Linode, which apparently is actually about Travis itself not being quite sane
[12:21] <niemeyer> We also saw at least once a message of packaging problems very early on in Travis setup land, before travis.yaml takes over
[12:22] <zyga> niemeyer: I saw a patch from mvo about debian and udev update, maybe that's that
[12:23] <zyga> (and also saw my branch fail on debian prepare)
[12:24] <pedronis> yes, things are failing on debian atm
[12:25] <cjwatson> pedronis: thanks, pushed fixes
[12:30] <fgimenez> hey niemeyer, yes, we had authentication issues from travis to linode, seems to be better now
[12:30] <niemeyer> fgimenez: Any news from this morning?
[12:32] <fgimenez> niemeyer: we were getting this morning auth errors like https://travis-ci.org/snapcore/snapd/builds/244823012?utm_source=github_status&utm_medium=notification, recent executions don't show this error (i'm about to retrigger that one btw)
[12:33] <morphis> zyga: ping
[12:35] <zyga> morphis: hey, what's up?
[12:36] <morphis> zyga: I am currently looking into a failure of tests/main/interfaces-content on Fedora, https://paste.ubuntu.com/24907862/
[12:36] <morphis> effectively I don't see the bind mount in place so wondering what I should look at
[12:36] <zyga> morphis: looking
[12:37] <zyga> with master, I presume
[12:37] <zyga> morphis: any SELinux denials?
[12:37] <morphis> no
[12:37] <morphis> but wait, maybe I have a clue
[12:37] <zyga> morphis: it's a new program, perhaps the policy is stale
[12:37] <morphis> the bind mount is in place, /var/lib/snapd/snaps/test-snapd-content-slot_2.snap on /snap/test-snapd-content-plug/2/import type squashfs (ro,nodev,relatime)
[12:38] <morphis> hah
[12:38] <morphis> $ echo $SNAP
[12:38] <morphis> /var/lib/snapd/snap/test-snapd-content-plug/2
[12:38] <morphis> that is the reason why
[12:38] <mvo> morphis: updated the forum
[12:38] <morphis> mvo: thanks!
[12:38] <zyga> morphis: I think we spoke about that
[12:38] <zyga> morphis: that $SNAP is wrong on Fedora
[12:38] <morphis> zyga: we did
[12:39] <zyga> morphis: I thought we fixed that but ... well :)
[12:39] <zyga> morphis: good catch
[12:39] <morphis> zyga: we fixed the content interface impl
[12:39] <morphis> but as it seems not the part which sets up SNAP
[12:43] <niemeyer> fgimenez: That's the same we were observing yesterday
[12:43] <niemeyer> fgimenez: Please let me know if you see it again.. I'll tweak spread to debug the problem if so
[12:44] <fgimenez> niemeyer: sure, thx
[12:50] <jdstrand> mvo: hey, yesterday I had some ideas on the testsuite but I forget to click 'Review changes' so they were pending til just now. Let me know if you have questions
[12:52] <Chipaca> jdstrand: o/
[12:52] <mvo> jdstrand: cool, let me read it now
[12:52] <Chipaca> jdstrand: did you see me point you at a snap the other day?
[12:52] <mvo> jdstrand: I think all your other suggestions are now implemented, thanks again
[12:53] <jdstrand> Chipaca: I don't recall otoh. which snap?
[12:53] <Chipaca> jdstrand: test-snapd-service-notify
[12:53] <jdstrand> mvo: thank you :) once you are ready, I wanted to go through it one more time top to bottom
[12:54] <jdstrand> oh I definitely didn't see that
[12:54]  * jdstrand looks
[12:54] <mvo> Chipaca: I can also approve snaps fwiw
[12:54] <Chipaca> mvo: it's published :-)
[12:54] <Chipaca> mvo: it's about it getting DENIEDs because it's notify
[12:54] <jdstrand> Chipaca: ok, yes, it is in the store and published. what do you need?
[12:54] <jdstrand> ah
[12:55] <Chipaca> jdstrand: if you install it, you'll see denies
[12:55] <Chipaca> jdstrand: so first a question: is it a bug in the snap, ie is it expected, or is it a bug in our confinement?
[12:55] <jdstrand> Chipaca: is this as script or compiled code? if compiled code, where is the source?
[12:55] <Chipaca> if the latter, i can file a bug and all :-)
[12:55] <Chipaca> jdstrand: it's not compiled
[12:55] <Chipaca> jdstrand: it's python, using the system python, and a sdnotify.py included in the snap
[12:55] <jdstrand> let me look at it. I feel like I remember this was intentional
[12:56] <mvo> Chipaca: aha, sorry, then I misunderstood
[12:56] <jdstrand> I remember we did talk about how you were seeing denials and would get back to me
[12:56] <Chipaca> mvo: I don't know how you could've possibly misunderstood my vague insinuations at the half-formed predecessors of ideas
[12:57] <Chipaca> jdstrand: this is that :-)
[12:57] <jdstrand> yeah, c'mon mvo
[12:57] <jdstrand> Chipaca: yep :)
[12:57] <mvo> Chipaca: lol
[12:59] <mup> PR snapd#3480 closed: overlord/cmdstate: new package for running commands as tasks <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3480>
[13:00] <mvo> jdstrand: thanks for your comments, that looks very nice. I have the standup now, I will get back to it. I'm not sure I understand the "runimentary" part in the simulateBpf suggestion. unless I miss something (and modulo bugs) this should be exactly the same bpf environment that the kernel is using. we can talk after the standup if you want, maybe I'm missing something
[13:03] <jdstrand> mvo: it isn't the same bpf vm as the kernel and we can't launch programs under it
[13:03] <jdstrand> and so*
[13:04] <jdstrand> by using the kernel, we can prove to ourselves it will work (well, at least on those kernels) and by running a program under it, even if it is /bin/true, we can prove to ourselves that the bpf is sane enough to be useable as a seccomp filter
[13:06] <jdstrand> you are right that the fact that it compiles and is usable under the bpf vm shows a good deal (since the tested bpf needs to be good enough for both the vm and the kernel to use)
[13:06] <jdstrand> mvo: ^
[13:19] <jdstrand> Chipaca: ok, this needs a new interface because in 'man sd_notify' we see that sd_pid_notify() and sd_pid_notifyf() allow specifying a pid as the originating pid of the message, so a snap would be able to send status messages to systemd-notify for other processes not part of the snap
[13:20] <jdstrand> Chipaca: this interface would consist of a comment along the lines of what I just mentioned and this rule '/run/systemd/notify w,'
[13:24] <jdstrand> Chipaca: were you planning on using this mechanism by default?
[13:27] <jdstrand> Chipaca: it looks like that interface could also include this rule: /{,usr/}bin/systemd-notify ixr,
[13:27] <Chipaca> jdstrand: the only mechanism i think we wanted to support is notifying systemd itself (ie the READY=1 thing i think, plus the watchdog one?) but I think you're saying that you can't separate these things?
[13:29] <mvo> jdstrand: thanks, yeah. I think both tests complement each other nicely, the nice thing aobut the VM is that we can easily test the KILL works and the whole thing is more controlled. but +1 for both tests
[13:29] <mvo> jdstrand: I look into this now
[13:30] <Chipaca> jdstrand: that last "you" was meant in the same generic "we"/"one" voice I was using before, I'm not saying you personally can't separate them :-)
[13:31] <jdstrand> Chipaca: apparmor cannot-- it either gives access to the socket or it does not. access to the socket means that only DAC permissions will protect you, so if you are a root daemon, you can send status messages for other root daemons, based on the man page. I did not test this with code
[13:31]  * Chipaca nods
[13:32] <jdstrand> mvo: yes, not advocating for removing the vm (though a fork/exec could handle the kill ok)
[13:32] <jdstrand> but yeah
[13:32] <Vamsi> Hi, is it possible that the localhost has 2 login IDs?
[13:32] <jdstrand> Chipaca: do you want me to dive deeper on that?
[13:33] <jdstrand> Chipaca: I suspect I will only prove my assertion since the man page says that is what the api is designed to do
[13:33] <Chipaca> jdstrand: and in any case we'd want the interface to support the broader use
[13:33] <Chipaca> jdstrand: so, maybe jot it down to do in your copious free time
[13:33] <Chipaca> Vamsi: pardon?
[13:34] <Chipaca> jdstrand: it==the deeper dive i mean
[13:34] <jdstrand> Chipaca: systemd could be updated to mediate that better since it says 'provided the appropriate privileges are available'. it could query the LSM (eg, AppArmor) to do more than just check DAC/capabilities
[13:35] <Vamsi> Chipaca: to login the local host is showing two ssh IDs.
[13:35] <jdstrand> Chipaca: how about I just create the interface and then detail everything in comments?
[13:35] <Chipaca> jdstrand: A+
[13:35] <jdstrand> I don't have any problem with the interface since users get to decide (or snap decls)
[13:36] <Chipaca> yup
[13:36] <jdstrand> Chipaca: when do you need this?
[13:36] <Vamsi> For example: blah@172.18.0.65 and blah@172.19.0.65
[13:36] <Chipaca> jdstrand: no present urgency
[13:37] <Chipaca> Vamsi: where are you seeing this? What is the system running?
[13:37] <jdstrand> Chipaca: ok, after the bpf and profile regeneration mvo is working on, and after password-manager-service, I'll do this (that puts it ahead of getting back to wayland, but this shouldn't take too long so I think that is ok. I might be able to squeeze it in somewhere sooner
[13:37] <jdstrand> )
[13:38] <Chipaca> jdstrand: perfect, thank you
[13:38]  * Chipaca watches Vamsi go off and is left wondering
[13:40] <Vamsi> Chipaca: I have connected my Ubuntu core local host to a monitor and that's where I see this.
[13:41] <Chipaca> ogra: do you know if we print both addresses if you have more than one live interface?
[13:41] <ogra> i think we do, yeah
[13:41] <Chipaca> Vamsi: does your device actually have two network interfaces?
[13:42] <ogra> they both need to be up and have an assigned IP
[13:42] <Vamsi> Chipaca: I was initially using it on another network. And now changed the network.
[13:43] <Chipaca> that shouldn't cause it
[13:43] <ogra> so ssh in ... run sudo console-conf and de-confiigure the unused interface
[13:43] <Chipaca> or should it?
[13:43] <Chipaca> ogra: ?
[13:43] <ogra> Chipaca, well, if he used a fixed IP that IP would still be set
[13:43] <Chipaca> ogra: right, but if it were fixed it wouldn't pick up a new one
[13:44] <Chipaca> ogra: and if it's dynamic it should just pick up the new one
[13:44] <ogra> on that device
[13:44] <Chipaca> Vamsi: I didn't see you answer: do you actually have two network interfaces on this device?
[13:44] <niemeyer> mvo, Chipaca: What builds were failing on the auth issue?
[13:44] <Chipaca> niemeyer: aw, i just restarted one
[13:44] <Chipaca> niemeyer: but, chances are it'll be back
[13:44] <niemeyer> Chipaca: np, goal was to restart indeed.. do you have a link?
[13:45] <Chipaca> (travis is slow so it'll take a while to start)
[13:45] <Vamsi> Chipaca: No. only one at a time. I had to change to a different because of some reasons.
[13:45] <niemeyer> I've pushed an initial debug build of spread
[13:45] <Chipaca> niemeyer: https://travis-ci.org/snapcore/snapd/builds/244930470 is the one i just restarted
[13:45] <niemeyer> THanks
[13:46] <Chipaca> niemeyer: seems to be 1:4 success rate right now, so you should see it fail again soon
[13:46] <Chipaca> it just started, in fact
[13:46] <niemeyer> mvo: Looks like yours passed
[13:46] <mup> PR snapd#3475 closed: store: change main store host to api.snapcraft.io <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3475>
[13:46] <Chipaca> niemeyer: it failed again
[13:46] <mvo> niemeyer: yeah, I had a bunch of issues this morning but the current one seems to be ok
[13:47] <niemeyer> Chipaca: Great, let me see
[13:47] <Chipaca> Vamsi: are you able to access the device?
[13:48] <Chipaca> Vamsi: over the network to one of those two addresses?
[13:48] <Chipaca> Vamsi: actually, could you open a forum topic with all this? that way the console-conf people will also be able to help (i think they're in APAC tz)
[13:49] <Chipaca> niemeyer: does that tell you anything?
[13:52] <niemeyer> Chipaca: It does.. the environment seems right, which puts the doubt back on Linode.. I'll print out part of the actual key right before sending to be 100% sure
[13:54] <Chipaca> niemeyer: maybe do a 'printenv'-like thing?
[13:54] <Chipaca> i thought we had a printenv but i guess we ditched to save space in the logs
[13:54] <niemeyer> Chipaca: We do that already
[13:54] <niemeyer> Chipaca: Right before the call to spread
[13:55] <niemeyer> Chipaca: (it's folded)
[13:55] <Chipaca> ah so we do
[13:55] <niemeyer> Okay, there we go again.. hold tight
[13:55] <zyga> jdstrand: hey, can you review https://github.com/snapcore/snapd/pull/3464 please
[13:55] <mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
[13:55] <zyga> jdstrand: ideally before new interfaces land :)
[13:56] <Chipaca> niemeyer: -_- are you printing it at every api call?
[13:56] <niemeyer> Chipaca: Oh no... it passed.. that's going to be a long log :)
[13:56] <Chipaca> niemeyer: that's a lot of api calls
[13:56] <jdstrand> zyga: yes it is on my list. it is after the bpf stuff atm
[13:57] <Chipaca> niemeyer: cancel the build, i'm told spread loves that
[13:57] <niemeyer> Chipaca: Yeah, we monitor the machines to see if they go down
[13:57] <zyga> jdstrand: perfect, thank you
[13:57] <niemeyer> Chipaca: Because they take a very long time to restart..
[13:57] <niemeyer> I should optimize that so it uses less calls
[14:03] <niemeyer> Alright.. future runs won't print sooo much data
[14:20] <roadmr> niemeyer: hello :)
[14:21] <roadmr> niemeyer: when you have a sec we'd love your feedback in https://forum.snapcraft.io/t/edge-case-scenarios-for-snap-validations/1036
[14:21] <mup> PR snapd#3499 opened: Spi patch <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
[14:30] <niemeyer> Chipaca: It passed, despite a reaaaaaaaly long log
[14:30] <Chipaca> niemeyer: I'm sorry
[14:31] <niemeyer> Chipaca: :P
[14:31] <niemeyer> roadmr: Heya
[14:31] <Chipaca> niemeyer: maybe when somebody reviews it I'll have to change something and you'll get another chance
[14:31] <niemeyer> roadmr: Will look, thanks
[14:31] <Chipaca> niemeyer: meanwhile I've had fun making go throw errors I'd never seen before
[14:32] <Chipaca> like “write barrier prohibited by caller”
[14:32]  * Chipaca has all the fun
[14:32] <niemeyer> Chipaca: Wow, never seen that either
[14:33] <Chipaca> niemeyer: https://go-review.googlesource.com/c/43713/#message-52f9575a6a2544ad52ddaa588bfb29fb2e9feb3f
[14:34] <Chipaca> “dance for me, little robot-hamster-thing” “NO.”
[14:55] <niemeyer> Chipaca: This seems closely related to the issue:
[14:55] <niemeyer> https://www.irccloud.com/pastebin/Tru74bnx/
[14:56] <niemeyer> https://www.irccloud.com/pastebin/tu7rft1h/
[14:56] <Chipaca> niemeyer: ah, sorry, i didn't mean to send you down that rabbithole
[14:57] <niemeyer> Chipaca: I'm not down into it.. was just overlooking it from afar.. :P
[14:57] <Chipaca> niemeyer: it's SEP; I wrote it with a mutex, Ian copied over rwmutex and asked me to use that, but rwmutex is a lot more complex (to the point where it interacts wiht the gc), which things from newm can't do
[14:58] <niemeyer> Meanwhile, all PRs I try to debug are passing.. maybe that's the solution.. I just need to keep looking
[14:59] <mup> PR snapd#3500 opened: store: talk to api.snapcraft.io for assertions <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3500>
[15:00] <zyga> niemeyer: typical quantum CI bug
[15:04] <mvo> jdstrand: I was trying to make you prctl suggestions work with golang but its tricky with golang, it seems the only way is to add a C helper just for these kinds of tests, not sure its worth the work over spread tests
[15:07] <niemeyer> Oh, sweet.. some interesting debug info now.. the bug is definitely on the spread end..
[15:08] <zyga> mvo: which prctl call do you need?
[15:08] <jdstrand> mvo: I was wondering if the goroutines would get in the way. so, the C helper is already there and there is C test code and C code in snap-confine so it shouldn't be hard to get that building. what I've been somewhat uncomfortable with is that the old tests ran through the kernel and the new don't. because we would build snap-confine everywhere, the tests in the profiles always went through all the different kernels in our test matrix
[15:09] <mvo> zyga: I have all the prctl stuff, I just get hangs and zombies when I apply it
[15:09] <jdstrand> mvo: the new implementation dropped that, but tested more, so it was kinda a wash. with my suggestion, we get better coverage in the new
[15:10] <mvo> jdstrand: ok, I will create a tiny C helper for that then
[15:10] <jdstrand> mvo: I guess it could be in a follow-up PR if you feel strongly about it (I'd like to not lose the kernel bpf loading tests for new rules, etc)
[15:10]  * mvo takes a break first
[15:10] <jdstrand> mvo: to be clear, you did see the C helper I pasted, right?
[15:10] <jdstrand> (in the PR)
[15:11] <jdstrand> it works so steal away
[15:11] <mvo> jdstrand: its fine, I want the PR in ASAP, but I also want it to be as good as possible as it changes one of our fundamental things :)
[15:11] <jdstrand> mvo: yes, I feel the same. with this we will have super-charged testing, which is always a good thing :)
[15:11] <mvo> jdstrand: yeah, I saw it. I'm more thinking about the bits around it, like how/when to build this C helper from the unit tests etc
[15:11]  * jdstrand nods
[15:12] <jdstrand> I'm going to step away for a little exercise but will be back in a bit
[15:12] <mvo> jdstrand: let me ponder a little bit, I whish golang would give me more control over the runtime
[15:12] <mvo> jdstrand: enjoy
[15:12] <jdstrand> mvo: yeah :\
[15:14] <zyga> mvo: welcome to my shoes :)
[15:14] <zyga> mvo: I really really wish golang had a "system" mode but it would run counter to the threading and io model
[15:34] <cjwatson> Can https://travis-ci.org/snapcore/snapd/builds/244975993 be retried?
[15:34] <zyga> yep
[15:35] <zyga> done
[15:35] <cjwatson> ta
[15:35] <ogra> ppisati, http://paste.ubuntu.com/24908787/ ... got the nanopi neo  booting with master-next (still a lot of =y that i need to sort, but getting there )
[15:36] <mup> PR snapd#3501 opened: store: orders API now checks if customer is ready <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3501>
[15:36] <ogra> elopio, hey
[15:40] <pedronis> cjwatson: is api/v2 also going to be api/v2/snaps/assertions ?
[15:40] <pedronis> or we don't know yet
[15:41] <cjwatson> pedronis: so eventually I expect yes, but I've been taking the approach that any API that I've basically just transcribed from something existing goes under /api/v1/snaps/ for now
[15:41] <cjwatson> pedronis: (following a discussion with William)
[15:42] <cjwatson> pedronis: v2 might get e.g. bulk endpoints
[15:42] <cjwatson> pedronis: and we can easily copy things over if we decide we remain happy with them
[15:43] <pedronis>   /snaps/assertions readds a bit weird to me
[15:43] <cjwatson> pedronis: so the policy is basically /api/v1/<anything else> -> old, legacy, busted, please don't use, only on search.apps.ubuntu.com; /api/v1/snaps -> current generation, may need work; /v2 -> new, not defined yet
[15:44] <cjwatson> pedronis: the api.s.i frontends disallow everything under /api/v1 that isn't /api/v1/snaps, because there was a bunch of other legacy stuff there
[15:44] <cjwatson> that we didn't want to expose on api.s.i
[15:44] <pedronis> because of things like account or account-key
[15:45] <cjwatson> for v2 I'd expect it to be /v2/assertions, not /v2/snaps/assertions
[15:45] <pedronis> ok
[15:45] <cjwatson> the snaps segment there is basically just so that we don't have to juggle too many haproxy rules for v1
[15:45] <cjwatson> it really means /api/v1/nottotalcrap
[15:46] <ogra> elopio, HAPPY BIRTHDAY !
[15:50] <koza_> orga, hey, there might be solution to hummingboard issue
[15:51] <koza_> ogra, fyi one has to blow USB fuses to force microSD boot
[15:52] <roadmr> happy birthday elopio \o/
[15:55] <ppisati> ogra: yeahhh! :)
[15:56] <ppisati> ogra: what are the boards you are working on?
[16:06] <ogra> koza_, blow ?
[16:07] <ogra> ppisati, orangepui zero and nanopi neo ... i also have an old bananapro lying here ... and popey said he was planning to get a nanopi air so i'll have a guineapig to make the wlan variant work as well
[16:08] <pedronis> cjwatson: I think this is something you wondered about in the past: https://forum.snapcraft.io/t/unify-asserts-errnotfound-and-store-assertionnotfounderror/1065
[16:08] <ogra> koza_, yoou mean like "physically break" or is that a SW thing
[16:08]  * zyga goes to pack
[16:10] <ogra> ppisati, also https://github.com/ogra1/orangepi-zero-gadget and https://github.com/ogra1/nanopi-neo-gadget for the u-boot gadgets ...
[16:12] <cjwatson> pedronis: It sounds like the sort of thing that might well have annoyed me when I was doing account-key stuff, though I don't remember for sure
[16:15] <koza_> ogra, irreversible change, take a look by yourself https://wiki.solid-run.com/doku.php?id=products:imx6:microsom:imx6-fuse
[16:17] <ogra> koza_, woah
[16:17] <ogra> thats really awful
[16:18] <ogra> koza_, so i cant get my board back to original state then :(
[16:19] <mup> PR snapcraft#1368 closed: cli: get_project_options must not discard kwargs <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1368>
[16:20] <koza_> ogra, yeah it is, where am I going to find windows based pc? ;-)
[16:20] <ogra> koza_, in a VM i guess :)
[16:21] <koza_> most probably there
[16:21] <ogra> oh man ...
[16:21] <ogra> why do people design such stuff ... /me shakes head
[16:23] <genii> ogra: Yes, I often wonder that also. Why not just have it so you can always choose what to boot from and screw fuses and other irreversible things
[16:24] <ogra> genii, the fun part is that the board has a bunch of jumpers for exactly that ...
[16:24]  * genii goes back to struggling with his NanoPi M3 now
[16:24] <ogra> genii, well, i just got my neo booting ubuntu core ;)
[16:24] <genii> Ah, nice
[16:25] <ogra> working on a generic allwinner kernel snap
[16:36] <popey> ogra: if you're gonna work on it, I'll absolutely get a nanopi air! :D
[16:36] <mvo> niemeyer: unless jdstrand disagrees I think 3431 is ready for a second review
[16:36] <niemeyer> mvo: Sweet, thanks!
[16:36] <ogra> popey, well, i got the neo booting ... afaik the air is identical with just an additional wlan chip
[16:36] <niemeyer> Getting to the bottom of the API key issue, I think
[16:36] <mvo> niemeyer: one of the very last questions/answers is about the testing, thats an area we are currently exploring, jamie prefers the kernel bpf for the testing instead of the bpf VM
[16:37] <mvo> niemeyer: but its all in the PR hopefully and I can answer any questions after dinner
[16:37] <niemeyer> mvo: Thanks again
[16:46] <popey> ogra: ordered
[16:46] <ogra> ha!
[16:46] <ogra> awesome
[16:46] <popey> expect weeks from china tho
[16:50] <Chipaca> niemeyer: in looking at this I'm wondering again about "snap start --enable foo" vs "snap enable-service --now foo"
[16:50] <Chipaca> niemeyer: should i resuscitate the forum thread?
[16:51] <niemeyer> Chipaca: You just did I think :D
[16:51] <Chipaca> not in the forum per se :-)
[16:51] <pedronis> in the total conversation space
[16:54] <popey> can I please point snapd people at https://forum.snapcraft.io/t/why-do-devmode-snaps-not-auto-update/1028
[16:54] <Chipaca> niemeyer: pedronis: in the forum now: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262/23?u=chipaca
[16:56] <Chipaca> popey: I can say for sure that it isn't a bug; it's very much intentional
[16:56] <Chipaca> popey: that is, it isn't a _code-level_ bug
[16:56] <Chipaca> popey: it might be a design-level bug :-)
[16:56] <Chipaca> pie-in-the-sky bug
[16:56] <Chipaca> mmm pie
[16:57]  * Chipaca takes a break that will not involve pie
[16:59] <niemeyer> popey: Let me try to find the prior discussion to copy there
[17:11] <mup> PR snapcraft#1370 closed: integrations: add the snapcraft Dockerfile <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1370>
[17:14] <jdstrand> mvo: I'm going to go through it top to bottom. I expect to give an Approved
[17:18] <niemeyer> jdstrand: Thanks for your attention on this one
[17:18] <jdstrand> np
[17:42] <niemeyer> ALRIGHT
[17:42] <Chipaca> INNIT
[17:42] <niemeyer> I think the auth issue is sorted
[17:43] <Chipaca> niemeyer: what was it?
[17:49] <niemeyer> Chipaca: Bug on the key reading logic.. bug surfaced after a second Linode backend was introduced in spread.yaml
[17:51] <Chipaca> niemeyer: heh. ok then :-)
[17:51] <Chipaca> EOD o'clock for me
[17:51] <Chipaca> ogra: https://bash.rocks/ just for you
[17:51] <ogra> hahaha
[17:53] <niemeyer> Chipaca: "bashing rocks" is exactly how I feel when writing shell
[19:20] <mup> PR snapcraft#1352 closed: Allow source-type to specify local <Created by jocave> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1352>
[20:16] <ondra> ogra ping
[20:16] <ogra> ondra, hey
[20:17] <ondra> ogra it's working for both
[20:17] <ondra> ogra dd and fastboot
[20:17] <ogra> oh, i didnt notice that
[20:17] <ondra> ogra that fastboot blob will create part table identical to when you dd
[20:18] <ondra> ogra just to have both options if anybody cares
[20:18] <ogra> ondra, yeah, as long as i can still just use ubuntu-image and get a single partitioned img file out, thats fine
[20:18] <ondra> ogra BTW I defo think step to convert u-boot to boot.img is missing in read me, without that it just does not work
[20:19] <ondra> ogra ubuntu-image works just like before, and up to you what method to install you choose
[20:19] <ogra> well, i want to re-work the gadgets anyway ... we can add that setp to the build
[20:19] <ondra> ogra and I think we can also use upstream u-boot
[20:20] <ogra> i dont think db410c was ever submitted upstream
[20:20] <ogra> (happy to be wrong though)
[20:21] <ondra> ogra I think it was
[20:22] <ogra> well, if it was we should definitely swithc over
[20:22] <ondra> ogra so v2017.5 tag does boot uboot. but fails to power mmc
[20:22] <ogra> i'll check that when i re-work the gadget
[20:22] <ondra> ogra give me sec, checking one thing
[20:22] <ogra> ah
[20:23] <ogra> btw, i got nanopi and oragepi zero roughly working ...
[20:24] <ondra> ogra nice!
[20:25] <ondra> ogra will confirm tomorrow, but I think tag v2016.05 from upstream will work
[20:25] <ogra> still a little work to do but the hard parts are done
[20:25] <ondra> ogra it has dragonboard410c config
[20:25] <ogra> ondra, yeah, no hurry ... i'll be in the office next week btw
[20:26] <ondra> ogra I wonder more how to support it more officially
[20:27] <ogra> what exactly ?
[20:27] <ogra> the db ?
[20:27] <ogra> cant be more official than now :)
[20:27] <ondra> ogra as we do not update u-boot now anyway, once you flash, you can actually use gadget for mmc
[20:27] <ondra> ogra emmc boot
[20:28] <ogra> well, an initrd with a dd script ... wrapped around the image
[20:28] <ogra> as one blob on an SD
[20:28] <ondra> ogra BTW how are dtb handled on dragonboard, do they need to be loaded by lk before u-boot?
[20:28] <ogra> boot the SD ... UI offers install
[20:28] <ogra> no
[20:28] <ogra> such awful design only exists on RPi
[20:29] <ondra> ogra does not matter how we install. it's more how we create image
[20:29] <ogra> for normal boards uboot is responsible for loading the dtb
[20:29] <ondra> ogra cool, as to build u-boot into boot.img it uses "fake dt and fake ramdisk"
[20:29] <ondra> ogra so lk is happy
[20:30] <ogra> are you in bluefin next week ? lets sit down and brainstorm some plans for installers ;)
[20:30] <ondra> ogra so yeah, we sort of need two gadgets, to build image for mmc and for emmc
[20:30] <ondra> ogra yeah I will be
[20:30] <ogra> yep
[20:30] <ogra> cool
[20:30] <ondra> ogra BTW u-boot has installing facility
[20:31] <ogra> yep
[20:31] <ogra> like dd
[20:31] <ondra> ogra I try to patch it a bit already with right files
[20:31] <ondra> ogra no, it uses actually that fastboot blob to repartition and then flash each partition from supplied file
[20:32] <ondra> ogra it has defined partition <> file map there
[20:32] <ogra> did you actually try that yet ?
[20:32] <ogra> the resize code might fall over
[20:32] <ogra> (during first boot)
[20:34] <ogra> HOOORRRRAAAAYYY !
[20:34] <ogra> https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner/+build/48484
[20:34] <ogra> it built !!!
[20:57] <jdstrand> roadmr: would you mind pulling r884 of CRT? it isn't urgent
[20:57] <roadmr> jdstrand: not a problem, here I go
[20:57] <jdstrand> roadmr: thanks!
[20:58] <ogra> http://paste.ubuntu.com/24911070/
[20:58] <ogra> :D
[20:59] <jdstrand> ogra: nice! :)
[20:59] <ogra> yeah ... not sure what to do with the kernel package though ...
[21:00] <ogra> it is based off master-next from the kernel team ... i'm pondering if i actullay want to be responsible for that :)
[21:01] <ogra> (it can only build on artful ... due to a hard gcc6 requirement of the allwinner bits ... so i have to jump through pkenty of hoops for every update currently)
[21:01] <ogra> OTOH thats probably fine for a developer community image ...
[22:33] <Chipaca> niemeyer: o/
[22:34] <niemeyer> Chipaca: o_/
[22:34] <Chipaca> niemeyer: what's the reasoning behind "restart --reload" instead of just "reload"?
[22:36] <niemeyer> Chipaca: The second part of the sentence.. "Daemons that do not support reloading are restarted instead as long as they were already running (systemd's try-reload-or-restart)."
[22:36] <Chipaca> niemeyer: tbh neither sits comfortably
[22:37] <niemeyer> Chipaca: That sounded like the best compromise when considering the options
[22:38] <niemeyer> Chipaca: The reload option that does nothing if the daemon doesn't support it feels bad, and using reload to restart without notice also feels bad
[22:38] <niemeyer> Chipaca: "restart --reload" doing the best it can out of both seems reasonable
[22:38] <Chipaca> niemeyer: documenting it is weird: restart restarts it if it's running, starts it if not; restart --reload reloads it if it is running and supports it, restarts it if running and does not, does nothing if not running
[22:39] <niemeyer> Chipaca: You're trying pretty hard to be confusing there :)
[22:39] <niemeyer> Chipaca: The sentence per the original forum post seems much simpler
[22:39] <Chipaca> niemeyer: i didn't mean "this is how you document it", i meant, these things don't mesh, and in documenting we'd try to describe them as a single thing
[22:39] <Chipaca> niemeyer: the sentence in the forum post tells the user to go read man systemctl
[22:40] <niemeyer> Chipaca: No, that was an implementation hint
[22:40] <niemeyer> This seems pretty clear:
[22:41] <niemeyer> snap restart <snap>[.<app>] – Restarts all daemons in the snap, or only the selected one if specified. Daemons which are not yet running will be started as well.
[22:41] <niemeyer> snap restart --reload <snap>[.<app>] – Reloads all daemons in the snap, or only the selected one if specified. Daemons that do not support reloading are restarted instead as long as they were already running.
[22:41] <Chipaca> niemeyer: but that's not how the 'snap restart --help' would get printed
[22:41] <Chipaca> snap restart: <does this thing> --reload <changes this thing into this other thing>
[22:42] <niemeyer> Chipaca: It can similar to that. We have other commands that provide examples and document them under snap.
[22:42] <niemeyer> Chipaca: I can also try to help on the review if you want
[22:42] <Chipaca> niemeyer: I'll implement it this way, but i'm pretty sure we're going to come back and tweak it later
[22:42] <Chipaca> niemeyer: don't review just yet, i'm about to push a change to the pr that's up
[22:43] <Chipaca> because i forgot to expose try-reload-or-restart
[22:43] <niemeyer> Chipaca: Sounds good, and thanks for the care being put on those commands. Appreciated.
[22:44] <Chipaca> niemeyer: one thing that's bothering me a little is the cute summary
[22:44] <Chipaca> niemeyer: in snapd it's fine, we don't i18n that
[22:45] <Chipaca> niemeyer: but as the status for the command, which would print something similar, it gets iffy
[22:45] <Chipaca> because we want to i18n those
[22:45] <Chipaca> and I don't know how to handle that properly
[22:45] <Chipaca> i'm pretty sure our i18n thing doesn't support plurals enough to do it 'right'
[22:46] <Chipaca> i worry too much; we don't have arabic nor belarusian nor welsh translations yet :-)
[22:47] <Chipaca> niemeyer: basically, languages where knowing which plural form to use requires a formula
[22:51] <niemeyer> Chipaca: Yeah, we'll need to worry about that at some point :)
[22:51] <Chipaca> niemeyer: e.g. polish has singular, then a plural for 2,3,4; then a plural for 5-21, a different one for 22-24, then 25-31, …
[22:52] <Chipaca> and i can't find anywhere that says how to do a list of e.g. "x, y, and z"
[22:52] <niemeyer> Chipaca: There are tricks we can use
[22:52] <niemeyer> Chipaca: Such as not using plural forms at all
[22:52] <Chipaca> like, never translate to polish
[22:52] <niemeyer> Chipaca: and that
[22:52] <niemeyer> :)
[22:52] <Chipaca> :-D
[22:53] <Chipaca> "your language is too complicated, so from now on you speak spanish"
[22:53] <niemeyer> zyga might agree
[22:54] <niemeyer> "We've upgraded your country to portuguese.. wait, no.. that was a downgrade.. esperanto!"
[22:54] <Chipaca> if we did that, there'd be *so* many smug people
[22:54] <niemeyer> Anyway, I should find dinner
[22:54] <niemeyer> In portuguese
[22:55] <niemeyer> Have a good night there
[22:55] <Chipaca> niemeyer: buen provecho! i'll probably be gone by the time you get back :-)
[22:56] <niemeyer> Gracias, una buena noche a usted
[22:56] <Chipaca> igualmente!
[23:01] <_28Kb> is there any visual tool for creating snaps yet? even anounced...
[23:06] <_28Kb> 21st century... extremely overrated
[23:07] <nacc> _28Kb: "visual tool"?
[23:07] <_28Kb> software for making snaps
[23:07] <ogra> a bit overkill give you create a single yaml file
[23:08] <ogra> *given
[23:08] <nacc> _28Kb: yeah, i think that's the wrong approach
[23:08] <nacc> _28Kb: what ogra describes is certainly the ideal, but generally
[23:08] <ogra> yeah, i'm an optimist ;)
[23:09] <nacc> heh
[23:12] <_28Kb> snappy promises new age of app managing... and basically stays same as traditional
[23:14] <nacc> _28Kb: i'm not sure what you're talking about?
[23:14] <nacc> _28Kb: yes, you still have to write code(ish) to package something, but snaps are way less and it's yaml
[23:14] <_28Kb> you make something with plugs and slots... and then time passes, your hair turn white and you see no progress
[23:15] <nacc> _28Kb: i'm not sure what a GUI would help with plugs and slots?
[23:15] <ogra> interface management in gnome-software is actively being worked on
[23:15] <nacc> ogra: i assume that's allowing you to manage what slots/interfaces various snaps are allowed to use?
[23:15] <ogra> yes
[23:15] <nacc> ogra: or something correct in the terminology :)
[23:16] <nacc> ogra: cool, that will be nice to see
[23:16] <ogra> but that has still nothing to do with creating a snap
[23:16] <nacc> right, that was going to be my next point :)
[23:16] <ogra> for which most people like to use github and build.snapcraft.io
[23:18] <nacc> but even then, i think _28Kb was referring to making the snap itself (like writing the code?). I'm not sure
[23:18] <ogra> that said ... if you have an idea how to do snap cration in a GUI way, nobody will block you _28Kb
[23:19] <_28Kb> i just wanted to create some opengl program... i must be a scientist for that i assume now
[23:19] <nacc> _28Kb: you don't have the program already?
[23:19] <_28Kb> i don't even have a platform
[23:20] <ogra> snap is a packaging and delivery mechanism ... you still need the app ... completely independent from the way you deliver it to users
[23:20] <_28Kb> i understand that, and i'm sad :)
[23:21] <ogra> (well, also a security mechanism etc ... there is definitely more to it than just delivery and such ... but still you need an app first :) )
[23:22] <ogra> integration snap building in various IDEs would surely make sense though
[23:23] <_28Kb> for me, it's ok for system to be read only... then i saw this snappy ideas.. i thought i'd be like in the ocean just swimming
[23:23] <ogra> well... you will drown if you dont learn to swim first
[23:24] <ogra> nobody "just jumps into the ocean"
[23:24] <ogra> and mind the sharks ...
[23:24] <ogra> ... with lasers ...
[23:24] <ogra> ;)
[23:24] <_28Kb> it's easier to make a better world with rifle and bullets
[23:25] <ogra> nah, violence is never the right answer
[23:25] <ogra> (well ... except in games :) )
[23:26] <_28Kb> it's easier to create your own framework than use existing ones...
[23:26] <_28Kb> people will help you by giwing the fish.. nobody learns you to do it yourself
[23:27] <_28Kb> surface everywhere.. nowhere the essence
[23:29] <ogra> so did you already try to package your opengl app as a snap ?  ... you wont learn it if you dont try it ...
[23:29] <_28Kb> i will
[23:30] <ogra> well, if you run into concrete problems, we are here to help ...
[23:30] <_28Kb> i found some snap similar to your nickname earlier... ogre or ogra (green dude)
[23:30] <ogra> heh
[23:31] <_28Kb> i thought i could play with OpenGL right away
[23:32] <ogra> you would play with opengl right away ... but outside of the snap ... once your app works, you snap it up
[23:32] <ogra> by simply creating a snapcraft.yaml
[23:33] <ogra> it is two separate things
[23:33] <_28Kb> i't like snap daddy... and you connect child snaps to it?
[23:33] <_28Kb> it's*
[23:35] <ogra> not really ... its more like a kindergarden full of children and you control the access to the play equipment on the playground
[23:35] <ogra> so first of all ... make children ;)
[23:35] <ogra> then build the kindergarden (snap) ...
[23:35] <ogra> then contol the access with interfaces (slots/plugs)
[23:37] <_28Kb> i'll try... ty for info
[23:37] <ogra> come back if you have more questions ...
[23:38] <_28Kb> ok :)
[23:38] <ogra> (not today anymore for me though ... 1:40 here, i'll go bedwards)