[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: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: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
[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: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
[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
[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
[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


[00:07] <duanedesign> newboon2age_: yeah that is an 'upstream' bug report so only people associated with that project can assign importence
[00:07] <duanedesign> newboon2age_: the ubuntu project is: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client
[00:09] <newboon2age_> duanedesign: thank you for that.
[00:09] <newboon2age_> duanedesign: is your project in the .deb packaged stage yet?
[00:10] <duanedesign> newboon2age_: we should be doing that this weekend
[00:10] <newboon2age_> duanedesign: i'd like to check it out.  Tell me again (very briefly or point me somewhere) what it does?
[00:12] <duanedesign> newboon2age_: stipple backs up .config files to a couchdb. Ubuntu one then replicates those databases to all your computers. Then the program will put the .config files in the appropriatte places on the 'other' computers
[00:13] <duanedesign> there are quite a few plugins already for it. Writing new plugins is easy.
[00:13] <newboon2age_> and is a different plugin required for each different app?
[00:14] <newboon2age_> is it in python?
[00:14] <Chipaca> duanedesign: have you spoken with the guys doing oneconf at all?
[00:15] <duanedesign> Chipaca: yes i have
[00:15] <duanedesign> Chipaca: my project also backs up packages, so we shared notes
[00:16] <duanedesign> Chipaca: however once OneConf comes online i will probably phase out that feature.
[00:16] <Chipaca> duanedesign: ok
[00:18] <newboon2age_> duanedesign: does it require a different plugin for each different app?  are plugins written in python?
[00:18] <duanedesign> Chipaca: i think they are going to limit their project to packages and leave more 'advanced' uses like backing up config files to projects like stipple
[00:18] <duanedesign> newboon2age_: yes that is correct
[00:18] <Chipaca> duanedesign: great news
[00:19] <duanedesign> Chipaca: yes. didrocks has been super friendly and very helpful
[00:33] <Chipaca> I'm glad
[00:43] <Chipaca> vds: your network card sucks, you know? :)
[00:47] <duanedesign> newboon2age_: here is a recent screenshot.  It determines which plugins to load based on what packages you have installed. http://people.ubuntu.com/~duanedesign/stipple.SS.2.png
[00:57] <billday> For some reason the UbuntuOne music store thinks that I am in the EU rather than the US.  Is there a way to correct this?
[01:03] <Chipaca> billday: it's based on your IP address
[01:03] <Chipaca> billday: are you in some kind of vpn?
[01:04] <billday> Thank you.  I know it is based on the IP address.  I am not in a VPN, but I do sometimes use a proxy.
[01:04] <billday> It seems that I have managed to confuse the store.
[01:04] <billday> Can I unconfuse it?
[01:05] <newboon2age_> duanedesign: cool, i'll look forward to checking it out...
[01:10] <Chipaca> billday: just starting a new session should suffice
[01:11] <Chipaca> billday: i.e. restarting rhythmbox
[01:13] <billday> Chipaca:  OK, thanks, I'll give it another go.  Cheers.
[02:40] <korben> hello
[02:41] <korben> can i ask u all something about ubuntu one?
[02:46] <duanedesign> hello korben
[03:50] <josephnexus> could someone point me in the direction of the kubuntu client?
[03:57] <duanedesign> hello josephnexus
[04:00] <duanedesign> josephnexus: here is a recent thread on the forums by http://ubuntuforums.org/showthread.php?p=9535765#post9535765
[04:01] <duanedesign> josephnexus: newboon2age is in here fairly regularly. It is his/her post
[04:03] <duanedesign> josephnexus: also: https://answers.edge.launchpad.net/ubuntuone-client/+faq/594
[04:04] <duanedesign> josephnexus: the final link i have on the subject might be similar to the Launchpad FAQ. But just in case: http://maketecheasier.com/how-to-install-and-setup-ubuntu-one-in-kubuntu/2010/03/15
[04:33] <nuboon2Win> sorry, new to pidgin and it functions differently than i'm used to ..
[04:34] <nuboon2Win> apachelogger: can you give an update on the status of ubuntuone-kde ?
[04:35] <duanedesign> hello nuboon2Win
[04:36] <nuboon2Win> Chipaca: as an experiment i set up Portable Ubuntu and tried ubuntuone-client-gnome on it.  The results of my experiment so far are on http://ubuntuforums.org/showpost.php?p=9540830&postcount=2
[04:36] <duanedesign> josephnexus was just asking about U1 on KDE. I linked him to your forum post and the FAQ by joshua
[04:37] <nuboon2Win> duanedesign:  howdy, this is nuboon2age, i'm writing this from pidgin running on Portable Ubuntu on Vista.  Wierd huh?
[04:39] <duanedesign> yes, i have not tried portablew Ubuntu
[04:39] <duanedesign> nuboon2Win: what do you think?
[04:39] <duanedesign> like it
[04:40] <nuboon2Win> josephnexus: my experiment w/ ubuntuone-kde seems to be working despite the fact i got error messages when i was trying to install it (due to the fact i'd previously installed ubuntuone-client-gnome I'm pretty sure -- if i'd done a clean install i don't think i'd have too many problems).
[04:41] <nuboon2Win> duanedesign: Portable ubuntu seems to be working at least better than wine does.  its sort of like the reverse of wine.
[04:42] <nuboon2Win> duanedesign: i'm going to play with it anyway.  Ubuntu One only seems to see the top level files.  No nested files.
[04:42] <duanedesign> interesting
[04:43] <nuboon2Win> i'm thinking i may be able to workaround this by symbolic links.  Don't know yet...
[04:45] <nuboon2Win> it gives at least some of the experience of running Ubuntu (but from within Windoze).  Seems like it could be a good tool.  One of its claims to fame is that you can put it on a pen drive and have another way to run Ubuntu portably on different Windoze machines (in addition to the possibility of creating a bootable pen drive of course).
[04:46] <nuboon2Win> duanedesign: the 'tres' version i'm running is the latest and its based on Karmic
[04:49] <nuboon2Win> duanedesign: geeze i'm going to wake everyone by mistake... in Konversation i can test a nick before sending it, but in pidgin i guess one letter, return and i end up notifying everyone who'd nick starts with that letter...
[04:50] <duanedesign> heh
[04:51] <nuboon2Win> duanedesign: :)
[04:56] <nuboon2Win> duanedesign: can you take a sec and tell me about your ide and programming environment you're using for your project?  I'm interested in setting up a development environment for python, but i'm new to development on Ubuntu and python.  Any tips you could share?  Do you know if there is a sort of standard set up for the canonical developers?
[04:59] <duanedesign> there are certain things that are encouraged
[05:00] <duanedesign> python, Couchdb for persistence, GTK
[05:00] <duanedesign> i just use Gedit
[05:01] <duanedesign> http://okiebuntu.homelinux.com/okwiki/pythonquest
[05:01] <duanedesign> there is a little guide there for setting up Gedit
[05:01] <nuboon2Win> duanedesign: rats another who 'just uses Gedit' :)
[05:01] <duanedesign> if you have a solid foundation i would recommend quickly
[05:02] <nuboon2Win> duanedesign: oh that's a neat resource...  very cool...
[05:03] <nuboon2Win> duanedesign: how do you keep track of complex multi file projects w/ only Gedit?
[05:06] <nuboon2Win> duanedesign: Also, i'm wondering did you use quickly on your project?
[05:07] <duanedesign> i did not use quickly.
[05:07] <duanedesign> when i started it m it was a command line app
[05:08] <duanedesign> quickly is for GUI apps
[05:09] <nuboon2Win> duanedesign: oh, and how do you keep track of complex apps with lot's o library files and such w/ only Gedit?
[05:10] <nuboon2Win> duanedesign: or maybe your project is not as complex as some of the gui things are...
[05:10] <duanedesign> stipple has a gui now.
[05:10] <nuboon2Win> duanedesign: i'd like some aids to help me keep track of all the imports and such...
[05:11] <nuboon2Win> duanedesign: oh yeah that's right... duh
[05:11] <duanedesign> i also have another project. clicompanion
[05:11] <duanedesign> i have used IDLE, that is a popular IDE for python
[05:15] <nuboon2Win> is python your main language duanedesign?
[05:16] <duanedesign> yes. i am trying to learn more C
[05:16] <duanedesign> but there is enough in python to keep you busy for awhile :)
[05:17] <duanedesign> err, keep me busy
[05:17] <nuboon2Win> i saw that one of the ide's (can't remember if it was IDLE) allowed you to plug in whatever editor you wanted (could plug in Gedit for instance).  As an editor i've certainly liked Gedit (though I haven't done that much with it, just basic edits).
[05:19] <nuboon2Win> duanedesign: okay well i won't detain you further.  I appreciate your input, and look forward to seeing stiple in action...
[05:20] <duanedesign> nuboon2Win: been nice talking to you
[05:20] <nuboon2Win> duanedesign: thank you for all your irc support. :)
[08:57] <GeorgiusCz> hello, some ubuntuone developer here ? I have a tiny compilation question ...
[08:58] <GeorgiusCz> honk ... ?
[09:36] <Chipaca> GeorgiusCz: compilation of what?
[09:36] <Chipaca> GeorgiusCz: next time, just ask the question :)
[09:36] <lifeless> morning Chipaca
[09:38] <GeorgiusCz> Chipaca: I just wanted to be sure not to pose the question in the vacuum. I am trying to compile ubuntuone for N900 and I would like not to compile against nautilus - see https://bugs.edge.launchpad.net/ubuntuone-client/+bug/512052?comments=all
[09:38] <ubot4> Launchpad bug 512052 in ubuntuone-client "Support for maemo (Nokia n900) (affects: 60) (heat: 292)" [Wishlist,Confirmed]
[09:41] <Chipaca> GeorgiusCz: the only part you have to compile is the nautilus part (unless you count the protobuf)
[09:43] <Chipaca> GeorgiusCz: or do you mean build the package?
[09:44] <GeorgiusCz> no, just build  the sync daemon
[09:44] <Chipaca> the syncdaemon is just python
[09:44] <Chipaca> the protocol_pb.py is "compiled" from the protocol description (this is in ubuntuone-storage-protocol), but I believe we include the compiled version as well as the protocol description anyway
[09:45] <Chipaca> in other words: it should just work
[09:45] <GeorgiusCz> 8-o ...
[09:45] <Chipaca> have you tried running it?
[09:45] <Chipaca> PYTHONPATH=. bin/ubuntuone-syncdaemon --debug ?
[09:46] <GeorgiusCz> I have the source package (as N900 is ARM)
[09:47] <GeorgiusCz> going to test it in a scratchbox ...
[09:47] <Chipaca> I've got to have breakfast, and then do the checkout; I'm at the end of a weeklong sprint and a bit tired. email me how it went, and if something is broken, I'll try to fix it
[09:48] <Chipaca> ok?
[09:48] <Chipaca> GeorgiusCz?
[09:49] <GeorgiusCz>   File "bin/ubuntuone-syncdaemon", line 34     from ubuntuone.syncdaemon.config import (                                             ^ SyntaxError: invalid syntax
[09:49] <Chipaca> you need python 2.6
[09:49] <Chipaca> you *might* get away with 2.5
[09:50] <Chipaca> sounds like you have 2.2 or somehting :)
[09:50] <GeorgiusCz> no, 2.5
[09:50] <Chipaca> weird
[09:50] <Chipaca> ok, I'll bbl
[09:50] <GeorgiusCz> thanks so far
[10:15] <GeorgiusCz> oops, something weird with scratchbox ... going to test directly on the device
[10:27] <GeorgiusCz> So, python 2.5.4 - Syntax errror on line 73 (file bin/ubuntuone-syncdaemon) - args=args
[10:37] <Chipaca> GeorgiusCz: ok, 1 sec
[10:38] <Chipaca> GeorgiusCz: can you pastebin the whole traceback please?
[10:38] <GeorgiusCz> not easily, but I give it a try
[10:40] <Chipaca> ah
[10:40] <Chipaca> GeorgiusCz: ok, so, there is no args=args in ubuntuone-preferences
[10:40] <Chipaca> GeorgiusCz: so, I figure you're reading the traceback wrong
[10:40] <Chipaca> oh wait
[10:40] <Chipaca> why i am looking at -preferenecs?
[10:41] <GeorgiusCz> nope, it is in  bin/ubuntuone-syncdaemon
[10:42] <GeorgiusCz-atN90> mnt/card/bin/ubuntuone-client-1.2.0 $ bin/ubuntuone-syncdaemon n  File "bin/ubuntuone-syncdaemon", line 73n    args=args, usage=usage)n       ^nSyntaxError: invalid syntax
[10:42] <Chipaca> ok, yes, that's a bug
[10:42] <Chipaca> GeorgiusCz-atN90: cool :)
[10:43] <Chipaca> I've found a python 2.5 to test with
[10:43] <Chipaca> and yes, this thing breaks :(
[10:43] <Chipaca> but I don't have time to fix it right now
[10:43] <GeorgiusCz> :-(
[10:44] <GeorgiusCz> I am a python beginner, so I have to admitt that I do not have a clue what is trying to be done on this line
[10:44] <Chipaca> i guess we're only testing 2.5 on the server-side things :(
[10:44] <Chipaca> (this is not good)
[10:44] <Chipaca> georgiusCz: next week, can you ping me on irc?
[10:44] <Chipaca> I'm pretty sure I'll forget this otherwise
[10:45] <Chipaca> but when I'm back at my office I can fix this in a few minutes :)
[10:45] <GeorgiusCz> OK, or some mail/ICQ/jabber/skype .. ?
[10:46] <Chipaca><EMAIL_ADDRESS>but that channel will be flooded  :)
[10:46] <Chipaca> I've got to set up a vm so i can test with 2.5
[10:46] <Chipaca> is debian still on 2.5?
[10:46] <Chipaca> that would make it an even more serious issue
[10:46] <GeorgiusCz> I guess so .. (because Maemo is debian-based)
[10:47] <GeorgiusCz> Recently I am on Ubuntu machine and I do not use Python on my Debian boxes (C++ or bash, nothing in between ;-) )
[10:47] <Chipaca> ok, I've got to check taht too
[10:48] <GeorgiusCz> yep, lenny 2.5
[10:48] <GeorgiusCz> squeeze 2.6.5-5
[10:48] <GeorgiusCz> and SID 2.6.5-5 as well
[10:49] <GeorgiusCz> So stable is still 2.5, next version "comming soon ;-)" will be 2.6
[10:50] <Chipaca> ok, so I need a lenny vm and that'll fix it for both. Good!
[10:50] <GeorgiusCz> yep
[10:51] <GeorgiusCz> So thank you so far and I will write both here and in the mail on monday morning CET
[10:51] <Chipaca> ok, i've got to pack up and leave
[10:51] <GeorgiusCz> thank you again and good bye
[10:52] <Chipaca> i'm on GMT-3, so CET might be a little early :)
[10:52] <Chipaca> but I'll get the message anyway, so go ahead
[10:52] <GeorgiusCz> OK
[13:55] <duanedesign> 'lo all
[22:57] <nunatak_> I'm trying to buy music at the UO music store for the first time. I payed by paypal but now there labeled all tracks I bought with "Queued" since 10 minutes.
[22:58] <newboon2age_> honk fo nunatak_
[22:59] <nunatak_> what!?
[22:59] <newboon2age_> duanedesign: do you know who could help nunatak_ out with that?    honk
[22:59] <newboon2age_> nunatak_: i meant " honk for nunatak_ "
[23:00] <nunatak_> yes, I read it!
[23:03] <newboon2age_> nunatak_: i'm just an end user like yourself.  I haven't tried out the music store yet.  What music did you get?
[23:03] <nunatak_> Its still 'Queued'...
[23:04] <newboon2age_> nunatak_: and what music was it, out of curiousity?
[23:04] <nunatak_> the artist is called Villagers
[23:04] <nunatak_> Becoming a Jackal
[23:04] <nunatak_> the album name
[23:04] <nunatak_> does that matter?
[23:04] <newboon2age_> nunatak_: i'll have to check them out.  What style?
[23:04] <newboon2age_> nunatak_: no i'm just curious...
[23:04] <nunatak_> indie i think
[23:05] <nunatak_> singer & songwriter otherwiese
[23:05] <nunatak_> ...wise
[23:05] <nunatak_> :)
[23:05] <newboon2age_> nunatak_: is it a direct download setup or some kind of torrent?
[23:06] <nunatak_> I don't know. Hiw I mentioned thats my first download from the UO music store. I don't know how it work. If its http or torrent download
[23:06] <nunatak_> its from 7digital
[23:07] <newboon2age_> nunatak_: i was thinking of trying it out.  I've only used torrents a few times.  it works quickly if someone has 'seeded' it, but if not it ends up where you wait until someone does i think.  I don't know much about it.
[23:07] <nunatak_> But I allready read at ubuntuusers.de that there are problems with downloading music from the store
[23:08] <nunatak_> unfortunatly the forum is offline caused by server-problems this weekend
[23:09] <newboon2age_> nunatak_: okay, well let's try Chipaca, and lifeless, and nhaines (they're folks i've asked questions of before)  honk.
[23:10] <Chipaca> *yawn*
[23:10] <Chipaca> what?
[23:10] <newboon2age_> Chipaca: sorry to bother... can you help nunatak_ out or redirect them to someone who can...
[23:11] <Chipaca> sure, what's the issue?
[23:11] <Chipaca> hmmm
[23:11] <newboon2age_> nunatak_: take it away...
[23:12] <nunatak_> ??
[23:12] <newboon2age_> nunatak_ said: I'm trying to buy music at the UO music store for the first time. I payed by paypal but now there labeled all tracks I bought with "Queued" since 10 minutes.
[23:12] <Chipaca> I didn't know you could pay with paypal, but ok
[23:12] <nunatak_> I think I payed allready
[23:13] <Chipaca> ok. And have the songs turned up in one.ubuntu.com/files/ ?
[23:14] <nunatak_> yes. at paypal there is displayed the peyment
[23:14] <nunatak_> payment
[23:16] <Chipaca> nunatak_: ok. And have the songs turned up in one.ubuntu.com/files/ ?
[23:17] <nunatak_> thats what I see in rhythmbox music store: http://s239.photobucket.com/albums/ff165/nullm3ridian/?action=view&current=Bildschirmfoto-Musik-Wiedergabe.png
[23:17] <Chipaca> aquarius: hi!
[23:18] <Chipaca> nunatak_: ok. And have the songs turned up in one.ubuntu.com/files/ ?
[23:18] <Chipaca> nunatak_: that's the third time I've asked. Are you reading what I'm writing?
[23:18] <Chipaca> nunatak_: if the question isn't clear, please tell me so
[23:19] <Chipaca> aquarius: what did 'Queued' mean in the music store thing?
[23:19] <Chipaca> I always forget
[23:20] <aquarius> Chipaca, hey. Queued means "the song hasn't arrived on your machine yet", which could be because it's still being fetched from 7d, or because it's fetched from 7d into U1 but it hasn't started downloading yet
[23:21] <Chipaca> ok, so I was on the right track
[23:21] <Chipaca> :)
[23:21] <Chipaca> nunatak_: so... *is* the album visible at http://one.ubuntu.com/files/ (in the "purchased from ubuntu one" folder) ?
[23:25] <nunatak_> Chipaca: Ah, ok. I know what u mean. I got a look!
[23:25] <Chipaca> nunatak_: ah, good! I wait patiently.
[23:26] <nunatak_> :)
[23:26] <newboon2age_> Chipaca: might have been a little language barrier prob.  looks like nun is native German speaker
[23:26] <nunatak_> hey, don't annoy!
[23:27] <newboon2age_> nunatak_: so does that mean you're seeing the albums on the ubuntuone account now?
[23:27] <nunatak_> but sorry. hehe.....they are in my ubuntuone files.
[23:27] <nunatak_> yes. no
[23:28] <newboon2age_> so problem solved?
[23:29] <newboon2age_> nunatak_: problem solved?
[23:29] <nunatak_> I think so. :)
[23:29] <newboon2age_> nunatak_: Yeah!!!
[23:29] <newboon2age_> nunatak_: i'll have to try out the music store sometime soon...
[23:30] <newboon2age_> nunatak_: maybe the villagers will be first up. ;)
[23:30] <nunatak_> newboon2age_: I slightly feel you mock at me. ;)
[23:30] <duanedesign> newboon2age_: there are some free mp3s you can downloaad to try out the store
[23:30] <newboon2age_> nunatak_: not at all nunatak_,
[23:30] <Chipaca> nunatak_: do you have the files _on your computer_ now?
[23:30] <nunatak_> yes of course. ^^
[23:30] <duanedesign> i use the free songs to test the store when someone has an issue
[23:30] <nunatak_> no
[23:30] <nunatak_> but i get them now
[23:31] <Chipaca> nunatak_: how do you get them?
[23:31]  * Chipaca has visions of nunatak_ downloading them "by hand" from the web interface
[23:31] <newboon2age_> Chipaca: it sounds like nunatak_ is using Rhythmbox.  Don't know how that works...
[23:33] <Chipaca> newboon2age_: if you wait until I've made sure nunatak_ has his mp3s in the right way, I can explain
[23:33] <Chipaca> you information leech you :)
[23:33] <newboon2age_> Chipaca: he he
[23:34] <Chipaca> nunatak_: ping
[23:34] <nunatak_> Chipaca: by downloading them from my ubuntu.one account
[23:34] <Chipaca> nunatak_: please don't do that
[23:34] <Chipaca> nunatak_: I mean, you *can* do that
[23:34] <Chipaca> nunatak_: but, you shouldn't have to do that
[23:34] <Chipaca> nunatak_: the system is designed to be automated
[23:35] <nunatak_> antoher question, maybe someone of you know it: Is Ubuntu-Linux supported with the money canonical get from the UO music store?
[23:35] <Chipaca> nunatak_: can you open a terminal and type in
[23:35] <Chipaca> nunatak_: u1sdtool -s
[23:35] <Chipaca> nunatak_: and pastebin the output?
[23:35] <Chipaca> nunatak_: yes, yes it is
[23:35] <nunatak_> Chipaca: why I shouldn't?
[23:36] <nunatak_> ok
[23:36] <Chipaca> nunatak_: because the beauty of the u1 music store is that you can connect multiple machines to u1 and then they will all get the music
[23:36] <nunatak_> ok
[23:37] <newboon2age_> Chipaca: does downloading from the ubuntuone then remove it from ubuntuone and then your other clients won't have access to it Chipaca?
[23:37] <Chipaca> newboon2age_: no, of course not
[23:37] <newboon2age_> Chipaca: then i don't understand...
[23:38] <Chipaca> *sigh*
[23:38] <Chipaca> newboon2age_: what part don't you understand?
[23:38] <newboon2age_> why is it less good for nunatak_ to download it off web site?   I passed exams and I'm back to work. did you receive my last mail (Re: to the last one), your opinion is appreciated :)
[23:41] <nunatak_> the output: http://pastebin.ca/1894129
[23:41] <aquarius> mkarnicki, I did -- I am still thinking about it :)
[23:42] <mkarnicki> aquarius: sure, thanks :)
[23:42] <Chipaca> newboon2age_: the server-side component of the music store injects the files into an ad-hoc folder in the user's account
[23:42] <Chipaca> newboon2age_: syncdaemon gets the notification that there is new stuff there, and downloads it
[23:42] <newboon2age_> Chipaca: so the songs probably *should* 'just show up' in rhythmbox? and do they also show up in the 'Ubuntu One' folder in the home directory?
[23:42] <Chipaca> nunatak_: and the output of «find ~/.ubuntuone» ?
[23:43] <Chipaca> newboon2age_: no, it's in a "UDF", what you get when you right-click a folder in your home other than Ubuntu One and select 'sync with u1'
[23:44] <nunatak_> "no such file or directory
[23:44] <nunatak_> I downloaded the songs by the hard way. but I will check the term you said for the next time!
[23:46] <Chipaca> nunatak_: can you open Ubuntu One under System -> Preferences and (wait a minute or so and) see if Music Download is enabled?
[23:46] <nunatak_> thanks for helping
[23:47] <nunatak_> yes i can!
[23:47] <Chipaca> nunatak_: if it's not enabled, please enable it
[23:49] <nunatak_> I'll learn more about UO syncing tomorrow
[23:51] <Chipaca> OK
[23:52] <newboon2age_> Chipaca: The good thing is that when you share something with me i can send it out through wiki help, forums and irc, so you save yourself some effort. :)
[23:53] <Chipaca> newboon2age_: I appreciate it. Try to make it google-able so people can find it, too :)
[23:53] <newboon2age_> Chipaca: yup on the wiki and forums it is.
[23:54] <newboon2age_> Chipaca: would you mind sharing which ide you use? or do you use an ide?
[23:54] <newboon2age_> Chipaca: and is there any kind of recommended ide w/in Canonical?
[23:55] <Chipaca> newboon2age_: I use emacs. And Canonical keeps out of the way and lets us get on with building awesome stuff.
[23:55] <Chipaca> newboon2age_: so some people in my team use gedit
[23:55] <newboon2age_> Chipaca: gotcha.  Thanks. :_
[23:55] <Chipaca> some, eclipse
[23:56] <Chipaca> some think they need to repay some karma or something and use vi
[23:56] <newboon2age_> Chipaca: :)
[23:56] <Chipaca> and some of us use emacs
[23:57] <newboon2age_> anyone using idle or (i think its) SPE?
[23:58] <Chipaca> I don't know; I think I've listed everybody. Manuel might use something stranger, I dunno.
[23:58] <Chipaca> I'm pretty sure nobody uses idle
[23:58] <Chipaca> I think I'd know because of all the cursing
[23:59] <newboon2age_> Chipaca: :)
[23:59] <Chipaca> j/k


[02:33] <RAOF> Ok, I need some help for https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1934995
[02:33] <RAOF> Who's good for ppc64 toolchain-esque bugs?
[02:48] <mwhudson> RAOF: probably me or doko these days
[02:51] <mwhudson> RAOF: "A umockdev build with the versions that hirsute's 0.15.4-1 built with." seems incomplete, i assume that should end "still crashes"?
[02:52]  * RAOF checks.
[02:52] <RAOF> Hm, yes.
[02:53] <RAOF> I built a umockdev package using the versions of binutils, gcc, and vala found in https://launchpadlibrarian.net/515322542/buildlog_ubuntu-hirsute-ppc64el.umockdev_0.15.4-1_BUILDING.txt.gz
[02:54] <RAOF> The umockdev from that package also crashes.
[02:54] <mwhudson> RAOF: i don't suppose you have a command line to invoke that crashes?
[02:54] <mwhudson> as in, some way of starting in with gdb?
[02:54] <mwhudson> i'm running a build in canonistack
[02:54] <RAOF> I can
[02:54] <mwhudson> but that will take a while
[02:54] <RAOF> I wonder if I can share my canonistack instance with you?
[02:55] <mwhudson> yeah just ssh-import-id i think
[02:55] <mwhudson> i don't think we have any fancy per-user security groups
[02:56] <RAOF> umockdev-run bin/mir_umock_unit_tests will hit it.
[02:57] <RAOF> Your launchpad SSH key should have access to<EMAIL_ADDRESS>now.
[02:57] <mwhudson> i am in
[02:58] <RAOF> There's a byobu session with a built Mir tree and umockdev build.
[02:58] <RAOF> (In a hirsute schroot)
[02:58] <mwhudson> er how do i join a byobu session? i only know screen
[02:59] <RAOF> Just run byobu
[02:59] <mwhudson> ah got it
[03:02] <mwhudson> RAOF: ah heh so need to get an old gdb deb from somewhere?
[03:03] <RAOF> Maybe!
[03:03] <RAOF> Could also just upgrade everything and fix the brokenness.
[03:03] <RAOF> Oh, huh. This is an impish chroot.
[03:04] <RAOF> Forgot what I was doing last :)
[03:04] <mwhudson> RAOF: yeah maybe just upgrading everything makes sense
[03:05] <mwhudson> RAOF: if that's not going to lose state that would be annoying to recover?
[03:05] <RAOF> Nah.
[03:06] <RAOF> The built-with-the-working-build's-umockdev .debs are still in there for testing, as are all the relevant gcc, binutils, and vala debs :)
[03:09] <mwhudson> RAOF: meep
[03:10] <RAOF> Yes!
[03:16] <mwhudson> RAOF: have you tried using liblttng-ust0 from the last passing test?
[03:16] <RAOF> Presumably something has been corrupted before we hit this point, but valgrind doesn't complain about any out-of-bounds writes until the stack smashing.
[03:17] <RAOF> I think this is the liblttng-ust0 from the last passing test?
[03:17]  * RAOF double-checks.
[03:18] <RAOF> Oh, yeah, it definitely is. LTTNG hasn't been rebuilt in impish, and mir 2.4.0-0ubuntu2 built and ran its tests fine in impish.
[03:21] <mwhudson> RAOF: so what has changed since things worked? glibc?
[03:22] <mwhudson> but only in minor ways
[03:22] <RAOF> umockdev got rebuilt.
[03:22] <RAOF> (Or, rather, umockdev 0.16.something was built in impish)
[03:22] <mwhudson> there's always the LTO bogeyman
[03:22] <RAOF> If you install umockdev 0.15.4-1 from the hirsute archives, it works.
[03:22] <mwhudson> hmmmm
[03:23] <mwhudson> have you tried a build of umockdev without lto yet?
[03:23] <RAOF> I have not, no.
[03:23] <mwhudson> ... i wonder when that became the default
[03:23] <RAOF> That seems a sensible next step!
[03:23] <RAOF> If it was about half-way through the hirsute cycle that would be an excellent candidate.
[03:24] <mwhudson> seems it was just before release
[03:25] <mwhudson> which seems a bit crazy so maybe it was earlier
[03:25] <RAOF> Odd time to turn it on, but sure.
[03:25] <RAOF> That tracks; as I say, rebuilding umockdev in hirsute release results in a umockdev that crashes in this way.
[03:26] <mwhudson> yeah definitely worth a try
[03:26] <mwhudson> i wouldn't mind keeping the schroot i'm currently poking around in though
[03:46] <RAOF> If you can walk me through adding storage to a canonistack instance I can make that happen :)
[03:46] <RAOF> But I'm not sure the disc is big enough to handle a second schroot.
[03:46] <RAOF> Hm. Yes. The working version of umockdev was built prior to LTO by-default.
[03:46] <RAOF> (Or, at least, the 0.15.4-1 buildlog does not contain any references to lto, and the 0.16.1-1 buildlog does)
[03:48] <mwhudson> grr why can i only run the failing command once in each gdb session?
[03:51] <RAOF> Because it's a wrapper that tests some environment variables and then exec()s the real thing.
[03:51] <RAOF> mwhudson: As that's getting annoying for you, you can export the relevant environment variables (I *think* LD_LIBRARY_PATH is the only one relevant for this test?) and then run bin/mir_umock_unit_tests.bin
[03:52] <RAOF> mwhudson: You're after `export LD_LIBRARY_PATH=/root/mir-2.4.1/build-ppc64el/bin/../lib`, I believe.
[03:53] <mwhudson> RAOF: ah yes
[03:58] <RAOF> It's a bit of a panda's thumb.
[04:03] <mwhudson> so i don't remember the ppc64el abi inside and out but it sure looks like the open in libumockdev-preload is doing very bad things
[04:03] <mwhudson> like saving non-volatile registers way outside its stack frame
[04:04] <RAOF> Huh.
[04:04] <RAOF> I wonder why valgrind didn't pick that up?
[04:05]  * mwhudson drowns in preprocessor
[04:08] <mwhudson> https://paste.ubuntu.com/p/BSNKBGrSHZ/
[04:09] <mwhudson> no wait what is this doing
[04:09] <mwhudson> it's writing r5 to r10 to crazy locations but they're not non-volatile registers
[04:10] <mwhudson> ah no that's the parameter save area
[04:10] <mwhudson> aaaaaaaaaah
[04:11] <mwhudson> RAOF: i think it's because mir's declaration for real_open does not match that of umockdev
[04:11] <mwhudson>     int (*real_open)(char const *path, int flags, mode_t mode);
[04:12] <mwhudson> vs (const char *path, int flags, ...) for umockdev
[04:12] <RAOF> Oh, no! va_args!
[04:13] <mwhudson> i'm not completely sure that's the problem
[04:14] <mwhudson> yeah i bet it is
[04:15] <RAOF> Well, this should be quick to test!
[04:17] <RAOF> mwhudson: Can I quit your gdb session to test that change?
[04:18] <mwhudson> RAOF: i think i just quit the schroot in fact but yes
[04:18] <mwhudson> ah i'll stop typing :)
[04:18] <mwhudson> how do i disconnect?
[04:19] <RAOF> F12 d
[04:19] <RAOF> By default.
[04:19] <mwhudson> ok
[04:19] <mwhudson> i'm out
[04:19] <mwhudson> RAOF: btw i have no idea how this ever worked :-)
[04:19] <RAOF> The best sort of bugs!
[04:20] <mwhudson> a schrödinbug
[04:21] <RAOF> It's been perfectly happy with this code for the last 3 years :)
[04:22] <mwhudson> how does open(2) manage to have an optional argument anyway??
[04:22] <RAOF> 🤷♀
[04:26] <mwhudson> oh the protoype has va_args
[04:27] <mwhudson> so yeah mir's needs to too
[04:29] <mwhudson> RAOF: you'll need to fix the open64 wrapper too, not sure about the others
[04:29] <mwhudson> anyway i must vanish in a puff of childcare obligations
[04:29] <RAOF> Sweet.
[04:29] <RAOF> Enjoy!
[04:29] <RAOF> Thanks very much.
[07:39] <egorenar> Hi all, i'm working on a new stand-alone dump concept for IBM z Architecture on Ubuntu (and other distros) and my idea is to use the dracut package to build an initramfs image for the dumper. This is similar to how kdump tooling works. That would make the package s390-tools (in particular the zipl tool) depend on the dracut package. I was told to ask on this channel whether you see any problem with that. Furthermore, i would like to
[07:39] <egorenar> know whether the dracut package will continue to be supported on Ubuntu in the future ? Thank you very much.
[07:48] <ricotz> juliank, hi :), fwupd-signed did not bump its build-dep as mentioned in the changelog and therefore is not installable -- https://launchpad.net/ubuntu/+source/fwupd-signed/1.27.1ubuntu4
[07:48] <juliank> ricotz: yes, I know
[07:49] <ricotz> alrighty :)
[07:56] <schopin> bdmurray: re openssl, I was pinging the uploader to hirsute-proposed to understand what was going on with the previous upload and how to... coordinate, I guess? In any case, we're good, but I'm still in need of a sponsor :)
[08:44] <rbasak> egorenar: in Ubuntu we wouldn't be able to carry a dracut dependency on s390-tools without further work, since s390-tools is in main but dracut is in universe. I'm fairly sure we don't use dracut for initramfs images on Ubuntu.
[09:34] <mwhudson> we do not use dracut by default for sure
[09:51] <egorenar> rbasak: dracut would be just a soft dependency for s390-tools, we would have a helper script in s390-tools that calls dracut, and if it's not installed then you can't use the new stand-alone dump, that's all. but there would be no hard dependency on dracut. I know that Ubuntu uses initramfs-tools for building initramfs images.
[09:52] <egorenar> The reason we are trying to go with dracut because it is supported on all distros that Linux Z targets.
[09:58] <egorenar> Other alternatives we considered would mean a lot more effort to maintain custom initramfs scripts and tools to build the required images for the dumper.
[09:59] <egorenar> With dracut, we just need to provide a small custom module, uniform for all distros.
[10:04] <rbasak> egorenar: I don't see an issue there then, but wouldn't it be difficult for Ubuntu users to switch to dracut to make use of this feature?
[10:07] <egorenar> maybe we misunderstand each other :) Ubuntu users don't have use dracut to build *regular* initramfs, to use the new dump feature, Ubuntu users just need to install dracut, that's all. we don't want to change any initramfs tooling Ubuntu already using.
[10:08] <rbasak> Sounds fine to me :)
[10:08] <egorenar> great :) and dracut will be supported for a long time ? no plans to remove it ?
[10:11] <rbasak> What do you mean by "supported"?
[10:11] <rbasak> dracut is in universe so relies entirely on community support. It is autosynced from Debian.
[10:11] <rbasak> In general packages aren't removed from Ubuntu as long as they exist in Debian, unless they cause problems.
[10:15] <egorenar> ok, thanks for clarifying
[11:21] <GunnarHj> Hi vorlon! Can you please take a look at bug #1937922. Should gtk4 be added to the list of packages which are built on i386?
[11:37] <laney> autopkgtest [12:36:34]: ERROR: "dpkg --unpack /tmp/autopkgtest.N3wyHj/2-autopkgtest-satdep.deb" failed with stderr "dpkg-deb: error: archive '/tmp/autopkgtest.N3wyHj/2-autopkgtest-satdep.deb' uses unknown compression for member 'control.tar.zst', giving up
[11:37] <laney> blerp
[11:37] <laney> did we break running debian autopkgtests from ubuntu
[15:24] <vorlon> GunnarHj: what will reference gtk4 that is currently in the i386 set?
[15:24] <vorlon> (or, will anything)
[16:03] <GunnarHj> vorlon: Don't know. It's rather about build-deps in ibus. Or do you indicate that we should skip the build of ibus-gtk4 when building for i386? Can that be done without creating a permanent Ubuntu/Debian delta?
[16:08] <schopin> Anyone willing to sponsor an openssl upload to impish? THis is bug #1931994 which will be SRUed if all goes well, but first Impish :).
[23:03] <bdmurray> dbungert, jawn-smith: here is an example of hint MP https://code.launchpad.net/~ginggs/britney/+git/britney/+merge/405912
[23:04] <jawn-smith> thanks bdmurray
[23:08] <bdmurray> there are also branches for stable releases


[06:10] <cpaelzer> jamespage: ok, thanks
[06:10] <cpaelzer> jamespage: we'll need some time for the new DPDK in Debian anyway - if things work out I'll get in touch with you for a snapshot build of 2.13 then
[09:25] <jamespage> cpaelzer: ok ounds like a plan
[10:53] <nightuser> Hi folks. The main channel suggested to ask here. What's the right way of enabling auto-updates on a server? Still use cron or systemd timers?
[11:00] <mwhudson> nightuser: man unattended-upgrades (which uses systemd timers, at least in newer releases)
[11:18] <weedmic> nightuser: is that really what you want to do?  we (where I work) check which updates are available, if they can affect running items, is it worth the risk, etc. and above all - how to revert if it breaks something.  I'm talking servers, not workstations.  Just a thought
[11:19] <nightuser> weedmic: I believe that updates from security repo are safe enough. It's just a tiny VPS which I keep for myself, so I'm not risking anything really.
[11:21] <weedmic> safe v crippling are not the same thing - it was just a thought to consider - u need not listen to me at all
[11:25] <nightuser> weedmic: I understand your point. If it was something serious, I'd think twice before applying them, but for personal usage it's okay for me.