=== ezobn1 is now known as ezobn
=== ezobn1 is now known as ezobn
[07:06] <fgimenez> good morning
[07:10] <dholbach> good morning
[07:58] <mvo> fgimenez, Chipaca, ricmm: image r152 should be good for testing
[08:06] <fgimenez> mvo, ok thanks, on it
[08:08] <fgimenez> mvo, 147 for armhf, right?
[08:13] <mvo> fgimenez: I have not build a armhf image with the latest snappy for 15.04 yet, I started that some minutes ago, wanted to verify on amd64 first
[08:13] <mvo> and there were a bunch of integration issues, but hopefully all good now
[08:14] <fgimenez> mvo, ok
[08:14] <mvo> fgimenez: there a some version (r151, r150) that are broken and will not work with system-image-cli correctly, just fyi when you do rollback testing
[08:15] <fgimenez> mvo, ok, should it work from r149?
[08:16] <mvo> fgimenez: yeah, that sounds good, from the latest you have faith in :)
[08:16] <mvo> fgimenez: to r152 or later and it should be good
[08:17] <fgimenez> mvo, :) ok i'll let you know how it goes
[08:17] <mvo> thanks
[08:27] <Chipaca> mo'in, whippersnappers!
[08:27]  * Chipaca adds a "whipper" subcommand
[08:27] <mvo> hey Chipaca - new 15.04 is ready
[08:27] <Chipaca> mvo: so i hear :) congrats
[08:27] <Chipaca> mvo: i also hear it's been painful
[08:27] <mvo> thanks, was a hard fight
[08:30] <Chipaca> mvo: there is go generate in 1.4
[08:30] <Chipaca> mvo: 15.04 has go 1.3
[08:31] <Chipaca> oh dear
[08:31]  * Chipaca is pedantic today
[08:31] <mvo> yeah
[08:31] <mvo> meh
[08:32] <JamesTait> Good morning all; happy Tuesday, and happy International Dot Day! 😃
[08:33] <Chipaca> mvo: wait, it worked with xreadPassword and not with readPassword?
[08:33] <Chipaca> or am i misunderstanding somehting
[08:33]  * ogra_ notes that mvo did quite some imae builds :)
[08:36] <mvo> Chipaca: yes
[08:36] <mvo> Chipaca: thats exactly it, I still have not tracked that down, but will soon
[08:38] <fgimenez> mvo, rolling back from 153 to 149 doesn't seem to work http://paste.ubuntu.com/12416211/
[08:41] <mvo> fgimenez: hrm hrm hrm
[08:46]  * mvo tries to reproduce
[08:47] <ogra_> mvo, more kids ? oO
[08:47] <Chipaca> JamesTait: ⡧⢼⡮⢵⡯⡯⢱⠁  ⣏⠆⢎⡱⢹⠁⠮⡲⡃
[08:47] <ogra_> (and you really dont need to tell us)
[08:48] <JamesTait> Impressive, Chipaca!
[08:48] <Chipaca> JamesTait: sorry for not even trying to write "international" :)
[08:49] <Chipaca> ogra_: maybe we should tell him about getting off irc for that, also
[08:51] <ogra_> Chipaca, true true ... germans ... tsk
[08:52] <Chipaca> ogra_: ooh! did you know "tsk" and "tut" are american and british ways of writing the same ("dental click") sound?
[08:52] <ogra_> hah, nope :)
[08:52] <Chipaca> me neither
[08:53] <Chipaca> https://en.wikipedia.org/wiki/Dental_clicks
[08:54] <ogra_> heh, that page makes me wanting to do a handstand to read it
[08:54] <ogra_> all that phonetic upside down stuff :)
[08:54] <mvo> fgimenez: r152->153->152 seems to work, I'm downloading 149 now
[08:56] <ogra_> looks like my amd64 installed system  has properly updated from 148 to 151 via autopilot over night :)
[08:59] <fgimenez> mvo, ok i'll try that path too, the integration suite is passing on 153
[09:00] <fgimenez> but including fake updates, i'll try it now with real updates and executing from a rollback
[09:06] <Chipaca> mvo: we don't need https://code.launchpad.net/~mvo/snappy/15.04-services/+merge/270965 now do we?
[09:07] <mvo> Chipaca: indeed, no
[09:08] <Chipaca> mvo: https://code.launchpad.net/~mvo/snappy/snappy-lp1490574-systemd-type-forking/+merge/270142 could use a bit of love
[09:11] <mvo> fgimenez: I think I found the issue, for some reason the boot-ok job seems to have not triggered
[09:12] <mvo> Chipaca: will do once I found the root cause for the rollback problem
[09:12] <Chipaca> ayup
[09:15] <mvo> pitti: did anything change between vivid and wily re "After=multi-user.taget"? I changed the ubuntu-snappy.boot-ok.service to have after=multi-user.target and that appears to be fine in wily (I can see that the service gets started and the output in wily but on vivid I don't see it starting, just that its active
[09:16] <pitti> mvo: "active" means that it started -- perhaps you mean "enabled"?
[09:16] <pitti> mvo: nothing wrt. After=, Requires= or enablement changed, but maybe the enablement link somehow got dropped in vivid?
[09:17] <mvo> pitti: http://paste.ubuntu.com/12416363/ is what I see on vivid
[09:17] <pitti> mvo: can you pastebin the journal?
[09:18] <fgimenez> mvo, great! thanks :) the rest of tests seem to be fine so far
[09:18] <pitti> mvo: that's not affected by the "too late bind mounting" issue, right? (as /etc/systemd/ gets bind-mounted in initramfs already0
[09:18] <mvo> pitti: yeah, it gets bind mounted early
[09:18] <mvo> pitti: http://paste.ubuntu.com/12416373/
[09:19] <pitti> mvo: systemctl cat ubuntu-snappy.boot-ok.service
[09:19] <pitti> mvo: find /etc/systemd -name '*boot-ok*'
[09:20] <pitti> mvo: nevermind
[09:20] <pitti> Breaking ordering cycle by deleting job ubuntu-snappy.boot-ok.service/start
[09:20] <mvo> pitti: ohhh
[09:20] <mvo> pitti: \o/
[09:20] <pitti> mvo: so cat'ing the unit would help
[09:21] <ogra_> pitti, just FYI https://launchpadlibrarian.net/217937303/initramfs-tools-ubuntu-core_0.7.7~ppa6_0.7.7~ppa7.diff.gz
[09:21] <mvo> pitti: http://paste.ubuntu.com/12416384/ <- its the wantedby=gettey, right?
[09:21] <mvo> hm, no
[09:22] <pitti> ogra_: nice!
[09:22] <ogra_> pitti, i'm considering moving all the bind mounts to that next iteration
[09:22] <mvo> ogra_: I was wondering about this too, I don't think it matters much but why have two places if one is sufficient
[09:23] <ogra_> right
[09:23] <pitti> mvo: ah, yes indeed -- getty.target wants boot-ok, but this runs after multi-user; maybe newer versions accept this kind of mixed wants/after cycle, but not yet vivid's?
[09:23] <pitti> mvo: or do you get a different cycle on wily, and it's just pure luck?
[09:23] <ogra_> and who knows what other races we might cause by mounting half of them later
[09:24] <mvo> pitti: yeah, now I just need to figure out what Install synatx to use instead of getty.target
[09:24] <pitti> ogra_: do we have fsck of the /writable partition in initramfs?
[09:24] <pitti> mvo: multi-user.target doesn't work?
[09:24] <mvo> we do
[09:24] <mvo> pitti: simply wantedby=multi-user.target ? or removing the wantedBy entirely?
[09:24] <ogra_> pitti, yeah, a few lines before the function above gets called
[09:24] <pitti> mvo: no, WantedBy=multi-user.target instead of getty.target (not sure why it's getty)
[09:25] <mvo> cool, will do
[09:25] <mvo> probably a historic accident
[09:25] <mvo> i.e. not talking to the right people :-D
[09:25]  * mvo hugs pitti
[09:25] <ogra_> pitti, http://paste.ubuntu.com/12416406/ ... handle_writable_paths does the mounting
[09:26] <ogra_> the mount/umount to speed up e2fsck is a funny trick
[09:26] <ogra_> (and works really well)
[09:27] <dholbach> tedg, do you know what's happening here? https://bugs.launchpad.net/snapcraft/+bug/1495525
[09:27] <ubottu> Launchpad bug 1495525 in Snapcraft "qml plugin: example is broken" [Undecided,New]
[09:35] <mvo> Chipaca: I woder if the rollback issue could be releated to the new static grub.cfg
[09:35] <Chipaca> oh!
[09:35] <Chipaca> maybe?
[09:35]  * mvo looks deeper
[09:36] <Chipaca> mvo: i'd suggest waiting for sergio on that one, as he'd know without looking :)
[09:36] <Chipaca> it's possible we said "no rollback from this change"
[09:36] <Chipaca> but i think the new static grub should deal with it as long as there's a versionless symlink
[09:36] <Chipaca> which there used to be, at leastr
[09:38] <mvo> Chipaca: hmm, looks like we have the old non-static grub.cfg in /boot/grub/grub.cfg :(
[09:42] <Chipaca> mvo: woo :-p
[09:59]  * guest42315 aw-food
[10:01] <mvo> Chipaca:  http://paste.ubuntu.com/12416556/ <- not looking great
[10:03] <ogra_> mvo, uuh Bug 1495688 i see that too here (seems we have more fish to fry )
[10:03] <ubottu> bug 1495688 in Snappy "system-image-cli tool fails on rolling/edge; missing file '/etc/system-image/config.d/00_default.ini" [Undecided,New] https://launchpad.net/bugs/1495688
[10:04] <Chipaca> ogra_: there's a dangling symlink
[10:05] <ogra_> hmm, not related to recent changes though ... my RPi image from sept. 2 has it too
[10:05] <ogra_> Chipaca, yes, but why
[10:05] <ogra_> it should ship client.ini
[10:06] <ogra_> aha
[10:06] <ogra_> should come from system-image-common
[10:06]  * ogra_ checks the manifest 
[10:06] <mvo> Chipaca: so we may need this services backport branch afterall
[10:07] <ogra_> hmm
[10:07] <ogra_> system-image-common is installed in the latest image
[10:08] <ogra_> oh
[10:08] <Chipaca> mvo: D:
[10:08] <ogra_> my phone only has system-image 2.5.1 ... snappy has 3.0.1 ... (both on vivid)
[10:10] <Chipaca> mvo: can we ship an override to update-grub that does something useful?
[10:15] <Chipaca> ohh
[10:15] <Chipaca> mvo: we're calling the _old_ update-grub on update?
[10:15] <Chipaca> or are we calling the new one?
[10:16] <mvo> Chipaca: we call the new one, maybe this could work http://paste.ubuntu.com/12416613/
[10:17] <mvo> Chipaca: or simpler, we make the new update-grub write the static config and loose the ability to rollback (because the kernel will not be in /boot/grub/b
[10:17] <mvo> )
[10:19] <dholbach> https://code.launchpad.net/~dholbach/snapcraft/fix-for-empty-stage_packages-in-plugins/+merge/271090
[10:19] <dholbach> https://code.launchpad.net/~dholbach/snapcraft/small-typo/+merge/271086
[10:20] <Chipaca> mvo: maybe we can make a release note about rollback not working
[10:20] <mvo> Chipaca: just making 09_snappy write the new static conf and stop would be ideal, least risky option but no rollback
[10:20] <ogra_> mvo, oh ... do we need to seed system-image-snappy-common ?
[10:20] <mvo> ogra_: why?
[10:20] <ogra_> mvo, system-image-common does not ship any client.ini file anymore
[10:21] <ogra_> and i also assume we want the client.ini for snappy, not the phone one
[10:21] <mvo> ogra_: we can ship it in ubuntu-core-config then
[10:21] <mvo> ogra_: and we actually should do that already as 20_snappy iirc
[10:21] <ogra_> fine with me too ... currently system-image-cli only throws exceptions
[10:21] <ogra_> (on 15.04 edge that is)
[10:24] <mvo> ogra_: system-image-cli -v work for me on 154 (I also see the broken symlink)
[10:24] <ogra_> mvo, and -i ?
[10:25] <mvo> ogra_: that explodes indeed
[10:25] <ogra_> -v gets me a ton of permission denied errors (it shoudlnt)
[10:26] <ogra_> hmm, ignore that ... happens on the phone too
[10:26] <ogra_> i thought that uses the dbus backend so it doesnt need sudo
=== kickinz1 is now known as kickinz1|lunch
[10:46] <fgimenez> mvo, should i file a bug about the rollback issue?
[10:47] <mvo> fgimenez: a good question, I think its understood, the hard questions is now what to do about it
[11:19] <sergiusens> dholbach, thanks for the branches!
[11:19] <sergiusens> dholbach, btw, have you read the new intro? I hope it is to your liking ;-)
[11:24] <ogra_> workarounds for bug 1495688 and bug 1495683 uploaded
[11:24] <ubottu> bug 1495688 in Snappy "system-image-cli tool fails on rolling/edge; missing file '/etc/system-image/config.d/00_default.ini" [Undecided,New] https://launchpad.net/bugs/1495688
[11:24] <ubottu> bug 1495683 in Snappy "Drop /etc/profile.d/Z99-cloud-local-test.sh from Cloud target" [Undecided,New] https://launchpad.net/bugs/1495683
[11:32] <sergiusens> ogra_, they are called fixes ;-)
[11:32] <ogra_> lol
[11:32] <dholbach> sergiusens, the google doc or updated docs in the branch?
[11:33] <sergiusens> dholbach, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/your-first-snap.md
[11:33] <dholbach> sergiusens, great - I'll check it out - thanks a bunch!
[11:33] <sergiusens> dholbach, I need to add a config walkthrough and extend that more (to get a bit more of a complicated example) ;-)
[11:33] <sergiusens> dholbach, but it has all the new stuff trunk has already
=== kickinz1|lunch is now known as kickinz1
[11:40] <dholbach> sergiusens, what's still on your list for the 0.2 release?
[11:43] <sergiusens> dholbach, I think we are good to switch already
[11:44] <sergiusens> dholbach, well, I want my config branch in and to extend the docs
[11:44] <dholbach> ok cool
[11:44] <ogra_> mvo,  triggering an image to make sure the file removals worked
[11:44] <dholbach> just asking to get an idea of what's planned :)
[11:48] <sergiusens> dholbach, soon after comes an interesting feature ;-)
[11:49] <dholbach> sergiusens, which one
[11:49] <dholbach> ?
[11:50] <Chipaca> anybody got a snap with an invalid yaml lying around?
[11:50] <Chipaca> wanting to test some error reporting
[11:51] <Chipaca> elopio: fgimenez: you, by chance? ^
[11:52] <sergiusens> Chipaca, just unpack and repack ;-)
[11:53] <Chipaca> sergiusens: how do i repack? trying with "ar" i can never get it to work
[11:53] <fgimenez> Chipaca, there's an integration test for that, but iirc it generates the wrong yaml on the fly, let me check
[11:53] <Chipaca> and snappy build won't let me build a broken one :)
[11:53] <ogra_> Chipaca, ar and snappy build indeed
[11:54] <ogra_> oh
[11:54] <Chipaca> i'm wanting to build a snap with an *invalid yaml* :)
[11:54] <Chipaca> snappy build is not down with that
[11:54] <ogra_> yeah, only read the last line after typing
[11:54] <Chipaca> i can build subtly broken ones, but not "aiee yaml parser kaput" broken ones
[11:55] <Chipaca> and that just happens to be an error case unlike others
[11:55] <sergiusens> Chipaca, I thought dpkg-deb would do the trick
[11:55] <Chipaca> in that it's a 500 error, from a yaml, in an async handler
[11:56] <Chipaca> trying dpkg-deb...
[11:58] <fgimenez> Chipaca, sorry nope, the test just check that actually you can't build it http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/tests/build_test.go#L75
[11:58] <Chipaca> fgimenez: sergiusens: ogra: dpkg-deb -R, and dpkg-deb --nocheck -b, do the trick
[12:17] <Chipaca> http://pastebin.ubuntu.com/12417202/
[12:17] <Chipaca> \o/
[12:18] <Chipaca> ^ that's what the rest api thinks of you having a fortune instead of yaml
[12:19] <Chipaca> (that's with my still in-progress "give context to errors" branch)
[12:32] <sergiusens> Chipaca, \o/
[12:48] <ogra_> hmm
[12:49] <ogra_> neither /etc/system-image/config.d/00_default.ini nor /etc/profile.d/Z99-cloud-local-test.sh seem to exist at build time (i see the sccript to remove them being executed during build but it doesnt rm any files)
[12:49] <ogra_> i wonder where they come from if not the build
[12:51]  * ogra_ twiddles thumbs waiting for the importer 
[13:18] <dholbach> davidcalle, which articles were you working on?
[13:19] <dholbach> davidcalle, is there any stuff which should go into the individual branches? or will it be just for developer.u.c?
[13:19] <Chipaca> darn, yesterday i was able to make the yaml parser panic, but today i can't reproduce it
[13:19] <Chipaca> should've written down the yaml
[13:19] <davidcalle> dholbach, not me directly, but some new snappy doc being written. Just duc :)
[13:19] <dholbach> ok
[13:19] <davidcalle> not *by me
[13:21] <tedg> dholbach: No, are you on vivid? Perhaps things changed in wily.
[13:21] <dholbach> tedg, I'm on wily, yes
[13:22] <dholbach> tedg, would it make sense to let qml snaps just depend on ubuntu-sdk-libs?
[13:23] <tedg> dholbach: No, not really. The SDK requires a lot more than we can support today.
[13:25] <dholbach> ok, I was just wondering it we could simplify the list of packages in snapcraft/plugins/qml.py somehow
[13:26] <rickspencer3> does anyone know what I need to do figure out what to hw-assign so that my snap can use gpio pins on the rpi2?
[13:26] <rickspencer3> jdstrand, ^ ?
[13:26] <rickspencer3> apparmor only reports net_admin getting denied
[13:30] <ogra_> sigh !
[13:30] <mvo> sergiusens, Chipaca: do you think https://code.launchpad.net/~mvo/snappy/snappy-all-for-15.04 covers the bases? I want to tidy it a bit more and I think its good but a second opinion from an expert would be great
[13:31] <ogra_> (amd64)ogra@aleph2:~$ ls -l /etc/system-image/config.d/00_default.ini
[13:31] <ogra_> lrwxrwxrwx 1 root root 13 Sep 15 15:26 /etc/system-image/config.d/00_default.ini -> ../client.ini
[13:31] <ogra_> (amd64)ogra@aleph2:~$
[13:31]  * ogra_ doesnt get where it comes from, it doesnt seem to exist at rootfs build time 
[13:32] <sergiusens> mvo, you don't like asking questions with simple answers, eh? :-)
[13:33] <Chipaca> mvo: i agree, we need an opinion from an expert.
[13:33] <Chipaca> mvo: we're going to have to go find one
[13:33] <mvo> lol
[13:33] <ogra_> do we have spare headcount to hire one ?
[13:34] <ogra_> job description "expert"
[13:34] <mvo> I think its good, it just needs its own (blocking) systemd-job to ensure everything is in place before the user can hit the commandline
=== ezobn1 is now known as ezobn
[13:34] <ogra_> GRRR ... so calling [ -e ... ] on a dangling symlink isnt the cleverest of things
[13:35] <tedg> dholbach: I think it does make sense to do some sort of meta-package, but the SDK has too much other stuff in it.
[13:35]  * ogra_ switches to -L
[13:35] <mvo> ogra_: if you have spare cycles, system-image.ubuntu.com//pool/device-f6dbcd89372ad1bd2b6a37df25b2e02fae38530d92c9ebd541bf327c27048794.tar.xz has also some danling symlinks in assets/vmlinuz
[13:35]  * mvo dives back into grub
[13:36] <dholbach> tedg, I thought ubuntu-sdk-libs was just the stuff phone apps could know to expect around
[13:36] <ogra_> ARGH !
[13:36] <Chipaca> mvo: that code seems correct, but i'd test it all the ways
[13:36] <ogra_> copy pasting a filename with typo out of a bug report isnt so clever either
[13:37]  * ogra_ should take the day off 
[13:37] <tedg> dholbach: Sure, but we don't want all of those things for a QML snap. We can't provide all the services that they require. That's gotta be provided by the U8 framework.
[13:38] <dholbach> ok
[13:41] <rickspencer3> jdstrand, could you take a look and let me know why I am seeing the denial here, considering what is in my apparmor profile?
[13:41] <rickspencer3> http://pastebin.ubuntu.com/12417599/
[13:41] <jdstrand> rickspencer3: sorry, in a meeting
[13:41] <jdstrand> be bak in a minute
[13:41] <rickspencer3> k
[13:49] <jdstrand> ok, back
[13:51] <jdstrand> rickspencer3: instead of /sys/devices/platform/soc/3f200000.gpio, use /sys/devices/platform/soc/3f200000.gpio/**
[13:52] <ogra_> ok ... since all good things in life are three ...
[13:52]  * ogra_ triggers the third image for that file removal stuff
[13:54] <rickspencer3> ok, I'll try that
[13:58] <rickspencer3> jdstrand, the only difference is the *?
[13:58] <rickspencer3> because I am still seeing the denial
[13:58] <rickspencer3> jdstrand, I just added /* to the app armor profile and reparsed it
[13:58] <rickspencer3> I didn't do hw-assign again
[13:59] <ogra_> it is /** not /*
[13:59] <jdstrand> rickspencer3: use '**'. not '*'
[13:59] <jdstrand> s/\.//
[14:00] <rickspencer3> oops, text wrapping in xchat :/
[14:00] <jdstrand> but yes
[14:01] <jdstrand> the /sys/devices/platform/soc/3f200000.gpio/** means 'everything under (but not including) /sys/devices/platform/soc/3f200000.gpio'
[14:01] <mvo> pitti: I assume "before=multi-user.target" and "wnatedby=multi-user.target" is safe and will ensure my service has finished before a user can login?
[14:22] <fgimenez> ogra_, with these changes https://code.launchpad.net/~fgimenez/snappy/resize_test2/+merge/271131 the resize test works (and passes) on 15.04, r155 :)
[14:22] <ogra_> fgimenez, yay
[14:23] <mvo> ogra_: http://paste.ubuntu.com/12417786/ should hopefully fix the broken symlinks in assets/ that I saw earlier. its basicly just a forward port of the wily code, but a second pair of eyes would be great
[14:24] <ogra_> mvo, can we copy the config too if we copy abi  and System.map ?
[14:25] <mvo> yeah
[14:25] <ogra_> mvo, looks fine otherwise
[14:26] <ogra_> i still fight with /etc/system-image/config.d/00_default.ini :(
[14:28] <ogra_> i dont get why
[14:33] <pindonga> mvo, hi there, remember that bug about supporting forking services in systemd unit files? I saw the mp pending review... is there anything blocking that?
[14:38] <mvo> just lack of tme, shoud land rsn
[14:38] <pitti> mvo: before/wantedby is the usual combination indeed
[14:39] <pitti> mvo: but stuff in multi-user.target can happen after gettys; if you strictly want "before users can log in", you want Before=systemd-user-sessions.service (WantedBy=multi-user.target is still okay)
[14:40] <pitti> mvo: the thing that seems to cause loops/trouble is if you order (After=) a service *past* a target it's wanted in; before is always fine
[14:40] <mvo> thanks
[14:41] <clobrano> hi there, I'm looking for info sources about installing udev rules in snappy (other than using hw-assing). Any suggestion? :)
[14:49] <pindonga> mvo, ack, thx
[14:54] <sergiusens> Chipaca, mvo dholbach https://code.launchpad.net/~sergiusens/snapcraft/wiki/+merge/271140
[14:55] <fgimenez> ogra_, on bbb i'm getting this while executing the resize test http://paste.ubuntu.com/12417958/
[14:57] <fgimenez> ogra_, this is the script used http://bazaar.launchpad.net/~fgimenez/snappy/resize_test2/view/head:/_integration-tests/scripts/install-test-initramfs
[14:58] <ogra_> fgimenez, thats not the initrd
[14:58] <ogra_> you want the one under /boot/uboot
[14:59] <fgimenez> ogra_, ok i'll fix that, thanks! :)
[15:03] <dholbach> sergiusens, replied
[15:07] <sergiusens> dholbach, thanks, replied (I wasn't part of the discussion either fwiw) :-)
[15:07] <dholbach> :)
[15:13] <dholbach> sergiusens, the summary of the example package is still a bit weird, but apart from that it looks good to me
[15:16] <sergiusens> dholbach, oh, if you have a better suggestion; just go ahead :-)
[15:16] <dholbach> maybe I just don't understand it :)
[15:16] <dholbach> sergiusens, is it meant to say "downloader"?
[15:17] <dholbach> or "downloaded"?
[15:17] <dholbach> I mean I'm nitpicking - the rest looks fine AFAICT :)
[15:17] <sergiusens> dholbach, yeah, the package name is downloader and it downloads from the wiki to create it
[15:18] <sergiusens> dholbach, I should of not worked on a downloader snap for this I guess :-)
[15:18] <sergiusens> dholbach, oh, but now I see the typo
[15:18] <dholbach> <3
[15:18] <sergiusens> :-)
[15:20] <sergiusens> dholbach, now that's fixed
[15:21] <dholbach> sergiusens, approved
[15:41] <fgimenez> Chipaca, is this a good source of info for integration tests of the api http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/daemon/api_test.go ? is there anything else not covered there?
[15:49] <mvo> pitti: hi, sorry for bothering you again, I added a new service to snappy, its configured exactly like the boot-ok service and yet http://paste.ubuntu.com/12418278/
[15:52] <pitti> mvo: any cycle in the journal? can you please cat the unit?
[15:52] <mvo> ogra_: more ininitramfs troubel it seems, /etc/systemd/system is a writable path, it contains a symlink in getty.target.wants to boot-ok which I removed from the image but because its a writable path with transition the file is never removed
[15:52] <pitti> mvo: ah, but this one is disabled too -- did you actually systemctl enable (or update-rc. enable) it?
[15:53] <mvo> pitti: http://paste.ubuntu.com/12418301/ is the journal
[15:53] <ogra_> mvo, yeah, what i said during the meeting :)
[15:53] <ogra_> we dont have any way to remove such files yet
[15:54] <mvo> ogra_: I bet thats the same issue for migrate-grub, its a new file in multi-user.tar.get.want but its not copied up too
[15:54] <pitti> mvo: ah, so I suppose that's related to "can't remove symlinks"?
[15:54] <mvo> pitti: http://paste.ubuntu.com/12418313/
[15:55] <pitti> mvo: I suppose you just didn't enable this then?
[15:55] <mvo> pitti: yeah, I think its exactly this, /etc/systemd/system/multi-user.target.wants is in mode "transitional" but after the initial copy I think it never updates new files or deletes files so we are lost
[15:55] <mvo> pitti: it should be enabled via the deb, let me double check
[15:56] <ogra_> \o/ ...
[15:56] <ogra_> ok, the most recent rootfs only has 20_snappy.ini in the system-image/conf.d dir
[15:58] <mvo> pitti, ogra_: so the image has the new ubuntu-snappy.grub-migrate.service but the bind mount over it hides it. thats pretty terrible if we can not add or change job and that we can't fix bugs like that there is a wrong getty.target.wants
[15:58]  * mvo scratches head
[15:59] <ogra_> hmm, did you try setting the dir to sync instead of transition ?
[15:59] <ogra_> (and reboot)
[16:00] <mvo> ogra_: I cross all fingers that I have
[16:00] <ogra_> well, else we need a hack in initrd
[16:01] <ogra_> actually it might be cool if we could use rsync instead of cp in that code ... that might fix some issues
[16:05] <mvo> ogra_: no, synced does not help at all :/
[16:05] <ogra_> :(
[16:06] <seb128> mvo, you noticed that the snappy update in wily is depwait on goget-ubuntu-touch which depwait on golang-uboot-go-dev?
[16:10] <mvo> ogra_: hm, looking at the source synced should work, it should at least make my files appear
[16:10] <ogra_> yes
[16:11] <ogra_> mvo,  even transition should work
[16:13]  * ogra_ doesnt get it 
[16:14] <ogra_> i wonder if we could force it with an extra "cp -u $redaonly-dir $writable-dir"
[16:20] <mvo> ogra_: so /etc/systemd/system/getty.target.wants/ubuntu-snappy.boot-ok.service needs to go and /etc/systemd/system/multi-user.target.wants/ubuntu-snappy.{grub-migrate,boot-ok}.service must appear
=== kickinz1 is now known as kickinz1|eod
=== kickinz1|eod is now known as kickinz1
[16:22] <ogra_> mvo, yeah, not sure how we should do that ... it seems to never update anything actually
[16:23] <ogra_> mvo, if i unmount the dir i also see a webdm service that got never copied
[16:24] <mvo> ogra_: yeah, I'm not suggesting to hack it, jsut do document the issue
[16:24] <mvo> ogra_: pretty alarming
[16:24] <ogra_> yes
[21:07] <cyphermox> ogra_: ricmm: could you please let me know when we have a rolling image with fwupdate included?
[21:07] <cyphermox> we'd shoud probably include fwupd too.
[21:07] <cyphermox> zomg, I can't type.
[21:08] <ogra_> whats that ?
[21:08] <ogra_> (firmware ? firewall ? )
[21:09] <ogra_> (funny witches)
[21:11] <cyphermox> firmware.
[21:11] <cyphermox> disregard fwupd for now since it's not even in Debian.
[21:17] <ogra_> heh
[21:17] <ogra_> cyphermox, thats for bluez ?
[21:18] <cyphermox> no. it's for firmware updating magic in the EFI specification
[21:18] <cyphermox> as in, permanent updates :)
[21:18] <ogra_> ah, shudder ,... you said EFI
[21:18] <cyphermox> it's the future.
[21:18]  * ogra_ pets uboot 
[21:19]  * cyphermox kicks uboot :)
[21:19] <ogra_> hey !
[21:19] <ogra_> :)
[21:19] <ogra_> our grub setup is closer to uboot than to anything else nowadays :)
[21:20] <sergiusens> \o/
[21:20] <ogra_> \o/
[21:20]  * ogra_ joins the yoga class
[21:20] <cyphermox> ogra_: you can do some very cool magic with grub and EFI.
[21:20] <ogra_> nah, i cant :)
[21:21] <ogra_> but i can do some very cool magic with uboot :)
[21:22] <cyphermox> ok then, I can :)
[21:22] <ogra_> heh
[21:22] <ogra_> yeah, and i'm happy i know whom to poke if it comes to grub ;)
[21:23] <ogra_> tough in regard to snappy ...
[21:23] <ogra_> (amd64)ubuntu@localhost:~$ wc -l /boot/grub/grub.cfg
[21:23] <ogra_> 54 /boot/grub/grub.cfg
[21:24] <ogra_> we dont really have much there :)
[21:24] <ogra_> (static file btw)
[21:26] <cyphermox> feel free to ask me