Re: RFS: uvcvideo -- Source for the USB Video Class (uvcvideo) webcam driver
On Mon, Dec 17, 2007 at 02:24:03PM -0500, Ryan Schultz wrote: > * Package name: uvcvideo > Version : 20071216svn > Upstream Author : Laurent Pinchart <[EMAIL PROTECTED]> > * URL : http://http://linux-uvc.berlios.de/ > * License : GPL > Programming Lang: C > Description : Source for the USB Video Class (uvcvideo) webcam driver > > This package provides the source code for the uvcvideo kernel modules. > The uvcvideo package is also required in order to make use of these > modules. Kernel source or headers are required to compile these modules. > . > The UVC driver supports several video input devices, including the > Logitech QuickCam series, many notebook cameras, the Apple iSight, > and several others. How does this compare to the linux-uvc-source package already in the archive? -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp] - where does /etc/default/ntpdate come from?
On Tue, Dec 18, 2007 at 06:53:39PM +0100, D. Pathirana wrote: > Actually there IS THE file in "debian/ntpdate.default" but is never > refered in the rules file or elsewhere. > > I believe it has something to do with .default suffix but I was not able > to find any docs about what and how it is going on. So where does the > magic happen? dh_installinit You can run $ DH_VERBOSE=1 debian/rules build to see exactly what each debhelper program is doing. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ifeq in an if statement
On Sun, Jan 27, 2008 at 01:20:45AM +0100, Laszlo Boszormenyi wrote: > In one package I would like to prevent some binary being strip-ped if > DEB_BUILD_OPTIONS instruct so. How about using the conditional to set STRIP = /bin/true if the nostrip option is present. Then you don't have to clutter up the rest of the rules. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
how indicate that a kernel module package is obsolete?
I maintain a kernel module package (eeepc-acpi-source) that has been merged into the mainline Linux kernel as of version 2.6.26, and has had features added, bugs fixed, etc. The standalone module is still useful for the 2.6.25 kernel, but will be unnecessary in lenny+1. I'd like to somehow indicate that the resulting eeepc-acpi-modules-NNN packages are obsolete when NNN >= 2.6.26. 1. I can make the package fail to build (under module-assistant or make-kpkg) when the kernel version is recent enough. I don't know whether this kind of "conditional build failure" is acceptable practice, but it would keep useless .debs out of the archive. 2. I can make the package continue to build, but have the resulting .deb conflict with, as well as depend on, the corresponding linux-image package, so it becomes uninstallable. 3. I can do nothing at the package level, and rely on "educating users" to not use this package for recent kernels. I'd appreciate any guidance. Cheers, Eric -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A little question of a license
On Thu, Oct 16, 2008 at 04:01:06PM +0200, Leopold Palomo-Avellaneda wrote: > I would like to ask if a software that contains a file with this: > -- > Copyright (C) 2005, XX >All rights reserved. > > Redistribution and use in source and binary forms, with or without >modification, are permitted provided that the following conditions >are met: > > 1. Redistributions of source code must retain the above copyright > notice, this list of conditions and the following disclaimer. > > 2. Redistributions in binary form must reproduce the above copyright > notice, this list of conditions and the following disclaimer in the > documentation and/or other materials provided with the distribution. > > 3. The names of its contributors may not be used to endorse or promote > products derived from this software without specific prior written > permission. > > -- > > could be in main? (so is dfsg) Yes, this is just the 3-clause BSD license. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
executable scripts in debian/
I need to run a script as part of debian/rules. I can't rely on it being executable when unpacked, since dpkg-source doesn't preserve the mode. I can explicitly call its interpreter (Perl in this case): /usr/bin/perl debian/my-script or I can set it executable each time: chmod +x debian/my-script debian/my-script ... Is there a preferred approach? Thanks. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fspanel -- minimalist panel for X (ITA #352430)
> Homepage: http://www.chatjunkies.org/fspanel/ This page says it is no longer maintained. OTOH, there is also fbpanel in Debian, which is described as a spinoff of fspanel. Is there a need for both? -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a kernel module
On Thu, Mar 09, 2006 at 04:49:59PM -0800, Martin Kelly wrote: > Hi, I am very new to Debian packaging, and I have a question about > packaging kernel modules. > > The program I am trying to package is a kernel module for some wireless > drivers (http://sourceforge.net/projects/rtl8180-sa2400/). I've heard > there is framework in place to package kernel modules, and I was > wondering what that was, or where I could learn more. Install the "module-assistant" package and read its docs. Many of the kernel module packages in the archive use it -- use apt-cache rdepends module-assistant to list them. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
upstream tarball repackaging from bz2 to gz
The upstream tarball for a package I maintain is in .tar.bz2 format. I've been downloading it and recompressing it into .tar.gz format. This seems like a very common situation. 1. Should I still follow the section on "best practices for .orig.tar.gz files" in the Developer's Reference, and include a README.Debian-source file and a get-orig-source target in debian/rules? 2. Should I automate the bunzip2 & gzip in the debian/watch file? (I don't think I can justify asking upstream to publish a more wasteful version of the same bits on his website just to suit Debian.) -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: rootsh
On Fri, Apr 20, 2007 at 01:33:01AM +0200, José Manuel Bustillo wrote: >2007/4/20, Nico Golde <[EMAIL PROTECTED]>: > What is the difference to script(1)? > >Is totally different programs, rootsh is a logging wrapper for shells >which logs all echoed keystrokes and terminal output to a file and/or >to syslog. It still looks like this can all be done with script + logger: $ mkfifo myfifo; logger -f myfifo & script -f myfifo -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
notifying the user about an incompatible upgrade
What is the best way to notify the user or administrator when a new version of a package changes the format of a configuration file in a backwards-incompatible way? These options occurred to me: Try to upgrade the user's old configuration automatically. Document it in NEWS. Print a warning on stderr. Use a debconf note. Send an email to root or some other system user. I'd appreciate any advice. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: scheme48 (updated package)
On Sun, Sep 09, 2007 at 09:33:21PM +1000, Trent W. Buck wrote: > It builds these binary packages: > cmuscheme48-el - Emacs mode specialized for Scheme48 > scheme48 - A simple, modular, and lightweight Scheme implementation > scheme48-doc - Documentation for the Scheme48 implementation of Scheme > scheme48-scm - Sources for the Scheme48 implementation of Scheme Why is a separate scheme48-scm package needed for the source? The long description of that package should indicate why one would want to install that (instead of "apt-get source scheme48"). -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
how should a daemon drop privileges in a PAM-compatible way?
I wrote a daemon that is started from an init-script as root, and then uses setuid and setgid to drop to a less-privileged user & group. A user discovered that the program breaks when he uses the libpam-tmpdir module, because TMPDIR doesn't get changed to the /tmp/user/NNN directory, so the daemon tries to create files in /tmp without permission. So, what is the correct way to do this? Is there a high level function to "change userid, groupid and do the related PAM things" that I can use, or an example program to copy? Thanks for any pointers. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scheme48 watch file
On Mon, Nov 26, 2007 at 08:30:56PM +1100, Trent W. Buck wrote:
> ...I haven't been able to work out how to do this, because
> http://s48.org/ has a link to 1.7/download.html instead of to 1.7/
Here's a version that works, using the downloadurlmangle option:
version=3
opts=downloadurlmangle=s{s48.org/(.*)/download.html}{s48.org/$1/scheme-$1.tgz} \
http://s48.org/index.html (.*)/download.html
You could probably tighten up the "(.*)" regexps, but the idea is to
use one pattern to detect the version, and then munge that URL to get
to the actual tarball.
--
Eric Cooper e c c @ c m u . e d u
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uscan ends up with "500 Can't connect :443 (certificate verify failed)"
On Mon, Jul 09, 2012 at 05:28:03PM +0200, Andreas Tille wrote: > [...] > uscan warning: In directory ., downloading > https://forge.imag.fr/frs/download.php/238/camitk-3.0.0-Source.tar.gz > failed: 500 Can't connect to forge.imag.fr:443 (certificate verify failed) > -- Scan finished > > Any idea how to successfully get the upstream source using uscan? Use downloadurlmangle to change "https" to "http". -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120709154334.ga7...@cooper-siegel.org
Re: tool to create .deb for proprietary software?
On Thu, Aug 23, 2012 at 03:46:08PM -0500, Matt Zagrabelny wrote: > Is there a tool to create a .deb from a directory of files? See the "equivs" package. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120823212542.ga24...@cooper-siegel.org
best practice for updating inetd.conf with a user-chosen port?
What is the best way to register a daemon under inetd with a user-chosen port? (I am packaging a daemon that is run by inetd, but does not have a standard port number.) Currently I am prompting the user for the port via debconf, grepping /etc/inetd.conf to make sure it's not already there, and then calling update-inetd. Is there a better way, or an existing package that does something similar? -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: best practice for updating inetd.conf with a user-chosen port?
On Thu, Mar 12, 2009 at 02:13:12PM +0100, Holger Levsen wrote: > On Donnerstag, 12. März 2009, Giacomo A. Catenazzi wrote: > > But now I'm not sure about: > > - if it is a good thing to have admin choosed ports > > I dont think so and I guess I'm not alone and thats why there is no best > practice to do that. The only (typo of) package where I can think off where > this is sensible as default, is one which sets up a hidden service. > > What kind of daemon are you packaging? I'm packaging approx, which for compatibility with apt-proxy defaults to port (not in /etc/services). That was fine when approx, like apt-proxy, was run as a standalone daemon from an initscript. But I just changed it to run (only) from inetd, hence this thread. Regarding the other thread in -devel about the future of inetd: in my case I found it very sensible to jettison all the code for opening sockets, binding ports, handling IPv6, handling tcp-wrappers, daemonizing processes, etc. and punt it to inetd. Since apt clients keep their connections open for many multiple, the performance hit is negligible. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
restricting git commits to the debian subdirectory?
I maintain both the upstream and Debian version of a program in a git repo, using "upstream" and "master" branches, git-buildpackage, etc. Occasionally I forget which branch I'm on and commit upstream changes to the master branch by mistake. Is there a way to tell git that when I'm on the master branch, I should only be allowed to commit files in the debian/ subdirectory? -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623221641.ge15...@localhost
how to correct missing changelog information?
I recently uploaded a new version of a package and forgot to include a (closes: #NNN) line in the changelog for a bug that was closed. I can easily close the bug using the mailserver, but what is the right way to correct the changelog file? Will it break anything if I simply "revise history" and change the earlier version's entry the next time I do an upload? -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100721023144.ga27...@localhost
