Re: PGP pack.
Massimo Lusetti <[EMAIL PROTECTED]> writes: ML> I wish only know if out there's a .deb for PGP 2.6.3i ... tnx Read ftp://ftp.debian.org/debian/README.pgp. -- _ / \ "The cat's been in the box for over | David Maze | 20 years. Nobody's feeding it. The | [EMAIL PROTECTED] |cat is dead." | http://donut.mit.edu/dmaze/ | -- Grant, on Schroedinger's Cat \_/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
/debian/project/experimental in dftp
Is there any way to get directories that don't have the normal architecture structure, i.e. project/experimental, to show up in dselect using the ftp backend? (I at least want the Packages file to get loaded when I press [U]pdate...) -- _ / \ "The cat's been in the box for over | David Maze | 20 years. Nobody's feeding it. The | [EMAIL PROTECTED] |cat is dead." | http://donut.mit.edu/dmaze/ | -- Grant, on Schroedinger's Cat \_/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
Steve Dunham <[EMAIL PROTECTED]> writes: SD> Hamish Moffatt <[EMAIL PROTECTED]> writes: HM> On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: LA> The kernel-source-2.0.32 deb has a 130K diff file against the LA> standard source. Just where do these patches come from and why LA> are they necessary? Is the fact that I _have_ to have 2.0.32 LA> source or headers going to stop me from going to 2.0.33? HM> HM> I don't know why all those patches are already applied. I have HM> stopped using the kernel-source packages because they can't be HM> patched up to the next kernel version easily (because of the HM> already applied patches). You should be able to install HM> kernel-headers to satisfy it and then dump the standard Linux HM> source tree in for building kernels. SD> SD> Does anyone know why there is a dependency on kernel-headers? I SD> was under the impression that glibc didn't use the kernel headers. ...or why it depends on kernel-headers-2.0.32 instead of just kernel-headers, which is provided by the kernel-source-* and kernel-headers-* packages? -- _ / \ "The cat's been in the box for over | David Maze | 20 years. Nobody's feeding it. The | [EMAIL PROTECTED] |cat is dead." | http://donut.mit.edu/dmaze/ | -- Grant, on Schroedinger's Cat \_/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: An Idea/RFP: x group /
Andreas Rottmann <[EMAIL PROTECTED]> writes: AR> Wht about a package that contains the following commands (yet to be AR> written): AR> AR> xuseradd # Add's the user to the x group AR> xuserdel # Deletes the user from the x group AR> AR> The package would have an config file where it lists all users that AR> are allowed to use x (there must be an user that x runs under, I think AR> best called x ;-)). The x startup script would then call xhost AR> +@localhost for all of these users, and the above commands would AR> use xhost (if X is running) to update the status immediatly. Does user-based xhost authentication work? At all? AR> Since xhost supports NIS, it would be good to accept "users" like this AR> nis:[EMAIL PROTECTED] and, for network use [EMAIL PROTECTED] (one could simply pass AR> names that contain '@' without appending '@localhost'). My impression is that anything involving NIS is horribly insecure. Is there any encryption/authentication in the X protocol? AFAIK, the Kerberos-based authentication is horribly broken and won't work with any version of Kerberos 5 released within the past 5 years. Nothing else is secure at all over the network. (Hence, the popularity of X tunnelling over ssh.) BTW, why would you *want* to do this? You're basically creating a class of local and/or remote users who can spy on/take over arbitrary users' X sessions. I'd be pretty scared if I was using a system and another user's X windows started popping up on top of mine. Other things to think about if you're really set on doing this: what keeps the logged-in user from running 'xhost [EMAIL PROTECTED]'? What keeps someone on the acl from running 'xhost -:0.0'? What if there are multiple X servers running on the machine? -- David Maze [EMAIL PROTECTED] http://www.mit.edu/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#194938: ITP: drivel -- A LiveJournal client for the GNOME desktop
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le mar 27/05/2003 à 20:42, Neil McGovern a écrit : >> Description : A LiveJournal client for the GNOME desktop >> >> Drivel is a LiveJournal.com client for the GNOME desktop. >> >> It supports all livejournal-based servers, and allows you to perform >> most functions that are supported by the server (posting, friends editing, >> friend groups, friend page checking, post editing etc). > > Reading this description, I have absolutely no idea abut whet this > software is about. Could you please rewrite it by explaining what is a > "livejournal.com client" ? http://www.livejournal.com/ is a quasi-free-as-in-beer online journaling service that seems to be fairly popular. There are a couple of other services that use the same code base, and a couple other livejournal clients already in Debian (I tend to use logjam, for example, which has a somewhat similar package description). I think the service is popular enough that you don't need to explain what it is, in the same way that you don't need to explain what an SNMP daemon is to have and snmpd package. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Kernel build dependencies for prepackaged modules
My kernel module packages (lm-sensors and i2c) both build-depend on kernel-build-2.4.20-1, which provides enough bits to build packages (as far as I can tell, successfully). Problem is, evidence suggests that kernel-build-2.4.20-1 is i386-only. I'm looking at moving to 2.4.21, but kernel-build-2.4.21-1 also appears to just be an i386 thing. It looked like kernel-tree-2.4.21 might be useful for this, but it doesn't obviously appear to depend on architecture-specific patches and doesn't give any clue as to what flavors exist and has *no documentation at all*. Is there actually something I can build-depend on that will get me correct headers for the kernels on whatever platform I'm building on? -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Kernel build dependencies for prepackaged modules
Herbert Xu <[EMAIL PROTECTED]> writes: > How many Debian users are there that will use lm-sensors and i2c > modules for a prepackaged kernel on a non-i386 architecture? I've had at least one user ask me about support for powerpc, which is the big thing that's driving me to ask. If it makes you happier, pretend I'm asking about something hardware-independent like openafs. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Future releases of Debian
"Jamin W. Collins" <[EMAIL PROTECTED]> writes: > On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: >> me too! any package that doesn't build on m68k or arm is broken and >> needs to be fixed, even if it works on x86 by chance! > > So, are you volunteering to help those of us without access to either of > the above architectures with "bugs" found in our packages? But Debian has ~public machines for pretty much every architecture. I'd say "look on http://db.debian.org/machines.cgi";, except that's down; I can at least point you at section 4.4 of the Developer's Reference, though that doesn't say a whole lot beyond this. I admit that this doesn't necessarily help for testing installers, but for your own packages it should be straightforward for you to do testing and bugfixing even on architectures you don't personally own a machine for. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
Cajus Pollmeier <[EMAIL PROTECTED]> writes:
> On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote:
>> Severity: serious
>> Justification: Policy 9.1.1
("Debian should obey the FHS"; I don't claim to be an FHS expert, but
all it seems to say about /etc is "no binaries", which this doesn't
violate.)
>> The shell script /etc/acpi/powerbtn.sh should be installed in something
>> else, like /usr/share/acpid/ or /usr/sbin/.
> I've no problem with that, but:
>
> These scripts used by acpid should be treated as some kind of user
> configuration, like i.e. cron keeps skripts installed by someone in
> /etc/cron.daily, acpid keeps skripts that take actions when some
> events happened.
Is this "script that gets run when the console user presses the power
button", and is it obvious that the user could potentially want to
configure it? If so, then it makes sense that it should be a
configuration file, and so by policy 10.7.2 it should live in /etc.
(And as you point out, it's not like there aren't other admin-editable
scripts in /etc already, say, all of /etc/init.d.) My reading is that
what you're doing now is fine and the bug is wrong.
--
David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Re: libraries being removed from the archive
Chris Cheney <[EMAIL PROTECTED]> writes: > IMHO we need to make an addition to policy stating that an old lib can > not be removed from the archive until no other packages still depend on > it. So say I maintain foo. The source package produces two binary packages, foo and libfoo1. Now, there's a new foo release, that changes libfoo's soname. In the current scheme, I package the new upstream release and upload foo and libfoo2; since there's no source package for libfoo1, it eventually gets removed from unstable. Are you proposing that (a) the ftpmasters not remove libfoo1, or (b) that package maintainers of library packages are now compelled to package the last version of foo's source providing libfoo1 separately, potentially for multiple release cycles for a widely used library? Option (b) sounds problematic to me... -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: How to install X-Chat in five hours (or more)
Frederik Rousseau <[EMAIL PROTECTED]> writes:
>> I really think aptitude should only show end user packages with
>> decent, readable, localised names ("Apache Web Server", "x Chat (IRC
>> Client)", "Infrared Control for XMMS"). At the moment the user is
>> completely overwhelmed by the list of packages, which is not helped by
>> the fact that each one comes with a dozen or more libraries,
>> extensions, and so forth.
>
> Some people like Ian Hickson don't want to see package names like libgtk2.0.
> But _I_ want to see this, I am sys admin and want to know exactly what I am
> putting on _my_ systems.
>
> Just one of the reasons why I like GNU/Linux ... I know what I'm doing!
>
> Anyway, does this mean we need something like a GNU/Linux Debian and a
> GNU/Linux Debian For Dummies showing only icons?
It probably means there should be a configuration option in aptitude
to hide sections like devel, libdevel, libs, and interpreters, since
end users typically don't care (and 90% of the time I find myself not
caring, too). Perhaps suggesting to new users that they look in the
"tasks" section of aptitude would help reduce the package overload,
too. I don't think we need to abandon the power of our current
infrastructure, just have ways of making it less visible for people
who don't want it.
--
David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Re: Building kernel modules for stock kernels is a hell of a job!
Manuel Bilderbeek <[EMAIL PROTECTED]> writes: > After having worked with Debian testing for about 2 years, I'm getting > fed up with the seemingly unnecessarily complicated way of building > kernel modules for the stock kernels. > 1) install the kernel source for the kernel, >e.g. kernel-source-2.4.21 Since you're singling out lm-sensors here, I can tell you that lm-sensors-source does build fine against the correct kernel-headers package; the "normal" binary package build-depends on a kernel-build package to get all of the kernel-headers, and uses those without any particular magic. > 5) apt-get install [modulename-source] (sometimes -src), > e.g. lm-sensors-source. > > 6) this should give [modulename].tar.gz in /usr/src; extract it: tar > xzvf [modulename].tar.gz > now, the source is in /usr/src/modules/[modulename] At this point, I think what I would tell you to do is (untested): cd $MODULE_LOC/$modulename debian/rules kdist-image KDREV=2.4.21-4 KVERS=2.4.21-4-k7 \ KSRC=/usr/src/kernel-headers-2.4.21-4-k7 \ KMAINT="Your Name" KEMAIL="[EMAIL PROTECTED]" \ APPEND_TO_VERSION=-4-k7 ROOT_CMD=fakeroot which will produce the binary package you're looking for in /usr/src. This is just using the interface required by kernel-package. > 9) install the just built package(s) with dpkg -i [package_name] > now the kernel modules should be in the right dir in /lib/modules and > modprobe (or modconf) can find them. > - If you have just installed a new kernel-image package (i.e. a new > stock kernel), you need to do everything from the start *after* > booting this new kernel You shouldn't need to. (Though you go through a little more effort to get the right .config file.) > - In my experience, if you forget the export of step 7, you have to > wipe your whole kernel source tree and start at step 2. I know I'm > supposed to do a make-kpgk modules clean, but that didn't do the > trick; 'rm -rf /usr/src/modules' is often quite theraputic for odd problems like this. Screwing up --append-to-version using kernel-package has kind of unfortunate side effects for recovering. :-/ > People, stock kernels are very comfortable, but building modules for > them is not! Please tell me what I did wrong, or make the procedure a > lot easier! (The latter especially applies to the maintainers of that > NVIDIA package...) > > Luckily, David Z. Maze has the lm-sensors as binary package in > unstable nowadays... :) (Although not yet for 2.4.21...) In some ways, doing this feels a lot like a very slow game of Whack-A-Mole. The process goes something like this: (1) Notice that Debian kernel 2.4.21-1 exists. (2) Install kernel-build-2.4.21-1. Change debian/rules to reference the right kernel. (3) Actually rebuild the package. This winds up taking quite a long time for me, particularly since there are seven different kernel flavors and I'm foolishly doing the build over AFS over a cable modem. (Should probably fix that. :-) (4) Upload. (5) Wait for ftpmaster, since these are all new packages. (6) Notice that Debian kernel 2.4.21-2 exists. (7) ftpmaster accepts lm-sensors-2.4.21-1-*, which depend on kernel-image-2.4.21-1-*, which is no longer in the repository. (8) Go to 2. It's also a bit frustrating to look at cross-platform compatability, and realize that the magic to get things built is just going to be different on each platform, since the platform-specific kernel packages are all different. Plus getting stock kernel modules built is presently entirely in the hands of the module maintainers, and the glue code in debian/rules to actually do that is kind of groady. I suspect for unstable, there's just not a lot to be done. For sarge, we should probably pick a kernel and a kernel ABI (or sets thereof) and not change it, so that packages that provide prebuilt kernel modules can do that more reasonably. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
Herbert Xu <[EMAIL PROTECTED]> writes:
> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>>
>> So, I'm curious why you chose to make it a part of the Debian
>> kernel source, rather than a separate patch (kernel-patch-ipsec or
>> such).
>
> Well the reason for it to be in the default kernel-source is simple:
>
> The patch should be used on all default Debian kernel images unless
> the arch maintainer chooses to override it.
That doesn't sound like it really answers the question...
>> I suppose the more fundamental question is, what is your vision for the
>> Debian kernel source? What do you feel belongs there, and what does not?
>
> Perhaps vision is too strong a word.
>
> I have some simple checks when it comes to patch inclusion:
>
> * Is it actively maintained by someone?
> * If it's a feature, can it be disabled/enabled at runtime?
> * If it's a bug fix, how bad are its side-effects?
> * What size impact does it have to the binary kernel image?
...do you include *everything* that comes by you that meets these
criteria? Because from this it sounds like anything that has an
upstream that can be built as modules would be included. My
particular directed thought right now is a somewhat invasive patch
that updates the 2.4 kernels to use i2c-2.8, which would solve some
headaches for me ("somewhat invasive", in that it also goes off and
modifies all of the other drivers that depend on i2c); if I were the
kernel maintainer, it'd trip a "too different from kernel.org" flag
for me, but it sounds like it does meet your four criteria here.
--
David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Re: Building kernel modules for stock kernels is a hell of a job!
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Manoj Srivastava <[EMAIL PROTECTED]> > >> He said use the kernel-headers package, not >> kernel-package. Any debian packaged module shall work with something >> like: > >> ./debian/rules KVERS="2.4.21" KSRC="/usr/src/kernel-headers-2.4.21" >> KPKG_DEST_DIR="../" KDREV="blah" kdist_image > > Interesting. Just out of curiosity, where is that supposed to be > documented? All of the information is in /usr/share/doc/kernel-package/README.modules, though not with a single command line like that as such. > (Btw, is it a bug for the debian/rules in a module package to run > dh_testroot from its 'build' target? I know it's not allowed in the > debian/rules in a _source_ package, but perhaps the conventions > for kernel-module packages are different). I don't consider it a bug. I do think the kdist and kdist_image targets should reinvoke make under $(ROOT_CMD), though, just to be sure. The i2c-source debian/rules file has: kdist_image: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean kdist: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules dpkg-genchanges -b -e"$(KMAINT) <$(KEMAIL)>" -u"$(KSRC)/.." > $(CHFILE) debsign -e"$(KMAINT) <$(KEMAIL)>" $(CHFILE) $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean kdist_clean: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean ...with some magic early on in the file to figure out the name of the .changes file $(CHFILE). -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Question about libcdda_paranoia
Henning Moll <[EMAIL PROTECTED]> writes: > But now i am in a bit of trouble: i packaged a woody backport of k3b. > This programm tries to dlopen (=at runtime) 'libcdda_paranoia.so'. But > that is only possible if package 'libcdparanoia0-dev' is installed. > This would mean a dependency to a development package. > Is this a bug in k3b? Should k3b try to dlopen 'libcdda_paranoia.so.0' > instead? That's probably what I would do... > Is there a standard for so-naming (which is respected by all/ most > Gnu/Linux distributions)? Well, the actual process involved is something like this: you specify -lfoo on the ld (cc) command line; the linker finds and reads libfoo.so, and looks for the SONAME field in it; that soname (typically libfoo.so.2) is written into the binary; when the binary is loaded by ld.so, that looks for the libfoo.so.2 that was the soname. So in the "normal" process, you only need lib*.so at build time, and the major-version symlink at runtime. Plus, if the major version of the library chages, you'll probably need to change your program anyways. So I think explicitly writing in libcdda_paranoia.so.0 is actually the right thing to do. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Bug#219172: RFA: lm-sensors, i2c
Package: wnpp Severity: normal I'm looking for someone to take over maintenance of the lm-sensors hardware monitoring package, along with the corresponding i2c interface kernel modules. These two packages have the same upstream and they're pretty closely related, so it'd be nice if they had the same maintainer. Both packages involve kernel modules. The lm-sensors package also involves a shared library and a few userspace packages. I'd like to say that these are clean friendly packages; they're at least lintian-clean, and the packaging is fairly sane (and debhelperful, if that matters to you), but there are Issues... (1) lm-sensors 2.8 userspace depends on lm-sensors 2.8 kernel modules, which depend on i2c 2.8 kernel modules. But the Linux kernel has i2c 2.6 kernel modules, and mix-and-match ==> kernel panic. See bug #209228. I haven't figured out a good way around this yet. Also, you can't just patch the kernel to use the newer i2c modules, since i2c support bleeds over into several other kernel modules. (2) The library's soname has changed recently. This wouldn't be so bad, but lm-sensors 2.7.0 contained a different libsensors1 from lm-sensors 2.6.5, so later versions of lm-sensors 2.7.0 had a libsensors-1debian1. Upstream did fix the soname, so now lm-sensors 2.8.0 has libsensors2. But, meanwhile, kdebase has a package (ksysguardd) that got compiled against libsensors-1debian1, and went into testing (!) in spite of the corresponding libsensors never having made it. (3) Minor i18n things that I've never gotten to looking at, mostly with the output wanting to use a "degree" character. I haven't really been using my one machine that can use lm-sensors much, and my current housemates object to it being left on (it's loud), so I don't have good access to a machine to test it on. If you're looking at this package, you should definitely have hardware that can make use of this package, and maybe you're using it already. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux everett 2.4.21-3-everett #1 Thu Aug 7 13:20:54 UTC 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Library packages and their use
[EMAIL PROTECTED] (Otto Wyss) writes: > The discussion about the libc6-dev package and its headers let me to the > impression that the Debian package structure isn't optimal for > libraries. If anyone wants to build his own version of a package (i.e. > libwxgtk2.4) he has to get all the dependent underlying dev packages as > well. This is a long line of dependencies which mostly aren't wished and > shouldn't be necessary. Why is this a problem? I don't really understand, for example, why you want to recompile libraries, or what the problem is with needing to have -dev packages installed to get header files for libraries. > There are 3 kinds of dissimilar user groups of a package: > 1. Users just using a library linked to other packages (...who don't want the header files, static libraries, or .so links; they're just users.) > 2. Developers building packages which depends on a library package (...who need the header files, etc.) > 3. Developers building his own version of this library package I don't understand this category in particular. Do you mean "maintainer"? Or do you really want to install home-built versions of libraries? Supporting home-built versions of system things (not just libraries, but also things like MTAs) is something Debian has traditionally been bad at; if I was going to optimize for this, I'd probably use a BSD distribution over anything Linux-based. > Currently group 1 just uses the "normal" packages while group 2 + 3 have > both to use the "dev" packages. Especially for group 2 this isn't a good > solution leading to a long line of unnecessary dependencies. Again, what makes them unnecessary? If myapp.c includes foo/foo.h, and foo/foo.h includes bar/bar.h, then you can't compile myapp.c without having bar/bar.h around, period. Which means that, in the Debian world, you need to have libbar-dev installed, even if myapp.c doesn't include anything out of bar.h directly. > Solution 1: Splitting the 2 packages into 3. Not very attractive, it > will more confuse than improve the situation. Maybe the dbg packages > could take over the role of the 3. group. ...what is the proposed split here? All of your proposals are kind of hand-wavy, and I really don't understand what you're getting at. > Solution 2: Packages are changed that group 1 + 2 can use the normal > packages and only group 3 uses the dev. That means the normal library > packages contain enough so that other packages depending on this can be > build. That sounds like a proposal to get rid of -dev packages entirely. Is that what you're actually proposing? > I'm not sure if any of the above solutions will improve the situation > but we should all try to remove dependencies wherever possible. "Dependencies are bad"? Yeah, there are lots of ways to get around them (static linking and the like) but they come with lots of costs (binary bloat, need to rebuild every package when libc changes). -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Need help: Idle X-user?
Dennis Stampfer <[EMAIL PROTECTED]> writes: > timeoutd loggs user out when they reached timeout-restrictions like max. > login-time, max. idle-time, etc. > > Is there any way to querry how long a X-user is idle? You might look at the xscreensaver driver source; the basic answer is "yes, about four of them, none of which are guaranteed to be there". > If not, do you think it's okay to write something like "IDLE-Logout > does not work with X" into Readme.Debian and into the > config-file(,manpage, ...)? IMHO the README.Debian file and package description should be sufficient. Mentioning it in the man page wouldn't hurt; I think splattering it in the config file is going a bit far. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Bug#171555: ITP: kernel-patch-sensors Hardware health monitoring tool (kernel patch) . This package contains two kernel patches. For 2.4.19 and 2.4.20.
Robert Nagy <[EMAIL PROTECTED]> writes: > * Package name: kernel-patch-sensors > Version : 2.6.5 > Upstream Author : The Lm_sensors Group <[EMAIL PROTECTED]> > * URL : http://www2.lm-sensors.nu/~lm78/ > * License : GPL > Description : Lm-sensors is a hardware health monitoring package for > Linux (kernel patch) > > I've created the patches on my own for 2.4.19 and 2.4.20 from the > lm-sensors-source package. > This patch allow you patch you kernel with lm_sensors. Hmm. I (as the lm-sensors maintainer) am a little ambiguous about this. It seems wrong to have two separate source packages for lm-sensors when they both do the same thing. But I'm also unclear whether the effort of maintaining a kernel-patch version of lm-sensors in addition to the modules source is useful effort, since this sounds like something that's hard to debug via the BTS. How involved are the patches? (How does the kernel-package patch_the_kernel option work?) Can you submit a wishlist bug against lm-sensors-source, at least? > This package Depends on kernel-patch-i2c. How much "depends"? Right now the standalone kernel modules for lm-sensors 2.6.5 depend on i2c 2.6.1 or newer, so the version of i2c in kernels 2.4.13 or newer works fine too. There's magic in the lm-sensors-source package to figure this out. Repeat everything I said before about kernel patches, replacing lm-sensors with i2c (including filing a wishlist bug against i2c-source). -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Using kernel-build packages to autobuild modules
The perennial wart on the side of kernel module packages is that it's a big pain to auto-build modules for the stock kernels. It looks like the 2.4.20 kernel packages now include a kernel-build package, which advertises that it contains everything you need to do module builds. Is there a good way to drop this into module builds? The fundamental problem seems to be that I want to build-depend on kernel-build-2.4.20, and then build a module for each of the flavors in /usr/src/kernel-build-2.4.20. But which flavors exactly exist varies per platform, and might also vary between builds of the kernel. This means that the contents of debian/control need to be different on each platform. I could put every possible architecture/version/flavor triple in debian/control, but this seems unmaintainable. Any hints? -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: ABI change in libsensors1 (from lm-sensors)
Steve Langasek <[EMAIL PROTECTED]> writes: > On Mon, May 12, 2003 at 01:45:30PM -0400, David Z Maze wrote: >> (a) Repackaging lm-sensors 2.6.5, which would just have libsensors1 >> 1:2.6.5-1, which in turn would Conflict: with any packages that >> have compiled against libsensors1 2.7.0 (AFAIK, just one). > >> (b) Changing the soname of libsensors.so to libsensors.so.1.debian.1 >> in lm-sensors 2.7.0, and changing the name of the library package >> to libsensors-1debian1, and changing the shlibs file >> appropriately. > >> (c) Checking that the user-kernel interface hasn't changed; that is, >> that the 2.6.5 library works vs. 2.7.0 modules, and vice versa. > >> Is this a reasonable course of action? The soname feels a little ugly >> to me, but otherwise, assuming (c), it does feel like about the right >> thing to do. > > You're talking about doing all of the above? If you do (b) and (c), why > do you still need to do (a)? (I.e., why would you maintain two versions > of the library in unstable simultaneously?) > > Doing (b) and (c) seems reasonable, at least. But if you don't have > kernel interface issues from (c), I don't see why you would want (a). I'd like packages that haven't recompiled vs. libsensors-1debian1 to still work. (a) would mean providing the old libsensors1 with the old ABI, which would enable this. (If (c) works and I do (b) but not (a), then the lm-sensors source package now provides libsensors-dev and libsensors-1debian1, and nothing provides libsensors1.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: "Bug marked as done" messages to-be-MIMEified?
"Adrian 'Dagurashibanipal' von Bidder" <[EMAIL PROTECTED]> writes: > Q: is content-disposition handled properly, especially for > messag/rfc822 type attachments? (Or if not, are message attachments > displayed inline by default?) Gnus: yes (since 5.8.0, the first MIME-aware version) > (Yes, I've stopped caring about users of a certain other widespread MUA, as > you've probably guessed anyway when you notice me using PGP/MIME to sign > messages...) I'm not actually clear how much this is a good thing; at some level, we do want people reporting bugs. (Though at the same level, we also want them reading and using debian-user, and "get a real MUA" is a common sentiment there.) But yeah, its unnamed inbound MIME handling is pretty terrible; content-disposition is completely ignored, so if I attach a file to mail, the recipient sees my .signature as a separate attachment... -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: ABI change in libsensors1 (from lm-sensors)
Chris Cheney <[EMAIL PROTECTED]> writes: > Why not kick upstream into releasing 2.7.1 with proper soname bump to > libsensors2 (Make sure they are aware they screwed up...). Then upload > libsensors2, there are only 8 sources depending on libsensors1 now so > it wouldn't be a big deal to rebuild those few in any case. I did send upstream mail pointing out the issue and asking for an soname change, but I haven't heard anything back. I'll upload a new package with a Debian-specific soname as soon as I can get to a development machine with the relevant hardware, probably tomorrow... > sources depending on libsensors1 > > hardware-monitor > kdebase > ksensors > lm-sensors > mrtgutils > wmgtemp > wmsensors > xsensors (The other motivation for uploading a new libsensors1 is to Conflict: with the subset of these packages that have linked against the libsensors1 that doesn't work; if I'm not going to do that, then I should probably ask that libsensors1 be removed.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Maintaining kernel source in sarge
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Kernel module policy: > - > > * Kernel modules must be provided as a "binary source" package. > * Module source packages should provide a debian/rules file. > * The debian/rules file must compile the module if KSRC=kernelsourcedir > and KVERS=versionname is priovided. I'd be slightly happier if the targets kernel-package used were supported here, 'debian/rules kdist-image' and such. (This is to accomodate "binary source" packages that have a single debian/rules file that's copied verbatim from the source package to the binary package; both lm-sensors and i2c work this way, don't know about other packages.) > * The debian/rules file may fail if an unsupported version of the kernel is > provided by the environment. > * The debian/rules file may fail if no kernel-headers is in that location. > * The debian/rules file should handke KMAINT and KEMAIL env variables. ...in fact, this looks a lot like what kernel-package currently documents. Is a separate policy from the kernel-package documentation needed? (FWIW, i2c and lm-sensors both successfully build against only the kernel headers, via the kernel-build-* packages.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: How to put files at a location determined at install-time.
Marc L de Bruin <[EMAIL PROTECTED]> writes: MLdB> What I am trying to build are a couple of packages (let's call one of MLdB> these mydata.deb) containing just ordinary files, related to a MLdB> specific application. All these packages Depend on a generic MLdB> configuration package. This configuration package determines the final MLdB> location of these ordinary files by asking the user via MLdB> debconf. Why do these files not have a specified location? The two cases I can think of are (a) you're installing something that's system-wide, in which case you can just pick a location as the package maintainer, or (b) you're installing something that potentially multiple users would want to use. In the case of (a), I'd just unpack under /var/lib/genericpackage, and then use a symlink or Apache configuration or whatever to tell whatever it is that uses the files where they actually are. For something that multiple users could potentially want to use, really the best thing to do is provide a tarball in the package, and let the end-user be responsible for unpacking it where they feel is appropriate; this is the approach the various kernel module packages use. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
