=== beuno_ is now known as beuno [00:04] nixternal: seems like no sound hardware was found on your system at all, re your bug 382968 [00:04] Launchpad bug 382968 in alsa-driver "Sound works for system notifications through the PC speaker - no sound at all with multimedia apps" [Undecided,New] https://launchpad.net/bugs/382968 [00:09] TheMuso: ya, dtchen has already fixed the issue :) [00:09] oh? [00:09] ok [00:09] ya, during upgrade from jaunty -> karmic, somehow my user was removed from the audio group [00:09] ah [00:09] how I missed that is beyond me [00:09] haha [00:11] 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] I thought ubuntu didn't use the audio group anymore? [00:12] It doesn't. [00:12] johanbr: correct for ubuntu jaunty, which uses pulseaudio alongside consolekit [00:12] dtchen: I'm not in audio on my jaunty box here at work [00:12] its all policykit driven. [00:12] the only deriv that adds the user to the audio group is studio. [00:12] intrepid too [00:12] (user-setup 1.20ubuntu3) [00:12] are there some differences with groups between kubuntu & ubuntu there? [00:12] not as far as the installer is concerned [00:12] * ajmitch would hope not [00:14] 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] (it sets them to 'adm audio cdrom dialout lpadmin plugdev sambashare' right now) [00:14] alright [00:14] which in fact just adds audio over the default [00:14] ow, wrong side of midnight, bed [00:14] g'night [00:14] night === beuno_ is now known as beuno === asac_ is now known as asac [01:27] ugh, it's possible for pulseaudio to completely wedge the HDA controller, requiring an /sbin/alsa force-reload to restore functionality. :( [01:43] eew [01:47] dtchen: I'm not surprised, I was seeing a complaint of sound totally dying in another nz channel today [02:23] 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] 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] Particularly in here. [02:25] 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] 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] TheMuso+1 [03:51] 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] (at which point gcc-multilib can stay as it is, rather than needlessly shuffling the problem down the line) [03:52] 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] {arch} ? [03:59] We're running out of brackets [04:01] StevenK: *smack* [04:03] {([arch])} [04:06] {arch} was a control dir for tla [04:06] Yes, and I was using it in the context of debian/control, not a directory name [04:08] all the same [04:08] don't propogate the scarin [04:08] g [04:08] It would be used like {i386} [04:09] lifeless: Or do you just twitch when you read {arch} ? :-P [04:10] * lifeless twitches [06:34] 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] TheMuso: if you have a minute, I'd appreciate some guidance on dmraid startup [06:57] lifeless: if you are referring to your diffs in those bugs, I am about to get to those., [06:57] c [06:57] woops wrong window [06:58] TheMuso: to the apparent way that udev is calling dmraid-activate four times with 'no' 'block' 'devices' 'found' [06:58] 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] 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] TheMuso: When you can that would rock [07:12] ok [07:12] TheMuso: The only theory I have at the moment is that the no block devices found array is coming from dmraid itself [07:13] or something linked to the same lib [07:13] Right. [07:13] but I'm damned if I can see the freaking cause [07:13] hrm a brain wave. It could be mkid/whatever vol_id's replacement was. [07:14] 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] WHich means more patching is needed. [07:14] \o/ [07:14] is vol_id calledbefore dmraid ? [07:15] Yes. [07:15] or after? if vol_id is called on the dmraid mapper device it would be fine [07:15] Not in the dmraid rule, but in other rules. [07:15] hrm not sure if this the problem now, but can't think of what else it is currently. [07:17] sorry its blkid [07:17] thanks [07:17] I shall poke tomorrow [07:18] ls [07:18] woops [07:18] ok [07:19] in util-linux source package, you want libs/blkid/src/probers/isw_raid.c === hunger_t is now known as hunger [07:29] Good morning [07:31] 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] slangasek: the other problem that I have is that suspend/resume is broken with external monitor (doesn't get switched on again) [07:31] otherwise it's working quite well [07:33] pitti: an upload for the intel driver was made today. You tried that yet? [07:33] TheMuso: I have used the xorg-edgers PPA, I get updates practically daily [07:33] pitti: ah ok. [07:33] during UDS, karmic was totally broke for me [07:33] broken [07:33] 2.7.1 wedged everything [07:35] bryce: thanks for the new -intel upload [07:36] bryce: would you rather have people test xorg-edgers or karmic? [07:36] pitti: it fixes or fucks? [07:36] lifeless: xorg-edgers makes everything work like a charm again [07:36] pitti: but bryces' upload to karmic? [07:37] lifeless: didn't try that yet [07:37] well, actually I did [07:37] I have 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu0sarvatt [07:37] and bryce uploaded 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1 [07:37] so I guess they are by and large identical [07:37] ok cool [07:37] the PPA also has a newer mesa etc., though [07:37] I won't avoid updating then ;) === tkamppeter_ is now known as tkamppeter [08:20] 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] 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] 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] slangasek: we didn't really discuss the problem of /usr/share/doc// at UDS - I see there are several options for that in the spec but I don't recall us settling on something [08:29] 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] please help out with http://people.ubuntu.com/~dholbach/sponsoring - the list is growing! :-/ [08:40] growing to devour us all? [08:41] dholbach++ [08:41] 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] cjwatson: it does, in my patch [08:45] (dmraid--activate checking $?) [08:46] dholbach: useful list, it shows me a bug I missed in the changelog [08:46] and also some merge duplication, unfortunately [08:46] 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] 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] 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] 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] 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] 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] - - [08:51] - - [08:51] - - [08:51] but agreed, we should tackle this list ;-) [08:51] haha :) [08:52] hey Hobbsee [08:52] seb128: heya! [08:52] seb128: I'm sure you'll find it relaxing to review a few patches between writing one spec and the other [08:53] dholbach: lol :-P [08:53] 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] seb128: yeah, maybe it could be an option in your Typing Break from GNOME :-P [08:56] locking the screen every hour "now it's time for doing some sponsoring"? ;-) [08:56] Heh [08:56] seb128: lol :-P [08:57] or dholbach calling your house every hour to remind you === sabdfl1 is now known as sabdfl [10:14] 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] StevenK: check process-removals? [10:14] Debian should have removed pretty much all gnome 1 rdepends [10:15] apt-cache rdepends libgnomesupport0 [10:15] [10:15] hmm [10:15] StevenK: if you find some, just ditch them [10:15] I checked one, and it hasn't been removed in Debian [10:15] I suspect it will be [10:19] Riddell: do you know whether KDE relies on hal's camera.libgphoto2.* properties? === quadrispro1 is now known as quadrispro [10:19] Riddell: or info.capabilities == camera? [10:20] Riddell: in other words, if /usr/share/hal/fdi/preprobe/10osvendor/20-libgphoto2.fdi would go away, woudl anything break? [10:20] pitti: no idea, I can ask though [10:22] pitti: I'm told it relies on both [10:22] meh, ok [10:22] pitti: what would replace it? devicekit? [10:23] Riddell: for PtP cameras you can just use libudev and ask udev [10:23] for the ancient custom protocol ones we still need something like it [10:23] we'll probably need to keep the list around, and just rewrite it as udev rules [10:24] Riddell: I'll think about it, thanks for checking [10:38] 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] soren, "aptitude show"? [10:42] soren, there's this whole "Automatically installed:" line you might like [10:42] directhex: Blimey, there it is. *facepalm* [10:42] directhex: Thanks. [10:43] (aptitude search gives it, too) === ogra_ is now known as ogra [10:48] soren: it'd be nice if apt-mark let you query that state as well as set it ... [10:49] cjwatson: Hm.. Never heard of apt-mark before. Looks handy. Thanks. [10:51] 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] (btw) [10:53] cjwatson: good point [10:54] ion_: apt and aptitude use a shared database since some time for the auto flag [10:55] mvo: “All”, as in debfoster as well. [10:55] Perhaps aptitude gains debfoster-like functionality some day. That would be nice. [10:55] ion_: aha, ok. debfoster should probably be modified to use the extended_states file as well [10:59] mvo, could you drop the blacklisting for i945GM from compiz in karmic ? [10:59] the new driver works just fine [10:59] mvo: Oh, btw, since i finally manage to be online simultaneously with you: please check out the debdiff in LP #377065. :-) [10:59] Launchpad bug 377065 in command-not-found "zsh_command_not_found should use the pre*_functions arrays instead of overwriting the singular preexec/precmd functions" [Undecided,New] https://launchpad.net/bugs/377065 [11:00] ion_: thanks, I have a look now [11:00] ogra: yes [11:00] mvo, thanks :) [11:04] ogra: GM965 you mean? [11:05] mvo, 8086:2a02, yes [11:05] ogra: fixed in bzr [11:05] gracias :) [11:10] kees: I'm merging shadow since I'm also merging user-setup; hope that's ok ... === azeem_ is now known as azeem === dyfet_ is now known as dyfet [13:25] hi all === beuno_ is now known as beuno [13:41] * ogra sighs ... what the heck is a text/uri-list decoder plugin [13:46] ogra: Perhaps something that parses various playlist formats? [13:46] yes, apparently, but an apt search doesnt reveal anything [13:46] i should have everything installed but RB still moans [13:47] though i got one radio station working now on my arm board [13:52] 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] cjwatson: /usr/share/doc/ - 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] pitti: yeppers - I don't see that suspend/resume problem with my external monitor on my ThinkPad === mok01 is now known as mok0_laptop [13:55] 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] or was that the "implicit Replaces: same-binary (<< ${binary:Version}) [different-arch]" thing? [13:56] I think I came in half-way through that [13:57] 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] 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] I fixed two of my own this morning ... [13:57] ah, ok [13:58] * cjwatson vomits at the shadow merge. The chpasswd -S option just got a LOT more complicated [14:13] asac, grmbl ... [14:27] 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] ogra: huh? [14:28] kees: can do [14:28] asac, running firefox remotely through a ssh tunnel uses my local ~/.mozilla dir ! [14:29] Riddell: thanks! [14:29] 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] ogra: only if you have a ff already running locally. yes [14:30] oh, i have indeed [14:30] so it pulls it from ram ? [14:30] ogra: but that would make FF run on your system and not on the remote machine [14:30] ogra: stop everything [14:30] ok [14:30] * ogra tries again [14:31] oh, now i also dont get my prompt back on the babbage, that looks more sane [14:31] * ogra hugs asac [14:31] thanks, seems to work [14:34] ogra: if you still need your ffox locally you can export MOZ_NO_REMOTE=1 [14:34] on remote end and it will not find your locally running FFOX [14:34] ah, good to know === sconklin-afk is now known as sconklin [14:57] slangasek: james_w would know more precisely but the target is the next couple of months, I believe [14:58] kees: fun, isn't it [14:58] * soren is laughing on the inside [14:58] cjwatson: ah, so I'm late to this realization? [14:59] I was just poking at the merge... [14:59] kees: see your mail ;-) [14:59] I got blocked on it this morning so went ahead ... [14:59] d'oh, checking. still a bit behind... [15:00] (sorry if you duplicated work as a result!) [15:00] 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] cjwatson: I was figuring we'd need something to replace "chpasswd -e" eventually. it's just "now". [15:02] 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] d-i accepts encrypted passwords as well. [15:02] IIRC, that is. [15:02] (by way of preseeding, usually) [15:02] yes, it does [15:03] d-i is being fixed - that's why I found myself blocked on the merge [15:03] Template: passwd/root-password-crypted [15:03] Whoops.. [15:03] kees: chpasswd -S is still outstanding, as is the default to SHA512 [15:04] cjwatson: well, -S was needed because of g-s-t [15:04] (d-i is actually already fixed for this upstream) [15:04] the SHA512 default was only needed because of the lack of PAM integration [15:04] indeed, and it's still needed until such time as -S is either dropped or converted to PAM [15:04] is anything left that reads ENCRYPT_METHOD in the shadow package? [15:04] I haven't checked the rest of shadow to see if there's anything left [15:04] right [15:05] if there was really nothing left, I'd have been sort of surprised if nekral hadn't nuked it with extreme prejudice :) [15:05] compatibility with non-PAM systems perhaps [15:05] yeah, USE_PAM is in heavy use in the code. [15:06] lovely PAM, wonderful PAM [15:06] I'm all for the merge, which was precipitated (I like to think) by my "-S" patch being proposed. :P [15:06] slangasek: is there a non-insane way to get an encrypted password hash out of PAM? [15:06] no [15:06] hth :) [15:07] wheee [15:07] nekral suggested a custom conversation function of some kind [15:07] said he had a patch but didn't elaborate, Fermat-style [15:07] haha [15:07] cjwatson: like, custom-to-the-PAM-stack? errrg [15:07] kees: no idea [15:07] I had taken it to mean "custom-to-shadow" [15:07] so had I [15:08] the conversation function would be provided by the calling app [15:09] 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] isnt that done by udev ? === You're now known as ubuntulog [15:09] \sh: they all start as "eth0", and then udev renumbers them based on /etc/udev/rules.d/70-persistent-net.rules [15:09] (roughly) [15:10] 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] \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] there is a kernel commandline option for ipconfig to enfoce a NIC being the first one [15:12] 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] ogra: PXE is before the kernel though? [15:13] <\sh> kees: yes [15:13] 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] i cant remember it from the top of my head, but the guys in #ltsp use it often [15:14] \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] but, I'd do whatever ogra says since I've got only small experience with this. :) [15:15] 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] 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] kees: I don't know if there's a better way ... [15:16] CDBS_REPLACES += , python2.3-moinmoin (<< 1.5.3-1.1), python2.4-moinmoin (<< 1.5.3-1.1) [15:16] Replaces: ${cdbs:Replaces} [15:16] Doing. It. Wrong. [15:16] kees: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528610 [15:16] Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528610;mbox=yes) [15:17] poor ubottu [15:18] 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] soren, /etc/default/rcS should be right, its just not in there by default [15:20] cjwatson: what a mess. [15:20] ogra: Thanks. [15:20] cjwatson: so... now usermod needs a "read stdin for the password" option. :P [15:20] 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] but dunno [15:22] 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] \sh, you want IPOPTS=:::::eth0 (and change eth0 to whatever your device is) [15:23] put that into your append line [15:23] in pxelinux.cfg/default [15:23] kees: yes [15:25] <\sh> ogra: will it tell IPConfig of udev to use this device? [15:25] it will tell ipconfig ... its an ipconfig option [15:28] \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] pitti: for -intel, at the moment xorg-edgers and karmic should be identical. [15:30] how so ? [15:30] pitti: for now, testing xorg-edgers is preferred. [15:30] bryce: good, I'll continue to do so then [15:31] 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] 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] right [15:32] and otherwise its trial and error [15:33] might just take multiple attempts [15:34] cjwatson: say, can you snag kbd if you're doing merges? I don't really know that package very well. [15:47] cjwatson: would you mind doing a review of the lsb packages in {hardy,jaunty}-proposed? [15:49] 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] jcastro: the latter is fine :-) [15:50] we've gotten enough test results now, we're confident of the path forward now [15:55] jcastro, "awesome in karmic" :) [15:56] awesome in karmic: 3.3~rc4-1 [15:56] :-P [15:58] 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] you havent yet !?! [16:00] youre a developer ... eat your own dogfood !!! [16:01] ogra, I won't upgrade until I can run a liveCD to make sure my system won't be hosed after upgrading [16:01] ogra, although I don't think I can put it off much longer [16:02] mcasadevall: it's generally working fine [16:02] mcasadevall: and if -intel should really totally break for you, you can always blacklist i915 to get back X with metacity [16:02] If -intel breaks, I flip the switch and use -nv :-) [16:02] Yay dual graphics cards. [16:02] yeah, i use it day to day since uds [16:02] is MoM stalled? It seems to be a bit behind. [16:03] Hrm, now the question is format and install, or upgrade [16:03] kees: sure [16:03] slangasek: ok [16:03] 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] mcasadevall, sudo update-manager -d [16:03] mvo: Btw, is posted some comments to https://wiki.ubuntu.com/AptSyncInKarmicSpec (at the end). [16:03] 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] stgraber, did you test it with ltsp btw ? [16:04] 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] mcasadevall: it falls over half-way through, manifesting as login not being able to start /bin/bash [16:05] ion_: nice, have you done some benchmarks with zsync and lookinside gzip yet? [16:05] cjwatson, right, same issue I saw [16:05] 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] ion_: as in "how much data will it still need to fetch" ? [16:06] 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] mvo: Haven’t got around to that yet. [16:08] mvo: But the look-inside-gzip mode will most likely fetch less data even with gzip --rsyncable. [16:08] ion_: that is my gut-feeling as well, I would love some data on it :) [16:14] mcasadevall: I think the problem is with processes running as non-root, but I thought I'd fixed that! [16:15] cjwatson, no, the issue happens while root (which I tested being in single-user on the CD< then running scripts by hand) [16:15] I'm definitely seeing symptoms that I know I fixed that way [16:15] 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] I believed I had fixed this by using -o default_permissions -o allow_other -o suid [16:16] If the klogd script is removed, do you get a successful startup? [16:17] there are lots of other things broken, I'm not going to waste my time on that kind of check [16:17] 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] 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... === chand_ is now known as chand [16:23] what license is ubuntu distributed under? [16:24] 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] thanks cjwatson [16:25] looks like I could have found that googling. sorry to bug [16:26] 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 === mrpouit is now known as mr_pouit [16:27] * ogra glares at the date [16:27] cjwatson, ha thanks I guess [16:27] :) [16:27] Keybuk: ...binging? [16:28] slangasek: http://www.bing.com/ [16:28] slangasek, MS's new toy [16:28] I could've found that by purging [16:28] Microsoft rebranded MS Live Search, and clearly asked for a word people could verb [16:28] * rickspencer3 sigh [16:29] Microsoft Bing Powered By Microsoft Live Search 3.11 for Workgroups NT [16:29] I "binged" you...heh [16:30] Microsoft Bing Seen 2000 [16:30] sounds a bit "nasty" :P [16:30] rickspencer3: it's ok, you escaped [16:30] 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] lol [16:31] I like the pop-up previews on the right though. That's a nice touch. [16:32] Have you seen how pathetically biased the search results are, though? [16:32] Hint: enter "linux" and look at the top autocompletions :-) [16:32] that's awesome [16:32] * Keybuk wants Linux Vista [16:32] 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] cjwatson, so essentially, does ubuntu not put a license on the distribution as a whole? [16:34] Nilbus: that's correct [16:34] 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] Keybuk: blech, with all those ground-up kernels in it? [16:34] cjwatson, ok. right [16:34] make sense === lamont` is now known as lamont [16:41] ogra: not yet [16:46] it seems neither totem nor totem-gstreamer has the actual binary anymore, is it in some other package now? [16:47] totem-gstreamer ships /usr/bin/totem-gstreamer and registers an alternative for /usr/bin/totem [16:47] unless this changed since my mirror last pulsed [16:48] perseus:[~] dpkg -L totem-gstreamer | grep bin [16:48] zsh: done dpkg -L totem-gstreamer | [16:48] zsh: exit 1 grep bin [16:48] mdz, cjwatson: this was discussed in #u-desktop an hour ago [16:48] wrong alternatives cleanup in postinst [16:48] pitti: thanks [16:48] there's debian/lp bugs for it, too, on the way [16:48] * slangasek mourns the channel fragmentation [16:50] 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] mdz: sudo apt-get install --reinstall totem to fix it [16:50] seb128: thanks [16:50] seb128: I was just reading the scripts to see if that would fix it, thanks [16:50] mdz: totem-gstreamer is a dummy package, there is only totem which is gstreamer now [16:51] pitti: bug 383187 is the one referenced on #-desktop [16:51] Launchpad bug 383187 in totem "totem doesn't open" [High,Fix released] https://launchpad.net/bugs/383187 [16:51] \sh, we share the same initramfs code for netbooting, so thats surprising [16:51] 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] oh, then its actually changed ... we used to usew the ipconfig -d ${DEVICE} line too before [16:54] i guess sid uses configure_networking() too [16:55] 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] mdeslaur: please do. If you don't have the time, I can do it === ArneGoet1e is now known as ArneGoetje === mgunes1 is now known as mgunes [17:30] hrm, why is ubuntu-bug crashing now :( [17:31] file a bug :P [17:32] already reported [17:32] 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 === pace_t_zulu is now known as pace_t_zulu|work [17:33] slangasek: on some assertion about the bug title? [17:33] pitti: yes, bug #383104 [17:33] Launchpad bug 383104 in apport "Ubuntu-bug crashed with AssertionError" [High,Triaged] https://launchpad.net/bugs/383104 [17:34] ah, I fixed that this morning [17:34] pitti: I guess you already fixed this in -3, right :) [17:34] * slangasek upgrades to confirm [17:35] mcasadevall: but util-linux-udeb *does* have /sbin as a file [17:35] $ dpkg -c ~/ubuntu/pool/main/u/util-linux/util-linux-udeb_2.15.1~rc1-1ubuntu1_ia64.udeb [17:35] drwxr-xr-x root/root 0 2009-05-29 12:42 ./ [17:35] (not ia64-specific) [17:35] -rwxr-xr-x root/root 24992 2009-05-29 12:42 ./sbin [17:36] o__o; [17:36] (argh, I'm an idiot, but thats a separate issue) [17:36] Now the question is how did that happen [17:36] mcasadevall: I suspect debian/rules forgets to create a directory before using install(1) [17:39] pitti: yeesh, enough changelog symlink indirection in apport? :P [17:40] slangasek: hm? [17:40] once again, changelog symlinks without strict versioned dep == bad [17:40] oh, that [17:40] pitti: I tried to manually upgrade apport. I'm having to manually upgrade two more packages to actually get the matching changelog. [17:43] mvo: https://wiki.ubuntu.com/AptSyncInKarmicSpec updated. [17:46] mcasadevall: http://paste.ubuntu.com/187511/ should fix it [17:46] apt-sync? Interesting. Why not pdiff/rred ? [17:46] (against the ubuntu/master branch of lamont's git repository) [17:47] * cjwatson wanders off for the evening [17:47] Ow, git :-/ [17:47] I suggest making either lamont or Keybuk do the actual commit and upload ;-) [17:48] cjwatson, probably a good idea :-). Thanks for your assistance on my blind eye :-/. [17:48] mcasadevall: which version of util-linux, I wonder? [17:49] as in this is 2.15.1? [17:49] lamont: current in karmic [17:50] 2.15.1~rc1-1ubuntu1 [17:50] lamont, its whatever is in karmic: util-linux-2.15.1~rc [17:50] ^1 [17:50] 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] 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] 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] err, and indeed ln(1) etc. [17:51] 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] ion_: sweet [17:52] (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...) === mcasadevall is now known as NCommander [17:53] lamont: I'd recommend something like http://paste.ubuntu.com/187514/ for future robustness [17:53] slangasek: seahorse is the tools you use to handle gnome-keyring passwords too [17:53] ok, really gone [17:54] 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] cjwatson: now I just need to figure out if it's me or keybuk that I need to thwap [17:56] 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] slangasek: applications, accessories, seahorse [17:56] heh [17:57] or "key and password" or whatever is the english wording [17:57] "accessories" - not intuitive :) [17:57] "Passwords and Encryption keys" [17:59] 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] elmo: not off-hand (I'm not really following the bug reports on cups) [18:00] elmo: I guess they are stuck in /var/cache/cups/remote.cache ? [18:01] pitti: yeah === pace_t_zulu|work is now known as pace_t_zulu [18:01] elmo: you can't delete those with lpadmin/web UI, since they aren't really "there" locally [18:03] pitti: I guess I'm just surprised they don't time out of their own accord [18:03] elmo: they should; they do here [18:04] 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] mvo: Added a short summary to the bottom. [18:04] seb128: ah, n/m; I see now that seahorse-plugins was removed on upgrade [18:04] slangasek: searhose-plugins was installed in jaunty [18:04] right [18:04] we used a recommends where debian is using a suggests [18:06] should seahorse-plugins also Provides: gnupg-agent? [18:07] seb128: btw, do you know why the g-p-m icon theme is broken for me, before I go filing a bug? [18:08] no [18:08] ok [18:08] slangasek: no idea about gnupg-agent are those equivalent? [18:09] well, there's no defined virtual package for it - but it implements the gnupg agent protocol [18:09] and a Provides: would've been discoverabel [18:13] 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] Launchpad bug 383256 in seahorse "seahorse no longer running after upgrade to karmic, no gpg agent available" [Undecided,New] https://launchpad.net/bugs/383256 [18:13] slangasek: thanks [18:31] didrocks: actually, someone has already started it: LP #380806 [18:31] Launchpad bug 380806 in pidgin "Please merge pidgin 2.5.6 (main) from Debian sid (unstable)" [Undecided,In progress] https://launchpad.net/bugs/380806 [18:42] good night everyone [18:42] Night [18:44] mvo: Updated the latest benchmark with what happens with method #3 if inputfile hasn’t been packed with --rsyncable. [18:56] slangasek: do you know any packages using dep5 debian/copyright that I could see? [18:56] could somebody plz check https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/383271 [18:56] Ubuntu bug 383271 in audacious "Please merge audacious 2.0.1-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] [18:56] its my first merge, so hope its correct :) [18:59] dupondje: better to ask in #ubuntu-motu [19:03] stefanlsd: not yet; the dep5 is still in flux [19:03] slangasek: ok thanks! i was doing a package for revu - is it ok to use? [19:04] 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] directhex: I see mono's on the merge list again; is that in a syncable state now? [19:07] slangasek: thanks [19:17] slangasek: that makes sense, yes [19:17] (bumping seahorse-plugins to a Recommends) [19:17] pochu: see subsequent discussion with seb128; turns out that this *was* a Recommends previously [19:18] in Ubuntu [19:18] and it's been dropped === DrKranz is now known as DktrKranz === DktrKranz2 is now known as DktrKranz [20:10] 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] 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] pitti: I have some updates in lp:~kees/apport/apport.segv-analysis for you [21:24] slangasek: ping [21:26] nxvl: hi [21:28] 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] 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] slangasek: or at least to make that information available for people that want to help [21:30] 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] lamont: mmm, have you read the e-mail steve sended? [21:30] 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] nxvl: lalalala [21:31] nxvl: the upload of postfix is to have it Provide: default-mta on ubuntu [21:31] slangasek: so, is not a goal for karmic? [21:31] lamont: ohh!! got it! [21:31] nxvl: and no, haven't actually read the email, though I suspect the discussion I had with slangasek trumps it [21:31] lamont: i was confused about that :P [21:32] lamont: no, the email in question was letting ubuntu-devel know default-mta was open for the using [21:32] nxvl: it's not a goal of *mine* for karmic :) [21:32] 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] slangasek: right. trumped by our discussion (or confirmed, or whatever...) [21:32] nxvl: postfix already knows whether it's building on ubuntu or debian [21:32] so one more bit of abuse doesn't hurt, right? [21:33] lamont: really? awesome [21:33] 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] gigglr [21:43] if [ $(DISTRO) = Ubuntu ]; then echo postfix:Provides=default-mta >> debian/postfix.substvars; fi [21:43] see... that's easy [21:44] slangasek: please sync postfix 2.6.2~rc1-1 from sid kthx [21:45] 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] lazy [21:45] yes [21:45] though it wouldn't be any work to upload 2.6.2~rc1-0build1.... [21:46] though that should be -1~0build1 [21:46] you can if you wish :) [21:46] is it possible to run gvfs outside of gnome or X? [21:47] slangasek: the exim in karmic doesn't provide: default-mta, right? [21:47] lamont: right [21:47] (as of about the time I pinged you about this :) [21:48] uploaded [21:48] er, ing [21:49] slangasek: and nothing from 2.5.5-1.1ubuntu1 I need to worry about, right? [21:49] as in - I'm gonna totally ignore that ever existed [21:50] the only change was the default-mta bit [21:52] yay [21:52] and 2.6.2 will release sometime soonish, so I'm not too caring about the ~rc1 bit of that version [21:53] that and Wietse is pedantically anal about stable updates [22:09] anyone else notice firefox seems more laggy than usual lately? [22:09] oh, in karmic [22:11] calc, My new P8600 and 4GBs of ram makes everything seem fast. [22:11] i have the same and its lagging badly for some reason [22:12] like pageup/pagedown even lags [22:12] 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] 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] tedg: hi [22:16] jelmer: Hello. [22:17] tedg, jam and I managed to fix the bug you were hitting in bzr during UDS [22:17] tedg, I've just submitted the fix to PQM [22:17] jelmer: Whoo! Hooo! Many thanks! [22:17] tedg, There was also another issue, caused by an early bzr-svn bug that has been fixed now. [22:17] 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] 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] 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] jelmer: Ah, okay. That's fine. I'll recreate. Can I merge the old ones in? Will that create something useful? [22:22] 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] Ubuntu bug 381791 in libldap-ruby "LDAP::SSLConn from ruby fails, probably from not seeing cert" [Undecided,New] [22:22] Oh yeah. That's my bug. See my name? ;^) [22:23] slangasek: I am using a standard environment. Is there another place I should seek this help? [22:26] 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] tedg, And sorry this took so long. [22:27] jelmer: No problem. Happy that it's fixed. I've been using SVN... remember those days all too fondly now :) [22:32] xenocampanoli: ok, I can confirm the build failure in karmic [22:33] xenocampanoli: apparently libldap-ruby assumes LDAP_OPT_X_TLS_PROTOCOL is a constant, not a macro w/ arguments. [22:34] xenocampanoli: so I would say this is an upstream bug in libldap-ruby [22:37] i need -fprofile-correction from gcc 4.4 but i'm using jaunty and its in karmic [22:38] 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] 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] slagasek: compiler error that is. [22:39] xenocampanoli: filing a bug report would be advisable :) [22:39] slangasek. I'll put a number here when I'm done. [22:40] installing a package like gcc from a newer dist could be problematic. it likely requires libc etc... [22:40] not advisable? [22:40] or are jaunty/karmic still fairly binary compatible [22:44] slangasek: https://bugs.launchpad.net/ubuntu/+source/libldap-ruby/+bug/383371 [22:44] Ubuntu bug 383371 in libldap-ruby "Compiler error trying to build libldap-ruby from source" [Undecided,New] [22:44] slangasek: Please I am open to suggestions on this bug environment and its standardsd. [22:53] slangasek: I know if you can formally confirm 383371 it will likely expedite it's handling. [22:56] 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] 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] this particular build failure could be fixed by commenting out the lines referring to LDAP_OPT_X_TLS_PROTOCOL [22:59] slagasek: Trouble is, I will need to decide the intentions of the developer in charge for this macro. [22:59] I don't know if that's a correct fix [23:00] 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] xenocampanoli: hopefully there's also accurate information in debian/copyright that can be used to contact upstream [23:01] hmm.. I lost my gdm login screen after an upgrade to karmic on my 32-bit laptop [23:01] slangasek: I don't have an account in the Debian area, only on launchpad. Perhaps I should do that...? [23:02] xenocampanoli: debian/copyright is the file in the source package. And the Debian BTS doesn't use accounts, it's email-only [23:02] Just uploaded the first branding-ubuntu package. So far all it has is a new gnometris theme [23:03] https://wiki.ubuntu.com/branding [23:05] amitk: KMS? [23:05] 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] 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] xenocampanoli: if you find a solution, I suggest you follow https://wiki.ubuntu.com/SponsorshipProcess to get the fix included in Ubuntu [23:06] slangasek: default upgrade. Haven't yet enabled KMS. [23:07] amitk: oh. UXA? :) [23:07] slangasek: Thank you for confirming and all your help. [23:09] slangasek: xorg.conf had a 'virtual' line that seemed to be causing the problem [23:29] TheMuso: WRT desktop-karmic-audio-experience: will do [23:29] dtchen: thanks [23:34] joaopinto: we already have kpackagekit as our package manager in jaunty [23:34] its main limitation is not being able to install java, that's a pain but I can live with that with openjdk [23:55] 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