[06:24] <mvo> 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] <fgimenez> good morning
[07:35] <ogra_> mvo, sure, whatever suits :)
[07:40]  * ogra_ likes sentences with the word "remove" if they refer to the image ;)
[08:40] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <ppisati> let me try that
[08:53] <ogra_> right, thats what i'll do with 15.04.3
[08:55] <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:56] <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:57] <ppisati> :(
[08:57] <ogra_> yeah
[08:58] <ppisati> ogra_: found the dtb patch
[08:58]  * ppisati respins another kernel
[09:01] <livcd> any help ?
[09:03] <Chipaca> livcd: vbox is virtualbox?
[09:04] <Chipaca> livcd: the "no valid rapl domains found" is not a blocker/crasher/etc, just an informational message
[09:05] <livcd> Chipaca: yes...i know but the whole thing stops there
[09:05] <livcd> and won't continue booting
[09:07] <Chipaca> ogra_: at least here autopilot does reboot the machine
[09:08] <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:18] <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:19] <ogra_> *i always
[09:19] <ppisati> uhm
[09:20] <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:21] <ogra_> if our config differs, the dt will differ i guess
[09:28] <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:29] <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:30] <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:43] <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
[10:47] <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:48] <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:50] <popey> :(
[10:50] <popey> Finding their own launchpad page is the least hard part of signing the CoC to be fair
[10:51] <Chipaca> popey: good on you for noticing there are so many of us delinquent on that point
[11:32] <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:35] <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:36] <livcd> oh well the ova did not quiete work for me
[11:36] <livcd> it would not boot on vbox
[11:37] <ricmm> ogra_: sweetskies
[11:38] <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:39] <livcd> not yet
[11:41] <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:42] <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
[12:23] <livcd> ogra_: ok ty
[13:08] <josepht> aa
[13:15] <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:16] <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:17] <ogra_> no
[13:17] <ogra_> ogra@anubis:~/Devel/packages$ sudo -s sh -c "env|grep SUDO"
[13:17] <ogra_> SUDO_GID=1000
[13:18] <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:20] <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:21] <ogra_> did debian change anything ?
[13:22] <yashi_> did i?  not that i remember
[13:22] <yashi_> /etc/sudoers seems the same
[13:23] <ogra_> https://launchpad.net/ubuntu/+source/sudo/1.8.12-1ubuntu1
[13:23] <yashi_> all debian machine around me returns /root
[13:24] <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:25] <ogra_> yeah, that would be it i guess
[13:25] <yashi_> yup, thanks a lot
[13:26] <yashi_> 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] <ogra_> heh
[13:44] <Chipaca> mvo: you around?
[13:53] <Chipaca> ok, school run time for me
[13:57] <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:58] <dduffey> since gotomeeting URL is non-functional, do we have call in info?
[14:03] <dduffey> sorry, wrong channel
[14:13] <mvo> Chipaca: yes, sorry for the delay
[14:20] <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:21] <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:33] <ogra_> ppisati, ah, cool
[14:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[15:00] <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:10] <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:11] <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:33] <Chipaca> fgimenez: what firewall is running on that host?
[15:34] <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:35] <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:36] <Chipaca> fgimenez: tbh i wouldn't expect it to be blocked, but ¯\_(ツ)_/¯
[15:40] <Chipaca> mvo: i think i'm going to leave this husk work to later
[15:41] <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:42] <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:46] <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:48] <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:49] <fgimenez> Chipaca, mmm how could we do the get from the test if we don't know the port?
[15:50] <Chipaca> ah! you're doing it via activate from the test too
[15:50] <Chipaca> never mind then :)
[15:51] <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:52] <Chipaca> fgimenez: from outside, kill it with SIGINT SIGQUIT, or SIGTERM
[15:53] <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:54] <Chipaca> fgimenez: actually safer (non-panic'ing) code would be: proc := cmd.Process; if proc != nil {proc.Kill()}
[15:55] <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:56] <fgimenez> Chipaca, :) thanks, i'll put that in place
[16:41] <tedg> mvo: Looking at python-apt and the sourceslist support. It seems like that's just for reading, is that true?
[17:10] <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:12] <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:13] <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:14] <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:15] <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:17] <mvo> tedg: thats a long standing usability bug, update() really should open() internally again :/
[17:17] <mvo> tedg: and memonly=true will work
[17:22] <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:23] <mvo> thanks!
[17:50] <elopio> ogra_: https://code.launchpad.net/~elopio/snappy/resize_test/+merge/270718