Bug#354934: ITP: acerhk -- Acer Hotkey driver for Linux
Package: wnpp Severity: wishlist Owner: Kel Modderman <[EMAIL PROTECTED]> * Package name: acerhk Version : 0.5.32 Upstream Author : Olaf Tauber <[EMAIL PROTECTED]> * URL : http://www.informatik.hu-berlin.de/~tauber/acerhk/ * License : GPL Description : Acer Hotkey driver for Linux This driver will give access to the special keys on notebooks of the Acer Travelmate series, which are not handled by the keyboard driver. It also works on notebooks from other manufacturers (some Medion, Fujitsu-Siemens, ...). . It also has some other related functionality (depending on the model): - controlling LEDs (Mail, Wireless) - enable/disable wireless hardware . http://www.informatik.hu-berlin.de/~tauber/acerhk/ acerhk is i386 only. Current packages are available at the following location:- http://kanotix.com/files/debian/pool/main/a/acerhk/ Thanks, Kel. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (700, 'unstable'), (500, 'experimental'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-rc5-1 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: btsco -- ALSA drivers and daemons for using bluetooth audio devices
Hi Nobuhiro, On Sunday 17 September 2006 17:46, martin f krafft wrote: > also sprach Nobuhiro Iwamatsu <[EMAIL PROTECTED]> [2006.09.17.0559 +0200]: > > * Package name: btsco > > Please coordinate with Kel and Russell (on CC), who have been > working on this package for a while. One of the reasons that we have > not released it yet is because we want to make btsco a daemon that > can automatically associate with the device. Right now, btsco > requires manual (and root) interaction on every use. My excuse is that I have no btsco device, now or ever ;-) Therefore, I cannot be the one responsible for maintaining the proposed daemon. However, I will be glad to assist you in any way possible. The current existing btsco package is at: http://kanotix.com/files/debian/pool/main/b/btsco/btsco_0.42-3.dsc Russel maintains a Sarge backport: http://ace-host.stuart.id.au/russell/files/debian/sarge/btsco/ Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391032: ITP: gspca -- source for the gspca v4l kernel module
Package: wnpp Severity: wishlist Owner: Debian spca5xx Maintainers <[EMAIL PROTECTED]> * Package name: gspca Version : 01.00.04 Upstream Author : Michel Xhaard <[EMAIL PROTECTED]> * URL : http://mxhaard.free.fr/index.html * License : GPL Programming Lang: C Description : source for the gspca v4l kernel module The gpsca video for linux (v4l) driver, provides support for webcams and digital cameras based on the spca5xx range of chips manufactured by SunPlus, Sonix, Z-star, Vimicro, Conexant, Etoms, Mars-semi, Pixart and Transvision. . The gspca driver is a rewrite of the well known spca5xx v4l kernel module from the same author, Michel Xhaard. . This package provides the source code for the gspca kernel modules. Kernel source or headers are required to compile these modules. For basic install steps see /usr/share/doc/gspca-source/README.Debian.gz . http://mxhaard.free.fr/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396648: ITP: rt73 -- Linux device driver for Ralink RT73 a/b/g WLAN Card
On Thursday 02 November 2006 08:55, Piotr Roszatycki wrote: > Package: wnpp > Severity: wishlist > Owner: Piotr Roszatycki <[EMAIL PROTECTED]> > > * Package name: rt73 > Upstream author : Paul Lin <[EMAIL PROTECTED]> > Version : 1.0.3.6 > * URL : > http://www.ralinktech.com/drivers/Linux/RT73_Linux_STA_Drv1.0.3.6.tar.gz * > License : GPL > Programming Lang: C > Description : Linux device driver for Ralink RT73 a/b/g WLAN Card > > I am the owner of USB-stick Wi-Fi network interface (Edimax EW-7318Ug). The > only working driver is Ralink RT73 original driver. I'd like to see this > driver in Debian distribution. > > I want to provide rt73-source package which is compatible with > module-assistant. The resulting package (rt73-module-$VERSION) contains > rt73.ko driver. The driver loads firmware from separate file and has > included the blob with the default firmware if separate file is not > available. > > I think the driver can go to contrib with removed the blob from its sources > and with the firmware rt73.bin file can go to non-free as rt73-firmware > package. > > The rt73.bin file is marked as GPL. There is no real source code included > but this license implies that it is redistributable file at least as > non-free. I notice you quote upstream origin is ralinktech.com, but what about the rt73 drivers from rt2x00 project[1], that are maintained and bugfixed by a bunch of cool hackers, and are the origin of the existing rt2400, rt2500, rt2570 and rt2x00 source packages already in debian? Thanks, Kel. [1] http://rt2x00.serialmonkey.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of IPW3945 (Was: IPW3945)
On Sunday 12 November 2006 23:15, Evgeni Golov wrote: > On Sun, 12 Nov 2006 11:42:17 +0100 Loïc Minier wrote: > > - public packages for the driver may be found on personal web sites > > of various people, I've found Joachim Reichel, Russel Stuart, and > > Stefan Lippers-Hollmann to be providing such packages; I could update > > the more recent version based on a packaging mostly by Kel Modderman > > to the latest upstream version for my local needs, and it works like a > >charm, especially with the patches Kel has been adding recently; > >Daniel Baumann ITPed this driver, and Kel requested comments on his > >packages on the debian-mentors@ list > > - daemon is also available publicly from Joachim Reichel's site; > > Jurij Smakov ITPed the daemon, and started separate packaging efforts > > which he offered for comments as well recently; I've tested the > > packages of Jurij, and they work nicely (except for a point I believe > > is being addressed) > > These two are also packaged in Kanotix [1][2] (ucode is too, but it's > just one file...). In my eyes the packages are done well and are working > flavously on my Thinkpad. Could someone compare them to the packages > listed above? Yes. The -ucode package is already provided by firmware-ipw3945, thus a non-issue. The module source package from Kanotix is the one mentioned by Loic. Further info at [1]. Thanks, Kel. [1] http://lists.debian.org/debian-mentors/2006/11/msg00156.html
Re: kernel modules postinst script
Hi, Bernd wrote: > #!/bin/sh > set -e > > SYSTEMMAP=/boot/System.map-_KVERS_ > > if [ -f $SYSTEMMAP ] ; then > depmod -ae -F $SYSTEMMAP _KVERS_ > elif [ "`uname -r`" = "_KVERS_" ] ; then > depmod -a & > fi As of debhelper 5.0.37, dh_installmodules uses the System.map for the target kernel as per template, iirc. No maintainer provided script templates are required for this purpose if dh_installmodules is used. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian packages and upstart jobs
On Saturday 12 December 2009 07:07:21 Russ Allbery wrote: > Hello everyone, > > One of the packages I maintain, OpenAFS, is a network file system. As > such, one generally wants it to start before things like gdm that need to > read the user's home directory. However, in Ubuntu, gdm is started by > upstart instead of an init script, and all init scripts are run after the > native upstart jobs are run. > > The best way to address this for Ubuntu would be to introduce an upstart > job for OpenAFS. However, the package is in universe and hence > preferrably shared between Ubuntu and Debian. > > Is there any reason why it would cause problems for me to add an upstart > job to the Debian package, even though Debian doesn't currently use > upstart? (I realize that the logic around deactivating the init script if > upstart is present may be a bit complex, but I suspect we can find ways of > dealing with that.) I assume the job just sit there quiescent until > Debian switches to upstart. debehlper >= 7.4.1 contains an implementation of dh_installinit which takes care of debian/$package.upstart (and debian/$package.$name.upstart when called with --name= parameter) by installing the job(s) to /etc/init.d/ with a symlink from /etc/init.d/$jobfile -> /lib/init/upstart-job. It also adds 'upstart-job' to the substvars in misc:Depends. The status of 'upstart-job' is unknown to me, which raises my concern that Debian boot system may not be ready for upstart jobs when they are installed by dh_installinit. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please help me make athcool compatible with dependency-based init systems (was: Release Update: freeze, architecture requalification)
Hi Nicolas, On Wednesday 23 July 2008 06:18:43 Nicolas Boullis wrote: > > Hi, > > > > Disclaimer: I've been pretty busy recently, not giving my Debian > > packages the care and love they deserve. That's why I'm now asking for > > help, somewhat late... > > > > On Sat, Jul 19, 2008 at 03:35:35PM +0200, Luk Claes wrote: > > > > > > * Prepare init.d-Scripts for dependency-based init systems > > > > > > Wider testing of dependency-based init systems has lead to some new bugs > > > for this goal, but the current state looks quite well. We are confident > > > that we will have full support for dep-based init system in lenny. > > > > One of my packages, namely athcool installs an init script that is not > > yet compatible with dependency-based init systems. For some reason, it > > was not detected by automatic systems such as lintian, and no bug was > > filed against it, and no-one cared about it yet. > > > > Athcool installs an init script but does not install links to run it on > > boot, and that might be the reason why lintian did not notice about it. > > (No startup link is installed because athcool causes bad stability > > issues on some systems. If one tests it and experiences such problems, > > the system is back to a normal state after a reboot.) Someone who is > > satisfied with athcool can run update-rc.d (as documented in > > /usr/share/doc/athcool/README.Debian) to enable startup links. > > > > I'd like to reproduce a similar behaviour with the headers for > > dependency-based init systems, but I know close to nothing about such > > systems. I read the corresponding section of the LSB, but it did not > > help me much. I guess I could set Default-Start and Default-Stop empty. > > But then I have no idea how I would document the enablement of startup > > links by the user. Since those keywords are called "Default", I guess > > there is a way to override them, but how? Or I think one might change > > the Default-Start and Default-Stop keyworks, but then who would they ask > > the system to take the change into account? Just add the LSB header with correct information like: ### BEGIN INIT INFO # Provides: athcool # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: # Description: enable powersaving mode for Athlon/Duron processors ### END INIT INFO Your package does not call update-rc.d in postinst, courtesy of "dh_installinit -n", therefore no links get created even on insserv system. There is no need to modify README.Debian instructions, as insserv package provides an update-rc.d wrapper. When the admin follows the existing instructions of "update-rc.d athcool start 20 2 3 4 5 ." you will get runlevel links, just that the sequence number 20 is ignored and a more precise sequence number is calculated by insserv. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nut package freeze exception request (dependency based boot)
Hi all, On Wednesday 17 September 2008 23:08:27 Anton Martchukov wrote: > On 9/17/08, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > If we need virtual package scripts in init.d than I see now to options: > > > > > > 1) Use a script instead of symlink with different lsb headers (this > > > means rework of all packages using symlink) > > I suspect this involves very few packages, and could be implemented > > for Lenny, thought it is rather late for it. :) I would recommend this > > approach. > > (Adding mantainers of all ups-monitor related packages to CC. Note, > that upsd is orphaned, but it does not provide this link anyway). > > Can we work out a common solution for the problem? Now apcupsd, > genpower, nut (in testing), powstatd create ups-monitor symlink in > init.d since they provide ups-monitor virtual package. However, > insserv cannot solve dependencies since it discovers several init > scripts providing ups-monitor. Do I understand correctly that in all of these packages providing the /etc/init.d/ups-monitor symbolic link, that none of them attempt to register /etc/init.d/ups-monitor with update-rc.d in their postinst scripts? Is the link just there to be a "virtual/persistent" link to whatever service which is installed and provides the functionality? Inspection of the nut package leads me to believe this may be the case, so I wrote a patch for insserv which ignores any symlink in /etc/init.d/ which points to another script in /etc/init.d/, as I am not aware of any cases where this is valid (nor should it be in the future if we intend to have discrete and unique bundles of LSB data in the scripts). Can anyone think of what is wrong with this solution? > > The solution for this might be to replace symlink with separte script > (it can source original one) that have different lsb headers not to > confuse insserv. Obviously at least the listed packages behavior > should be changed to support this. > > Any objections? Well, lets us try and adapt insserv first, if that fails we may change the packages. For insserv to be widely accepted I think we must make effort to make it an almost "drop in" replacement which do not need other package churn. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#499537: ITP: iw -- tool for configuring Linux wireless devices
Package: wnpp Severity: wishlist Owner: Kel Modderman <[EMAIL PROTECTED]> * Package name: iw Upstream Author : Johannes Berg <[EMAIL PROTECTED]> * URL : http://wireless.kernel.org/en/users/Documentation/iw * License : BSD-3 Programming Lang: C Description : tool for configuring Linux wireless devices This package contains the `iw' tool which allows you to configure and show information about wireless networking. The tool is currently mainly used for drivers based on the mac80211 stack but work is under way to make it useful for other drivers as well. This package will be maintained by the Debian/Ubuntu wpasupplicant Maintainers <[EMAIL PROTECTED]> at: svn://svn.debian.org/pkg-wpa/iw/trunk http://svn.debian.org/wsvn/pkg-wpa/iw/trunk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nut package freeze exception request (dependency based boot)
On Sunday 21 September 2008 01:12:34 Anton Martchukov wrote: > On Thu, Sep 18, 2008 at 11:19:15PM +1000, Kel Modderman wrote: > > Is the link just there to be a "virtual/persistent" link to whatever service > > which is installed and provides the functionality? > > Inspection of the nut package leads me to believe this may be the case, so > > I wrote a patch for insserv which ignores any symlink in /etc/init.d/ which > > points to another script in /etc/init.d/, as I am not aware of any cases > > where > > As for ups-monitor that yes, it's the case. I looked at a couple of the packages you identified and this was also the case. The nut package should reinstate the symlink then, and new insserv uploaded with modification to handle /etc/init.d/symlink -> script case. > As for symlinks > I only heared about debian-edu earlier in this thread: > > > Petter Reinhold: > >> 2) Changhe insserv to not count symlinks at all (do not know about > >> possible affects about it) > >This will break debian-edu (which symlink in a script used for the > >first boot after installation, and remove it after the boot). I am > >not sure about other effects. > > But I guess it's realted to ignoring symlinks at all. Yeah, the patch committed would ignore symlinks to a relative path which contain no path separator, which can only be scripts in the same dir that insserv is reading scripts from (/etc/init.d/). > > Can you fill a bug to push this patch to unstable? #485045 Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: update-rc.d
Hi all, This email describes an extension of update-rc.d to provide an interface for disabling and reenabling initscript sysvinit runlevel start links. It contains a patch that is the last in a series[0] of patches submitted to the sysvinit team. After speaking with Petter Reinholdtsen on irc he suggested sending the idea to a wider audience for review and discusion. Another proposed update-rc.d extension[1] is worth a mention too, though it is not described in detail by this communication. It is a proposal for a method providing an interface for maintainer scripts to facilitate change of runlevel scheme on package upgrades. Please have a comment and identify what you think is good and crap. [0] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002861.html [1] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html --- DISABLING OR REENABLING INIT SCRIPT LINKS When run with the disable [ S|2|3|4|5 ] options, update-rc.d modifies existing runlevel links for the script /etc/init.d/name by renaming start links to stop links with a sequence number equal to the difference of 100 minus the orignal sequence number. When run with the reenable [ S|2|3|4|5 ] options, update-rc.d modifies existing runlevel links for the script /etc/init.d/name by renaming stop links to start links with a sequence number equal to the positive difference of current sequence number minus 100, thus returning to the original sequence number that the script had been installed with before disabling it. Both of these options only operate on start runlevel links of S, 2, 3, 4 or 5. If no start runlevel is specified after the disable or enable keywords, the script will attempt to modify links in all start runlevels. Below is an excerpt from a test suite script which shows the intended interface in action. At the very bottom of this email exists the patch (it depends on the other patches in the aforementioned series). --- update-rc.d hotkey-setup start 85 2 3 4 5 . stop 20 1 . Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/S85hotkey-setup -> ../init.d/hotkey-setup --- / `-- etc/ |-- init.d/ | `-- hotkey-setup |-- rc0.d/ |-- rc1.d/ | `-- K20hotkey-setup -> ../init.d/hotkey-setup |-- rc2.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc3.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc4.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc5.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc6.d/ `-- rcS.d/ --- update-rc.d hotkey-setup disable Disabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup /etc/rc2.d/S85hotkey-setup /etc/rc3.d/S85hotkey-setup /etc/rc4.d/S85hotkey-setup /etc/rc5.d/S85hotkey-setup Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/K15hotkey-setup -> ../init.d/hotkey-setup --- update-rc.d hotkey-setup reenable Re-enabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup /etc/rc2.d/K15hotkey-setup /etc/rc3.d/K15hotkey-setup /etc/rc4.d/K15hotkey-setup /etc/rc5.d/K15hotkey-setup Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/S85hotkey-setup -> ../init.d/hotkey-setup --- update-rc.d hotkey-setup disable 2 3 4 Disabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup /etc/rc2.d/S85hotkey-setup /etc/rc3.d/S85hotkey-setup /etc/rc4.d/S85hotkey-setup /etc/rc5.d/S85hotkey-setup Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/S85hotkey-setup -> ../init.d/hotkey-setup --- update-rc.d hotkey-setup reenable 3 4 Re-enabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotk
Re: RFC: update-rc.d
Sorry for not mentioning before, please keep me in CC on replies. On Sunday 21 September 2008 12:53:17 Michael Biebl wrote: > Kel Modderman wrote: > > Hi all, > > > > This email describes an extension of update-rc.d to provide an interface > > for disabling and reenabling initscript sysvinit runlevel start links. > > > > It contains a patch that is the last in a series[0] of patches submitted to > > the sysvinit team. After speaking with Petter Reinholdtsen on irc he > > suggested > > sending the idea to a wider audience for review and discusion. > > > > Another proposed update-rc.d extension[1] is worth a mention too, though it > > is > > not described in detail by this communication. It is a proposal for a method > > providing an interface for maintainer scripts to facilitate change of > > runlevel > > scheme on package upgrades. > > > > Please have a comment and identify what you think is good and crap. > > > > [0] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002861.html > > [1] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html > > Imho long overdue, thanks for taking a look at this! > > I haven't looked at [1] yet, but what happens, if you update a disabled > init script, will it update the K symlinks too, so when you (re)enable > the service, that it has the correct priority? No. Once the admin changes the link scheme, the default state has been changed and the modification will be preserved. It is intended as an interface of convenience for a local admin, so that they do not need to cumbersomely manipulate the symlink farm manually. But as you point out, it becomes painful when the admin wants to revert to defaults, as the default configuration no longer exists in suitable form to be easily replicated ... > > Example: > # update-rc.d foo defaults > /etc/rc[2345].d/S20foo > /etc/rc[016].d/K20foo > > # update-rc.d foo disable > /etc/rc[2345].d/K80foo > /etc/rc[016].d/K20foo > > # update-rc.d foo from defaults to start 30 2 3 4 5 . stop 70 1 . > /etc/rc[2345].d/K70foo > /etc/rc1.d/K70foo > > Would it work like this? No, but I guess this is leading to the other ideas you've floated on [EMAIL PROTECTED] involving link scheme state or defaults being stored somewhere else on the filesystem, instead of using the link scheme to determine defaults. > Would it also work together with insserv? My initial tests lead me to believe that insserv respects symlinks that have had the S -> K bit swapped, and still manages the sort number dynamically as service dependencies change. The from .. to .. api might be a different story, although insserv has a --defaults option which could possibly provide an analogous interface for changing runlevel defaults. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: update-rc.d
On Tuesday 23 September 2008 04:40:00 Michael Biebl wrote: > Kel Modderman wrote: > > Hi all, > > > > This email describes an extension of update-rc.d to provide an interface > > for disabling and reenabling initscript sysvinit runlevel start links. > > > > Hi again, > > thinking more about it, I think a function "is-enabled" would be quite > handy. > This would allow to query the init system in a defined way, if a given > service is enabled or disabled. > > Another idea would be, to define a new update-rc.d function called > "status", which would return either "running, not running or disabled". > There were some efforts recently, to add a status action to the init > scripts, which would be a prerequiste of such a new interface to work > properly. The mandate of update-rc.d is to manage initscript runlevel symlinks, not more or less, as I understand it. Therefore the querying of service status seems well outside of update-rc.d's scope. Ubuntu have added a `service' utility in sysvinit (2.86.ds1-59ubuntu4), it looks like a utility that satisfies your criteria, it is briefly introduced here: http://dustinkirkland.wordpress.com/2008/09/02/a-working-service-script-in-ubuntu-intrepid/ It can be seen in the Ubuntu package diff on sysvinit's PTS: http://patches.ubuntu.com/s/sysvinit/sysvinit_2.86.ds1-59ubuntu4.patch Debian could adopt this service utility, or the ideas and code behind service could be integrated into invoke-rc.d, making it "service-like" as some people desire: http://bugs.debian.org/377758 Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sidux?
Hi Lucas, On Thursday 16 October 2008 16:21:16 Lucas Nussbaum wrote: > Hi, > > Are some DDs or -devel@ readers involved into Sidux development? No Developers afaik. A couple of readers though. > > What's their exact technical model? They duplicate the whole archive, or > just change a few packages and use the normal Debian archive for the > rest of the packages? Distribute an installable live media which is based on software from the Debian sid archive at any given point in time, plus the necessary packages required for the live media to become possible (a live initramfs, some live media only initscripts, installation infrastructure) as well as our own linux image/module packages, some artwork and desktop preseed data. We try to adhere to the DFSG as close as possible [0]. Our distributable media contains only software which is in Debian main, or the main component of the sidux software archive (software existing in sidux/main adheres to same guidelines as Debian/main). No firmware, 3rd party multimedia stuff or other proprietary software or drivers are provided on the distributed media. There are a couple of home grown softwares included, such as a multi-lingual 'sidux' manual, a (K)control centre module for administrative tasks and an application for writing basic /etc/network/interfaces stanzas for standard desktop networking situations. Support requests and bugs are proxied by the sidux forums and irc channel. The community of sidux users make use of the infrastructure to discuss things desktop users usually discuss, and occasionally they report problems with broken packages which pop up in the sid archive. These problems can be dealt with a couple of ways, someone can cook up some crackful sed/perl one-liner to hack system files in ways not understood by the person executing them (thanks pusling for pointing this out in another reply, but we do not do that) or the bug report can be taken to the Debian BTS so that the problem may be addressed in a packaging update or enhancement. We choose the latter method. A lot of times a problem reported in the forum or on irc is already reported to the Debian BTS and we can supply a transient package NMU via our repository (fix.main section) to fix the immediate breakage, or we can put up a big warning sign in the forum/irc so that people restrain from upgrading their system during problematic periods and wait for the problem to be fixed within Debian. If the problem is not yet reported, we try to get a bug report + patch if possible to the BTS. As a rule, we hardly ever maintain a delta to software existing in Debian archive, except in the following situations: * we require modifications to achieve particular needs/persuits/goals: - linux kernel packages (using same packaging as Debian, with a maintained delta) - kernel module packages which compile against these new Linux versions, or are not yet in Debian - gfxboot patches for legacy grub, to enhance user experience with live media - our live media infrastructure, which existed before live-initramfs/helper was forked from casper and we don't particularly want to throw away just now (we never used live-helper, as lamby's reply suggests, just shared some knowledge) * it is severely broken and the Debian maintainer doesn't do anything for long periods (eg, sysvinit + libata shutdown, xserver-xorg-video-vesa) * one of us is heavily involved in Debian maintenance of the software, giving us a pool of users to test changes before going to Debian with them (eg, wpasupplicant, insserv, lirc) > (what does /etc/apt/* look like?) etc/apt/ |-- apt.conf.d | |-- 01autoremove | |-- 70debconf | `-- 80sidux |-- secring.gpg |-- sources.list |-- sources.list.d | |-- debian.list | `-- sidux.list |-- trustdb.gpg |-- trusted.gpg `-- trusted.gpg~ $ cat etc/apt/apt.conf.d/80sidux | grep -v '^//' APT::Get::AutomaticRemove "0"; APT::Get::HideAutoRemove "1"; APT::Install-Recommends "0"; APT::Install-Suggests "0"; Debug::pkgAutoRemove "0"; $ cat etc/apt/sources.list.d/*.list deb http://ftp.uk.debian.org/debian/ sid main #deb-src http://ftp.uk.debian.org/debian/ sid main deb http://sidux.com/debian/ sid main fix.main #deb-src http://sidux.com/debian/ sid main fix.main > > Are there opportunities to collaborate with them on some things? We collaborate on a few things already, none of them particularly major with respect to Debian's normal ongoings, but never the less, we try to exert our influences in areas we care about if we have the opportunity and ability: * maintain a few packages in Debian * submit patches to enhance packages in Debian, or create packages which are later adopted by a Debian Developer * report bugs in software distributed by Debian The people who do this work do so on their own accord, and do not particularly claim their allegiance to the sidux group or whatever by way of email address or some footnote on bottom of every communication. Therefore, our
Re: Possibility for dependencies against specific kernel modules
On Friday 31 October 2008 22:20:26 Josselin Mouette wrote: > Le vendredi 31 octobre 2008 à 12:44 +0100, Bastian Blank a écrit : > > Because of some recent events, I thought about the possibility for > > packages to depend against kernel module packages. As we don't want to > > dictate the usage of Debian provided kernels, we need a last resort > > fallback to the modules source. > > I think this is something good to have, but I’m skeptical about the > fallback to the source. It will, in unstable and sometimes in testing or > even stable, to situations where the modules are not available for a > while, and the source will get installed, leaving the system in a broken > state. Unless the source can use DKMS or a similar mechanism to > automatically generate modules, this is not very reliable. > fwiw, I have tried to address the issue of having $module-source packages have their binary product built and installed rather transparently, you may look at the initial hackwork at: http://svn.berlios.de/svnroot/repos/fullstory/dmakms/trunk/ http://svn.berlios.de/svnroot/repos/fullstory/dmakms/trunk/debian/README.Debian It's the start of a solution for: #299727 dmakms has got technical flaws, I know, but it works well enough for my current needs (without patching existing tools such as module-assistant, which could probably do with some lovin'), maybe it could be extended and fixed up to be technically better and useful for others. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function
Package: wnpp Severity: wishlist Owner: Kel Modderman * Package name: touchfreeze Upstream Author : Stefan Kombrink * URL : http://qsynaptics.sourceforge.net/dl.html * License : GPL-3+ Programming Lang: C++ Description : a facility for disabling touchpad tap-to-click function Touchfreeze docks in your system tray and disables your touchpad while typing. It re-enables your touchpad when typing stops, using a configurable delay time. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function
On Monday 29 December 2008 00:38:09 Evgeni Golov wrote:
> On Mon, 29 Dec 2008 00:04:58 +1000 Kel Modderman wrote:
>
> > Touchfreeze docks in your system tray and disables your touchpad
> > while typing. It re-enables your touchpad when typing stops, using a
> > configurable delay time.
>
> How does this compare to syndaemon from xserver-xorg-input-synaptics?
It's a GUI application which sits in the system tray of desktop environments
that support that, whereas syndaemon is a command line utility.
Touchfreeze is a (limited) replacement for {k,q}synaptics, which were
developed by (to best of my knowledge) the same person/people, which have
since been declared abandonware and removed from Debian [0].
[0] http://bugs.debian.org/468941
Fathi Boudra intended to package touchfreeze, but didn't do so. I contacted
pkg-kde-extras team and co-ordinated to help maintain it under their
maintenance umbrella [1].
[1]
http://lists.alioth.debian.org/pipermail/pkg-kde-extras/2008-September/006333.html
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function
On Tuesday 30 December 2008 03:44:26 Josselin Mouette wrote: > Le dimanche 28 décembre 2008 à 15:38 +0100, Evgeni Golov a écrit : > > On Mon, 29 Dec 2008 00:04:58 +1000 Kel Modderman wrote: > > > > > Touchfreeze docks in your system tray and disables your touchpad > > > while typing. It re-enables your touchpad when typing stops, using a > > > configurable delay time. > > > > How does this compare to syndaemon from xserver-xorg-input-synaptics? > > Especially, does it avoid waking up the CPU several tens of times per > seconds like syndaemon does? > I think they are similar in that regard ... Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible MBF due to DBus security issue
On Sunday 04 January 2009 06:57:00 Simon McVittie wrote: > > Debian/Ubuntu wpasupplicant Maintainers > > > >wpasupplicant > > ??? As far as I can tell, wpasupplicant installs an unaffected D-Bus configuration. Patch welcome if wrong :) Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: integration with power management stacks
On Sunday 11 January 2009 22:07:21 Stephen Gran wrote:
> Hello all,
>
> I have a couple of open bug reports about integration of hdparm with
> power management stacks (people would, quite rightly, like to see their
> disk settings reapplied at resume) - 468307 and 510676.
>
> Is there any sort of canonical place I can put a script and have it run
> that all of them look at?
pm-utils is probably providing the best place for this type of stuff, a few
distro's are collaborating to develop and maintain it. hal uses and depends on
it so should pm-utils be present on most standard systems.
> I have no idea for:
> pm-utils: ?
/etc/pm/{config,power,sleep}.d/
See pm-action(8) and pm-powersave(8). manpages.debian.net seems a good
off line viewer if these are not installed on your system.
> the gnome power stack - is this a veneer on pm-utils or it's own thing?
To best of my knowledge, veneer on pm-utils via hal.
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Tuesday 02 March 2010 04:13:25 Luis R. Rodriguez wrote: > On Mon, Mar 1, 2010 at 8:09 AM, Paul Wise wrote: > > On Mon, 2010-03-01 at 10:47 -0500, John W. Linville wrote: > > > >> FWIW, I don't create the tarballs. Perhaps we could ask Johannes to > >> do something in his scripts that create them? Beyond that I don't > >> see much point in checking-in a ChangeLog. > > I can add that too. > > > It definitely shouldn't be checked into git, but rather generated from > > the git commit logs; with git2cl, git log or similar. With an autotools > > based build system you would add a command to the Makefile.am so that > > automake runs git2cl during 'make dist' / 'make distcheck'. For > > non-autotools based projects you usually won't have a standard 'make > > dist' so it would need to be added to whatever script is the equivalent. > > > >> Do you like that git2cl output? It seems rather ugly to me... > > > > Its the standard ancient GNU form for a ChangeLog. I have no opinion on > > its aesthetics and I don't think it matters what format it has really. > > I think the format is indeed pretty ugly, can't we just do: > > git log v0.9.8..v0.9.9 > ChangeLog > > I've attached an example output of this on the iw package for example. > Paul, does Debian packaging not care the format the ChangeLog is on? FWIW, I do not think all of this is necessary, the information stored in the git repository is rich and readily available. We're getting pedantic here. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003020750.58757@otaku42.de
Bug#572220: ITP: wireless-regdb -- wireless regulatory database
Package: wnpp Severity: wishlist Owner: Kel Modderman * Package name: wireless-regdb Upstream Author : Luis R. Rodriguez * URL : http://wireless.kernel.org/en/developers/Regulatory/#Theregulatorydatabase * License : ISC Programming Lang: C, Python Description : wireless regulatory database This package contains the wireless regulatory database used by the Central Regulatory Database Agent (CRDA) to configure wireless devices to operate within the radio spectrum allowed in the local jurisdiction. . This regulatory information is provided with no warranty either expressed or implied. Only Linux drivers which use cfg80211 framework can make use of the regulatory database and CRDA. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100302125850.1429.35665.report...@localhost
Re: Debian Installer 6.0 Beta1 release
On Monday 01 November 2010 22:51:36 Christian PERRIER wrote: > Quoting Thomas Goirand (z...@debian.org): > > On 10/31/2010 03:00 AM, Otavio Salvador wrote: > > > The Debian Installer team[1] is pleased to announce the first beta > > > release of the installer for Debian GNU/Linux Squeeze. > > > > Great, thanks for the huge work. > > > > I was wondering if there will be WPA support in D-I for squeeze, as this > > No. Nobody did the needed tests on the patch proposed in > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;bug=327309 For this approach to be achieved cleanly, upstream wpa_supplicant authour would need to provide wpa_ctrl interface as a shared library so that we are not using a copy of that stuff. In it's current state, if I were a debian-installer maintainer, I wouldn't be thrilled to accept a clone of file(s) which already exists (in some version or another) in some other source package in the archive. I've asked wpa_supplicant upstream about it just now, will see what he reckons. I am interested in helping debian's installer gain support for better wireless networking, however there is much to learn about debian-installer itself to get started and I currently struggle to allocate time to existing Debian commitments. I tried to help answer Glenn Saberton's questions at the time he was busy on this stuff, but failed to help with anything more substantial :( Other components of Debian's wireless networking stack are missing too: crda and wireless-regdb. These may need to be integrated into debian-installer in the future too. So it seems that Debian's wireless networking stack is not keeping up close with upstream changes, and I am the first point of failure in this regard. pkg-wpa team understaffed, help needed etc etc. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201011041811.11753@otaku42.de
Re: [renamed] Debian crda?
On Wednesday 25 March 2009 17:39:03 Paul Wise wrote: > On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez wrote: > > > Last time I poked them it seemed it was not easy to figure out how to > > deal with, if at all, the optional but recommended RSA signature stuff > > [1] with the DFSG. > > > > [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature > > What is the percieved DFSG/RSA conflict? I can't detect any based on > that section of the page. Hi Paul, By default the upstream wireless-regdb tarball contains and installs a pre-built wireless regulatory information binary signed by John Linville's openssl snakeoil. It is my understanding that in Debian we would prefer to build the binary from its source code. That presents a problem because CRDA expects to see John Linville's openssl stuff. One way to work around this is to munge CRDA and regdb together, generate our own openssl stuff and build CRDA and wireless-redb at the same time. Another way to go is to do away with the openssl stuff during build altogether, but Luis doesn't like that, and the build system's need patching to support it last time I checked. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wednesday 25 March 2009 17:51:41 Luis R. Rodriguez wrote: > On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez wrote: > > On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise wrote: > >> On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez > >> wrote: > >> > >>> Last time I poked them it seemed it was not easy to figure out how to > >>> deal with, if at all, the optional but recommended RSA signature stuff > >>> [1] with the DFSG. > >>> > >>> [1] > >>> http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature > >> > >> What is the percieved DFSG/RSA conflict? I can't detect any based on > >> that section of the page. > > > > Thanks Paul, then its just a matter of packaging. There is an > > debian-example/ directory with a cdbs example of how to package for > > wireless-regdb and crda if anyone is up for it. The example packaging needs some love, I think. I don't see it as a great reference to the eventual packaging material that would enter Debian. > > And as its probably best to coordinate with Ubuntu, they have a > wireless-crda package which combines both into one package. Its > shipping for Jaunty. And that's the only way to sanely package it (by combining the two pieces upstream splits) as show by Fedora also choosing that route. Luis why can't CRDA and regd simply be released in same tarball considering they have such a strong relationship with eachother due to the openssl stuff? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Thursday 26 March 2009 03:41:30 Luis R. Rodriguez wrote: > On Wed, Mar 25, 2009 at 10:37 AM, Kel Modderman wrote: > > On Wednesday 25 March 2009 17:51:41 Luis R. Rodriguez wrote: > >> On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez > >> wrote: > >> > On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise wrote: > >> >> On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez > >> >> wrote: > >> >> > >> >>> Last time I poked them it seemed it was not easy to figure out how to > >> >>> deal with, if at all, the optional but recommended RSA signature stuff > >> >>> [1] with the DFSG. > >> >>> > >> >>> [1] > >> >>> http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature > >> >> > >> >> What is the percieved DFSG/RSA conflict? I can't detect any based on > >> >> that section of the page. > >> > > >> > Thanks Paul, then its just a matter of packaging. There is an > >> > debian-example/ directory with a cdbs example of how to package for > >> > wireless-regdb and crda if anyone is up for it. > > > > The example packaging needs some love, I think. I don't see it as a great > > reference to the eventual packaging material that would enter Debian. > > > >> > >> And as its probably best to coordinate with Ubuntu, they have a > >> wireless-crda package which combines both into one package. Its > >> shipping for Jaunty. > > > > And that's the only way to sanely package it (by combining the two pieces > > upstream splits) as show by Fedora also choosing that route. > > Well I actually disagree. The DFSG seems to suggest that the source code to the regulatory database should be modifiable and the derived work distributed under the same license. For our possible, and resonsible, modifications to take effect we need to build the regulatory database from source, not install the prebuilt/presigned one. The building of Debian packages is mostly done in anonymous build chroot's without access to personal cryptography information. How can the CRDA and wireless-regdb binaries both be built from source separately and share the same cryptographic information with these restrictions? (only then would debian-volatile be an option for regdb afaiu) Maybe the debian-kernel team should be contacted more directly, as it is ultimately them who need to make a decision about CONFIG_WIRELESS_OLD_REGULATORY ? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition of initscripts to new order / sequence number
On Thursday 19 March 2009 00:35:06 Jan Wagner wrote: > Hi there, > > while thinking about how to solve #508189, where I need to change the > position > of the initscript in bootorder, I thought it would not sufficient to change > only the call of dh_installinit in the rules file. > > If an user changed the symlinks, I guess I will break his changes. How should > we handle this? Is there any best practise and/or policy how we should deal > with it? I think it's not usefull just to override the changes by the local > sysadmin. > > Thanks for your hints, Jan. An update-rc.d interface for this was proposed here [0]. An analogous solution would need to be provided for dependency based boot (insserv diverts update-rc.d) and any other boot system in Debian which diverts update-rc.d. Thanks, Kel. [0] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Request for Comments: Standardize enabling/disabling of system services
On Thursday 02 April 2009 01:03:27 Patrick Schoenfeld wrote: > Hi, > > currently we seem to have no clear policy in Debian how to handle > the question: "Shall a service started once its installed or not?" > The current state of affairs is that some packages start after beeing > installed, some don't, because they don't have a reasonable default > configuration and some don't, because the maintainer does not like > this approach. > We also don't seem to have a clear consense how to disable/temporarily > deactivate services. The current situation is that some packages include > a file in /etc/default with a variable "RUN", "RUN_", > "START_ON_BOOT" or even another possible name > which decides weither a service runs when invoke-rc.d start > is issued or not. Some other packages do not follow this approach > and start or don't start as the maintainer sees fit. > > There are clear disadvantages with this: > - The administrator has no way to influence the decision weither > a service shall run directly after installation. > - The administrator needs to apply and know about several different > ways about how to enable/disable services. An interface for disabling/enabling system boot scripts has been proposed and committed [1] and also made available for dependency based boot [2]. These changes may need to be discussed further now though, as Steve Langasek seems to prefer this to be provided by a new tool (as mentioned later in this thread). Thanks, Kel. [0] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2009-February/001208.html [1] http://svn.debian.org/wsvn/initscripts-ng/?sc=1&rev=878 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Perhaps programs should create the subdirectories they use for their temporary files
On Saturday 04 April 2009 19:00:54 Guus Sliepen wrote: > On Sat, Apr 04, 2009 at 01:54:07AM +0200, Michael Biebl wrote: > > > > contact a running daemon. Could you explain what policykit uses /var/run > > > for, and educate me a bit on why D-Bus services have to put things in > > > /var/run but don't have init scripts? > > > > PolicyKit stores credentials in /var/run/PolicyKit which are of temporary > > nature > > and are automatically cleaned up on boot. > > I maintain a lot of systems that run on CompactFlash cards of a few GB, but > also have 1 or 2 GB of RAM. I mount a tmpfs over /var/cache/apt/archives, so I > can upgrade the system without using a large amount of space on flash, and to > prevent wear. Apt always complains about /var/cache/apt/archives/partial not > being there, so I either have to write an init script that creates it after > the > tmpfs is mounted, or (what I normally do is to) have a small script to perform > updates, which creates the missing directories. > > The problem is that some programs (apt-get, PolicyKit, etc.) store temporary > files in /var/run or /var/cache in their own subdirectories, but expect > something else to create these directories for them. I think we should require > these programs to create their own subdirectories at runtime. It is very > simple > to add an mkdir() command to these programs. If the directory already exists, > it is a no-op. wpa_supplicant and hostapd do this, and saves all this bollucks about providing an initscript for this sole purpose. Thanks for mentioning it Guus. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wednesday 06 May 2009 03:39:40 Steve Langasek wrote: > On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote: > > I have been told by upstream maintainers of one of my packages and by > > prominent developers of other distributions that supporting a standalone > > /usr is too much work and no other distribution worth mentioning does it > > (not Ubuntu, not Fedora, not SuSE). > > This is false for Ubuntu. Not only is it supported, but significant effort > was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as > pertains to wpasupplicant. Are the same changes (moving of runtime libs wpasupplicant uses to /lib) likely to be handed back to Debian? The same /usr-as-separate-mount bug is likely to strike iw and crda as well as it did wpasupplicant. Thanks, Kel.
Re: [renamed] Debian crda?
Hi Luis, Paul,
(Dropped the CC to linux-wireless as it rejected my other attempt to send
message claiming it was part HTML/Spam. Apologies if you get two copies.)
On Friday 27 March 2009 14:00:20 Luis R. Rodriguez wrote:
> On Wed, Mar 25, 2009 at 9:59 PM, Paul Wise wrote:
> > On Thu, Mar 26, 2009 at 1:19 PM, Luis R. Rodriguez wrote:
> >
> >>> Brainwave: no need to add a second public key to CRDA itself, the
> >>> wireless-regdb could install the public key corresponding to the
> >>> private key it was built with.
> >>
> >> Can you elaborate on what you mean? Do you mean for wireless-regdb to
> >> put the actual pubkey into the users' system somewhere? Otherwise not
> >> sure what you mean.
> >
> > The crda package would contain the default upstream public key.
> >
> > The wireless-regdb would ship the Debian maintainer's pubkey as
> > debian/pubkeys/debian.pem in the source package and
> > /lib/crda/pubkeys/debian.pub.pem (or similar) in the binary package.
And all other pubkeys of members of packaging maintenance group.
> >
> > Ubuntu would add their pubkey in a similar way.
Ubuntu probably cannot build and sign their own regulatory.bin: AFAIK they
do source only uploads and package is built on remote buildd (with no access
to privkey for signing). They seem to just install linvilles pre-compiled
presigned regulatory.bin in the Ubuntu wireless-crda package and be happy
with that.
> >
> > When wireless-regdb is built, it would:
> >
> > check the sha1sum/sha256sum of db.txt (alternatively upstream could
> > add a detached signature if possible to the tarball/git repo)
> >
> > if the db.txt is identical to the upstream one (or signed by
> > upstream), ship the upstream regulatory.bin file
> >
> > if the db.txt has been modified:
> >
> > if no private key is available, generate one automatically
I would rather the build process fail if the packager has not prepared
themselves a priv/pub key pair for maintaining wireless-regdb package or
else we could end up with a new key pair created on-the-fly and being used
to sign a regulatory.bin which is not recognised by the currently available
crda until it is recompiled with the new key in its PUBKEY_DIR.
Instead the debian packaging could provide some documentation/convenience
code for expected handling of maintainer priv/pub key pairs for signing
and authentication of regulatory.bin. Attempted to write such stuff here:
$ svn cat
svn://svn.debian.org/svn/pkg-wpa/wireless-regdb/trunk/debian/README.maintainer
---
Add to debian/pubkeys all public keys which crda should consider when
verifying regulatory.bin. This should include all members of the pkg-wpa-devel
team who plan to work on or upload wireless-regdb or crda.
To generate an openssl key pair for packaging purposes:
make -f debian/rules install-distro-key
This should create:
~/.wireless-regdb-pkg-wpa-devel.key.priv.pem
~/.wireless-regdb-pkg-wpa-devel.key.pub.pem
Copy the pubkey to debian/pubkeys and commit it to the VCS:
cp ~/.wireless-regdb-pkg-wpa-devel.key.pub.pem \
debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem
svn add debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem
When new keys are added to debian/pubkeys, the crda package needs to be
rebuilt with an updated versioned build dependency: the wireless-regdb
package version with the new key(s).
When building this package, the private key must be accessible so that
regulatory.bin can be signed by it to ensure the path of authentication
for the regulatory domain database is as good as possible. It does however
mean that the package cannot be built in a clean chroot (eg. pbuilder)
without having your ~/ bind mounted in it.
---
> >
> > rebuild the regulatory.bin file using the private key
> >
> > create the corresponding public key and install it in the package as
> > /lib/crda/pubkeys/custom.pub.pem when it is not the same public key as
> > one of the ones in debian/pubkeys/*.pem (avoids shipping two copies of
> > the Debian pubkey)
The pubkeys are small enough to not bother adding code and worry about having
a duplicate key in /lib/crda/pubkeys/ I think. At least at this stage it is
least of packaging worries.
> >
> > this scheme requires standard locations for the private key. I would
> > suggest either ~/.debian-wireless-regdb.priv.pem or
> > debian-wireless-regdb.priv.pem in the package build directory.
> >
Luis added some support code to handle this in wireless-regdb Makefile
recently.
> It is possible for users to add more public keys to the CRDA pubkeys
> dir and build their own wireless-regdb using their own private key.
> >>>
> >>> The above simplification makes this much easier.
> >>
> >> Not sure what you mean, but the idea with the pubkeys directory
> >
> > The above scheme would allow users who apt-get source wireless-regdb,
> > edit db.txt, debuild, debi to automatically trust their own key, as
> > well as trusting Debian's key and the upstream key.
Made an attempt at packaging wireless-regdb and crda after th
Re: [renamed] Debian crda?
Hi Luis, Paul,
On Friday 27 March 2009 14:00:20 Luis R. Rodriguez wrote:
> On Wed, Mar 25, 2009 at 9:59 PM, Paul Wise wrote:
> > On Thu, Mar 26, 2009 at 1:19 PM, Luis R. Rodriguez wrote:
> >
> >>> Brainwave: no need to add a second public key to CRDA itself, the
> >>> wireless-regdb could install the public key corresponding to the
> >>> private key it was built with.
> >>
> >> Can you elaborate on what you mean? Do you mean for wireless-regdb to
> >> put the actual pubkey into the users' system somewhere? Otherwise not
> >> sure what you mean.
> >
> > The crda package would contain the default upstream public key.
> >
> > The wireless-regdb would ship the Debian maintainer's pubkey as
> > debian/pubkeys/debian.pem in the source package and
> > /lib/crda/pubkeys/debian.pub.pem (or similar) in the binary package.
And all other pubkeys of members of packaging maintenance group.
> >
> > Ubuntu would add their pubkey in a similar way.
Ubuntu probably cannot build and sign their own regulatory.bin: AFAIK they
do source only uploads and package is built on remote buildd (with no access
to privkey for signing). They seem to just install linvilles pre-compiled
presigned regulatory.bin in the Ubuntu wireless-crda package and be happy
with that.
> >
> > When wireless-regdb is built, it would:
> >
> > check the sha1sum/sha256sum of db.txt (alternatively upstream could
> > add a detached signature if possible to the tarball/git repo)
> >
> > if the db.txt is identical to the upstream one (or signed by
> > upstream), ship the upstream regulatory.bin file
> >
> > if the db.txt has been modified:
> >
> > if no private key is available, generate one automatically
I would rather the build process fail if the packager has not prepared
themselves a priv/pub key pair for maintaining wireless-regdb package or
else we could end up with a new key pair created on-the-fly and being used
to sign a regulatory.bin which is not recognised by the currently available
crda until it is recompiled with the new key in its PUBKEY_DIR.
Instead the debian packaging could provide some documentation/convenience
code for expected handling of maintainer priv/pub key pairs for signing
and authentication of regulatory.bin. Attempted to write such stuff here:
$ svn cat
svn://svn.debian.org/svn/pkg-wpa/wireless-regdb/trunk/debian/README.maintainer
---
Add to debian/pubkeys all public keys which crda should consider when
verifying regulatory.bin. This should include all members of the pkg-wpa-devel
team who plan to work on or upload wireless-regdb or crda.
To generate an openssl key pair for packaging purposes:
make -f debian/rules install-distro-key
This should create:
~/.wireless-regdb-pkg-wpa-devel.key.priv.pem
~/.wireless-regdb-pkg-wpa-devel.key.pub.pem
Copy the pubkey to debian/pubkeys and commit it to the VCS:
cp ~/.wireless-regdb-pkg-wpa-devel.key.pub.pem \
debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem
svn add debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem
When new keys are added to debian/pubkeys, the crda package needs to be
rebuilt with an updated versioned build dependency: the wireless-regdb
package version with the new key(s).
When building this package, the private key must be accessible so that
regulatory.bin can be signed by it to ensure the path of authentication
for the regulatory domain database is as good as possible. It does however
mean that the package cannot be built in a clean chroot (eg. pbuilder)
without having your ~/ bind mounted in it.
---
> >
> > rebuild the regulatory.bin file using the private key
> >
> > create the corresponding public key and install it in the package as
> > /lib/crda/pubkeys/custom.pub.pem when it is not the same public key as
> > one of the ones in debian/pubkeys/*.pem (avoids shipping two copies of
> > the Debian pubkey)
The pubkeys are small enough to not bother adding code and worry about having
a duplicate key in /lib/crda/pubkeys/ I think. At least at this stage it is
least of packaging worries.
> >
> > this scheme requires standard locations for the private key. I would
> > suggest either ~/.debian-wireless-regdb.priv.pem or
> > debian-wireless-regdb.priv.pem in the package build directory.
> >
Luis added some support code to handle this in wireless-regdb Makefile
recently.
> It is possible for users to add more public keys to the CRDA pubkeys
> dir and build their own wireless-regdb using their own private key.
> >>>
> >>> The above simplification makes this much easier.
> >>
> >> Not sure what you mean, but the idea with the pubkeys directory
> >
> > The above scheme would allow users who apt-get source wireless-regdb,
> > edit db.txt, debuild, debi to automatically trust their own key, as
> > well as trusting Debian's key and the upstream key.
Made an attempt at packaging wireless-regdb and crda after thinking about
stuff discussed in this thread, the proposed packaging is at:
svn://svn.debian.org/svn/pkg-wpa/wireless-regdb/trunk/
svn://svn.debia
Re: Bug#529624: netbase: networking should not be stopped on reboot or halt
On Thursday 21 May 2009 01:56:16 Marco d'Itri wrote: > Does anybody see any downsides to this? > > - Forwarded message from Teodor - > > From: Teodor > To: Debian Bug Tracking System > Subject: Bug#529624: netbase: networking should not be stopped on reboot or > halt > > Package: netbase > Version: 4.34 > Severity: important > Tags: patch > > The current LSB header in the /etc/init.d/networking script contains: > # Default-Stop: 0 6 > > The networking should not be stopped at reboot or poweroff/halt since some > software depends on the networking to work until the host is down. One > example is 'apcupsd' and 'nut' software which needs to be able to detect on > slaves the power status reported by the master host which is actually > connected to the UPS. If the networking is stopped than the slaves cannot > connect to the remote daemon even if the UPS daemon is still working on the > master. > > The patch to achieve this is quite simple: > > --- /etc/init.d/networking2008-07-26 02:02:15.0 +0300 > +++ /etc/init.d/networking_new2009-05-20 18:45:36.0 +0300 > @@ -4,7 +4,7 @@ > # Required-Start:mountkernfs ifupdown $local_fs > # Required-Stop: ifupdown $local_fs > # Default-Start: S > -# Default-Stop: 0 6 > +# Default-Stop: > # Short-Description: Raise network interfaces. > ### END INIT INFO > The patch does not handle upgrades; existing rc.d links will be preserved and not changed to suit the new LSB defaults. Thanks, Kel.
Re: On init in Debian
> Whereas there's no indication that RHEL is switching away from upstart. I'm > not sure why Debian should regard OpenSUSE as an opinion leader when picking > its core technologies. When it comes to the boot system we have collaborated quite a lot with Werner Fink who is SuSE/OpenSuSE affiliated with sysvinit/insserv & startpar, it would be wise of those who work on Debian's boot system to at least take note of what direction OpenSuSE takes and consider if we may have the opportunity to collaborate further when adopting new boot system technologies. Kel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203241307.22627@otaku42.de
Re: Bits from the Release Team - Kicking off Wheezy
Hi Stefano, On Mon, 2 May 2011 06:41:07 AM Stefano Zacchiroli wrote: > On Sun, May 01, 2011 at 10:08:46PM +0200, Pierre Habouzit wrote: > > Those are real users from real life. I'm not saying "we"-re > > representative of a majority of Debian Users, but unlike all the > > handwaived users we've read about in this thread, those are real. > > First of all I think you should concede that the exercise you're asking > us to do cannot be done as easily as you did yours. You've been able to > mention real users of an existing distro, you are asking others to > provide evidence of users of a thing that does not exist yet; quite > challenging... So you do have an inherent advantage, but let me try > nonetheless. > > During last year: > > - I've talked at several trade shows and conferences with developers of > rolling distros based on Debian (in particular: Aptosid/Sidux and > Linux Mint Debian Edition). They usually claim they have built those > distros because Debian wasn't offering such feature (yes, they should > have probably tried do that in Debian, NIH syndrome exists, yada yada, > not to mention the fact they might have said that to me because they > wanted to be kind towards Debian). It must have been half a dozen > people. On the contrary, sidux/aptosid/$whatever exists, in my opinion, because Debian sid is a very useful and usable software collection with a small army of real communicative people who are motivated to care for it and keep it working well. Personally, I never involved myself in those groups to try and solve any kind of deficiency in Debian, but rather to get with people to learn about Debian, help it function better and to solve or advise about occaisional problems associated with using constantly changing software. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105020713.54829@otaku42.de
