kyrofaogra_, I suppose you're long gone into the night?00:07
kyrofaogra_, when you get in tomorrow: how hard would it be to fix https://bugs.launchpad.net/snappy/+bug/1650207 ? No ROS stuff will build in classic mode00:26
kyrofaOh, it's writable in classic, handy00:44
stokachuif i have an additional top level command 'conjure-down' for this do i need to register with the store to have that alias created?02:43
mhall119ahoneybun: it would be better off with a Qt5 part, it doesn't need all of KDE02:44
=== chihchun_afk is now known as chihchun
mupPR snapd#2666 closed: interfaces: add ability to set system time zone to timeserver_control interface <Created by justincan> <Closed by justincan> <https://github.com/snapcore/snapd/pull/2666>08:43
mupPR snapd#2679 opened: Ubuntu/14.04 <Created by vosst> <https://github.com/snapcore/snapd/pull/2679>08:43
mupPR snapd#2585 closed: debian: move systemd files out of ./debian and into ./data/systemd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2585>08:43
mupPR snapd#2680 opened: interfaces: shutdown: also allow shutdown/reboot/suspend via logind <Created by morphis> <https://github.com/snapcore/snapd/pull/2680>08:43
mupPR snapd#2681 opened: tests: only build test binaries if they are not present <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2681>08:43
diddledanjdstrand: I may have an idea why other snaps than my own corebird-diddledan aren't able to launch URLs via xdg-open. I need to test it, but I did NOT build my snap with the snapd-glib interface but bundled glib into my snap directly09:06
zygadiddledan: hey, I think this part is broken/needs love09:14
zygadiddledan: it's on our roadmap but always has low priority and gets postponed09:14
zygamvo: ^^ FYI09:14
diddledanzyga: the confusing bit was my own snap works as it should, but jdstrand had noticed other snaps not working correctly which prompted questions as to what was different about my snap that made mine work09:16
zygadiddledan: so to make it work you need two pieces09:16
zygadiddledan: and because it has been a bit neglected we don't have a well designed responsiblity as to who owns them09:16
zygadiddledan: on the desktop side you need snapd-xdg-open installed, in theory snapd should recommend that on the destkop09:17
zygadiddledan: on the othoer hand, core snap (or ubuntu-core) should ship the shim xdg-open from snapd-xdg-open09:17
zygadiddledan: AFAIK neither are true now09:17
zygadiddledan: if you install snapd-xdg-open on your desktop manually09:17
zygadiddledan: and build and install the shim in your snap manually09:17
zygadiddledan: then I believe, apart from bugs in the actual shim, it should work09:18
zygadiddledan: it's just not what we want people to have to go through :/09:18
diddledanzyga: I only installed snapd-xdg-open. jdstrand tested on his system so it's not something specific to my system09:18
diddledanzyga: as I say, corebird-diddledan WORKS CORRECTLY. it is OTHER snaps ON THE SAME SYSTEM WHERE MINE WORKS that fail09:19
diddledanI wasn't shouting there, but wanted to highlight the important bits, sorry if it appears aggressive - wasn't meant to be09:20
zygadiddledan: no, that's fine09:21
zygadiddledan: if corebird works ok but others don't then I suspect they don't ship the shim09:21
diddledanI don't ship the shim in mine09:21
diddledanI did absolutely nothing special apart from installing snapd-xdg-open on the host09:22
zygadiddledan: feels like magic, is there xdg-open in the core/ubuntu-core snap?09:23
diddledanbut even if it is in the core snap, that would suggest that other snaps should also work when they currently do not ON THE SAME SYSTEM09:24
diddledanok, the xdg-open shim is NOT in core NOR is it in corebird-diddledan09:26
diddledanit doesn't exist09:26
diddledanat all09:26
zygadiddledan: as I said, this story is neglected, I may be missing something, those other snaps may have tried to make it work but did something that made it more roken09:26
diddledanyeah that's what we want to understand. the WHY09:27
diddledanpersonally I'm happy that mine works. for the project it needs to be understood what is different09:28
zygadiddledan: hmm09:31
zygadiddledan: is your snap classic?09:31
zygadiddledan: (it should never work then)09:31
zygadiddledan: how do you observe it working?09:31
zygadiddledan: (in any case, there's a well-known list of things to do to fix this)09:31
zygadiddledan: do hello-xdg-open snap09:31
zygadiddledan: I bet it won't work if you run xdg-open09:31
zygadiddledan: maybe there's a dbus service that also opens URLs that is somehow allowed via unity09:31
* zyga has huge lag to IRC network09:31
diddledanmy snap is strict confinement09:31
diddledanI observe it working by clicking links or other actions that open a url directly from corebird09:32
zygadiddledan: and then your browser opens?09:34
zygadiddledan: I don't have time to investigate this now09:34
zygadiddledan: if you want to do that, I suggest stracing your application to see if it fork/execs something09:34
diddledanyes it does09:34
diddledanwell blow me down. it's _stopped_ working now09:39
diddledanI've not changed _anything_ and now it no longer works09:40
zygawell, at least that is good09:41
zygait should not have worked09:41
zygadid you run the app outside of confinement / sandbox by any chance09:41
zygae.g. running it directly from /snap/$SNAP_NAME/current/...09:41
diddledanI'm unsure now09:42
zygado what I suggested09:43
zygayou may get it to work for real then09:43
ogra_hmm, still all bots gone09:47
niemeyermup: you ok?11:19
mupniemeyer: I really wish I understood what you're trying to do.11:19
ogra_bug 1234511:19
mupBug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> <https://launchpad.net/bugs/12345>11:19
niemeyerogra_: mup back with its usual mood11:19
ogra_yeah, looks fine11:19
mupPR snapd#2724 opened: overlord,tests: have enable/disable affect security profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/2724>11:53
mupPR snapd#2725 opened: overlord/ifacestate: use ParseConnRef <Created by zyga> <https://github.com/snapcore/snapd/pull/2725>12:09
mupPR snapcraft#1079 opened: Add snapcraft plugin for Qt Build Suite (qbs) <Created by dpniel> <https://github.com/snapcore/snapcraft/pull/1079>12:24
mupBug #1659534 opened: userdel doesn't supports extrausers <Snappy:New> <shadow (Ubuntu):New> <https://launchpad.net/bugs/1659534>12:29
=== yofel_ is now known as yofel
mupPR snapd#2726 opened: interfaces: core-support: also allow enable/disable of a systemd unit <Created by morphis> <https://github.com/snapcore/snapd/pull/2726>13:26
mupPR snapd#2725 closed: overlord/ifacestate: use ParseConnRef <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2725>13:33
zygakirkland: hey, any update on that bug?13:39
zygakissiel: ^13:39
zyga(sorry kirkland)13:39
kissielzyga: https://bugs.launchpad.net/snapd/+bug/1659272; nope; @ mtg13:41
mupBug #1659272: dbus access denied in nested python  <snapd:New> <https://launchpad.net/bugs/1659272>13:41
zygakissiel: thanks13:41
jdstrandkyrofa: hi! remember the ca-certificates-java thing? I have an extra clue. if I build a snap that stage-packages openjdk-8-jre-headless and ca-certificates-java but doesn't have either of those installed on the system as debs, I get snapcraft creating a dangling symlink:13:44
jdstrand/home/ubuntu/snappy-apps/minecraft-snap/parts/minecraft/install/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts will be a dangling symlink13:44
zygajdstrand: hey, morning :)13:45
jdstrandkyrofa: if I use the same stage-packages but install the debs on the system, snapcraft finds it and uses the system one and the snap is fine:13:45
jdstrandCopying needed target link from the system /etc/ssl/certs/java/cacerts13:45
jdstrandhey zyga :) fyi 2718 and 2658 are at the top of my list today13:46
zygajdstrand: no worries, we're busy with a release :)13:46
zygajdstrand: the update-ns PR is does not need a deep review now (it should not land yet), I just wanted to get first impression13:46
* kirkland waves at zyga14:06
stokachuslangasek, what day does the SRU team normally process verification-done bugs?14:21
stokachuslangasek, or if you could flip the bit on snapd 2.21 so it'll make it into xenial-updates today that would be even better :)14:24
mhall119rmescandon: ping, I saw that you have a Solr snap in the store, have you been in contact with the upstream to see if they will adopt it?14:27
rmescandonmhall119, nope14:28
rmescandonmhall119, https://issues.apache.org/jira/browse/SOLR-1004414:45
jdstrandmhall119: hey, fyi, I issued snap declarations for dbus for two kde snaps and approved them, but they still need to be released (btw, why isn't apachelogger here?)14:46
rmescandonmhall119, no problem in moving code to another organization/place if needed14:46
slangasekstokachu: the SRU team releases SRUs Mon-Thu; I'll look at snapd now15:29
stokachuslangasek, awesome ty!15:29
morphisogra_: how do I do a let n=n+1 with /bin/sh?15:32
ogra_morphis, n=$((n+1))15:33
morphisogra_: thanks15:33
ogra_np :)15:33
mhall119thanks rmescandon15:40
mhall119thanks jdstrand15:40
ogra_morphis, you kept "let n=n+1" in the upper function ...15:53
ogra_also check if it works with non-integers ... i'm not sure it does15:54
ogra_(or probably set wait_time=1 instead)15:54
ogra_ogra@localhost:~$ n=$((n+0.1))15:55
ogra_-bash: n+0.1: syntax error: invalid arithmetic operator (error token is ".1")15:55
morphisogra_: can you comment that in the MP?15:58
mupPR snapd#2727 opened: overlord/ifacestate: register all security backends with the repository <Created by zyga> <https://github.com/snapcore/snapd/pull/2727>15:58
ogra_morphis, oh, sorry, i mis-took wait_time for wait_attempts ... all good15:59
morphisok :-)15:59
ogra_morphis, btw, probably good to bookmark this https://wiki.ubuntu.com/DashAsBinSh has all the POSIX vs bashism bits16:02
ogra_(including let)16:03
morphisogra_: thanks16:03
Chipacamorphis, o/16:05
Chipacamorphis, dunno if my review made sense16:05
Chipacathe `while $n -lt 10 $wait_attempts ! is_ssh_unit_enabled` line is fairly borked :-)16:05
morphisChipaca: thanks16:07
kyrofajdstrand, interesting-- the broken symlink is an absolute one, I assume?16:19
jdstrandkyrofa: it points to /etc/ssl/certs/java, yes16:20
jdstrandwhich doesn't exist in core16:20
jdstrandthe review tools notice that, but a locally installed snap user might not16:21
kyrofajdstrand, indeed... hmm. Perhaps the repo should be rewriting stage package symlinks16:21
mupPR snapd#2728 opened: tests: add extra debugging to security-setuid-root test <Created by zyga> <https://github.com/snapcore/snapd/pull/2728>16:23
kyrofaHey ogra_, how hard of a bug is https://bugs.launchpad.net/snappy/+bug/1650207 ?16:49
ogra_kyrofa, i landed a potential fix for it today ... not sure if mvo did re-build the edge core snap already since16:50
ogra_there was a release going on today to i didnt touch the build button16:50
kyrofaAnd will the fix mean that /etc/lsb-release is different in the core snap, or only in the classic shell?16:50
kyrofaogra_, awesome, thanks for working on that :)16:51
ogra_kyrofa, in the classic shell16:51
kyrofaogra_, will it be exactly xenial's, then?16:52
ogra_but the classic shell tarball is created during build of the core snap ;)16:52
ogra_the classic snap just unpacks it16:52
ogra_so the fix is in the core snap build itself16:52
kyrofaI suppose that does make sense. So they're intrinsically tied, eh?16:52
ryebotAre there docs for the snapd-control interface?16:53
ogra_the tarball contains all bits that we rip out during build :)16:53
ryebotnot a pressing thing, just curious about it16:53
kyrofaogra_, heh. So the /etc/lsb-release in the classic shell will be exactly xenial's?16:53
ogra_if the fix works, yes16:54
kyrofaogra_, excellent, thanks for the update!16:54
ogra_havent tested it yet ... i simply "dpkg -i" the original base-files package16:54
kyrofaryebot, what kind of documentation are you looking for?16:54
ogra_(but i'm not 100% sure it will overwrite the modified lsb-release file ... thats up for testing still)16:55
ryebotI just want to know what it can do, more or less16:55
kyrofaryebot, we have an Interfaces wiki: https://github.com/snapcore/snapd/wiki/Interfaces#snapd-control16:55
kyrofaBut it doesn't say much16:55
ryebotDoes it allow you to launch other snap's apps?16:55
kyrofaryebot, it allows the snap to talk to the snapd socket (install/update/remove snaps over REST API)16:55
kyrofaryebot, no16:55
mupPR snapd#2729 opened: tests: use test snap <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2729>16:56
ryebotokay, understood; thanks for the typically quick response :)16:56
kyrofaryebot, that interface is used for example by snapweb. Have you used that?16:56
ryebotI have, yes16:56
ryebotI was toying with the idea of writing a snap that hooked into custom urls to install/launch other snaps16:57
kyrofaryebot, that's a confined snap, but it allows you to search for/install snaps by talking to snapd. The only way it can talk to snapd like that is via the snapd-control interface16:57
ryebotmakes sense16:57
kyrofaryebot, I think such a utility would need to be outside confinement. It sounds like the snap-xdg-run utility that supports opening URLs from snaps16:58
kyrofa(not sure that's actually what it's called... but it's something like that :P )16:58
ryebotoh cool, thanks, I'll look into that16:58
kyrofaryebot, talk to jdstrand, he knows all16:58
jdstrandryebot: snapd-control does not allow launching other snaps. nothing does in strict confinement atm. snapd-xdg-open allows running a url handler, but that isn't tied into snaps yet17:01
ryebotthat's understandable17:02
mvoogra_: not rebuild anything yet, feel free to do that17:02
jdstrandryebot: you are probably interested in https://bugs.launchpad.net/snappy/+bug/163974617:02
mupBug #1639746: Snap launching other snaps <snapd-interface> <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1639746>17:02
ryebotjdstrand: yep! just signed up, thanks :)17:03
jdstrandryebot: the point of confinement is that snaps can't interfere with each other. transitioning from one confinement to another while honoring that requirement is tricky17:05
kyrofaogra_, if you happen to get a new classic into edge, I'd be happy to test it17:05
ogra_kyrofa, core you mean :)17:05
ogra_it is all in core17:06
kyrofaogra_, well, both, right? :P17:06
ryebotjdstrand: yeah, no doubt17:06
kyrofaogra_, wait... how does the classic snap update?17:06
kyrofaogra_, so the classic snap literally installs and then unpacks something that core is holding onto?17:06
kyrofaI thought you extracted that from core and put it into the classic snap, they were just released in lockstep17:06
ogra_the classic snap unsquashes core ... then unpacks the tarball (from insiode core) on top17:07
ogra_if classic gets updated nothing happens17:07
kyrofaogra_, what if I've already run that step? Will classic notice it's out of date?17:07
ogra_no, we dont fiddle with developer chroots once they are created17:07
ogra_its up to you to apt update/upgrade it then17:07
kyrofaogra_, ah interesting. So if I've already created that chroot, will an apt upgrade get me a new /etc/lsb-release?17:08
kyrofaogra_, can I kill the chroot and re-create it, then?17:08
ogra_apt-get install --reinstall base-files perhaps17:08
ogra_that should work17:09
kyrofaogra_, where is it, so that I can kill it?17:09
ogra_snap remove classic17:09
kyrofaOh, well.17:09
ogra_its in the common dir of the classic snap17:09
kyrofaogra_, perfect, thank you. Okay so then: if you happen to publish a new core snap with this change, please let me know, I've got a dragonboard setup I can use to test it17:11
kyrofaogra_, thanks for the explanation, I understand classic mode quite a lot more now17:11
ogra_i just triggered a new core build ... in ~30min there should be a new one in edge17:12
stokachuslangasek, thanks for the push to updates17:19
stokachuquestion, I'm about to upload a new revision of my conjure-up snap that has a new binary called 'conjure-down' do I need to ask someone to register an alias to conjure-down?17:21
kyrofastokachu, good question. Do you already have an alias?17:21
kyrofastokachu, I mean, do your aliases already auto-connect?17:21
stokachukyrofa, not that i know of17:22
stokachuso i have https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml17:22
kyrofaAh, then you don't need to talk to anyone. You can declare interfaces all day long, but snapd won't automatically enable them for you (or your users) without someone flipping a switch in the assertion store-side17:22
jdstrandstokachu: you can have as many aliases as you want to declare. users manullay add them to the system so there is nothing to worry about on the store end. only if you weant the alias auto-added do you need to ask a reviewer to grant that to you17:22
kyrofaArgh, not interfaces-- aliases17:22
kyrofaI type that word too much17:22
jdstrandman, I can't type17:23
stokachuso i would like to have them auto connected, do i need to upload the snap with the alias defined beforehand?17:23
kyrofajdstrand, you always make me feel better17:23
jdstrandkyrofa: thanks? :P17:23
kyrofajdstrand, :P17:23
jdstrandstokachu: it doesn't matter17:23
kyrofaI suspect just uploaded PERIOD so it has an ID17:24
stokachujdstrand, so i want to create the conjure-down alias for https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml#L1517:24
stokachumy snap is already uploaded it just doesn't have that latest build17:24
jdstrandstokachu: done17:25
stokachujdstrand, awesome ty!17:25
stokachunow that 2.21 is in xenial-updates i can finally flip the switch to pure snap of conjure-up17:25
stokachuwell classic snap anyway17:25
stokachujdstrand, do i still need to add the aliases: [conjure-down] in my snapcraft?17:26
jdstrandstokachu: yes17:27
kyrofajdstrand, are aliases individually granted? Or do you just say "yes, this snap can automatically have any aliases it declares"?17:27
stokachuperfect thanks17:27
mupPR snapd#2730 opened: snap: be more helpful in the `snap install <already-installed>` error message <Created by mvo5> <https://github.com/snapcore/snapd/pull/2730>17:28
jdstrandstokachu: you have to let snapd know what the aliases are. once it knows what they are, it looks at the snap declaration to see what to auto add17:28
stokachujdstrand, ack, makes sense ty17:28
niemeyerjdstrand: ping17:34
jdstrandniemeyer: hey17:34
niemeyerjdstrand: Heya17:35
niemeyerjdstrand: Today we've been having a long debate about the configure script for core17:35
niemeyerjdstrand: Lot's of back and forth on several details17:36
niemeyerjdstrand: By now it's getting pretty obvious that we want direct systemctl access on it17:36
jdstrandniemeyer: morphis let me in a few of those details17:36
jdstrandniemeyer: I thought he was able to use dbus-send fine?17:37
niemeyerjdstrand: I know you were against that, and I could see why.. wondering if some of your worries are relieved by having the interface as core-support17:37
niemeyerjdstrand: No, that was the first impression, but it's actually very messy17:37
=== chihchun is now known as chihchun_afk
* jdstrand notes he say later commits to his hook17:37
niemeyerjdstrand: We can't easily tell the result of the call.. the original hook was doing stop, but we really want stop+disable17:38
niemeyerjdstrand: So there's a loop in there, which isn't nice because it's waiting regardless of knowing why17:38
niemeyeretc etc17:38
niemeyerjdstrand: So the proper thing to do was to wait for the job, as systemctl does, ...17:38
niemeyerjdstrand: This is getting unwise to pursue, IMO17:39
jdstrandniemeyer: from my perspective, the security policy is clean right now with core-support, and that was my primary concern. the fact that only core can use it is important, yes, but systemctl isn't written with mediation in mind, so I didn't like all the extra unrelated security policy17:39
jdstrandniemeyer: if you want systemctl, then just put systemctl Uxr, in the policy17:39
jdstrandniemeyer: then we aren't pretending anything with the confinement17:40
niemeyerjdstrand: +117:40
niemeyerjdstrand: Given this is just an extension of snapd, I think that's okay17:40
jdstrand'Uxr' says systemctl can run unconfined17:40
niemeyerjdstrand: It's not quite ideal, but an excellent start IMO17:40
niemeyerjdstrand: The high-level goal of that one setting is precisely to have a properly abstracted way to enable and disable ssh in pure snap systems17:41
jdstrandniemeyer: it is good for the configure hook. it is poor from a security policy perspecitve. it is acceptable based on base declaration restrictions17:41
niemeyerjdstrand: If we render it technically flaky, or end up giving up altogether and putting the logic into the snapd binary proper, it won't be any better17:42
jdstrandniemeyer: this achieves that goal, but does not restrict it to only that goal17:42
jdstrandwhich is what I really didn't like17:42
niemeyerjdstrand: It doesn't on itself, but arguably the configure of core, specifically, is bound to be doing system-level configuration on behalf of the user and of other snapd that have snapd access17:43
jdstrandthere are ways to do stopping/starting/disabling/enabling services properly, but that couldn't be implemented today17:43
jdstrandniemeyer: that's why I said the base declaration makes it 'acceptable'17:43
niemeyerjdstrand: Ok, thanks17:44
niemeyerjdstrand: Let's move on with this then, and learn our lessons on the way17:44
jdstrandniemeyer: can someone ping me on the updated PR if this is time-sensitive?17:44
niemeyerjdstrand: It is time sensitive, and morphis plans to be doing work on it tomorrow morning17:46
niemeyerjdstrand: I'll mail him with the outcome of our conversation and one more detail today17:46
jdstrandroadmr: hi! would you mind pulling r833 of the review tools. it isn't terribly urgent (next week would be 'ok'). sonner is better, but don't feel like you have to do extraordinary measures17:49
jdstrandroadmr: also, I had the idea of shipping the review tools as a snap and floated that out to cprov. He loved it. that would allow staging to point at edge and prod stable and then no more pulls17:50
jdstrandsergiusens: this also means snapcraft could call the review tools if the command was available (ie, the snap installed) and we'd never have to worry about an out of date deb17:51
jdstrandsergiusens: ^17:51
jdstrandsergiusens: you could finally run the review tools and have confidence that what they and the store report was the same17:53
roadmrjdstrand: awesome idea on the snap!!!!17:57
cprovjdstrand: yup, instead of channels we we actually need refresh-control server side, but having the review-tools as a snap will be definitely an improvement17:58
roadmrjdstrand: having the service be mutable and update some component out-of-release-cycle sounds a bit scary, we try not to have mutable services, but totally worth a think. cprov this would be my main concern17:59
roadmr(so don't think I'm opposed, on the contrary, but we need to consider implications)17:59
roadmrjdstrand: also... sure, r833 coming up in a sec !17:59
jdstrandroadmr: a nice property is that the review tools run confined17:59
jdstrandmoving to a snap is not super soon in the queue, but I'll let you guys know when it is then you can start using it whenever you want18:00
roadmrthanks jdstrand ! yes, because it'll have implications on how the service is deployed and hosted. Weighing immutability vs. confination will make for a fun exercise18:05
jdstrandroadmr: I was mostly saying that it is a benefit. wasn't arguing immutability18:07
roadmrjdstrand: yes, I absolutely agree on the benefit of confination18:08
roadmrjdstrand: hehe so again please don't take my ramblings as any sort of pushback, I think it's an awesome idea and once the snap is available I'm happy to push for that to be the way we use the tools. I'll find a way to deal with any other concerns18:09
jdstrandsounds great :)18:09
mupPR snapd#2717 closed: interfaces: builtin: mir: allow recv and send <Created by albaguirre> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2717>18:17
mupPR snapcraft#1076 closed: autotools: extend Make plugin instead of repeating code <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1076>18:36
KristijanZicHello, got one question18:38
kyrofaHey there KristijanZic, fire away :)18:38
KristijanZicDoes snappy hard depend on Systemd? Could it be ported one day to BSD?18:38
KristijanZickyrofa: ^18:44
kyrofaKristijanZic, at the moment yes, systemd is a hard dependency. But the spec doesn't require it18:44
kyrofaKristijanZic, when one writes a snap that declares a service, the keys one uses to describe the service behavior (simple daemon, forking, etc.) would need to be satisfiable by the given system, and snapd would need to support it18:45
mupPR snapcraft#1080 opened: python plugin: avoid the use of PYTHON* env vars <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1080>18:45
kyrofaKristijanZic, as of right now, the only system supported is systemd18:45
kyrofaKristijanZic, but that may be refactored at some point18:46
dstolfakyrofa, it would be beneficial to make it extensible so that other service management systems could easily be hooked in with a form of a plugin or something. Once they're stable enough, potentially upstreamed18:46
KristijanZickyrofa: ah, not what I was hoping for but I hope that gets redesigned.18:46
sergiusensjamespage, stokachu, marcoceppi_ hey, mind testing this branch https://github.com/snapcore/snapcraft/pull/1080 ? It sort of solves the PYTHON* env var leaking but want to be sure it still works for you18:47
mupPR snapcraft#1080: python plugin: avoid the use of PYTHON* env vars <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1080>18:47
KristijanZickyrofa, thanks! :)18:47
kyrofadstolfa, I wholeheartedly agree, but there's always work to be done. The question is the priority that should be associated to such work18:47
marcoceppi_sergiusens: how do I test that branch? you got a snap ;)18:49
dstolfakyrofa, well, it could be done in a privsep way, that is separating the actual plugin that does it into different components, such as systemd, launchd, SMF, ..., and then have the standard functionality that it needs to provide. Somewhat similar to what the MAC framework does in FreeBSD. Now, that's probably not so much of an urgency, but I would be willing to write such a plugin once we have a service management system in place in FreeBSD(current w18:49
dstolfaI believe that people would find use of it on Apple systems though, through launchd which can provide such behaviour18:50
sergiusensmarcoceppi_, from source right now; I intend to have a solid snap on classic thing going soon but this branch needs to get in first18:50
kyrofadstolfa, well, you're assuming that the REST of snapd's dependencies are available on such systems as well18:50
kyrofaWhich isn't necessarily the case18:50
marcoceppi_sergiusens: I'll add it to my todo, won't have much time today18:50
kyrofadstolfa, I'm really talking about apparmor here18:50
dstolfakyrofa, I'm not aware of all the dependencies, is there a list somewhere?18:50
sergiusensmarcoceppi_, no problem, thanks18:50
kyrofadstolfa, the confinement tech isn't available everywhere18:51
kyrofadstolfa, in fedora they have selinux, for example18:51
dstolfaAh, well that's really just a form of access control, couldn't it be extensible?18:51
sergiusensmarcoceppi_, if not, give me your branch and tell me what to run to ensure it all works ok (to smoke it a bit)18:51
kyrofadstolfa, indeed, but you see how this blossoms18:51
dstolfaThat way, if someone wanted to, one could apply even things like grsec RSBAC to it18:51
dstolfakyrofa, well, it does. There is work to be done, but imo would be useful to do eventually, as the need arises :)18:51
kyrofadstolfa, right, I completely agree18:52
marcoceppi_sergiusens: https://github.com/juju-solutions/charm-pkg it's here for now, need to move the snapcraft yaml into the project root now that I've removed all the weird workaround files18:52
marcoceppi_sergiusens: once built and installed, try `charm version; charm create foobar; cd foobar; charm build`18:52
kyrofadstolfa, don't get me wrong, I think we can all agree we'd like to see snapd everywhere. But I'd rather have a good product in less places than a bad product everywhere because we devoted all our time to that18:52
marcoceppi_sergiusens: if you get tracebacks, you know something went wonky18:53
dstolfaThe only requirement in doing so really, is just keeping the dependencies in check -- that is, not allowing dependencies to branch out too much, rather wrapping them so that it's an easier job later on.18:53
dstolfakyrofa, agreed there.18:53
marcoceppi_sergiusens: just pushed up the latest changes18:54
dstolfaEither way, be right back. Food :)18:54
sergiusensmarcoceppi_, thanks!19:00
mupPR snapcraft#1081 opened: local source: preserve symlinks to directories <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1081>20:45
mupPR snapd#2697 closed: cmd,snap,wrappers: systemd reload command support <Created by cyberb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2697>20:46
mupPR snapd#2728 closed: tests: add extra debugging to security-setuid-root test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2728>20:49
mupPR snapd#2696 closed: spread: set SNAPD_DEBUG=1 in the core snap as well <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2696>21:00
mupPR snapd#2690 closed: daemon: add location header to reply for snap operations like install/remove <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2690>21:08
mupPR snapcraft#1073 closed: project: snapcraft.yaml in a snap directory <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1073>21:18
mupPR snapcraft#1082 opened: project: new plugin directory location <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1082>23:09

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