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