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