[20:12] <elky> genii: set +r in there for now
[20:19] <acheronuk> #ubuntu-desktop being flooded
[20:23] <Fuchs> yes, hello
[20:23] <elky> what nicks joined right before all that?
[20:23] <Fuchs> I abused my oper privs a bit to solve that, sorry
[20:23] <elky> forgiven
[20:25] <Fuchs> if the idiocy continues, you might want to either +r the channel,
[20:25] <Fuchs> or +zq $~a  and op up sigyn, which will feed her
[20:26] <Fuchs> please let me know once the idiocy is over, then I shall remove sigyn to avoid false positives
[22:25] <bazhang> genii, /me is a human right!
[22:25] <genii> hah
[22:28] <bazhang> Fuchs, once 'the idiocy is over'; wouldnt that entail the end of irc


[01:51] <DeadSquirrel01> Hi, only kitkat repo for build ubuntu touch or there is a newer like marshmallow?
[01:54] <DeadSquirrel01> No one know thiz?
[02:59] <duflu> DeadSquirrel01: Most of the people who could answer that are in Europe or the Americas. So they are sleeping :)
[07:22] <aroyl> @Acou_Bass do you stay logged in 24/7?
[09:33] <DeadSquirrel01>  Hi, only kitkat repo for build ubuntu touch or there is a newer like marshmallow?
[09:43] <DeadSquirrel01> Anyone knows?
[09:54] <DeadSquirrel01> What a difficult question :P
[12:19] <matv1> chrisccoulson I saw you released an oxide fix for that web app crash after using links (yeahh!). Does that mean that I should get fix that in the next rc-proposed build?
[12:47] <DeadSquirrel01>   Hi, only kitkat repo for build ubuntu touch or there is a newer like marshmallow?
[13:58] <DeadSquirrel01> Anyone??
[13:58] <DeadSquirrel01> Only kitkat manifest for ubuntu touch?
[14:00] <dobey> depends on the device
[14:00] <DeadSquirrel01> I have a ll mm and n device tree
[14:00] <DeadSquirrel01> But kitkat is too old
[14:01] <DeadSquirrel01> So?
[14:02] <DeadSquirrel01> I tried change the manifest branch to mm but on build i get lots of errors i don't get when building cm or any other rom
[14:02] <dobey> so, you should be able to use 5.1
[14:03] <dobey> but i don't know much beyond that it's possible
[14:03] <DeadSquirrel01> But not 6.0?
[14:03] <dobey> you should probably talk to the #ubports people
[14:03] <dobey> no i don't think libhybris works with 6 or 7 yet
[14:03] <DeadSquirrel01> Ow ok thx
[14:05] <HonP> Hi, is it possible to rotate display upside down? Or is it possible to install xrandr or xinput-calibrator to nexus 4?
[14:05] <HonP> I have problems with Nexus display, and this would really help me.
[14:12] <dobey> no, X is not the display system, so X tools wouldn't help
[14:13] <dobey> i actually don't know if rotation works for 180 degrees
[14:13] <HonP> dobey, there is not xserver?
[14:13] <HonP> is it the MIR thing there?
[14:14] <dobey> looks like it doesn't
[14:14] <dobey> yes Mir is the display server for unity8
[14:15] <dobey> doesn't rotate 180 that is; only 90 left or right, and not on the lock screen afaict
[14:15] <HonP> so i am totally screwed?
[14:17] <HonP> 90left/right is good but i need it in phone application.
[14:23] <dobey> i don't know about the dialer app. does it not rotate?
[14:23] <HonP> no
[14:25] <dobey> if you edit /usr/share/dialer-app/dialer-app.qml and change automaticOrientation: false to be true instead, then it should work i think
[14:26] <HonP> hm... give me sec.
[14:26] <dobey> hmm, might not be that simple though. on my vm it looks like it tries to force the width to always be a certain size :-/
[14:57] <HonP> dobey, does not work, but could i set it to landscape mode somehow?
[14:58] <dobey> no, it will require more changes, i guess
[14:58] <HonP> :(
[14:58] <HonP> :(
[15:01] <matv1> HonP not sure what you´re trying to achieve but for apps you can force orientation in the .desktop file
[15:01] <matv1> from memory i blieve something like Supported-Orientations=portrait
[15:01] <matv1> does that help?
[15:02] <HonP> matv1, could i ask what .desktop file shoul i us for dialer-app?
[15:02] <dobey> oh it does have that in the .desktop too
[15:03] <HonP> but where? :)
[15:03] <matv1> ah dialer app. thats a core app. and probably not C not qml
[15:03] <matv1> not sure about that
[15:04] <matv1> let me check the exact syntax in an old app of mine though
[15:04] <matv1> hang on
[15:05] <matv1> i have:
[15:05] <matv1> Type=Application
[15:05] <matv1> X-Ubuntu-Touch=true
[15:05] <matv1> X-Ubuntu-Supported-Orientations=portrait
[15:06] <matv1> again: not sure if that works for dialer though
[15:06] <HonP> great it works!!!
[15:07] <HonP> :)
[15:07] <HonP> it does not look good but it looks that i can use my phone now!
[15:07] <matv1> HonP Awsum!
[15:09] <HonP> thank you very much guys.
[15:11] <matv1> HonP np
[15:35] <tedg> popey: Do you know if the terminal app has changed how it gets a shell?
[15:35] <tedg> popey: It seems that vigo is reporting that the shell isn't in the cgroup for the app
[15:36] <tedg> Which isn't bad on the surface, I don't care about the shell, but I'm not sure if something bigger is broken.
[15:36] <tedg> vigo: Could you look at the pid for the terminal and see what its cgroup's are?
[15:37] <tedg> vigo: ubuntu-app-pid, and then /proc/$(pid)/cgroup
[15:40] <vigo> tedg, sure give me a few minutes :)
[15:56] <vigo> tedg, I just ran it again from tereminal and works fine it gives me the full path under freezer
[15:56] <vigo> my mistake
[15:57]  * tedg wipes the sweat of his brow ;-)
[15:57] <tedg> vigo: Cool, that's way better than the alternatives ;-)
[15:57] <vigo> tedg, thanks for your time :)
[15:58] <popey> \o/
[16:03] <renato__> popey, hey, do you know something about the javascript code used by calculator app?
[16:04] <popey> a bit
[16:04] <popey> what's up?
[16:04] <popey> Am on the phone currently, but will reply when I can
[16:04] <renato__> popey, I am trying to snappy it and I am getting error: math.js:71 Parser error
[16:05] <popey> erk
[16:05] <renato__> popey, this happen if I type any number in the calculator
[16:05] <renato__> popey, and the math.js is not human readable :D
[16:05] <popey> I think it;s https://github.com/josdejong/mathjs
[16:05] <popey> minified
[16:05] <renato__> popey, my guess is a missing dep
[16:09] <dednick> charles: hi charles. why is usb/adb auth in indicator-display?
[16:10] <dobey> indicator-flytrap
[16:10] <renato__> popey, found a bug about that: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1620333
[16:10] <ubot5`> Ubuntu bug 1620333 in Canonical System Image "calculator doesn't calculate: parse error in math.js" [High,Confirmed]
[16:10] <charles> dednick, it was an expediency. It's not intrinsic to indicator-display and if you want to move it that would be fine
[16:11] <dednick> charles: ok. ta
[16:11] <renato__> popey, I will try that :) https://bugs.launchpad.net/canonical-devices-system-image/+bug/1620333/comments/6
[16:11] <charles> dednick, is there an issue? or just looking for information?
[16:12] <dednick> charles: might be using it for multi-monitor support and possibly want to move it internally to unity8.
[16:12] <charles> ack
[16:12] <dednick> *or replace it...
[16:24] <renato__> popey, the calculator keypad become disabled if I replace the math.js file
[16:42] <popey> renato__: :(
[22:40] <matv1> it seems really hard to kill apps in the app carousel since the new app switcher.
[22:41] <matv1> I think there should be a bug for that
[22:41] <matv1> but i can't find it


[00:29] -queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.11.2-0ubuntu5~16.04 => 1.12.1-0ubuntu8] (no packageset)
[00:30] <mwhudson> ups
[00:30] <mwhudson> can someone reject that ^
[00:39] <apw> mwhudson, done
[00:39] <mwhudson> apw: thanks
[00:39] -queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (xenial-proposed) [1.12.1-0ubuntu8]
[00:39] <mwhudson> apw: you're my favourite SRU queue rejecter!
[00:39] <apw> i have my uses it seems
[02:24] <tumbleweed> cjwatson, doko, slangasek: temporary home: http://ubuntuqa.tblwd.org/
[05:47] <pitti> tsimonq2: what are you trying to do? at first sight it just looks like you are missing  britney'2 dependencies, such as python3-amqplib?
[05:48] <pitti> tsimonq2: err, Packages_* are supposed to be plain files, not compressed
[08:30] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.14.2~16.04 => 2.15] (desktop-core, ubuntu-server)
[09:20]  * apw is handling ^
[09:24] <bluesabre> pitti, can I go ahead and upload greybird-gtk-theme? It's a bugfix release and has been ack'd by the Xubuntu docs, release, artwork, and QA teams (lp 1623855)
[09:24] <ubot5`> Launchpad bug 1623855 in greybird-gtk-theme (Ubuntu) "[UIFe] Greybird 3.20.1" [Wishlist,New] https://launchpad.net/bugs/1623855
[09:36] <pitti> bluesabre: erm, sure; you don't need my permission :)
[09:36] <pitti> (already acked by docs and release teams)
[09:37] <bluesabre> wasn't sure if we needed to ack up to the ubuntu release team or if our own subteams were enough
[09:46] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.15]
[10:00] <apw> tumbleweed, cheeky i know, is there seeded-in-ubuntu info on there too ?
[10:01] <apw> tumbleweed, and ignore me and assume i can't read
[10:48] -queuebot:#ubuntu-release- New sync: ruby-babel-transpiler (yakkety-proposed/primary) [0.7.0-1]
[10:48] <LocutusOfBorg> some gitlab-ruby stuff ^^
[10:49] -queuebot:#ubuntu-release- New sync: ruby-sprockets-es6 (yakkety-proposed/primary) [0.9.1-1]
[10:51] -queuebot:#ubuntu-release- New sync: ruby-prof (yakkety-proposed/primary) [0.15.9+dfsg1-1]
[10:53] <LocutusOfBorg> ^^ and we should be good
[10:54] -queuebot:#ubuntu-release- New sync: keeper (yakkety-proposed/primary) [0.1.0+16.10.20160915.3-0ubuntu1]
[10:57] <LocutusOfBorg> pitti, ruby-devise-async is utterly broken, and needed only by gitlab. Since the new gitlab in proposed is not using it anymore, I propose you to demote it to proposed (or ignore the autpkgtestsuite), and help me in make gitlab migrate :)
[10:57] <LocutusOfBorg> removing from the archive might be even better :)
[10:58] <LocutusOfBorg> and will be removed from debian in some days too https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837644
[10:58] <ubot5`> Debian bug 837644 in ruby-devise-async "ruby-devise-async is not compatible with devise >= 4.0" [Serious,Open]
[11:05] -queuebot:#ubuntu-release- New: accepted keeper [sync] (yakkety-proposed) [0.1.0+16.10.20160915.3-0ubuntu1]
[11:05] -queuebot:#ubuntu-release- New: accepted ruby-prof [sync] (yakkety-proposed) [0.15.9+dfsg1-1]
[11:05] -queuebot:#ubuntu-release- New: accepted ruby-babel-transpiler [sync] (yakkety-proposed) [0.7.0-1]
[11:05] -queuebot:#ubuntu-release- New: accepted ruby-sprockets-es6 [sync] (yakkety-proposed) [0.9.1-1]
[11:09] -queuebot:#ubuntu-release- New sync: ruby-babel-source (yakkety-proposed/primary) [5.8.35-1]
[11:09] -queuebot:#ubuntu-release- New binary: ruby-prof [armhf] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
[11:10] -queuebot:#ubuntu-release- New binary: ruby-prof [i386] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
[11:11] -queuebot:#ubuntu-release- New binary: ruby-prof [amd64] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
[11:12] -queuebot:#ubuntu-release- New binary: ruby-prof [s390x] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
[11:28] <xnox> tumbleweed, temporary change dns too? to unbreak the world...
[13:00] <xnox> is there a way to make an upload, in such a way that it is forced to go through review queue? (even though it normally would not)
[13:02] <apw> none that i know of... nice thought i would be ... people in my team who wnat that feature tend to upload it to a PPA and ask for review there
[13:02] <xnox> yeah.... i want to upload something that should not be trusted =)
[13:06] <pitti> LocutusOfBorg: kicked to -proposed
[13:15] <rbasak> xnox: in our team, we'd probably import it into git and then file an MP against it.
[13:16] <rbasak> xnox: I can import a package for you if you'd like to do that.
[13:17] <xnox> it's ok
[13:22] <pitti> xnox: but no new binary or so?
[13:22] <pitti> xnox: I suppose asking someone to review from a git branch and/or PPA is most practical then
[13:24] <xnox> ack. will do.
[13:33] <LocutusOfBorg> ta
[14:03] <xnox> pitti, qemu is stuck in proposed on systemd autopkgtest failure and nova.
[14:03] <xnox> nova used to not be there, i'll check that.
[14:03] <xnox> but the systemd failure is weird to me... does the systemd autopkgtest do nested qemu and my update breaks that?
[14:04] <pitti> xnox: it does use nested qemu, for the "upstream" tests; but that's fine, it's the fsck test that failed
[14:04] <pitti> plymouth-start did not run, hmm
[14:04] <pitti> xnox: so, for sure unrelated to qemu, need to investigate
[14:05] <xnox> ack retried nova test because results are all PASS but cleanup failed.
[14:05] <pitti> it's been doing that for a few days already
[14:05] <pitti> xnox: hm, that should be a tmpfail; mind filing a bug against autopkgtst with a pointer to the log?
[14:06] <pitti> i. e. those should auto-retry
[14:07] <xnox> i might be impatient =)
[14:07] <pitti> xnox: oh, it's fine to manually retry, I just mean for the future
[14:09] <pitti> xnox: filed bug 1624406, will hint over systemd
[14:09] <ubot5`> bug 1624406 in systemd (Ubuntu) "systemd-fsck test started to fail" [High,In progress] https://launchpad.net/bugs/1624406
[14:13] <xnox> tah!
[14:35] <pitti> LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-devise is a valid candidate now, but still blocked on some transition
[14:37] <pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu → really close now!
[14:37] <pitti> xnox: did you retry nova/amd64 too?
[14:38] <xnox> no idea where it went
[14:38] <pitti> xnox: so you did? hang on
[14:39] <xnox> sso did do it
[14:40] <LocutusOfBorg> pitti, we need ruby* accepted from new queue
[14:40] <LocutusOfBorg> and demoting ruby-handlebars-assets might be appreciated :)
[14:41] <LocutusOfBorg> so, demoting handlebars, accepting the three packages in new, migration!
[14:41] <LocutusOfBorg> (handlebars has one rdep, diaspora)
[14:41] <pitti> xnox: hmm, no trace of it anywhere
[14:42] -queuebot:#ubuntu-release- New: accepted ruby-babel-source [sync] (yakkety-proposed) [5.8.35-1]
[14:42] -queuebot:#ubuntu-release- New: accepted ruby-prof [armhf] (yakkety-proposed) [0.15.9+dfsg1-1]
[14:42] -queuebot:#ubuntu-release- New: accepted ruby-prof [s390x] (yakkety-proposed) [0.15.9+dfsg1-1]
[14:42] <pitti> LocutusOfBorg: ^
[14:42] -queuebot:#ubuntu-release- New: accepted ruby-prof [amd64] (yakkety-proposed) [0.15.9+dfsg1-1]
[14:42] -queuebot:#ubuntu-release- New: accepted ruby-prof [i386] (yakkety-proposed) [0.15.9+dfsg1-1]
[14:42] <LocutusOfBorg> <3 pitti
[14:42] <pitti> LocutusOfBorg: WDYM with "demoting"? it already is in universe
[14:42] <pitti>  ruby-handlebars-assets | 2:0.21.0-5 | yakkety/universe          | source, all
[14:42] <LocutusOfBorg> demoting to proposed
[14:42] <pitti>  ruby-handlebars-assets | 2:0.23.0-3 | yakkety-proposed/universe | source, all
[14:42] <LocutusOfBorg> or remove, in debian the new version is in non-free
[14:42] <LocutusOfBorg> I'm wondering if you did some mistake in letting it be in universe
[14:43] <LocutusOfBorg> bugs.debian.org/830987
[14:43] <pitti> LocutusOfBorg: ruby-babel-source is in Debian main, WDYM?
[14:44] <pitti> oh, -handlebars; no idea, did I let that in?
[14:44] <pitti> LocutusOfBorg: anyway, if it has reverse dependencies then we can't just remove it, the reverse depends need to be fixed first
[14:44] <LocutusOfBorg> move both on multiverse :) or demote also diaspora?
[14:45] <LocutusOfBorg> the popcon is "1"
[14:45] -queuebot:#ubuntu-release- New binary: ruby-babel-source [amd64] (yakkety-proposed/none) [5.8.35-1] (no packageset)
[14:45] <pitti> bah, diaspora also has a gazillion reverse depends
[14:45] <LocutusOfBorg> oh...
[14:46]  * pitti wants reverse-depends back
[14:47] <pitti> ok, not that bad
[14:48] <LocutusOfBorg> I'm using coccia since reverse-depends is not in place
[14:48] <LocutusOfBorg> even if it is
[14:48] <pitti> $ change-override -S -c multiverse diaspora diaspora-installer ruby-handlebars-assets
[14:49] <pitti> (in contrib in Debian)
[14:49] <pitti> LocutusOfBorg: and once that's published, move hte three to -proposed?
[14:50] <LocutusOfBorg> sure
[14:50] <LocutusOfBorg> if you mean the three now in multiverse
[14:50] <LocutusOfBorg> but they are broken in Debian, and needs fixing there before ubuntu
[14:50] <LocutusOfBorg> incompatible with the other ruby stuff
[14:51] <LocutusOfBorg> babel-source is in new
[14:53] <pitti> LocutusOfBorg: no, it's not :)
[14:54] <LocutusOfBorg> this unblocks ruby-sprockets-es6 and ruby-babel-transpiler. Once they are cleared from new, everything migrates (if everything is good)
[14:54] <LocutusOfBorg> :)
[14:54] -queuebot:#ubuntu-release- New: accepted ruby-babel-source [amd64] (yakkety-proposed) [5.8.35-1]
[15:33] <pitti> LocutusOfBorg: I think I moved everything now, now needs another publisher cycle
[15:38] <LocutusOfBorg> thanks
[15:50] -queuebot:#ubuntu-release- New binary: ruby-babel-transpiler [amd64] (yakkety-proposed/universe) [0.7.0-1] (no packageset)
[15:56] <LocutusOfBorg> pitti, ^^
[16:26] -queuebot:#ubuntu-release- New: accepted ruby-babel-transpiler [amd64] (yakkety-proposed) [0.7.0-1]
[16:29] <LocutusOfBorg> pitti, ruby-sprockets (universe) is still doing autopkgtest against ruby-handlebars-assets (multiverse) <-- is that normal?
[16:44] <jbicha> pitti: does "Confirmed" mean you approved the uife for bug 1623855?
[16:44] <ubot5`> bug 1623855 in greybird-gtk-theme (Ubuntu) "[UIFe] Greybird 3.20.1" [Wishlist,Confirmed] https://launchpad.net/bugs/1623855
[16:56] <apw> the process says triaged means approved
[17:00] <jbicha> right, that's why I'm clarifying what pitti meant
[17:48] <tumbleweed> xnox: DNS is in the same hands as the server that's down
[17:49] <tumbleweed> pitti: there's a temporary reverse-depends on http://ubuntuqa.tblwd.org/
[17:52] <tsimonq2> pitti: I want to get a britney setup running locally to test Kubuntu packages before we whip up an FFe so we are absolutely 100% sure it breaks nothing
[17:52] <tsimonq2> pitti: (britney2)
[17:52] <tsimonq2> pitti: is there a dep list for britney2 that I'm missing?
[18:29] -queuebot:#ubuntu-release- New binary: ruby-sprockets-es6 [amd64] (yakkety-proposed/universe) [0.9.1-1] (no packageset)
[18:36] <LocutusOfBorg> pitti, last one I hope :D
[20:39] -queuebot:#ubuntu-release- New: accepted ruby-sprockets-es6 [amd64] (yakkety-proposed) [0.9.1-1]


[09:36] <bambee> apachelogger: touchegg 1.0 is on revu
[10:39] <shadeslayer_> hallo
[10:47] <shadeslayer_> yofel_: poke
[10:49] <shadeslayer_> oh nvm
[11:12] <ScottK> I uploaded kdepim-runtime with the fix mentioned on packagers.
[11:14] <shadeslayer_> ah, i was coming to that :P
[11:23] <shadeslayer_> i'm pretty sure one can make a rage comic on launchpad
[11:32] <fabo> ScottK: strigi sync request -> 855436
[12:01] <allee> can someone review: bug 855472
[12:11] <agateau> Riddell: hi, I found a typo in the French translation of Ubiquity slideshow, but I can't find the string on Launchpad. Where should I look?
[12:12] <apachelogger> bambee: will look at it
[12:13] <bambee> ok
[12:14] <apachelogger> bambee: did you file a FFe request?
[12:16] <yurchor> agateau: https://translations.launchpad.net/ubuntu/oneiric/+source/ubiquity-slideshow-ubuntu/+pots/ubiquity-slideshow-kubuntu/fr/+translate
[12:16] <agateau> yurchor: thanks!
[12:18] <bambee> apachelogger: bug 855491
[12:19] <apachelogger> ScottK: ^
[12:26] <shadeslayer_> hey apachelogger, ssup
[12:37] <ScottK> apachelogger: Touchegg: go for it.
[12:38] <ScottK> fabo: We need to wait until after Beta 2 is out for it.
[12:38] <fabo> ok
[12:38] <apachelogger> bambee: oh oh oh, touchegg-gui too
[12:47] <bambee> apachelogger: already opened, bug 834149
[12:47] <bambee> and already on revu too (I just said it 6 times...)
[12:50] <bambee> apachelogger: there is no release for touchegg-gui 1.0 btw
[12:50] <bambee> there is just touchegg 1.0
[12:51] <apachelogger> oh ok
[12:52] <apachelogger> bambee: do we have a FFe for gui
[12:52] <ScottK> You do.
[12:52] <shadeslayer_> soprano needs redland that requires rasqal that requires gmp
[12:52] <bambee> apachelogger: are you drunk ?
[12:52] <shadeslayer_> yay
[12:53] <bambee> apachelogger: look at your log at [12:47:13] UTC
[12:53] <apachelogger> ah
[12:53] <apachelogger> lol
[12:53] <apachelogger> kk
[12:56] <shadeslayer_> Launchpad feature request : make publishing of packages instant
[12:59] <apachelogger> bambee: bzr is not in sync with what is on revu for touchegg
[12:59] <apachelogger> shadeslayer_: wrong channel
[12:59] <shadeslayer_> i know ...
[12:59] <bambee> apachelogger: since it has not been reviewed yet, it's not pushed yet :)
[13:00] <apachelogger> plz push
[13:00] <bambee> pk
[13:00] <apachelogger> I'll upload from bzr
[13:00] <bambee> s/pk/ok/
[13:00] <kubotu> bambee meant: "ok"
[13:00] <shadeslayer_> it's ISO QA time btw
[13:00] <apachelogger> bambee: btw why the dep on pkg-kde-tools?
[13:01] <apachelogger> I mean.. if you were using lzma, which you should, it would make sense :P
[13:01] <bambee> apachelogger: oh good catch, I used it for lzma compression (touchegg 0.3) and I forgot to remove it
[13:02] <apachelogger> why no lzma anymore?
[13:02] <bambee> I use the orig tarball, it's gzipped
[13:02] <apachelogger> bambee: lzma is applied on the debs
[13:02] <apachelogger> not on the tar
[13:02] <apachelogger> http://markmail.org/message/4bava3abkqfelisy
[13:03] <apachelogger> oh, actually that is the wrong mail
[13:03] <bambee> repacking it just for lzma is silly, its size is 80KB... :\
[13:03] <apachelogger> it aint repacking
[13:04] <apachelogger> bambee:  ar t /var/cache/apt/archives/kde<tab><tab>
[13:04] <apachelogger> look at the content of our debs
[13:04] <apachelogger> then take a look at another one
[13:04] <apachelogger> that is not kdeish
[13:04] <apachelogger> taht is the mail http://osdir.com/ml/kubuntu-devel/2010-08/msg00070.html
[13:10] <bambee> apachelogger: http://paste.ubuntu.com/694438/ ^^
[13:26] <bambee> apachelogger: pushed
[13:31] <apachelogger> bambee: dude, did you read the mail?
[13:40] <Quintasan> bulldog98: Is the telepathy-kde issue fixed?
[13:44] <CIA-130> [touchegg] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/ (patches changelog control) New upstream release (LP: #855491)
[13:47] <apachelogger> bambee: mind pushing touchegg-gui to bzr?
[13:52] <bambee> apachelogger: done
[13:56] <apachelogger> bzr: ERROR: exceptions.ValueError: orig tarball file touchegg-gui_0.3+repack.orig.tar.xz has unknown extension
[13:56] <apachelogger> <3 bzr
[13:56] <bambee> WTF?
[13:57] <Guest5207> Quintasan: re: telepathy, yes it install now, no broken packages, the presence widget has a borked ui, though for some days
[13:58] <shadeslayer_> dh_makeshlibs: dpkg-gensymbols -plibsoprano4 -Idebian/libsoprano4.symbols -Pdebian/libsoprano4 returned exit code 1
[13:58] <shadeslayer_> yay
[13:59] <CIA-130> [touchegg-gui] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/ (changelog control) releasing version 0.3+repack-0ubuntu1
[14:02] <shadeslayer_> any ideas why dpkg-gensymbols craps out after spewing out a bunch of new symbols
[14:02] <apachelogger> broken lib?
[14:02] <apachelogger> bug?
[14:03] <shadeslayer_> builds fine on oneiric, so bug i'd say
[14:04] <shadeslayer_> apachelogger: http://paste.kde.org/125761/
[14:07] <Quintasan> claydoh: Well I'm not at fault there :P
[14:07] <CIA-130> [digikam] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/ (6 files) merge 2.1.1, courtesy of master shadeslayer
[14:08]  * shadeslayer_ cheats dpkg-gensymbol a bit
[14:08] <shadeslayer> and done
[14:08] <shadeslayer> apachelogger: i just copied over debian/libsoprano4/DEBIAN/symbols to debian/libsoprano4.symbols
[14:08] <apachelogger> yofel_: shadeslayer_: it makes sense to subscribe ubuntu release team to FFes :P
[14:09] <claydoh> Quintasan: No? hehe not complaining there, I can wait it out nice work though, looks promising. I like the 0.1 already, the dailies were shoing nice improvements
[14:09] <shadeslayer> :P
[14:09] <apachelogger> ScottK: do we have approval on bug 834190 ?
[14:09]  * shadeslayer got slammed on the dcmtk MIR
[14:09] <shadeslayer> now i'm scared of doko :P
[14:38] <apachelogger> bambee: akonadi-facebook needs FFe
[14:43] <bambee> apachelogger: bug 855612
[14:43] <apachelogger> ScottK: ^
[14:50] <shadeslayer> phew
[14:50] <shadeslayer> soprano done
[15:07] <bulldog98> Quintasan: I’m testing
[15:11] <bulldog98> Quintasan: fixed
[15:13] <bambee> apachelogger: akonadi-facebook is fine ?
[15:13] <apachelogger> didn't look at it in detail yet
[15:13] <bambee> k
[15:13] <apachelogger> though I think so
[15:13] <apachelogger> since it is from debian
[15:13] <apachelogger> bambee: you should change Maintainer to kubutnu dev to ubuntu dev though
[15:13] <apachelogger> bambee: als make sure what we have there is most up-to-date with what debian has in their repo
[15:13] <Quintasan> bulldog98: Awesome.
[15:14] <bambee> since it is from debian -> what ? :O
[15:19] <Quintasan> I wish Dolphin stopped with this silly message
[15:19] <Quintasan> Can't change permissions to <file path> whenever moving files to ntfs partition
[15:19] <apachelogger> bambee: you have debian vcs entries in contorl
[15:20] <apachelogger> naturally the package would be coming form debian, no?
[15:24] <bambee> no... do you find it on http://anonscm.debian.org/gitweb/ ?
[15:24] <bambee> I just see akonadi.git
[15:27] <shadeslayer> apachelogger: new mallit release
[15:27] <shadeslayer> +d
[15:27] <Quintasan> \o/
[15:28] <shadeslayer> even has initial wayland support :P
[15:29] <Quintasan> 0.80.3?
[15:30] <shadeslayer> .6
[15:35] <apachelogger> way way wayaland
[15:35]  * apachelogger prepares top secret software to be merged into other top secret software
[15:36] <Quintasan> shadeslayer: https://bugs.kde.org/show_bug.cgi?id=282483
[15:36] <Quintasan> :P
[15:37] <EagleScreen> Quintasan, shadeslayer I reported that to Launchpad
[15:37] <EagleScreen> some time ago..
[15:38] <EagleScreen> I think Dolphin should give that messages in a non-intrusive message
[15:38] <Quintasan> EagleScreen: Well, our bug policy is to report every bug in KDE to kdebugzilla
[15:38] <Quintasan> Since we do not have enough manpower to re-report everything
[15:38] <EagleScreen> yes
[15:38]  * shadeslayer doesn't have NTFS partitions anymore
[15:38] <EagleScreen> I still have
[15:39] <Quintasan> https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/195216
[15:39] <Quintasan> ?
[15:39] <charlie-tca> What's the KDE bugtracker url?
[15:40] <apachelogger> everyone: can you please send a highlight chain towards me, ideally at the same time from different people
[15:40] <charlie-tca> apachelogger: what is the KDE bugtracker URL?
[15:40] <apachelogger> bugs.kde.org
[15:41]  * apachelogger throws highlights at Quintasan and shadeslayer in the hopes of getting the favor returned
[15:41] <EagleScreen> aha that is
[15:41] <Quintasan> apachelogger
[15:42] <EagleScreen> let me add upstream tracker
[15:42] <apachelogger> more plz!
[15:42] <charlie-tca> apachelogger: thank you
[15:43] <shadeslayer> ssup apachelogger
[15:44] <shadeslayer> another apachelogger__ ?
[15:44] <apachelogger__> you are really no good at spamming
[15:44] <shadeslayer> they're taking over the world :O
[15:44] <apachelogger_> apachelogger:
[15:44] <apachelogger__> apachelogger:
[15:44] <shadeslayer> hahah
[15:44] <apachelogger_> KABOOOM
[15:44] <shadeslayer> what the hell is apachelogger trying to do?
[15:45] <Quintasan> apachelogger_:
[15:45] <Quintasan> apachelogger_:
[15:45] <apachelogger_> crashing the desktop by means of notifications
[15:45] <Quintasan> apachelogger:
[15:45] <Quintasan> apachelogger:
[15:45] <shadeslayer> hehe
[15:45] <apachelogger_> there we go
[15:45] <apachelogger_> next app down
[15:46] <apachelogger_> hm
[15:46] <apachelogger_> an assert
[15:46] <apachelogger_> oh
[15:46] <shadeslayer> i bet shtylman would like that :P
[15:47]  * Quintasan builds maliit-framework
[15:49] <shadeslayer> hahaha, aaron is awesome : https://bugs.kde.org/show_bug.cgi?id=270414#c48
[15:49] <shadeslayer> apachelogger: following that thread on kde-devel ? :P
[15:52] <apachelogger> shadeslayer: the rubbish one?
[15:52] <apachelogger> no
[15:52] <apachelogger> if I want pointless discussion I read ubuntu-deve-discuss
[15:52] <shadeslayer> heh
[15:52] <shadeslayer> apachelogger: also, this http://mjg59.dreamwidth.org/5552.html
[15:52] <apachelogger> and people wonder why I don't like austrians :P
[15:53] <apachelogger> well, most of them anyway
[15:53] <apachelogger> shadeslayer: too much to read
[15:54] <shadeslayer> tldr; UEFI booting will boot only signed kernels and stuff requiring the linux kernels to be signed and the keys sent to hardware manf. to be incorporated into BIOS and what not
[15:54] <apachelogger_> no idea what a UEFI is
[15:54] <Quintasan> apachelogger: Am I supposed to install stuff from /usr/lib/x86_64-linux-gnu/qt4/plugins/inputmethods/libmaliit.so under the same path?
[15:55] <shadeslayer> apachelogger: verfied boot, like in Chrome OS
[15:55] <apachelogger> Quintasan: yes
[15:55] <Quintasan> k
[15:55] <shadeslayer> digitally signed bootloaders et all
[15:55] <apachelogger> shadeslayer: right
[15:55] <apachelogger> like on the xbox
[15:55] <apachelogger> and the ps3
[15:55] <apachelogger> and all the mobile phones
[15:55] <apachelogger> worked out great for all of them
[15:55] <shadeslayer> heh
[15:56] <shadeslayer> apachelogger: i can haz apk of app to test?
[15:56] <apachelogger> what?
[15:56] <apachelogger_> apachelogger:
[15:56] <apachelogger__> apachelogger:
[15:56] <shadeslayer> apachelogger: the UDS App
[15:56] <shadeslayer> apachelogger: the one that you're making in QML
[15:56] <shadeslayer> apachelogger: the one that was running on yer tablet
[15:58] <apachelogger_> apachelogger:
[15:58] <apachelogger__> apachelogger:
[15:58] <shadeslayer> orly apachelogger
[15:59] <apachelogger__> apachelogger:
[15:59] <apachelogger_> apachelogger:
[16:00] <shadeslayer> We're sorry...... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now.
[16:01] <Quintasan> apachelogger:
[16:01] <shadeslayer> wohoo, 4 mins to ISO download
[16:08] <apachelogger> shadeslayer: I do not have the apk anymore
[16:08] <shadeslayer> :(
[16:09] <apachelogger> oh
[16:09] <apachelogger> actually I do
[16:09] <apachelogger> gitignore ftw
[16:09] <shadeslayer> :D
[16:09] <Quintasan> links plz
[16:09] <apachelogger> people.ubuntu.com/~apachelogger/tmp
[16:09] <apachelogger> or something
[16:09] <apachelogger> bambee: so, if akonadi-facebook is not from the debian
[16:10] <apachelogger> why does it have them lines?
[16:12] <shadeslayer> fooey, out of space on phone
[16:14] <apachelogger_> apachelogger:
[16:14] <apachelogger__> apachelogger:
[16:15] <bambee> apachelogger, apachelogger_, apachelogger__ : how would I know, a copy paste probably
[16:16] <apachelogger__> so
[16:16] <apachelogger_> you
[16:16] <apachelogger> should
[16:16] <apachelogger__> probably
[16:16] <apachelogger_> remove
[16:16] <apachelogger> it
[16:16] <apachelogger__> \
[16:16] <apachelogger_> o
[16:16] <apachelogger> /
[16:17] <apachelogger> looks like someone hugging my nicks
[16:17] <apachelogger> cool
[16:19] <apachelogger> shadeslayer: "goodbye"
[16:20] <shadeslayer> apachelogger: uh what? :P
[16:20] <shadeslayer> ah fsck, phone died
[16:20]  * shadeslayer grabs the charger
[16:26] <apachelogger> shadeslayer: see list
[16:27] <apachelogger> shadeslayer: I think that is the first ubuntu situation in kde in quite a while
[16:29] <shadeslayer> apachelogger: i coudln't make out what he's trying to say
[16:29] <apachelogger> oh you did not read the other thread?
[16:30] <shadeslayer> the one titled "Goodbye"
[16:30] <apachelogger> the one before that
[16:30] <apachelogger> why bug reports do not get looked at
[16:30] <shadeslayer> yeah, read that as well
[16:30] <apachelogger> so what do you not understand?
[16:30] <shadeslayer> but i don't understand what he's trying to say in "Goodbye"
[16:30] <apachelogger> I mean, I just skimmed through the long one as they walways turn out *Exactly* the same
[16:31] <shadeslayer> also, your app fails to load because it can't find QtGui
[16:31] <shadeslayer> hehe
[16:31] <apachelogger> shadeslayer: "you are rubbish people, I hate you, and you have screwed me over for the last time"
[16:31] <apachelogger> is essentially what he is saying
[16:31] <shadeslayer> ah ok
[16:31] <apachelogger> also he did not do anything wrong and was only awesome
[16:31] <apachelogger> also he has a pretty huge phonon
[16:32] <shadeslayer> apachelogger: i don't like it that aaron has reverted the fix
[16:32] <shadeslayer> i mean, i thought he was kidding
[16:32] <shadeslayer> until he actually commited it :/
[16:33]  * apachelogger can totally understand that move
[16:33] <shadeslayer> why should other users suffer because of one person?
[16:34] <shadeslayer> did i mention Dolphin 2 is utterly broken right now
[16:34] <apachelogger> yeah
[16:34] <apachelogger> because they will say thank you
[16:35] <shadeslayer> but they're suffering!!! Poor users
[16:35] <apachelogger> times you get shit for your work per commit: ~0.22
[16:35] <apachelogger> times you get praise for your work per commit: ~0.00013
[16:35] <shadeslayer> heh :D
[16:35] <apachelogger> the sad thing is that this is not actually far from the truth
[16:36] <shadeslayer> probably
[16:36] <apachelogger> so I can completely understand the revert
[16:36] <bambee> apachelogger: fixed btw
[16:36] <apachelogger> if only to proof a point
[16:36] <apachelogger> bambee: the control file?
[16:36] <bambee> yup
[16:36] <apachelogger> kk
[16:36] <apachelogger> waiting for ffe then
[16:40] <shadeslayer> ok, time for ISO testing
[16:40] <shadeslayer> ciao
[16:55] <shadeslayer> doesn't even start
[16:55] <shadeslayer> :/
[17:16] <apachelogger> shadeslayer: what does logcat say?
[17:16] <shadeslayer> apachelogger: dude, doesn't even get detected
[17:17] <shadeslayer> and one sec, i'm filling up us visa form
[17:17] <apachelogger> detected?
[17:17] <apachelogger> nyan I say!
[17:17] <shadeslayer> like, doesn't show up as a boot option
[17:17] <apachelogger> where?
[17:18] <apachelogger> apple circumcised boot?
[17:19] <shadeslayer> heh, yeah, as well as in reFit
[17:21] <apachelogger> must be broken then
[17:31] <ScottK> apachelogger: re digikam: Yes.
[17:32] <ScottK> I'm OK with akonadi-facebook too.
[17:32] <ScottK> Some folks need to be doing ISO testing though.
[17:33] <apachelogger> bambee: you need to do ISO testing I hear :P
[17:35] <bambee> apachelogger: dude, I already do testing :P
[17:36] <apachelogger> oh
[17:36] <ScottK> http://iso.qa.ubuntu.com/qatracker/build/kubuntu/all
[17:36] <apachelogger> apachelogger_: you need to do ISO testing I hear!
[17:37] <apachelogger_> meh.
[17:37] <apachelogger_> but I dont wanna
[17:37] <apachelogger> apachelogger_: you go do testing... now!
[17:37] <ScottK> No one does, but no test, no release.
[17:38] <apachelogger_> alright, I'll get myself some videos to test
[17:38] <apachelogger> -.-
[17:43] <shadeslayer> maybe it works with usb creator? I've dd'ed the iso onto the USB
[17:51] <shadeslayer> aw man, i have to file a bug to mark it as failed :/
[17:53] <shadeslayer> oh btw
[17:53] <shadeslayer> apachelogger: your app works
[17:53] <shadeslayer> on android 2.3.5 Cyanogen Mod 7
[17:53] <shadeslayer> doesn't really do anything except display a list
[17:54] <apachelogger> that is because you did not make it do more
[17:54] <shadeslayer> how do you make it do more? :P
[17:54] <apachelogger> throw in more random qml?
[17:56] <shadeslayer> heh
[18:09]  * ScottK makes a USB of the dvd.
[18:10] <bulldog98> apachelogger: I finally fixed the qml I reported about yesterday
[18:11] <bulldog98> the lib works now :)
[18:12] <apachelogger> bulldog98: fixed what exactly?
[18:12] <apachelogger> bulldog98: does the app work?
[18:12] <apachelogger> can I have a photo?
[18:12] <bulldog98> apachelogger: the pix is showen now, the only missing thing is my commit to my scratch
[18:12]  * apachelogger got himself a bottle of cabernet sauvignon
[18:13] <apachelogger> from down under
[18:14] <bulldog98> apachelogger: http://people.ubuntu.com/~bulldog98/doppelkopf-qml.png
[18:15] <apachelogger> groovy
[18:15] <apachelogger> bulldog98: btw, you can inject components from within the application
[18:15]  * bulldog98 now want’s an option to change the theme
[18:15] <apachelogger> that might make initial development faster
[18:16] <apachelogger> as you do not have to work on two projects to get something done
[18:16] <bulldog98> apachelogger: that’s c++ how could I do that?
[18:16] <apachelogger> bulldog98: see all my qt quick projects
[18:16] <apachelogger> I do that all the time
[18:16] <bulldog98> apachelogger: point me to one :P
[18:16] <apachelogger> G
[18:16]  * apachelogger looks for dragon as its main is more readable ^^
[18:17] <bulldog98> apachelogger: I want to get that lib included into kdegames, so …
[18:17] <apachelogger> if quickgit werent broken
[18:17] <apachelogger> bulldog98: yeah, but what makes it a lib is only the plugin.cpp
[18:17] <apachelogger> well
[18:17] <apachelogger> s/lib/plugin really :P
[18:18] <apachelogger> bulldog98: http://quickgit.kde.org/?p=scratch%2Fsitter%2Fdragon.git&a=blob_plain&h=ac6d0a4117e9734acf20e00854df188aa4b7b81a&f=src/mainwindow.cpp
[18:18] <apachelogger> see right after the constructor
[18:18] <apachelogger> you simply register your class with the qml type system
[18:18] <apachelogger> first argument is the uri, second is major version, third is minor version, thirds is qml type name
[18:19] <apachelogger> so in the qml I do
[18:19] <apachelogger> import Dragon 3.0
[18:19] <apachelogger> and then I can use the SmartFlow{} element
[18:19] <bulldog98> apachelogger: I have an shortcut for my install stuff, so 2 clicks and I updated the lib
[18:19] <apachelogger> 2 clicks too much
[18:19] <apachelogger> trust me
[18:20] <apachelogger> it is faster in one project
[18:20] <bulldog98> apachelogger: with 2 clicks I meant up and running my own app again
[18:21] <apachelogger> bulldog98: 2 clicks too many :P
[18:22] <bulldog98> apachelogger: I want to do it the proper way(tm)
[18:22] <apachelogger> that is the proper way :P
[18:22] <bulldog98> unlike you I don’t like quick and dirty stuff :P
[18:23] <apachelogger> it aint quick and dirty
[18:23] <apachelogger> dont mock kent beck's might
[18:23] <apachelogger> for he can squash ye with his mighty test suits
[18:25] <bulldog98> apachelogger: also I already switched to cmake for my lib
[18:26]  * apachelogger giggles
[18:26] <apachelogger> cmake
[18:28] <bulldog98> apachelogger: yes that works :P
[21:24]  * yofel takes a look at the patch for kdepim-runtime
[21:34] <yofel> ah, scott already did that
[21:36] <ScottK> It's even in the beta 2 images.
[21:38] <bulldog98> qt :)
[21:42] <DarkwingDuck> Hey guys
[21:42] <DarkwingDuck> I'm out of a computer till next week
[21:42] <yofel> bulldog98: any progress on pykde?
[21:43] <bulldog98> yofel: I’m testing if it builds now
[21:43] <yofel> it does build, just tested it now
[21:44] <yofel> I'm confused though just how the packaging needs to be fixed to work with python-support
[21:48] <yofel> ScottK: is it enough to switch --with=python2 into --with=python-support and adjust the build-deps?
[21:48] <ScottK> Probably.
[21:48] <ScottK> I don't recall all what I had to change.
[21:49]  * yofel takes a look at list-missing from old kdebindings
[21:49] <yofel> *not-installed rather
[21:50] <yofel> seems like this should work... I think...
[21:58] <yofel> apachelogger: there? was just looking at kde-l10n-common, and the svnrev in debian/config doesn't match what you put in the changelog for oneiric. Can it be that you uploaded kde-l10n 4.7.1 packages with the svnrev of 4.7.0 ?
[22:05] <CIA-130> [lp:~kubuntu-packagers/kubuntu-packaging/kde-l10n-common-natty] Philip Muškovac * 103 * debian/ (changelog config control) New upstream release (svn: 1250835, type: stable)
[22:12] <bulldog98> yofel: if it builds then upload it
[22:13] <yofel> it builds, and list-missing output matches what was in 4.6.5 not-installed, so I hope it's all right
[22:13] <yofel> uploading
[22:21] <bulldog98> yofel: btw I’m currently doing QML stuff, so my WIPs are gone
[22:21] <yofel> k
[22:37] <apachelogger> yofel: check the config
[22:39] <yofel> apachelogger: well, debian/config says: SVNREV=1242643, 4.7.1 tag is 1250835
[22:41] <apachelogger> interesting
[22:41] <apachelogger> doesnt make a difference though
[22:41] <apachelogger> as we only fetched desktop file translations
[22:41] <apachelogger> and those are not used anyway
[22:42] <yofel> ...
[22:43] <apachelogger> seems I only changed the changelog
[22:43] <apachelogger> fun
[22:44] <CIA-130> [kde-l10n-common] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/config align config with changelog... not that it made a difference we do not use desktop translations from launchpad this cycle
[22:45] <apachelogger> yofel: thx for noticing
[22:45] <yofel> yw
[22:50] <apachelogger> rbelem: https://bugs.launchpad.net/bugs/851668
[22:50] <apachelogger> you should poke jontheechidna too
[22:57] <apachelogger> bulldog98: http://kde-apps.org/content/show.php/Ponies+Everywhere?content=145448
[22:59] <bulldog98> apachelogger: bookmarked :)
[23:00] <apachelogger> ScottK: please reject touchegg-gui from NEW
[23:00] <apachelogger> 0.3 is not compatible with 1.0
[23:01] <apachelogger> and it is not clear whether we will get a compatible version in time
[23:18] <skaet> kubuntu daily-live 20110921.2 posted.   please flag in #ubuntu release if testing indicates there's a blocker level problem.
[23:18] <skaet> #ubuntu-release rather.
[23:19] <apachelogger> skaet: thanks
[23:42]  * bulldog98 now goes to bed and has a half working qml


[02:37] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: thunar 4.18.5 released<EMAIL_ADDRESS>[02:40] <Unit193> All these new releases and I can't touch them! :(
[06:57] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-mixer 4.18.0 released<EMAIL_ADDRESS>[06:57] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-mpc-plugin 0.5.3 released<EMAIL_ADDRESS>[06:57] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-netload-plugin 1.4.1 released<EMAIL_ADDRESS>[11:11] <Unit193> !info xfce4-mixer


[14:29] <xnox> infinity: stgraber: so the nfs thing is blocking automated cdimage qa. Any updates, or is it blocked on the massive initramfs merge =/
[14:30] <stgraber> xnox: infinity said he'd take a look. In theory we can workaround it in casper by adding the 3 modules I mentioned the other day, so we could do that if it's urgent
[14:31] <xnox> stgraber: yes, please. It's not urgent-urgent, but high. Up to now we still don't have automated ISO testing on the same level as we had throughout quantal cycle.
[14:32] <stgraber> xnox: do we have a bug number for this?
[14:33] <cjwatson> urgent> why not just add the relevant modules to initramfs-tools rather than either working around it in casper or waiting for the giant merge ...
[14:34] <xnox> stgraber: I don't believe we have one, apart from "jenkins bulb is red"
[14:35] <stgraber> hmm, good point. Let me see how to add those to initramfs-tools directly, once I find a packaging branch that's up to date...
[14:36] <stgraber> oh, it's just one revision behind, I can fix that easily
[14:37] <xnox> stgraber: note that the initramfs-tools version number is currently faked.
[14:37] <stgraber> xnox: yeah, I just meant that ubuntu:initramfs-tools is at 0.103ubuntu0.1 instead of 0.103ubuntu0.2
[14:37] <xnox> stgraber: oh _that_ revision =)
[14:38] <xnox> yeah QA are eager to get a working build.
[14:38] <stgraber> oh fun, the branch is busted in a similar way as ifupdown... so won't be able to fix it
[14:39] <stgraber> bug 1042396
[14:39] <ubot2> Launchpad bug 1042396 in bzr-builddeb (Ubuntu) "bzr-builddeb fails to import-dsc with native package on Ubuntu 12.04" [Undecided,New] https://launchpad.net/bugs/1042396
[14:39] <stgraber> will just do a manual upload
[14:40] <jibel> re urgent: it's blocking PS from running autopilot tests on hardware for raring.
[14:44]  * Laney wibbles
[14:44] <Laney> ./tests/run-pep8 gives a load of errors and fails the build for me locally, yet there aren't any commits (besides mine) since the release
[14:44] <Laney> (in ubiquity that is)
[14:45] <stgraber> yeah, the new pep8 is complaining a lot more
[14:45] <xnox> Laney: get fixin ;-)
[14:45] <stgraber> for example it now requires exact indentation when breaking a line
[14:45] <Laney> seems to be all about indentation
[14:45] <xnox> can it autofix those?
[14:45] <stgraber> right, that's what I've noticed too
[14:46] <stgraber> xnox: I doubt it, manually fixing those required quite a lot of magic for me in some other scripts
[14:46] <cjwatson> Perhaps --ignore= that for now
[14:46] <xnox> *sigh*
[14:46] <stgraber> xnox: as you actually need to break strings in half now to make it happy
[14:46] <stgraber> (you can no longer get away with doing print( and then the string at the beginning of the next line without indent as it'll report a no/or-missing indent)
[14:47] <stgraber> hmm, the initramfs-tools versioning is terribly confusing... 0.103 was introduced in quantal with 0.103ubuntu0.2 which is a SRU looking version number, yet it never was a SRU
[14:48] <stgraber> I guess I'll go with 0.103ubuntu1 then just to avoid messing with a potential SRU in quantal...
[14:48] <stgraber> ah, or not, changelog suggests it was done on purpose...
[14:49] <stgraber>   * NOTE: Not an actual merge, just a cherry-pick and reving the
[14:49] <stgraber>     version number to avoid having to touch the Breaks in klibc-utils
[14:49] <cjwatson> Yeah, make it 0.103ubuntu0.3 or whatever it is please
[14:49] <xnox> ^^^ "<xnox> stgraber: note that the initramfs-tools version number is currently faked."
[14:50] <stgraber> alright, uploaded
[15:19] <Laney> is d-i/update-control the file to edit to change ubiquity BDs?
[15:19] <cjwatson> yes
[15:19]  * Laney got rather distressed when his changes were clobbered
[15:19] <Laney> ta
[15:21]  * cjwatson starts in on thegiant pile of pep8 corrections
[15:22] <cjwatson> just mentioning since there's probably no point in >1 person doing this
[15:37] <stgraber> have fun :)
[15:38]  * stgraber gets back to fixing his other projects...
[15:42] <xnox> Laney: what are you coding for ubiquity?
[15:42] <xnox> =P
[15:42] <Laney> porting the webcam wotsit to gstreamer 1
[15:43] <xnox> Laney: thanks a lot =)
[15:43] <stgraber> yay, I won't be touched-it-last on that stuff anymore!
[15:43] <Laney> heh
[15:43] <Laney> it has Evan's name on it :P
[15:43]  * xnox is confused why ev is not all over the webcam plugin =))))))
[15:43] <stgraber> well, the last one who had to spend a week figuring out why the installer would hang on some laptops was me :)
[15:44]  * Laney fakes the commit logs
[15:44] <stgraber> (tracked down to a regression in gstreamer causing some kind of infinite loop)
[15:44] <xnox> stgraber: because the rest of us do not click to hw enable webcam on laptops while testing =)))))
[15:44] <stgraber> xnox: I don't actually have a single machine with a webcam builtin
[15:44] <ev> just because I wrote it, that doesn't mean I should be held accountable for it ;)
[15:44] <stgraber> xnox: I had to debug that one connected over ssh to London, working with gema's netbook
[15:45] <stgraber> ev: yes it does ;)
[15:45] <ev> shhhh you
[15:45]  * cjwatson tries to remember where the recommendation to indent closing brackets/braces in arrays/dicts came from
[15:45] <xnox> stgraber: 8-)
[15:45] <cjwatson> I always thought it was a bit bizarre but something somewhere enforced it and I thought it was PEP-8
[15:45] <cjwatson> but I don't see it there any more
[15:45] <ev> pylint maybe?
[15:45] <xnox> pyflakes ?
[15:46] <ev> I recall that being used way, way, way back in the early days of ubiquity
[15:46] <ev> or at least warnings being suppressed in comments
[15:46] <xnox> it will be hilarious if the new pep8 conflicts with pylint & pyflakes
[15:46] <ev> everything conflicts with pylint
[15:46] <ev> that's kind of the point
[15:46] <ev> WARNING: THERE'S SOME CODE HERE
[15:47] <stgraber> yeah, pylint just doesn't like you writting code, the only way to make something pylint-compliant is to not write it at all (IIRC pylint is happy when passed an empty file)
[15:47] <ev> lol
[15:47] <ev> I'm so amused that you've checked this
[15:47] <xnox> ev: maybe pylint should be one of the judges at the figure skating.
[15:47] <cjwatson> pyflakes doesn't seem to care
[15:47] <cjwatson> and I don't give a shit what pylint thinks :)
[15:47] <stgraber> actually, no, it's not happy with an empty file, you need an empty file with a docstring apparently nowadays :)
[15:48] <stgraber> C:  1,0: Missing docstring
[15:48] <Laney> pylint isn't very happy with pylint's code
[15:48] <xnox> stgraber: so what empty __init__.py is bad?
[15:48] <stgraber> xnox: yep
[15:48] <ev> lol
[15:49] <stgraber> xnox: echo '""" This file is empty """' > __init__.py
[15:49] <stgraber> then pylint is happy :)
[15:51] <cjwatson> aha, it's in the Launchpad Python style guide
[15:52] <cjwatson> that explains it
[15:52]  * cjwatson outdents a ton of stuff then
[16:27] <cjwatson> OK, ubiquity should be fine with pep8 now
[20:18] <stgraber> cjwatson: hey, pep8 question for you as I'm guessing you've seen more of it than I did :)
[20:18] <stgraber> parser.add_argument("--union-type", "-U", type=str, default="overlayfs",
[20:18] <stgraber>                     choices=("overlayfs", "aufs"),
[20:18] <stgraber>                     help=_(
[20:19] <stgraber> "type of union (overlayfs or aufs), defaults to overlayfs."))
[20:19] <stgraber> pep8 now complains about the last line as it's outdented
[20:19] <stgraber> the problem is that moving it to the line above will make the line length to be > 79 chars, so just trading pep8 errors really :)
[20:19] <stgraber> did you get any of those in ubiquity? and if you did, how did you "fix" them?
[20:20] <stgraber> an ugly hack would be to split into multiple strings and then just put them one per line below the help=_( block but that's ugly and I'm pretty sure gettext won't like it
[20:26] <stgraber> (commited an ugly "fix" to LXC for now, but I'm really not fond of having to use string concatenation to workaround this...)
[22:08] <cjwatson> stgraber: splitting the string is the usual answer, and I don't see why gettext wouldn't like it as long as you concat by just putting the strings logically adjacent to one another rather than with +
[22:08] <cjwatson> I'm fairly certain I've seen that working with gettext all over the place elsewhere
[22:09] <cjwatson> you can also give yourself more space by using the hanging indent style rather than the visual indent style
[22:10] <cjwatson> which I initially found a bit ugly but now find much easier to read as it tends to be more consistent
[22:10] <cjwatson> and is definitely more practical with multiple nested indentations


[00:00] <sveinse> Yes, I see that, though difficult at times. Like having a large, fast, buildserver which is useless in a armel farm
[00:01] <sveinse> But, back to another qemu issue:
[00:02] <sveinse> qemu crashes (consistenly on this machine) while compuing SSH2 keys
[00:02] <persia> With lots of output or almost no output?
[00:03] <sveinse> "Creating SSH2 RSA key; this may take some time ...qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[00:03] <sveinse> Segmentation fault"
[00:03] <sveinse> dpkg: error processing openssh-server (--configure):
[00:03] <persia> Get a stack trace (you can see what was being called from /var/lib/dpkg/info/openssh-server.postinst )
[00:04] <sveinse> I need to modify the rootstock (in order for it not delete the rootfs when failing) to inspect deeper
[00:04] <persia> If the crash is in ssh-keygen, then it probably needs fixing, but I doubt this is the case.
[00:04] <persia> More likely the crash is in the kernel, in which case it's qemu not handling something in the ideal manner.
[00:05] <sveinse> FYI I see some chatter on google about uncaught target signal 11 against armel
[00:05] <persia> That, or step through it more slowly, perhaps using qemu-debootstrap
[00:05] <sveinse> so it's not restricted to ubuntu or rootstock
[00:06] <persia> signal 11 just means "Segmentation Fault".
[00:06] <sveinse> aha
[00:06] <persia> If qemu was catching segfaults, we'd all be complaining about that because it would make it hard to debug things :)
[00:07] <persia> So, quick process to reproduce:
[00:07] <persia> 1) make a directory
[00:07] <persia> 2) populate a cross-chroot in that directory with qemu-debootstrap
[00:07] <persia> 3) chroot into the populated chroot
[00:07] <persia> 4) apt-get install openssh-server
[00:08] <persia> 5) After failure, inspect the postinst
[00:08] <persia> 6) Install your favorite debugging tools, and find the crash.
[00:10] <sveinse> you need apt-get in there as well, dont you?
[00:10] <persia> Hrm.  qemu-debootstrap lacks a manpage: it takes all the same arguments (with the same meanings) as debootstrap, so just use --arch=armel and otherwise follow the debootstrap model
[00:10] <persia> apt-get where?
[00:11] <sveinse> If you do 3)  apt-get need to be inside the chroot to do 4) right? Or have I misunderstood?
[00:11] <sveinse> baaah
[00:11] <sveinse> forget it
[00:11] <persia> Ah good.  I was getting very confused :)
[00:11] <sveinse> my bad, sorry
[00:11] <persia> No worries.
[00:15] <sveinse> Is there a way to create a rootfs where everything is downloaded, but not configured, and then later when the real target executes, let it do all the postinst steps?
[00:16] <sveinse> Rootstock at least fires up qemu to run the installer (or post installer, not sure on its specific task)
[00:18] <persia> Sure.  You can separate --first-stage and --second-stage in debootstrap.
[00:18] <persia> Take a look at the qemu-debootstrap code for a simple walkthrough of how one does this with qemu.
[00:19] <persia> Replicating that with hardware ought be relatively easy.
[00:19] <persia> Mind you, it's not necessarily safe to install lots of other stuff before running --second-stage, as the base system isn't configured yet.
[00:20] <sveinse> I see debootstrap retrieves, extracts, unpacks, configures. It seems to be the unpacking a later is done emulated. Am I right?
[00:20] <sveinse> *The unpacking stage and the preceeding steps are done emulated.  (it's getting late)
[00:21] <sveinse> I'll check qemu-debootstrap in all cases, thanks
[00:21] <persia> I'm not finding the source you're quoting.
[00:22] <persia> But debootstrap pulls the base system in a way that doesn't much care about dependencies, so it kinda handy to get a base.
[00:22] <persia> It does all of retrieval, extraction, unpacking, and configuration.  Based on the arguments, it can perform subsets of these actions.
[00:23] <persia> unpacking is safe to do on a foreign system: it's just unrolling tarballs.  configuration is *not* safe to do on a foreign system.
[00:23] <sveinse> Oh? How come?
[00:24] <sveinse> foreign being the target system which shall run ubuntu in the end?
[00:24] <persia> Because configuration scripts can run arbitrary binaries to accompish their goals.  Running these in a chroot with a foreign architecture will not work.
[00:24] <persia> Mind you, if you do things like the qemu-static binfmt trick, it's not really that foreign anymore
[00:25] <persia> (although qemu support isn't quite up to full hardware)
[00:25] <sveinse> And you could have binfmt back to intel on the armel (if such exits) to bridge the oposite gap?
[00:25] <persia> "foreign" meaning that the ISA for the code doesn't match the ISA for the machine on which the chroot is construted.
[00:26] <persia> It does exist.  it's supported by qemu-debootstrap.  It's so incredibly buggy that nobody should ever use it.
[00:27] <persia> the main issue is that qemu guest support for ia32 isn't well tested on armel hosts, and there don't seem to be any engineers wanting to try to fix discovered issues.
[00:27] <sveinse> And foreign is defined by the machine running qemu-debootstrap
[00:27] <persia> Sorta.
[00:27] <persia> A chroot is "foreign" if the instruction set in the chroot is not supported by the host.
[00:28] <persia> So an i386 chroot on an amd64 host is not foreign, but an amd64 chroot on an i386 host is foreign.
[00:28] <persia> armel chroots are foreign on everything not armel
[00:28] <sveinse> Since the configure step needs to be done "native" then you're basically tied to use all of debootstrap to make an image
[00:29] <persia> (although it may be that in the future armel chroots will not be foreign for armhf hosts)
[00:29] <persia> Well, you can reimplement debootstrap, but every image building tool I know starts with debootstrap.
[00:30] <sveinse> I'm trying to figure out why rootstock is considered "not for production" while debootstrap seems to be
[00:30] <persia> I'm not entirely comfortable with the passive voice in that sentence :)
[00:31] <persia> I don't consider rootstock suitable for production for three reasons:
[00:31] <sveinse> no offence, I'm truly curious. And since we're going to use ubuntu, I should know
[00:31] <persia> 1) It uses qemu-static binfmt hacks, such that the resulting image a) has extra files and b) is subject to any bug in qemu
[00:33] <persia> 2) It doesn't use the typical d-i based scripts for initial system configuration, which in practice may mean nothing more than a potential for bitrot, but may also be incomplete
[00:34] <persia> Hrm.  I remembered there being three, but the third one escapes me now
[00:35] <persia> Most likely, it was solved (since a lot of the issues passing through my head have corresponding memories of someone telling me they fixed it)
[00:35] <sveinse> I'll give you 3) openssh keygen & installation works fine on qemu-debootstrap, but fails on rootstock
[00:36] <sveinse> I've tried twice now
[00:37] <sveinse> OK, I've surely got a lot of very useful info here
[00:37] <persia> Heh.  Then 3) it's buggy :)
[00:37] <sveinse> :D
[00:37] <sveinse> I'm very grateful for the conversation!
[00:37] <persia> Aha!  rootstock still assumes versatile as an emulation host.
[00:39] <persia> (and apparently hardcodes a lucid kernel)
[00:39] <sveinse> Why should either affect qemu in respect of SSH keygen...
[00:40] <sveinse> rootstock is running a full VM, while deboostrap is only running chroot/binfmt?
[00:40] <persia> I believe that Ubuntu is currently shipping Linaro's QEMU, which I thought was no longer targeting versatile as primary.
[00:41] <persia> Rootstock works in three stages
[00:42] <persia> 1) debootstrap to populate a chroot
[00:42] <persia> 2) debootstrap under qemu-static to configure the chroot
[00:42] <persia> 3) fully-emulated environment to install random stuff
[00:43] <persia> Mind you, I'm not that familiar with the code, but that's how it appears to me from a quick look.
[00:43] <sveinse> sounds like I should move away from rootstock and integrate debootstrap instead
[00:43] <persia> debootstrap itself doesn't do anything architecture related.
[00:43] <persia> qemu-debootstrap (also not something I'd use for production) does the chroot/binfmt stuff.
[00:44]  * persia has fairly strong feelings about doing things natively, if this isn't already obvious
[00:44] <sveinse> I understand that
[00:45] <sveinse> What's the most powerful armel machine available? Because that is what you need to do such things natively, IMHO
[00:46] <GrueMaster> Available?  Possibly TI omap4 panda or nVidia Tegra.
[00:46] <persia> All the hardware I've used it IO-bound.
[00:46] <sveinse> Doing debootstrap on armel for armel is ok, right
[00:46] <persia> Find something (anything) with non-USB SATA, or other reasonable IO path, and you'll win.
[00:47] <persia> Even an OMAP3 should keep up.
[00:47] <GrueMaster> For I/O, Marvell is the best, but not available to the general public afaik.
[00:47] <persia> Native debootstrap is the basis for all official images.
[00:47] <GrueMaster> Is this just for image builds or for package compiling?
[00:47] <persia> I'm certainly happy with my Marvell IO performance, but it's not ARMv7a, so can't run native debootstrap for Ubuntu.
[00:48] <persia> Image builds.
[00:48]  * GrueMaster too lazy/busy to read backscroll.
[00:48] <GrueMaster> Ah.
[00:48] <persia> Backscroll summary: rootstrap is buggy and was being used on a high-speed build server for production images.
[00:48] <sveinse> An dual core ARMv7a with SATA is what I want I think
[00:48] <sveinse> hahahah
[00:49] <persia> sveinse, If you can find such a beast, then yes, that's precisely what you want.
[00:49] <GrueMaster> Well, for cost/speed, definately omap3/4 based atm.  Although the imx51 isn't bad in the Efika nettop.
[00:49] <GrueMaster> rootstock?  ouch.
[00:49] <persia> Just be sure to check the internal wiring: some devices claim SATA but really just have a USB<->SATA bridge, and you could do that yourself.
[00:49] <sveinse> persia, You work at reuters or something? That's the most compact summary I've ever read
[00:49] <persia> sveinse, I haven't worked with reuters is well over a decade, but thanks :)
[00:49] <GrueMaster> The efika is true sata.  Freescale fixed it post babbage3.
[00:50] <persia> GrueMaster, Really?  Nice!
[00:50] <GrueMaster> But only Cortex A8 (single core).
[00:50] <persia> debootstrap is single-threaded anyway.
[00:50] <GrueMaster> That's what I was told at UDS.
[00:51] <GrueMaster> Yea, but having one core focus on one thing while the other core handles normal tasks does provide some improvement.
[00:51] <persia> I heard the mx51 Efika's were currently at reduced prices, to clear inventory for the mx53s, so if single-core is enough, now is probably a good time.
[00:51] <GrueMaster> $125 for the nettop.
[00:51] <persia> Ah, you mean like handling the IO requests.  Heh.  Yeah.
[00:51] <persia> Yep.  That's about half what they were.
[00:51] <sveinse> I thought I heard a rumor about a armel server blade (for energy efficiency). I have no idea from where, though
[00:52] <GrueMaster> I've heard of that too.
[00:52] <persia> sveinse, I've been hearing all sorts of rumors like that for the past couple years, often from folk who really ought to know.  I have yet to see any retail products like that which support ARMv7a
[00:53] <persia> (retail servers with ARMv5te are plentiful though)
[00:53] <GrueMaster> https://www.genesi-usa.com/store/
[00:53] <GrueMaster> Oops.  $129.  My bad.
[00:53] <sveinse> That's like USB OTG. Have you guys ever seen a product with USB UTG? Which /uses/ the OTG part?
[00:54] <persia> Yes.
[00:54] <GrueMaster> UTG?
[00:54] <sveinse> sorry, typo
[00:54] <sveinse> its 2am here soon
[00:54] <GrueMaster> Ah.
[00:54] <GrueMaster> Time for more coffee.  :P
[00:55] <sveinse> Point is OTG is well defined by the USB standards, but it's very hard to come by any product and/or cables that are wired correctly
[00:55] <persia> You're not shopping in the right places :)  Cables are plentiful in some shops.
[00:55] <sveinse> It seems the industry and the standards dont line up on it
[00:56] <persia> The main issue is really that it's hard to figure out what it ought do.
[00:56] <sveinse> The product we're taking forward does include OTG. But all cables I've had in my hands are not correct
[00:56] <GrueMaster> I have found a few OTG cables that do work.  mini to usb host.  I've had a keyboard plugged into my beagle that way and it worked fine.
[00:57] <persia> In the limited context of using OTG on an Ubuntu system, the main issue is figuring out how to provide access to a useful filesystem when in gadget mode.
[00:57] <sveinse> Mini USB seems to be better supported, but micro is not
[00:57] <GrueMaster> Gadget mode is an entirely different thing.
[00:57] <persia> There's some micro cables around, but yeah, they're lots harder to get.
[00:57] <GrueMaster> I also found a micro to mini adapter.  Just got it Saturday, but haven't teted it yet.
[00:58] <cipher> are you using the beagle xM?
[00:59] <GrueMaster> I have one, yes.
[00:59] <persia> sveinse, Do you *need* to be micro, or would mini work?
[00:59] <sveinse> Too late in the design of the product. The tools for the enclosure are being built now
[01:00] <persia> Oh well.  Maybe find some online source of cables and point customers there.
[01:00] <sveinse> But mini are deprecated by USB, that's what puzzles me
[01:01] <persia> It is?  That's annoying.  I have *lots* of mini cables and ports around.
[01:01] <GrueMaster> True.  They are taller than micro, and the EU wanted a standard deployed across all cell phone markets.
[01:01] <GrueMaster> That's why the sudden conversion to micro.
[01:02] <sveinse> http://www.penguin.cz/~utx/hardware/USB_Mini/
[01:02] <GrueMaster> Gadget cables are plentiful.  It is the Host cables that are hard to find.
[01:03] <sveinse> Host cables being usbmicro to USB B (square) or USB A female receptacle?
[01:03] <persia> Right.
[01:04]  * sveinse want 10k cables of usbmicro to USB A female receptacle
[01:04] <GrueMaster> Would you like fries with that?  :P
[01:04] <persia> That quantity ought make it easier.
[01:06] <GrueMaster> Hmmm.  Just looked closely at my micro<>mini adapter.  It is for plugging a micro cable into a mini device, not the other way.  Useless.
[01:06] <rsalveti> sveinse: persia: rootstock uses qemu and debootstrap
[01:06] <rsalveti> but it copies the qemu-arm-static before doing the second phase of debootstrap
[01:06] <rsalveti> it can also run inside a full vm
[01:07] <rsalveti> and that's why it's using vexpress kernel
[01:07] <sveinse> yup. I just hoped finding it off the shelf somewhere. Yet the 5 cable samples I've tested all wires the ID pin incorrectly, so it's not trivial
[01:07] <rsalveti> but if you run with root, it just uses user mode emulation
[01:07] <sveinse> Which for some reason is crashing while computing ssh host keys
[01:07] <rsalveti> and the reason why rootstock is not suitable for production is that it's not the official tool to generate images
[01:08] <rsalveti> and not doing all the specific hacks used by live-rootfs to create the rootfs
[01:08] <persia> rsalveti, Do you think it ought migrate to use the omap3 kernel?
[01:08] <rsalveti> it creates the user with it's own way, and set the images using it's on setup
[01:09] <sveinse> I have two things when I start: A debian repo and a list of packages. They are to be installed into a image which shall be put into an sdcard in production.
[01:10] <sveinse> And if qemu-bootstrap is also dodgy because of qemu, then the only solution is to let an armel machine build the image for production
[01:10] <rsalveti> persia: last time I checked omap3 support you needed to create a whole bin image
[01:10] <rsalveti> with x-loader/u-boot and stuff
[01:11] <rsalveti> the only real problem with versatile is the ram restriction
[01:11] <rsalveti> besides that it works better with qemu
[01:11] <persia> Oh.  I thought the kernel team dropped versatile because omap3 support had improved enough to make it more suitable with qemu.
[01:12] <rsalveti> persia: well, it's hard to push omap 3 specific patches upstream
[01:12] <rsalveti> because upstream wants to emulate it exactly as the hardware should behave
[01:12] <persia> How far do we have to push?  I thought Ubuntu was shipping a special linaro-patched qemu
[01:12] <rsalveti> and versatile is kind of a virtual machine for qemu, no one actually check if the kernel really works with real hardware
[01:13] <rsalveti> yes, but last time I checked it was still missing some bits, would be nice to check it again
[01:13] <sveinse> rsalveti: My rootstock crashes when install openssh-server. It did not prior to it being upgraded from maverick to natty. Nor does my desktop machine (amd64) crash it.
[01:13] <persia> Some people have real versatile hardware, but not many, and it'&s known that the real hardware *can't* run Ubuntu (not ARMv7a compliant)
[01:13] <rsalveti> sveinse: unfortunately I'd recommend you to run natively on an ARM board if you want a stable tool
[01:13] <rsalveti> rootstock supports running on arm currently
[01:14] <rsalveti> versatile express should be fine
[01:15] <rsalveti> don't know how well that's support in qemu
[01:15] <persia> sveinse, What's your timeframe for getting the SD images complete?  If it's in July sometime, we should have clear instructions available for you beforehand.  If it's sooner, you may have some muddling to do.  (And no, you don't need to tell me the answer, just apply your answer to my comments)
[01:15] <sveinse> rsalveti: interestingly, this is the first time since the start of our project that it has crashed. It has been faithful since like nov -10. Daily builds, 10-20 builds per day
[01:15] <rsalveti> sveinse: this could be easy to fix, but then you'll end up having issues with mono
[01:15] <sveinse> Sure, we're still in development, so I can wait
[01:16] <persia> Hrm.  My usb micro host cables were from Green House Japan, but they don't seem to be offering any now.
[01:16] <rsalveti> if you don't use mono, or not plan to use, then rootstock should work in most of the cases
[01:16] <persia> It's not just mono: it's gotten buggier again because fewer folk are heavily using the qemu-static stuff.
[01:16] <sveinse> no mono, just this little regression :)
[01:17] <rsalveti> sveinse: do you have any specific change at your rootstock?
[01:17] <persia> And there's something else wonky: the openssh-server case works with qemu-debootstrap and not with rootstrap, which implies something rootstrap-specific as a bug.
[01:17] <rsalveti> sveinse: if not, can you paste me the logs? or cmd arguments you're using?
[01:18] <persia> s/rootstrap/rootstock/
[01:18] <sveinse> sure, hold on (takes a while)
[01:23] <sveinse> persia, does this mean you are working on docs for bootstrapping or a tool? (Since referring to july)
[01:25] <persia> sveinse, Yes.  Clear documentation of the Ubuntu image building infrastructure is something that's supposed to happen soon.
[01:25] <sveinse> excellent
[01:25] <persia> Presumably you could use this for your purposes.
[01:25] <sveinse> Seems so.
[01:25] <persia> Note that we're *not* attempting to generate documentation for full factory-automated installation at this point.
[01:26] <sveinse> No, I wouldn't expect that, nor demand such a thing
[01:26] <persia> I'd like it if we could provide that, but it's a hard problem still.
[01:27] <sveinse> And there are many holes to fall into I've noticed.
[01:27] <persia> I believe there's some work in progress to handle recovery partition creation, and presumably that could also be used to generate recovery media.
[01:27] <sveinse> E.g. rootstock as discussed. Previously (well haven't resolved it yet), the missing --sysroot from ubuntu/linary armel gcc
[01:28] <persia> But multicast distribution in a production environment is still several steps away (mostly because very few hobbyists have the infrastructure to test such things, and most people who build them like to sell their solutions)
[01:29] <sveinse> Our strategy is to make an sd-image which is duplicated across all units. And then we run a firstboot to make the units unique based on information from other sources
[01:30] <persia> I'd strongly recommend using oem-config as that "firstboot".  If it doesn't work for you, let's fix that, rather than have lots of implementations.
[01:30] <sveinse> Thanks, I'll look into it
[01:31] <persia> oem-config basically wraps d-i components for personalisation of a preconfigured system.  Does stuff like handle user creation, hostname assignment, timezone & locale information, etc.
[01:31] <sveinse> nice
[01:32] <persia> Since you're installing openssh-server, you may also be interested in looking at vm-builder: I'm not sure if all the work done there to ensure post-boot systems has migrated into oem-config, but you will want to have that set of hacks as well (stuff like regenerating SSH keys on first boot, etc.)
[01:33] <sveinse> openssh-server is a development tool for now
[01:33] <persia> Heh, OK.  If you're doing something like a desktop, handheld, phone, etc. then oem-config should have all the right bits already included.
[01:33] <persia> If you're doing a server, then I'm not sure it's as ready.
[01:34] <sveinse> while I'm at it: Our guys are reporting stability problems between Qt (QWS) and Natty. Is this something which is familiar?
[01:34] <sveinse> I haven't had time to dig into the issue, so I don't know first hand
[01:35] <persia> I've had a few things crash on my Kubuntu netbook, but most stuff seems to work.
[01:35] <persia> (that being natty/armel)
[01:35] <persia> The key thing is to report the bugs: if you can make something crash, it ought be fixed.
[01:36] <sveinse> Perhaps I should diff the qt4-x11 sources and the stock qt. Because we are on stock qt (due to support from Nokia)
[01:37] <sveinse> Yes, I'll report any bugs I come across. Just wanted to hear if its known to be unstable
[01:37] <persia> Works for me, but that's only one data point, and I don't claim to use that system that much.
[01:38] <sveinse> but thanks, it does help
[01:40] <sveinse> rsalveti: I have to sleep now, but I'll get hold of you if I'm able to reproduce the crash
[01:40] <persia> Just checked: there's a heap of patches against Qt.  You don't need to diff though: just `apt-get source qt4-x11` and look in debian/patches
[01:40] <sveinse> Thanks
[01:40] <rsalveti> sveinse: sure
[01:40] <persia> kubuntu_23_arm_memory_barriers.patch is one of the things you may require :)
[01:40] <sveinse> persia, yes, there's lots
[01:42] <sveinse> persia, thanks you for your insights and discussions. I've learned a lot. In fact I shall bookmark the irc logs from this evening
[01:44] <sveinse> good night
[05:58] <MrCurious> i am not entirely sure what the omap4 package has done for me
[06:24] <MrCurious> so i repeated the process with 11.04 that i used for 10.10, and it is corrupt again. and barfing on package updates.i even used a new SD card
[09:15] <sveinse> rsalveti, still awake?
[09:39]  * persia suspects it will be a couple hours yet
[12:52] <rsalveti> sveinse: I'm away now :-)
[12:52] <sveinse> ok, I'm not in a hurry
[15:48] <hrw> shit. my panda has rescue rootshell and getty running in same time on ttyO2 ;(
[15:49] <ogra_> did you boot oem-config without splash enabled ?
[15:49] <hrw> no, old rootfs with new kernel/initrd
[15:50] <ogra_> got "single" on the cmdline ?
[15:50] <hrw> panda login: General error mounting filesystems.
[15:50] <ogra_> upstart usually only fires up the rescue shell if you tell it to
[15:50] <ogra_> oh
[15:50] <hrw> fun is that / /home are properly mounted
[15:50] <ogra_> yeah, you likely had an fsck on your display ;)
[15:51] <ogra_> it will redirect that to the splash ... if you work remotely that indeed doesnt help
[15:54] <hrw> ok, upgrading my ubuntupandaa1 to oneiric
[15:54] <jayabharath> ogra_: Here are the logs and reports on the SD card sesize issues on 11.04 on PandaBoard http://groups.google.com/group/pandaboard/browse_thread/thread/76d19fab249a1ce9#
[15:54] <jayabharath> GrueMaster: ^^^ a follow up from our recent IRC discussion
[15:55] <jayabharath> Please feel free to study them and request more info on that thread... or log a trouble ticket if that is more appropraite
[15:55] <hrw> 466MB to download, 217MB extra used on disk. 955 packages to upgrade, 95 new to install, 3 to remove, 1 on hold
[15:55] <ogra_> jayabharath, /var/log/jasper.log would be intresting ... and a proper bug report
[15:56] <jayabharath> Atleast a couple of folks included the jasper.log
[15:56] <jayabharath> do you want me to put a bug report into the system?
[15:57] <ogra_> that would help, yep, and tell people to add their stuff there
[15:57] <jayabharath> ok
[15:57] <jayabharath> Seems like we are having a lot more problem reported with natty than with maverick
[15:57] <GrueMaster> I have the same hw as magog96 (Transcend 16G Class 10 SDHC & Panda A1).  Worked fine here.
[15:58] <hrw> ~hail apt-cacher-ng
[15:58] <jayabharath> it could also be that we now have a larger user base .. i.e. more testing and more possiblity of user errors ;)
[15:58] <GrueMaster> Most of them appear to be A2/A3 pandas.
[15:59] <GrueMaster> Which I don't have to test with (backorder).
[15:59] <jayabharath> GrueMaster: We can try to update your pandaboard with a newer version... should not be a issue.
[16:00] <hrw> have a nice rest of day
[16:09] <GrueMaster> jayabharath: I have noticed sproadic issues with natty on my A1, but have not been able to reproduce them.  During testing, I would see them once or twice a week when testing daily images.  Most of the time, it was just a matter of oem-config restarting instead of completing, but there was never any signs of corruption.
[16:09] <GrueMaster> And oem-config would complete on the second pass.
[16:09] <GrueMaster> I wonder if it is something in x-loader/u-boot that ships with natty?
[16:19] <martyn> Okay, one thing I just figured out about the i.mx53 boards -- they overheat
[16:19] <martyn> fast
[16:20] <martyn> Those processors actually need a heatsink.
[16:20] <ogra_> did you check for an intel logo on the SoC ?
[16:21] <GrueMaster> heh
[16:21] <martyn> *snicker*
[16:21] <GrueMaster> Intel processors don't overheat.  They throttle back to almost off when they reach 75C.
[16:22] <martyn> They could have done a much better job on the thermals .. this thing needs a heatsink, and they should have installed one on every board
[16:22] <ogra_> persia, NCommander, do you guys remember wheer the spice seed notes are (i know for sure both of you were in the room when we discussed them) ... infinity got that spec assigned but it seems to be empty
[16:24] <NCommander> ogra_: they should be on the etherpad document
[16:25] <ogra_> hey infinity
[16:26] <infinity> o/
[16:28] <ogra_> infinity,  challenge your javascript interpreter a bit ... http://summit.ubuntu.com/uds-o/meeting/other-o-arm-seed-spices/
[16:28] <NCommander> WOOO infinity !
[16:29] <martyn> hmm?
[16:30] <infinity> ogra_: That looks decidedly unfinished.  Fun!  I especially like "Talk to lamont + kamion to make sure design is workable"
[16:30] <ogra_> lol
[16:31] <ogra_> well, talk to persia, NCommander or me if you need explanation, we were in the BOF session and *might* remember one or the other bit
[16:31]  * infinity laughs.
[16:31] <infinity> Cause it was oh-so-long ago, right? :)
[16:32] <ogra_> indeed ... and there were these beers at night
[16:32] <NCommander> Basically we decided to implement it with metapackages
[16:32] <ogra_> *hungarian* beers
[16:32] <NCommander> persia was talking notes
[16:32] <martyn> Belgian beers too
[16:32] <martyn> some pretty strong ones, as I recall
[16:32] <ogra_> pfft
[16:33] <ogra_> belgian  "beer"
[16:33] <martyn> infinity: It's been a whole _month_ ...
[16:33] <infinity> NCommander: Metapackages shouldn't be entirely necessary, but I'm happy to get back in on the discussion in a bit, if I'm expected to implement the results. ;)
[16:33]  * martyn starts the biervars with Oliver
[16:33] <ogra_> infinity, just make it work properly ...
[16:33] <ogra_> we dont care about how :P
[16:34] <GrueMaster> Wait, what?  We were in sessions between beer???
[16:34] <ogra_> GrueMaster, thats when you sat down ... remember ?
[16:34] <GrueMaster> But I sat most of the time...oh, wait.
[16:35] <martyn> *chuckle*
[19:14]  * pmathews wonders if there is a channel for low power RF devices from TI
[21:23] <hrw> ogra_: Ubuntu uses x-loader-omap4 L24.9git20100901-0ubuntu5 or x-loader-panda?
[21:24] <GrueMaster> hrw: x-loader-omap4-panda 1.5.0+git20110325+b6bbfe7-1ubuntu1
[21:26] <GrueMaster> At least that is what is currently in oneiric.
[21:46] <dumarjo> I have some problem using rootstock on ubuntu 11.04 to build an lucid image for gumstix board
[21:47] <dumarjo> I have some segfault for the locale and I also have an error about E: Sub-process /usr/bin/dpkg received a segmentation fault.
[21:47] <dumarjo> E: Second stage build in chroot failed !
[21:47] <dumarjo> E: Please see the log to see what went wrong.
[21:47] <dumarjo> can someone can help me to resolv this ?
[21:48] <GrueMaster> dumarjo: Why lucid?  Why not just use our natty-headless image?
[21:48] <dumarjo> I can try
[21:48] <dumarjo> so I use -d natty ?
[21:49] <GrueMaster> You are creating an image to run from SD, right?
[21:49] <dumarjo> yes
[21:49] <dumarjo> but i would to use qemu too
[21:49] <GrueMaster> Just download the pre-installed image and flash to an SD card.
[21:50] <dumarjo> from the gumstix web site ?
[21:50] <GrueMaster> http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-headless-armel+omap.img.gz
[21:50] <GrueMaster> This will run through a serial console.
[21:51] <davidm> GrueMaster, he is using a gumstix, might not work
[21:51] <GrueMaster> I thought it was tested by linaro to work.
[21:51] <davidm> I don't have documentation on that
[21:52] <davidm> we should put that on the wiki if Linaro did indeed test it
[21:53] <dumarjo> is this image can be use with qemu ?
[21:57] <dumarjo> same error
[21:57] <dumarjo> I use this command line
[21:57] <dumarjo> sudo rootstock --fqdn WebNode --login gumstix --password gumstix --imagesize 2G --seed linux-image-omap,ubuntu-minimal --notarball -d natty
[21:57] <dumarjo> something wrong in taht ?
[21:58] <GrueMaster> looks ok.
[22:05] <dumarjo> ok then. I wil have to tale a look close towmorrow... thanx for your helps
[22:45] <hrw> GrueMaster: then it should provide upgrade path - my natty panda had L24.9 one and dpkg errors out with it as it's version does not begin with digit
[22:45] <hrw> GrueMaster: natty -> oneiric upgrade catched that
[22:48] <hrw> ubuntu kernel for panda still had cyan fb ;(


[18:55] <Pici> fyi, I'm out of town for a few days. I'm off from work on Monday, so I'll try to get the new ubottu up and running then
[18:58] <Mikaela> AlanBell: what is the situation with meetingology?