[01:52] <InHisName> Good evening all
[10:06] <rmg51> Morning
[11:54] <waltman> morning
[23:24] <InHisName> Only one morning from waltman and then, me at 7pm?  such a quiet day.


[00:00] <apachelogger> jtechidna: hehe, we were fiddeling with his wlan @ FOSDEM IIRC ;-)
[00:00] <jtechidna> it's nice to see Kubuntu get good press right on planet kde :)
[00:01] <apachelogger> yes, there is too few of that
[00:46]  * JontheEchidna got networking back
[00:46]  * JontheEchidna uninstalls network manager now that he doesn't need it
[03:00] <DaSkreech> Whoot!
[03:00] <DaSkreech> Grat apachelogger
[03:00] <DaSkreech> I just wanted to confirm that there is no migration plan for those on KDE4 now to Ibex?
[03:02] <ScottK-laptop> I think that puts it too strongly.
[03:02] <ScottK-laptop> But I don't know the details.
[03:04]  * DaSkreech speaks specifically of those users with apps in /usr/lib/kde4/ and settings in ~/.kde4
[03:05] <ScottK-laptop> The data doesn't get migrated.  That's true, but I'd imagine that could be done manually after upgrade.
[03:06]  * DaSkreech is pretty sure that cp ~/.kde4 ~/.kde will screw up a lot of crap
[03:06] <ScottK-laptop> I had some KDE4 stuff installed when I upgraded and the packages got replaced OK.
[03:06] <ScottK-laptop> Why?
[03:07] <DaSkreech> Well wouldn't it over write the data in ~/.kde ?
[03:07] <ScottK-laptop> I don't actually know, but the KDE3/KDE4 .kde dirs are generally forward compatible, so I doubt replacing KDE4 data with other KDE4 data would be problematic.
[03:08] <DaSkreech> It wouldn't have kde4 data in there
[03:08] <DaSkreech> it would be kde3 data from way back when that's all existed
[03:08] <JontheEchidna> if it's overwritten it's gone
[03:08] <DaSkreech> I know
[03:09] <DaSkreech> Which is why I was asking if there is no migration path?
[03:10] <ScottK-laptop> I see.
[03:10] <ScottK-laptop> I was thinking you wanted to migrate Hardy -> Intrepid and have KDE4 data come forward instead.
[03:11] <ScottK-laptop> Not sure how you would merge .kde and .kde4.
[03:11] <DaSkreech> Yeah
[03:13] <ScottK-laptop> So it looks like moving to bluez 4 changed the whole package structure.  kdebluetooth now depends on a transitional package.
[03:13] <ScottK-laptop> Someone ought to look into that.
[04:17] <NCommander> ScottK, I'm involved in the bluez change, whats the issue
[04:40] <ScottK-laptop> First, kdebluetooth now depends on a transitional pacakge.  That's not a good plan for the future.
[04:40] <ScottK-laptop> So what should it dependon instead?
[04:40] <ScottK-laptop> NCommander: ^^
[04:41] <ScottK-laptop> As was a bit suprised to find the bluez-gstreamer package in my default Kubuntu install, but I
[04:42] <ScottK-laptop> I've got libgstreamer installed anyway for other reasons, so it's not as far out as I initially thought.
[04:42] <ScottK-laptop> NCommander: Do you know if any KDE people tested it?
[04:44] <NCommander> Hrm
[04:45] <NCommander> I didn't test it in KDE ...
[04:45] <NCommander> I don't know if anyone did
[04:45] <ScottK-laptop> superm1 asked me to, but I didn't get to it.
[04:47] <NCommander> Whats the transitional package kdebluetooth is depending on?
[04:49] <ScottK-laptop> bluez-utils
[04:49] <NCommander> ScottK, I think you need to depend on package Bluetooth now
[04:49] <NCommander> Checking
[04:50] <ScottK-laptop> Back in a few.
[04:57] <ScottK-laptop> NCommander: Back.
[04:57] <NCommander> wb
[05:03] <ScottK-laptop> NCommander: Did you see my ping about openexr on sparc a coupld of days ago?
[05:03] <NCommander> oh yeah, that slipped my mind
[05:03] <NCommander> Crap
[05:04] <NCommander> The only machine I can build for sparc is spooky (REVU), so I'm not so sure I can work on that one
[05:04] <ScottK-laptop> Err or was it hppa?
[05:04] <NCommander> sparc
[05:08] <ScottK-laptop> NCommander: That one was hppa: https://launchpad.net/ubuntu/intrepid/+source/openexr/1.6.1-3
[05:08] <ScottK-laptop> I did ping you about a sparc one.
[05:09]  * NCommander notes something about you hating me
[05:10] <ScottK-laptop> Yeah, but I hate everybody.  At least you're useful.
[05:10] <ScottK-laptop> OK, not hate, but I am in a really foul mood at the moment.
[05:12]  * Hobbsee echoes hate back at ScottK-laptop just to make him feel better
[05:15] <ScottK-laptop> NCommander: I give you Bug #279983
[05:16]  * NCommander dunks his bluetooth dongle in soda
[05:16] <NCommander> Sorry, I don't have the necessary hardware
[05:17] <rgreening> :P
[05:18] <rgreening> ~order for NCommander blueberry pie
[05:18] <rgreening> dang... no pie
[05:18] <NCommander> I love blueberries!
[05:18] <NCommander> ;.;
[05:18] <NCommander> ARGH
[05:18] <rgreening> and blue teeth
[05:18] <rgreening> tooth
[05:18] <rgreening> :)
[05:30] <ScottK-laptop> NCommander: rebuilding doesn't seem to help.
[05:32] <DaSkreech> If I'm remastering a Cd and want a personal script installed as a command I'll have to make a Deb?
[05:35] <ScottK-laptop> Any kdebluetooth ninjas in the audience ...
[05:57] <yuriy> anybody using fglrx on intrepid?
[06:33] <DaSkreech> I might be
[06:37] <ScottK-laptop> Riddell: Bug #279983 looks to be a strong sign (according to superm1) that kdebluetooth needs updating to work with the new bluetooth stack uploaded today.
[07:33] <dbglt> is anyone working on fixing up update-notifier-kde?
[07:41] <DaSkreech> mornfall: ping
[07:41] <DaSkreech> Drat
[08:16] <jussi01> Morning all!
[08:16] <Arby> morning
[08:17] <jussi01> An I just noticed /topic, so Congrats apachelogger!
[08:35] <dbglt> hrmm, maybe this channel is better: odd. any reason why python-kde4-doc doesn't include the binary pykdedocs anymore?
[08:39] <dbglt> apparently not part of the latest build
[08:39] <dbglt> weird
[09:00] <stdin> kde4bindings-4.1.2$ find . -type f -name "pykdedocs*"
[09:00] <stdin> ./python/pykde4/docs/html/pykdedocs.html
[09:00] <stdin> dbglt: doesn't look like it even in the source package
[09:01] <dbglt> stdin: yeah, just checked svn as well
[09:01] <dbglt> stdin: odd, and kind of annoying
[09:01] <dbglt> but oh well! :)
[09:40] <thekorn> hi, short question, what's the right target for bug reports about konqueror, kdebase?
[11:57] <Hobbsee> thekorn: yes, iirc.
[11:58] <apachelogger> jussi01: thx :)
[12:17] <smarter> yeah https://bugs.launchpad.net/bugs/267705 :)
[12:22] <Riddell> smarter: what's that needed for?
[12:22] <smarter> Kalzium equation solver
[12:22] <smarter> I'm creating a debdiff right now
[12:28] <smarter> Riddell: if you could please upload that :) http://smarter.free.fr/pkg/kdeedu_4.1.2-0ubuntu1_to_ubuntu2.debdiff
[12:31] <Riddell> smarter: that it?  no new files needing adding to the packaging?
[12:31] <smarter> nop, cmake does the magic stuff
[12:31] <smarter> and everything is in the kalzium binary afaik
[12:31] <smarter> I could check
[12:31]  * smarter debuilds and debian/rules list-missing
[12:32] <smarter> I already did when I hacked my own package because I wanted to use the equation solver, but rechecking can't be bad :)
[12:41] <apachelogger> Riddell: should I poke pitti about bug 267599
[12:42] <Riddell> apachelogger: yes please
[12:50] <Riddell> ScottK-laptop: so superm1 uploaded a new bluetooth stack after beta and then says its the fault of kdebluetooth for not being new enough?
[12:50] <Riddell> Tonio_: able to look at bluetooth?  I know nothing about it
[12:50] <Riddell> https://launchpad.net/bugs/279983
[13:07] <smarter> Riddell: I just checked again, adding the build-dep is enough to make the eqsuation solver works :)
[13:07] <smarter> *equation
[13:07] <Riddell> thanks smarter
[13:08] <rgreening> Riddell: could this be a dbus issue? I've seen a lot of bug reports coming in from Python with "DBusException in call_blocking()"?
[13:09] <rgreening> coincidence?
[13:09] <smarter> Riddell: also, could you upload bespin -0ubuntu3? bzr branch lp:~kubuntu-members/bespin/ubuntu && bzr diff -r20..21 > bespin.debdiff
[13:10]  * smarter bbl
[13:10] <smarter> see you later guys
[13:10] <rgreening> Riddell: Did you upload the qtjambi I sent? If not, hold off, I want to add a quick fix (bug 250002)
[13:16] <Riddell> rgreening: I did
[13:16] <rgreening> Riddell: Ok, I'
[13:17] <rgreening> I'll send a new rev. to fix the afore meantioned bug. closes last qtjambi bug
[13:20] <JontheEchidna> apachelogger: bug 279996
[13:20] <JontheEchidna> The package desc still has a tiny bit of wa left in there :P
[13:21]  * apachelogger doesn't think that is uploadworthy
[13:21] <apachelogger> Riddell: did you upload 4.1.2 l10n yet?
[13:22] <rgreening> Riddell: the Dbus Call_Blocking all are either dbus or python related. I wouldn't blame this (necessarily) on bluetooth. I just got an exception and it's for kbluetoothd (which is python based) and calls the dbus error
[13:23] <JontheEchidna> Jockey and guidance-power-manager have been getting similar DBus problems
[13:24] <rgreening> yep. either we have a dbus or pythnon prob (IMHO)
[13:24] <rgreening> s/pythnon /python
[13:24] <JontheEchidna> apachelogger: latest l10n is 4.1.2
[13:24] <apachelogger> well
[13:25] <apachelogger> if I get round to upload before intrepid... otherwise we are going to fix that for 4.1.3
[13:25] <Riddell> apachelogger: yes
[13:27] <Riddell> JontheEchidna: I can upload a fix if you have a debdiff for that
[13:28] <JontheEchidna> Riddell: I don't have one yet, currently mucking around with -workspace
[13:28] <Riddell> JontheEchidna: what are you doing to -workspace?
[13:28] <Riddell> I hvae rendering errors today
[13:28] <JontheEchidna> Riddell: fixing libtaskmanager includes
[13:31] <JontheEchidna> which I sorta messed up with my tooltips patch
[13:33] <rgreening> Riddell: see bug 139154. I'll test out the patch comment and see if it fixes the dbus exception.
[13:34] <rgreening> Riddell: it'
[13:34] <rgreening> is an old bug it seems...
[13:34] <seele> hmm.. ntpd isn't running by default?
[13:34] <seele> anyone running a beta install instead of upgrade?
[13:36] <seele> hmm.. was kdesudo supposed to be fixed?
[13:45] <jussi01> seele: I am (running a beta install)
[13:46] <seele> jussi01: is Set date and time automatically turned on for you in System Settings > Date & Time?
[13:47]  * jussi01 looks
[13:47] <jussi01> seele: no.
[14:13] <seele> hmm.. do you think ntp should be turned on by default? most computers have a network connection, and even if it drops (such as with a laptop), it won't throw an error, it just waits until the connection comes back
[14:14] <Riddell> I'm sure we (used to) have ntp running by default, as a daemon not at the kde level
[14:15] <rgreening> ntpd is a good thing
[14:29] <Riddell> seele: yep, ntp should run when a network connection is made
[14:34] <seele> Riddell: we can do it for Ibex?
[14:35] <Riddell> seele: we do, and always have
[14:37] <seele> ntp but not the kde daemon?
[14:38] <Riddell> right
[14:38] <Riddell> kde is the wrong level to have you time sync being done
[14:39] <seele> ok.. so how do we fix the problem of the option not being turned on in system settings?
[14:40] <seele> is it looking at the kde daemon instead of elsewhere?  it's misleading if it is turned off but ntpd still updates time
[14:41] <Riddell> probably we should just remove that from the UI
[14:46] <seele> hum
[14:47] <nixternal> are we install pidgin by default?
[14:48] <nixternal> wow I can spoke this morning :)
[14:48] <seele> why would we have pidgin?
[14:48] <Riddell> nixternal: no
[14:48] <nixternal> ahh, it is probably left over from my gnome install
[14:48] <seele> is kopete borked?
[14:48] <nixternal> forgot i did that
[14:48] <nixternal> seele: it is for me
[14:48] <nixternal> I send people messages and it is in HTML markup
[14:56] <Riddell> nixternal: can we test that?
[14:56] <Riddell> apachelogger: I just added --dist-upgrade to update-manager-kde you'll be pleased to know
[15:12] <smarter> Riddell: I just noticed update-notifier-kde was not running, I started it and a systray popup said that I had "Apt Authentification Issue", it asked me to click on "Run this action now"(strange name for a button), but nothing happened when I clicked on it
[15:13] <smarter> and according to the command line, it's trying to run gksu
[15:13] <smarter> /bin/sh: gksu: not found
[15:13] <smarter> this line appears everytime I click on the button
[15:14] <Riddell> smarter: what's in /var/lib/update-notifier/user.d/ ?
[15:15] <smarter> apt-auth-failure.note  firefox-3.0-restart-required  fuse-utils-needs-users-added-to-fuse-group  user-must-execute-asoundconf-set-default-card
[15:15] <smarter> in apt-auth-failure.not there is:
[15:15] <smarter> Command: gksu -- synaptic --non-interactive --update-at-startup --hide-main-window
[15:30] <Riddell> smarter: I'm poking mvo on #ubuntu-devel
[15:30]  * smarter looks :)
[15:41]  * jussi01 sighs that flash is so horrible in intrepid. :(
[15:42] <apachelogger> Riddell: I don't have update-manager-kde
[15:42] <Riddell> apachelogger: you're missing ouy
[15:42] <Riddell> apachelogger: you're missing out
[15:43] <Riddell> update-notifier-kde I mean
[15:43] <apachelogger> Riddell: update-notifier-kde: Unknown option 'dist-upgrade'.
[15:44] <Riddell> you'll need the version that probably isn't in the archives yet
[15:44] <apachelogger> *nod*
[15:45]  * apachelogger prepares workspace for upload
[15:45] <Riddell> apachelogger: workspace?  I think JontheEchidna is doing stuff to that
[15:45] <JontheEchidna> apachelogger: ye got my patch?
[15:45] <apachelogger> yus
[15:45] <apachelogger> JontheEchidna: I hope you didn't forget to unbreak something :P
[15:45] <JontheEchidna> kool
[15:46] <Riddell> toscalix!
[15:49] <JontheEchidna> Oh, crap
[15:49] <JontheEchidna> Lancelot uses the Taskmanager lib
[15:50] <JontheEchidna> meaning the toolitps patch broke it
[15:51] <apachelogger> that explains a lot
[15:51] <apachelogger> JontheEchidna: time to remind you of apachelogger's primary rule of packaging
[15:51] <JontheEchidna> yeah yeah...
[15:51] <JontheEchidna> patches are evil (tm)
[15:54] <JontheEchidna> just means more work for me, lol
[15:54] <smarter> JontheEchidna: ooh, that's why lancelot was not working anymore
[15:54] <apachelogger> IMHO you should grab all the plasma related stuff and grep for other stuff that links against tasmanager
[15:55]  * smarter was sure this patch was going to causes some problems :P
[15:55] <apachelogger> well, it's a patch :P
[15:58] <apachelogger> JontheEchidna: first line of the debdiff exceeds 80 chars
[15:59] <apachelogger> JontheEchidna: did you take the changes for a testdrive?
[16:03] <JontheEchidna> apachelogger: tooltips still work
[16:03] <apachelogger> k
[16:07] <ScottK> Riddell: Apparently asking for testing with KDE is enough.  It's not an issue if it's not actually done (bluetooth).
[16:11] <JontheEchidna> Crap, Lancelot's taskmanager code is the same in trunk as it is in 4.1....
[16:14] <smarter> JontheEchidna: maybe it needs a rebuild?
[16:14] <JontheEchidna> maybe
[16:15] <kde4> #digikam
[16:15] <JontheEchidna> That would cause binary incompatibility, come to think of it
[16:23] <apachelogger> kde4: eh?
[16:24] <apachelogger> is bug 280099 actually a bug?
[16:27] <JontheEchidna> apachelogger: I didn't fix it all the way
[16:27] <JontheEchidna> Lancelot fails to build here \o/
[16:27]  * Riddell adds libqca2-plugin-ossl to seeds
[16:28] <apachelogger> Riddell: please add xterm as well
[16:28] <Riddell> why?
[16:28] <apachelogger> needed for KDM's failsafe
[16:28] <apachelogger> I actually think we should just add it as dep for kubuntu-desktop as all the other -desktop's depend on it as well
[16:29] <Riddell> it was removed from the seeds because we have good terminal applications this millenium
[16:29] <Riddell> if kdm needs it, then kdm should depend on it
[16:29] <apachelogger> kdm recommends it
[16:29] <Riddell> sorted
[16:29] <apachelogger> hm
[16:29] <apachelogger> ok
[16:29]  * apachelogger won't fixes the bug report
[16:29] <Riddell> is it really in the ubuntu.desktop seed?
[16:30] <JontheEchidna> apachelogger: oh, or maybe not. I think it's fixed all the way
[16:30] <apachelogger> Riddell: apt-cache show ubuntu-desktop | grep xterm
[16:30] <Riddell> hmm, so it is, I'm sure that was removed some releases ago
[16:31] <apachelogger> Riddell: maybe we should patch kdm to use konsole, I guess if kdelibs is broken KDM won't start anyway
[16:32] <Riddell> it should use konsole if xterm isn't around at least
[16:33]  * apachelogger looks for some existing alternatives
[16:34] <apachelogger> or maybe write a shell script
[16:45] <JontheEchidna> Yay, lancelot works after a rebuild
[16:48] <JontheEchidna> apachelogger: http://paste.ubuntu.com/55316/
[16:48] <JontheEchidna> can haz sponsor?
[16:53] <apachelogger> uploaded
[16:53] <apachelogger> workspace also uploaded
[16:53] <JontheEchidna> thinking about it
[16:53] <JontheEchidna> it does need workspace 0ubuntu6 to work
[16:54] <JontheEchidna> or else it'll ftbfs
[16:56] <apachelogger> I guess it will ftbfs then :P
[16:56] <apachelogger> JontheEchidna: next time bump the build-dep
[16:59] <apachelogger> I think my desktop containment just exploded
[17:05] <apachelogger> JontheEchidna: can you reproduce bug 280134
[17:08] <JontheEchidna> apachelogger: yes
[17:08] <apachelogger> weird, does work here
[17:08] <apachelogger> JontheEchidna: what happens if you don't minimize the window?
[17:09] <JontheEchidna> still new window
[17:10] <apachelogger> JontheEchidna: please make a snapshot of your konqueror config dialog
[17:10] <apachelogger> JontheEchidna: you try launching it from kmail?
[17:11] <JontheEchidna> yes
[17:11] <JontheEchidna> oh
[17:11] <JontheEchidna> hmm, maybe that's why
[17:11]  * JontheEchidna missed a setting
[17:13] <JontheEchidna> nope, still no good
[17:13] <apachelogger> screenshot
[17:14] <JontheEchidna> actually
[17:14] <JontheEchidna> it works, just not with the initial window
[17:14] <apachelogger> well
[17:14] <apachelogger> it doesn't claim so, does it? :P
[17:14] <JontheEchidna> I opened konq via kmenu
[17:15] <JontheEchidna> clicked a clickly link in kmail -> new window pops us
[17:15] <JontheEchidna> *up
[17:15] <JontheEchidna> clicked another link in kmail, new tab in new window shows up
[17:15] <apachelogger> m
[17:15] <apachelogger> hm
[17:15] <apachelogger> maybe mention that and forward the report to kde
[17:56] <apachelogger> JontheEchidna: plz join #oxygen
[18:04]  * Riddell uploads adept to hardy-proposed with skip_intrepid patch
[18:38] <Riddell> rgreening: uploaded update-notifier hanks
[18:38] <Riddell> thanks
[18:39] <rgreening> Riddell: np. one less to cause headaches :) and dup bugs and no update notifications... :)
[18:39] <rgreening> plus, it annoyed me. it was always crashed. hehe
[18:40] <rgreening> Riddell: I have an update for qtjambi coming too.
[19:11] <Riddell> rgreening: qtjambi up
[19:12] <rgreening> Riddell: qtjambi fix is in progress. A couple of things to correct. ie. bug 250002. Also, there's a problem with the designer-qtjambi CLASSPATH. Working on that now.
[19:14] <rgreening> Riddell: in qtjambi-examples-wrapper, we have java -cp /usr/share/java/qtjambi.jar:/usr/share/java/qtjambi-linux32-gcc.jar:/usr/share/java/qtjambi-examples.jar com.trolltech.launcher.Launcher. the linux32 would be a problem on 64 bit. So that needs to be corrected.
[19:14] <rgreening> how woudl I do that for the wrapper (allow 32 or 64)?
[19:16] <Riddell> it's a shell script, just check which file exists
[19:16] <Riddell> if [ -e /path/tolinux32 ]; ...
[19:16] <Riddell> something like that
[19:16] <rgreening> ah... good idea
[19:17] <rgreening> I was thinking on editing it preinstall via the packaging.
[19:17] <rgreening> but a global check would work just as well.
[19:18] <rgreening> ok, a new rev will be necessary to fix these extra problem I found... oh well...
[19:41] <rgreening> On 64 bit Linux, will uname -m show x86_64 always?
[19:42] <Riddell> no
[19:43] <rgreening> ok, wondering the "right" way to determine if the system is 64 or 32
[19:45] <rgreening> think I found a good ex in jcontrol
[20:30] <rgreening> Riddell: sent off final qtjambi fix. ver ubuntu3 should be built. ubuntu2 can die.
[20:32] <rgreening> Riddell: http://www.kdedevelopers.org/node/3713 - SuSE k.n.m native for KDE4... close
[20:36] <yuriy> has kdebluetooth been tested with the new bluetooth stack?
[20:53] <ScottK> yuriy: Yes.  Doesn't work.
[20:55] <yuriy> same here
[20:55] <yuriy> i just installed bluetooth-gnome, and I have to say this works nicer than kdebluetooth even when the latter does work
[20:56] <apachelogger> hm
[20:56] <apachelogger> revert bluetooth stack change?
[20:56] <apachelogger> JontheEchidna: what to do with bug 220474
[20:56] <yuriy> apachelogger: hmm?
[20:57] <yuriy> libbluetooth has been upgraded to version 4
[20:57] <apachelogger> when?
[20:57] <JontheEchidna> apachelogger: we don't use kdesu anymore, right?
[20:57] <JontheEchidna> it shouldn't be causing problems in Intrepid
[20:57] <apachelogger> JontheEchidna: well, I think one can still install kde without kdesudo
[20:58] <yuriy> apachelogger: a couple days ago. mario limonciello sent mail to (among others) kubuntu-devel
[20:58] <apachelogger> even if it's not in $PATH
[20:58] <apachelogger> yuriy: well, it breaks compatibility with kbluetooth obviously
[20:58] <ScottK> yuriy: Bug #279983
[20:58] <ScottK> apachelogger: Yesterday.
[20:59] <apachelogger> I suggest testing kbluetooth svn, if that exists.
[20:59] <apachelogger> otherwise I reverting the lib change would probably make a lot of sense
[21:00] <apachelogger> s/I/
[21:02] <ScottK> apachelogger: Tonio_ has done most of the bluetooth stuff.  Hopefully he'll make an appearance and have some magic fix.
[21:02] <ScottK> Part of the rationale for going forward was the the old lib was pretty broken with the current kernel.
[21:03] <ScottK> I think reversion isn't going to happen.
[21:03] <apachelogger> hm
[21:03] <ScottK> Just add this one to your list when next Jono claims that Kubuntu is treated equally and there are only two devs working on Gnome.
[21:03] <apachelogger> why did no one test kbluetooth before the version bump?
[21:03] <ScottK> I didn't have time.
[21:04] <ScottK> The real question is why did they go ahead with no kbluetooth testing.
[21:04] <ScottK> I'd suggest maybe Riddell should take that up with slangasek.
[21:04] <apachelogger> yeah, Riddell should do that ;-)
[21:05] <apachelogger> We should make a list of screw ups and throw it at Jono, so he can do something to prevent them in the future.
[21:06] <apachelogger> jjesse: Please make sure to mark bugs as incomplete when you request information.
[21:06] <JontheEchidna> Man, we have a ton of incomplete bugs in workspace
[21:11] <apachelogger> I am so looking forward to close them :P
[21:12] <ScottK> Personally I think if it's a real problem it's better to leave it open and maybe someone else has the problem and adds the info later.
[21:13] <ScottK> If it's incomplete because it's not clear there is a real problem, then I think closing is fine.
[21:13] <apachelogger> ScottK: in general most of the KDE bugs are actually missing information
[21:14] <apachelogger> JontheEchidna: there aren't many incompletes without response really
[21:15] <apachelogger> 13 results
[21:16] <ScottK> OK. I just think that generally in Ubuntu bug closing is too agressive.
[21:18] <apachelogger> I agree.
[21:18] <apachelogger> But especially for the big KDE meta packages it is difficult, if we don't keep them clean it's pretty easy to get lost.
[21:32] <apachelogger> bug 176152 is awesome
[21:32] <apachelogger> "1. Create a large file hierarchy (by "large", I mean one that contains hundreds of thousands of directories and a million or more files)."
[21:32] <apachelogger> Won't fix => reproducing fails at step 1
[21:32] <apachelogger> :P
[21:43] <ScottK> apachelogger: Massive file transfer is one of the places where switching from fish to sftp will help.  Last time I tried it with fish, if you wanted to transfer 50,000 files it would try to open 50,000 connections with the remote.  I forkbombed myself once that way.
[21:44]  * apachelogger didn't use fish in years
[21:45]  * apachelogger can't reproduce that bug with 4k folders and 16k files
[21:45] <ScottK> Come on, he said lots ....
[21:46] <ScottK> ;-)
[21:46] <JontheEchidna> you should cp the folder that has that and place it in the lowest subdirectory
[21:48] <apachelogger> hm
[21:49]  * ScottK recalls once accidentally being recursive in a file copy script.
[21:49] <apachelogger> 10,000 loops creating 9 directories (each one a sub dir of the previous one) and storing 4 empty files in each dir
[21:49] <ScottK> That was the day I learned about command line length limitations for rm.
[21:49] <apachelogger> :)
[21:50] <apachelogger> I once looped a gpg exec in a wrapper script
[21:50] <apachelogger> took down the system in no time
[21:50] <apachelogger> almost 2k loops finished
[21:50] <ScottK> The fish fork bomb is my favorite though.  It was to a shared server account and their system worked perfectly.  My account was totally dead and everone else's was fine.
[21:51] <apachelogger> hehe
[22:17] <ryanakca> apachelogger: *points to the reply to bug 278634 *... beyond my abilities now :)
[22:18] <apachelogger> Riddell: ^
[22:18] <apachelogger> I have no idea how this was taken care of in KDE 3
[22:20] <Riddell> apachelogger: dunno, that's my priority item for tomorrow
[22:20] <apachelogger> ok
[22:20] <Riddell> has anyone asked superm what he was thinking when he uploaded an untested bluez?
[22:20] <apachelogger> not yet
[22:24] <ScottK> Riddell: The reply I got was along the lines of "I asked for people to test it."
[22:25] <Riddell> he never asked me
[22:25] <ScottK> Riddell: slangasek made a comment about viewing the old version as sufficiently broken on the current kernel that the risk of it getting worse was low.
[22:25] <ScottK> Riddell: He did send mail to kubuntu-devel
[22:26] <ScottK> Of course I had file transfer before and I don't now, so it's a regression for me.
[22:26] <Riddell> humph
[22:27] <reisi> should i be able to compile (as i did with kubuntu 8.04 w/ kde4) kde4 apps from cmake sources with the latest beta? (kde-devel installed)
[22:27] <reisi> or should i start firing package bugreports; cmake reports that it cannot find KDE4InternalConfig.cmake
[22:28] <Riddell> yes you can compile, we wouldn't get very far if you couldn't
[22:29] <reisi> Riddell: of course :) but i mean should i now install some other meta-package than kde-devel (with previous version kde4-devel was enough)?
[22:30] <Riddell> kde-devel should suffice
[22:35] <reisi> ok FindKDE4Internal is where it should be but for some reason cmake still pukes
[22:51] <reisi> now that kde4 has moved to /usr it seems that cmake-2.6 scripts have a hard time actually finding anything
[23:06] <reisi> FindKDE4.cmake expects kde4-config to be /usr/lib/kde4/bin/kde4-config, as it nowdays is /usr/bin/kde4-config
[23:07] <reisi> should i file a bugreport on cmake package on this one?


[06:34] <dileks> this might be a noob question: report-bug is not the appropriate tool, ubuntu-bug grumps about app PID
[06:41] <dileks> sudo ubuntu-bug $(pidof NetworkManager)
[06:44] <RAOF> dileks: Works here.
[06:44] <dileks> damn, I need a launchpad account, too
[06:44] <dileks> RAOF: I am on 3.4-rc4
[06:44] <dileks> https://bugzilla.redhat.com/show_bug.cgi?id=785772
[06:44] <RAOF> Likewise :)
[06:45] <ubot2> bugzilla.redhat.com bug 785772 in NetworkManager "Logs filled by ICMPv6 RA: ndisc_router_discovery() failed to add default route" [Unspecified,On_qa]
[06:46] <dileks> damn
[06:47] <dileks> how they want that both captcha words
[06:47] <dileks> with space, no space
[06:47] <RAOF> No idea; I generally space, though.
[06:56] <dileks> w/o space
[06:56] <dileks> lauchpad #988183
[06:57] <dileks> my first BR for ubuntu-bts
[07:00] <dileks> OMG, Sedat-dilek (sedat-dilek) <--- can I change that?
[07:02] <RAOF> dileks: I think so, yes.  Change your LP name.
[07:02] <dileks> hmm, just looking for sth like personal settings. more coffee.
[07:02] <RAOF> (You can't easily change your ID, but you can change the name that gets displayed)
[07:03] <RAOF> launchpad.net/~ will bring up your home page; the “change details” link from there will let you do stuff.
[07:04] <dileks> yupp, just did that
[07:06] <dileks> but I would like to change my "OpenID login" to my nickname, as this is well known on other platforms
[07:07] <dileks> Member since: 2010-09-14 <--- didnt know that (registered today) :-)
[07:11] <dileks> Can I change my OpenID id?
[07:11] <dileks> Yes. You can change your Launchpad id and that will change your identity URL. That could mean that sites you've already logged into using your previous OpenID URL may consider you a new user.
[07:11] <dileks> NO, I cant
[07:11] <dileks> https://help.launchpad.net/YourAccount/OpenID?action=show&redirect=OpenID#rename-account
[07:15] <dileks> OK, clicked save again
[07:30]  * smb grumbles about the terminator taking over...
[07:54] <amitk> smb: Arnold has taken over what?
[07:54] <smb> amitk, my ctrl-alt-t
[07:56] <smb> I mean I have installed the terminator package, but until this morning the default terminal window was the gnome one
[07:56] <amitk> :)
[07:57] <amitk> I was worried Arnold had taken over handling of the world economy...
[07:57] <smb> Cannot be worse than California... :-P
[08:37] <dileks> RAOF: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/988183/comments/2
[08:37] <ubot2> Launchpad bug 988183 in network-manager "Logs full with "ICMPv6 RA: ndisc_router_discovery() failed to add default route"" [Undecided,New]
[08:42] <RAOF> dileks: Cool.
[08:42] <dileks> rebuilding first ubuntu package
[08:48] <dileks> RAOF: is there a defined length (of chars) for a patch in ubuntu?
[08:48] <dileks> git_core_dont_fight_with_the_kernel_over_the_default_IPv6_route_77de91e5.patch
[08:48] <dileks> is a bit long
[08:55] <RAOF> dileks: No, you can use whatever length you want.  That does seem a bit long, though :)
[08:55] <dileks> yeah, IIRC in debian/changelog
[08:56] <dileks> now, you can propose a patch-name before building :-)
[08:56] <ohsix> that seems a big long even for shortlog :]
[08:58] <dileks> git_core_fix_default_IPv6_rout_handling_77de91e5.patch ?
[08:59] <ohsix> leave_ipv6_route_alone :]
[08:59] <RAOF> dont_fight_kernel_for_default_ipv6_route.patch would be my plan :)
[09:01] <dileks> should I use lp-no as prefix?
[09:01] <dileks> lp988183_dont_fight_kernel_for_default_ipv6_route.patch ?
[09:04] <RAOF> Maybe; you can add that as metadata in the patch header, though.
[09:04] <RAOF> http://dep.debian.net/deps/dep3/
[09:05] <smb> RAOF, Hey there. :) We're having fun with ati this morning. ... :-P
[09:07] <dileks> RAOF: hehe. I proposed DEP-3 in a little router project for years. they love to steal but dont want to document. if this is even GPLv2-conform?
[09:09] <dileks> I think it enough to point lp-no in debian/changelog
[09:11] <dileks> RAOF: http://nopaste.snit.ch/135174
[09:17] <RAOF> smb: Still?  I chose to interpret your “Oh, it's mirroring on the other thing” as meaning that everything was going fine :)
[09:18] <RAOF> dileks: We don't have maintainers in Ubuntu, so we don't have non-maintainer uploads :)  Other than that, I'd probably give a short description of the bug in addition to the LP number; and you want to use the syntax ‘(LP: 988183)’ to do the equivalent of ‘(Closes: 988183)’.
[09:19] <dileks> OK, so drop NMU line?
[09:19] <RAOF> Yup.
[09:22] <dileks> RAOF: the version string is OK?
[09:23] <smb> RAOF, Well there is the explanation. Right after install when I log-in and the displays are in mirror mode there is no launcher and at least for me terminal windows are near unusable. Unpluging the external monitor before loggin in fixes this also changing into seperate monitor mode
[09:24] <smb> And surprisingly switching back into mirror mode still seems to not get into the same trouble again...
[09:24] <smb> Just sounds like a bit of a big loop to get it working... On the other hand not critical
[09:24] <smb> Unfortunately it means I have to reinstall to get back into the problematic state...
[09:27] <RAOF> :/
[09:28] <RAOF> dileks: It depends on what you want to do with it - if you want to get it into the distro, then no; ~dileks isn't generally in official versions :)
[09:29] <dileks> into the distro would mean to be a ubuntu developer?
[09:30] <RAOF> Yes, but you wouldn't necessarily need upload privileges; you could attach the debdiff to the bug and subscribe ubuntu-sponsors.
[09:30] <dileks> anyway, I build a new NM and see, if it really fixes my issue
[09:30] <RAOF> Good plan :)
[09:30] <dileks> LP registration was hard enough :-)
[09:38] <dileks> RAOF: BTW, I had a lot of WLAN dis- and reconnects
[10:15] <dileks> RAOF: https://launchpadlibrarian.net/103041203/network-manager-<IP_ADDRESS>.debdiff
[10:15] <dileks> it fixes my issue
[10:28] <smb> apw, RAOF, FYI about that dual display issue. bug 988252
[10:28] <ubot2> Launchpad bug 988252 in unity "Launcher missing after desktop install" [Undecided,New] https://launchpad.net/bugs/988252
[10:29] <smb> cking, ^ if you want to add comments of your own
[10:29] <cking> smb, will do
[10:57] <orated> Hello! Could anyone suggest me resources which describes what porting is and how it is done? And how porting an OS different from rebuilding one?
[11:01] <apw> orated, porting is making something work on something where it did not work before
[11:03] <orated> And usually what all steps are involved in it?
[11:04] <cking> http://en.wikipedia.org/wiki/Porting
[11:04] <cking> is this a homework assignment?
[11:04] <orated> ?!
[11:04] <orated> No, it isn't cking
[11:07] <orated> I don't know what makes you ask that. apw: Then how is that different from a rebuild?
[11:07] <cking> orated, so, when porting to a new architecture one needs to port the compiler (which is hard work, which is described will in the Aho, Sethi and Ullman dragon compiler book). Then one has to write or port a boot loader and also write the architecture specific parts of the kernel (which involves understanding the low-level arch specific details and writing a lot of low-level code in assembler).
[11:08] <cking> ..however a lot of arch specific code can be written in C too.
[11:09] <cking> the compiler side is interesting, one normally creates a cross compiler, and one can eventually boot strap up from this a native compiler, but one has to do a lot of work up front to create the back-end for the target architecture
[11:10] <cking> see http://en.wikipedia.org/wiki/Porting#Porting_compilers
[11:10] <orated> Ah, thank. Making an OS cross platform -- x86>arm>sparc - making it run from one architecture to another, right?
[11:11] <orated> processor architecture, instruction set etc ...
[11:11] <cking> yep
[11:12] <cking> however, one can port applications by re-compiling them if one has the OS and the compiler already and if the program is written in a portable way
[11:12] <orated> So for example when ubuntu ARM is being installed on beagleaboard/pandaboard... is that really porting?
[11:12] <orated> that is rebuilding what you said above ^?
[11:12] <cking> installing is just copying it onto the machine
[11:13] <orated> So the image is what is already prepared to run on a arm based system?
[11:13] <orated> installation image
[11:15] <cking> to get to the installation image, work had to be done to get it working on that architecture and then build all the necessary software (packages) to make it into a working system and then create an installation image to allow one to get it copied and running on that target platform
[11:16] <orated> So that is what basically involves porting? To prepare an installation image?
[11:17] <cking> orated, read http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=14&ved=0CDwQFjADOAo&url=http%3A%2F%2Fwww.usenix.org%2Fpublications%2Flibrary%2Fproceedings%2Fusenix98%2Finvited_talks%2Fjohnson.ps&ei=Bt2XT9OSNsjg8APzrr2DBg&usg=AFQjCNFNr1GoorYkVMfYkKIz1ewCqrUxNw&sig2=wtmJ9C0TJpyBXeS_Q6Acwg
[11:20] <orated> Sure, I'll read that ps file and the wiki. Thanks.
[11:23] <orated> cking:  I was wondering about the installation image download option which comes on ubuntu site. It asks to select image for x86 or x86_64 -- instruction set. In the same way I found that certain images are for omap_ armel for ARM..  so these images which are created, does the process of it involves what you said above about porting?
[11:24] <orated> ... building kernel based on the target hardware?
[11:42] <cking> orated, well some body had to originally port the code. we however are packaging it up
[11:44] <cking> orated, for a lot of ARM systems the porting work isn't so bad, the work goes into writing the platform specific board support
[11:47] <cking> orated, note that sometimes when porting applications one has to fix bad code that doesn't handle CPU endianess or alignment issues correctly.
[11:47] <orated> writing platform specific board support like ?
[11:48] <cking> orated, I can't parse your last question
[11:48] <orated> " for a lot of ARM systems the porting work isn't so bad, the work goes into writing the platform specific board support" :)
[11:49] <orated> so in that context I meant to ask for examples for platform specific board support ...
[11:52] <cking> orated, so the board support code for each platform (e.g. omap2, beagleboard, etc) has to be written to port a system - sometimes the code can be re-used, but most likely somebody has to write specific drivers to handle the hardware on a platform
[11:54] <cking> ..but since these are ARM based, the tool chain and a lot of the kernel functionality to support the CPU is already there from previous porting exercises
[11:56] <orated> cking:  Ah, ok. I'd like to confirm the ubuntu ARM and beagleboard part. When one uses the preinstalled armel omap image to try on ARM based boards like beagle/panda, then that actually is installing ubuntu and not porting
[11:56] <orated> right?
[11:57] <orated> https://wiki.ubuntu.com/ARM/OmapNetbook
[11:58] <cking> yep, installing is just the act of copying it to your board
[11:59] <orated> But I noticed that sometimes compiling is also required like for example here for demo images - http://elinux.org/BeagleBoardUbuntu#Demo_Image
[11:59] <orated> linux kernel compile
[12:01] <cking> orated, in my book, porting is when some poor soul has to get software working on a different system and it involves some effort to get it into the shape where it builds correctly and runs  in the way that is expected.
[12:03] <cking> sometimes that can be weeks of effort because of the quality of software, missing or different architecture features or assumptions made about of the target platform.  just downloading the source, building it and it works is just rebuilding it IMHO
[12:03] <orated> well, I don;t understand then why many put up instructions on 'porting Ubuntu on Beagleboard' when its basic installation from the image
[12:04] <orated> ah
[12:04] <orated> rebuilding, porting, image creation, image installing -- all different thing
[12:07] <cking> depending on how people want to defined terms. Quoting Lewis Carroll: “When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean - neither more nor less.”
[12:09] <cking> orated, anyhow, I suspect at this point "google" is your friend in helping you find out more
[12:14] <orated> Could you suggest me any book/resource on basics of porting other than what you suggested above for compilers?
[12:35] <brendand> cking - did you want to have a look at bug 926136
[12:35] <ubot2> Launchpad bug 926136 in linux "CPU1 on Dell PowerEdge M610, R715 and IBM X3500 M3 goes offline after exercising frequency governors" [Medium,Triaged] https://launchpad.net/bugs/926136
[12:35] <brendand> ?
[12:35] <cking> brendand, sure, once I've finished my lunch
[13:59] <dupondje> kamal not here ?
[14:39] <hggdh> apw, pgraner: the 0-day kernel for precise does not show any regressions on the QRT
[14:41] <tgardner> ogasawara, ^^
[14:41] <ogasawara> nice, that's comforting
[14:41] <hggdh> ogasawara: ah, I did not know you were the one interested in it, sorry (apw asked for it, relaying Pete's request)
[14:42] <ogasawara> hggdh: I'm sure they're interested as well
[14:48]  * ogasawara back in 20
[14:49] <diwic> hggdh, fyi, are you - or do you know any of the QA folks that would be interested in https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-hda-automated-qa
[14:49] <diwic> might interest some kernel folks as well
[14:49] <hggdh> diwic: I am certainly interested :-)
[14:50] <diwic> hggdh, ok, let's discuss more at UDS then
[14:50] <diwic> :-)
[14:50] <hggdh> diwic: I subscribed to it, thank you for the heads up
[14:51] <diwic> hggdh, while I have an idea of how to develop the stuff, the actual integration with existing QA and kernel scripts is mostly a black box for me
[14:51] <hggdh> diwic: heh. And we are moving to a more flexible approach there also, so it would be an even blacker box
[15:07] <apw> hggdh, thanks :)
[15:08] <hggdh> apw: yw. for the record, I had to run it manually, there is no support for testing off a PPA
[15:20] <apw> hggdh, thanks, this was definatly a non-standard kernel as we wanted it out very rapidly; ie. not following standard process at all
[15:20]  * ogasawara check if it's finished building on i386
[15:20] <hggdh> apw: no problem from me, I just did not want people to think results would be available on jenkins
[15:21] <apw> hggdh, understood
[15:56] <tgardner> apw, so, what are you thinking about this fsnotify/fanotify patch set ? have you had any indication from upstream whether this is gonna fly ?
[15:57] <apw> tgardner, i had no feedback what so ever, i was thinking of reviving it once the release is done
[15:57] <apw> and starting the effort to repeat myself enough it gets accepted
[15:57] <tgardner> apw, you mean no feedback from upstream ?
[15:57] <apw> tgardner, no they never responded as far as i recall
[15:58] <apw> the next logical step is to clean the patches up a bit so they are only vile and push them as an RFC
[15:58] <tgardner> apw, do you know under what circumstance this ticket lock is most likely to occur ?
[16:00] <apw> the ticket lock bug, i think it was henrix or sforshee who could reproduce it, i think it was mostly triggered by stuff which occured automatically as soon as you shove in USB sticks etc
[16:00] <sforshee> apw, wasn't me, must have been henrix
[16:00] <tgardner> apw, so its likely to nail a bunch of folks regularly.
[16:00] <henrix> apw: yep, it was me
[16:00] <apw> yeah i think henrix you could repro it ?  and did test?
[16:01]  * henrix reads backlog...
[16:01] <hggdh> apw, ogasawara: hold on the kernel for a while -- one of the machines seems to be having problems rebooting, and I want to find out why
[16:01] <henrix> apw: yeah, so i was able to reproduce it using 2 scripts (link in LP)
[16:02] <hggdh> (this was after the tests, and I was just being cautious, trying to reboot  sometimes)
[16:02] <tgardner> apw, henrix: just trying to evaluate the ensuing carnage v.s. the maintenance hassle of the patch set
[16:02] <henrix> apw: i reproduced it using a virtual machine, with a single CPU, mounting and unmount a filesystem with a notification setup to the mounting dir
[16:03] <henrix> so, there were 2 reporters claiming that the issue is still present
[16:03] <henrix> but at least one of them is actually hitting a different issue
[16:03] <henrix> obviously, the "different issue" may be introduced by the patch... but IMO it is not...
[16:04] <ogasawara> hggdh: ack, keep us posted.
[16:04] <henrix> apw: tgardner: let me know if you would like some more testing on this
[16:05] <henrix> the issue is triggered very quickly (seconds); with the patched kernel, i wasn't able to reproduce it
[16:05] <tgardner> henrix, I'm mostly interested in knowing what scenarios cause the lockup. Is this something that will be common? I assume so if its triggered by inserting  a USB stick.
[16:05] <hggdh> apw, ogasawara: http://paste.ubuntu.com/945894/
[16:06] <ogasawara> hggdh: do you see the same issue with the 3.2.0-23.36 kernel we're releasing with?
[16:06] <henrix> tgardner: i guess it can happen with different devices, as long as there is a notifier set on the mount point
[16:07] <hggdh> ogasawara: I did not. But I also did not see this on the first 3 boots on this kernel
[16:07] <henrix> tgardner: in my test scenario, i was actually mounting/unmounting an HD partition under kvm
[16:07] <henrix> tgardner: s/kvm/virtualbox/
[16:12] <ogasawara> hggdh: can you see if you are able to find a reproducer with the day-0?  I'm not convinced this is a regression with the day-0 and warrant it being upheld.
[16:18] <hggdh> ogasawara: I also do not see it as a regression
[16:20] <ogasawara> bjf: https://launchpad.net/ubuntu/+source/linux/3.2.0-24.37
[16:20] <ogasawara> bjf: i386 is still building though
[16:31] <tgardner> smb, are you deploying your dom0 servers using MAAS ?
[16:57] <hggdh> ogasawara: only one machine seems to suffer from the slowpath on boot (not always, but frequently). I tend to see it as non-critical issue right now
[16:58] <ogasawara> hggdh: ack
[16:58] <ogasawara> hggdh: are you seeing it with previous kernels as well?
[16:59] <ogasawara> hggdh: lets get it filed as a bug for now so we can track it going forward
[16:59] <hggdh> ogasawara: I did not, on the last sru runs. I wil keep my eyes on this machine
[16:59] <hggdh> ogasawara: will do
[17:00] <ogasawara> hggdh: when you say the last SRU runs, I assume you mean Oneiric SRU's?
[17:00] <hggdh> ogasawara: and previous, and last precise run (with 3.2.0-23
[17:02] <ogasawara> hggdh: if you could try to hammer on it with the 3.2.0-23.36 kernel to see if you can reproduce there as well it would be good.  As I'm not seeing anything obvious from the day-0 changes
[17:02] <hggdh> ogasawara: will try
[17:17] <hggdh> ogasawara: bug 988430
[17:17] <ubot2> Launchpad bug 988430 in linux "slowpath very early in the boot process" [Undecided,New] https://launchpad.net/bugs/988430
[17:58] <arges> apw, hey are you around?
[17:58] <apw> arges, of a sorts
[18:56] <ogasawara> tgardner: https://launchpadlibrarian.net/103072856/buildlog_ubuntu-precise-i386.linux-backports-modules-3.2.0_3.2.0-24.7_FAILEDTOBUILD.txt.gz
[18:56] <tgardner> ogasawara, ok, I'll have a look
[18:57] <ogasawara> tgardner: I'm not sure what's happening there exactly, I did a local test build on both amd64 and i386 before uploading and they passed
[18:57] <tgardner> ogasawara, did the PPA overflow? sometimes it runs out of disk space, or just craps out.
[18:58] <tgardner> ogasawara, hmm, looks like the ixgbe makefile is kind of cranky.
[18:59] <tgardner> ogasawara, could be a host kernel version mismatch.
[19:06] <tgardner> bjf, I just you hate mail about your Hardy CVE patch
[19:06] <tgardner> sent you*
[19:07] <tgardner> ogasawara, did you ever build Precise LBM on gomeisa ?
[19:07] <ogasawara> tgardner: nope
[19:07] <tgardner> I'll bet it fails there
[19:08] <smb> tgardner, no
[19:09] <tgardner> smb, please elaborate. I can't remember what I asked.
[19:09] <tgardner> oh, xen MAAS deploym,ent
[19:09] <smb> tgardner, :) I am not using MAAS to deploy xen servers. To a degree I used cobbler to deplay clients
[19:10] <smb> *deploy
[19:10] <tgardner> smb, so how are the server folks doing it? wouldn't they use MAAS to deploy the hypervisors, then cobbler to provision the clients ?
[19:11] <smb> tgardner, Actually this would be both the same. In theory. However last time I looked MAAS would not install into something usable
[19:11] <ogasawara> tgardner: could you install the linux-headers-3.2.0-24-generic linux-headers-3.2.0-24-generic-pae in the precise-i386 chroot
[19:12] <tgardner> ogasawara, yep, working on it
[19:12] <tgardner> ogasawara, note that the failing build host is hardy based
[19:13] <smb> tgardner, Just as I only have a limited number of machines (at most two) to act as servers and those usually also are set up in a rather development way (having multiple releases in a special multiboot) it was not worth the effort to me.
[19:13] <tgardner> smb, ok. I have some boxes that are fungible. I'll see if I can get that working.
[19:13] <bjf> tgardner: sent hate mail of my own
[19:13] <smb> But you could have the server installed by maas  and then use koan (orh whatever it is then) to create/register guests
[19:14] <tgardner> smb, ok, I'll likely have some questions for you about it tomorrow
[19:15] <smb> tgardner, sure and if that is not enough I am sure we can grab beers and a laptop in soonish UDS time
[19:15] <tgardner> ogasawara, <IP_ADDRESS> headers installed on precise-i386. just hack the LBM changelog to build against -23
[19:17] <bjf> tgardner: my reply doesn't say so but i acknowledge the need to apply the patch to openvz and xen
[19:17] <tgardner> bjf, ack
[19:21] <tgardner> ogasawara, build fails as expected on gomeisa
[19:21] <ogasawara> tgardner: yep, just saw the same
[19:21] <tgardner> ogasawara, you wanna fix it? no use both of us working on it
[19:21] <ogasawara> tgardner: sure
[19:25]  * apw goes mad watching images install
[19:25] <tgardner> ogasawara, its almost certainly this line in the ixgbe makefile: BUILD_KERNEL=$(shell uname -r)
[19:26]  * tgardner wonders what the hell apw is still doing at work
[19:26] <apw> thats release for you
[19:27] <tgardner> apw, you in millbank ?
[19:36] <tgardner> cnd, sforshee says you could use a MB Air to debug touchpad issues. I've got a newer one that isn't in heavy use right now.
[19:38] <cnd> tgardner, I won't turn down someone giving me one
[19:38] <tgardner> cnd, email or PM your address.
[19:38] <cnd> but we might be able to fix things at UDS too
[20:27] <tgardner> ogasawara, any idea why no_dumpfile=true for Percise x86'en ? it was off for every prior release. vmcore is only built if no_dumpfile is empty. see bug #988512
[20:27] <ubot2> Launchpad bug 988512 in linux "Missing /boot/vmcoreinfo-{version} file is breaking kdump" [Undecided,New] https://launchpad.net/bugs/988512
[20:28] <ogasawara> tgardner: hrm, can't remember anything off the top of my head
[20:28] <tgardner> ogasawara, ok, I'm gonna SRU a patch for it. vmcore should be getting built
[20:28] <ogasawara> tgardner: ack
[20:28] <ogasawara> tgardner: I also uploaded the lbm fix
[20:28] <tgardner> ogasawara, ack
[20:35] <ogasawara> commit a450f280e14071376484af512d67446c6c75d964
[20:35] <ogasawara> Author: Tim Gardner<EMAIL_ADDRESS>[20:35] <ogasawara> Date:   Tue Sep 6 10:25:34 2011 -0600
[20:35] <ogasawara>     UBUNTU: [Config] Disable makedumpfile for i386/amd64
[20:35] <ogasawara>
[20:35] <ogasawara>     Disable this until upstream produces a version that understands a 3.1
[20:35] <ogasawara>     kernel layout.
[20:35] <tgardner> ogasawara, damn.
[20:37] <tgardner> ogasawara, I remember that now. seems like a long time ago.
[20:38] <tgardner> guess I'll find out in a few minutes if makedumpfile is any smarter
[20:40] <tgardner> ogasawara, bummer, burned in on makedumpfile
[20:40] <tgardner> I'll look at it tomorrow.
[20:40]  * tgardner -> EOD
[20:40] <ogasawara> tgardner: ack
[21:05] <cking> apw_, what's the situation now with testing?
[23:31] <hallyn> has tangerine just been rebooted, or is my network wonky?


[12:35] <BluesKaj> Hi all
[13:06] <Guest877> i'm thinking about kubuntu
[14:11] <mybalzitch> I dream of kubuntu
[15:50] <iomari891> greetings, kubuntu 22.04 my lock screen password no longer works? An yes the password is correct.
[15:51] <iomari891> I can unlock using the terminal: unlock-sessions.
[15:56] <arraybolt3[m]> iomari891: Maybe try restarting SDDM?
[15:57] <arraybolt3[m]> Oh, but it's the lock screen... hmm...
[15:57] <arraybolt3[m]> What version of Kubuntu?
[15:57] <iomari891> 22.04
[15:58] <arraybolt3[m]> OK... that's odd. Does restarting fix it?
[15:58] <arraybolt3[m]> (Sorry that these suggestions seem generic, I'm just kinda stumbling around here since this is a weird problem.)
[15:59] <iomari891> arraybolt3[m]: I'm about to reboot now. I'll get back to you when I reboot....
[15:59] <arraybolt3[m]> Also, what is the exact error message it gives when you try to unlock and it doesn't work? Is it just "unlocking failed", or something else?
[15:59] <arraybolt3[m]> (We might also look at the syslog to see what happened. See you in a bit!)
 Peace be among you all, kindly help me who have successfully run wine on the latest disto 22.04? I am getting errors 🙏🏽
[18:49] <arraybolt3[m]> @LOBOLATELEPHONY: What guide are you following to install Wine?
[19:16] <tomreyn> standard procedure would be: slice wax, pull cork, attach bottle opening to mouth, let go. and, as always with wine, sometimes it goes well, other times... it's just one huge headache.
[19:18] <oerheks> it helps to release some air into the bottle, from time to time ..
[19:18] <oerheks> or is that just me?
[19:23] <cbreak> don't people nowadays use carbon dioxide?
[19:29] <arraybolt3[m]> tomreyn:
[19:30] <arraybolt3[m]> tomreyn: Maybe move this to #ubuntu-offtopic? (LOL yes I am being silly here.)
[19:31] <arraybolt3[m]> I remember that the stable version of Wine wasn't released for Ubuntu 22.04 when I wrote this guide: https://discourse.lubuntu.me/t/running-windows-applications-on-lubuntu/3368 So that's probably the problem. Just install development or staging instead.
[19:31] <tomreyn> nah you're right
[19:32] <arraybolt3[m]> (I just saw the opportunity to tell an op that they had gone off-topic and couldn't resist :P)
[19:37]  * RikMills pulls a cork
[20:42] <kubuntu> hi
 https://wiki.winehq.org/Ubuntu (re @IrcsomeBot: <arraybolt3[m]> @LOBOLATELEPHONY: What guide are you following to install Wine?)
[23:31] <arraybolt3[m]> @LOBOLATELEPHONY: Try to install the winehq-staging or winehq-devel package rather than winehq-stable - I know it seems counterintuitive, but I don't think they remembered to release winehq-stable for 22.04.
 ok thank you my friend🙏🏿
 lobola@LOBOLA-TELEPHONY:~$ sudo apt install --install-recommends winehq-staging
 Reading package lists... Done
 Building dependency tree... Done
 Reading state information... Done
 Some packages could not be installed. This may mean that you have
 requested an impossible situation or if you are using the unstable
[23:42] <arraybolt3> @LOBOLATELEPHONY: Could you use a service like bpa.st to hold that error message and then send the link? IRC flood protection didn't let your message get all the way through.


[00:25] <EdwinGrubbs> wgrant: ping
[00:29] <wgrant> EdwinGrubbs: Hi.
[00:55] <EdwinGrubbs> wgrant: hi, I was wondering if you had any opinion about hiding the links at the top of the +related-software page if they are empty. There would always be a link on the person/team page pointing to +related-software, but the +uploaded-packages, +maintained-packages, +ppa-packages, and +related-projects links would be hidden if they were empty.
[01:21]  * mwhudson tries to pound the puller into breaking locally
[01:36] <spm> mwhudson: :-)
[01:41] <mwhudson> completely unsuccessfully so far :(
[01:42] <wgrant> EdwinGrubbs: That's how I imagined it was intended to be.
[01:42] <spm> mwhudson: "if it was easy, we wouldn't have given it to you" <== story of my life and one you could take to heart as well ;-)
[01:43] <wgrant> What is the normal slave replication lag, and what is the maximum before requests all go to the masteR?
[01:53] <kfogel> dobey: pong
[01:56] <spm> wgrant: bugger and all; don't recall offhand - but not that long. a few mins max.
[01:56] <wgrant> spm: A few minutes is enormous...
[01:56] <spm> tradeoffs. most folk aren't modifying.
[01:57] <wgrant> API requests will now use a slave where possible. This is going to cause a lot of clients to get very angry.
[01:57] <gary_poster> wgrant: I don't think that is the case.  What makes you think that?
[01:57] <wgrant> gary_poster: See devel r9703
[01:58] <gary_poster> I think I know what that is, but double-checking.
[01:58] <wgrant> Oh. session cookie only.
[01:58] <wgrant> I guess that's less unreasonable.
[02:00] <gary_poster> right.  this is for JS browser users.
[02:03] <mwhudson> wgrant: spm is wrong btw, lag is usually 5-10 seconds
[02:03] <gary_poster> mwhudson: hi.  I have a bzr plugin problem with eggs in the branch where I'm trying to apply voodoo to make the build happy on karmic.  I've "fixed" the horrible namespace package problem.
[02:03] <gary_poster> Now I only have two failures, both for the same reason. test_successful_start_then_stop and test_unexpected_error_logs_oops fail because they start up bzr, which tries to load plugins from all possible places including the system's site-packages, even though I'm not using the system 's bzr.
[02:04] <gary_poster> If you have plugins installed then bzr complains, because they cannot be imported.  This causes test failures in assertFinishedCleanly: return code is 0, yes; stdout is empty, yes; but stderr is not empty: in my case, it is the following string:
[02:04] <gary_poster> "No module named dbus.bus\nUnable to load plugin 'dbus' from '/usr/lib/python2.4/site-packages/bzrlib/plugins'\nNo module named dbus.bus\nUnable to load plugin 'avahi' from '/usr/lib/python2.4/site-packages/bzrlib/plugins'\n"
[02:04] <gary_poster> I have stepped through the bzr code and I do not see a way to tell the bzr commandline to please only use the plugin path I'm providing, and don't look anywhere else, especially not in the system site-packages.
[02:04] <gary_poster> Therefore, what I'm planning on doing is changing assertFinishCleanly to check that the return code is 0; check that the stdout is empty; and check that stderr is entirely comprised of 0 or more of those plugin error messages, using a regex.
[02:04] <gary_poster> Can you get behind that?  The only other option I can see is making another LP-specific bzr egg change, which I am loathe to do.
[02:04] <gary_poster> (done)
[02:04] <spm> mwhudson: heh. that's a variation of definition. 5-10 secs to me is bugger and all. :-)
[02:04] <mwhudson> gary_poster: where are these tests?
[02:05] <wgrant> mwhudson: It's sometimes a lot more, though.
[02:05] <mwhudson> spm: you said "a few minutes max" -- it doesn't get as high as a minute very often though does it?
[02:05] <gary_poster> mwhudson: lp.codehosting.tests.test_lpserve.TestLaunchpadServe
[02:05] <mwhudson> wgrant: generally when something breaks, i think
[02:05] <mwhudson> gary_poster: looking
[02:05] <gary_poster> thank you
[02:05] <spm> mwhudson: very rarely - is something critical that we alert on.
[02:07] <mwhudson> gary_poster: ararargh!
[02:07] <gary_poster> mwhudson: well, yes
[02:09] <mwhudson> gary_poster: i guess your solution is ok
[02:09] <mwhudson> gary_poster: so long as there's a big fat XXX pointing at a bzr bug i'll find in a sec
[02:09] <gary_poster> mwhudson: heh, that sort of XXX would make me feel better, yes.
[02:11] <mwhudson> wth it's Fix Released
[02:12] <mwhudson> oh, but very recently
[02:12] <mwhudson> gary_poster: i think your patch is ok then, we should remove the hack when we upgrade bzr
[02:12] <mwhudson> gary_poster: https://bugs.edge.launchpad.net/bzr/+bug/316192 fwiw
[02:12] <mup> Bug #316192: bzrlib.plugin.load_plugins() loads system plugins even for non-system bzrlib <Bazaar:Fix Released by vila> <Launchpad Bazaar Integration:Fix Released by thumper> <https://launchpad.net/bugs/316192>
[02:16] <gary_poster> mwhudson: awesome that is fixed.  OK, thank you very much.
[02:17] <mwhudson> gary_poster: np
[02:57] <mwhudson> spm:  has u1 stopped exploding yet>
[02:57] <mwhudson> ?
[02:57] <wgrant> It's working enough for me to have discovered 5 XSS vulnerabilities in the past hour.
[02:58] <wgrant> (I am not amused)
[03:01] <mwhudson> :(
[03:08] <spm> mwhudson: sorta. in that the immediate stuff is now under control; now I move to the ZMOG 9999 priority stuff. I can do small simple things; else... busy :-/
[03:16] <mwhudson> spm: ok
[03:18] <mwhudson> spm: btw the thing i want to talk to you about is one of those things where priority -> \infty as we get closer to karmic being released :-)
[03:19] <spm> mwhudson: heh. figures.
[04:11]  * mwhudson updates his puller bashing to be less wasteful
[07:30] <spm> noodles775: 1. Heyo! 2. Bug 452730 for your attn :-)
[07:30] <mup> Bug #452730: lp_publish/ppa-generate-keys is broken atm <Soyuz:New> <https://launchpad.net/bugs/452730>
[07:30] <noodles775> looking...
[08:12] <noodles775> spm: do you know what the latency between the main and slave db servers is?
[08:13] <noodles775> (just chasing one possibility for the above bug)
[08:13] <wgrant> noodles775: Oh, I know exactly what that bug is.
[08:13] <wgrant> devel r9687
[08:13] <noodles775> wgrant: it's related to r9687.
[08:14] <noodles775> yep...
[08:14] <wgrant> There are now PPAs in production for users without a PPA named 'ppa'.
[08:14] <noodles775> wgrant: sure, but the new method that's been added doesn't assume the name is ppa - it just grabs the first one.
[08:14] <wgrant> noodles775: But that code is only on edge.
[08:14] <wgrant> noodles775: Not on whatever machine runs ppa-generate-keys
[08:14] <noodles775> wgrant: right.
[08:15] <wgrant> So Person.default_ppa still looks up a PPA named 'ppa', always.
[08:15] <noodles775> yep - I'll chat to bigjools about getting r9687 cp'd.
[08:15] <noodles775> Thanks wgrant
[08:15] <wgrant> That's what I suspected. Thanks.
[08:28] <wgrant> spm: U1 rollout not done yet, I hope?
[08:29] <spm> wgrant: partially.
[08:29] <adeuring> good morning
[08:30] <wgrant> spm: Great. I presumed it would be done after 3ish hours, but hoped it wasn't, given that it still seems broken.
[08:31] <spm> the app servers are done; but i'm having a mild pebkac issue with one of the back end services - unsure how related that is to the problems
[08:31] <wgrant> Uhoh.
[08:32] <spm> believed I didn't have the keys to push the new hotness up. turns out I did - in a different directory. le-sigh.
[08:37] <awilkins> jelmer: Why isn't Launchpad using subvertpy instead of python2.4-subversion  .... I'd guess it's an immense fiddle to have both subversion 1.6.5 and launchpad-dependencies because of the python bindings?
[08:40] <wgrant> awilkins: Launchpad doesn't use bzr-svn. It uses a cscvs, horrible horrid horror which uses some strange svn bindings and predates subvertpy by several years.
[08:42] <awilkins> wgrant: I'm presuming that means that LP-monitored SVN branches are essentially trapped and the only way to get patches back to the original project is to ... send patches?
[08:43] <wgrant> awilkins: Yes. There is an intention to move to bzr-svn soon.
[08:43] <awilkins> wgrant: Is there a roadmap the public can see? How about git integration? When will this pestering get too annoying? ;p
[08:44] <wgrant> awilkins: I am the public. I do not know of such a roadmap.
[08:44] <wgrant> 'git integration'?
[08:45] <awilkins> LP using git in the same capacity it uses bzr, where possible
[08:45] <wgrant> That is not on the roadmap even if it does exist.
[08:57] <wgrant> win 23
[09:04] <gmb> Morning padlaunchers.
[09:14] <mrevell> Morning!
[09:15]  * wgrant wonders whether to consider it safe to dive back into Canonical-produced code...
[09:15] <wgrant> maybe as long as it isn't webapp code.
[09:16] <awilkins> That on IP grounds, or just because it's scary? :-)
[09:18] <wgrant> Scary in bad ways.
[10:04] <jml> wgrant, that's simply not fair.
[10:05] <wgrant> jml: Hm?
[10:09] <wgrant> What have I done now?
[10:09] <jml> wgrant, Canonical-produced code isn't that scary
[10:09] <jml> and it's not a fair category.
[10:10] <wgrant> jml: It is scary in that I don't know how many more fucking obvious huge vulnerabilities I will discvoer.
[10:15] <jml> wgrant, oh ok.
[10:15] <jml> wgrant, yeah, that sucks. :)
[10:16] <wgrant> Although LP has less of them than U1, or they are less obvious. This is good.
[10:45] <jml> allenap, hi
[10:46] <jml> allenap, do you have any idea how to stop PQM from sending success messages to the Launchpad list every time we do an automatic merge from stable?
[10:46] <jml> (you don't have to, but I thought I'd ask someone)
[11:19] <jml> allenap, I've read your test parallelization email & lifeless's reply.
[11:19] <jml> allenap, I don't have much to add to what Rob said, except to say that I'm happy for you to call to talk about stuff if you think that'll help.
[11:39] <gmb> jml: Do you have any idea why I'd see http://pastebin.ubuntu.com/294573/ when running ec2 demo?
[11:39] <gmb> What do I need to do to ec2 to know who I am in LP?
[11:40] <jml> gmb, the unhelpful answer to your first question is that our ec2 tools lack tests.
[11:41] <gmb> Hah.
[11:41] <jml> gmb, give me a minute to finish what I'm doing now and I'll have a look & see what's going on.
[11:41] <gmb> jml: Ta muchley.
[11:49] <mrevell> Can anyone remind me where to find the API uses wiki page?
[11:50] <mrevell> Of course, it's https://help.launchpad.net/API/Uses
[11:50] <noodles775> lol
[11:55] <jml> gmb, ok. I'm all yours.
[11:56] <jml> gmb, can you paste me the full log of what you're doing, from command through to error?
[12:01] <jml> gmb, also, what do you get when you type 'bzr launchpad-login'
[12:01] <gmb> jml: So, full log: https://pastebin.canonical.com/23397/
[12:01] <gmb> jml: `bzr launchpad-login` gives me `gmb`
[12:02] <jml> gmb, thanks.
[12:02] <jml> gmb, I'm going to try reproducing the problem locally.
[12:03] <gmb> ok
[12:05] <jml> "I told him to go away and reproduce his problem, but not in those words exactly"
[12:05] <jml> (why I'm not Woody Allen)
[12:06] <jml> gmb, try applying this patch http://pastebin.ubuntu.com/294591/. You'll need to do it in a branch that's not the branch that you want to demo (I recommend stable)
[12:07] <gmb> jml: Okay, bear with me a sec...
[12:13] <gmb> jml: Works. Thanks!
[12:13] <gmb> jml: r=me on the patch if it needs landing ;)
[12:13] <jml> gmb, https://code.edge.launchpad.net/~jml/launchpad/fix-ec2-demo/+merge/13461
[12:14] <gmb> jml: Approved.
[12:14] <jml> gmb, thanks.
[12:16] <jml> gosh ec2 land is handy.
[12:17] <bigjools> :)
[12:17] <bigjools> is there a mode on it to send straight to PQM?
[12:17] <jml> bigjools, no, I thought of doing that.
[12:17] <bigjools> 'twould be useful for us heathens
[12:17] <jml> bigjools, but then mwh said "what's the point?" and "your branch is too big already"
[12:18] <bigjools> I can think of many points
[12:18] <jml> bigjools, I'll happily review a patch for adding a --no-test option or similar.
[12:18] <jml> alternatively
[12:18] <bigjools> ok when I have some time I'll ask you for a pre-imp on that
[12:18] <jml> I'll trade you that for a vfs backend on soyuz so people can rename their accounts if they have PPAs.
[12:19] <bigjools> heh
[12:19] <bigjools> I suspect that would push the renaming problem elsewhere, but I am not unsympathetic to it
[13:02] <bac> bigjools, jml: i though of adding a --no-test option, but it seemed a little perverse since the point of the script is to send things off to ec2
[13:02] <bac> bigjools: you can do 'ec2 land --print-commit' and combine the results with 'bzr pqm-submit'
[13:02] <bigjools> I think its use lies more in the automation of the perverse options we have to put in the commit string
[13:03] <bac> bigjools: i understand.  i've had the need myself but it still felt odd.
[13:04] <bac> bigjools: so an alias of:  bzr pqm-submit -m "`ec2 land --print-commit`" or some variation may work
[13:05] <bigjools> bac: that's so sick I love it :)
[13:05] <bac> :)
[13:05] <bac> bigjools: and it doesn't have to go through code review!
[13:15] <allenap> jml: I don't know how to prevent PQM from sending success messages, but I'll have a look.
[13:15] <allenap> jml: Thank you for reading through my message. I think Rob's reply is very useful to help me approach the problem, but I'll ask you about implementation as I go along.
[13:17] <jml> allenap, cool. don't worry too much about the PQM thing, I've now just set up a rule so I don't get those emails any more :)
[13:17] <allenap> jml: Jolly good :)
[13:42] <bac> sinzui: https://edge.launchpad.net/gnome
[13:44] <sinzui> bac: are you hinting that I fix the licenses for all those projects?
[13:45] <sinzui> bac: This page looks better
[13:49] <sinzui> bac: Do you know why the projects state they are proprietary when they are have a subscription: https://edge.launchpad.net/launchpad-project
[13:51] <sinzui> bigjools: What is the license for https://edge.launchpad.net/launchpad-buildd
[14:29] <bac> sinzui: nothing so deep.  i was showing you that our tiny little fix allows the gnome page to load without OOPSing
[14:29]  * sinzui nods
[14:30] <bigjools> sinzui: good question
[14:44] <sinzui> https://edge.launchpad.net/launchpad-registry/+milestone/3.1.10
[15:43] <Ursinha> err, better here
[15:43] <Ursinha> salgado: ping :)
[15:44] <Ursinha> salgado: hey, I'm checking the oopses here and I see occurrences of UnicodeDecodeError in +filebug
[15:44] <Ursinha> salgado: OOPS-1384C2001
[15:44] <Ursinha> err
[15:45] <Ursinha> salgado: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1384C2001
[15:45] <Ursinha> salgado: is this related to bug 61171
[15:45] <Ursinha> ?
[15:45] <mup> Bug #61171: +login page OOPSes if query string has accented chars encoded as ASCII <oops> <Apport:Invalid> <Launchpad Foundations:Fix Released by salgado> <https://launchpad.net/bugs/61171>
[15:47] <salgado> Ursinha, no, this is something else
[15:56] <dobey> hey guys
[15:56] <dobey> is it possible to change the comment string on a GPG key that was generated for a user/team for PPAs?
[16:15] <Ursinha> salgado: I've filed another bug, bug 453203
[16:15] <mup> Bug #453203: UnicodeDecodeError in +filebug: unexpected code byte <oops> <Launchpad Bugs:New> <https://launchpad.net/bugs/453203>
[16:15] <Ursinha> maybe a bugs' person could take a look on it
[16:19] <Ursinha> hi allenap
[16:19] <allenap> Ursinha: Hi!
[16:19] <Ursinha> :)
[16:19] <Ursinha> allenap: do you have some time to take a look at bug 453203, please?
[16:19] <mup> Bug #453203: UnicodeDecodeError in +filebug: unexpected code byte <oops> <Launchpad Bugs:New> <https://launchpad.net/bugs/453203>
[16:22] <allenap> Ursinha: Looking now. That's an odd one.
[16:26] <Ursinha> thanks allenap
[17:50] <jcinpv> Running Ubuntu 9.04 in Virtualbox on an Intel Mac; After a recent update, the Window Manager does not launch on start up or restart, but does launch after logging out and back in. Going to System->Preferences->Windows, get error message: 'Cannot start the preferences application for your window manager; Window manager "unknown" has not registered a configuration tool.'  I have deleted .gnome2, .gnome2_private, .gconf, and .gconfd to
[17:50] <jcinpv> no avail and I have reproduced the problem in a new user account. Where to look?
[17:56] <Ursinha> jcinpv: I think you may find more useful advices on #ubuntu
[18:01] <mrevell> Have a good weekend all.
[18:02]  * rockstar lunches
[18:52] <jcinpv> Ursinha: Been there. No help.
[18:52] <jcinpv> They suggested I submit a bug.
[18:53] <jcinpv> Where do I submit a bug?
[19:04] <Ursinha> jcinpv: https://launchpad.net/ubuntu/+filebug
[19:57] <jcinpv> Ursinha: Thanks. Bug submitted.
[19:58] <Ursinha> np jcinpv, sorry not being that helpful
[20:05] <jcinpv> Ursinha: You were very helpful in pointing me to the right place to file a bug. My first time.
[20:07] <Ursinha> jcinpv: in this case, glad that helped :)
[21:37] <rockstar> abentley, chat?
[21:37] <abentley> rockstar: 1 sec
[21:38] <rockstar> abentley, just call when ready.
[21:48] <barry> are there any bugs folks still around?  allenap, gmb, intellectronica, deryck
[21:49] <rockstar> abentley, that lag is terrible.
[21:49] <abentley> rockstar: and unpredictable...
[22:18] <gary_poster> night all


[11:39] <manusheel> ishan: Check this http://pastebin.com/KTh829tB
[14:27] <jelkner> dfarning, are you here?
[14:31] <jelkner> has anyone seen dfarning?
[15:04] <manusheel> jelkner: Hello.
[15:05] <jelkner> manusheel, hi!
[15:05] <manusheel> jelkner: David seems to be offline at this juncture. You can send him an e-mail.
[15:05] <jelkner> Thanks, manusheel, I'm doing just that right now ;-)
[15:48] <lfaraone> jelkner: unless the bug is directly related to something in the USR PPA or disk images, please file bugs against the specific packages in ubuntu
[15:54] <thangam_arun> dfarning, Hii
[15:55] <thangam_arun> dfarning, I am waiting for your reply for VM access to create USR for Tamil language
[16:04] <thangam_arun> manusheel, Hii
[16:17] <dfarning> thangam_arun, I don't understand how internationalization works.  Every time I look into it my head starts to swim:(
[16:17] <dfarning> thangam_arun, I really can't be of much help
[16:18] <dfarning> thangam_arun, do you understand how to create a language specif iso?
[16:18] <thangam_arun> dfarning, We are as a team trying to promote Sugar with Ubuntu
[16:19] <thangam_arun> Ya, i have done customization for ubuntu-10.04 using UCK tool
[16:20] <thangam_arun> dfarning, Here people in Tamil Nadu part of India speaks Tamil as the Mother tonque. So inorder reach them we need regional language support
[16:21] <dfarning> thangam_arun, hmm so you can just take a ubuntu iso and respin it with language support using UCK?
[16:21]  * dfarning installs UCK
[16:22] <thangam_arun> dfarning, i am not sure will that help
[16:22] <thangam_arun> dfarning, i have not tried yet
[16:23] <dfarning> thangam_arun, ok, do you know if sugar has been translated to tamil?
[16:23] <thangam_arun> dfarning, Manusheel  form seeta team refered to approach for this work
[16:24] <thangam_arun> dfarning, I am the Tamil language admin for sugarlabs projects
[16:24] <thangam_arun> dfarning, I have done the translation. Its 100%
[16:25] <dfarning> thangam_arun, awesome.  That is 95% of the work!
[16:26] <thangam_arun> dfarning, yes :-)
[16:27] <dfarning> Ian_Daniher, do you know how to make a language specific spin?
[16:27] <thangam_arun> dfarning, Refer this link also:  http://translate.sugarlabs.org/ta/
[16:30] <dfarning> thangam_arun, what is the iso code for tamil?
[16:31] <thangam_arun> dfarning, You mean Locale ??
[16:32] <thangam_arun> ta_IN is the locale code for Tamil
[16:32] <dfarning> thangam_arun, yes(i think) the two letter code for the lang.
[16:33] <dfarning> thangam_arun, thanks
[16:33] <thangam_arun> dfarning, YEs
[16:38] <dfarning> thangam_arun, ok it looks like the ta .po files are correctly migrating from pootle to git.... see http://git.sugarlabs.org/projects/sugar/repos/mainline/trees/master/po
[16:40] <thangam_arun> dfarning, oh good
[16:42] <dfarning> thangam_arun, what happens if you install sugar on maverick and switch your local to ta?
[16:45] <dfarning> thangam_arun, one thing I dont understan is that the version of sugar on maverick is .88 and I don't know if pootle applied your recent translations to that version or to .90(the most recent version.
[16:46] <thangam_arun> dfarning, I have no Tamil Language option in the "USR-i386-20100907.iso" image
[16:47] <thangam_arun> in .90 version the updates will be there
[16:55] <dfarning> thangam_arun, I am going to try to use UCK to add tamil to the iso as a debugging step.
[16:55] <thangam_arun> dfarning, okay
[17:03] <dfarning> thangam_arun, it looks like the UCK method is working.... But I cant read tamil well enough to read the menus.
[17:05] <dfarning> thangam_arun, would you mind 1) downloading the latestest usr iso 2) using UCK to modify the usr iso to set tamil as the default lang and 3) test the modified iso.
[17:06] <dfarning> thangam_arun, if that works, I will modify the standard USR build process to make a tamil based iso by default.
[17:11] <thangam_arun> dfarning, Sure
[17:12] <thangam_arun> dfarning, I will that by tmw and will update you the status :-)
[17:13] <thangam_arun> dfarning, Also i am willing to take part in USR creation. Would like to contribute for the same
[17:13] <dfarning> thangam_arun, if that doesn't work we will have to create an iso of sugar .90 on maverick.
[17:14] <dfarning> thangam_arun, are you familar with shell scripting?
[17:14] <thangam_arun> dfarning, Yes i am Linux Sys admin
[17:15] <dfarning> thangam_arun, nice!
[17:15] <thangam_arun> dfarning, i  use Linux as my Desktop/Server :-)
[17:18] <dfarning> thangam_arun, nice.  The build script is pretty straight forward.... but it contains a lot of magic and is pretty brittle.  So we can't run it automatically.  would you be interested in running builds?
[17:19] <thangam_arun> Yes, I will be happy in doing this work
[17:20] <dfarning> thangam_arun, NIICE. Can you send me you ssh key so I can give you access to the build machine?
[17:21] <thangam_arun> dfarning, Sure
[17:21] <dfarning> thangam_arun, are you familar with the basic concepts of building a ubuntu live CD?
[17:21] <thangam_arun> dfarning, i will send through mail. is that okay?
[17:22] <thangam_arun> dfarning, Yes
[17:22] <dfarning> thangam_arun, yes<EMAIL_ADDRESS>[17:22] <thangam_arun> dfarning, okay i will send in 15 minutes.
[17:23] <thangam_arun> dfarning, i am taking my dinner right now. :-)
[17:24] <dfarning> thangam_arun, I m going to lunch too.  I'll be back in about an hour.
[17:24] <thangam_arun> dfarning, oh ok
[18:14] <mukul> alsroot: Around?
[18:14] <alsroot> mukul: yup
[18:15] <mukul> alsroot: I intend to make some change in logging.py and give a bolean value to a new variable. Then using the bolean value I want add an alert. Can you tell me which file should I use for add the alert function?
[18:17] <alsroot> mukul: do you mean popping up an alert from logging.py?
[18:17] <mukul> Yes
[18:17] <mukul> alsroot: But I guess that can't be done directly. It doesn't have the GUI functions.
[18:18] <alsroot> mukul: that will be misusing of logging.py, it is only for non-gui stuff, you need to popup alerts from more high level
[18:20] <mukul> alsroot: Yes. I'll just create a new variable in logging.py which then would be used for popping up an alert. The problem is in which gui file should I use the variable and popup the alert.
[18:21] <thangam_arun> dfarning, i am back
[18:22] <thangam_arun> dfarning, Also sent a mail to your gmail with public ssh key
[18:22] <alsroot> mukul: could you explain what use case you mean (with such variable in logging.py)
[18:25] <mukul> alsroot: This is what I intend to do. whenever a function logging.error or logging.warn or logging.warning or logging.exception is called. I want it to display an alert saying "The requested operation could not be performed. Please check the logviewer activity for more details.". All this is with reference to the bug#2063. Am I on the right track?
[18:26] <mukul> alsroot: This is what I made out of the conversation between bernie and eben.
[18:31] <alsroot> mukul: well dunno about the way you've chosen, for me this feature smells bad -- for me, using something like bug report is more useful -- anyway about your Q about an alert, this exactly what don't like in this bug :)
[18:31] <alsroot> s/what/what I/
[18:32] <alsroot> any method I can imagine sounds ugly
[18:34] <mukul> alsroot: Ok. I agree this might not be the ideal way.
[18:35] <alsroot> mukul: I meant the your way, but this feature itself
[18:35] <alsroot> s/your/not your/
[18:35] <mukul> alsroot: However, wish if you could suggest a gui file which I could use to popup an alert.
[18:36] <alsroot> mukul: alrert classes are in sugar-toolkit/src/sugar/graphic/alert.py
[18:37] <alsroot> mukul: for the place alert might be popped up, well maybe from journal
[18:37] <mukul> alsroot: Yes but there alerts are defined. I need a GUI file as was (journalactivity.py) where in I could add an alert.
[18:37] <alsroot> s/might be/only/
[18:38] <alsroot> mukul: sugar/src/jarabe/journal
[18:39] <alsroot> JournalActivity is the main class
[18:50] <mukul> alsroot: One more question, when it is written import logging... which file is being imported. I mean there are multiple copies of logging.py with different paths. How do I ensure it is being imported from the one I am making changes in?
[18:52] <alsroot> mukul: python uses PYTHONPATH envar + standard paths
[18:52] <alsroot> ..including current one
[19:12] <thangam_arun>  dfarning, Did you receive my mail ??
[19:21] <mukul> alsroot: journalactivity.py imports logging. I have introduced the a new variable at the logging.py. But when I use the variable using logging.CHECK_ALERT , the log says " The module object has no attribute CHECK_ALERT". There are 4 logging.py file in sugar-jhbuild. Any ideas how to resolve this?
[19:23] <alsroot> mukul: btw you shouldn't override standard "logging" import, the right way is creating new module and use it instead of standard one
[19:25] <alsroot> mukul: better to avoid name clashing
[19:36] <thangam_arun>  dfarning_, Did you receive my mail ??
[19:43] <dfarning_> thangam_arun,   yes, I just got back from lunch and my bike ride.
[19:43] <thangam_arun>  dfarning_, oh great
[19:43] <thangam_arun>  dfarning_, oh great
[19:45] <dfarning_> thangam_arun, did modifing the USR iso with UCK work?
[19:46] <thangam_arun>  dfarning_, Not yet. I have to dwonload the latest ISO. I will do it my tmw
[19:47] <thangam_arun> s/my/by/
[19:48] <dfarning_> thangam_arun,  Great.  what username should I use for your account on usr.sugarlabs.org?
[19:49] <thangam_arun> thangam.arunx
[19:57] <dfarning_> thangam_arun, can you ssh<EMAIL_ADDRESS>[19:57] <thangam_arun> dfarning, i will do that now
[19:59] <thangam_arun> dfarning, I just logged in
[20:01] <dfarning_> thangam_arun, can you sudo?
[20:02] <thangam_arun> dfarning, Yes, i can
[20:02] <dfarning_> thangam_arun, great you will need to sudo to do a build.
[20:03] <thangam_arun> dfarning, Oh okay
[20:04] <dfarning_> all of the build stuff is in my home dir under the usr dir.  can you copy that dir to your home dir, change the chown to your account and try to run a build?
[20:05] <dfarning_> thangam_arun, 'sudo ./usr-scratch.sh all i386' is the incantation to run a build.
[20:06] <thangam_arun> sure sure
[20:08] <dfarning_> thangam_arun, I think user-scratch is pretty straight forward for a sysadmin with a knowledge of customzation.
[20:08] <thangam_arun> dfarning, Yes,  should be
[20:12] <thangam_arun> dfarning, i have to copy the "usr" dir or "usr-scratch.sh" file alone ??
[20:13] <thangam_arun> dfarning, the build folder is 4.8GB size
[20:18] <dfarning_> thangam_arun, you need usr-scratch and template/
[20:18] <thangam_arun> dfarning, ok fine
[20:20] <dfarning_> thangam_arun, but the script might die. becuase of missing dir that you will have to add by hand.... or better yet have the script create the dirs as necessary
[20:20] <thangam_arun> oh ok
[20:21] <thangam_arun> dfarning,thse dir's build/  logs/  output/ ??
[20:21] <thangam_arun> s/thse/these
[20:23] <dfarning_> thangam_arun, I just deleted the contents of build. so yo can copy the whole usr dir.
[20:24] <thangam_arun> dfarning, oh ok
[20:24] <dfarning_> thangam_arun, to reduce network load I cache everything between builds
[20:25] <thangam_arun> dfarning, ok
[20:25] <dfarning_> thangam_arun, build/ contains the chroot and image for a build of each arch
[20:25] <dfarning_> output/ contains the isos
[20:26] <dfarning_> logs/ contain the build logs
[20:26] <thangam_arun> dfarning, All right
[20:26] <dfarning_> tempplate/ contains some file to prime the process.
[20:27] <dfarning_> thangam_arun, I think there are about 25G free on the harddrive so space is not too much of an issue
[20:29] <thangam_arun> dfarning, ok ok
[20:45] <thangam_arun> dfarning, Sugar-88 is not yet added to ubuntu maverick repo ??
[20:46] <thangam_arun> dfarning, Some of the packages were need to be added in order to have suagr-0.88  or ??
[20:46] <dfarning_> thangam_arun, everything should be coming from maverick universe.
[20:47] <thangam_arun> dfarning, In the script the default version is suagr-0.86
[20:48] <dfarning_> thangam_arun, where? sugar is install in line 134
[20:49] <thangam_arun> yes in 135
[20:50] <dfarning_> thangam_arun, line 135 installs a group of activites
[20:50] <dfarning_> thangam_arun, core is installed in 134.
[20:51] <thangam_arun> bernie, oh ok. then the versio is 0.88 or 0.86 ?
[20:52] <thangam_arun> dfarning, oh ok. then the versio is 0.88 or 0.86 ?
[20:52] <thangam_arun> s/versio/version
[20:52] <dfarning_> thangam_arun, actually as your first change to the script you can delete line 135.  all of the activites are now included as part of usr-meta
[20:54] <dfarning_> thangam_arun,  it is .88.  there are a couple of activities name sugar-*activity-0.86 this is just a quirk that mean that activity only runs on ).86 or later.
[20:54] <thangam_arun> dfarning, ok fine
[20:54] <thangam_arun> dfarning, i will do that
[20:55] <dfarning_> thangam_arun, there was an api change between .84 and .86 which broke a bunch of activities
[20:56] <thangam_arun> dfarning, Okay
[20:58] <dfarning_> thangam_arun,  sugar-ubuntu-remix is the equivlent of installing ubuntu-desktop or ubuntu-netbook
[20:59] <thangam_arun> dfarning, Fine, What else got added if you use "sugar-ubuntu-remix" other then "ubuntu-desktop or ubuntu-netbook" ??
[21:00] <dfarning_> thangam_arun, it contain the entire distro stack.  the casper, prober,ubiquity... stuff is for the live cd and installer
[21:00] <thangam_arun> dfarning, Oh okay
[21:01] <dfarning_> thangam_arun, sugar-ubuntu-remix is auto generated from a seed file
[21:01] <dfarning_> thangam_arun, see http://usr.sugarlabs.org/seeds/ubuntu-sugar-remix.maverick/ubuntu-sugar-remix
[21:02] <thangam_arun> dfarning, yes
[21:03] <dfarning_> thangam_arun, most of it is a very standard ubuntu install there are a couple of sugar specif stuff in the last 20 lines (or so)
[21:03] <thangam_arun> dfarning, ok
[21:03] <dfarning_> thangam_arun, we have removed a couple of things to save space.
[21:05] <dfarning_> thangam_arun, the usr seed file is a very slightly modified from the seed file used by ubuntu-netbook
[21:05] <thangam_arun> dfarning, Okay
[21:06] <dfarning_> thangam_arun, this means that usr will run on every machine on which ubuntu runs:)
[21:06] <thangam_arun> dfarning, got  it
[21:11] <dfarning_> thangam_arun, the use of the -meta, -setting, and other seed files is a bit convoluted.  The goal was for the build system to exactly match the upstream ubuntu build process.
[21:12] <dfarning_> thangam_arun, this will allow us to add USR to the upstream ubuntu build farm with little modification.
[21:12] <thangam_arun> dfarning, to avoid the build breakups ?
[21:12] <thangam_arun> dfarning, thats good
[21:14] <dfarning_> thangam_arun, my goal is for USR to be a 'community supported distro' for 11.04 and a 'canonical supported distro' by 11.10
[21:14] <dfarning_> thangam_arun, 11.10 will be a LTS release:)
[21:14] <thangam_arun> dfarning, Okay
[21:21] <thangam_arun> dfarning, Here in India its 2 am now :-)
[21:22] <dfarning_> thangam_arun, time for bed:)  ping me tomorrow with any more questions.
[21:22] <thangam_arun> dfarning, Sure
[21:22] <thangam_arun> dfarning, Thanks a lot for your kind support
[21:22] <thangam_arun> dfarning, Gud night
[21:24] <dfarning_> thangam_arun, good night. I hope we can be of use to you.
[21:24] <thangam_arun> dfarning, Yes Really :-)
[21:24] <thangam_arun> dfarning,See you tmw