| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| fgimenez | good morning | 07:03 |
|---|---|---|
| davidcalle | Morning o/ | 07:14 |
| === bigcat__ is now known as bigcat | ||
| JamesTait | Good morning all; happy Monday, and happy Miniature Golf Day! 😃 | 09:09 |
| * ogra_ puts | 09:16 | |
| === vrruiz_ is now known as rvr | ||
| sergiusens | Chipaca, around for a review? | 10:12 |
| biezpal | Hello all. We've updated our Snappy Ubuntu to the latest stable and now our package version after installation is some random string (like IBQKIEHAHMYG) instead of 0.0.1 for example. Is it a new feature or bug? Where we can read about it? | 10:17 |
| sergiusens | biezpal, it is a feature; for sideloaded apps; in order to have an upgrade path when iterating during development | 10:18 |
| biezpal | sergiusens, how can we access data at this location without specifying version? | 10:21 |
| sergiusens | biezpal, using SNAP_APP_DATA_PATH and other env vars | 10:22 |
| sergiusens | biezpal, if you are not familiar with the env vars, maybe install hello-world and run hello-world.env | 10:23 |
| biezpal | sergiusens, and what if we have build-in paths in executables? | 10:24 |
| biezpal | some external soft which we cannot rewrite | 10:24 |
| biezpal | lxc for example | 10:24 |
| asac | biezpal: do you build lxc on your own? Otherwise I cannot see how it could work with anyway. | 10:34 |
| biezpal | asac, yes, we are rebuilding lxc | 10:35 |
| biezpal | we are using lxc as a virtualization provider in our own project | 10:38 |
| ogra_ | mvo, sergiusens, any idea how we can tackle bug 1497582 ? looks tricky given dget is involved | 10:40 |
| ubottu | bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,New] https://launchpad.net/bugs/1497582 | 10:40 |
| ogra_ | (kind of blocked me to pacckage up my IMAP server snap on the weekend | 10:41 |
| ogra_ | ) | 10:41 |
| sergiusens | ogra_, oh, I need to massage an MP form mvo | 10:41 |
| sergiusens | ogra_, and we aren't using dget anymore | 10:41 |
| ogra_ | ah, we have a fix ? | 10:41 |
| ogra_ | neato :) | 10:41 |
| sergiusens | ogra_, we are using python3-apt | 10:41 |
| ogra_ | cool, yeah, that should resolve the dep | 10:42 |
| sergiusens | ogra_, yeah, I need to tinker it a bit since it has been targetting one of tedg's internal branches | 10:42 |
| sergiusens | ogra_, I'll wait for tedg to see if he started or not to work on this; if not I'll get to it :-) | 10:42 |
| ogra_ | yeah, if sometihing is in the pipe i'm happy | 10:43 |
| ogra_ | after doing the irceproxy yesterday and ll the wrangling with the config stuff i guess the mailserver will rather be a multi day effort anyway | 10:43 |
| ogra_ | *all | 10:44 |
| biezpal | asac, https://github.com/lxc/lxd-pkg-ubuntu/blob/snappy/build | 10:44 |
| biezpal | we are using versioning in the similar way as in the lxd, but now it's impossible | 10:44 |
| ogra_ | longsleep, congrats to the release ! | 10:46 |
| asac | stgraber: heya see biezpal challenge above with lxc/lxd and requiring known, fixed path during package-as-snap time... anyway to make this relocatable? | 10:51 |
| mvo | sergiusens: I thought this was part of ted MP? I can create a fresh MP and fix the outstanding issues, sorry, was not aware that the ball was in my court :) | 10:56 |
| sergiusens | mvo, it is, but I want to streamline it into trunk directly as that MP might take a bit :-) | 10:56 |
| asac | biezpal: so the problem really is that we plan to not enforce that you put a unique version into the version: field... but we will rather assign versions during upload. this means we will somehow also allow that two snaps with same version can be installed on same disk, which makes it impossible to use that version | 10:56 |
| ogra_ | i was surprised to see the virtual dep ... i thought the debian policy forbids such deps | 10:56 |
| ogra_ | but looking deeper it seems it is wildely used in perl packages | 10:57 |
| sergiusens | ogra_, might be a dep for something that was removed from the archive? | 10:57 |
| sergiusens | ah, perl; always doing dirty things ;-) | 10:57 |
| ogra_ | no, perl-base provides the virtual api package dep | 10:57 |
| ogra_ | and packages using perl base seem to all depend on it | 10:58 |
| biezpal | asac, why don't you create "current" link as in the /apps directory? | 10:58 |
| ogra_ | how would that help with non-modifyable paths ? | 10:59 |
| ogra_ | (upstream paths i mean) | 10:59 |
| asac | biezpal: we currently dont create current link for the sideloaded app? | 10:59 |
| ogra_ | asac, we dont create it for any *_DATA_* dirs | 10:59 |
| ogra_ | only for the package dir itself | 10:59 |
| asac | ogra_: why is that? | 10:59 |
| ogra_ | no idea :) | 11:00 |
| asac | feels like a bug to me | 11:00 |
| ogra_ | i know we used to have that link in the beginning | 11:00 |
| biezpal | ogra_, if there will be "current" link we'd use it to access data | 11:00 |
| ogra_ | and for some reason it was decided to not have it anymore | 11:00 |
| asac | i could see that apps shouldnt accidentially write in the wrong data dir, but confinement would protect us from that risk, no? | 11:00 |
| ogra_ | biezpal, well, use the env vars for that | 11:00 |
| sergiusens | asac, ogra_ current link for data breaks security | 11:00 |
| mvo | sergiusens: makes sense, I will get to it after lunch | 11:01 |
| ogra_ | ah, that was it | 11:01 |
| asac | ogra_: well, lots of software has build time arguments like https://github.com/lxc/lxd-pkg-ubuntu/blob/snappy/build | 11:01 |
| asac | think the less we ask folks to patch code the better :) | 11:01 |
| asac | mvo: thoughts on current link for data? | 11:01 |
| ogra_ | asac, right, so we need to find a fix for that ... but seems "current" isnt the right solution | 11:01 |
| asac | ogra_: why? | 11:01 |
| ogra_ | see what sergiusens said | 11:01 |
| asac | sergiusens: that feels odd | 11:02 |
| asac | jdstrand: tyhicks: how does current link for data break security? doesnt apparmor look at realpath to enforce confinement? | 11:02 |
| asac | sergiusens: are you sure? when did we talk about this? | 11:03 |
| sergiusens | mvo, maybe review my code instead and I can rebase ;-) | 11:03 |
| ogra_ | asac, it was removed after IOM iirc | 11:03 |
| mvo | sergiusens: already done | 11:03 |
| sergiusens | mvo, oh goodie, thanks | 11:03 |
| asac | mvo: do you remember the current link discussion for data? | 11:04 |
| * sergiusens gets started with breakfast | 11:05 | |
| ogra_ | oh, thats a good idea | 11:05 |
| sergiusens | asac, I am not sure; but we also wanted all symlinks killed | 11:05 |
| asac | i really dont buy this... if a link allows to fake a path within a subtree, then folks can create links in their data directory to whatever place they want to hack on | 11:05 |
| asac | unless we dont allow creation of symlinks at all ... which would surely be a big problem :) | 11:06 |
| asac | guess lets wait for security friends to wake up | 11:07 |
| mvo | asac: not much of it unfortunately, I will read backlog after lunch. | 11:08 |
| biezpal | thanks for response, waiting for security friends :) | 11:08 |
| soffokl | btw, apparmor confined path like "/var/lib/apps/foo/*/run/state r," anyway | 11:10 |
| soffokl | s/confined/confine | 11:10 |
| === om26er_ is now known as om26er | ||
| longsleep | ogra_: thanks ! Now that i have a release with firmware, i encountered several wifi related systemd services failing. I was planning to add a bug for each of them - do you think that makes sense? | 11:39 |
| ogra_ | yeah | 11:39 |
| longsleep | i think wifi was not much tested with snappy yet. It works fine though, just scary error messages on boot. | 11:40 |
| ogra_ | yeah, we need to fix that | 11:46 |
| jdstrand | asac: apparmor will resolve symlinks so /var/lib/apps/foo/current -> /var/lib/apps/foo/1.0, an app using current would evaluate to /var/lib/apps/foo/1.0 when rules are applied | 12:09 |
| jdstrand | we use current for install directory, we should be able to use it for data dir | 12:10 |
| ogra_ | jdstrand, why did we remove it then ? | 12:10 |
| jdstrand | I have no idea. I have always wondered why it wasn't there | 12:10 |
| ogra_ | well, all i remember is that it was removed after some discussion at the IOM sprint | 12:11 |
| ogra_ | we used to have it in the beginning | 12:11 |
| jdstrand | I think it should be carefully tested, because the data dir has a bind mount for /tmp, but otoh I can't think of a reason why it wouldn't work | 12:12 |
| ogra_ | probably due to overlayfs plans ? | 12:12 |
| jdstrand | istr (vaguely) it having to do with rollbacks | 12:12 |
| jdstrand | like, something about it being confusing | 12:13 |
| jdstrand | any decisions for current and security based on overlayfs would have been premature | 12:13 |
| jdstrand | since overlayfs isn't ready to be used in this context | 12:14 |
| asac | jdstrand: how is progress on that? | 12:14 |
| jdstrand | (doesn't play well with LSMs in general) | 12:14 |
| asac | thats really the golden bullet for everything | 12:14 |
| jdstrand | asac: it is deprioritized | 12:14 |
| asac | by whom? | 12:14 |
| asac | upstream? | 12:14 |
| jdstrand | it is our of our control | 12:14 |
| asac | can we take control through investment? | 12:14 |
| ogra_ | by kernel versions :) | 12:14 |
| jdstrand | idk | 12:15 |
| jdstrand | we'd need a kernel developer to engage with them on the problems they have with LSMs | 12:15 |
| jdstrand | we looked at it quite a bit, and we can pick it up again, but not while we have to focus on stacked namespacing (lxd) | 12:16 |
| jdstrand | (which is why it is deprioritized on our board) | 12:16 |
| jdstrand | to be clear, we plan to pick it up again, but not particularly soon | 12:17 |
| jdstrand | I don't think investment is an option now that I think about it | 12:17 |
| ogra_ | well and if we hard-depend on it it will massively reduce the ability to use BSP kernels | 12:17 |
| jdstrand | the principle author is a redhat employee and in tight control | 12:17 |
| jdstrand | perhaps tyhicks has more background information | 12:18 |
| dholbach | mvo, can you take a look at https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801? | 12:20 |
| jdstrand | asac: reading our trello card, it is high priority but below namespace stacking. however, tyhicks said he might be able to reengage with upstream this month (september). based on sprint timing and identity (which is taking longer than expected), this is more likely next month | 12:21 |
| jdstrand | asac: so, I slightly misremembered (sorry). it is deprioritized for one engineer, reassigned to another where it is only slightly deprioritized | 12:21 |
| jdstrand | but, we still don't have control of upstream-- we'll be interacting with them and talking about what apparmor needs | 12:22 |
| jdstrand | I don't know how overlayfs solves 'current' though | 12:23 |
| asac | jdstrand: i thought there is no problem with current | 12:23 |
| asac | or is there? | 12:23 |
| jdstrand | I don't think there is. I'm just wondering how we got to overlayfs (golden bullet comment) after talking about current | 12:24 |
| ogra_ | well, it would be good to do some forensics why current was removed in the first place | 12:25 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | unrelated question-- are we copying the data dir for apps on app upgrades or do apps have to do it themselves? | 12:25 |
| ogra_ | i thinkwe do | 12:25 |
| ogra_ | at least it happens for me | 12:26 |
| ogra_ | (i.e. configs under /var/lib/apps move forward) | 12:26 |
| sergiusens | mvo, I grabbed the work for apt and fixing, we indeed need manifest.txt in there or the downloaded package list is a bit to long | 12:29 |
| mvo | sergiusens: oh, ok. I had hoped that we can get away with the priority | 12:39 |
| mvo | sergiusens: if we need it, just revet the change that removes it | 12:39 |
| mvo | sergiusens: or let me fix it, as you want | 12:39 |
| sergiusens | mvo, I'll push a branch to ~snappy-dev if I can't around it | 12:40 |
| sergiusens | mvo, building the examples is getting tricky with this pacakge set brought in | 12:41 |
| mvo | sergiusens: push it now, I will pick it up | 12:41 |
| * Chipaca waves hello from a train | 12:43 | |
| sergiusens | mvo, lp:~snappy-dev/snapcraft/more-apt | 12:48 |
| mvo | sergiusens: ta | 12:48 |
| mvo | sergiusens: how nice do you want this to be? we could (trivially) use geoip to select the country mirror for example | 12:49 |
| mvo | sergiusens: looks very nice otherwise | 12:50 |
| sergiusens | mvo, if it is not too much work, would be good :-) but then again, I'm not sure how to solve a broken archive issue, so maybe more into the future? | 12:51 |
| ogra_ | just enfoce usage of a stable archive ;) | 12:51 |
| ogra_ | LTS only or some such | 12:51 |
| sergiusens | mvo, if only that branch worked, the examples (webcam-webdm) fails terribly; python3 goes on a CPU roll doing 'writing dependency_links to config.egg-info/dependency_links.txt' | 12:51 |
| mvo | sergiusens: oh? give me a minute to check. releated to the python-apt changes you think? | 12:52 |
| sergiusens | mvo, yeah, I can roll back to triple check | 12:53 |
| sergiusens | but I'm pretty sure I built all the examples before this change | 12:53 |
| mvo | sergiusens: at what point does it explode for you? I am just running it now and its downloading stuff | 12:54 |
| sergiusens | mvo, on python3 setup.py install for the config part | 12:55 |
| mvo | sergiusens: not sure whats going on, but webcam-webui_1_amd64_.snap was created succesfully for me | 12:57 |
| sergiusens | mvo, oh, heh; I just cleaned up the python build stuff and trying again (remove 'build', 'dist' and egg stuff) | 12:58 |
| ogra_ | mvo, hmm, we didnt have dailies since friday on 15.04 edge | 12:58 |
| sergiusens | mvo, if it works I'll propose the MP; and I was thinking of using trusy instead of vivid but not sure that would break anything, in any case, starting 16.04 we should stick to that | 12:59 |
| ogra_ | mvo, oh, i guess we trashed cdimage, seems one of us didnt put the proper linking in place when renaming the dirs | 13:01 |
| sergiusens | mvo, it gets stuck on writing manifest file 'config.egg-info/SOURCES.txt', very cpu intensive | 13:09 |
| mvo | sergiusens: if you don't mind I will commit geoip support | 13:10 |
| mvo | ogra_: meh, that was probably me, sorry for that. are you fixing it or shall I do that? | 13:11 |
| ogra_ | well, still trying to find out why i only got one single failure mail | 13:11 |
| ogra_ | it should still have attempted a build every day since friday, but it didnt | 13:11 |
| mvo | ogra_: ok, just let me know when I shall look at anything (don't want to duplicate effort) | 13:12 |
| mvo | sergiusens: commited as r187, just uncommit if you think its not a good fit | 13:12 |
| sergiusens | mvo, no worries; I'm still battling with this python issue | 13:13 |
| tedg | Could we just check if the base system has a mirror set? | 13:28 |
| tedg | grep /etc/apt/sources.list | 13:29 |
| ogra_ | hmm | 13:29 |
| ogra_ | is snapcraft shell supposed to work ? | 13:29 |
| ogra_ | (and if so, how ? since the staging area doesnt actually have a full chroot) | 13:30 |
| ogra_ | seems it installed a lot of crap into my host when i ran apt-get install under it | 13:30 |
| ogra_ | not really what i would expect when reading the help | 13:33 |
| tedg | I'd guess it just sets up the env and cwd | 13:34 |
| ogra_ | well, it doesnt really "enter" the env though | 13:34 |
| ogra_ | apt-get install foobar after snapcraft shell will just happily install foobar on your host | 13:35 |
| tedg | Hmm, yeah. I don't think we'll ever change that. | 13:35 |
| ogra_ | running snapcraft shell changes my prompt to green, thats the only difference i see :) | 13:36 |
| tedg | We'd have to set up a lot more complex setup to get that to work. | 13:36 |
| ogra_ | well, then we should hit that in the help or some such | 13:36 |
| tedg | We're running apt in custom setup, not changing the environment. | 13:36 |
| ogra_ | *hint | 13:36 |
| tedg | Yeah | 13:36 |
| ogra_ | i can imagine a lot of people trashing their host with that | 13:36 |
| ogra_ | help cureently says: "shell enter staging environment" | 13:37 |
| ogra_ | which makews me think of a protected chroot or container or some such | 13:37 |
| sergiusens | ogra_, we can do like we do on the device ;-) | 13:39 |
| sergiusens | mvo, btw, I reverted all changes, to trunk and it works fine now | 13:39 |
| ogra_ | "like we do on the device" ? | 13:39 |
| sergiusens | mvo, I'm going mad as the package list is the same :-P | 13:39 |
| mvo | sergiusens: hmmm | 13:40 |
| dholbach | asac, I was wondering if we should set up milestones in LP for snapcraft and start targeting bugs, so it'll be easier to figure out what's planned next... | 13:48 |
| sergiusens | dholbach, replicate trello then? | 13:51 |
| dholbach | sergiusens, are the most important snapcraft bugs in trello? | 13:52 |
| sergiusens | dholbach, yes | 13:52 |
| ogra_ | there are no bugs in snapcraft, just hidden features :) | 13:52 |
| sergiusens | dholbach, I don't mind using lp, but it would be a pain to track in two locations | 13:52 |
| sergiusens | ogra_, it is still unreleased ;-) | 13:53 |
| dholbach | we are already tracking things in two locations | 13:53 |
| ogra_ | sergiusens, details :P | 13:53 |
| dholbach | but sure, I'm happy to use whatever is more convenient | 13:53 |
| tedg | sergiusens: Are you pulling the sources list specifying stuff into your branch? I had splitting that out on my todo. | 13:53 |
| sergiusens | dholbach, I'll bring it up during standup | 13:53 |
| sergiusens | tedg, yes, here lp:~snappy-dev/snapcraft/more-apt | 13:54 |
| sergiusens | tedg, team effort now ;-) | 13:54 |
| tedg | sergiusens: Heh, okay, I'll base off that branch. | 13:54 |
| dholbach | sergiusens, so you'd recommend to just look at the "Development Experience" list in Trello to see what's planned in the next days/weeks? | 13:55 |
| sergiusens | tedg, and mvo added geoip; I still have issues here with the branch building the examples though | 13:55 |
| sergiusens | dholbach, yeah | 13:55 |
| dholbach | ok | 13:55 |
| tedg | sergiusens: I tried to throw a snapcraft at maas and it needs that branch. | 13:55 |
| sergiusens | dholbach, if someone can, I'd integrate bug linking in trello somehow and moving columns change the status in lp ;-) | 13:55 |
| dholbach | mh | 13:57 |
| tyhicks | jdstrand, asac: I have no new information regarding better LSM support in overlayfs | 14:00 |
| tyhicks | jdstrand, asac: I haven't had a chance to keep up with the linux-security-module mailing list over the last few weeks so I'll skim it some time this week to see if there is anything new there | 14:01 |
| tedg | sergiusens: Why not have default sources be the one on the system? | 14:05 |
| tedg | sergiusens: It seems like that'd match what people are used to the best. | 14:06 |
| sergiusens | tedg, consistent base for the snap | 14:06 |
| tedg | sergiusens: Like if you're confused on a dep you'd do "apt-cache depends foo" to figure it out. | 14:06 |
| tedg | sergiusens: I think that we should allow people to set that, but we shouldn't choose it. | 14:07 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | tedg, not even depending on the target snappy release? | 14:07 |
| tedg | sergiusens: No, I think that local machine makes sense. It's "my dev machine" — otherwise we're starting to do magic. | 14:07 |
| sergiusens | tedg, we already are ;-) | 14:08 |
| sergiusens | tedg, and then how do we solve jdstrand's bug in an easy transparent way? | 14:08 |
| tedg | I mean, I understand from the reproducable build perspective. But I think that it seperates the developer from what she is building. | 14:08 |
| ogra_ | what i as developer want is to maintain my snapcraft dir in a branch and if the distro releases a security update to the package i user i just want to go into the branch and caall snapcraft again to get the update binary | 14:09 |
| tedg | sergiusens: I think that it's pretty unlikely that people will have a deb installed on their system that they can't get... | 14:10 |
| ogra_ | thats my main purpose for using debs actually ... someone else does the maintenance of the binary for me | 14:10 |
| tedg | ogra_: Sure, the question is whether we choose one release for everyone to be based on. | 14:11 |
| ogra_ | i would say LTS by default with the ability to override | 14:11 |
| tedg | ogra_: And sergiusens says 15.04 because that is the snappy we're releasing right now. | 14:12 |
| tedg | Fight! | 14:12 |
| tedg | ;-) | 14:12 |
| ogra_ | if i'm after the stability and foreign maintenance above then non LTS doesnt make much sense for me | 14:13 |
| sergiusens | tedg, but you missed the part of my comment that once 16.04 is released; that should be the base | 14:13 |
| ogra_ | if i'm after the latest and greatest it would be nice to have a --devel-distro switch | 14:13 |
| sergiusens | ogra_, tedg snapcraft.yaml is supposed to have a target field which says which release to build for | 14:14 |
| ogra_ | buit effectively ... if you are after latest and greatest you should probably compile upstreams trunk | 14:14 |
| tedg | I think that we should be able to switch, but the default should be your current system. | 14:14 |
| tedg | It makes it easier to debug build failures. | 14:14 |
| sergiusens | mvo, so so, it works now; I wiped the branch and started from a clean checkout (maybe __pycache__ was going nuts) | 14:15 |
| ogra_ | tedg, so i get 12.04 packages in a precise system ? | 14:15 |
| mvo | sergiusens: ok, cool. anything else I can help with with that branch? | 14:15 |
| sergiusens | mvo, review, and maybe fight or side with tedg :-P | 14:15 |
| * ogra_ proposes a round of bullshit bingo during standup, who wins decides ... | 14:17 | |
| sergiusens | mvo, tedg ogra_ MP is here fwiw https://code.launchpad.net/~snappy-dev/snapcraft/more-apt/+merge/271817 | 14:17 |
| sergiusens | tedg, using local sources also may provide unsharable builds as it might depend on the ppa set you have | 14:18 |
| ogra_ | well, you got vivid hardcoded there or do i read the code wrong ? | 14:19 |
| sergiusens | ogra_, yes; that will change once target lands in snapcraft.yaml | 14:19 |
| ogra_ | right | 14:20 |
| tedg | sergiusens: Sure, but I think what we want first is to make it easy to use, not universally correct. | 14:20 |
| sergiusens | ogra_, targetting the right target | 14:20 |
| * ogra_ thinks thats fine for a start | 14:20 | |
| ogra_ | tedg, you mean like we did with all the rest of snappy that we are redesigning over and over now ? | 14:20 |
| ogra_ | i think doing it correct from the start is the better approach :) | 14:21 |
| tedg | ogra_: I believe the modern, hip word is "pivoting" | 14:21 |
| ogra_ | even if that means it isnt complete | 14:21 |
| tedg | I disagree that it is correct. | 14:22 |
| tedg | I think it's forcing someone to starting building a system that is correct from the start, it's okay if they don't make it perfect from the start. | 14:22 |
| ogra_ | i only disagree that we should use vivid as default | 14:22 |
| tedg | We need it to be easier to play with from the start. | 14:22 |
| sergiusens | tedg, why is it hard to play with this way? | 14:23 |
| tedg | sergiusens: Because when it breaks you can't easily figure out why. | 14:24 |
| sergiusens | I really want to avoid the 'works for me' converstions | 14:24 |
| sergiusens | tedg, ah, but when it breaks and we get a bug report we can | 14:24 |
| tedg | sergiusens: No, it'll be "eh, doesn't work, I'll use Docker" ;-) | 14:24 |
| tedg | There'll be no bug report | 14:24 |
| sergiusens | tedg, in any case we can add a cli switch to use the local cache | 14:24 |
| sergiusens | tedg, well, we have 2 already | 14:26 |
| tedg | Hmm, I think I broke it. | 14:30 |
| tedg | Seems None is different than not a value. | 14:30 |
| asac | tyhicks: thx! | 14:31 |
| tedg | sergiusens: The exception test is failing, I'm not sure why. | 14:46 |
| sergiusens | tedg, oh, because I didn't run the tests :-/ The mp spiraled out of control and ended up in an mp to see the diff | 14:47 |
| sergiusens | let me fix those tests | 14:47 |
| stgraber | asac: not really. We hardcode those paths for security reasons as some of the LXC binaries are setuid and so using relative paths would allow for a user to root escalation | 14:52 |
| dholbach | fgimenez, good catch in your build-examples-test branch! | 14:54 |
| dholbach | fgimenez, do you know if we are planning to hook up the dep8 tests with tarmac somehow? | 14:54 |
| fgimenez | dholbach, thx :) no idea about the integration with tarmac, maybe elopio can help with that | 14:56 |
| dholbach | I think it'd be fantastic if we could run exercise the snapcraft test machinery whenever we want to land stuff - not sure though how much work that would be or if it's planned | 14:57 |
| ogra_ | dholbach, isnt that the outstanding CI integration thing ? | 14:57 |
| dholbach | ogra_, I don't know :) | 14:57 |
| ogra_ | :) | 14:58 |
| Chipaca | sergiusens: where does the yaml requirement come from? i don't see it in config itself | 15:11 |
| elopio | dholbach: tarmac is running ./runtests, which executes the integration tests. | 15:11 |
| Chipaca | sergiusens: coreconfig, yes, because it yaml decodes it into a struct, but generic config just passes a string? | 15:11 |
| jdstrand | tyhicks: re no new info> right that is fine and inline with our card priorities over the last few weeks. thanks! :) | 15:13 |
| sergiusens | Chipaca, right | 15:13 |
| sergiusens | Chipaca, you are right; I'm just talking spec wise | 15:13 |
| sergiusens | Chipaca, code wise we are a bit more broken :-) | 15:13 |
| Chipaca | ah, ok | 15:14 |
| jdstrand | ogra_: re snapcraft and security updates-- yes, that sounds nice | 15:16 |
| ogra_ | :) | 15:17 |
| jdstrand | and yes, choosing the LTS as the default sounds sane to me, with some way to choose another release | 15:17 |
| === chihchun is now known as chihchun_afk | ||
| dholbach | elopio, cool.... with the examples-test landing soon, can we add that too? :) | 15:24 |
| dholbach | right now the py2- and py3- examples are broken | 15:24 |
| dholbach | qml almost fixed | 15:24 |
| elopio | dholbach: we can. What we can't yet is to run the tests in qemu. | 15:38 |
| elopio | we need a bare metal machine for that. | 15:38 |
| dholbach | ok, I see | 15:41 |
| dholbach | thanks elopio | 15:41 |
| sergiusens | mvo, so mind reviewing https://code.launchpad.net/~snappy-dev/snapcraft/more-apt/+merge/271817 ? | 15:48 |
| === kickinz1 is now known as kickinz1|afk | ||
| sergiusens | Chipaca, in between RESTs ;-) | 15:59 |
| Chipaca | sergiusens: clearly | 15:59 |
| sergiusens | Chipaca, so never as you are always RESTing now ;-) | 15:59 |
| asac | biezpal: hey, can you file a bug please and give it to me? | 16:13 |
| asac | thanks | 16:13 |
| elopio | ev: can I deploy this is jenkins in a local lxc? That would make the requests to RT easier. | 16:25 |
| dholbach | all right my friends - I call it a day - see you all tomorrow! | 16:27 |
| === ogra2 is now known as ogra-snappy-test | ||
| tedg | sergiusens: So we may need a way to filter out packages... the ros stuff is pulling in the whole kitchen sink | 17:25 |
| tedg | sergiusens: Not sure if we should provide a way to basically say we already have some installed or provided | 17:26 |
| sergiusens | tedg, as in, extend the manifest.txt thing? | 17:26 |
| tedg | sergiusens: Or just provide a generic filter | 17:26 |
| sergiusens | tedg, is this using the ros debs you created? | 17:26 |
| tedg | sergiusens: Hmm, I guess I'm set for trusty, so that may be the problem. | 17:26 |
| tedg | sergiusens: No, ROS debs from their official archive | 17:27 |
| sergiusens | tedg, do most of these ros things need to be stage-packages contrary to build-packages? | 17:42 |
| * sergiusens is catching up with ros | 17:42 | |
| tedg | sergiusens: Yeah, basically you're installing the RPC mechanism. | 17:46 |
| tedg | Well, really it's an RPC broker | 17:46 |
| jdstrand | zyga (though this may be a question for sergiusens/tedg): I tried to 'snapcraft' with this: https://git.launchpad.net/~zyga/+git/snap-example-hostapd/tree/snapcraft.yaml, and have: | 17:50 |
| jdstrand | Namespace(cmd='snap', force=False, func=<function assemble at 0x7f1af125e510>) | 17:50 |
| jdstrand | Unknown plugin: x-custom | 17:50 |
| jdstrand | Could not load part x-custom | 17:50 |
| jdstrand | I have the snapcraft from the tools-proposed ppa | 17:50 |
| jdstrand | where does one get that plugin? | 17:51 |
| tedg | jdstrand: There is an MR, but I doubt it'll be adopted. | 17:51 |
| tedg | jdstrand: It runs scripts, which we were trying to avoid. | 17:51 |
| ogra_ | jdstrand, alsso the snapcraft.yaml format changed | 17:52 |
| ogra_ | http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/your-first-snap.md | 17:52 |
| sergiusens | jdstrand, did you delete the 'parts' dir in there? that's where local plugins live | 17:52 |
| jdstrand | I didn't do anything | 17:52 |
| jdstrand | :) | 17:52 |
| jdstrand | zygo gave me this url at the beginning of last week | 17:52 |
| sergiusens | ogra_, he already has that ;-) | 17:52 |
| jdstrand | zyga* | 17:52 |
| jdstrand | so I just tried to use it. I guess it needs work | 17:53 |
| sergiusens | jdstrand, but yeah, that example won't work with trunk anymore | 17:53 |
| jdstrand | zyga: do you have an updated snapcraft.yaml for the new tools? | 17:53 |
| jdstrand | well, I don't really need it | 17:53 |
| jdstrand | I tested my network-admin cap in other ways and will just add more rules as needed | 17:53 |
| * zyga looks | 17:53 | |
| sergiusens | jdstrand, this MP is pretty straight forward in explaining why https://code.launchpad.net/~sergiusens/snapcraft/mapnames/+merge/271799 | 17:54 |
| zyga | jdstrand: no, that format works with trunk (it's already using the new format) | 17:54 |
| zyga | jdstrand: the issue of running scripts from snapcraft.yaml vs from makefile that that snapcraft.yaml points at is not a priority for me now, I'm working on a commercial project now and I won't have time to look at this for a while | 17:55 |
| zyga | jdstrand: it probably doesn't work with the version in the ppa but it does work with trunk | 17:55 |
| jdstrand | ok, that's fine | 17:55 |
| jdstrand | like I said, I tested what I'm doing in other ways | 17:56 |
| zyga | jdstrand: if you branch lp:snapcraft and build it it should be fine | 17:56 |
| jdstrand | zyga: thanks | 17:56 |
| zyga | jdstrand: ok, sorry this is not more friendly :/ | 17:56 |
| jdstrand | zyga: ok, I was just going by what others said-- I have the branch from friday running here | 17:56 |
| jdstrand | anyhoo | 17:56 |
| * jdstrand tries to build a java one now | 17:57 | |
| * tedg sends flowers to jdstrand's CPU | 17:58 | |
| jdstrand | well, really, I have a jar file | 17:58 |
| jdstrand | I just need to snag openjdk and then I can script the rest | 17:58 |
| jdstrand | is there some easy way to say "give me these 5 debs and I'll provide 'services/binaries' that use them"? | 18:01 |
| zyga | jdstrand: you can use the stage-debs key AFAIR | 18:02 |
| * zyga looks | 18:02 | |
| zyga | stage-packages: | 18:02 |
| zyga | jdstrand: ^^ | 18:02 |
| jdstrand | sergiusens mentioned something about that on friday (ie, grab ufw from the archive and use parts for it), but this is different. I want openjdk. I'll just show a jar in the snap and script the rest | 18:02 |
| ogra_ | jdstrand, http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml | 18:03 |
| ogra_ | stage-packages | 18:03 |
| jdstrand | ok, thanks | 18:03 |
| ogra_ | (with dash in front) | 18:03 |
| zyga | is there a manual page for snapcraft.yaml? | 18:03 |
| jdstrand | s/show a/shove a/ | 18:03 |
| zyga | plainbox has close to two dozen manual pages now and it's a lot easier for developers to use it now | 18:03 |
| ogra_ | jdstrand, you want the copy plugin then | 18:03 |
| zyga | maybe I should write some for snapcraft | 18:03 |
| jdstrand | please note, I am a total newbie | 18:04 |
| ogra_ | jdstrand, look at my snapcraft.yaml above ... you should be able to mostly copy it and change the values | 18:04 |
| zyga | jdstrand: that's why manual pages are great! | 18:04 |
| sergiusens | jdstrand, you can use the jdk plugin as well | 18:04 |
| jdstrand | I read the docs/* and a couple examples | 18:04 |
| * jdstrand <3s manpages | 18:04 | |
| ogra_ | sergiusens, will that copy a local jar in place ? | 18:04 |
| sergiusens | ogra_, no; I thought he said he wanted a jdk environment :-) | 18:05 |
| sergiusens | and grab a random jar | 18:05 |
| ogra_ | he has a jar and wants the env around it | 18:05 |
| jdstrand | yes, what ogra_ said | 18:05 |
| sergiusens | jdstrand, maybe the easiest path is ogra's | 18:06 |
| jdstrand | ok | 18:07 |
| sergiusens | jdstrand, the canonical example from sources is http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/files/head:/examples/java-hello-world/ | 18:07 |
| jdstrand | sergiusens: yeah, I saw that. I just have a jar, so | 18:09 |
| ogra_ | so put it next to your snapcraft.yaml and use the copy plugin like in mine ... | 18:10 |
| ogra_ | for stage-packages you add your jdk then | 18:10 |
| ogra_ | http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files for reference | 18:10 |
| jdstrand | yeah, I have openjdk-7-jre-headless | 18:11 |
| sergiusens | zyga, is this fixed btw https://bugs.launchpad.net/snapcraft/+bug/1484596 ? | 18:11 |
| ubottu | Launchpad bug 1484596 in PlainBox (Toolkit) "tests print a lot of warnings when they leave files on the working directory" [Undecided,Triaged] | 18:11 |
| zyga | sergiusens: nope, not yet, though I did have a look at how to fix it and I think I can patch it in snapcraft directly without involving the more correct fix | 18:11 |
| * zyga looks | 18:11 | |
| zyga | one logging call to silence | 18:12 |
| zyga | sergiusens: I have a fix, testing now | 18:23 |
| sergiusens | ack, ty | 18:23 |
| sergiusens | jdstrand, right, no need to add the jdk if not building | 18:24 |
| sergiusens | ogra_, btw, I just recalled; sources.list for armhf will be different (ports...) | 18:24 |
| ogra_ | yeah | 18:25 |
| ogra_ | and an /ubuntu-ports suffix | 18:25 |
| sergiusens | ogra_, and no geoip I guess | 18:25 |
| ogra_ | no mirrors | 18:26 |
| sergiusens | right | 18:26 |
| * zyga adds some improvements for plainbox that snapcraft can use | 18:30 | |
| zyga | sergiusens: can I assume you run unit tests with the daily development snapshots of plainbox? | 18:31 |
| jdstrand | ok, that seems to have worked, nice | 18:33 |
| jdstrand | ogra_: thanks! | 18:33 |
| sergiusens | zyga, whatever is in our readme | 18:33 |
| sergiusens | zyga, sudo add-apt-repository ppa:hardware-certification/public | 18:34 |
| zyga | sergiusens: excellent | 18:40 |
| sergiusens | elopio or Chipaca mind walking down the pipe for https://code.launchpad.net/~sergiusens/snapcraft/1498140/+merge/271860 ? | 19:22 |
| * guest42315 snappy <3 | 19:27 | |
| zyga | sergiusens: testing now, I'll sent the MR in a sec | 19:30 |
| zyga | sergiusens: wow, seing people crete new plainbox jobs is amazing | 19:30 |
| zyga | sergiusens: FYI: ttps://code.launchpad.net/~zyga/snapcraft/fix-1484596/+merge/271863 | 19:33 |
| zyga | (still testing, give me one sec) | 19:34 |
| sergiusens | zyga, that's empty ;-) | 19:35 |
| zyga | ohh, sorry | 19:35 |
| zyga | sergiusens: fixed, I'll pastebin the way it runs for me now | 19:41 |
| zyga | (now with fixed merge conflict and typos) | 19:42 |
| zyga | snapcraft/normal/assemble-meta fails for me (new laptop, perhaps some deps missing) | 19:43 |
| sergiusens | zyga, strange | 19:43 |
| zyga | sergiusens: I'll pastebin in a sec | 19:44 |
| zyga | sergiusens: do I need snappy from the ppa or is wily fresh enough? | 19:46 |
| sergiusens | zyga, ah, the ppa isn't fresh enough | 19:48 |
| zyga | sergiusens: yes, but it won't prevent it from working | 19:48 |
| zyga | sergiusens: I'll merge the fix to the ppa in a sec | 19:48 |
| zyga | sergiusens: and fast-path to stable | 19:48 |
| zyga | sergiusens: (though tomorrow, I need to ack this with spineau) | 19:48 |
| sergiusens | zyga, tomorrow is fine | 19:51 |
| * zyga still runs tests for the pastebin | 19:52 | |
| zyga | http://paste.ubuntu.com/12516689/ | 19:55 |
| zyga | sergiusens: ^^ I think you can merge this, those are just flags | 19:56 |
| zyga | sergiusens: I'll write an article on the new feature and merge this into plainbox | 19:57 |
| zyga | sergiusens: afk for a sec | 19:57 |
| * zyga tests suspend | 19:57 | |
| zyga | sergiusens: add those flags to new jobs that are coming in | 19:57 |
| sergiusens | ogra_, does this look ok to you? https://code.launchpad.net/~sergiusens/snapcraft/1498157/+merge/271872 | 20:46 |
| sergiusens | elopio, finish up the reviews! :-) | 21:18 |
| sergiusens | tedg, elopio https://code.launchpad.net/~sergiusens/snapcraft/1498212/+merge/271881 | 22:24 |
| * sergiusens will be back later tonight | 22:25 | |
| sergiusens | that fixes the broken setup.py's | 22:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!