=== Pricey is now known as PriceChild [03:53] hello people [04:02] hi [04:07] somerville32, heya [04:09] :) [04:10] someone can open task for Gutsy, Feisty, edgy, Dapper in Bug #195949 ? [04:10] Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,Fix released] https://launchpad.net/bugs/195949 [04:10] i can only nominate, only >=MOTU can open task :P [04:43] I need a core-dev to sponsor my fontconfig update. It's available on rookery in ~arne/fontconfig/ . Thanks a lot! [05:05] ArneGoetje: file a bug and subscribe ubuntu-main-sponsors [05:25] slangasek, how often is the cdimage cron job going to run on the mythbuntu disk? [05:25] i haven't seen it show up as of yet [05:27] somerville32: done, thanks. [05:34] superm1: 6:19 AM London time it seems. [05:42] Bug #196359 [05:42] 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] that is causing hardy alt install to fail. [05:43] IIRC getting virtkey updated just got approved. [05:44] k - I'll watch for it and close the bug [05:45] so should that have been filed against package python-virtkey? [05:54] No. [05:54] Updating virtkey is the fix for that problem. [05:57] ScottK2: virtkey has been uploaded so all should be well very shortly. [05:58] Great. [06:00] And has built everywhere, so should be hitting the mirrors. === toresbe_ is now known as toresbe [06:33] good morning [06:36] Hi dholbach [06:36] hi geser [06:36] up early today? :) [06:36] yes, I have to. I've an exam in one hour. [06:37] how does it look? well-prepared? :-) [06:37] * dholbach crosses the fingers [06:39] thanks, I should be well-prepared. [06:39] * geser leaves now for the exam, bbl [06:40] ROCK ON :) [07:11] superm1: right, it should run daily, no promises that it succeeds though... :) let me have a look at the logs [07:13] ! Could not open lamp-server from checkout of (any of): [07:13] ! http://bazaar.launchpad.net/~mythbuntu/ubuntu-seeds/mythbuntu.hardy [07:13] ! http://bazaar.launchpad.net/~mythbuntu/ubuntu-seeds/platform.hardy [07:13] ! http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mythbuntu.hardy [07:13] ! http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.hardy [07:13] superm1: ^^ [07:14] Good morning [07:14] * slangasek waves [07:14] hi pitti, hi slangasek [07:23] 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] slangasek, okay i'll remove that reference [07:25] 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? === greeneggsnospam is now known as jsgotangco [10:17] Keybuk: hm, do we deliberately don't have antialiased fonts any more? [10:17] pitti: not delierately, no [10:17] hey pitti [10:17] * pitti hugs seb128, bonjour [10:17] pitti: dunno if you read about it yesterday but the no duplicate battery patch is creating issues [10:17] * seb128 hugs pitti [10:18] pitti: mine are still anti-aliased [10:18] pitti: like backlight control not displaying the popup dialog correctly and lagging, the battery icon being displayed when plugged on ac, etc [10:18] (having just started a new app to check) [10:18] could you have a gnome-settings-daemon failure maybe? [10:18] Keybuk: mine were as well, until I cleaned up my configuration this morning [10:18] * pitti tries with a fresh profile [10:20] Keybuk: can you try with a fresh profile? doesn't work for me with one [10:20] sure [10:20] but not right now [10:21] seb128: ugh, all just because we ignore batteries in /proc now? [10:21] pitti: yes [10:21] seb128: I heard about some issues with displaying wrong charge, etc. [10:21] pitti: does you d430 work correctly? [10:21] so maybe the ones in /proc are right, and in /sys are wrong [10:22] 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] pitti: well, you would have noticed if the battery icon was displayed while plugged ;-) [10:22] seb128: I think I configured it that way [10:23] I want the icon whenever there is a battery [10:23] ok [10:23] try changing the backlight there [10:23] what it does on my laptop is to display the popup some seconds later and scrambled [10:24] ok, booted, running on battery [10:24] hm, now after resuming I don't have a g-p-m icon at all [10:24] but it's running [10:24] brightness changing works, but no popup window [10:24] darn, this morning I still had an icon which worked [10:24] seb128: that must be your bad influence :) [10:25] lol [10:25] I just noticed that yesterday in fact [10:25] pitti: created a new user [10:25] still has anti-aliasing [10:26] Keybuk: weird; thanks for trying [10:26] the hinting is reduced to Medium by default, but it's still aliased [10:26] pitti: I confirmed that dropping the double battery patch fixes the issues [10:27] ah, how I have by battery icon back [10:27] 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] seb128: Are you restarting g-p-m after restarting hal? (or rebooting entirely) [10:27] ion_: 3x3? that would make them entirely unreadable : [10:27] mjg59: I rebooted several time a day and it's always broken [10:27] seb128: confirming the scrambled brightness popup [10:27] pitti: Yeah, isn’t that the direction we’re going? :-) [10:28] mjg59: I also tried to start gpm in verbose mode after the session [10:28] mjg59: gpm is always screwed, the log shows it fails to get the backlight value, etc [10:28] seb128: hm, if it's that broken, maybe we should reverse the patch to *only* consider batteries in /proc? [10:28] mjg59: ^ WDYT? [10:29] pitti: I can't see any way that it could cause the backlight issues [10:29] gpm is all screwed dunno why [10:29] neither can I, seems like hal/g-p-m misinterpreting /sys or so [10:29] but *shrug* [10:29] the log has dbus timeout errors when getting to get the backlight [10:30] g-p-m never touches stuff directly - it just cares about what hal provides [10:30] seb128: Run hal in verbose mode as well? [10:30] but that might be a side effect [10:30] mjg59: how do I do that? [10:30] brb, switching to laptop [10:30] hal --verbose=yes --daemon-no [10:31] re [10:33] seb128: hald --verbose=yes --daemon=no [10:34] bug #194719 [10:34] 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] [12012]: 11:34:51.697 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call [10:35] 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] This is normally a bug in some application using the D-Bus library. [10:35] seb128: That much makes sense, but I can't see how it could affect brightness [10:35] the hal log has that when pressing the keys to change backlight [10:35] Especially if you're using addon-dell-backlight [10:36] Which we probably shouldn't be on any hardware supporting the acpi backlight interface, but still [10:37] 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] 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] hal does that when gpm is started [10:40] [12450]: 11:39:33.071 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call [10:40] 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] This is normally a bug in some application using the D-Bus library. [10:40] [12450]: 11:39:41.090 [D] addon-dell-backlight.cpp:198: Received SetBrightness DBus call [10:40] 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: 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] This is normally a bug in some application using the D-Bus library. [10:40] pitti: first one can be checked by manually looking into /sys [10:40] mjg59: might be a side effect [10:41] pitti: I will check that in the evening, after work [10:41] could be that the new battery doesn't have enough informations and gpm gets confused when some things are lacking? [10:42] mjg59: gpm seems to be all broken in fact, the battery is display when the laptop is on ac for example [10:42] heh, i was just about to say something about that [10:42] since the double battery thing was fixed, gpm has been very broken wrt batteries ;) [10:43] s/very/completely uselessly/ [10:43] it tells me I have 62 hours of battery life left and doesn't show I'm on AC [10:43] Ng: lucky you! 62 hours of battery - not bad! :) [10:43] dholbach: yeah! ;) [10:43] mjg59: I don't get the hald assertions with the build done without the patch, it does that [10:43] [12922]: 11:42:49.686 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call [10:43] [12922]: 11:42:49.687 [D] addon-dell-backlight.cpp:82: Reading 5 from the AC backlight register [10:44] I've found bugs 194719, 194201, 194052 and 194180 so far which may be related [10:44] 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] Launchpad bug 194201 in hal "Battery Monitor not working (neither the battery applet) on Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/194201 [10:44] Launchpad bug 194052 in gnome-power-manager "gpm does not create the correct profiling files" [Undecided,Confirmed] https://launchpad.net/bugs/194052 [10:44] Launchpad bug 194180 in gnome-power-manager "After #177570 fix, GPM reports nonsensical values" [Undecided,Incomplete] https://launchpad.net/bugs/194180 [10:44] mine tells me i'm on AC power but my battery is discharging [10:44] argh, damn you ubotu [10:44] eep, bug flood [10:44] Hah [10:44] sorry :/ [10:45] seb128: You built both on the same system? [10:45] mjg59: no, it's hardy version vs local build without the patch [10:45] seb128: Ok. I'd recommend building locally. [10:45] I can try a local rebuild of the hardy version [10:45] ok, trying [10:45] Keybuk: my font preferences defaulted to 'best form', not subpixel smoothing [10:46] while I'm here, can I get apport to catch network-admin segfaults? it doesn't seem to be atm (in hardy) [10:47] hm, it uses policykit and thus declares itself as not dumpable [10:47] 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] 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] Ng: I don't see how we can easily have both ATM [10:48] current kernel does not allow us to disable ptrace() and still keep core dumping [10:49] pitti: I'd prefer to have it err on the side of security :) [10:49] and it would circumvent the ptrace protection, too [10:49] mjg59: local build of the hardy version has the same issue, [10:49] [6800]: 11:48:58.156 [D] addon-dell-backlight.cpp:231: Received GetBrightness DBUS call [10:49] 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] This is normally a bug in some application using the D-Bus library. [11:21] pitti: do you plan to update dbus to 1.1.4? [11:22] seb128: not really, unless we need it? [11:22] pitti: well, those are bug fix versions I think [11:22] pitti: the gvfs guys were asking about it [11:22] seb128: I looked at it some days ago, and there were new features, so I didn't update [11:22] pitti: you probably want to get 1.1.20 or backport the security patch from it (see CVE-2008-0595) [11:22] ** 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] some gvfs guys rather to be exact ;-) [11:23] 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] seb128: what do they need from it? [11:23] * pitti -> lunch, bbl [11:23] 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] pitti: enjoy [11:29] bug 173950 - what an excellent bug, I'd never thought of that problem [11:29] Launchpad bug 173950 in ubiquity "Keyboard layout choice in installer confusing" [Undecided,Confirmed] https://launchpad.net/bugs/173950 [11:58] Can anyone tell me how to find out which application a window belongs to? [11:58] Windows-esque adware windows have just appeare on my desktop [12:00] no window class [12:01] mez: This isn’t really a support channel, but run xprop and click the window. [12:01] ion_, I know it's not, however, If it's adware, then I'm gonna help get rid of it === danielm_ is now known as danielm [12:06] re [12:07] 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] \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] seb128: so at least 1.1.4 -> 1.1.20 is bugfix only [12:11] 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] \sh: just remove the suggests [12:21] 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] pitti: dbus 1.1.20 is unstable release of 1.2 version, why do you want it? [12:22] pitti: will it get in hardy? [12:22] Lure: seb128 and slomo asked for it above [12:23] Lure: 1.1.2 -> 1.1.3 was the really heavy release [12:23] Lure: 1.1.3-> 1.1.4 and 1.1.4 -> 1.1.20 are just small bug fixes [12:23] 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] 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] pitti: ok, seen now original msg about security fix [12:24] lool: this was changed to forcefully remove previous symlinks on upgrade, right? [12:24] pitti: If you like, you're welcome to try it out -- I personally didn't try the new upstream part [12:24] pitti: Correct, to work with insserv and file-rc [12:25] lool: while this is not generally good practice, I think it does help a lot in our case [12:25] As these are based on update-rc replacements and move the /etc/rc*.d/ symlinks around [12:25] bug 25931 is open for way too long [12:25] Launchpad bug 25931 in dbus "Failed to initalize HAL." [High,New] https://launchpad.net/bugs/25931 [12:25] \sh: so why does tomcat5.5 need a jdk? [12:25] and it's primarily due to shuffled rc priorities [12:25] <\sh> doko: javac is needed [12:25] so I'd love to merge this into hardy to fix it for all upgrades [12:25] \sh: why can't you fix it? [12:26] pitti: In general, the update-alternatives "symlink data is your configuration" approach doesn't scale :-/ [12:26] 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] 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] It's hard to catch mbiebl on IRC these days, I'll drop him an email now [12:28] lool: I'm happy to test it here, too [12:28] As you please [12:28] \sh: so then why do you ask? soren may be interested in tomcat [12:28] 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] lool: since due to your excellent merging into Debian the remaining Ubuntu delta should be small [12:29] 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] lool: for proper merging I'd just like to have the Debian source package for 1.1.20-1 [12:32] pitti: You mean an uploaded one? I can hand you a svn-buildpackage --svn-exported one if you like [12:32] lool: the latter would suffice, I think [12:33] we still have a delta, so precise md5sum match of diff.gz doesn't matter [12:33] I'd just like to use the same orig.tar.gz [12:33] pitti: We use tarballs from http://dbus.freedesktop.org/releases/dbus/ AFAIK [12:33] ah, great [12:34] pitti: But the diff might still change since mbiebl didn't confirm he finished [12:34] ah, I seee [12:34] He released, but then he might still change it again [12:34] lool: ok, then I'll just use your export for an initial merge [12:35] lool: and for the FF exception request [12:35] pitti: http://people.dooz.org/~lool/debian/dbus/1.1.20-1/sid/ [12:35] lool: our Ubuntu delta won't change with some further small fixes from mbiebl [12:35] Is an export [12:35] lool: merci [12:40] 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] lool: more or less, yes [12:41] pitti: Intuitively I thought it would look at seeds [12:41] lool: it uses the dependencies as initial heuristics, which works for about 98% of packages [12:41] lool: and it has an override list so that we can manually move misdetected packages into the right category [12:41] pitti: Is it possible to have multiple langpacks ship the same translations? [12:41] lool: they would conflict to each other [12:42] 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] lool: if a translation is relevant for both gnome and kde (like libxine) it lands in the neural langpack [12:42] neutral [12:42] lool: i. e. language-pack-fr instead of language-pack-{gnome,kde}-fr [12:42] pitti: Ok; that's how I understood it [12:42] 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] (what's called the default or standard langpack on the translationprocess wiki) [12:43] like, a dependency to libhildon or something [12:43] TranslationLifecycle rather [12:43] right [12:43] I don't have a really good name for that 'default' category [12:43] 'main' is misleading (component) and 'base' too (due to the -base/update pkg split) [12:43] I would have called it base, but then this conflicts with the base/update langpacks :-/ [12:43] Yep [12:43] snap :) [12:44] 'common' maybe [12:45] 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] And we also have to convert the upstream pot (or create them) and them convert them back [12:46] lool: so, building entirely separate packages, not basing on the 'common' ones above? [12:46] Anyway, we would have to push pots into another LP project, and retrieve another tarball [12:46] that would certainly work [12:46] then you can also include some GTK translations and add a Conflicts: [12:47] 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] 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] Is it possible to build the mobile langpacks against multiple LP translation tarballs? [12:48] (Typically the Ubuntu main translations and the "mobile-translations" project translations tarball) [12:48] lool: as long as the later ones only update the previous ones, that's possible, yes [12:49] 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] no, there's one source per binary [12:49] since we only update a langpack when its translations actually changed [12:50] 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] 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] Excellent [12:50] lool: it's not there in bzr head, but it's trivial to revive from the bzr history [12:50] I just removed it since we don't need it any more these days, but if you need it, no problem [12:51] seb128: Right, you get to figure out what broke between the hardy build and now... [12:51] pitti: Found it in history, thanks [12:52] 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] lool: depends; do you want to build completely separate packages, or build on top of the Ubuntu 'common' and 'gnome' ones? [12:54] pitti: One high priority goal is to save space [12:54] So a completely separate one [12:54] ok, right [12:54] * Hobbsee curses evil x bugs [12:54] (The seed data would really be good here) [12:54] then we'd need a langpack-o-matic branch for mobile with some updated skeleton source packages [12:54] with updated descriptions and Conflicts, etc. [12:55] we can drop the category matching there, since there will be just one [12:55] lool: so, getting this langpack-o-matic branch right would take maybe one or two hours [12:55] lool: the more interesting question is how to get a matching LP translation export [12:56] pitti: We have to remap translations from english <-> localized to msgid <-> localized [12:56] 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] lool: why? [12:56] pitti: Does that happen starting from the LP tarball and before calling lang-o-matic? [12:56] lool: that needs to happen for the LP translations web ui [12:57] but not necessarily for langpacks [12:57] as long as you make sure that on the mobile device at least one locale is always defined [12:57] But the code uses msgids [12:57] I know what the code does [12:58] 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] lool: let's have a phone call, shall we? [12:58] pitti: Sure :) [12:58] pitti: It's going to be on my mobile == expensive though [12:58] pitti: Or I can call you, sorry [12:58] pitti: I'm really stupid when I'm sick [12:58] pitti: Can I call your landline? [12:59] lool: see /msg [12:59] * lool is in /query overflow [12:59] Ah, another network === svolpe_gerrath is now known as svolpe === StevenK_ is now known as StevenK [13:14] 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] slomo: ok, I was confused with announcement mail then [13:16] Lure: it's explained at the bottom of that mail [13:31] re [13:32] 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] 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] 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] seb128: Yeah, dbus-send [13:56] mvo: did you get my e-mail with the question from ossi? [13:57] Riddell: let me check, I'm traveling currently [13:57] IRC while travelling. Way cool [13:59] Riddell: yes, have it [13:59] StevenK: not literally traveling, more "away from my regular environment" :) [13:59] mvo: answer when you can, I forgot you were travelling [14:01] Riddell: if I haven't by monday, kick me please [14:03] pitti: shouldn't jockey be in multiverse? [14:03] pitti: btw, hi. [14:04] 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] pitti: btw, when I said multiverse I mean restricted [14:06] carlos: why should it be there? [14:06] carlos: that's a managing drivers thing, not restricted to non free ones now I think [14:07] seb128: isn't the argument for restricted-manager move to restricted valid anymore? [14:07] carlos: why was it moved there? [14:07] seb128: because it depended on drivers that were not free [14:07] Jockey provides a user interface for configuring third-party drivers, [14:07] such as the Nvidia and ATI fglrx X.org and various Wireless LAN [14:07] kernel modules. [14:07] seb128: which is also true for jockey [14:08] at least from the description [14:09] 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] carlos: better to wait for pitti to respond, he had network issue and we are in a meeting right now though [14:11] ok [14:11] seb128: thanks for your input [14:11] heno» hello, where are the update from dapper to hardy directions? [14:18] nosrednaekim: not sure we have those yet [14:18] mvo: ^? [14:19] nosrednaekim: yes, give me a sec [14:19] thanks [14:19] seb128: look, dbus 1.1.20: https://edge.launchpad.net/~pitti/+archive [14:20] pitti: will try that, thanks [14:20] nosrednaekim: https://help.ubuntu.com/community/HardyUpgrades#head-e7f287c730b93116f89de7ea7e05efbe95fa6dd1 [14:21] nosrednaekim: let me know how it works for you, if a error happens, please send me the logs [14:23] pochu: hey, will you do the tracker update and uvf request? [14:25] mvo» uhhh sorry little crash there. [14:25] seb128: packages are already being built; dput to start of build took like 10 seconds :) (yay ppa) [14:25] hi carlos [14:25] nosredna_ekim: please /msg me details or put the error message into paste.ubuntu.com [14:25] pitti: hi [14:25] carlos: jockey is in main again, yes [14:25] I'm actually testing upgrading kubuntu using the gtk tool. Anything I should be fore-warned of? [14:25] carlos: because it's designed for free third-party drivers, too, and it doesn't hard-depend on l-r-m [14:26] carlos: however, that doesn't generally mean that we will never put packages in restricted which need i18n [14:26] pitti: ok, could I disable restricted translations handling in Launchpad then? [14:26] pitti: also, you should stop stripping translations out for those packages too [14:26] pitti: well, I discussed with you that some days ago [14:27] Keybuk: where does bootchart puts the chart? [14:27] 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] seb128: /var/log/bootchart [14:27] pitti: so, what should I do? [14:27] ah, log [14:27] carlos: I can disable stripping for restricted if we want, but why? [14:27] carlos: what's gneerally wrong with including restricted in the normal translation workflow? [14:27] ah, because of the license [14:27] I see, valid point [14:28] Keybuk: http://people.ubuntu.com/~seb128/hardy-20080228-1.png [14:28] carlos: true that, so please remove the hack [14:28] pitti: ok, thanks for clarify it. [14:28] nosredna_ekim: no, it should be fine [14:29] seb128: how strange [14:29] iz udev bog! [14:29] seb128_: I'd say kernel [14:29] if it were udev bug, udev would be a more interesting colour [14:30] 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] mvo» ok, thanks, I'll report back one way or the other. [14:30] thanks nosredna_ekim [14:30] seb128: udev.log would help [14:30] Keybuk: there is no color on this long bar [14:30] seb128: 30s is a suspiciously round number [14:31] that implies alarm(30) in someting [14:31] it's just sitting there [14:31] pitti: does apt-get dist-upgrade prompt? cause that'd be a non-interactive handler, I believel; [14:31] yeah exactly [14:31] it's sitting there [14:31] lamont: that's the dpkg conffile prompt, not maintainer scripts or apt [14:31] pitti: right [14:32] Keybuk: do you know what informations could be useful there? [14:34] lamont: want me to file an RT for it? [14:35] pitti: that's an infinity thing not me.. [14:36] I suspect he would want one though [14:36] and you might want to hold off on breaking all the buildds (if it does that) until he's around... [14:38]