[03:08] ping woodrowshen === chihchun_afk is now known as chihchun [06:40] Good morning [06:40] Chipaca: I am now [07:45] Hi all. It's renat from Screenly. I have a question about snapcraft tool. I want to specify $SNAP_APP_DATA_PATH but [07:46] But I get this error: "services description field 'Start' contains illegal 'usr/bin/screenly-playlist.wrapper -c '$SNAP_APP_DATA_PATH/config.yaml'' (legal: '^[A-Za-z0-9/. _#:-]*$') [07:46] " [07:46] eww [07:47] Does this mean that I shouldn't use environment variables in a start command, or it's a bug? [07:55] good morning [08:04] dholbach, ping [08:07] hi liuxg [08:08] dholbach, I created a python project using requirements.txt at https://github.com/liu-xiao-guo/restapi [08:09] liuxg, I never played around with pip and snapcraft [08:09] dholbach, however, there is a problem with the project. It works well on the desktop. When I deploy it onto KVM, it does not work. I see a symbolic link in the snap file http://paste.ubuntu.com/13780578/ [08:10] dholbach, would you please help me to confirm whether it is a bug or not. [08:10] let me see [08:11] dholbach, thanks a lot. the django stuff seems not packaged into the snap though they are pulled down. [08:11] renat: it means the path is just a path, not a command line [08:12] you should put this -c ARG into the wrapper itself === ricmm_ is now known as ricmm [08:12] liuxg, why don't you use django from the Ubuntu archive? didn't that work? or do you strictly need django 1.9? [08:13] liuxg, for me django is contained in the snap [08:13] it's in ./usr/lib/python2.7/dist-packages/django [08:13] (run dpkg -c mysnap.snap | less) [08:14] dholbach, in fact, anything should work. I just tried to see whether it works or not. if I want to use it from the ubuntu archive, I should use the "stage-packages", right? [08:14] yep [08:15] dholbach, after I deploy it, it is a little strange, in the KVM, it is a symbolic link there though the file is in the "snap" directory. [08:17] dholbach, this is what is seen in my place http://paste.ubuntu.com/13780734/ [08:18] yes, it's a broken symlink [08:19] so yes, I can confirm the issue [08:19] dholbach, is this a bug in the tool? [08:20] dholbach, maybe I need to report a bug for it? [08:20] yes, as far as I can tell, there shouldn't be symlinks going to locations which just exist in your home-directory when snapping [08:20] yes [08:20] your case is very good for testing [08:21] dholbach, it took me quite a while to debug this problem [08:21] ricmm_, thanks. I was thinking about it. I can't do it from a snapcraft. So I decided to create a bug in the launchpad. [08:22] renat: I dont understand, why cant you do it with snapcraft? [08:22] liuxg, maybe we can, as a safety measure, get the reviewers tools to give a warning if the symlinks are going to be broken [08:22] liuxg, let me know once you've filed the bug [08:22] you are using a wrapper script, so those arguments are better suited inside of the wrapper [08:22] dholbach, sure, I am reporting a bug for it. [08:24] thanks liuxg [08:27] dholbach, i have reported the bug at https://bugs.launchpad.net/snapcraft/+bug/1523384. please take a look at it. I hope it can fixed soon! [08:27] Launchpad bug 1523384 in Snapcraft "broken symlinks when snapping a python project using requirements.txt" [Undecided,New] [08:28] brilliant - thanks [08:28] I'll add a task for the reviewers tools as well [08:29] dholbach, thanks for your confirmation. I think this is a serious bug for it :) === davidcalle_ is now known as davidcalle [09:00] ricmm, that wrapper script is created by snapcraft tool. So I want it to include my command line options. [09:03] ahh I understand, yes [09:04] renat: you can modify the .wrapper in snap/ and manually build, or make your own and put it in the right location with a copy plugin [09:55] ogra_: any concerns about http://paste.ubuntu.com/13782938/ ? we currently rely on /etc/sudoers.d/90-cloud-init-users for sudo but it seems a group makes more sense [09:57] mvo, no objections at all ... but doesnt that also need a change in could-init then ? [09:58] (it creates some stuff in /etc/sudoers.d IIRC) [10:00] ogra_: it won't hurt (the cloudinit stuff). its just *if* we use a system without cloud init (a os snap) then things still work with sudo, right now they don't without cloud init [10:00] ogra_: I will upload then, thanks for the sanity check [10:00] ah, cool, yeah, if it is preventive thats fine indeed :) [10:14] ogra_: looks like bzr and archive are out of sync *grrr* [10:14] oh ? [10:17] and sil2100's last commit misses a changelog entry [10:18] ogra_: indeed it does [10:18] wow, what a mess [10:18] choas! [10:19] ogra_: I will untangle the mess (unless you are already on it) [10:20] no, i only checked, didnt start anything yet [10:21] ogra_: ok, should be fixed in some minutes [10:42] pitti: it seems systemd's journal loses messages during shutdown [10:42] pitti: is this expected? [10:42] pitti: or are we doing something wrong? [10:44] pitti: as in: 'stop' action prints some messages that normally appear in journal, but they're nowhere to be seen on shutdown, but stop action can be seen to be working by tee'ing the messages to a file under its control [10:46] ricmm, seems it's really possible to use shell variables. You may see here that "args" argument is not used in _wrap_exe. https://github.com/ubuntu-core/snapcraft/blob/a06a75e70bcbc76f02f4cbeacee11010f3f24440/snapcraft/meta.py#L256 [10:48] ricmm, thanks for help. I want to experiment with snapcraft and see what I can improve. [11:01] stevebiscuit: hello === Guest9543 is now known as beowulf [11:01] beowulf: 'ello [11:02] mvo: Chipaca: stevebiscuit is the "Steve" for webdm now [11:02] there can be only one === andyrock_ is now known as andyrock [11:41] stevebiscuit: welcome! [11:41] mvo: cheers :) [13:10] ogra_: ricmm: so, what are the kernel plans for dragonboard? [13:10] I want to make sure we're aligned in there somehow [13:10] and avoid yet another kernel tree [13:10] rsalveti, no idea, waiting for ppisati ... [13:10] i just want his deb ;) [13:10] <- lazy [13:11] got it :-) [13:11] tell him to ping me later [13:12] he is out today i was just told [13:12] so probably rather tomorrow [13:12] yeah, no worries :-) [13:12] ogra_: next ubuntu release is going to use 4.4, right? [13:12] do you know if i need all of the 8 boot partitions ? [13:12] i.e. the blob stuff [13:13] didn't yet try booting without them, so not so sure [13:13] ok, then i'll do trial and error as usual :) [13:14] * ogra_ is still pondering how to reflect that partition mess in the oem snap [13:17] hmm, tha dragonboard u-boot tree or the booti command dont understand CONFOG_RAW_IN'ITRD [13:18] even with the option set i need to use an uInitrd [13:18] just ping the maintainer, he can easily find out why [13:18] hallor at #96boards [13:18] ah i *knew* there was a board channel :P [13:29] Chipaca: are these messages from very late shutdown, perhaps after journal already stopped? [13:29] Chipaca: also, I thought snappy uses ephemeral journal only (i. e. not in /var/log)? [13:29] pitti, no, it uses both [13:29] we have rsyslog installed and running [13:33] Chipaca: oh, you mean you are not seeing late messages in /var/log/syslog? that's rsyslog, not journal [13:33] rsyslog gets stopped earlier indeed; but still a bit blurry about what kind of messages are missing === chihchun is now known as chihchun_afk [14:08] Chipaca, ping === |svij| is now known as svij [14:30] elopio, don't merge yet [14:31] kyrofa: ahhhh [14:31] Haha, that's okay [14:31] elopio, not important [14:31] kyrofa: I'm on the hangout. [14:31] elopio, getting on now [14:43] dholbach, so you've been adding some documentation for the snapcraft plugins? [14:45] kyrofa, yep, I've been going through the app developer manual and checking where we could reintegrate some of the bits from there [14:46] dholbach, I'd like to help with documenting the ROS Catkin plugin [14:47] kyrofa, it would probably make sense to make it a separate article, right? [14:47] a tutorial with an example on how to use the plugin maybe? [14:48] dholbach, yeah probably [14:48] kyrofa, probably easiest to just add it to snapcraft trunk and we import it from there :-) [14:48] dholbach, okay. You're pulling from 1.x, right? [14:49] elopio, how do you feel about cherry-picking the ROS plugin updates into 1.x? [14:49] kyrofa, right now yes, but soon from both [14:49] dholbach, oh good to know [14:49] kyrofa, right now it's still manual, but we're working on the automatic imports [14:50] dholbach, do you have a favorite article who's format I can follow? [14:51] kyrofa: I would prefer not to touch the other branch if we don't have to. Maybe once you finished doing all the changse and are totally happy with the plugins, we can just replace them. [14:51] elopio, good deal [14:52] kyrofa, no, not really - maybe just make it a walkthrough how to turn an existing ROS project into something which works with snapcraft? [15:05] dholbach, right, I guess that was more of a "where exactly should I put it and how do I make it look similar" question [15:05] kyrofa, if you just place it as a .md file in snapcraft's ./docs that should be good enough [15:06] dholbach, alright. Would it be worth creating a "plugins" subdir there so that directory doesn't just balloon as we add plugin docs? [15:06] I don't know [15:07] dholbach, not important I suppose. I'll just add to the root for now and we can move stuff around if necessary [15:07] yep, let's do that [16:04] elopio: joining? [16:04] plars: uf, sorry. [21:09] kyrofa, elopio, in case you are feeling bored https://github.com/ubuntu-core/snapcraft/pull/160 [21:10] Hey sergiusens, how is brazil? [21:11] kyrofa, great, going out for dinner now; but the sprint conversation was great, covered many things, all snaps and capabilities more than anything else [21:11] tomorrow it will be assertions [21:11] sergiusens, awesome :) [22:02] blount