/srv/irclogs.ubuntu.com/2017/06/20/#snappy.txt

=== AdmWiggin is now known as tianon
=== chihchun_afk is now known as chihchun
mupPR snapd#3494 opened: tests: Restart rng-tools services after few seconds <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3494>03:41
=== chihchun is now known as chihchun_afk
mwhudsonhey guyz snapcraft fails tests with python 3.604:17
mupPR snapcraft#1318 closed: tests: refactor the travis jobs using stages <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1318>04:40
mupPR snapcraft#1291 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1291>04:55
mupPR 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>06:16
=== fnordahl_ is now known as fnordahl
mupPR snapd#3495 opened: tests: remove snapd before building from branch <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3495>07:07
=== mcphail_ is now known as mcphail
Chipacafgimenez: 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
morphisChipaca: you have a link?07:34
Chipacahttps://travis-ci.org/snapcore/snapd/builds/244733765#L65307:34
fgimenezChipaca: sure, looking07:35
fgimenezChipaca: morphis maybe the problem happens a bit earlier "Cannot install 'libudev-dev'"07:36
morphisyes, that looks like what it is07:36
morphisif the install command in pkgdb gets a list of packages it aborts on the first error07:37
Chipacaaborts but doesn't return an error?07:37
morphisah, but this is really gdebi07:37
morphisAFAIK it does07:38
Chipacaanyway, i really need to run07:38
Chipacao/07:38
morphishm, https://packages.debian.org/sid/libudev-dev is in all debian archives07:38
ograversion 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 iirc07:41
ogra)07:42
zygare08:05
zygaogra: hey08:12
ograyo08:12
zygaogra: do you have a moment?08:12
ograsure08:12
zygaogra: how can I run test-init without it being init08:13
zygaogra: I don't want to use break=... and then script the shelll that spawns (unreliable)08:13
ograzyga,  i meant the other way around08:13
ograand no, you shouldnt use break :)08:14
zygaogra: can you tell me what you mean then?08:14
ograzyga, you boot with boot=/test-init ...08:14
ograthat simply runs /init08:14
ograso that you get all the env bits you need08:14
zygaaha08:14
* zyga tries08:14
zygahmm08:14
ograthe environment and available devices differ between the stages08:15
ograand init makes sure to exec each bit in its assignedf stage08:15
zygaogra: so kernel command line would have boot=test-init08:15
ograright08:15
zygaogra: that wants to run /scripts/test-init08:15
zygaogra: how do I pass arguments to my init program?08:15
ograand test-init somehow needs toexec the scrip snippets at the step that init would use08:15
ogratake a look at it ... it read env vars08:16
ogra*reads08:16
* zyga looks08:16
ograevery ubuntu install has the script in /usr/share/initramfs-tools/init08:16
ograso no need to dig into the source ;)08:16
zygaTBH the whole exercise only made me want to write /init in C more than anyhting08:16
ograwell, thats something you should discuss with debian :)08:17
zygaall the complexity there and all the fragility08:17
zygawhy? is debian doing ubuntu-core? :D08:17
zygaogra: btw, I think I found a bug in the script08:17
ograno, but we use their inittamfs-tools package08:17
zygaogra: have a look at the FIXME I added08:17
ograyeah08:17
ograwe should just fix it ;)08:17
zygaogra: I'd like to do a pass and document and test some of those functions better08:17
ogra(well, we use debians package with ubuntu sauce on top indeed)08:18
zygaogra: right but I didn't want to bring that in with this patch, I want this to land08:18
zygaogra: I don't know if anyone else is doing this08:18
zygaogra: (testing initrd this way)08:18
zygaogra: but I wanted to show it is doable08:18
ogranope08:18
ograand 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-process08:18
zygaalso I'm sick08:18
ograso that we could just use it from there (and have someone else maintain the core part of it ;) )08:19
zygaand moving out day after tomorrow08:19
zygaand also sunburned and on painkillers08:19
ogra:(08:19
zygaso some adverse factors towards productivity08:19
zygaogra: I wrote the code to be modular and reusable, with some more polish this could be used to test any early boot scenario08:19
ograwell, we're not on a race, are we ?08:20
zygaogra: I'm mostly fond of the snapshot approach, which means this is blazingly fast08:20
zygaogra: well, I feel some pressure to finish this and move to snapd08:20
ograzyga, 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 package08:20
zygaogra: I had a look at a redhat paper describing qemu and kernel optimizations that allows them to boot a kernel i 150ms08:20
zygaogra: sounds like a good idea, I will08:21
ogra(alongside with landing it in our branch)08:21
ograif they take over we only need to care for the tests in the end08:21
ograand not for the framework08:21
ograand they get testing for free ;)08:21
=== cjwatson_ is now known as cjwatson
zygaogra: yeah08:24
zygaogra: well, let me try that change you suggested08:25
ograto 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 there08:26
zygaogra: I'm not yet sure if that's the approach to take but let me experiment and see what I can come up with08:27
ograand if you do that you can drop a lot of your code ... i.e. the bits that populate /dev and mount all the filesystems08:27
ogra(and use what /init does at the top)08:28
zygaINFO:qemu:(console) Begin: Mounting root file system ... /init: /scripts//test-init: line 1: syntax error: unexpected word (expecting ")")08:29
zygaogra: it seems that boot=test-init assumes everything is written in shell08:29
ograit shouldnt, that would be a kernel bug08:29
zygaINFO: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:30
* zyga feels dizzy again08:31
zygawhat a day :/08:31
ogratake a sick day ...08:31
ograseriously08:31
zygaone sec08:31
ograno, one day :P08:32
ogranot curing it just makes it last longer08:32
zygaogra: just sent you a pic08:32
zygaogra: everything looks like this around me08:32
zygadownstairs is mostly packed now08:32
ograyou picked the angle where i dont see the mountain of napkins around you :)08:33
zygaogra: they are behind me in the rubbish bin08:33
ograyeah, thought so :)08:33
pstolowskifgimenez, hey, i'm seeing a bunch of auth errors from linode on travis08:44
fgimenezhi pstolowski, do you have a link to the errors? sounds like something we can't help with, just to confirm08:47
pstolowskifgimenez, https://travis-ci.org/snapcore/snapd/builds/244606124?utm_source=github_status&utm_medium=notification08:47
fgimenezpstolowski: 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 travis08:51
* zyga de-conflicted https://github.com/snapcore/snapd/pull/346408:56
mupPR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>08:56
fgimenezpstolowski: 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 this09:01
pstolowskifgimenez, ack, thanks for looking into this!09:02
fgimenezpstolowski: yw :)09:03
zygahey pstolowski09:07
zygahow are you doing?09:08
pstolowskihi zyga! good, thanks! what's up?09:08
zygapstolowski: could you have a look at https://github.com/snapcore/snapd/pull/346409:08
mupPR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>09:08
zygapstolowski: patch by patch, it should be trivial to review as each diff fits on screen (just moves code from a to b)09:09
pstolowskizyga, very nice, i will09:11
zygapstolowski: dzięki :)09:12
cjwatsonCould somebody please retry the xenial-i386 test on https://github.com/snapcore/snapd/pull/3475 ?  It looks suspiciously not-a-problem-with-my-branch09:23
mupPR snapd#3475: store: change main store host to api.snapcraft.io <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3475>09:23
mvoactually, can someone do a second review on 3475 please? should be straightfoward (and an easy win)09:27
zygacjwatson: I don't know if anyone can do this easily09:31
zygacjwatson: I was talking to mvo about it a few days ago, that it is not easy to re-trigger those tests09:32
pedronismvo: I'll look at it in a bit09:32
cjwatsonzyga: What options do I have?09:33
mvocjwatson: no worries, once this has a second review it can go in09:34
mvocjwatson: 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 upload09:35
zygacjwatson: force push again, not sure09:36
cjwatsonAh, sounds like maybe I can just ignore the failing test then ...09:39
mvocjwatson: yes, this is our problem, not yours :)09:40
cjwatsonOK :)09:40
cjwatsonI like the sound of that.09:40
mupPR 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:02
pedronismvo: ^10:06
mvopedronis: yeah, just peeked (no pun intended) at it. I'm looking at debian unstable right now, breaks all our tests10:07
pedronismvo: just a heads up really, I understand getting 2.26 out is out first priority10:09
mvopedronis: thanks for this10:12
mupPR snapd#3497 opened: spread: help libapt resolve installing libudev-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/3497>10:15
Chipacamorphis: fgimenez: any luck with the debian thing?10:30
morphisChipaca: can you drop the quiet around that gdebi call so we can see why it fails to install libudev?10:31
Chipacamorphis: if the gdebi call failed the quiet would print the output. Is it not failing?10:32
Chipacaor rather, is it not returning with exit_failure?10:32
morphisit should as it prints out it can't install libudev for whatever reason10:33
Chipacai can also disable debian and let you dig; it's not just my PR that's failing in this way10:33
morphisno, don't disable debian10:33
morphisso something has changed which breaks this now10:35
Chipacaah, you mean the --quiet10:36
fgimenezChipaca: morphis snapd#3497 from mvo fixes it10:36
Chipacanot a prefix quiet but gdebi's --quiet itself10:36
mupPR snapd#3497: spread: help libapt resolve installing libudev-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/3497>10:36
Chipacaat what point did we regress prepare to run apt-get install eleventyfour times, once for each package we wanted to install?10:36
morphisah!10:37
Chipacawe'd got it reduced to a single call or two at most :-(10:37
Chipacabecause it added several minutes to the prepare time10:37
morphisChipaca: I have a change pending to improve the pkgdb for that10:38
Chipacamorphis: 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 level10:39
morphisChipaca: it abstracts package installation10:40
Chipacamorphis: yes, i get that10:40
morphisChipaca: you give it something "cups" and it will figure out the right thing to do10:40
Chipacamorphis: but does it make sense, given package names are going to be different?10:40
morphisit will map "cups" to the right packages for each distro10:40
morphisbased on the set SPREAD_SYSTEM10:40
Chipacamorphis: is "cups" a target, or a package name?10:41
Chipacadunno if "target" is the right name10:41
morphisit's a name of a thing you want to install10:41
morphisit can be a package name10:41
Chipacaso we're going to carry around a table of package names per distro?10:41
morphisyes10:41
morphisthat keeps these distro specific things out of the test cases10:42
morphisand you just have to express "I want cups"10:42
morphisChipaca: but doing more than on apt-get call per distro_install_package call isn't what we should do10:46
mupPR snapd#3498 opened: hooks: support for install and remove hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3498>11:09
mupPR snapd#3497 closed: spread: help libapt resolve installing libudev-dev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3497>11:12
morphismvo: btw. what is the state of the 2.26 release?11:23
pedronisChipaca: 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
pedronisare you doing anything strange?11:36
pedronisor it's a github bug11:36
mvomorphis: seccomp-bpf needs to get merged, then we are unstuck again12:03
morphismvo: ah12:03
morphismvo: any timeline for this?12:03
mvomorphis: jamie and I are working on this as quick as possible, the goal is before the end of this week12:04
mvohopefully sooner12:04
morphisok12:04
morphisnot pressure from my site, was just curious :-)12:04
morphismvo: 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 too12:04
zygapstolowski: small review of 349812:07
pedroniscjwatson: reviewed that PR, +1  , couple small remarks12:07
niemeyerMornings12:17
niemeyerHow's Travis behaving this morning?  Still issues?12:18
zygahey niemeyer12:18
* zyga hasn't seen any issues yet12:18
zyganiemeyer: have you seen this?12:19
zyga  12:19
zyga  12:19
zygaThis 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:19
niemeyerzyga: 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 sane12:20
niemeyerWe also saw at least once a message of packaging problems very early on in Travis setup land, before travis.yaml takes over12:21
zyganiemeyer: I saw a patch from mvo about debian and udev update, maybe that's that12:22
zyga(and also saw my branch fail on debian prepare)12:23
pedronisyes, things are failing on debian atm12:24
cjwatsonpedronis: thanks, pushed fixes12:25
fgimenezhey niemeyer, yes, we had authentication issues from travis to linode, seems to be better now12:30
niemeyerfgimenez: Any news from this morning?12:30
fgimenezniemeyer: 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:32
morphiszyga: ping12:33
zygamorphis: hey, what's up?12:35
morphiszyga: I am currently looking into a failure of tests/main/interfaces-content on Fedora, https://paste.ubuntu.com/24907862/12:36
morphiseffectively I don't see the bind mount in place so wondering what I should look at12:36
zygamorphis: looking12:36
zygawith master, I presume12:37
zygamorphis: any SELinux denials?12:37
morphisno12:37
morphisbut wait, maybe I have a clue12:37
zygamorphis: it's a new program, perhaps the policy is stale12:37
morphisthe 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:37
morphishah12:38
morphis$ echo $SNAP12:38
morphis/var/lib/snapd/snap/test-snapd-content-plug/212:38
morphisthat is the reason why12:38
mvomorphis: updated the forum12:38
morphismvo: thanks!12:38
=== jdstrand_ is now known as jdstrand
zygamorphis: I think we spoke about that12:38
zygamorphis: that $SNAP is wrong on Fedora12:38
morphiszyga: we did12:38
zygamorphis: I thought we fixed that but ... well :)12:39
zygamorphis: good catch12:39
morphiszyga: we fixed the content interface impl12:39
morphisbut as it seems not the part which sets up SNAP12:39
niemeyerfgimenez: That's the same we were observing yesterday12:43
niemeyerfgimenez: Please let me know if you see it again.. I'll tweak spread to debug the problem if so12:43
fgimenezniemeyer: sure, thx12:44
jdstrandmvo: 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 questions12:50
Chipacajdstrand: o/12:52
mvojdstrand: cool, let me read it now12:52
Chipacajdstrand: did you see me point you at a snap the other day?12:52
mvojdstrand: I think all your other suggestions are now implemented, thanks again12:52
jdstrandChipaca: I don't recall otoh. which snap?12:53
Chipacajdstrand: test-snapd-service-notify12:53
jdstrandmvo: thank you :) once you are ready, I wanted to go through it one more time top to bottom12:53
jdstrandoh I definitely didn't see that12:54
* jdstrand looks12:54
mvoChipaca: I can also approve snaps fwiw12:54
Chipacamvo: it's published :-)12:54
Chipacamvo: it's about it getting DENIEDs because it's notify12:54
jdstrandChipaca: ok, yes, it is in the store and published. what do you need?12:54
jdstrandah12:54
Chipacajdstrand: if you install it, you'll see denies12:55
Chipacajdstrand: 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
jdstrandChipaca: is this as script or compiled code? if compiled code, where is the source?12:55
Chipacaif the latter, i can file a bug and all :-)12:55
Chipacajdstrand: it's not compiled12:55
Chipacajdstrand: it's python, using the system python, and a sdnotify.py included in the snap12:55
jdstrandlet me look at it. I feel like I remember this was intentional12:55
mvoChipaca: aha, sorry, then I misunderstood12:56
jdstrandI remember we did talk about how you were seeing denials and would get back to me12:56
Chipacamvo: I don't know how you could've possibly misunderstood my vague insinuations at the half-formed predecessors of ideas12:56
Chipacajdstrand: this is that :-)12:57
jdstrandyeah, c'mon mvo12:57
jdstrandChipaca: yep :)12:57
mvoChipaca: lol12:57
mupPR 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>12:59
mvojdstrand: 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 something13:00
jdstrandmvo: it isn't the same bpf vm as the kernel and we can't launch programs under it13:03
jdstrandand so*13:03
jdstrandby 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 filter13:04
=== mhall119_ is now known as mhall119
jdstrandyou 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
jdstrandmvo: ^13:06
jdstrandChipaca: 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 snap13:19
jdstrandChipaca: this interface would consist of a comment along the lines of what I just mentioned and this rule '/run/systemd/notify w,'13:20
jdstrandChipaca: were you planning on using this mechanism by default?13:24
jdstrandChipaca: it looks like that interface could also include this rule: /{,usr/}bin/systemd-notify ixr,13:27
Chipacajdstrand: 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:27
mvojdstrand: 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 tests13:29
mvojdstrand: I look into this now13:29
Chipacajdstrand: 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:30
jdstrandChipaca: 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 code13:31
* Chipaca nods13:31
jdstrandmvo: yes, not advocating for removing the vm (though a fork/exec could handle the kill ok)13:32
jdstrandbut yeah13:32
VamsiHi, is it possible that the localhost has 2 login IDs?13:32
jdstrandChipaca: do you want me to dive deeper on that?13:32
jdstrandChipaca: I suspect I will only prove my assertion since the man page says that is what the api is designed to do13:33
Chipacajdstrand: and in any case we'd want the interface to support the broader use13:33
Chipacajdstrand: so, maybe jot it down to do in your copious free time13:33
ChipacaVamsi: pardon?13:33
Chipacajdstrand: it==the deeper dive i mean13:34
jdstrandChipaca: 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/capabilities13:34
VamsiChipaca: to login the local host is showing two ssh IDs.13:35
jdstrandChipaca: how about I just create the interface and then detail everything in comments?13:35
Chipacajdstrand: A+13:35
jdstrandI don't have any problem with the interface since users get to decide (or snap decls)13:35
Chipacayup13:36
jdstrandChipaca: when do you need this?13:36
VamsiFor example: blah@172.18.0.65 and blah@172.19.0.6513:36
Chipacajdstrand: no present urgency13:36
ChipacaVamsi: where are you seeing this? What is the system running?13:37
jdstrandChipaca: 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 sooner13:37
jdstrand)13:37
Chipacajdstrand: perfect, thank you13:38
* Chipaca watches Vamsi go off and is left wondering13:38
VamsiChipaca: I have connected my Ubuntu core local host to a monitor and that's where I see this.13:40
Chipacaogra: do you know if we print both addresses if you have more than one live interface?13:41
ograi think we do, yeah13:41
ChipacaVamsi: does your device actually have two network interfaces?13:41
ograthey both need to be up and have an assigned IP13:42
VamsiChipaca: I was initially using it on another network. And now changed the network.13:42
Chipacathat shouldn't cause it13:43
ograso ssh in ... run sudo console-conf and de-confiigure the unused interface13:43
Chipacaor should it?13:43
Chipacaogra: ?13:43
ograChipaca, well, if he used a fixed IP that IP would still be set13:43
Chipacaogra: right, but if it were fixed it wouldn't pick up a new one13:43
Chipacaogra: and if it's dynamic it should just pick up the new one13:44
ograon that device13:44
ChipacaVamsi: I didn't see you answer: do you actually have two network interfaces on this device?13:44
niemeyermvo, Chipaca: What builds were failing on the auth issue?13:44
Chipacaniemeyer: aw, i just restarted one13:44
Chipacaniemeyer: but, chances are it'll be back13:44
niemeyerChipaca: np, goal was to restart indeed.. do you have a link?13:44
Chipaca(travis is slow so it'll take a while to start)13:45
VamsiChipaca: No. only one at a time. I had to change to a different because of some reasons.13:45
niemeyerI've pushed an initial debug build of spread13:45
Chipacaniemeyer: https://travis-ci.org/snapcore/snapd/builds/244930470 is the one i just restarted13:45
niemeyerTHanks13:45
Chipacaniemeyer: seems to be 1:4 success rate right now, so you should see it fail again soon13:46
Chipacait just started, in fact13:46
niemeyermvo: Looks like yours passed13:46
mupPR 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
Chipacaniemeyer: it failed again13:46
mvoniemeyer: yeah, I had a bunch of issues this morning but the current one seems to be ok13:46
niemeyerChipaca: Great, let me see13:47
ChipacaVamsi: are you able to access the device?13:47
ChipacaVamsi: over the network to one of those two addresses?13:48
ChipacaVamsi: 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:48
Chipacaniemeyer: does that tell you anything?13:49
niemeyerChipaca: 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% sure13:52
Chipacaniemeyer: maybe do a 'printenv'-like thing?13:54
Chipacai thought we had a printenv but i guess we ditched to save space in the logs13:54
niemeyerChipaca: We do that already13:54
niemeyerChipaca: Right before the call to spread13:54
niemeyerChipaca: (it's folded)13:55
Chipacaah so we do13:55
niemeyerOkay, there we go again.. hold tight13:55
zygajdstrand: hey, can you review https://github.com/snapcore/snapd/pull/3464 please13:55
mupPR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>13:55
zygajdstrand: ideally before new interfaces land :)13:55
Chipacaniemeyer: -_- are you printing it at every api call?13:56
niemeyerChipaca: Oh no... it passed.. that's going to be a long log :)13:56
Chipacaniemeyer: that's a lot of api calls13:56
jdstrandzyga: yes it is on my list. it is after the bpf stuff atm13:56
Chipacaniemeyer: cancel the build, i'm told spread loves that13:57
niemeyerChipaca: Yeah, we monitor the machines to see if they go down13:57
zygajdstrand: perfect, thank you13:57
niemeyerChipaca: Because they take a very long time to restart..13:57
niemeyerI should optimize that so it uses less calls13:57
niemeyerAlright.. future runs won't print sooo much data14:03
roadmrniemeyer: hello :)14:20
roadmrniemeyer: when you have a sec we'd love your feedback in https://forum.snapcraft.io/t/edge-case-scenarios-for-snap-validations/103614:21
mupPR snapd#3499 opened: Spi patch <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>14:21
niemeyerChipaca: It passed, despite a reaaaaaaaly long log14:30
Chipacaniemeyer: I'm sorry14:30
niemeyerChipaca: :P14:31
niemeyerroadmr: Heya14:31
Chipacaniemeyer: maybe when somebody reviews it I'll have to change something and you'll get another chance14:31
niemeyerroadmr: Will look, thanks14:31
Chipacaniemeyer: meanwhile I've had fun making go throw errors I'd never seen before14:31
Chipacalike “write barrier prohibited by caller”14:32
* Chipaca has all the fun14:32
niemeyerChipaca: Wow, never seen that either14:32
Chipacaniemeyer: https://go-review.googlesource.com/c/43713/#message-52f9575a6a2544ad52ddaa588bfb29fb2e9feb3f14:33
Chipaca“dance for me, little robot-hamster-thing” “NO.”14:34
niemeyerChipaca: This seems closely related to the issue:14:55
niemeyerhttps://www.irccloud.com/pastebin/Tru74bnx/14:55
=== Elleo__ is now known as Elleo
niemeyerhttps://www.irccloud.com/pastebin/tu7rft1h/14:56
Chipacaniemeyer: ah, sorry, i didn't mean to send you down that rabbithole14:56
niemeyerChipaca: I'm not down into it.. was just overlooking it from afar.. :P14:57
Chipacaniemeyer: 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 do14:57
niemeyerMeanwhile, all PRs I try to debug are passing.. maybe that's the solution.. I just need to keep looking14:58
mupPR snapd#3500 opened: store: talk to api.snapcraft.io for assertions <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3500>14:59
zyganiemeyer: typical quantum CI bug15:00
mvojdstrand: 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 tests15:04
niemeyerOh, sweet.. some interesting debug info now.. the bug is definitely on the spread end..15:07
zygamvo: which prctl call do you need?15:08
jdstrandmvo: 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 matrix15:08
mvozyga: I have all the prctl stuff, I just get hangs and zombies when I apply it15:09
jdstrandmvo: the new implementation dropped that, but tested more, so it was kinda a wash. with my suggestion, we get better coverage in the new15:09
mvojdstrand: ok, I will create a tiny C helper for that then15:10
jdstrandmvo: 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 first15:10
jdstrandmvo: to be clear, you did see the C helper I pasted, right?15:10
jdstrand(in the PR)15:10
jdstrandit works so steal away15:11
mvojdstrand: 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
jdstrandmvo: yes, I feel the same. with this we will have super-charged testing, which is always a good thing :)15:11
mvojdstrand: 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 etc15:11
* jdstrand nods15:11
jdstrandI'm going to step away for a little exercise but will be back in a bit15:12
mvojdstrand: let me ponder a little bit, I whish golang would give me more control over the runtime15:12
mvojdstrand: enjoy15:12
jdstrandmvo: yeah :\15:12
zygamvo: welcome to my shoes :)15:14
zygamvo: I really really wish golang had a "system" mode but it would run counter to the threading and io model15:14
cjwatsonCan https://travis-ci.org/snapcore/snapd/builds/244975993 be retried?15:34
zygayep15:34
zygadone15:35
cjwatsonta15:35
ograppisati, 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:35
mupPR snapd#3501 opened: store: orders API now checks if customer is ready <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3501>15:36
ograelopio, hey15:36
pedroniscjwatson: is api/v2 also going to be api/v2/snaps/assertions ?15:40
pedronisor we don't know yet15:40
cjwatsonpedronis: 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 now15:41
cjwatsonpedronis: (following a discussion with William)15:41
cjwatsonpedronis: v2 might get e.g. bulk endpoints15:42
cjwatsonpedronis: and we can easily copy things over if we decide we remain happy with them15:42
pedronis  /snaps/assertions readds a bit weird to me15:43
cjwatsonpedronis: 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 yet15:43
cjwatsonpedronis: 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 there15:44
cjwatsonthat we didn't want to expose on api.s.i15:44
pedronisbecause of things like account or account-key15:44
cjwatsonfor v2 I'd expect it to be /v2/assertions, not /v2/snaps/assertions15:45
pedronisok15:45
cjwatsonthe snaps segment there is basically just so that we don't have to juggle too many haproxy rules for v115:45
cjwatsonit really means /api/v1/nottotalcrap15:45
ograelopio, HAPPY BIRTHDAY !15:46
koza_orga, hey, there might be solution to hummingboard issue15:50
koza_ogra, fyi one has to blow USB fuses to force microSD boot15:51
roadmrhappy birthday elopio \o/15:52
ppisatiogra: yeahhh! :)15:55
ppisatiogra: what are the boards you are working on?15:56
ograkoza_, blow ?16:06
ograppisati, 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 well16:07
pedroniscjwatson: I think this is something you wondered about in the past: https://forum.snapcraft.io/t/unify-asserts-errnotfound-and-store-assertionnotfounderror/106516:08
ograkoza_, yoou mean like "physically break" or is that a SW thing16:08
* zyga goes to pack16:08
ograppisati, also https://github.com/ogra1/orangepi-zero-gadget and https://github.com/ogra1/nanopi-neo-gadget for the u-boot gadgets ...16:10
cjwatsonpedronis: 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 sure16:12
koza_ogra, irreversible change, take a look by yourself https://wiki.solid-run.com/doku.php?id=products:imx6:microsom:imx6-fuse16:15
ograkoza_, woah16:17
ograthats really awful16:17
ograkoza_, so i cant get my board back to original state then :(16:18
mupPR 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:19
koza_ogra, yeah it is, where am I going to find windows based pc? ;-)16:20
ograkoza_, in a VM i guess :)16:20
koza_most probably there16:21
ograoh man ...16:21
ograwhy do people design such stuff ... /me shakes head16:21
geniiogra: 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 things16:23
ogragenii, 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 now16:24
ogragenii, well, i just got my neo booting ubuntu core ;)16:24
geniiAh, nice16:24
ograworking on a generic allwinner kernel snap16:25
popeyogra: if you're gonna work on it, I'll absolutely get a nanopi air! :D16:36
mvoniemeyer: unless jdstrand disagrees I think 3431 is ready for a second review16:36
niemeyermvo: Sweet, thanks!16:36
ograpopey, well, i got the neo booting ... afaik the air is identical with just an additional wlan chip16:36
niemeyerGetting to the bottom of the API key issue, I think16:36
mvoniemeyer: 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 VM16:36
mvoniemeyer: but its all in the PR hopefully and I can answer any questions after dinner16:37
niemeyermvo: Thanks again16:37
popeyogra: ordered16:46
ograha!16:46
ograawesome16:46
popeyexpect weeks from china tho16:46
Chipacaniemeyer: in looking at this I'm wondering again about "snap start --enable foo" vs "snap enable-service --now foo"16:50
Chipacaniemeyer: should i resuscitate the forum thread?16:50
niemeyerChipaca: You just did I think :D16:51
Chipacanot in the forum per se :-)16:51
pedronisin the total conversation space16:51
popeycan I please point snapd people at https://forum.snapcraft.io/t/why-do-devmode-snaps-not-auto-update/102816:54
Chipacaniemeyer: pedronis: in the forum now: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262/23?u=chipaca16:54
Chipacapopey: I can say for sure that it isn't a bug; it's very much intentional16:56
Chipacapopey: that is, it isn't a _code-level_ bug16:56
Chipacapopey: it might be a design-level bug :-)16:56
Chipacapie-in-the-sky bug16:56
Chipacammm pie16:56
* Chipaca takes a break that will not involve pie16:57
niemeyerpopey: Let me try to find the prior discussion to copy there16:59
mupPR snapcraft#1370 closed: integrations: add the snapcraft Dockerfile <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1370>17:11
jdstrandmvo: I'm going to go through it top to bottom. I expect to give an Approved17:14
niemeyerjdstrand: Thanks for your attention on this one17:18
jdstrandnp17:18
niemeyerALRIGHT17:42
ChipacaINNIT17:42
niemeyerI think the auth issue is sorted17:42
Chipacaniemeyer: what was it?17:43
niemeyerChipaca: Bug on the key reading logic.. bug surfaced after a second Linode backend was introduced in spread.yaml17:49
Chipacaniemeyer: heh. ok then :-)17:51
ChipacaEOD o'clock for me17:51
Chipacaogra: https://bash.rocks/ just for you17:51
ograhahaha17:51
niemeyerChipaca: "bashing rocks" is exactly how I feel when writing shell17:53
mupPR snapcraft#1352 closed: Allow source-type to specify local <Created by jocave> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1352>19:20
ondraogra ping20:16
ograondra, hey20:16
ondraogra it's working for both20:17
ondraogra dd and fastboot20:17
ograoh, i didnt notice that20:17
ondraogra that fastboot blob will create part table identical to when you dd20:17
ondraogra just to have both options if anybody cares20:18
ograondra, yeah, as long as i can still just use ubuntu-image and get a single partitioned img file out, thats fine20:18
ondraogra BTW I defo think step to convert u-boot to boot.img is missing in read me, without that it just does not work20:18
ondraogra ubuntu-image works just like before, and up to you what method to install you choose20:19
ograwell, i want to re-work the gadgets anyway ... we can add that setp to the build20:19
ondraogra and I think we can also use upstream u-boot20:19
ograi dont think db410c was ever submitted upstream20:20
ogra(happy to be wrong though)20:20
ondraogra I think it was20:21
ograwell, if it was we should definitely swithc over20:22
ondraogra so v2017.5 tag does boot uboot. but fails to power mmc20:22
ograi'll check that when i re-work the gadget20:22
ondraogra give me sec, checking one thing20:22
ograah20:22
ograbtw, i got nanopi and oragepi zero roughly working ...20:23
ondraogra nice!20:24
ondraogra will confirm tomorrow, but I think tag v2016.05 from upstream will work20:25
ograstill a little work to do but the hard parts are done20:25
ondraogra it has dragonboard410c config20:25
ograondra, yeah, no hurry ... i'll be in the office next week btw20:25
ondraogra I wonder more how to support it more officially20:26
ograwhat exactly ?20:27
ograthe db ?20:27
ogracant be more official than now :)20:27
ondraogra as we do not update u-boot now anyway, once you flash, you can actually use gadget for mmc20:27
ondraogra emmc boot20:27
ograwell, an initrd with a dd script ... wrapped around the image20:28
ograas one blob on an SD20:28
ondraogra BTW how are dtb handled on dragonboard, do they need to be loaded by lk before u-boot?20:28
ograboot the SD ... UI offers install20:28
ograno20:28
ograsuch awful design only exists on RPi20:28
ondraogra does not matter how we install. it's more how we create image20:29
ografor normal boards uboot is responsible for loading the dtb20:29
ondraogra cool, as to build u-boot into boot.img it uses "fake dt and fake ramdisk"20:29
ondraogra so lk is happy20:29
ograare you in bluefin next week ? lets sit down and brainstorm some plans for installers ;)20:30
ondraogra so yeah, we sort of need two gadgets, to build image for mmc and for emmc20:30
ondraogra yeah I will be20:30
ograyep20:30
ogracool20:30
ondraogra BTW u-boot has installing facility20:30
ograyep20:31
ogralike dd20:31
ondraogra I try to patch it a bit already with right files20:31
ondraogra no, it uses actually that fastboot blob to repartition and then flash each partition from supplied file20:31
ondraogra it has defined partition <> file map there20:32
ogradid you actually try that yet ?20:32
ograthe resize code might fall over20:32
ogra(during first boot)20:32
ograHOOORRRRAAAAYYY !20:34
ograhttps://code.launchpad.net/~ogra/+snap/linux-generic-allwinner/+build/4848420:34
ograit built !!!20:34
jdstrandroadmr: would you mind pulling r884 of CRT? it isn't urgent20:57
roadmrjdstrand: not a problem, here I go20:57
jdstrandroadmr: thanks!20:57
ograhttp://paste.ubuntu.com/24911070/20:58
ogra:D20:58
jdstrandogra: nice! :)20:59
ograyeah ... not sure what to do with the kernel package though ...20:59
ograit is based off master-next from the kernel team ... i'm pondering if i actullay want to be responsible for that :)21:00
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
ograOTOH thats probably fine for a developer community image ...21:01
=== sarnold_ is now known as sarnold
=== Eleventh_Doctor is now known as Pharaoh_Atem
Chipacaniemeyer: o/22:33
niemeyerChipaca: o_/22:34
Chipacaniemeyer: what's the reasoning behind "restart --reload" instead of just "reload"?22:34
niemeyerChipaca: 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
Chipacaniemeyer: tbh neither sits comfortably22:36
niemeyerChipaca: That sounded like the best compromise when considering the options22:37
niemeyerChipaca: The reload option that does nothing if the daemon doesn't support it feels bad, and using reload to restart without notice also feels bad22:38
niemeyerChipaca: "restart --reload" doing the best it can out of both seems reasonable22:38
Chipacaniemeyer: 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 running22:38
niemeyerChipaca: You're trying pretty hard to be confusing there :)22:39
niemeyerChipaca: The sentence per the original forum post seems much simpler22:39
Chipacaniemeyer: 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 thing22:39
Chipacaniemeyer: the sentence in the forum post tells the user to go read man systemctl22:39
niemeyerChipaca: No, that was an implementation hint22:40
niemeyerThis seems pretty clear:22:40
niemeyersnap 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
niemeyersnap 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
Chipacaniemeyer: but that's not how the 'snap restart --help' would get printed22:41
Chipacasnap restart: <does this thing> --reload <changes this thing into this other thing>22:41
niemeyerChipaca: It can similar to that. We have other commands that provide examples and document them under snap.22:42
niemeyerChipaca: I can also try to help on the review if you want22:42
Chipacaniemeyer: I'll implement it this way, but i'm pretty sure we're going to come back and tweak it later22:42
Chipacaniemeyer: don't review just yet, i'm about to push a change to the pr that's up22:42
Chipacabecause i forgot to expose try-reload-or-restart22:43
niemeyerChipaca: Sounds good, and thanks for the care being put on those commands. Appreciated.22:43
Chipacaniemeyer: one thing that's bothering me a little is the cute summary22:44
Chipacaniemeyer: in snapd it's fine, we don't i18n that22:44
Chipacaniemeyer: but as the status for the command, which would print something similar, it gets iffy22:45
Chipacabecause we want to i18n those22:45
Chipacaand I don't know how to handle that properly22:45
Chipacai'm pretty sure our i18n thing doesn't support plurals enough to do it 'right'22:45
Chipacai worry too much; we don't have arabic nor belarusian nor welsh translations yet :-)22:46
Chipacaniemeyer: basically, languages where knowing which plural form to use requires a formula22:47
niemeyerChipaca: Yeah, we'll need to worry about that at some point :)22:51
Chipacaniemeyer: 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:51
Chipacaand i can't find anywhere that says how to do a list of e.g. "x, y, and z"22:52
niemeyerChipaca: There are tricks we can use22:52
niemeyerChipaca: Such as not using plural forms at all22:52
Chipacalike, never translate to polish22:52
niemeyerChipaca: and that22:52
niemeyer:)22:52
Chipaca:-D22:52
Chipaca"your language is too complicated, so from now on you speak spanish"22:53
niemeyerzyga might agree22:53
niemeyer"We've upgraded your country to portuguese.. wait, no.. that was a downgrade.. esperanto!"22:54
Chipacaif we did that, there'd be *so* many smug people22:54
niemeyerAnyway, I should find dinner22:54
niemeyerIn portuguese22:54
niemeyerHave a good night there22:55
Chipacaniemeyer: buen provecho! i'll probably be gone by the time you get back :-)22:55
niemeyerGracias, una buena noche a usted22:56
Chipacaigualmente!22:56
_28Kbis there any visual tool for creating snaps yet? even anounced...23:01
_28Kb21st century... extremely overrated23:06
nacc_28Kb: "visual tool"?23:07
_28Kbsoftware for making snaps23:07
ograa bit overkill give you create a single yaml file23:07
ogra*given23:08
nacc_28Kb: yeah, i think that's the wrong approach23:08
nacc_28Kb: what ogra describes is certainly the ideal, but generally23:08
ograyeah, i'm an optimist ;)23:08
naccheh23:09
_28Kbsnappy promises new age of app managing... and basically stays same as traditional23:12
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 yaml23:14
_28Kbyou make something with plugs and slots... and then time passes, your hair turn white and you see no progress23:14
nacc_28Kb: i'm not sure what a GUI would help with plugs and slots?23:15
ograinterface management in gnome-software is actively being worked on23:15
naccogra: i assume that's allowing you to manage what slots/interfaces various snaps are allowed to use?23:15
ograyes23:15
naccogra: or something correct in the terminology :)23:15
naccogra: cool, that will be nice to see23:16
ograbut that has still nothing to do with creating a snap23:16
naccright, that was going to be my next point :)23:16
ografor which most people like to use github and build.snapcraft.io23:16
naccbut even then, i think _28Kb was referring to making the snap itself (like writing the code?). I'm not sure23:18
ograthat said ... if you have an idea how to do snap cration in a GUI way, nobody will block you _28Kb23:18
_28Kbi just wanted to create some opengl program... i must be a scientist for that i assume now23:19
nacc_28Kb: you don't have the program already?23:19
_28Kbi don't even have a platform23:19
ograsnap is a packaging and delivery mechanism ... you still need the app ... completely independent from the way you deliver it to users23:20
_28Kbi understand that, and i'm sad :)23:20
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:21
ograintegration snap building in various IDEs would surely make sense though23:22
_28Kbfor 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 swimming23:23
ograwell... you will drown if you dont learn to swim first23:23
ogranobody "just jumps into the ocean"23:24
ograand mind the sharks ...23:24
ogra... with lasers ...23:24
ogra;)23:24
_28Kbit's easier to make a better world with rifle and bullets23:24
ogranah, violence is never the right answer23:25
ogra(well ... except in games :) )23:25
_28Kbit's easier to create your own framework than use existing ones...23:26
_28Kbpeople will help you by giwing the fish.. nobody learns you to do it yourself23:26
_28Kbsurface everywhere.. nowhere the essence23:27
ograso did you already try to package your opengl app as a snap ?  ... you wont learn it if you dont try it ...23:29
_28Kbi will23:29
ograwell, if you run into concrete problems, we are here to help ...23:30
_28Kbi found some snap similar to your nickname earlier... ogre or ogra (green dude)23:30
ograheh23:30
_28Kbi thought i could play with OpenGL right away23:31
ograyou would play with opengl right away ... but outside of the snap ... once your app works, you snap it up23:32
ograby simply creating a snapcraft.yaml23:32
ograit is two separate things23:33
_28Kbi't like snap daddy... and you connect child snaps to it?23:33
_28Kbit's*23:33
ogranot really ... its more like a kindergarden full of children and you control the access to the play equipment on the playground23:35
ograso first of all ... make children ;)23:35
ograthen build the kindergarden (snap) ...23:35
ograthen contol the access with interfaces (slots/plugs)23:35
_28Kbi'll try... ty for info23:37
ogracome back if you have more questions ...23:37
_28Kbok :)23:38
ogra(not today anymore for me though ... 1:40 here, i'll go bedwards)23:38

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