[02:07] <Chipaca> kgunn, kyrofa, snap is the new client, that just talks to the rest api; we're moving commands over to it
[02:08] <Chipaca> as they get feature-complete(ish) the old one is removed from snappy
[04:27] <wigleworm> Can anyone help with a question about snapcraft and "build packages"
[04:28] <wigleworm> I want to create a snap with lsusb and lspci. I think I would use "build packages" with snapcraft but I keet getting a "parts" error
[04:29] <wigleworm> btw I have not defined a "parts" section because I have no clue how to do that when all I want are packages
[04:29] <wigleworm> rather deb packages
[04:33] <wigleworm> I also read about using "stage-packages" but that makes even less sense to me given that I still have to have a "parts" section.
[04:54] <wigleworm> more clarification - I want to add the functionality of lsusb and lspci to snappy as its not installed. With that in mind, I am trying to build a snap that will install the two deb packages (and dependences) into the system so that I can run them from the command line
[07:45] <dholbach> good morning
[07:48] <didrocks> hey dholbach
[08:10] <dholbach> salut didrocks
[09:12] <noizer> morning
[09:41] <sergiusens> jdstrand, hey, if you have  a chance to look at, it would be great https://github.com/ubuntu-core/snapcraft/pull/360/files
[09:42] <sergiusens> it is in nagging mode so most commands run (except 2) will nag
[09:42] <sergiusens> this is where my creativity ends
[10:39] <zyga> ppisati: hey
[10:39] <zyga> ppisati: do you have a moment to talk about the raspberry pi kernel
[10:41] <ppisati> zyga: what's that
[10:42] <zyga> ppisati: I was trying to use video core specific modules and I found that we don't have them in our kernel
[10:42] <zyga> ppisati: specifically I was trying to use bits required to use the camera interface
[10:42] <ogra_> zyga, which ones specifically ?
[10:42] <ogra_> the camera ones should be there with the latest image
[10:43] <zyga> ogra_: oh? yesterday they were not
[10:43] <ogra_> hmm
[10:43] <zyga> ogra_: vcsm
[10:43] <ogra_> except ....
[10:43] <zyga> ogra_: and the lot
[10:43] <zyga> ogra_: I can make a proper list in a moment, just got my network back
[10:43] <ogra_> zyga, the modules are in the kernel, but there was a bump of the bootloader required to make them used ...
[10:43] <ogra_> i'm just wondering, i think i only updated it for 15.04
[10:43] <zyga> ogra_: ohhh, can you do it for 16.04 as well
[10:44] <ogra_> i'll try to find some time, no promises for today though
[10:44] <ppisati> zyga: how do you use the camera?
[10:44] <ppisati> zyga: because
[10:44] <zyga> ogra_: everything that is needed for this: https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc
[10:44] <ppisati> zyga: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217
[10:44] <zyga> ppisati: not v4l2
[10:44] <ogra_> bug 1500755
[10:44] <zyga> ppisati: through the videocore apis
[10:44] <zyga> ppisati: the same way that raspian has this
[10:45] <ppisati> zyga: someone alreaby opened a bug for it, and it was just a matter of modifying config.txt etc
[10:45] <ogra_> ppisati, no, there was more
[10:45] <zyga> ppisati: using official rpi foundation libs (python wrappers for libbcm_host.so)
[10:45] <ogra_> my fault, i only updated the 15.04 oem snap
[10:45] <zyga> ogra_,ppisati: I'd argue that for a complete system we should also ship all those binary libs in our kernel snap
[10:45] <ogra_> on 16.04 the firmware is outdated
[10:45] <zyga> or each snap will need them as well
[10:46] <zyga> I haven't checked, maybe that part is actually open source so we can also build it
[10:46] <ogra_> zyga, i'm about to trigger a discussion on the ML foir that today
[10:46] <zyga> ogra_: fantastic, I'll chime in
[10:46] <ppisati> i'm not familiar with the videocore api
[10:46] <ogra_> (more about graphics drivers, but that should include these libs too)
[10:46] <zyga> ogra_: I'm trying to get all the pi2 specific hardware to work with interfaces
[10:46] <ppisati> zyga: what's the userland bin that you use to take picture?
[10:46] <ppisati> zyga: raspistill?
[10:47] <zyga> ppisati, ogra_: it's actually very closely related, lots of OpenMAX libs
[10:47] <zyga> ppisati: no, I was using the library directly, but it's all the same, raspistill is a good test for this
[10:47] <ppisati> zyga: ok then, can you take a look at this bug?
[10:47] <ogra_> ppisati, we will need the videocore bits (the opensource graphics driver) to actually have graphical output on the pi
[10:47] <zyga> ppisati: (through https://picamera.readthedocs.org/en/release-1.10/)
[10:47] <ppisati> zyga: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217
[10:47] <ogra_> it is for display as much as for video decoding and camera
[10:48] <ppisati> ogra_: uh ok, is that part of the rpi kernel or it is a separate repo?
[10:48] <zyga> ogra_: the display is my next item, as soon as the camera is working
[10:48] <ogra_> ppisati, i think the open one entered in 4.4
[10:48] <ppisati> ogra_: cool
[10:49] <zyga> ppisati, ogra_: is there anything actionable for me now?
[10:49] <ogra_> id libraspberrypi-bin (from your bug above) in the archive ?
[10:49] <ogra_> *is
[10:50] <zyga> ogra_: not in xenial
[10:50] <zyga> ogra_: looks like a raspbian package
[10:51] <ppisati> ogra_: we should make this guy push all his packages into the archive
[10:51] <ogra_> +1
[10:51] <ppisati> https://launchpad.net/~fo0bar/+archive/ubuntu/rpi2/
[10:51] <ppisati> ogra_: ^
[10:51] <ogra_> yeah, thats what a serch got me
[10:51] <ogra_> *search
[10:52] <ppisati> he's not here :(
[10:52] <ogra_> in #ubuntu-devel perhaps ?
[10:52] <ppisati> oh, ok, US, he's still sleeping... :)
[10:52] <ogra_> i know that nickname, so he is here occasionally i'm sure
[10:52] <ppisati> ok
[10:53] <ogra_> FSVO "here" .... perhaps not actually in #snappy
[10:53] <ogra_> not sure how easy/hard it is to push to the archive licensing wise though
[10:53] <zyga> ogra_: can we use the same bits that raspbian has?
[10:54] <ppisati> ogra_: good point, the license...
[10:54] <zyga> ogra_: broadcom licensing seems to say that it is okay to resistribute for broadcom hardware
[10:54] <ogra_> right, but it might have to go to restricted
[10:54] <zyga> (which is a bit weird but if they (raspbian) can then perhaps we can too)
[10:54] <ogra_> or multiverse
[10:54] <ogra_> not sure if there are binary bits in it
[10:55] <ogra_> zyga, we should ... but they need to work with our kernel and bootloader
[10:55] <ogra_> i.e. that needs QA
[10:56] <zyga> ogra_: can we ship the same kernel as the raspberry pi foundation?
[10:56] <zyga> ogra_: after all, isn't that what's snappy is all about?
[10:56] <zyga> (modulo ubuntu extra modules)
[10:58] <ysionneau> how can I get the core dump for a segfault on ubuntu snappy?
[10:59] <ogra_> make /proc/sys/kernel/core_pattern point to a file
[10:59] <ogra_> ubuntu@localhost:~$ cat /proc/sys/kernel/core_pattern
[10:59] <ogra_> |/bin/false
[11:00] <ogra_> you want to pipe to /tmp/core or some such ...
[11:00] <ogra_> instead of /bin/false
[11:00] <ogra_> (just make sure there is enough space for a whole RAM dump ;) )
[11:00] <ysionneau> hehe
[11:00] <ysionneau> ok I don't know what I messed up, but now it does not say "core dumped" any more
[11:01] <ogra_> damn, you fixed it :P
[11:01] <ysionneau> ahah no
[11:02] <ysionneau> it says "segmentation fault", but without the "(core dumped)"
[11:03] <ysionneau> afk lunch!
[11:06] <zyga> ppisati, ogra_: is there anything actionable for me now?
[11:58] <kyrofa> Good morning
[12:09] <zyga> kyrofa: hey
[12:09] <kyrofa> zyga, hey :)
[12:58]  * ogra_ grumbles about slow SD cards
[13:16] <mvo> dpm: hi, you will need to do a small tweak to your snaps: https://lists.ubuntu.com/archives/snappy-devel/2016-March/001516.html
[13:16] <ciastek> "hello-world failed to install: snappy package not found" while taking a tour. Known problem?
[13:16] <mvo> dpm: will probably land today
[13:16] <mvo> ciastek: the store has a problem right now
[13:17] <mvo> ciastek: should be fixed soon, people are working on it
[13:17] <ciastek> mvo: thank you! will try later.
[13:17] <dpm> mvo, thanks for the heads up, I had seen the e-mail, but wasn't sure the changes had landed. So I should basically change the snaps and re-upload them now?
[13:18] <mvo> ciastek: yeah, sorry, but we will try to fix it ASAP, its affecting our integration tests as well
[13:18] <mvo> dpm: not just yet, I'm waiting for our integration tests to work again (store issue) but I expect that I will land this today
[13:18] <ciastek> mvo: thank again :)
[13:18] <dpm> thanks mvo
[13:19] <mvo> dpm: I can ping you once it is uploaded
[13:19] <dpm> mvo, that'd be awesome, thanks!
[13:46] <zyga> mvo: I guess a pet project to build a functional version of apt repository tools where each change yields a new URL but all the old URLs contain the old state
[13:46] <zyga> mvo: do you know of anyone doing something like that?
[13:51] <kyrofa> dduffey, ping
[13:52] <noizer> Hi guys do someone know how to install the webdm on the rolling versions?
[13:53] <mvo> zyga: sounds like snapshots.debian.net
[13:53] <zyga> noizer: snap install webdm/edge perhaps
[13:53]  * zyga cannot remember the right syntax for channels)
[13:53] <mvo> zyga: ups, http://snapshot.debian.org/
[13:53] <ogra_> just webdm.canonical shoudl work
[13:54] <mvo> noizer: alias in the store is broken right now
[13:54] <mvo> people are investigating
[13:54] <zyga> mvo: looks kind of like what we want, do you know how that is implemented?
[13:55] <zyga> mvo: is that a cron job doing snapshots
[13:55] <zyga> mvo: or just a very smart archive that does this internally
[13:55] <zyga> mvo: and is never inconsistent
[13:55] <ysionneau> hmm
[13:56] <mvo> zyga: I don't know the detials, sorry
[13:56] <zyga> mvo: thanks
[13:56] <mvo> zyga: I suspect more than a cron job though
[13:56] <ysionneau> as soon as I change /proc/sys/kernel/core_pattern from |/bin/false to something else , I don't get the "core dumped" message anymore
[13:56] <ysionneau> for instance now I've set it to /tmp/dumps/core.%e.%p.%h.%t
[13:57] <kyrofa> Hey mvo, zyga: I'd like to talk about Snappy data. Both unversioned data and how we should solve the problem of storing data on a separate HD
[13:57] <zyga> kyrofa: hmm
[13:57] <kyrofa> (for 16.04)
[13:58] <zyga> kyrofa: (in a meeting now)
[13:58] <zyga> mvo: for new os snap please land pull 565 (go-flags sync)
[13:59] <kyrofa> zyga, ah no problem
[14:00] <kyrofa> mvo, zyga I just want to make sure we solve those issues before 16.04 comes out
[14:06] <zyga> kyrofa: I'm not very familiar with snap data and update changes
[14:07] <zyga> kyrofa: I'm interested in the 2nd hdd problem
[14:07] <zyga> kyrofa: can you tell me more
[14:07] <kyrofa> zyga, I saw some ML posts a while back about that, and there were some good ideas. I figured you'd be interest in that second one ;)
[14:08] <kyrofa> zyga, ownCloud has a specific use-case. They want to ship a device that is essentially a rpi2 with a western-digital HD for ownCloud data
[14:08] <noizer> mvo zyga So it is normal that the webdm not works now on 16.04
[14:08] <ogra_> noizer, "not works" ?
[14:09] <ogra_> can you be a bit more specific ?
[14:09] <zyga> kyrofa: I think the "easy" approach is to have an interface for a given /mnt/foo data and let owncloud just use that
[14:09] <kyrofa> zyga, but with a default partition layout it's not possible to even use that HD. You'd need to put the entire writable partition there
[14:09] <zyga> kyrofa: I suspect it's something post 16.04 though
[14:09] <noizer> when im surfing to it. it keeps loading
[14:09] <ogra_> kyrofa, we would first need support for that on the system level anyway
[14:09] <kyrofa> ogra_, what do you mean?
[14:10] <ogra_> kyrofa, some fstab entry to have a fixed mountpoint for example
[14:10] <ogra_> (one that you can use the "interfaces" system on)
[14:11] <kyrofa> ogra_, ah, okay
[14:11] <ppisati> ogra_: you said they moved the dtb in memory (latest rpi2 firmware), so what's the new location?
[14:11] <ogra_> you dont really want someone to be able to just re-plug a usb key on some mission critical device to steal data etc
[14:11] <ogra_> ppisati, no, that was dragonboard stuff :)
[14:11] <ogra_> rpi is fine and stayed where it was
[14:12] <ogra_> 0x100 should still work
[14:12] <ppisati> ogra_: uhm
[14:12] <kyrofa> ogra_, well... no way around that if you're using an external device-- at least owncloud supports encryption
[14:12] <ogra_> (i think ... my rpi is still in a suitcase, i'll have to check)
[14:12] <ppisati> ogra_: http://pastebin.ubuntu.com/15266835/
[14:13] <ogra_> kyrofa, well, i would like my device to actually alert me and to not accept another device witgh a different UUID for example
[14:13] <kyrofa> ogra_, can't UUIDs be set, though?
[14:13] <ogra_> as a low level security measure
[14:13] <ogra_> not atm
[14:14] <ogra_> mounting all happens by labels, the fstab is generated from the initrd
[14:14] <ogra_> thats fine for the internal filesystems ... but for externals i'd like some snappy config option where you can set a UUID to have it added to fstab with a specific mountpoint
[14:15] <ogra_> if you then replace the USB stick the app wont just start writing critical data to it
[14:15] <zyga> ogra_: you can just use the same uuid (clone it) and then booting is somewhat unreliable as far as being sure where you boot from
[14:15] <zyga> ogra_: but I totally agree about doing this with some more insinght as to how external media should be exposed
[14:15] <ogra_> zyga, sure, its just another stop gap
[14:16] <ogra_> indeed you can clone it ... and indeed it shoudl be encrypted :)
[14:16] <ogra_> but encryption isnt supported yet either
[14:16] <zyga> ogra_: and here I'd say that we should treat external media as something gadget snap can influence (down the line)
[14:16] <ogra_> so i dont think this is a topic for 16.04 release ...
[14:16] <zyga> ogra_: agreed
[14:17] <ogra_> it is a topic for 16.04 SRUs for sure though :)
[14:17] <ogra_> and we shoudl start planning for it after release day
[14:19] <kyrofa> ogra_, okay. So our recommended way of doing that is placing the writable label on the external?
[14:19] <ogra_> for now, yeah
[14:19] <ogra_> which essentially means you fully run from external in eth all-snaps world
[14:19] <ysionneau> hmm weird, if I sleep 20 & then kill -s SIGSEGV %1 , it creates a core dump, but not when I run my hello world which segfaults
[14:19] <ogra_> (the readonly snaps live on 7writable nowadays)
[14:20] <ogra_> *on /writable
[14:20] <ogra_> ysionneau, are you still running under qemu ?
[14:20] <ysionneau> yes
[14:20] <kyrofa> ogra_, would that be possible to automate in any way?
[14:20] <ogra_> might be a vm issue
[14:20] <ysionneau> the thing is, I trigger a kernel issue with my hello world
[14:21] <ogra_> kyrofa, not easily ... you could have a script that calls kpartx to pull the content from /writable and push it to a USB disk indeed
[14:21] <kyrofa> ogra_, zyga mvo if the external HD is a post-16.04 support issue, I guess we're just left with the unversioned data. That sounds a bit easier to solve, perhaps?
[14:21] <ysionneau> ogra_: http://pastebin.com/QNu0G3w4
[14:22] <kyrofa> ogra_, yeah I'll need to figure something out-- tough to have a shippable device when every device requires manual work
[14:23] <kyrofa> ogra_, I may be pinging you on that later, if that's okay
[14:23] <ogra_> sure
[14:29] <noizer> ogra_ got this error: "Error: cannot list snaps: cannot communicate with server: Get http://localhost/2.0/snaps?sources=local: dial unix /run/snapd.socket: connect: no such file or directory"  when he did this call: http://192.168.0.105:4200/api/v2/packages/?installed_only=true
[14:30] <ogra_> noizer, is that 16.04 ?
[14:30] <ogra_> (works here )
[14:30] <noizer> ogra_ yes
[14:33] <noizer> so on your 16.4 it works ogra_
[14:33] <kyrofa> Chipaca, you seemed to have some thoughts on the unversioned data stuff on the ML. Do you still think we can get that for 16.04?
[14:33] <ogra_> noizer, only tried on arm64, but yes, there it works
[14:33] <ogra_> (or at least did a few days ago, but there was no new webdm since)
[14:33] <noizer> hmm ok
[14:34] <ogra_> ppisati, hmm... there seems to be an issue on the dragonboard with /dev/urandom
[14:34] <ogra_> ubuntu@localhost:~/xenial-chroot$ lsb_release -cs
[14:34] <ogra_> Fatal Python error: Failed to read bytes from /dev/urandom
[14:34] <ogra_> Segmentation fault (core dumped)
[14:35] <ogra_> i can read from it a few times but then it doesnt work anymore and i have to reboot
[14:35] <ppisati> ogra_: /dev/urandom?
[14:36] <ogra_> ppisati, yeah, see the error
[14:36] <ppisati> ogra_: ah, i didn't see that
[14:36] <ogra_>  lsb_release -cs works for a while after fresh boot
[14:36] <ogra_> but at some point i start getting python errors like the above
[14:37] <ogra_> feels like there are only a few random bytes and once i used them up it starts failing ;)
[14:37] <ppisati> ogra_: what if you do a 'dd if=/dev/urandom of=/dev/null'?
[14:38] <ogra_> ubuntu@localhost:~$ dd if=/dev/urandom of=/dev/null
[14:38] <ogra_> 0+0 records in
[14:38] <ogra_> 0+0 records out
[14:38] <ogra_> 0 bytes (0 B) copied, 0.000768486 s, 0.0 kB/s
[14:38] <ogra_> nothing
[14:39] <jdstrand> dpm: hey-- I'd like to try your calculator snap on a unity7 desktop. are there instructions for what needs to be installed?
[14:39] <jdstrand> maybe that is a question for mvo ^
[14:41] <jdstrand> I feel like there was an email but I can't seem to find it
[14:41] <dpm> jdstrand, at the end of the the doc. Once snappy is enabled, then just 'sudo snappy install ubuntu-calculator-app'
[14:41] <jdstrand> ah, maybe that was it
[14:41] <jdstrand> ok, thanks
[14:41] <dpm> I can also paste the instructions when I'm off the phone
[14:41] <jdstrand> I'm there
[14:41] <dpm> cool
[14:41] <jdstrand> dpm: thanks!
[14:42] <jdstrand> ah, I grabbed ubuntu-snappy-cli but not ubuntu-snappy
[14:42] <jdstrand> yow
[14:42] <jdstrand> http://paste.ubuntu.com/15267034/
[14:43] <jdstrand> I'm glad I'm in a vm, I don't want my laptop's grub migrated :)
[14:43] <jdstrand> mvo: fyi, ^
[14:43] <jdstrand> (apt-get install ubuntu-snappy)
[14:43] <dpm> jdstrand, added some notes to the doc to install the calc and clock apps
[14:46] <jdstrand> heh
[14:46] <jdstrand> man, a 144M clock
[14:47] <jdstrand> I thought we were going to have a thick os snap...
[14:47] <jdstrand> anyhoo
[14:47] <jdstrand> thanks!
[14:48] <ogra_> thats just a prototype :)
[14:48] <ogra_> i'm actually surprised it is *only* 144M
[14:49] <ogra_> given it pulls in the whole of sdk-libs
[14:49] <jdstrand> well, with the calculator, there is another 141 ;)
[14:49] <ogra_> diskspace is cheap :P
[14:49] <jdstrand> apparently that is what people say :P
[14:49] <jdstrand> heheh
[14:49] <ogra_> (we should add that underneath the "linux for human beings" to the logo now ;) )
[14:49] <jdstrand> :)
[14:50] <jdstrand> pfft
[14:50] <jdstrand> I was wondering how it launched with no denials
[14:50] <jdstrand> unconfined template
[14:50] <ogra_> shiny eh ?
[14:50] <ogra_> :P
[14:50] <jdstrand> well, I was wondering who did the work for me :)
[14:51] <jdstrand> and now I know
[14:53]  * zyga solitcits reviews of https://github.com/ubuntu-core/snappy/pull/559 
[14:55] <jdstrand> zyga, niemeyer: we need to have a chat so we can nail down what needs to be done wrt old-security, moving to native interfaces and existing security interface names. can we scedule a hangout sometime this week?
[14:55]  * jdstrand adds several more items to trello card wrt snappy on classic
[14:56] <zyga> jdstrand: yep, let's do it
[14:56] <zyga> jdstrand: I started to implement old-security natively but gustavo asked me to postpone that till the full interface core is working
[14:56] <zyga> jdstrand: as for the hangout, just propose one
[14:57] <niemeyer> jdstrand: Yes, please!
[14:58] <niemeyer> zyga: Yes, there's little meaning in "porting" logic to a non-working mechanism :)
[14:58] <jdstrand> oh, and snaps on unity7 interfaces
[14:58] <jdstrand> ok, let me see if I can find something
[14:58] <niemeyer> jdstrand: We also need to decide whether we need a sprint in a few weeks or not
[14:59] <niemeyer> Imminently
[15:00] <dpm> jdstrand, and it's ~600MB when installed (clock or calc), but probably some trimming down can be done already
[15:01] <mvo> jdstrand: thanks, its a known bug
[15:02] <mvo> jdstrand: it won't actually do anything, grub-migrate is dead
[15:11] <ogra_> mvo, so the initrd build error is actually an issue with mkinitramfs ... seems it tries to copy the linker to a non-existing /lib64 dir
[15:12] <ogra_> i wonder where that comes from
[15:12] <ogra_> (no code that would do that in any of the initrd build scripts)
[15:12]  * davmor2 instantly blames that ogra_ bloke bound to be him ;)
[15:13] <davmor2> ogra_: see that driveby blaming there ;)
[15:22] <ogra_> mvo, so if i add set -x to the last initramfs hook that gets called i get this output ... http://paste.ubuntu.com/15267323/ ... note how it expands to searching for /lib64/ld-linux-aarch64.so.1 at the end before it exists non-zero
[15:23] <ogra_> i'm not sure where that lib64 comes from :(
[15:23] <mvo> ogra_: in a meeting
[15:23] <ogra_> ok
[15:23] <mvo> ogra_: will look after that
[15:23] <ogra_> i think we need infinity but he is out today
[15:25] <davmor2> ogra_: no you don't need infinity it'll just keep searching if you do that
[15:25] <ogra_> davmor2, canadian infinity is different
[15:34] <ogra_> hmm
[15:34] <ogra_> ubuntu@localhost:~/xenial-chroot$ ls /usr/share/initramfs-tools/hooks/|grep klibc
[15:34] <ogra_> klibc-utils
[15:34] <ogra_> klibc^i-t
[15:34] <ogra_> apw, ^^ any idea whats up with that klibc hook ?
[15:34] <ogra_> (update-initramfs complains about it)
[15:35] <ogra_> /usr/share/initramfs-tools/hooks/klibc^i-t ignored: not alphanumeric or '_' file
[15:35] <ogra_> looks like someone typoed somewhere
[15:36] <kyrofa> jdstrand, does either security-override read-paths or write-paths encompass execution, by any chance?
[15:36] <apw> yeah that it looks like there is a junk file in hooks
[15:36] <apw> is there a file with a tab in the name in there ?
[15:36] <ogra_> ubuntu@localhost:~/xenial-chroot$ ls /usr/share/initramfs-tools/hooks/
[15:36] <ogra_> busybox    fixrtc       fsck         klibc^i-t  resize  thermal             udev
[15:36] <ogra_> compcache  framebuffer  klibc-utils  kmod       resume  ubuntu-core-rootfs  zz-busybox-initramfs
[15:37] <ogra_> dosnt look like it
[15:37] <ogra_> all other files look normal
[15:37] <jdstrand> kyrofa: no
[15:38] <kyrofa> jdstrand, didn't think so. I have some software that wants to shell out to /sbin/ip
[15:38] <jdstrand> iirc, you need the network-admin cap
[15:38] <kyrofa> jdstrand, oh! That's covered by that eh? Nice
[15:38] <ogra_> hmm, funny ... in the source of initramfs-tools the klibc hook looks correct
[15:39] <ogra_> the arm64 binary definitely has it though
[15:40] <ogra_> apw, aha, klibc-utils adds a diversion ... i guess the typo is in there
[15:42] <ogra_> there we go
[15:42] <ogra_> https://launchpadlibrarian.net/237842216/klibc_2.0.4-7_2.0.4-8.diff.gz
[15:44] <ogra_> apw, seems like a debian bug we actually inherit
[15:45] <ogra_> (introduced by bwh)
[15:45] <apw> nice
[15:46] <ogra_> to bad that wont help with my issue though ... i just stumbled over it trying to get arm64 to behave when building initrds :/
[15:51] <ogra_> dholbach, anything to discuss today ?
[15:52] <dholbach> ogra_, sorry, in a separate meeting right now
[15:52] <dholbach> and no :-/
[15:53] <ogra_> lets skip then
[15:58] <kyrofa> kgunn, the beard! It's gone!
[15:58] <ogra_> O M G !
[16:02] <kgunn> :)
[16:03] <kgunn> wife didn't like it
[16:03] <jdstrand> mvo: do you have a moment now?
[16:03] <kyrofa> kgunn, aww, too bad
[16:04] <mvo> jdstrand: yes, HO? just send me the link via /msg
[16:17] <ogra_> grmbl
[16:21] <davmor2> kgunn: wise man say when wife happy home is happy too :)
[16:25] <mvo> jdstrand: you asked about unshare() in ubuntu-core-launcher, we do use unshare(CLONE_NEWNS) when setting up the slave mount namespace (main.c:301). will this potentially cause issues with apparmor?
[16:27] <noizer> How can i use the snappy ubuntu core REST API on the rolling version?
[16:35] <zyga> noizer: look at docs/rest.md
[16:35] <zyga> noizer: you just make http requests to an unix socket (not tcp/ip socket
[16:35] <zyga> noizer: for starters, cmd/snap is doing exactly that
[16:36] <zyga> mvo: can you please land https://github.com/ubuntu-core/snappy/pull/559 if you have a moment
[16:37] <mvo> zyga: *if*
[16:45] <zyga> mvo: yeah, I know what kind of day it is for you today
[16:56] <kyrofa> Hey ogra_ I know you disabled the resize for dragon, but I just flashed an rpi and it didn't resize on boot either
[17:04] <ogra_> kyrofa, oh ?
[17:05] <ogra_> anything in /dev/.initramfs ?
[17:05] <ogra_> there shoudl be logs
[17:05] <kyrofa> ogra_, no, that doesn't exist
[17:05] <wiggleworm> is there a history server somewhere - I asked a Q last night but then I closed the chat app and cannot see if there was a responce
[17:07] <kyrofa> wiggleworm, http://irclogs.ubuntu.com/2016/
[17:08] <dduffey> kyrofa, last night I copied over the build ... and I could see better what was happening
[17:09] <wiggleworm> thanks kyrofa
[17:09] <jdstrand> mvo: mount namespaces are not a problem. it is a file namespace that is the issue
[17:09] <dduffey> the old yaml was including dependencies like libglog the new yaml didn't
[17:09] <mvo> jdstrand: great, we are good then
[17:10] <kyrofa> dduffey, I think it all working now, but it seems the system is down?
[17:10] <jdstrand> mvo: we should be, yes. I'll be poking at this and I'll come to you if I notice anything issues
[17:10] <dduffey> let me check
[17:12] <wiggleworm> Can anyone help with a question about snapcraft and "build packages"? I want to create a snap with lsusb and lspci. I want to add the functionality of lsusb and lspci to snappy as its not installed. With that in mind, I am trying to build a snap that will install the two deb packages (and dependences) into the system so that I can run them from the command line. I think I would use "build packages" with
[17:12] <wiggleworm> snapcraft but I keet getting a "parts" error. I have not defined a "parts" section because I have no clue how to do that when all I want are the deb packages. I also read about using "stage-packages" but that makes even less sense to me given that I still have to have a "parts" section.
[17:12] <dduffey> kyrofa, you first have to ssh into 192.168.122.188 from the jumphost
[17:13] <dduffey> and then ssh into 192.168.10.35
[17:13] <mvo> jdstrand: thanks
[17:13] <kyrofa> Ahh, I misunderstood
[17:13]  * mvo -> dinner
[17:14] <ogra_> kyrofa, oh, sorry ... that should be /run/initramfs/resize-writable.log
[17:14] <ogra_> the /dev/.initramfs is what we used in the past
[17:15] <kyrofa> dduffey, all good here! I'll be testing for a bit now. Sorry about that, I just though "MAAS? Why do I care about MAAS? Okay, SSHing into snappy..." :P
[17:17] <dduffey> kyrofa, no problem ... I will be stepping in/out over the next hour and then I'll be out the rest of the day
[17:17] <kyrofa> dduffey, good deal, I just wanted in there, I'm set now
[17:28] <kyrofa> ogra_, the only thing in there is fsck-writable, and it contains http://pastebin.ubuntu.com/15268551/
[17:59] <kyrofa> sergiusens, you're killing the examples tests man. 6?
[18:01] <sergiusens> kyrofa, I didn't change anything that would trigger this failure though
[18:04] <kyrofa> sergiusens, haha, "Everything passed[...]marked build as failure"
[18:06] <mwb> good afternoon.  Anyone got a moment for a frustrated newbie?
[18:08] <mwb> I'm trying to get snappy-core running in VMware workstation using the OVA.  It boots fine and I've created the basic cloud-init iso - that works.  However, as soon as I try and modify user-data to add a user, or just add ssh-keys, it breaks and I can't log in on boot.
[18:24] <kyrofa> mwb, I'm sorry, I'm not sure there's much experience around here with OVA
[18:24] <kyrofa> mwb, kvm, virtualbox, we gotcha
[18:27] <ogra_> sergiusens, https://launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core/0.7.23 ... cross your fingers :)
[18:32] <ogra_> YIPIIIIEEE !!! it built
[18:33]  * ogra_ waits for armhf now 
[18:35] <kyrofa> ogra_, is it just me or is xenial dramatically faster than trusty on the rpi2?
[18:43] <ogra_> kyrofa, well, i guess the squashfs really helps for devices with slow SD cards
[18:44] <kyrofa> ogra_, no that's not it. Just compiling speed seems to be faster. Though it may have been the image I was using previously
[18:44] <ogra_> ah
[18:50] <ogra_> heh, so the generic initrd is 2.3MB big ...
[18:51] <ogra_> vs
[18:51] <ogra_> ubuntu@localhost:~$ ls -lh /boot/uboot/canonical-dragon-linux.canonical_4.2.0-2014-generic-dragon410c.snap/|grep initrd
[18:51] <ogra_> -rwxr-xr-x 1 root root 8.7M Feb 19 17:40 initrd.img
[18:54]  * ogra_ calls it a day ... 
[19:06] <sergiusens> ogra_, nice! Now I need to get my hands dirty :-P
[19:25] <kyrofa> jdstrand, trying to debug somewhat of a hacked snappy system, and u-c-l is giving me a "No such file or directory," with aa_change_onexec returning -1. Would that imply it can't find the profile, you think?
[19:27] <jdstrand> it would
[19:27] <jdstrand> do 'sudo aa-status' and see if the profile you expect is loaded
[19:28] <kyrofa> jdstrand, ah, kernel mod isn't loaded :P
[19:31] <jdstrand> kyrofa: oh, that is perhaps more than a 'somewhat hacked system' :P
[19:31] <kyrofa> jdstrand, *cough*
[19:31] <jdstrand> hehe
[19:43] <kyrofa> So let's say I make a kernel snap, with some extra modules in it. I then make a snap that relies on those modules being present/loaded. I then upload that snap to the store. Is there anything that prevents someone running a kernel on which that snap won't run from installing it?
[19:43] <kyrofa> Do we care about that?
[19:49] <wiggleworm> has anyone here created a snapcraft.yaml file to build usbutils or pciutils? If so can you point me to your file?
[20:02] <rajen> Hi there. Did anyone try a ruby application inside a snap app?
[20:09] <kyrofa> rajen, not yet-- what are you looking to do?
[20:10] <rajen> Our application has few scripts using ruby1.9.1
[20:11] <rajen> We are able to include ruby inside the snap app. However, by default 2.2 ruby is downloaded from the repos. Our swig modules are not yet ported to ruby2.2. I am looking for ways to include ruby1.9.1 inside my snap environment
[20:13] <kyrofa> rajen, build from source I say
[20:14] <kyrofa> rajen, ruby is great to build from source
[20:14] <rajen> Let me see how that goes.
[20:14] <rajen> thanks for the tip
[20:16] <kyrofa> rajen, sure thing. Make sure you include the packages you need though (openssl, etc.) or the build system will just skip it
[20:16] <kyrofa> (ruby's, I mean)
[20:16] <rajen> kyrofa, okay
[20:17] <zyga> rajen: just depend on ruby1.9
[20:17] <zyga> rajen: get it from the archive as any other package
[20:18] <kyrofa> zyga, ha! That might be easier
[20:18] <rajen> zyga, I tried that but I am using snapcraft and it doesn't seem to like when I give it as ruby1.9.1 as depends
[20:18] <kyrofa> Didn't realize that was still in xenial
[20:18] <zyga> ah
[20:18] <zyga> it's not
[20:18] <zyga> boo hoo
[20:18] <zyga> rajen: get a ppa with ruby 1.9
[20:18] <zyga> rajen: and use it as a support ppa for your package
[20:19] <zyga> rajen: you can probably backport one into xenial or just find a ppa where someone did that for you
[20:19] <rajen> zyga, few more info. I am not really familiar with ppa.
[20:19]  * kyrofa always builds ruby from source, even on production servers
[20:20] <rajen> Meanwhile I am trying to see if I can compile our swig modules with ruby2.2.0
[20:20] <rajen> That will be my first try.
[20:43] <sergiusens> kyrofa, so http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/179/testReport/junit/test_libpipeline/LibPipelineTestCase/test_libpipeline/ is erroring due to the same thing I fixed in pkg-config about the bad decode
[20:43] <kyrofa> sergiusens, grr
[20:46] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/362
[20:46] <sergiusens> there
[21:14] <sergiusens> kyrofa, for some reason the examples can't find build-packages
[21:15] <sergiusens> hmm, and I'm not seeing the adt tests anymore
[22:03] <robert_ancell> Does anyone know how to distinguish between a snap in the "removed" state that was installed from a store and one that was sideloaded?
[22:03] <robert_ancell> i.e. the "removed" state hides if the state would otherwise be "not installed" or (does not exist)
[22:04] <robert_ancell> It seems download_size is a possible check to see if it is available in the store, but not sure if that's reliable
[22:05] <robert_ancell> Chipaca, ^?
[22:07] <robert_ancell> There also seems to be the issue in what the version field means - if I have a snap in the "removed" state how do I know what version is available in the store? The version field will show the last installed version, which may have been sideloaded
[22:15] <rajen> Hi. Can someone point me to documentation where /tmp behavior in snappy is explained.
[22:16] <rajen> I need info on 16.04 implementation.
[22:37] <sergiusens> robert_ancell, I think it is just missing the assertions story
[22:37] <sergiusens> rajen, it is mounted under a new namespace for a running snap by the snap-launcher
[22:38] <sergiusens> jdstrand, does this make any sense to you https://github.com/ubuntu-core/snapcraft/pull/360 ?
[22:41] <rajen> sergiusens, In our application Snap, we have multiple commands. One central app will create bunch of files in /tmp/. Now the commands are trying to access the same /tmp folder that central app created. However, they all don't see the same tmp directory
[22:42] <beuno> rajen, right, /tmp is per snap
[22:42] <beuno> as they are confined
[22:43] <rajen> no I see that every time I run a user exposed command, a tmp file is created.
[22:45] <sergiusens> beuno, it is more per snap and app
[22:45] <rajen> yeah..that is what I observed.. per snap and app
[22:45] <sergiusens> jdstrand, is that the desired behavior? ^
[22:45] <rajen> But we want all our apps to use same tmp dir to share information
[22:45] <rajen> Is it possible?
[22:46] <sergiusens> rajen, I will wait for our security guy to say some words ^
[22:46] <sergiusens> my first response would be that that should be the case as beuno mentioned
[22:47] <sergiusens> but from how I think it is implemented now it is as I mentioned
[22:55] <jdstrand> the /tmp should be per snap. I believe it is a bug that it is per command
[23:00] <rajen> What about TMPDIR. Is it still valid to use it or will it be deprecated soon?
[23:04] <ogra_> wont be deprecated, no :)
[23:04] <ogra_> and as a workaround you could use a wrapper script to set it to your writable snap dir
[23:04] <ogra_> (or a subdir in there)
[23:05] <ogra_> sergiusens, ubuntu-core-generic-initrd seeded ... will be in tomorrows tarballs
[23:05] <ogra_> (i havent boot-tested it yet though, thats for tomorrow :P )
[23:06] <rajen> ogra_, Problem is that in our application C code we refer hard-coded  /tmp in a lot of places. I am trying to see if Snappy provides an automatic /tmp handling.
[23:06] <ogra_> well, as jdstrand said, it is supposed to be per snap so all your apps in the same snap package should theoretically see the same /tmp ... but there seems to be a bug
[23:07] <ogra_> if your apps dont support TMPDIR using it is indeed not a workaround :)
[23:09] <rajen> Yup there is a bug..
[23:09] <rajen> I can see random directories getting created in /tmp for each command access
[23:09] <rajen> It never stops..
[23:11] <rajen> root@localhost:~# ls /tmp/ | grep hello snap.0_hello-ruby.sideload_BezZyD snap.0_hello-ruby.sideload_OXHsLL snap.0_hello-ruby.sideload_mM7VIZ snap.0_hello-ruby.sideload_vSAWkF root@localhost:~# hello-ruby.hello hello root@localhost:~# ls /tmp/ | grep hello snap.0_hello-ruby.sideload_BezZyD snap.0_hello-ruby.sideload_FoOB3j snap.0_hello-ruby.sideload_OXHsLL snap.0_hello-ruby.sideload_mM7VIZ snap.0_hello-ruby.sideload_vSAWkF root@localho
[23:13] <lool> hi there
[23:13] <rajen> http://pastebin.com/vPryWH9V
[23:13] <lool> rajen: yes, each run will create a tmp dir
[23:13] <lool> I'm not sure who's supposed to clean them up
[23:14] <jdstrand> rajen: can you file a bug here: https://bugs.launchpad.net/snappy/+filebug
[23:14] <lool> rajen: basically running a command creates a throw away temp dir, and writes to /tmp are remapped to it
[23:15] <lool> jdstrand: ah I didn't know the design was supposed to be per-snap
[23:15] <rajen> All: Okay..so which version is correct?
[23:15] <jdstrand> I think it defeats the purpose of a tmp dir if it is per command/daemon
[23:16] <jdstrand> if the original design was per command, I think there should be a bug to revisit it
[23:16] <jdstrand> perhaps people didn't think through rajen's use case
[23:17] <jdstrand> but how I remember it is that we were setting TMPDIR to a directory that was per snap
[23:17] <jdstrand> becvause people hard-code /tmp, that was problematic
[23:17] <jdstrand> so the per-snap /tmp mount was devised
[23:18] <rajen> I seem to like jdstrand's philosophy. That is what I as a developer of heavy duty application would expect.
[23:18] <jdstrand> the proper implementation is create/mount it if it doesn't exist, then let it persist so other commands/daemons can mount the same dir
[23:18] <jdstrand> then clean up on reboot
[23:19] <jdstrand> well, it doesn't totally defeat the purpose of the /tmp dir if it is per command, but it does if you have a complex app and can't easily use SNAP_APP_DATA
[23:20] <zyga_> cd
[23:20] <zyga_> hmm, right
[23:21] <lool> jdstrand: yup
[23:21] <lool> this all makes sense
[23:21] <jdstrand> rajen: filing a bug will get the right people involved to decide on the path forward
[23:21] <lool> I agree it's a nicer design for traditional apps
[23:24] <rajen> okay let me file one
[23:31] <rajen> https://bugs.launchpad.net/snappy/+bug/1552458
[23:32] <rajen> here it is
[23:32] <sergiusens> kyrofa, is examples testing broken for you too?