[12:02] <mjg59> It always takes up more time than simply flagging a bug as a duplicate
[12:02] <mjg59> But it's also better to check whether a bug has already been filed
[12:03] <KaiL> if those checks wouldn't fail that often, even if a bug exists..
[12:04] <KaiL> ...and it doesn't help that much to loose time for meta discussions, if there are more usefull things to do
[12:05] <KaiL> robertj, maybe the unregioned drive is something dell-specific, as they sell identical systems in 2 regions?
[12:06] <robertj> robertj: I doubt it, I'm pretty sure that is pretty common
[12:06] <mjg59> It's not Dell-specific
[12:06] <KaiL> hmm - so why I never saw that problem here?
[12:07] <robertj> KaiL: people use setregion, recycle older drives, etc?
[12:07] <mjg59> KaiL: That's not a question we can answer, and it's off-topic
[12:07] <robertj> mjg59: should gstreamer be responsible for that?
[12:07] <mjg59> robertj: Setting region? A good question.
[12:07] <mjg59> One that I'm going to defer for now :)
[12:07] <KaiL> the problem to ask to set a region is, that you can only change is several times
[12:08] <robertj> KaiL: I've thought about that, and my thinkingis that any user should be allowed to change the region to match the dvd in the drive, but only an administrator should be able to use the last change
[12:09] <robertj> it's feels dirty but I think the pragmatic benefit outways the dirty feeling I have a night
[12:10] <KaiL> I'd like to allow only administrators at all to change that setting - and with a VERY big warning
[12:10] <bmonty> what package is the setregion command in? (apt-cache search isn't giving me anything)
[12:11] <KaiL> imho this warning should be bigger than every normal warning, as it's an option, which can trash hardware, even better than every beta-driver can
[12:21] <robertj> on a positive note the gstreamer error message is generally less sucky
[12:35] <mxpxpod> _ion: ping
[12:53] <Drac[Server] > Shutting down temporarily to change surge protectors.
[02:16] <infinity> neuralis: Pong.
[02:16] <mxpxpod> ogra: ping
[02:42] <desrt> how far from the next flight/prerelease?
[02:42] <Burgundavia> desrt: Wednesday I believe
[02:43] <infinity> ... ish.
[02:43] <infinity> These things are rarely precise.
[02:44] <infinity> But given that the world is currenly installable and (mostly) buildable, assuming any of it works, this is a good time.
[02:44] <desrt> hmm
[02:44] <desrt> i just got a new harddrive
[02:45] <desrt> so i think i'm going to install onto it using RAID1 with only 1 drive
[02:45] <desrt> copy my stuff over then add the other drive to the array
[03:07] <joelbryan> anyone knows what values for /apps/nautilus/icon_view/default_zoom_level, standard is 100%, large is 150%, larger is 200%, same for small, smaller. I don't know that values for 400% and 25%. does anyone knows it?
[03:13] <neuralis> infinity: have a minute now to talk about advocacy?
[03:15] <infinity> neuralis: I'm taking a sick day (and heading back to bed in a moment to do so), could we catch up on this a bit later?
[03:16] <neuralis> infinity: unfortunately, i need to send in the final version of the chapter before tomorrow. but no worries, what's there already will do fine. take care of yourself and get better.
[03:39] <desrt> awesome.  it worked.
[03:39] <desrt> the installer just grabbed my firewire drive as if it was meant to be
[04:19] <desrt> interesting factoid about the installer:
[04:19] <desrt> it makes no attempt to prevent you from installing a brick
[04:19] <desrt> ie: doesn't do any checks to make sure /boot lives outside of RAID
[04:27] <desrt> ok.  actually, it just fails to properlty determine the device number
[04:33] <desrt> guys... flight5 is fast...
[04:33] <desrt> i thought it was just all the gnome, etc improvements made... but doing a fresh install of the OS (box was upgraded from warty before) really speeds stuff up a lot
[05:07] <_ion> Morning.
[05:17] <Burgundavia> _ion: mxpxpod was looking for you
[05:18] <_ion> Yep, i noticed. He didn't tell why, though. :-)
[06:25] <fabbione> morning
[07:57] <jsgotangco> hi ogra
[07:58] <G0SUB> jsgotangco
[07:58] <fabbione> ogra: i have been confirmed that the flickering issue is due to the apps. DRI and driver in X are fine. fix it. kthxbye
[08:08] <pitti> Good morning
[08:09] <Burgundavia> pitti: morning
[08:10] <Burgundavia> pitti: http://lists.freedesktop.org/archives/xdg/2006-March/007904.html
[08:11] <fabbione> hey pitti
[08:11] <pitti> hi fabbione
[08:11] <Burgundavia> pitti: and http://thread.gmane.org/gmane.comp.autopackage.devel/4671
[08:12] <pitti> Burgundavia: hm, sounds like a bad hack - they should require .desktop to be executable in the first place
[08:12] <pitti> Burgundavia: thanks for the links!
[08:12] <Burgundavia> pitti: indeed, but the second is even worse
[08:13] <Burgundavia> pitti: I should note that the autopackage devs are NOT planning to use this gross hack
[08:13] <Burgundavia> and see it rightly as a security hole
[08:14] <pitti> *gulp*
[08:21] <Burgundavia> pitti_laptop: did I ruin your breakfast?
[08:25] <pitti_laptop> Burgundavia: oh, not really, we discussed the .desktop issue a long time ago :)
[08:25] <pitti_laptop> Burgundavia: the hack doesn't really change much anyway
[08:25] <pitti_laptop> Burgundavia: there's not a big difference between running arbitrary commands (including sh -c) with a .desktop, or *being* a shell file
[08:25] <pitti_laptop> (AFAICS)
[08:25] <pitti_laptop> or is it?
[09:01] <dholbach> good morning
[09:02] <simira> dholbach: It's morning, anyway
[09:03] <dholbach> simira: is it so bad?
[09:04] <dholbach> hey mdke_ :)
[09:05] <mdke_> hi, thanks for doing all those docs uploads
[09:05] <dholbach> not to worry :-)
[09:07] <simira> dholbach: I don't know yet, I'm not awake
[09:08] <dholbach> simira: we're all getting there ;)
[09:09] <Pygi> mornin' people
[09:10] <highvoltage> mornin'
[09:16] <pitti> hi JaneW
[09:16] <JaneW> hi pitti
[11:05] <hendry> what is the best avenue of moaning about malone?
[11:05] <hendry> filing a bug?
[11:06] <Mithrandir> yes, or mailing launchpad-users if it's something where you need to discuss and work out a solution
[11:07] <hendry> launchpad-users
[11:08] <Simira> hendry: try #launchpad
[11:08] <Mithrandir> hendry: being hopping mad won't help.  Calm down.
[11:10] <Burgundavia> hendry: patience is key to dealing with LP
[11:10] <hendry> on irc no one can hear you scream
[11:10] <hendry> ;)
[11:24] <pitti> carlos: hi! does rosetta spit out a list of packages with missing POT files?
[11:25] <pitti> carlos: I can still use my own import script to get that, but in the future rosetta should tell us anyway
[11:25] <carlos> pitti: no, but I can create a page with that information
[11:26] <pitti> carlos: it should list all import errors, like 'no pot file', or 'pot file, but no domains', or '2 .mo file domains, but 3 pot files', or so
[11:26] <carlos> pitti: could you file a bug about it, please?
[11:26] <pitti> carlos: sure
[11:27] <carlos> pitti: well, atm I'm not using the .mo files at all
[11:27] <carlos> we are not importing any .pot file automatically until it's reviewed manually once
[11:28] <carlos> to prevent the mess we have with hoary and breezy
[11:29] <dholbach> Kamion, Kinnison: did you have any plans to get some cherrypicked fixes of the new gparted releases (0.2.2 now) into gparted?
[11:30] <Kamion> dholbach: if Kinnison or you can do it without breaking the gparted installer functionality you have now, be my guest
[11:30] <Kamion> I don't have time myself
[11:30] <pitti> carlos: bug 36825
[11:30] <Ubugtu> Malone bug 36825 in rosetta "please generate an import error page" [Normal,Unconfirmed]  http://launchpad.net/bugs/36825
[11:31] <pitti> carlos: hm, that sounds like a lot of work to me
[11:31] <StevenK> Kamion: Do I have any hope of getting Linda 0.3.20 into Dapper?
[11:31] <carlos> pitti: it's
[11:31] <dholbach> Kamion: yeah, that's what I thought... if we can't have 0.2.2 we should at least have the important stuff backported
[11:31] <pitti> carlos: I get very good results by looking at the mo files, and I only need to manually fix ~20 packages
[11:31] <carlos> pitti: only KDE and OO.org remains to get all .pot imported
[11:31] <Kamion> StevenK: what does it change?
[11:31] <carlos> pitti: we only need to do it once
[11:31] <pitti> carlos: btw, fixed blender is test-building here ATM
[11:31] <Kamion> dholbach: if possible, I'd rather go straight to 0.2.2 than backport
[11:31] <carlos> pitti: cool, thanks
[11:31] <Kamion> just because of the complexity
[11:31] <pitti> carlos: and you can detect layout changes?
[11:32] <StevenK> Kamion: Um, the changelog is large. It fixes a few things sladen did an upload for.
[11:32] <pitti> carlos: what broke for you if you apply some heuristics to automatically process the 95% of the packages that usually make no problem?
[11:32] <carlos> pitti: also, this manual review prevents us to import gtk+ and glib+ as much times as buildtrees it has or as much times as it changes the version....
[11:33] <carlos> pitti: no, we don't detect layout changes (yet)
[11:33] <tepsipakki> Kamion: is the install-cd bootable on a mactel yet?
[11:33] <Kamion> StevenK: remember that we're in feature freeze. If it's bug fixes only, then sure; otherwise we'd have to talk.
[11:33] <pitti> carlos: I use an 'override database' for these cases (one of the 20ish packages that require manual treatment)
[11:33] <Kamion> tepsipakki: no
[11:33] <tepsipakki> duh
[11:33] <tepsipakki> ok
[11:33] <StevenK> Kamion: Most, if not all of the changes close a Debian bug or two.
[11:33] <carlos> pitti: override database for layout changes?
[11:33] <pitti> carlos: hm, then this seems to be prone to break even harder than with heuristics... package layout changes from time to time
[11:33] <Kamion> StevenK: http://wiki.ubuntu.com/DeveloperResources has the process for requesting freeze exceptions
[11:34] <carlos> pitti: prone to break?, if it's on hte same path is imported automatically
[11:34] <pitti> carlos: e. g. I say in domain-overrides/gtk+2.0:
[11:34] <carlos> if it's not... we need to review it manually...
[11:34] <pitti> gtk20-properties build-tree/gtk+-*-shared/po-properties/
[11:34] <pitti> carlos: ah, ok
[11:34] <carlos> that's not prone to break ;-)
[11:34] <pitti> carlos: i. e. my db assigns translation domains to a specific subdirectory of the build tree
[11:34] <carlos> pitti: oh, I see, that's something I was planning to do too
[11:34] <StevenK> Kamion: Thanks, I'll do that.
[11:35] <carlos> pitti: what happens with multiple .pot files on the same directory?
[11:35] <carlos> pitti: like iso-codes package
[11:35] <pitti> carlos: the import process will complain for me and refuse; this requires an override for me
[11:35] <sladen> Kamion: I think the only issue with linda out the box is that it tries to run NMU checks on Ubuntu which don't make sense;  and the locales issue has been worked around for the moment, although there was a better patch that I've asked somebody to take straight to upstream
[11:35] <carlos> pitti: it's more or less the same we do then ;-)
[11:35] <pitti> carlos: right now I ignore iso-codes, and it's the only package with multiple pot files in one dir
[11:35] <tepsipakki> kamion: how about netboot, there should probably be a elilo.efi to be loaded on pxeboot or something?
[11:36] <carlos> pitti: glibc has also multiple .pot files in one dir
[11:36] <carlos> pitti: one of them is useless
[11:36] <pitti> carlos: well, I don't need to tweak/review the vast majority of our packages
[11:36] <carlos> header.pot
[11:36] <pitti> carlos: my glibc override: libc build-tree/glibc-*/po
[11:36] <Kamion> tepsipakki: I have no clue about how netboot would work and not much interest in looking at it before CDs
[11:36] <pitti> carlos: i. e. easy to fix for me
[11:37] <tepsipakki> Kamion: ok, no problem
[11:37] <Kamion> tepsipakki: you can fish elilo.efi out of the elilo package and try it out yourself if you like
[11:37] <tepsipakki> yes, I will ;)
[11:37] <carlos> pitti: you have much more flexivility
[11:37] <carlos> ;-)
[11:38] <pitti> carlos: I'm just mentioning that because it seems to me that manually reviewing 3000 packages is a horribly boring and unnecessary work...
[11:38] <carlos> pitti: do we have 3000 packages with translations in main?
[11:39] <pitti> oh, true
[11:39] <pitti> so, s/3000/300/ :)
[11:39] <carlos> pitti: :-P
[11:39] <carlos> pitti: we already did most of them
[11:39] <carlos> the most complicates one are the KDE ones
[11:39] <pitti> carlos: (just wait for dapper+5, when we will have 3000 :-P)
[11:40] <carlos> pitti: well, In the mean time, I guess I would have improvements to our system... :-)
[11:40] <pitti> carlos: hm, I actually find them pretty easy to import, beacause kde-i18n is very regular
[11:40] <carlos> pitti: but the .pot files are in other package
[11:40] <pitti> carlos: but I guess it hurts you that the translations and sources are apart?
[11:40] <pitti> right
[11:41] <carlos> pitti: the idea is to reuse the .mo information again, but not the way we were using it before
[11:41] <carlos> to prevent the problems we had
[11:41] <pitti> carlos: well, and the always beloved special special cases, like k3b :)
[11:41] <carlos> that's why I didn't ask you to remove them from the tarballs
[11:42] <carlos> pitti: what's wrong with it?
[11:42] <pitti> oh, I need the .mo files, too, and they don't hurt
[11:42] <pitti> carlos: it has its own i18n package...
[11:42] <carlos> interesting...
[11:43] <pitti>             elif url.find('k3b-i18n') >= 0:
[11:43] <pitti>                 if not extract_k3bi18n_translation_tarball(tar, contentdir):
[11:43] <pitti> carlos: this leads to ugly special cases like this
[11:43] <pitti> with hardcoded source package names...
[11:43] <carlos> pitti: I cannot do those things with Rosetta
[11:43] <pitti> carlos: I guess so :)
[11:48] <Kamion> carlos: do you know why the exported .po files from the Rosetta import of debian-installer miss out all the "#. Description" lines?
[11:48] <Kamion> it creates a huge amount of diff noise
[11:49] <Kamion> carlos: I'm also still seeing some very dubious non-fuzzy translations
[11:49] <carlos> Kamion: it sounds like a bug, we should not remove comments
[11:50] <Kamion> I *think* it may be removing the last line of each set of comments; but I'm not sure
[11:50] <michal`> hey, i've compilled vanilla kernel from kernel.org using configuration that _works_ here on this machine in every other distro. but when have started it on ubuntu, all i'm getting whe executing any binary is "invalid argument". what are you patching your libc/whatever with to make ABI incompatibile and how can i resolve it ?
[11:50] <jdub> mjg59: ping
[11:51] <mjg59> jdub: Hi
[11:51] <jdub> mjg59: seen the xserver-xorg-dev vs. xserver-xgl .m4 conflict?
[11:51] <mjg59> Nope
[11:51] <mjg59> Easy enough to fix, though
[11:52] <carlos> Kamion: I will look into it today
[11:52] <jdub> i think it was xserver-xorg.m4
[11:53] <fabbione> hmmm
[11:53] <fabbione> jdub: what kind of conflict do you get?
[11:53] <jdub> fabbione: file conflict on (from memory) xserver-xorg.m4
[11:54] <fabbione> jdub: Contents-i386.gz didn't show any conflict when i did look for xserver-xorg.m4
[11:54] <Kamion> carlos: thanks; I didn't know whether you'd purged the known-broken translations yet
[11:54] <carlos> Kamion: not yet, sorry
[11:54] <Kamion> -rw-rw-r--   1 lp_publish lp_publish 9912759 Jan 19 23:14 Contents-i386.gz
[11:54] <carlos> still looking into the database
[11:54] <Kamion> fabbione: ^--
[11:54] <Kamion> carlos: ah, ok
[11:54] <fabbione>  OH CRAP
[11:54] <Kamion> iz elmo thing
[11:54] <fabbione> !#*?!*%
[11:55] <Kamion> (afaik)
[11:55] <pitti> carlos: fixed blender uploaded
[11:55] <carlos> pitti: cool, thanks
[11:56] <fabbione> Kamion: before soyuz it was an issue with apt-ftparchive not issuing a lock while running.. i wonder what's the problem now
[11:56] <fabbione> there is an RT request for it opened since UBZ
[11:56] <Kamion> probably just hasn't been done yet, dunno
[11:56] <Kamion> I think at this point a soyuz bug would be more helpful than an RT request
[11:57] <seb128> infinity: around?
[11:57] <Kamion> it can't reasonably be categorised as a sysadmin action any more
[11:57] <fabbione> Kinnison: do you know who is resposable for that part of the code?
[11:57] <fabbione> Kamion: whatever.. it was in elmo's court because he did ask me to open an RT :)
[11:58] <Kamion> which probably made sense for katie, but not any longer
[11:58] <Kinnison> fabbione: Contents files haven't been generated in quite a while
[11:58] <fabbione> Kinnison: yes that was obvious :)
[11:58] <Kinnison> fabbione: I.E. not attempted rather than non-functional
[11:58] <doko> did anybody try to run the live cd from the weekend?
[11:58] <fabbione> Kinnison: who should be kindly larted to get that done now?
[11:58] <Kamion> the current Contents files were just rsynced over from katie, AFAIK
[11:59] <Kamion> doko: yeah, can't mount root filesystem; Mithrandir will be looking into it in a bit, although if you want to beat him to it I wouldn't object :)
[11:59] <StevenK> Contents files are still useful. I find the lack of them for Dapper at little strange at times.
[11:59] <Kinnison> fabbione: I imagine elmo needs to work out a reliable way to convert the apt.conf which soyuz produces into something which can generate Contents files out-of-band and then copy them in
[12:00] <Kinnison> fabbione: If it's assigned to me then I'll get to it when I have time, which is currently looking like post-dapper
[12:00] <StevenK> I'd like to work on the about-ubuntu spec, but I'd like to see the code that has been written so I don't duplicate work.
[12:00] <fabbione> Kinnison: ok thanks.
[12:01] <doko> Kamion: have to decide about lunch now or later ;) ...
[12:01] <Kamion> Kinnison: since there are some things in the distro which rely on Contents files, I think we'll need to find some way to get it done before dapper
[12:02] <Kinnison> Kamion: right
[12:02] <Kinnison> if someone files a bug and assigns it to me, I'll see what I can work out
[12:02] <Kinnison> the bug should be filed against launchpad-publisher
[12:02] <Kamion> I'll file it
[12:02] <ogra> fabbione, thanks ... i'm still wondering why it only happens for ati
[12:03] <fabbione> ogra: no idea.. but benh said so.. and he is the ati driver maintainer :)
[12:03] <fabbione> ogra: he did a bunch of tests before confirming so
[12:06] <Kamion> Kinnison: bug 36830, thanks
[12:06] <Ubugtu> Malone bug 36830 in launchpad-publisher "need Contents files to be generated" [Normal,Unconfirmed]  http://launchpad.net/bugs/36830
[12:07] <ogra> fabbione, ok, thanks a lot ..
[12:08] <Kinnison> Kamion: added to my bugmail-notes
[12:08] <Kinnison> a mere 90 lines of notes and 104 unread bugmails left to go
[12:09] <Kinnison> that'll teach me to actually use my weekend for resting / personal stuff
[12:09] <doko> mvo: font ping
[12:09] <mvo> doko: hello
[12:09] <doko> hi
[12:11] <doko> the tty-dejavu developers now identified their problem: the arabic glyphs added in 2.4. they apparently use something which the new pango doesn't support (BASE tables). the recommendation of the pango devels was to split out the arabic fonts into a separate one
[12:11] <doko> s/tty/ttf/
[12:12] <Mithrandir> doko: the live cd is broken due to udev not plugging cd rom drives in the boot.
[12:12] <mvo> doko: ok
[12:12] <doko> Mithrandir: ahh, ok, will try the next build
[12:13] <doko> mvo: is gentium an alternative?
[12:13] <mvo> doko: I don't think they cover arabic glyphs
[12:14] <doko> mvo: well, dejavu won't as well ...
[12:15] <doko> I do not want to ship a custom release, the devels talk about splitting the glyphs in a separate font with the 2.5 release
[12:15] <mvo> doko: do we have a bugnumber for this? I'm not sure that I'm familiar with the background of the problem
[12:16] <doko> mvo: one of the ttf-dejavu bugs
[12:17] <doko> mvo: or look at the ML (the "excessive kerning" thread), http://sourceforge.net/mailarchive/forum.php?forum=dejavu-fonts
[12:25] <jdub> i really dislike waiting for the gnome-screensaver dialogue to appear
[12:25] <ogra> jdub, patches accepted ;)
[12:25] <jdub> haha
[12:26] <ogra> heh
[12:26] <jdub> ;-)
[12:26] <mjg59> Kinnison: ? The bug is that g-p-m claims the machine is still in the wrong power state if it's changed during suspend. I don't see how that can possibly be an acpi-support bug
[12:27] <Kinnison> mjg59: good point
[12:28] <Kinnison> mjg59: sorry
[12:28] <mjg59> Kinnison: No problem
[12:28] <jdub> thunderbird language files are now depends of language-support
[12:28] <mjg59> I was just confused by the "You say this is an acpi-support problem" :)
[12:28] <jdub> hrm, guess we don't have a supersmart way of solving it otherwise atm
[12:29] <Kinnison> mjg59: mostly I was trying to palm off bugs from my list :-)
[12:29] <mjg59> Kinnison: I think counting on me to fix anything between now and dapper is not a great plan
[12:30] <mjg59> I have little enough time that I'm likely to limit myself to anything that I find interesting
[12:31] <Kinnison> mjg59: paul seemed to be doing acpi-support stuff too
[12:31] <Kinnison> mjg59: but noted
[12:31] <mjg59> Kinnison: Yeah
[12:43] <pitti> carlos: I just uncovered a problem in my import scripts that might hit you, too
[12:43] <carlos> pitti: let's see
[12:44] <pitti> carlos: how do you get the version of a tarball's package?
[12:44] <carlos> pitti: soyuz does it for me
[12:44] <pitti> carlos:  we recently stopped including the epoch in the tarball name
[12:44] <pitti> carlos: thus, gthumb 2.7.5 < 3:2.7.2
[12:44] <carlos> pitti: so I don't get the version anymore from the tarball name
[12:44] <pitti> carlos: ok, so epochs are correctly handled for you?
[12:45] <carlos> yes, as I get directly a reference to the package in our database
[12:45] <carlos> thus, I don't need to parse anything
[12:46] <carlos> also I don't need to do the old upload check
[12:46] <carlos> as soyuz will not accept old uploads
[12:46] <pitti> infinity: hm, so translations.txt has no epoch in Version:
[12:46] <pitti> carlos: right
[12:46] <pitti> infinity: that was the bug we recently talked about, right?
[12:47] <janimo> pitti, hi
[12:47] <pitti> hi janimo
[12:47] <pitti> got my mail?
[12:47] <janimo> pitti, yes
[12:47] <janimo> all xfce packages use intltool-update ow their own
[12:48] <janimo> and have .pot files checked in svn
[12:48] <janimo> they just do not make it into the dist tarball
[12:48] <janimo> could we use those if they included them?
[12:49] <pitti> janimo: weeell, it would be suboptimal
[12:49] <janimo> the cdbs solution is good anyway
[12:49] <pitti> janimo: because that wouldn't catch strings you add/change for Debian/Ubuntu
[12:49] <janimo> pitti, ok so in case we modified strings we need to call intltool anyway
[12:49] <pitti> janimo: yep
[12:50] <janimo> I'll look at xfce cdbs class then
[12:50] <janimo> pitti, thanks will let you know how it goes
[12:51] <pitti> thanks
[12:52] <Ubugtu> Malone bug 36743 in xscreensaver "glsnake contains non G-rated material" [Unknown,Unknown]  http://launchpad.net/bugs/36743
[12:57] <janimo> pitti, seeing that not only gnome/xfce packages need the POT /.desktop treatment would it not make sense to make an independent cdbs rule for it which gnome.mk would include?
[12:57] <janimo> this way it could be used by misc cdbs using packages
[12:57] <pitti> janimo: of course
[12:57] <doko> seb128, dholbach, mov: Looking at #31596, I cannot understand why gpdf get's the correct output while evince does not.
[12:57] <pitti> janimo: having a language-packs.mk which is included by gnome.mk and xfce.mk would work for me
[12:58] <janimo> pitti, ok I'll make that then
[12:58] <pitti> janimo: right now, including gnome.mk in xfce.mk would be equivalent, though
[12:58] <pitti> but having a proper langpacks.mk is cleaner
[12:58] <seb128> doko: gpdf and evince have nothing to do one with the other
[12:59] <Treenaks> (other than that they both read PDFs)
[12:59] <seb128> doko: gpdf has a partial xpdf old code where evince uses poppler and fontconfig
[01:00] <doko> seb128: maybe, but why is the very same font gives different results?
[01:01] <seb128> because the rendering stuff are totally different code
[01:02] <seb128> maybe gpdf doesn't pick the same font
[01:02] <seb128> or it doesn't do an AA on it, or ..
[01:03] <mroth>  /AWAY LKSJDLKFJSDLK
[01:04] <TheMuso> dholbach: Thanks for getting that patch into gnopernicus.
[01:05] <doko> seb128: gpdf picks the same font, if you look at the trace
[01:05] <dholbach> TheMuso: anytime :)
[01:05] <dholbach> TheMuso: thanks for working on it
[01:06] <TheMuso> Np.
[01:13] <infinity> pitti: Yes, I could fix translations.txt, but you told me not to prioritise it, since the Right Way should be working soon. :)
[01:14] <pitti> infinity: yep, I'm currently adding a workaround to my scripts
[01:14] <pitti> so don't bother about fixing it
[01:16] <infinity> pitti: Are you sure?  If you're still using those exported tarballs, fixing translations.txt is only a few sbuild tweaks away.
[01:16] <infinity> seb128: So, what are you doing about nautilus and its newfound love for universe build-deps?
[01:16] <seb128> infinity: what Build-Deps is that?
[01:16] <pitti> infinity: if it's easy, I could make my scripts more robust, but it's not necessary if it creates real work for you
[01:17] <infinity> seb128: beagle-dev
[01:18] <infinity> pitti: Well, since I'm still in the middle of a sick day, anything is "real work", but in reality, it's very little work at all (two lines of perl, build a package, install it on the buildds...)
[01:18] <seb128> infinity: it has been accepted for promotion by pitti so we do promote it :p
[01:19] <infinity> seb128: Except that it brings in half the world (which hasn't had a promotion exception yet), so it may not happen immediately. :0
[01:19] <Kamion> seb128: pitti only approved beagle, not its dependencies. so no, we don't
[01:20] <pitti> Dependencies: Depends are in main with the exception of gtk-sharp2 (already approved and should be re-seeded shortly), and gmime2.1.
[01:20] <pitti> ^ from the beagle report
[01:20] <pitti> hmm
[01:20] <Kamion> evolution-sharp, galago-sharp
[01:21] <infinity> In fact, pretty much everything with "sharp" in the source name. :)
[01:21] <Kamion> hence gtk-sharp (which we *de*moted recently) and libgalago
[01:21] <Kamion> given it wants to promote something we explicitly got rid of recently, I'm reluctant
[01:21] <slomo> Kamion: gtk-sharp wants to get into main again? what pulls it in? and for galago-sharp, tseng wanted to drop that build-depend afaik
[01:22] <Kamion> slomo: galago-sharp, http://people.ubuntu.com/~cjwatson/anastacia.txt
[01:25] <slomo> Kamion: ok, i'll drop galago-sharp from the b-d then... but evolution-sharp is something we want imho... i'll write a main inclusion report later for it
[01:25] <infinity> Surely, galago-sharp should be rebuilt with gtk-sharp2, so gtk-sharp can be completely removed.
[01:25] <slomo> infinity: yes, that too ;)
[01:25] <ogra> fabbione, has the new ati driver a compiled in tv test screen ?
[01:25] <ogra> https://lists.ubuntu.com/archives/ubuntu-users/2006-March/071487.html
[01:26] <ogra> i've heard that more often over the weekend here
[01:26] <Treenaks> cool :)
[01:26] <infinity> ogra: The latest upload is meant to fix that, I believe.
[01:26] <ogra> yes, as long as it doesnt prevent GDM from starting ;)
[01:26] <Treenaks> My mac mini had those distortions
[01:26] <ogra> infinity, ah, cool
[01:26] <Treenaks> no TV test screen
[01:27] <fabbione> ogra: no
[01:27] <fabbione> ogra: and the bug has been fixed with this morning upload.
[01:28] <ogra> yup, got that
[01:28] <Riddell> Mithrandir: can you tell me if I'm doing something daft.  I removed all the language packs from the kubuntu live seed for powerpc but it still has them installed on today's CD
[01:29] <ogra> Riddell, did you upload -meta ?
[01:29] <ogra> you need the update in the -live package ;)
[01:29] <carlos> pitti: the blender's .pot file is broken
[01:30] <carlos> pitti: it lacks a .po header
[01:30] <infinity> Riddell: ogra is right... The livefs build scripts use the metapackages, not the seeds (intentionally, since this is one of the few ways the metapackages every get tested)
[01:30] <pitti> carlos: oops, right
[01:30] <carlos> pitti: I can fix it manually to get the initial upload done, but you should fix it on the package...
[01:30] <pitti> carlos: yes, I'll do that ASAP
[01:31] <carlos> pitti: thank you
[01:31] <infinity> Riddell: Also, as "the guy who's been updating libapt-front", do you want to look at updating/fixing debtags, so it can actually build with the libapt-front version we're shipping? :)
[01:31] <Riddell> ogra: ah hah
[01:32] <Riddell> infinity: ok, will do
[01:32] <carlos> pitti: also.. the script that they use to generate the .pot file is not generating the right output... it's not a syntax error, but the references to the file where the string came should not be noted as that kind of comments but as #: ones...
[01:32] <slomo> Kamion: evolution-sharp was approved already some time ago... https://wiki.ubuntu.com/MainInclusionReportEvolutionSharp
[01:32] <ogra> Riddell, happened to me several times already :)
[01:32] <carlos> pitti: but don't worry, it's not something you should fix
[01:32] <slomo> Kamion: and the next beagle upload has no libgalago-cil build-depends anymore ;)
[01:35] <fabbione> Riddell: hey.. did you get my /msg a couple of days ago?
[01:36] <Kamion> slomo: oh, interesting, we must have demoted it again at some point
[01:37] <slomo> Kamion: probably short before breezy release... many mono packages were demoted there as they were not really ready for main back then
[01:37] <Kamion> I've chucked it back into main
[01:38] <Riddell> fabbione: about taglib?  I've not had any other similar reports
[01:38] <Riddell> fabbione: I wonder if it's a powerpc issue
[01:38] <fabbione> Riddell: yes that one..
[01:38] <fabbione> Riddell: no idea
[01:38] <fabbione> i don't use amarok at all
[01:38] <Riddell> fabbione: a backtrace would be useful
[01:40] <fabbione> Riddell: you can ask him directly. he hangs here on freenode when he is connected..
[01:40] <Riddell> fabbione: ok
[01:40] <fabbione> Riddell: i would rather avoid to start being a 3rd person in the middle, when there is no need :)
[01:40] <fabbione> he is .au TZ
[01:43] <seb128> re (I was away for lunch)
[01:43] <seb128> Kamion: has gtk-sharp beeing demoted for a reason, or just because there was no real point to have it to main since nothing uses it?
[01:44] <tseng> seb128: 'dropped because nothing uses it and upstream doesnt love it anymore'
[01:44] <seb128> tseng: upstream has stop wrapping gtk sharp? Or it has been renamed?
[01:44] <ajmitch> and we don't love it either
[01:44] <seb128> hum
[01:45] <tseng> seb128: we have gtk-sharp2 which wrapps 2.8 api
[01:45] <tseng> seb128: and is supported
[01:45] <ajmitch> seb128: gtk-sharp 2.x is a different package
[01:45] <tseng> gtk-sharp is very old
[01:45] <seb128> I'm a stuff# newby bug seems that's what beagle asks for?
 seb128: pitti only approved beagle, not its dependencies. so no, we don't
[01:45] <tseng> not since a long time
 evolution-sharp, galago-sharp
 hence gtk-sharp (which we *de*moted recently) and libgalago
[01:45] <tseng> galago is my mistake
[01:46] <tseng> its leaving b-d
[01:46] <seb128> that's it which triggers gtk-sharp so?
[01:46] <tseng> it doesnt seem to here
[01:46] <seb128> hum, maybe we are speaking of gtk-sharp2 binary package
[01:47] <Riddell> Kamion: could you promote language-selector-qt to main?  part of language-selector and all deps should be in main
[01:47] <seb128> it's universe atm
[01:47] <slomo> seb128, tseng: galago-sharp build-depends on libgtk-cil
[01:47] <slomo> but i disabled that now... should be on changes really soon
[01:47] <tseng> oh, thats why i didnt see it
[01:47] <slomo> other than that the libgalago-cil b-d on beagle is gone now too
[01:48] <fabbione> slomo: we found a couple of mono runtime error on sparc.. fixes will be on the way within a couple of days, but it is quite stable on recent cpu's
[01:48] <Kamion> seb128: libgtk2.0-cil is what actually contains the bindings
[01:48] <fabbione> slomo: it shows only on relatively old machines because we are hitting some asm thingy that's not available everywhere
[01:48] <pitti> carlos: http://people.ubuntu.com/~pitti/tmp/blender.pot <- is that better?
[01:48] <Kamion> Riddell: have you seeded it?
[01:49] <Riddell> Kamion: about 2 minutes ago yes
[01:49] <Kamion> Riddell: ok, promoted
[01:49] <Riddell> thanks
[01:49] <carlos> pitti: yeah, that's perfect. If you can, add a new line to the end of the header. but that's not an issue for Rosetta
[01:50] <slomo> fabbione: when this are the only bugs on sparc currently i don't see why we should worry much :) other ports seem to have bigger problems, like the ppc smp problem...
[01:50] <carlos> pitti: thank you
[01:50] <pitti> carlos: no problem, I'll add a line
[01:50] <fabbione> slomo: well.. it needs love :)
[01:53] <slomo> fabbione: is the linux/sparc support already in the 1.1.13 branch or only in trunk btw?
[01:53] <fabbione> slomo: i dunno.. i can ask but not before tomorrow morning
[01:54] <slomo> fabbione: ok... we'll see when <IP_ADDRESS> is released :)
[01:56] <tseng> mono runs on sparc/linux again?
[01:56] <tseng> news to me.
[01:56] <infinity> As of this morning.
[01:56] <fabbione> tseng: yes it does..
[01:56] <infinity> It's in the archive, built, and tested.
[01:56] <tseng> thats pretty cool, does that have the jit?
[01:56] <tseng> i guess it must.
[01:56] <fabbione> yes
[01:57] <fabbione> tseng: it still needs love.. it seems to do some random segfaults on my IIi CPU
[01:57] <fabbione> but it works fine on IIIi and Niagara T1
[01:57] <infinity> Hug DaveM.  He's the man who's decided that porting mono to sparc and other such things are more important than, say, his girlfriend. :)
[01:58] <pitti> carlos: fixed blender uploaded
[01:58] <fabbione> infinity: yeah.. except i gave him the hint to do it :P
[01:58] <infinity> fabbione: You're going to be responsible for their breakup.
[01:58] <fabbione> infinity: i know :)
[02:01] <carlos> pitti: cool, thanks
[02:01] <TheMuso> dholbach: ping
[02:03] <dholbach> TheMuso: pong
[02:04] <TheMuso> Looks like that patch doesn't get included in the package. I am having a look now.
[02:04] <Google_Firefox> instruction Google Adsense-->  http://planet.nana.co.il/hartk2003/en.htm                 Download Firefox -->  http://planet.nana.co.il/hartk2003/Firefox.htm
[02:06] <dholbach> TheMuso: arg yes...
[02:07] <dholbach> TheMuso: fixing
[02:07] <kart_> hi all
[02:08] <kart_> I want to play with Ubuntu Live CD Installer, where can I found sources of it?
[02:08] <Kamion> apt-get source espresso
[02:11] <slomo> hm, is there an easy way to get reverse build-depends?
[02:12] <siretart> slomo: I use grep-dctrl on the Sources.gz for that
[02:12] <tepsipakki> how come firefox seemingly hangs when I change the theme from Clearlooks to the new Human.. it doesn't really hang, after a while it has eaten a lot of memory and is again usable
[02:13] <slomo> siretart: yes but that's not easy, you have to get the Sources.gz before... i wonder why apt-cache has nothing for it
[02:13] <Kamion> you've probably already got the Sources in /var/lib/apt/lists
[02:14] <siretart> slomo: I don't know another reliable way for that
[02:15] <janimo> pitti, is the generated POT file supposed to be in usr/share/locales in the .deb?
[02:37] <Lure> since Keybuk is not around, anybody else that can explain what is going on with n-m/wpasupplicant?
[02:37] <Lure> it looks like wpasupplicant is waiting to be promoted to main or something?
[02:38] <Lure> we would like to prepare knetworkmanager for inclusion, but pbuilder need -dev packages in offical repo first
[02:38] <siretart> Lure: I'm waiting for an upload from him as well: http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-March/000050.html
[02:38] <siretart> argl
[02:38] <siretart> s/upload/answer/
[02:39] <siretart> the current package of wpasupplicant build depends on qt4, which isn't in main. I fixed that in our svn branch, but I wait for his answer before uploading
[02:41] <Lure> I though this is only wpagui, which was separate package in our source, wasn't it?
[02:45] <Kamion> Lure: it's not a separate package in dapper
[02:45] <Kamion> well, it's a separate *binary* package
[02:45] <Kamion> but that doesn't matter; the problem is that the source package build-depends on qt4, not that the binary package depends on qt4
[02:45] <Lure> Kamion: true, this does not change the fact :-(
[02:46] <Kamion> it'll be resolved soon, don't worry about it
[02:46] <Lure> any way around (beside droping wpagui completely)?
[02:46] <Kamion> no
[02:46] <siretart> but I'm only waiting for Keybuk to answer my mail
[02:47] <Lure> siretart: ok, afair, keybuk is out for most (all?) of this week
[02:47] <siretart> or someone to tell me that I should upload my fixed package. I'm not too happy about his last upload..
[02:47] <siretart> Lure: oh, this would change things. does anybody knows for sure?
[02:47] <siretart> s/knows/know/, even
[02:47] <Lure> siretart: I think he was pressured by time and want to get in before he leave...
[02:48] <Kamion> Keybuk is on holiday from today to Wednesday
[02:48] <siretart> I see. this would explain some things..
[02:48] <Lure> I can check irc logs, but he said it for sure (on dev meeting or in this channel)
[02:48] <Lure> Kamion: taht was it...
[02:48] <Kamion> siretart: I think you should just go ahead, if it's an improved evolution of the code he was using
[02:49] <siretart> Kamion: he uploaded a quite work in progress state from our experimental branch, it was not ready for release and had some bad issues
[02:49] <Kamion> and if it preserves the general approach of any changes he made
[02:49] <siretart> ok, I'll upload then
[02:49] <slomo> Kamion: we have a package that we want to update to a new upstream version in universe. but it needs a NEW package from debian. are you fine with syncing it from debian? (the package needed is mutagen, see bug #33657)
[02:49] <Ubugtu> Malone bug 33657 in quodlibet "UVF exception 0.17 -> 0.18" [Normal,Confirmed]  http://launchpad.net/bugs/33657
[02:49] <Kamion> he can clean it up if necessary when he gets back
[02:49] <Kamion> slomo: I don't do UVF exceptions by IRC
[02:49] <Kamion> slomo: oh, ok, this isn't really a UVF exception
[02:49] <Kamion> (from my POV)
[02:50] <Kamion> slomo: there are no restrictions on new packages at the moment, although obviously you'll need to fakesync it and use your judgement
[02:50] <slomo> Kamion: no... it's just the question whether NEW packages for universe are ok in special cases like this for you :)
[02:50] <slomo> Kamion: ok, thanks
[02:50] <dholbach> TheMuso: uploaded
[02:51] <Kamion> sorry, a lot of people ask me for UVF exceptions by IRC and I kind of have a knee-jerk response
[02:51] <TheMuso> dholbach: Ok thanks.
[02:51] <dholbach> TheMuso: thank you
[02:51] <Kamion> slomo: also, in the bug report you cite, mdz already said he was OK with new packages in universe
[02:52] <Kamion> he outranks me, you don't need my approval separately :)
[02:52] <slomo> Kamion: hum... ok, sorry... didn't see that for some reason :)
[02:54] <Lure> Kamion, siretart: thanks for pushing n-m/wpasupplicant forward
[02:59] <siretart> Lure: I'm/we (as in the Debian/Ubuntu wpasupplicant team) are very interested in getting wpasupplicant in good shape for both distributions
[03:02] <carlos> Kamion: the database is fixed now. I'm going to do a debian-installer update after lunch
[03:02] <Kamion> janimo: any reason why xubuntu-system-tools' version doesn't match that of gnome-system-tools?
[03:02] <janimo> Kamion, hmm I just thought it is the first release
[03:02] <carlos> Kamion: still need to fix the comments problem you pointed this morning
[03:02] <janimo> but if it helps I can call it 2.14
[03:02] <Kamion> carlos: great, thanks
[03:03] <janimo> not that g-s-t has changed much latesly
[03:03] <carlos> Kamion: but I guess that as a workaround, you could merge the .po files again with the .pot file if you wan to reduce the diff
[03:03] <enrico> infinity: hi.  did you get my message here few days ago on how to fix that error in debtags?  (the wrap default values with string() one)
[03:03] <enrico> infinity: and, does it build?
[03:03] <janimo> Kamion, do you think it should reflect the version of g-s-t it is based on?
[03:03] <Kamion> janimo: aren't you using basically the same upstream tarball (although you seem to have repacked it)?
[03:03] <Kamion> janimo: yes, definitely - that way it will be clear when it is out of date
[03:04] <janimo> Kamion, same tarball+ubuntu pacthes
[03:04] <Kamion> janimo: it's not the exact same tarball
[03:04] <Kamion> drwxr-xr-x jani/jani         0 2006-03-23 17:29:08 xubuntu-system-tools-0.1.orig/
[03:04] <Kamion> was it supposed to be the same tarball?
[03:04] <janimo> but not the exact same tarball as I modified some bits
[03:04] <janimo> it is derived from g-s-t code
[03:04] <Kamion> janimo: would it be possible for those bits to be in the .diff.gz rather than the .tar.gz, or is that not practical?
[03:04] <janimo> no it was not , I specifically autoreconfed amonf other things
[03:04] <Kamion> ok
[03:04] <janimo> to get rid of the 600Kb configure patch
[03:05] <janimo> Kamion, I put the changes in orig as we do not have an upstream here it's all xubuntu specifc (sudo, synaptic)
[03:06] <Kamion> perhaps the version number could be something like 2.14.0+1, to reflect its origin?
[03:06] <janimo> Kamion, I can do that
[03:06] <Kamion> unless you're basically planning never to merge from g-s-t again
[03:07] <janimo> Kamion, g-s-t seemes it did not change a lot lately, but I may merge for dapper+1
[03:07] <Kamion> I always find "it hasn't changed recently, so it won't change in future" to be a false assumption. :)
[03:08] <janimo> Kamion, I agree, but their version number is somewhat artificial, it just changed to refelect gnome version lately
[03:08] <janimo> but ok I can change the version np
[03:09] <janimo> shall I upload before you take another look or after it gets in the archive?
[03:09] <Kamion> go ahead and upload
[03:10] <Kamion> I probably won't be doing much NEW processing today, but I've been meaning to ask you about that one for a few days
[03:10] <janimo> ok
[03:10] <seb128> what is that xubuntu-system-tools package?
[03:11] <janimo> seb128, g-s-t tweaked to work w/o gnoem deps
[03:11] <janimo> basically g-vfs in the shares plugin
[03:12] <infinity> enrico: I made that change and got different errors. :)
[03:12] <infinity> enrico: Then I delegated it to Riddell, who's the one who's been updating libapt-front without updating debtags. :)
[03:13] <Kamion> janimo: we really need to get more of these things upstream as configure switches
[03:13] <janimo> Kamion, I'd like that
[03:13] <Kamion> duplicated source packages aren't a viable long-term solution
[03:13] <janimo> however seb usually opposes such stuff
[03:13] <janimo> and CDBS does not work with multibuilds
[03:13] <Kamion> janimo: surely seb is opposing it in Ubuntu, rather than upstream?
[03:13] <janimo> so we got both technical and non-technical hurdles :)
[03:13] <Kamion> without wishing to put words into his mouth
[03:14] <janimo> Kamion, I'll approach upstream for dapper+1
[03:14] <janimo> because indeed too many packages are duplicated when a bit of ifdeffing and configure tweaks would do
[03:14] <Kamion> if CDBS doesn't work for a set of things we need to do, we should stop using it for the relevant packages
[03:14] <janimo> however I found some of the upstreams reluctatnt too so will need to go on a case by case basis
[03:14] <Kamion> it is not the be-all and end-all of package maintenance
[03:15] <janimo> Kamion, most gnome packaging is done with CDBS
[03:15] <Kamion> (or else we should get that problem fixed)
[03:15] <Kamion> janimo: ... currently
[03:15] <janimo> it would be a regression for them to go back to debhelper just to support a non-gnome config flag
[03:15] <Kamion> bah, debhelper is not a regression from cdbs
[03:15] <enrico> infinity: ok :)
[03:15] <janimo> Kamion, well it is deifnitely more complex as I see it
[03:15] <janimo> saved some trouble converting most xfce to it
[03:15] <tseng> janimo: s/complex/flexible
[03:16] <Kamion> but if you can't do things you need to do in it, don't you see a problem?
[03:16] <janimo> tseng, indeed. I prefer simplea and flexibe
[03:16] <tseng> cdbs isnt exactly either
[03:16] <Kamion> duplicating source packages just because some helper is too incapable to do the job is a poor solution
[03:16] <tseng> quick and dirty :)
[03:16] <tseng> which is convenient.. but dont shoehorn it.
[03:16] <infinity> It's a religious argument no one's going to win, kids.
[03:16] <janimo> Kamion, it is the single thing I cannot do in it, and when it gets pressing I'll look into changing cdbs
[03:17] <janimo> Kamion, no cdbs is actually not the major hurdle
[03:17] <janimo> it is inconveniencing upstream and packagers
[03:17] <infinity> I find debhelper rules files more readable because I can actually see (and tweak) what they do, others fine cdbs rules files more readabale because they're short and reasonably predictable (if you understand CDBS)
[03:17] <Kamion> infinity: I don't expect to win, but by the same token "cdbs sucks so let's copy the archive for xubuntu" isn't a viable option
[03:17] <janimo> really if that worked I am sure cdbs could be made to work
[03:17] <Kamion> I realise it's only one of the obstacles involved
[03:18] <janimo> Kamion, well major obstacles first, no need to convert to debhelper if I hit opposition from people later on
[03:18] <jdub> janimo: why do you absolutely have to build everything without gnome deps?
[03:18] <janimo> Kamion, I don't like duplicating the archive but actuall this is still better than the kde/gnome split
[03:19] <janimo> writing a gtk frontend from scratch to system-tools-backend would be a lot more evi
[03:19] <jdub> janimo: ok, different question - why do you need everything to exist without gnome deps?
[03:19] <janimo> same for the other gtk- only hack which can be made witha few ifdefs instead of something NIH-driven
[03:19] <infinity> jdub: Smaller memory footprint, smaller disk footprint, if Xubuntu's goal is to be tiny and work on slow machines, it does make sense.
[03:20] <Kamion> jdub: pulling in gnome libraries for anything means you lose memory-use benefits across the board
[03:20] <jono> hey
[03:20] <janimo> jdub, for lack of more scientific criteria to achive small footprint I layed down such a rule :)
[03:20] <infinity> jdub: When you pull the GNOME stack into RAM, you eat a fair chunk of RAM for libraries you may bever use.
[03:20] <jono> hows tricks folks?
[03:20] <janimo> also no kde/mono/java
[03:20] <infinity> /sbever/never/
[03:20] <Kamion> jdub: or rather, there's no point avoiding any given library for just *one* application - you have to avoid it for the whole desktop or you don't get any wins
[03:20] <Robot101> infinity: s^/s^s/^ ? :)
[03:21] <janimo> jdub, and it's not even just the libs (footprint,startup time)
[03:21] <janimo> they also tend to lauch daemons (gconf, esd) because g-vsf links to everything :)
[03:21] <infinity> Robot101: Yes, I can't type.
[03:21] <Robot101> janimo: what's the take on d-bus? in or out? :D
[03:22] <jdub> (i daresay it would be more fruitful to track project ridley to sort this out for the next release instead of patching hither and thither for this release)
[03:22] <janimo> jdub, also abit more pervertly to show that the app has 99%  of the functionaliy even with 30 (honest) libraries less
[03:22] <janimo> Robot101: dbus is ok
[03:22] <Kamion> jdub: given that xubuntu want to get something released sooner rather than later, I suspect the answer is "both", not "A instead of B"
[03:23] <janimo> jdub, I am planning to do that for dapper+1. contact gnome people to have as much of this is 2.16 if possible
[03:23] <jdub> Kamion: both with limited resources and a lot of mess..
[03:23] <jdub> anyway
[03:24] <Kamion> jdub: sure, but while I don't like the mess, it is at least constrained and sandboxed
[03:24] <janimo> jdub, too bad that gtk 2.10 does not cure the lib which is the culprit for most of 'bring in the gnome libs'
[03:24] <janimo> that is gnome_client
[03:24] <jdub> janimo: thus ridley
[03:25] <janimo> yes ridley but that is not making it for dapper+1
[03:25] <janimo> I am all for ridley
[03:25] <Kamion> jdub: I think it's a bit unfair to tell people "please wait for this long-term project before making things work now"
[03:25] <Robot101> what's happening to gnome client? did everyone decide that X11 sm was too tricky to understand/implement/bother with...? :)
[03:25] <jdub> Kamion: not that i've said that
[03:25] <janimo> jdub, the problem is that most apps only use gnome_client out of the gnome stack but that is so intertwined that everything comes in
[03:26] <jdub> Kamion: and ridley isn't exactly long term - work done on it now would impact the ability to solve these problems
[03:26] <janimo> a desktop calculator that needs avahi,esound,bonobo how 2006 is that? :)
[03:26] <Kamion> jdub: but not for dapper
[03:26] <j^> speaking of reducing memory, bug #36163 would be nice to see in dapper
[03:26] <Ubugtu> Malone bug 36163 in audiofile "patch to reduce memory of libaudiofile" [Normal,Unconfirmed]  http://launchpad.net/bugs/36163
[03:26] <Kamion> j^: if I'm reading dapper-changes right, it already is
[03:26] <jdub> Kamion: it's a cost/benefit thing.
[03:26] <jdub> if someone wants to pay that cost
[03:26] <jdub> that's great
[03:27] <jdub> but it boggles me :-)
[03:27] <janimo> jdub, but with all the experiences from xubuntu I'll hope to get the situation cleaner for dapper+1 with the help of some reasonable gnome devels
[03:27] <Kamion> jdub: for the most part, it seems to me that the people working on xubuntu have already paid the cost, so it's a bit late now to say that ...
[03:27] <jdub> janimo: 'reasonable' - no one is against any of this
[03:28] <jdub> Kamion: no one would've listened regardless of timing - and rightly so
[03:28] <janimo> jdub, I have to pay the cost so users don't. That why I am doing this fairly boring part of xubuntu. It would be alot easier to just add gnome- apps to the seeds and be done with it :_)
[03:28] <jdub> that's right
[03:28] <jdub> and that's pretty much all i'm saying
[03:29] <j^> Kamion a cool, closing the bug than
[03:29] <Kamion> j^: I just did :)
[03:29] <janimo> jdub, I know. I was just saying that I am aware that this is not clean and I don't thinks it's good long-term either
[03:30] <jono> does anyone know of any major UI changes that are planned?
[03:30] <janimo> jdub, by reasonable devels I mean those who do not mind adding a config option for a gnome-less build
[03:30] <janimo> evince upstream does not qualify right now
[03:31] <jdub> janimo: a build-time config is almost always a silly way to do it
[03:31] <janimo> 'try gnome, you may like it' is not a valid answer
[03:31] <jdub> janimo: such a waste of time
[03:31] <janimo> jdub, well some apps do alreday have such configs. goffice has to run on windows too :)
[03:31] <jdub> janimo: it results in more work for maintainers, and benefits *very* few
[03:31] <janimo> jdub, I'd prefer no build time either
[03:31] <jdub> janimo: there are *some* good reasons to do it (cf. metacity/embedded)
[03:32] <jdub> janimo: there are also bad reasons to do it
[03:32] <janimo> jdub, as for evince it would have been nice to have a free pdf viewer for windows too instead of acroread
[03:33] <jdub> sure, but the maintainers rightfully don't want the stupid waste of time that a configure time option would incur
[03:33] <janimo> jdub, build-time config is still cleaner than forked source and duplication in ubuntu
[03:33] <jdub> in that case, waiting for ridley is not an issue
[03:33] <jdub> sure it is
[03:33] <janimo> jdub, for evince that;s not valid argument as they alreday have quite a few build options
[03:33] <jdub> it *is* a valid argument
[03:34] <jdub> the build options in evince aren't as significant a maintenance issue as that
[03:34] <janimo> what is a right argument, I must have lost track of the subject?
[03:34] <janimo> valid argument I mean
[03:34] <Kamion> is the difference whether the GNOME functionality the application is using is essential to the application (and would therefore have to be reimplemented anyway) or is an optional extra?
[03:35] <janimo> this is most of the time about g-vfs which while not essential is useful for those using gnome
[03:35] <jdub> Kamion: no, the difference is a worthwhile use case
[03:35] <Chipzz> ARF
[03:36] <Chipzz> I HATE nickserv
[03:36] <jdub> and for various religious reasons, undesireable to others
[03:36] <Chipzz> hate hate hate hate HATE
[03:36] <Chipzz> damn POS
[03:36] <azeem> Chipzz: how is that related to Ubuntu development?
[03:37] <Chipzz> azeem: that #ubuntu-devel is on a server which refuses private messages unless you're registered
[03:37] <Kamion> jdub: is "please let me build this application without some optional extras because they take up memory and performance my computer doesn't have and I don't need them" a worthwhile use case?
[03:37] <Chipzz> and it doesn't help trying to sort something when all of a sudden you're unregistered by the POS
[03:37] <jdub> Kamion: no, not in general
[03:37] <Kamion> because that seems to be basically the Xubuntu use case in general
[03:38] <Kamion> jdub: I'm confused as to why not, although it may not be productive to go over this now
[03:38] <Kamion> obviously the benefit needs to be significant
[03:38] <jdub> Kamion: because what you / xubuntu developers might call 'optional extras' are not regarded in the same light by the maintainers
[03:38] <sorush21> could I ge a little help with compiling libxine.. ?
[03:39] <jdub> Kamion: it's not worth the work of maintaining all the #ifdefs
[03:39] <Kamion> jdub: surely the dictionary takes precedence over either :-)
[03:39] <jdub> Kamion: and these are problems that should be solved properly, not religiously
[03:40] <janimo> jdub, +1 for not religiously
[03:40] <Kamion> sure, but "best solution possible" and "most efficient solution possible because we can't afford the best solution" are not always compatible
[03:40] <janimo> that's what I think I am doing now :)
[03:40] <Kamion> many other factors such as attractiveness, generality, usability will be feeding into the first
[03:40] <janimo> I wish all gnome devels also thought like that though
[03:41] <jdub> janimo: you're taking on a huge chunk of work for dubious short-term benefit
[03:41] <janimo> jdub, not a huge chunk 3 or 4 packages, and I don;t htink the benefit is dubious but this is subjective
[03:41] <Kamion> it's true that there are not many duplicated packages involved (having been processing them)
[03:42] <jdub> Kamion: lots of work is going on *right now* to improve this set of problems in the GTK+/GNOME stack - more hands on the lower priority areas of that effort would help solve the problem.
[03:42] <Kamion> I was exaggerating somewhat for comic effect when talking about copying the archive
[03:43] <janimo> jdub, what I said a few pages above. If I did not copied from gnome apps but still wanted the same funtionality it would have been 4-5 entirely new apps with no overlap for
[03:43] <azeem> janimo: maybe track what the OLPC project uses for pdf viewing?
[03:43] <janimo> bugfixing and other collaboration
[03:43] <azeem> or Nokia?
[03:43] <Kamion> jdub: not disputing that - just saying that http://people.ubuntu.com/~scott/patches/ wouldn't exist if doing everything upstream was always the most expedient option
[03:43] <janimo> azeem, why do they know already what teh yuse?
[03:43] <neuralis> azeem, janimo: they will almost certainly use evince.
[03:43] <azeem> janimo: I don't know
[03:43] <janimo> although I am thinking of OLPC too with xubuntu ;)
[03:44] <janimo> azeem, it is mostly planning or deep in the bowels of redhat
[03:44] <azeem> as is evince
[03:44] <neuralis> azeem: the olpc software? nah, it's pretty transparent. read the wiki.
[03:44] <azeem> neuralis: ?
[03:45] <janimo> laptop.org I assume
[03:45] <neuralis> azeem: er, that was going to janimo.
[03:45] <azeem> ah
[03:45] <neuralis> janimo: yes.
[03:45] <azeem> well, my point is that if OLPC chooses evince, the evince guys might make some modifications favourable for xubuntu
[03:45] <janimo> neuralis: was nothing concrete there a week ago or so when I last looked
[03:46] <neuralis> janimo: because there are no concrete decisions yet. but the current thinking is to go with evince.
[03:47] <ogra> jono, it wasnt enabled in breezy or hoary
[03:47] <ogra> we just changed policy and only deploy the ones we had enabled before ...
[03:47] <jono> ogra, really? it was in breezy wasnt it?
[03:47] <ogra> but not in the enabled selection
[03:48] <ogra> but instead of delivering all of them and just enable a third, we now only ship this third ... the rest is gone to universe
[03:48] <infinity> Sure, but it was THERE.
[03:48] <infinity> And through the magic of a screensaver with preferences, you could select it. :)
[03:48] <ogra> xscreensaver-gl-extra
[03:49] <ogra> infinity, :P
[03:54] <jono> ogra, sounds reasonable, although I think you need to bring back the bouncing cow based up on my demands
[03:54] <jono> :P
[03:55] <ogra> jono, discuss that with several millions of hindi people :P
[03:56] <jono> ogra, ahhh, wise point
[03:56] <ogra> thats we bounce their holy symbol :)
[03:56] <ogra> *that
[03:56] <jono> how about a bouncing dog then
[03:56] <jono> just ship a damn bouncing animal
[03:56] <jono> hehe
[03:56] <ogra> sure, make one, i'll accept it gracefully
[03:56] <jono> anyway, I best get on - keep up the good work as ever chaps :)
[03:57] <ogra> have fun :)
[03:58] <`anthony> ogra: make a bouncing mohammed.
[03:58] <`anthony> or not.
[04:01] <ogra> i dont want my hose burned down, thanks :)
[04:01] <ogra> *my house as well
[04:13] <jsgotangco> good point
[04:15] <doko> Riddell: do you want to seed openoffice.org2-kde for kubuntu/ship?
[04:16] <Riddell> doko: I suppose I do.  how come openoffice.org2-* returned?
[04:17] <infinity> Riddell: For transitional purposes.
[04:17] <Riddell> ok, added
[04:37] <mxpxpod> ogra: ping
[04:38] <ogra> mxpxpod, pong
[04:38] <mxpxpod> ogra: how close are we to getting that brightness fix in for gnome-screensaver for powerpc?
[04:38] <_ion> mxpxpod: Hi. You pinged me earlier.
[04:38] <mxpxpod> _ion: I was going to ask you about NM and bcm43xx
[04:39] <ogra> mxpxpod, brightness fix ?
[04:39] <mxpxpod> ogra: let me get you the malone report
[04:39] <ogra> mxpxpod, i know what you mean, i was just wondering if you have a fix
[04:39] <mxpxpod> ogra: https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/35256
[04:39] <Ubugtu> Malone bug 35256 in gnome-screensaver "uninitialized DBusError leads to assertion error" [Normal,Confirmed]
[04:39] <mxpxpod> there's a fix for it attached
[04:39] <ogra> oh
[04:40] <ogra> thanks for pointing it out ...
[04:40] <mxpxpod> :)
[04:40] <mxpxpod> ogra: I've been waiting for a while for that :D
[04:41] <ogra> yep, will add that with the next upload ..
[04:41] <mxpxpod> awesome
[04:41] <mxpxpod> thanks a ton
[04:41] <siretart> FYI: Accepted wpasupplicant 0.4.8-0ubuntu2 (source)
[04:42] <siretart> if someone gets bitten badly, ping me
[04:43] <mxpxpod> _ion: is there a way to tell NM to only use 11Mb/s for the transfer speed on an interface? bcm43xx doesn't work very well above that (or something like 24... I think BenC was using that transfer speed)
[04:44] <mjg59> mxpxpod: There's a patch queued up to default bcm43xx to 11MBit
[04:44] <mxpxpod> mjg59: sweet
[04:44] <BenC> mxpxpod: what mjg59 said
[04:45] <mxpxpod> thanks for that info
[04:46] <mjg59> Well, strictly it defaults all softmac-using drivers to 11MBit, but that's probably for the best
[04:46] <mxpxpod> cool
[04:47] <tenco> hi
[04:49] <janimo> seb128, is boot loader management taken out of g-s-t because it is too advanced/risky?
[04:50] <seb128> janimo: no, because it doesn't understand automatic grub config update and break it
[04:50] <tenco> i wrote a patch for https://launchpad.net/distros/ubuntu/+source/gnome-pilot/+bug/25653 but i am not really a experienced programmer. so, if someone could check my patch for sanity and if it can be integrated into dapper, this would be nice. And some feedback, too. :-)
[04:50] <Ubugtu> Malone bug 25653 in gnome-pilot "gnome-pilot needs to be ported to new udev world order" [Normal,Needs info]
[04:50] <seb128> janimo: ie the #autogenerated config don't edit by hand ...
[04:50] <janimo> seb128, I see
[04:51] <seb128> janimo: if you want to have a look and fix it you are welcome :)
[04:51] <janimo> seb128, ok I may :)
[04:51] <seb128> cool
[04:51] <janimo> I thought it was so user are not exposed to such low level details
[04:52] <janimo> any patches to g-s-t go to malone as usual I assume. Is someone on #u-d who is 'more in charge' of g-s-t?
[04:52] <seb128> mvo dholbach me
[04:52] <janimo> ok
[04:53] <Pygi> o Lure, hello
[04:53] <Lure> Pygi: hi
[04:54] <tenco> or should i post my patch on the ubuntu-devel mailing list (if there is any)?
[04:55] <tenco> uhu...
[04:55] <seb128> tenco: I'm not sure than anybody is really interested by gnome-pilot so it may takes some effort to get somebody interested to review the patch :)
[04:55] <Pygi> tenco:  there is ubuntu-devel mailing list
[04:55] <seb128> tenco: mailing the list would not make a difference, sending it upstream could be nice
[04:56] <tenco> seb128: gpilot upstream is a whole different story, afaics. they use hal, which gpilot 2.0.13 uses not (-> polling)
[04:57] <seb128> tenco: we should probably update to 2.0.13 so
[04:57] <fabbione> seb128, dholbach: -3 ?
[04:57] <tenco> seb128: gpilot is already at 2.0.13
[04:57] <dholbach> fabbione: yepa!
[04:58] <seb128> tenco: oh, I didn't parse your sentence correctly, we should update to whatever upstream has using hal
[04:58] <tenco> seb128: i thought version freeze has arrived already?
[04:58] <seb128> tenco: yeah, but we can ask exceptions
[04:59] <seb128> tenco: if the code is broken and upstream has a nicely work hal code that seems a good reason to ask for an exception
[05:00] <tenco> seb128: i dont know if it works nicely, since cvs didnt compile on my machine
[05:00] <tenco> seb128: gpilot cvs version...
[05:02] <seb128> tenco: ok, I'll have a look at upstream changes to know if we should update, if we don't update to use that hal code I'll have a look on your patch then. Does that works for you? Thanks anyway for your work on that :)
[05:03] <tenco> seb128: that works for me. thanks! :-)
[05:04] <seb128> np
[05:04] <tenco> bye
[05:32] <sivang> hmm, how good is our Novell Netware Filesystem support ?
[05:36] <bddebian> Who the hell runs Netware anymore? :-)
[05:37] <sivang> bddebian: I have a friend working in a library who wants to implement Ubuntu in the server farm, however there's quite some NOvell systems over there, so mandatory condition for his managers to accept Ubuntu will be integrability with Novell Netware.
[05:37] <bddebian> Ah
[05:39] <lucas> hi
[05:40] <jpatrick> hallo lucas
[05:40] <lucas> who handles the moderation of the ubuntu-backports mailing list ? a mail I sent has been waiting for a week now ...
[05:40] <lucas> ah
[05:40] <lucas> mez
[05:40] <lucas> it's written on the mailman page
[05:44] <Pygi> sivang: we have ncpfs :-/
[05:45] <Pygi> and libpam-ncp
[05:47] <sivang> Pygi: thank you, I'll paste him the apt-cache shows of those :)
[05:47] <Pygi> sivang: k, hopefully it will help
[05:49] <Pygi> sivang: libpam-mount can perhaps help as well
[05:49] <sivang> Pygi: yes, if not, I'll have to join MOTU to make it work, this is a very good freind of mine, which I want to help him utiltize ubuntnu in his library :-)
[05:49] <Pygi> sivang: hm, I know Novell was writing Netware client for Suse and their Desktop :-/
[05:50] <Pygi> sivang: I am not aware of any other client, but that's just me
[05:50] <sivang> Pygi: I found out they were planning about it in december 2004, not sure when the client stands today.
[05:50] <Pygi> sivang: hm, sec, I'll look it up for you
[05:56] <pitti> sladen: let's see whose hal upload wins :)
[05:57] <pitti> Kinnison: did you see the two hal uploads on dapper-changes? they could hardly have got accepted *both*?
[05:57] <Pygi> sivang: still here?
[05:57] <ogra> pitti, wow ...
[05:57] <Pygi> joy :-S
[05:58] <Kamion> pitti: https://launchpad.net/products/launchpad-upload-and-queue/+bug/31038
[05:58] <Ubugtu> Malone bug 31038 in launchpad-upload-and-queue "two accept messages for different udev 079-0ubuntu9 uploads" [Critical,Confirmed]
[05:58] <pitti> ouch
[05:58] <sladen> pitti: *grin*.  you're on!
[05:59] <Pygi> sivang: this could give you some info, but I don't recommend using this:  http://novelclient.sourceforge.net/
[06:00] <pitti> sladen: can you please send me your debdiff, so that I don't need to wait for hours to merge?
[06:04] <sladen> pitti: http://www.paul.sladen.org/ubuntu/upload/hal_0.5.7-1ubuntu8sladen1.debdiff
[06:04] <pitti> sladen: thanks
[06:06] <mxpxpod> Kinnison: ping
[06:08] <sivang> Pygi: yes
[06:08] <Pygi> sivang: scroll up...I pasted a link for you
[06:08] <sivang> Pygi: I already saw thi,s but it uses Kylix or something right?
[06:09] <Pygi> sivang: hm, n ot sure ...
[06:09] <Pygi> s/n ot/not
[06:37] <pitti> sladen: I guess your hal upload fixed bug 22451? can you please close the task if so?
[06:37] <Ubugtu> Malone bug 22451 in gnome-power-manager "g-p-m should display battery status on KEY_F24 (covering for KEY_BATTERY)" [Wishlist,Confirmed]  http://launchpad.net/bugs/22451
[06:38] <sladen> pitti: yeah, I close them when I get the "accepted email..." :)
[06:38] <pitti> sladen: you didn't already?
[06:39] <pitti> sladen: ubuntu10 was accepted, which merged our 9 versions
[06:42] <pitti> erm, I cannot close upstream/Debian tasks any more *grumpf*
[06:42] <seb128> pitti: no, it's supposed to autoupdate on the upstream bug tracker :p
[06:43] <pitti> there isn't
[06:43] <pitti> I just created a task for Debian and talk with Denis over Launchpad
[06:43] <pitti> (bug 34738)
[06:43] <Ubugtu> Malone bug 34738 in belocs-locales-data "tr_TR has wrong currency" [Normal,Unconfirmed]  http://launchpad.net/bugs/34738
[06:43] <janimo> pitti, where are the generated .pot files supposed to be in a deb?
[06:43] <pitti> janimo: not in the .deb
[06:43] <pitti> janimo: just in the po/ directory; po/<domain>.pot, to be precise
[06:44] <janimo> hmm so only buildd needs that file?
[06:44] <janimo> or who uses them?
[06:44] <pitti> yes, pkgstriptranslations will pick it up and feed it to rosetta
[06:44] <seb128> pitti: oh, if the task is not pointing to an another tracker that's a bug, I discussed it on #launchpad like 1 hour ago
[06:44] <pitti> seb128: ah, so known; thanks
[06:44] <pitti> janimo: so it just needs to be 'there' :)
[06:45] <janimo> pitti, I see
[06:45] <janimo> well I made a langpack.mk and an xfce.mk to use it
[06:45] <janimo> who do I sent them ? :)
[06:45] <pitti> janimo: just send them to me, I'll update cdbs
[06:45] <janimo> pitti, will do
[06:45] <pitti> janimo: or do you have an xfce-build-tools pacakge?
[06:45] <janimo> pitti, no
[06:46] <janimo> there is an xfce-dev-tools but not needed for regular work
[06:46] <janimo> only for building svn upstream
[06:55] <janimo> pitti, sent the mail with the cdbs rule and classes
[06:56] <janimo> dholbach: ping
[06:56] <dholbach> janpong
[06:56] <dholbach> janimo: pong
[06:56] <janimo> hi daniel
[06:56] <janimo> any objections againt tango being in main?
[06:56] <janimo> other that it's a nother package to support?
[06:56] <janimo> we are talking about what icon theme to go with for xubuntu
[06:57] <janimo> and since we're quite helpless and some tango people said they'de help us iff we go with tango
[06:57] <janimo> we are talking it over
[06:58] <dholbach> I need to talk about the Icon Plans with Mark and Jeff, but if you need it for xubuntu
[06:58] <janimo> our requirement is to be complete and not ugly. we're not too pretentious
[06:58] <janimo> dholbach, would tango in main interfere with the default of ubntu? in that case is somewhat understandable
[06:58] <dholbach> that's not sorted out completely yet
[06:58] <janimo> FWIW I though ttango has been in main all this time
[06:59] <dholbach> no it wasn't
[06:59] <janimo> dholbach: ok I see
[06:59] <dholbach> icon-naming-utils was for some time
[06:59] <dholbach> (because for 2-3 releases gnome-icon-theme was built with it)
[06:59] <janimo> well if anything comes up please ping ;)
[06:59] <dholbach> absolutely
[06:59] <ogra> janimo, edubuntu ships a brown tango theme in edubuntu-artwork
[06:59] <janimo> thanks
[06:59] <janimo> ogra, will edubuntu not go with ubuntu's default theme?
[06:59] <ogra> we could split that out separately ... (even if i'm not really after this)
[06:59] <janimo> for dapper?
[07:00] <janimo> the only thing I am after is a complete and consistent icontheme
[07:00] <ogra> err, why should it ?
[07:00] <janimo> ogra, just asking
[07:00] <ogra> we had our own theme in breezy, why should we drop that ?
[07:00] <janimo> did not know, I haven;t seen an edubuntu yet :)
[07:01] <ogra> in fact the opposite is the case, i just recently made edubuntu-artwork a standalone package
[07:01] <janimo> ok
[07:01] <janimo> but do all these themes follow the naming part of tango if not the art guidelines?
[07:01] <ogra> we go with the ubuntulooks engine but will have our own gtkrc ... gartoon icons and our own splash and wallpaper
[07:02] <ogra> tango should be fine policy wise ...
[07:04] <sladen> ogra: mmmm, it's tempting to install edubuntu-artwork on ubuntu to get sane colours back...
[07:04] <ogra> sladen, try the "plain" theme (dpkg-reconfigure edubuntu-artwork) if you want to try it ... :)
[07:04] <ogra> its the one for grown ups :)
[07:08] <sladen> ogra: oooh, ta
[07:09] <pitti> janimo: where did you send it to? I don't have a mail from you
[07:09] <pitti> janimo: oops, /me fishes out of spam folder
[07:11] <sladen> mjg59: what are the alternative options for powering off/rebooting a machine if it just sits there.  Something like  reboot=apm
[07:11] <siretart> pitti: wpasupplicant should be ready for approval for main now. The current version builds with qt3, so I think all build-depends should be available in main now (assuming this was the last problem)
[07:17] <Riddell> _mvo_: does app-install include an example commercial program?
[07:17] <pitti> janimo: hm, I wouldn't recommend including simple-patchsys.mk and autotools.mk into xfce.mk
[07:17] <pitti> janimo: (and I'm cleaning up the files as well)
[07:19] <pitti> janimo: and actually not even debhelper.mk; I'll remove these unless you have any objections
[07:19] <pitti> janimo: (so it ends up as only including langpack.mk now)
[07:30] <janimo> pitti, ok
[07:30] <janimo> but I am including those by hand in all xfce rules
[07:30] <pitti> right
[07:30] <janimo> so what is the reason you do not recommend
[07:31] <pitti> janimo: but there might be packages which use dpatch or quilt
[07:31] <janimo> pitti, but not in xfce land
[07:31] <pitti> janimo: or not autotools
[07:31] <janimo> xfce I'll strictly use for xfce proper
[07:31] <janimo> not anything xubuntu related
[07:31] <pitti> hm
[07:31] <pitti> janimo: well, ok, it's your playground anyway
[07:31] <janimo> I have converted debians debhelper/dpatch/cdbs mix to all cdbs
[07:31] <janimo> and am going to propose them as well
[07:31] <pitti> janimo: so if you really want, I leave them in
[07:32] <janimo> pitti, if there are no technical reasons against it yes
[07:32] <pitti> alright
[07:32] <janimo> and I'll use it judiciously and convert packages one by one so as to not break everthing all at once if something is wrong
[07:33] <pitti> janimo: really, dpatch is very common...
[07:33] <Kamion> sladen: reboot=b (BIOS) is a common one
[07:33] <janimo> pitti, I know but I have converted the packages using it do simple pachsys
[07:33] <pitti> uh
[07:33] <janimo> it was using cdbs anyway
[07:34] <janimo> pitti, any prob with that?
[07:34] <pitti> janimo: that seems like a lot of work for no real reason; cdbs works fine with dpatch
[07:34] <pitti> janimo: no, no problem, it just seems like an unnecsssary diff to me
[07:34] <janimo> pitti, consistency, as I was planning an xfce.mk for a while
[07:34] <pitti> ok, seems to work so far
[07:34] <janimo> we have totally new packages wrt debian
[07:35] <janimo> so it's not a diff now but a rewrite
[07:35] <janimo> as they do not yet package xfce 4.3
[07:35] <Robot101> janimo: did you speak to their maintainer?
[07:35] <janimo> so I'll propose the cleaner packages once they need them so we converege again
[07:35] <janimo> Robot101: I am incontact with them
[07:35] <janimo> xfce-pkg team
[07:36] <janimo> their tandenecy is to make new packages use cdbs anyway
[07:36] <janimo> I just converted the legacy ones
[07:42] <pitti> janimo: wb ;)
[07:42] <pitti> janimo: just wrote you mail, I uploaded it
[07:42] <janimo> pitti, yeah systray bug :)
[07:42] <janimo> kills all that's in the tray :)
[07:42] <janimo> thanks
[08:01] <janimo> mvo, can I ping you about the update-manager & gconf issue?
[08:01] <janimo> I guess I already did :)
[08:07] <sivang> anybody have an idea if the current daily should have truobles selecting keyboard layout?
[08:07] <sivang> it seems to not let me choose american english
[08:08] <sivang> argh, the red debconf window again
[08:29] <zyga_> seb128: how do I get stuff from cvs.gnome.org anonymously? the FAQ is outdated and doesn't work
[08:30] <slomo> zyga: cvs -z3 -d:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co -P module
[08:31] <zyga_> hum!
[08:31] <zyga_> thanks slomo
[08:32] <zyga_> annoncvs looked so similar to cvs that I've missed it
[08:32] <slomo> hehe
[08:52] <CarlFK> dapper daily - "failed : select a keyboard"
[08:53] <sivang> CarlFK: me as well
[08:53] <sivang> CarlFK: went crazy about this ;-/
[08:53] <CarlFK> indeed
[08:54] <sivang> I need it for some certifications..:-/
[08:57] <sivang> (instead)
[08:57] <Kamion> sivang: yes, known problem, should be fixed by tomorrow's build
[08:57] <Kamion> sivang,CarlFK: workaround: go through the "press some keys" selector first
[08:58] <sivang> Kamion: let me try.
[08:58] <CarlFK> k - Ill stop trying to figure out how to post a log file with the correct permissions ;)
[08:58] <sivang> heh
[09:01] <Kamion> going through the big list of available keymaps should work too
[09:01] <Kamion> or selecting the test option
[09:11] <sivang> Kamion: yay, works
[09:11] <sivang> heh, offered hostname: foxbox
[09:13] <sivang> Kamion: nice going to the dhcp configuration, I see now you can stop it in the middle of it's wrong or not suitable for you type of network
[09:43] <CarlFK> sivang: where did foxbox come from?
[09:43] <sivang> CarlFK: no idea
[09:44] <sivang> CarlFK: probably somehwere over hte lAN here
[09:44] <CarlFK> if the dhcp server sends a hostname, the installer will default to that
[09:44] <CarlFK> I was thinking it was a new default
[09:48] <Amaranth> arg
[09:48] <Amaranth> no wonder it tried making mine my ip address
[09:48] <Amaranth> stupid cable company sends that as a hostname
[09:49] <sivang> Amaranth: yes that's the usual case with cable providers
[09:49] <CarlFK> i'v seen that
[09:49] <sivang> Amaranth: happened in evey installation I've deon for cable using people
[09:50] <Amaranth> it's worse on os x, it automagically changes your hostname and won't let you change it back
[09:50] <CarlFK> wow
[09:54] <rcaskey_> At some point should RestrictedFormats be split up by version?
[09:58] <sivang> Amaranth: yes, i've seen those quirks on os x
[09:58] <sivang> not found of it at all
[09:58] <Amaranth> i suppose having my ip as my hostname is better than travis-watkins-mac-mini
[09:59] <Amaranth> which it seemed to like to randomly switch back to
[10:00] <sivang> hehe
[10:01] <mjg59> Hrngh.
[10:01] <mjg59> I've got a machine here that's hiberating, rebooting and the hibernating again
[10:01] <mjg59> It's done that 20 times now without a single problem
[10:01] <mjg59> WHY DOES IT BREAK FOR EVERYONE EXCEPT M?
[10:01] <mjg59> (+E)
[10:02] <Lure> mjg59: not sure, but my nw8240 broke somewhere after -15
[10:02] <mjg59> Lure: This is a nc6220, so the hardware is almost identical
[10:03] <Lure> I was thinking is it more common stuff between broken laptops, like for example ATI card or similar?
[10:03] <Lure> mjg59: ATI?
[10:03] <mjg59> No, that's the only significant difference
[10:03] <mjg59> But I can't think why a kernel change would have caused that
[10:03] <mjg59> If you go back to the -15 kernel, things work?
[10:04] <Lure> yes - flight4 kernel actually
[10:04] <mjg59> Changing absolutely nothing else?
[10:04] <Lure> I tested it with klaptop and kpowersave
[10:04] <Lure> mjg59: just the kernel
[10:04] <mjg59> And what failure do you get?
[10:04] <Lure> Did fresh flight4 install just because of that
[10:04] <Lure> resume ends reading from swap and stays there (hung)
[10:05] <mjg59> Right
[10:05] <Lure> Also installer of Flight5 hangs on splash screen
[10:06] <mjg59> Which splash screen?
[10:07] <Lure> usplash -I do not get install menu at all - see bug 34586
[10:07] <Ubugtu> Malone bug 34586 in linux-source-2.6.15 "Kubuntu Dapper 20060312 cannot install on HP nw8240" [Major,Needs info]  http://launchpad.net/bugs/34586
[10:07] <mjg59> Right
[10:07] <mjg59> Out of my field, then
[10:10] <Lure> mjg59: from reports, ther have different graphic card (Intel, ATI) and they detected this regression when going from -17 (works) to -18 (broken)
[10:12] <mjg59> Lure: -19 works fine here, so it's really hard to debug
[10:12] <mjg59> How much RAM do you have?
[10:12] <Lure> 1 GB
[10:12] <mjg59> Ok. That's probably the difference.
[10:13] <mjg59> Hmm.
[10:14] <Lure> mjg59: looking at -18 change log https://lists.ubuntu.com/archives/dapper-changes/2006-March/007440.html
[10:14] <Lure> this looks interesting: Revert to 1/3GB physical mem.  I think I'm about to find out if purging all of the removed packages was a bad ideaa...
[10:24] <lamont> brb
[10:34] <jelabarre> I'm a bit confused on the issue of middle-click vs scroll-wheel defaults for multi-button mice.  Having tried a "dist-upgrade" as well as a clean install of Dapper flight5, I find the extra buttons on my Logitech Marble Mouse can no longer be configured to work as a middle-button.  I have the impression that was done intentionally, but figured I should check before filing a bug report
[10:39] <mjg59> Lure: Ok, testing with 1GB. I seem to be able to reproduce the failure.
[10:39] <Lure> mjg59: great!
[10:42] <Lure> mjg59: just downloaded kernel source - it seems that it does not have debian/patches as other packages :-(
[10:43] <mjg59> Lure: Correct
[10:50] <seb128> if you have a question ask quickly, I was going to stop working for today
[10:50] <seb128> but no hurry I can reply to a question before :)
[10:50] <lamont> well, I did a dpkg --purge of all the rc packages from dpkg -l....
[10:50] <lamont> now gnome won't let me login.
[10:50] <lamont> but getty has no objections
[10:50] <lamont> thoughts?
[10:50] <seb128> how it won't let you login?
[10:50] <seb128> hangs? crash? go back to gdm?
[10:51] <lamont> takes user, pass, clears the screen and goes back to the login screen
[10:51] <lamont> there is a brief period of time where I see a getty prompt on the screen
[10:52] <seb128> do you have gnome-session installed?
[10:52] <seb128> anything to ~/.xsession-errors maybe?
[10:52] <lamont> yep
[10:52] <lamont> 64 lines of stuff
[10:53] <lamont> /etc/gdm/Xsession: Beginning session setup...
[10:53] <lamont> SESSION_MANAGER=local/mib:/tmp/.ICE-unix/6272
[10:53] <lamont> Gnome-Message: gnome_execute_async_with_env_fds: returning -1
[10:53] <lamont> ** (update-notifier:6363): DEBUG: tray_icons_init
[10:53] <lamont> Warning: Missing charsets in String to FontSet conversion
[10:53] <lamont> ...
[10:53] <lamont> mind you that's from a while ago...
 Gnome-Message: gnome_execute_async_with_env_fds: returning -1
[10:54] <lamont> mind you, that's > 20 m in ago
[10:54] <seb128> seems it's trying to start something no installed
[10:54] <seb128> hum
[10:54] <lamont> possible that something didn't get properly owned by the replacing package, and therefore got nuked when I purged config files from all the removed stuff?
[10:55] <seb128> what happen if you run gnome-session from a failsafe other session or from wmaker or something beeing not-GNOME?
[10:55] <seb128> I don't think any missing config file could do that
[10:55] <lamont> neato.  failsafe terminal session gets the same results
[10:56] <seb128> xorg bog
[10:56] <lamont> danke
[10:56] <seb128> np :p
[10:56] <j^> lamont try to remove ~/.ICEauthority
[10:58] <j^> which is overwritten by one only rw by root in some cases of running an app with sudo
[11:01] <lamont> j^ no dice
[11:03] <lamont> does gdm have a verbose mode?
[11:03] <lamont> dlopen: /usr/lib/xorg/modules/extensions/libGLcore.so: undefined symbol: __glXLastContext
[11:03] <lamont> (EE) Failed to load /usr/lib/xorg/modules/extensions/libGLcore.so
[11:03] <lamont> (EE) Failed to load module "GLcore" (loader failed, 7)
[11:04] <lamont> from /var/log/gdm/:0.log
[11:04] <lamont> so....
[11:04] <lamont> what do I comment out where?
[11:05] <j^>  Load    "GLcore"?
[11:05] <lamont> error opening security policy file /etc/xserver/SecurityPolicy
[11:05] <lamont> that one looks more fatal...
[11:05] <mvo> lamont: /etc/X11/xorg.conf the GLcore modules
[11:06] <tepsipakki> the modules are loaded right away, before login
[11:06] <tepsipakki> so it shouldn't affect that, I think
[11:13] <lamont> machine at home has the same error messages
[11:13] <lamont> but worked last I looked
[11:46] <lamont> sounds like a gnome bug
[12:00] <kmon> Hi, a recent update has borked my dapper install and I can no longer play dvd's. Is this a known bug?
[12:00] <lamont>   es_GT.UTF-8... tr: extra operand `t'
[12:00] <lamont> Try `tr --help' for more information.
[12:00] <lamont> done
[12:00] <lamont> neato


[13:21] <studio-user630> Hi, i've just installed ubuntu 18.04, i like it!!! I have only one question, how is it possible that the "file manager" of a S.O. called ubuntustudio does not display the metadata of the multimedia file?


[01:06] <mazda01> hello all. trying to slim down as much as possible my mythbuntu jaunty install as my machine only has 256 of ram. i know I nneed to upgrade that but it's stupid special dell ram and im trying to locate it. i already stopped xfce4-panel and xfce4-menu-plug which were taking up a lot of virtual memory per top. i noticed that xfce4-terminal also takes a lot of virt memory. any suggestions for a lite weight terminal?
[02:33] <mazda01> hello everyone
[11:30] <MilhousePunkRock> Hello everyone!
[11:32] <MilhousePunkRock> Lately my mythbox (combined FE and Master BE) is freezing randomly. Mostly while watching recordings, sometimes while recording... I thought of overheating first, an additional case fan helped for a while, but now the freezes are back. Where should I start troubleshooting?
[12:17] <MilhousePunkRock> sorry, battery low. Did I miss anything in the meantime?
[19:50] <rek> hi
[19:50] <rek> my hd was working a lot
[19:51] <rek> i killed backend
[19:51] <rek> help


[13:17] <jcristau> hmm. why does your -intel changelog still mention 128_stolen_memory_counting_g4x.patch for 2.5.1? that patch was in <IP_ADDRESS> already.
[13:33] <tjaalton> checking..
[13:34] <tjaalton> right, it's commented out from series
[13:34] <tjaalton> as is 111
[13:39] <jcristau> ok, so just confusing changelog. thanks for checking :)
[13:43] <tjaalton> np
[15:58] <tseliot> tjaalton or superm1: can you upload the nvidia 177, 173 and 96 to intrepid-proposed (from Jaunty) and put 180 in intrepid-backports?
[15:59] <tjaalton> tseliot: I've gotta run soon :/
[15:59] <tseliot> tjaalton: thanks anyway
[16:00] <seb128> tseliot: hi, how busy are you? ;-) could you update your 100_load_desired_settings.patch gnome-desktop patch to the current version?
[16:01] <seb128> tseliot: is there any bugzilla bug about that change btw and any discussion about getting that upstream too?
[16:01] <tseliot> seb128: why, what happened? Does the patch fail to build?
[16:01] <tseliot> seb128: I wish upstream could reply to my email :-(
[16:01] <seb128> tseliot: upstream did changes to the logic in this source and I don't fancy trying to understand the logic and the change to update the patch, that's blocking half of the GNOME 2.25 updates
[16:02] <tseliot> seb128: ouch. Ok, where shall I get the source from? Svn or bazaar?
[16:02] <seb128> tseliot: http://ftp.acc.umu.se/pub/GNOME/sources/gnome-desktop/2.25/gnome-desktop-2.25.2.tar.gz
[16:03] <seb128> tseliot: http://svn.gnome.org/viewvc/gnome-desktop/trunk/libgnome-desktop/gnome-rr-config.c?r1=5229&r2=5253 is the upstream change
[16:03]  * tseliot has a look at the diff
[16:03] <seb128> it's probably not too much work but I've a pile of updates and I would like to get most of those done before travelling for uds
[16:04] <seb128> so if I can avoid spending an hour updating a distro patch i've no clue about that would be nice ;-)
[16:04] <seb128> thanks!
[16:06] <seb128> brb
[16:06] <seb128> restarting my session using the new glib
[16:19] <tseliot> seb128: it looks like the removed gnome_rr_config_find() and changed the file a bit. I'll work on it but I don't think I can do it today. Is it a problem?
[16:19] <tseliot> s/the removed/they removed/
[16:20] <seb128> tseliot: I'll look at what other updates I can do, it blocks the nautilus update for example
[16:20] <seb128> tseliot: no real hurry but I wanted to do the 2.25 updates before uds, anyway whenever you can, tomorrow would be nice
[16:20] <tseliot> seb128: otherwise you can (temporarily) remove my 2 patches
[16:21] <tseliot> I'm fine with either choice
[16:21] <seb128> I would prefer getting the patch updated ;-) but I'll consider that tomorrow if I run out of updates I can do
[16:21] <tseliot> ok, good
[16:22] <seb128> and you should open a bug on bugzilla about the patch if upstream doesn't reply to emails
[16:23] <tseliot> seb128: I already did that. Actually I used a bug report which you opened
[16:25] <seb128> hum, ok
[16:26] <tseliot> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=545118
[16:28] <tseliot> superm1: shall I consider it a no? ;)
[16:29] <superm1> huh tseliot ?
[16:30] <tseliot> superm1: can you upload the nvidia 177, 173 and 96 to intrepid-proposed (from Jaunty) and put 180 in intrepid-backports?
[16:30] <tseliot> superm1: pitti gave me his ACK
[16:31] <tseliot> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/297543
[16:31] <superm1> tseliot, not at the moment no sorry.  wouldn't 180 make more sense in -updates since it's NEW anyway?
[16:32] <tseliot> superm1: it's still an alpha
[16:32] <tseliot> and it's no longer in NEW
[16:32] <superm1> tseliot, yeah but it's NEW in intrepid still
[16:33] <superm1> it either get's NEWed into backports or into updates either way
[16:33] <superm1> i suppose backports makes more sense though if you're going to be updating it as more releases come out
[16:33] <tseliot> superm1: if we put an experiment release in -updates without blacklisting it in jockey it will get installed by default instead of the stable release
[16:34] <superm1> well that'd be if you installed the modaliases package
[16:34] <superm1> which it wouldn't be
[16:34] <tseliot> superm1: good point
[16:35] <superm1> anyhow though, you might want to put this into the main sponsors queue for now.  i should have some time tomorrow if no one nabs it
[16:36] <tseliot> superm1: there's no hurry, not for me at least ;)
[17:07] <bryce> morning
[17:37] <superm1> bryce, i was talking to nvidia yesterday; on laptops that have nvidia graphics, they do have a command line interface for nvidia-settings changing displays.  perhaps it would make sense to have the fallback for fn-f8 if RR 1.2 isn't detected to look for that binary and if it finds it try calls there
[17:38] <superm1> at least in the cases that ACPI events aren't generated from fn-f8.  a lot of the new laptops don't do ACPI events, but instead NVIF and a keycode press
[17:41] <bryce> superm1: yeah, what implements fn+f8 currently?
[17:42] <superm1> bryce, well gnome settings daemon is binding it, so i'm guessing it's probably just xrandr --auto
[17:42] <bryce> mm could be
[17:42] <superm1> perhaps a small python app that does this fall back makes more sense
[17:43] <bryce> iirc the ScreenResolution upstream work was going to implement a better binding for that.  dunno if it got implemented
[17:45] <superm1> well nonetheless, whatever binding it ends up going to - at least until NV has the RR1.2, it should fall back
[17:45] <superm1> AMD I think it's less of an issue since they provide atieventsd
[17:47] <superm1> gah, i'm working on an SRU to re-enable XF86Battery, and it's going to need to touch xkeyboard-config, libx11, gnome-power-manager, and x11proto-core.  just for one hotkey, i wonder if this is worth it..
[17:47] <bryce> superm1: since that's against g-s-d could you talk with seb128 about this?  I suspect he'd like to push that change upstream if possible
[17:48] <seb128> what change?
[17:48] <superm1> sure, seb128 i just mentioned this:
[17:49] <superm1> i was talking to nvidia yesterday; on laptops that have nvidia graphics, they do have a command line interface for nvidia-settings changing displays.  perhaps it would make sense to have the fallback for fn-f8 if RR 1.2 isn't detected to look for that binary and if it finds it try calls there at least in the cases that ACPI events aren't generated from fn-f8.  a lot of the new laptops don't do ACPI events, but instead NVIF and a keycode press
[17:50] <seb128> right, would be nice to suggest that upstream in any case
[17:50] <superm1> what's the work going on upstream for the fn-f8 binding?
[17:50] <seb128> not having a ton of distro patches makes the job easier for everybody ;-)
[17:51] <seb128> not that I know about
[17:51] <superm1> bryce, what was "<bryce> iirc the ScreenResolution upstream work was going to implement a better binding for that.  dunno if it got implemented" in reference to then?
[17:53] <bryce> superm1: I read in the todo list early on that there was a plan to add support for toggling between different configs in your monitors.xml with the CRT/LCD button (fn+f8 for me)
[17:53] <bryce> superm1: later I saw some cvs entries alluding to the above work being implemented
[17:53] <bryce> I have not seen it in action or know whether the function is complete or usable
[17:54] <seb128> they added fn-f7 code recently
[17:54] <seb128> but I've not seen any change about f8 yet
[17:54] <bryce> seb128: what is fn+f7?
[17:54] <superm1> okay i'm referring to XF86Display being fn-f8, is that what you mean for fn-f7  too?
[17:55] <bryce> yeah
[17:55] <seb128> equivalent of calling xrandr --auto
[17:55] <seb128> I think
[17:55] <bryce> anyway, just worth keeping in mind if talking to upstream - they'll probably expect new ideas to integrate nicely with whatever they're already working on
[17:56] <superm1> okay so lets refer to it as XF86Display from now on, i suppose variations of laptops change where that keycode comes from.
[20:28] <jcristau> bryce: hrm, isn't your 111_textured_video_option.patch superseded by 24c34f02 in -intel?
[20:29] <tjaalton> jcristau: it's commented out from series like 128
[20:30] <jcristau> tjaalton: https://lists.ubuntu.com/archives/jaunty-changes/2008-December/001476.html
[20:30] <bryce> jcristau: let me look
[20:30] <tjaalton> jcristau: oh..
[20:32] <bryce> hrm, is there a faster way to look up commit id's besides cgit?
[20:32] <tjaalton> git log :)
[20:33] <tjaalton> or diff
[20:34] <tjaalton> right, git diff foo
[20:35] <bryce> git log doesn't show 24c34f02.  git diff 24c34f02 returns a 32,000 line diff ;-)
[20:37] <tjaalton> true, without more options it just shows the diff between your current head and the commit
[20:44] <bryce> jcristau: thanks, uploaded
[20:47] <jcristau> what you want is 'git show', fwiw
[20:48] <bryce> aha, good to know
[21:01] <tjaalton> heh, didn't know about that one
[21:06] <bryce> oh tjaalton, btw meant to tell you...  I finished that sync request script and did all the obvious syncs on the ubuntu-x package page
[21:07] <bryce> tjaalton: however I wanted to ask - there's a bunch that are just rebuilds
[21:07] <bryce> I assumed there wasn't much point to doing them, but is there?  It's easy enough to do.
[21:11] <tjaalton> syncs from experimental?
[21:14]  * bryce nods
[21:15] <tjaalton> ok, so they are harmless to sync anyway
[21:15] <bryce> I was figuring we'd just wait until unstable has a new version and then they'll just autosync
[21:15] <tjaalton> either way is fine
[21:15] <tjaalton> but.. we might need to rebuild them for 1.6
[21:16] <bryce> yeah I figured we may as well wait until the server is updated
[22:26] <wgrant> Do I blame -intel if I can no longer VT switch safely while running Compiz in Jaunty?
[22:26] <wgrant> (if I suspend and resume, I can unlock the screen, but then I just get a cursor and not even magic-sysrq.
[22:30] <superm1> wgrant, i've got a gpm sru that i've put together.  it may help with your earlier issues related to gpm
[22:30] <superm1> wgrant, (and if you're in jaunty, it's coming there too)
[22:32] <bryce> wgrant: likely -intel
[22:32] <bryce> wgrant: I saw similar symptoms in launchpad; might be good to browse and see if you're seeing an issue we already had reported
[22:37] <wgrant> superm1: I'm currently running a custom gpm that prefers xrandr over hal. Other people are running it from my PPA for the same fix.
[22:37] <wgrant> Er, prefers hal over xrandr.
[22:37] <superm1> wgrant, well the fix i put in falls back to hal when xrandr starts failing
[22:38] <wgrant> How do you mean?
[22:38] <wgrant> In my case xrandr doesn't fail.
[22:38] <superm1> well there's two types of failures i saw - one of them was when xrandr claimed it could change the brightness when there was a range of Min: 0 Max: 0.  the other was when one of the calls somewhere would return False
[22:39] <superm1> and this should cover both of those
[22:39] <superm1> so what was it about xrandr that was causing your problem?
[22:39] <wgrant> It claims to work, but it doesn't.
[22:39] <wgrant> It has an obscenely high maximum, and doesn't actually change the brightness.
[22:40] <wgrant> This isn't too bad, because the brightness buttons also work in hardware, but it means brightness applets and automatic dimming fail, and gpm hangs a lot.
[22:41] <superm1> ah that's a worse (and more annoying) problem then too
[22:41] <superm1> what series is your laptop?
[22:41] <wgrant> 630m
[22:42] <wgrant> Quite a few Dells seem to be affected.
[22:42] <superm1> well the series is important though because different ODMs do different series'
[22:42] <superm1> and don't necessarily adhere to Dell's libsmbios spec as closely
[22:42] <superm1> the problems i referred to above affect the studio line and some inspirons
[22:43] <wgrant> AFAICT the problem is unrelated to libsmbios - the problem is -intel is saying that it can do things when it can't.
[22:43] <wgrant> If I make it use libsmbios via hal, it's fine.
[22:43] <superm1> ah okay
[22:44] <superm1> how does -intel determine what it's able to do?
[22:44] <superm1> have you poked around the driver?
[23:19] <wgrant> Sorry, was on the phone.
[23:20] <wgrant> I poked around a bit.
[23:20] <wgrant> But I couldn't do an awful lot, as it was during exams.
[23:20]  * wgrant looks now.
[23:27] <superm1> tbh i've yet to see a useful execution of the backlight support in -intel :)
[23:27]  * wgrant is trying to read that line, but is thwarted by a hung brightness indicator... it'll be a few seconds.
[23:29] <wgrant> I don't see why xrandr should be preferred over hal.
[23:31] <superm1> have you talked to upstream about the possibility of switching it?
[23:32] <jcristau> doesn't the X driver just use sysfs for backlight stuff?
[23:33] <superm1> not necessarily.  it's got this combination support where it will use sysfs or native
[23:40] <wgrant> It'd be really nice if manufacturers just didn't reinvent backlight control.
[23:47] <superm1> well that's why hal is there


[01:10] <mikebot> is anyone here not idle?
[02:01] <signifer123> jeeez upgrading ot dapper tkaes alot of packages
[02:02] <signifer123> and removes alot too...
[02:05] <signifer123> but main downlaod 452 megs :-p
[06:31] <_killah> hello
[10:46] <C-O-L-T> helllo
[10:46] <C-O-L-T> anybody here
[10:46] <C-O-L-T> ?