#snappy 2016-01-01 <alfreako> hi channel. Does anyone know why the snappy tutorials only refer to ubuntu 15.04; i found a .tar.gz download for 15.10 but there's no info on how to use it - should I just extract to /? #snappy 2016-01-02 <anpok_> I have started using snappy <ogra_> yay <anpok_> on a banan pi board.. I want to use that one as nfs server <anpok_> so the interesting stuff was boring.. it just works <anpok_> i took a beta image from lemaker .. with 4.2 kernel.. so no graphics drivers <ogra_> hmm, i wonder how up to date the banana pi is wrt new image technology <ogra_> (the bootloader handling and setup of things has changed a lot since the last banana pi image i know) <anpok_> release: ubuntu-core/15.04/edge <ogra_> well, that only reflects the userspace <anpok_> ok .. not the device part <ogra_> right <anpok_> i was wondering if there is a way to switch release channels.. <ogra_> we keep the stuff backwards compatible so you could have a very old setup, depends on th3e person who does the device part <ogra_> and if he/she kept it up to date <anpok_> hm from september <ogra_> ah, that does sound decent <anpok_> i thought about buying another one for other purposes.. and getting the mali drivers to work <ogra_> yeah, we're still quite behind on any graphical stuff <anpok_> for nfs server I started to create snapcraft.yaml file that pulls in deb files for nfs.. and some libraries.. <anpok_> i am not pulling in a few libraries that i already found in the core image.. is that ok? <anpok_> or should everything apart from libc and pthreas be duplicated in the snap? <ogra_> the latter <ogra_> nobody can guarantee that any libs stay in the core image <anpok_> ok.. <anpok_> is there a syntax in snapcraft to move files around, that were pulled in from debs? <ogra_> anpok_, the copy plugin copies all contents of the stage packages <ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml here is a package that uses deb contents <enoch85> hi guys, I'm trying to get an rPi to run as a webserver with snappy, but I have a hard time finding out how to do it. On a regluar Ubuntu Server you just install Apache and MySQL with apt-get, but it doesn't seem to work on this one. Please help. <anpok_> ogra_: oh ircproxy was another thing i wanted to do <ogra_> anpok_, i plan to upload it during the holidays, it is easy to build yourself though, just bzr branch and run snapcraft in the toplevel dir <ogra_> it can be configured via "snappy config" (so it weill hook into the REST api later which will make it easy to intergrate it into UIs etc) <kyrofa> enoch85, you would need to bundle apache etc. in the .snap itself <enoch85> kyrofa, Kyle? <kyrofa> enoch85, indeed :) <enoch85> kyrofa, ok, hmm... I been struggling with this for a day now, and I still haven't figured out how to put the boot on the SD card and root on HDD, the filepath (setup) that Snappy offers, differs from all the guides I've tried <enoch85> kyrofa, hey btw! :) <kyrofa> enoch85, haha, hi! Okay, and this is to enable ownCloud, yes? <enoch85> kyrofa, sec, will send you a link <kyrofa> enoch85, so I've run this type of ownCloud setup for years, and I typically use the SD for the OS, but use the HDD for ownCloud's data <enoch85> kyrofa, this is my mission: https://owncloud.org/blog/update-about-the-western-digital-and-owncloud-pi-project/ <enoch85> kyrofa, aah ok, but what about the mysql and apache config? <enoch85> kyrofa, I read that small writes to the SD card is bad practice <ogra_> enoch85, dont put the OS on the SSD ... instead format the SSD as ext4, label it "writable", remove the "writable" label from the old writable partitions and copy the content to the SSD ... then reboot <ogra_> s/partitions/partition/ <kyrofa> ogra_, we're talking about the SD card in the rpi2 <ogra_> yeah <ogra_> leave the readonly parts there <ogra_> and move the writable partition to the ssd <kyrofa> ogra_, ah, interesting idea <ogra_> by simply moving the label and data over <ogra_> we mount the partitions by label ... so thats pretty easy <kyrofa> enoch85, that ^^ would make the SD lifetime quite a bit longer <ogra_> what is important is that you copy the data ... there is some cloud-init metata data thats required to configure the user on boot .... you wont get in without that in place <enoch85> ogra_, thanks! kyrofa that's what I thought <ogra_> *meta <enoch85> ogra_, all this is new to me, so I would really appriciate a guide of some kind, or at least the commands of doing this <ogra_> note though that USB2.0 is limited to 24MB/s ... the disk throughput wont be stellar <enoch85> ogra_, yeah, I know, but this is what I have to work with <ogra_> yep <kyrofa> enoch85, you might want to start walking before you run though-- perhaps focus on getting owncloud working before optimizing? <kyrofa> enoch85, since you're investigating apache and mysql, I'm assuming you're looking to make an owncloud .snap sans Docker, correct? <enoch85> kyrofa, I'm one of the maintainers of the ownCloud VM, and I have provided a VM from my site (www.techandme.se) since 2014, so I'm familiar with Ubuntu Server since before. A couple of days ago I got an email from Frank that asked me if I thought it was a good idea to make the rPi appliance (with) snappy. I thought he meant that the appliance should *be* snappy, so I said yes - and now I'm here trying to figure out how to get Ubuntu <enoch85> Snappy to run well as a webserver with ownCloud on Apache and MySQL and all the other needed dependencies. :) <enoch85> kyrofa, then if that means running a Docker container, then yes. <kyrofa> enoch85, yeah, Snappy/Ubuntu Core is a bit different than good-old Ubuntu Server. So normally you'd expect to simply install the apache, mysql, and php packages, extract the owncloud tarball, and start running (more or less), right? * ogra_ always thinks the snappy app confinement is enough to shield apps ... no need for extra container overhead imho ... <ogra_> especially since it eats you alive on a rPi <kyrofa> Yeah, not something I'd recommend either, but that's the only ownCloud .snap that exists right now <ogra_> yeah <kyrofa> enoch85, .snaps differ from .debs in a number of ways, but a big one is that .snaps must include their dependencies <kyrofa> enoch85, which means making an ownCloud .snap "the right way" would be putting apache/php/mysql etc. in a .snap with ownCloud configured as well * ogra_ likes to see snaps as project packages ... the focus isnt so much on the actual software itself but more on the feature and functionality a snap provides <kyrofa> Indeed. enoch85 think of .snaps as deployment solutions for a product <kyrofa> enoch85, which is why it's such a good fit for this project. When a new version of ownCloud is released, or you find a bug in the config, you can release a new .snap with the problem fixed, and then the whole thing can be updated transactionally <kyrofa> enoch85, if you've got Ubuntu Core running on the rpi2, I suggest you begin looking at Snapcraft for putting the pieces together <kyrofa> enoch85, I'd be happy to do this with you on Monday too, if you like (I only have a few minutes today, I'm afraid) <ogra_> if you look at my upnp-server package in the store you can see that it ships lightttpd and minidlna in a bundle, each of them set up pre-configured for a single purpose ... in a future revision i could just replace lighttpd with apache without the user noticing (given i dont mess up the config indeed) <kyrofa> ogra_, great example, thank you <kyrofa> enoch85, perhaps eventually you decide apache2 sucks. Replace with nginx and release an update. End users don't see a difference <enoch85> kyrofa, ogra_ so basically, what I would need to do is create a .snap with all the stuff pre-configured? and then just install it as a .snap in the root system of Snappy (that I moved to HDD) <ogra_> well, pre-configured is up to you indeed :) <kyrofa> enoch85, yeah you got it <ogra_> for the upnp-server case above i was following a very specific purpose ... i want a webdav share onn port 80 ... and every media file i drop in there should be served by upnp/dlna to my network ... <kyrofa> enoch85, so the challenge is coming up with an initial .snap. Fortunately, if you use Snapcraft you can use the .deb packages you're used to for apache and mysql etc. <ogra_> so in that case you want some pre-config and a snappy config hook to adjust only related settings <enoch85> kyrofa, ogra_ I'm not convinced yet. ;) I'm thinking of all the extra work that needs to be done rather than just using my old config scripts. And about the update, that is handled automatically today in my config via a cronjob that executes a script and make the necessary configurations: https://github.com/enoch85/ownCloud-VM/blob/master/production/owncloud_update.sh <ogra_> why a cron script ? <enoch85> kyrofa, ogra_ but I will sureley give it a try! you're kind to help! <ogra_> isnt config migration something you only want to run on upgrades ? <kyrofa> ogra_, to obtain owncloud releases periodically, I would assume <ogra_> ah <kyrofa> ogra_, yeah `php /var/www/owncloud/occ upgrade` <kyrofa> enoch85, indeed, I understand your hesitation <kyrofa> enoch85, consider this: what happens if this script fails? <ogra_> that might need some special handling indeed ... since you would likely want snappy to actually handle the upgrades <ogra_> to have the rollback feature and keep the download small due to using package diffs etc <enoch85> ogra_, as the commands aren't the same on snappy as on ubuntu server then my old scripts would fail. And if I understand you correctly I would have to rebuild the .snap everytime I wouold want to update or make changes to the owncloud config. Then my questions is, who would maintain that? :) <ogra_> why would you update the package for config changes ? <ogra_> dont you want the user to do the config ? <ogra_> (and keep/migrate it appropriately on SW upgrades) <kyrofa> ogra_, I think the vision is to have a product that can just be used, is that right enoch85 ? <enoch85> kyrofa, ogra_ I agree that the scripts isn't totally failsafe, but during the 2 years I've used it I never run into any issues <enoch85> kyrofa, yes <ogra_> kyrofa, sure, i just dont understand the concerns about the config <enoch85> kyrofa, that's right, my mission is to make a rPi image than will be shipped on the first 500 devices that WD will ship with ownCloud on <enoch85> ogra_, maybe it's me that doesn't get how it really works, in my mind it seems comlicated <enoch85> kyrofa, the target audience is noob users <ogra_> your config lives in the writable space like in every other install <kyrofa> enoch85, plug in and go, my favorite <enoch85> kyrofa, that's why everything has to work out of the box, and continue to work for years after that <kyrofa> enoch85, gotcha <enoch85> kyrofa, haha ;) <ogra_> if you upgrade there will be a backup of the old config and the migrated one ... <enoch85> kyrofa, mine too <enoch85> ogra_, <enoch85> ogra_, ooh, sounds nice! <ogra_> if you find you cant use the new config you can roll back to the last version of the app <kyrofa> enoch85, that's what I was talking about regarding the failure ^^ <ogra_> (same fgoes for the OS itself, you can always go back to the last stable state ) <kyrofa> enoch85, your database was backed up, etc <enoch85> ogra_, kyrofa like I said, I want to do this and I really appriciate your help! :) I'm just new to all this .snap thingy so that's why I sound uncertan <ogra_> anyway, there is definitely no need for you to re-roll the package unless there is a new version you want to release <ogra_> surely not needed for config changes ... <kyrofa> enoch85, you're in good company :) . And if you decide this isn't a good fit, we understand! Any chance you have some time on Monday to work on this together? <enoch85> kyrofa, ogra_ so basically, .snap is like a "container" aka "app" that one would have to maintain, and make all the changes inside the .snap app..? to be clear, that includes updates to apache as well as apt-get isn't existing? <ogra_> yes <kyrofa> enoch85, correct <enoch85> kyrofa, sec, will check my schedule * ogra_ gets evil looks from the GF on the sofa ... i guess i'll have to switch back to vacation mode ;) <enoch85> kyrofa, working on monday, but are free on tuesday and wednesday :) <enoch85> ogra_, haha :D <enoch85> ogra_, this is what I do on my free time <kyrofa> enoch85, Tuesday works! <enoch85> cool, I'll be online <enoch85> kyrofa, btw, any time difference? <enoch85> kyrofa, i'm in Sweden <kyrofa> enoch85, I'm on EST-- you? <kyrofa> Ha! Yes then :P <enoch85> Time is 19:58 atm <enoch85> kyrofa, 12 at your place? <kyrofa> enoch85, 13:58 here <enoch85> kyrofa, ok, well, when I'm off I tend to sleep for a while :) <enoch85> kyrofa, I will be prepared with a clean install of Ubuntu Snappy, and a freshly made partition of the WD HDD. :) <kyrofa> enoch85, I'm here steady from 0800-1600, just ping me? <enoch85> kyrofa, yes, I'll ping you :) <kyrofa> enoch85, excellent :) . I look forward to it! <kyrofa> enoch85, alright I gotta run <enoch85> kyrofa, ogra_ thanks for your help! talk to you on tuesday then. looking forward to get this baby up and running. :) #snappy 2016-01-03 <T3SLA> Hi <T3SLA> I am trying to install snappy on rpi 2 <T3SLA> can any1 help me with that <T3SLA> I am new to ubuntu so pls help me #snappy 2016-01-04 <dholbach> good morning <fgimenez> good morning <anpok> I continued toying around with a nfs server snap... now there is a library opening a config file in /etc/.. libtripc within rpcbind. The path is a compile time literal. Whats the right way to solve that? Is snappy doing something on startup to remap paths for each app? Should I change that to a relative path.. or use an env var? <asac> happy new year! <dholbach> asac: and the same to you! * asac hugs dholbach * dholbach hugs asac <JamesTait> Good morning all; happy Monday, happy New Year, and happy World Braille Day! ð <anpok> snappy new year! <asac> ubuntu@localhost:~$ snappy enable-classic <asac> 147.41 KB / 73.75 MB [______________________________________________________________________________] 0.20 % 367.10 KB/s 3m25s <asac> 73.75 MB / 73.75 MB [====================================================================================] 100.00 % 1.12 MB/s <asac> failed to create classic mode dir: mkdir /writable/classic: permission denied <asac> mvo: ? <asac> $ snappy list <asac> Name Date Version Developer <asac> canonical-linux-raspi2 2015-12-17 4.2.0-1014-3 canonical <asac> ubuntu-core-armhf (930)970-5854.04.0-4 canonical <asac> canonical-pi2 2015-12-17 2.2 canonical <asac> dont see an apparmor error for that... so guess just missing directory? * asac mkdir /wrtable/classic and then retries <asac> mvo: oh i think its bnecause i didnt use sudo * asac retries another time <asac> bah lp timeout when filing this as a bug :(\ <mvo> asac: yeah, sudo - but that is a bug in itself that it tries to do that even without uid=0 <asac> mvo: nexty problem ist hat i cant apt-get install in classic\ <asac> tried to snappy classic shell with sudo, but didnt work <asac> also when running snaoppy shell classic i end up with ubuntu user in the container <asac> mvo: https://bugs.launchpad.net/snappy/+bug/1530826 <ubottu> Launchpad bug 1530826 in Snappy "enable-classic should fail fast if not run with sudo/as root" [Undecided,New] <asac> bug one <asac> mvo: bug two: https://bugs.launchpad.net/snappy/+bug/1530827 <ubottu> Launchpad bug 1530827 in Snappy "cannot apt-get install in snappy shell classic" [Undecided,New] <mvo> asac: that seems to be something new in xenail I will debug <mvo> asac: releated to the new apt sandbox stuff <asac> mvo: what is apt sandbox <asac> ? <ogra_> asac, apt has its own user now <ogra_> (broke the images for a week :P ) <ogra_> so it drops privs (abd does other stuff to operate more securely) <ogra_> *and <mvo> asac: yeah, what ogra_ says. the idea is that if e..g there is a buffer overflow in the http downloader then the attacker does not get root right away <mvo> asac: on fixing the issues now (but may get interrupted by a lunch break soon :) <ogra_> mvo, are you actually working already again ? <asac> mvo: so we got debian crack that broke everywhere? nice :P <ogra_> it only broke snappy and touch due to the added user :) <mvo> ogra_: I think so, I need to check the calendar but I think I do :) <anpok> hm i guess there is no policy called network-servr <anpok> *server <mvo> ogra_: may take a day off during the week <mvo> asac: *cough* yeah <ogra_> mvo, heh ... i'm still off til 16th ... but wanted to poke you with that pending u-d-f merge .... and snappy FTBFS on arm64 in xenial since a few weeks now <ogra_> would be good if someone could handle that <mvo> ogra_: 16! woah :) <ogra_> well, i had to burn vac. days and decided to actually burn some in advance this year :) <mvo> ogra_: u-d-f> I have a look, I think I need to spend some time on that one :/ <ogra_> oh, why is that ? <mvo> ogra_: just because noone else is and the all-snap branch needs integration in there too <ogra_> it applies, builds an runs fine for me <mvo> ogra_: oh, sorry, not specific to your diff, thats just a tiny part of it :) <ogra_> i dont think it should be affected by all-snaps ... at least not beyond some preipherial bits <mvo> ogra_: thats good <mvo> ogra_: arm64> is it just a test failure? if you don't know from the top of your head don't worry, I check it out <ogra_> i dont know, i just see the image build failure since a while, i didnt check the snappy build itself * ogra_ sighs ...snow ... i thought i'd get away without shoveling this year <mvo> asac: sorry for the apt trouble, I looked at this and you need to run "sudo apt update", this is a bug in apt that it does not tell you this. plus you probably can't use sudo in classic right now because the fix https://github.com/ubuntu-core/snappy/pull/266 is not merged yet :/ <pindonga> sergiusens, mvo jdstrand_ hi there... if I need to add a dependency to snapcraft for a feature I'm proposing, I also need to package that dependency as an ubuntu package right? <pindonga> but that would also mean having to introduce a PPA until the pkg is available in the main repos <pindonga> maybe there's a better alternative? <sergiusens> pindonga, you only want to target xenial for snapcraft 2.0 (if the question is about that) <sergiusens> pindonga, landing in xenial is pretty fast <pindonga> sergiusens, so the answer would be 1) yes, package deps for ubuntu (xenial), 2) yes, use main repos <pindonga> right? <sergiusens> pindonga, yeah, I was also suggesting no need to think about backporting <pindonga> ack <asac> mvo: no worries.... thanks! let me try <asac> so yeah, no sudo in classic (e.g. lack of sudoers) <ogra_> ppisati, http://paste.ubuntu.com/14399210/ ... worjking dragonboard config with your branch ... it isnt merged with the std ubuntu one yet so a bit messy, but it makes all HW work fine <ogra_> ppisati, it uses the apq8016-sbc.dtb DT <mvo> asac: yeah, this is fixed in the branch above, once that branch is merged it will be fine <asac> cool... waiting then <kyrofa> Good morning <kyrofa> Chipaca, so `snappy remove` doesn't remove any of the snap's data? <ppisati> ogra_: i've seen your email from december <ppisati> ogra_: the kernel with your config changes is building ATM <ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+build/8800172 <ogra_> ppisati, yeah, but i re-did a lot of that stuff since <ogra_> cool ! <ppisati> ogra_: ah <ppisati> ogra_: did you change anything in the config? <ogra_> initially i was using the wrong DT ... <ogra_> a lot, yeah <ppisati> ogra_: oh ok, then i'll do anothe config diff and repush <ogra_> effectively i went back to the 96boards one plus systemd and apparmor options <ppisati> ogra_: anyhow, i couldn't test this kernel <ogra_> i.e. you will have to go over it and somehow merge it with the normal ubuntu config (not all USB modules, etc etc ... ) <ppisati> ogra_: cause i've a problem with your img <ogra_> oh ? <ppisati> ogra_: it's weird, but after the first boot <ppisati> ogra_: my board refuses to boot subsequently from sd <ogra_> you made sure it is a 4G card ? <ppisati> ogra_: 8G <ogra_> ! <ogra_> there is a reaadme next to the image :P <ogra_> resizing is still broken, it wipes your GPT <ppisati> ogra_: fuck <ogra_> you need a 4G card <ppisati> i haven't see that <ppisati> that explain it <ppisati> ok <ogra_> yeah * ppisati search for a 4G card then <ogra_> i might fix the resizing during my vacation :) * ogra_ is still officially off til 16th <ppisati> ogra_: no prob, i'll play with your img and my kernel <ppisati> ogra_: till it works fine <ogra_> well, the current cnfig should work fine but surely has glitches (iirc it has preempt turned on and stuff) <ppisati> ogra_: the kernel compiling there, it's the same from december + the config diff you posted back then <ogra_> i also havrnt looked at the firewall options, i think most are missing as well <ppisati> ogra_: i'll make sure eveyrhing is fine <ogra_> yeah, i just used your source package ;) <ppisati> at least now i know why the img had that weird behaviour <ogra_> yeah <ogra_> note that you have to replace the wrongly named DTB when you change the kernel on it <ogra_> uboot still points to the wrong name <ogra_> (<ou need to copy apq8016-sbc.dtb over it) <ppisati> ok <ogra_> oh, and with that kernel there is a bug with console blanking(havent checked if the 96boards kernel has it too) ... it doesnt wake up on keystroke <ogra_> in case you plan to use the tty console :) <ppisati> ogra_: i even tried to install uboot on the boot partion on the internal flash <ppisati> ogra_: but i couldnt make the board boot in that case <sergiusens> kyrofa, morning <ppisati> lets' see if i can figure that out too <kyrofa> Hey sergiusens! <kyrofa> Good vacation? <sergiusens> kyrofa, you can tell from my absence here :-) <ogra_> ppisati, well, you need to turn it into a boot.img first if you use the internal flash i think <kyrofa> sergiusens, haha :) <sergiusens> it was pretty good, really humid and rainy though, flooded cities everywhere <kyrofa> Ugh <kyrofa> Everyone save though? <ppisati> ogra_: i did that, my problem was that i couldn't boot the board <kyrofa> s/save/safe/ <asac> mvo: can i hack my classic stuff so that ubuntu is in sudoers maybe? <asac> would really love to unblock what i am really after: "get an armhf build env" <ppisati> ogra_: it was like, after kernel / dtb load and decompression, the board hung there <ogra_> ppisati, like ... not at all ? i.e. not even messages from the SPL on the serial console ? <ppisati> ogra_: zero <sergiusens> kyrofa, mostly evacuated and the losses are only monetary; but it hasn't been without losses <ogra_> ppisati, well, you should at least get the SBL messages, else you messed something up ... <ppisati> ogra_: i was following this, i guess you saw that too <ppisati> ogra_: http://rglinuxtech.com/?p=1606 <ppisati> ogra_: sorry <ppisati> ogra_: still sleepy :P <sergiusens> kyrofa, how was your time off? <kyrofa> sergiusens, I'm sorry :( <ppisati> ogra_: yes, i got a "complete boot" up to the point of loading kernel / dtb <ogra_> ah <ppisati> ogra_: so uboot was live and 'working' <ogra_> that was with your kernel back then ? <ppisati> ogra_: right, but even with the config change you pasted back then <ogra_> oh <kyrofa> sergiusens, mine was nice, but a little tough-- my wife has been having some pretty good contractions and we're still over a month out. She's been more or less on bed rest <ogra_> but you used the right dtb :) <ppisati> ogra_: right <ppisati> ogra_: apq- <ogra_> my first config change only worked withteh wrong one <ppisati> ogra_: that might explain it <ogra_> the pasteed config above now works with the right one :) <sergiusens> kyrofa, yeah, that can be tough <ppisati> ogra_: cool, i'll do config diff, recompile and reboot tests <sergiusens> kyrofa, I get you guys are getting pretty anxious due to that <kyrofa> sergiusens, yeah it's a bit stressful <ppisati> ogra_: it'll be ready for when you are back <ogra_> :D <mvo> asac: yes, just do "sudo vi /writable/classic/etc/group" and add "ubuntu" to the "sudo" group <mvo> asac: and bribe someone to review my branch that fixes the issue :P <asac> mvo: i need your branch on top? <mvo> asac: just that, then you should be fine <mvo> asac: the branch will do it automatically <sergiusens> kyrofa, elopio should we do a quick standup? <elopio> Hello everybody. <elopio> it's good to be back. <kyrofa> sergiusens, yeah <elopio> sergiusens: yes. <sergiusens> elopio, trading a natural jungle with a software one :-) <sergiusens> elopio, kyrofa I'm in <kyrofa> asac, how are those snapcraft PRs coming? I'd be happy to push them the rest of the way if you like <kyrofa> sergiusens, the ld.so.conf.d idea is really elegant. I'm wondering if we should perhaps do that throughout snapcraft rather than just the catkin plugin. Thoughts? <kyrofa> sergiusens, might save some pain for devs <kyrofa> elopio, ^^ <sergiusens> kyrofa, +1 on that <kyrofa> sergiusens, excellent :) <asac> kyrofa: could be that we can abandon them... let me try something <kyrofa> asac, alright let me know <asac> and hny! <asac> sergiusens: heya! can we ahve a default target back to be snap? <asac> on master <asac> utlemming: do you have xenial snappy all-snaps builds set up for aws, gcloud etc. yet? <asac> that would make my month :) <sergiusens> asac, we can, yes; I just need to make it clear in the spec. <asac> cool <asac> i think that would feel more natural than bailing out <asac> kyrofa: https://github.com/asac/etherpad-lite-snap/commit/e68ad2fd5ab2d75034c5fc32466c32eb380a0417 <kyrofa> asac, happy new year to you as well! <asac> that seems to work; entirely due to my lack of node knowledge <asac> i have to dobule check but for now assume its an abandon <kyrofa> asac, ah, interesting. And yeah, I can't help you on the node knowledge-- maybe sergiusens can? I think he made the plugin <asac> i think its fine as above <asac> and i wont need a new feature for node plugin this way <asac> just have to test the runtime package :) <kyrofa> asac, I'll go ahead and close them, then-- you can always reopen if you still want it :) <asac> will do thanks! <asac> if anyone wants to install http://people.canonical.com/~asac/etherpad-lite_master_amd64.snap and see if the pad is working on 9001 port after <asac> that would be cool <sergiusens> kyrofa, I am not a node expert, only looked at it for one day and came up with a simple hand written app and an existing popular one :-) <asac> i only have my new "production" etherpad snappy instance <sergiusens> asac, if you need node help, beowulf is the guy we want to talk to <kyrofa> sergiusens, heh <sergiusens> asac, is that snap built with snapcraft? <asac> sergiusens: of course <sergiusens> asac, nice! <asac> with the branch above <asac> https://github.com/asac/etherpad-lite-snap/ * beowulf looks to see what kind of bus sergiusens has thrown him under <asac> is legacy already though, because the real variant moved it into real tree <asac> https://github.com/asac/etherpad-lite <asac> e.g. in tree snapcraft <asac> vs. out of tree snapcraft which is the -snap repo above <asac> will hack on awesome config support today <kyrofa> Haha, hey beowulf <asac> https://github.com/asac/etherpad-lite/tree/snap-support/bin/snappy <asac> thats the in-tree snapcraft <beowulf> o/ kyrofa <kyrofa> beowulf, it's been a while! What are you working on nowadays? <asac> would love to consolidate the README to just have "snapcraft" for both 1.x and 2.x <beowulf> kyrofa: i'd like to say i work on the store, but it's more like the store works on me <kyrofa> beowulf, :D <elopio> ping plars. Are you working today? <plars> elopio: yes, Happy New Year :) <plars> elopio: what's up? <elopio> plars: same to you! <elopio> plars: we are wondering about making an ubuntu-device-flash specific for 16.04. That would mean that you need xenial to build new images, and an older distro to generate 15.04 images. <elopio> plars: could you get two agents working, one for new and one for old images? <plars> elopio: no, it's not really possible to have two different agents coordinating the same device <plars> elopio: it may be possible to somehow give a hint to how it's built, but it couldn't be on two different agents. Wouldn't it be possible to just have two different ubuntu-device-flash binaries? Why does the whole distro it's built on need to be different? <elopio> plars: well, there are many options, I just thought two builders was the easiest. The u-d-f from xenial will build 16.04, the u-d-f from the other distros will build 15.04. If you can install both on the same agent, and tell me how to choose, I think that works too. <plars> elopio: so it's just a different binary then, the whole distro you are building the image on does not need to be updated correct? <plars> a different udf binary that is <elopio> plars: afaik, yes. sergiusens: right? <plars> elopio: do you know if there's any plan to add backward compatibility support? <elopio> plars: that's what we want to avoid. <plars> elopio: There are a few different approaches we could take, either way you'll definitely want to set up a new "image" in spi (since it is a new image) <plars> elopio: for that image, you'll need to tell it to use the new udf binary to build the image, not the default one <elopio> plars: sure. So what remains is to see if we can have both installed in the same machine. <sergiusens> elopio, I don't know, that is a mvo question, but I am thinking that there is a dependency on using 16.04 for the new stuff <plars> elopio: this will require some rethinking of how the agents work too I'm afraid... we never anticipated needing multiple versions of UDF, rather it was assumed that we want to carefully control the version of udf installed and make sure it's updated only when needed <plars> elopio: so as a result, you specify the options to udf, rather than a script to just go get whatever version of udf you want (like you do with the tests) and run it <plars> sergiusens: dependency on using 16.04? or a dependency on using 16.04 version of udf? And can that version also build 15.04 based images? <elopio> plars: worst case scenario, we'll want the agents to be xenial. And fgimenez and I can run the 15.04 tests manually on our homemade labs :p <noise][> elopio: wasn't there some talk about u-d-f becoming ubuntu-image + ubuntu-flash as 2 new separate binaries for 16.04? <plars> elopio: it may not be so simple... what about others that may want to test 15.04 images? <elopio> noise][: yup. We are planning the transition for that. <plars> elopio: hopefully there's some transition path for all of this? Otherwise everything will just be broken for a while <plars> elopio: of course, for bbb, I think we're still down because of that bug right? <noise][> if that were the case, couldn't the existing 15.04 compat. u-d-f still be packaged for xenial alongside the 16.04 split ones? <sergiusens> noise][, u-d-f can still be there in xenial; but the new ubuntu-image will only build with all snaps in mind <elopio> noise][: maybe. So far I'm just asking the questions to see what are the requirements for the transition. <elopio> I'm ok with a little downtime, if that speeds up the transition to all-snaps. <elopio> Also we want to avoid having u-d-f generating 15.04 and 16.04 images. <anpok> Jan 4 16:33:03 localhost systemd[1]: Cannot add dependency job for unit ubuntu-snappy.snapd.socket, ignoring: Unit ubuntu-snappy.snapd.socket failed to load: No such file or directory. <anpok> ^ something I should care about? <plars> elopio: so it's a whole new command - ubuntu-image, that will be used? <plars> elopio: is there any documentation about this? <elopio> plars: that's the final solution, yes. While that command is ready, we need to support building new images. <plars> elopio: it would be a little weird to run these agent hosts on xenial I think, is there no plan to build a trusty version of the new ubuntu-image binary? <plars> elopio: it's still not clear to me if the build host *must* run xenial, or if it just needs the new binary <elopio> plars: we want to avoid that. We want to have people writing things for xenial to be using xenial. <plars> elopio: but we're not developing anything on that system, just building an image <plars> elopio: In either case, I think we'll need to extend the json you pass for spi to support a new field for using ubuntu-image vs. udf <elopio> plars: again, right now I'm just asking for requirements. If we can completely ignore trusty, that would be easier for sure. <plars> elopio: then once all 15.04 images are deprecated, we can just kill the previous stuff <plars> elopio: I think in the near future though, we have to support both <kyrofa> Chipaca, ping <kyrofa> Chipaca, I'm having trouble merging my understanding of snappy with my understanding of this purge code :P <kyrofa> Chipaca, specifically, if DataDirs returns multiple results, Purge seems to try and deactivate the snap more than once, resulting in an error after the first deactivation since it was already deactivated <kyrofa> Chipaca, I thought that was a common scenario? <kyrofa> Chipaca, trying to fix https://github.com/ubuntu-core/snappy/pull/264 by the way <kyrofa> sergiusens, any chance you know what I'm talking about? <Chipaca> kyrofa: sorry, hadn't brought irc up yet. am here now. <Chipaca> reading backlog <kyrofa> Chipaca, ah, no problem :) <Chipaca> kyrofa: so, correct, `snappy remove` leaves data in place <kyrofa> Chipaca, makes sense given how apt-get works <kyrofa> Chipaca, or dpkg I guess <Chipaca> kyrofa: yeap, which is why it's this way, but it is surprising if you don't come from apt, so it'll change for 16.04 to be less so <Chipaca> kyrofa: oh dear, you are correct in that the use of datadirs is buggy :-( <Chipaca> hmm <kyrofa> Chipaca, oh *whew* that's better than me being incredibly confused :P <Chipaca> :-) <Chipaca> well, users might disagree with you on that =) <kyrofa> Hahaha <kyrofa> Chipaca, well I've got fixed (i.e. failing) tests anyway <Chipaca> hmm <kyrofa> Chipaca, I can make a PR to fix it before fixing #264 <Chipaca> on the other hand, maybe not <Chipaca> ah! yes because it'll do deactivate in the second path <Chipaca> bah humbug :-( <Chipaca> kyrofa: +1 <Chipaca> kyrofa: things current code doesn't consider is a snap using both data dir and user data dir, and multiple users <Chipaca> kyrofa: both would fail in similar ways <kyrofa> Chipaca, ah, indeed <Chipaca> kyrofa: in both cases moving deactivate to inside the first loop would solve it i think? <kyrofa> Chipaca, what was the purpose of looping through the data dirs in the first place? Is there a use-case I'm missing? <Chipaca> kyrofa: as opposed to what? <kyrofa> Chipaca, ah, it was for multiple VERSIONS <kyrofa> Chipaca, yes? <Chipaca> ah, yes <kyrofa> Chipaca, okay, I'll point you to the PR when I make it, if that's alright <Chipaca> kyrofa: that would be very alright <Chipaca> kyrofa: going back on this a bit, depending on the size of the change, maybe moving it to pkg/lightweight is better <kyrofa> Chipaca, ah, I've never looked at that package <Chipaca> kyrofa: they're both my fault, but datadirs is rather adhoc for the purge command, whereas lightweights is an iteration of the idea made more generally useful (only i didn't get around to removing datadirs) <kyrofa> Chipaca, I don't think the change is large, but it sounds like a refactor that should happen at least eventually. Would you like me to do that here? <Chipaca> kyrofa: as the whole purge command is going away, probably not worth it unless fixing datadirs is big <kyrofa> Chipaca, I think not. But I'll keep it in mind just in case * Chipaca nods <kyrofa> Chipaca, https://github.com/ubuntu-core/snappy/pull/283 <sergiusens> kyrofa, so should we do a 1.x today? <kyrofa> sergiusens, we can, but this ld.so.conf.d feature will need to get into 1.x as well. I'm fine with waiting on it or releasing twice-- up to you <kyrofa> sergiusens, but I know we've been wanting to get that out <sergiusens> kyrofa, depends on how long it will take, I don't want to delay too much ;-) <sergiusens> kyrofa, also, do the docs need more work or can they merge? <kyrofa> sergiusens, agreed. How about we wait until tomorrow. If it's not done and looking good, we'll release <kyrofa> sergiusens, ah, let me look them over again now <sergiusens> kyrofa, yeah, releasing on wednesday is fine by me <sergiusens> kyrofa, it would be nice to get the qml fix backported too <kyrofa> sergiusens, agreed. I didn't see a response on that, so I can cherry pick <sergiusens> kyrofa, is it CLA worthy? A single cherry requires squashing though iirc <kyrofa> sergiusens, the qml fix guy did sign the CLA <sergiusens> great <brei> is it possible to define an unpack path for the tar_content.py plugin? <kyrofa> sergiusens, the ld.so.conf idea may not actually work. At least from what I've seen so far, those files are placed in the .deb postinst, which doesn't seem to have an effect since we're really only unpacking them <sergiusens> kyrofa, oh bummer <kyrofa> sergiusens, yeah it's sad... it was such a good idea <sergiusens> kyrofa, I can't think of another way that can reliably work for all cases <kyrofa> sergiusens, I want all that stuff to be done in some sort of temporary lxc so the packages can actually be installed or something <sergiusens> kyrofa, we should only focus on lxc for 2.x <sergiusens> kyrofa, I'd say, send some sort of proposal to the devel list to see what comes <kyrofa> sergiusens, alright... I guess I'll scrap this idea for 1.x then, unless you think walking /lib and /usr/lib and adding them all to LD_LIBRARY_PATH is an acceptable backup plan <sergiusens> kyrofa, what about things in /opt' and such? <sergiusens> it sort of gets some things working, but not all <kyrofa> sergiusens, yeah, it doesn't work in all cases, but it works better than what we have now <kyrofa> Exactly :P <sergiusens> kyrofa, can we use rpath with relative paths? <sergiusens> probably not a good solution either <kyrofa> sergiusens, I think you can with some special keywords, but it's been a long time since I played with that <kyrofa> sergiusens, yeah... I'm not a huge fan of either. Do we like one better than the other, or stick the .snap author with making wrappers every time they have a lib outside of the standard? <sergiusens> kyrofa, the general consensus was that most of this is a project specific problem <kyrofa> sergiusens, which makes a certain amount of sense, but also can mean a nightmare for someone just trying to package something with a lot of .deb dependencies <sergiusens> kyrofa, personally, snapcraft magic voodoo should only be done when there's something we can hold on to <kyrofa> sergiusens, yeah, you're right <sergiusens> kyrofa, there's nothing reliable we can use here <sergiusens> too bad those ld things are postinst :-( <sergiusens> I thought they'd be config files at most <kyrofa> sergiusens, agreed. Let's scrap the idea and revisit if we ever get some sort of contained build <kyrofa> sergiusens, they are, but they're symlinked in <sergiusens> kyrofa, is there any specific path that is already blocking something? <kyrofa> sergiusens, I ran into it making a ROS .snap that uses opencv, which relies on opengl, which is in /usr/lib/arch/mesa <sergiusens> kyrofa, for the case of mesa/egl/gl, right? <kyrofa> sergiusens, right <sergiusens> kyrofa, those are sufficiently common I guess to be able to track and check for <kyrofa> sergiusens, I can at the very least add it to the catkin env(). Want me to add them to the overall runtime_env()? <sergiusens> kyrofa, overall is fine <sergiusens> kyrofa, I wonder if this is a pattern ''/etc/alternatives/.*_conf <sergiusens> something we can check for <kyrofa> sergiusens, in the case I'm looking at, the real .conf is distributed within /usr/lib/arch/mesa, and the postinst installs it with update-alternatives <kyrofa> So yes.... but no <kyrofa> Because in that case, even the etc/alternatives is a symlink <sergiusens> kyrofa, ah/usr/lib/x86_64-linux-gnu/mesa-egl/ld.so.conf <kyrofa> sergiusens, right <kyrofa> Stupid chicken and egg problems... <sergiusens> kyrofa, the other option is to search for ld.so.conf files <sergiusens> but that can be dangerous too <kyrofa> sergiusens, I assume that name is nonstandard <sergiusens> kyrofa, exactly <sergiusens> kyrofa, so maybe search for those specific egl ones and read them through <sergiusens> kyrofa, we'll need to figure out what nvidia does as well <sergiusens> gl is sort of an important topic <sergiusens> ah, nvidia is mostly a runtime thing, disregard me <kyrofa> sergiusens, alright, I can do that <sergiusens> kyrofa, elopio is this just me with a new pep? http://paste.ubuntu.com/14404846/ <sergiusens> easy fix, just want to know how it got through :-) #snappy 2016-01-05 <fgimenez> good morning <JamesTait> Good morning all; happy Tuesday, and happy Golden Gate Bridge Day! ð <Chipaca> stevebiscuit: mo'in! <Chipaca> stevebiscuit: a question that suddenly came to me <Chipaca> stevebiscuit: why is webdm fetching the icon? <Chipaca> stevebiscuit: (as opposed to giving the url to the browser and letting it figure it out) <stevebiscuit> Chipaca: hello! <LefterisJP> hello <stevebiscuit> Chipaca: the browser could handle things for uninstalled packages as the icon path would be something on the store <LefterisJP> When using snappy-remote, to upload a testing snap to a snappy target is it supposed to give some form of progress bar? I would like to determine if my process is stuck or if it's actually doing something <stevebiscuit> Chipaca: for installed packages, the path would be something like "/1.0/icons/myapp.myorigin/icon" which would be unaccessible <Chipaca> hurr durr <Chipaca> stevebiscuit: sorry i even asked :-) <stevebiscuit> Chipaca: not to worry, I had to double check! <LefterisJP> Hey all got a question. I am trying to deploy some test snapps from the snapcraft examples. The host is an Ubuntu 14.04 LTS and the snappy target is a Raspberry PI. <LefterisJP> When I do snapcraft the resulting .snap file has amd64 in its name and when I try to deploy with snap-remote I get this error: <LefterisJP> /tmp/webcam-webui_1_amd64.snap failed to install: package's supported architectures (amd64) is incompatible with this system (armhf) <LefterisJP> <LefterisJP> How can I generate a .snap file for specific architecture? <LefterisJP> hmmm is anyone seeing my messages/questions or is there a problem with my IRC client :-) ? <Chipaca> LefterisJP: wait a bit for sergiusens or kyrofa to be around, i think <Chipaca> stevebiscuit: how much do we care about somebody calling their icon something utf8-ish? <kyrofa> Good morning <stevebiscuit> Chipaca: good question, when a snap is built will it allow a utf8 filename? <Chipaca> stevebiscuit: let's assume no, at least for now <kyrofa> LefterisJP, I believe snapcraft needs to be run on the target arch <stevebiscuit> Chipaca: grand, I'm happy to abdicate the responsibilty :) <Chipaca> stevebiscuit: especially because what we do know is incorrect for utf8 filenames only on firefox <Chipaca> which does blow my mind a little bit <Chipaca> and not in a good way <Chipaca> although that's 2013 info; might need updating <LefterisJP> kyrofa: thanks for the reply. So I would have to install snapcraft in a Raspberry PI and then build the package there? <kyrofa> LefterisJP, I believe so, assuming you're compiling (last I checked snapcraft didn't support cross-compiling) <kyrofa> LefterisJP, or in an arhm qemu or something <kyrofa> s/arhm/arm/ <sergiusens> good morning <kyrofa> Morning sergiusens :) <kyrofa> sergiusens, to double check: to build an armhf .snap with snapcraft, snapcraft needs to run on an arm, right? <sergiusens> kyrofa, today, yes <LefterisJP> or in general what is the recommended way to build for Raspberry PI target from an Ubuntu host. <sergiusens> kyrofa, you are up early, or maybe I am up late :-P <kyrofa> sergiusens, yeah a little. This time of year exercising in the morning sucks <kyrofa> sergiusens, so I'm trying to shift my schedule back a little so I can exercise after work <LefterisJP> sergiusens: You mentioned today yes. Is there any plans to add support for compiling for RaspPi (armhf) from an Ubuntu host in the future? <sergiusens> LefterisJP, only ideas; probably mostly for things like go and node. Nothing stops you today from writing a custom plugin basing out of one of the existing ones that does just that for your needs though <LefterisJP> I am still getting my bearings as to how Snappy Ubuntu works and how I can accomplish my goals. <LefterisJP> Thanks I understand. <sergiusens> LefterisJP, what are your goals? <LefterisJP> I may bother you guys a bit more with extra "newbie" questions. <kyrofa> LefterisJP, no bother! <kyrofa> LefterisJP, but yeah, if you can explain what exactly you're looking to accomplish, we can probably point you in the easiest direction <LefterisJP> I am working for slockit (http://slock.it/) and am trying to evaluate and see if it makes sense to use Snappy Ubuntu for our work. I am trying to gather as much info as possible to creating Snappy Frameworks as my final goal is to create an Ethereum(https://ethereum.org/) Snappy Framework which other Snappy apps can utilize. <LefterisJP> At least for now for testing purposes I use a Raspberry Pi as my testing target environment <kyrofa> LefterisJP, for evaluation purposes perhaps it would be easier to use an amd64 virtual machine running snappy? <kyrofa> LefterisJP, a qemu VM is just going to be slow is all <sergiusens> kyrofa, btw are you on xenial? <kyrofa> (an arm one anyway) <sergiusens> kyrofa, I am seeing this with the tests http://paste.ubuntu.com/14410381/ <sergiusens> but it does not happen on travis <kyrofa> sergiusens, no I'm on trusty :P <kyrofa> sergiusens, huh, that doesn't look good <kyrofa> Looks like the mock lib changed... ? <sergiusens> kyrofa, indeed <kyrofa> grr... breaking api... <kyrofa> sergiusens, I'm not sure how to fix that in a backward-compatible way <sergiusens> kyrofa, I'll look into it <kyrofa> sergiusens, alright let me know. I can fire up a xenial lxc in no time <sergiusens> kyrofa, I can do it with more code <sergiusens> kyrofa, the problem is the error 'helper' message when the assertion fails <kyrofa> sergiusens, oh. Did they just remove support for it? <sergiusens> kyrofa, I don't think it was removed entirely as I use it too and those don't fail (Equal), only in the called one it seems <kyrofa> sergiusens, worst case we can just remove the helper message and that will work on all versions * sergiusens checks the docs <sergiusens> kyrofa, I;ll leave the message, don't worry ;-) <sergiusens> easy to fix <sergiusens> kyrofa, so even worse, nothing changed; assert_not_called only exists in 3.5 and trusty uses 3.4 so you were tricked by the mock's consumtion of anything it was called with :-P <kyrofa> sergiusens, oh no <kyrofa> sergiusens, that's _terrible_ <kyrofa> sergiusens, oh, so embarrassing :P <kyrofa> sergiusens, easy fix though <sergiusens> kyrofa, yeah, done already; taking more time to think of a commit message than anything else :- <sergiusens> :-P <kyrofa> sergiusens, just using .called? <sergiusens> kyrofa, yeah <kyrofa> sergiusens, great, thanks for mopping up behind me <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/200 <LefterisJP> So I have a bit more general question. Once you make an app or Framework for Ubuntu core it does not mean that it will run on every device running Ubuntu core, right? It means only for devices having the same architecture? Then to support each device you would have to generate a .snap for that device's architecture separately? <kyrofa> LefterisJP, you have the right idea, although it's possible to create a .snap for multiple architectures if your project supports such a thing. An example might be a series of shell scripts, or something you've already compiled for other architectures <kyrofa> LefterisJP, keep in mind that you don't HAVE to have snapcraft build your snap for you. In current releases you can just snappify a directory with snappy build (future releases moves that functionality into snapcraft, but you can still just snappify a directory) <LefterisJP> interesting, where can I find more information for multiple architectures projects? I mean I saw some projects adding an architectures list in the yaml file, like: `architecture: [amd64, armhf]` but how can you specify the rules as to how to build
{'channel': 'snappy', 'month': 1}