=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:57] Chipaca: \o/ for your excellent code review [06:41] morning o/ [06:51] mvo: if you s/FIMXE/FIXME/, it'll get picked up by some tools better [06:52] hey clobrano and Chipaca [06:52] Chipaca: heh, thanks. sounds like I need more tea :) [06:52] mvo: how was this not obvious when I clearly said “bä bä svarta får” [06:54] :) [06:55] fixed [06:57] ouh [06:57] one thing [06:57] mvo: you're using %v with the output of cmd.Output() [06:57] mvo: that might not be what you want [06:57] cmd.Output() gives you a []byte [06:58] and []byte looks like [20 75 124 94 ...] [06:58] with %v i mean [06:58] * Chipaca can only handle short sentences this early [06:58] mvo: suggest using %s instead, or string(output) (although that creates a third copy) [07:00] although [07:00] that'd break your error message [07:01] because output will probably have \n's in it [07:02] mwhudson: congrats [07:02] mvo: not the first time i'm thinking we should hide all this stuff inside helpers somewhere :-/ [07:07] Chipaca: uh, good point, let me fix this as well [07:07] mvo: bottom line would be: either remove the ()s, or %#q and string(output) [07:07] um [07:07] %q, not %#q [07:08] that is: either accept the \n's you'll get with %s, or quote the thing at the expense of some memory [07:08] it's build anyway, not a long-lived thing :) [07:11] Chipaca: indeed, let me add %q [07:12] and now i'm off to take the boys to school [07:12] Chipaca: see you [07:12] bbi~1h [07:14] Chipaca: \o. [07:17] good morning [07:25] hi mvo, how are you? [07:26] hey fgimenez, good morning. I'm good, how are you? [07:27] mvo, fine, a little cold this morning but anyways :) [07:27] mvo, i've been working on a logging package for the integration tests, can you have a look when you have the time https://code.launchpad.net/~fgimenez/snappy/integration-tests-verbosity-flag/+merge/273670 ? [07:27] mvo, no rush at all :) [07:28] fgimenez: sure, happy to do that [07:28] mvo, thanks a lot, specifically if you could address elopio's question it would be great === chihchun_afk is now known as chihchun [07:30] * mvo nods [07:41] good morning [07:45] Morning o/ [07:58] fgimenez: I commented in the MP, hope it makes sense, please let me know if there are any quesitons [07:58] mvo, ok thx :) [08:34] mvo: i have good news and bad news [08:35] oh, wait [08:35] * Chipaca checks something [08:35] * mvo waits [08:35] mvo: i have no bad news [08:36] *puhhh* [08:36] what was the bad news? [08:36] mvo: unless "i didn't know %q worked that way with []byte" is bad news, nothing :) [08:36] so the good news is, i learned that (wonder how many times i learned it before) [08:37] mvo: now, can we talk about husks? :) [08:37] Chipaca: you mean about leightweights ;) [08:38] Chipaca: is the other stuff addressed? if so and we can not find a better name husks win [08:38] mvo: i meant exuvia, sorry [08:38] "other stuff"? [08:38] * Chipaca looks [08:38] i thought that was all there was [08:38] Chipaca: I can't remember if so, then great, let me double check [08:47] Chipaca: some inline comments about tiny bits (comments, the one panic) [08:47] dude, i'd missed those entirely [08:47] * Chipaca reads [08:48] Chipaca: I like lightweights, so if its not too bothersome and makes stuff not too ugly I'm slightly in favour of changing (but not strongly) [08:53] mvo: is that because you can't lift the heavy one ;) === chihchun is now known as chihchun_afk [09:02] davmor2: lol === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [09:09] Good morning all; happy Thursday, and happy World Sight Day! 😃 👓 👁 === chihchun_afk is now known as chihchun [09:27] mvo: question for you [09:27] mvo: was going with lightweight.PartList [09:27] mvo: but then i thought, does that make you think you can range over it? should i call it a PartBag instead? [09:28] mvo: or did you mean just call it lightweight.Lightweight? [09:33] Chipaca: hm, PartBag sounds ok, PartList is probably ok as well, but you are right, there is this association with a real list then [09:34] * Chipaca nods [09:47] mvo: hmmmmmm [09:47] mvo: LoadActive() is “ return h.Load(h.ActiveIndex())” [09:47] mvo: not sure it's worth it :) [09:49] Chipaca: indeed, wasn't there error checking on the index before? or am I misrembmering? [09:49] definitely mistyping ;) [09:49] * Chipaca looks at merged-list [09:50] mvo: there is error checking [09:50] hmm [09:51] mvo: so LoadActive could return nil,nil if activeIndex<0, or nil, ErrNoActiveIndex or sth [09:51] either way the caller would have to handle it differently [09:52] Chipaca: aha, ok, in this case its not worth it I agree [09:52] that is, today: idx:=h.ActiveIndex(); if idx<0{not found}; if h.load(idx) errors { internal error } [09:52] Chipaca: I just noticed in the MP what looked like repeating code that could be done in a single place, but if it actually can't … [09:52] with active index: part,err:=h.LoadActive(); if err=NoActive{not found} else if err != nil {internal} [09:55] mvo: promise i'll revisit it in a month to see how we're actually using it and add convenience methods :) [09:55] * Chipaca adds a calendar thing [09:55] Chipaca: deal! [10:12] mvo: i think that addresses all your issues, please take a look when you cna [10:12] can* [10:12] morning [10:15] uia! un sergio! [10:15] sergiusens: morning [10:16] Chipaca: thanks, will do [10:16] sergiusens: good morning [10:17] mvo: ah, one question about the squashfs build branch [10:17] mvo: i heard something about moving build to snapcraft [10:17] mvo: is that accurate? [10:18] Chipaca: yes, eventually [10:18] Chipaca: we still need something for our tests in snappy I think [10:18] ok [10:19] Chipaca, mvo the code base for lp:snappy looks so different 5 days past [10:19] mvo: yes, but once snapcraft does build, let's not have two implementations of it :) [10:19] Chipaca: yeah, I agree, at the same time I don't want to be distracted by this just now :) [10:20] * Chipaca nods [10:20] speaking of changes to lp:snappy, how do you remove tags from it? [10:21] i added tags when playing with them, removed them, but they have appeared upstream somehow, and no amount of removing them makes them go away :-( [10:21] Chipaca, as in bzr tags? [10:21] yes [10:21] Chipaca, --overwrite I think, it is extremely complicated [10:21] does bzr tag --delete work? [10:21] it works locally [10:21] but --overwrite-tags says it's got nothing to do [10:21] but not with a lp prefix? [10:22] Chipaca: what tag should go? [10:22] mvo: " " and "\t" [10:22] Chipaca, interesting tags, those should stay :-P [10:22] sergiusens: um. Ok. Don't --print-ids then. [10:23] --show-ids i mean [10:48] whaaaat [10:49] no LastIndexByte before 1.5 [10:49] sigh [10:49] * Chipaca fixes === chihchun is now known as chihchun_afk [11:17] hmm [11:18] tests pass here, with go 1.3. fail in tarmac. map output for failed tests is identical for obtained/expected. [11:20] wait, they're not all identical [11:20] differing keys: [11:20] 'installed_size': expected '208', got '8260' [11:20] wtf [11:34] * guest42315 EWWWW mailing lists [11:35] guest42315: ? [11:36] Chipaca, oh sorry /me /ame [11:38] sergiusens: ping [11:39] Chipaca, pong [11:39] sergiusens: any ideas wrt tests failing in tarmac in weird ways? [11:41] Chipaca, weird ways, no; what are you running? [11:42] sergiusens: in snappy, run-checks locally passes fine, every time, with go 1.5 and 1.3, starting from a pristine directory (just like tarmac does it) [11:43] sergiusens: in tarmac, https://code.launchpad.net/~chipaca/snappy/husk/+merge/273482/comments/690882 [11:44] sergiusens: 4 failed tests, of which 1 the obtained/expected mappings are apparently identical [11:44] sergiusens: and the others differ in "installed_size", with 8k extra on disc [11:44] oh, wait, 8k extra [11:45] hmm [11:45] Chipaca, 'snappy unpack' and snappy installed on tarmac [11:45] Chipaca, could it be that? [11:45] Chipaca, not sure how unit the unit test is :-) [11:45] the 8k might be because i use tmpfs [11:45] snappy unpack not involved [11:46] Chipaca, don't use ue tmpfs locally and why would it be different? [11:46] if both places use tmpfs [11:47] sergiusens: in tmpfs a directory's du is 0, an empty file's du is 0 [11:47] sergiusens: outside of tmpfs, both of those are 4k [11:47] or 2k or 16k [11:47] block size [11:47] dangit :( [11:48] sergiusens: thank you! [11:49] Chipaca, you did it all by yourself ;-) [11:50] sergiusens: you're a good sounding board [11:50] Hi all! Is it hard to make our oem snap packages signed? :) [11:53] biezpal: put them in the store? [11:55] Chipaca, is it enough to make it signed? actually, we just don't like "sideload" prefix :) [11:55] and random string in version field.. [11:56] because of https://bugs.launchpad.net/snappy/+bug/1498396 [11:56] Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,New] [11:57] oh, bug 1498396 [11:57] bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,Fix released] https://launchpad.net/bugs/1498396 [11:58] i knew there was a bug about it but didn't find it when making the branch. fixed, anyway. [11:58] biezpal: data dir now has a 'current' link [11:58] Chipaca, in current edge this bug is still exists [11:58] biezpal: anyway, getting it from the store is (for now) the only way to get it auth'ed [11:59] biezpal: really? [11:59] maybe i should've checked first :-/ [11:59] * Chipaca checks now [12:00] Chipaca, we are build it from edge channel [12:00] sudo ubuntu-device-flash core 15.04 --channel edge --oem parallella_4.0_all.snap --device-part=device.tar.xz -o parallella1.img [12:00] soffokl: biezpal: 15.04? [12:00] yes, 15.04 [12:00] sigh [12:00] needs backporting i guess [12:01] i was sure that was included in the latest 15.04 [12:01] ah. no. it's for the next one. i remember now. [12:02] for the next one edge?) [12:04] i mean: it's in rolling/edge [12:04] i guess it's not on stable [12:04] gah [12:04] i mean not on 15.04 [12:05] biezpal: if youc reate the symlink by hand for now, things'll sort themselves out [12:08] Chipaca, sigh [12:08] thanks [12:08] $ ls -l /var/lib/apps/hello-world.canonical/ [12:08] total 4 [12:08] drwxr-xr-x 2 root root 4096 Oct 8 12:03 1.0.18 [12:08] lrwxrwxrwx 1 root root 6 Oct 8 12:04 current -> 1.0.18 [12:09] biezpal: ^ :) [12:09] Chipaca, handmade link? :) [12:09] biezpal: no, rolling edge [12:10] biezpal: s/15.04/rolling/ in your u-d-f command above and you get that [12:10] but rolling is the one we *actively* break :) [12:10] so beware [12:11] we should really default to do development in 15.04 and forward port instead of the other way round [12:11] Chipaca, ok, i guess we can use rolling for development purposes [12:12] Chipaca, can I get your opinion on https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826 ? [12:12] sergiusens: you can try :) [12:13] Chipaca, I don't like the MP, but I don't know what else to do [12:14] sergiusens: i guess the removing the dangling one if unresolved is the bit you don't like? [12:15] sergiusens: BTW, $ dpkg -S /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts [12:15] openjdk-7-jre-headless:amd64: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts [12:17] Chipaca, oh, then that is fine and covered, what about libc6? [12:17] Chipaca, I might have been having issues with ':' [12:19] Chipaca, and wait [12:19] Chipaca, you just confused me, the thing it links to is what I can't figure out where it comes from [12:19] Chipaca, as in /etc/ssl/certs/java/cacerts [12:19] ca-certificates-java i'd assume [12:20] oh, oh, oh [12:20] i know what's missing here [12:20] Chipaca, nope [12:21] Chipaca, not provided by ca-certificates-java [12:21] ok, need to dig a bit more [12:21] but [12:21] you need to loop [12:21] to loop? [12:22] or does realpath do that? [12:22] if it's a symlink-to-a-symlink [12:23] Chipaca, oh, I can try (s/realpath/readlink/ I suppose) [12:25] realpath might resolve it; check (or read docs) [12:25] so [12:25] that file [12:25] is *probably* created by ca-certificates-java [12:25] via /etc/ca-certificates/update.d/jks-keystore [12:26] sergiusens: by running /usr/share/ca-certificates-java/ca-certificates-java.jar [12:28] sergiusens: realpath loops [12:28] sergiusens: you're set [12:28] Chipaca, this MP won't work :-) [12:28] still trying to understand it tbh :) [12:29] ah! [12:29] Chipaca, look at the bug [12:29] sergiusens: so, yes, change the first readlink to realpath [12:29] ... or something! i dunno [12:29] programming is complicated, i'm going to have a cuppa tea [12:29] Chipaca, so we don't run postinst for 'stage-packages' [12:30] Chipaca, and jdstrand is not using any of the java plugins [12:30] Chipaca, just downloading debs, so he doesn't have the certs; and I can't just copy because a bare bones system won't have them either [12:30] right [12:31] Chipaca, then there is libc6; do we want those libs in the snap or should they be allowed as dangling symlinks? [12:35] sergiusens: libc6 is problematic, because nss needs to be exactly the same [12:35] sergiusens: so copying it in won't work [12:35] sergiusens: that's how you get segfaults or, worse, weird behaviour [12:37] Chipaca, right, so I need to circle back with jdstrand to get more smarts in the click-review tool and also make sure that using 'stage-packages' requires hand holding in some cases [12:39] Chipaca, cat /etc/lsb-release [12:39] DISTRIB_ID=Ubuntu [12:39] DISTRIB_RELEASE=15.10 [12:39] DISTRIB_CODENAME=wily [12:39] DISTRIB_DESCRIPTION="Ubuntu Wily Werewolf (development branch)" [12:39] (Parallella)ubuntu@localhost:~$ ls -l /var/lib/apps/parallella/ [12:39] total 4 [12:39] drwxr-xr-x 2 root ubuntu 4096 Oct 8 2015 ICaVaRAVXWYS [12:39] Ubuntu bug 4096 in meld (Ubuntu) "meld: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/4096 [12:40] sudo ubuntu-device-flash core rolling --channel edge --oem parallella_4.0_all.snap --developer-mode --device-part=device.tar.xz -o parallella2.img [12:40] ... [12:40] interesting :-/ [12:41] wait [12:41] that parallela package [12:41] that was installed by u-d-f [12:41] and that u-d-f is probably not recent enough to include these changes? [12:41] soffokl: apt-cache policy ubuntu-device-flash if you please [12:42] ubuntu-device-flash: [12:42] Installed: 0.31-0ubuntu1 [12:42] Candidate: 0.31-0ubuntu1 [12:42] Version table: [12:42] *** 0.31-0ubuntu1 0 [12:42] 500 http://ppa.launchpad.net/snappy-dev/tools/ubuntu/ vivid/main amd64 Packages [12:42] 100 /var/lib/dpkg/status [12:42] 0.20-0ubuntu1 0 [12:42] 500 http://kg.archive.ubuntu.com/ubuntu/ vivid/universe amd64 Packages [12:46] Chipaca, meh, ca-certificates-java.jar harcodes to /etc :/ [12:47] sergiusens: when/how does u-d-f get rebuilt? [12:54] mvo: ok to top-approve merged-list? [12:57] yes, done so [13:00] mvo: no files were sneaked in to that branch last minute* [13:00] :P [13:01] * or so you think [13:01] snuck, not sneaked. sigh. [13:02] * ogra_ hands Chipaca a pair of sneakers [13:02] * Chipaca snickers [13:03] yummy peanuts and caramel [13:03] * ogra_ wishes he could eat that :( [13:03] sergiusens: I guess you are saying some things should symlink out (libc6) but some things shouldn't (cacerts) [13:04] sergiusens: if you file a bug against the click-reviewers-tools project, I'll fix it. I have a couple of other things to fix this week [13:04] sergiusens: just let me know what is a legitimate symlink [13:05] ogra_: you want one of these: http://pickupthefork.com/wp-content/uploads/2014/10/IMG_8754.jpg [13:05] mean ! [13:06] (no sugar for me for another week .... ) [13:07] ogra_: oh! i thought it was the nuts you couldn't have [13:07] well, i cant bite nuts :) [13:08] (thats another 4 weeks) [13:08] hence why i thought one of those would give you the nuts+caramel thing without having to bite nuts [13:08] heh [13:08] see, i'm so thoughtful it hurts [13:11] jdstrand, ok, it's mostly libc6 things as per what we discussed with Chipaca; for cacerts, I'm solving it in the jdk plugin, the error for it is fine, but I can't fix it in a generic way for stage-packages uses because some of these are postinst hook created. [13:11] yay, maintainer scripts [13:11] :P [13:12] sergiusens: won't the jdk plugin pull in a bunch of stuff I don't need? [13:13] sergiusens: why can't you examine the symlinks in the directory? perhaps you could prompt to include them from the system? [13:14] jdstrand, I have as a first approach https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826 [13:14] jdstrand, I just feel it would be weird [13:15] sergiusens: at the very least, you should detect them and report them with suggestions on how to fix them, because if you don't then snapcraft will generate a package that fails review. the review tools could be the place to detect them and make a suggestion if you'd prefer [13:15] but it seems like snapcraft is in a position to fix things up [13:15] Chipaca: there are more branches ftw, just in case you are bored ;) [13:16] i saw nothing [13:16] fgimenez, elopio: could one of you install squashfs-tools on the tarmac server please? [13:16] eg, "oh, cacerts is pointing to something in /etc. let me copy what is in /etc to ./snap/etc and adjust the symlink [13:16] " [13:16] sergiusens: ^ [13:16] jdstrand, yeah, I'll go with that branch and polish a bit to not include libc6 links [13:17] Chipaca, u-d-f, when you dput it [13:18] sergiusens: cool. btw, I don't care if you copy in place (your mp) or copy to the intended place and adjust the link (what I suggested). however, what I suggested is probably more robust if you have multiple symlinks to the same thing [13:18] Chipaca, ideally the ubuntu-snappy stuff goes to the archive and then gets rebuilt and it does so prior to a release [13:19] jdstrand, right, it could save more space, not sure if it would when everything is squashfs [13:25] mvo, sure, give me a minute [13:28] mvo, done http://paste.ubuntu.com/12714696/ [13:33] ogra_: did you get too track down the ipv6-only thing? [13:33] (were you [going to be] doing that?) [13:34] ipv6-only ? [13:34] * ogra_ hasnt heard of it [13:37] fgimenez: elopio: you might want to tell ogra_ about it :) [13:41] ogra_: rpi2 was coming up with only an ipv6 address (and i think fgimenez got it in kvm also once, but not consistent) [13:41] ogra_: but i don't know the details [13:43] weird [13:48] ogra_, this is the bug https://bugs.launchpad.net/snappy/+bug/1503329 [13:48] Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Undecided,Confirmed] [13:51] fgimenez, well, there was a kernel update between 186 and 187 i think [13:54] (no idea if related or not) [14:21] sergiusens: So I know we wanted to get rid of the situation where plugins subclass other plugins. [14:21] sergiusens: Did we also want to get rid of 'requires' in the plugin yaml? [14:24] tedg, hmm, wasn't aware of subclassing [14:24] tedg, as we discussed this last week https://code.launchpad.net/~sergiusens/snapcraft/1500902/+merge/273444 [14:25] still needs a round of testing for local plugins, but works fine otherwise [14:26] sergiusens: So I think that's fine, but the specific case here is a plugin that needs Python3, including PIP support, so it doesn't make sense to copy-and-past. [14:26] paste (should have cut-and-pasted that from somewhere) [14:26] sergiusens: So it'd like to basically have the python3 plugin run first for everything, which is kinda what requires did. [14:26] tedg, we have plugins already that base out of python3 [14:27] tedg, oh, the requires problem and pull phases problem is a problem of the past; it is fine if a pull phase for every part can't be completed due to an 'after' [14:28] tedg, in the end, lp should not be a blocker (words out of beuno's mouth ;-) ) [14:29] Chipaca, mind taking another look at https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826 ? [14:31] Chipaca, this time it is better [14:31] ogra_, why did you break my 2fa? :-P [14:32] sergiusens, well, i was bored y'know [14:32] (what do you mean ? ) [14:34] sergiusens, do you mean the authenticator app breakage ? [14:34] * ogra_ fully blames bzoltan_ for that :P [14:35] * bzoltan_ takes the blame ... do you want to punish me ;P [14:35] i guess he will throw argentinian steaks at you :) [14:36] ogra_, hah, it is my 2fa device so now I am sort of in limbo :-P [14:40] Chipaca, jdstrand, o/ good news, I managed to work-around transmission issues with mount/quotactl by using statvfs, and it works! I'll be uploading the fixed version later today :) [14:40] matiasb: great! :) [14:41] yay [14:43] jdstrand, btw, re random/uuid, everything seems to work ok even if that is denied by apparmor; I was thinking if I should I upload the package without any profile customization then? once the perm is added to the default template, future installs will get access? (it seems the profile is generated from the default template on install, right?) [14:44] matiasb: yes on all counts. if it works fine, but remove security-policy. it will use the default template with network-client. you'll have the denial until I do the upload [14:44] s/but remove/then remove/ [14:45] jdstrand, great, that's my plan then; that should go through review without any issues and without requiring manual intervention [14:45] matiasb: with that change and using 'architectures' in your package.yaml, it will pass automated review [14:45] yep [14:45] correct [14:51] matiasb: you're building it multi-arch, yes? pretty please? [14:51] Chipaca, yeap :) [14:52] sweet [14:53] pitti: you around? question about removing a service from systemd's status [14:53] hey Chipaca [14:53] pitti: hi! [14:54] pitti: right now, if you have a snap with a service, and upgrade it, the old service never goes away from systemctl [14:54] pitti: are we doing something wrong? [14:54] we stop the service, disable it, reload-daemon [14:54] Chipaca: you mean you don't stop the old service before upgrading? [14:54] we stop it [14:54] ah, then it should be stopped, no? [14:54] we disable it [14:55] we remove the service file [14:55] we do a reload-daemon or daemon-reload or whatever that was [14:55] daemon-reload [14:55] but it's still there in the systemctl output [14:55] Chipaca: with --all? yes, that's right [14:55] shoudl be inactive/dead then, or is it still running? [14:56] inactive/dead/not found [14:56] not with --all though [14:56] this happens a lot, particularly with instantiated units (foo@.service) [14:56] Chipaca: hm, by default "systemctl" only lists active units -- if it's listed there as inactive that's a bug indeed [14:56] systemctl show, not status, sorry [14:56] ah [14:57] you can still query e. g. the journal from the old units, or their status [14:57] Chipaca, another smaller one when you feel like dropping a finger on the approve button https://code.launchpad.net/~sergiusens/snapcraft/1504174/+merge/273853 [14:58] pitti: oh, wait, i spotted the bug. and it's mine. sorry to bug you :-/ [14:58] pitti: wouldn't've spotted it without you though, so thanks ! :) [14:59] heh [14:59] Chipaca: so, this might just be a cosmetical thing -- systemctl status anything.service will say "not found" [14:59] (and exit with 3) [15:00] pitti: i was getting a list of all installed snaps [15:00] Chipaca: except that for services which did exist in the past you still get the old journal [15:00] pitti: not filtering by "active" [15:00] so i'm *asking systemctl for it myself* [15:00] with completely bogus names you just get not-found [15:00] * Chipaca puts the brown paper bag back on [15:00] * pitti pats Chipaca, no worries :) [15:36] sergiusens, do we have a "null" plugin now ? [15:36] or do i still have to abuse the copy plugin (and copy an empty README file) to just get some deb binary content [15:37] (i thinnk someone said that was planned) [15:40] fgimenez: would it be too hard to add levels to the snappy/log ? [15:42] elopio, not sure, i can try in a branch [15:42] fgimenez: it would be awesome if we could make this an independent library. But just if the effort required is not too much. [15:44] fgimenez: also, there's https://github.com/golang/glog [15:47] elopio, ok thanks, i'll take a look [16:26] ogra_, it was an idea, but is there any case where that would produce a good snap? [16:26] http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml [16:26] jdstrand, this should solve minecraft (except for libc6 libs) https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826 [16:27] sergiusens, ^^^ thats what i use now to quickly pack a tool if i need it ... [16:27] ogra_, heh, the 'nop' plugin I need to propose [16:27] its just silly to have an empty README file to copy around just to get the staging packag [16:27] e [16:28]