[07:08] <fgimenez> good morning
[07:27] <dholbach> good morning
[08:30] <JamesTait> Good morning all; happy Wonderful Weirdos Day! ð
[08:54] <fgimenez> hi Chipaca, can you please take a look at https://code.launchpad.net/~fgimenez/snappy/comment-rc-local-crash-test/+merge/270485 ?
[08:55]  * Chipaca looks
[08:56] <Chipaca> fgimenez: ouch
[08:58] <fgimenez> Chipaca, yep :) commenting it again should be enough by now
[09:03] <fgimenez> Chipaca, thx, trying elopio's serve_daemon_test now
[10:05] <Chipaca> wily edge update just jammed with â[    7.021077] FAT-fs (sda2): IO charset iso8859-1 not foundâ
[10:08] <Chipaca> (dunno if that's what jammed it, but that's the last thing on console)
[10:08] <ogra_> ppisati, ^^^^ i thought we compile that in nowadays ?
[10:45] <ppisati> Chipaca: BBB?
[10:45] <Chipaca> ppisati: kvm
[10:45] <Chipaca> amd64
[10:46] <ppisati> and why the kernel can't load the module?
[10:46] <ppisati> Chipaca: ^
[10:47] <Chipaca> ppisati: how would i know? :)
[10:47] <Chipaca> it might be a download problem though
[10:48] <Chipaca> as now it seems to be working, modulo the space problem
[10:48] <Chipaca> which is strange -- it should notice the download failed and not try to run with it
[10:48] <ppisati> Chipaca: ls -la /lib/modules/`uname -r` - you get something, right?
[10:50] <mvo_> Chipaca: reviewing your branch right now and just noticed the backlog, is this a fresh image or a upgrade?
[10:50] <Chipaca> ppisati: I got the error twice in a row (that is: booted an image from yesterday with -snapshot, sudo snappy update succeeded, got the error above on reboot), but now i'm getting a different error
[10:50] <Chipaca> ppisati: i'll answer your question in a moment though
[10:50] <Chipaca> mvo_: upgrade
[10:51] <mvo_> Chipaca: anything unusual in the upgrade, i.e. out-of-space on boot or something like this
[10:52]  * ppisati -> out for lunch, biab
[10:54] <Chipaca> nope
[10:55] <Chipaca> well
[10:55] <mvo_> Chipaca: hrm, thats alarming
[10:55] <mvo_> Chipaca: what is the new error you get?
[10:55] <Chipaca> right now I *do* get the out-of-space error
[10:55] <Chipaca> because it's still creating the versioned boot files
[10:55] <Chipaca> however it didn't happen when i then went on to get the other
[10:55] <Chipaca> hence why i suspect it's a download problem (or perhaps something else, but resulting in an empty or smaller initrd)
[10:55] <ogra_> currently the module (if it isnt compiled in) should live in the initrd
[10:56] <Chipaca> does that make sense?
[10:56] <ogra_> so you should get it loaded in any case ... unless your initrd didnt get loaded
[10:56] <Chipaca> now rebooting after doing the upgrade dance (which involves cleaning up /boot/b before upgrade, and then moving the versioned boot files to their unversioned place)
[10:56] <ogra_> do you have a full boot log/dmesg output ?
[10:56] <Chipaca> and it booted fine
[10:57] <Chipaca> from when it failed?
[10:57] <Chipaca> as it happens, i do
[10:57] <ogra_> i guess it loaded the wrong initrd or no initrd at all
[10:57] <mvo_> Chipaca: hm, I think it just failed to load the right inird.img, i.e. syncbootfiles copied the old one and the new (and correct) one was not renamed by the upgrade. I though I pushed a branch with a fix for this a while ago
[10:58] <Chipaca> ogra_: mvo_: http://pastebin.ubuntu.com/12320079/
[10:58] <mvo_> it will be a glorious day when we get rid of syncbootfiles
[10:58] <mvo_> hopefuly soon
[10:59] <ogra_> hmm, it definitely loads an initrd there
[10:59] <ogra_> doesnt seem corupt either
[11:02] <mvo_> it could just be the old one
[11:02] <ogra_> Chipaca, so i guess it simply loaded the wrong initrd ...
[11:02] <ogra_> did it properly reboot after the error ?
[11:03] <Chipaca> no, stuck there
[11:03] <ogra_> that should definitely not happen indeed
[11:03] <ogra_> i guess we'd need to teach systemd to panic in such a moment
[11:04] <Chipaca> "systemd now eats kernel panic generator"
[11:04] <ogra_> heh
[11:04] <ogra_> hmm
[11:04] <ogra_> [    0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/EFI/ubuntu/grub/a/vmlinuz root=LABEL=system-a ro init=/lib/systemd/systemd console=ttyS0 console=tty1 panic=-1
[11:04] <ogra_> [    0.000000] KERNEL supported cpus:
[11:04] <ogra_> shouldnt there be an initrd on the line as well
[11:09] <Chipaca> ogra_: apparently not
[11:09] <ogra_> grub.cfg doesnt set it by default ?
[11:09] <Chipaca> it does have an initrd stanza
[11:10] <Chipaca> but the cmdline doesn't mention it -- even on a successfully booted image
[11:10] <ogra_> ok
[11:10] <ogra_> well, it finds one ... so we're fine ... as long as it is the right one
[11:11] <ogra_> in any case the system shouldnt hang in such situations but reboot back into the other partition
[11:18] <Chipaca> mvo_: replied to your comments
[11:21] <mvo_> Chipaca: heh, looks like we should include the link to gustavos blog post as a comment when tomb is included :)
[11:22] <mvo_> Chipaca: thanks for the reply! lets wait with the top-approve until the dependencies are there, I will have a look after lunch
[11:22] <Chipaca> mvo_: mucho thank you
[11:22] <Chipaca> mvo_: wrt tomb, the blogpost is referenced from the package documentation which is in the standard place :)
[11:24] <mvo_> Chipaca: uh, ok. lalalala
[11:24] <Chipaca> added a nice long comment to the api checker test
[11:53] <ogra_> hmm
[11:54] <ogra_> do we have the ability to have a snap ship services and not start them by default ? (thinking of a snap that will come with default config we not necessarily want to run before it is configured)
[11:55] <ogra_> (beyond hacking something in via snappy config)
[11:56] <ogra_> mvo_, is there a reason that the wily versions of packages are uploaded in parallel in the image build PPA ?
[11:56] <ogra_> (vs just using the archive)
[12:00] <mvo_> ogra_: the turnaround time of the ppa is better than the archive, thats the only reason
[12:00] <ogra_> ah, k
[12:00] <ogra_> no general policy or some such
[12:00] <mvo_> no, just me being impatient
[12:14] <sergiusens> mvo_, did you do a release of snappy into wily?
[12:14]  * sergiusens wants to rebuild u-d-f with it
[12:15] <mvo_> sergiusens: not yet, can do so in a bit
[12:15] <sergiusens> mvo_, sounds good
[12:31] <mvo_> sergiusens: uploaded
[12:37] <Chipaca> tests pass \o/
[12:37] <Chipaca> ~> lunch
[12:37] <ogra_> grmbl ... the out of space thing is really annoying
[12:38]  * ogra_ spent the last 30min trying to update his rolling image 
[12:43]  * ogra_ sees a plano-amd64 package announced by the store to G+
[12:43] <Chipaca> ogra_: it's easy to update rolling!
[12:43] <Chipaca> ogra_: first, determine whether the next one will be a or b
[12:43] <ogra_> Chipaca, until it tells you there is no space for the kernel/initrd :P
[12:44] <Chipaca> ogra_: then, rm a-or-b/initrd.img* a-or-b/vmlinuz*
[12:44] <Chipaca> ogra_: then, update
[12:44] <Chipaca> ogra_: then, mv initrd and vmlinuz to be versionless
[12:44] <Chipaca> ogra_: easy peasy
[12:44] <ogra_> yeah, i mv'ed them to the generic ones
[12:44] <ogra_> this time :P
[12:45] <ogra_> but it took a few attempts
[12:45] <ogra_> (and it is super annoying that it downloads the rootfs every time )
[12:46] <ogra_> (we might have devices that only use GSM for networking ... might take them a week to download :P )
[12:46] <ogra_> heh
[12:46]  * ogra_ notes that rickspencer3 found out that devicetree sucks 
[12:46] <rickspencer3> omg
[12:46] <rickspencer3> please, someone, fix this for me!
[12:46]  * Chipaca hides
[12:46] <ogra_> i doubt it is fixable
[12:47] <ogra_> it is the alternative to compile your own kernel for each and every use-case
[12:47] <mvo_> ogra_: the fix went in yesterday it seems, so sorry, hopefully the last time
[12:47] <ogra_> mvo_, yeah
[12:47] <sergiusens> rickspencer3, just noticed I replied privately
[12:48] <rickspencer3> sergiusens, I assumed that was so you didn't embarrass my because my question was so silly
[12:48] <rickspencer3> :)
[12:48] <Chipaca> the last time i answered that kind of plea from rick i spent three months crunching numbers for academia
[12:48] <ogra_> rickspencer3, its not silly, but likely not solvable easily
[12:48] <sergiusens> rickspencer3, nah, I haven't installed a proper email client yet :-P
[12:49] <rickspencer3> really? we can't just make a custom overlay to include by default in the image?
[12:49] <mvo_> sergiusens: mutt is small
[12:50] <ogra_> rickspencer3, we could, but then people would have to remove it before loading theirs
[12:50] <ogra_> the usage of the setup is usually mutually exclusive
[12:50] <rickspencer3> that doesn't seem too bad
[12:50] <rickspencer3> right
[12:50] <rickspencer3> maybe we could have one image set up nicely for hackers
[12:50] <ogra_> and typically on a BBB you dont have any cape config by default for a generic image
[12:50] <rickspencer3> and then you take a different image if you want to do an overlay
[12:51] <rickspencer3> maybe we make an image that is on rolling and has the pins laid out for hacking
[12:51] <ogra_> i'm also not sure how far we are with capemgr support in our kernel
[12:51] <ogra_> ppisati, ?
[12:51] <rickspencer3> well, not being able use pwm is a killer for a lot of applications
[12:51] <rickspencer3> I have a multi-colored led, for example
[12:51] <ogra_> rickspencer3, you need to create your own oem snap anyway if you use any cap currently
[12:51] <rickspencer3> not to mention the servo
[12:51] <ogra_> *cape
[12:52] <rickspencer3> ogra_, well, these aren't capes, these are jumper cables and pieces
[12:52] <rickspencer3> on a breadboard
[12:52] <ogra_> they use the cape interface
[12:52] <rickspencer3> right
[12:52] <rickspencer3> so, maybe we make a "breadboard" image, that is set up like I said?
[12:53] <rickspencer3> a list of digital pins, a list of pwms, etc...
[12:53] <ogra_> well, your setup for the breadboard might completely differ from my setup ...
[12:53] <ogra_> while you use a servo and emit the right voltage/current, i might want to run a relais on the very same pin
[12:53] <sergiusens> right, pinouts can be completely different
[12:53] <ogra_> with a totally different voltage and curremt
[12:54] <rickspencer3> so?
[12:54] <rickspencer3> there are like 60 pins
[12:54] <rickspencer3> certainly there is a more sensible default than "nothing works"
[12:54] <ogra_> you would potentially blow up my HW with your cape setup
[12:54] <ogra_> this is like serial ports ...
[12:54] <rickspencer3> I find it strange that every other board seems to have a sensible set of default pins where I can use my gizmos
[12:54] <rickspencer3> but it's not possible on bbb?
[12:55] <rickspencer3> that doesn't ring true
[12:55] <sergiusens> ogra_, we could arguably create an alterante oem snap configured with a pinout that has a couple of everything
[12:55] <ogra_> while you coould make it default to be a mouse port ... there might be 3D controllers for $$$$$$$ that blow up completely if you attach it to such a port
[12:55] <rickspencer3> right
[12:55] <ogra_> so setting a default for that pinout can be very dangerous
[12:55] <rickspencer3> but, I am just talking about saying that hackers can use their breadboards without having to do this complicated overlay stuff
[12:55] <rickspencer3> ogra_, again, that sounds specious
[12:55] <ogra_> but they cant
[12:55] <ogra_> they could only use exactly your setup
[12:55] <ogra_> not theirs
[12:55] <rickspencer3> right
[12:56] <rickspencer3> but that set up for most people hacking with breadboards would be fine, right?
[12:56] <rickspencer3> what do they need?
[12:56] <rickspencer3> some digital pins
[12:56] <rickspencer3> some pwms
[12:56] <ogra_> especially for a breadboard that seems suboptimal
[12:56] <Chipaca> mvo_: E: golang-snappy-dev: arch-independent-package-contains-binary-or-object usr/bin/xgettext-go
[12:56] <rickspencer3> some analog ins
[12:56] <ogra_> since a breadboard is 100% freely usable/configurable
[12:56] <rickspencer3> sure, but most people just need a few pins to work
[12:57] <rickspencer3> if the hacker knew which 10 digitial pins will work, which 4 pwms will work, etc...
[12:57] <rickspencer3> then they could do most stuff
[12:57] <ogra_> right, they would need an overlay then ... and we should make it easier to use them, no doubt
[12:57] <ogra_> but we shouldnt ship a default overlay that potentially blows up stuff
[12:58] <mvo_> Chipaca: oh, that needs fixing, we should probably simply not install that at all, I wonder why its in the package
[12:58] <mvo_> Chipaca: I can do a seperate branch for this
[12:58] <ricmm> this is my original spec for kernel and gadget snap
[12:58] <rickspencer3> ricmm, do you think what I am proposing is going to blow stuff up?
[12:59] <ogra_> ricmm, right, is anything left from that ?
[12:59] <ricmm> ogra_: ashes
[12:59] <rickspencer3> It just seems simple that we make an image that "works"
[12:59] <ricmm> rickspencer3: if there is pin multiplexing involved, we cant have generic usage of pins
[12:59] <Chipaca> mvo_: k :)
[12:59] <ricmm> something will get fried, a garage door might crush a kid, someone might get sued
[12:59] <Chipaca> mvo_: anyway, top-approvernated
[12:59] <ricmm> Chipaca: you mean happrovernated
[13:00] <ricmm> miissing an h
[13:00] <rickspencer3> ricmm, then how come other boards have that?
[13:00] <rickspencer3> for example, on Arduino, the pins are the pins
[13:00] <rickspencer3> I plug stuff into the right pins, and good to go
[13:00] <ricmm> rickspencer3: that is because on arduino there is no pin multiplexing for other physical wire protocols
[13:01] <ricmm> they are all 5V TTL GPIO
[13:01] <ricmm> sergiusens: mvo_ ogra_ call time
[13:01] <mvo_> ricmm: I'm in the hangout
[13:01] <sergiusens> ricmm, what a pain :-P
[13:01] <rickspencer3> hmmm, it still seems to me that we could roll and image that "works" and document what the pins are
[13:02] <ogra_> rickspencer3, oops
[13:02] <ogra_> err
[13:02] <ogra_> ricmm,
[13:02]  * ogra_ moves to office, sorry 
[13:05] <yashi_> hmm..., when an amd64 snappy image created with u-d-f does not boot with qemu, where should I look?
[13:06] <Guest30312> uh new toy https://uappexplorer.com/app/plano-amd64.canonical
[13:19] <Chipaca> Guest30312: you forgot to set your nick :)
[13:20] <Guest30312> Chipaca, this is my nick :))
[13:20] <ogra_> yashi_, how does it not boot ?
[13:20] <ogra_> (errors etc ? )
[13:21] <o> oOoOOo
[13:22] <yashi_> ogra_: no errors, cpu temp up, no output.  I must have done something wrong.
[13:23] <yashi_> ogra_: it should work with qemu, right?
[13:24] <ogra_> well, it definitely works with kvm here
[13:24] <yashi_> something like: qemu-system-x86_64 -enable-kvm -m 512 my.img
[13:25] <ogra_> kvm -m 512 -redir :8022::22 my.img
[13:26] <ogra_> thats what i use
[13:27] <yashi_> ogra_: yeah, that's a wrapper provided by qemu-kvm; just oneliner to wrap qemu-system...
[13:27] <yashi_> in fact, the official image of amd64 I downloaded from ubuntu is working fine
[13:28] <yashi_> I just can't re-create it here on wily
[13:55] <Chipaca> mvo_: seems we need to throw some packages at tarmac
[13:57] <mvo_> Chipaca: yeah, elopio or fgimenez can probably help, I have the info how to access tarmac somewhere too but already forgot where :/
[13:59] <fgimenez> mvo_, Chipaca np, the ip is in the trello board https://trello.com/c/nFPZb4AL/192-automated-testing-and-continuous-integration
[13:59] <fgimenez> you should be able to ssh, let me know if not
[14:02] <mvo_> fgimenez: neat
[14:04] <ogra_> mvo_, so my rolling image finally upgraded ... i see watchdog installed but i dont see any systemd units created for it
[14:05] <ogra_> (there is a sysvinit script)
[14:05] <ogra_> pitti, do i need to do anything spethial to trigger the generator ?
[14:05] <pitti> ogra_: generators are called at boot and with systemctl daemon-reload
[14:07] <ogra_> hmm, calling systemctl daemon-reload ... and then systemctl|grep watch doesnt return anything
[14:07] <ogra_> same goes for the ppp-dns sysvinit script
[14:08] <ogra_> would it be named the same in systemctl ? (or at least contain the old sysvinit name ?)
[14:10]  * ogra_ is a bit lost here 
[14:15] <ogra_> pitti, would the generator  print anything in syslog ?
[14:15] <pitti> systemctl | grep watch? you mean "sudo journalctl -f" perhaps?
[14:16] <pitti> ogra_: most generators don't, unless you enable debugging
[14:16] <pitti> systemd-analyze set-log-level debug
[14:16] <ogra_> no, i mean systemctl |grep watch ... to find athe unit for watchdog
[14:17] <ogra_> ok,, that prints more into syslog ... still no trace of watchdog though
[14:18] <ogra_> Sep  9 14:17:10 localhost systemd[1]: Looking for SysV init scripts in:
[14:18] <ogra_> Sep  9 14:17:10 localhost systemd[1]: #011/etc/init.d
[14:18] <ogra_> nothing else
[14:19] <ogra_> i see /etc/rc2.d/S03watchdog when looking in the dirs
[14:24]  * ogra_ sighs
[14:26] <ogra_> does the sysvinit job need a special format or something to be picked up ?
[14:26] <pitti> ogra_: sorry, no context -- what do you actually try to do? you have your own generator, or look at the sysv one?
[14:26] <ogra_> pitti, i added a new package to the readonly rootfs ... it has a sysvinit job
[14:26] <pitti> ogra_: not really, just an LSB header; if you want you can run the gnerator manually (even as user), to see what it does
[14:26] <ogra_> namely the watchdog package
[14:27] <ogra_> as i understand systemd should generate a unit for it on first boot ... but it doesnt seem to
[14:27] <pitti> mkdir /tmp/x; SYSTEMD_LOG_LEVEL=debug /lib/systemd/system-generators/systemd-sysv-generator /tmp/x /tmp/x /tmp/x
[14:28] <pitti> ogra_: right, as long as it's enabled and has some working LSB header it should work
[14:29] <ogra_> Ignoring S03watchdog symlink in rc2.d, not generating watchdog.service.
[14:29] <ogra_> aha
[14:30] <ogra_> oh
[14:30] <pitti> ogra_: is there maybe already a watchdog.service?
[14:30] <ogra_> Native unit for watchdog.service already exists, skipping
[14:30] <ogra_> Native unit for pppd-dns.service already exists, skipping
[14:30] <pitti> :)
[14:30] <ogra_> so why doesnt systemctl list it then ?
[14:31] <pitti> perhaps it's not running? it should be in "systemctl --all" at least, is it not?
[14:31] <pitti> or systemctl status watchdog
[14:32] <ogra_> (amd64)ubuntu@localhost:~$ sudo systemctl start watchdog
[14:32] <ogra_> (amd64)ubuntu@localhost:~$ ps ax|grep watchdog
[14:32] <ogra_> ...
[14:32] <ogra_>  1001 ?        SLs    0:00 /usr/sbin/watchdog
[14:32] <ogra_> ...
[14:32] <ogra_> all good it seems
[14:32] <ogra_> after i start it manually
[14:32] <ogra_> pitti, thanks !
[14:32] <pitti> ogra_: ok, so what whas the root of the confusion here? the already existing native job?
[14:33] <ogra_> no, that i missed --all apparently :P
[14:33] <pitti> ah, ok
[14:33] <ogra_> systemctl --all |grep watchdog lists it just fine
[14:36] <ogra_> hmm
[14:36] <ogra_> watchdog doesnt start automatically though ... even though it is enabled in /etc/default/watchdog
[14:37] <ogra_> Sep 09 14:37:01 localhost.localdomain systemd[1]: [/lib/systemd/system/watchdog.service:10] Unbalanced quoting in command line, ignoring: "/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module"
[14:37] <ogra_> hmm
[14:41] <ogra_> yeah, /lib/systemd/system/watchdog.service has cleraly messed up qquoting
[14:41] <ogra_> http://paste.ubuntu.com/12321213/
[14:43] <ogra_> now it would be good to know where systemd gets that line from
[14:43] <ogra_> it is definitely not just copying it from the sysvinit script
[14:44] <ogra_> pitti, that smells a bit like a bug in the generator
[14:44] <ogra_> the sysvinit script has : [ "${watchdog_module:-none}" != "none" ] && /sbin/modprobe $watchdog_module
[14:45] <ogra_> the generate seems to turn that into:
[14:45] <ogra_> ExecStartPre=/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module
[14:45] <sergiusens> mvo_, https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/modprobe/+merge/270545
[14:45] <Chipaca> mvo_: what ubuntu is tarmac running in? :-/
[14:45] <ogra_> (note the missing single quote ...)
[14:45] <sergiusens> Chipaca, a cloud one; but fgimenez is the right person to ask ;-)
[14:45] <Chipaca> fgimenez: ^
[14:46] <Chipaca> because it's got a go that doesn't have os.Unsetenv
[14:46] <Chipaca> um
[14:46] <Chipaca> mvo_: and that's the main difference between stgraber's activation and the coreos one, i guess
[14:47] <ogra_> ricmm, so with the above watchdog will never auto-start ... i can run it manually though, do you think thats ok for now ?
[14:48] <stgraber> Chipaca: right, the only difference is mine works with Go 1.3
[14:48] <Chipaca> stgraber: and that's what's in 15.04, right?
[14:49] <Chipaca> stgraber: we're so far mostly building from golang-*-dev instead of vendoring
[14:49] <stgraber> Chipaca: correct
[14:49] <Chipaca> anyway. big sigh. :)
[14:49] <Chipaca> mvo_: so we need to switch back to stgraber's, or ship go 1.5 to 15.04
[14:50] <stgraber> Chipaca: we briefly tried using golang-*-dev, then noticed that to be able to build we'd have to update a whole bunch of them which would break docker as it was requiring an older version of some of them... I don't see this model working until the Go community learns to version their APIs and that seems difficult for those guys :(
[14:50] <ricmm> ogra_: that is ok
[14:51] <ogra_> ok ... still, there is a bug somewhere indeed
[14:51] <ricmm> ogra_: if its not autostarting, we can just ask them to use a config file
[14:51] <stgraber> Chipaca: if you've got a packaged version of upstream go-systemd, you can also just cherry-pick my change on top of that, it's tiny.
[14:51] <Chipaca> stgraber: a large chunk of github seems to ignore the idea of versioning entirely
[14:51] <ogra_> seems the generator tries to be clever with shell script ... and isnt
[14:52] <fgimenez> Chipaca, sergiusens i think elopio set up tarmac, he can confirm
[14:52] <Chipaca> fgimenez: 's ok, 15.04 is already too old for what my question was
[14:54] <stgraber> oh, also, since we're talking Go and snappy. I seem to remember seeing you guys using go-gettext too. How are you extracting your strings?
[14:54] <stgraber> there isn't a go xgettext filter that I know of, I believe for LXD we're using the c++ one but it's not picking up some multi-line strings which makes it less than ideal
[14:55] <Chipaca> stgraber: ooooh!
[14:55] <Chipaca> stgraber: we wrote our own xgettext
[14:55] <Chipaca> stgraber: mvo_ did in fact
[14:55] <Chipaca> mvo_: see? we should totally package that binary :)
[14:56] <stgraber> any pointer to that xgettext? We totally need it!
[14:56] <mvo_> Chipaca: uh, hrrrm
[14:56] <Chipaca> stgraber: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/i18n/xgettext-go/
[14:56] <stgraber> nice!
[14:56] <mvo_> Chipaca: I send a pull-request to the upstream go-gettext guys
[14:57] <mvo_> Chipaca: I had hoped it would be adopted there
[14:57] <mvo_> stgraber: happy to package it on its own if its useful for you
[14:57] <Chipaca> mvo_: any response?
[14:57] <mvo_> I will ping upstream again
[14:57] <mvo_> no :(
[14:57] <mvo_> not even a "we hate you"
[14:57] <mvo_> (or your code, but isn't that the same ;)
[14:57] <ogra_> pitti, do you want a bug for the above ?
[14:57] <stgraber> mvo_: that'd probably be useful at some point, until then I can change our makefile to just go get it from your branch
[14:58] <Chipaca> oh man, sometimes it's hard to remember that no, it isn't the same :)
[14:58] <mvo_> Chipaca: what are you talking about, it's not the same ?!?!?!
[14:58] <pitti> ogra_: re
[14:58] <ogra_> ah, you were out
[14:58] <pitti> ogra_: please, with the original sysvinit script to reproduce
[14:58] <pitti> ogra_: yeah, mowing the lawn
[14:58] <ogra_> yep, will add that .... and the unit it generated
[14:59] <ogra_> hah, i got that ahead too today :)
[14:59] <pitti> ogra_: if it's not just a copy&paste error when someone created /lib/systemd/system/watchdog.service :)
[14:59] <ogra_> "brothers in mow"
[14:59]  * pitti ^5s ogra_
[14:59]  * ogra_ ^5s back
[14:59] <ogra_> pitti, i didnt touch it ... all automatic
[14:59] <ogra_> but i re-ran the generator manually when digging
[15:00] <ogra_> (as you know)
[15:00] <pitti> ogra_: right, but that didn't rewrite it because it was already there in /lib
[15:00] <ogra_> yeah
[15:02] <davmor2> ogra_: is this how you ^5 backs? https://xrixterweb.wordpress.com/2013/04/07/ncis-the-agent-gibbs-slapgif-images/
[15:04] <pitti> davmor2: oh gawd, you read too much internet! :-)
[15:05] <davmor2> pitti: :)
[15:10] <davmor2> pitti: also only the bits you can make fun :)
[15:10] <pitti> oh crap, missed the 17:00 confcall for Anand's  presentation
[15:10] <pitti> will that be recorded?
[15:24] <Chipaca> ogra_: http://www.jann.cc/2013/02/02/linux_watchdog.html has things form a guy using a hardware watchdog under systemd
[15:24] <zyga> Chipaca, ogra_: what are your plans for the watchdog?
[15:26] <davmor2> pitti: 17:00 your time or UTC
[15:27] <pitti> davmor2: mine
[15:27] <pitti> i. e. 1500 UTC
[15:27] <davmor2> pitti: nevermind then :)
[15:28] <ogra_> zyga, no plans
[15:28] <ogra_> we need to include it and it needs to work ... thats all
[15:58] <rickspencer3> hey, is pwm supported by snappy on raspberry pi 2?
[15:58] <elopio> Chipaca: still having problems with tarmac?
[15:59] <ogra_> rickspencer3, perhaps not /me cant tell ... i2c was the main focus fro 15.04.2
[15:59] <rickspencer3> ug
[15:59] <rickspencer3> no servos for Rick
[15:59] <ogra_> did you try ?
[16:00] <ogra_> perhaps it works
[16:00] <ogra_> there was just no specific focus to that ... main focus was making dtb overlays loadable at all and i2c
[16:00] <davmor2> rickspencer3: not after the moon on a stick again are you ;)
[16:00] <rickspencer3> ogra_, I did try, yes
[16:00] <Chipaca> elopio: my problems are not with tarmac :)
[16:00] <rickspencer3> and I got this ... panic: gpio: pwm not supported on this host
[16:01] <rickspencer3> at least I got a normal GPIO pin to work ;)
[16:02] <ogra_> rickspencer3, might be thats missing in the kernel then
[16:02] <ogra_> ask ppisati
[16:03] <rickspencer3> ppisati, can I do pwm on rpi2?
[16:03] <rickspencer3> with snappy, of course ;)
[16:03] <ogra_> i dont see any special option in config.txt that would switch it on/off
[16:03] <fgimenez> elopio, i've added the card about splitting the common package
[16:03] <ogra_> only some tuning option
[16:04] <ppisati> rickspencer3: what did you do to get a "panic: gpio: pwm not supported on this host"?
[16:05] <rickspencer3> ppisati, I run code from the embd library
[16:05] <rickspencer3> also, I note that there is no "pwm" under /sys/class
[16:05] <rickspencer3> so I can't do it manually
[16:05] <ogra_> ppisati, http://lwn.net/Articles/596188/
[16:06] <ogra_> seems thats the driver
[16:06] <ppisati> rickspencer3: oh, it's the app then
[16:06] <fgimenez> elopio, i've added another about writing godoc comments for generating the integration tests documentation, what do you thing about that?
[16:06] <rickspencer3> ppisati, right, it's not kernel panic, if that's what you mean
[16:06] <rickspencer3> it's a Go panic
[16:07] <ppisati> rickspencer3: everytime i see the word "panic" i attach it to the kernel
[16:07] <rickspencer3> ppisati, here is the code
[16:07] <ogra_> and i dont see /sys/class/rpi-pwm on my 15.04.2 install
[16:07] <rickspencer3> https://github.com/kidoman/embd/blob/master/samples/servo.go
[16:07] <ogra_> which should be the respective sysfs node
[16:07] <ppisati> right
[16:08] <ppisati> PWM is off in 3.19, i just checkd the config
[16:08] <elopio> fgimenez: thanks. I think it will be nice. I tend to hate docs, but will give this a try, is probably worth it :)
[16:08] <ppisati> i'll fix it and push a new kernel
[16:08] <ogra_> ppisati, thanks
[16:08] <ogra_> rickspencer3, so 15.04.3 will have it :)
[16:10]  * ppisati goes to pick up the car from the garage
[16:13] <fgimenez> elopio, ok, leaving, see you tomorrow
[16:13] <fgimenez> nice evening everyone o/
[16:56] <Chipaca> ok, off to a parents' evening. Will bb(m)l.
[18:45] <sergiusens> mvo_, here's another one https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/modprobe-orig-files/+merge/270579
[18:45] <sergiusens> :-)
[18:52] <stgraber> mvo_: hey, what am I doing wrong? http://paste.ubuntu.com/12322788/
[18:55] <stgraber> mvo_: seems to fail on a particular file for some reason
[18:56] <elopio> sergiusens: where do I get this?
[18:56] <elopio> pkg-checkbuilddeps: Unmet build dependencies: golang-uboot-go-dev
[18:57] <stgraber> mvo_: nevermind, it's our existing multi-line trick which fails, I'll just fix all of those to use the proper multi-line syntax instead
[18:58] <mvo_> stgraber: if you could mail me the failing file I will inspect and fix tomorrow morning
[18:59] <mvo_> sergiusens: I look at your two branches now
[19:05] <stgraber> mvo_: the syntax which fails is string concatenation, e.g.:
[19:05] <stgraber> gettext.Gettext("abc\n" +
[19:05] <stgraber> "def\n")
[19:05] <stgraber> which was our workaround to get the c++ xgettext parser to extract most of our strings
[19:06] <stgraber> mvo_: also, your parser does extract all the strings, yay! but the produced gettext template looks odd, as in, I get literal \n in there rather than proper line breaks, is that expected?
[19:06] <mvo_> stgraber: sort of, I was relying on LP to make it look nice, but thats certainly something I can fix too
[19:07] <mvo_> stgraber: I will make a not about it (plus a note about the string concat) and look into fixing it tomorrow morning
[19:09] <mvo_> sergiusens: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/modprobe-orig-files/+merge/270579 I thought transitional would do a "merge" of original and writable path, am I misrembering this?
[19:09] <stgraber> mvo_: awesome, thanks so much for that tool, it's going to make our use of getext useful at last!
[19:10] <mvo_> stgraber: yay, happy to hear that
[19:10] <sergiusens> mvo_, it does, but for that to work I need to write the modprobe.d file directly to system-a (instead of writable)
[19:10] <mvo_> sergiusens: oh, ok
[19:10] <sergiusens> mvo_, IOW, if the dir on writable exists, the transition is considered done
[19:10] <mvo_> sergiusens: makes sense
[19:10] <sergiusens> mvo_, I forgot about that too :-/
[19:13] <sergiusens> mvo_, in any case we may not want to do this at all in the future
[19:30] <stgraber> mvo_: another small bug, if a string contains a ", your tool doesn't escape it
[19:30] <stgraber> mvo_: that leads to an invalid pot file
[19:30] <mvo_> stgraber: thanks
[19:30] <mvo_> that one at least is easy
[19:30] <mvo_> :)
[19:31] <stgraber> :)
[20:38] <mvo_> stgraber: lp:~mvo/snappy/snappy-gettext-fixes should contain the fixes, please let me know by mail if you notice any regression(s)