[00:41] <jcgs> hi, does anyone know what to do if i think i've found that a package in the repositories is unusable?
[00:41] <lifeless> you should file a bug
[00:42] <jcgs> i already did
[00:42] <jcgs> in march
[00:42] <lifeless> great
[00:45] <jcgs> lifeless: i was just wondering if i could try and help get some progress on it
[00:45] <lifeless> if you want to work on it, that would be great.
[00:46] <jcgs> apparently there is a perfectly good package available from another repository
[00:46] <jcgs> i wondered if it would be possible to do a swap
[00:47] <jcgs> lifeless: i don't think it's so much a problem with the code, as the specific package available in the repositories
[00:51] <RAOF> jcgs: Working out precisely what the problem is is a great first step :)
[00:54] <jcgs> i've filed a bug report already, how would i go about decoding the information in that, and related bug reports
[00:54] <jcgs> is there a source package available i could recompile from?
[00:54] <RAOF> Yes, of course.
[00:55] <RAOF> “apt-get source $PACKAGENAME”
[00:56] <jcgs> RAOF: that generated some errors
[00:57] <jcgs> apaprently public key not found
[00:57] <RAOF> That's a warning, not an error.  You're good to go.
[01:02] <jcgs> RAOF: where did it put it? sudo find / -name "pango-graphite" returned nothing
[01:02] <RAOF> It puts it in a subdirectory of your current directory.  $PACKAGENAME-$UPSTREAM_VERSION
[01:03] <RAOF> So, it's likely to be in the pango-graphite-0.9.2 directory.
[01:05] <cjwatson> note that that find command returns only directory entries named exactly "pango-graphite" - you have to do a bit more to make it be a substring search
[01:05] <CynthiaG> "*pango-graphite*"
[01:05] <CynthiaG> what cjwatson said
[01:06] <RAOF> Hm.  Looks like an interensting package, too.
[01:06] <ajmitch> that package looks like a good candidate for removal
[01:07] <ion> Yay, maverick’s kernel has an automatic workaround for an ACPI bug i had to work around manually in lucid. (Thermal sensor wouldn’t work, thus CPU throttling wouldn’t work, thus the laptop would overheat.)
[01:07] <jcgs> ajmitch: why? is it beacuse it is broken?
[01:08] <ajmitch> jcgs: broken, and hasn't seen an update for quite awhile in debian
[01:08] <ajmitch> though it doesn't look entirely dead upstream
[01:09] <jcgs> ajmitch: apparently upstream are maintaining their own ubuntu repo
[01:09] <jcgs> i was wondering if someone could just swap their package into the ubuntu repositories?
[01:12] <ajmitch> if it's as severwly screwed up as it looks (crashing firefox, etc), then it's possible it could be updated in lucid after being tested for a bit in maverick
[01:12] <ajmitch> someone would need to spend time to do so
[01:14] <ajmitch> it'd depend on whether it needs other libraries to be upgraded as well
[01:19] <jcgs> erm, sorry to waste your time so much, but what do i do with the file now that i've got them
[01:19] <jcgs> i seem to have two tarballs, i'm not quite sure why
[01:22] <jcgs> i think i'm ok now, but when i run the configure script, it seems to want three packages that don't exist: pango pangoft2 and glib-2.0
[01:23] <jcgs> these don't seem to be in the repositories
[01:23] <CynthiaG> jcgs: (sudo) apt-get install libpango-dev libpangoft2-dev libglib2.0-dev
[01:23] <CynthiaG> or similar names, see Synaptic or Aptitude for the real names or press Tab to check the names
[01:23] <RAOF> And, for future reference, install apt-file and try “apt-file search pango.pc”
[01:23] <jcgs> CynthiaG: thanks
[01:24]  * ajmitch really doesn't like tarball-in-tarball packages
[01:29]  * micahg wonders what ajmitch has against firefox :P :)
[01:32] <jcgs> it fails to make with error "memmove is not a member of std"
[01:33] <jcgs> and adding #include <string.h> hasn't remedied the situation :(
[01:36] <jcgs> aha! it meant what it said. std::memmove has become memmove
[01:43] <psusi> k, so I'm reading the autoconf manual and managed to use the AC_CHECK_LIB macro to test for glib-2.0... how do I get the include path added to CFLAGS though for the glib headers?
[01:43] <psusi> AC_CHECK_HEAEERS tests if it works, but doesn't seem to have a way to specify the include path
[06:30] <antileet> Hi, is this the right place to ask for help with pbuilder?
[07:31] <pitti> Good morning
[07:32] <ddecator> morning pitti
[07:33] <ajmitch> morning
[07:45] <dholbach> good morning
[07:50] <CynthiaG> Good morning
[08:06] <ttx> pitti: could you reject etckeeper from the lucid-proposed queue ? I'll upload a better fix.
[08:23] <netshine> hey all..
[08:27] <pitti> ttx: *flush*
[08:27] <ttx> thanks!
[08:28] <pitti> de rien :)
[09:37] <ericm> pitti, ping
[09:37] <pitti> hello ericm
[09:38] <ericm> pitti, I saw your name at https://launchpad.net/libusb, just wondering who's still maintaining this libusb-0.1 package?
[09:38] <ericm> pitti, there is a bug 427805, which I found a fix and many else reported working, just wondering what is the right way to go
[09:38] <pitti> it's abandoned upstream
[09:39] <ericm> pitti, yeah - looks like will be replaced by the new libusb, yet it looks still used somewhere
[09:39] <pitti> libusb-1.0-0 is the current version, so it'd be better to port stuff over to that one
[09:39] <pitti> but if you have a patch for this, that's great!
[09:39] <pitti> ericm: just subscribe ubuntu-sponsors
[09:39] <ericm> pitti, link?
[09:40] <pitti> https://wiki.ubuntu.com/SponsorshipProcess
[09:41] <ericm> pitti, ok - I'm reading, will let you know if I have further questions, sorry to bother
[09:41] <pitti> ericm: no need to be sorry, thanks; as I said you just need to subscribe ubuntu-sponsors
[09:41] <pitti> to the bug
[09:41] <ericm> pitti, ok
[09:42] <ericm> pitti, done
[10:28] <_rene_> no mvo here? hrmpf ;)
[10:28] <pitti> he's on vacation today
[10:28]  * _rene_ will then write a mail. sorry for disturbing ;)
[10:57] <asac> cjwatson: i have someone who is scared about his complex multiboot setup and wonders if alternative installer asks before he wipes any bootloader
[10:57] <asac> cjwatson: he found bug 337957
[10:58] <cjwatson> I changed it in lucid to ask
[10:58] <cjwatson> hence that fix-released
[10:58] <cjwatson> see the changelog for grub-installer 1.49ubuntu9
[11:46] <stefanlsd> world cup kickoff parties here in south africa. stuff is going crazy
[11:49] <pitti> stefanlsd: hey, how are you? heh, enjoy the next three weeks :)
[11:50] <Chipzz> stefanlsd: as someone who doesn't give a rats ass about soccer, I was hoping this channel would be spared of the nonsense. guess not :)
[13:17] <ScottK> pitti: Would you please rescore kdepimlibs (just affects powerpc).
[13:18] <pitti> ScottK: sure, rescored to 1 :)
[13:18] <pitti> j/k
[13:18] <ScottK> Thanks.
[13:18]  * pitti pushes it to the queue front
[13:23] <sebner> pitti: immer diese vetternwirtschaft :P  hi btw :)
[13:23] <pitti> hey sebner
[13:23] <pitti> *pfft* :-)
[13:24] <pitti> yes, we do have some bureaucracy these days, but rescoring doesn't yet need a written contract in triplicate :-P
[13:24] <sebner> :D
[13:54] <Chipzz> pitti: a single contract signed with blood will do? ;)
[13:55] <pitti> barely
[13:55] <Chipzz> btw, is it just me or are a lot of the core developers on vacation this week?
[13:55] <Chipzz> mvo & keybuk
[13:55] <Chipzz> coincidence?
[13:57] <Chipzz> hrrrm probably taking a break post-lucid
[14:12] <ScottK> Maybe they are football fans.
[14:14] <pitti> well, at least mvo is rather a wedding fan :)
[14:14] <sebner> lol
[14:14] <sebner> ScottK++
[14:24] <LucidFox> Speaking of which, C++ really should have been named ++C. ;)
[14:27] <soren> LucidFox: Or Java--.
[14:27] <LucidFox> LOL
[14:27] <soren> srsly
[14:27] <soren> I don't look at C++ and think, "wow, this is a much better C than C."
[14:28] <LucidFox> Java isn't a much better C than C, either ;)
[14:28] <soren> Certainly not.
[14:28] <LucidFox> it's a completely different language that just happens to use curly brackets syntax
[14:28] <soren> *nod*
[14:29]  * psusi remains convinced that Java was created by engineers in the field for schools to teach students so that they would learn to be bad programmers, thus insuring job security for the older engineers
[14:32] <LucidFox> ...
[14:32] <LucidFox> psusi> You realize I earn, like, money from Java programming?
[14:33] <psusi> I hadn't, no... and that was half tounge-in-cheek ;)
[14:34] <Chipzz> psusi: I have similar thoughts on Java tbh
[14:34] <Chipzz> LucidFox: my condolences :P
[14:35]  * LucidFox hisses
[14:35]  * soren recently stumbled upon his Java 1.4 Certified Programmer certificate :)
[14:36]  * psusi often does miss having destructors and proper stack unwinding in C, that's for sure
[14:42] <pitti> vala! vala! vala!
[14:42] <pitti> (hey, it's Friday afternoon, some trolling should be tolerated by now)
[14:47] <psusi> hehe ;)
[14:48]  * psusi passes out copies of e2defrag for everyone to review, test, and have eat their data over the weekend ;)
[14:49] <pitti> psusi: oh, new ureadahead goodness?
[14:51] <psusi> pitti: yea, I have some of that too I need to have keybuck review and merge
[14:51] <ion> Awesome
[14:51] <psusi> but I uploaded a new e2defrag release last night.... it burns up a good deal of cpu at the start... room for optimization there... but it works now on a 1.5 tb drive with only 2 gigs of ram
[14:52] <psusi> I modified it to use an extent based block relocation map instead of two paralell arrays of block pointers, which needed 666 megs of ram for a 320 gig drive
[14:53] <ion> Btw, did you manage to fix the problem of readaheaded device blocks not being considered by the filesystem code when reading files etc?
[14:58] <ion> psusi: (It was you who mentioned encountering that problem, wasn’t it?)
[14:58] <psusi> sort of... had to split the reading into two passes to do it... first read all the directory blocks via the dev node, then read the normal file data the usual way
[15:01] <psusi> I also want to get a patch applied I made to e2fsprogs so we can turn on lazy_itable_init by default and vastly speed up mkfs on large volumes... very frustrating to have Ubiquity sit at 5% complete for 20 minutes while it formats a 1.5tb disk with no apparent progress
[16:03] <bdrung> jdstrand: why did you upload arc-colors? we had it removed from lucid.
[16:04] <jdstrand> bdrung: it was sitting in maverick's NEW as part of a sync I assumed. I figured since it wasn't blacklisted we would try again in maverick
[16:04] <bdrung> jdstrand: can we remove and blacklist it?
[16:05] <jdstrand> bdrung: sure. can you file a bug listing why it should be removed and it should be blacklisted, and assign my to it?
[16:06] <bdrung> jdstrand: bug #550306
[16:08] <jdstrand> bdrung: k, I tasked it and assigned it to me
[16:08] <bdrung> thanks
[16:43] <jdstrand> mdz: fyi, fta pointed me to http://googlechromereleases.blogspot.com/2010/04/dev-channel-update_08.html regarding font changes
[16:44] <mdz> jdstrand: thanks
[16:45] <jdstrand> sure, np
[16:49] <mdz> jdstrand: I guess we can all look forward to our browsers changing in random and unexpected ways in SRUs from now on :-/
[16:51] <jdstrand> mdz: *sigh*, yes, unfortunately. That is the new world order starting with chromium and mozilla following suit...
[16:52] <jdstrand> mdz: but, on the plus side, the experience is more like Windows now :P
[16:52] <mdz> jdstrand: hooray for matching user expectations :-)
[16:52] <jdstrand> hehe
[17:53] <crimsun_> TheMuso: I'll push it to bzr after flight-hell
[18:23] <hallyn> jinkeys:  bzr: ERROR: Cannot lock LockDir(lp-69481744:///~ubuntu-branches/ubuntu/maverick/qemu-kvm/maverick/.bzr/branchlock): Transport operation not possible: readonly transport
[18:25] <mathiaz> hallyn: did you try to bzr co lp:ubuntu/qemu-kvm?
[18:26] <hallyn> i had started with bzr co lp:ubuntu/maverick/qemu-kvm qemu-kvm-serge
[18:26] <hallyn> then did bzr merge-upstream
[18:27] <mathiaz> hallyn: right - so bzr co will do a checkout which means you're bound to the branch in LP
[18:28] <mathiaz> hallyn: if you commit locally it will try to commit directly to LP as well
[18:28] <hallyn> oops
[18:28] <hallyn> so i should branch first
[18:28] <mathiaz> hallyn: yeah - try to bzr branch instead
[18:28] <mathiaz> hallyn: this may be the reason why you've ran into the error above
[18:41] <smoser> hey all, i've a question. cloud-utils (https://launchpad.net/ubuntu/+source/cloud-utils) is a native package.
[18:41] <smoser> i believe that the numbering is wrong 0.11-0ubuntu1
[18:42] <smoser> i think that should be just 0.11. right ?
[18:46] <SpamapS> am I the only one who thinks cdbs *.mk files just look like spaghetti in a blender?
[18:49] <mathiaz> hallyn: could you use the same branch for your qemu-kvm update?
[18:49] <mathiaz> hallyn: that way when creating another merge proposal the comments of the existing merge proposal will be kept
[18:50] <mathiaz> hallyn: it makes the review easier as the comments I made in the review are still around
[18:50] <mathiaz> hallyn: IIRC you need to use the same branch to do so
[18:53] <cjwatson> smoser: native packages should indeed not generally contain a dash in their version
[18:53] <hallyn> mathiaz: ok.  i've got a new branch i'm developing it, but i'll update the old branch when i've tested
[18:53] <cjwatson> SpamapS: just use dh instead then :)
[18:53] <smoser> cjwatson, thank you.
[18:55] <cjwatson> hmm - from the trend lines, dh should have overtaken cdbs in popularity in unstable by DebConf
[18:55] <SpamapS> cjwatson: unfortunately, debian-maven-helper is tied to cdbs pretty heavily. ;)
[18:58] <hallyn> mathiaz: so to be clear, when you say a single changelog entry, you mean debian/changelog, not bzr changelog, right?  I guess I wasn't quite sure whether you wanted a 1-1 relationship between those, but your comment above makes it clear that you don't.  (good)
[18:59] <mathiaz> hallyn: right
[18:59] <mathiaz> hallyn: I usually use debcommit instead of bzr commit
[18:59] <mathiaz> hallyn: as debcommit will actually use debian/changelog to infer the commit message for the bzr commit message
[19:00] <mathiaz> hallyn: you can test what would be done by using debcommit -n
[19:00] <mathiaz> hallyn: but I definetely don't require to have a 1-1 mapping between changelog entries and bzr commit messages
[19:00] <mathiaz> hallyn: on the contrary
[19:02] <hallyn> bzr ci seemed to base on debian/changelog as well
[19:03] <mathiaz> hallyn: you meant by looking at the bzr log for the existing branch?

[19:05] <hallyn> i assumed it just took the top debian/changelog entry
[19:05] <hallyn> and pasted that into my editor to start
[19:06] <hallyn> i'll play more in  a toy branch later
[19:07] <hallyn> so is it safe to say that every package has a corresponding lp:ubuntu/package-name branch, which corresponds to what you get from 'apt-get source package' ?
[19:07] <hallyn> or did i just get lucky?
[19:07] <mathiaz> hallyn: nope - that's the plan
[19:07] <hallyn> i see
[19:07] <mathiaz> hallyn: almost all packages have a corresponding bzr branch
[19:08] <mathiaz> hallyn: I think there is a minor number of packages that are not imported yet
[19:09] <mathiaz> hallyn: https://code.launchpad.net/ubuntu/+source/qemu-kvm
[19:09] <mathiaz> hallyn: ^^ gives a good overview about the branches that are available for a package
[19:09] <mathiaz> hallyn: I have it set as a shortcut in my firefox
[19:10] <mathiaz> hallyn: so that I can easily lookup the state of src package
[19:40] <statik> hi SpamapS, thanks for working on the couchdb 0.11 merge
[19:52] <RoAkSoAx> pitti: hi there! I was wondering why http://cdimage.ubuntu.com/cdimage/.manifest-daily is not showing others flavors besides ubuntu desktop isos?
[19:53] <RoAkSoAx> other isos besides ubuntu desktop*
[19:54] <uga> Hi there, I hope this is the right place for asking, after an unhelpfull google search...
[19:54] <uga> have there been big changes in the intel graphics drivers in maverick? after my upgrade I managed getting up to a 200frames in 5s in glxgears...
[19:54] <cjwatson> RoAkSoAx: that's probably more my thing, let me look
[19:55] <uga> either I'm missing important configs or something is pretty weird
[19:56] <RoAkSoAx> cjwatson: ok :)
[19:56] <marcococos> hello. can anyone please tell me why is gcc installed on ubuntu by default?
[19:56] <cjwatson> because getting online to fetch more packages sometimes involves compiling a driver (which you got on a CD or whatever)
[19:57] <cjwatson> it's a compromise
[19:58] <cjwatson> RoAkSoAx: heh, if you look closely at the file sizes it's actually a mislabelled xubuntu manifest
[19:59] <marcococos> oic
[19:59] <micahg> cjwatson: is there any follow up I need to do with you WRT the mozilla package set?
[19:59] <marcococos> maybe one would need to compile wireless drivers... i see
[19:59] <marcococos> well, thanks for the info
[20:00] <cjwatson> RoAkSoAx: fixed now
[20:00] <cjwatson> micahg: no, I think I still have the action
[20:00] <micahg> cjwatson: k, thanks
[20:00] <cjwatson> I just suck
[20:01] <RoAkSoAx> cjwatson: thank you :). And would it be possible to haven such manifest for older Ubuntu releases?
[20:01] <micahg> cjwatson: ?  I wasn't complaining :)
[20:01] <cjwatson> RoAkSoAx: I'd rather not, the point of that manifest is to measure how well daily builds are being mirrored
[20:01] <cjwatson> RoAkSoAx: http://releases.ubuntu.com/ has its own manifest
[20:02] <cjwatson> and the dailies built for older releases are unreliable and mostly stale
[20:03] <RoAkSoAx> cjwatson: this one then: http://releases.ubuntu.com/.manifest (but it shows only 10.04 and not older ones)
[20:04] <cjwatson> I guess I'd rather let our mirroring folk decide on that - that originally had the older releases too but it was stripped back for release
[20:04] <cjwatson> why do you need it?
[20:04] <cjwatson> jpds: ^- do you care if the releases.u.c manifest grows older releases again?
[20:04] <elmo> cjwatson: it should, please
[20:04] <elmo> cjwatson: it's only meant to be stripped down during release to make the mirror prober run faster
[20:04] <RoAkSoAx> cjwatson: for testdrive. TO be able to add support for testdriving old isos, such as hardy
[20:05] <cjwatson> ok, sure, I can change that then
[20:05] <RoAkSoAx> cjwatson: awesome. Thank you :)
[20:06] <cjwatson> ok, I've moved .manifest.full back over the top of .manifest
[20:07] <elmo> RoAkSoAx: I wouldn't recommend relying on that file for anything
[20:07] <elmo> RoAkSoAx: it's going to change around every major release on releases.ubuntu.com (i.e. beta, rc and final)
[20:08] <the-fallen> hello
[20:08] <RoAkSoAx> elmo: At first, TestDrive kinda used a hardcoded list of ISOs, but we decided to use the manifests to parse the available ISOs and add them to the list given the preferences desired
[20:08] <cjwatson> maybe testdrive should look for .manifest.full first, and only .manifest if that fails
[20:09] <cjwatson> when we prune the manifest back for release, we put a full version on .manifest.full
[20:09] <RoAkSoAx> cjwatson: yeah than can also be done. The only thing I need the manifest for is to be able to grab the location of the ISO per each release/flavor
[20:10] <RoAkSoAx> it caches it and updates it daily
[20:10] <cjwatson> that sounds like the correct fix, then
[20:10] <the-fallen> I'd like to build my own kernel from vanilla sources and create a deb-package from it. I am following several howtos (even if I did it many times) but after installing the kernel-image and the kernel-headers, the link "build" unter /lib/modules/.../ points to the original source dir, not to the headers
[20:10] <RoAkSoAx> and from that cache, I generate the ISO list
[20:11] <RoAkSoAx> cjwatson: indeed :)
[20:14] <the-fallen> or -at least- does someone know if the maverick kernels do have the cpufreq driver as module again?!
[20:15] <crimsun_> CONFIG_X86_ACPI_CPUFREQ=y
[20:15] <crimsun_> and CONFIG_X86_PCC_CPUFREQ=m
[20:15] <the-fallen> damn
[20:15] <the-fallen> thanks
[20:20] <RoAkSoAx> jcastro: Are yu using the latest release of TestDrive?
[20:23] <jcastro> RoAkSoAx: I'm using what's in lucid
[20:25] <RoAkSoAx> jcastro: use the one in ppa:testdrive/ppa. THat one has support for older ubuntu releases, which isos are in cdimage.ubuntu.com. Later on I'll add the support for ISO's that are on releases.ubuntu.com
[20:28] <jcastro> RoAkSoAx: oh I had no idea, thanks for the help!
[20:30] <RoAkSoAx> jcastro: np :)
[20:53] <vish> ScottK: :D  neat! "Could we leave the fanboi stuff off and just deal with the actual issues"
[21:23] <ScottK> Would a buildd admin please rescore kdebindings kdebase-workspace kdepimlibs (only affects powerpc and ia64)
[21:25] <cjwatson> ScottK: done
[21:26] <ScottK> cjwatson: Thanks.
[21:31] <ScottK> cjwatson: If you wouldn't mind, I accidentally left kdegraphics off my list.  Can haz too?
[21:31] <psusi> oh boy... I just found a bug in the kernel device mapper... addresses over the  2 tb mark get quietly wrapped back ground to zero
[21:41] <cjwatson> ScottK: done (on powerpc)
[21:41] <ScottK> cjwatson: Thanks.  That's the one I needed.
[22:05] <jono> are the X issues fixed now in Maverick?
[22:05] <jono> safe to upgrade?
[22:06] <arand> jono: I upgraded a whole slew of things today, and nothing broke too badly at least, this was on a kvm though.
[22:08] <jono> cool thanks arand
[22:13] <barry> is keyserver.ubuntu.com unhappy?  add-apt-repository for a ppa is timing out :(
[22:14] <didrocks> barry: same here
[22:15] <barry> didrocks: okay, at least it's not me :)  i'll see if there are any is folks around. since warsaw's 2nd law is in effect, it might just be time to call it a week :)
[22:17] <didrocks> right, same here, and getting late :)
[22:31] <barry> didrocks: seems to be back now, but it definitely s flakey
[22:32] <CynthiaG> Good evening
[22:32] <CynthiaG> cjwatson: A daily build of the LiveCD must have been done with bootchart included by now, correct?
[22:34] <CynthiaG> If so, I'll deconstruct it and reconstruct it using my ready-made mksquashfs ordering script + post results in bug 592485
[22:34] <CynthiaG> ... wrong bug
[22:34] <CynthiaG> bug 589629
[22:42] <andersk> A few packages in maverick are older than lucid (e.g. apt, brasero, language-pack-en), even though the lucid packages aren’t numbered like SRUs. What’s up with that?
[22:45] <slangasek> andersk: SRU numbering isn't mandatory; and when the package is intended to be forward-copied from -updates to the next dev release early in the cycle, sometimes devs don't use the SRU versioning
[23:14] <cjwatson> CynthiaG: yes, today's daily has it
[23:14] <CynthiaG> cjwatson: cool, I'll download it right now! :D
[23:14] <cjwatson> you can look in the .list and .manifest files to check
[23:15] <cjwatson> (sometimes it's in one or the other depending on details)
[23:16] <CynthiaG> >> maverick-desktop-i386.manifest:  bootchart 0.90.2-7
[23:18] <JanC> can somebody familiar with udev & hdparm please have a look at bug #568120 ? -- there is no init-script for hdparm anymore in lucid, and because of that some (documented!) parts of hdparm.conf aren't used anymore, causing all sorts of regressions for people... (and people are getting pointed to using packages from Debian and other recipes for possible future disaster)
[23:23] <slangasek> JanC: the "command_line" is a horrible misfeature which is deliberately omitted from the udev script, and it's not documented in the manpage.  What documentation points at this?
[23:25] <JanC> slangasek: it is (or was) at least documented in the default hdparm.conf
[23:26] <JanC> and lots of on-line docs about fixing hard disk related stuff uses it too
[23:27] <JanC> and it is actually documented in the manpage too
[23:27] <slangasek> no, it's not
[23:27] <slangasek> on-line docs> well, it's hard to stop the Internet from giving people bad advice
[23:27] <JanC> see the paragraph just below the options...
[23:28] <slangasek> it is still present in the default hdparm.conf, yes; that's something we can fix
[23:28] <JanC> it's in the manpage in Lucid
[23:28] <slangasek> JanC: oh, sorry - it wordwrapped, making it impervious to my search command
[23:28] <slangasek> right, there's a documentation gap here we should fix
[23:28] <CynthiaG> and there's a bug in 'man' too :)
[23:28] <JanC> and probably include a warning about it no longer working
[23:29] <CynthiaG> searches shouldn't be affected by wordwrap
[23:29] <JanC> it might be a cludge from the past, but people want their stuff to keep working, or at least know why it doesn't  ;)
[23:30] <cjwatson> CynthiaG: not much man itself can do about that
[23:31] <SpamapS> "Nobody ever upgrades. They just buy new computers when they want new features." -- Steve Jobs (paraphrased, from a lifetime of behavioral patterns)
[23:31] <cjwatson> it's the pager that handles most searches
[23:31] <CynthiaG> oh, didn't know that
[23:31] <CynthiaG> so basically it's 'less' handling the search?
[23:31] <cjwatson> yes
[23:32] <CynthiaG> bah :(
[23:36] <CynthiaG> anyway, sorry about interrupting the discussion about udev and hdparm
[23:38] <cjwatson> if anyone in the MIR team is still awake, I'd really appreciate a review of bug 582189