=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [06:15] Morning! [06:15] Some might be interested on https://www.indiegogo.com/projects/erle-spider-the-ubuntu-drone-with-legs. [06:40] good morning [07:05] good morning [07:38] https://code.launchpad.net/~dholbach/snapcraft/1491303/+merge/270363 [07:56] mvo_, hmm, vivid images stopped building, seems the ubuntu-snappy source doesnt build the ubuntu-snappy binary anymore [07:57] resulting in: [07:57] The following packages have unmet dependencies: [07:57] ubuntu-snappy : Depends: ubuntu-snappy-cli (= 1.0.1-1+467~ubuntu15.04.1) but it is not going to be installed [07:57] E: Unable to correct problems, you have held broken packages. [07:57] P: Begin unmounting filesystems... [07:59] oh, failed on amd64 ... [08:00] dh_install -O--buildsystem=golang -O--fail-missing [08:00] cp: cannot stat 'debian/tmp//usr/bin/xgettext-go': No such file or directory [08:00] dh_install: cp -a debian/tmp//usr/bin/xgettext-go debian/golang-snappy-dev///usr/bin/ returned exit code 1 [08:00] make: *** [binary] Error 2 [08:22] Chipaca, any idea about the above ? seems it comes from backporting https://code.launchpad.net/~chipaca/snappy/delayed-service-start into 15.04 (why is there xettext in that merge at all ?) [08:22] *xgettext [08:33] Good morning all; happy Tuesday, and happy Physical Therapy Day! 😃 === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [09:32] ogra_: not entirely sure, no; mvo patched up the xgettext thing for it to work [09:46] Hi what exactly is ubuntu Core ? I have obviously read the description page but still fail to understand the purpose [09:46] is it meant to be a "container OS" for a docker like environment [09:46] or a base system running docker images ? :3 [09:46] or both [09:47] it is meant to be a core of any kind of OS [09:48] (even a desktop install is planned) [09:49] ok so what do you think about a base host for docker and docker containers ? :D [09:50] whither mvo? [09:50] livcd: grab snappy ubuntu core, then "sudo snappy install docker" [10:12] pitti, is there an easy way to find that sysvinit scripts are in use via systemctl ? [10:12] s/that/which/ [10:12] ogra_: you mean that a unit was generated from a sysvinit script? [10:12] yep [10:13] (we just seeded ppp in the image and that doesnt ship any systemd stuff) [10:13] $ systemctl show -p SourcePath networking.service [10:13] SourcePath=/etc/init.d/networking [10:13] something like that? [10:13] ah, perfect [10:14] event works with a wildcard :D [10:14] ogra_: I assume this is for a script -- as a human, looking at systemctl status foo is a bit more obvious, and simpler to remember [10:15] ● networking.service - LSB: Raise network interfaces. [10:15] Loaded: loaded (/etc/init.d/networking) [10:15] pitti, well, i was not sure if snappy ships the sysvinit generator at all [10:15] ogra_: oh, ambitious :) [10:16] (but indeed that does sound achievable) [10:16] and pppd ships a /etc/init.d/pppd-dns script ... we need to be sure this still works (ppp doesnt seem to have any kind of native systemd integration) [10:20] ricmm, seems watchdog is completely configured via /etc/default/watchdog that should be easy [10:20] and its is already shipping proper systemd service files too ... [10:21] ogra_: perfecto [10:21] * ogra_ guesses there is nothing to do for watchdog except adding writability for the confi [10:21] g [10:49] ogra_: arch seems to have pppd systemd scripts :) [10:49] ogra_: otoh, systemd was working on pppd support [10:49] as part of networkd though [10:49] yeah, but thats for later [10:50] the sysvinit script it ships is a one liner: [10:50] [ -x /etc/ppp/ip-down.d/0000usepeerdns ] \ [10:50] && exec /etc/ppp/ip-down.d/0000usepeerdns [10:50] ah. meh :) [10:50] also pretty debian/ubuntu specific too [10:51] i think we're fine shipping it as is for now ... just need /etc/ppp/ writable [10:51] (and if needed have snappy config modify/add/remove files in there) [11:12] good morning from the americas! [11:13] yo yo! === dholbach_ is now known as dholbach [12:19] * ogra_ sees that ubuntu-snappy has finally built and triggers a new 15.04 image [12:42] is there a generic image i can get ? [12:43] i plan to use it with vbox [12:47] * Chipaca shakes his fist at classes that use private globals for configuration you should change for testing use of the class [12:47] livcd: yes, you probably want the amd64 15.04 stable image [12:47] livcd, wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz ? [12:47] livcd: https://developer.ubuntu.com/en/snappy/start/ [12:48] Chipaca: is that the one ? [12:48] is not that the one for KVM ? [12:49] livcd: the url guest42315 pointed at works with kvm, yes [12:50] livcd: i assume vbox is virtualbox, in which case I understand it also can work with that image, but I haven't tested this myself [12:50] oh i think i have to convert that one first [12:50] i have seen on the page a "larger" multipurpose image for vmware,vbox,etc [12:51] livcd: get the OVA file [12:52] livcd: from the page i pointed you at [12:52] livcd: probably the easiest way [12:53] the ova file [12:53] yeah that's the one [12:53] ok [12:53] though i wanted the smallest image possible :D [13:22] hello [13:26] jdstrand, I noticed that I am getting this error when I try to use certain pins on my bbb [13:26] Sep 08 13:25:36 localhost.localdomain ubuntu-core-launcher[1090]: open /sys/class/gpio/gpio44/direction: permission denied [13:26] yashi_: hello [13:27] just tried to run ubuntu-device-flash under systemd-nspawn container and found out that oem handler runs `udevadmin control --reload` which is not possible under nspawn containers. installOemHardwareUdevRules seems to assume that environment it's called is runtime env, but not a host with u-d-f [13:27] rickspencer3: https://bugs.launchpad.net/snappy/+bug/1488618 ? [13:27] Launchpad bug 1488618 in Snappy trunk "cannot specify /sys/class/gpio/export with hw-assign" [Critical,Fix released] [13:27] I added this to my apparmor profile to try to hack around it, but it didn't work [13:27] /sys/class/gpio/gpio44/direction rw, [13:28] Chipaca, well, that is another bug I found perviously [13:28] not sure if this is the same or related [13:28] ah [13:28] me neither :) [13:28] is there a way for me to tell my bbb to update to the latest daily image? [13:29] sudo snappy update ubuntu-core [13:29] shoudl work [13:30] arg, ogra_ maybe I didn't get onto rolling when I made the image :( [13:30] ah, thats the hacked channel image ? [13:30] it seems to me that what u-d-f want is to install udev rules but not activation. does anyone know around this? [13:30] is says I am on version 4 [13:30] yeah, that might not just work [13:31] aaarg [13:31] you can force it in the bootloader config to switch to the other partition [13:32] (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep ^snappy_ab [13:32] snappy_ab=a [13:32] yashi_: sorry, what? [13:32] (RaspberryPi2)ubuntu@localhost:~$ sudo fw_setenv snappy_ab b [13:32] then reboot [13:33] ((unless your image is really really old ... in which case you dont have the right bootloader setup and actually need to re-flash) [13:34] Chipaca: have you run ubuntu-device-flash under systemd nspawn containers? [13:34] yashi_: I have not. What for? [13:34] Chipaca: using a container for lightweight vm, nothing more. [13:35] * ogra_ guesses the typical ubuntu user uses lxc instead of nspawn :) [13:36] yashi_: and you run u-d-f _inside_ the container, and ... something about udev? [13:36] ogra_: oh [13:37] * Chipaca isn't getting where udev comes into it [13:37] yeah, sounds weird [13:37] is that when you are executing it ? [13:37] at first i thought you were trying to use the output of u-d-f inside an nspawn (which wouldn't work) :) [13:37] Chipaca: yeah, in short u-d-f does not work inside the container. reason: no access to systemd-udevd [13:37] or do you refer to the u-d-f package shipping rules [13:37] ah [13:39] rickspencer3: let me look at the bug again [13:39] but i thought u-d-f does not need to / should not access systemd-udevd via udevadm. [13:39] sigh [13:40] well, it creates partitioned images ... i havent seen the source but it might talk to udevd to determine loop devices and whatnot [13:40] sergiusens, ^^^^ ? [13:40] that's probably the oem setup? [13:40] it is related but the fix isn't broad enough. unfortunately, I've never done gpio so not sure of all the paths. I am going to suggest going broader to cover this [13:40] Chipaca, yeah [13:41] ogra_: hmm. I'l check about loop device [13:41] Chipaca: yes, it's activateOemHardwareUdevRules() in oem.go [13:41] yup [13:42] oh. lunch. [13:42] * Chipaca ~> lunch [13:49] mvo_: hey, I just filed bug #1493389 on rickspencer3's behalf. it is essentially the same bug as the one you fixed before but for a different path. In the bug, the fix I suggested should prevent this bug in the future for any path in /sys/class/gpio [13:49] Bug #1493389: cannot specify /sys/class/gpio/*/direction with hw-assign [13:49] bug 1493389 in Snappy trunk "cannot specify /sys/class/gpio/*/direction with hw-assign" [Critical,New] https://launchpad.net/bugs/1493389 [13:50] mvo_: I took the liberty of triaging it to match bug #1488618 (without assigning you) [13:50] Bug #1488618: cannot specify /sys/class/gpio/export with hw-assign [13:50] bug 1488618 in Snappy trunk "cannot specify /sys/class/gpio/export with hw-assign" [Critical,Fix released] https://launchpad.net/bugs/1488618 [13:50] yashi_, ogra_ what u-d-f are you using, the udev rules are not supposed to be triggered, just layed out [13:51] sergiusens, well, it seems to actually try to call udevd [13:51] yashi_, that is inhibited from u-d-f (activateOemHardwareUdevRules) [13:58] thanks jdstrand [14:00] sergiusens: do you mean u-d-f shouldn't call activateOemHardwareUdevRules() ? === charles_ is now known as charles [14:02] yashi_, it shouldn't and I'm sure I added code for that [14:02] yashi_, I'm checking now [14:02] yashi_, are you actually using the latest u-d-f from the snappy-tools PPA = [14:02] ? [14:02] just to make sure :) [14:03] sergiusens: i've checked the u-d-f from the snappy official ppa and bzr [14:04] ogra_: I noticed errro with the official binary so did `go get` and built u-d-f myself [14:06] ogra_: i'm not bzr guy so not sure which branch is the tip, but i've built the one in goget-ubuntu-touch revno 61 [14:08] sergiusens: which branch should I checkout to see your change? [14:08] yashi_: i suspect the change has gotten lost, as I don't see code in tip to not do the activate [14:08] yashi_, I was looking at bzr logs to figure out where the change went [14:09] * Chipaca hugs sergiusens [14:09] seems I did something similar, but not to this [14:09] and on a sidenote https://code.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk is trunk :) [14:09] Chipaca, seems it's not there, we need to either split write and install or pass in inhibitHooks [14:09] mhmm [14:09] * Chipaca runs back to his own code [14:10] ogra_: thanks! [14:12] Chipaca, no, please stay ;-) [14:18] jdstrand, I applied your work around, but I am still getting denied [14:18] maybe I need a different hw-assign? [14:18] Sep 8 14:14:58 localhost kernel: [ 69.578787] audit: type=1400 audit(1441721698.017:10): apparmor="DENIED" operation="open" profile="ssh-ready.sideload_ssh-ready_0.1" name="/sys/devices/platform/ocp/4804c000.gpio/gpio/gpio44/direction" pid=1098 comm="ssh-ready" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 [14:23] rickspencer3: yes, you need an additional hardware assign [14:24] jdstrand, so, weird that it always works fine on pin 67 and 68 [14:24] rickspencer3: do remember that if you do hw-assign again, you'll have to re-add the workaround rule [14:25] mvo_: ogra_: hadn't we fixed the thing where we create vmlinuz-$version and initrd-$version? [14:26] because wily edge 166 still has it, right now [14:26] Chipaca, i think sergio did the u-d-f side to ssuport the versioned binaries ... and i think mvo_ recently added code that makes sure everything is removed from /boot [14:26] Chipaca, the part missing is that system-image would need to generate the yaml [14:26] Chipaca: I have a branch for this up for review right now [14:26] jdstrand, ack [14:26] it might be that we still have unversioned duplicates in the oem snap [14:27] mvo_: you have a lot of branches waiting on the integration test runner, it seems [14:27] mvo_: is that thing working? [14:27] Chipaca: I think so, I tested it on some kernel change image iirc [14:27] hey everyone [14:27] tedg: I'd like to sync with your on python support [14:28] mvo_: i meant the integration test runner thing [14:28] zyga: Morning, I have a branch, but it needs to get updated with sergiusens' fixes. [14:28] tedg: can I have a look? [14:29] tedg: maybe your approach is easier to land than mine :) [14:29] Chipaca: it seems its not right now, we probably should ask fgimenez :) [14:30] zyga: No, it is a secret. What ever you do, don't click on this link! https://code.launchpad.net/~ted/snapcraft/python-pip [14:31] tedg: thanks [14:32] mvo_, you mean this branch https://code.launchpad.net/~mvo/snappy/snappy-lp1476129-boot-ok/+merge/269224 right? we can keep the rc local failover test commented [14:33] fgimenez: there are a number of branches that are waiting for the integration test +1 [14:33] fgimenez: is that working? because it's been a week for some of them [14:34] fgimenez: so if you think it's working, you think wrong :) [14:34] sergiusens: gotta go, it's late here. let me know if you need a tester for it, i have some time tomorrow [14:35] Chipaca, it's not enabled yet afaic, probably some of the jenkins instances kept requesting the review, while the jobs weren't triggered [14:36] mvo_: top approve 'em all! [14:36] go go go [14:36] shell shell shell [14:36] yashi_, sure, just remind me tomorrow [14:36] thanks [14:38] Chipaca: :) yay [14:38] ogra_: how do I generate the init img from this initramfs-tools-ubuntu-core branch? [14:38] elopio: first, you take a black rooster on a full moon [14:38] elopio: the initrd.img ? find .|cpio -o -H newc|xz -c -9 --check=crc32 [14:39] elopio: after you unpacked it to "." of course [14:39] elopio: and yes, full moon also helps ;) [14:39] Chipaca: that's easy to get. [14:39] elopio, make a chroot ... install initramfs-tools and initramfs-tools-ubuntu-core in it ... chroot into it ... sudo update-initramfs -kfoo -c [14:39] elopio: your neck of the woods, sure [14:39] oh, what ogra_ said works too to build it afresh, my suggestion works when modifying a existing one [14:40] right, you can as well unpack and re-pack [14:40] and replace the right bits === utlemmin` is now known as utlemming [15:49] fgimenez: do you have ssh access to that instance that failed on the free space test? [15:50] elopio, yep, let me add your key [15:52] elopio, the jenkins container is running at 10.55.32.36, you should be able to access now, sudo docker exec -ti snappy-jenkins bash to enter the container [15:53] fgimenez: I meant to the snappy instance. [15:53] sorry for not being clear. [15:53] elopio, the instance itself where the tests run is deleted, but you can spin it up again with nova [15:53] yep, np :) [15:54] fgimenez: I have started a couple of instances and can't reproduce it. [15:54] I think this will help, for sure: https://code.launchpad.net/~elopio/snappy/parted_script/+merge/270421 [15:54] but I'm not sure if it will fix your problem. Does it happen on all the runs from jenkins? [15:55] elopio, these are the results http://10.55.32.36:8080/job/snappy-daily-1504-canonistack/, fails with each execution [15:55] fgimenez: great, so let me try with this branch from a jenkins instance. Thanks. [15:56] elopio, maybe it's because it's running against 15.04? [15:56] let me try rolling too [15:57] fgimenez: if ogra has not backported this, then the image doesn't have parted installed. Let me check. [15:57] elopio, right, not backported yet [15:58] i was waiting for test feedback first ... [15:58] fgimenez: ^ so the test is rolling only. [15:59] elopio, ogra_ ok thanks, now running it === kickinz1 is now known as kickinz1\afk [16:17] Uhg, this sucks. bug 1306991 [16:17] bug 1306991 in python-pip (Ubuntu) "pip stops with ImportError for request-Modul" [Undecided,Confirmed] https://launchpad.net/bugs/1306991 [16:17] Finally found the issue, but not sure how to work around it. [16:19] Frustrating, but ironic, to run into the issue that people have working with Ubuntu packages while trying to build Snappy === greyback is now known as greyback|eod === soee_ is now known as soee [16:34] tedg, maybe just easy_install pip and forget the ubuntu package? [16:45] ogra_ or sergiusens: when do we need the dtbs? only for uboot? [16:46] elopio, yes; for arm [16:49] elopio, what sergiusens said ... depneding on the device you need them earlier or later [16:50] (BBB only needs them in uboot, RPi already in the first stage loader) [17:12] sergiusens: Yeah, working through that... directories become fun. === bschaefer_ is now known as bschaefer [18:43] hi everyone, is there a way yet to use snapcraft on my (x86) laptop to build a package for (armhf) RPi2? [18:43] using a .deb from the archives [18:44] mhall119, are you subscribed to snappy-app-devel? [18:45] probably not [18:45] mhall119, if you do, and if you look at the latest thread [18:46] you will get your answer! [18:46] * beuno doesn't want to spoil the ending [19:03] beuno: You're such a tease! [19:45] Ha, I think it works. === bjf_ is now known as bjf [20:04] jdstrand, does this mean I need to do hw-assign /sys/devices/ ? [20:04] Sep 8 20:03:12 localhost kernel: [19340.684890] audit: type=1400 audit(1441742592.719:445): apparmor="DENIED" operation="open" profile="pan-tilt-camera.sideload_pan-tilt-camera_0.1" name="/sys/devices/" pid=1852 comm="pan-tilt-camera" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [20:15] rickspencer3: that one is annoying. does the app not work correctly without that access? [20:15] jdstrand, well, it threw that error constantly in a loop [20:15] then, I granted the app access to /sys/devices [20:16] not more error, but the app is not working [20:16] also, I just burned out a servo by plugging it into the wrong pin [20:16] right. if it wants /sys/devices/ it is perhaps looking for something [20:16] ouchie [20:16] jdstrand, I think it is a pwd port [20:17] as in, I think the port support pwd [20:18] * rickspencer3 notes to be more careful with servos [20:18] there's $3 I'll never see again [20:18] hehe [20:18] jdstrand, so I am not seeing any denials or errors [20:19] it's just not working [20:19] and I have no idea where to start [20:19] nothing in pwm [20:19] hrm [20:19] * rickspencer3 goes to google [20:20] I'm going to allow access to /sys/devices/ so you won't have to worry about that [20:20] h man, I plugged it into the totally wrong pin [20:39] criminy [20:40] ogra_, anything I need to know before using pwm on my bbb? [20:40] for example, "how to make it work" ;) === c74d is now known as Guest32121 [21:24] tedg, can you peek at https://code.launchpad.net/~sergiusens/snapcraft/filesets/+merge/270455 (work in progress) and get some initial thoughts in? I'd also appreciate if you can look at all the prereqs to this which are under actual review :-) [21:34] sergiusens: Not a fan of "!include" [21:34] tedg, well, that is part of the spec ;-) [21:34] sergiusens: Means that you have two "languages" in the same file. YAML and a string lang. [21:34] * sergiusens wasn't there [21:35] Eh :-/ [21:35] tedg, also, ! means something in yaml so you have to explicitly cast the string with quotes :-/ [21:35] Nice. [21:35] What does "!" mean in YAML? [21:36] tedg, ready for the irony...? [21:36] tedg, it is some form of 'include' [21:36] :-P [21:37] Oh, an it seems !! allows for typing. [21:37] tedg, I'll be writing an email about this [21:40] Wow, YAML is kinda crazy on this. [21:40] * tedg had no idea [21:46] sergiusens: Not sure I have useful comments... it matches the spec :-) The spec is a bit odd in this case. [21:46] It feels like we're real close to needing regular expressions. [21:47] Which I don't think is a good place to be. [21:49] tedg, ;-) well you can review the prereqs I guess :-P [21:50] We effectively have sets of globs which use to generate sets of files. [21:51] I can't figure out a way to resolve it, but it feel yucky. [21:53] sergiusens: Didn't we have something autobuilding the MRs? [21:53] * tedg doesn't see a comment [21:55] tedg, after approval iirc [21:55] elopio, ^ ? [21:57] sergiusens: Why can't tabs be in a snapcraft.yaml? [21:57] sergiusens: It seems like valid YAML. [21:57] tedg, It is not; tabs can't start a line like that [21:58] tedg, http://www.yaml.org/faq.html [21:58] tedg, it made it to the two question faq :-P [22:00] sergiusens: Hmm, I think that Juju allows them atleast, I'm sure I've used them :-) [22:01] sergiusens: Interestingly they can be used for spacing values but not indentation. [22:02] tedg, the golang based parser doesn't care; snappy doesn't care either [22:03] tedg, it is just not following the spec, that's all [22:03] tedg, I would rather ont patch python3-yaml to not follow the spec :-P [22:04] seems to be the wrong direction :-) [22:04] sergiusens: You could patch the YAML spec ;-) [22:04] * tedg wants to move things the right direction [22:05] * sergiusens would make all code just use tabs [22:05] * sergiusens walks away for a bit [22:05] I like tabs for YAML files because you can just set your tabstop to 10 and see what the indentation really is. [22:06] I'm going to have to go soon.