=== tsimonq2alt is now known as tsimonq2 [02:18] PR snapd#1651 opened: More create-user fixes === chihchun_afk is now known as chihchun [03:34] PR snapd#1652 opened: Correct interface connection JSON documentation (used an object inste… [03:54] PR snapd#1653 opened: Correct documentation on refresh action (referred to an old update ac… [04:47] PR snapd#1654 opened: Fix typo mutlipart -> multipart === hikiko_ is now known as hikiko [06:47] PR snapd#1654 closed: Fix typo mutlipart -> multipart [06:50] PR snapd#1652 closed: Correct interface connection JSON documentation (used an object inste… [06:53] good morning [07:08] good morning zyga [07:11] I wonder is there a way to refer to snap paths like $SNAP_DATA from the snapcraft yaml when specifying commands [07:12] I have a forking daemon, and wonder if I could modify it's "command" to include such [07:12] that would allow to avoid a lot of glue-code just to pass the right config file directory [07:12] I have seen in snappy-playpen others used a launcher.sh to pickup the path [07:12] but there could (should?) be a way to do e.g. [07:12] command: usr/local/sbin/ntpd -c $SNAP_DATA/etc/ntpd.conf [07:13] maybe just the right amount of escaping ... [07:13] the given example above resolves to just /etc/ntpd.conf for now [07:29] hmm - just wondered about the ML archives - was the snappy-devel list discontinued for the snapcraft list? [07:30] "Please use https://lists.ubuntu.com/mailman/listinfo/snapcraft instead." [07:30] ah yes, ok [07:34] cpaelzer: hey [07:35] cpaelzer: the command field of each app should be able to resolve environment variables (they are just copied and eventually are resolved by the shell) [07:35] cpaelzer: hmm [07:36] cpaelzer: can you look at the prime directory and see if it is resolved early? My point is that it should be present there verbatim, as you spelled it above [07:36] yeah I just examined the systemd service [07:36] it is just referring to its "usual" warpper [07:36] cpaelzer: and it doesn't contain $SNAP_DATA? [07:36] it does [07:37] so the wrapper is "good" [07:37] let me check all of this for typos and such [07:37] exec "$SNAP/usr/local/sbin/ntpd" -c $SNAP_DATA/etc/ntpd.conf "$@" [07:37] cpaelzer: hmm cna you pastebin the systemd unit? [07:37] sure, just a sec [07:37] systemd http://paste.ubuntu.com/22782806/ wrapper http://paste.ubuntu.com/22782810/ [07:38] uh that is nice [07:38] zyga: I found it [07:38] it is actually an application issie I think [07:38] service snap.ntpsec.ntpd status reports 30780 /snap/ntpsec/x1/usr/local/sbin/ntpd -c /var/snap/ntpsec/x1/etc/ntpd.conf [07:38] so it did resolve [07:38] yes, it looks correct [07:39] I was tricked by seeing that in journal for it "getconfig: Couldn't open : No such file or directory" [07:39] so it is more an app bug to ignore its arg for whatever reason [07:39] Tried building and installing the ubuntu-clock-app example with snapcraft + snap install now. I get the following errors: "libGL error: failed to load driver: swrast" "Unrecognized OpenGL version". [07:39] anyway it was good to go down the snap-systemd unit -> wrapper -> command path at least once [07:39] Should this work with the current version of snapcraft and snap? [07:39] zyga: thanks [07:40] dragly: does the old version from the store work? [07:41] what's the name in the store? [07:41] dragly: ubuntu-calculator-app [07:43] can't find anything with that name in Ubuntu Software nor with apt [07:43] I'm running Ubuntu 16.04 [07:45] the one I tested was from https://github.com/ubuntu/snappy-playpen [07:48] dragly: snap find clock gives me "ubuntu-clock-app" from the store [07:49] trying to install now on my16.40 just to check [07:52] dragly: fetch & install from store worked fine - was your issue that the one from playpen didn't build or install ? [07:52] ah, sorry, I forgot that snap install != apt install [07:53] cpaelzer: it both builds and installs, but when running I get the OpenGL errors [07:53] hi, guys! [07:53] same with the one from "snap install ubuntu-clock-app" [07:54] running the one from store http://paste.ubuntu.com/22783564/ (works) [07:54] Anynews on Ubuntu core and RPI3? [07:54] cpaelzer: doesn't work here, seems to be the same issue as others are reporting: https://askubuntu.com/questions/759647/opengl-error-in-snaps-ubuntu-16-04/760096#760096 [07:55] I had the same issue previously, but thought it was fixed [07:56] I think there is a bug report on it somewhere. Let me see if I can dig it up. [07:57] cpaelzer https://bugs.launchpad.net/snappy/+bug/1574851 [07:57] Bug #1574851: libgl not found on nvidia machines (so far)

[07:59] I haven't tried to workaround, but will be distributing an app to others with Nvidia machines, so I'm wondering if there's anything I can do without having to ask the users to copy the nvidia libGL.so to /var/lib/snapd/lib/gl ? [08:05] dragly: can you please try to install "snap-confine ubuntu-core-launcher" from xenial-proposed? that should fix the nvidia problem [08:05] mvo, hey [08:05] mvo: I understand that there are some regressions that are blocking the update out of the SRU proposed pocket, correct? [08:05] hey seb128 [08:06] zyga: yes, however I think those got all resolved by now, I think its good to go now [08:07] mvo: including the one you pinged me about last week, the X11 one? [08:07] mvo, attente, unsure when/where snapd-xdg-open was discussed but I would like to start a discussion about removing the whitelist, filed https://github.com/ubuntu-core/snapd-xdg-open/pull/12 for that but maybe a mailing list would be better? can you do suggestions? [08:07] PR ubuntu-core/snapd-xdg-open#12: don't restrict the urls that are handled [08:08] zyga: yes, this no longer happens with snapd 2.11 and I think its was adt artifcat [08:09] seb128: iirc gustavo suggested to put this in place, he is probably the best one to discuss how to ease/remove it [08:12] mvo: that's good to know, thank you [08:13] mvo, ok, thanks, I'm unsure what we protect against and ideally we are going to want to let apps open the urls they handle, like skype handles x-scheme-handler urls and you are going to want that to work without us having to patch the helper to know about every application on earth [08:13] x-scheme-handler/skype I meant [08:16] mvo: did you get the "add to whitelist" syntax wrong on https://github.com/snapcore/snapd/pull/1651 ? [08:16] PR snapd#1651: More create-user fixes [08:17] mwhudson_: I did, thanks! should be fixed now [08:17] mwhudson_: congratulations to your family :) [08:17] zyga: thanks :) [08:18] mvo: i'm hacking on adding --sudoer and --yaml flags now [08:29] the 'details' link on the test results on my PR isn't working for me [08:29] "162.213.35.179 took too long to respond" [08:32] mwhudson_: on integration tests? [08:32] yeah [08:32] mwhudson_: that's over VPN [08:32] oh [08:32] mwhudson_: aka annoying ylink [08:33] not very community? [08:33] but not too bad for me :) [08:34] ah duh [08:34] zyga, mvo: what does snappy think about rebasing? [08:36] mwhudson_: doesn't like it much [08:36] mwhudson_: merges are more welcome [08:37] zyga: well my PR fails a test [08:37] mwhudson_: merge with master to fix it (if that fixes it) [08:37] zyga: i could rebase and fix the problem, or push a new commit [08:37] it's a real problem :) [08:37] oh, just push a new fixing commit then [08:38] ok [08:38] related [08:38] can i run the integration tests locally easily [08:38] ? [08:38] mwhudson_: sure [08:39] mwhudson_: with the exception of magic version of ubuntu-device-flash you should just be able to run run-tests --integration [08:39] mwhudson_: it's tad slow though [08:39] the u-d-f from http://people.canonical.com/~mvo/all-snaps/16/ should work with this [08:39] mwhudson_: maybe something has changed since I first looked, fgimenez knows this part better than I do [08:39] mwhudson_: so just staick that in your $PATH and you should be ok [08:39] s/staick/stick/ [08:40] ok [08:40] my link is laggy today, downloading some stuff for work later [08:42] Hi, is there a quick way to get out of "error: cannot remove "X": snap "ipe" has changes in progress" limbo [08:42] I already tried to restart snapd but that did not help [08:46] * mwhudson_ lols at the ascii art "crushing failure and despair" [08:47] imexil: can you tell me what does "snap changes" say [08:48] well I cancelled an install with CTRL+C and that's what it is still doing. [08:48] imexil: unlike apt or yum, snapd remembers and retries requests [08:48] mvo: Sorry, I managed to overlook your message earlier. Installed snap-confine ubuntu-core-launcher now. [08:48] zyga: 123 Doing 2016-08-09T08:14:25Z - Install "ipe" snap from file "ipe_7.2.5_amd64.snap [08:48] Now ubuntu-clock-app.clock returns "multiple nvidia drivers detected, this is not supported. errmsg: No such file or directory" [08:48] imexil you just quit the front end, the backend (snapd) is still doing what you asked it to do [08:49] dragly: can you report a bug on snap-confine [08:49] dragly: with all the details you can add [08:49] zyga: so how do I kill the backend? [08:49] dragly: and pastebin "ls -d /usr/lib/nvidia*" please? [08:50] dragly: especially output of /usr/lib/nvidia-[1-9][0-9][0-9] [08:50] imexil: you don't have to [08:50] zyga: Sure! Do you happen to know what returns the error message so that I can try to figure out why it detects multiple versions? [08:50] I get /usr/lib/nvidia/ /usr/lib/nvidia-352/ /usr/lib/nvidia-361/ /usr/lib/nvidia-361-prime/ [08:50] imexil: what do you want toarchive? [08:50] *achieve [08:50] dragly: yes, I wrote that code :/ [08:51] The install on this machine is an upgrade, could that be why I have multiple nvidia versions in that folder? [08:51] zyga: well I can't do anything since it just sits there in limbo for 30 mins or more now [08:51] dragly: can you try rmeomving all except the one you actually want to use [08:51] imexil can you do this: snap abort 123 [08:51] (123 i the identifier of the task) [08:51] s/task/change/ [08:51] zyga, mwhudson_, mvo yep, with the new udf all should be fine to run the remaining integration tests (most of them have been ported to spread) [08:51] you can salso see snap change 123 [08:51] for details [08:51] zyga: Thanks! [08:52] That worked === om26er__ is now known as om26er [08:52] imexil: note that if you had killed snapd it would just restart the next time and resumed the whole activity [08:53] I see. [08:55] i think http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/4144/console is going to make me very upset with adduser(1) [08:56] zyga: I tried to remove the nvidia-352 with "sudo apt remove nvidia-352" and also checked dpkg --get-selections for any other nvidia packages. However, the folder still remains. I'll remove it manually now, but I suspect the script might need to verify if multiple packages are really installed. [08:56] dragly: what is inside? [08:56] I currently only find libnvidia-fbc.so.1@ libnvidia-wfb.so.1 in the folder [08:56] two dead symlinks to libnvidia-fbc.so.352.63 and libnvidia-wfb.so.352.63 [08:57] dragly: you can use dpkg -S to find which package puts stuff inside that folder [08:57] dragly: yeah, please try to remove them [08:57] uh [08:57] seems like noone is taking responsibility for those files [08:58] how _do_ you add a user to a group with extrausers [08:58] dragly: then they must be created by postinstall scripts [08:59] now I'm back to the "libGL error: failed to load driver: swrast" [09:00] dragly: hmm [09:00] trying to update all packages with xenial-proposed now [09:00] I guess snapd should be updated too? [09:02] dragly: snapd doesn't affect this but sure [09:02] dragly: you can update it [09:02] dragly: I think someone with nvidia hardware of the same / similar era should be able to explore this bug in detail [09:04] can i d/l an ubuntu-core image yet? [09:06] oh, http://people.canonical.com/~mvo/all-snaps/16/ [09:07] zyga: Sure. I would also be happy to explore it further myself. Should any links have automatically been created in /var/lib/snapd/lib/gl/ with the above packages installed? Currently this folder is empty. [09:31] uh does libnss-extrausers just not support supplementary groups at all [09:33] Tried the workaround by copying the files from nvidia-* to /var/lib/snapd/lib/gl, but that didn't work either. [09:51] mvo, so i'm a bit desparate with my kernel snap creation ... whatever i try with u-d-f i can not get any working arm images (funnily kvm works, even if the kernel package isnt built correctly) ... when i mount a pi2 or dragonboard image after dd'ing i end up with: [09:51] ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/ [09:51] unset [09:52] dragly: re, sorry I was on a call [09:52] dragly: it is a bit magic, you need to read this to understand what is going on [09:52] dragly: http://www.zygoon.pl/2016/08/snap-execution-environment.html [09:53] dragly: the only way to see the actual environment is to experience it at runtime, try the hello world snap or anything that includes bash (I use snapd-hacker-toolbelt snap) [09:53] dragly: then you can see what the /var/lib/snapd/lib/gl folder really contains [09:53] dragly: you should also, after you get familiar with the ideas, look at github.com/snapcore/snap-confine [09:54] dragly: there's src/mount-support-nvidia.c there that does all the nvidia work [09:54] dragly: so please explore that and get in touch when you have some ideas [09:54] ogra_: is this a sideloaded kernel? [09:54] yes [09:54] i didnt want to upload potentially broken ones to the store [09:55] I am running snappy on my RPi2 after a while, seems there is no longer enable-classic command ? Was that removed or is that another way for that ? [09:56] (and currently my kernel build script is broken wrt pi2 so i cant quickly give you something to test) [09:56] ogra_: aha, ok. I think that is the issue, i.e. a bug in that code path [09:56] downloaded from https://people.canonical.com/~mvo/all-snaps/16/ [09:56] ah, phew [09:56] mvo, another thing ... did you ever try to reboot a kvm image 3-4 times ? [09:56] hey ogra_ how are you doing? :-) [09:57] about the 3rd time it wipes the grub variables [09:57] ogra_: magic broken grub thing? [09:57] ogra_: I have a vague idee what it is, I can give you something in maybe 1h or so, just ping me when you have your script ready again [09:57] yeah [09:57] mvo, ok [09:57] om26er: please try "snap install classic" [09:57] ogra_: uh :( does it happen if you randomly reboot in the middle of the boot process? [09:57] ogra_: or normal reboots? [09:57] normal reboots [09:58] fresh install, do the first boot and check you can log in ... reboot ... do that again ... grub dead [09:58] ogra_: ta, I have a look [09:58] i forgot if it is the second or third time ... but it is reliably reproducable [09:58] ta [09:58] * zyga recalls checkbox reboot stress test (just 30 reboots) [09:59] mvo, says snap not found [09:59] yeah, that would have hit it quickly [09:59] om26er: sorry, "sudo snap install --devmode classic" [09:59] om26er, --devmode --edge [09:59] ogra_, does --edge give me yakketty ? [10:00] uh uh is /etc/sudoers.d supposed to be writable? [10:00] mvo, also, if you check the store ... ubuntu-core auto-uploads work ... i talked to jdstrand_ about getting an exception into the review tools to auto-publish (i was hoping it was done today, seems not... i should have turned off auto-build :) ) [10:00] mwhudson_, yes, cloud-init needs to put a file in there [10:01] zyga: Ok, thanks. I'll try to package a bash script and see what I can figure out. [10:01] om26er, no, yakkerty is dead beef ... all channels are xenial ... edge is just the test channel [10:01] oh right [10:01] * mwhudson_ was being dumb [10:02] dragly: you can use my snapd-hacker-toolbelt snap [10:02] dragly: just install it and run snapd-hacker-toolbelt.busybox sh [10:02] dragly: then explore === hikiko is now known as hikiko|ln [10:07] Great! === mwhudson_ is now known as mwhudson [10:33] ogra_: do I have to change any configuration file to enable the pi3 serial console with your image? [10:34] morphis, nope, serial is the default [10:34] hm [10:34] works here ... [10:34] 115200 8n1? [10:34] yeah [10:35] (i just use screen for that: screen /dev/ttyUSB0 115200) [10:36] let me verify my pin connection [10:36] third pin is ground ... [10:36] ogra_: following https://www.element14.com/community/servlet/JiveServlet/previewBody/73950-102-10-339300/pi3_gpio.png?01AD=3qQ4vBf_OyjHCgCsVfVCaOLElbWZscIAIt5xnDSIb_jh1EytwTHJ-Ag&01RI=4BD464EBE91DD68&01NA=na [10:36] yeah [10:39] and https://www.sparkfun.com/products/9873 [10:42] ah, i just use a cable ... [10:45] hm === jibel_ is now known as jibel [10:48] ogra_: works [10:48] my fault [10:48] phew [10:48] PR snapd#1655 opened: integration-tests: look for ubuntu-device-flash on PATH before calling sudo [10:59] ogra_: ok, a manual ifdown/ifup makes ethernet working [11:00] yeah, there is some race that mwhudson filed a bug about (cant find it atm) [11:01] Son_Goku: hey, I cracked the go-xgettext issue [11:05] Son_Goku: I pushed the package to github.com/zyga/snapcore-fedora, just doing local builds in mock to ensure it is good === hikiko|ln is now known as hikiko [11:20] zyga, sweet [11:34] Son_Goku: morning :) === chihchun is now known as chihchun_afk [11:45] Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1359802#c9 [11:45] sergiusens, marking bugs as inclomplete but not asking for and info ? (bug 1608432) [11:45] Bug #1608432: snaps with type: os should allow publishing of .manifest files [11:46] s/and/any/ [11:49] zyga, approved [11:51] Son_Goku: woot, thank you, looking at snap-confine now [11:52] you should go ahead and import go-xgettext and prepare the bodhi things now [11:52] Bodhi has now been activated for F25, too [11:53] yep, I read the mail today [11:53] I see a few things that rpmlint reports on snap-confine, I'll do as you said and then return to snap-confine === DanChapman_ is now known as DanChapman [12:20] * zyga returned from small lunch :-) [12:23] Son_Goku: package requested, focusing on snap-confine now [12:23] ogra_: what are you building the pi3 kernel snap from? is there a snapcraft.yaml? [12:24] Son_Goku: someone finally updated pkgdb code to select rpms by default (instead of the docker images) :-) [12:24] yeah [12:24] that drop down is going to be get really annoying [12:24] especially once we have modules :/ [12:25] and if the snapcraft stuff gets done, snaps too [12:25] I heard about modules last week but I didn't dig into it, what are they? [12:29] zyga, they're some abstract definition of a collection of software that provide a specific capability [12:30] for now, a module is a definition that pulls in a bunch of RPMs and generates a self-contained repository of them [12:30] and when you install a module, it installs all of the repository [12:30] I'm not entirely sure why we're doing this, since (to me) it looks like it's the same thing as the comps groups (composition groups) [12:31] Son_Goku: looks like old package collections [12:31] * Son_Goku shrugs [12:31] https://fedoraproject.org/wiki/Modularity [12:35] morphis, it is the pi2 kernel actually (same thing, just additional FW for the pi3 is needed) [12:36] morphis, this is the (currently still broken) attempt to roll automated kernel snaps https://code.launchpad.net/~ogra/+junk/kernel-test-snap ... https://code.launchpad.net/~ogra/+snap/kernel-test-snap [12:37] the original code for this lives in livecd-rootfs in the live-build/auto/build script [12:38] ogra_ I did reply to that [12:38] ogra_ hmm, didn't make it through :-/ [12:39] Son_Goku: does this look sensible http://pastebin.ubuntu.com/22798002/ [12:39] Son_Goku: I see the setuid bit, the setgroups that is actually desired in this case (I checked with the security team) and the script in /lib/udev/ [12:40] does snap-confine not support using capabilities in-place of setuid? [12:40] Son_Goku: capabilities? [12:40] https://fedoraproject.org/wiki/Features/RemoveSETUID [12:40] Son_Goku: well, I'm not sure [12:41] Son_Goku: let me check [12:41] oh, I see [12:41] cool, let me try [12:41] it *probably* is enough [12:41] though snap-confine still checks for uid == 0 [12:42] I think that check is obsolete when capabilities are in use [12:43] if it supports using file capabilities instead of needing setuid/setgid bits, then you should probably adjust the build system to offer the choice [12:43] both SUSE and Fedora prefer caps over setuid/setgid [12:44] Son_Goku: upstream code doesn't support this yet but it seems easy enough to implement [12:44] cool [12:44] Son_Goku: where are the authoritative caps I can use? [12:45] I see Invalid capability: cap_setuid,cap_dac_override,cap_sys_admin [12:45] +%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin) %{_libexecdir}/snap-confine [12:45] I think file caps are documented in the capabilities manpage [12:45] man 7 capabilities [12:45] thanks [12:47] zyga, also, it should be /usr/libexec/snapd [12:47] err [12:47] ... /usr/libexec/snapd/snap-confine [12:47] snap-confine needs to be in a folder in /usr/libexec [12:48] noted, let me change that [12:49] it's essentially the same rule as in debian, except we actually use /usr/libexec for helper programs [12:49] instead of stuffing them into /usr/lib [12:49] honestly don't know why debian hasn't adopted it, especially since it's now part of the FHS spec as an optional component [12:49] libexec is not present in hier anymore [12:49] yes it is [12:49] FHS 3.0 includes it [12:50] drizzt@liara ~ % man hier | grep libexec [12:50] drizzt@liara ~ % [12:50] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html [12:51] * zyga tries to guess the %caps() syntax [12:51] To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself. [12:52] timothy, yes, I know [12:52] hence "optional" [12:52] for example systemd uses /usr/lib/systemd by default :) [12:53] Son_Goku: https://fedoraproject.org/wiki/How_to_create_an_RPM_package talks about %caps(cap_net_admin=pe) FOO.BAR [12:53] Son_Goku: do you know what =pe is for? [12:53] nope [12:53] we're getting into weird stuff now :) [12:53] one sec [12:53] * zyga googles [12:53] dwalsh is online on #fedora-devel [12:53] you could ask him [12:53] yep, let's try that [12:53] where do I report issues with the docs? in tour instructions, to be precise [12:53] he's usually the guy to turn to on these things [12:54] Bug #1611287 opened: provide canonical way to install templates and configuration files into $SNAP_* dirs [12:55] I am trying to create a snap for EDS and I am using "plugin: autotools configflags: [..]". It is running configure with the correct flags. But looks like it is trying to use the configflags as gcc arg as well. [12:55] Which is causing problems [12:55] like that: gcc-5.real: error: unrecognized command line option ‘--sysconfdir=/etc’ [12:55] How I can solve that? [12:56] renatu: i's not an autoconfig configure [12:58] timothy, what you mean? [12:59] renatu: maybe it is a configure script but it is not a real autoconf configure script [13:00] renatu: but a hand-written one [13:04] zyga, timothy, I am using the same flags that I found in debian/rules: DEB_CONFIGURE_EXTRA_FLAGS += [...] [13:04] renatu: as CFLAGS or what? [13:05] I did not see any special case [13:05] this is the full log: http://paste.ubuntu.com/22799750/ [13:06] yes, you are passing configure flags as CFLAGS [13:07] timothy, how I can avoid that? [13:07] what is you yaml file? [13:07] timothy, http://paste.ubuntu.com/22799877/ [13:11] hey guys: anyone know the story here: https://bugs.launchpad.net/snappy/+bug/1611078 installing snaps in containers needs some more tricks? [13:11] Bug #1611078: could not install hello-world snap in lxd container [13:15] cjwatson, do you have an opinion about bug 1608432 ? (specifically about sergiusens' comment) [13:15] Bug #1608432: snaps with type: os should allow publishing of .manifest files === JanC is now known as Guest75507 === JanC_ is now known as JanC [13:18] ogra_: it would make more sense to do it in launchpad-buildd, since that has the build tree right there [13:20] cjwatson, ok, any preference for the location or the naming ? [13:21] (do you want me to sort the full naming scheme and just put it in meta/ so you can just blindly cp *.manifest) [13:21] ogra_: well, could be even simpler [13:21] ogra_: can you just write another file to the same output directory that the .snap is written to? [13:22] ogra_: (it would certainly be best if launchpad-buildd didn't have to have a pile of naming logic in it) [13:22] i can try to, yes (the files already exist i think. live-build hasnt changed in that regard and i dont explicitly remove them) [13:22] Cool if that manifest had a checksum in it too. [13:22] ogra_: launchpad-buildd would have to whitelist the file too [13:22] if entry.endswith(".snap") and not os.path.islink(path): [13:22] self._slave.addWaitingFile(path) [13:23] timothy, systemd was granted an exception back in 2012 in Fedora [13:23] it's not allowed without good reason [13:24] claro [13:24] hmm, i see: [13:24] [2016-08-08 04:33:53] lb_binary_manifest [13:24] P: Begin creating manifest... [13:24] Son_Goku: Debian never adopted /usr/libexec basically because it would have been a ton of work for negligible benefit [13:24] but i dont see the .manifest file anywhere (i thought i had some "ls" in the build to show the output dir) [13:24] i need to check that [13:24] what work? even debhelper still sets it by default [13:25]