[00:00] slangasek: which is why i glimmered to life when I saw you and lamont discussing the possibility that dund might be coming back! :-P [00:00] aoh, here's some info though: http://lists.maemo.org/pipermail//maemo-users/2007-December/007933.html [00:01] not *encouraging* info, it basically says "use dbus-send", but... [00:05] slangasek: nice, "successively calling dbus-send...and parsing its output" [00:07] slangasek: hrm, perhaps someone should write a "daemon" to do that? oh wait! :-) [00:09] kirkland: well, the python dbus bindings are certainly a saner choice than dbus-send... :) [00:11] slangasek: about like writing a webserver in awk, though isn't it? :-P [00:12] hrm? [00:12] surely you're not comparing python to awk? :) [00:12] slangasek: never. i was comparing the dbus-send hack to writing a webserver in awk. it can be done, but...... [00:13] ah, yes [00:16] slangasek: awk is more like a tire iron. there bigger, better, faster, prettier, tools in the shed, but in the right situation, it'll get you out of a jam. [00:22] kirkland: "awk is more like a tire iron. If you find yourself faced with someone wielding it, back away slowly." [00:23] slangasek: i'd agree with that one too ;-) [00:24] slangasek: i suppose you could "hit them with a pipe" and "grep it away from them" ? [00:24] haha [00:25] nerd humor gone too far [00:27] no, nerd humor gone too far would be "sed plerumque sequitur ocassio calvata" [00:28] or "occasio calvata", if I could spell today [00:42] Are there plans to upgrade Transmission to the latest release? it fixes many problems [00:42] http://www.transmissionbt.com/ [00:43] asac: still up? [00:43] It has smaller memory footprint [00:44] verb3k: don't think so, too late and it adds new features [00:44] jdong: ^ [00:45] see bug 208836 [00:45] pochu, but it also fixes many many problems, we will need this during the 3 year timespan [00:46] + lower footprint [00:47] please read the bug report [00:47] ok [00:47] so far I am planning , with Charles, to isolate the bugfix patches to 1.06 [00:47] we will hold off on the new features of 1.10 for now [00:47] Warning: Color name "'#400040'" is not defined [00:47] stupid uxterm [00:47] I see [00:48] transmissions's also one of those things that I backport within a week of a new release, so that's where Hardy users can go for newer versions [00:48] but at this stage IMO it's too big of a risk to upgrade the default torrent client to a UI-changed version. [00:52] jdong, I see, I think I agree now :) [00:52] verb3k: alright, cool :) [00:52] jdong, as long as there will be backports I am cool :) [00:52] verb3k: I promise there will be backports :) [00:52] thanks for your time jdong :) [00:53] of course [01:04] Oh sure. He applies and then runs off. [01:04] * mneptok does the Deluge dance [01:06] mneptok: Is that the one where the UI blocks all the time, and the blocklist plugin crashes it? :P [01:06] RAOF: not in my experience. [01:08] I could be using the wrong plugins, of course. [01:08] generally you'd want to use Deluge plugins with Deluge. *shrug* [01:08] >:) [01:10] heya people [01:10] Right, yes :P [01:25] Can I use apt to upgrade my current gutsy 7.10 to the hardy 8.04 beta? [01:27] it's an old test laptop; I've got the desktop 8.04 beta, but it cannot use that since it's not powerful enough and I don't have resources to burn another CD [01:28] Use do-release-upgrade, and now please read the topic. [01:59] How can I call various arguments for a callback? here's the declaration: void command (GtkWidget *joliet, GtkWidget *rock, GtkWidget *verbose, GtkWidget *volid_entry, GtkWidget *input_entry, GtkWidget *output_entry); and I'm pretty sure this won't work: g_signal_connect (G_OBJECT (make_button), "clicked", G_CALLBACK (command), (gpointer) joliet, (gpointer) rock_ridge, (gpointer) verbose, (gpointer) volid_entry, (gpointer) in [02:00] theunixgeek: wrong channel [02:00] theunixgeek: /topic. This channel is not for development *on* Ubuntu :) [02:00] oh [02:00] never mind :) === evalles is now known as effie_jayx [05:12] jdong: *rofl* [05:13] keescook: lol you saw it too :) [05:13] you totally had me for like 10 seconds. multiple layer of "wtf" before I remembered the time. [05:14] http://lkml.org/lkml/2008/3/31/367 [05:16] Twitch [05:16] Perhaps they should have said OpenBSD and Theo is going to be a co-admin [05:25] StevenK: did you see scrollback re: bluez-utils? I wantses my dund back... or a writeup of how to get palm net-over-bt without it... [05:28] StevenK: and I'm wondering if maybe dund isn't in the current dbus-hackery or such? what about the other util binaries that got dropped, I wonder? [05:31] lamont: I saw it, but I'm not sure about it [05:32] I'm pretty sure that it's the only thing keeping my secondary work surface on gutsy [05:32] So a binary has been dropped between gutsy and hardy? [05:33] 3 of them [05:33] jdong: Saw what? URL please. :-) [05:33] see the diff in dpkg --contents between the two bluez-utils debs [05:34] lamont: Where is that output? [05:34] StevenK: and comments in the bug about how maybe at least part of that is intentional [05:35] lamont: I've been distracted with $WORK for the better part of four hours since, what's the bug number? [05:35] ion_: https://lists.ubuntu.com/archives/ubuntu-motu/2008-April/thread.html [05:35] ion_: see if you spot anything wrong [05:35] dpkg --contents bluez-utils_3.19-0ubuntu3_i386.deb | grep /bin/ [05:35] drwxr-xr-x root/root 0 2007-10-03 02:55 ./usr/bin/ [05:35] -rwxr-xr-x root/root 10716 2007-10-03 02:55 ./usr/bin/ciptool [05:35] -rwxr-xr-x root/root 20204 2007-10-03 02:55 ./usr/bin/dund [05:35] -rwxr-xr-x root/root 39864 2007-10-03 02:55 ./usr/bin/hcitool [05:35] -rwxr-xr-x root/root 32680 2007-10-03 02:55 ./usr/bin/hidd [05:35] -rwxr-xr-x root/root 6904 2007-10-03 02:55 ./usr/bin/l2ping [05:35] -rwxr-xr-x root/root 20620 2007-10-03 02:55 ./usr/bin/pand [05:35] -rwxr-xr-x root/root 26784 2007-10-03 02:55 ./usr/bin/passkey-agent [05:35] -rwxr-xr-x root/root 26848 2007-10-03 02:55 ./usr/bin/rfcomm [05:35] -rwxr-xr-x root/root 62936 2007-10-03 02:55 ./usr/bin/sdptool [05:35] -mix 780 : dpkg --contents bluez-utils_3.26-0ubuntu3_i386.deb | grep /bin/ [05:35] drwxr-xr-x root/root 0 2008-02-14 18:07 ./usr/bin/ [05:35] -rwxr-xr-x root/root 10620 2008-02-14 18:07 ./usr/bin/ciptool [05:35] -rwxr-xr-x root/root 39864 2008-02-14 18:07 ./usr/bin/hcitool [05:35] -rwxr-xr-x root/root 6844 2008-02-14 18:07 ./usr/bin/l2ping [05:35] -rwxr-xr-x root/root 26848 2008-02-14 18:07 ./usr/bin/rfcomm [05:35] -rwxr-xr-x root/root 62520 2008-02-14 18:07 ./usr/bin/sdptool [05:35] Argh. Pastebin! [05:36] sorry - it looked shorter [05:36] tha'ts what she said. [05:36] * StevenK belts jdong [05:36] Yes, yes it is. [05:37] lamont: So, dund, hidd, and pand are missing? [05:37] and there are corresponding --enable-foo entries in configure that weren't there before... [05:37] jdong: Haha! (the email) [05:37] OTOH, there are comments about having dbus integration for at least some parts of it... [05:43] lamont: You think we need a few --enable's scattered around, and the extra files installed? [05:43] well, I can't see how to get dund otherwise... not so sure about hidd [05:44] hidd and pand seem to maybe just possibly have dbus ducttape [05:47] But that doesn't help those who may need such daemons on a system where there is no GUI, and no dbus... [05:50] lamont: Are you able to play, or were you hoping I would just fix it? [05:50] I can play - I just wanted to give you the opportunity to say "hell no, not that way" :-) [05:51] and then there's the question of whether we want to restore all of those binaries, just dund, or somewhere in between... [05:53] and then there's the little tidbit that I'm going to hit bed in about 3 minutes... [05:54] lamont: I have no idea about bluetooth [05:54] heh. you gonna use my old argument of "I just upload bits??" :-) [05:55] lamont: Works for me. :-) [05:57] ok. so you think I should just enable all the binaries - and people can sort out dbus vs helper binaries at their leisure? [05:57] anyway, I'll upload something in about 16 hours or so. :-) [05:58] or maybe sooner, depends on how my day looks before core-hours tomorrow [05:58] * lamont -> sleep [06:24] http://live.gnome.org/GnomeGoals/XDGConfigFolders <- Rock! [06:25] calc: Awesome. [06:26] now just get .bashrc into there and it will be complete ;-) [06:26] "if the user choose a default preference, this preference should not be saved anywhere and the corresponding entry in the config file should be empty" ♥ [06:27] calc: I have a ~/.config/shellrc, which is sourced by both .bashrc and .zshrc. :-) The .rcs still contain shell-specific stuff, but .config/shellrc contains everything that works in both shells. [06:31] Slightly relevant to the quote i pasted, i've been thinking of hacking together a script that goes through your gconf settings and deletes every personal setting that matches with the system setting. [06:31] calc: Wheee!!!! Yay, that'd be cool. [06:37] i just submitted the upstream bug for OOo [06:37] it will likely take a few centuries for them to fix that one ;-) [06:42] Isn't getting to OOo to work, not look like it has been hit by a train, and be quick, a little more important? [06:47] Yes, I'd much rather have it look like a GNOME app instead of a Windows app with a gtk-like theme :) [07:12] Good morning === thegodfather is now known as fabbione [07:25] Amaranth: changing the functionality of it though would end up making it hard for users to transition from Windows to Linux, but the look is going to improve some with the new font display patch [07:25] * calc bbl, bedtime === hunger_t is now known as hunger === \sh_away is now known as \sh [07:54] good morning [07:56] keescook: ah, thanks for fixing PK (bug 205037); did you forward it upstream? [07:59] cjwatson: do you know why d-i in bug 193696 was marked 'invalid'? it's obviously still an issue === doko_ is now known as doko [08:16] <\sh> Mithrandir: congrats to your new job...but hopefully you stay with ubuntu :) [08:18] \sh: thanks, and yes, I will [08:55] Good morning [08:56] mvo: Around? [09:02] Fujitsu: yes, hello [09:02] mvo: Hi. You're only running upgrade tests for main, aren't you? [09:03] Fujitsu: mostly yes, universe is just so big. currently I have a test running with gutsy universe, but it takes quite a long time to finish. are you interessted in running some of this too? [09:05] mvo: It is unfortunate that it's so large :( [09:05] But yes, I poked you to ask how I could help. [09:06] We rebuilt universe and multiverse in 5 days, I'm sure we can manage upgrade testing in only a few times that interval. [09:08] oh, jdong finally uploaded automatix to the archive [09:09] cool :) [09:10] wasn't automatix just declared as dead? [09:11] bryce, https://lists.ubuntu.com/archives/ubuntu-motu/2008-April/003510.html [09:12] bryce, morning btw [09:12] Fujitsu: ok, sounds cool! [09:12] morning === cprov is now known as cprov-afk [09:12] Fujitsu: do you have access to a machine that supports kvm? [09:12] huh, well whatever, guess I'm confused [09:12] mvo: Said machine is currently running Xen. Probably can't run both at the same time :( [09:19] Seveas: I've subscribed you to bug #209429 (the tzdata issue from the other day) because you indicated you were able to reproduce the problem; I'm having trouble reproducing it, and am hoping you can help me narrow it down === cprov-afk is now known as cprov [09:22] Fujitsu: right, xen is fine for semi-manual testing. [09:27] slangasek: hi :) may i update swfdec, swfdec-gnome and swfdec-mozilla? all in universe, no other rdeps except these three... swfdec-gnome is part of gnome 2.22 and needs swfdec0.6 (we currently have 0.5, soname change)... if we get these two we require new swfdec-mozilla too because the old version doesn't work with the new swfdec0.6 [09:28] slangasek: what do you think? if you need more information just ask :) [09:29] slomo: if you're asking for a freeze exception, you need to talk to motu-release [09:29] slangasek: which makes things much more complicated... *sigh* ok, thanks [09:31] slomo: the bug is filed already and was approved AFAIK [09:31] dholbach: thanks, i'll search for it [09:31] slomo: bug 202468 [09:33] can someone confirm that in https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/153625/comments/29 we are not using "ubuntu" in the version as we don't need to worry about auto-syncs? === asac_ is now known as asac [09:35] james_w: I think that may have been an oversight on pitti's part [09:36] so I need to prepare them as normal, but make sure that there is an upgrade path between all releases? [09:37] (including maintainer update?) [09:38] make sure that the version numbers for each upload sort correctly wrt the releases, yes [09:38] (perhaps pitti did mean what he said, I don't know; but I don't see any reason that SRUs would be exempt from the DebianMaintainerSpec) [09:41] I shall wait for his return, there's plenty of time while I create all my chroots anyway. [09:54] cjwatson: Hmm that Xsettings for the IM in Gtk+ never worked, right? [09:55] bryce, still around ? [09:55] lool: do you understand the change sent to the bts? [10:00] seb128: Yeah, the backport was incorrect [10:00] I thought these were some codes, but these are actually offsets [10:00] ok [10:02] lool: btw about the glib upload, did you commit your changes to debian? [10:03] AFAIK yes, did I miss any? [10:03] I don't see anything pending in my SVN checkout [10:57] mvo: want me to approve release-upgrader-apt? [10:57] and -dpkg? [10:58] Riddell: from when are those? [10:59] 456636 | S- | release-upgrader-apt | 0.7.9ubuntu1 | 12 days [10:59] | * release-upgrader-apt/0.7.9ubuntu1 Component: main Section: debian-installer [11:01] Riddell: please do, much appreciated === asac_ is now known as asac [11:02] mvo: ok. also update-manager 0.81.3 has been stuck in gutsy unapproved for 5 weeks I believe to wait for 0.81.2 to move from -proposed to -updates, is that in progress? [11:03] Riddell: sort of, I need to nag bdmurray again I think [11:04] mvo: he added a comment to bug 172609 a while ago [11:04] Launchpad bug 172609 in update-manager "mishandles prerequists-sources.list on ports architectures" [High,Fix committed] https://launchpad.net/bugs/172609 [11:08] soren: as part of the server team i wonder if you have a working samba setup :)? [11:14] Sorry if this seems like a support question, but I just want to know if what I see is expected behaviour or not... I have replaced 2 old dvd drives with a single new one, and the symlink to the device is now /dev/dvd1 (and dvdrw1, cdrom1 and cdrw1). Is this to be expected, or shouldn't it rather be dvd, dvdrw, cdrom and cdrw, now that there is now only a single one of those types of drives? [11:15] Fjodor: that's expected behaviour. hotplugging means that you can't know there will only ever be one. [11:16] asac: I have samba installed, and I haven't noticed it not working... But it's not something I use on daily basis (or even a monthly basis). What's up? [11:16] soren: :) [11:16] james_w: Ok, thanks. I personal opinion would be, then, that it should be /dev/dvd0 then, shouldn't it? [11:16] soren: you are my tester then ;) ... bug 134082 [11:16] Launchpad bug 134082 in network-manager "[gutsy][fiesty] network-mannager should restart samba if ip-address is changed." [Medium,Confirmed] https://launchpad.net/bugs/134082 [11:16] Fjodor: I don't know about that. [11:17] soren: does that happen? [11:17] soren: otherwise we might wanna try to ship a restart script in /etc/NetworkManager/dispatcher.d/ [11:17] soren: what do you think? [11:19] james_w: Ok. Thanks for your answer ;-) [11:20] asac: Restartin samba unconditionally seems icky. Won't a SIGHUP do the trick? [11:20] soren: you are much more in samba land than i am :) [11:20] (i guess) [11:21] * soren tries to act innocent [11:21] slangasek, james_w: right, that indeed was a typo; of course it should be ubuntu0.6.06 etc. [11:21] soren: you think we can come up with a script for dispatcher.d? [11:22] soren: how can me make samba behave correctly when changing the IP? [11:22] james_w: do you want to prepare the SRUs, or shall I help you with them? [11:23] asac: Well, I'm hoping a SIGHUP (or smbcontrol reload-config) will make samba figure out that it's got a new IP. [11:23] soren: so only call SIGHUP on start) :? [11:23] and do nothing on stop? [11:23] * ogra_cmpc thinks smbcontrol reload-config sounds way cleaner ... leave it to the tool to care [11:24] well s/start/up/ s/stop/down/ [11:24] pitti: I'm happy to do it, I have all the chroots now, I might just have a couple of questions along the way. [11:24] asac: Yeah, when stopping, I think it figures it out on its own. [11:24] james_w: right, I'll gladly help you with anything you encounter [11:24] soren: but thats strange [11:24] pitti: so for dapper it would be 20050804-0ubuntu0.6.06 ? [11:24] soren: well not [11:25] pitti: given that dapper currently has 20050804 [11:25] james_w: exactly [11:25] great, thanks. [11:25] james_w: -0ubuntu6.06 would work, too, but for hysterical raisins we usually use 0ubuntu0.6.06 [11:25] soren: so you say that samba recognizes the down, but then doesn't get to know about he "up" ? [11:25] soren: would reload-config the right thing then? [11:26] james_w: so that the next 'regular' ubuntu upload (ubuntu1) would be greater [11:26] asac: Well, in the down case, it notices that the network has gone away. In the up case (in the bug), it's just a matter of the IP changing. [11:26] asac: It's worth a try. [11:26] asac: I've not tried it. It's just a guess. [11:26] asac: (and haven't looked at code either) [11:26] asac: I can take a quick peek at the code, when I'm back from lunch. [11:27] pitti: the bug referenced as an example on the SRU page also includes .changes, are those required? It also mentions something about the changelog mentioning approval. [11:28] james_w: the debdiff is enough for review [11:28] james_w: the .dsc, .diff.gz, and source.changes are the bits that actually get uploaded, but they can be generated from the debdiff [11:28] james_w: well, since the changelog is part of the debdiff, it needs approval, too, right [11:29] james_w: I'm picky about it because a lot of users read stable changelogs in update-manager [11:29] james_w: so " * Fix bug (LP: #1234)" isn't helpful at all [11:29] pitti: but the text of the changelog doesn't need to specify that the SRU is approved or anything? [11:29] james_w: no; it should be a human-readable text which points out the impact, some technical details, and the bug # [11:30] james_w: sth like " * Do not mark variable names ad translatable. This fixes certificates under Brazilian Portugese locales (LP: #1234)" [11:31] i. e. properly describe the bug (for users), the solution (for developers), and the bug# (for tracking) [11:31] ok, great. Thanks [11:34] soren: you could use /etc/NetworkManager/dispatcher.d/01ifupdown as a template if you want to give it a quick shot. [11:42] asac, btw, we were advised to use the suspend.d and resume.d dirs for that in gutsy (for dhcpd), is it better to use /etc/NetworkManager/dispatcher.d/ here ? [11:42] * ogra_cmpc notes that the dhcpd patch should be updated to use pm-utils though [11:42] soren, are you the dhcpd guy now ? ^^^ [11:43] ogra_cmpc: why suspend and resume if i want up and down handling? [11:43] hmm, indeed [11:43] i am confused :/ [11:43] dhcpd is unlikely to be used on dynamic devices :) [11:44] ogra_cmpc: who knows. i am sure that someone complained that dhcpd doesn't work well with network-manager :) [11:44] heh [11:45] sorry, i didnt think that far, i thought they could be related but dhcpd is indeed different [11:45] still though, the patch needs updating [11:45] not sure ... maybe it should be restarted as well when network manager downs and ups interfaces :) [11:46] well, dhcpd should be run on dynamic interfaces at all imho [11:47] *shouldnt [11:47] how do prevent that? [11:47] by not tieing dhcpd start/stop to NM but to pm-tools :) [11:48] dhcpd will start if it finds an interface with an IP range iot knows from its own config [11:48] it wont start at all if thats not the case [11:48] so NM doesnt matter for it here [11:49] ogra_cmpc: I don't think so, no. [11:49] soren, i just saw it was handed to the server team recently here in teh channel, but forgot to whom [11:51] might have been mathiaz [11:51] * soren has lost track of the amount of things he's supposed to handle :) [12:11] pitti: I think the original fix may have been too simplistic, do we need to provide an upgrade path from broken versions that does something for pt_BR users? [12:12] currently they still won't get any enabled, as they are all marked to ignore. [12:12] is there a way we can detect if they were hit by the bug? We don't know what locale was used originally do we? [12:15] pitti: because the bug was filed elsewhere, and in any case was never a d-i bug [12:15] pitti: Steve's comment is correct [12:15] pitti: there were two different bugs conflated into one [12:33] hi all [12:34] why you dont fix that errors in /usr/bin/compiz for the path !! the path is /usr/local/bin/compiz. but the right path would be /usr/bin/compiz.real !! [12:35] i have already hardy installed and this basic bug is annoying [12:38] james_w: indeed, there should be a transition path; maybe detect if the file sizes are 0? [12:40] pitti: that's probably the safest, it would be bad for anyone that had chosen to enable no certificates [12:40] james_w: hm, if someone dpkg-reconfigure'd the package and chose not to use any certificate, it would be empty as well? [12:41] james_w: if we need to take debconf values into account, then IMHO a 'forced reconfigure' on upgrade should work? [12:41] scobby: what bug is that? do you have a launchpad bug number? [12:42] i dont know but its only a minor bug. the path is wrong. the right path is /usr/bin and there is /usr/local/bin. and the libary path is wrong too, and the compiz bin path [12:42] every time i update compiz or reinstall i have to change these path to /usr/bin [12:43] scobby: where is the wrong path used? [12:43] scobby: Where to you change that path? [12:43] pitti: I'm unable to actually get debconf to ask me in the pbuilder chroot, I haven't yet worked out why [12:43] wrong path in /usr/bin/compiz [12:44] pitti: but a forced reconfigure wouldn't work for pt_BR I think, as they are all marked as rejected and so filtered out from the list that would be shown [12:46] you see the wrong pathes in the compiz wrapper? [12:46] any dev should repair that. but btw some people report it is working with that wrong path. but not for my 2 pcs [12:47] I see them, but I'm deeply surprised. compiz works just fine here. [12:47] scobby: is there a bug in the bugtracker? [12:47] you are one of them [12:47] james_w: didnt search [12:47] what wrong path is used? === bigon` is now known as bigon [12:48] seb128: The first variable set is COMPIZ_BIN_PATH [12:48] wrong: /usr/local/bin right: /usr/bin same with COMPIZ_NAME="compiz" but COMPIZ_NAME="compiz.real" is right [12:48] Amaranth, mvo: around? ^ [12:49] seb128: The final line that ends up calling compiz starts with $COMPIZ_BIN_PATH. Running it with sh -x clearly says /usr/bin/compiz.real, though. [12:50] Ah. /etc/xdg/compiz/compiz-manager has the answer. [12:50] scobby: Do you have that file? [12:51] i have similar files [12:51] scobby@laptop:~$ nano /etc/xdg/compiz/compiz-manager. [12:51] compiz-manager.bak compiz-manager.ubuntu compiz-manager.ubuntu.dpkg-new [12:51] compiz-manager.dpkg-dist compiz-manager.ubuntu.bak [12:51] but the pathes are wrong or i am wrong? [12:51] greetings [12:52] that looks like fallout from some conffile updates [12:52] scobby: the path are sent in /etc/xdg/compiz/compiz-manager [12:52] s/sent/set [12:52] hey Hobbsee [12:52] The paths in /usr/bin/compiz is (as you've seen) /usr/local/bin. However, we override that in a configuration file, which you seem to have chosen to remove. [12:52] (or at least rename) [12:53] hmmm sucks. maybe in /usr/bin/compiz should be the right path from the beginning [12:53] scobby: would need Amaranth or mvo to comment, but it seems to be the upstream version there and the ubuntu changes in /etc/xdg/compiz/compiz-manager [12:53] scobby: why did you remove the correct configuration? [12:54] i never removed that config. and i didnt know that there is also a config hidden ;-) [12:55] scobby: as seb128 said, we use the compiz-manager wrapper that comes from upstream and use the config to customize it to our needs [12:55] i think some people have that problems and the best solution would be to set the right path in /usr/bin/compiz and dont hope for a correct use of n /etc/xdg/compiz/compiz-manager [12:55] scobby: if you didn't do that you used some broken tool which did it for you [12:55] since i can think i always have to edit that /usr/bin/compiz [12:56] and with hardy i have also to comment out that new laptop check for radeon ...... [12:57] scobby: restore /etc/xdg/compiz/compiz-manager and you will have no need to do those changes [12:57] ok i try it [12:59] but the laptop check has to be removed for me to, btw i dont understand why my laptop should not use compiz?? [12:59] ok i renamed that compiz-manager and now it works [13:00] but this is not a good solution [13:00] james_w: you might need dpkg-reconfigure debconf first [13:00] james_w: hm, too bad; ah, right, the bug was in debconf itself, not in the evaluation of the debconf DB [13:01] pitti: dpkg-reconfigure debconf does nothing either [13:01] even with -plow -freadline [13:02] \sh: i did, then persia reinstated it. Don't mention the lack of power of the MC and such [13:02] pitti: sorry, lacking context, which bug in debconf? [13:03] cjwatson: sorry, bad expression; I mean "the bug was in ca-certificate's debconf templates itself" [13:03] ah [13:03] cjwatson: not in the debconf package [13:03] james_w: hm, weird [13:05] http://lists.debian.org/debian-mentors/2003/09/msg00047.html [13:05] it appears I can't do it within the chroot [13:07] james_w, you can do fiddly things with the passthrough frontend and work through a filedescriptor that you can access from outside the chroot then i think [13:07] Riddell: nice one on u-archive@! [13:08] pitti: I think we can do it with a forced reconfigure, so that the only annoyance will be an extra question for non pt_BR users. [13:09] ogra_cmpc_: I'd be happy with the readline frontend, so let's hope it doesn't come to that [13:09] james_w: hm, extra question for affected users is ok (pt_BR), but not for the unaffected users? [13:11] pitti: so, forced reconfigure if the file is empty, and just cope with annoying those few users who deactivated all certificates? [13:12] james_w: that sounds good [13:12] pitti: I'll try and come up with that then [13:12] pitti, is there an easy way to prevent translations to be ripped out of a package ? [13:12] pitti: we should put the improved fix in hardy as well? [13:13] james_w: indeed, and please let's have it uploaded to hardy first [13:13] ogra_cmpc_: export NO_PKG_MANGLE=1 in debian/rules [13:13] thanks :) [13:13] ogra_cmpc_: that will also suppress pkgmaintainermangler, though [13:13] ogra_cmpc_: and prevent LP import [13:14] ogra_cmpc_: why do you want to do that? [13:14] seems we got a patch for ldm to make it translateable [13:14] pitti, i dont need lang\packs in ltsp chroots ... the only thing exposed to the user is the ldm gui [13:14] pitti: sure. [13:14] so i'd like to keep the translations in ldm to save size [13:15] (instead of installing the whole translation set) [13:15] ogra_cmpc_: I see; that currently means that you need to use LP manually for translations [13:15] ogra_cmpc_: yeah, makes sense [13:48] haha I need to download more than the size of the CD to upgrade to 8.04 [13:48] 900mb :/ [13:49] calugor: got a lot of stuff that's not on the cd installed? [13:50] yeah [13:50] but I thought they were the latest :P [14:02] soren: is it intentional that kvm seems to do no work when it doesn't have X input focus? [14:02] cjwatson: Um.. No :) [14:02] actually, that's not quite true - when it isn't on the current virtual desktop [14:02] it's rather inconvenient not to be able to just leave a test running and go and do something else [14:02] cjwatson: Execution is halted? [14:03] cjwatson: With the sdl frontend? [14:03] I'm running 'sudo kvm -hda ~/desktop.img -cdrom hardy-desktop-i386.iso -boot d -m 512' [14:03] so whatever is the default I guess === TeTeT_ is now known as TeTeT [14:03] when I switch desktops, activity in my system monitor applet drops to zero [14:04] but, interestingly, only if kvm had focus before I switched desktops [14:04] if I alt-tab and then switch desktops, activity continues [14:04] When running like that, you don't need sudo. [14:04] Just access to /dev/kvm. [14:04] ok, but does that matter? [14:04] Nono, not at all. [14:04] I'm just saying. [14:04] I'll add myself to the kvm group, then [14:04] but it might expose something [14:05] cjwatson: I can't seem to reproduce it.. [14:06] I noticed the same thing last night [14:06] (but didn't nail it down quite as much) [14:06] Are you using compiz? [14:06] no [14:07] X bug ? === _jason is now known as jrib [14:16] Spads: do you have a minute to help me debug bug 210200? [14:17] Launchpad bug 210200 in cdrom-detect "cdrom-detect fails for HP DL145 in hardy beta" [Undecided,New] https://launchpad.net/bugs/210200 [14:32] quick q - is the updated theme still in hardy - so when I click on Places, it has a brown border on the left? [14:32] after my upgrade that theme doesnt seem to be there [14:33] <\sh> Hobbsee: I just wanted to know..a bit surprising ;) [14:33] cjwatson: Wow. I've reproduced it. Extraordinary. [14:33] jono: you should switch to kubuntu. [14:33] heh [14:35] soren: glad it's not just me [14:36] cjwatson: You switch virtual desktops with ctrl-alt-arrow keys, right? [14:36] Or did you trigger it some other way? [14:36] Riddell: I did another upload of release-upgrader-apt that should make pkgstriptranslations happy, would be cool if you could accept it [14:37] ctrl-alt tells kvm (qemu, actually) to grab input focus. When you switch to a different virtual desktop, I'm guessing it can't finish grabbing input, so it gets stuck. [14:41]