[00:00] <ssbash> http://paste.ubuntu.com/24845115/
[00:01] <cachio> the error is the same?
[00:02] <ssbash> yea, "ImportError: No module named 'wraticus.lib'; 'wraticus' is not a package"
[00:06] <cachio> and the snapcraft.yaml?
[00:08] <ssbash> http://paste.ubuntu.com/24845159/
[00:08] <ssbash> pretty much unchaged aside from the script
[00:08] <ssbash> I tried it both with and without the environment specifications
[00:11] <cachio> ssbash, https://paste.ubuntu.com/24845181/
[00:11] <cachio> https://paste.ubuntu.com/24845185/
[00:11] <cachio> there you have an example
[00:11] <cachio> using a wrapper
[00:14] <ssbash> ok should I move the environment block to the parts section?
[00:33] <cachio> you create a part with the wrapper
[00:35] <ssbash> http://paste.ubuntu.com/24845323/ this is my lastest version, I'm still getting the 'wraticus is not a package' error
[00:45] <cachio> ssbash, does it exist?
[00:45] <cachio> $SNAP/bin/wraticus.py
[00:46] <cachio> and it calls to the lib?
[06:13] <francis[m]> Any recipes to make a snap from a deb?
[06:14] <zyga> good morning
[06:14] <zyga> francis[m]: you can use snapcraft and stage-packages
[06:15] <zyga> francis[m]: look at the array of snapcraft examples on the web
[06:17] <francis[m]> zyga (IRC): i looked around
[06:17] <francis[m]> But apart from some no longer maintained projects i didnt find
[06:18] <francis[m]> Will look at snapcraft
[06:18] <francis[m]> Thx!
[06:20] <luk3yx> If I want to include a binary from /usr/bin in a snap, what's the best way to do it?
[06:20] <zyga> francis[m]: https://github.com/search?utf8=%E2%9C%93&q=stage-packages+extension%3A.yaml&type=Code&ref=advsearch&l=&l=
[06:21] <zyga> luk3yx: stage-packages as this binary is typically packaged itself
[06:24] <luk3yx> zyga: Okay, I'll try that.
[06:27] <zyga>  good luck
[06:27] <zyga> note that stage packages are not always the best way to make a snap, but they are the quickest for sure
[06:30] <luk3yx> It works, thanks.
[09:24] <sborovkov> Hello, stupid question but I never used uboot before, if I add some binary to the boot-assets in the gadget snap from what path would it be available in uboot when booting?
[09:30] <morphis> ogra: ^^
[09:31] <morphis> zyga: you will love https://github.com/morphis/spread-images/commit/628d428c655f1004dcadb91bfd3d5eebd44ce804
[09:31] <zyga> looking
[09:31] <zyga> nice :-)
[09:33] <morphis> zyga: if we can't fix pacman in the archive lets import packaging bits and make sure they are taken care of, then whoever maintains the pkg can pull these into the main archive
[09:33] <zyga> yes, I think that's the natrual way to handle this
[09:34] <zyga> then anyone can propose improvements to the snapd tree (no need to be a distro maintainer)
[09:34] <zyga> and we can work with timothy or anyone else to synchronize with upstream packaging
[09:45] <ogra> sborovkov, usually from / in the system-boot partition ... unless you push it to a raw place via the gadget snap like i do in https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/
[09:48] <ogra> sborovkov, if you mean from the uboot shell, then "fatls mmc <devicenumber> <partition>" is your friend to find it ...
[09:49] <ogra> i.e. if system-boot is yuor first partition on the first SD: "fatls mmc 0 1"
[09:49] <ogra> (or "...mmc 0 0")
[09:51]  * zyga needs a coffee
[10:18] <sborovkov> ogra: ah, alright, yes I am building the gadget snap. Trying to add splash screen
[10:18] <ogra> sborovkov, heh, i have that half done here for the default gadgets ... :)
[10:18] <ogra> (but it is more of a pet project so i only work on it every now and then)
[10:20] <sborovkov> ogra: is there some standard mechanism (or it's going to be developed) to hide login promt on the first boot? First boot takes quite awhile and that would look bad for user to see login promt at that time...
[10:21] <sborovkov> also, is I understood you correctly when adding bmp file to the boot-assets it would be available from /? so I can add splashscreen=/boot-assets/Screenly.bmp?
[10:21] <ogra> sborovkov, well ... depends ... in IoT i would expect most boards to only have a serial console and operate completely headless ...
[10:22] <ogra> same goes for core based cloud images
[10:22] <ogra> no, you wouldnt use boot-assets/ ...
[10:23] <sborovkov> Alright, understood thanks
[10:23] <ogra> if it sits directly on your system-boot partition you'd use splashscreen=Screenly.bmp
[10:24] <ogra> if i were ou i'd just add it to the gadget, build an image with it, stop the boot on the u-boot console and develop the scripting for it in there ... (then later add it to uboot.env.in)
[10:25] <ogra> so that you can check for paths and the like with fatls/fatload etc
[10:25] <ogra> https://www.denx.de/wiki/DULG/UBootSplashScreen and https://www.denx.de/wiki/DULG/UBootBitmapSupport should be helpful
[10:26] <sborovkov> thanks!
[11:20] <mup> PR snapd#3457 closed: tests: add refresh --time output check <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3457>
[11:22] <mup> PR snapd#3474 opened: tests: fix ipv6 disable for ubuntu-core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3474>
[11:29] <ogra> koza, hmm ... i only actually use the hummingboard with HDMI and kbd attached, did you try that ? (i only opened the case once but didnt touch any jumpers, the board is as it got it from madper)
[11:29] <ogra> *as *I* got it
[11:30] <ogra> koza, it should work fine from microSD
[12:20] <morphis> zyga-suse, zyga-fedora: two of you now? :_)
[12:21] <zyga-suse> morphis: yes, on each system, ubuntu too but I think I can manage with just two IRC accounts :)
[12:21] <morphis> hehe
[12:21] <zyga-suse> sadly irc doesn't do multi-client very well
[12:21] <morphis> zyga-suse: https://paste.ubuntu.com/24848692/ , that is what we get now on the Pi 1 or Pi Zero with that patch I did
[12:22] <zyga-suse> morphis: that's nice
[12:22] <zyga-suse> morphis: btw, one idea
[12:22] <morphis> not optimal but that is something we can improve later
[12:22] <zyga-suse> morphis: if the core snap for the architecture cannot be found, link to a forum thread
[12:22] <zyga-suse> morphis: and encode the architecture in the URL
[12:22] <morphis> why not
[12:22] <zyga-suse> once it gets found we do nothing more
[12:22] <zyga-suse> and meanwhile people will have a place to go to and discuss
[12:24]  * ogra finds it funny that hexchat actually turns zyga from violet to "SuSE green" when he renames himmself to zyga-suse 
[12:24] <ogra> -m
[12:25] <niemeyer> o/
[12:25] <zyga-suse> oh really? :D
[12:25] <zyga-suse> nice :)
[12:52] <cachio> Chipaca, hey
[12:53] <cachio> Chipaca, I have seen some tests failing because of an error 502
[12:54] <cachio> Chipaca, downloading apps
[12:55] <cachio> Chipaca, have ouy seen that?
[12:56] <pstolowski> zyga-suse, hey, re snap-confine and security tag vs snap name matching - do we have strong incentive to get rid of regexp in verify_security_tag? because if not, the fix is going to be very simple with captured text
[12:56] <Chipaca> cachio: yes; was that yesterday, or today?
[12:56] <cachio> yesterday
[12:56] <cachio> I saw it twice
[12:56] <Chipaca> right
[12:57] <Chipaca> yesterday the store had some issues
[12:57] <zyga-suse> pstolowski: I'd say we fix the immediate issue and then iterate on improvements (regexp removal)
[12:57] <Chipaca> cachio: https://r.chipaca.com/sauc.cgi?maxDays=2
[12:57] <pstolowski> zyga-suse, sounds good to me
[12:58] <cachio> Chipaca, are those store metrics?
[12:59] <Chipaca> cachio: from the perspective of a very cheap shared hosting
[12:59] <cachio> Chipaca, linode provided that?
[12:59] <Chipaca> cachio: no, that's me
[13:00] <Chipaca> cachio: in any case it's back to the usual ~1 error in a 24 hour period
[13:16] <koza> ogra, lunch this time, ah you are lucky with the board. could you take a photo of the board for me. i could verify if all the jumpers are in correct positions. the dos that I could find over the net are not quite detailed.
[13:16] <ogra> koza, that will take a bit, i need to open the case again :) ...
[13:16] <ogra> koza, just to make sure we have the same thing, you have a hummingboard GATE with case ?
[13:18] <koza> ogra, I have hummingboard gate w/o case (but I have been told this is the same pcb, case is an optional accessory) https://www.solid-run.com/product/hummingboard-gate/#configuration
[13:20] <ogra> koza, https://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard has a table for the jumper
[13:21] <ogra> bridging 3+4 and 5+6 should do it
[13:21] <ogra> (at the very bottom)
[13:21] <koza> ogra, this is what I bridged :-) thts is why I want to super verify everything
[13:22] <ogra> gimme a bit ... going to the office and grabbing my board and a screwdriver :)
[13:23] <koza> ogra, sure, thanks
[13:23] <mup> PR snapd#3453 closed: tests/main/manpages: install missing man package <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3453>
[13:23] <morphis> niemeyer: thanks!
[13:29] <ogra> koza, oh, interesting
[13:29] <ogra> koza, no jumpers at all !
[13:31] <ogra> which would mean OTG boot ... but i guess it falls back to SD if no OTG is connected or some such
[13:33] <koza> ogra, interesting
[13:33] <ogra> well, try it ... perhaps it boots then for you too
[13:33] <ogra> btw, i use a 12V 1A PSU
[13:34] <ogra> (an old thing from some broken netgear switch that happened to have the right plug size)
[13:34] <ogra> so you should be fine with your 12V2A
[13:35] <koza> ogra, trying now, exactly 2A should be fine; one thing how your serial is connected? mine is to the 3-pin uart connector which is on the edge half way between microSD slot and the boot-mode pins
[13:35] <ogra> the default cmdline has "console=ttymxc0,115200 console=tty0 " so you should see something on serial if it is wired correctly
[13:35] <ogra> i have never used serial on it
[13:36] <ogra> HDMI worked just fine ... i actually didnt open the case when working on the image
[13:36] <ogra> only after i had that up ... to take a look how it looks inside
[13:36] <koza> ogra, got it
[13:36] <ogra> but there is that thing labeled UART on the board with three pins
[13:38] <koza> ogra, yeah but there is another one but just holes w/o pins soldered which is a bit confusing which one to use
[13:39] <ogra> well, surely the one with pins :)
[13:39] <ogra> i doubt they want you to solder pins onto the one without before you can boot ;)
[13:39] <koza> ogra, hopefully :-)
[13:40] <ogra> getting the order right might be a bit of trial and error though
[13:41] <koza> ogra, at least the jumpers are clear now :-)
[13:42] <ogra> dont you have a TV or HDMI monitor you could try ?
[13:43] <koza> ogra, I have, no signal though
[13:43] <ogra> give it a bit
[13:44] <ogra> the u-boot stuff might not be displayed ... only once the kernel loads
[13:44] <ogra> aha
[13:44] <ogra> there is another UART on the GPIO pins it seems
[13:44] <ogra> https://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard:hardware:hbpbgpio
[13:44] <ogra> scroll to the bottom
[13:45] <ogra> pin 6, 8 and 10
[13:45] <ogra> 6 being GND
[13:46] <Chipaca> niemeyer: one argument for not having oddjob just implement execute-command is that I won't be able to reuse the code from the systemd package afaict
[13:46] <koza> yeah but the gate version has the gpio ports laid out differently, like four pins in each row; there are though three responsible for UART but we just have been discussing them - these do not have pins
[13:46] <Chipaca> bah, it'll be a rather big refactor
[13:47] <Chipaca> niemeyer: but i can probably make it shallow enough that you'll still like it :-)
[13:47] <koza> ogra, like here https://www.solid-run.com/wp-content/uploads/2015/09/hummingboard-gate-03.jpg
[13:48] <ogra> well, i guess it is just split into two rows ... the prob is to find where pin1 is on that :P
[13:48] <koza> ogra, left top corner 2nd set of three holes (labeled J35) is a UART too
[13:48] <ogra> ah
[13:48] <niemeyer> Chipaca: It feels like the commands to be run there are trivial enough, but I definitely have a much vaguer understanding of the issue than you do at this point
[13:48] <ogra> yep, i see that on my board
[13:49] <koza> here they say it is uart http://download.solid-run.com/pub/solidrun/HummingBoard%202/HummingBoard2%20Schematics%20rev%201.2.pdf (bottom of page 6)
[13:49] <Chipaca> niemeyer: this is true; most of the code in systemd is around things other than these direct commands
[13:49] <Chipaca> status and logs and such
[13:49] <Chipaca> niemeyer: I'll take a stab at it :-)
[13:49] <niemeyer> 👍
[13:50] <Chipaca> OTOH maybe this evolvs to be the other way around, with start-snap-services using oddjob directly
[13:50] <Chipaca> anyhow, to the code
[13:54]  * zyga-fedora goes for lunch
[13:57]  * zyga-suse goes for lunch too
[13:57] <ogra> are you lunching together ?
[13:59] <ogra> koza, just to make sure, the SD was definitely written correctly ?
[13:59] <ogra> (if you plug it into the PC it shows the two partitions ?)
[14:02] <koza> ogra, just been checking this; yes two
[14:02] <ogra> ok
[14:02] <koza> ogra, perhaps Im using too big card, mine is 32G
[14:03] <ogra> that shouldnt matter to find the kernel and the system-boot partition
[14:03] <koza> indeed
[14:03] <ogra> mine only shows the u-boot stuff occasionally on HDMI though ...
[14:03] <ogra> not on every boot
[14:04] <ogra> if it doesnt show it, the screen sits at "no signal" for like 20-30sec, then flashes to black screen and after another few sec i ger kernel messages
[14:04] <ogra> *get
[14:05] <koza> nothing here; screen has switched off before it printed anything; I'll try with 2nd card just to ruleut issue with card
[14:05] <ogra> +1
[14:05] <ogra> if we have the same board there is no reason that yours shouldnt boot
[14:06] <koza> exactly
[14:06] <ogra> perhaps my monitor is special :P
[14:08] <Chipaca> pedronis: do you remember if the tomb that's the second arg of state.HandlerFunc is used to abort?
[14:08] <Chipaca> trying to track down how abort happens and it's a little elusive
[14:09] <koza> monitor and board, the extra feature is "it works" ;-)
[14:09] <mup> PR snapd#3473 closed: tests: pull from urandom when real entropy is not enough <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3473>
[14:10] <niemeyer> cachio: ^^^ This is in as a step forward, but let's please do the changes we discussed and get random fixed in a more reliable way
[14:11] <cachio> niemeyer, yes, already working on that
[14:11] <niemeyer> Thanks!
[14:11] <niemeyer> morphis: Ok, so which one do you want sanpshotted?
[14:12] <cachio> ogra, could you please point me to see how you are feeding the entropy pool for ubuntu core?
[14:12] <ogra> cachio, we dont ... as i explained in the forum, we just force the kernel to do it proper and dont use any userspace tools
[14:12] <morphis> niemeyer: spread-54 as archlinux-64
[14:13] <cachio> ogra, ok
[14:13] <ogra> cachio, and for the kernel the cmdline option is needed
[14:14] <cachio> ogra, ok, I'll try to do that
[14:14] <niemeyer> morphis: spread-54 is being cleaned by spread, and the arch disks are not even there
[14:20] <morphis> niemeyer: hm.. sounds like I have to redo that one again
[14:29] <niemeyer> morphis: :(
[14:29] <niemeyer> morphis: #3222 is almost ready.. just needs to drop that extra function and it's good to go
[14:32] <pedronis> Chipaca: yes
[14:34] <morphis> niemeyer: wasn't that much work
[14:43] <ogra> koza, ok, i bit the bullet andf wired up mine with FTDI ... i'm on J25 wired black,white green when the SD card slot is pointing at me ... i get serial output just fine
[14:46] <mup> PR snapd#3410 closed: cmd/hotfix: add hotfix tool <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3410>
[14:46] <cachio> niemeyer, so, I can do what is being done for ubuntu core, and add a boot command line option for the entropy
[14:46] <niemeyer> morphis: Is there something ready to be looked at?
[14:46] <cachio> niemeyer, but, it requires a reboot
[14:47] <niemeyer> cachio: So we can't do it.. we don't want to add another reboot on that pipeline
[14:47] <morphis> niemeyer: not yet, being in a meeting but will do that afterwards
[14:47] <ogra> koza, http://people.canonical.com/~ogra/image20170613_164358179.jpg ... in my terminal i use "screen /dev/ttyUSB0 115200"
[14:47] <niemeyer> cachio: We want something closer to what we discussed today in the call
[14:47] <cachio> niemeyer, ok
[14:48] <ogra> koza, also ... which image exactly are you using ... daily or daily-stable (i only ever use daily here)
[14:52]  * zyga-suse returns to work
[14:53] <ogra> zyga-suse, did you bring zyga-fedora along with you ? :)
[14:54] <koza> ogra, i think stable, will go for daily then
[14:55] <koza> lol :-)
[14:55] <ogra> koza, well, the gadget is the same on both so you should definitely see serial output frrom uboot
[14:55]  * ogra tries the different images 
[14:58]  * koza will try once is done with meeting
[14:59] <ogra> so daily-stable seems fine here, i'm in console-conf
[14:59] <koza> ogra, i see, must be sth with my board then
[15:00] <ogra> how did you write the SD ? perhaps something went wrong there
[15:00] <koza> sudo dd if=/home/konrad/Downloads/ubuntu-core-16-hummingboard.img of=/dev/sdb bs=32M
[15:00] <koza> ogra, ^^
[15:00] <ogra> sounds about right ...
[15:00] <ogra> xzcat /datengrab/images/snappy/daily-stable/current/ubuntu-core-16-hummingboard.img.xz | sudo dd of=/dev/sdc bs=32M
[15:01] <ogra> thats what i just used (got a local copy of the all-snaps fiolder here)
[15:03] <ogra> koza, oh,.... did you make sure that the card was unmounted before dd'ing to it ?
[15:03] <ogra> mine gets automounted by nautilus and i have to sudo umount /dev/sdc1 and 2 first
[15:04] <ogra> if you dont do that you get a corrupt card
[15:05] <ogra> (or like US people might call it a "trump card" :P )
[15:05] <psftw> I should NOT be running snapcraft as root, right?
[15:05] <ogra> right
[15:05] <psftw>  <3 ogra
[15:05] <psftw> so I have a package which depends on a PPA ;-)
[15:05] <ogra> if it needs root permissions it is clever enough to ask for it during the process
[15:06] <psftw> https://github.com/docker/docker-snap/blob/master/snap/snapcraft.yaml#L68
[15:06] <psftw> ^ installs the PPA to host to support the build process
[15:07] <psftw> should I just prepend "sudo" to appropriate commands ?  wonder if that would work on the launchpad build machines.
[15:07] <ogra> i think in LP it simply runs as root anyway
[15:07] <ogra> there are no users in the buildd setups
[15:08] <psftw> thank you, will give it a shot
[15:11] <ogra> koza, oh, interesting fact (not relevant for your prob though) is that serial doesnt accept any input
[15:15] <koza> ogra, could not unmount indeed (slow re still in a mtg)
[15:16] <ogra> koza, yeah, no worries i'm noot impatient :)
[15:16] <ogra> *not
[15:18] <ogra> hmm, i really wonder why my serial only has output ... but no input
[15:19] <morphis> niemeyer: spread-13 it is now
[15:19] <niemeyer> morphis: On it
[15:19] <morphis> niemeyer: thanks!
[15:23] <niemeyer> morphis: The image is 1.7G
[15:24] <morphis> niemeyer: 1.2G is it for me, again block-level thing but nothing more I can cleanup
[15:24] <niemeyer> morphis: Just for comparison
[15:24] <morphis> ah ok
[15:24] <niemeyer> ubuntu 16.04, is 608MB
[15:25] <niemeyer> 32 bits is 872
[15:25] <niemeyer> 16.10 is 610
[15:26] <niemeyer> fedora is 1.4GB, opensuse is 1.5, and now arch is 1.7GB
[15:26] <ogra> crazy ... why are they so excessively big ?
[15:26] <niemeyer> morphis: What might be going on there?  Block or not those images are growing and growing
[15:26] <niemeyer> morphis: We have a limit in how much we can take in space, not to mention those bits need to move around
[15:27] <morphis> niemeyer: I don't really know, I got the image with 1.9G and reduced it to 1.2G
[15:27] <niemeyer> morphis: All of the sizes above are block wise
[15:28] <morphis> ok
[15:28] <niemeyer> morphis: My guess is that either there's data being left around, or that there's a ton of software that is not relevant for our tests in place
[15:28] <ogra> koza, and just FYI http://paste.ubuntu.com/24849651/ is the serial log of my most recent boot
[15:29] <morphis> niemeyer: https://paste.ubuntu.com/24849664/
[15:29] <morphis> that is on the file level
[15:29] <mup> PR snapcraft#1364 opened: lxd: Inject snapcraft and core snaps into the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1364>
[15:29] <niemeyer> morphis: Yeah, so 1.2GB on usr.. what is there?
[15:29] <morphis> niemeyer: usr/lib
[15:30] <morphis> usr/share is 289M and usr/lib 789M
[15:30] <niemeyer> morphis: Yeah, so there's likely a *ton* of libraries in there, right? :)
[15:30] <morphis> the difference to debian/ubuntu is that the packages are not really split into sub packages like -docs etc
[15:30] <morphis> niemeyer: sure but removing more than I did break the system
[15:31] <niemeyer> morphis: Yeah, I can understand that removing certain things might break the system.. we don't want to remove those
[15:31] <niemeyer> morphis: But are you saying that every single library in there is a strict requirement?
[15:32] <niemeyer> morphis: I'd look for large trees of packages which are not relevant for us
[15:32] <niemeyer> That's what I did with the Ubuntu images, and why they are small
[15:32] <niemeyer> I wasn't the one cooking 14.04.. it's 1.45G as well
[15:35] <mvo> jdstrand: hey, I am looking into porting the sh based tests for snap-confine current, I put a bunch of things into the unit tests, I wonder if you have suggestions/opinions about the spread based part of this, one way would be a direct port like https://github.com/snapcore/snapd/pull/3431/commits/5dafe3f80c0afc1378be975f5a14d7c27c03d3b2#diff-c0e64403c5c43941d93df36f87c53bb5R6 but that feels slightly overkill to do for all the old sh-based tests,
[15:35] <mvo> how do you feel about it?
[15:35] <mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
[15:35] <morphis> niemeyer: https://paste.ubuntu.com/24849689/
[15:36] <mvo> jdstrand: maybe can can have a short HO or something later to discuss how to best test this
[15:36] <morphis> niemeyer: that are the packages which are left
[15:37] <fgimenez> hey jdstrand, i needed to add some changes to the test-snapd-autopilot-consumer snap, could you please take a look (no rush at all)? https://dashboard.staging.snapcraft.io/dev/snaps/8405/rev/5/ if you can take a look to prod too (same snap) that would be great https://dashboard.snapcraft.io/dev/snaps/7807/rev/2/
[15:38] <niemeyer> morphis: Pretty small.. still, have you tried to take stuff out of there?
[15:38] <morphis> niemeyer: sure
[15:39] <niemeyer> morphis: licenses is likely just the text.. reiserfsprogs would be surprising to be a requirement, etc
[15:39] <niemeyer> morphis: tzdata, we don't care
[15:39] <morphis> but that one is really just 577kb
[15:39] <morphis> tzdata breaks glibc
[15:40] <morphis> hm, why was make still in there but 1.47M just
[15:40] <niemeyer> morphis: Yes, the difference between size bit-wise and size block-wise is that every block is 4kb..
[15:41] <niemeyer> morphis: make isn't a big deal.. we'll need to get it in anyway
[15:41] <mup> PR snapd#3475 opened: Change main store host to api.snapcraft.io <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3475>
[15:45] <niemeyer> morphis: The 320MB in var.. what are they mostly about?
[15:45] <mup> PR snapd#3476 opened: snap-confine: validate SNAP_NAME against security tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/3476>
[15:45] <pstolowski> zyga-suse, ^ when you have a moment..
[15:45] <mvo> jdstrand: I get some lunch now, lets catchup later
[15:45] <zyga-fedora> yep, looking
[15:46] <zyga-fedora> pstolowski: make fmt
[15:46] <pstolowski> zyga-suse, note, I deliberately removed two "paranoid" checks, not sure if they were adding any value at that point.. just repeated cheks
[15:47] <pstolowski> zyga-fedora, ah, sorry
[15:51] <zyga-fedora> pstolowski: 2 comments
[15:51] <pstolowski> thx
[15:55] <pstolowski> zyga-fedora, done
[16:00] <zyga-fedora> pstolowski: can you add some tests that show that a valid snap name and valid security tag that don't match are not passing verification please?
[16:00] <zyga-fedora> pstolowski: perhaps at the end of the test function you modified
[16:00] <zyga-fedora> pstolowski: // Good name and security tags that don't match each other
[16:00] <zyga-fedora> pstolowski: and then some tests
[16:01] <pstolowski> zyga-fedora, I added one test
[16:01] <pstolowski> zyga-fedora, look for "nonmatchingname"
[16:02] <pstolowski> ah perhaps it belongs to the "..names we know are good" section
[16:02] <pstolowski> or as you say
[16:02] <pstolowski> a new one
[16:02] <jdstrand> mvo: sorry, still heads down in the bpf review
[16:02] <jdstrand> mvo: ping me when you get back
[16:02] <zyga-fedora> pstolowski: I added two more comments
[16:11] <morphis> niemeyer: that is the pkgdb again which I just have temporarily until I logout
[16:11] <morphis> niemeyer: then /var is down to 24M
[16:16] <morphis> niemeyer: https://paste.ubuntu.com/24849997/ is the size breakdown per package
[16:17] <niemeyer> morphis: Cool, thanks
[16:17] <morphis> but nothing of the top ones can be remove without breaking the system
[16:17] <niemeyer> morphis: I went ahead and created the image so you're not blocked for the rest of the week
[16:17] <morphis> niemeyer: really? I am still logged in :-)
[16:17] <niemeyer> morphis: But this is our largest image yet.. would be nice to drive it down at some point
[16:18] <morphis> wondering if Linode uses a different fs block size for these images
[16:18] <niemeyer> morphis: Nope, 4kb
[16:18] <morphis> right
[16:19] <morphis> niemeyer: but I agree that these larger images sizes are not really what we want
[16:20] <morphis> wondering how much is this related to the fact that other distros pay less attention to properly splitting source packages into multiple binary packages
[16:21] <morphis> niemeyer: found another one, now down to 901M according to df
[16:22] <niemeyer> morphis: Ah, nice!
[16:22] <morphis> niemeyer: give me a few more minutes before you snapshot again
[16:22] <niemeyer> morphis: Sounds good, just ping me.. I'll take the machine off the pool to make sure we're not losing that
[16:23] <morphis> thanks
[16:23] <pstolowski> zyga-fedora, pushed
[16:23] <zyga-fedora> pstolowski: thanks
[16:24] <zyga-fedora> pstolowski: +1
[16:24] <zyga-fedora> pstolowski: I requested a 2nd review from jdstrand
[16:24] <pstolowski> zyga-fedora, thanks!
[16:35] <morphis> niemeyer: ok, don't get it much smaller, lets take what we have
[16:49] <niemeyer> morphis: Ready to snapshot 13?
[16:50] <morphis> niemeyer: yes!
[16:50] <niemeyer> Ok, there we go
[16:51] <niemeyer> morphis: I must be looking at the wrong machine
[16:52] <niemeyer> morphis: Size didn't change at all
[16:52] <niemeyer> morphis: It's also suspect that you didn't get logged off earlier
[16:52] <morphis> ah!
[16:52] <niemeyer> morphis: Are you still logged in now?
[16:53] <morphis> niemeyer: yes, which one did you look at?
[16:53] <niemeyer> :P
[16:53] <niemeyer> morphis: Okay, we're definitely not looking at the same machine
[16:53] <niemeyer> morphis: 13..
[16:53] <morphis> .spread-reuse.yaml tells me 20 .. wtf
[16:53] <niemeyer> morphis: Aha!
[16:53] <niemeyer> Okay, let me check
[16:55] <morphis> niemeyer: don't tell me it's much smaller now :-)
[16:55] <niemeyer> Well, I hope it is!
[17:02] <niemeyer> morphis: 1.25G, well done!
[17:02] <morphis> niemeyer: not well enough :-)
[17:02] <niemeyer> morphis: Machine back up and running, snapshot done
[17:02] <morphis> thanks!
[17:02] <niemeyer> morphis: Thank you!
[17:02] <morphis> niemeyer: if we don't talk anymore, enjoy your long weekend!
[17:03] <niemeyer> morphis: Thanks a lot
[17:05] <Chipaca> niemeyer: 23   Done    2017-06-13T17:04:51Z  2017-06-13T17:04:51Z  [/usr/bin/printf hello]
[17:06] <Chipaca> niemeyer: also, http://pastebin.ubuntu.com/
[17:06] <Chipaca> still need to look into aborting it
[17:07] <niemeyer> Chipaca: Suspect there's a number missing on that second line :P
[17:07] <Chipaca> maybe
[17:07] <Chipaca> who knows
[17:07] <Chipaca> niemeyer: http://pastebin.ubuntu.com/24850224/
[17:07] <Chipaca> silly "this field is required" error
[17:08] <Chipaca> niemeyer: the “INFO hello” thing is noteworthy
[17:08] <niemeyer> Chipaca: Yeah, I was just thinking about it
[17:08] <Chipaca> niemeyer: I'm spawning a couple of goroutines and updating the task's log as stdout/stderr change
[17:09] <niemeyer> Chipaca: I don't think we do that in hooks except when it errors
[17:09] <niemeyer> Chipaca: WHich is perhaps a good idea
[17:09] <morphis> niemeyer, zyga-suse, mvo: was there anything special you guys did with the loop-devices each snap create to prevent them from showing up in the desktop launcher?
[17:10] <Chipaca> niemeyer: probably for the best :-)
[17:10] <Chipaca> i'll throw away the goroutines and just use a pair of buffers
[17:10] <niemeyer> Chipaca: +1
[17:10] <niemeyer> Chipaca: and then, I think we want to tune the summary, but that was probably just for demonstration's purpose, right?
[17:11] <Chipaca> yeah.... demonstration...
[17:11] <Chipaca> :-)
[17:11] <niemeyer> Suppa, thanks
[17:11] <Chipaca> niemeyer: whoever creates the task sets the summary, so they'd have more context to add
[17:11] <Chipaca> the task summary itself i think will stay about the same
[17:11] <niemeyer> Yeah, +1
[17:11] <Chipaca> (helps debugging)
[17:12] <Chipaca> the change summary would be the contextual one, i mean
[17:12] <niemeyer> Chipaca: About the same as what?
[17:12] <Chipaca> e.g. on the change summary "restarting services: foo1 foo2"
[17:12] <Chipaca> on the task summary, "systemctl restart snap.foo1.service snap.foo2.service"
[17:13] <niemeyer> Chipaca: The task summary should follow the style we use elsewhere I think
[17:13] <niemeyer> Chipaca: Same for the change summaries, actually
[17:13] <Chipaca> niemeyer: can i have an example?
[17:13] <niemeyer> Chipaca: We even have a style for when there are too many things to report, IIRC
[17:14] <niemeyer> % snap changes
[17:14] <niemeyer> ID   Status  Spawn                 Ready                 Summary
[17:14] <niemeyer> 488  Done    2017-06-13T12:24:58Z  2017-06-13T12:25:09Z
[17:14] <niemeyer> Clearly NOT THAT
[17:14] <niemeyer> Where did the summary go?
[17:14] <Chipaca> niemeyer: no i mean for the specific case of this
[17:14] <niemeyer> Bizarre
[17:14] <Chipaca> I can see e.g. Done    2017-06-12T13:04:42Z  2017-06-12T13:04:42Z  Remove aliases for snap "test-snapd-service"
[17:16] <niemeyer> Chipaca: Yeah.. Restart service "foo.baz" on snap "baz"?
[17:16] <Chipaca> niemeyer: so the same as the change summary?
[17:16] <niemeyer> Yeah, if we have nothing better
[17:16] <niemeyer> Here are some example for the ghost change above
[17:16] <Chipaca> so just set by the caller
[17:17] <niemeyer> https://www.irccloud.com/pastebin/1EgvoizI/
[17:17] <Chipaca> niemeyer: but a difference is that those tasks are always doing that thing, afaik
[17:18] <niemeyer> Chipaca: I don't see how that would justify an entirely different style
[17:18] <Chipaca> whereas this task is always just doing exec of something it doens't know the significance of
[17:18] <Chipaca> that's why i asked you for an example for this case in particular
[17:18] <niemeyer> E.g. we literally have a task saying 'Stop snap "lxd" services'  above
[17:18] <Chipaca> yes, in a task that just does that
[17:19] <niemeyer> Yeah..?
[17:19] <niemeyer> I hope all these tasks just do what they claim :)
[17:19] <Chipaca> my point is that this task gets told “execute systemctl restart snap.lxd.service”
[17:19] <Chipaca> which is a long way from "restart lxd services"
[17:20] <niemeyer> Chipaca: Sorry, I'm trying to be difficult.. I just don't understand the point.. in my mind we have a pretty clear pattern for task summaries, and should follow suit for this one task as well.. all these tasks we see above have different implementation details across each other
[17:21] <niemeyer> Even then, we have a one-liner summary that is user oriented and worded in similar terms
[17:21] <Chipaca> niemeyer: can you, please, for the third time, give me a concrete example of what you want this task summary to look like?
[17:24] <niemeyer> Chipaca: I already provided an example above (17:16).. but I think something even simpler, like "Restart service foo.bar" when it's a single one, or "Restart service foo.bar and bar.baz" when two, or something similar to what we do when aggregating snap names in the API otherwise, should do.. WDYT?
[17:25] <niemeyer> Chipaca: and again, yes, I think it's fine to have change and task with the same summary if they are indeed matching each other
[17:25] <Chipaca> thank you
[17:25] <Chipaca> i needed to be clear on whether the summary was going to get passed in or not
[17:26] <Chipaca> this does mean we lose track of exactly what was executed, although I guess I could log it
[17:26] <niemeyer> Chipaca: I don't think we need to log what's executed.. that's an implementation detail, same as for other tasks
[17:27] <Chipaca> ok
[17:28] <jdstrand> mvo: hey, since I didn't hear from you, this should make it easier: https://github.com/snapcore/snapd/pull/3431/commits/5dafe3f80c0afc1378be975f5a14d7c27c03d3b2#r121744025
[17:28] <mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
[17:29] <pedronis> Chipaca: HookTask gets the summary passed in, I suppose you want the same
[17:36] <mvo> jdstrand: thanks a bunch, I have some obligations here for at least one more hour, thanks a lot for your comments and also for the verification code!
[17:38] <mvo> jdstrand: and agreed that it is valuable to have one integration test with bad syntac
[17:45] <jdstrand> mvo: whenever you get back to it, I gave input for read/stat as well as the path checks. I also responded to Gustavo's comment. basically, check your mail :)
[17:45] <jdstrand> mvo: I'm continuing to look at this PR
[17:47] <Chipaca> pedronis: yeap
[17:47] <jdstrand> mvo: (not saying you haven't checked your mail, just saying more is coming)
[17:48] <cachio> ogra, do you know another way to increase entropy, I can't reboot the machine so I cant add that command line
[17:49] <ogra> cachio, not really, but perhaps the security guys do ...
[17:49] <ogra> tyhicks, jdstrand ^^
[17:49] <cachio> tx
[17:51] <tyhicks> cachio: do you have a hwrng device available?
[17:51] <cachio> tyhicks, I need it for a vm
[17:51] <mup> PR snapd#3447 closed: debian: unify built_using between the 14.04 and 16.04 packaging branch <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3447>
[17:52] <cachio> and I need to increase the entropy
[17:52] <tyhicks> cachio: is the VM using pollinate?
[17:52] <cachio> I have used pollinate and rngd-tools but we are seeing a segfault which is breaking our tests
[17:53] <cachio> tyhicks, yes, we are currently using pollinate but we want to change it
[17:53] <cachio> tyhicks, https://forum.snapcraft.io/t/error-creating-key/964
[17:55] <cachio> tyhicks, some tests are failing because the entropy is too low and snapd cand generate a key
[17:55] <cachio> tyhicks, it happens when there is a seg faul as it is described in the forum
[17:55] <tyhicks> cachio: have you looked into fixing the rngd segfault?
[17:56] <cachio> tyhicks, no
[17:56] <cachio> tyhicks, no idea how to do it
[17:56] <mup> PR snapd#3429 closed: interfaces/snapd-control: also allow use of /usr/bin/snap <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3429>
[17:57] <tyhicks> cachio: I need some time to read through that forum thread
[17:57] <tyhicks> cachio: this is not a trivial problem
[17:59] <cachio> tyhicks, ok, any advice about what I could start doing?
[18:01] <tyhicks> cachio: not yet - I need to understand your problem
[18:01] <cachio> tyhicks, ok
[18:12] <tyhicks> cachio: you said that the tests are running in a VM - do you have admin rights on the host?
[18:13] <cachio> tyhicks, yes
[18:14] <tyhicks> cachio: you could set up virtio-rng to feed entropy from the host into the guest via a virtual hwrng
[18:15] <cachio> tyhicks, ok
[18:17] <cachio> tyhicks, I'll try with this one
[18:18] <cachio> tyhicks, virtio-rng is just for virtual environments?
[18:19] <tyhicks> cachio: yes
[18:19] <tyhicks> cachio: it is only helpful in VMs where the host has set up a virtio-rng device for the VM
[18:22] <tyhicks> cachio: what's the oldest version of gpg that you'll need to operate on?
[18:22] <cachio> tyhicks, I need to run snapd test in real hardware and in vms, that are from different sources, for example we currently used linode in the cloud and qemu
[18:23] <tyhicks> cachio: then virtio-rng may not work for you
[18:24] <tyhicks> (you're less likely to hit lack of entropy issues on real hardware but maybe you still have that problem on real hardware)
[18:25] <cachio> tyhicks, is there any way to feed manually the entropy pool
[18:25] <cachio> tyhicks, with fake random data?
[18:26] <tyhicks> cachio: that's what you're doing with rngd
[18:26] <tyhicks> cachio: fixing the segfault is the easiest solution
[18:28] <cachio> tyhicks, ok, I'll report it
[18:29] <tyhicks> cachio: rngd is community maintained (in universe) so it isn't likely to get attention in normal circumstances
[18:29] <tyhicks> cachio: how urgent do you need it fixed?
[18:30] <cachio> tyhicks, it is for our snapd test suite
[18:30] <cachio> there are several tests failing because of that
[18:30] <tyhicks> cachio: ok - first step is to report the bug
[18:31] <tyhicks> cachio: then we'll all need to figure out who is going to work on fixing it
[18:31] <tyhicks> rngd is simple so I'm hoping the fix won't be too difficult
[18:32] <cachio> tyhicks, well that's something really good
[18:33] <cachio> niemeyer, we were discussing a solution to the lack of entropy problem
[18:34] <niemeyer> cachio: hey
[18:34] <niemeyer> cachio: Ok, and what's up there?
[18:35] <cachio> niemeyer, so, the best approach to deal with this is to fix the issue that it is causing the segfault in rngd
[18:36] <tyhicks> to be clear, the rngd hack of using /dev/urandom as the HWRNG device should only be used for testing environments
[18:36] <cachio> tyhicks, of course, this is our case
[18:36]  * tyhicks nods
[18:37] <cachio> niemeyer, so the change that I did, won't be needed
[18:38] <niemeyer> cachio: Yeah, that's the most reasonable.. but what's the ETA for the fix?  Do we need to do anything meanwhile to make sure we're not getting tests hanging?
[18:39] <cachio> niemeyer, we can leave my patch with the note, and once it is fixed, I'll remove it
[18:39] <cachio> niemeyer, I know it is not the best approach
[18:39] <cachio> niemeyer, but it is a temporal workaround
[18:40] <niemeyer> cachio: That has the issues we discussed.. can we cheaply do one of the changes we discussed today?
[18:41] <niemeyer> cachio: In practice that fix will take a long time to propagate to all the kernels we care about
[18:41] <niemeyer> Ah, not kernels, it was rngd isn't it?  Either way, same case
[18:41] <tyhicks> niemeyer: the fix will be to rngd, not the kernel, but your point still stands
[18:42] <cachio> niemeyer, the change is in rngd
[18:42] <niemeyer> Anybody else? ;)
[18:42] <tyhicks> :)
[18:43] <tyhicks> niemeyer: is it possible for you to pre-generate a key that will be used for all test runs?
[18:43] <tyhicks> (include it in the test suite and put it in place before each test run)
[18:45] <cachio> tyhicks, the issue is that there are tests that are testing the create-key
[18:46] <cachio> tyhicks, so, for those cases we can't pregenerate the keys
[18:46] <tyhicks> cachio: it isn't necessarily correct to pump up the system with fake entropy for those tests, either
[18:47] <tyhicks> in the field, create-key will be used on low entropy systems
[18:48] <tyhicks> (there's no perfect solution to this problem)
[18:49] <tyhicks> the create-key tests could be skipped when /proc/sys/kernel/random/entropy_avail is below a certain threshold
[18:50] <cachio> tyhicks, well that could be a solution
[18:52] <cachio> niemeyer, what do you think?
[18:52] <tyhicks> possible permanent solutions:
[18:52] <cachio> niemeyer, we can't pre-create keys, manually feed the pool is not cheap
[18:53] <tyhicks> 1) fix rngd (fix has to propagate to all affected distros that you test on)
[18:53] <tyhicks> 2) write your own version of rngd that knows how to feed fake entropy to /dev/random
[18:54] <tyhicks> 3) remove /dev/random and mknod it back using the device major/minor of /dev/urandom (I'm not certain that this will work)
[18:54] <cachio> tyhicks, well, how much effort should be needed for 2)
[18:54] <cachio> ?
[18:54] <niemeyer> cachio: We don't want to skip the test like this.. otherwise this might be completely broken and we'll never know
[18:55] <tyhicks> cachio: crack open the rngd sources to see - you'd essentially be forking it
[18:55] <niemeyer> tyhicks: How to feed entropy into the kernel?
[18:56] <niemeyer> tyhicks: If it's just a matter of piping data somewhere, which I hope it is, it might be much simpler than forking rngd
[18:56] <tyhicks> niemeyer: it is an ioctl()
[18:57] <tyhicks> niemeyer: the random(4) man page details it
[18:58] <tyhicks> the Configuration section of that man page also touches on my option #3 above (the mknod command)
[18:59] <tyhicks> I need to get back to some other work now
[18:59] <tyhicks> I hope those suggestions are helpful
[19:01] <cachio> tyhicks, sure, tx
[19:07] <niemeyer> tyhicks: Indeed, thanks
[19:07] <niemeyer> cachio: You said earlier we already had the /dev/random trick at the pepare level?
[19:08] <cachio> niemeyer, yes
[19:09] <niemeyer> cachio: If that's the case, why are we redoing it in that function?
[19:10] <cachio> niemeyer, it is because the entropy pool is cleaned when the segfault happens
[19:11] <cachio> niemeyer, I could make something generic, to regenerate entropy when is it under 700 for all the tests
[19:11] <niemeyer> cachio: Yeah, I get it, but isn't the /dev/random tweak already in place?
[19:12] <cachio> niemeyer, it is done at the begening of the test suite
[19:12] <niemeyer> cachio: Yes, so why do we need to do that every time the function is called?  Why isn't it simply a restart?
[19:13] <cachio> niemeyer, you mean just to restart it? not check for the entropy level?
[19:14] <cachio> niemeyer, for each test?
[19:14] <niemeyer> cachio: Why do we have that environment line change every time
[19:14] <cachio> niemeyer, echo "HRNGDEVICE=/dev/urandom" > /etc/default/rng-tools =
[19:14] <cachio> this one?
[19:15] <niemeyer> Yes :)
[19:15] <cachio> niemeyer, it can be done just the first time
[19:15] <cachio> in the prepare
[19:15] <niemeyer> cachio: Then, I don't think I get the whole picture.. when it crashes, it restarts, right?
[19:16] <cachio> when it crashes it does not restart
[19:16] <niemeyer> cachio: Oh?
[19:16] <cachio> niemeyer, that's why I am doing this
[19:17] <niemeyer> cachio: Why would it not restart?  Isn't it a systemd unit as usual?
[19:17] <cachio> you mean rng-tools?
[19:19] <cachio> I'll take a look to see why it is not restarting
[19:19] <niemeyer> cachio: Thanks
[19:20] <niemeyer> cachio: Maybe that's the only thing we need to fix
[19:35] <ryebot> My snap has a configure hook that attempts to write to the file $SNAP_DATA/args. Most of the time it works, but on some (identical) lxc containers, I get an apparmor denial: http://bit.ly/2reFFt5
[19:37] <ryebot> Any idea what might be going wrong, and why it's not going consistently wrong?
[19:38] <kyrofa> ryebot, that should be non-fatal, it's a snapctl denial, nothing to do with you directly
[19:39] <kyrofa> It's noisy though, and last I heard work was ongoing to fix it
[19:53] <ssbash> hey if anyone has a second I'm still having trouble with getting my python path wrapper command to work?
[19:53] <ryebot> kyrofa: thanks
[19:54] <ssbash> here is the bash script: http://paste.ubuntu.com/24851223/ snapcraft.yaml: http://paste.ubuntu.com/24851218/ and the error message:http://paste.ubuntu.com/24844781/
[20:17] <mup> Bug #1697770 opened: can't run juju from snap: "Too many levels of symbolic links" <Snappy:New> <https://launchpad.net/bugs/1697770>
[20:30] <ssbash> cachio? do you see any probkems with my bash script or snapcraft.yaml?
[20:34] <ryebot> kyrofa: Alright, red herring apparmor logs aside, any reason my snap wouldn't be able to write to $SNAP_DATA? http://bit.ly/2rXVwzm
[20:36] <kyrofa> ryebot, no, that seems weird indeed. Can I take a look at the configure hook itself?
[20:36] <ryebot> kyrofa: certainly, one second
[20:36] <ryebot> kyrofa: http://paste.ubuntu.com/24850838/
[20:38] <kyrofa> Huh, yeah, I really have no explanation for that. Particularly why it's flaky. I assume you've verified that the only denial you're seeing is the snapctl one?
[20:39] <ryebot> kyrofa: let me check. I've also been advised to check the host as well, so let me do that too.
[20:40] <cachio> niemeyer, so, basically, rng-tools tools is not configured to restart after a crash
[20:40] <cachio> it is stopped when the crash happens
[20:42] <kyrofa> ryebot, ahhhh, running in lxc?
[20:42] <cachio> niemeyer, so I can make some changes to autorestart, but it could have different implementations based on the distro
[20:42] <cachio> niemeyer, or I can check in the prepare-each if the service is stopped and start it again
[20:43] <cachio> once I start it the entropy is recovered
[20:43] <ryebot> kyrofa: yes
[20:43] <ryebot> kyrofa: sorry, second time I haven't made that clear enough in these parts :\
[20:44] <kyrofa> ryebot, yeah I run snaps on lxc as well, snapd doesn't run quite right there
[20:44] <kyrofa> ryebot, typically you don't need to. But snapd and lxc share a lot of the same tech, and they don't always get along
[20:45] <ryebot> gotcha
[20:45] <ryebot> anyway, yeah, only snapctl
[20:45] <ryebot> kyrofa ^
[20:47] <kyrofa> Nothing on the host either?
[20:47] <ryebot> correct
[20:55] <kyrofa> ryebot, sorry, I really don't know what's happening. You'll need to wait for someone in snapd
[20:57] <ryebot> kyrofa: no worries, thanks for reaching out!
[20:57] <kyrofa> It'd be nice to see snapd add lxc to their test suite
[20:58] <kyrofa> Weird breakages will probably continue until that happens
[21:02] <bdx> is there a ruby/rails plugin laying around anywhere?
[21:03] <kyrofa> bdx, ruby is pretty easy, talk to elopio. Rails is a little harder because bundler likes symlinks
[21:04] <kyrofa> I just haven't gotten the time to finish one. I'd love to see one though, if you work on it
[21:15] <bdx> kyrofa: I've been looking into it pretty heavily ..... I'm having trouble understanding what I need to do in the snap world to even start ....
[21:16] <bdx> kyrofa: so, 1) need ruby - it would be best to create a plugin for ruby im guessing
[21:17] <kyrofa> bdx, yes, that's something elopio is working on. I suppose bundler support could be added there, in which case it would work for rails as well
[21:17] <kyrofa> Obviously Gemfiles are not unique to rails
[21:17] <bdx> then use the ruby plugin and the git plugin together
[21:17] <bdx> yeah
[21:18] <kyrofa> There is no git plugin-- those are sources. You won't need to do anything special there, they're part of core snapcraft
[21:18] <bdx> kyrofa: awesome
[21:19] <kyrofa> bdx, here, let me show you an example, but you really should talk to elopio about the ruby plugin, I know he was wanting to work with someone to do it
[21:19] <bdx> kyrofa: great thanks
[21:19] <kyrofa> bdx, how familiar are you with ruby, by the way?
[21:20] <bdx> kyrofa: I can read and write it, but dont prefer it ... I have 30+ prod rails deploys via charms
[21:21] <bdx> so my rails charms are on point - i feel like this would set me up to be ready to snap them
[21:21] <kyrofa> Indeed
[21:21] <kyrofa> bdx, here's the cmake plugin as an example: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/cmake.py
[21:22] <kyrofa> bdx, here's some basic info for how to write plugins and test them in your own tree instead of needing to patch snapcraft: https://snapcraft.io/docs/build-snaps/plugins
[21:23] <bdx> excellent, thanks for these
[21:23] <bdx> would lthe nodejs plugin be more similar you think?
[21:23] <ssbash> http://paste.ubuntu.com/24851807/
[21:24] <kyrofa> Yes perhaps so. I do think we should support multiple versions of ruby
[21:24] <bdx> it seems like nodejs would be more similar in the sense that there are multiple versions of node that the plugin should be able to handle
[21:24] <kyrofa> Yep
[21:24] <ssbash> hi can someone explain why my snap is deliberly ignoring the python path i've set for it?
[21:25] <nacc> ssbash: if you run snap run --shell and then run your command with your pythonpath set, you should be able to debug it live
[21:25] <bdx> kyrofa: I'm also wondering how much the gemfile should matter .... some consider it a best practice to define their ruby version in their gemfile
[21:26] <kyrofa> bdx, interesting, I've never done that. What tool consumes it? Bundler can't install it, right?
[21:26] <kyrofa> I'd lean more toward using .ruby-version like what rvm might place there
[21:27] <bdx> elopio
[21:27] <ssbash> nacc: I tried running env to seee what the pythonpath was, and it print out "PYTHONPATH=:/snap/wsnap/x1/lib/python3.5/site-packages"
[21:28] <bdx> elopio: I would love to connect concerning a ruby snap - jamesbeedy@gmail.com
[21:28] <bdx> so
[21:28] <bdx> kyrofa: http://imgur.com/a/g44Sb
[21:28] <ssbash> everything seems to be set correctly, I have no idea why the snap command isnt working
[21:28] <bdx> I think it acts more like a stop check
[21:28] <bdx> if your rubyversion doesnt match, bundler wont install
[21:29] <nacc> ssbash: but now your PYTHONPATH doesn't include the dist-packages? what is the error you get?
[21:29] <ssbash> "ImportError: No module named 'wraticus.lib'; 'wraticus' is not a package"
[21:29] <kyrofa> bdx, interesting, okay. I say keep it simple in the first rev, just accept a `ruby-version` option, fetch the source, and build it
[21:29] <ssbash> wraticus is definitely in the site-packages directory
[21:30] <kyrofa> bdx, then we can start looking into those things once we have a basic plugin working
[21:30] <nacc> ssbash: ok, in your snap shell, run python and try to import wraticus
[21:30] <nacc> ssbash: and then try to import wraticus.lib
[21:31] <bdx> kyrofa: entirely ... I'll keep investigating, and try to get in touch with elopio
[21:31] <kyrofa> bdx, I've given him your contact info in another channel as well, he's probably out to lunch
[21:31] <kyrofa> Please let me know if I can help
[21:32] <ssbash> nacc: I'm able to import both wraticus and wraticus.lib
[21:33] <nacc> ssweeny: hrm
[21:34] <bdx> kyrofa: your insight has been super helpful, thanks. I'm going to give the cmake and nodjs plugins a glance over this evening and try to get a strwman up
[21:34] <kyrofa> bdx, any time :)
[21:34] <bdx> I'll send you guys a ping tomorrow (hopefully with some progress)
[21:34] <kyrofa> Good deal, I'll be here!
[21:38] <ssbash> nacc: is there anything I can do? here is my snapcraft.yaml for reference: http://paste.ubuntu.com/24851218/
[21:38] <bdx> kyrofa: so you think I should keep away from system ruby, and look to use a ruby version manager instead, due to the ease of changing versions etc etc?
[21:39] <kyrofa> bdx, I definitely suggest not using system ruby. As for what TO use, well, I'm not sure. First cut I'd just build ruby from source
[21:39] <nacc> ssbash: and what does snapify.sh contain?
[21:39] <kyrofa> bdx, I doubt any ruby version manager is going to support deploying that ruby somewhere specific, whereas you can always install ruby in a snap
[21:40] <nacc> ssbash: and if you run snapify.sh from your shell session, does it work?
[21:40] <ssbash> nacc: http://paste.ubuntu.com/24851223/
[21:40] <kyrofa> bdx, for example, rvm supports per-user rubies and system-wide rubies, but not "put that ruby <here>" as far as I know
[21:41] <ssbash> nacc: running it from the shell session gives me the same "ImportError: No module named 'wraticus.lib'; 'wraticus' is not a package"
[21:42] <nacc> ssbash: line 2, should be PYTHONPATH=$PYTHONPATH:...
[21:43] <nacc> ssbash: you are removing the dist-packages from your path :)
[21:43] <nacc> ssbash: specifically, the wrapper that's calling your wrapper is (i think) setting the snap's dist-patckage in the path and you're then eliding them
[21:49] <bdx> kyrofa: yeah ... I was thinking more along the lines of a simple api via the plugin that manages ruby versions through the version manager
[21:50] <ssbash> oh ok
[21:51] <bdx> but yeah possibly not ... I'll just try to get something super basic working
[21:51] <kyrofa> bdx, well, the plugin (and snapcraft in general) is only involved when creating the initial snap. Once the snap it created, it needs to be standalone
[21:51] <bdx> I see
[21:51] <ssbash> nacc: ill give it a try
[21:51] <kyrofa> So the ruby must be in the snap at the end, regardless of how you get there
[21:52] <bdx> so the plugin cant offfer up an api that can be used throughout the lifecycle of the snap?
[21:52] <bdx> I see
[21:52] <kyrofa> Right, the plugin is gone by the time the snap is running. Snapcraft builds snaps, and has nothing to do with running them (that's snapd)
[21:54] <bdx> possibly the plugin could grab the ruby version from the Gemfile if it exists then, and just download and build that version of ruby
[21:54] <kyrofa> Right
[21:54] <kyrofa> (though it'd be easier to just start with the user telling the plugin "give me this version of ruby"
[21:54] <kyrofa> )
[21:54] <bdx> yeah, ok
[21:57] <ssbash> nacc: still not working, I'm getting the same error
[21:58] <ssbash> could it be an issue with my setup.py file? where are python packages supposed to be installed by default
[21:58] <kyrofa> ssbash, have you tried just via pip? Ignoring snaps all together? Does it work then?
[21:58] <nacc> kyrofa: good enough
[21:59] <nacc> kyrofa: err, good idea! rather :)
[21:59] <ssbash> kyrofa: this package is a local. It's not on pip.
[22:00] <kyrofa> ssbash, I mean the typical: make a virtualenv, source it, pip install .
[22:00] <kyrofa> Or setup.py install if you prefer
[22:00] <niemeyer> cachio: Isn't it super trivial to setup systemd units to restart on crash? I think that's actually the default behavior isn't it?
[22:01] <ssbash> kyrofa: it works in my virtualenv.
[22:02] <kyrofa> ssbash, is your code public? Can I take a look?
[22:04] <ssbash> its not public, the best I can do is share the directory layout http://paste.ubuntu.com/24852053/
[22:05] <kyrofa> Yeah that doesn't help I'm afraid
[22:12] <ssbash> kyrofa: oh ok thank you for your input
[22:39] <cachio> niemeyer, it is not a systemd unit
[22:39] <cachio> it is a system v service
[22:40] <niemeyer> Okay, so maybe that's the fix? Making it one?
[22:43] <cachio> niemeyer, well, that should not be difficult but not sure for other distros
[22:44] <cachio> niemeyer, I'll give a try
[22:45] <niemeyer> cachio: Thanks! It might end up nicely as we won't have to worry about it anywhere else
[22:53] <cachio> niemeyer, It is a systemd service too, and it is configured to "no restart" :)
[22:53] <cachio> niemeyer, I'll change that
[22:54] <niemeyer> So all you need is an override file
[22:54] <cachio> niemeyer, yes
[22:55] <cachio> or replace Replace=no with Replace=always
[22:55] <elopio> bdx: hello! With kyrofa we made this to get started: https://github.com/travis-ci/travis.rb/pull/515/files
[22:55] <elopio> bdx: now we want to turn it into a plugin. Your help there would be awesome.
[23:06] <elopio> cjwatson: build.snapcraft.io should be able to find the snapcraft.yaml when it's in the root, right?
[23:06] <elopio> ah, nevermind. The problem is that it's not in the master branch.
[23:19] <cjwatson> elopio: Yeah I must finish the branch to at least allow a different default