[00:04] <TheMuso> nixternal: seems like no sound hardware was found on your system at all, re your bug 382968
[00:09] <nixternal> TheMuso: ya, dtchen has already fixed the issue :)
[00:09] <TheMuso> oh?
[00:09] <TheMuso> ok
[00:09] <nixternal> ya, during upgrade from jaunty -> karmic, somehow my user was removed from the audio group
[00:09] <TheMuso> ah
[00:09] <nixternal> how I missed that is beyond me
[00:09] <nixternal> haha
[00:11] <dtchen> i'm not entirely sure, since i don't have a kubuntu jaunty live image, whether the default user is in @audio to begin with
[00:11] <johanbr> I thought ubuntu didn't use the audio group anymore?
[00:12] <TheMuso> It doesn't.
[00:12] <dtchen> johanbr: correct for ubuntu jaunty, which uses pulseaudio alongside consolekit
[00:12] <ajmitch> dtchen: I'm not in audio on my jaunty box here at work
[00:12] <TheMuso> its all policykit driven.
[00:12] <TheMuso> the only deriv that adds the user to the audio group is studio.
[00:12] <cjwatson> intrepid too
[00:12] <cjwatson> (user-setup 1.20ubuntu3)
[00:12] <ajmitch> are there some differences with groups between kubuntu & ubuntu there?
[00:12] <cjwatson> not as far as the installer is concerned
[00:12]  * ajmitch would hope not
[00:14] <cjwatson> expanding a little on what TheMuso said, ubuntustudio is the only derivative built on the main infrastructure that changes the default groups set by the installer *at all*
[00:14] <cjwatson> (it sets them to 'adm audio cdrom dialout lpadmin plugdev sambashare' right now)
[00:14] <ajmitch> alright
[00:14] <cjwatson> which in fact just adds audio over the default
[00:14] <cjwatson> ow, wrong side of midnight, bed
[00:14] <ajmitch> g'night
[00:14] <TheMuso> night
[01:27] <dtchen> ugh, it's possible for pulseaudio to completely wedge the HDA controller, requiring an /sbin/alsa force-reload to restore functionality. :(
[01:43] <TheMuso> eew
[01:47] <ajmitch> dtchen: I'm not surprised, I was seeing a complaint of sound totally dying in another nz channel today
[02:23] <Hobbsee> Keybuk: just reading the meeting logs now, but we do (IMO) need more ops in here, while europe is asleep.  slangasek would be a great start, but some more would be good.
[02:23] <Hobbsee> although i agree with you on getting developers who are around, if possible
[02:25]  * TheMuso watches IRC quite regularly during his work day at least.
[02:25] <TheMuso> Particularly in here.
[02:25] <Hobbsee> TheMuso: you would probably be a good candidate to be on the list, too, then
[02:26]  * TheMuso needs to go and read the meeting log when he has time.
[03:04] <TheMuso> hrm. ptlib supports esd/esound, yet we don't build support for that. That would be at least one way of getting better pulse support for ekiga...
[03:17] <lifeless> TheMuso+1
[03:51] <slangasek> cjwatson: I don't think we really reached a conclusion about how to handle gcc-multilib under multiarch; we could have a gcc wrapper that handles -m32/-m64, but that's fairly unsatisfactory IMHO, and still implies cross-arch build-dependencies for packages that really truly need to build 32-bit code on amd64 (and there are some), so I guess we need to have a way to handle that?
[03:52] <slangasek> (at which point gcc-multilib can stay as it is, rather than needlessly shuffling the problem down the line)
[03:52] <slangasek> also, I just noticed that we can't use the [arch] syntax to declare a cross-arch build-dep, because that syntax is already used for arch-specific build-deps...
[03:59] <StevenK> {arch} ?
[03:59] <StevenK> We're running out of brackets
[04:01] <lifeless> StevenK: *smack*
[04:03] <ScottK> {([arch])}
[04:06] <lifeless> {arch} was a control dir for tla
[04:06] <StevenK> Yes, and I was using it in the context of debian/control, not a directory name
[04:08] <lifeless> all the same
[04:08] <lifeless> don't propogate the scarin
[04:08] <lifeless> g
[04:08] <StevenK> It would be used like {i386}
[04:09] <StevenK> lifeless: Or do you just twitch when you read {arch} ? :-P
[04:10]  * lifeless twitches
[06:34] <TheMuso> dtchen: When you get a minute, could you please have a look at the notes/whiteboard for https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-audio-experience and add anything I may have missed/incorrectly stated in the wiki page? I feel I got everything, but another pair of eyes is useful. Thanks.
[06:46] <lifeless> TheMuso: if you have a minute, I'd appreciate some guidance on dmraid startup
[06:57] <TheMuso> lifeless: if you are referring to your diffs in those bugs, I am about to get to those.,
[06:57] <TheMuso> c
[06:57] <TheMuso> woops wrong window
[06:58] <lifeless> TheMuso: to the apparent way that udev is calling dmraid-activate four times with 'no' 'block' 'devices' 'found'
[06:58] <lifeless> simply knowing that my patched dmraid-activate, with logging enabled, boots for other people would be good
[06:58]  * TheMuso rechecks the udev rule.
[07:12] <TheMuso> lifeless: I am stumped as to why udev returns no block devices found. The syntax for the rule looks correct. I will have to do a karmic dmraid install to see what the hell is going on.
[07:12] <lifeless> TheMuso: When you can that would rock
[07:12] <TheMuso> ok
[07:12] <lifeless> TheMuso: The only theory I have at the moment is that the no block devices found array is coming from dmraid itself
[07:13] <lifeless> or something linked to the same lib
[07:13] <TheMuso> Right.
[07:13] <lifeless> but I'm damned if I can see the freaking cause
[07:13] <TheMuso> hrm a brain wave. It could be mkid/whatever vol_id's replacement was.
[07:14] <TheMuso> vol_id had its own code to deal with dmraid arrays, and its replacement obviously doesn't know about your hpa stuff, same thing with jaunty and vol_id.
[07:14] <TheMuso> WHich means more patching is needed.
[07:14] <lifeless> \o/
[07:14] <lifeless> is vol_id calledbefore dmraid ?
[07:15] <TheMuso> Yes.
[07:15] <lifeless> or after? if vol_id is called on the dmraid mapper device it would be fine
[07:15] <TheMuso> Not in the dmraid rule, but in other rules.
[07:15] <TheMuso> hrm not sure if this the problem now, but can't think of what else it is currently.
[07:17] <TheMuso> sorry its blkid
[07:17] <lifeless> thanks
[07:17] <lifeless> I shall poke tomorrow
[07:18] <TheMuso> ls
[07:18] <TheMuso> woops
[07:18] <TheMuso> ok
[07:19] <TheMuso> in util-linux source package, you want libs/blkid/src/probers/isw_raid.c
[07:29] <pitti> Good morning
[07:31] <pitti> slangasek: 945 external monitor> Previously I had pipe underruns, which seem to have been cured by the extra 1 GB RAM which I plugged in during UDS
[07:31] <pitti> slangasek: the other problem that I have is that suspend/resume is broken with external monitor (doesn't get switched on again)
[07:31] <pitti> otherwise it's working quite well
[07:33] <TheMuso> pitti: an upload for the intel driver was made today. You tried that yet?
[07:33] <pitti> TheMuso: I have used the xorg-edgers PPA, I get updates practically daily
[07:33] <TheMuso> pitti: ah ok.
[07:33] <pitti> during UDS, karmic was totally broke for me
[07:33] <pitti> broken
[07:33] <pitti> 2.7.1 wedged everything
[07:35] <pitti> bryce: thanks for the new -intel upload
[07:36] <pitti> bryce: would you rather have people test xorg-edgers or karmic?
[07:36] <lifeless> pitti: it fixes or fucks?
[07:36] <pitti> lifeless: xorg-edgers makes everything work like a charm again
[07:36] <lifeless> pitti: but bryces' upload to karmic?
[07:37] <pitti> lifeless: didn't try that yet
[07:37] <pitti> well, actually I did
[07:37] <pitti> I have 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu0sarvatt
[07:37] <pitti> and bryce uploaded 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1
[07:37] <pitti> so I guess they are by and large identical
[07:37] <lifeless> ok cool
[07:37] <pitti> the PPA also has a newer mesa etc., though
[07:37] <lifeless> I won't avoid updating then ;)
[08:20] <pitti> lifeless: BTW, it's pretty hard to entirely wreck the machine; if nothing else helps, blacklisting the i915 module is a pretty sure way to get it back up (without acceleration/compiz/etc. of course)
[08:25] <cjwatson> TheMuso: IMO dmraid-activate should be checking the exit status of dmraid nowadays, now that dmraid exits non-zero if it can't find anything, rather than doing those dodgy tests on its output
[08:28] <cjwatson> slangasek: in some ways I'd rather that build-dependencies were always native, which would seem to suggest that we would need to keep around a small number of biarch libraries as well. I wonder if it's just glibc in practice, or if there are more?
[08:28] <cjwatson> slangasek: we didn't really discuss the problem of /usr/share/doc/<package>/ at UDS - I see there are several options for that in the spec but I don't recall us settling on something
[08:29] <cjwatson> oh good, I see that dh_compress uses gzip -n nowadays - that should probably be a requirement for any multiarch package to avoid spurious differences
[08:39] <dholbach> please help out with http://people.ubuntu.com/~dholbach/sponsoring - the list is growing! :-/
[08:40] <ajmitch> growing to devour us all?
[08:41] <pitti> dholbach++
[08:41] <ajmitch> my excuse is that I was actually doing a couple of merges this week :)
[08:41]  * dholbach takes a look at dx and *recordmydesktop
[08:45] <lifeless> cjwatson: it does, in my patch
[08:45] <lifeless> (dmraid--activate checking $?)
[08:46] <ajmitch> dholbach: useful list, it shows me a bug I missed in the changelog
[08:46] <ajmitch> and also some merge duplication, unfortunately
[08:46] <dholbach> ajmitch: maybe our first impulse should always be "I'll check the sponsoring page and see if somebody else did it already and I just need to review it" :-)
[08:47] <ajmitch> dholbach: to be fair, I'd left a comment on MoM that I was merging it before that bug appeared on the list :P
[08:49] <seb128> dholbach: some people were away for uds and the week before that which might explain why they have been less activate on sponsoring ;-)
[08:50] <dholbach> seb128: I said "please help out with sponsoring" and not "you guys suck and should all be replaced by staplers because you don't do sponsoring" :-)
[08:50] <seb128> lol
[08:50]  * seb128 hugs dholbach
[08:50]  * dholbach hugs seb128 back :)
[08:51]  * Hobbsee tries replacing dholbach with a stapler
[08:51]  * Hobbsee watches people abstain from cuddling it.  Hmmm.
[08:51] <seb128> dholbach: in an other way "I plan to do some but I've a lot of catchup to do this week and spec drafting", ie some people know they have to do sponsoring but are still after uds busy
[08:51]  * dholbach staples
[08:51] <dholbach> - -
[08:51] <dholbach> - -
[08:51] <dholbach> - -
[08:51] <seb128> but agreed, we should tackle this list ;-)
[08:51] <Hobbsee> haha :)
[08:52] <seb128> hey Hobbsee
[08:52] <Hobbsee> seb128: heya!
[08:52] <dholbach> seb128: I'm sure you'll find it relaxing to review a few patches between writing one spec and the other
[08:53] <juanje> dholbach: lol :-P
[08:53] <seb128> dholbach: good idea, you should write a slogan "take a break, review a patch" kind of advertisement ;-)
[08:54]  * iulian feels that he should start sponsoring.
[08:56] <juanje> seb128: yeah, maybe it could be an option in your Typing Break from GNOME :-P
[08:56] <seb128> locking the screen every hour "now it's time for doing some sponsoring"? ;-)
[08:56] <iulian> Heh
[08:56] <juanje> seb128: lol :-P
[08:57] <ajmitch> or dholbach calling your house every hour to remind you
[10:14] <StevenK> pitti: libgnomesupport0 got removed from the archive by you -- there are 4 packages that require the Gnome 1.x libraries -- shall we just boot them, or play the waiting game (IE: See what Debian does?)
[10:14] <pitti> StevenK: check process-removals?
[10:14] <pitti> Debian should have removed pretty much all gnome 1 rdepends
[10:15] <pitti> apt-cache rdepends libgnomesupport0

[10:15] <pitti> hmm
[10:15] <pitti> StevenK: if you find some, just ditch them
[10:15] <StevenK> I checked one, and it hasn't been removed in Debian
[10:15] <StevenK> I suspect it will be
[10:19] <pitti> Riddell: do you know whether KDE relies on hal's camera.libgphoto2.* properties?
[10:19] <pitti> Riddell: or info.capabilities == camera?
[10:20] <pitti> Riddell: in other words, if /usr/share/hal/fdi/preprobe/10osvendor/20-libgphoto2.fdi would go away, woudl anything break?
[10:20] <Riddell> pitti: no idea, I can ask though
[10:22] <Riddell> pitti: I'm told it relies on both
[10:22] <pitti> meh, ok
[10:22] <Riddell> pitti: what would replace it?  devicekit?
[10:23] <pitti> Riddell: for PtP cameras you can just use libudev and ask udev
[10:23] <pitti> for the ancient custom protocol ones we still need something like it
[10:23] <pitti> we'll probably need to keep the list around, and just rewrite it as udev rules
[10:24] <pitti> Riddell: I'll think about it, thanks for checking
[10:38] <soren> Is there a way to query whether a given package was installed manually or pulled in as a dep? I know the info is in /var/lib/apt/extended_states, but does apt or aptitude expose it somehow (preferably in a scriptable manner)?
[10:42] <directhex> soren, "aptitude show"?
[10:42] <directhex> soren, there's this whole "Automatically installed:" line you might like
[10:42] <soren> directhex: Blimey, there it is. *facepalm*
[10:42] <soren> directhex: Thanks.
[10:43] <Lutin> (aptitude search gives it, too)
[10:48] <cjwatson> soren: it'd be nice if apt-mark let you query that state as well as set it ...
[10:49] <soren> cjwatson: Hm.. Never heard of apt-mark before. Looks handy. Thanks.
[10:51] <ion_> I use debfoster to handle the automatic/manual state and apt-mark-sync to sync its decisions to apt and aptitude, since they all still don’t use a shared database for that.
[10:51] <ion_> (btw)
[10:53] <mvo> cjwatson: good point
[10:54] <mvo> ion_: apt and aptitude use a shared database since some time for the auto flag
[10:55] <ion_> mvo: “All”, as in debfoster as well.
[10:55] <ion_> Perhaps aptitude gains debfoster-like functionality some day. That would be nice.
[10:55] <mvo> ion_: aha, ok. debfoster should probably be modified to use the extended_states file as well
[10:59] <ogra> mvo, could you drop the blacklisting for i945GM from compiz in karmic ?
[10:59] <ogra> the new driver works just fine
[10:59] <ion_> mvo: Oh, btw, since i finally manage to be online simultaneously with you: please check out the debdiff in LP #377065. :-)
[11:00] <mvo> ion_: thanks, I have a look now
[11:00] <mvo> ogra: yes
[11:00] <ogra> mvo, thanks :)
[11:04] <mvo> ogra: GM965 you mean?
[11:05] <ogra> mvo, 8086:2a02, yes
[11:05] <mvo> ogra: fixed in bzr
[11:05] <ogra> gracias :)
[11:10] <cjwatson> kees: I'm merging shadow since I'm also merging user-setup; hope that's ok ...
[13:25] <mib_i6x4ojh7> hi all
[13:41]  * ogra sighs ... what the heck is a text/uri-list decoder plugin
[13:46] <ion_> ogra: Perhaps something that parses various playlist formats?
[13:46] <ogra> yes, apparently, but an apt search doesnt reveal anything
[13:46] <ogra> i should have everything installed but RB still moans
[13:47] <ogra> though i got one radio station working now on my arm board
[13:52] <slangasek> cjwatson: it looks like it's just libc6 that gcc-multilib woud build-depend on for biarch.  So we can do that, though I think that would still be a blemish
[13:53] <slangasek> cjwatson: /usr/share/doc/<package> - I discussed it with guillem after the session, and his plan is to have dpkg keep track of file checksums directly and only allow co-installability if overlapping files match
[13:54] <slangasek> pitti: yeppers - I don't see that suspend/resume problem with my external monitor on my ThinkPad
[13:55] <cjwatson> slangasek: my worry about that was always that it means that non-identical versions implicitly conflict, which seems to me to be a likely source of lurking difficulties for upgrades
[13:55] <cjwatson> or was that the "implicit Replaces: same-binary (<< ${binary:Version}) [different-arch]" thing?
[13:56] <cjwatson> I think I came in half-way through that
[13:57] <slangasek> yeah, that was that one... I think that's effectively what guillem is doing, with the added constraint that two multiarch packages aren't allowed to be configured unless they're at the same version
[13:57] <cjwatson> slangasek: I suspect we also have a number of packages that don't use gzip -n for one reason or another, so that will have to be a requirement for anything with Multi-Arch: set
[13:57] <cjwatson> I fixed two of my own this morning ...
[13:57] <slangasek> ah, ok
[13:58]  * cjwatson vomits at the shadow merge. The chpasswd -S option just got a LOT more complicated
[14:13] <ogra> asac, grmbl ...
[14:27] <kees> Riddell: can you take a look at the libmsn merge?  I'm less familiar with this code, and since it's in Debian now, it's a "real" merge.
[14:28] <asac> ogra: huh?
[14:28] <Riddell> kees: can do
[14:28] <ogra> asac, running firefox remotely through a ssh tunnel uses my local ~/.mozilla dir !
[14:29] <kees> Riddell: thanks!
[14:29] <ogra> i was just surprised how fast FF on the babbage2 runs remotely to then discover all my cache and bookmarks was used locally :/
[14:29] <asac> ogra: only if you have a ff already running locally. yes
[14:30] <ogra> oh, i have indeed
[14:30] <ogra> so it pulls it from ram ?
[14:30] <asac> ogra: but that would make FF run on your system and not on the remote machine
[14:30] <asac> ogra: stop everything
[14:30] <ogra> ok
[14:30]  * ogra tries again
[14:31] <ogra> oh, now i also dont get my prompt back on the babbage, that looks more sane
[14:31]  * ogra hugs asac 
[14:31] <ogra> thanks, seems to work
[14:34] <asac> ogra: if you still need your ffox locally you can export MOZ_NO_REMOTE=1
[14:34] <asac> on remote end and it will not find your locally running FFOX
[14:34] <ogra> ah, good to know
[14:57] <cjwatson> slangasek: james_w would know more precisely but the target is the next couple of months, I believe
[14:58] <cjwatson> kees: fun, isn't it
[14:58]  * soren is laughing on the inside
[14:58] <kees> cjwatson: ah, so I'm late to this realization?
[14:59] <kees> I was just poking at the merge...
[14:59] <cjwatson> kees: see your mail ;-)
[14:59] <cjwatson> I got blocked on it this morning so went ahead ...
[14:59] <kees> d'oh, checking.  still a bit behind...
[15:00] <cjwatson> (sorry if you duplicated work as a result!)
[15:00] <kees> cjwatson: ah, only a few minutes of duplicated work.  I was actually thinking we could just drop all the Ubuntu-changes since everything else is in Debian now.
[15:01] <kees> cjwatson: I was figuring we'd need something to replace "chpasswd -e" eventually.  it's just "now".
[15:02] <kees> cjwatson: trouble is, more than just g-s-t uses chpasswd.  vmbuilder uses chpasswd -e, and I think, d-i, though I'm not sure if it calls it with -e.  (I think not)
[15:02] <soren> d-i accepts encrypted passwords as well.
[15:02] <soren> IIRC, that is.
[15:02] <soren> (by way of preseeding, usually)
[15:02] <cjwatson> yes, it does
[15:03] <cjwatson> d-i is being fixed - that's why I found myself blocked on the merge
[15:03] <soren> Template: passwd/root-password-crypted
[15:03] <soren> Whoops..
[15:03] <cjwatson> kees: chpasswd -S is still outstanding, as is the default to SHA512
[15:04] <kees> cjwatson: well, -S was needed because of g-s-t
[15:04] <cjwatson> (d-i is actually already fixed for this upstream)
[15:04] <kees> the SHA512 default was only needed because of the lack of PAM integration
[15:04] <cjwatson> indeed, and it's still needed until such time as -S is either dropped or converted to PAM
[15:04] <kees> is anything left that reads ENCRYPT_METHOD in the shadow package?
[15:04] <cjwatson> I haven't checked the rest of shadow to see if there's anything left
[15:04] <kees> right
[15:05] <cjwatson> if there was really nothing left, I'd have been sort of surprised if nekral hadn't nuked it with extreme prejudice :)
[15:05] <cjwatson> compatibility with non-PAM systems perhaps
[15:05] <kees> yeah, USE_PAM is in heavy use in the code.
[15:06] <slangasek> lovely PAM, wonderful PAM
[15:06] <kees> I'm all for the merge, which was precipitated (I like to think) by my "-S" patch being proposed.  :P
[15:06] <kees> slangasek: is there a non-insane way to get an encrypted password hash out of PAM?
[15:06] <slangasek> no
[15:06] <slangasek> hth :)
[15:07] <kees> wheee
[15:07] <cjwatson> nekral suggested a custom conversation function of some kind
[15:07] <cjwatson> said he had a patch but didn't elaborate, Fermat-style
[15:07] <slangasek> haha
[15:07] <kees> cjwatson: like, custom-to-the-PAM-stack?  errrg
[15:07] <cjwatson> kees: no idea
[15:07] <kees> I had taken it to mean "custom-to-shadow"
[15:07] <cjwatson> so had I
[15:08] <slangasek> the conversation function would be provided by the calling app
[15:09] <kees> cjwatson: how was d-i fixed to avoid needing "-e" ?
[15:09] <\sh> guys..is there any documentation how the kernel enumerates e.g. NIC interfaces?
[15:09] <ogra> isnt that done by udev ?
[15:09] <kees> \sh: they all start as "eth0", and then udev renumbers them based on /etc/udev/rules.d/70-persistent-net.rules
[15:09] <kees> (roughly)
[15:10] <pitti> s/start as eth0/start in random order/
[15:11] <\sh> kees: yes...that I know..and that's actually a problem...kernel finds e.g. external NICs first, and then the internals..udev enumerates then eth0...ethN which can cause really serious problems...e.g. I don't have the possibility to boot pxe/mount NFS from the external nics...but kernel + udev are telling me, my internal card is eth3
[15:12] <kees> \sh: yeah, you'll want to adjust /etc/udev/rules.d/70-persistent-net.rules if you want to control how they're named.
[15:12] <ogra> there is a kernel commandline option for ipconfig to enfoce a NIC being the first one
[15:12] <ogra> kees, doesnt help with PXE
[15:12] <\sh> kees: sure...that's what I would do when I'm already have an installed system..but using automation for deploying, that doesn't help
[15:13] <kees> ogra: PXE is before the kernel though?
[15:13] <\sh> kees: yes
[15:13] <ogra> right
[15:14] <\sh> kees: 1. pxe, 2. kernel booting via tftp, 3. /scripts/live-premount which does IPConfig: and then there is udev telling me your eth0 is not my eth0 and my eth0 is your eth3 ;)
[15:14] <ogra> i cant remember it from the top of my head, but the guys in #ltsp use it often
[15:14] <kees> \sh: what I did for this in the past was to either pre-populate the image with the NIC MAC I knew was in the machine (since I had that already for the PXE configs), or I wrote scripts in the target that checked interfaces for the right DHCP lease.
[15:14] <kees> but, I'd do whatever ogra says since I've got only small experience with this.  :)
[15:15] <cjwatson> kees: http://bazaar.launchpad.net/~ubuntu-core-dev/user-setup/ubuntu/revision/179 - look at the user-setup-apply bit
[15:15] <\sh> kees: the problem is time ;) kernel boots and then /scripts/live-premount starts and somehow inside this initramfs script there is this IPConfig which takes udevs eth0 which suddenly is not the boot device...
[15:16] <cjwatson> kees: i.e. it uses usermod --password - it can get away with this because d-i controls the entire system and doesn't have to worry about command line visibility in ps
[15:16] <cjwatson> kees: I don't know if there's a better way ...
[15:16] <slangasek> CDBS_REPLACES += , python2.3-moinmoin (<< 1.5.3-1.1), python2.4-moinmoin (<< 1.5.3-1.1)
[15:16] <slangasek> Replaces: ${cdbs:Replaces}
[15:16] <slangasek> Doing. It. Wrong.
[15:16] <cjwatson> kees: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528610
[15:17] <directhex> poor ubottu
[15:18] <soren> Does anyone know where HWCLOCKACCESS (used by /etc/init.d/hwclock) is supposed to be set? I was thinking /etc/default/rcS, but it's not mentioned in the rcS(5) man page.
[15:19]  * ogra knew that once
[15:20] <ogra> soren, /etc/default/rcS should be right, its just not in there by default
[15:20] <kees> cjwatson: what a mess.
[15:20] <soren> ogra: Thanks.
[15:20] <kees> cjwatson: so... now usermod needs a "read stdin for the password" option.  :P
[15:20] <cjwatson> kees: I suspect they might be amenable to restoring -e and making it force non-PAM, judging from bug logs I've seen
[15:21] <cjwatson> but dunno
[15:22] <kees> cjwatson: well, I support the PAM-integration -- but -e and -S are needed to "split" the halves of the PAM stack (select hash, store hash)
[15:23] <ogra> \sh, you want IPOPTS=:::::eth0 (and change eth0 to whatever your device is)
[15:23] <ogra> put that into your append line
[15:23] <ogra> in pxelinux.cfg/default
[15:23] <cjwatson> kees: yes
[15:25] <\sh> ogra: will it tell IPConfig of udev to use this device?
[15:25] <ogra> it will tell ipconfig ... its an ipconfig option
[15:28] <ogra> \sh, http://codtech.com/wiki/index.php/Ipconfig might be helpful
[15:29] <\sh> ogra: well...regarding this...the ipconfig inside initramfs does something wrong
[15:30] <bryce> pitti: for -intel, at the moment xorg-edgers and karmic should be identical.
[15:30] <ogra> how so ?
[15:30] <bryce> pitti: for now, testing xorg-edgers is preferred.
[15:30] <pitti> bryce: good, I'll continue to do so then
[15:31] <bryce> pitti: probably makes sense to keep testing xorg-edgers up until beta or so
[15:31] <\sh> ogra: forget it....I mis-readed the entry...
[15:31] <\sh> and the source
[15:32] <ogra> it doesnt help much with udev shuffling around the names but it helps with enforcing a device name for netbooting
[15:32] <\sh> well...if you have HW which behaves always the same, this is not a problem :)
[15:32] <ogra> right
[15:32] <ogra> and otherwise its trial and error
[15:33] <ogra> might just take multiple attempts
[15:34] <kees> cjwatson: say, can you snag kbd if you're doing merges?  I don't really know that package very well.
[15:47] <slangasek> cjwatson: would you mind doing a review of the lsb packages in {hardy,jaunty}-proposed?
[15:49] <jcastro> bryce: do you have a wiki grid or something for the latest intel driver? or do I just tell you "much better after this upload"?
[15:49] <bryce> jcastro: the latter is fine :-)
[15:50] <bryce> we've gotten enough test results now, we're confident of the path forward now
[15:55] <ogra> jcastro, "awesome in karmic" :)
[15:56] <ion_> awesome in karmic: 3.3~rc4-1
[15:56] <ion_> :-P
[15:58] <ogra> well, stable for me ... and fast as in intrepid :)
[16:00]  * mcasadevall feels like its getting to be the time I should upgrade to Karmic 
[16:00] <ogra> you havent yet !?!
[16:00] <ogra> youre a developer ... eat your own dogfood !!!
[16:01] <mcasadevall> ogra, I won't upgrade until I can run a liveCD to make sure my system won't be hosed after upgrading
[16:01] <mcasadevall> ogra, although I don't think I can put it off much longer
[16:02] <pitti> mcasadevall: it's generally working fine
[16:02] <pitti> mcasadevall: and if -intel should really totally break for you, you can always blacklist i915 to get back X with metacity
[16:02] <mcasadevall> If -intel breaks, I flip the switch and use -nv :-)
[16:02] <mcasadevall> Yay dual graphics cards.
[16:02] <ogra> yeah, i use it day to day since uds
[16:02] <kees> is MoM stalled?  It seems to be a bit behind.
[16:03] <mcasadevall> Hrm, now the question is format and install, or upgrade
[16:03] <cjwatson> kees: sure
[16:03] <cjwatson> slangasek: ok
[16:03] <tormod> mcasadevall: although there is no official live cd, we made an xorg-edgers live cd you can try: http://people.ubuntu.com/~bryce/xorg-edgers-0.1-i386.iso
[16:03] <ogra> mcasadevall, sudo update-manager -d
[16:03] <ion_> mvo: Btw, is posted some comments to https://wiki.ubuntu.com/AptSyncInKarmicSpec (at the end).
[16:03] <cjwatson> BTW, if anyone desperately wants to debug what's happening to unionfs-fuse on the live CD at the moment, I wouldn't say no ...
[16:04]  * ogra will take a look, but not today
[16:04] <ogra> stgraber, did you test it with ltsp btw ?
[16:04] <mcasadevall> cjwatson, what was the specific issue? (I did some debugging into it when working on UDS< but my setup was non-standard enough that I couldhave been seeing a different issue)
[16:05] <cjwatson> mcasadevall: it falls over half-way through, manifesting as login not being able to start /bin/bash
[16:05] <mvo> ion_: nice, have you done some benchmarks with zsync and lookinside gzip yet?
[16:05] <mcasadevall> cjwatson, right, same issue I saw
[16:05] <cjwatson> it basically manages to get most of the way up, so I think it's one specific fuse call that's hosing it
[16:05] <mvo> ion_: as in "how much data will it still need to fetch" ?
[16:06] <mcasadevall> cjwatson, I traced to getting as far as upstart coming up, it destablizes itself after one of the startup scripts, but I didn't isolate it
[16:07] <ion_> mvo: Haven’t got around to that yet.
[16:08] <ion_> mvo: But the look-inside-gzip mode will most likely fetch less data even with gzip --rsyncable.
[16:08] <mvo> ion_: that is my gut-feeling as well, I would love some data on it :)
[16:14] <cjwatson> mcasadevall: I think the problem is with processes running as non-root, but I thought I'd fixed that!
[16:15] <mcasadevall> cjwatson, no, the issue happens while root (which I tested being in single-user on the CD< then running scripts by hand)
[16:15] <cjwatson> I'm definitely seeing symptoms that I know I fixed that way
[16:15] <cjwatson> mcasadevall: the first thing that fails for me is klogd, and the failure is right after it drops privileges to the klog user
[16:16] <cjwatson> I believed I had fixed this by using -o default_permissions -o allow_other -o suid
[16:16] <mcasadevall> If the klogd script is removed, do you get a successful startup?
[16:17] <cjwatson> there are lots of other things broken, I'm not going to waste my time on that kind of check
[16:17] <cjwatson> it's clear that access from other ids is broken (I can reproduce similar things with sudo, for instance) and that's going to break stuff all over the show
[16:17] <cjwatson> I've fixed this before, so I just need to figure out what went wrong with my fix
[16:18] <\sh> ogra: this IPOPTS doesn't work...
[16:23] <Nilbus> what license is ubuntu distributed under?
[16:24] <cjwatson> Nilbus: a wide variety of licences; the basic requirements we place on them are described in http://www.ubuntu.com/community/ubuntustory/licensing
[16:25] <Nilbus> thanks cjwatson
[16:25] <Nilbus> looks like I could have found that googling. sorry to bug
[16:26] <cjwatson> Nilbus: you redeem yourself by being the first person in months to say that, though :-)
[16:26]  * Keybuk waits for the day someone says they could have found that by binging
[16:27]  * ogra glares at the date
[16:27] <Nilbus> cjwatson, ha thanks I guess
[16:27] <Nilbus> :)
[16:27] <slangasek> Keybuk: ...binging?
[16:28] <Keybuk> slangasek: http://www.bing.com/
[16:28] <ogra> slangasek, MS's new toy
[16:28] <slangasek> I could've found that by purging
[16:28] <Keybuk> Microsoft rebranded MS Live Search, and clearly asked for a word people could verb
[16:28]  * rickspencer3 sigh
[16:29] <Keybuk> Microsoft Bing Powered By Microsoft Live Search 3.11 for Workgroups NT
[16:29] <robbiew> I "binged" you...heh
[16:30] <slangasek> Microsoft Bing Seen 2000
[16:30] <robbiew> sounds a bit "nasty" :P
[16:30] <Keybuk> rickspencer3: it's ok, you escaped
[16:30] <rickspencer3> Microsoft Windows Live Bing powered by Microsoft Windows Live Search Technology
[16:30]  * mdeslaur thinks it should have been named "bong" based on the search results it generates
[16:30] <rickspencer3> lol
[16:31] <tedg> I like the pop-up previews on the right though.  That's a nice touch.
[16:32] <maxb> Have you seen how pathetically biased the search results are, though?
[16:32] <maxb> Hint: enter "linux" and look at the top autocompletions :-)
[16:32] <Keybuk> that's awesome
[16:32]  * Keybuk wants Linux Vista
[16:32] <mdeslaur> didrocks: I published a security update for pidgin today. Were you planning on merging pidgin? Do you want me to?
[16:33]  * slangasek wants Linux Olida
[16:33]  * Keybuk wants a Linux Daiquiri
[16:34] <Nilbus> cjwatson, so essentially, does ubuntu not put a license on the distribution as a whole?
[16:34] <cjwatson> Nilbus: that's correct
[16:34] <cjwatson> Nilbus: in many cases, we would actually be violating the licences on other people's code by attempting to do so - most licences don't allow relicensing
[16:34] <slangasek> Keybuk: blech, with all those ground-up kernels in it?
[16:34] <Nilbus> cjwatson, ok. right
[16:34] <Nilbus> make sense
[16:41] <stgraber> ogra: not yet
[16:46] <mdz> it seems neither totem nor totem-gstreamer has the actual binary anymore, is it in some other package now?
[16:47] <cjwatson> totem-gstreamer ships /usr/bin/totem-gstreamer and registers an alternative for /usr/bin/totem
[16:47] <cjwatson> unless this changed since my mirror last pulsed
[16:48] <mdz> perseus:[~] dpkg -L totem-gstreamer | grep bin
[16:48] <mdz> zsh: done       dpkg -L totem-gstreamer |
[16:48] <mdz> zsh: exit 1     grep bin
[16:48] <pitti> mdz, cjwatson: this was discussed in #u-desktop an hour ago
[16:48] <pitti> wrong alternatives cleanup in postinst
[16:48] <mdz> pitti: thanks
[16:48] <pitti> there's debian/lp bugs for it, too, on the way
[16:48]  * slangasek mourns the channel fragmentation
[16:50] <seb128> mdz: should be fixed in 0ubuntu3 which is building
[16:50] <\sh> ogra: btw...this ipopts thing can be written as "ip" (standard kernel commandline as documented) the ubuntu initramfs can actually use it..the lenny one has some problems with it, it seems...
[16:50] <seb128> mdz: sudo apt-get install --reinstall totem to fix it
[16:50] <mdz> seb128: thanks
[16:50] <mdz> seb128: I was just reading the scripts to see if that would fix it, thanks
[16:50] <seb128> mdz: totem-gstreamer is a dummy package, there is only totem which is gstreamer now
[16:51] <mdz> pitti: bug 383187 is the one referenced on #-desktop
[16:51] <ogra> \sh, we share the same initramfs code for netbooting, so thats surprising
[16:51] <mdz> slangasek: indeed
[16:53] <\sh> ogra: this lenny initramfs is using the /usr/share/initramfs-tools/scripts/live* infrastructure on jaunty I didn't see it...but in .../scripts/functions we (ubuntu) have now the configure_networking() bash func which handles the IP/IPOPTS stuff currectly...but the "scripts/live" of debian lenny just did an ipconfig -d ${DEVICE} without checking if there is something in ip/ipopts
[16:53] <ogra> oh, then its actually changed ... we used to usew the  ipconfig -d ${DEVICE} line too before
[16:54] <ogra> i guess sid uses configure_networking() too
[16:55] <ogra> so might be because of the long freeze lenny had
[16:55] <\sh> ogra: I think sid == yes, but lenny == no...I changed it now manually and had the wanted behaviour
[17:07] <didrocks> mdeslaur: please do. If you don't have the time, I can do it
[17:30] <slangasek> hrm, why is ubuntu-bug crashing now :(
[17:31] <ogra> file a bug :P
[17:32] <slangasek> already reported
[17:32] <mcasadevall> cjwatson, I'm trying to understand whats gone wrong with this build failure: http://launchpadlibrarian.net/27284406/buildlog_ubuntu-karmic-ia64.debian-installer_20081029ubuntu39_FAILEDTOBUILD.txt.gz. I've already ruled out the possibility that hdparm-udeb and util-linux-udev have /sbin as a file, but this issue still happens when I tried it yesterday afternoon
[17:33] <pitti> slangasek: on some assertion about the bug title?
[17:33] <slangasek> pitti: yes, bug #383104
[17:34] <pitti> ah, I fixed that this morning
[17:34] <slangasek> pitti: I guess you already fixed this in -3, right :)
[17:34]  * slangasek upgrades to confirm
[17:35] <cjwatson> mcasadevall: but util-linux-udeb *does* have /sbin as a file
[17:35] <cjwatson> $ dpkg -c ~/ubuntu/pool/main/u/util-linux/util-linux-udeb_2.15.1~rc1-1ubuntu1_ia64.udeb
[17:35] <cjwatson> drwxr-xr-x root/root         0 2009-05-29 12:42 ./
[17:35] <cjwatson> (not ia64-specific)
[17:35] <cjwatson> -rwxr-xr-x root/root     24992 2009-05-29 12:42 ./sbin
[17:36] <mcasadevall> o__o;
[17:36] <mcasadevall> (argh, I'm an idiot, but thats a separate issue)
[17:36] <mcasadevall> Now the question is how did that happen
[17:36] <cjwatson> mcasadevall: I suspect debian/rules forgets to create a directory before using install(1)
[17:39] <slangasek> pitti: yeesh, enough changelog symlink indirection in apport? :P
[17:40] <pitti> slangasek: hm?
[17:40] <slangasek> once again, changelog symlinks without strict versioned dep == bad
[17:40] <pitti> oh, that
[17:40] <slangasek> pitti: I tried to manually upgrade apport.  I'm having to manually upgrade two more packages to actually get the matching changelog.
[17:43] <ion_> mvo: https://wiki.ubuntu.com/AptSyncInKarmicSpec updated.
[17:46] <cjwatson> mcasadevall: http://paste.ubuntu.com/187511/ should fix it
[17:46] <maxb> apt-sync? Interesting. Why not pdiff/rred ?
[17:46] <cjwatson> (against the ubuntu/master branch of lamont's git repository)
[17:47]  * cjwatson wanders off for the evening
[17:47] <mcasadevall> Ow, git :-/
[17:47] <cjwatson> I suggest making either lamont or Keybuk do the actual commit and upload ;-)
[17:48] <mcasadevall> cjwatson, probably a good idea :-). Thanks for your assistance on my blind eye :-/.
[17:48] <lamont> mcasadevall: which version of util-linux, I wonder?
[17:49] <lamont> as in this is 2.15.1?
[17:49] <cjwatson> lamont: current in karmic
[17:50] <cjwatson> 2.15.1~rc1-1ubuntu1
[17:50] <mcasadevall> lamont, its whatever is in karmic: util-linux-2.15.1~rc
[17:50] <mcasadevall> ^1
[17:50] <cjwatson> lamont: I think my original patch to add the udeb was correct, but it looks as if the new file debian/util-linux-udeb.dirs got lost somewhere along the way
[17:51] <cjwatson> lamont: and because util-linux IMO unwisely uses install(1) without a trailing slash on the target directory name, rather than a build failure, this resulted in a busted udeb
[17:51] <mcasadevall> lamont, if you could fix it, it should get up 90% of the way of d-i building, and once d-i builds, ia64 alternate and livecds should build.
[17:51]  * mcasadevall suspects he'll still need to nudge d-i's scripts to get it a large enough partition to plop a kernel onto
[17:51] <cjwatson> err, and indeed ln(1) etc.
[17:51] <slangasek> pochu: it appears you're responsible for the change that causes seahorse gpg-agent to no longer be running by default - should seahorse-plugins be a Recommends: of seahorse instead of a Suggests:?
[17:51] <mvo> ion_: sweet
[17:52] <slangasek> (if we're not going to run the gpg agent, I can't see why we would want seahorse itself installed by default at all...)
[17:53] <cjwatson> lamont: I'd recommend something like http://paste.ubuntu.com/187514/ for future robustness
[17:53] <seb128> slangasek: seahorse is the tools you use to handle gnome-keyring passwords too
[17:53] <cjwatson> ok, really gone
[17:54] <seb128> slangasek: we had this discussion with pitti and he thinks that the gpg agent is not a standard user feature and cost some login time
[17:54] <lamont> cjwatson: now I just need to figure out if it's me or keybuk that I need to thwap
[17:56] <slangasek> seb128: which bit of this is used for handling gnome-keyring passwords, then?  I can't even find this in the GNOME menu
[17:56] <seb128> slangasek: applications, accessories, seahorse
[17:56] <slangasek> heh
[17:57] <seb128> or "key and password" or whatever is the english wording
[17:57] <slangasek> "accessories" - not intuitive :)
[17:57] <slangasek> "Passwords and Encryption keys"
[17:59] <elmo> pitti: do you know of any bugs to do with cups where printers you've seen announced once never go away and can't be deleted?
[18:00] <pitti> elmo: not off-hand (I'm not really following the bug reports on cups)
[18:00] <pitti> elmo: I guess they are stuck in /var/cache/cups/remote.cache ?
[18:01] <elmo> pitti: yeah
[18:01] <pitti> elmo: you can't delete those with lpadmin/web UI, since they aren't really "there" locally
[18:03] <elmo> pitti: I guess I'm just surprised they don't time out of their own accord
[18:03] <pitti> elmo: they should; they do here
[18:04] <slangasek> seb128: the other thing I don't understand is why the Debian changelog moved the Xsession file in 2.24.1, saying "the agent is now in seahorse-plugins", but with 2.26 in jaunty it was working just fine for me, seemingly without seahorse-plugins installed
[18:04] <ion_> mvo: Added a short summary to the bottom.
[18:04] <slangasek> seb128: ah, n/m; I see now that seahorse-plugins was removed on upgrade
[18:04] <seb128> slangasek: searhose-plugins was installed in jaunty
[18:04] <slangasek> right
[18:04] <seb128> we used a recommends where debian is using a suggests
[18:06] <slangasek> should seahorse-plugins also Provides: gnupg-agent?
[18:07] <slangasek> seb128: btw, do you know why the g-p-m icon theme is broken for me, before I go filing a bug?
[18:08] <seb128> no
[18:08] <slangasek> ok
[18:08] <seb128> slangasek: no idea about gnupg-agent are those equivalent?
[18:09] <slangasek> well, there's no defined virtual package for it - but it implements the gnupg agent protocol
[18:09] <slangasek> and a Provides: would've been discoverabel
[18:13] <slangasek> seb128: bug #383256 filed, anyway, so that there's at least a record in LP of why the desktop team thinks I'm wrong :)
[18:13] <seb128> slangasek: thanks
[18:31] <mdeslaur> didrocks: actually, someone has already started it: LP #380806
[18:42] <pitti> good night everyone
[18:42] <ion_> Night
[18:44] <ion_> mvo: Updated the latest benchmark with what happens with method #3 if inputfile hasn’t been packed with --rsyncable.
[18:56] <stefanlsd> slangasek: do you know any packages using dep5 debian/copyright that I could see?
[18:56] <dupondje> could somebody plz check https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/383271
[18:56] <dupondje> its my first merge, so hope its correct :)
[18:59] <stefanlsd> dupondje: better to ask in #ubuntu-motu
[19:03] <slangasek> stefanlsd: not yet; the dep5 is still in flux
[19:03] <stefanlsd> slangasek: ok thanks! i was doing a package for revu - is it ok to use?
[19:04] <slangasek> stefanlsd: I don't think *any* of the machine-readable copyright formats provide very good guidance about their use yet; whether or not it's ok for revu is not my call, but I would recommend using something that other people are already using
[19:05] <slangasek> directhex: I see mono's on the merge list again; is that in a syncable state now?
[19:07] <stefanlsd> slangasek: thanks
[19:17] <pochu> slangasek: that makes sense, yes
[19:17] <pochu> (bumping seahorse-plugins to a Recommends)
[19:17] <slangasek> pochu: see subsequent discussion with seb128; turns out that this *was* a Recommends previously
[19:18] <slangasek> in Ubuntu
[19:18] <slangasek> and it's been dropped
[20:10] <xenocampanoli> Subject:  trying to compile libldap-ruby I get ldap.c:424: error: ‘LDAP_OPT_X_TLS_PROTOCOL’ undeclared (first use in this function).  This is shown as a macro only in my /usr/include/ldap.h.  Another told me it is commented out in his /usr/include/openldap.h, but I do not have one of those.
[20:27] <xenocampanoli> Subject:  trying to compile libldap-ruby I get ldap.c:424: error: ‘LDAP_OPT_X_TLS_PROTOCOL’ undeclared (first use in this function).  This is shown as a macro only in my /usr/include/ldap.h.  Another told me it is commented out in his /usr/include/openldap.h, but I do not have one of those.
[21:19] <kees> pitti: I have some updates in lp:~kees/apport/apport.segv-analysis for you
[21:24] <nxvl> slangasek: ping
[21:26] <slangasek> nxvl: hi
[21:28] <joaopinto> pitti, I have learned that kubuntu is going to use packagekit as the default installer for karmic, do you have any idea how they plan to address those limitations you described earlier ?
[21:29] <nxvl> slangasek: about exim4 -> postfix mail on devel, i just made the list of the package depending on those two, don't you think it will be usefull to put a wiki page with those to make the change?
[21:29] <nxvl> slangasek: or at least to make that information available for people that want to help
[21:30] <lamont> nxvl: I'll be uploading postfix 2.6.2~rc1-1 to sid today, which will DTRT on ubuntu once synced to karmic
[21:30] <nxvl> lamont: mmm, have you read the e-mail steve sended?
[21:30] <slangasek> nxvl: no objections, but I'm not really looking to make a campaign out of this - just to let people know there's a way to get rid of existing deltas as they're doing merges
[21:30] <lamont> nxvl: lalalala
[21:31] <lamont> nxvl: the upload of postfix is to have it Provide: default-mta on ubuntu
[21:31] <nxvl> slangasek: so, is not a goal for karmic?
[21:31] <nxvl> lamont: ohh!! got it!
[21:31] <lamont> nxvl: and no, haven't actually read the email, though I suspect the discussion I had with slangasek trumps it
[21:31] <nxvl> lamont: i was confused about that :P
[21:32] <slangasek> lamont: no, the email in question was letting ubuntu-devel know default-mta was open for the using
[21:32] <slangasek> nxvl: <shrug> it's not a goal of *mine* for karmic :)
[21:32] <nxvl> lamont: yup, that said now it makes sense, your first comment sounded off-topic to me, but now i get the full idea of why you said it
[21:32] <lamont> slangasek: right.  trumped by our discussion (or confirmed, or whatever...)
[21:32] <lamont> nxvl: postfix already knows whether it's building on ubuntu or debian
[21:32] <lamont> so one more bit of abuse doesn't hurt, right?
[21:33] <nxvl> lamont: really? awesome
[21:33] <lamont> yeah - because no way I'm going to maintain a fork (for 5 years now) just to get the banner to be different between debian and ubuntu
[21:33]  * slangasek NMUs postfix to Debian and builds it on Ubuntu, teehee
[21:34] <lamont> gigglr
[21:43] <lamont> if [ $(DISTRO) = Ubuntu ]; then echo postfix:Provides=default-mta >> debian/postfix.substvars; fi
[21:43] <lamont> see... that's easy
[21:44] <lamont> slangasek: please sync postfix 2.6.2~rc1-1 from sid kthx
[21:45] <lamont> though if you wait until the next dinstall run, it'll be in sid instead of incoming...
[21:45]  * slangasek will wait for dinstall
[21:45] <lamont> lazy
[21:45] <slangasek> yes
[21:45] <lamont> though it wouldn't be any work to upload 2.6.2~rc1-0build1....
[21:46] <lamont> though that should be -1~0build1
[21:46] <slangasek> you can if you wish :)
[21:46] <mweichert> is it possible to run gvfs outside of gnome or X?
[21:47] <lamont> slangasek: the exim in karmic doesn't provide: default-mta, right?
[21:47] <slangasek> lamont: right
[21:47] <slangasek> (as of about the time I pinged you about this :)
[21:48] <lamont> uploaded
[21:48] <lamont> er, ing
[21:49] <lamont> slangasek: and nothing from 2.5.5-1.1ubuntu1 I need to worry about, right?
[21:49] <lamont> as in - I'm gonna totally ignore that ever existed
[21:50] <slangasek> the only change was the default-mta bit
[21:52] <lamont> yay
[21:52] <lamont> and 2.6.2 will release sometime soonish, so I'm not too caring about the ~rc1 bit of that version
[21:53] <lamont> that and Wietse is pedantically anal about stable updates
[22:09] <calc> anyone else notice firefox seems more laggy than usual lately?
[22:09] <calc> oh, in karmic
[22:11] <cody-somerville> calc, My new P8600 and 4GBs of ram makes everything seem fast.
[22:11] <calc> i have the same and its lagging badly for some reason
[22:12] <calc> like pageup/pagedown even lags
[22:12] <xenocampanoli> Subject:  trying to compile libldap-ruby I get ldap.c:424: error: ‘LDAP_OPT_X_TLS_PROTOCOL’ undeclared (first use in this function).  This is shown as a macro only in my /usr/include/ldap.h.  Another told me it is commented out in his /usr/include/openldap.h, but I do not have one of those.
[22:14] <slangasek> xenocampanoli: this is not a help channel; but the libldap-ruby package in Ubuntu appears to be built just fine, perhaps you're using some ldap.h other than the one from Ubuntu?
[22:15] <jelmer> tedg: hi
[22:16] <tedg> jelmer: Hello.
[22:17] <jelmer> tedg, jam and I managed to fix the bug you were hitting in bzr during UDS
[22:17] <jelmer> tedg, I've just submitted the fix to PQM
[22:17] <tedg> jelmer: Whoo!  Hooo!  Many thanks!
[22:17] <jelmer> tedg, There was also another issue, caused by an early bzr-svn bug that has been fixed now.
[22:17] <tedg> jelmer: So is there a snapshot that I can grab then?  I don't think that bzr-svn is in the bzr nightly PPA, right?
[22:18] <jelmer> tedg: That bzr-svn bug has been fixed, but your bzr branches on launchpad seem to've been created with an older version of bzr-svn that had that bug so those branches are broken.
[22:19] <jelmer> tedg: You'll need a nightly version of bzr, and probably to ditch and recreate your existing inkscape branches on Launchpad from svn
[22:19] <tedg> jelmer: Ah, okay.  That's fine.  I'll recreate.  Can I merge the old ones in?  Will that create something useful?
[22:22] <xenocampanoli> slangasek:  No, the libldap-ruby package has a bug (https://bugs.launchpad.net/ubuntu/+source/libldap-ruby/+bug/381791) on Ubuntu Server and I am trying to compile it in a standard environment to get diagnostics for that bug, and it won't for me.  Perhaps I am leaving out a step.
[22:22] <xenocampanoli> Oh yeah.  That's my bug.  See my name? ;^)
[22:23] <xenocampanoli> slangasek:  I am using a standard environment.  Is there another place I should seek this help?
[22:26] <jelmer> tedg: I'm not sure if that would do anything meaningful. If possible, it would be best to just keep the two separate.
[22:26] <jelmer> tedg, And sorry this took so long.
[22:27] <tedg> jelmer: No problem.  Happy that it's fixed.  I've been using SVN...  remember those days all too fondly now :)
[22:32] <slangasek> xenocampanoli: ok, I can confirm the build failure in karmic
[22:33] <slangasek> xenocampanoli: apparently libldap-ruby assumes LDAP_OPT_X_TLS_PROTOCOL is a constant, not a macro w/ arguments.
[22:34] <slangasek> xenocampanoli: so I would say this is an upstream bug in libldap-ruby
[22:37] <prefrontal> i need -fprofile-correction from gcc 4.4 but i'm using jaunty and its in karmic
[22:38] <xenocampanoli> Thank you.  I haven't put the compiler in as a bug, only my other problems.  Do you want me to do so?
[22:38] <xenocampanoli> slangasek:  Thank you.  I haven't put the compiler in as a bug, only my other problems.  Do you want me to do so?
[22:39] <xenocampanoli> slagasek:  compiler error that is.
[22:39] <slangasek> xenocampanoli: filing a bug report would be advisable :)
[22:39] <xenocampanoli> slangasek.  I'll put a number here when I'm done.
[22:40] <prefrontal> installing a package like gcc from a newer dist could be problematic. it likely requires libc etc...
[22:40] <prefrontal> not advisable?
[22:40] <prefrontal> or are jaunty/karmic still fairly binary compatible
[22:44] <xenocampanoli> slangasek:  https://bugs.launchpad.net/ubuntu/+source/libldap-ruby/+bug/383371
[22:44] <xenocampanoli> slangasek:  Please I am open to suggestions on this bug environment and its standardsd.
[22:53] <xenocampanoli> slangasek:  I know if you can formally confirm 383371 it will likely expedite it's handling.
[22:56] <slangasek> xenocampanoli: realistically, expediting it means finding a developer who uses ruby; it seems this same bug has been open on the Debian package for over two months, and the Debian maintainer hasn't taken any action yet
[22:58] <xenocampanoli> slangasek:  Well, I may not be competent to debug encryption stuff, but if I am allowed, and with help regarding the architecture, I can probably come up with the solution.  I've written near 100,000  lines of C in my life, though mostly over 10 years ago.
[22:59] <slangasek> this particular build failure could be fixed by commenting out the lines referring to LDAP_OPT_X_TLS_PROTOCOL
[22:59] <xenocampanoli> slagasek:  Trouble is, I will need to decide the intentions of the developer in charge for this macro.
[22:59] <slangasek> I don't know if that's a correct fix
[23:00] <xenocampanoli> slangasek:  Yes, I will need to study the code more.  How do we discover if the code has been orphaned?  I have an email into the maintainers listed in the README.
[23:01] <slangasek> xenocampanoli: hopefully there's also accurate information in debian/copyright that can be used to contact upstream
[23:01] <amitk> hmm.. I lost my gdm login screen after an upgrade to karmic on my 32-bit laptop
[23:01] <xenocampanoli> slangasek:  I don't have an account in the Debian area, only on launchpad.  Perhaps I should do that...?
[23:02] <slangasek> xenocampanoli: debian/copyright is the file in the source package.  And the Debian BTS doesn't use accounts, it's email-only
[23:02] <YokoZar> Just uploaded the first branding-ubuntu package.  So far all it has is a new gnometris theme
[23:03] <YokoZar> https://wiki.ubuntu.com/branding
[23:05] <slangasek> amitk: KMS?
[23:05] <xenocampanoli> slangasek: Oh, Yes, that's where I got Ian's and Akira's email addresses.  Sorry.  The copyright's in the readme were in fact what I got the emails from.
[23:06] <xenocampanoli> slangasek:  So, presumably if I come up with a solution, I can post that on the bug and at least it is likely to get used at some point...???
[23:06] <slangasek> xenocampanoli: if you find a solution, I suggest you follow https://wiki.ubuntu.com/SponsorshipProcess to get the fix included in Ubuntu
[23:06] <amitk> slangasek: default upgrade. Haven't yet enabled KMS.
[23:07] <slangasek> amitk: oh.  UXA? :)
[23:07] <xenocampanoli> slangasek:  Thank you for confirming and all your help.
[23:09] <amitk> slangasek: xorg.conf had a 'virtual' line that seemed to be causing the problem
[23:29] <dtchen> TheMuso: WRT desktop-karmic-audio-experience: will do
[23:29] <TheMuso> dtchen: thanks
[23:34] <Riddell> joaopinto: we already have kpackagekit as our package manager in jaunty
[23:34] <Riddell> its main limitation is not being able to install java, that's a pain but I can live with that with openjdk
[23:55] <andre> hello... iam using ubuntu9.04 with gnome... anyone knows how to change from utf8 to iso8859-15? on console i already have changed. but it seems that nautilus is creating files with UTF8-names