| === zenlot_away is now known as zenlot | ||
| Chipaca | kgunn, kyrofa, snap is the new client, that just talks to the rest api; we're moving commands over to it | 02:07 |
|---|---|---|
| Chipaca | as they get feature-complete(ish) the old one is removed from snappy | 02:08 |
| wigleworm | Can anyone help with a question about snapcraft and "build packages" | 04:27 |
| 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:28 |
| 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:29 |
| 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:33 |
| 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 | 04:54 |
| dholbach | good morning | 07:45 |
| didrocks | hey dholbach | 07:48 |
| dholbach | salut didrocks | 08:10 |
| === willcooke_ is now known as willcooke | ||
| noizer | morning | 09:12 |
| 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:41 |
| sergiusens | it is in nagging mode so most commands run (except 2) will nag | 09:42 |
| sergiusens | this is where my creativity ends | 09:42 |
| zyga | ppisati: hey | 10:39 |
| zyga | ppisati: do you have a moment to talk about the raspberry pi kernel | 10:39 |
| ppisati | zyga: what's that | 10:41 |
| 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:42 |
| 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:43 |
| 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 |
| ubottu | Launchpad bug 1532217 in linux-raspi2 (Ubuntu) "Can't modprobe bcm2835-v4l2 to use RPi2 camera module" [Undecided,New] | 10:44 |
| zyga | ppisati: not v4l2 | 10:44 |
| ogra_ | bug 1500755 | 10:44 |
| ubottu | bug 1500755 in Snappy "bootloader firmware needs update to get vchiq working with 4.2" [High,Fix committed] https://launchpad.net/bugs/1500755 | 10:44 |
| zyga | ppisati: through the videocore apis | 10:44 |
| zyga | ppisati: the same way that raspian has this | 10:44 |
| 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:45 |
| 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:46 |
| 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 |
| ubottu | Launchpad bug 1532217 in linux-raspi2 (Ubuntu) "Can't modprobe bcm2835-v4l2 to use RPi2 camera module" [Undecided,New] | 10:47 |
| ogra_ | it is for display as much as for video decoding and camera | 10:47 |
| 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:48 |
| 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:49 |
| zyga | ogra_: not in xenial | 10:50 |
| zyga | ogra_: looks like a raspbian package | 10:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| ogra_ | zyga, we should ... but they need to work with our kernel and bootloader | 10:55 |
| ogra_ | i.e. that needs QA | 10:55 |
| 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:56 |
| ysionneau | how can I get the core dump for a segfault on ubuntu snappy? | 10:58 |
| 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 | 10:59 |
| 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:00 |
| ogra_ | damn, you fixed it :P | 11:01 |
| ysionneau | ahah no | 11:01 |
| ysionneau | it says "segmentation fault", but without the "(core dumped)" | 11:02 |
| ysionneau | afk lunch! | 11:03 |
| zyga | ppisati, ogra_: is there anything actionable for me now? | 11:06 |
| kyrofa | Good morning | 11:58 |
| zyga | kyrofa: hey | 12:09 |
| kyrofa | zyga, hey :) | 12:09 |
| * ogra_ grumbles about slow SD cards | 12:58 | |
| 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:16 |
| 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:17 |
| 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:18 |
| mvo | dpm: I can ping you once it is uploaded | 13:19 |
| dpm | mvo, that'd be awesome, thanks! | 13:19 |
| 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:46 |
| kyrofa | dduffey, ping | 13:51 |
| noizer | Hi guys do someone know how to install the webdm on the rolling versions? | 13:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| zyga | kyrofa: (in a meeting now) | 13:58 |
| zyga | mvo: for new os snap please land pull 565 (go-flags sync) | 13:58 |
| kyrofa | zyga, ah no problem | 13:59 |
| kyrofa | mvo, zyga I just want to make sure we solve those issues before 16.04 comes out | 14:00 |
| zyga | kyrofa: I'm not very familiar with snap data and update changes | 14:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:19 |
| 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:20 |
| 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:21 |
| kyrofa | ogra_, yeah I'll need to figure something out-- tough to have a shippable device when every device requires manual work | 14:22 |
| kyrofa | ogra_, I may be pinging you on that later, if that's okay | 14:23 |
| ogra_ | sure | 14:23 |
| 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:29 |
| ogra_ | noizer, is that 16.04 ? | 14:30 |
| ogra_ | (works here ) | 14:30 |
| noizer | ogra_ yes | 14:30 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| jdstrand | ah, I grabbed ubuntu-snappy-cli but not ubuntu-snappy | 14:42 |
| jdstrand | yow | 14:42 |
| jdstrand | http://paste.ubuntu.com/15267034/ | 14:42 |
| 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:43 |
| jdstrand | heh | 14:46 |
| jdstrand | man, a 144M clock | 14:46 |
| jdstrand | I thought we were going to have a thick os snap... | 14:47 |
| jdstrand | anyhoo | 14:47 |
| jdstrand | thanks! | 14:47 |
| ogra_ | thats just a prototype :) | 14:48 |
| ogra_ | i'm actually surprised it is *only* 144M | 14:48 |
| 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:49 |
| 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:50 |
| jdstrand | and now I know | 14:51 |
| * zyga solitcits reviews of https://github.com/ubuntu-core/snappy/pull/559 | 14:53 | |
| 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:55 | |
| 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:56 |
| niemeyer | jdstrand: Yes, please! | 14:57 |
| 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:58 |
| niemeyer | Imminently | 14:59 |
| dpm | jdstrand, and it's ~600MB when installed (clock or calc), but probably some trimming down can be done already | 15:00 |
| mvo | jdstrand: thanks, its a known bug | 15:01 |
| mvo | jdstrand: it won't actually do anything, grub-migrate is dead | 15:02 |
| 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:11 |
| 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:12 | |
| davmor2 | ogra_: see that driveby blaming there ;) | 15:13 |
| 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:22 |
| 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:23 |
| 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:25 |
| 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:34 |
| ogra_ | /usr/share/initramfs-tools/hooks/klibc^i-t ignored: not alphanumeric or '_' file | 15:35 |
| ogra_ | looks like someone typoed somewhere | 15:35 |
| 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:36 |
| ogra_ | dosnt look like it | 15:37 |
| ogra_ | all other files look normal | 15:37 |
| jdstrand | kyrofa: no | 15:37 |
| 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:38 |
| ogra_ | the arm64 binary definitely has it though | 15:39 |
| ogra_ | apw, aha, klibc-utils adds a diversion ... i guess the typo is in there | 15:40 |
| ogra_ | there we go | 15:42 |
| ogra_ | https://launchpadlibrarian.net/237842216/klibc_2.0.4-7_2.0.4-8.diff.gz | 15:42 |
| ogra_ | apw, seems like a debian bug we actually inherit | 15:44 |
| ogra_ | (introduced by bwh) | 15:45 |
| apw | nice | 15:45 |
| 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:46 |
| ogra_ | dholbach, anything to discuss today ? | 15:51 |
| dholbach | ogra_, sorry, in a separate meeting right now | 15:52 |
| dholbach | and no :-/ | 15:52 |
| ogra_ | lets skip then | 15:53 |
| kyrofa | kgunn, the beard! It's gone! | 15:58 |
| ogra_ | O M G ! | 15:58 |
| kgunn | :) | 16:02 |
| kgunn | wife didn't like it | 16:03 |
| jdstrand | mvo: do you have a moment now? | 16:03 |
| kyrofa | kgunn, aww, too bad | 16:03 |
| mvo | jdstrand: yes, HO? just send me the link via /msg | 16:04 |
| === FourDollars_ is now known as FourDollars | ||
| ogra_ | grmbl | 16:17 |
| davmor2 | kgunn: wise man say when wife happy home is happy too :) | 16:21 |
| 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:25 |
| noizer | How can i use the snappy ubuntu core REST API on the rolling version? | 16:27 |
| 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:35 |
| zyga | mvo: can you please land https://github.com/ubuntu-core/snappy/pull/559 if you have a moment | 16:36 |
| mvo | zyga: *if* | 16:37 |
| zyga | mvo: yeah, I know what kind of day it is for you today | 16:45 |
| 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 | 16:56 |
| ogra_ | kyrofa, oh ? | 17:04 |
| 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:05 |
| kyrofa | wiggleworm, http://irclogs.ubuntu.com/2016/ | 17:07 |
| dduffey | kyrofa, last night I copied over the build ... and I could see better what was happening | 17:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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:13 | |
| 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:14 |
| 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:15 |
| 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:17 |
| kyrofa | ogra_, the only thing in there is fsck-writable, and it contains http://pastebin.ubuntu.com/15268551/ | 17:28 |
| kyrofa | sergiusens, you're killing the examples tests man. 6? | 17:59 |
| sergiusens | kyrofa, I didn't change anything that would trigger this failure though | 18:01 |
| kyrofa | sergiusens, haha, "Everything passed[...]marked build as failure" | 18:04 |
| mwb | good afternoon. Anyone got a moment for a frustrated newbie? | 18:06 |
| 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:08 |
| 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:24 |
| ogra_ | sergiusens, https://launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core/0.7.23 ... cross your fingers :) | 18:27 |
| ogra_ | YIPIIIIEEE !!! it built | 18:32 |
| * ogra_ waits for armhf now | 18:33 | |
| kyrofa | ogra_, is it just me or is xenial dramatically faster than trusty on the rpi2? | 18:35 |
| ogra_ | kyrofa, well, i guess the squashfs really helps for devices with slow SD cards | 18:43 |
| 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:44 |
| ogra_ | heh, so the generic initrd is 2.3MB big ... | 18:50 |
| 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:51 |
| * ogra_ calls it a day ... | 18:54 | |
| sergiusens | ogra_, nice! Now I need to get my hands dirty :-P | 19:06 |
| 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:25 |
| jdstrand | it would | 19:27 |
| jdstrand | do 'sudo aa-status' and see if the profile you expect is loaded | 19:27 |
| kyrofa | jdstrand, ah, kernel mod isn't loaded :P | 19:28 |
| jdstrand | kyrofa: oh, that is perhaps more than a 'somewhat hacked system' :P | 19:31 |
| kyrofa | jdstrand, *cough* | 19:31 |
| jdstrand | hehe | 19:31 |
| 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:43 |
| wiggleworm | has anyone here created a snapcraft.yaml file to build usbutils or pciutils? If so can you point me to your file? | 19:49 |
| rajen | Hi there. Did anyone try a ruby application inside a snap app? | 20:02 |
| kyrofa | rajen, not yet-- what are you looking to do? | 20:09 |
| rajen | Our application has few scripts using ruby1.9.1 | 20:10 |
| 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:11 |
| kyrofa | rajen, build from source I say | 20:13 |
| 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:14 |
| 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:16 |
| zyga | rajen: just depend on ruby1.9 | 20:17 |
| zyga | rajen: get it from the archive as any other package | 20:17 |
| 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:18 |
| 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:19 | |
| 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:20 |
| 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:43 |
| sergiusens | kyrofa, https://github.com/ubuntu-core/snapcraft/pull/362 | 20:46 |
| sergiusens | there | 20:46 |
| sergiusens | kyrofa, for some reason the examples can't find build-packages | 21:14 |
| sergiusens | hmm, and I'm not seeing the adt tests anymore | 21:15 |
| === utlemmin` is now known as utlemming | ||
| 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:03 |
| 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:04 |
| robert_ancell | Chipaca, ^? | 22:05 |
| 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:07 |
| rajen | Hi. Can someone point me to documentation where /tmp behavior in snappy is explained. | 22:15 |
| rajen | I need info on 16.04 implementation. | 22:16 |
| 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:37 |
| sergiusens | jdstrand, does this make any sense to you https://github.com/ubuntu-core/snapcraft/pull/360 ? | 22:38 |
| 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:41 |
| beuno | rajen, right, /tmp is per snap | 22:42 |
| beuno | as they are confined | 22:42 |
| rajen | no I see that every time I run a user exposed command, a tmp file is created. | 22:43 |
| 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:45 |
| 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:46 |
| sergiusens | but from how I think it is implemented now it is as I mentioned | 22:47 |
| jdstrand | the /tmp should be per snap. I believe it is a bug that it is per command | 22:55 |
| rajen | What about TMPDIR. Is it still valid to use it or will it be deprecated soon? | 23:00 |
| 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:04 |
| 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:05 |
| 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:06 |
| ogra_ | if your apps dont support TMPDIR using it is indeed not a workaround :) | 23:07 |
| 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:09 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| zyga_ | cd | 23:20 |
| zyga_ | hmm, right | 23:20 |
| 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:21 |
| rajen | okay let me file one | 23:24 |
| === zenlot_away is now known as zenlot | ||
| rajen | https://bugs.launchpad.net/snappy/+bug/1552458 | 23:31 |
| ubottu | Launchpad bug 1552458 in Snappy "Sharing tmp directory across multiple commands in a snap app" [Undecided,New] | 23:31 |
| rajen | here it is | 23:32 |
| sergiusens | kyrofa, is examples testing broken for you too? | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!