| mhall119 | sergiusens: blame Linus :) | 00:47 |
|---|---|---|
| sergiusens | mhall119, I can ask Dirk; I have some minor contributions to subsurface ;-) | 00:49 |
| sergiusens | if anything they will save bandwidth ;-) | 00:50 |
| mhall119 | sergiusens: I may trouble you for help in the near future then :) | 00:53 |
| mhall119 | well, I almost certainly will trouble you for help, but it *may* be about subsurface | 00:53 |
| mhall119 | [ 83%] Linking CXX shared library libssrfmarblewidget.so | 00:55 |
| mhall119 | [ 83%] Built target ssrfmarblewidget | 00:55 |
| mhall119 | Makefile:160: recipe for target 'all' failed | 00:55 |
| mhall119 | make: *** [all] Error 2 | 00:55 |
| mhall119 | Command '['/bin/sh', '/tmp/tmpiqorb2d5', 'make', '-j4']' returned non- | 00:55 |
| mhall119 | zero exit status 2 | 00:55 |
| mhall119 | darn, I thought I was getting close | 00:55 |
| === shuduo_ is now known as shuduo | ||
| thomas25 | Hi | 08:25 |
| thomas25 | Last weeek end I was attending a conference in Lyon about snappy (given by didrocks) and I have a question I did not think about. | 08:28 |
| thomas25 | You are using squashfs to store the "snaps" but it is a read only fs, however you are also ablo to rollback the data. | 08:29 |
| thomas25 | So how do you store the data in the snaps ? | 08:30 |
| didrocks | thomas25: hey! we don't store the data themselves in snaps, only the executables code+assets | 08:31 |
| didrocks | thomas25: the data are just traditional file in a writable subdirectory | 08:31 |
| didrocks | and we have a "current" pointer to know to which folder to point at | 08:32 |
| thomas25 | So you juste copy the data when you update the snaps ? | 08:32 |
| thomas25 | It means that a developer which package an app need to give all the data files present in its snap ? | 08:34 |
| didrocks | thomas25: hardlinks (just need to recheck this though) | 08:34 |
| didrocks | thomas25: no, this is the data that the snap is writing, not the assets | 08:34 |
| didrocks | the assets is part of the code, and normally, not changed by the app | 08:34 |
| didrocks | so this is part of the .snap file | 08:35 |
| didrocks | (as they live on a traditional system in /usr/share for instance) | 08:35 |
| thomas25 | okay | 08:35 |
| thomas25 | Thanks for your quick answer and for the great conf last week end. | 08:37 |
| didrocks | thomas25: with pleasure! Do not hesitate to come by if you have any other questions :) | 08:38 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| shuduo | hello, may i know if snap store still accept new snap for 15.04? | 11:37 |
| zyga | shuduo: I think it should but I haven't checked | 11:41 |
| zyga | shuduo: give it a try? | 11:42 |
| shuduo | zyga: i submitted a snap built on 15.04 then be rejected by review tool. i guess only new version snapcraft will warn me. the fail msg is "Unexpected output from click-review." | 11:47 |
| zyga | I don't know what's the cause of that | 11:47 |
| shuduo | zyga: I see different set of snaps on store from 1504 snappy system and 1604. so if someone want to submit his/her app to both he/she should build twice and submit twice. right? | 11:50 |
| shuduo | as 16 is under developent but i need show something with 1504, so i have to submit my app to store for 1504. even the store still accept it, i have to build it by 2.x snapcraft to make sure no warning and will not be rejected by store. | 11:53 |
| zyga | shuduo: I believe so | 11:54 |
| zyga | shuduo: snapcraft 2.x only works for 16.04 | 11:54 |
| zyga | shuduo: for 15.04 you have to use snapcraft 1.x | 11:54 |
| shuduo | zyga: yes, i understood it. | 11:54 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| sergiusens | dholbach, hey, anything we can do about https://bugs.launchpad.net/snapcraft/+bug/1558296 ? | 12:02 |
| ubottu | Launchpad bug 1558296 in Ubuntu Developer Portal "snappy build-apps broken link to devel ref page" [Medium,Confirmed] | 12:02 |
| dholbach | sergiusens, I thought anyone of you would add their opinion to it? | 12:02 |
| sergiusens | dholbach, is it generated from one of our MD files? | 12:03 |
| sergiusens | kyrofa, is this still valid https://bugs.launchpad.net/snapcraft/+bug/1532515 ? | 12:04 |
| ubottu | Launchpad bug 1532515 in Snapcraft trunk "Copy plugin doesn't copy symlinks" [Low,In progress] | 12:04 |
| kyrofa | sergiusens, yes. I finally closed the PR as the discussion wasn't progressing | 12:04 |
| kyrofa | sergiusens, I think we have a good solution for it though. Just need to do it | 12:05 |
| kyrofa | sergiusens, oh wait | 12:05 |
| dholbach | sergiusens, https://github.com/ubuntu-core/snapcraft/blob/master/docs/intro.md | 12:06 |
| kyrofa | sergiusens, that may have been solved my the most recent copy plugin change | 12:07 |
| kyrofa | sergiusens, let me test real quick | 12:07 |
| sergiusens | kyrofa, yeah, that's why I ask; maybe a PR with a test is enough ;-) | 12:08 |
| sergiusens | dholbach, ic, thanks | 12:08 |
| kyrofa | sergiusens, yeah I haven't had my coffee yet | 12:09 |
| didrocks | hey kyrofa, sergiusens :) | 12:11 |
| sergiusens | hey | 12:11 |
| didrocks | hum, seems files: is still required? wasn't my argument good enough yesterday? | 12:12 |
| didrocks | (well, that can be enhanced later on, but I think there is a good use of having a consistent behavior by making it optional) | 12:13 |
| jdstrand | zyga: hi! did you say that the udev branch landed or it is ready to landed? I ask because, well, I wanted to take a look but I also wanted to make sure of a couple of things, like the former oem assign (from oem.go) was preserved and that the lenient apparmor rules were conditionally applied only when hardware is assigned | 12:21 |
| sergiusens | didrocks, I convince kyrofa to go the other way | 12:21 |
| zyga | jdstrand: it has landed | 12:21 |
| zyga | jdstrand: if you want to change it, go ahead | 12:21 |
| zyga | jdstrand: note that hw-assign is gone (as soon as we land install with --developer-mode) | 12:22 |
| zyga | jdstrand: so many things get simplified | 12:22 |
| zyga | jdstrand: I'm working on install support and auto connect | 12:22 |
| zyga | jdstrand: I'll ask you to review a small/boring branch that adds auto-connect flag to some interfaces | 12:23 |
| jdstrand | zyga: well... I don't think I'm the right person to implement oem assign (ie, where the gadget snap does assignments for things that match stuff like idVendor, etc, and the udev interface is going to need to add an apparmor snippet | 12:23 |
| zyga | jdstrand: I also created https://github.com/ubuntu-core/snappy/pull/785/files | 12:23 |
| zyga | jdstrand: oem assign -> post 16.04 | 12:23 |
| zyga | jdstrand: current oem assign is gone | 12:23 |
| zyga | jdstrand: kernel/gadget snap is specced for post 16.04 | 12:23 |
| jdstrand | zyga: oem assign is going to be needed for GA though, no? | 12:23 |
| zyga | jdstrand: yes | 12:24 |
| zyga | jdstrand: but perhaps as a different thing | 12:24 |
| jdstrand | ok, that's fine | 12:24 |
| zyga | jdstrand: I suspect it will be a way for the gadget snap to pre-connect stuff | 12:24 |
| jdstrand | zyga: but hardware assignment still won't work with what you landed unless you already realized you had to add general apparmor rules when applying udev rules | 12:24 |
| zyga | jdstrand: hw assign is removed too | 12:25 |
| zyga | jdstrand: the replacement is developer mode and working on a new interface | 12:25 |
| jdstrand | whatever its called doesn't matter | 12:25 |
| zyga | it's not abou the name, we remove the functionality entirely | 12:25 |
| jdstrand | the point I'm making is that what is using the udev backend won't work | 12:26 |
| zyga | so anything that used to be related to hw-assign is gone | 12:26 |
| jdstrand | because apparmor will continue to block it | 12:26 |
| zyga | ah, I see | 12:26 |
| zyga | I think we can ignore that and solve it with the first udev-using interface | 12:26 |
| zyga | jdstrand: this week will be filled with more removals | 12:27 |
| didrocks | sergiusens: mind if we discuss that during our standup? | 12:30 |
| didrocks | sergiusens: I really think this just makes it verbose for no good reason (but again, we can change it later on, as it would be backward compatible anyway) | 12:30 |
| jdstrand | zyga: ok, so it sounds like anything resemblinb hw-assign is gone forever, therefore you would never have a udev interface without a corresponding apparmor snippet. that makes sense (though it is very limiting while interfaces are being bootstrapped) | 12:31 |
| didrocks | sergiusens: or beforehand otherwise :) | 12:31 |
| zyga | yes | 12:31 |
| zyga | jdstrand: yes, I think that's exactly true | 12:31 |
| zyga | jdstrand: hence the change will happen with --developer mode | 12:31 |
| zyga | jdstrand: I think for that we should let the launcher not create a device cgroup | 12:31 |
| jdstrand | zyga: I don't understand what you mean by ghat | 12:31 |
| zyga | jdstrand: so "everything is allowed" | 12:31 |
| jdstrand | yeah, sure, that's fine | 12:32 |
| zyga | jdstrand: ah, sorry, yes this limits usability while interfaces are being boostrapped but our idea is to use developer mode as a replacement | 12:32 |
| zyga | jdstrand: so that in developer mode you can really access anything you like | 12:32 |
| zyga | jdstrand: and steer towards creating proper interfaces | 12:32 |
| jdstrand | cause cgroups don't log denials (it is just a DAC issue) and there is no complain mode | 12:32 |
| zyga | jdstrand: yes, that's true | 12:33 |
| zyga | jdstrand: I think it will be better than nothing still | 12:33 |
| jdstrand | what I'm saying is no cgroups in developer mode is just fine | 12:33 |
| zyga | jdstrand: and note that hw-assign can come back | 12:33 |
| zyga | jdstrand: as an interface | 12:33 |
| zyga | jdstrand: likely after 16.04 when hooks are back | 12:33 |
| zyga | jdstrand: (or some simple state can be kept) | 12:33 |
| jdstrand | well, hw-assign in some future interation of gadget assign for GA I suspect is going to have some interplay with the apparmor issue I just mentioned | 12:34 |
| zyga | jdstrand: (I'd like to createa dir-assign interface that lets users create slices of $HOME for specific needs) | 12:34 |
| jdstrand | s/of gadget/or gadget/ | 12:34 |
| zyga | jdstrand: (and hand those out to apps) | 12:34 |
| zyga | jdstrand: hw-assign is _gone_ even for GA | 12:34 |
| jdstrand | I understand that | 12:34 |
| zyga | jdstrand: for GA we'll work with interfaces and setting up auto-connections | 12:34 |
| jdstrand | you said "and note that hw-assign can come back" | 12:34 |
| zyga | jdstrand: so whatever issues are ahead will be solved in an uniform way, not specific to hw-assign replacement | 12:35 |
| zyga | jdstrand: I meant that the functionality can come back as a simple interface | 12:35 |
| jdstrand | I knew what you meant | 12:35 |
| zyga | jdstrand: and as you said we can then marry apparmor and udev | 12:35 |
| zyga | jdstrand: sorry, I'm confusing today :-) | 12:35 |
| zyga | jdstrand: I think we are good for 16.04 and we have a plan for a plan for GA | 12:36 |
| jdstrand | I'm saying that simple udev matching as happens with current oem assign that is presumably going to be a part of GA gadget assign will have to deal with the apparmor issue I mentioned. whatever some future hw-assign looks like could also depending on how it is implemented | 12:36 |
| jdstrand | anyway, this was meant to call out the issue that udev alone won't work | 12:37 |
| jdstrand | not be an argument or prolonged discussion :) | 12:37 |
| zyga | jdstrand: sorry I understand what you mean now | 12:37 |
| zyga | jdstrand: I think I've seen a variant of this while working on a i2c interface locally | 12:37 |
| jdstrand | yeah | 12:37 |
| zyga | jdstrand: where I also used two subsystems to get it to work (udev and apparmor) | 12:37 |
| jdstrand | cause things go hooping around in /sys/devices after they get the device in /dev | 12:38 |
| zyga | jdstrand: I think over time our snippet-based approach might evolve to make some things like that easier | 12:38 |
| jdstrand | hopping* | 12:38 |
| zyga | but that's something post 16.04 | 12:38 |
| sergiusens | didrocks, sure, the only reason I said no to it was because it made things harder to explain to people; did I mention I hate the copy plugin? :-) | 12:39 |
| jdstrand | so *if* hw-assign and oem-assign are gone, then is no issue (other than them being gone and not replced yet) | 12:39 |
| * sergiusens goes out to run some errands | 12:39 | |
| jdstrand | zyga: as for dir-assign-- yes, we totally need that for sdoc | 12:39 |
| didrocks | sergiusens: heh, yeah, you do :) however, with the current behavior and no filtering, depending on when you run snapcraft (after a first build or other parts are pulled), we may end up with other results | 12:39 |
| zyga | jdstrand: what is sdoc? | 12:39 |
| didrocks | sergiusens: anyway, yeah, if we change that later on, this will be backward compatible, so good :) | 12:40 |
| jdstrand | zyga: at one point we said there would be a home-hidden interface that you'd set a property on (or whatever the term is) the interface to specify the directory. is that now a general purpose dir-assign? | 12:42 |
| zyga | jdstrand: there was no bigger discussion on that that I'm aware of; dir-assign is just something I was thinking about as a cool and useful interface | 12:43 |
| zyga | jdstrand: as a way to let a snap consume HOME and produce slices of home as separate interfaces | 12:43 |
| zyga | jdstrand: and as a nice way to introduce more features (hook-based plugs/slots) | 12:44 |
| zyga | jdstrand: it has many parallels to device discovery but is easier to work with (not hardware) | 12:44 |
| jdstrand | ok, well as we decided last week, the security team would like to see branches to interfaces and changes to security policy whenever they are proposed | 12:45 |
| zyga | jdstrand: noted and understood | 12:45 |
| jdstrand | zyga: I look forward to the connecting stuff landing-- I'll let you work on it now | 12:46 |
| ogra_ | mvo_, you didnt merge all-snaps along the way to support the new adb in u-d-f ` | 12:47 |
| ogra_ | ? | 12:47 |
| mvo_ | ogra_: no, support for bulding core images is temporarly removed until the final format of kernel and gadget snap is decided upon. plus the model-assertions work is pending | 12:48 |
| ogra_ | you are aware that we need to SRU even livecd-rootfs after release day to have the changes for the snaps we build ? | 12:49 |
| * ogra_ would really like to have some kind of working state before release | 12:49 | |
| ogra_ | or do you expect it to be "all-done" before ? | 12:50 |
| shuduo | is there a workable example snap consuming docker just like old version owncloud snap? | 12:56 |
| ogra_ | hrm | 13:00 |
| ogra_ | ubuntu@localhost:~$ snap find | 13:00 |
| ogra_ | error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps?sources=store: dial unix /run/snapd.socket: connect: no such file or directory | 13:00 |
| ogra_ | (yesterdays ubuntu-core snap ... that used to work before) | 13:00 |
| ogra_ | seems like snapd isnt coming up on boot anymore | 13:06 |
| ogra_ | works after "systemctl start ubuntu-snappy.snapd" | 13:08 |
| ogra_ | mvo_, did you upload a new ubuntu-core to the store today ? | 13:18 |
| ogra_ | (seems whoever did that forgot armhf) | 13:19 |
| === chihchunl is now known as chihchun | ||
| === robert-ma_ is now known as robert-ma | ||
| === xnox_ is now known as xnox | ||
| === not_phunyguy is now known as phunyguy | ||
| === cprov_ is now known as cprov | ||
| === clemensv_ is now known as clemensv | ||
| === inaddy_ is now known as inaddy | ||
| shuduo | kyrofa: hello, do you know if there is a workable example snap consuming docker just like old version owncloud snap? I notice you are author of new owncloud snap but seems it does not consume docker. | 13:25 |
| kyrofa | shuduo, not that I know of. Indeed, the new ownCloud is native | 13:25 |
| ogra_ | yeah, that would just be a massive waste of resources :) | 13:25 |
| ogra_ | but i would assume docker still works the same ... so grabbing the old owncloud from 15.04 might be enough to find the docker bits you need in it | 13:26 |
| shuduo | kyrofa, ogra_ i have a customer use a close-source legacy software which run well with classic ubuntu 14.04. so seems only docker is solution to move to snappy. | 13:27 |
| shuduo | ogra_: old owncloud is designed to be built by "snappy build". | 13:27 |
| ogra_ | i'm bnot talking about the snappy side :) | 13:27 |
| kyrofa | ogra_, I actually imagine docker is broken due to interfaces | 13:27 |
| ogra_ | might be | 13:28 |
| === mjl_ is now known as mjl | ||
| ogra_ | but i assume the scripts you will need to set up the container and all that should still be the same | 13:28 |
| kyrofa | shuduo, what makes you say that docker is the only solution? Just because it's closed-source? | 13:29 |
| ogra_ | so starting with an unconfined snap that consumes docker should work ... and then you slowly port over to interfaces once they are 100% done | 13:29 |
| shuduo | kyrofa: yes, i think so. or maybe lxd works too | 13:29 |
| kyrofa | shuduo, depending on how it works in the confined environment there's nothing stopping you from still snapping it | 13:30 |
| shuduo | kyrofa: so i can use snapcraft to copy exist legacy binary with rootfs in place then run a script to run docker with a rootfs? | 13:32 |
| kyrofa | shuduo, you can use snapcraft to copy the binaries into a snap and potentially run _without_ docker | 13:32 |
| rajen | Hi, I am not able to build a snap due to download error. http://pastebin.ubuntu.com/15629597/ Any clue what is going on? | 13:33 |
| ogra_ | unless there are hardcoded versioned dependencies :) | 13:33 |
| shuduo | kyrofa: yes, if it has no dependencies. :) | 13:33 |
| ogra_ | rajen, what is build_snap.sh ? | 13:34 |
| kyrofa | shuduo, you can pull in .debs and whatnot and LD_LIBRARY_PATH will be setup for you-- not gonna work you think? | 13:34 |
| rajen | it is our wrapper around "snapcraft snap" | 13:34 |
| kyrofa | shuduo, I just think you'll run into some pain using docker in 16.04 right now is all. And I haven't heard anything that makes what you're discussing sound like it really needs it | 13:35 |
| ogra_ | sergiusens, ^^ do we use the hosts package lists ? | 13:35 |
| ogra_ | (looks like an "apt update" is missing there | 13:35 |
| ogra_ | ) | 13:35 |
| shuduo | kyrofa: it's a single prebuilt binary executive. not a deb. | 13:35 |
| kyrofa | shuduo, I mean for its dependencies | 13:35 |
| kyrofa | rajen, just gotta run again | 13:36 |
| kyrofa | rajen, it's a temporary archive error | 13:36 |
| rajen | I have been running it for the past 30min | 13:36 |
| sergiusens | ogra_, not yet | 13:36 |
| ogra_ | where does it get the "us." from ? | 13:36 |
| kyrofa | ogra_, geo location on the ip | 13:37 |
| ogra_ | inside snapcraft ? | 13:37 |
| kyrofa | ogra_, yep | 13:37 |
| ogra_ | wow .. any way to override that ? | 13:37 |
| kyrofa | ogra_, no, but we have a bug for it | 13:37 |
| ogra_ | heh | 13:37 |
| rajen | "/etc/apt/sources.list" also has it as us... | 13:38 |
| kyrofa | ogra_, actually because of people hitting exactly that problem-- archive errors that don't go away for a while | 13:38 |
| rajen | By the way even "apt update" fails. | 13:38 |
| kyrofa | rajen, which makes sense if they're using the same archive | 13:38 |
| ogra_ | kyrofa, yeah, i never use the german mirror on my dev machines (only on the stable ones) | 13:38 |
| ogra_ | simply because it is always a few hours behind | 13:39 |
| kyrofa | Yeah | 13:39 |
| rajen | So..do you want me to wait for few hours till all the archives are synced across geo's? | 13:39 |
| ogra_ | well, the hash sum mistmatch is happening if the publisher re-creates the sums on the server ... that usually takes only a few minutes | 13:40 |
| sergiusens | ogra_, kyrofa 2.8 will use your hosts sources by default | 13:40 |
| cjwatson | kyrofa,ogra_: proper fix for that should roll out today-ish | 13:46 |
| ogra_ | yay | 13:46 |
| beuno | ogra_, you are are #3 of the devs with most uploaded apps in the store (phone & snappy) | 14:01 |
| beuno | congrats! | 14:01 |
| ogra_ | oh, who are #1 and 2 ? | 14:02 |
| * ogra_ guesses popey is one of them :) | 14:02 | |
| ogra_ | beuno, and thanks :) | 14:03 |
| beuno | ogra_, if I tell you, I'd have to kill you. | 14:05 |
| ogra_ | lol | 14:05 |
| === shuduo is now known as shuduo-afk | ||
| dduffey | kyrofa, mvo_ so found the problem I was having building an image with ubuntu-device-flash, I was running it under a 16.04 lxc container and it didn't like that for some reason ... I ran it under a 16.04 KVM and the tool created an image | 14:30 |
| kyrofa | dduffey, ah, yeah I've run into that as well | 14:30 |
| dduffey | kyrofa, ubuntu-device-flash was updated today in ~mvo, so you'll need to update the md5 | 14:30 |
| kyrofa | dduffey, no idea why that happens | 14:31 |
| kyrofa | dduffey, ah, zyga ^^ for your ubuntu-image script | 14:31 |
| zyga | hmm | 14:31 |
| zyga | dduffey: can you open a pull request please? | 14:31 |
| dduffey | maybe lxc doesn't support kpartx / loopback devices and that is why it fails to run there? | 14:31 |
| === bregma_ is now known as bregma | ||
| zyga | mvo_: is the updated version the one without core support? | 14:32 |
| dduffey | zyga, not a dev ... just play one on TV :/ | 14:32 |
| mvo_ | zyga: yes | 14:32 |
| zyga | mvo_: ah, I see, thanks | 14:32 |
| zyga | dduffey: so I guess for now we should not update | 14:32 |
| zyga | dduffey: as that would entirely stop ubuntu-device-flash from working with snappy | 14:33 |
| mvo_ | zyga: so the package in the archive removed support. however the version on people.c.c still has it | 14:33 |
| zyga | mvo_: ah, | 14:33 |
| zyga | mvo_: has that one (on p.c.c) been updated as well? | 14:33 |
| zyga | mvo_: should I update ubuntu-image to use it? | 14:34 |
| mvo_ | zyga: yes, some minutes ago, I'm doing some final testing | 14:34 |
| mvo_ | zyga: yeah, I do some final testing now, but we need a new one because snappy is no longer compatible with the previous one (the removal of the developer from all paths) | 14:34 |
| === dpm is now known as dpm-afk | ||
| oparoz | Hello, what's the path to the installed snaps from classic? | 14:53 |
| === zyga_ is now known as zyga | ||
| zyga | oparoz: /snaps | 15:00 |
| ogra_ | schnaps ! | 15:01 |
| oparoz | zyga: It doesn't exist | 15:01 |
| oparoz | zyga: ls: cannot access '/snaps': No such file or directory | 15:01 |
| ogra_ | yeah, i think there is an lxc container on classice where /snaps is | 15:02 |
| oparoz | ogra_: Maybe it's a bug that /snaps isn't mounted, but is there a way to manually mount it in classic? | 15:03 |
| oparoz | ogra_: Like mounting /dev/loopXX | 15:03 |
| * ogra_ hanst dont anything with snappy on classic yet ... no idea, sorry | 15:04 | |
| ogra_ | *done | 15:04 |
| === kickinz1|eod is now known as kickinz1 | ||
| sergiusens | mvo_, or Chipaca` mind looking at bug #1566363 ? It looks unrelated to snapcraft but I'm not sure how this is possible at all | 15:06 |
| ubottu | bug 1566363 in Snapcraft "snapcraft deb touches snap-package systemd files" [Undecided,New] https://launchpad.net/bugs/1566363 | 15:06 |
| sergiusens | dholbach, maybe you can explain this? ^ | 15:08 |
| dholbach | wow, no idea | 15:08 |
| elopio | fgimenez: let's skip the meeting today. I wasn't productive yesterday, I'm running today :) | 15:14 |
| fgimenez | elopio, ok np, i've been revamping the snappy-jenkins' data-container branch, so much that now it doesn't even uses data containers :D | 15:15 |
| elopio | :D:D:D | 15:16 |
| mvo_ | sergiusens: this looks like chad has etckeeper running? | 15:16 |
| fgimenez | elopio, this volume https://github.com/ubuntu-core/jenkins-ubuntu/blob/master/Dockerfile#L16 is enough for the purposes of the branch, it was there all the time | 15:16 |
| mvo_ | sergiusens: it gets called automatically when apt runs dpkg via a apt/dpkg integration hook | 15:16 |
| mvo_ | sergiusens: DPkg::Post-Invoke or Pre-Invoke | 15:17 |
| fgimenez | elopio, anyway i've taken the opportunity to write the backup/restore scripts and the needed code to allow the configuration from the image to overwrite the files from the instance | 15:18 |
| fgimenez | elopio, with this in place we only need the secrets branch, i hope that we'll redeploy tomorrow | 15:18 |
| fgimenez | elopio, today i'll try to finish the practitest requirements, with the previous changes it won't take too long | 15:20 |
| elopio | fgimenez: +1. sounds great. | 15:21 |
| sergiusens | mvo_, thanks | 15:22 |
| didrocks | sergiusens: waow, the bot is more advanced that I was expecting! (j/k) | 15:26 |
| morphis_ | sergiusens: was there a reason why snapcraft run was removed? | 15:38 |
| sergiusens | morphis_, because `snappy try` was supposed to happen | 15:40 |
| morphis_ | sergiusens: which didn't? | 15:41 |
| ogra_ | morphis_, as usual :P | 15:44 |
| ogra_ | but it will :) | 15:44 |
| morphis_ | ogra_, sergiusens: I see :-) | 15:44 |
| morphis_ | ogra_: as usual :-) | 15:44 |
| ogra_ | :) | 15:44 |
| qengho | sergiusens: sorry about that bug report. | 16:01 |
| sergiusens | no worries | 16:02 |
| rajen | Hi folks, I observed in latest ubuntu-core image that psuedo terminal behavior has changed. Inside our snap app we do an open /dev/ptmx and it in turn creates a /dev/pts/0 But in the latest image, I don't see the /dev/pts/0 file. Any clue what has changed in recent times. | 16:14 |
| === kickinz1 is now known as kickinz1|eod | ||
| zyga | rajen: AFAIR that's been changed in ubuntu-core-launcher | 16:33 |
| zyga | rajen: more security, I don't know | 16:33 |
| zyga | rajen: ask jdstrand | 16:33 |
| rajen | okay will check with jdstrand | 16:34 |
| === dpm-afk is now known as dpm | ||
| nessita | elopio, hi! you around? | 17:39 |
| oparoz | Is there a plugin which allows downloading a list of files from various sources? I don't want to have to create a part for each file | 17:42 |
| elopio | nessita: hello! | 17:45 |
| nessita | elopio, hi! I was chasing you for getting a green light on the latest changes we did for summary/description metadata field in the package index | 17:47 |
| elopio | nessita: let me finish a couple of tasks, and I'll try uploads to staging. ~30 mins. | 17:48 |
| nessita | elopio, great, thank you! | 17:48 |
| zyga | oparoz: can you just download a tarball? | 17:54 |
| zyga | oparoz: or stick those files into a git repo? | 17:54 |
| oparoz | zyga: Not really, it's apps coming from various locations and I don't want to have to start maintaining a repo just to aggregate those apps | 17:56 |
| zyga | oparoz: when you say apps, what do you mean exactly? | 17:56 |
| oparoz | zyga: It looks like I need to write a go or pything plugin to do that, but I'm wondering if there isn't a use case here | 17:56 |
| oparoz | zyga: I'm talking about apps published here per example: https://apps.owncloud.com/ | 17:56 |
| jdstrand | I talked to rajen in privmsg but will respond here for others | 17:56 |
| jdstrand | this is a result of old-security/security-template going away and not being able to set confined | 17:57 |
| jdstrand | unconfined* | 17:57 |
| zyga | oparoz: how would those apps be consumed by users? as a part of an owncloud snap or as separate snaps? | 17:57 |
| jdstrand | so the default policy is being applied, which currently doesn't allow /dev/ptmx | 17:57 |
| zyga | jdstrand: thanks for doing this | 17:58 |
| jdstrand | once all the interfaces stuff lands, I have some tweaks to policy that are queued up | 17:58 |
| jdstrand | one is allowing /dev/ptmx by default now that we have a devpts newinstance and it is safe to do so | 17:58 |
| zyga | jdstrand: you can make modifications to the security right now, interfaces/ is stable for 16 IMHO | 17:58 |
| zyga | jdstrand: (except for more interfaces and misc changes to repo.go) | 17:59 |
| jdstrand | zyga: it isn't enforcing yet is it or did that land today? | 17:59 |
| oparoz | zyga: As part of the ownCloud snap. The ownCloud git tree comes with a default set, but I'd like to extend that set by downloading some apps from the app store when building the snap instead of writting a script which will download everything at install time | 17:59 |
| zyga | jdstrand: it's not live yet, no, I'm still trying to get to a patchset that will be accepted | 17:59 |
| zyga | jdstrand: plus mvo's branch hasn't landed so I'm also waiting for that | 17:59 |
| zyga | oparoz: hmm | 17:59 |
| zyga | oparoz: I'd do a custom plugin for now | 17:59 |
| zyga | oparoz: to see that it works | 18:00 |
| oparoz | zyga: That must affect other web apps which come with an app store as well | 18:00 |
| jdstrand | ok. well I have a number of things I'm working on, but thanks for the heads up on me being unblocked to land stuff like that | 18:00 |
| zyga | oparoz: when you have more experience with how it looks like we can think about what the next step is | 18:00 |
| oparoz | zyga: Well, I know what it looks like since that's how it's done in the official VM already. I'm just trying to translate that into the Snappy world, but was surprised to see that source wasn't an array | 18:02 |
| oparoz | zyga: It's simply, download, unzip and let the install script move these to the correct location at install time | 18:02 |
| zyga | oparoz: I'd be surprised if it was | 18:02 |
| zyga | oparoz: in any case, I'd suggest starting with a plugin | 18:03 |
| zyga | oparoz: and a bunch of parts | 18:03 |
| oparoz | zyga, maybe a simple makefile will do | 18:05 |
| zyga | oparoz: good luck | 18:06 |
| oparoz | :) | 18:07 |
| elopio | nessita: is staging alright? I'm getting "Remote end closed connection without response" when I run the upload test. | 18:27 |
| elopio | nessita: nevermind, I uploaded it fine now. | 18:30 |
| nessita | elopio, ack! this particular test is about getting the right metadata from the package index | 18:34 |
| nessita | elopio, so would that be covered by your tests? | 18:37 |
| elopio | nessita: not on the previous one. I'm trying now to install the snap I uploaded, but snappy is not cooperating. | 18:38 |
| nessita | elopio, any error I can help with? | 18:40 |
| elopio | nessita: yes, I'm pasting it... | 18:40 |
| elopio | nessita: https://paste.ubuntu.com/15636132/ | 18:41 |
| elopio | I see basic.snappy-test in the index. Do you know of something I might be missing? | 18:42 |
| nessita | looking | 18:45 |
| nessita | elopio, so the snap is there and I can download it, see https://search.apps.staging.ubuntu.com/api/v1/package/basic.snappy-test | 18:47 |
| nessita | elopio, is available only on amd64, is that the arch you are using? | 18:47 |
| elopio | nessita: yes, I can do that too. And yes, amd64. | 18:48 |
| nessita | elopio, there seems to be something in the snap code that can not completes the operation. Have any more information? | 18:49 |
| nessita | elopio, also, the main thing I needed QAd is that there is a new summary field, and the description field no longer has the summary (ex tagline) prepended | 18:49 |
| elopio | nessita: I'm looking at the code. https://github.com/ubuntu-core/snappy/blob/master/store/snap_remote_repo.go#L261 | 18:49 |
| elopio | nessita: I can see that on https://search.apps.staging.ubuntu.com/api/v1/package/basic.snappy-test | 18:50 |
| elopio | everything looks good on the cpi side. I can't install, but that might not be your fault. | 18:51 |
| nessita | elopio, right, if you try again, does it work? | 18:51 |
| * sergiusens is happy to know that the snapcraft side of the work is at least on track | 18:51 | |
| elopio | nessita: nop. I can install hello-world using staging, so that makes me a little uneasy. | 18:52 |
| elopio | still, as so many things are in flux and will be changing soon, I don't worry too much about this. A deploy of this summary field to production seems a step forward. | 18:53 |
| elopio | um, hello-world is not in the staging index, so it's likely not using this env var. | 18:56 |
| nessita | elopio, oh, so is trying to use prod? | 18:57 |
| elopio | nessita: ah, got it. It's just my fault, I was passing the env var on the wrong side of sudo. I installed it. | 19:00 |
| nessita | oh, great news! | 19:00 |
| elopio | nessita: so the install works. I have no way to show the summary because snap find is not working atm, but if anything is wrong there it should be fixed on the snappy side. | 19:01 |
| elopio | nessita: so go for it, let me reply to the list. | 19:01 |
| nessita | elopio, excellent, thank you | 19:01 |
| elopio | sergiusens: is the summary going to be added to snapcraft.yaml ? | 19:02 |
| elopio | oh, no, it's there already. | 19:02 |
| nessita | elopio, is there already! | 19:02 |
| nessita | elopio, and the store is parsing and using it | 19:03 |
| elopio | nessita: I had to manually fill it when I hit publish. | 19:03 |
| nessita | elopio, yeah, we are deploying that :-) | 19:03 |
| elopio | nessita: on staging. | 19:03 |
| nessita | elopio, was this a new package, or new version for existing package? | 19:04 |
| elopio | nessita: a new version for an existing package. | 19:04 |
| nessita | elopio, right, for this I followed the existing code, where new uploads do not change existing metadata for a package | 19:05 |
| elopio | nessita: ok, I don't know what to expect there. Now that I'm here, let me do a new upload to confirm it fills the summary. | 19:06 |
| nessita | elopio, a new package you meant, right? | 19:06 |
| nessita | new upload, in the store terminology, is a new version for an existing package | 19:06 |
| elopio | nessita: yes, that's what I meant, new package. | 19:07 |
| nessita | great :-) | 19:08 |
| elopio | nessita: +1. | 19:11 |
| nessita | elopio, thanks! | 19:12 |
| elopio | thanks to you. | 19:19 |
| sergiusens | elopio, it already is, isn't it? | 19:26 |
| code1o6 | sergiusens, do you know Manik Taneja? he is reviewing my snappy app for permissions. Do you know his nic IRC? | 19:27 |
| code1o6 | sergiusens, *nick | 19:28 |
| JamieBennett | code1o6 its manik | 19:30 |
| jdstrand | tyhicks: fyi, lp:~jdstrand/ubuntu-core-launcher/fix-udev-for-1604 | 19:32 |
| jdstrand | tyhicks: I'm moving to preparing the MP for seccomp arg filtering next | 19:33 |
| tyhicks | jdstrand: I saw that but I think it is going to be hard for me to get to it today - what kind of timelines are you needing for that review? | 19:33 |
| jdstrand | it doesn't have to be today | 19:33 |
| sergiusens | code1o6, what JamieBennett said | 19:33 |
| code1o6 | JamieBennett, sergiusens thanks | 19:33 |
| jdstrand | tyhicks: but trying to get these launcher changes done and into release so I can work on developer mode | 19:33 |
| tyhicks | ok | 19:34 |
| ogra_ | code1o6: i think he is traveling today | 19:35 |
| JamieBennett | ogra_, yeah, he is | 19:35 |
| code1o6 | ogra_, thanks | 19:37 |
| code1o6 | ogra_, JamieBennett , do you what timezone he is in? | 19:37 |
| JamieBennett | code1o6, Pacific | 19:39 |
| JamieBennett | *usually* | 19:39 |
| JamieBennett | no idea where he is travelling to atm | 19:39 |
| elopio | sergiusens: yes, it's just not updated when a previous version of the package exists. | 20:00 |
| * elopio <- lunch | 20:23 | |
| qengho | I admire mksquashfs for being able to use 387.7% of my CPUs. | 20:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!