[00:13] <jbicha> !backports | mika
[00:13] <ubottu> mika: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[00:13] <ScottK> Yes, that's what I was about to say.
[01:34] <blahsphemer> Does the passwd executable change the ownership of any file? cuz it's capability list seems to list: CAP_CHOWN as one of the capabilities
[01:38] <infinity> It's entirely possible that it does so when it creates backups and copies things around.  Though why it doesn't create with the permissions it wants then, I don't know.
[01:38] <infinity> (I haven't checked, though, the CAP may be entirely unnecessary)
[01:39] <blahsphemer> infinity, no. THe cap is necessary. I tried removing the cap and change a passwd, it says Authentication token manipulation error
[01:39] <blahsphemer> How do I investigate this? As in how do I find out which file it's modifying?
[01:39] <infinity> strace it.
[01:39] <infinity> Or read the source.
[01:40] <infinity> But stracing is the simpler way to quickly find the opens/creates/renames/chowns.
[01:41] <blahsphemer> infinity, ok
[02:17] <blahsphemer> infinity, I unable to change passwords if I run passwd using strace. Would you know why?
[02:17] <blahsphemer> infinity, running from the terminal normally,  am able to change the password, though.
[02:22] <infinity> Are you doing it as root?
[02:22] <infinity> stracing suid binaries doesn't work so well.
[02:23] <blahsphemer> infinity, oh no. I completely forgot that part. I'll do it now.
[02:27] <blahsphemer> infinity, found it. It chowns /etc/nshadow. Thank you very much
=== Amaranth_ is now known as Amaranth
=== bregma_ is now known as bregma
=== Amaranth_ is now known as Amaranth
[07:55] <mika> ScottK: thanks (and also to jbicha who isn't here anymore :))
[09:12] <asac> hmm. weren't there bzr branches for ppa packages similar to UDD? whats the url scheme for those?
[09:15] <asac> james_w: i guess you know :) ?
=== tkamppeter_ is now known as tkamppeter
[10:26] <maxb> asac: I never heard of such a thing
[10:30] <asac> maxb: kk
[10:46] <Daviey> infinity: Sync's don't seem to provide karma.. so there is no risk of gaining too much :)
[10:48] <StevenK> Daviey: If there isn't a bug for syncs not providing karma, please file one.
[10:48] <Daviey> StevenK: that would imply we care about karma :)
[10:49] <StevenK> Well, we as in the LP team do.
[11:04] <erle-> when will there be a fglrx update? who is in charge?
[11:05] <erle-> maybe a update fixes it
[11:05] <erle-> repos have version 8.889, amd has version 8.892 released
[14:38] <infinity> StevenK: I want karma every time I perform queue manipulation.
[14:38] <infinity> StevenK: But more seriously, I want every queue change audited.
[19:34] <zub> Hi, what package is reponsible for the distro upgrade dialog - is it update-notifier?
[19:35] <hyperair> update-manager i should think.
[19:36] <zub> ah, ok
[19:36] <zub> http://linux.fjfi.cvut.cz/~zub/Screenshot-Ubuntu%2011.10%20Upgrade%20Available.png
[19:36] <zub> seems it ignores http proxy, so I'm looking if there's a bug reported for this already
[19:38] <hyperair> try setting it in /etc/apt/apt.conf.d/
[19:38] <zub> it is set, come on
[19:38] <zub> aptitude works ok
[19:38] <hyperair> ah
[19:38]  * hyperair shrugs
[19:38] <zub> and it's set in http_proxy, and even in the gnome thing, whatever that does
[19:38] <zub> hyperair: sorry :)
[19:40] <zub> in that window, it's trying to fetch a web page with some info about the upgrade - I think... so it shouldn't be using apt's proxy, but http_proxy or whatever else the gnom proxy setting changes
[19:40] <zub> but anyway as far as I know, all that's needed was set at that box, web works, apt works
[19:47] <slangasek> zub: please file a bug against update-manager, yes
[19:47] <penguin_03> has this patch "DM-CRYPT: Scale to multiple CPUs v3" http://lkml.org/lkml/2010/10/10/44 been applied to any versions of Ubuntu?
[19:47] <zub> slangasek: ok, thanks for info
[19:48] <zub> I'm also filing/commenting on some unity bugs
[19:48] <zub> I've been using it for 1 day and found several issues I believe to be bugs :-(
[19:49] <slangasek> penguin_03: there's no reason we would have picked such a patch unless it's included in the upstream kernel we're shipping
[19:49] <penguin_03> do the newer kernels have any parallel dm-crypt support?
[19:50] <slangasek> no idea
[19:56] <dajhorn> penguin_03: That patch is in the Oneiric kernel.
[19:56] <penguin_03> dajhorn, thanks
[19:57] <dajhorn> penguin_03: Welcome.
=== yofel_ is now known as yofel
[20:01] <SpamapS> slangasek: https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/876959 ... he's right that the dbgsym packages for the version of mysql 5.1 in lucid-updates aren't on ddebs.ubuntu.com. Any ideas?
[20:01] <ubottu> Launchpad bug 876959 in mysql-dfsg-5.1 (Ubuntu) "no mysql-server-5.1-dbgsym for security/updates repositorires" [Undecided,New]
[20:01] <SpamapS> though they are available for the highest version in lucid-security
[20:01] <slangasek> SpamapS: ICMP redirect pitti
[20:02] <slangasek> in general the ddeb archive is a mess because there's no LP-driven reference counting; but I'm never clear on what bugs are present at any given time
[20:02] <SpamapS> pitti: https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/876959 ... he's right that the dbgsym packages for the version of mysql 5.1 in lucid-updates aren't on ddbes.ubuntu.com. Any ideas?
[20:02] <ubottu> Launchpad bug 876959 in mysql-dfsg-5.1 (Ubuntu) "no mysql-server-5.1-dbgsym for security/updates repositorires" [Undecided,New]
[20:02] <SpamapS> slangasek: I've had mostly failure when trying to make use of it. :-/
[20:03] <SpamapS> partial success... but almost always some piece missing
[20:03] <SpamapS> slangasek: so there's no LP project that is specific to the dbgsym repo?
[20:03] <SpamapS> was going to redirect the bug to that
[20:04] <slangasek> ah, I don't know; my point was about soyuz not knowing about ddebs
[20:04] <SpamapS> oh right
[20:11] <SpamapS> slangasek: so, the PHP upstreams want us to include PHP 5.4 in 12.04
[20:11] <SpamapS> slangasek: maybe I'll make the condition that their build process stops smoking crack for 3 months before we do that. ;)
[20:11] <slangasek> heh
[20:12] <slangasek> good luck, it's a lifelong addict
[20:14] <SpamapS> Like taking the weed from snoop
[20:14] <SpamapS> it wouldn't be PHP if it didn't have the rock
[20:35] <luist_> can anyone point me a simple .dsc to build a deb package?
[20:39] <cjwatson> .dsc files are generated by the dpkg-dev toolchain from a source tree; you won't get anywhere at all trying to write a .dsc by hand
[20:41] <marw> i'd like to assist in development of a project/application, and i know only python. any advice on where to start?
[20:44] <luist_> oh god…. i have a folder with 1 executable and 1 .desktop file. i compressed them in a tar.gz. how do i make a deb package out of it… that should be so simple but all the freaking guides i find shows the tons of useless stuff that i dont need…!
[20:45] <cjwatson> dh_make should get you most of the way there; or I'm sure if you put the .tar.gz somewhere public then somebody could give you the files you need under debian/
[20:46] <cjwatson> (I would, but need to deal with children's bedtime ...)
[20:46] <marw> luist_: there is a good video tutorial by a german guy about deb files for py projects
[20:46] <luist_> marw: link?
[20:46] <SpamapS> luist_: dh_make will indeed build you a pretty good debian/ dir
[20:46] <marw> luist_: you're in luck, i saved it. http://showmedo.com/videotutorials/video?name=linuxJensMakingDeb
[20:46] <cjwatson> python packaging can actually be a fairly complex case and is more than you need if it's just a single executable
[20:47] <cjwatson> (because of all the complexities around supporting multiple python versions)
=== Quintasan_ is now known as Quintasan
[20:47] <maxb> And the infelicitous profileration of methods of doing so
[20:47] <maxb> *proliferation
[20:48] <cjwatson> yes, though that's getting better
[20:48] <SpamapS> luist_: you probably jus need to run that, and then list the files you want installed in debian/install  like   executable_file /usr/bin      then  exec.desktop /usr/share/applications
[20:48] <cjwatson> (it did involve the creation of a third method, but the previous two are now deprecated and their use is dropping)
[20:48] <maxb> Sadly, despite my best efforts, I have yet to eliminate Debian etch at work, so I'm doomed to live with the variety for a while longer :-)
[20:48] <cjwatson> yep, what SpamapS said
[20:49] <cjwatson> *etch*?
[20:49] <luist_> SpamapS: ok nice! but what am i doing wrong here: http://pastie.org/2742190  the dir names seems to be right
[20:49] <maxb> I know, I know
[20:49]  * cjwatson passes maxb an archaeologist's hat
[20:49] <cjwatson> cd hinfo-0.1; dh_make
[20:49] <SpamapS> indeed
[20:49] <luist_> oh
[20:50] <cjwatson> (actually you may need to 'mv hinfo-0.1.tar.gz hinfo_0.1.orig.tar.gz' first)
[20:50]  * SpamapS recalls similar happy days learning to package his first real C application.. pipemeter.. some 10 years ago :)
[20:51] <maxb> The one thing to bear in mind about dh_make is that it writes an informative *template* - it might just work even if you don't customize what it emits at all, but I'd strongly recommend deleting all the bits you don't need and ensuring you understand everything you keep
[20:51] <luist_> SpamapS: ook! whats exactly is this debian/install
[20:51] <cjwatson> 'man dh_install' will tell you
[20:51] <luist_> cjwatson: ok :P
[20:52] <maxb> many of the debian/<something> files are declarative instructions for the dh_<something> program
[20:52] <cjwatson> but briefly, it's just a declarative way of installing specific files to specific locations, especially useful if your project doesn't already have 'make install' or similar
[20:52] <SpamapS> if you have a Makefile that understand 'make', and DESTDIR=foo 'make install' ..  it generally works IIRC
[20:52] <SpamapS> maxb: they're all .ex so they just sit there
[20:53] <SpamapS> cruft, but thats ok, he's not trying to get included in the distro ;)
[20:53] <maxb> SpamapS: Agreed, they don't harm the functionality of building the package, but they do obfuscate the new packager's understanding if they don't take the time to delete as appropriate
[20:54] <SpamapS> thats one reason we started pkgme ... trying to be smarter about building a real package, not just a templated one
[20:54]  * SpamapS sorely wishes he could raise contributing to pkgme on his priority list
[20:54] <luist_> i just tried this: /work/HardwareInfo/hinfo-0.1$ dh_make -f ./hinfo-0.1.tar.gz  and i have no idea what happened rofl
[20:54] <cjwatson> just dh_make, you shouldn't need options
[20:55] <luist_> cjwatson: well its not like i see any difference here :T
[20:55] <luist_> cjwatson: is there any default folder where packages should be built, like with rpms?
[20:55] <cjwatson> no, that's rpm brain-damage :)
[20:55] <luist_> cjwatson: yep :(
[20:55] <cjwatson> anywhere under your home directory is just fine
[20:56] <luist_> cjwatson: well /work/... doesnt seem like my home dir right ;)
[20:56] <cjwatson> or anywhere you can write to
[20:56] <luist_> ok
[20:56] <cjwatson> as I say, if you're in a rush, it's fine to put the tar.gz somewhere and it would probably take an experienced packager five minutes.  it depends whether your goal is to make a package, or to learn how to do it
[20:57] <luist_> cjwatson: today: make a package   next week: learn how to do it to provide an update :T
[20:57]  * cjwatson nods
[20:57] <luist_> yes it would take less than 5 minutes for me to make an rpm… but im not really in the mood of working on a weekend -.-
[20:57] <cjwatson> (note, then, that dh_make is one way to create the initial files, but you don't use it to update to new versions, and if you try you'll get confused)
[20:58] <luist_> cjwatson: well as long as it have a version, i can update right?
[20:58] <cjwatson> the basic idea of rpm and debian packaging is much the same; install files into a temporary directory, then bundle it up into a package with some metadata attached
[20:58] <cjwatson> debian packaging is split out into several files rather than using a single .spec file, that's all really
[20:59] <cjwatson> (and sure, lots of tools and so on, but at the basic level ...)
[21:00] <luist_> well what exaclty should i do after running dh_make… plus i dont now what im doing until now: prepare Debian packaging for an original source archive sounds a bit abstract for me
[21:00] <cjwatson> the bare minimum for a Debian package is (a) debian/rules (which can be a copy of /usr/share/doc/debhelper/examples/rules.tiny) (b) debian/control with some metadata about your package (c) debian/changelog with version history in a specified format (d) if you want it to be accepted into a public repository anywhere, debian/copyright
[21:00] <cjwatson> there are usually a few other files as well but that's the guts
[21:01] <luist_> cjwatson: do i create these inside my folder?
[21:01] <cjwatson> then 'debuild' builds source + binary packages
[21:01] <cjwatson> yes
[21:01] <cjwatson> dh_make should have done that for you
[21:01] <luist_> cjwatson: no it didnt
[21:01] <cjwatson> did it produce any output at all?
[21:01] <luist_> cjwatson: but now a lot of things make sense.. that would replace the .spec right
[21:01] <cjwatson> indeed
[21:01] <luist_> cjwatson: nop it didnt
[21:02] <cjwatson> blink
[21:02] <luist_> cjwatson: what about hinfo_0.1.orig.tar.gz ?
[21:02] <luist_> cjwatson: my bad it gave me output
[21:02] <maxb> luist_: Do you use Bazaar? If so, check out the trivial example package https://code.launchpad.net/~maxb/+junk/example-package
[21:03] <cjwatson> um, introducing more tools may not be the correct response to a confused person :)
[21:03] <cjwatson> but you can just look at it on the web
[21:03] <maxb> or just browse it, there are only 6 files
[21:04] <cjwatson> yep, that's a good place to start
[21:04] <maxb> In fact, go here: http://bazaar.launchpad.net/~maxb/+junk/example-package/revision/1 then click "expand all"
[21:05] <cjwatson> luist_: pastebin the output?
[21:06] <luist_> cjwatson: oh i just used --createorig and it worked now
[21:06] <luist_> cjwatson: :)
[21:06] <cjwatson> I'd have renamed hinfo-0.1.tar.gz to hinfo_0.1.orig.tar.gz, but whatever works
[21:09] <luist_> cjwatson: http://pastie.org/2742277
[21:09] <luist_> cjwatson: theres no debian/install :T
[21:11] <cjwatson> that's ok, create it
[21:11] <luist_> cjwatson: did with the line: HardwareInfo    /usr/bin
[21:12] <luist_> cjwatson: or it should be just usr/bin ?
[21:13] <maxb> I have a feeling either might work, but usr/bin definitely will
[21:15] <cjwatson> either will work
[21:16] <luist_> cjwatson: ok also added: hinfo.desktop     etc/xdg/autostart
[21:16] <luist_> cjwatson: now what :)
[21:17] <cjwatson> run 'debuild', and if it gives you any errors then fix them up.  repeat.
[21:17] <cjwatson> (until successful.)
[21:17] <cjwatson> if it completes successfully, run 'debc' to show what the resulting package looks like.
[21:24] <luist_> cjwatson: oh god: http://pastie.org/2742328
[21:25] <cjwatson> you'll need to edit debian/changelog then.  it should be self-explanatory; if it isn't, paste it
[21:25] <luist_> cjwatson: wasnt it generated by dh_make rofl
[21:25] <cjwatson> where it apparently says " -- root", it should be something like (example from one of my packages):
[21:25] <cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Wed, 19 Oct 2011 22:53:40 +0100
[21:26] <cjwatson> please don't use "rofl" as punctuation, it sets my teeth on edge :)
[21:26] <cjwatson> it can't autodetect everything - it generates a template for you to edit, hopefully fairly close to usable but it probably does need a few edits to work
[21:27] <cjwatson> (it's a long time since I actually used dh_make myself, sorry, I've been in this game long enough that I just do it by hand)
[21:29] <luist_> cjwatson: ok :) btw this is not self-explanatory at all… the line thats giving me the warning has the same syntax from the example u gave me: -- Max Bowsher <_@maxb.eu>  Sat, 22 Oct 2011 21:58:42 +0100
[21:30] <cjwatson> the error output you pasted disagrees; it says that the line reads " -- root"
[21:30] <maxb> The format is quite strict, including the number of spaces in each place, and the date format
[21:31] <maxb> There is a tool, called "dch" for adding new changelog entries, such that you never need to type those lines manually
[21:31] <cjwatson> I'm surprised dh_make gets it wrong by default though :-(
[21:31] <luist_> cjwatson: well i changed to   -- SEE-MG <_@anything.com> Sat, 22 Oct 2011 19:27:23 +0100
[21:32] <luist_> cjwatson: but same error
[21:32] <maxb> The *two* spaces between the email and the date are mandatory
[21:32] <luist_> maxb: oh
[21:32] <cjwatson> oh meep, bug 875705
[21:32] <ubottu> Launchpad bug 875705 in dh-make (Ubuntu) "dh_make in Oneiric outpus wrong content to changelog" [High,Confirmed] https://launchpad.net/bugs/875705
[21:32] <cjwatson> sigh
[21:33] <maxb> outpus!  irta octopus initially :-)
[21:35] <luist_> errr… hinfo-0.1/debian/control at line 5: line with unknown format (not field-colon-value)   http://pastie.org/2742358
[21:35] <Laney> hah
[21:35] <cjwatson> yeah, same bug
[21:35] <cjwatson> 'export DEBFULLNAME="Your Full Name"; export DEBEMAIL=your@email.address'
[21:35] <cjwatson> rm -rf debian  and start again
[21:36] <cjwatson> sorry - I'll look into getting this fixed reasonably urgently
[21:36] <luist_> o.O
[21:37] <cjwatson> looks like it's because LOGNAME isn't set, perhaps a desktop-level change?
[21:38] <cjwatson> I bet this is actually a lightdm bug
[21:39] <luist_> cjwatson: ok.. going to install these now: Could not find a signing program (pgp or gpg)!
[21:39] <luist_> cjwatson: i can feel im almost there
[21:39] <cjwatson> you can ignore that
[21:40] <luist_> cjwatson: really?
[21:40] <luist_> http://pastie.org/2742381
[21:41] <cjwatson> it won't have cryptographically-signed the package but it will have generated one, if it got that far
[21:41] <cjwatson> you can use 'debuild -uc -us' to stop it trying
[21:43] <luist_> ok good
[21:43] <luist_> cjwatson: oh god i have a deb package!!
[21:46] <luist_> cjwatson: thanks a lot :)
[21:46] <cjwatson> excellent, sorry about that roadblock
[21:47] <cjwatson> I think I have a fix, just will need to test it a bit and do the paperwork for a stable update
[21:47] <luist_> cjwatson: its ok… ive learnt a lot here
[21:47] <cjwatson> (http://paste.ubuntu.com/716397/)
[21:54] <cjwatson> fix uploaded to precise, doing the writeup for oneiric-proposed now
[21:54] <Laney> hm, I use lightdm yet have $LOGNAME set
[21:54] <cjwatson> something in your shell startup scripts?
[21:54] <Laney> not knowingly
[21:54] <cjwatson> or even your shell
[21:54] <Laney> gnome-panel/xmonad instead of unity
[21:54] <maxb> lightdm/unity here ... and no $LOGNAME
[21:54] <cjwatson> the bug seemed fairly clear when I looked at the lightdm source
[21:55] <Laney> yeah, I checked on another unity laptop and it didn't have it
[21:55] <Laney> zsh must set it
[21:55] <cjwatson> it does
[21:56] <cjwatson> ./Src/params.c:703:    setsparam("LOGNAME", ztrdup((str = getlogin()) && *str ? str : cached_username));
[21:57] <Laney> luverly
[22:02] <foresto> Hi, all.  I'm packaging a driver module that was removed from ubuntu ages ago. Someone forgot to remove the man page from the ubuntu 'manpages' package when the driver was removed from ubuntu, so my new package (which contains an updated man page) now clashes with 'manpages', and dpkg won't install it. What is the best way to avoid the conflict?
[22:06] <cjwatson> you could give the man page a slightly different name; perhaps append a short string to the section number
[22:07] <cjwatson> (called a "section extension" - see e.g. the "3pm" pages documenting perl modules)
[22:07] <cjwatson> luist_: OK, I've uploaded a dh-make fix to oneiric-proposed as well now (waiting for review) and forwarded the patch to Debian
[22:08] <foresto> I'm considering that. Is there an officially blessed (by debian/ubuntu) way to handle this?
[22:08] <cjwatson> luist_: so the next person shouldn't have the same problem, hopefully
[22:08] <cjwatson> foresto: not that I know of, but I maintain man-db so I guess my advice is about the best approximation to that you'll get ;-)
[22:09] <foresto> Thanks, cjwatson.  I've filed a bug on the dangling man page, too.
[22:10] <cjwatson> right, and if that gets fixed then you could rename the page in your package and add Breaks/Replaces on manpages; but until then (and for <= oneiric) I'd definitely advise working around the file conflict
[22:10] <cjwatson> are the pages basically the same between manpages and your package?  is there a problem with people getting the manpages version if they have that installed?
[22:10] <cjwatson> oh, you said updated, hmm
[22:10] <cjwatson> there probably isn't an ideal short-term solution
[22:11] <luist_> cjwatson: :)
[22:11] <cjwatson> I suppose you could dpkg-divert away manpages' version, but that feels rather heavy-handed to me
[22:12] <foresto> Yeah, it's the sk98lin driver, and the one in manpages is ancient. Options have changed since then.
[22:15] <maxb> ooi, what would be the downsides to having the new package declare a Replaces: manpages ?
[22:16] <maxb> Or, would that all go horribly wrong the first time manpages was updated after the custom package was installed?
[22:28] <cjwatson> maxb: I think we did make that work in dpkg a while back (dapper, maybe)
[22:28] <cjwatson> maxb: but even so, I kind of take the attitude that anything I have to look up in dpkg source to conclusively determine its behaviour may not be a good idea :-)
[22:28] <cjwatson> I think it's best to avoid file conflicts wherever possible
[22:30] <DoctorPepper> hi guys !!!
[22:31] <foresto> I did see the note in the debian policy about using Replaces: when a package takes over a file from another package, but it looked to me like it was intended for use when a new package takes over the duties of an old one. That's not really what's going on here.
[22:32] <DoctorPepper> agateau:  are you here ?
[22:36] <cjwatson> foresto: it is used for single files moving between packages too.  I prefer to only use it consensually though (i.e. when the file is actually moved, not just to slam something over the top of an existing package that still ships the file).
[22:36] <cjwatson> the definition of Replaces is a little confusing as it does double duty depending on whether the packages also Conflict or not.
[22:36] <foresto> Yes, that usage was hinted as well. Thanks for making sure I didn't miss it.
[23:13] <foresto> Okay, so I have the man page in a subsection now (4opt), but of course, it doesn't show up unless the user runs "man -a sk98lin" or "man 4opt sk98lin". Anyone know if there's a subsection that would override section 4 as the default?
[23:13] <foresto> An appropriate subsection, that is.
[23:16] <foresto> and thanks, cjwatson.
[23:17] <penguin42> the order seems to be set by /etc/manpath.config
[23:22] <foresto> Thanks, penguiin42.  Hm... None of the sections preceding 4 really apply, but since it's just a temporary workaround until the ubuntu manpages bug is fixed, maybe I could put the new man page in section 8.
[23:23] <foresto> (It is a network module after all, and there are plenty of network-admin-related things in section 8.)
[23:40] <slangasek> foresto: section 8 is "system management commands"; a network module doesn't sound like it belongs.
[23:40] <slangasek> (cf. man-pages(7))
[23:42] <foresto> slangasek: Yes, note my comment two lines up:  None of the sections preceding 4 really apply.
[23:44] <foresto> IMHO, it's more important to avoid giving the user bad instructions on the use of his kernel driver than it is to adhere perfectly to the section categories, and since this is only a temporary workaround and only necessary due to a bug in the stock manpages, I think abusing section 8 a little is warranted.
[23:46] <foresto> In other words, I'd rather annoy someone for bending the man section rules than really screw someone by leading them to render their system unbootable.
[23:46] <infinity> foresto: Why not just fix the manpage shipped in manpages?
[23:46] <slangasek> foresto: well, if you're just putting it in a section where it doesn't belong as a workaround, rationalizing which section is less bad than the others to abuse is unnecessary :)
[23:47] <slangasek> to someone who cares about the sections, it'll be in the wrong section; to someone who doesn't, any section will do
[23:48] <foresto> slangasek: heh... point taken. I'm just trying to do this as well as I can.  :)
[23:49] <foresto> infinity: The bug is already filed. I don't have the power to alter the official manpages package, and I don't think anyone has the power to retroactively do it on packages that have already "shipped".
[23:49] <infinity> Well, we can push updates, if it matters deeply.
[23:50] <infinity> But you could just dpkg-divert the manpages' copy out of the way too.
[23:50] <foresto> Your suggestion would make sense if my package was not going to be released until manpages is fixed. I'm releasing in a PPA though. Today.
[23:50] <foresto> We talked about dpkg-divert a couple hours ago. cjwatson didn't like the idea.
[23:51] <infinity> He just said "that feels heavy-handed".
[23:51] <foresto> Yea.
[23:51] <infinity> It's still more correct than throwing the manpage in the wrong section to force it to have priority. :)
[23:51] <infinity> I'm pretty sure he didn't suggest that either. :P
[23:52] <foresto> Actually, he suggested using a subsection.
[23:52] <infinity> Right.
[23:52] <foresto> A subsection  to the existing section doesn't solve the problem.
[23:52] <infinity> But then you disliked that because it won't sort the way you want.
[23:52] <foresto> No.
[23:53] <foresto> Because it leaves the average user with bad instructions on configuring rather delicate part of his system.
[23:55] <infinity> It's a NIC driver, not a nuclear reactor.
[23:55] <infinity> But yeah, having the right info is nice.
[23:55] <infinity> dpkg-divert still sounds like the right solution to me for a third-party package that wants to overwrite files without overwriting.
[23:55] <infinity> Which is, in the end, what you're after.
[23:56] <foresto> It's very possibly the user's only convenient connection to the net, which means a misconfiguration would leave him unable to easily find out how to fix it.
[23:56] <foresto> To be fair, I do see your point.
[23:57] <foresto> dpkg-divert seems heavy-handed to me too, but I'll consider it.
[23:58] <infinity> Well, it's the "right" solution to the problem.
[23:58] <infinity> Having manpages in the wrong section thwarts people like me who read by section intentionally.
[23:59] <foresto> No wonder you're pushing so hard for it. :)
[23:59] <infinity> For instance, I'm used to typing "man 2 open", and if I ever read manpages for kernel modules, I'd probably instictively read "man 4 sk98lin".
[23:59] <infinity> So, I'd still get the wrong info if you shove it in section 8.