=== bigcat is now known as kengyu | ||
=== kengyu is now known as bigcat | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== guest42315 is now known as o | ||
=== o is now known as Guest30312 | ||
=== kickinz1\afk is now known as kickinz1 | ||
=== chihchun_afk is now known as chihchun | ||
fgimenez | good morning | 07:08 |
---|---|---|
dholbach | good morning | 07:27 |
JamesTait | Good morning all; happy Wonderful Weirdos Day! 😝 | 08:30 |
=== greyback|eod is now known as greyback | ||
fgimenez | hi Chipaca, can you please take a look at https://code.launchpad.net/~fgimenez/snappy/comment-rc-local-crash-test/+merge/270485 ? | 08:54 |
* Chipaca looks | 08:55 | |
Chipaca | fgimenez: ouch | 08:56 |
fgimenez | Chipaca, yep :) commenting it again should be enough by now | 08:58 |
fgimenez | Chipaca, thx, trying elopio's serve_daemon_test now | 09:03 |
Chipaca | wily edge update just jammed with “[ 7.021077] FAT-fs (sda2): IO charset iso8859-1 not found” | 10:05 |
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:08 |
ppisati | Chipaca: BBB? | 10:45 |
Chipaca | ppisati: kvm | 10:45 |
Chipaca | amd64 | 10:45 |
ppisati | and why the kernel can't load the module? | 10:46 |
ppisati | Chipaca: ^ | 10:46 |
Chipaca | ppisati: how would i know? :) | 10:47 |
Chipaca | it might be a download problem though | 10:47 |
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:48 |
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:50 |
mvo_ | Chipaca: anything unusual in the upgrade, i.e. out-of-space on boot or something like this | 10:51 |
* ppisati -> out for lunch, biab | 10:52 | |
Chipaca | nope | 10:54 |
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:55 |
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:56 |
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:57 |
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:58 |
ogra_ | hmm, it definitely loads an initrd there | 10:59 |
ogra_ | doesnt seem corupt either | 10:59 |
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:02 |
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:03 |
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:04 |
Chipaca | ogra_: apparently not | 11:09 |
ogra_ | grub.cfg doesnt set it by default ? | 11:09 |
Chipaca | it does have an initrd stanza | 11:09 |
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:10 |
ogra_ | in any case the system shouldnt hang in such situations but reboot back into the other partition | 11:11 |
Chipaca | mvo_: replied to your comments | 11:18 |
mvo_ | Chipaca: heh, looks like we should include the link to gustavos blog post as a comment when tomb is included :) | 11:21 |
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:22 |
mvo_ | Chipaca: uh, ok. lalalala | 11:24 |
Chipaca | added a nice long comment to the api checker test | 11:24 |
ogra_ | hmm | 11:53 |
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:54 |
ogra_ | (beyond hacking something in via snappy config) | 11:55 |
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) | 11:56 |
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:00 |
sergiusens | mvo_, did you do a release of snappy into wily? | 12:14 |
* sergiusens wants to rebuild u-d-f with it | 12:14 | |
mvo_ | sergiusens: not yet, can do so in a bit | 12:15 |
sergiusens | mvo_, sounds good | 12:15 |
mvo_ | sergiusens: uploaded | 12:31 |
Chipaca | tests pass \o/ | 12:37 |
Chipaca | ~> lunch | 12:37 |
ogra_ | grmbl ... the out of space thing is really annoying | 12:37 |
* ogra_ spent the last 30min trying to update his rolling image | 12:38 | |
* 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:43 |
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:44 |
ogra_ | but it took a few attempts | 12:45 |
ogra_ | (and it is super annoying that it downloads the rootfs every time ) | 12:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 12:59 |
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:00 |
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:01 |
ogra_ | rickspencer3, oops | 13:02 |
ogra_ | err | 13:02 |
ogra_ | ricmm, | 13:02 |
* ogra_ moves to office, sorry | 13:02 | |
=== fionnan_ is now known as fionnan | ||
yashi_ | hmm..., when an amd64 snappy image created with u-d-f does not boot with qemu, where should I look? | 13:05 |
Guest30312 | uh new toy https://uappexplorer.com/app/plano-amd64.canonical | 13:06 |
Chipaca | Guest30312: you forgot to set your nick :) | 13:19 |
Guest30312 | Chipaca, this is my nick :)) | 13:20 |
ogra_ | yashi_, how does it not boot ? | 13:20 |
ogra_ | (errors etc ? ) | 13:20 |
=== Guest30312 is now known as o | ||
o | oOoOOo | 13:21 |
=== o is now known as Guest81846 | ||
yashi_ | ogra_: no errors, cpu temp up, no output. I must have done something wrong. | 13:22 |
yashi_ | ogra_: it should work with qemu, right? | 13:23 |
ogra_ | well, it definitely works with kvm here | 13:24 |
yashi_ | something like: qemu-system-x86_64 -enable-kvm -m 512 my.img | 13:24 |
ogra_ | kvm -m 512 -redir :8022::22 my.img | 13:25 |
ogra_ | thats what i use | 13:26 |
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:27 |
yashi_ | I just can't re-create it here on wily | 13:28 |
Chipaca | mvo_: seems we need to throw some packages at tarmac | 13:55 |
mvo_ | Chipaca: yeah, elopio or fgimenez can probably help, I have the info how to access tarmac somewhere too but already forgot where :/ | 13:57 |
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 | 13:59 |
mvo_ | fgimenez: neat | 14:02 |
ogra_ | mvo_, so my rolling image finally upgraded ... i see watchdog installed but i dont see any systemd units created for it | 14:04 |
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:05 |
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:07 |
ogra_ | would it be named the same in systemctl ? (or at least contain the old sysvinit name ?) | 14:08 |
* ogra_ is a bit lost here | 14:10 | |
ogra_ | pitti, would the generator print anything in syslog ? | 14:15 |
pitti | systemctl | grep watch? you mean "sudo journalctl -f" perhaps? | 14:15 |
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:16 |
ogra_ | ok,, that prints more into syslog ... still no trace of watchdog though | 14:17 |
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:18 |
ogra_ | i see /etc/rc2.d/S03watchdog when looking in the dirs | 14:19 |
* ogra_ sighs | 14:24 | |
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:26 |
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:27 |
pitti | ogra_: right, as long as it's enabled and has some working LSB header it should work | 14:28 |
ogra_ | Ignoring S03watchdog symlink in rc2.d, not generating watchdog.service. | 14:29 |
ogra_ | aha | 14:29 |
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:30 |
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:31 |
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:32 |
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:33 |
ogra_ | hmm | 14:36 |
ogra_ | watchdog doesnt start automatically though ... even though it is enabled in /etc/default/watchdog | 14:36 |
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:37 |
ogra_ | yeah, /lib/systemd/system/watchdog.service has cleraly messed up qquoting | 14:41 |
ogra_ | http://paste.ubuntu.com/12321213/ | 14:41 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 14:59 |
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:00 |
davmor2 | ogra_: is this how you ^5 backs? https://xrixterweb.wordpress.com/2013/04/07/ncis-the-agent-gibbs-slapgif-images/ | 15:02 |
pitti | davmor2: oh gawd, you read too much internet! :-) | 15:04 |
davmor2 | pitti: :) | 15:05 |
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:10 |
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:24 |
davmor2 | pitti: 17:00 your time or UTC | 15:26 |
pitti | davmor2: mine | 15:27 |
pitti | i. e. 1500 UTC | 15:27 |
davmor2 | pitti: nevermind then :) | 15:27 |
ogra_ | zyga, no plans | 15:28 |
ogra_ | we need to include it and it needs to work ... thats all | 15:28 |
=== chihchun is now known as chihchun_afk | ||
rickspencer3 | hey, is pwm supported by snappy on raspberry pi 2? | 15:58 |
elopio | Chipaca: still having problems with tarmac? | 15:58 |
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 ? | 15:59 |
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:00 |
rickspencer3 | at least I got a normal GPIO pin to work ;) | 16:01 |
ogra_ | rickspencer3, might be thats missing in the kernel then | 16:02 |
ogra_ | ask ppisati | 16:02 |
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:03 |
ppisati | rickspencer3: what did you do to get a "panic: gpio: pwm not supported on this host"? | 16:04 |
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:05 |
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:06 |
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:07 |
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:08 |
* ppisati goes to pick up the car from the garage | 16:10 | |
fgimenez | elopio, ok, leaving, see you tomorrow | 16:13 |
fgimenez | nice evening everyone o/ | 16:13 |
=== greyback is now known as greyback|eod | ||
Chipaca | ok, off to a parents' evening. Will bb(m)l. | 16:56 |
sergiusens | mvo_, here's another one https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/modprobe-orig-files/+merge/270579 | 18:45 |
sergiusens | :-) | 18:45 |
stgraber | mvo_: hey, what am I doing wrong? http://paste.ubuntu.com/12322788/ | 18:52 |
stgraber | mvo_: seems to fail on a particular file for some reason | 18:55 |
elopio | sergiusens: where do I get this? | 18:56 |
elopio | pkg-checkbuilddeps: Unmet build dependencies: golang-uboot-go-dev | 18:56 |
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:57 |
mvo_ | stgraber: if you could mail me the failing file I will inspect and fix tomorrow morning | 18:58 |
mvo_ | sergiusens: I look at your two branches now | 18:59 |
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:05 |
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:06 |
mvo_ | stgraber: I will make a not about it (plus a note about the string concat) and look into fixing it tomorrow morning | 19:07 |
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:09 |
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:10 |
sergiusens | mvo_, in any case we may not want to do this at all in the future | 19:13 |
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:30 |
stgraber | :) | 19:31 |
mvo_ | stgraber: lp:~mvo/snappy/snappy-gettext-fixes should contain the fixes, please let me know by mail if you notice any regression(s) | 20:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!