=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [06:24] ogra_, ricmm: do you think we can remove the /etc/ppp example files? they make the snappy config ubuntu-core output pretty ugly [07:08] good morning [07:35] mvo, sure, whatever suits :) [07:40] * ogra_ likes sentences with the word "remove" if they refer to the image ;) === davidcalle_ is now known as davidcalle [08:40] ogra_: i finally cracked pwm support on the rpi2 [08:40] ogra_: it requires a new kernel with some config changes and a little atch [08:40] ogra_: and the pwm overlay must be loaded from config.txt [08:42] cool [08:42] http://pastebin.ubuntu.com/12327126/ [08:42] 15.04.3 release should be around end of the month i think [08:43] ogra_: do you have your rpi2 with snappy installed? [08:43] indeed [08:43] ogra_: i'm using the newer linux-firmware here (i'm juggling betweeb 3.19 and 4.2) [08:43] ogra_: sudo cat /proc/device-tree/soc/pwm@7e20c000/compatible [08:44] (RaspberryPi2)ubuntu@localhost:~$ sudo cat /proc/device-tree/soc/pwm@7e20c000/compatible [08:44] cat: /proc/device-tree/soc/pwm@7e20c000/compatible: No such file or directory [08:44] only i2c, spi, gpio and leds [08:45] no pwm by default [08:45] ogra_: find /proc/device-tree/ | grep pwm [08:45] (RaspberryPi2)ubuntu@localhost:~$ find /proc/device-tree/ | grep pwm [08:45] (RaspberryPi2)ubuntu@localhost:~$ [08:45] ogra_: ok so, the device-tree there din't have the bindings for the pwm [08:45] ogra_: in vivid we need to update that too [08:45] well, thats the default dt [08:46] no overlays [08:46] ogra_: the pwm overlay just turn it on [08:46] ogra_: the pwm node must be there already [08:46] nope [08:46] ogra_: https://github.com/raspberrypi/linux/blob/rpi-4.1.y/arch/arm/boot/dts/overlays/pwm-overlay.dts [08:47] (RaspberryPi2)ubuntu@localhost:~$ find /lib/modules/ | grep pwm [08:47] (RaspberryPi2)ubuntu@localhost:~$ [08:47] there is no pwm support at all, so how would that work [08:47] ogra_: right [08:47] ogra_: but what i'm saying is that, evern with a kernel with the correct config [08:47] ogra_: the driver doesn't know where to attach [08:47] Good morning all; happy Thursday, and happy Swap Ideas Day! 😃 [08:47] ogra_: because the DT doesn't export the hw [08:48] indeed, thats why you need to enable the overlay [08:48] and thats good [08:48] ogra_: but overlay support is already on [08:48] ogra_: and the pwm overlay, it just flips a value [08:49] we dont want pwm on while someone has plugged somethin into it that requires the pins configured completely different [08:49] ogra_: right [08:49] worst case that could blow up something [08:49] so changing config.txt for now is fine [08:49] ogra_: and indeed what the overlat does, is to just flip it from off to on [08:49] yeah [08:49] ogra_: yeah, but the DT has to have the node there [08:50] ogra_: let me show my DT without the pwm overlay [08:50] right, does that work with the bootloader ? [08:50] switching to our own dtb there i mean [08:51] ubuntu@raspy2:~$ grep pwm /mnt/config.txt [08:51] #dtoverlay=pwm-overlay [08:51] ubuntu@raspy2:~$ sudo cat /proc/device-tree/soc/pwm@7e20c000/compatible [08:51] brcm,bcm2835-pwmubuntu@raspy2:~$ sudo cat /proc/device-tree/soc/pwm@7e20c000/status [08:52] disabledubuntu@raspy2:~$ [08:52] with no overlat loaded [08:52] but the node is already there [08:52] ogra_: the one provided with the kernel? don't know, i would just switch to the latest https://github.com/raspberrypi/firmware [08:52] yes, because your kernel config has it [08:53] let me try that [08:53] right, thats what i'll do with 15.04.3 [08:55] i have downloaded ova and imported it to vbox on mac but the whole thing gets stuck on booting somewhere in no valid rapl domains found [08:56] cat: /proc/device-tree/soc/pwm@7e20c000/status: No such file or directory [08:56] ogra_: it doesn't have that node [08:57] :( [08:57] yeah [08:58] ogra_: found the dtb patch [08:58] * ppisati respins another kernel [09:01] any help ? [09:03] livcd: vbox is virtualbox? [09:04] livcd: the "no valid rapl domains found" is not a blocker/crasher/etc, just an informational message [09:05] Chipaca: yes...i know but the whole thing stops there [09:05] and won't continue booting [09:07] ogra_: at least here autopilot does reboot the machine [09:08] Chipaca, not if you disable it [09:08] livcd: you're giving us zero information we can use to help you :-( [09:08] ogra_: correct [09:08] it still does the download and installs it though [09:18] ogra_: so, you were already using the dtb provided by the kernel so far? [09:18] ppisati, nope [09:18] laways the one from upstream [09:19] *i always [09:19] uhm [09:20] i wonder if there's any difference between the one shipped by upstreamn (linux-firmware in the github/raspberry repo) and ours [09:20] well, given they get generated based on kernel config ... [09:21] if our config differs, the dt will differ i guess [09:28] ogra_: right, and we are switching from an upstream dtb to our dtb, right in the middle of a cycle [09:28] ogra_: i've to do some db-diff and see the difference [09:29] yeah, not ideal [09:29] ogra_: or we should simply bite the bullet, and move to wily [09:29] *wily's kernel [09:29] as long as we can do that without regressing anything [09:30] ogra_: ok so, i'm pushing a new kernel with owm and so to my ppa [09:30] ogra_: then i cehck that wily is ok [09:30] ogra_: and after all that, i'll do some db-dif to see if moving from upstream to vivid is ok === chihchun_afk is now known as chihchun [09:43] Chipaca, oh, i see, the context is missing because the text from the readme.md in that mail is all screenshots [09:43] the text in the inline image actually talks about the fact how the update applies if you disabled it [10:47] popey: next time you want to point somebody at "their own page on launchpad", try https://launchpad.net/~ [10:47] :) [10:47] dammit, I was looking for that but couldn't find the thing [10:48] i thought it was +me [10:48] popey: if only you knew people that knew launchpad better than you, such that you could ask them! [10:48] * Chipaca is being mean [10:50] :( [10:50] Finding their own launchpad page is the least hard part of signing the CoC to be fair [10:51] popey: good on you for noticing there are so many of us delinquent on that point === chihchun is now known as chihchun_afk [11:32] bah how do i uncompress the xz img ? [11:32] ah [11:32] usin unxz :) [11:32] there's a unxz [11:35] ricmm, oh, forgot to tell you, the latest 15.04 edge has auto-resize [11:35] (still testing pending, working on it) [11:35] i am starting to give up on snappy [11:35] whats your issue ? [11:36] oh well the ova did not quiete work for me [11:36] it would not boot on vbox [11:37] ogra_: sweetskies [11:38] i plan to build a box using Packer.io but there seem to be too much hassle to get a working vbox img :SSS [11:38] livcd, did you try just converting the amd64 img ? [11:39] not yet [11:41] wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz [11:41] unxz ubuntu-15.04-snappy-amd64-generic.img.xz [11:41] qemu-img convert -O vdi ubuntu-15.04-snappy-amd64-generic.img ubuntu-15.04-snappy-amd64-generic.vdi [11:41] then just use the vdi [11:42] yeah except i will have to get unxz and quemu-img first to my system (not on ubuntu) [11:42] ah [11:42] in vbox you need to use "Choose an Existing Virtual Hard Drive File" when creating the vm [12:23] ogra_: ok ty [13:08] aa [13:15] is it intended to put image cache under /root/.cache when I run u-d-f? because u-d-f needs to be run with sudo [13:16] no, it should use the $SUDOUSER [13:16] well the home of that user :) [13:16] ah, ubuntu sudo is special? [13:17] no [13:17] ogra@anubis:~/Devel/packages$ sudo -s sh -c "env|grep SUDO" [13:17] SUDO_GID=1000 [13:18] SUDO_UID=1000 [13:18] SUDO_COMMAND=/bin/bash -c sh -c env|grep\ SUDO [13:18] SUDO_USER=ogra [13:18] sorry ... should be SUDO_USER [13:20] sudo -s sh -c "env|grep HOME" [13:20] HOME=/home/yashi [13:20] under wily [13:20] but i get HOME=/root under sid [13:21] did debian change anything ? [13:22] did i? not that i remember [13:22] /etc/sudoers seems the same [13:23] https://launchpad.net/ubuntu/+source/sudo/1.8.12-1ubuntu1 [13:23] all debian machine around me returns /root [13:24] ah [13:24] thanks [13:24] keep_home_by_default.patch: Keep HOME in the default environment [13:24] there are a few changes ... nothing that points to an obvious mangling of HOME though [13:24] oh, i'm blind [13:24] :P [13:25] yeah, that would be it i guess [13:25] yup, thanks a lot [13:26] not sure it's planed to package for debian, but this needs to be remembered if it is [13:27] * Chipaca just tried importing "path/timepath". Science fiction and coding mix quite well. [13:28] heh [13:44] mvo: you around? [13:53] ok, school run time for me [13:57] ok, some progress; no partitions are recognized grub seems to be working; but "error: invalid file name `root=LABEL=system-a'." after "Booting from hard Disk..." [13:57] this should be easy to fix [13:57] (hope) [13:58] since gotomeeting URL is non-functional, do we have call in info? [14:03] sorry, wrong channel [14:13] Chipaca: yes, sorry for the delay [14:20] ogra_: so, i was looking at the snappy dtb [14:20] ogra_: and it looks very very similar to the one we are shipping with the 3.19 kernel [14:20] ogra_: actually, it's almost the same! [14:21] ogra_: the only difference are the naming of the leds (led0 vs ACT and led1 vs PWR and stuff like that) [14:21] ogra_: abnd the pwm node that i added [14:33] ppisati, ah, cool [14:52] mvo: no worries, i was on a school run anyway. I'm wondering at the relation between oem packages, and LocalRepo(oemDir) [14:52] mvo: ie, are all packages in an oemDir of type oem? [14:52] and thus, unremovable [14:52] Chipaca: yes [14:53] or are there non-oem packages that could live in an oemDir, which we may then try to remove and fail [14:53] there is duplication of information there :) [14:53] Chipaca: well, unless the user manually copies stuff in there or something [14:53] well, if they purposely break it, they can go ahead and keep all the bits [14:53] :) [14:53] Chipaca: yeah [14:53] Chipaca: so if type == Oem -> installdir = /oem [14:53] Chipaca: what duplication do you have in mind? the prefix? [14:53] mvo: so conversely, a list of removed packages can skip the oem repo entirely [14:54] mvo: type=oem, and oem repo [14:54] Chipaca: yes [14:54] anyway, the tiny bit of code that i'm working on is correct if that <-> is true [14:55] mvo: so, installdir = /oem -> type==oem? [14:55] Chipaca: yes [14:55] \o/ [14:55] Chipaca: just out of curiosity, is this simpler than just checking the type and excluding it? (I assume the anwer is yes :) [14:56] mvo: in answering the question "can i get a list of all packages that have been removed but not purged" [14:56] ohhh [14:56] ok [14:56] quite [14:57] mvo: so i'll just check the path of the repo, and if it's not the apps path, i'll return nil [14:57] \o/ :) [14:58] Chipaca: sounds reasonable, we will have data dirs for kernel/os at some pont though, but thats future [14:58] (but its getting closer!) [14:58] mvo: and are those SnapParts, or are they their own go type? [14:59] because the problem here is because oem snaps and framework snaps and app snaps are the same go type [14:59] which used to make sense, but is making less as we refine the business logic behind each [14:59] Chipaca: yeah, I struggle(d) with that too [14:59] Chipaca: I made them OsSnap, AppSnap, KernelSnap now [15:00] Chipaca: but its not 100% great because of misisng dynamic binding of functions (we talked about this some days ago). but its a step forward :) [15:10] Chipaca, a log of the error http://10.55.32.36:8080/job/snapd-test/34/console [15:10] the code http://bazaar.launchpad.net/~fgimenez/snappy/snapd_integration_test/view/head:/_integration-tests/tests/snapd_test.go#L69 [15:11] Chipaca, i'm pretty sure it's working fine, i've been able to access it with curl from the laptop after adding a rule for the testing port [15:33] fgimenez: what firewall is running on that host? [15:34] Chipaca, it's managed by nova, the security group that we have been using so far only accepts incoming requests to port 22 [15:34] Chipaca, i think there's nothing else, it's a regular snappy image [15:35] fgimenez: can you ask whether it's filtering access to 127.0.0.1:80? [15:35] Chipaca, yes, there's no rule for that, i can add one [15:36] fgimenez: tbh i wouldn't expect it to be blocked, but ¯\_(ツ)_/¯ [15:40] mvo: i think i'm going to leave this husk work to later [15:41] Chipaca: what work specificially? [15:41] ogra_: a micro branch, can you please review? https://code.launchpad.net/~elopio/snappy/parted_script/+merge/270421 [15:42] mvo: a Husk part that is a part representing a remove package [15:42] mvo: so i get the "removed" state right [15:42] removed* [15:46] Chipaca, yes, we give them this restrictive security groups just for testing! :) [15:46] Chipaca, if you want to have a look there's a running instance in 10.55.32.103 with the service up on 9999, you should be able to ssh [15:46] now the security group has the 9999 port opened, curl -i -X GET http://10.55.32.103:9999 works for me [15:48] fgimenez: 's ok, i'll believe you :) [15:48] fgimenez: fwiw, note that you can ask to serve on port 0 and you'll be given a random available one [15:49] Chipaca, mmm how could we do the get from the test if we don't know the port? [15:50] ah! you're doing it via activate from the test too [15:50] never mind then :) [15:51] Chipaca, ok :) one question for you, how could we kill the service created by systemd-activate? [15:51] fgimenez: from inside, or from outside? [15:51] Chipaca, inside [15:51] fgimenez: you call Stop() [15:51] Chipaca, sorry, inside the testbed, not the code [15:52] fgimenez: from outside, kill it with SIGINT SIGQUIT, or SIGTERM [15:53] Chipaca, ok thx, i'll add it to the integration test [15:53] fgimenez: e.g., cmd.Process.Kill() [15:53] fgimenez: or cmd.Process.Signal(syscall.SIGINT) [15:54] fgimenez: actually safer (non-panic'ing) code would be: proc := cmd.Process; if proc != nil {proc.Kill()} [15:55] because cmd.Process can be nil [15:55] if the universe has exploded or something [15:55] which can happen in a racy end-of-test cleanup [15:56] Chipaca, :) thanks, i'll put that in place [16:41] mvo: Looking at python-apt and the sourceslist support. It seems like that's just for reading, is that true? [17:10] tedg: if you use aptsources.SourceList there is a save() method [17:10] tedg: that should work and also preserve order comments and all that [17:12] mvo: Do you think it makes sense to import the system default? [17:12] mvo: I'm wavering on that. Kinda looking now towards full replacement to make it more predictable. [17:12] tedg: my gut feeling is yes [17:13] tedg: but I have no strong opinion either way, not doing it is more predictable (no crazy ppas get pulled in by default) but might surprise people who expect their crazy ppas :) [17:13] mvo: I'm okay surprising crazy people, the results are fun! ;-) [17:14] the up-side of using the system ones is that you don't need a apt.Cache().update() run which might be expensive on slow networks. but then - you don't need it very often in any case [17:14] Yeah, but I think I always need that with custom sources. [17:15] So I think I can default to system if not set, but if anything custom, I think just replace. [17:15] mvo: Also, I'm confused on why I need to do update() and then open(), will that work if memonly=True ? [17:17] tedg: thats a long standing usability bug, update() really should open() internally again :/ [17:17] tedg: and memonly=true will work [17:22] mvo: Cool, good to know as I build this up :-) [17:22] tedg: I step away from the laptop for a bit, but I will read scrollback if you have any more questions, the software-properties code might also be a useful real-world example of p-apt [17:22] mvo: Cool, thanks! Enjoy your evening! [17:23] thanks! [17:50] ogra_: https://code.launchpad.net/~elopio/snappy/resize_test/+merge/270718 === ahayzen_ is now known as ahayzen === ahayzen_ is now known as ahayzen