[00:34] <slangasek> superm1: well, looks like my headset isn't attaching any better with 2.6.27-5
[00:37] <stgraber> slangasek: is that SCO ?
[00:37] <slangasek> stgraber: yes
[00:38] <stgraber> ok, got some problem with mine as well, haven't tried with today's kernel though
[00:38] <slangasek> hmm, I'm getting stack traces in /var/log/syslog that point to an apparmor issue
[00:38] <stgraber> attaching using alsa and the alsa-bluez thing (.asoundrc) didn't quite work (I got sound but microphone was crappy) and using btsco just didn't work at all
[00:39] <slangasek> bluez-alsa doesn't work at all for me, I get errors trying to connect
[00:43] <stgraber> seems to attach correctly here with btsco but I can't make any sound to come through the headset
[00:43] <TheMuso> superm1: I am not keen on updating pulseaudio this close to release.
[00:50] <stgraber> doh, no my btsco seems to have crashed (process is I/O wait ...)
[00:51]  * calc hates LP downtime :\
[00:51] <calc> i forgot it was currently down and tried to commit
[00:53] <directhex> so, who likes the idea of a SRU for gnupg2 for pretty much every currently supported release? :)
[00:54] <ScottK> No.
[00:54] <ScottK> Why?
[00:56] <directhex> it may (i repeat, may, am trying to confirm) be the cause of an infuriating problem in *completely* unrelated software
[01:04] <slangasek> jdstrand: is there a way that I could bypass apparmor_socket_sendmsg in the kernel without having to rebuild the kernel?  I'm trying to rule out apparmor interaction as the source of some bluetooth problems
[01:17] <sbeattie> slangasek: I think you need to add "apparmor.enabled=0" to the kernel boot line
[01:17] <slangasek> sbeattie: thanks, testing
[01:17] <sbeattie> that IIRC should cause apparmor to not register its LSM hooks.
[01:29] <slangasek> gar
[01:29] <slangasek> asac: do you know if anyone, at any point, has ever *tested* the keyfile plugin to NM?  Because it's still uselessly broken for me
[02:24] <superm1> TheMuso, i didn't think so.  not a highly critical issue anyhow.  Jaunty will hopefully introduce nice bluetooth headset support then :)
[02:25] <superm1> stgraber, ah i don't have any headsets with mics.  i've only used stereo audio with mine (i have bluetooth headphones)
[02:26] <superm1> slangasek, that's too bad.  well nonetheless no changes over the bluez 3.x packages currently sitting in intrepid though right?
[02:33] <slangasek> superm1: not as far as I can tell, but then, it's not clear to me whether this is a solvable problem with one version over the other...
[02:35] <slangasek> superm1: I would obviously be a lot more enthusiastic about approving an exception if either version was doing useful things for me :/
[02:56] <stgraber> superm1: oh, you have stereo headsets using SCO and not A2DP ? (I thought A2DP was done for stereo headsets and supposed to provide a better quality for these)
[03:19] <slangasek> I didn't think SCO would even do stereo...?
[03:25] <stgraber> slangasek: if it does, I didn't know either :)
[03:33] <dx9s_home> hey what talk have you guys had about building kernels with 64GB support (PAE) in 32-bit side???
[03:34] <dx9s_home> and make it offical kernel (instead of people like me, DL the ubuntu patched kernel source and recompiling the kernel with usually one or two option changes)
[03:36] <dx9s_home> was wondering what compatibility issues might pop up if the generic kernel has PAE enabled and what CPU issues it would cause ? ...
[03:37] <persia> dx9s_home, PAE requires HW support.  I believe it is enabled in the -server kernel (although I may be mistaken)
[03:38] <dx9s_home> I don't think so.
[03:38] <dx9s_home> but I could be wrong too
[03:38] <dx9s_home> crap  sorry
[03:39] <persia> dx9s_home, This is being discussed at http://brainstorm.ubuntu.com/idea/1553/ : you may want to follow the discussion there.
[03:39] <dx9s_home> what I was going to say before I pressed the wrong button
[03:40] <dx9s_home> PAE is available on Pentium PRO and newer cpus.. what if it's enabled and by CHANCE a PAE enabled kernel runs on 486 .... would it crash?
[03:40] <stgraber> root@data:~# cat /boot/config-2.6.24-19-server | grep 64G
[03:40] <stgraber> CONFIG_HIGHMEM64G=y
[03:40] <stgraber> root@data:~# cat /boot/config-2.6.24-19-server | grep PAE
[03:40] <stgraber> CONFIG_X86_PAE=y
[03:40] <dx9s_home> thanks stgraber ... I wasn't sure...
[03:42] <dx9s_home> okay ... yes... "CPU too old" see that now
[03:44] <dx9s_home> but PAE is fairly common now ... (like I said... Pentium Pro and newer Intel CPU's and forget where on AMD side... I don't know about some of the fairly strange x86 CPU's... those might not have PAE yet)
[03:44] <slangasek> "Pentium Pro" - that's incorrect
[03:44] <dx9s_home> so for desktop... the only was is to go with custom compiled kernel each time
[03:44] <slangasek> there are lots of newer chips that don't support PAE
[03:45] <dx9s_home> true
[03:46] <slangasek> well, wikipedia says it's specifically the Pentium Ms that don't support it (heh, figures)
[03:47] <dx9s_home> for some.. the option to go 64-bit native bypasses the need for PAE.. but for those that still want 32-bit kernel (for various reasons, like wine or things like non-64-bit code... from commercial sources [closed source]) ...
[03:48] <stgraber> just install the server kernel, what's the problem with it ?
[03:48] <persia> dx9s_home, wine runs on Ubuntu amd64.  There's also support for some third-party 32-bit binaries (read the wiki entry for skype).  Alternately, install the -server kernel.
[03:48] <dx9s_home> not optimized with desktop in mind
[03:50] <slangasek> PAE is not a desktop technology
[03:50] <dx9s_home> well a while ago (on my first AMD64).. I did some benchmarks.. and running 32-bit code under a 64-bit kernel (dual mode).. you incur a performance penalty during context switches to-from 32<->64 -bit ... it hurts performance .. but it possible to run both at same time (I know)... I suspect that the new "VT" things helps some
[03:51] <dx9s_home> I know.. but PAE on "desktop" machines is common... (and desktop machines with 4G+ memory is more common)
[03:52] <ajmitch> doesn't PAE itself have some overhead?
[03:52] <dx9s_home> some
[03:53] <dx9s_home> it has memory limits where a "Segment/selector" of memory cannot point to more than 4G at a time
[03:53] <dx9s_home> aka cannot directly point to and "offset" more than 4G for any one memory pointer
[03:55] <persia> ajmitch, Indeed it does.
[03:56] <dx9s_home> so . basically I am not making any sense... and will continue to custom compile a PAE kernel for desktop support ... was hoping to convince talking about 32-bit kernels with PAE and optimized for desktop (or perhaps even RT)
[04:04] <persia> dx9s_home, You may want to look at linux-rt for the latter.
[04:04] <dx9s_home> still no PAE
[04:10] <superm1> stgraber, ah no, my headset does use a2dp, that's right
[04:10] <stgraber> superm1: ok, would have been stranged otherwise :) so SCO is really broken at the moment ...
[04:11] <superm1> stgraber, well i'll rummage around for my old headset for my mobile phone, that should be using sco
[04:14] <persia> I thought btsco was no longer encouraged for use, as a2dp has become sufficiently mature.
[04:14] <stgraber> yes, I've been testing with my Logitech HS05. It used to work just fine with .asoundrc in Hardy
[04:14] <stgraber> persia: as I understand it SCO and A2DP are two different bluetooth protocol and far from all devices offer both. (I don't know much about bluetooth though)
[04:16] <dx9s_home> stgraber, that sounds correct
[04:16] <johanbr> Yes, SCO and A2DP are different.
[04:17] <dx9s_home> I have a headphone that provides A2DP and the Hands Free Profile (Moto's S9) ... and that can cause some problems...
[04:18] <johanbr> There are a number of different ways of using SCO. The recommended one seems to be to use the bluez audio service, but last I tried it didn't work all that well.
[04:32] <superm1> stgraber, okay so I dug up my mono headset thing i used to use with my mobile.  sco is less attractive than a2dp indeed :(
[04:33] <stgraber> hehe :) but I tend to like to use SCO when I want a quick way of doing some skype/twinkle/...
[04:33] <stgraber> I like the idea of having the same device for my cell and my lappy
[04:33] <superm1> stgraber, well it would be nice if somehow this would segfault or something useful
[04:33] <superm1> 'ALSA lib pcm_bluetooth.c:1619:(bluetooth_init) BT_GETCAPABILITIES failed : Input/output error(5)' simply isn't useful to me
[04:35] <persia> superm1, At least it's a hint : what does the BT_GETCAPABILITIES macro do?  Perhaps the device in question doesn't support the target profile?
[04:36] <slangasek> superm1: it's bluetoothd itself that fails, so there's stuff in the logs; but I haven't been able to make any progress from there
[04:36] <slangasek> (and it still fails after disabling apparmor, so the apparmor stack trace is a red herring)
[04:36] <superm1> slangasek, my bluetoothd isn't crashing from this at least
[04:36] <superm1> slangasek, so you must be pulling yours down harder
[04:36] <slangasek> I didn't say it was crashing
[04:37] <slangasek> merely failing
[04:37] <slangasek> Oct  6 17:57:39 dario bluetoothd[6163]: link_key_request (sba=00:19:7D:E9:26:00, dba=00:1A:0E:02:B7:54)
[04:37] <slangasek> ^^ that's what I get
[04:37] <slangasek> Oct  6 17:57:49 dario bluetoothd[6163]: Unable to lock headset
[04:37] <slangasek> Oct  6 17:57:49 dario bluetoothd[6163]: config failed
[04:38] <slangasek> superm1: anyway, not to change the subject, but freeze exception granted :)
[04:38] <superm1> ah that's more interesting then.  i'll see if i'm seeing simliar
[04:38] <superm1> slangasek, okay great.  i'll get things in order to get things uploaded tomorrow
[04:41] <TheMuso> superm1: Please send me the alsa-lib bits. I may have to do another alsa-lib upload, so its easier if I do it all at once.
[04:41] <TheMuso> superm1: if thats ok with you.
[04:41] <superm1> TheMuso, there should be a debdiff on that bug
[04:41] <superm1> TheMuso, if you want to extract the patch from there
[04:41] <TheMuso> superm1: oh, ok. I'll have a look.
[04:48] <superm1> stgraber, interesting, i cleared out /var/lib/bluetooth and repaired.  this time it does register as SCO for me: http://paste.ubuntu.com/54863/
[04:48] <superm1> still doesn't play properly, but at least registering the right service this time
[05:07] <savvas> just a quick question, is it normal that gnome is 2.24 and gnome-system-tools is 2.22 in intrepid?
[05:09] <lukehasnoname> so is it weird to anyone that when I rsync from a backup to my /home/luke directory, it breaks something to where I can't start any graphical apps? MTI-COOKIE or something error
[05:11] <persia> lukehasnoname, You probably copied your Xauthority file.
[05:11] <wgrant> lukehasnoname: That's not weird if you erase or overwrite .Xauthority, no.
[05:11] <lukehasnoname> hmmm <_<
[05:12] <lukehasnoname> *adds an --exclude*
[05:14] <lukehasnoname> OK, the exclude option is terribly documented
[05:14] <lukehasnoname> rsync master@192.168.10.100:/home/backup/ /home/luke/ --exclude ~/.wine/ --exclude ~/.Xauthority
[05:14] <lukehasnoname> rsync master@192.168.10.100: /home/backup/ /home/luke/ --exclude ~/.wine/ --exclude ~/.Xauthority
[05:14] <lukehasnoname> It tells me it's skipping . and doesn't do anythin
[05:15] <StevenK> You probably want rsync -a
[05:15] <lukehasnoname> aw hell, yes. I'm tired.
[05:15] <lukehasnoname> I usually use -avh
[05:15] <StevenK> -avh is good
[05:16] <dx9s_home> what about removing and recreating the .Xauthority ? or am I missing something (not entirely impossible)
[05:16] <lukehasnoname> if I'm doing it over anything more than my local router -avzhe ssh
[05:16] <lukehasnoname> dx9s_home: possible
[05:36] <erast> NCommander: nexenta-on package which includes full nexenta kernel sources uploaded into hardy repository now, its very initial, so don't expect much... the work will continue
[05:40] <ScottK-laptop> NCommander: Any suggestions on http://launchpadlibrarian.net/18275920/buildlog_ubuntu-intrepid-sparc.kdebase-workspace_4:4.1.2-0ubuntu5_FAILEDTOBUILD.txt.gz
[05:41] <ScottK-laptop> NCommander: I'm heading to bed, but I'll read the scrollback in ~6 hours.
[06:23] <pitti> Good morning
[06:26] <mvo> hey pitti!
[06:27] <StevenK> Morning pitti!
[06:28] <ion_> Hi
[06:28]  * pitti hugs the lot
[06:28] <pitti> mvo: hey Mr. Foundations Team :)
[06:29] <StevenK> pitti: Is the NBS list getting updated since the drescher -> cocoplum move?
[06:29] <pitti> StevenK: oh, good point; apparently not
[06:29]  * pitti pokes
[06:35] <ion_> Anyone feel like sponsoring http://launchpadlibrarian.net/18250664/iconv.debdiff to fix LP #278195? Thanks.
[06:47]  * cjwatson puts his topic changes from last night back
[07:07] <dholbach> pitti: somebody told me that xvfb was unhappy in intrepid - is there a bug filed for it?
[07:08] <pitti> dholbach: I don't know details, I'm afraid
[07:08] <dholbach> OK, thanks
[07:09]  * StevenK notices the foo directory on NBS and looks at pitti 
[07:09] <pitti> StevenK: that was my rsync test
[07:09] <StevenK> Heh
[07:14] <StevenK> dholbach: I've heard that, and have a rebuild pending due to it. Anything you find out I'd be happy to know
[07:14] <dholbach> StevenK: alright
[08:22] <NCommander> pitti, you around?
[08:23] <stefanlsd> Does anyone have an idea why my computer insist's of cpu-stepping to minimum (i'm on power).  cpufreq-selector -g performance fixes it, but need to run it manually everytime. running intrepid on a dell vostro 1500
[08:44] <RAOF> mvo: It seems there's been an compiz upload that doesn't appear in lp:~compiz/ubuntu.  Would you like me to roll that in to bzr?
[08:45] <mvo> RAOF: let me check, maybe just a forgoten push?
[08:45] <seb128> hey mvo!
[08:45] <mvo> RAOF: hm, no. so please add it
[08:45] <mvo> hey seb128
[08:45] <RAOF> Once that's done, I can add an LP bug number to the XDG_CONFIG_DIRS fix; people are hitting it.
[08:46] <mvo> RAOF: ok, cool
[08:46] <mvo> RAOF: we should probably branch the tree, I had hoped to get 0.7.8 FFE accepted and the current bzr is based on this
[08:46] <seb128> mvo: it didn't get accepted?
[08:47] <mvo> seb128: oh, sorry. I'm 18h late, I was granted now
[08:47] <mvo> ^--- RAOF (bug 273923)
[08:47]  * mvo does a little dance
[08:47] <seb128> mvo: ah ok, didn't know about that, I was just being curious ;-)
[08:48] <RAOF> mvo: Yeah, I noticed that FFe grant :)
[08:48] <RAOF> But, not having core-dev powers... ;)
[08:48] <mvo> seb128: took a bit (because of beta freeze in between etc)
[08:48] <seb128> mvo: if you upload this one and doesn't fix my keyboard focus issue on workspace switching before intrepid I'll find you ;-)
[08:48]  * seb128 hugs mvo
[08:49] <mvo> RAOF: right, just let me know when you are finished with bzr and I do the final upload :)
[08:49] <mvo> seb128: *cough*
[08:51] <mvo> seb128: I can't remember if we talked about it, but IIRC you reported a bug about it, right?
[08:53] <seb128> mvo: I don't think I reported a bug but you said you were getting the issue when being quicker than the animation display
[08:53] <mvo> seb128: yes, but not always, I could reproduce it sometimes, but not reliable
[08:53] <RAOF> mvo: You might want to clarify what 029_compiz_manager_decoration.patch does; I'm pretty sure it doesn't blacklist an Intel driver, which is what the changelog entry says :)
[08:53] <seb128> you need to be quicker ;-)
[08:54] <mvo> heh :)
[08:54] <seb128> mvo: btw do you know about totem crashing on intrepid intel card when using compiz?
[08:54] <mvo> seb128: no, I have a machine that I could test that with though
[08:54] <mvo> seb128: its still running hardy, but I guess its a good time to test this anyway
[08:54] <RAOF> mvo: I'm not _entirely_ sure what to do here; should I retrospectively alter the changelog, or add a new "whoops" entry to the current log?
[08:55] <seb128> mvo: The error was 'BadAlloc (insufficient resources for operation)'.
[08:56] <mvo> RAOF: 028_ has "+T="$T 8086:2e02 " # Intel Eaglelake" for me
[08:56] <mvo> seb128: hm, sounds like something with exa again :/
[08:56] <RAOF> mvo: Yes, but the changelog entry _after_ that talks about 29_compiz_manager
[08:57] <seb128> mvo: should I try XAA?
[08:57] <RAOF> mvo: Which is removing the starting of the decorator from the script (It's the 0ubuntu12 log entry)
[08:58] <mvo> RAOF: hm, I guess retro correcting is ok in this case (if its a obvious typo from me, maybe with a changelog entry about the changelog :)
[08:58] <mvo> seb128: do you get the error yourself?
[08:58] <seb128> mvo: yes
[08:58] <mvo> seb128: aha, cool. please put Xorg.0.log somewhere, I would like to have a look
[09:00] <seb128> mvo: http://people.ubuntu.com/~seb128/Xorg.0.log
[09:02] <pitti> Hi NCommander
[09:02] <NCommander> pitti, think you can tackle a usplash question?
[09:03] <NCommander> pitti, I'm trying to figure out if there has been any recent changes in usplash to make it work while a machine is coming out of hibernation. I somehow got roped into looking at this bug in Debian :-)
[09:03] <pitti> NCommander: there haven't been any changes to usplash recently, no
[09:03] <NCommander> Darn. I was hoping it was something non-Debian specific
[09:03]  * NCommander pulls out his hacking toolbelt and dives in to fix it
[09:03] <pitti> NCommander: there might have been some in sysvutils in Debian, to integreate *splash more tightly, but we didn't merge for a while
[09:04] <NCommander> I think its an issue with initramfs on Debian
[09:04] <mvo> seb128: "  * Disable 01_fix_compiz_video.diff, since it appears to be obsolete
[09:04] <mvo>     by now.
[09:04] <mvo>  ^--- from the xserver-xorg-video-intel changelog. looks like its not quite obsolete by now ;)
[09:04] <NCommander> Since if you kill the usplash commands there, it seemingly resolves the hang
[09:04] <RAOF> mvo: Compiz pushed; please check there's no glaring problems :)
[09:04] <seb128> mvo: bad xorg guys!
[09:04] <NCommander> pitti, http://img262.imageshack.us/my.php?image=screenshotqi1.png - is that a bug against libpam0g, debian-installer, or something else :-)
[09:05] <mvo> thanks RAOF!
[09:06] <mvo> seb128: hm, is that your machine with the i965?
[09:06] <seb128> mvo: yes
[09:06] <pitti> NCommander: what does that have to do with usplash?
[09:06]  * mvo scratches his head
[09:06] <pitti> NCommander: and what's the bug there? that's a legitimate debconf question?
[09:06] <NCommander> pitti, is it susposed to prompt for restarting services during an inital installation?
[09:07] <NCommander> pitti, oh, that wasn't with usplash, just something that popped up while we were talking
[09:07] <pitti> NCommander: oh; no, of course not
[09:07] <StevenK> NCommander: My machine does usplash during resume
[09:07] <NCommander> StevenK, Debian?
[09:07] <seb128> mvo: I can try rebuild the intel driver using this patch if you want
[09:07] <StevenK> NCommander: Of course not
[09:07]  * NCommander falls over
[09:07] <mvo> seb128: hm, that patch was for older cards, the i965 should not make a difference, but you could still try it (should be build quickly)
[09:07] <StevenK> NCommander: Who's my employer, again? :-P
[09:07] <NCommander> Right, stupid question.
[09:07] <mvo> seb128: the patch is still in the series file
[09:07] <seb128> mvo: ok will do that
[09:08] <mvo> seb128: please also enable 11_textured_video
[09:08] <seb128> mvo: both in the same run?
[09:09] <mvo> seb128: yes (quicker this way)
[09:20] <mvo> RAOF: I updated the changelog again and I think its now good to go
[09:28] <tseliot> pitti: can you merge from my jockey-generic branch?
[09:29] <RAOF> mvo: Hah!  I obviously need to aptutude update!
[09:29] <seb128> re
[09:29] <pitti> tseliot: hm, didn't you just introduce the Disable dri2 thing because it breaks something else?
[09:29] <mvo> RAOF: heh :)
[09:30] <seb128> mvo: not good, when stating playing a video the screen turn to whole gray and I had to reboot
[09:31] <tseliot> pitti: dri2 was removed by the current Xorg and it breaks nvidia-settings and nvidia-xconfig which share the same parser
[09:31] <pitti> ah, so we don't need it any more
[09:31] <mvo> seb128: *ick*
[09:31] <pitti> tseliot: removeOption() will not error out if the option doesn't exist?
[09:32] <mvo> seb128: that is nasty
[09:32] <seb128> pitti: is video playing working under compiz on your laptop?
[09:32] <pitti> seb128: trying
[09:32] <tseliot> pitti: no, it won't
[09:33] <pitti> seb128: yes, both windowed and fullscreen
[09:33] <seb128> pitti: hum, ok
[09:33] <pitti> seb128: I didn't dist-upgrade today yet, though
[09:33]  * pitti does now
[09:33] <seb128> me neither
[09:33] <seb128> it's broken for some weeks
[09:33] <pitti> Version: 1:0.7.7+git20080807-0ubuntu12
[09:34] <pitti> oh, I had noticed that
[09:34] <pitti> "I would have", I mean
[09:34] <pitti> indeed there's a new compiz today
[09:34] <pitti> I was about to reboot to the hardy kernel anyway, I'll test it alongside
[09:36] <mvo> pitti: you have a i945, right? not a i965?
[09:36] <pitti> mvo: right
[09:36] <mvo> seb128:  it may only affect i965 (but that is useful information for sure)
[09:39] <pitti> seb128: oh, btw, I'm running the slightly older -intel driver (ubuntu4), since ubuntu6 is broken for me
[09:39]  * pitti will file a report soon, he just discussed it with tjaalton so far
[09:42] <seb128> I'm wondering if anybody looks at the intel bugs
[09:42] <liw> mvo, welcome back; system-cleaner 1.10 was uploaded yesterday :)
[09:43] <seb128> https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs sorted by new bugs, most of the first page looks like it has not been triaged
[09:44] <mvo> liw: sounds like I'm right back in time!
[09:47] <rom1v> hi
[09:48] <rom1v> is there a chance that this fix would be included in intrepid : https://bugs.launchpad.net/ubuntu/+bug/215876 ?
[09:50] <sivang> liw: hi
[09:50] <sivang> liw: you develop system cleaner ?
[09:50] <liw> sivang, yes
[09:51] <Hobbsee> mvo: perhaps you might add rom1v's fix to your upload
[09:52] <mvo> Hobbsee: I'm collecting changes currently. what bugnumber is this one?
[09:52] <Hobbsee> [19:48] <rom1v> is there a chance that this fix would be included in intrepid : https://bugs.launchpad.net/ubuntu/+bug/215876 ?
[09:52] <mvo> Hobbsee: I have anohter one for firefox that needs to be added as well
[09:52] <mvo> thanks Hobbsee
[09:52] <Hobbsee> mvo: you're welcom
[09:52] <Hobbsee> e
[09:53] <mvo> rom1v: hello! thanks for your patch. I think this came up before and I was wondering why this is not added to the Xsession.d from the nvidia-settings package?
[09:53] <sivang> liw: nice, how do you know which kernel to remove and which one to leave ?
[09:54] <rom1v> mvo, do you think it is better to add it to the Xsession.d ?
[09:54] <liw> sivan, system-cleaner does not special case kernel packages, so it removes those kernels that are no longer available in the archive
[09:54] <rom1v> maybe, I just make a patch which works, but if you think it should be on another place, feel free :)
[09:54] <mvo> rom1v: I don't know a great deal about nvidia-settings, but it sounds like this would be useful for metacity users as well (or people running stuff like afterstep etc)
[09:55] <rom1v> I think it's only for composite wm
[09:55] <rom1v> but not sure
[09:55] <mvo> rom1v: aha, thanks. I have a look, thanks
[09:55] <sivang> liw: ah I see, thanks
[09:57] <sivang> liw: I once created a spec, https://wiki.ubuntu.com/SystemCleanUpTool that's why I'm happy to see that there's already a tool uploaded :)
[09:57] <rom1v> mvo: when you have some more details about that, could you comment the bug ?
[10:01] <james_w> is anyone else noticing evolution sending two copies of emails?
[10:01] <james_w> I only have a suspicion so far...
[10:02] <pitti> james_w: one for the recipient, one for the NSA?
[10:02] <james_w> heh :-)
[10:05] <liw> sivang, cool :)
[10:11]  * sivang notices there's now a last-good-boot mechanism in grub, easing solving the left over kernels problem
[10:11] <liw> sivang, yup
[10:18] <sivang> liw: is there a tool already to remove old kernels ? or to notify when there's a last-good-boot ?
[10:18] <persia> superm1, stgraber: Re: SCO connectivity: http://marc.info/?l=linux-bluetooth&m=122309203608203&w=2 may be interesting : supposed to be resolved in 4.11
[10:19] <liw> sivang, as far as I understand, the new approach to kernel packaging will take care of old kernels in the future, and system-cleaner's orphaned package removal will take care of currently obsolete kernel packages
[10:20] <rom1v> mvo: do you think removing the code "# special case handling for dapper upgrades (this runs only once after the upgrade)" in /usr/bin/gnome-wm has a risk?
[10:20] <sivang> liw: but can a situation arise where a user boots a kernel from an orphaned kernel package ?
[10:21] <sivang> liw: since then removing obsolete kernel packages might do harm
[10:21] <liw> sivang, that can happen with any package that system-clenaer thinks is cruft; that's why the user needs to confirm the list
[10:22] <mvo> rom1v: no, that should be fine now
[10:22] <sivang> liw: right
[10:23] <sivang> liw: I'm thinking along the lines of huristics similar to the popularity contest, but for actual usage of packages.
[10:23] <sivang> liw: (not for kernel packages obviously)
[10:23] <liw> sivang, that might be interesting
[10:23] <cjwatson> that's excessive, system-cleaner should just check the running kernel version (if it doesn't already)
[10:23] <rom1v> ok, could you take care of it (I'm just a simple user)?
[10:23] <cjwatson> I believe apt-get autoremove already checks that
[10:24] <sivang> cjwatson: was that addressed to us ? :)
[10:24] <cjwatson> yes
[10:25] <mvo> update-manager does for sure
[10:25] <sivang> how is packages usage measured?
[10:25] <sivang> not installation, usage.
[10:26] <sivang> btw, big hi(s) mvo , cjwatson
[10:26] <mvo> hey sivang :)
[10:27] <sivang> cjwatson: apt-get autoremove checks the running kernel version?
[10:29] <liw> is there still a chance that a Main Inclusion Request for system-cleaner could be approved for intrepid?
[10:30] <lool> liw: I don't see it in https://bugs.edge.launchpad.net/~ubuntu-mir
[10:30] <lool> liw: Is ubuntu-mir subscribed?
[10:31] <liw> lool, I haven't filed one yet, I'm wanting to know if MIRs have any chance of being approved for intrepid or if I'd be wasting everyone's time by writing one (but perhaps asking about that is wasting time)
[10:31] <lool> You're going to have to write anyway, don't you?  :)
[10:32] <liw> true, I guess :)
[10:32]  * liw goes write one
[10:35] <cjwatson> sivang: that does indeed appear to be what I said, although it's just a memory and I haven't yet found evidence for it
[10:36] <cjwatson> so I may be mistaken
[10:36] <sivang> cjwatson: okay
[10:39] <pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ is current now
[10:40] <StevenK> Woot!
[10:44] <StevenK> Ugh, it's even bigger now
[10:45] <persia> Most of it is without rdepends though...
[10:48] <StevenK> Most of it is are two kernels, which you can't rely on rdepends for.
[10:50] <Tonio_> hi !
[10:50] <pitti> StevenK: -4 can be killed, and -5 as soon as d-i moves to -6
[10:50] <StevenK> What about the ports kernel?
[10:50] <StevenK> Has d-i moved to 2.6.25-2?
[10:50] <StevenK> cjwatson: ^
[10:52] <StevenK> seb128: gimp is in main, and libgegl-0.0-dev is in universe
[10:53] <seb128> StevenK: you are stating to obvious ;-)
[10:53] <StevenK> Heh
[10:53] <seb128> StevenK: didrocks is working on writting the required mirs, the gegl one is written, still need the babl one
[10:53] <StevenK> What is it with library names that sound like random letters
[10:54] <didrocks> StevenK: gegl is the new "engine" of gimp
[10:54] <persia> libsdfj23c02a ?
[10:54] <StevenK> didrocks: I know
[10:54] <didrocks> StevenK: sorry, I was thinking you were speaking about them :-)
[10:55] <cjwatson> StevenK: yes
[10:55] <cjwatson>   * Move ports architectures to 2.6.25-2 kernels.
[10:55] <cjwatson>   * Move mainline architectures to 2.6.27-5 kernels.
[10:55] <StevenK> cjwatson: Excellent, thanks.
[10:55] <StevenK> pitti: Okay, binning -4 and -1 kernels
[10:55] <pitti> (NB that the kernel is at -6 already)
[10:55] <cjwatson> they've released -6 ? sigh
[10:55] <StevenK> Hah
[10:56] <StevenK> -meta is still -5
[10:56] <pitti> The "ABI spreading like Tribbles" release :)
[10:56] <StevenK> Hmmm. LRM is still -5, too
[10:59] <cjwatson> I'll commit the d-i update for -6, but won't upload it until more kernel bits are in
[11:00] <cjwatson> it can't be NBS-removed until l-r-m and -meta are uploaded anyway
[11:00] <StevenK> Right.
[11:01] <Riddell> pitti: do you know when language packs will be uploaded?
[11:01]  * liw says "whee" in a small voice, having filed his first MIR
[11:01] <pitti> Riddell: ArneGoetje is coordinating that now; "soon"
[11:02] <Riddell> ArneGoetje: very soon would be nice, I have no idea if KDE translations are working
[11:03] <StevenK> Chug chug chug
[11:04]  * cjwatson deals with 2.6.27-6 binaries in new
[11:05] <StevenK> Which means LRM is probably in DEPWAIT
[11:06] <StevenK> seb128: Are gimp-{gnomevfs,libcurl,python} really NBS or are they a side affect of gimp being in DEPWAIT?
[11:07] <cjwatson> yes
[11:16] <BenC> cjwatson: is there a linux-meta uploaded already?
[11:16] <BenC> cjwatson: I just did an upload for -5 to add -virtual, I don't want it getting lost
[11:17] <StevenK> BenC: You uploaded a -5 kernel?
[11:18] <BenC> No, linux-meta
[11:18] <ion_> benc: I wonder how to debug LP #278188?
[11:18] <cjwatson> BenC: well, you can read https://launchpad.net/ubuntu/+source/linux-meta as well as I :-)
[11:19] <cjwatson> BenC: somebody'll need to do an ABI bump following that of course, but I don't see one yet
[11:19] <BenC> cjwatson: for some reason I was thinking it would be kept in NEW, but that doesn't happen to linux-meta
[11:19] <cjwatson> indeed
[11:20] <BenC> cjwatson: thanks, I follow up with a -6 ABI bump later
[11:20] <cjwatson> you should be able to see that on https://launchpad.net/ubuntu/intrepid/+queue FWIW
[11:20] <cjwatson> linux-meta *binaries* are in NEW mind you ...
[11:20] <StevenK> Due to -virtual?
[11:21] <cjwatson> yes. processed now
[11:22] <ogra> asac, hmm, with MN managing static /e/n/i devices we need to make sure dhcp3-sever (and probably dnsmasq) start after NM
[11:22] <ogra> *NM
[11:22] <ogra> at least dhcpd reiles on having an interface available on startup
[11:23] <StevenK> Come on cocoplum, go faster.
[11:23] <ogra> i think atm the debian/rules use default for dh_installinit ... which results in S25 ... NM has S30
[11:24] <ogra> (debian/rules of dhcpd)
[11:27] <RAOF> So... should /usr/sbin/NetworkManager again decide to consume 1.4GB RSS, what can I do to debug?
[11:27] <Keybuk> RAOF: do you know what RSS means?
[11:28] <RAOF> I may be using the wrong term.
[11:28] <RAOF> That's the "Resident" column.
[11:29] <Keybuk> are you sure it's not 1.4 MB? :-)
[11:29] <RAOF> Virtual was something like 2.4GB.
[11:29] <Keybuk> use massif to identify the memory usage pattern
[11:29] <RAOF> Yes.  Because loadav was 15, and it didn't manage to switch to a VT, even after 3 minutes of frantic thrashing.
[11:30] <asac> ogra: dhcp-server?
[11:30] <asac> ogra: you say now that NM supports system configurations we should see if we can enable any server apps properly?
[11:30] <asac> hmm
[11:32] <StevenK> pitti: A *whole* bunch of stuff flushed out
[11:32] <ogra> asac, no, i say that i currently get a lot of complaints from ltsp users that their dhcpd doesnt start :P
[11:33] <ogra> asac, dhcpd has a builtin check ... it looks for a static device with an ip and compares this IP to its config, if a subnet declaration is found for one of the running devices it starts up ... thats our default setup
[11:33] <RAOF> Aha.  Massif is in valgrind.
[11:34] <ogra> asac, if the device isnt up, which is the case atm, dhcpd just fails to start and doesnt serve anything on such a device
[11:34] <ogra> asac, even though you plan to switch off managed mode, it will still be possible to turn it on, if people do so, dhcpd needs to start after NM
[11:35] <ogra> asac, i'm not sure how critical a static IP is for other services, but dhcpd wont work without one
[11:35] <ogra> so its initscrip needs to start after NM
[11:36] <rom1v> mvo: you're right, https://bugs.launchpad.net/ubuntu/+bug/215876 I think it would be better to add this script in Xsession.d (last comment)
[11:38] <pitti> StevenK: \o/
[11:38] <StevenK> pitti: I just counted. 200 binaries
[11:39] <asac> ogra: why isnt the device up?
[11:39] <asac> ogra: ifup/ifdown should still bring it up
[11:39] <asac> i havent touched that yet
[11:39] <asac> ogra: i think the problem might have been that NM did down and up the interfaces
[11:39] <asac> ogra: but that should be fixed since yesterday. you want "unmanaged" mode
[11:41] <bond`> pitti: can you have a look at bug #276472?
[11:42] <asac> ogra: does that match what you want ?
[11:42] <ogra> asac, right, but users that installed from an alpha have it managed from NM ...
[11:42] <asac> ogra: yeah. anyway. now it shouldnt happen anymore, which doesnt mean that we shouldnt move dhcp-server to be started after NM (if its possible)
[11:42] <ogra> asac, also, it is possible that you switch to managed if you want ... we should make sure it works in that case
[11:43] <asac> ogra: would be nice to have dhcp working without ifupdown
[11:43] <liw> users installing from alphas have a lot of things they need to tweak... but perhaps I can entice someone to write a system-cleaner plugin to clean that up? ;-)
[11:44] <ogra> asac, you can do that by forcing dhcpd it a specific interface in /etc/defaults, but that omits the selftest and i dont think we want to tinker with defaults
[11:44] <ogra> just make sure it doesnt start if no interface is up
[11:44] <ogra> for which you give a possibility in the current setup
[11:44] <ogra> its not that hard to move dhcpd's init to S31
[11:45] <ogra> and we might decide to switch to managed mde in jaunty ... so it would save us one transition ...
[11:45] <ogra> *mode
[11:50] <asac_> 12:44 < ogra> just make sure it doesnt start if no interface is up
[11:50] <asac_> 12:48 < asac> ogra: so would there be a problem to start dhcp-server later?
[11:50] <asac_> 12:48 < asac> ogra: NM cannot be started before dbus is up. thats for sure
[11:50] <asac_> 12:49 < asac> ogra: we could then put some love in the NM init script ... so it waits for a while giving NM a chance to connect
[11:50]  * pitti already sees Keybuk jump at asac "don't sleep in init scripts" :)
[11:51] <asac> ogra: so would there be a problem to start dhcp-server later?
[11:51] <asac> ogra: NM cannot be started before dbus is up. thats for sure
[11:51] <asac> ogra: we could then put some love in the NM init script ... so it waits for a while giving NM a chance to connect
[11:51] <ogra> asac, i dont think there would be a prob starting it later
[11:51] <ogra> the prob atm is that it will never start if you switch to managed mode
[11:52] <ogra> and its trivial to solve by moving the initscript to S31
[11:52] <asac> ogra: coudlnt dhcp server be told to retry through if-up.d scripts?
[11:53] <ogra> no ide, i guess rewriting its selftest would be a quite big patch
[11:53] <ogra> which is what i think this would involve
[11:53] <asac> ogra: ;) ... we could just run dhcp-server start in ifup.d and dhcp-server stop in ifdown.d
[11:54] <ogra> well, how would that work for people not having NM ?
[11:54] <ogra> ifup would care i guess ?
[11:56] <asac> ogra: as of now, would dhcp-server break if you run ifdown eth0; wait a bit; ifup eth0 ?
[11:56] <asac> ogra: or is it just important that the interface is up when dhcp-server initially gets started?
[11:56] <ogra> if its initscript tries to start inbetween it would break
[11:56] <ogra> it expects a static iface with IP
[11:57] <ogra> right
[11:57] <ogra> the latter
[11:57] <asac> ogra: ok, but its just a startup check?
[11:57] <asac> ogra: so yes, moving dhcp-server back sounds reasonable
[11:57] <asac> ogra: but:
[11:57] <asac> we either have to make NM init script wait until its online (or some time has passed to give up)
[11:57] <asac> _or_
[11:57] <asac> we could make the dhcp-server script do that
[11:58] <asac> (e.g. wait a bit in case the interface isnt up yet)
[11:58] <ogra> what does NM do ? if its static it shouldnt wait for anything
[11:58] <asac> ogra: it starts a daemon. it should connect quite snappy, but still its a race :)
[11:59] <asac> and races always come with a risk to be lost :)
[11:59] <ogra> indeed
[11:59] <asac> ogra: so better wait for 5 or 10 seconds, testing whether nm-online is true
[12:00] <asac> ogra: /usr/bin/nm-tool  | grep State:\ connected
[12:00] <ogra> in a while loop ?
[12:01] <asac> ogra: for the moment that would be safe. for more sophistication i would need to ship the "nm-online" tool
[12:01] <asac> which does the looping for a certain timeout for oyu
[12:01] <ogra> and wrpped with a grep for managed=true
[12:03] <asac> ogra: if you want to do that, then yes.
[12:03] <ogra> i'll assemble a mail with that and follow up on your RFC
[12:03] <asac> ogra: my ifup -a patch would spit out a warning if its "managed"
[12:03] <asac> $ ifup -a
[12:03] <asac> WARNING: ifup -a is disabled in favour of NetworkManager. Set ifupdown:managed=false in /etc/NetworkManager/nm-system-settings.conf.
[12:04] <ogra> right, but people might want managed mode for whatever reason ...
[12:04] <ogra> so to make sure we dont break the world the above seems a sane solution
[12:04] <asac> ogra: yes. what i am trying to say is that you dont need to parse the conf on your own
[12:05] <asac> you could use ifup to do that (where we have to include a iniparser anyway)
[12:06] <asac> ogra: but well. in general we agree i think. its just a matter on how to do it
[12:06] <ogra> well, reply to the mail once i sent it :) i guess its safer to hold the rest of the discussion on the ML
[12:06] <asac> "details" .-Ü
[12:06] <ogra> yeah
[12:06] <pitti> asac: your smiley needs some urgent medical treatment
[12:07] <ion_> ☺
[12:09] <ogra> pitti, nah, its a germanized smiley, it uses umlauts :)
[12:09] <asac> pitti: i am rambo :)
[12:10] <ogra> asac, a rambo pirate eh ? looks like you use a oatch over the left eye
[12:10] <ogra> *patch
[12:10] <asac> hehe ;)
[12:19] <asac> pitti: any preferred way i should set the status/milestone/importance for 3G hal-info tweaks?
[12:19] <pitti> asac: for which kind of bugs?
[12:20] <asac> pitti: missing product id
[12:20] <pitti> those you'd like to get committed upstream and uploaded to intrepid?
[12:20] <asac> pitti: typical bug would be #279182
[12:20] <asac> pitti: not sure about upstream. we surely want them in intrepid to support as many phones/devices as possible
[12:20] <pitti> asac: generally, if you want me to do that, assign it to me; I don't use importance a lot, and milestone is kind of useless now, too, since there's just one left :)
[12:20] <asac> pitti: you committed all upstream, so i guess you want to send them upstream
[12:20] <StevenK> Ahh. pitti langpack'd the i386 builders again.
[12:21] <pitti> asac: yep
[12:21] <asac> pitti: ok. i will assign those that get filed through me then.
[12:21] <pitti> asac: so, subscribing me is fine, or just apply proper patches to hal-info and upload, which I can just take and apply upstream later on
[12:21] <asac> oh
[12:22] <asac> pitti: ok.
[12:22] <cjwatson> Riddell: has KDE stopped honouring /etc/default/locale? bug 278634
[12:24] <Riddell> cjwatson: I don't know, until we get language packs uploaded that actually contain some translations I can't really test properly
[12:25] <cjwatson> Riddell: it's easy to see in System Settings, even without language packs
[12:45] <liw> lool, heh, you're on a rampage; thanks for all the bugs
[12:56] <Riddell> mvo, ArneGoetje: where does incomplete-language-support-foo get copied to /var/lib/update-notifier/user.d/ ?
[13:47] <siretart> seb128: re bug #279398, didn't you say at some point that you wanted to switch gstreamer0.10-ffmpeg to use the internal ffmpeg copy?
[13:47] <seb128> siretart: right, but I decided against it, I'm already too busy so I'll just wait for next cycle and the update ffmpeg version
[13:53] <siretart> seb128: okay. I reassigned that bug to gstreamer0.10-ffmpeg.
[13:54] <seb128> siretart: why?
[13:54] <seb128> siretart: gstreamer0.10-ffmpeg uses the system ffmpeg no?
[13:54] <seb128> siretart: and libavcodec51: /usr/lib/i686/cmov/libavcodec.so.51 is a libavcodec51 library
[13:55] <siretart> seb128: since you are the one who reassigns most of the bugs to ffmpeg-debian; unless I'm given an example file to reproduce, I cannot really do much about it, since I need to reproduce it
[13:55] <siretart> seb128: see bugtrail. it seems to me that gstreamer0.10-ffmpeg is passing garbage to libavcodec. garbage in, segfault out
[13:57] <siretart> seb128: that's another point: can we please disable apport reports from natilus thumbnailer?
[13:57] <wgrant> Or fix the bugs...
[13:57] <seb128> siretart: why? we don't get many of those do we?
[13:58] <siretart> seb128: most of the crashes are of course somehow valid. however we need an example so that we can forward them to upstream
[13:58] <siretart> seb128: I have the feeling that most of the reports in ffmpeg where of them. I triaged all of them for now
[13:59] <ScottK-laptop> mvo: I have an KDE upgradability question that might need solving in update-manager if you have a moment to discuss.
[13:59] <siretart> seb128: but since in almost all cases I had to reject the bug, I think we shouldn't bug users in the first place to submit them to lanchpad
[13:59] <mvo> Riddell: IIRC the installer copies that file if it can not get networking (not 100% sure though)
[13:59] <seb128> siretart: well, that's true for any crash bug, usually without steps to reproduce a one time bug is not easy to work on
[13:59] <mvo> ScottK-laptop: sure
[14:00] <seb128> siretart: that's not a good reason to reject those though
[14:00] <seb128> siretart: do you have a stock reply for ffmpeg bugs which points to instruction that we could use when reassigning those? so we would reassigning bugs as incomplete and it's easy to clean those up when there is no reply
[14:01] <ScottK-laptop> mvo: We have cases were a package has move from using kde4libs to kde5libs, and so the -dev package now depends on kde5libs-dev, but it's not co-installable with kde4libs-dev (which is still around and valid since we have to support some KDE 3 stuff still).
[14:01] <wtgee> Hola...anybody else reported that the timer in sudoku is not working?  I didn't see a bug.
[14:02] <ScottK-laptop> mvo: So if someone has, for example, libkdegames-dev installed and upgrades from Hardy, then upgrade will fail because libkdegames-dev in Intrepid needs kde5libs-dev and that can't be installed due to the presence of kde4libs-dev
[14:03] <ScottK-laptop> mvo: We can't use replaces because it doesn't actuall.
[14:03] <mvo> ScottK-laptop: right, you need conflicts in this case it seem. and they clash on the filename namespace?
[14:03] <ScottK-laptop> mvo: So I was considering some kind of rule for upgrading kde -dev packages that would allow the KDE libs -dev package to be force upgraded.
[14:03] <ScottK-laptop> Yes.
[14:03] <mvo> ScottK-laptop: that sound not optimal for reasons that go beyond upgrading :)
[14:04] <mvo> ScottK-laptop: I can add code to update-manager that force -dev upgrades for certain packages
[14:04] <ScottK-laptop> Well I didn't go back and consider redesigning the packaging at this point.
[14:04] <mvo> ScottK-laptop: what happens currently? are they held back (not upgraded) or does the upgrader complain that it can not calculate the upgrade?
[14:04] <ScottK-laptop> Held back and not upgraded
[14:05]  * mvo nods
[14:05] <mvo> ScottK-laptop: ok, if you want such a rule, its trivial for me to add it, especially if there is a pattern or a list of package names
[14:05] <ScottK-laptop> So it'd be if kde5libs-dev is wanted and kde4libs-dev is installed, go ahead and force it.
[14:06] <ScottK-laptop> mvo: Does that work or do you need a list of the packages that would depend on it?
[14:06] <kwwii> seb128: so nobody responded about the themes package yet...I am sure we will hear people when we actually split them out, but if nobody has anything to say about it in advance it must not be soo bad
[14:06] <seb128> kwwii: right
[14:07]  * Riddell notes it's kdelibs5-dev and kdelibs4-dev
[14:07] <ScottK-laptop> Riddell: Thanks.  I swear I was going to double check that.
[14:07] <mvo> ScottK-laptop: that should be fine, the list would be nice, but I can generate it here too. I will add the packages to my (kubuntu) test system to ensure that the rule work etc :)
[14:07] <ScottK-laptop> mvo: Thanks.  Would you like that in the form of a bug?
[14:08] <seb128> kwwii: I'll do the change tomorrow, I just wanted to let them some chance to reply before and I'm quite busy today
[14:08] <davmor2> mvo: is there a fix in compiz to allow the screensaver to work?
[14:08] <nxvl> pitti: hi!
[14:08] <nxvl> pitti: would you like to take a look at Bug #279425 please?
[14:09] <kwwii> seb128: excellent, thanks for the help :-)
[14:09] <pitti> nxvl: I got the bug mail; will do ASAP
[14:09] <seb128> kwwii: you're welcome!
[14:09] <nxvl> pitti: thank you!
[14:10] <mvo> ScottK-laptop: yes, would be good. please give me the bugnumber once its added, its enough if its very short (just the "make update-manager force kdelibs4-dev->kdelib5-dev upgrade")
[14:10] <ScottK-laptop> mvo: Will do.
[14:10] <mvo> davmor2: could you be a bit more specific (or point me to a bug)? screensaver seems to work for me with compiz
[14:11] <cjwatson> Riddell: mvo is correct; pkgsel and ubiquity do it
[14:11] <rom1v> mvo: I don't know if you saw my message, I think you're right : https://bugs.launchpad.net/ubuntu/+bug/215876 (last comment), adding a script to Xsession.d would be better
[14:12] <davmor2> mvo: bug 253367
[14:13] <ogra> davmor2, i see that as well on the samsung Q1U
[14:13] <ogra> (also intel)
[14:13] <davmor2> mvo: screen fades to black as soon as it has gone black it shoots back to desktop again
[14:13] <ogra> but dont see it on the laptop ... intel as well
[14:13] <ogra> its definately dpms misbehaving but i doubt its the intel driver
[14:14] <ogra> mvo ^^^
[14:14] <ogra> in cae you need a tester
[14:14] <mvo> rom1v: yes, I have seen it, thanks! that should probably be reassinged to nvidia-settings at this point so that it is added there. I vaguely remember this came up before, have you looked in the bugreports for nvidia-settings if that was ever discussed?
[14:14] <davmor2> mvo: also if I enable the Nvidia binary for my other test desktop and enable compiz same thing again.
[14:14] <mvo> ScottK-laptop: thanks!
[14:15] <davmor2> ogra: disable compiz and it works fine
[14:15] <mvo> davmor2: my desktop seems to be fine, let me have a look
[14:15] <ogra> davmor2, i'll try
[14:15] <mvo> ogra: thanks, dpms is a good hint
[14:15] <davmor2> mvo: Is there anything I can do to lower it down a bit for you?
[14:15]  * ogra disables compiz on -mobile and waits
[14:16] <mvo> davmor2: what video card/driver to you have?
[14:17] <pitti> nxvl: in fact, it just happens to be next on my list, doing now :)
[14:17] <rom1v> mvo: bug 108060
[14:17] <rom1v> ?
[14:17] <nxvl> pitti: \o/
[14:17] <pitti> seb128, mvo: just for the record, video playback WFM for current compiz, too
[14:18] <seb128> pitti: bah
[14:18] <pitti> nxvl: wrt your diff.gz, I'll augment the changelog with some real change descriptions, if you don't mind?
[14:19] <nxvl> pitti: as in the changes added? sounds good to me
[14:19] <siretart> seb128: the reason to reject was either - lack of answer or - sorry, was a partially transferred file
[14:19] <mvo> excellent, thanks pitti
[14:19] <siretart> seb128: as for stock responses, see http://ffmpeg.org/bugreports.html for bug reporting guidelines
[14:20] <davmor2> nvidia 7200 is the one and it's intel in the box I reported from initial I'll get the exact model in a couple of seconds for you
[14:20] <davmor2> mvo: ^
[14:20] <mvo> davmor2: what driver is used there -177 ? or a older one?
[14:21] <seb128> siretart: ideally ffmpeg should not crash on non incomplete videos
[14:21] <ScottK-laptop> mvo: Bug #279621
[14:21] <seb128> -non
[14:21] <davmor2> mvo: the latest and recommended so I think it is the 177
[14:21] <siretart> seb128: true. however without example file, there is no point in even trying to forward such bugs
[14:21] <siretart> seb128: that's why I propose to disable apport for thumbnailer crashes
[14:22] <seb128> siretart: right, so either we disable apport and will never get a reply or we use stock replies and set those to uncomplete and let a chance to users to provide enough informations to fix an issue
[14:22] <seb128> siretart: it's your call as ffmpeg maintainer
[14:23] <mvo> davmor2: hrm, I have that too on my desktop
[14:23] <seb128> siretart: we can reassign bugs asking for an example using a stock reply appropriate and ask to reopen if the submitter has the informations
[14:23] <mvo> davmor2: desktop/laptop or both ? (if you see it on two machines)?
[14:23] <seb128> siretart: the number of crashers we get is manageable
[14:23] <mvo> davmor2: I also wonder if it might be only affecting new installs (or is this a upgraded machine)?
[14:23] <siretart> seb128: okay, then let's try that
[14:24] <seb128> siretart: ok good, do we have a stock reply somewhere on the ubuntu wiki for ffmpeg bugs? https://wiki.ubuntu.com/Bugs/Responses lists the common ones
[14:24] <davmor2> mvo: New installs (I'm an iso tester) both are desktop
[14:24] <davmor2> mvo: intel is an 83945 G/GZ
[14:24] <seb128> siretart: ah, there is a "xine-lib and ffmpeg bugs", do the reply looks good enough to you?
[14:25] <siretart> what's the link? let me check
[14:25] <mvo> davmor2: thanks. and it happens only with compiz, not when you disable effects?
[14:25] <davmor2> s/83945/82945 sorry
[14:25] <seb128> siretart: https://wiki.ubuntu.com/Bugs/Responses#xine-lib%20and%20ffmpeg%20bugs
[14:25] <davmor2> mvo: that is correct
[14:25] <davmor2> ogra: how about you ^
[14:25] <mvo> davmor2: thanks, anything in ~/.xsession-errros when it happens?
[14:26] <ogra> davmor2, still waiting for dpms
[14:26] <ogra> davmor2, oh now it starts ... one more second
[14:26] <ogra> yep, seems to work fine with compiz off
[14:26] <siretart> seb128: yes. that response should be okay for most cases, I'd think.
[14:26] <ogra> fades properly and doesnt come back
[14:27] <seb128> siretart: ok, let's try that then, if that doesn't prove efficient we will just add an apport hook to ignore those
[14:29] <davmor2> mvo: http://www.davmor2.co.uk/esys-lshw.html
[14:30]  * Keybuk discovers /sys/dev
[14:30] <davmor2> mvo: I'll check ~/.xsession-errors in a second for you
[14:31] <cjwatson> Keybuk: hey, that's kind of handy
[14:31] <Keybuk> cjwatson: udev upstream just grew a /dev/{block,char}/maj:min -> /dev/node mapping too
[14:32] <Keybuk> quite a nice round-trip
[14:32] <Keybuk> if you have a sysfs devpath, read "dev" to get maj:min, and readlink /dev/{block,char}/maj:min to get the device node name
[14:32] <ScottK-laptop> pitti: If you have a moment, I could use a bit of advice on how to fix this: http://launchpadlibrarian.net/18194120/Traceback.txt - Should python-dbus do something other than raise an exception here or should Guidance catch the error and ? retry/wait/die
[14:33] <ScottK-laptop> pitti: Someone said you were having similar problems with Jockey.
[14:33] <Keybuk> if you have a /dev path, stat() to get maj:main, and readlink /sys/dev/{block,char}/maj:min to get the sysfs devpath
[14:34] <pitti> ScottK-laptop: "similar in jockey" only in the sense that I got crash reports about unavailable policykit-kde-agent
[14:34] <pitti> ScottK-laptop: IMHO python-dbus DTRT here, and guidance should intercept it and die gracefully
[14:35] <pitti> ScottK-laptop: or just let it die like it does now, the exception message is clear enough (will cause some apport bug spam, though)
[14:35] <ScottK-laptop> pitti: Some aspects of Guidance seem to work when hal is missing, so I'll try and see what the most useful direction to go in is.
[14:35] <ScottK-laptop> pitti: Thanks.
[14:36] <siretart> seb128: thanks
[14:36] <seb128> siretart: you're welcome
[14:42] <davmor2> mvo: Nothing in ~/.xsession-errors
[14:43] <davmor2> mvo: I should say nothing new in ﻿~/.xsession-errors
[14:43] <mvo> davmor2: ok, I'm rsyning the current livecd and check if I can reproduce it from it (I don't have a new install atm)
[14:46] <davmor2> mvo: the intel card is still doing on the smoketest from yesterday
[14:50] <mvo> davmor2: I just tested it on a upgraded intel system and the screensaver is fine there
[14:50] <mvo> davmor2: live-cd is next
[15:10]  * StevenK sighs at mit-scheme
[15:11] <StevenK> No fair requiring sysctl changes to build
[15:12] <davmor2> mvo: any joy?
[15:15] <mvo> davmor2: still burning the disk
[15:15] <davmor2> okay cool :)
[15:17] <munkey092092> hello?
[15:18] <munkey092092> are you interested in stuff you can develop which is not in it?
[15:20] <munkey092092> i got a ubuntu some time ago and it said it was completely compatable with windows but not with my 3g modem which installs as a mass storage device and automatically installs a windows driver 2000 xp or viste it is a huawei 3g modem mebbe yous want to know this stuff
[15:20] <munkey092092> these modems are 3.6Mb broadband and v cheap
[15:21] <munkey092092> huawei E220 hsdpa modem (wireless)
[15:23] <jsgotangco> strange, i have the same modem and it works fine on ubuntu and even debian :-) its already in the kernel
[16:05] <ogra> Keybuk, meep ... one question about udev rules, ltspfs is synced from debian now, when i packaged it i used to use 080 for the custom rules, from debian it comes in with 050, i happen to remember somewhere in my head that this isnt good numbering
[16:06] <Keybuk> ogra: Debian and Ubuntu use different, incompatible, rule numbering
[16:06] <siretart> Keybuk: section 1 says "keep intact all the notices that refer to this License and to the absence of any warranty"
[16:06] <ogra> right, so 080 was the right one, right ?
[16:06] <ogra> for custom overriding rules
[16:06] <Keybuk> depends what you want to use in the rules
[16:06] <Keybuk> siretart: and "give any other recipients of the Program a copy of this License"
[16:07] <Keybuk> siretart: section 2 says "You must cause any work that you distribute or publish[...]to be licensed[...]under the terms of this License."
[16:07] <ogra> Keybuk, http://paste.ubuntu.com/55029/
[16:08] <ogra> Keybuk, also intesting is that ENV{ID_TYPE} doesnt seem to work
[16:08] <cjwatson> ogra: neither 050 nor 080 is correct in Ubuntu - we use two-digit rule numbers. check /etc/udev/rules.d/
[16:08] <cjwatson> and I think Debian tend to use an underscore as a separator too
[16:09] <cjwatson> dh_installudev knows about the differences
[16:09] <Keybuk> ogra: reading
[16:09] <siretart> Keybuk: which is according to schily also the case here.
[16:10] <ogra> cjwatson, yeah, the package uses that
[16:10] <ogra> actually it doesnt set any numbering
[16:10] <ogra> hmm
[16:10] <siretart> Keybuk: please note that he considers cdrtools as a mere collection of more or less independent programs and libraries
[16:10] <Keybuk> ogra: other than ID_TYPE, that can go anyway
[16:10] <Keybuk> ogra: anywhere, sorry
[16:10] <Keybuk> though 80 would be where I'd put it
[16:11] <siretart> Keybuk: the real tricky point is that we are discussion license compatibility in a pretty complicated case here.
[16:11] <ogra> right, i think i remember that you suggested that for my package ... i wonder though where dh_installudev gets the 50 from now ... there is no number set at all
[16:11] <Keybuk> siretart: I understood his argument to be
[16:11] <Keybuk> foo is GPL, source is GPL, binary is GPL
[16:11] <cjwatson> ogra: 50 is the default unless you tell it otherwise
[16:11] <ogra> ah
[16:11] <cjwatson> ogra: following /etc/udev/rules.d/README
[16:11] <persia> Who knows python python and would like the scheduling in #ubuntu-meeting to work?
[16:11] <Keybuk> it links to libbar which has source under CDDL, but you can pretend the binary is GPL
[16:11] <Keybuk> right?
[16:12] <Keybuk> ogra: for ID_TYPE to work, it probably _has_ to be 80
[16:12] <siretart> mkisofs source is GPL, binaries of mkisofs are GPL as well.
[16:12] <cjwatson> indeed, this is documented in dh_installudev(1) ...
[16:12] <Keybuk> siretart: but mkisofs links to non-GPL libraries?
[16:12] <ogra> Keybuk, yeah, that was my thought
[16:12] <ogra> stgraber, ^^^
[16:12] <liw> persia, hm? the bot needs fixing?
[16:13] <stgraber> ogra: oh, will give that a try
[16:13] <siretart> Keybuk: GPL section 2 does only talk about "the Program or any portion of it", not about additional libraries it links to
[16:13] <ogra> cjwatson, thanks a lot, i'll fix that then
[16:13] <ogra> stgraber,   80   rules that run programs (but do not load modules)
[16:13] <ogra> stgraber, from /etc/udev/rules.d/README
[16:13] <persia> liw, Indeed.  Google iCal sends a single announcement for recurring events that needs more parsing.  Work in progress is at https://code.edge.launchpad.net/~tsimpson/+junk/Webcal but is stalled.  Help appreciated.
[16:13] <liw> persia, hm, not something I know much about, I'm afraid
[16:13] <persia> liw, Awww.
[16:14] <persia> Anyone else?
[16:14] <siretart> Keybuk: it does specifcally not use "the whole Program" as elsewere in the text. schily claims that this wording is used here on purpose
[16:14] <liw> persia, I'd be happy to spend a few days learning about iCal, but you'll have to convince cjwatson I should do it :)
[16:14] <persia> cjwatson, Can liw fix the bot?
[16:15] <cjwatson> err, a few days is a bit much
[16:15] <liw> indeed
[16:15] <persia> pity
[16:15] <cjwatson> does it really need liw to be an iCal expert, or just a general python hacker? does somebody else already know the necessary iCal stuff?
[16:16] <stgraber> ogra: rebuilding the squashfs, let's hope it did the trick
[16:16]  * ogra hopes
[16:16] <stdin> ical is not too complicated, it's the data processing that's mind-melting
[16:16] <stdin> s/data/date/
[16:17] <liw> stdin, in what way?
[16:18] <stdin> liw: in iCal you can have a rule where an event repeats on the first Thursday and second Tuesday of the month. working that out properly is, erm, not easy
[16:19] <liw> stdin, hmm, I could have a look then; cjwatson, an hour is ok, I hope?
[16:19] <cjwatson> sure
[16:19] <liw> tomorrow, then
[16:20] <persia> liw, cjwatson: Thank you.
[16:20] <stdin> ical.py and rrule.py are the guts (uses python-dateutil and included icalendar module)
[16:21] <liw> stdin, can you e-mail me (lars@ubuntu.com) how to reproduce the problem so that I can be sure I'm fixing it?
[16:21] <liw> stdin, alternatively, will you be around in about 22 hours?
[16:21] <stdin> the google iCal is http://tinyurl.com/6mzmbr, just try parsing it with the ical module
[16:22] <stdin> 22hours = 14:22 for me, so yeah
[16:22] <stdin> (probably anyway)
[16:26] <stdin> liw: http://pastebin.com/f4379d83e is a small test run to see what events it sees
[16:26] <liw> stdin, thanks! I'll look at it tomorrow, now I need to go celebrate Xmas
[16:26] <liw> (with a company that went bankrupt in 2001)
[16:43] <nxvl> seb128: can you please take a look at Bug #273396
[16:43] <seb128> nxvl: I'm already building a patched package
[16:43] <seb128> nxvl: usually no need to ping on IRC when bugs are fixed we do read the bug mails ;-)
[16:43] <nxvl> seb128: oh ok, since i attached a patch inthere
[16:43] <nxvl> :P
[16:43] <mvo> davmor2: hrm, the livecd does not have a screensaver of course (well, it does, but no locking)
[16:43] <nxvl> \o/
[16:43] <seb128> nxvl: ah, didn't get this one yet
[16:44] <persia> mvo, can't it be locked if one manually forces the setting of the password for the ubuntu account?
[16:44] <nxvl> seb128: then IRC was needed
[16:44] <nxvl> :D
[16:44] <mvo> persia: yeah, I will fiddle a bit
[16:44] <seb128> nxvl: yeah ;-)
[16:45]  * nxvl HUGS seb128 
[16:45] <nxvl> seb128: if you are preparing and upload please include that, is a really annoying bug
[16:46] <persia> mvo, Oops.  My mistake.  casper-bottom/22screensaver disables locking in gconf + kdesktoprc
[16:46] <davmor2> mvo: this is just the standard SS the blank screen that comes as standard once installed.  However you get the same thing on Livecd too it still fade during install and on my nvidia it stays blank and on the intel it wakes up
[16:47] <seb128> nxvl: oh, already uploaded, when I said I was building a patched package that was to do an upload ;-)
[16:47] <mvo> persia: hrm, I enabled it again in gconf and it still won't lock
[16:48] <persia> Odd.  With that unset, and a password for ubuntu, it ought, I'd think.
[16:49] <nxvl> seb128: ok, i will update the patch in s bit
[16:49] <mvo> persia: it doesn't - oh well
[16:49] <Riddell> persia: what's this?
[16:50] <kwwii> TheMuso, seb128, mvo, pitti...heck, anyone :-) We need to revert the -sounds package
[16:50] <persia> Riddell, Trying to figure out how to lock the screen from the liveCD.
[16:50] <ogra> mvo, it wont lock if no PW is set
[16:51] <ogra> kwwii, what id you do ? put a farting sound into gdm ?
[16:52] <mvo> ogra: hrm, I set one, maybe its lying to me
[16:52] <seb128> nxvl: what do you want to update?
[16:53] <nxvl> seb128: the patch i attached to that bug report
[16:53] <seb128> nxvl: what patch?
[16:53] <ogra> mvo, hmm, i just know gss and xss were patched to not lock with no pwd when i maintained them ...
[16:53] <ogra> not sure how thats done now
[16:53] <seb128> nxvl: I've the feeling we have a communication issue there
[16:53] <nxvl> seb128: yup
[16:54] <nxvl> Bug #273396 -> i've attached a patch into it
[16:54] <mvo> ogra: no luck, I created a different user even
[16:54] <ogra> did you unset the gconf key ?
[16:54] <seb128> nxvl: and as said before I alread uploaded a patched version, it was building when you pinged me
[16:54] <ogra> its a system wide one iirc
[16:55] <nxvl> seb128: oh! a patch fixing that issue, ok, i thought you were building a one fixing another issue
[16:55] <seb128> nxvl: sorry I would have used your debdiff if I had read the bug comment before uploading
[16:55] <nxvl> seb128: you were right, communitcation issue
[16:55] <seb128> nxvl: we just worked on the same issue around the same time ;-)
[16:55] <nxvl> seb128: no problem, i just want that annoying bug fixed
[16:55] <nxvl> so
[16:55] <seb128> alright
[16:55] <nxvl> thank you!
[16:55]  * nxvl HUGS seb128 
[16:55]  * seb128 hugs nxvl
[16:56] <ogra> mvo, ah, no it has sudo -u $USER ... its a user setting
[16:57] <mvo> ogra: I toggled the key too, yes
[17:08] <kwwii> ogra: haha, no...apparently the sounds are very window-ish (/me has no windows and therefor didn't catch it)
[17:08] <ogra> well, the vista sounds were made by robert fripp iirc ...
[17:09] <ogra> that would honor us :)
[17:40]  * calc will be making a new OOo ppa upload today after verifying the build
[17:41] <calc> should only affect ppa users :)
[17:44] <cody-somerville> calc, shouldn't affect anyone ;]
[17:48] <zul> slangasek: ping can we get a FFE for drbd8 please?
[17:48] <slangasek> zul: that's on the top of my list to look at today
[17:48] <zul> slangasek: thanks
[17:51] <evand> asac: is it a bug if continuous calls to udevadm trigger; udevadm settle causes this: http://evalicious.com/tmp/udevbug.png
[17:52] <kirkland> seb128: hey
[17:53] <kirkland> seb128: there's a couple of people complaining about the fact that the ~/Private encrypted mount creates an icon on their desktop
[17:53] <kirkland> seb128: i'm wondering if there's an easy way that we could blacklist the ecryptfs ~/Private mount from generating that icon when mounted?
[17:57] <stgraber> slangasek: hey, did you have a chance to look at the exceptions for ldm and ltsp ?
[17:58] <slangasek> stgraber: not yet, no
[18:07] <seb128> kirkland: we could teach gio to ignore those mounts easily
[18:08] <seb128> kirkland: we get quite some bugs about unmounting not working on those directory
[18:08] <kirkland> seb128: right...  for unmounting to work, it needs to call /usr/sbin/umount.ecryptfs_private
[18:08] <seb128> kirkland: is that something which will be standard in intrepid? whoever worked on the spec should have though about nautilus integration from the start
[18:08] <kirkland> seb128: well....  i worked on the spec, and specifically intended it for servers
[18:09] <kirkland> seb128: but quite a number of people latched onto it as useful for the desktop
[18:09] <seb128> ok, fair enough
[18:09] <kirkland> seb128: my apologies for lack of nautilus integration, but that's not my strong suit or focus
[18:09] <stgraber> ogra: fix confirmed to work for ltspfs, do you do the packaging change or do you want me to do it ?
[18:09] <seb128> is there easy instructions on how to configure that somewhere?
[18:09] <kirkland> seb128: as yourself, run "ecryptfs-setup-private"
[18:10] <kirkland> seb128: logout, login
[18:10] <seb128> kirkland: that's alright and quite understandable
[18:10] <kirkland> seb128: that's pretty much it
[18:10] <kirkland> seb128: there's a question in the alternate/server installer that does this for you
[18:10] <kirkland> seb128: i don't think cjwatson ever ended up putting it on the desktop installer
[18:10] <kirkland> cjwatson: ?
[18:10] <seb128> kirkland: ok, I'll give it a try later and see if it's easy to ignore those
[18:10] <kirkland> seb128: thanks much
[18:10] <seb128> no problem
[18:10] <kirkland> seb128: let me know if there's anything i need to do on the ecryptfs-utils side
[18:11] <kirkland> seb128: or if you have any questions/problems
[18:11] <seb128> ok I will
[18:11] <kirkland> seb128: there's a community effort on making a python-gtk gui for it
[18:11] <kirkland> seb128: i plan on integrating that in Jaunty
[18:11] <kirkland> seb128: too late for Intrepid, i think
[18:11] <seb128> right it's late not for this cycle
[18:12] <nxvl> seb128: are there plans on including gimp2.6 for intrepid?
[18:14] <cjwatson> kirkland: not as yet
[18:15] <seb128> nxvl: it has been uploaded yesterday?
[18:16] <nxvl> really?
[18:16] <nxvl> ah yes
[18:16] <seb128> nxvl: yes, why?
[18:16] <nxvl> :D
[18:16]  * nxvl HUGS seb128 
[18:16] <nxvl> seb128: i still have 2.4.7 on my sistem
[18:16] <nxvl> system*
[18:17] <seb128> nxvl: it didn't build yet, gegl and babl need to be promoted, mir bugs have been filled and I pinged pitti who said he would have a look today
[18:17] <nxvl> ohh
[18:17] <nxvl> ok
[18:17]  * nxvl HUGS seb128 again
[18:17] <seb128> ;-)
[18:17] <nxvl> intrepid desktop will rock!
[18:18] <seb128> indeed ;-)
[18:20] <ogra> stgraber, if you like to
[18:20] <seb128> lool: speaking about gimp and gegl I noticed you commented on the bug, the package comes from debian so you should probably ask there
[18:23] <stgraber> ogra: ok, will do. Won't take long, it's a simple change to the packaging.
[18:23] <ogra> right, just a change to the dh_installudev line
[18:23] <ogra> ping me for uploadin
[18:23] <ogra> g
[18:26] <slangasek> zul: could you please provide the information requested in https://wiki.ubuntu.com/FreezeExceptionProcess for the drbd FFe?
[18:26] <zul> slangasek: yep
[18:45] <nxvl> seb128: it looks like the update wasn't the solution (gtkhtml one)
[18:50] <directhex> confirmation from one user that removing gnupg-agent fixes f-spot.
[18:54] <stgraber> ogra: https://www.stgraber.org/download/ltsp/
[18:54] <james_w> does anyone know if it's possible to set an inotify watch on a file that doesn't exist yet?
[18:54] <stgraber> oh, wrong one :)
[18:54] <stgraber> ogra: https://www.stgraber.org/download/ubuntu/ltsp/
[18:54] <stgraber> this one should be better
[18:54] <ogra> stgraber, tsk, buy a proper cert :P
[18:55] <stgraber> I did a test build on amd64, package content after that was ok
[18:55] <Daviey> james_w: you can set it on the location, at least
[18:55] <stgraber> ogra: oh, right you can also use http:// :) and the cert is valid, it's just cacert so you need the cacert root certificate (not default in firefox, unfortunately)
[18:55] <Daviey> james_w: ie, watch for a new file, then react to it via grep or similar
[18:56] <ogra> i wasnt serious :)
[18:56] <james_w> Daviey: you can set it on the parent directory with IN_CREATE, and get notified when a new file appears below it apparently, but the code I am looking at sets it on the file, and I can't determine if that is legal from the documentation.
[18:56] <james_w> Daviey: have you seen it set on a non-existent file?
[18:56] <stgraber> ogra: yeah, well a couple of co-worker were like, you should buy a real certificate, self-signed certificates are bad ... but they didn't realise it's not a self-signed certificate :) it's just a cert authority they don't have.
[18:57] <ogra> uploaded
[18:57] <stgraber> ogra: and buying a *.stgraber.org can be quite expensive for basically my website and my webmail :)
[18:57] <Daviey> james_w: pass.. sorry no idea
[18:57] <stgraber> ogra: cool, thanks
[18:57] <james_w> Daviey: never mind, thanks for the help
[18:57] <james_w> I guess I should write a test case
[18:57] <ogra> stgraber, yeah, i know a guy who made millions with that cert stuff :)
[18:58] <stgraber> ogra: oh, really. I wonder who ? :)
[18:59] <ogra> hehe
[19:08] <james_w> yeah, you can't set an inotify watch on an open file.
[19:08] <james_w> on a non-existent file I mean.
[19:13] <pitti> superm1: did you send 03_dell_studio.patch (hal-info) to upstream? I didn't see it on the list, but it might have slipped my attention
[19:13] <pitti> superm1: unless there was an objection, I'd just commit it upstream, to get rid of our hal-info patches
[19:14] <superm1> pitti, i sent it upstream, and matthew garret commented on it
[19:14] <superm1> pitti, he said not to detect specifically on a line of computers unless there is a known conflict
[19:15] <superm1> pitti, but i had assumed he committed it as not detecting on that line then
[19:15] <slangasek> superm1: how's bluez 4.x coming along?
[19:16] <superm1> slangasek, i'm doing a retest of SCO stuff on upstream's 4.12, they had claimed it should be working
[19:16] <superm1> slangasek, and i'll upload after i make sure it's clean for input things (whether or not sco is)
[19:16] <slangasek> ok
[19:17] <pitti> superm1: ah, I see, http://lists.freedesktop.org/archives/hal/2008-October/012330.html
[19:18] <pitti> superm1: it's not committed yet
[19:19] <pitti> superm1: oh, sorry, it is; nevermind me
[19:20] <pitti> superm1: argh, my first look was right; it's not committed
[19:20] <pitti> superm1: I got confused, there is this line already:
[19:20] <pitti>           <append key="input.keymap.data" type="strlist">e013:f23</append> <!-- FIXME Fn+Left arrow Auto Brightness -->
[19:20] <pitti> superm1: but your's was e00c:f23
[19:20] <slangasek> zul: is there an upstream changelog for drbd?  That's probably what's going to be most useful for reviewing
[19:21] <zul> slangasek: yeah ill attach it sorry about that
[19:21] <superm1> pitti, yeah these newer laptops unfortunately changed that a few of those keys keycodes
[19:21] <slangasek> zul: n/p, thaks
[19:21] <slangasek> n
[19:21] <pitti> superm1: does the FIXME mean that the e013 is actually invalid, or they apply on older models?
[19:21] <pitti> superm1: do you still have that thread or latest reply, and could bounce it to me? then I can answer without breaking the thread
[19:21] <superm1> pitti, it means that it's valid but the key doesn't do anything useful
[19:22] <superm1> pitti, yeah i can bounce you into the thread
[19:23] <superm1> pitti, on the windows side there is a little "tooltip" that pops up telling you that your keyboards light has been turned off, or  the ambient sensor is adjusted (as though you don't already know), but that's what that keycode is for - if such a thing is added in linux
[19:25] <zul> slangasek: done
[19:25] <slangasek> thanks
[19:26] <pitti> superm1: got it, thanks
[19:26] <superm1> thanks pitti
[19:31] <pitti> superm1: done, and replied; thanks
[19:44] <lool> seb128: Indeed
[19:47] <seb128> lool, pitti: anybody of you could look for the babr and gegl mir today or tomorrow?
[20:08] <nxvl> seb128: ping
[20:08] <seb128> nxvl: hello
[20:09] <seb128> nxvl: I tried the fix here, did you restart evolution?
[20:09] <nxvl> seb128: yup, i think... :D anyway, i was thinking doesn't evolution need to be rebuilded?
[20:09] <nxvl> heh
[20:10] <nxvl> i just got the update
[20:10] <nxvl> :P
[20:10] <seb128> nxvl: no, the composer is a gtkhtml widget
[20:10] <nxvl> really?
[20:10] <nxvl> isn't it a library?
[20:10] <seb128> gtk is a library too and it has widgets
[20:11] <seb128> a widget is an object
[20:11] <seb128> you can have it in a library
[20:11] <nxvl> oh!
[20:11] <nxvl> i need to read more about gnome development
[20:12] <nxvl> \o/ it works
[20:12]  * nxvl HUGS seb128 once again
[20:12]  * nxvl is starting to think that he has hug seb128 a lot today
[20:12] <seb128> yeah, I was thinking that too ;-)
[20:12] <seb128> but good to know that's working!
[20:13] <nxvl> :D
[20:15] <digistyl3_> anyone familiar with alsa and pulseaudio in intrepid?
[20:38] <superm1> slangasek, okay i've dropped bluez itself into NEW.  once it clears through the queue and is in the appropriate component, i'll upload more.
[20:40] <pitti> superm1: ah, already exercising your new superpowahs? :-)
[20:41] <superm1> pitti, :)
[20:44] <pitti> halp plz! how can I ask git for the equivalenze of "bzr ignored", i. e. display a list of files which aren't tracked?
[20:45] <superm1> pitti, 'git status', achieve what you are looking for?
[20:45] <pitti> nope
[20:45] <pitti> it doesn't show me anything, and --help doesn't help either
[20:47] <pitti> ah, seems "git ls-files -o" does the trick
[21:05] <slangasek> superm1: ah hrm, bluez is sourceful new?  why do source packages have to change names :(
[21:06] <superm1> slangasek, it's because bluez-libs and bluez-utils are one package now
[21:06] <seb128> uploading the new bluez stack? good ;-)
[21:07] <slangasek> superm1: am I going to fail if I try to match the code up by hand for a source check?
[21:08] <superm1> slangasek, what does that mean?
[21:08] <slangasek> superm1: it's in sourceful new, so I have to make sure it's ok for the archive; is it non-trivial to correlate the contents of the new bluez package with the two old packages, if I try shuffling dirs around?
[21:09] <psusi> is there a way to have buildd build a private bazaar branch?  like if I want to link a bug report to a test fix package, rather than pbuildering it myself and uploading it as an attachment?
[21:09] <superm1> slangasek, yeah it's likely non-trivial, you will get to a state where the directories will correlate, but not necessarily "all" of the content
[21:19] <slangasek> superm1: bluez-audio is being renamed to bluez-alsa (with split contents)?
[21:41] <slangasek> superm1: I raise this because I'm not clear on what the upgrade path will look like for users who had bluez-* installed in hardy, but not bluetooth; it looks to me like it will regress on upgrade
[21:52] <RAOF> psusi: No.  It's not possible to have a buildd build a _public_ bzr branch.  The best you can do is a PPA.
[21:53] <psusi> err, yea... that's what I meant.... personal branch..
[21:54] <psusi> like code.launchpad.net/~Phillip Susi/package/branch.... how would I request that?
[22:06] <superm1> slangasek, bluez-utils should pull it in as a transitional package
[22:08] <slangasek> ok, I suppose that should cover the vast majority of cases
[22:08] <slangasek> (accepted, btw, and watching for the binaries)
[22:10] <superm1> slangasek, okay great, as soon as binaries clear I'll get the rest of the stuff uploading
[22:15] <slangasek> tseliot: bug #275977 appears to have an ack from pitti; are you waiting on us for anything else before upload, or do we just need bryce to poke it?
[22:15] <tseliot> slangasek: bryce has just uploaded the packages
[22:16] <slangasek> ah
[22:16] <tseliot> slangasek: thanks for your interest ;)
[22:16] <slangasek> tseliot: the bug is still open, though?
[22:17] <tseliot> slangasek: maybe the other report was closed. Let me check
[22:18] <tseliot> slangasek: maybe should set them to fix released manually
[22:18] <tseliot> we
[22:19] <slangasek> tseliot: please do so, I assume you know what upload fixed it better than I do :)
[22:19] <tseliot> slangasek: ok
[22:20] <slangasek> superm1: these binary packages all have changelog files symlinked to the one in the bluetooth package; that's wrong, the changelogs will be missing unless the user installs bluetooth, which is not a dependency
[22:20] <slangasek> superm1: is there a "common" package that everything deps on?
[22:20] <slangasek> superm1: libbluetooth3, probably?
[22:21] <superm1> slangasek, most of them libbluetooth3.  this is likely a side effect of cdbs though, nothing I had changed at least.  how do you correct that?
[22:22] <slangasek> hmm, this problem didn't exist in bluez-utils before.  Let me have a look at debian/rules, if I can still find it while we're mid-publish
[22:23] <superm1> (i'll just do a second upload if it ends up being too late to catch in the first)
[22:23] <directhex> i need a FFe for mono. security update.
[22:23] <slangasek> directhex: bugfixes don't require FFe
[22:24] <directhex> oh, good
[22:24] <directhex> then i'll be hunting for a sponsor.
[22:25] <slangasek> superm1: I don't see anything obvious that explains why this is happening to the changelogs :/
[22:25] <slangasek> pitti: do you know what in cdbs would automatically symlink changelogs to the copies in another package?  This is happening in bluez, without a dependency between the packages
[22:26] <slangasek> superm1: fwiw, I bet if you moved the libbluetooth3 binary package to be the first in debian/control, it would magically work right :-P
[22:26] <slangasek> superm1: oh, and the description of the bluetooth package should probably not be 'Blueooth support' :-)
[22:27] <superm1> slangasek, okie dokie, i'll move it around.  you going to grab it midpublisher, or should I just upload a second update?
[22:27] <slangasek> superm1: it has to be a second update
[22:28] <superm1> slangasek, okay
[22:28] <slangasek> there's no mid-publisher grabbing I can do to make it disappear, I was just grabbing the source to look at :)
[22:28] <superm1> slangasek, i'll actually hold off and queue this up in bzr for the end of the week.  upstream has a few bug fixes that they are working on at their development summit
[22:38] <calc> OOo 3.0.0~rc4-1ubuntu1 now in the ppa :)
[22:41] <directhex> calc, intrepid ships with 2.4 or a 3.0 rc?
[22:41] <wst> calc: Nice, thanks! Will try them as soon as they have been built!
[22:42] <calc> directhex: 2.4.1
[22:42] <calc> directhex: 3.0 still isn't released yet, maybe next week though, but is too late to be in intrepid
[22:42] <wst> no openoffice3 package in universe or something like that either?
[22:42] <directhex> calc, absolutely fair enough (people are on at me for mono 2.0, so i know i know)
[22:43] <calc> wst: building with versioning doesn't work anymore, but we might put it in backports to override 2.4.1, not sure yet
[22:43] <wst> ah ok thanks
[22:43] <calc> directhex: hopefully mono is slightly more stable than OOo in the general case though ;-)
[22:43] <calc> directhex: up until last week they were still finding major blocker bugs
[22:44] <directhex> calc, well, our diff.gz is a little bit smaller, but still full o' patches
[22:44]  * calc bets they will find plenty of major bugs for OOo 3.0 a few weeks after its released
[22:44] <calc> directhex: heh :)
[22:44] <directhex> mono 2.0 only shipped yesterday
[22:44] <calc> OOo diff.gz is up to ~ 100MB now
[22:44] <directhex> calc, i noticed
[22:45] <calc> hmm 95.4MiB for rc4
[22:45] <calc> directhex: ah
[22:47] <wst> calc: do you also want bug reports for these packages anywhere? or are there enough known issues already :-)
[22:48] <calc> wst: if you file bugs make sure to use the help->report a bug so that it properly includes apport information
[22:49] <calc> wst: but i'm sure there will be plenty of bugs in them, heh
[22:49] <calc> wst: it shouldn't be too buggy from a packaging standpoint, but from upstream though it probably is
[22:49] <wst> hehe ok we will find out :-)
[22:49] <calc> it should be installable in probably ~ 6-10hr
[22:51] <emgent> heya
[22:51] <calc> emgent: hi
[22:52] <emgent> calc: good morning :)
[22:53] <calc> emgent: its 5pm here :)
[22:54]  * calc heads off to clean up his house, will watch irc though
[22:57] <emgent> hem.. sorry calc :)
[23:49] <NCommander> superm1, so I can take it the bluetooth transition is now being uploaded inbulk :-)?
[23:50] <superm1> NCommander, well in bulk would be a nice for loop to do it all, i'm double checking each of them locally and submitting patches to appropriate upstreams before i upload each
[23:50] <superm1> NCommander, but please do upload the one you touched
[23:50] <NCommander> superm1, I'm not an MOTU :-)
[23:50] <superm1> NCommander, oh. become a MOTU already.
[23:50] <superm1> ;)
[23:50] <NCommander> superm1, haven't been in one full release cycle yet
[23:51] <NCommander> (DIF jaunty is my application date, the email written, I just need to do the time now)
[23:51] <superm1> NCommander, at least feels like you've been with us a while, but that's probably because you're so productive
[23:51] <superm1> NCommander, good to hear
[23:51] <NCommander> superm1, I'm trying to break 50 uploads before intrepid releases :-)
[23:51]  * NCommander hears multiple gunshots from all directions
[23:52] <NCommander> superm1, I'm finishing my NM application, so my services as a DD will be much more useful until DIF jaunty since I can help do NMUs if necessary to get patches to fly in reverse
[23:52] <superm1> NCommander, ah yeah, that's a good point
[23:53] <TheMuso> superm1: Oh you got core-dev? Congrats!!!
[23:53] <bddebian> And get yelled at by other DDs for NMUing their packages :)
[23:53] <superm1> TheMuso, yup, thanks :)
[23:53] <NCommander> bddebian, you obviously saw that bug then :-)
[23:53] <NCommander> That teachs me to post a debdiff to help someone else
[23:54] <superm1> slangasek, it looks like there is a separate SRU bug for nautilus-sendto.  isn't that part of the bluez 4.x 4.x exception?  I'm not sure why it was filed separately
[23:54] <bddebian> NCommander: No, it happens to all of us :)
[23:54] <slangasek> superm1: I didn't file it :)
[23:54] <NCommander> bddebian, yeah well, your AM wasn't CCed for the entire 10 email flame war
[23:55] <superm1> slangasek, should I upload it then, or do you/rest of ubuntu-release want to look at it separately then?
[23:55] <slangasek> superm1: and haven't even looked at it, yet; I guess there are separate upstream changes that someone thinks need blessing?
[23:56] <superm1> slangasek, yeah.  didn't realize nhandler_ popped it on a different bug
[23:58] <bddebian> NCommander: Who is your AM?
[23:59] <NCommander> bddebian, huggie
[23:59] <bddebian> Ah