[03:53] <emgent> hello people
[04:02] <somerville32> hi
[04:07] <emgent> somerville32, heya
[04:09] <somerville32> :)
[04:10] <emgent> someone can open task for Gutsy, Feisty, edgy, Dapper in Bug #195949 ?
[04:10] <ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,Fix released] https://launchpad.net/bugs/195949
[04:10] <emgent> i can only nominate, only >=MOTU can open task :P
[04:43] <ArneGoetje> I need a core-dev to sponsor my fontconfig update. It's available on rookery in ~arne/fontconfig/ . Thanks a lot!
[05:05] <somerville32> ArneGoetje: file a bug and subscribe ubuntu-main-sponsors
[05:25] <superm1> slangasek, how often is the cdimage cron job going to run on the mythbuntu disk?
[05:25] <superm1> i haven't seen it show up as of yet
[05:27] <ArneGoetje> somerville32: done, thanks.
[05:34] <TheMuso> superm1: 6:19 AM London time it seems.
[05:42] <CarlFK> Bug #196359
[05:42] <ubotu> Launchpad bug 196359 in onboard "Depends: python-virtkey (>= 0.50) but 0.42 is to be installed" [Undecided,New] https://launchpad.net/bugs/196359
[05:43] <CarlFK> that is causing hardy alt install to fail.
[05:43] <ScottK2> IIRC getting virtkey updated just got approved.
[05:44] <CarlFK> k - I'll watch for it and close the bug
[05:45] <CarlFK> so should that have been filed against package python-virtkey?
[05:54] <ScottK2> No.
[05:54] <ScottK2> Updating virtkey is the fix for that problem.
[05:57] <TheMuso> ScottK2: virtkey has been uploaded so all should be well very shortly.
[05:58] <ScottK2> Great.
[06:00] <TheMuso> And has built everywhere, so should be hitting the mirrors.
[06:33] <dholbach> good morning
[06:36] <geser> Hi dholbach
[06:36] <dholbach> hi geser
[06:36] <dholbach> up early today? :)
[06:36] <geser> yes, I have to. I've an exam in one hour.
[06:37] <dholbach> how does it look? well-prepared? :-)
[06:37]  * dholbach crosses the fingers
[06:39] <geser> thanks, I should be well-prepared.
[06:39]  * geser leaves now for the exam, bbl
[06:40] <dholbach> ROCK ON :)
[07:11] <slangasek> superm1: right, it should run daily, no promises that it succeeds though... :) let me have a look at the logs
[07:13] <slangasek> ! Could not open lamp-server from checkout of (any of):
[07:13] <slangasek> !   http://bazaar.launchpad.net/~mythbuntu/ubuntu-seeds/mythbuntu.hardy
[07:13] <slangasek> !   http://bazaar.launchpad.net/~mythbuntu/ubuntu-seeds/platform.hardy
[07:13] <slangasek> !   http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mythbuntu.hardy
[07:13] <slangasek> !   http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.hardy
[07:13] <slangasek> superm1: ^^
[07:14] <pitti> Good morning
[07:14]  * slangasek waves
[07:14] <dholbach> hi pitti, hi slangasek
[07:23] <slangasek> superm1: so, the mythbuntu branch references seeds in its STRUCTURE file that don't apply
[07:23]  * pitti NEWs l-r-m and virtualbox modules
[07:23] <superm1> slangasek, okay i'll remove that reference
[07:25] <superm1> slangasek, for future usage is there somewhere I can browse these logs so i dont have to bug you if there are troubles with the seeds?
[10:17] <pitti> Keybuk: hm, do we deliberately don't have antialiased fonts any more?
[10:17] <Keybuk> pitti: not delierately, no
[10:17] <seb128> hey pitti
[10:17]  * pitti hugs seb128, bonjour
[10:17] <seb128> pitti: dunno if you read about it yesterday but the no duplicate battery patch is creating issues
[10:17]  * seb128 hugs pitti
[10:18] <Keybuk> pitti: mine are still anti-aliased
[10:18] <seb128> pitti: like backlight control not displaying the popup dialog correctly and lagging, the battery icon being displayed when plugged on ac, etc
[10:18] <Keybuk> (having just started a new app to check)
[10:18] <Keybuk> could you have a gnome-settings-daemon failure maybe?
[10:18] <pitti> Keybuk: mine were as well, until I cleaned up my configuration this morning
[10:18]  * pitti tries with a fresh profile
[10:20] <pitti> Keybuk: can you try with a fresh profile? doesn't work for me with one
[10:20] <Keybuk> sure
[10:20] <Keybuk> but not right now
[10:21] <pitti> seb128: ugh, all just because we ignore batteries in /proc now?
[10:21] <seb128> pitti: yes
[10:21] <pitti> seb128: I heard about some issues with displaying wrong charge, etc.
[10:21] <seb128> pitti: does you d430 work correctly?
[10:21] <pitti> so maybe the ones in /proc are right, and in /sys are wrong
[10:22] <pitti> seb128: let me check; there are no obvious bugs, bug I don't change brightness often, etc.
[10:22]  * pitti resumes his laptop
[10:22] <seb128> pitti: well, you would have noticed if the battery icon was displayed while plugged ;-)
[10:22] <pitti> seb128: I think I configured it that way
[10:23] <pitti> I want the icon whenever there is a battery
[10:23] <seb128> ok
[10:23] <seb128> try changing the backlight there
[10:23] <seb128> what it does on my laptop is to display the popup some seconds later and scrambled
[10:24] <pitti> ok, booted, running on battery
[10:24] <pitti> hm, now after resuming I don't have a g-p-m icon at all
[10:24] <pitti> but it's running
[10:24] <pitti> brightness changing works, but no popup window
[10:24] <pitti> darn, this morning I still had an icon which worked
[10:24] <pitti> seb128: that must be your bad influence :)
[10:25] <seb128> lol
[10:25] <seb128> I just noticed that yesterday in fact
[10:25] <Keybuk> pitti: created a new user
[10:25] <Keybuk> still has anti-aliasing
[10:26] <pitti> Keybuk: weird; thanks for trying
[10:26] <Keybuk> the hinting is reduced to Medium by default, but it's still aliased
[10:26] <seb128> pitti: I confirmed that dropping the double battery patch fixes the issues
[10:27] <pitti> ah, how I have by battery icon back
[10:27] <ion_> How about we implement a convolution filter to freetype that blurs all rendered text with e.g. a 3×3 kernel? That would be even nicer default.
[10:27] <mjg59> seb128: Are you restarting g-p-m after restarting hal? (or rebooting entirely)
[10:27] <pitti> ion_: 3x3? that would make them entirely unreadable :
[10:27] <seb128> mjg59: I rebooted several time a day and it's always broken
[10:27] <pitti> seb128: confirming the scrambled brightness popup
[10:27] <ion_> pitti: Yeah, isn’t that the direction we’re going? :-)
[10:28] <seb128> mjg59: I also tried to start gpm in verbose mode after the session
[10:28] <seb128> mjg59: gpm is always screwed, the log shows it fails to get the backlight value, etc
[10:28] <pitti> seb128: hm, if it's that broken, maybe we should reverse the patch to *only* consider batteries in /proc?
[10:28] <pitti> mjg59: ^ WDYT?
[10:29] <mjg59> pitti: I can't see any way that it could cause the backlight issues
[10:29] <seb128> gpm is all screwed dunno why
[10:29] <pitti> neither can I, seems like hal/g-p-m misinterpreting /sys or so
[10:29] <pitti> but *shrug*
[10:29] <seb128> the log has dbus timeout errors when getting to get the backlight
[10:30] <mjg59> g-p-m never touches stuff directly - it just cares about what hal provides
[10:30] <mjg59> seb128: Run hal in verbose mode as well?
[10:30] <seb128> but that might be a side effect
[10:30] <seb128> mjg59: how do I do that?
[10:30] <seb128> brb, switching to laptop
[10:30] <mjg59> hal --verbose=yes --daemon-no
[10:31] <seb128> re
[10:33] <mjg59> seb128: hald --verbose=yes --daemon=no
[10:34] <seb128> bug #194719
[10:34] <ubotu> Launchpad bug 194719 in gnome-power-manager "01_proc_sys_batteries.patch causes a regression making gnome-power-manager not detecting the battery properly" [Undecided,Confirmed] https://launchpad.net/bugs/194719
[10:35] <seb128> [12012]: 11:34:51.697 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
[10:35] <seb128> process 12012: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
[10:35] <seb128> This is normally a bug in some application using the D-Bus library.
[10:35] <mjg59> seb128: That much makes sense, but I can't see how it could affect brightness
[10:35] <seb128> the hal log has that when pressing the keys to change backlight
[10:35] <mjg59> Especially if you're using addon-dell-backlight
[10:36] <mjg59> Which we probably shouldn't be on any hardware supporting the acpi backlight interface, but still
[10:37] <zdzichuBG> is sysfs battery interface pollable? on my thinkpad, sysfs battery level is updated maybe once per hour. this was really visible when g-p-m displayed two batteries (proc and sysfs one) -- proc battery would discharge normally, while sysfs would show 99% just to suddenly jump to 30% after some time
[10:38] <seb128> mjg59: http://paste.ubuntu.com/5085/ that's the gnome-power-manager log
[10:39]  * pitti wonders whether the kernel doesn't provide a good-enough /sys battery information yet, or whether hal needs to be updated to read it differently
[10:40] <seb128> hal does that when gpm is started
[10:40] <seb128> [12450]: 11:39:33.071 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
[10:40] <seb128> process 12450: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
[10:40] <seb128> This is normally a bug in some application using the D-Bus library.
[10:40] <seb128> [12450]: 11:39:41.090 [D] addon-dell-backlight.cpp:198: Received SetBrightness DBus call
[10:40] <seb128> process 12450: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
[10:40] <mjg59> seb128: As I said, I can't see any way this could have anything to do with the battery patch. addon-dell-backlight is a separate process.
[10:40] <seb128> This is normally a bug in some application using the D-Bus library.
[10:40] <zdzichuBG> pitti: first one can be checked by manually looking into /sys
[10:40] <seb128> mjg59: might be a side effect
[10:41] <zdzichuBG> pitti: I will check that in the evening, after work
[10:41] <seb128> could be that the new battery doesn't have enough informations and gpm gets confused when some things are lacking?
[10:42] <seb128> mjg59: gpm seems to be all broken in fact, the battery is display when the laptop is on ac for example
[10:42] <Amaranth> heh, i was just about to say something about that
[10:42] <Ng> since the double battery thing was fixed, gpm has been very broken wrt batteries ;)
[10:43] <Fujitsu> s/very/completely uselessly/
[10:43] <Ng> it tells me I have 62 hours of battery life left and doesn't show I'm on AC
[10:43] <dholbach> Ng: lucky you! 62 hours of battery - not bad! :)
[10:43] <Ng> dholbach: yeah! ;)
[10:43] <seb128> mjg59: I don't get the hald assertions with the build done without the patch, it does that
[10:43] <seb128> [12922]: 11:42:49.686 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
[10:43] <seb128> [12922]: 11:42:49.687 [D] addon-dell-backlight.cpp:82: Reading 5 from the AC backlight register
[10:44] <Ng> I've found bugs 194719, 194201, 194052 and 194180 so far which may be related
[10:44] <ubotu> Launchpad bug 194719 in gnome-power-manager "01_proc_sys_batteries.patch causes a regression making gnome-power-manager not detecting the battery properly" [Undecided,Confirmed] https://launchpad.net/bugs/194719
[10:44] <ubotu> Launchpad bug 194201 in hal "Battery Monitor not working (neither the battery applet) on Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/194201
[10:44] <ubotu> Launchpad bug 194052 in gnome-power-manager "gpm does not create the correct profiling files" [Undecided,Confirmed] https://launchpad.net/bugs/194052
[10:44] <ubotu> Launchpad bug 194180 in gnome-power-manager "After #177570 fix, GPM reports nonsensical values" [Undecided,Incomplete] https://launchpad.net/bugs/194180
[10:44] <Amaranth> mine tells me i'm on AC power but my battery is discharging
[10:44] <Ng> argh, damn you ubotu
[10:44] <Amaranth> eep, bug flood
[10:44] <StevenK> Hah
[10:44] <Ng> sorry :/
[10:45] <mjg59> seb128: You built both on the same system?
[10:45] <seb128> mjg59: no, it's hardy version vs local build without the patch
[10:45] <mjg59> seb128: Ok. I'd recommend building locally.
[10:45] <seb128> I can try a local rebuild of the hardy version
[10:45] <seb128> ok, trying
[10:45] <pitti> Keybuk: my font preferences defaulted to 'best form', not subpixel smoothing
[10:46] <Ng> while I'm here, can I get apport to catch network-admin segfaults? it doesn't seem to be atm (in hardy)
[10:47] <pitti> hm, it uses policykit and thus declares itself as not dumpable
[10:47] <pitti> that's normally a safety precaution which prevents your password from getting into core dumps and other processes ptrace()ing it to steal it
[10:47]  * Fujitsu 's battery is always discharging and either full or 5%.
[10:48] <Ng> pitti: I did wonder if the new "Unlock" button and its refusal to run with gksu was related. I'll file a text backtrace then. thanks :)
[10:48] <pitti> Ng: I don't see how we can easily have both ATM
[10:48] <pitti> current kernel does not allow us to disable ptrace() and still keep core dumping
[10:49] <Ng> pitti: I'd prefer to have it err on the side of security :)
[10:49] <pitti> and it would circumvent the ptrace protection, too
[10:49] <seb128> mjg59: local build of the hardy version has the same issue,
[10:49] <seb128> [6800]: 11:48:58.156 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
[10:49] <seb128> process 6800: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
[10:49] <seb128> This is normally a bug in some application using the D-Bus library.
[11:21] <seb128> pitti: do you plan to update dbus to 1.1.4?
[11:22] <pitti> seb128: not really, unless we need it?
[11:22] <seb128> pitti: well, those are bug fix versions I think
[11:22] <seb128> pitti: the gvfs guys were asking about it
[11:22] <pitti> seb128: I looked at it some days ago, and there were new features, so I didn't update
[11:22] <slomo> pitti: you probably want to get 1.1.20 or backport the security patch from it (see CVE-2008-0595)
[11:22] <ubotu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0595)
[11:22] <seb128> some gvfs guys rather to be exact ;-)
[11:23] <pitti> right, if we update at all, then to the latest version, but as I said, we need to test it properly for the new features
[11:23] <pitti> seb128: what do they need from it?
[11:23]  * pitti -> lunch, bbl
[11:23] <seb128> pitti: not sure, will ask, but the new 1.1.20 has "This is the next generation supported STABLE release of D-Bus." in its description
[11:24] <seb128> pitti: enjoy
[11:29] <cjwatson> bug 173950 - what an excellent bug, I'd never thought of that problem
[11:29] <ubotu> Launchpad bug 173950 in ubiquity "Keyboard layout choice in installer confusing" [Undecided,Confirmed] https://launchpad.net/bugs/173950
[11:58] <Mez> Can anyone tell me how to find out which application a window belongs to?
[11:58] <Mez> Windows-esque adware windows have just appeare on my desktop
[12:00] <Mez> no window class
[12:01] <ion_> mez: This isn’t really a support channel, but run xprop and click the window.
[12:01] <Mez> ion_, I know it's not, however, If it's adware, then I'm gonna help get rid of it
[12:06] <pitti> re
[12:07] <pitti> seb128: hmkay, I'll have a look at the changelog again
[12:08] <\sh> doko: tomcat5.5 is not installable without a jdk...it suggests java-virtual-machine, but I have at least one installed...what do you think is the best way to fix this issue?
[12:09] <doko> \sh: hmm, why does a suggests hinders you installing the package?
[12:10] <\sh> doko: it should default to a free one, imho :)
[12:10] <pitti> seb128: so at least 1.1.4 -> 1.1.20 is bugfix only
[12:11] <pitti> so is 1.1.3 -> 1.1.4
[12:11] <\sh> doko: e.g. icedtea-java7-jdk (if this is resonable and works with tomcat)
[12:14] <doko> \sh: just remove the suggests
[12:21] <pitti> lool: dbus 1.1.20-1 seems released in alioth svn, but not uploaded yet; do you know when this is planned to happen?
[12:22] <Lure> pitti: dbus 1.1.20 is unstable release of 1.2 version, why do you want it?
[12:22] <Lure> pitti: will it get in hardy?
[12:22] <pitti> Lure: seb128 and slomo asked for it above
[12:23] <pitti> Lure: 1.1.2 -> 1.1.3 was the really heavy release
[12:23] <pitti> Lure: 1.1.3-> 1.1.4 and 1.1.4 -> 1.1.20 are just small bug fixes
[12:23] <pitti> 1.1.20 primarily has the security bug fix)
[12:24] <\sh> doko: the problem is, that "java-virtual-machine" is a wrong suggests...it needs a jdk and all packages providing java-virtual-machine are Runtime packages (JREs)
[12:24] <lool> pitti: I tried getting some testers for the update-rc.d changes, but didn't so far; I don't know about the new upstream
[12:24] <Lure> pitti: ok, seen now original msg about security fix
[12:24] <pitti> lool: this was changed to forcefully remove previous symlinks on upgrade, right?
[12:24] <lool> pitti: If you like, you're welcome to try it out -- I personally didn't try the new upstream part
[12:24] <lool> pitti: Correct, to work with insserv and file-rc
[12:25] <pitti> lool: while this is not generally good practice, I think it does help a lot in our case
[12:25] <lool> As these are based on update-rc replacements and move the /etc/rc*.d/ symlinks around
[12:25] <pitti> bug 25931 is open for way too long
[12:25] <ubotu> Launchpad bug 25931 in dbus "Failed to initalize HAL." [High,New] https://launchpad.net/bugs/25931
[12:25] <doko> \sh: so why does tomcat5.5 need a jdk?
[12:25] <pitti> and it's primarily due to shuffled rc priorities
[12:25] <\sh> doko: javac is needed
[12:25] <pitti> so I'd love to merge this into hardy to fix it for all upgrades
[12:25] <doko> \sh: why can't you fix it?
[12:26] <lool> pitti: In general, the update-alternatives "symlink data is your configuration" approach doesn't scale   :-/
[12:26] <pitti> lool: I'm currently reading the upstream changelog - tons of bug fixes and two or three new features
[12:27] <\sh> doko: well, the fix is to remove the suggests and do something helping the user...actually, when I Recommend or Depend on a jdk, it needs to be a free one, and this means, disabling the security manager from tomcat (this works only with the sun jdk)
[12:27] <lool> pitti: I see mbiebl tunned the update-rc.d snippet to hide output, so he probably tested it
[12:27] <\sh> doko: all documented in README.Debian of tomcat5.5 ;)
[12:27] <lool> It's hard to catch mbiebl on IRC these days, I'll drop him an email now
[12:28] <pitti> lool: I'm happy to test it here, too
[12:28] <lool> As you please
[12:28] <doko> \sh: so then why do you ask? soren may be interested in tomcat
[12:28] <pitti> lool: I'll prepare a merge anyway and test it locally; even if we don't get it into hardy for some reason we can still use it for intrepid
[12:28] <\sh> doko: because you are my java pkg hero :)
[12:28] <pitti> lool: since due to your excellent merging into Debian the remaining Ubuntu delta should be small
[12:29] <lool> pitti: Let me know if you need me to work on merging back additional stuff into pkg-utopia, I'm happy to act as a proxy and lower our delta
[12:30] <\sh> doko: I'll discuss it with the server guys
[12:31] <pitti> lool: for proper merging I'd just like to have the Debian source package for 1.1.20-1
[12:32] <lool> pitti: You mean an uploaded one?  I can hand you a svn-buildpackage --svn-exported one if you like
[12:32] <pitti> lool: the latter would suffice, I think
[12:33] <pitti> we still have a delta, so precise md5sum match of diff.gz doesn't matter
[12:33] <pitti> I'd just like to use the same orig.tar.gz
[12:33] <lool> pitti: We use tarballs from http://dbus.freedesktop.org/releases/dbus/ AFAIK
[12:33] <pitti> ah, great
[12:34] <lool> pitti: But the diff might still change since mbiebl didn't confirm he finished
[12:34] <pitti> ah, I seee
[12:34] <lool> He released, but then he might still change it again
[12:34] <pitti> lool: ok, then I'll just use your export for an initial merge
[12:35] <pitti> lool: and for the FF exception request
[12:35] <lool> pitti: http://people.dooz.org/~lool/debian/dbus/1.1.20-1/sid/
[12:35] <pitti> lool: our Ubuntu delta won't change with some further small fixes from mbiebl
[12:35] <lool> Is an export
[12:35] <pitti> lool: merci
[12:40] <lool> pitti: Do I understand correctly that lang-o-matic works with the Packages file and regexps on gtk / qt / kde to sort translations into langpacks?
[12:41] <pitti> lool: more or less, yes
[12:41] <lool> pitti: Intuitively I thought it would look at seeds
[12:41] <pitti> lool: it uses the dependencies as initial heuristics, which works for about 98% of packages
[12:41] <pitti> lool: and it has an override list so that we can manually move misdetected packages into the right category
[12:41] <lool> pitti: Is it possible to have multiple langpacks ship the same translations?
[12:41] <pitti> lool: they would conflict to each other
[12:42] <lool> pitti: One thing where it might fail is with a mobile langpack -- most things are gtk-ish already, and sometimes not easy to distinguish
[12:42] <pitti> lool: if a translation is relevant for both gnome and kde (like libxine) it lands in the neural langpack
[12:42] <pitti> neutral
[12:42] <pitti> lool: i. e. language-pack-fr instead of language-pack-{gnome,kde}-fr
[12:42] <lool> pitti: Ok; that's how I understood it
[12:42] <pitti> lool: if those are only a few, we can override them manually, but IMHO it would be better to have a heuristics first
[12:42] <lool> (what's called the default or standard langpack on the translationprocess wiki)
[12:43] <pitti> like, a dependency to libhildon or something
[12:43] <lool> TranslationLifecycle rather
[12:43] <pitti> right
[12:43] <pitti> I don't have a really good name for that 'default' category
[12:43] <pitti> 'main' is misleading (component) and 'base' too (due to the -base/update pkg split)
[12:43] <lool> I would have called it base, but then this conflicts with the base/update langpacks  :-/
[12:43] <lool> Yep
[12:43] <pitti> snap :)
[12:44] <pitti> 'common' maybe
[12:45] <lool> pitti: Concerning actually building the langpacks, we might be basing on a separate project than "Ubuntu" for UME as we might have some post string/ui freezes translations
[12:46] <lool> And we also have to convert the upstream pot (or create them) and them convert them back
[12:46] <pitti> lool: so, building entirely separate packages, not basing on the 'common' ones above?
[12:46] <lool> Anyway, we would have to push pots into another LP project, and retrieve another tarball
[12:46] <pitti> that would certainly work
[12:46] <pitti> then you can also include some GTK translations and add a Conflicts:
[12:47] <lool> I'd guess we would still want the mobile langpacks built frmo hardy and then continue building new ones and pushing them to our ppa or so
[12:48] <lool> So, first we would have to add a mobile langpacks (with proper conflicts), then I'd like to continue pushing new langpacks to our ppa
[12:48] <lool> Is it possible to build the mobile langpacks against multiple LP translation tarballs?
[12:48] <lool> (Typically the Ubuntu main translations and the "mobile-translations" project translations tarball)
[12:48] <pitti> lool: as long as the later ones only update the previous ones, that's possible, yes
[12:49] <lool> I guess this is all manual, and results in a giant .dsc which I push to our ppa and builds the binary arch: all packages?
[12:49] <pitti> no, there's one source per binary
[12:49] <pitti> since we only update a langpack when its translations actually changed
[12:50] <lool> So I would even be able to push a mobile langpack alone; I might need the Ubuntu + mobile translations tarballs to succeed building the .dscs though
[12:50] <pitti> lool: langpack-o-matic previously had a script 'merge-tarballs' which lets you combine two exported tarballs and then build packs from the merge
[12:50] <lool> Excellent
[12:50] <pitti> lool: it's not there in bzr head, but it's trivial to revive from the bzr history
[12:50] <pitti> I just removed it since we don't need it any more these days, but if you need it, no problem
[12:51] <mjg59> seb128: Right, you get to figure out what broke between the hardy build and now...
[12:51] <lool> pitti: Found it in history, thanks
[12:52] <lool> pitti: What would you be your guesstimate amount of work (either for you or for me) to add a mobile langpack and to actually produce new langpack packages?
[12:53] <pitti> lool: depends; do you want to build completely separate packages, or build on top of the Ubuntu 'common' and 'gnome' ones?
[12:54] <lool> pitti: One high priority goal is to save space
[12:54] <lool> So a completely separate one
[12:54] <pitti> ok, right
[12:54]  * Hobbsee curses evil x bugs
[12:54] <lool> (The seed data would really be good here)
[12:54] <pitti> then we'd need a langpack-o-matic branch for mobile with some updated skeleton source packages
[12:54] <pitti> with updated descriptions and Conflicts, etc.
[12:55] <pitti> we can drop the category matching there, since there will be just one
[12:55] <pitti> lool: so, getting this langpack-o-matic branch right would take maybe one or two hours
[12:55] <pitti> lool: the more interesting question is how to get a matching LP translation export
[12:56] <lool> pitti: We have to remap translations from english <-> localized to msgid <-> localized
[12:56] <pitti> lool: i. e. if LP translations gives us exactly one tarball which contains mobile+ubuntu we need more code in langpack-o-matic
[12:56] <pitti> lool: why?
[12:56] <lool> pitti: Does that happen starting from the LP tarball and before calling lang-o-matic?
[12:56] <pitti> lool: that needs to happen for the LP translations web ui
[12:57] <pitti> but not necessarily for langpacks
[12:57] <pitti> as long as you make sure that on the mobile device at least one locale is always defined
[12:57] <lool> But the code uses msgids
[12:57] <pitti> I know what the code does
[12:58] <lool> How do you find the msgid <-> string mapping on the device if you don't fix the LP exports before running l-o-m?!
[12:58] <pitti> lool: let's have a phone call, shall we?
[12:58] <lool> pitti: Sure :)
[12:58] <lool> pitti: It's going to be on my mobile == expensive though
[12:58] <lool> pitti: Or I can call you, sorry
[12:58] <lool> pitti: I'm really stupid when I'm sick
[12:58] <lool> pitti: Can I call your landline?
[12:59] <pitti> lool: see /msg
[12:59]  * lool is in /query overflow
[12:59] <lool> Ah, another network
[13:14] <slomo> pitti, Lure: 1.1.20 is a stable dbus release, only reason why it isn't 1.2 is that the licensing wasn't fixed yes (apart from that we have an unstable one anyway)
[13:16] <Lure> slomo: ok, I was confused with announcement mail then
[13:16] <slomo> Lure: it's explained at the bottom of that mail
[13:31] <seb128> re
[13:32] <seb128> Lure: the notes have "This is the next generation supported STABLE release of D-Bus.", why do you say it's an unstable version?
[13:32] <seb128> mjg59: well current hardy is broken, I'll try to write a small test case, is there an easy way to send a GetBacklight over dbus using a command line tool?
[13:34] <seb128> pitti: I think having the current stable dbus in hardy would be nice but no strong reason why we can't do with the version we have now so it's your call
[13:48] <mjg59> seb128: Yeah, dbus-send
[13:56] <Riddell> mvo: did you get my e-mail with the question from ossi?
[13:57] <mvo> Riddell: let me check, I'm traveling currently
[13:57] <StevenK> IRC while travelling. Way cool
[13:59] <mvo> Riddell: yes, have it
[13:59] <mvo> StevenK: not literally traveling, more "away from my regular environment" :)
[13:59] <Riddell> mvo: answer when you can, I forgot you were travelling
[14:01] <mvo> Riddell: if I haven't by monday, kick me please
[14:03] <carlos> pitti: shouldn't jockey be in multiverse?
[14:03] <carlos> pitti: btw, hi.
[14:04] <carlos> pitti: as far as I know, is the replacement for restricted-manager and it was moved to restricted, not sure why it's reverted now...
[14:04] <carlos> pitti: btw, when I said multiverse I mean restricted
[14:06] <seb128> carlos: why should it be there?
[14:06] <seb128> carlos: that's a managing drivers thing, not restricted to non free ones now I think
[14:07] <carlos> seb128: isn't the argument for restricted-manager move to restricted valid anymore?
[14:07] <seb128> carlos: why was it moved there?
[14:07] <carlos> seb128: because it depended on drivers that were not free
[14:07] <carlos> Jockey provides a user interface for configuring third-party drivers,
[14:07] <carlos>  such as the Nvidia and ATI fglrx X.org and various Wireless LAN
[14:07] <carlos>  kernel modules.
[14:07] <carlos> seb128: which is also true for jockey
[14:08] <carlos> at least from the description
[14:09] <carlos> seb128: I wonder it because I had to do a modification in Launchpad to allow restricted manager translations in the restricted pocket, but seems like this is not true anymore, in which case I want to revert the launchpad change too, so I just want to be sure that is not just a mistake in that new package
[14:11] <seb128> carlos: better to wait for pitti to respond, he had network issue and we are in a meeting right now though
[14:11] <carlos> ok
[14:11] <carlos> seb128: thanks for your input
[14:11] <nosrednaekim> heno» hello, where are the update from dapper to hardy directions?
[14:18] <heno> nosrednaekim: not sure we have those yet
[14:18] <heno> mvo: ^?
[14:19] <mvo> nosrednaekim: yes, give me a sec
[14:19] <nosrednaekim> thanks
[14:19] <pitti> seb128: look, dbus 1.1.20: https://edge.launchpad.net/~pitti/+archive
[14:20] <seb128> pitti: will try that, thanks
[14:20] <mvo> nosrednaekim: https://help.ubuntu.com/community/HardyUpgrades#head-e7f287c730b93116f89de7ea7e05efbe95fa6dd1
[14:21] <mvo> nosrednaekim: let me know how it works for you, if a error happens, please send me the logs
[14:23] <seb128> pochu: hey, will you do the tracker update and uvf request?
[14:25] <nosredna_ekim> mvo» uhhh sorry little crash there.
[14:25] <pitti> seb128: packages are already being built; dput to start of build took like 10 seconds :) (yay ppa)
[14:25] <pitti> hi carlos
[14:25] <mvo> nosredna_ekim: please /msg me details or put the error message into paste.ubuntu.com
[14:25] <carlos> pitti: hi
[14:25] <pitti> carlos: jockey is in main again, yes
[14:25] <nosredna_ekim> I'm actually testing upgrading kubuntu using the gtk tool. Anything I should be  fore-warned of?
[14:25] <pitti> carlos: because it's designed for free third-party drivers, too, and it doesn't hard-depend on l-r-m
[14:26] <pitti> carlos: however, that doesn't generally mean that we will never put packages in restricted which need i18n
[14:26] <carlos> pitti: ok, could I disable restricted translations handling in Launchpad then?
[14:26] <carlos> pitti: also, you should stop stripping translations out for those packages too
[14:26] <carlos> pitti: well, I discussed with you that some days ago
[14:27] <seb128_> Keybuk: where does bootchart puts the chart?
[14:27] <carlos> and you asked me to not import those translations for other packages because translations would end in language packs that are in main...
[14:27] <Keybuk> seb128: /var/log/bootchart
[14:27] <carlos> pitti: so, what should I do?
[14:27] <seb128_> ah, log
[14:27] <pitti> carlos: I can disable stripping for restricted if we want, but why?
[14:27] <pitti> carlos: what's gneerally wrong with including restricted in the normal translation workflow?
[14:27] <pitti> ah, because of the license
[14:27] <pitti> I see, valid point
[14:28] <seb128_> Keybuk: http://people.ubuntu.com/~seb128/hardy-20080228-1.png
[14:28] <pitti> carlos: true that, so please remove the hack
[14:28] <carlos> pitti: ok, thanks for clarify it.
[14:28] <mvo> nosredna_ekim: no, it should be fine
[14:29] <Keybuk> seb128: how strange
[14:29] <seb128_> iz udev bog!
[14:29] <Keybuk> seb128_: I'd say kernel
[14:29] <Keybuk> if it were udev bug, udev would be a more interesting colour
[14:30] <pitti> lamont, infinity: if I were to upload a new pkgbinarymangler which modifies striptranslations.conf (not strip "restricted"), would that need manual changes in the buildd chroots? (since that conffile is modified there)
[14:30] <nosredna_ekim> mvo» ok, thanks, I'll report back one way or the other.
[14:30] <mvo> thanks nosredna_ekim
[14:30] <Keybuk> seb128: udev.log would help
[14:30] <seb128_> Keybuk: there is no color on this long bar
[14:30] <Keybuk> seb128: 30s is a suspiciously round number
[14:31] <Keybuk> that implies alarm(30) in someting
[14:31] <seb128_> it's just sitting there
[14:31] <lamont> pitti: does apt-get dist-upgrade prompt?  cause that'd be a non-interactive handler, I believel;
[14:31] <Keybuk> yeah exactly
[14:31] <Keybuk> it's sitting there
[14:31] <pitti> lamont: that's the dpkg conffile prompt, not maintainer scripts or apt
[14:31] <lamont> pitti: right
[14:32] <seb128_> Keybuk: do you know what informations could be useful there?
[14:34] <pitti> lamont: want me to file an RT for it?
[14:35] <lamont> pitti: that's an infinity thing not me..
[14:36] <lamont> I suspect he would want one though
[14:36] <lamont> and you might want to hold off on breaking all the buildds (if it does that) until he's around...
[14:38] <pitti> lamont: hm, oops; if you think it'll actually break the builds, then maybe I should do a followup upload which reverts it?
[14:39] <lamont> pitti: dunno what it'll do...
[14:39] <lamont> the build starts by untarring the chroot tarball, doing a non-interactive (I think) dist-upgrade, and then runs sbuild
[14:41] <pitti> anyway, rt sent
[14:43] <seb128> pitti: the dbus binaries are not published yet in the ppa
[14:43] <seb128> pitti: I'll try when they are
[14:44] <pitti> http://ppa.launchpad.net/pitti/ubuntu/pool/main/d/dbus/
[14:44] <pitti> seb128: right, that should happen soon; the debs are in the pool already
[14:47] <pochu> seb128: yeah I'll do it
[14:47] <pochu> seb128: it's already in Debian so it's a merge ;)
[14:47] <pochu> but it needs an exception, yes
[14:49] <pitti> pochu: yes, I merged them (the PPA version is a merge)
[14:50] <tjaalton> pitti: jockey disables composite for fglrx, is that still needed? (AFAIK it has supported it for some time)
[14:50] <seb128> pitti: pochu was speaking about new tracker
[14:50] <pochu> yeah, what were you talking about? dbus? :)
[14:51] <seb128> pochu: yes, new dbus there ;-)
[14:57] <pitti> tjaalton: no idea; if someone verifies that it works, I'm happy to un-disable it
[14:57]  * pitti does not have any ATi card
[14:57] <pitti> seb128: bug 196568 updated FYI; PPA binaries are published
[14:57] <ubotu> Launchpad bug 196568 in dbus "update to new 1.1.20 stable version" [Undecided,New] https://launchpad.net/bugs/196568
[15:01] <asabil> hi all
[15:09] <tjaalton> pitti: ok, I'll find out if it can be dropped
[15:12] <seb128> pitti: new dbus installed on my laptop, rebooted, everything works fine as far as I can tell
[15:12] <pitti> seb128: here, too
[15:12] <seb128> pitti: I've added a comment on the bug saying so
[15:32] <seb128_> mjg59, pitti: so, rebuilding the hal hardy version without 01_proc_sys_batteries.patch
[15:32] <seb128_> $ dbus-send --system --print-reply --dest=org.freedesktop.Hal `hal-find-by-capability --capability laptop_panel`  org.freedesktop.Hal.Device.LaptopPanel.GetBrightness
[15:32] <seb128_> method return sender=:1.114 -> dest=:1.118 reply_serial=2
[15:32] <seb128_>    int32 7
[15:33] <pitti> wow, that's so weird
[15:33] <seb128_> same box, applying the patch, make, run new version
[15:33] <seb128_> $ dbus-send --system --print-reply --dest=org.freedesktop.Hal `hal-find-by-capability --capability laptop_panel`  org.freedesktop.Hal.Device.LaptopPanel.GetBrightness
[15:33] <seb128_> Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[15:33] <seb128_>  
[15:33] <seb128_> so it doesn't look like a gpm bug, now no idea why that timeout after using the patch
[15:34] <seb128_> the laptop_panel capability doesn't change between versions
[15:35] <toresbe> seb128_: hey
[15:35] <toresbe> you're not the appropriate seb, sorry
[15:36] <seb128_> toresbe: hi, no problem ;-)
[15:37] <seb128_> pitti: does the command timeout for you too?
[15:38] <pitti> seb128_: booting my laptop
[15:39] <seb128> pitti: sorry for the trouble, trying to look at the issue but my hal and dbus foo are limited
[15:43] <pitti> seb128: yes, I get the same timeout
[15:43] <pitti> seb128: do you see anything in the hal debug output?
[15:44] <seb128_> pitti:
[15:44] <seb128_> [12735]: 16:41:41.975 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call
[15:44] <seb128_> process 12735: arguments to dbus_message_get_args() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 1667.
[15:44] <seb128_> This is normally a bug in some application using the D-Bus library.
[15:44] <pitti> ah, right, that
[15:44] <seb128_> pitti: but I fail to see how to changes are leading to that
[15:44] <seb128_> I'm getting log with and without the patch and diffing those now
[15:58] <mi__> did we see libtab 1.5 in hardy ?
[15:59] <lool> Is anyone going to Cebit?
[15:59] <seb128_> mi__: dunno what libtab is but you can look on launchpad
[15:59] <mi__> taglib 1.5
[16:00] <seb128_> mi__: same reply, apt-cache show or launchpad
[16:00] <seb128_> mi__: or try #ubuntu for user questions
[16:01] <mi__> lol...amarok2 now use this package ( hardy have old1-1.48)
[16:02] <mi__> never mind
[16:02] <seb128_> mi__: was that a question?
[16:03] <mi__> seb128_: no ..i say never mind
[16:04] <seb128_> mi__: what would be constructive is to look at the version first because you don't need to ask on the devel chan to know that and to argue about the need to update to the new version if that's what you wanted
[16:28] <seb128> Keybuk: ok, no hint about what could be useful as debug information about this slow boot issue?
[16:28] <Keybuk> seb128: udev.log
[16:32] <pitti> seb128: oh, yay! I just noticed that nautilus/gvfs stopped showing my internal partitions on the desktop
[16:33] <seb128> pitti: right, only mounts under media and the user directory are listed now
[16:33] <pitti> \o/
[16:33] <seb128> ;-)
[16:33] <seb128> Keybuk: /var/log/udev you mean?
[16:36] <Keybuk> that's the one
[16:37] <seb128> Keybuk: http://people.ubuntu.com/~seb128/udev
[16:37] <somerville32> Could someone regenerate and upload xubuntu-meta for me?
[16:38] <seb128> Keybuk: doesn't look like really useful to me, that's only events, no debug informations nor timing there
[16:59] <cjwatson> Riddell: would http://paste.ubuntu.com/5104/ be OK by you? from ArneGoetje
[17:03] <seb128> ArneGoetje: maybe you could describe what your changes are doing, the fontconfig upload changelog is not very informative ;-)
[17:03] <Riddell> cjwatson: should be yes
[17:05] <ArneGoetje> seb128: set antialias to true, hinting to true, hintstyle to hintmedium and rgba to none. That;s the setting we use in gnome. These changes will enable these settings system wide across all flavors.
[17:06] <seb128> ArneGoetje: ok, good to know, thanks ;-)
[17:13] <xhaker> talking about hinting. just tried hinting set to none, and the applet freaked out. the 4 checkboxes for font rendering are checked
[17:14] <seb128> xhaker: they are not checked, they are in undefined state which means none is selected
[17:15] <xhaker> hmm.. let me check  with human-clearlooks
[17:17] <xhaker> ok.. here is the problem. with human-clearlooks they look ok.. undefined state is different.. both human-cl and human-murrine need to be fixed i think
[17:18] <seb128> those are known bugs
[17:18] <seb128> patches are welcome ;-)
[17:18] <xhaker> ok, will try my luck
[17:19] <seb128> cool ;-)
[17:36] <pitti> jdstrand, keescook: are you still the primary maintainers for the package tests branch? could you take a look at/merge the test script for 'nut' in bug 182790?
[17:36] <ubotu> Launchpad bug 182790 in nut "main inclusion report" [Low,Confirmed] https://launchpad.net/bugs/182790
[19:36] <lool> pitti: BTW, this is where we are tracking the langpack points https://wiki.ubuntu.com/MobileAndEmbedded/MobileLangpack
[19:36] <lool> pitti: It turns out the 30 MBs or so we might save with mobile langpacks might not be worth a new langpack, however we definitely have to make hildon modules langpack-able, so the l-o-m hooks part and the scripts to convert pot and all are still needed on our side
[19:37] <lool> pitti: Feel free to work on germinate integration though :)
[19:37] <emgent> mdke, ping
[19:37] <mdke> emgent: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[20:13]  * slangasek wonders what should be done with a langpack that depends on a package in multiverse (language-support-writing-eu -> myspell-eu-es)
[20:15] <cjwatson> slangasek: bug report? :-)
[20:15] <cjwatson> langpacks belong in main, so ...
[20:16] <slangasek> so "drop the dependency" is the ultimate answer, ok. :)
[20:17] <cjwatson> well, at least it should be <= Recommends, probably Suggests
[20:17] <cjwatson> not sure what language-selector will do with that though
[20:18] <slangasek> perhaps language-support-writing-eu shouldn't exist at all yet, if the only dependency is in multivesre
[20:19] <infinity> cjwatson: (re: livecd-rootfs/link_in_boot) Do you envision us ever rolling new dapper livecds?
[20:19] <infinity> cjwatson: If so, I can just make sure the fix is in the dapper-live chroots now and close out that task.
[20:20] <mario_limonciell> slangasek, I lost my connection last night before i was able to stick around to hear a response to my question regarding logs.  In  the failed alternate cd builds, is there somewhere i'll be able to look at logs to see what happened without having to bug you?
[20:20] <infinity> cjwatson: (and then watch it mysteriously disappear when I forget to back it up when I reinstall the buildds, post-hardy, but that's my own issue to deal with..)
[20:20] <slangasek> mario_limonciell: would that I knew the answer to that
[20:21] <infinity> mario_limonciell: http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
[20:21] <slangasek> but apparently infinity knows the answer, so hooray :)
[20:21] <infinity> mario_limonciell: Assuming that has enough info for you...
[20:21] <mario_limonciell> infinity, great thanks :)
[20:21] <mario_limonciell> yeah that's exactly what i need
[20:22] <infinity> mario_limonciell: It's less than ideally-laid-out, but it should have full logs for just about everything.  Ish.
[20:24] <slangasek> cjwatson: in your opinion, given the choice between not being able to have a language-support-writing-eu package and having it in multiverse (or restricted), which would be the better option?
[20:24] <infinity> slangasek: Unless we've been relaxing this of late, restricted is only for hardware support (drivers/firmware), so it would be multiverse.
[20:25] <slangasek> ok
[20:26] <cjwatson> infinity: I think it's unlikely
[20:26] <infinity> slangasek: And you'd have to test how launguage-selector would deal with it in multiverse, I guess.
[20:26] <cjwatson> mm, there is the consequential problem that language-support-eu depends on language-support-writing-eu
[20:26] <infinity> cjwatson: That would have to change, obviously...
[20:26] <cjwatson> I'm not honestly sure which I prefer of those two options
[20:27] <cjwatson> I think I'd like to hear from mvo what it would do to language-selector (or what could easily be changed there, if necessary)
[20:32] <doko> $ ldd gcjwebplugin.so | grep 'not found' 2>&1|less
[20:32] <doko>         libxul.so => not found
[20:32] <doko>         libxpcom.so => not found
[20:32] <doko> asac: expected?
[20:40] <mjg59> doko: Aren't they in the firefox directory?
[20:40] <mjg59> doko: /xulrunner
[20:40] <doko> yep, I'll see if that's enough
[20:44]  * slangasek whimpers at the lack of sover in those library names
[20:44] <infinity> slangasek: They're private libraries, in theory...
[20:44] <infinity> slangasek: (Not counting gcjlolplugin's above abuse...)
[20:44] <zdzichuBG> while discharging, energy_now in sysfs decreases steadily, but battery.charge_level.current in HAL stays still
[20:45] <slangasek> infinity: xulrunner isn't so private anymore, though?
[20:45] <infinity> slangasek: Depends on who you ask, I suppose.
[20:46] <infinity> slangasek: It's still in "SOVER 0" land, in my opinion.  (ie: not necessarily private, but the API and ABI might get broken every third Tuesday).
[20:47] <infinity> slangasek: As horrible as it sounds, any shlibdeps on those libs should probably be exact versions. :/
[20:47] <slangasek> mmh
[20:47] <infinity> slangasek: (Which makes security updates rather lollerskatish)
[20:48] <geser> infinity: Hi, do you know when you'll find some time to work on bug 184557?
[20:48] <ubotu> Launchpad bug 184557 in jbossas4 "Circular build-depends, needs initial bootstrapping on the buildds" [Medium,Confirmed] https://launchpad.net/bugs/184557
[20:49] <infinity> geser: Sometime before release. ;)
[20:49] <infinity> geser: I could do it today, perhaps... I'm currently wrapping my brain around somthing that's making me grumpy anyway.
[20:52] <geser> infinity: bug 31098 needs also your attention
[20:52] <ubotu> Launchpad bug 31098 in cmucl "Build-Depends dependency for cmucl cannot be satisfied (circular build-depends; needs manual bootstrapping on the buildd)" [Medium,Confirmed] https://launchpad.net/bugs/31098
[20:56] <infinity> geser: That one's tougher.
[20:57] <infinity> geser: The comments claim that it can only be bootstrapped with itself (ie: with the same version), which means every upload (or every new upstream, at least) would need a manual bootstrap.
[20:57] <infinity> geser: I don't think I'm prepared to do that.
[20:57] <geser> ok
[20:59] <infinity> geser: Responded to that bug, though.
[20:59] <geser> infinity: jbossas4 is more needed as other packages are in depwait on it, so you can ignore cmucl till you are bored :)
[20:59] <infinity> geser: The jboss4 one is a one-time bootstrap, I assume?
[21:00] <geser> infinity: yes, at least I hope
[21:04] <jdstrand> pitti: re net: no problem
[21:05] <jdstrand> s/net/nut/
[21:08] <jdstrand> keescook: ^^
[21:15] <asac> doko: yes
[21:15] <asac> doko: thats ok
[22:10] <zyx386> hi
[22:12] <zyx386> i report now anew bug or Suggestion :)
[22:12] <zyx386> https://bugs.launchpad.net/ubuntu/+bug/196764
[22:12] <ubotu> Launchpad bug 196764 in ubuntu "add ku-sorani-fonts paket in Ubuntu!" [Undecided,New]
[22:13] <zyx386> I hope that one makes pure ;)
[22:35] <mdke> emgent: hi?
[22:35] <emgent> mdke, query please :)
[23:45] <Fujitsu> Why are my scrollbars orange?
[23:47] <jdong> Fujitsu: orange you glad they aren't brown?
[23:47] <jdong> ok sorry, that was horrible
[23:49] <Fujitsu> And my menu bars have decided to be striped. Hmm..
[23:49] <seb128> that's called a new theme
[23:49] <seb128> you can change in the appearance capplet