[00:43] <warsocket> k question, lets say ive made a program that would do nice in the ubuntu repository, what should i doe or who should i contact to get it there
[00:46] <azeem> warsocket: #ubuntu-motu
[00:50] <warsocket> k
[01:21] <geser> slangasek: Hi, when you have time, can you please review the merge for gnupg? bug #225005
[02:49]  * Hobbsee wonders how to disable the "feature" of having no shut down button, without going to gdm first.
[02:52] <RAOF> Hobbsee: Surely that's a lie - I've got a shutdown button.
[02:52] <RAOF> Admittedly, it doesn't actually _shutdown_, but it's certainly a button, marked shutdown :)
[02:52] <RAOF> Mostly it freezes gnome-panel.
[02:53] <Hobbsee> RAOF: intrepid?
[02:53] <RAOF> Hobbsee: Yah
[02:53] <Hobbsee> ah.  there's a separate shut down one
[02:53] <RAOF> Right.
[02:54] <RAOF> It's reverted to upstream GNOME's shutdown/logout thingy.
[02:56] <Hobbsee> RAOF: thanks
[02:56] <RAOF> It's broken for me, though, so it's not _really_ helpful :)
[02:57] <Hobbsee> aww
[02:59] <Hobbsee> RAOF: if you're in an answering mood, how do i make compiz work again?
[03:00] <RAOF> How's it broken?
[03:00] <Hobbsee> /usr/bin/compiz.real (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0"
[03:00] <Hobbsee> /usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0
[03:00] <Hobbsee> Window manager warning: Workarounds for broken applications disabled. Some applications may not behave properly.
[03:00] <RAOF> Ah.  Turn off metacity's compositor.
[03:00] <Hobbsee> (from a compiz --replace &)
[03:00] <RAOF> Metacity's compositor doesn't release the CM selection in the way that compiz would like it to.
[03:01] <Hobbsee> ahhh
[03:01] <RAOF>  /apps/metacity/general/compositing_manager or somesuch.  It's changed name at some point in the past.
[03:01] <Hobbsee> found it, thanks
[03:02] <RAOF> That should now allow you to experience other bugs in Compiz :)
[03:02] <RAOF>  / mesa / X
[03:02] <Hobbsee> like the fact taht some of my settings have been lost, and my metakeys aren't working again?
[03:02] <Hobbsee> well, some of them
[03:04] <RAOF> Dunno.  I'm only just playing with compiz again now that there's an nvidia-glx to test.
[03:21] <alex-weej> and the workspaces have gone back to 2 even though i've chosen 4!
[03:22] <Hobbsee> alex-weej: yeah, it seems to have wiped all the settings.
[03:23] <Hobbsee> RAOF: right.  got it all working, except that it still doesn't start by default.
[03:23] <Hobbsee> and gnome-panel's being tempramental, again
[03:25] <Hobbsee> mmm...fire :)
[03:25] <superm1> RAOF, how's the experience going for the nvidia-glx new way of doing things (except for jockey not being there yet)?
[03:30] <RAOF> superm1: Basically flawless.  Installing nvidia-glx-177 works fine, nvidia-xconfig worked for me.
[03:32] <superm1> cool, that's good
[03:35] <alex-weej> superm1: what's new?
[03:36] <alex-weej> i'm using 177 beta on intrepid now cause jockey didn't want to work
[03:36] <alex-weej> (and it's not in lrm)
[03:36] <superm1> alex-weej, the way that everything is packaged has changed with it not being in LRM, so i just was curious to make sure that there was no major problems coming up using the nonlrm packaging
[03:37] <superm1> alex-weej, you weren't using the .run file from nvidia's website right?
[03:37] <alex-weej> i was
[03:37] <alex-weej> and it worked
[03:37] <alex-weej> shouldn't it have?
[03:38] <RAOF> Well, it should have.  But the nvidia-glx-177 package would've made it easier :)
[03:38] <superm1> alex-weej, the nvidia-glx-177 should be able to handle the upgrades from kernel to kernel properly
[03:38] <superm1> so that's the important part to make sure continues to work
[03:39] <alex-weej> that's a good point... i've had loads of kernel updates but not had to rebuild
[07:11] <ryanhaigh> hello all, im trying to help someone here: http://ubuntuforums.org/showthread.php?p=5427518 . How would I go about changing the version number assigned to the package when building using the process described there?
[07:15]  * Hobbsee wonders why they don't just purge tracker and be done with it.
[07:16] <Hobbsee> ah
[07:22] <ryanhaigh> yeah doesn't work unfortunately
[07:25] <ryanhaigh> can anyone point me in the right direction
[07:33] <Hobbsee> edit debian/control
[07:37] <RAOF> Hobbsee: You mean debian/changelog, right?
[07:38] <Hobbsee> er, yes, that.
[07:38]  * Hobbsee wonders where her brain went.
[07:42] <ryanhaigh> and just add another version in there?
[07:42] <ryanhaigh> im not on my ubuntu machine at the moment so i can't try this myself
[07:46] <RAOF> ryanhaigh: Correct.  "dch -i" is likely to be the easiest way to get a well-formed changelog entry.
[07:58] <pitti> Good morning
[07:58] <pitti> asac: just mention it in the MIR
[08:08] <Hobbsee> heya pitti
[08:10]  * pitti hugs Hobbsee, hey!
[08:11] <Hobbsee> :D
[08:12] <Mithrandir> hiya Hobbsee, pitti
[08:14]  * StevenK waves, jetlagged
[08:14] <Mithrandir> jet lag is overrated.
[08:16] <StevenK> Not right now, it isn't.
[08:18] <Hobbsee> hey Mithrandir!
[08:19] <stgraber> moin
[09:04] <asac> pitti: yep. did that. https://wiki.ubuntu.com/MainInclusionReportPcsc-Lite
[09:05] <StevenK> pitti: Could you poke at why twin failed to upload to every arch it built on, bar lpia?
[09:05] <StevenK> pitti: http://launchpadlibrarian.net/16198199/upload_673575_log.txt is the upload log
[09:06] <StevenK> asac: MIRs are bugs ... :-)
[09:08] <Wubbbi> bug 249850 is reported. Can you fix it please? :)
[09:08] <asac> StevenK: err its a bug as well
[09:08] <asac> bug 250245
[09:09] <StevenK> asac: Heh, fair enough
[09:10] <asac> ;)
[09:13] <pitti> StevenK: ugh, no idea; I'm afraid that's a cprov problem
[09:25] <soren> asac: I'm curious... Do you specifically want to keep pcscd out of main or do you just "not care"?
[09:26] <asac> soren: the latter. i just need the lib to build wpasupplicant in a way that you can install pcscd and then get smart card support
[09:26] <soren> asac: Ok, cool.
[09:49] <geser> StevenK: twin does hardcode the binary deb versions in debian/rules. twin 0.5.1-3ubuntu1 build packages with the versions like twin 0.5.1-3.
[09:50] <geser> StevenK: don't forget to also update the versioned dependency of libtw0-dev in debian/control
[09:51] <StevenK> What the?!
[09:51]  * StevenK digs
[09:52] <StevenK> Oh, for crying out loud
[09:52] <StevenK> There's a substvar for this!
[10:05] <StevenK> geser: It gets worse. The version is hard coded in debian/rules.
[10:06] <StevenK> Which is about the worst crack-cut-with-washing-powder I've ever seen
[10:07] <geser> is there a better way to produce binary debs with a different version than the source?
[10:08] <StevenK> Yes.
[10:08] <StevenK> Don't do that.
[10:08] <StevenK> geser: Seriously, it's complete crack
[10:09] <cjwatson> sometimes it's necessary
[10:09] <cjwatson> cf. gcc-defaults
[10:10] <cjwatson> you can fish out parts of the source version and do arithmetic if necessary
[10:10] <StevenK> Exactly.
[10:10] <StevenK> Wield dpkg-parsechangelog and such.
[10:22] <StevenK> pitti: Okay, that twin failure is a package bug
[10:22] <pitti> StevenK: yep, saw it in backscroll
[10:22] <StevenK> I feel so dirty
[10:23]  * StevenK will nail the patch to the Debian BTS.
[10:23] <StevenK> Severity: important. Maybe serious
[10:47] <cjwatson> hmm. why did rarian-compat get demoted back to universe?
[10:47]  * cjwatson puts it back in main
[10:49] <soren> seb128: Fix for the virt-manager hypervisor selection bug just uploaded..
[10:50] <seb128> soren: ah, cool, thanks
[10:51] <soren> seb128: Any time :)
[11:51] <NCommander> Anyone here an archive admin who can answer a quick question or two
[11:51] <pitti> NCommander: yes, some; just ask your question, please
[11:52] <NCommander> I have codeblocks sitting in the NEW queue; it has a lintian override, which I forgot to document; should I simply wait for the package to be REJECTed (as it would be in Debian), or is it possible it can be put through, and then get a debdiff applied to it ASAP?
[11:53] <pitti> NCommander: you can just upload a new package if you want
[11:53] <pitti> NCommander: however, an underdocumented lintian warning is not generally a reason for outright rejection
[11:54] <pitti> unless it overrides something really bad
[11:54] <NCommander> It overrides script-not-executable
[11:54] <NCommander> (lintian is detecting a code parser as a script)
[11:54] <pitti> ah, that's usually scripts in /usr/share/ with a shebang
[11:55] <pitti> NCommander: I wouldn't reject a package due to that
[11:55] <NCommander> THere is a second issue which I caught just a few hours ago
[11:55] <NCommander> Upstream shipped a Debian folder
[11:55] <NCommander> When I ran update-maintainer, the person who packaged it ended up in Original Maintainer
[11:55] <NCommander> (my name is in the changelog)
[11:55] <NCommander> I'm not sure if that's right, or not
[11:58] <cjwatson> update-maintainer is for use when making Ubuntu modifications to packages that also exist in Debian, where the prior consensus has been that Debian maintainers should not be listed in Maintainer of Ubuntu-modified packages
[11:59] <cjwatson> when making modifications to packages that originated elsewhere, you ought to find out whether that's what the original packager wants
[12:00] <NCommander> cjwatson, it was a mistake that it went with that Original-Maintainer; I had intended to switch it to myself, but obviously that didn't quite happen
[12:00] <NCommander> (I redid most of the Debian folder, so while I do credit the creator of the upstream folder in copyright, I'd think I should be there)
[12:15] <cjwatson> you're allowed to edit debian/control by hand rather than using update-maintainer if that's what's needed ;-)
[12:16] <cjwatson> it's a human-editable file
[12:16] <cjwatson> (BTW, in Unix we call them directories rather than folders)
[12:16] <cjwatson> in the case of what you *should* do with Original-Maintainer, I don't think it's terribly important either way, and certainly wouldn't be cause for a rejection
[12:49] <ivoks> wrong channel
[12:49] <ivoks> :)
[13:29] <emgent> moin
[14:13] <Ng> is there any way of tuning/inspecting gvfs? its sftp performance seems to be shockingly slow
[14:13] <Ng> I can scp a file at line speed (10
[14:14] <Ng> err, let me try that sentence again ;)
[14:14] <Ng> I can scp a file at line speed (10MB/s). using nautilus's sftp claimed about 1MB/s, cp'ing to ~/.gvfs/blah/ and inspecting with iptraf suggested it was doing <200K/s
[14:15] <\sh> Ng: if you do a simple sftp via sftp client...do you get the same?
[14:16] <Ng> \sh: yep, ~10MB/s
[14:16] <\sh> Ng: strange, I always had the same issue with winscp from windows -> to sftp enabled servers (linux, sun) ... sftp was always slow for me..that's why I try to avoid sftp in general
[14:16] <Ng> (wired ethernet on a 100Mb fibre to the network the remote machine is on, so I'm pretty sure it's not network related or wireless nonsense)
[14:18] <\sh> scp was always faster...could be me or something weired on the network those days...
[14:18] <Spads> this is over an internal network, effectively
[14:18] <\sh> Spads: yes :)
[14:19] <Ng> I'm just curious if it's known that gvfs is slow at this stuff, or maybe if I can change block sizes it's sending or something
[14:20] <seb128_> Ng: "this stuff" being?
[14:21] <Ng> seb128_: I'm scping stuff to one of our machines and getting pretty much full wire speed (10MB/s) with scp and sftp console clients. nautilus via gvfs sftp claims to do ~1MB/s and if I use iptraf to inspect my eth0 when I'm doing a regular cp to the ~/.gvfs/ location it's more like 200KB/s
[14:21] <Ng> I would expect some overhead, but that seems a bit odd
[14:22] <seb128_> Ng: the .gvfs location is a standard fuse mount
[14:24] <Ng> seb128_: any suggestions for where I could be looking to figure out why it's slow?
[14:25] <seb128_> Ng: http://bugzilla.gnome.org/show_bug.cgi?id=523015 for gvfs, dunno about fuse
[14:25] <seb128_> Ng: gvfs = when you use the ssh backend to do the copy, ie what nautilus is doing
[14:26] <Ng> seb128_: ok. I'm entirely happy to ignore the fuse end of things, in which case we are only losing one order of magnitude ;)
[14:27] <seb128_> Ng: also compare to command line sftp and not to scp if you want fair numbers ;-)
[14:27] <Ng> I did, it's also pretty much full line speed
[14:27] <Ng> there's a little variance which is probably because the line isn't exclusively mine, but 9-10MB/s
[14:28] <seb128_> ok, that's probably somewhat along the line of the bug I pointed then
[14:29] <seb128_> though your line is probably not a low latency one
[14:29] <Mithrandir> seb128_: generally, sftp will be faster than scp, since scp has some ickiness in the buffering algorithms.  (I think?)
[14:30] <seb128> Mithrandir: possible, anyway in this case that's clearly gvfs not doing an optimal job
[14:31] <Ng> seb128: the latency is pretty low from here, we have fibre to the network the other machine is on, so we're talking a millisecond or so
[14:32] <seb128> Ng: ok, so I don't know about other bug and it would probably require debugging from somebody knowing the code well enough
[14:32] <Wubbbi> hello :)
[14:33] <pitti> cjwatson: which installer component puts the user into the initial groups? (audio, video, etc.)? I'd like to drop some (intrepid-device-permissions)
[14:33] <Ng> seb128: having 64k blocks from that patch would probably be enough in most instances, and since it was applied in march maybe we alreayd have that?
[14:33] <Ng> bugzilla fails at making this stuff easy to find out ;(
[14:35] <seb128> Ng: yes, it's already in hardy and intrepid
[14:35] <Ng> seb128: hmm, a quick google suggested libglib 2.17, but hardy has 2.16?
[14:38] <Ng> but our 2.16 does indeed have a 1024*64 buffer
[14:39] <seb128> Ng: http://svn.gnome.org/viewvc/glib?view=revision&revision=6736
[14:39] <Ng> yeah, I just grabbed the glib hardy source and that patch is definitely in it :/
[14:42] <chmj> .join #ubuntu-za
[14:42] <chmj> baah
[14:45] <cjwatson> pitti: user-setup
[14:45] <pitti> cjwatson: ah, thanks
[14:46] <cjwatson> pitti: I'd appreciate it if you kept an eye on bug 188759 and bug 205563 while doing so
[14:46] <pitti> cjwatson: right
[14:46] <pitti> cjwatson: btw, related to that spec, is it easily doable to not create the cdrom fstab entry for desktop installs?
[14:47] <cjwatson> no. apt-cdrom needs it
[14:48] <pitti> hm, too bad
[14:48] <cjwatson> attested by e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464899
[14:49] <cjwatson> I've said this pretty much every time somebody's asked about that fstab entry in the last four years, but none of the people who want it gone seem to have fixed it yet ;-)
[14:49] <pitti> seems I keep forgetting about apt-cdrom then
[14:50] <seb128> anybody knowing about dtd registration and use there who could have a look to http://paste.ubuntu.com/28998/ and let me know if that seems correct?
[14:50] <seb128> that's a copy of the scrollkeeper dtd to rarian-compat and a registration similar to what scrollkeeper is doing
[14:50] <cjwatson> pitti: see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282344
[14:50] <cjwatson> (which is a more useful bug)
[14:51] <pitti> cjwatson: ah, however, the fstab entry doesn't require the user to be in the cdrom group
[14:51] <pitti> since nowadays we get ACLs on /dev/ storage devices, we can drop that
[14:52] <pitti> (for raw-reading CD-ROMs)
[14:52] <cjwatson> I store what I know about groups in the base-passwd documentation
[14:52] <cjwatson> but, indeed, cdrom and floppy don't seem to be used for that
[14:53] <cjwatson> pitti: the dialout comment about monetary consequences is a little odd, given that it's the first user and they could probably just pick up the phone ;-)
[14:53] <cjwatson> though I suppose there's the spyware case, if that's what you meant by dialer programs
[14:53] <pitti> right
[14:54] <pitti> it's allegedly a bit far-fetched, since I didn't see actual programs which did that under Linux yet
[14:54] <cjwatson> polkit-gnome-authorization would have a hard time dealing with minicom, wouldn't it?
[14:54] <pitti> but they had been a PITA under Windows
[14:54] <cjwatson> I think we should take some care with the serial port access programs we ship to avoid just pushing lots of people towards sudo
[14:55] <pitti> cjwatson: that just controls ACLs on /dev/ttyS, so minicom is not a problem
[14:55] <pitti> but yeah, I won't drop dialout until we actually have a replacement
[14:55] <cjwatson> oh, it does? it has no manual page so I couldn't tell
[14:55] <pitti> cjwatson: s/does/is planned to/ :-)
[14:56] <pitti> cjwatson: for now I plan to drop cdrom, floppy, plugdev, audio, video, dip
[14:56] <pitti> and keep dialout, adm, fuse
[14:56] <cjwatson> bit of a horror show of a UI though
[14:57] <pitti> cjwatson: how do you mean?
[14:57] <cjwatson> plugdev> awooga that's used by other bits of the installer
[14:57] <cjwatson> polkit-gnome-authorization? it's one of the most complex UIs I've ever seen :)
[14:57] <cjwatson> came up in Ubuntu reviews too
[14:57] <pitti> cjwatson: what's behind the "enable modem access" checkbox shouldn't matter to the user? (PolKit call or add group)
[14:57] <cjwatson> oh, if there's a cleaner wrapper around it, sure
[14:58] <pitti> cjwatson: ah, right; yes, that's known upstream, too, and being worked on
[14:58] <cjwatson> partman-basicfilesystems/fstab.d/basic:64:                      # base-passwd defines gid 46 as group plugdev
[14:58] <cjwatson> partman-basicfilesystems/fstab.d/basic:74:                      # base-passwd defines gid 46 as group plugdev
[14:58] <cjwatson> used for giving people the ability to see the contents of FAT/NTFS filesystems
[14:58] <cjwatson> and write to them, come to that
[14:59] <pitti> cjwatson: the installer cares which groups the initial user is in?
[14:59] <cjwatson> yes
[14:59] <pitti> s/cares/& about/
[14:59] <cjwatson> or, rather, if they aren't in plugdev, they won't be able to read/write those filesystems
[14:59] <cjwatson> which will be a fairly serious regression
[14:59] <pitti> hm, how odd
[14:59] <cjwatson> pitti: not that odd - with the way FAT/NTFS permissions work, it has to just give access to a Unix group
[14:59] <pitti> I wasn't aware that these parts of the installer run as the target user instead of just in the installer context
[14:59] <cjwatson> they don't
[15:00] <cjwatson> but the result, post-install, will be that the user cannot read from or write to those filesystems
[15:00] <cjwatson> the alternative is to give access only to root (inconvenient) or to a specific user (doesn't allow permissions to be extended)
[15:01] <cjwatson> at the time, plugdev was a pretty reasonable choice for that
[15:01] <pitti> hm, I still don't understand, I'm afraid
[15:01] <cjwatson> we put this in fstab:
[15:01] <cjwatson>                         echo "$path" "$mountpoint" vfat $options,umask=007,gid=46 0 1
[15:01] <pitti> I haven't had plugdev membership for ages, and no problem with fat/ntfs drives
[15:01] <cjwatson> if the user is not in gid 46 then they will not be able to use their Windows-formatted data partition
[15:02] <cjwatson> then you have yours set to non-default permissions
[15:02] <pitti> oh, that, I see
[15:02] <cjwatson> this is for ones that the user explicitly mounts in a particular place using the partitioner
[15:02] <pitti> cjwatson: well, I never statically add windowsish partitions to fstab
[15:02] <cjwatson> rather than filesystems that are automatically mounted
[15:02] <cjwatson> you don't, but it's not uncommon to want them on e.g. /data rather than /media/blah
[15:02] <pitti> right
[15:02] <cjwatson> and people do do that
[15:03] <cjwatson> it's not the absolute novice user case, but it's within what I'd consider to be relatively normal use of the desktop CD
[15:03] <pitti> hm, seems we cannot get rid of either (fstab/groups) without getting rid of the other, too
[15:03] <cjwatson> is plugdev doing any harm? just leave it there :)
[15:04] <pitti> well, seems I need to for this round then :)
[15:05] <cjwatson> I do understand the rationale, and we shouldn't use plugdev in similar ways for new purposes
[15:09] <pitti> group 'sambashare'? that's new to me
[15:10] <pitti> ah, bug 238224
[15:14] <slytherin> Can any of the archive admins please process batik from 'NEW'? I would like to start looking into the packages that depend on batik and hence never built before.
[15:17] <norsetto> seb128: hi, seen my email?
[15:21] <seb128> norsetto: hi, I had a quick glance on the subject but that's all, I'm still busy catching up on other things after 2 weeks travelling, is there any hurry?
[15:23] <norsetto> seb128: well, if you could say yes or no soonish would be nice otherwise the guy will be kept hanging
[15:35] <mkrufky> to my surprise, "apt-cache search cogito" does not find any cogito package in hardy ....   am i looking in the wrong place?
[15:36] <jcristau> mkrufky: no. cogito is dead.
[15:36] <mkrufky> dead?!?
[15:36] <mkrufky> cogito always accepts my malformed git commands....  now i have to learn how to use git PROPERLY ???
[15:36] <mkrufky> :-P
[15:37] <mkrufky> jcristau: can you recommend another tool?
[15:37] <jcristau> git
[15:37] <mkrufky> meh
[15:37] <mkrufky> ok, thanks
[15:38] <DktrKranz> mkrufky: for additional informations, see debian 436248
[15:38] <mkrufky> thank you, DktrKranz
[15:39] <hwilde> anybody else get hit with smenara ?
[15:41] <hwilde> found this nonsense in root history  http://pastebin.ubuntu.com/29004/
[15:42] <hwilde> tar file has a port scanner, a password list, and a replacement binary for ssh and sshd :/
[15:43] <mkrufky> hwilde: take a look in /tmp/ for any suspicious directories
[15:44] <hwilde> I looked around couldn't find anything
[15:44] <mkrufky> hwilde: especially directories whose name is comprised of >= 1 whitespace chars
[15:44] <hwilde> but when I tried to ssh it gave a bunch of bogus ssh2 errors
[15:44] <hwilde> so I removed and purged ssh, sshd, changed all passwords, reinstalled
[15:44] <hwilde> fine now
[15:44] <hwilde> but I couldn't find anything out on the net related
[15:44] <slangasek> geser: yes, on my todo list
[15:44] <mkrufky> i got hit by something a few months ago.... actually, it was a server that was powered down for a few years... i think i got attacked BEFORE i took it down, and only noticed a few months after bringing it back online
[15:45] <hwilde> so if it's not a widespread thing on the net, I am thinking it was someon internal :/
[15:45] <mkrufky> hwilde: also look around for suspicious cron deamons
[15:45] <mkrufky> any users logged in that arent u
[15:45] <hwilde> not without sshd :)
[15:47] <mkrufky> look anyway ... if there are false cron daemons running, it can spawn processes without using sshd
[15:48] <hwilde> nothing in cron
[15:48] <hwilde> no users logged in
[15:48] <hwilde> no way they could I removed --purge sshd
[15:49] <mkrufky> i dont mean actual users
[15:49] <mkrufky> ugh
[15:49] <mkrufky> just ps aux and see if anything looks wierd
[15:49] <mkrufky> my users logged in, i means any tasks running that may or may not be malicious
[15:49] <mkrufky> ^ s/my/by
[15:50] <mkrufky> anyway, im just making suggestions... i got hit pretty badly, but it was on a very very old system runnign a 2.4 kernel that i did not keep up to date with security fixes
[15:50] <mkrufky> it was actually rather entertaining tracking it down
[15:51] <hwilde> dbus-daemon --fork --print-address 24 --print-pid 26 --session
[15:51] <hwilde> that looks a bit odd
[15:51] <hwilde>  /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=28
[15:51] <hwilde> pretty sure I don't need htat either
[15:51] <hwilde> but they don't smell malicious
[15:52] <hwilde> the scripts don't even look like they work
[15:52] <hwilde> seems like a junior hack attempt
[15:52] <hwilde> but why would it just hit me and no hits on google
[15:52] <hwilde> must have been an inside job
[15:52] <mkrufky> keep in mind that the hacker might want you to THINK that
[15:53] <Trewas> some rootkits change binaries or even modify kernel so that their processes do not show, so there is no easy way to be sure everything has been purged (and whoever did it does not have access anymore) short of complete re-install
[15:54] <ion_> “hacker” – /me cringes
[15:54] <ion_> rkhunter and chkrootkit might give some diagnostics.
[15:58] <cjwatson> Trewas: (FWIW boot from read-only media and verify md5sums plus a manual check of any other unwanted files would normally be sufficient, though I'd only advise it to a competent person)
[15:58] <pitti> james_w, seb128: our system-tools-backeds still installs /etc/dbus-1/event.d/70system-tools-backends; to me it seems entirely obsolete since /usr/share/dbus-1/system-services/org.freedesktop.SystemToolsBackends.service starts it automatically; do you see any problem with that? (works fine for me)
[15:58] <pitti> james_w: (currently processing your mergre)
[16:00] <seb128> pitti: any problem with what? having a duplicate way to start it? seems not optimal but I don't think it creates bugs either
[16:04] <Trewas> cjwatson: right, if you have the known good md5sums available... gathering them by hand takes some effort and debsums at least does not know nearly all packages
[16:04] <pitti> seb128: it's rather about having the s-t-b daemon running all the time, needlessly
[16:05] <hwilde> rkhunter seems pretty cool...   but it just says       Checking /dev for suspicious file types                  [ Warning ]
[16:05] <hwilde> which ones are the suspcious file types :/
[16:05] <hwilde> [11:04:04]          /dev/shm/pulse-shm-2415330484: data
[16:05] <hwilde> hmmm
[16:06] <seb128> pitti: not sure what the "that" refers to in what you wrote before but if you suggest removing the event.d script I think that's a good idea
[16:07] <pitti> seb128: ok; will do that then, merci
[16:07] <seb128> cool, thanks
[16:08] <cjwatson> Trewas: debsums does know nearly all packages, although it omits a few
[16:09] <hwilde> cjwatson, isn't there an automated way to do that from livecd
[16:09] <cjwatson> hwilde: is there?
[16:09] <cjwatson> it's news to me if there is a simple way
[16:10] <cjwatson> http://lintian.debian.org/tags/no-md5sums-control-file.html lists 221 packages, which is a rather small minority
[16:11] <hwilde> I guess you would have to build the checksum list and put it on an external hd first
[16:11] <hwilde> then tell the livecd to read that and compare
[16:12] <hwilde> that would be pretty tight
[16:12] <hwilde> I think i'm going to build it and then check my system
[16:13] <Trewas> cjwatson: well yeah, rootkit would have to be quite carefully constructed to hide in the set of packages which debsums misses :)
[16:16] <gaspa> someone knows who or what takes care of closing bugs, starting from changelogs like (lp:xxxx) ??
[16:16] <gaspa> some scripts? launchpad itself? soyuz?
[16:20] <hwilde> gaspa, #ubuntu-bugs takes care of it
[16:20] <gaspa> ?
[16:21] <gaspa> hwilde: i mean "automatically"...
[16:21] <hwilde> i mean   /join #ubuntu-bugs
[16:24] <seb128> gaspa: soyuz does, why?
[16:25] <gaspa> seb128: thanks.
[16:25] <gaspa> for a discussion on debian-devel. (please a moment... searching for it)
[16:27] <gaspa> seb128: http://lists.debian.org/debian-devel/2008/07/msg00697.html
[16:27] <gaspa> the point is:"if a debian maintainer close a LP bug on his changelog, will be automaticaly closed in launchpad?"
[16:28] <gaspa> the answer seems to be "yes".
[16:28] <gaspa> i only wanted to know how... but now i'm likely satisfied.
[16:28] <seb128> ok
[16:29] <seb128> gaspa: https://wiki.ubuntu.com/ClosingBugsFromChangelog for reference
[16:32] <gaspa> i see, seb128, thanks.
[16:35] <hwilde> how can you destroy the root passwd is somebody set it
[16:35] <cjwatson> gaspa: yes, our tool that syncs packages from Debian parses the changelog for LP: entries
[16:37] <gaspa> cjwatson: yep.
[16:46] <slangasek> gaspa: fwiw, I've just added an explanation to https://wiki.ubuntu.com/UbuntuForDebianDevelopers about the changelog closing, in response to that thread on d-d
[17:32] <jdstrand> kees: well, I haven't figured out the solution yet, but I have identified the problem with ubuntu-cve-tracker and firefox
[17:33] <jdstrand> kees: firefox (the source package) produces the firefox-2 binary, but not the firefox binary
[17:33] <jdstrand> kees: firefox-3.0 (the source package) produces the firefox-3.0 binary and the firefox binary
[17:34] <jdstrand> kees: you can see the issue with 'apt-cache madison' and 'apt-cache showsrc'
[17:35] <jdstrand> (for hardy)
[17:36] <jdstrand> kees: the trick is to get ubuntu-cve-tracker to work this out, without breaking other stuff...
[17:37] <jdstrand> (ie, it needs to pick 'firefox-3.0' as the source package in this case)
[17:37] <kees> jdstrand: hurm, what's the example failure I can see with it at the moment?
[17:38] <jdstrand> kees: well, you can see what happens with ubuntu-cve-tracker by doing './scripts/cve_status CVE-2008-2785'
[17:39] <jdstrand> kees: you can see that the table shows firefox as 'needed' for all releases, though the CVE shows firefox as released for dapper-hardy
[17:39] <jdstrand> kees: however, I don't think it's ubuntu-cve-tracker's fault, but perhaps apt_pkg
[17:39] <jdstrand> (from python-apt)
[17:40] <jdstrand> or perhaps our usage of it
[17:40] <jdstrand> kees: I believe 'apt-cache madison firefox | grep hardy' demonstrates the issue
[17:41] <jdstrand> kees: we really should only get back the firefox 2 source package (which is named 'firefox'), but we get back both firefox and firefox-3.0
[17:41]  * kees scratches his head
[17:42] <jdstrand> kees: at least, I only want to see the firefox 2 source package in that case
[17:43] <kees> hm, we're only using apt_pkg do parse the file...
[17:43] <pitti> hey kees
[17:43] <kees> (and compare versions)
[17:43] <kees> heya pitti!
[17:44] <kees> jdstrand: but yeah, there is certainly something wrong... hm
[17:47] <jdstrand> kees: re apt_pkg> well, it is precisely the parsing that is the issue :) it does seem consistent across various apt invocations, so I am not suggesting a bug there, just that we need to somehow work around it's parsing
[17:52] <Hew> What's the best way to contribute a small patch to language-support-writing-en (to fix bug #58308)? I'm not an experienced contributor, and looking at the naming scheme of the version, appending ubuntu1 doesn't seem appropriate.
[17:53] <slangasek> Riddell: 189MB to go on the CDs? :-)
[17:53] <Riddell> slangasek: I don't think the livefs has rebuilt yet
[17:53] <slangasek> hmm
[17:54] <Riddell> slangasek: it needs a recommends changed in arts but arts fails to build with a nasty compile error I don't understand
[17:54] <slangasek> ok; shall I have a look?
[17:54] <Riddell> http://paste.ubuntu.com/29036/
[17:54] <LaserJock> pitti: bummer, re: rm'ing chroots
[17:55] <pitti> LaserJock: :)
[17:55] <LaserJock> pitti: thanks for the tip though
[17:55] <Riddell> slangasek: don't know if that makes any sense to you
[17:55] <slangasek> Riddell: a vague amount of sense; is this reproducible with the version in the archive?
[17:56] <Riddell> slangasek: yes
[18:00] <cjwatson> Hew: language-support-* are all generated; it's better to make a bzr branch of langpack-o-matic and submit that for review (there are facilities in LP for that)
[18:00] <cjwatson> (oh, and mention the branch in the bug too)
[18:02] <Hew> cjwatson: thanks for your help. I'm a noob at bzr, so I'll have a look at it :-)
[18:08] <jdstrand> kees: hmm-- I don't think this is as complicated as I thought-- a bug was recently introduced that appears to mark all as needed if one is needed
[18:09] <jdstrand> kees: as I think I may have introduced it, I'll fix it :)
[18:09] <kees> jdstrand: okay, cool, I was just zero'ing in on it myself too
[18:09] <slangasek> mathiaz: samba 3.2.0 wants merging :)
[18:12] <asac> pitti: ArneGoetje: have you heard of any issues with the lang packs? you think we could copy them tonight so we can release the ffox/xul bits tomorrow morning?
[18:13] <pitti> asac: one positive (pt from slangasek), no negatives
[18:14] <asac> so noone replied on the call for testing?
[18:14] <pitti> if so, they should have replied to Arne
[18:17] <asac> pitti: so is one week without negative feedback enough for you?
[18:17] <pitti> I don't understand why we don't get feedback this time
[18:18] <asac> pitti: i gave you the reason ;) ... the name matters
[18:18] <pitti> it's just about installing the -proposed packs, checking if GNOME starts and works, and Firefox is translated
[18:18] <asac> pitti: firefox being translated i can check for a lot of languages
[18:19] <pitti> asac: maybe you can verify for Chinese, Spanish, German, and French?
[18:19] <pitti> (for ffox)
[18:19] <asac> pitti: i can do that now.
[18:19] <pitti> ffox is the part I'm most concerned about, the .po files should be ok
[18:19] <pitti> asac: many thanks
[18:20] <asac> pitti: i already checked almost all languages when i acked the packages to enter -proposed
[18:20] <asac> anyway i can retry
[18:20] <pitti> asac: ah, good
[18:21] <asac> pitti: the only thing we should do is to roll the langpacks out half a few publisher runs before the firefox bits
[18:21] <pitti> asac: the -proposed packs will work with the firefox in -updates?
[18:21] <pitti> asac: i. e. you just bumped maxVersion?
[18:21] <asac> pitti: yes. just the other way around
[18:21] <asac> is a problem
[18:21] <asac> right
[18:21] <pitti> *nod*
[18:21] <asac> pitti: let me check that ;)
[18:22] <pitti> mmmmmm testing :-P
[18:22] <asac> for the important languages ;)
[18:22]  * pitti hugs asac
[18:22] <asac> pitti: but in the end the translations didnt change ;)
[18:22] <asac> would be scary if they broke
[18:22]  * asac searches for old ffox and xul
[18:23] <johanbr> asac: What should I do with bugs I find in the network-manager package  from the n-m 0.7 ppa?
[18:24] <slangasek> pitti: if someone can tell me why I get a black screen when trying to switch back after starting a session as a new user, I'd be happy to test more languages for you :-P
[18:25] <zul> slangasek: already merged and uploaded :)
[18:25] <zul> (samba-3.2)
[18:25] <pitti> slangasek: hm, I don't get that; do you use compiz?
[18:25] <slangasek> zul: heh, ok
[18:25] <slangasek> pitti: nope
[18:25] <asac> johanbr: tell me briefly here and i tell you what to do ;)
[18:26] <asac> slangasek: xorg driver issue i'd say. at least sounds wierd enough ;)
[18:26] <johanbr> asac: After resume from suspend-to-ram, n-m takes a very long time (~10 minutes) to expire wireless networks no longer present.
[18:26] <slangasek> asac: well, telling me it's an xorg driver issue doesn't make it stop happening, though
[18:28] <asac> slangasek: right. if there is no choice for your chipset.
[18:28] <slangasek> "intel"
[18:30] <asac> pitti: ok. good news. no translation got disabled after downgrading ... now lets check for breakage
[18:30] <pitti> asac: in the meantime, let me copy the langpacks from hardy-proposed to intrepid
[18:31] <asac> pitti: good idea
[18:31] <pitti> new ffox in intrepid has broken translations, too, the langpacks should help
[18:32] <asac> yep
[18:32] <tkamppeter> Riddell, hi
[18:33] <pitti> running
[18:33] <Riddell> hi tkamppeter
[18:33] <pitti> hey tkamppeter
[18:33] <tkamppeter> Riddell, did you hear anything new from Alex Wauck in the last days?
[18:33] <tkamppeter> hi pitti
[18:34] <Riddell> tkamppeter: no, I didn't get a weekly status report last week, I e-mailed him this morning about it but nothing yet
[18:36] <asac> pitti: ok NEW de, fr, zh_TW, zh_CN, pt_BR, pt_PT and es_ES work fine with _old_ ffox/xulrunner
[18:36] <pitti> yay
[18:37] <asac> pitti: let me upgrade and do the same for new ffox/xul
[18:50] <asac> pitti: ok NEW de, fr, zh_TW, zh_CN, pt_BR, pt_PT and es_ES work fine with _NEW_ ffox/xulrunner
[18:51] <pitti> asac: ok, thanks a lot; I'll do the copy-o-mania hten
[18:52] <asac> pitti: cool. ill remind you tomorrow morning and we can do the final ffox/xulrunner release then
[18:52] <asac> thank you very much
[18:53] <pitti> no problem, thanks for testing
[19:00] <slangasek> Riddell: I think I have a patch for arts; where do you want it?
[19:01] <Riddell> slangasek: an http url is nice
[19:02] <slangasek> Riddell: how about an http url to a mergeable vcs branch? :)
[19:03] <Riddell> slangasek: if that's easy to do, sure
[19:05] <slangasek> Riddell: hrm, given the structure of the bzr branch that's available, perhaps not :/
[19:07] <slangasek> Riddell: http://people.ubuntu.com/~vorlon/arts-ftbfs.diff
[19:09] <Riddell> slangasek: I always said you were a genius
[19:11] <slangasek> well, if I'm writing patches like this one, that must make me an evil genius ;P
[19:13] <liw> slangasek, yikes
[19:21] <ogra> cjwatson, https://bugzilla.mindrot.org/show_bug.cgi?id=1399 does that get us proper statfs calls in sshfs as well ?
[19:26] <kirkland> pitti: hiya, are you still around?
[19:26] <pitti> hey kirkland, yes
[19:27] <pitti> unfortunately no Taekwondo on Mondays during school holidays :/
[19:27] <kirkland> pitti: hey, this is in regards to the ecryptfs MIR
[19:27] <kirkland> pitti: :-)
[19:27] <kirkland> pitti: actually, for one of ecryptfs' build deps, opencryptoki
[19:27] <kirkland> pitti: doko had raised a concern about it, hard coding 2048 for path names
[19:28] <pitti> right, I saw it
[19:28] <kirkland> pitti: i wrote a patch, that made it upstream into opencryptoki last week, and an updated package is now in Debian unstable
[19:28] <kirkland> pitti: would you be able to force a sync?
[19:28] <kirkland> pitti: there are no Ubuntu changes
[19:29] <pitti> kirkland: nice work!
[19:29] <kirkland> pitti: oh, sure, no problem ;-)
[19:29] <kirkland> pitti: also, I think your concerns about the ecryptfs PAM module are addressed in the last merge
[19:30] <pitti> kirkland: opencryptoki synced
[19:30] <pitti> 2.2.6+dfsg-1
[19:30] <kirkland> pitti: i have a stack of manpages I wrote for ecryptfs that I'm sending upstream today, should hit Debian within a day or two
[19:30] <kirkland> pitti: cool, thanks, i'll point doko to that in the MIR bug report
[19:31] <pitti> kirkland: that's good (but that won't block the MIR)
[19:31] <kirkland> pitti: see if that code makes him happier ;-)
[19:31] <kirkland> pitti: oh, right, more just an heads up that I might need to do another merge later in the week
[19:44] <mathiaz> 13:09 #ubuntu-devel: < slangasek> mathiaz: samba 3.2.0 wants merging :)
[19:44] <mathiaz> 13:10 #ubuntu-server: < zul> mathiaz: samba-3.2 uploaded
[19:44] <mathiaz> that was fast...
[19:44] <slangasek> quite :-)
[19:45] <zul> mathiaz: i was up early :)
[19:51] <slangasek> jdstrand: have you seen bug #249881?  ISTR that SASL/EXTERNAL auth was one of the use cases you test for, no?
[19:51] <alex-weej> how do i enable the apport segfault catcher?
[19:51] <alex-weej> lots of things going wrong in intrepid... think i need to get on top of them
[19:52] <RAdams> I need to compile 2.6.24-19 with acpi debugging AND tracing to track a known issue on Dell Latitude d800 and so laptops. I am familiar with how to do this with a vanilla kernel, but I want to confirm what the most useful/correct way to do this for this Ubuntu-specific build. I would love to help finally nail down this problem and thus contribute to the improvement of Ubuntu, but I need a point in the right direction. Thanks.
[19:54] <jdstrand> slangasek: it is one of the test cases in qa-regression-testing, yes
[19:54] <slangasek> RAdams: I'd suggest asking on #ubuntu-kernel
[19:54] <RAdams> slangasek: thank you
[19:55] <jdstrand> slangasek: oh, 'external', no, I just test supportedSASLMechanisms: DIGEST-MD5
[19:55] <slangasek> jdstrand: ok
[19:57] <slangasek> jdstrand: right, looks like this is broken in hardy but works in sid (so probably works in intrepid too, haven't tested there)
[19:59] <jdstrand> slangasek: I've made a note to add a test case for this
[19:59] <zul> slangasek: how do you test that?
[20:00] <slangasek> zul: well, the bug reporter shows how to check whether it's a supported sasl mech
[20:01] <zul> slangasek: k
[20:12] <pwnguin> poor sh
[20:18] <ilowe> Anybody have a quick and easy way to get mercurial to output a properly formatted changelog?
[20:25] <alex-weej> how do i enable the apport segfault catcher?
[20:26] <mario_limonciell> alex-weej, modify /etc/default/apport
[20:26] <mario_limonciell> there is a variable for enabled={0,1}
[20:27] <alex-weej> cool
[20:27] <alex-weej> cheers
[20:29] <ilowe> How do I patch a config file when installing a package? Do I have to do it "manually" in my postinst or is there a better way?
[20:36] <mario_limonciell> pitti, slangasek did one of you folks adjust the component of the fglrx-installer source package from multiverse to restricted?
[20:37] <slangasek> in what context?
[20:37] <slangasek> fglrx-installer - looks like it's intrepid-only?
[20:37] <mario_limonciell> yeah it is
[20:37] <slangasek> I haven't touched that, no
[20:37] <mario_limonciell> it's lived in multiverse for some time
[20:37] <mario_limonciell> since i first uploaded it
[20:38] <mario_limonciell> which was great since i could do the uploads without a sponsor
[20:38] <mario_limonciell> but over the weekend it looks like it moved around :(
[20:38] <slangasek> yeah, wasn't me
[20:39] <slangasek> were the packages it builds previously in restricted?
[20:40] <mario_limonciell> yeah...
[20:40] <mario_limonciell> so maybe it was an oversight that was just rather convenient for me
[20:47] <mario_limonciell> slangasek, well is copying from PPA release pockets to the archive supported now?  perhaps that can be a more sane use model for doing these uploads?
[20:48] <slangasek> mario_limonciell: that would seem to imply archive admin intervention, so no, I don't think that's more sane...
[20:49] <mario_limonciell> hum.
[20:57] <Wubbbi> bug 249850
[21:18] <pitti> mario_limonciell: no, copy-package is too dumb to respect/change the overrides, so you'd have to do regular uploads
[21:20] <mario_limonciell> pitti, could you change it back to leaving the source package in multiverse then?
[21:20] <pitti> mario_limonciell: it doesn't make sense to have the source in mulitverse and binaries in restricted
[21:20] <mario_limonciell> i'd hate to have to bug sponsors for this since i'm the only one that can control the upstream packaging for it at this point
[21:21] <pitti> mario_limonciell: I can move the entire source/binaries back to multiverse for the time being, if that's better?
[21:22] <mario_limonciell> pitti, well for doing uploads for now that makes more sense, but for long term, i suppose it should live in restricted
[21:22] <pitti> right
[21:23] <mario_limonciell> pitti, well whatever you think is the best solution at this point
[21:26] <pitti> asac: for the record, copy to intrepid done, starting copy to hardy-updates now
[21:26] <pitti> asac: should be done by midnight
[21:33] <alex-weej> asac: is n-m 0.7 planned for intrepid?
[21:48] <asac> alex-weej: yes
[21:49] <alex-weej> is it getting into the archive soon or should i use your PPA to test?
[21:55] <slangasek> ScottK: is there an MIR in progress for libcrypt-openssl-rsa-perl (needed by libmail-dkim-perl)?
[22:05] <stgraber> superm1: Hi, I just noticed the upload of the new fglrx, is it supposed to work with the new X server ?
[22:07] <AlinuxOS> hello, I'm installing Ubuntu 8.04.1 on my Acer Aspire One (nettop), knows someone about this kind of installation?
[22:09] <mario_limonciell> stgraber, unfortunately not.
[22:09] <mario_limonciell> stgraber, still need to roll back to older x server
[22:09] <mario_limonciell> this release does perform a lot better though otherwise
[22:10] <stgraber> ok, so let's hope next driver will solve that (maybe this Wednesday if they stick to their "usual" release schedule)
[22:11] <mario_limonciell> stgraber, well this is the "next driver" (the 8-7 release)
[22:11] <mario_limonciell> so i'm really disappointed too
[22:11] <stgraber> argh :(
[22:11] <stgraber> so one more month to wait and hope we'll have something working ...
[22:11] <mario_limonciell> well i'm starting to wonder if we can get around this by just restoring the single missing symbol
[22:11] <mario_limonciell> for now
[22:12] <mario_limonciell> but i dont know exactly what the function does, so i'm wary of doing that
[22:12] <stgraber> would be great to have it install again, the new cdbs packaging works fine from what I've tested (before the new X upload), the only problem is that missing symbol ...
[22:13] <mario_limonciell> well if nothing else, this could be backported though to hardy if users wanted it too
[22:14] <mario_limonciell> the way that the packaging is handled, it should override LRM, and it won't apply any 2.6.26 support patches when built on != intrepid
[22:33] <mario_limonciell> so it appears that with the libtool in intrepid, ltmain.sh got moved from /usr/share/libtool/ltmain.sh to /usr/share/libtool/config/litmain.sh.  Should we be writing patches to configure scripts to handle this, or what's the appropriate policy for it?
[22:34] <slangasek> you have packages where this requires handling?
[22:35] <mario_limonciell> well it looks like libsmbios is FTBFS now
[22:35] <mario_limonciell> and that appears to be the root cause from what i've looked around
[22:36] <slangasek> in the general case, packages ship a copy of ltmain.sh in their source; a smaller number of packages update at build time using libtool -f -c.  No package ought to be linking directly to the system copy of ltmain.sh, AFAIK.
[22:37] <mario_limonciell> well after a run of configure, there is a symlink to where it should be (was in hardy) in /usr/share/libtool.
[22:37] <mario_limonciell> so then the package should be fixed to use its own ltmain.sh then
[22:37] <mario_limonciell> i'll speak to upstream about it
[22:38] <kees> wow.  pulse audio sounds really really bad.
[22:38] <mario_limonciell> i suppose this explains why my patch was working early last week though.  the new libtool that broke stuff came in on the 18th
[22:39] <slangasek> mario_limonciell: it doesn't look like an upstream bug to me, it looks like a packaging bug
[22:39] <slangasek>         test -e build/ltmain.sh -a -L build/ltmain.sh || \
[22:39] <slangasek>                 ln -sf /usr/share/libtool/ltmain.sh build/ltmain.sh
[22:40] <slangasek> there's a "libtool -f -c" command for this, someone broke the abstraction
[22:40]  * slangasek sees who the maintainer is and sighs
[22:41] <kees> omg, seriously, how do I get rid of pulse?
[22:42] <mario_limonciell> slangasek, yeah you are right.  in the upstream tarball the ltmain.sh is present
[22:43] <mario_limonciell> slangasek, why do you sigh about the maintainer though?
[22:43] <slangasek> kees: system -> preferences -> sound?
[22:43] <kees> slangasek: doesn't seem to work for gnome start up nor flash.  they are ignoring it.
[22:45] <slangasek> mario_limonciell: History<tm>
[22:45] <kees> ugh, such horror.
[22:45] <slangasek> kees: no one else is screaming about pulseaudio sounding horrible; you might want to file a bug report about that?
[22:45] <mario_limonciell> slangasek, well i guess i'll file a bug in debian then with this chap
[22:46] <kees> slangasek: yeah, I guess so.  *sigh
[22:46] <slangasek> kees: and if this is intrepid, are you sure this isn't the weirdness with the snd_pcspkr driver?
[22:48] <kees> slangasek: well, it does sound that bad, so maybe it is.  I hadn't heard of that until you mentioned it.
[22:50] <slangasek> kees: try rmmoding the module in question (snd_pcspkr or snd_spkr or something I don't remember exactly) and see if it takes care of it
[22:50] <kees> hrm, it's being held open, one sec
[22:51] <slangasek> then afterwards, let me know if you see a bug report open about this, so I can milestone it :)
[22:53] <kees> slangasek: yeah, it has clearly chosen the wrong default sink.  thanks PA
[22:54] <slangasek> not sure PA is to be blamed for alsa suddenly enabling bizarre PC speaker output devices :)
[22:54] <kees> yeah, though clearly ALSA picks the right default...
[22:55] <kees> pulseaudio manager is helpful enough to not let me change it.  *sigh*
[22:56] <tedg> kees, you might need the pulse audio tools.
[22:56] <kees> tedg: I've got like 3 open currently.  which is the "right" on?
[22:56] <tedg> kees: Try pavucontrol and pavumeter
[22:57] <tedg> kees: Then you can right click and change the device defaults.
[22:57] <tedg> kees: puvacontrol, Output Devices, then set the right one to default.
[22:57] <kees> tedg: hah.  that was very discoverable.  (the right-clicking)
[22:57] <TheMuso> kees, slangasek, tedg, I'll be looking at the pulse/PC speaker issue this week, maybe even today for intrepid. There are bugs filed on it, so its certainly known. Its an alsa issue.
[22:58] <tedg> kees: You might need to go to Playback tab and change some things there also.
[22:58] <slangasek> TheMuso: can you give me a bug number?
[22:58] <kees> tedg: default changed it.
[22:58] <TheMuso> slangasek: Give me a bit to get to that folder in my mail. Still processing mail for the first time this morning.
[22:58] <slangasek> TheMuso: ok :)
[22:58] <kees> so now I guess I should open bugs about flash and gnome login sounds not respecting the sound config settings.  (I set everything to ALSA in an earlier attempt to fix this)
[23:00] <slangasek> if by gnome login you mean gdm, there's a bit of a problem with trying to make it respect per-user sound settings
[23:00] <tedg> kees: No, you should just give up and accept "the pulse way" ;)
[23:01] <kees> tedg: feh.  only when it doesn't skip on start-up and doesn't eat half a cpu.
[23:01] <tedg> kees: You need quad-core, then it's only 1/8th the CPU.
[23:02] <kees> slangasek: I assume I mean gnome, but whatever plays the "login" sound event.
[23:02] <kees> tedg: I have a quad core.  they're busy doing other things.  (hence the skipping and getting in my way generally being a problem for me and pulse)
[23:03] <kees> but, yes, it seems that alsa is the real culprit here, somehow
[23:10]  * kees blames it all nonfree flash
[23:11] <kees> tedg: okay, if you can show me how to get flashplugin-nonfree to work with pulse, I'll switch to pulseaudio.  :)
[23:12] <kirkland> is there a lint-like program to run on manpage source code?
[23:14] <tedg> kees: swfdec works for me.  :)
[23:14] <kees> tedg: it doesn't for me.  :)
[23:15] <tedg> kees: Chris Blizzard just said that mozilla trunk works with Ogg, just upgrade.  I'm sure there are no security issues.
[23:16] <tedg> kees: BTW, are you sure you tried swfdec and not gnash, gnash never worked and swfdec was much, much better.
[23:17] <kees> tedg: hrm? my problem is half the flash sites I go to don't work with either swfdec or gnash.  I would agree that swfdec was better, though.
[23:17] <kees> current problem seems to be that even with libflashsupport installed, flash tries to use alsa instead of pulseaudio
[23:18] <tedg> kees: I don't go to that many flash sites I guess...  I like that swfdec doesn't load unless I ask it to.
[23:18] <kees> tedg: yeah, that's handy.  NoScript basically does the same for me.
[23:19] <slangasek> augh, how do I get dbs-edit-patch to be non-fecal for 10 seconds?
[23:20] <kees> slangasek: ew.
[23:20] <kees> tedg: although at this rate, I'm more likely to have less frustration with swfdec than nonfree flash playing audio back on the only available audio device, the alsa pc speaker.  *sob*
[23:22] <tedg> kees: Freedom is good for you ;)
[23:23] <kees> tedg: so is being able to read crazy hacker blogs.  :)
[23:23] <kees> cjwatson: why was openssh-blacklist moved to a Suggests on openssh-server?
[23:24] <slangasek> space reasons
[23:24] <slangasek> do you think it's still critical to include?
[23:27] <kees> slangasek: well, it leaves new servers open to dumb people putting busted keys on the server.
[23:27] <kees> slangasek: in theory, no keys should be left in the world.
[23:28] <slangasek> ok
[23:28] <slangasek> maybe it can be re-added in the case of openssh-server without hurting us on the CDs, I'm not sure
[23:31] <kees> tedg: fail.  swfdec just crashed firefox.  :)
[23:32] <sbeattie> kees: wait, wha? You're reading crazy hacker blogs and you need/want flash? Uhm, h'okay....
[23:32] <cjwatson> ogra: statfs> I don't know whether sshfs needs to be updated too
[23:33] <ogra> cjwatson, do you plan to pull that into our 4.7 ?
[23:33] <cjwatson> kees: as Steve said, it didn't fit. I know demoting it is not without problems, but find me some space
[23:33] <kees> sbeattie: I was wondering when someone would ask.  ;)
[23:33] <ogra> seems the patch is 5.1 only
[23:33] <cjwatson> ogra: I'd rather not brutalise our 4.7 further, TBH
[23:33] <kees> cjwatson: okay, no problem.  as long as you're okay with it.
[23:33] <ogra> it would be massivley helpful for ltsp localapps
[23:33] <cjwatson> understood, I'll see if I can get us up to 5.1
[23:33] <ogra> which is what i'm going to portland for on wed :)
[23:34] <ogra> that would indeed be even better
[23:38] <cjwatson> ogra: I was trying to get 4.7 (with all the key vulnerability nightmares) settled for lenny
[23:40] <ogra> understood ... but then 5.1 would indeed move us away from debian for now
[23:40] <ogra> (isnt lenn yfreezing in about a month or two ? )
[23:40] <slangasek> or a day or two
[23:40] <ogra> oh, really ? that soon ?
[23:41] <slangasek> "this week"
[23:41] <ogra> i didnt really keep track
[23:41] <ogra> i just knew that sept. was the estimated date ... so i suspect dec to be the real one :)
[23:41] <ogra> *suspected
[23:42] <ogra> impressing
[23:42] <kirkland> cjwatson: can you recommend an sort of lint-like utility that reviews manpage source?
[23:51] <cjwatson> kirkland: man --warnings (or --warnings=foo,bar,baz where warning names are as listed in the Warnings node of 'info groff')
[23:51] <cjwatson> ogra: I was going to put it in experimental
[23:51] <cjwatson> ogra: and yes, it would introduce divergence, but it's not as if I have problems contacting the Debian maintainer ;-)
[23:52] <ogra> heh