Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

2009-04-01 Thread Michael Tautschnig
[...]
> 
> I'm unsure why we need *any* 32-bit libraries or binaries on an
> amd64 system.  If one needs to run 32-bit software, it is possible to
> debootstrap an i386 system and use it as a chroot.  Using a tool such
> as schroot handles all of the kernel personality and chroot details,
> and even allows normal users to use it with access to all their files,
> etc.  With a few one line scripts/shell aliases, it's completely
> transparent.  It also has the advantage of being a complete i386
> system rather than just a collection of libraries; you can keep it up
> to date using the usual tools, and even boot it if you desire.  i.e.
> you get all the normal security support and updates.
> 
> With multiarch, it's a different story, but we aren't quite there yet.
> 

My main use of 32-bit libraries is commercial software that is available for
32bit systems only. Yes, that's bad, but I can't do anything about that ATM. I'd
really hate to run (and maintain!) an additional chroot on each of those servers
just to run a single application. I do have i386 schroots on other systems, but
I prefer not to maintain that on each and every server. It might actually be a
bit of problem, because one of those commercial products is our backup
software...

Best,
Michael



pgpuxu7YoZpem.pgp
Description: PGP signature


Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

2009-04-01 Thread Sune Vuorela
Package: wnpp
Severity: wishlist
Owner: Sune Vuorela 


* Package name: Qoreutils
  Version : 1.0.0
  Upstream Author : John Doe 
* URL : http://www.qoreutils.org/
* License : GPL
  Programming Lang: C++ with Qt
  Description : Coreutils reimplemented using Qt libraries

Qoreutils is a reimplementation of the classic tools from coreutils,
such as ls, mkdir and cp

I'm packaging this on behalf of the Debian Qt/KDE maintainers as a first
step towards making the Qt libraries Essential: yes and on the way to
take over the world.

Currently, the package will dpkg-divert all the implemented tools of
coreutils to shake out any remaining bugs and if any bugs found,  the
user can fall back to command.coreutils as a last way out. Within the
next couple of months, it will instead have replace/conflict/provides
coreutils and slowly push out coreutils from the most users machines.

/Sune

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (200, 'experimental')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Transitions update: some done, some ready, some starting

2009-04-01 Thread Felipe Sateler
Adeodato Simó wrote:

> We’ll be also
> doing some Bin-NMUs to get rid of dependencies on obsolete
> jack-audio-connection-kit transitional packages

Should we file bugs against packages for build-depending on the wrong package,
so that we can drop the Provides later? Or just let it be for the time being?

-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Transitions update: some done, some ready, some starting

2009-04-01 Thread Felipe Sateler
Adeodato Simó wrote:

> We’ll be also
> doing some Bin-NMUs to get rid of dependencies on obsolete
> jack-audio-connection-kit transitional packages

Also, I think you can start the binNMUs now, since the shlibs file already point
to the libjack0 package.

-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Participate in development

2009-04-01 Thread Ishan Jayawardena
Hi everyone,
I'm a computer science student at the University of Moratuwa, Sri Lanka. And
I was searching for some open source project to contribute to. So I read
about Debian and read couple of documentation at Debian wiki and I subscribe
to Debian wiki. Now I need to know how to start or how can I get involved in
a development work for Debian. I need your help. Please also let me know how
can I start coding and how can I improve my coding and programming skills as
I go on. Can any beginner join this development community easily? I expect
your kind reply
thank you.


Bug#522151: ITP: calf -- High quality open source audio plugins for musicians

2009-04-01 Thread Adrian Knoth
Package: wnpp
Severity: wishlist
Owner: Adrian Knoth 


* Package name: calf
  Version : 0.0.18.3
* URL : http://calf.sf.net/
* License : GPL
  Programming Lang: C++
  Description : High quality open source audio plugins for musicians

(Include the long description here.)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.28.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Transitions update: some done, some ready, some starting

2009-04-01 Thread Adeodato Simó
> > We’ll be also
> > doing some Bin-NMUs to get rid of dependencies on obsolete
> > jack-audio-connection-kit transitional packages

> Should we file bugs against packages for build-depending on the wrong package,
> so that we can drop the Provides later? Or just let it be for the time being?

You will need to file bugs at RC severity against jackbeat and
gst-plugins-bad0.10 ASAP, as I already mentioned in the previous mail.

For the rest, feel free to file bugs at minor severity; you’ll probably
want to usertag them, and to include a mention that libjack-dev is in
Lenny already. When there are no packages left in testing build-depending
on the old name, you can drop the provides.

> Also, I think you can start the binNMUs now, since the shlibs file already 
> point
> to the libjack0 package.

Yes, I just need to find a bit of time to do it. I’ll get back to you
once I’ve scheduled them, so that you can track failures, etc.

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Participate in development

2009-04-01 Thread Obey Arthur Liu
Ishan Jayawardena a écrit :
> Hi everyone,
> I'm a computer science student at the University of Moratuwa, Sri Lanka.
> And I was searching for some open source project to contribute to. So I
> read about Debian and read couple of documentation at Debian wiki and I
> subscribe to Debian wiki. Now I need to know how to start or how can I
> get involved in a development work for Debian. I need your help. Please
> also let me know how can I start coding and how can I improve my coding
> and programming skills as I go on. Can any beginner join this
> development community easily? I expect your kind reply
> thank you.

Hi Ishan,

You might want to have a look at:


Cheers

Arthur

-- 
Obey Arthur Liu




signature.asc
Description: OpenPGP digital signature


Re: Bug#522151: ITP: calf -- High quality open source audio plugins for musicians

2009-04-01 Thread Ben Finney
Adrian Knoth  writes:

>   Description : High quality open source audio plugins for musicians
> 
> (Include the long description here.)

You failed to follow the instructions.

-- 
 \ “Computers are useless. They can only give you answers.” —Pablo |
  `\   Picasso |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Extended descriptions size

2009-04-01 Thread Andreas Tille

On Wed, 1 Apr 2009, Goswin von Brederlow wrote:


Cant you have mutliple descriptions for the same package with
different md5sums in the translation file?


Yes there are such cases.  If an arch is unable to catch up (for whatever
reason) and the description has changed inbetween the versions you end
up with different description translations (belonging to different package
versions).  This does not happen in stable (by definition), is very seldom
in testing and happens approximately 50 times in unstable (I can give
real numbers if you are interested and the numbers heavily depend on how
good translators catch up).

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



please add id

2009-04-01 Thread neha singh
Dear webmaster

Please add my id, my  id is-  * rozip...@gmail.com*
thank you
with regards
Miss rozi


Bug#522176: ITP: nftables -- packet administration tool for kernel nftables

2009-04-01 Thread Laurence J. Lane
Package: wnpp
Severity: wishlist
Owner: "Laurence J. Lane" 


* Package name: nftables
  Version : 0.01-alpha1 
  Upstream Author : Patrick McHardy 
* URL : 
* License : GPL
  Programming Lang: C
  Description : packet administration tool for kernel nftables

nftables is an IP packet administration tool and is intended to be
the successor to iptables.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

2009-04-01 Thread Sjors Gielen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sune Vuorela wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sune Vuorela 
> 
> 
> * Package name: Qoreutils
>   Version : 1.0.0
>   Upstream Author : John Doe 
> * URL : http://www.qoreutils.org/
> * License : GPL
>   Programming Lang: C++ with Qt
>   Description : Coreutils reimplemented using Qt libraries
> 
> Qoreutils is a reimplementation of the classic tools from coreutils,
> such as ls, mkdir and cp
> 
> I'm packaging this on behalf of the Debian Qt/KDE maintainers as a first
> step towards making the Qt libraries Essential: yes and on the way to
> take over the world.

For KMess, we have recently switched to Tcl/Tk (TMess):
http://kmess.org/board/viewtopic.php?f=13&t=3894
We did this mainly because we thought Qt and KDE was very inferior and
insuperior to Tcl/Tk. A lot of projects are making the same smart decision.

I think coreutils should not be rewritten in Qt but in Tcl, because it
will be the fastest, easiest and most maintainable solution. I for one
accept TclCoreutils, and with it Tcl, as my leader.

- - Sjors
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknTYnkACgkQHJNr90P0N+FlAQCggp9Ikw7LvL/PloP+PWXQjLYR
ugoAnAsi6g1XGjfDdO+m4leWDazy4wBk
=Wdvo
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Extended descriptions size

2009-04-01 Thread Michael Bramer

Goswin von Brederlow schrieb:

Andreas Tille  writes:


On Mon, 30 Mar 2009, Michael Bramer wrote:


Goswin von Brederlow schrieb:

I think the idea of using the Description-md5sum is that in most cases
the md5sum remains identical for many versions. If you use the
packages actual version then every upload will need a new translation
entry or some fuzzyness to accept an older versions translation.

I understood the sense of having md5sums in translation files. My
suggsetion was an *additional* field which keeps the package version.
In case there are different versions of a package in one dist (might
be because an arch is lagging behind) either the md5sums differ
and you store different translations anyway or the desciptions are
equal and in this case use the highes available version number.


Cant you have mutliple descriptions for the same package with
different md5sums in the translation file?


We _have_ mutliple descriptions for the same package with different 
md5sums in the translation file for sid.


Gruss
Grisu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Request for Comments: Standardize enabling/disabling of system services

2009-04-01 Thread Patrick Schoenfeld
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.

I know there are constraints where a local-admin decision "start/don't
after installation" cannot be followed. Still, I would like to work
on the following idea and implement it somewhere during the
squeeze (or +1) release cycle.

--- IDEA START ---
* We establish the practice, that by default no package does include
  an enabled RUN_ variable in its /e/d/ file. Instead
  every service shall include such a variable, but commented. The default
  of the init script should be to start, unless RUN_ says different.
  The name of the variable should be standardized to RUN_.

* We add a new configuration file (possibly /etc/rc.conf because thats
  a file that exists in different distributions and has a similar meaning)
  which can have the following configuration settings:

   * RUN_NEW_SERVICES_AFTER_INSTALL=
   * RUN_=

  This configuration file must not be modified by maintainer scripts.
  The rationale for the RUN_ entries is that an admin can have
  RUN_NEW_SERVICES_ON_INSTALL=false, but decide for a certain service
  that it shall start after he installed it before.

* We let the maintainer scripts respect the RUN_NEW_SERVICES_ON_INSTALL
  setting on a new installation.

* We develope a policy.d layer that respects the RUN_ settings from
  rc.conf and /e/default/* and permits/denies start of services, based
  on these settings. Init scripts shall only start if the service is allowed
  to start (RUN_* setting or RUN_NEW_SERVICES_ON_INSTALL) and if they have
  a sensible default configuration (which pays due to the
  before mentioned contraints). This policy.d layer should be of priority
  Standard. Eventually we should extend the policy.d concept in a way that
  permits to have more than one policy.d layer at a time, so that a user can
  still use an (additional) own layer.

* A bonus would be to have a utility to enable/disable services.
--- IDEA END ---

I post this as a proposal/request-for-comments to debian-devel, because
I'd like to hear if anybody thinks working on this is valueable and
because I'd like to know, who is interested to actually work on this idea
(besides myself). I also hope that some of you have some ideas
to enhance the idea.

Best Regards,
Patrick


signature.asc
Description: Digital signature


Re: Request for Comments: Standardize enabling/disabling of system services

2009-04-01 Thread Lars Wirzenius
ke, 2009-04-01 kello 17:03 +0200, Patrick Schoenfeld kirjoitti:
> 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.

We have invoke-rc.d, which maintainer scripts are supposed to use to
start services, and policy-rc.d, which the sysadmin can write to control
stuff. policy-rc.d could do with a default implementation that obeys a
single config file.



-- 
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

2009-04-01 Thread Josselin Mouette
Le mercredi 01 avril 2009 à 17:03 +0200, Patrick Schoenfeld a écrit :
> * We add a new configuration file (possibly /etc/rc.conf because thats
>   a file that exists in different distributions and has a similar meaning)
>   which can have the following configuration settings:
> 
>* RUN_NEW_SERVICES_AFTER_INSTALL=
>* RUN_=
> 
>   This configuration file must not be modified by maintainer scripts.
>   The rationale for the RUN_ entries is that an admin can have
>   RUN_NEW_SERVICES_ON_INSTALL=false, but decide for a certain service
>   that it shall start after he installed it before.

I think it is a bad idea to specify system-wide whether certain services
can be enabled or not.

Some services absolutely need to be running when they are installed, to
satisfy dependencies (think D-Bus or HAL). Some services cannot run
before they are configured (think a firewall).

I like the homogenization part of your proposal, but the default policy
should be set by packages themselves, not by the local administrator.

Cheers,
-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: Extended descriptions size

2009-04-01 Thread Goswin von Brederlow
Michael Bramer  writes:

> Goswin von Brederlow schrieb:
>> Andreas Tille  writes:
>>
>>> On Mon, 30 Mar 2009, Michael Bramer wrote:
>>>
 Goswin von Brederlow schrieb:
> I think the idea of using the Description-md5sum is that in most cases
> the md5sum remains identical for many versions. If you use the
> packages actual version then every upload will need a new translation
> entry or some fuzzyness to accept an older versions translation.
>>> I understood the sense of having md5sums in translation files. My
>>> suggsetion was an *additional* field which keeps the package version.
>>> In case there are different versions of a package in one dist (might
>>> be because an arch is lagging behind) either the md5sums differ
>>> and you store different translations anyway or the desciptions are
>>> equal and in this case use the highes available version number.
>>
>> Cant you have mutliple descriptions for the same package with
>> different md5sums in the translation file?
>
> We _have_ mutliple descriptions for the same package with different
> md5sums in the translation file for sid.
>
> Gruss
> Grisu

Then the version number will not be needed when an arch lags
behind. The translation for the old md5sum can just be kept.

MfG
Goswin


-- 
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

2009-04-01 Thread Michael Biebl
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.
> 

I don't like this idea of RUN=yes variables in /etc/default.

1.) There is already a documented interface, how to disable a service (i.e.
renaming the S?? symlinks for that runlevel to K??). Adding another layer to do
this is just confusing and inconsistent.
There are tools like sysv-rc-conf which can handle that for you. Enabling a
service is then as easy as sysv-rc-conf $service on|off


2.) It makes the init script useless.
I often install services, which I only need from time to time, so I disable them
via the approach above and can start them on-demand vi /etc/init.d/service.
A RUN=no will break that.

Imho the only sane option is, to get rid of those RUN_ variables as much as
possible and advertise tools like sysv-rc-conf more (or even install them by
default).

There are indeed services though, which should *not* be started by default, as
e.g. they need to be configured first. But instead of inventing such a RUN_
variable, the init script could directly check if its prerequisites are given
and only start in that case. It then can also output a more sane error message,
telling the user what it is missing and how he can change that.

So in short, I don't like the idea at all.
Instead of adding more of those RUN_ variables we should get rid of them as much
as possible.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

2009-04-01 Thread Mike Bird
On Wed April 1 2009 00:03:10 Sune Vuorela wrote:
> Qoreutils is a reimplementation of the classic tools from coreutils,
> such as ls, mkdir and cp

Thanks but this won't be necessary.  We just uploaded a GCC patch
that converts coreutils to use Qt.  No source changes are needed.

--Mike Bird


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

2009-04-01 Thread Milan P. Stanic
On Wed, 2009-04-01 at 09:09, Mike Bird wrote:
> On Wed April 1 2009 00:03:10 Sune Vuorela wrote:
> > Qoreutils is a reimplementation of the classic tools from coreutils,
> > such as ls, mkdir and cp
> Thanks but this won't be necessary.  We just uploaded a GCC patch
> that converts coreutils to use Qt.  No source changes are needed.

Sorry for my ignorance, but what does that mean? We will have to install
libqt always?
 
-- 
Kind regards,  Milan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

2009-04-01 Thread Samuel Thibault
Milan P. Stanic, le Wed 01 Apr 2009 18:54:22 +0200, a écrit :
> On Wed, 2009-04-01 at 09:09, Mike Bird wrote:
> > On Wed April 1 2009 00:03:10 Sune Vuorela wrote:
> > > Qoreutils is a reimplementation of the classic tools from coreutils,
> > > such as ls, mkdir and cp
> > Thanks but this won't be necessary.  We just uploaded a GCC patch
> > that converts coreutils to use Qt.  No source changes are needed.
> 
> Sorry for my ignorance, but what does that mean? We will have to install
> libqt always?

Not only libqt, but also qemu, to run the algorithmic part of coreutils
(e.g. the sorting function) safely in a virtual machine running
hurd-i386.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

2009-04-01 Thread torkvemada

2009/4/1 Milan P. Stanic :

On Wed, 2009-04-01 at 09:09, Mike Bird wrote:

Thanks but this won't be necessary.  We just uploaded a GCC patch
that converts coreutils to use Qt.  No source changes are needed.


Sorry for my ignorance, but what does that mean? We will have to install
libqt always?



Sure, but only until 2.6.30 kernel is released. As expected, Qt libs will be 
provided as a kernel module in it.

--
Best wishes,
Vsevolod Velichko



signature.asc
Description: OpenPGP digital signature


Bug#522208: ITP: inksmoto -- Xmoto level editor

2009-04-01 Thread Vincent Mauge
Package: wnpp
Severity: wishlist
Owner: Vincent Mauge 


* Package name: inksmoto
  Version : 0.5.1
  Upstream Author : Emmanuel Gorse 
* URL : http://xmoto.tuxfamily.org/
* License : GPL
  Programming Lang: Python
  Description : Xmoto level editor

  Inksmoto is the Xmoto level editor.
  It's an Inkscape extension.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Manoj Srivastava
The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.kernel as well.

On Tue, Mar 24 2009, Frans Pop wrote:

> Hi all,
>
> I'm not sure whether this discussion should happen here (d-kernel + 
> selected interested parties) or would be better held on d-devel.
> If ppl think it would be better on d-devel, then please let me know and 
> I'll restart it there.

I think this is best held on -devel, since a wider audience will
 benefit from this.

> INTRO
> =
> For the past year and more I've been building upstream kernels without 
> using any Debian tools, by just calling the kernel's own 'make deb-pkg' 
> target.
>
> The maintainer scripts for the thus generated kernel image package don't 
> do anything but call hook scripts in /etc/kernel/{pre,post}{inst,rm}.d/.

The new kernel package maintainer script will expand on
 this. The image packages do call run parts on
/etc/kernel/{pre,post}{inst,rm}.d/. 
 In additions, the doc, source, and headers packages will call upon
  /etc/kernel/{src,doc,header}_{pre,post}{inst,rm}.d/. 
 This means that hok scripts can take control at any of the maintainer
 script stages, for any of the packages produced by kernel-package.

In the future, I'll extend this to 
  /etc/kernel/{uml,xen}_{pre,post}{inst,rm}.d/. 

>
> In general the kernel team should be aware that there _are_ other current 
> users of /etc/kernel/ hook scripts.

Yes. And kernel-package has been doing so for a while, and
 intends to expand the usage.

>
> DEB-PKG PATCHES
> ===
> My patch series for the upstream kernel contains roughly the following 
> changes:
> - some minor cleanup
> - a fix so that the arm kernel image gets found (use of KBUILD_IMAGE is
>   not completely standard across arches)
> - a way to pass maintainer script parameters to hook scripts (see below)
> - an option to specify a custom package version/revision
> - an option to use a different hook scripts directory from /etc/kernel
>   (I currently use /etc/kernel.custom to avoid my hook scripts to be
>   run when I install an official Debian kernel package)
>
> The last patch provides a general escape, but it would be nice if all 
> Debian kernel packages could use the same hook scripts. (/me dreams)

Where are these patches?

>
> ISSUES
> ==
> Parameters passed to hook scripts
> -
> Official Debian kernels (at least up to 2.6.26) and make-kpkg based 
> packages pass two parameters:
> - kernel version
> - $realimageloc$kimage-$version (/boot/vmlinuz-)

> deb-pkg based packages only pass the kernel-version.
>
> AFAICT ltsp-client hook scripts use neither of these parameters.
>
> New initramfs-tools hook scripts uses the kernel version and includes a 
> hack that tests if $2 is defined to avoid running with pre-squeeze 
> kernels and make-kpkg kernels. Not ideal...
>
> There is legacy here which makes any transition hard. But given the 
> limited existing users of hook scripts I think we can essentially ignore, 
> but it would be good to agree on a standard for the future!

There are more users of the kernel images than just Debian
 packages; and I do not think we can ignore an installed base without
 reason.

>
> Is anything other than the kernel version really needed?

Yes, since in the old days the image location could be changed,
 by passing a parameter to make-kpkg. I think this feature is used,
 since it was put into kernel-package by request.

> Maintainer script parameters
> 
> Currently maintainer script parameters are not passed on to the hook 
> scripts, but IMO they could be very useful, for example: a bootloader 
> update only needs to be run on package removal, but not on purge.
>
> Given the previous point I think adding them to the parameters passed to 
> the hook scripts is not a good option. I therefore propose to instead 
> export them in a standard environment parameter. Proposal:
>   export DEB_MAINT_PARAMS="$@"

Hmm. That would mean that the first argument is the name of the
 script, then?

> Execution order of hook scripts
> ---
> Both initramfs-tools and ltsp-client currently just dump a script in the 
> hook dirs without any naming convention. If many packages were to do 
> that, chaos would be a guaranteed result.
>
> IMO scripts should have standardized names starting with numbers to 
> regulate execution order. Ranges should be reserved, for example:
> - early scripts 00-19
> - initrd generation 30-49
> - bootloader update 50-69
> - late scripts 80-99
>
> Use of new numbers by packages should probably be coordinated by the 
> kernel team.

If this were to become policy, I would say _all_ stakeholders
 should be involved, not just the official kernel packages, and that
 means not shutting out end users who compile their own kernel image
 debs.

> To conffile or not to conffile
> -

Re: Request for Comments: Standardize enabling/disabling of system services

2009-04-01 Thread Patrick Schoenfeld
On Wed, Apr 01, 2009 at 06:31:04PM +0300, Lars Wirzenius wrote:
> ke, 2009-04-01 kello 17:03 +0200, Patrick Schoenfeld kirjoitti:
> > 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.
> 
> We have invoke-rc.d, which maintainer scripts are supposed to use to
> start services, and policy-rc.d, which the sysadmin can write to control
> stuff. policy-rc.d could do with a default implementation that obeys a
> single config file.

You finished reading my mail after that paragraph, didn't you? ;)

Regards,
Patrick


-- 
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

2009-04-01 Thread Patrick Schoenfeld
On Wed, Apr 01, 2009 at 05:38:29PM +0200, Josselin Mouette wrote:
> Le mercredi 01 avril 2009 à 17:03 +0200, Patrick Schoenfeld a écrit :
> > * We add a new configuration file (possibly /etc/rc.conf because thats
> >   a file that exists in different distributions and has a similar meaning)
> >   which can have the following configuration settings:
> > 
> >* RUN_NEW_SERVICES_AFTER_INSTALL=
> >* RUN_=
> > 
> >   This configuration file must not be modified by maintainer scripts.
> >   The rationale for the RUN_ entries is that an admin can have
> >   RUN_NEW_SERVICES_ON_INSTALL=false, but decide for a certain service
> >   that it shall start after he installed it before.
> 
> I think it is a bad idea to specify system-wide whether certain services
> can be enabled or not.

Well, its only about *new* services after installation. The intention
behind that is that some people don't like to run un- or half-configured
daemons immediately after installing them. The idea is to support
whatever the admins wants to choice, which seems good to me.

> Some services absolutely need to be running when they are installed, to
> satisfy dependencies (think D-Bus or HAL). Some services cannot run
> before they are configured (think a firewall).

Yeah, right. But those are special cases that should be handled
accordingly and don't need to stop us from aiming at a homogenization of
services control.

> I like the homogenization part of your proposal, but the default policy
> should be set by packages themselves, not by the local administrator.

Well, thats an opinion I can't agree less with. Yes, I accept that there
are special cases, but the default really should be that the admin has
the last word.

Best Regards,
Patrick


-- 
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

2009-04-01 Thread Lars Wirzenius
ke, 2009-04-01 kello 20:30 +0200, Patrick Schoenfeld kirjoitti:
> You finished reading my mail after that paragraph, didn't you? ;)

Pretty much. It looked long and complicated and I was in a hurry. I
skimmed it but I see now I missed that you actually knew about
policy-rc.d.

Let me make amends by suggesting you _not_ have packages modify a
hypothetical /etc/rc.conf file, and instead invent a /etc/rc.conf.d
directory. It's been one of the lessons learned by Debian that modifying
configuration files in a lot of maintainer scripts is error-prone,
whereas having packages include configuration files in .d directories is
almost foolproof.

I would keep things simpler, though. Let package maintainers exercise
their best judgement as to whether their services should be started upon
package install or not, and provide an optional default implementation
of policy-rc.d (i.e., something not installed by default, at least not
until it has proven itself) that reads /etc/policy-rc.d.conf to see
which services to allow and which not. Syntax might be something like
this:

Deny *
AllowPriority standard important required
Allow apache2

Default should be to allow everything. Allow sysadmin to match either
names or package priorities.

This still lets packages use whatever /etc/default/$package variables
they wish, but I'm fine with that.



-- 
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

2009-04-01 Thread Patrick Schoenfeld
Hi,

On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
> I don't like this idea of RUN=yes variables in /etc/default.
> 
> 1.) There is already a documented interface, how to disable a service (i.e.
> renaming the S?? symlinks for that runlevel to K??). Adding another layer to 
> do
> this is just confusing and inconsistent.
> There are tools like sysv-rc-conf which can handle that for you. Enabling a
> service is then as easy as sysv-rc-conf $service on|off

yes, that is true. This concept is however limited in so far that you
cannot decide before installing a certain service, weither it starts
after installation. Which is important if you want to avoid running
wrong/half configured services in your network. Basically the approach
is just to give some more possible choices to the users.

> 2.) It makes the init script useless.

That is definitely not true. The init script still stays a common known
interface to control a given service. The idea just adds another layer
of control.
 
> I often install services, which I only need from time to time, so I disable 
> them
> via the approach above and can start them on-demand vi /etc/init.d/service.
> A RUN=no will break that.

Hu? How should that break it? You do not need to set RUN_=no,
if you don't want to. You can still disable the service on boot, by
disabling them via sysv-rc-conf and interface with them via invoke-rc.d.

> Imho the only sane option is, to get rid of those RUN_ variables as much as
> possible and advertise tools like sysv-rc-conf more (or even install them by
> default).

No, because this approach basically does not help anybody.
 
> There are indeed services though, which should *not* be started by default, as
> e.g. they need to be configured first. But instead of inventing such a RUN_
> variable, the init script could directly check if its prerequisites are given
> and only start in that case. It then can also output a more sane error 
> message,
> telling the user what it is missing and how he can change that.

Well, its no invention, becuase the RUN_ variables already exist. They are
just used inconsistent and every init script re-implements the parsing
of them, instead of doing it in a central place with added benefit.

Best Regards,
Patrick


-- 
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

2009-04-01 Thread Patrick Schoenfeld
Hi,

On Wed, Apr 01, 2009 at 09:50:47PM +0300, Lars Wirzenius wrote:
> ke, 2009-04-01 kello 20:30 +0200, Patrick Schoenfeld kirjoitti:
> > You finished reading my mail after that paragraph, didn't you? ;)
> 
> Pretty much. It looked long and complicated and I was in a hurry. I
> skimmed it but I see now I missed that you actually knew about
> policy-rc.d.
> 
> Let me make amends by suggesting you _not_ have packages modify a
> hypothetical /etc/rc.conf file, and instead invent a /etc/rc.conf.d
> directory. It's been one of the lessons learned by Debian that modifying
> configuration files in a lot of maintainer scripts is error-prone,
> whereas having packages include configuration files in .d directories is
> almost foolproof.

you missunderstood my mail in this point. I explicitly stated that
maintainer scripts *must not* edit the file file. Its a file which shall
be 100% under administrator control.

> I would keep things simpler, though. Let package maintainers exercise
> their best judgement as to whether their services should be started upon
> package install or not, and provide an optional default implementation
> of policy-rc.d (i.e., something not installed by default, at least not
> until it has proven itself) that reads /etc/policy-rc.d.conf to see
> which services to allow and which not. Syntax might be something like
> this:

Basically that is the idea, just that I already stated some possible
implementation details and tended to re-use existing methods that users
are familar with. 

> Deny *
> AllowPriority standard important required
> Allow apache2
>
> Default should be to allow everything. Allow sysadmin to match either
> names or package priorities.

Is dislike that format, because users are already used to the RUN_*
system and additional people changing from another distribution or even
operating system will notice similarities, which is good as well.
 
> This still lets packages use whatever /etc/default/$package variables
> they wish, but I'm fine with that.

Well, except for the RUN_* variable they could still do what they want.

Best Regards,
Patrick


-- 
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

2009-04-01 Thread Lars Wirzenius
ke, 2009-04-01 kello 21:02 +0200, Patrick Schoenfeld kirjoitti:
> Is dislike that format, because users are already used to the RUN_*
> system and additional people changing from another distribution or even
> operating system will notice similarities, which is good as well.

RUN_* variables make it harder to allow/deny by priority. I might want
to disable starting new services, but I _do_ want any services from
importand and required packages.

(Anyway, that exhausts my interest in this topic. It's not something I
really care about, so I won't argue my point very hard. Do continue the
discussion!)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

2009-04-01 Thread Cyril Brulebois
Vincent Fourmond  (01/04/2009):
>   Although I admit that schroot is a neat tool to deal with that, it is
> overkill in the case of wine, and much too complex for users that would
> be interested to use wine: one of the public that can be attracted to
> the GNU/Linux side of the game is gamers - especially now that there are
> so many *recent* games that work with it. Telling them: «well, you'll
> have to build a ia32 chroot to play...» is likely to drive them off for
> good.

I can't really see why wine couldn't embed a script to do the needed
work. Users would need to call a single command to prepare the
environment. It could, I guess, even be done in the postinst.

Mraw,
KiBi.


signature.asc
Description: Digital signature


UDD gatherer for DDTP translations (Was: Extended descriptions size)

2009-04-01 Thread Andreas Tille

On Wed, 1 Apr 2009, Goswin von Brederlow wrote:


Then the version number will not be needed when an arch lags
behind. The translation for the old md5sum can just be kept.


Well, this thread was missused to discuss several issues. 
Would you mind reading my original posting why version numbers
in Translation files make sense and would you please base your 
arguing on this posting.  Perhaps I'm just wrong but version

numbers are really handy in this case and I see an extra benefit
in making these files somehow human readable (in the sense that
I doubt you are able to calculate md5sums manually to find out
the matching description.

Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#522225: ITP: cpm -- Console password manager using PGP-encryption

2009-04-01 Thread Lars Bahner
Package: wnpp
Severity: wishlist
Owner: Lars Bahner 


* Package name: cpm
  Version : 25beta~beta1
  Upstream Author : Harry Brueckner 
* URL : http://www.harry-b.de/dokuwiki/doku.php?id=harry:cpm
* License : GPL
  Programming Lang: C
  Description : Curses based password manager using PGP-encryption

This program is a ncurses based console tool to manage passwords and store them 
public key encrypted in a file - even for more than one person. The encryption 
is handled via GnuPG so the programs data can be accessed via gpg as well, in 
case you want to have a look inside. The data is stored as as zlib compressed 
XML so it's even possible to reuse the data for some other purpose.

The software uses CDK (ncurses) to handle the user interface, libxml2 to store 
the information, the zlib library to compress the data and the library GpgMe to 
encrypt and decrypt the data securely.


-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)



-- 
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

2009-04-01 Thread Frans Pop
Patrick Schoenfeld wrote:
> * RUN_NEW_SERVICES_AFTER_INSTALL=

I dislike the semantics of this because it does not allow for the case 
where for whatever reason (e.g. new system install) you have to reboot 
shortly after installing a package before you had a chance to 
review/change the configuration.

IMO if an admin chooses not to "start after installation", the service 
should also not be started after reboot before the admin has acked 
things. So I'd prefer an implementation that uses NOT_CONFIGURED instead 
of what you're proposing.

An alternative could be a mechanism that checks some flag
"HAS_BEEN_STARTED_BEFORE" (either automatically or manually), but that 
could cause problems later in the lifetime of the system, e.g. when a 
system is restored from backup and those flags are not included (because 
they are too obscure and have been overlooked).

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Frans Pop
Manoj Srivastava wrote:
> On Tue, Mar 24 2009, Frans Pop wrote:
>> I'm not sure whether this discussion should happen here (d-kernel +
>> selected interested parties) or would be better held on d-devel.
>> If ppl think it would be better on d-devel, then please let me know and
>> I'll restart it there.
> 
> I think this is best held on -devel, since a wider audience will
>  benefit from this.

I've replied to d-kernel, but thanks for this "heads up" to d-devel.

For those interested in this topic, my full original message and initial 
replies can be found at:
   http://lists.debian.org/debian-kernel/2009/03/msg00611.html
Discussion continues at:
   http://lists.debian.org/debian-kernel/2009/04/msg1.html

If there is sufficient interest in the topic, we can summarize for or 
restart on d-devel.

Cheers,
FJP


-- 
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

2009-04-01 Thread Michael Biebl
Patrick Schoenfeld wrote:
> Hi,
> 
> On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
>> I don't like this idea of RUN=yes variables in /etc/default.
>>
>> 1.) There is already a documented interface, how to disable a service (i.e.
>> renaming the S?? symlinks for that runlevel to K??). Adding another layer to 
>> do
>> this is just confusing and inconsistent.
>> There are tools like sysv-rc-conf which can handle that for you. Enabling a
>> service is then as easy as sysv-rc-conf $service on|off
> 
> yes, that is true. This concept is however limited in so far that you
> cannot decide before installing a certain service, weither it starts
> after installation. Which is important if you want to avoid running
> wrong/half configured services in your network. Basically the approach
> is just to give some more possible choices to the users.
> 
>> 2.) It makes the init script useless.
> 
> That is definitely not true. The init script still stays a common known
> interface to control a given service. The idea just adds another layer
> of control.

And I don't see the need for such an additional layer

>> I often install services, which I only need from time to time, so I disable 
>> them
>> via the approach above and can start them on-demand vi /etc/init.d/service.
>> A RUN=no will break that.
> 
> Hu? How should that break it? You do not need to set RUN_=no,
> if you don't want to. You can still disable the service on boot, by
> disabling them via sysv-rc-conf and interface with them via invoke-rc.d.

So you have two ways now how to disable service, one via the traditional
symlinks and the other via RUN_* variables. not a good idea imho

>> Imho the only sane option is, to get rid of those RUN_ variables as much as
>> possible and advertise tools like sysv-rc-conf more (or even install them by
>> default).
> 
> No, because this approach basically does not help anybody.

Care to elaborate?

>  
>> There are indeed services though, which should *not* be started by default, 
>> as
>> e.g. they need to be configured first. But instead of inventing such a RUN_
>> variable, the init script could directly check if its prerequisites are given
>> and only start in that case. It then can also output a more sane error 
>> message,
>> telling the user what it is missing and how he can change that.
> 
> Well, its no invention, becuase the RUN_ variables already exist. They are
> just used inconsistent and every init script re-implements the parsing
 ^
Definitely not every, some do. And I don't like this behaviour as it doesn't buy
you anything.
Imo you failed to clearly motivate why we need such an additional layer. I am
not convinced yet about the benefits of such an approach.


Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Again: Bug#503367: plink: file conflict with putty-tools

2009-04-01 Thread Andreas Tille

Hi,

in October last year there was a longish discussion about name space
pollution regarding plink.  If you like to spend some time you should
read the complete log of #503367 [1].

I decided to put an end now on this issue to make sure it will
not remain as is for ever and renamed the entry in /usr/bin.
This is explained in README.Debian of this package (see svn[2]).

Two questions are left on my side:

  1. On the one hand plink upstream claimed on their website[3] that
 Debian *has* renamed plink to snplink (which is not really true
 because the discussion ended without any real action).  But Gentoo
 went the same road to "follow" Debian.

 So there is one established way which is accepted upstream to handle
 this problem.

 On the other hand there is this other biological project which
 has a snplink as well.[4]  While chances are not really high
 that this software will also be packaged - you can not know.

 So what is better: Just seeking for another name which hopefully
 is singular and asking upstream as well as Gentoo to change as
 well or live with the small risk to run the same circle of name
 space pollution in case the other snplink will be packaged?

  2. Is the information that plink was renamed to snplink visible
 enough or should I rather use a debconf note to make users really
 aware what they have to do?

Kind regards

Andreas.

[1] http://bugs.debian.org/503367
[2] 
http://svn.debian.org/wsvn/debian-med/trunk/packages/plink/trunk/debian/README.Debian?op=file&rev=0&sc=0
[3] http://pngu.mgh.harvard.edu/~purcell/plink/download.shtml
[4] 
http://www.icr.ac.uk/research/research_sections/cancer_genetics/cancer_genetics_teams/molecular_and_population_genetics/software_and_databases/index.shtml

--
http://fam-tille.de


--
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

2009-04-01 Thread Stephen Gran
This one time, at band camp, Frans Pop said:
> Patrick Schoenfeld wrote:
> > * RUN_NEW_SERVICES_AFTER_INSTALL=
> 
> I dislike the semantics of this because it does not allow for the case 
> where for whatever reason (e.g. new system install) you have to reboot 
> shortly after installing a package before you had a chance to 
> review/change the configuration.
> 
> IMO if an admin chooses not to "start after installation", the service 
> should also not be started after reboot before the admin has acked 
> things. So I'd prefer an implementation that uses NOT_CONFIGURED instead 
> of what you're proposing.
> 
> An alternative could be a mechanism that checks some flag
> "HAS_BEEN_STARTED_BEFORE" (either automatically or manually), but that 
> could cause problems later in the lifetime of the system, e.g. when a 
> system is restored from backup and those flags are not included (because 
> they are too obscure and have been overlooked).

It feels to me like we're all kind of ignoring the current mechanism for
enabling and disabling services that we already have.

It might be useful in this conversation to seperate out two different
ideas:

It would be nice to have a consistent user interface for enabling and
disabling whether a given service starts at boot (something like
redhat's chkconfig, but possibly one that works with init script
dependencies).

It would be nice for packages to be able to opt in to a common system
for allowing an admin to decide if new packages will be enabled with
the above (or similar) system.  I think it's probably a mistake to
make all packages do this by default - hal and dbus being installed
as dependencies are good examples of this behavior breaking normal
expectations, but things like avahi-daemon being installed by cups is
a good case for having things not started by default.  This common
system can be as simple a thing as ACTUALLY_RUN=1, which only controls
maintainer scripts calls to the mechanism that updates symlinks and then
calls invoke-rc.d.  This should not be referenced in init scripts
themselves, so that admins can run the scripts manually or have normal
behavior from the init script when it's symlinked appropriately.

Just my 2p,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature


Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Manoj Srivastava
On Wed, Apr 01 2009, Frans Pop wrote:

> Only just submitted:
>http://marc.info/?l=linux-kbuild&m=123861445626856&w=2
>
> maks has also submitted a set of patches:
>http://marc.info/?l=linux-kbuild&m=123851278623264&w=2Some discussion on 
> those:
>http://marc.info/?l=linux-kbuild&m=123860208704620&w=2
>
>>> ISSUES
>>> ==
>>> Parameters passed to hook scripts
>>> -
>>> Is anything other than the kernel version really needed?
>> 
>> Yes, since in the old days the image location could be changed,
>>  by passing a parameter to make-kpkg. I think this feature is used,
>>  since it was put into kernel-package by request.

> But is anyone still using it? Is there any current reason to support
> it

I think that there are Debian users who use that option of
 make-kpkg, and I have not seen any indication that there usage of that
 option has decreased.

> (i.e. is there any reason to _add_ support for it in deb-pkg or in
> whatever the kernel team is planning)?

I think so. If we do standardize on /etc/kernel/*.d directories
 as the place where kernel packages will look into to run scripts, then
 the scripts in that location should have a common API. Since we have an
 installed base, and there is going to be continued support for this
 feature by the current debian end user kernel packaging tool, we can't
 just drop the old api and scripts.

>>> Maintainer script parameters
>>> 
>>> Currently maintainer script parameters are not passed on to the hook
>>> scripts, but IMO they could be very useful, for example: a bootloader
>>> update only needs to be run on package removal, but not on purge.
>>>
>>> Given the previous point I think adding them to the parameters passed to
>>> the hook scripts is not a good option. I therefore propose to instead
>>> export them in a standard environment parameter. Proposal:
>>> export DEB_MAINT_PARAMS="$@"
>> 
>> Hmm. That would mean that the first argument is the name of the
>>  script, then?
>
> No. $@ starts at $1, not at $0.
>
> In the hook scripts I currently use I do:
> version=$1
> set -- $DEB_MAINT_PARAMS
>
>>> Execution order of hook scripts
>>> ---
>>> Both initramfs-tools and ltsp-client currently just dump a script in the
>>> hook dirs without any naming convention. If many packages were to do
>>> that, chaos would be a guaranteed result.
>>>
>>> IMO scripts should have standardized names starting with numbers to
>>> regulate execution order. Ranges should be reserved, for example:
>>> - early scripts 00-19
>>> - initrd generation 30-49
>>> - bootloader update 50-69
>>> - late scripts 80-99
>>>
>>> Use of new numbers by packages should probably be coordinated by the
>>> kernel team.
>> 
>> If this were to become policy, I would say _all_ stakeholders
>>  should be involved, not just the official kernel packages, and that
>>  means not shutting out end users who compile their own kernel image
>>  debs.
>
> Agreed. That's why I said "coordinated" and not "mandated".
> However, IMO it's probably not unreasonable to expect stakeholders to be
> subscribed to d-kernel.

I am not subscribed to -kernel, though I would consider myself
 as a stake holder.

Also, this proposal should go through the vetting of the primary
 place we make technical policy for Debian, which is the debian-policy
 mailing list. Since this is going to require interaction between all
 kinds of packages in providing scripts for kernel package handling, the
 standards we create for determining when these scripts are triggered,
 how parameters are passed in, is precesily the kind of thing that
 policy is created for.

For example, how is an initramfs creation script supposed to
 determine when the package creator wants to use an initrd? When I build
 my own kernels, I have stopped using modules (apart from nvidia). I
 certainly do not need an initrd -- how does one tell the initrd script
 not to trigger for some image packages and not others?

Traditionally, you passed --initrd to make-kpkg to trigger the
 call to initrd; but now that we are thinking of different drivers than
 make-kpkg, how is this information stored and sent to the script?

I think that crafting a policy is crucial if we want different
 mechanism to create kernel packages all work seamlessly in Debian,
 instead of each taking the approach that they are the sole users of the
 /etc/kernel/*.d mechanism.

manoj
-- 
Prosperity makes friends, adversity tries them. Publilius Syrus
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Manoj Srivastava
On Wed, Apr 01 2009, Frans Pop wrote:

> Manoj Srivastava wrote:
>> I think this is best held on -devel, since a wider audience will
>>  benefit from this.
>
> I've replied to d-kernel, but thanks for this "heads up" to d-devel.

> If there is sufficient interest in the topic, we can summarize for or 
> restart on d-devel.

Well, I am not subscribed to debian-kernel, which seems to  be
 mostly a team internal mailing list for dealing with bugs, and  doing
 internal scheduling of team activities for the most part, and deals
 mostly with issues related to official kernel images. And yes, oficial
 kernel images are one such stakeholder. People builkdihg their own
 images, using either kernel-package, or the upstream make-deb are
 usually not subscribed to the official kernel team internal mailing
 list. 

However, if we are going to move a working solution over to
 -policy at some point, I would like to get some feedback from the other
 developers; such technical expertise is always welcome.

Hence, I again request that the discussion be opened to a wider
 audience, since we are talking about systems integration of services
 related to kernel image, header, doc, and source packages. I would also
 like to get feedback from people who compile and run Xen and UML
 images. 

Thanks

manoj
-- 
"Little else matters than to write good code." Karl Lehenbauer
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
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

2009-04-01 Thread Adam Borowski
On Wed, Apr 01, 2009 at 05:03:27PM +0200, Patrick Schoenfeld wrote:
> 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.

Please, DON'T.
If a service shouldn't be run, there is a good command to disable it:
dpkg --remove

Anything else is superfluous.  There are multiple ways to disable the
service already.  No need to add a yet another one.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Manoj Srivastava
On Wed, Apr 01 2009, Frans Pop wrote:
> On Wednesday 01 April 2009, maximilian attems wrote:
>> On Wed, 25 Mar 2009, Frans Pop wrote:

>
> The default for deb-pkg should IMO remain /etc/kernel in order not to 
> break things for existing users. If you move to /lib and users want to 
> follow, they can use my mechanism.

The situation is similar for kernel-package. The installed base
 means that moving to /lib would be suboptimal, and I I do think that
 actions taken when kernel packages are installed should be overridable
 by the site admin. 

>> > New initramfs-tools hook scripts uses the kernel version and includes
>> > a hack that tests if $2 is defined to avoid running with pre-squeeze
>> > kernels and make-kpkg kernels. Not ideal...
>>
>> why not ideal?
>
> Because it relies on a very specific, largely accidental difference 
> between implementations. What if we decide that we _do_ want to use a 
> second parameter for something.
> My suggestion set the origin of a build in an envvar is more flexible.

Since the kernel-package will now stop running initramfs in the
 postinst, and will rely on a hook script to generate or not generate an
 initramfs, we have the need for a script that handles _all_ kernels
 that need an initramfs, no matter how the .deb was created, and which
 also can be told _not_ to create an initramfs, if there is no need.

We need to have a sane, documented, and stable means for doing
 so. 

>> > IMO scripts should have standardized names starting with numbers to
>> > regulate execution order. Ranges should be reserved, for example:
>> > - early scripts 00-19
>> > - initrd generation 30-49
>> > - bootloader update 50-69
>> > - late scripts 80-99
>> >
>> > Use of new numbers by packages should probably be coordinated by the
>> > kernel team.
>>
>> nah not very useful,
>
> Eh? Then how are you going to ensure update-initramfs runs before 
> update-grub? Alphabetically they are in the wrong order.

I also think we need some kind of policy guideline for naming
 scripts, and I agree in principle with the ouline Frans has proposed
 above.


>> enforcing correct file name ending with .sh might be more worthwhile.
>
> That's discouraged by policy (except maybe for files that are sourced).

We can look to /etc/init.d for inspiration here.

>> > To conffile or not to conffile
>> > --
>> > If I'm correct neither initramfs-tools nor ltsp-client currently
>> > defines the hook scripts as conffiles. This is both good and bad.
>> >
>> > - good: the hook script are removed when the package is removed which
>> >   avoids the problem that it could get run after removal, but before
>> > purge - bad: user changes in the scripts get lost on package upgrades
>>
>> no conffile.
>> users shouldn't care to much about these details.

> Most users probably won't care, but I still think you underestimate this. 
> Especially if make-kpkg and official kernels are going to use the same 
> hook dirs.

I think that if we should stick to /etc (and I think we should),
 we have no option: these files will be configuration files, even if
 they are not conffiles, and user input will have to be preserved. There
 is no reason not to follow policy here.

>
>> i'd prefer a /lib location and if you still see it worthwile
>> for powerusers the /etc conffile?!
>
> If there is a clear mechanism for overruling the standard scripts that 
> could work.

I suppose I can live with e /lib location, as long as the
 overruling by the local admin is easy.

>> > - possibly be responsible for creating/updating symlinks, although
>> > that's always a tough one as you might want symlinks updated for
>> > official kernels but not for custom built ones (or use different
>> > symlinks for custom kernels); the suggested "source" envvar could
>> > help there

I think this should be a local decision. The symlink issue has
 had some very strong opinions expressed over the years.

>> > - provide a shell library file with functions to implement some of the
>> > ideas mentioned above 
>>
>> no extra package should be needed
>
> That's a rather unsubstantiated opinion. Could you elaborate how you'd 
> solve the points I listed here?

I can see a whole set of differing solution, perhahs offered by
 a set of conflicting packages, here.

>> linux-2.6 make deb-pkg should have it's postinst fixed and should work
>> standalone that is the main point and greatest bonus.
>
> I don't understand what you're saying here. I actually _like_ the simple 
> hook script mechanism of deb-pkg as it allows me to very simply have 
> different things done for different architectures.
>
> What's broken about the deb-pkg postinst?
> What do you mean by "standalone"?

We also can not close the door on other mechanisms that help end
 users create image packages. Heck, if we can have qtcoreutils, we can
 have qt-make-kpkg.

manoj

-- 
Sanity and insanity overlap 

Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Frans Pop
Manoj Srivastava wrote:
> On Wed, Apr 01 2009, Frans Pop wrote:
>> (i.e. is there any reason to _add_ support for it in deb-pkg or in
>> whatever the kernel team is planning)?
> 
> I think so. If we do standardize on /etc/kernel/*.d directories
>  as the place where kernel packages will look into to run scripts, then
>  the scripts in that location should have a common API. Since we have an
>  installed base, and there is going to be continued support for this
>  feature by the current debian end user kernel packaging tool, we can't
>  just drop the old api and scripts.

Eh, different _existing_ tools already diverge. I agree on the need for a 
common API, or at least ensuring that there is legacy support. (After 
all, that is why I sent my initial mail).
But I see no reason why the "the make-kpkg way" should be elevated to that 
standard API without any discussion.

> Also, this proposal should go through the vetting of the primary
>  place we make technical policy for Debian, which is the debian-policy
>  mailing list. Since this is going to require interaction between all
>  kinds of packages in providing scripts for kernel package handling, the
>  standards we create for determining when these scripts are triggered,
>  how parameters are passed in, is precesily the kind of thing that
>  policy is created for.

I have no problems with that.

> Traditionally, you passed --initrd to make-kpkg to trigger the
>  call to initrd; but now that we are thinking of different drivers than
>  make-kpkg, how is this information stored and sent to the script?

Which only worked because initrd generation was/is coded in the postinst 
itself and not in a postinst hookscript.

To be honest, I don't really see why k-p supports hook scripts at all, 
given that it already does everything that's normally needed in the 
regular postinst it generates. For that reason I would guess that the 
number of users that actually use the existing hook script mechanism in 
make-kpkg is very, very low [1].

And that is a completely different model from what the deb-pkg target does 
and what's now being considered by the kernel team. Unifying those 
separate models is always going to be painful.

Cheers,
FJP

[1] Which IMO makes the "legacy" issue somewhat less important than it 
would otherwise be.


-- 
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

2009-04-01 Thread Russ Allbery
Adam Borowski  writes:
> On Wed, Apr 01, 2009 at 05:03:27PM +0200, Patrick Schoenfeld wrote:

>> 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.

> Please, DON'T.
> If a service shouldn't be run, there is a good command to disable it:
> dpkg --remove
>
> Anything else is superfluous.  There are multiple ways to disable the
> service already.  No need to add a yet another one.

The problem is, they all suck:

* Removing the service, when what you may want to do is run the service in
  a different way (via supervise or runit, for example, or via separate
  init scripts because you're running multiple instances on different
  ports or different IP addresses).

* Renaming init script links, for which we have no adequate tool and which
  is not an easily reversible process because nothing remembers what the
  init script links were originally and what runlevels they were enabled
  in.  This is particularly a problem if you have a custom runlevel
  configuration, want to disable an init script, and then want to put it
  back where you had it.

* Using policy-rc.d, which is at least underdocumented.  I've used Debian
  for a long time and I still have difficulty figuring out just what I'm
  supposed to put where to disable a specific init script for a specific
  service using the policy-rc.d layer and how that interacts with the
  system boot process.

* Adding DISABLE=y or DONT_RUN=y or DONT_NOT_RUN=no or similar unintuitive
  stuff in configuration files, with all the problems of maintaining
  configuration file differences when there are other parameters for which
  you want to accept updates, and which disables the init script.

I think that renaming and/or removing the init script symlinks is the
Right Thing To Do, but the tools we have for doing this are awful.  I
think it would be a great solution if update-rc.d gained the following
features:

* An option intended for use by automated processes that reports the
  current status of the init script (enabled or disabled) and the current
  run levels and sequence information in an easy-to-parse fashion.

* A way to disable an init script while retaining the current runlevel and
  sequence information so that when it's re-enabled, it goes back where it
  was.

* A way to move an init script at a particular sequence to a different
  sequence without breaking the rest of the world, overriding local
  policy, or killing puppies.  (Unless dependency-based boot takes over
  the world in time for squeeze and renders sequence information obsolete,
  which would be lovely.)

-- 
Russ Allbery (r...@debian.org)   


-- 
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

2009-04-01 Thread sean finney
On Wed, Apr 01, 2009 at 10:03:07PM +0100, Stephen Gran wrote:
> It feels to me like we're all kind of ignoring the current mechanism for
> enabling and disabling services that we already have.
> 
> It might be useful in this conversation to seperate out two different
> ideas:

yeah, i think these two use cases are entirely seperate but unfortunately
seem to always get lumped together.  for users/admins life would be much
easier if we had a decent chkconfig implementation installed by default.  end
of problem for them.

for packagers it's a bit more complicated and my guess is update-rc.d
and invoke-rc.d will need to be extended (and possibly replaced in
the case of update-rc.d).  there's no easy way for a maintainer to
prompt the admin for whether a service should automatically start, and
even more so in most cases usually this ends up being done with some
voodoo setting in /etc/default (instead of using the init system's
features themselves).

i actually tried to do this "The Right Way" once, using only invoke-rc.d,
update-rc.d, and debconf.  it works, anyway.  if anyone's interested
take a look at the nsca package and feel free to comment.


sean


signature.asc
Description: Digital signature


Re: Again: Bug#503367: plink: file conflict with putty-tools

2009-04-01 Thread gregor herrmann
On Wed, 01 Apr 2009 22:51:39 +0200, Andreas Tille wrote:

> This is explained in README.Debian of this package (see svn[2]).
[..]
>   2. Is the information that plink was renamed to snplink visible
>  enough or should I rather use a debconf note to make users really
>  aware what they have to do?

NEWS.Debian might be a good compromise between README.Debian and a
debconf message.

Cheers,
gregor 
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: U2: Elvis Prestley And America


signature.asc
Description: Digital signature


Re: Request for Comments: Standardize enabling/disabling of system services

2009-04-01 Thread Marc Haber
On Wed, 1 Apr 2009 23:39:34 +0200, Adam Borowski 
wrote:
>If a service shouldn't be run, there is a good command to disable it:
>dpkg --remove

My notebook has a big number of server packages installed with
services disabled for the sake of documentation.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Manoj Srivastava
The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.kernel as well.

On Wed, Apr 01 2009, Frans Pop wrote:


> - using debhelper would probably imply running a clean target and that's
>   one of the reasons why I very much prefer deb-pkg over make-kpkg:
>   build times with deb-pkg are significantly lower

When I ditched the debian/official support in the new make-kpkg,
 I get times as fast as the usptream; since nothing is rebuilt. We can
 smiply remove ./debian, and things are still fast, since only things
 that upstream kbuild thinks need to be remade are remade, and calling
 dpkg is not that slow.

I am experimenting with the idea that every time you call
 make-kpkg, it recreates ./debian; which means if you have made any
 changes, they are silently incorporated in ./debian/changelog.

I routinely use make-kpkg now from the git directory, and even
 after a git pull, very little work is done to rebuild the .deb.

manoj

-- 
Just don't make the '9' format pack/unpack numbers...  :-) Larry Wall in
<199710091434.haa00...@wall.org>
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
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

2009-04-01 Thread Steve Langasek
On Wed, Apr 01, 2009 at 08:38:46PM +0200, Patrick Schoenfeld wrote:
> Well, its only about *new* services after installation. The intention
> behind that is that some people don't like to run un- or half-configured
> daemons immediately after installing them.

It's Debian policy that packages should come with a reasonable default
configuration.  If a given package provides a default configuration for a
service that is not reasonable, you should take that up with the maintainer
of that package.

Note that this does not imply "any service that ships enabled is buggy".  It
means only that the maintainer of the package is responsible for ensuring
the default behavior isn't insecure or horrid.  Demanding that services one
selects for installation not be enabled out-of-the-box is not a prerequisite
to achieving the policy goals; that has more to do with placating
control-fetishizing admins than with ensuring secure defaults.

> > I like the homogenization part of your proposal, but the default policy
> > should be set by packages themselves, not by the local administrator.

> Well, thats an opinion I can't agree less with. Yes, I accept that there
> are special cases, but the default really should be that the admin has
> the last word.

Well, I don't see in what sense this is a "default".  The default is what's
shipped in the package.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Manoj Srivastava
On Wed, Apr 01 2009, Frans Pop wrote:

> Manoj Srivastava wrote:
>> On Wed, Apr 01 2009, Frans Pop wrote:
>>> (i.e. is there any reason to _add_ support for it in deb-pkg or in
>>> whatever the kernel team is planning)?
>> 
>> I think so. If we do standardize on /etc/kernel/*.d directories
>>  as the place where kernel packages will look into to run scripts, then
>>  the scripts in that location should have a common API. Since we have an
>>  installed base, and there is going to be continued support for this
>>  feature by the current debian end user kernel packaging tool, we can't
>>  just drop the old api and scripts.
>
> Eh, different _existing_ tools already diverge. I agree on the need for a 
> common API, or at least ensuring that there is legacy support. (After 
> all, that is why I sent my initial mail).
> But I see no reason why the "the make-kpkg way" should be elevated to that 
> standard API without any discussion.

We have had make-kpkg be the way we did kernel images since
 circa '96.  There is a a lot of installed base there -- or so we should
 assume, unless we know differenty. I'll be willing to change things if
 you can show that there is not much of an installed base -- I hate
 assuming there is none, and yanking the rug out from under the users.

>
>> Also, this proposal should go through the vetting of the primary
>>  place we make technical policy for Debian, which is the debian-policy
>>  mailing list. Since this is going to require interaction between all
>>  kinds of packages in providing scripts for kernel package handling, the
>>  standards we create for determining when these scripts are triggered,
>>  how parameters are passed in, is precesily the kind of thing that
>>  policy is created for.
>
> I have no problems with that.
>
>> Traditionally, you passed --initrd to make-kpkg to trigger the
>>  call to initrd; but now that we are thinking of different drivers than
>>  make-kpkg, how is this information stored and sent to the script?
>
> Which only worked because initrd generation was/is coded in the
> postinst itself and not in a postinst hookscript.

Right. But functionality is desirable -- regardless of how it
 was implemented in the past.

This is the functionality we want:
 o) Some kernels configurations are such that an initrd is rewquired --
all file systems, for example, can be put into modules
 o) Other configurations do not use modules -- and a lot of kernel
hackers do not. It improves boot times, etc. For these cases, an
initrd is not required, and should not be created.
 o) The same amchine may want to use a lean, experimental kernel,
and fall back on the distro default in case of failure.

Now, if you can devise a mechanism where we can distinguish
 between these kernel images, and have an initrd either created, or not
 created, i'll comply with whatever protocol you come up with.

>
> To be honest, I don't really see why k-p supports hook scripts at all,
> given that it already does everything that's normally needed in the
> regular postinst it generates.

But it does not. There is no way for the kernel package postinst
 to work with grub, without using the hook scripts.

Also, the mechanisms built in are constricting, and people are
 using different mechanisms for booting, and taking other action when a
 boot component is changed.

Keeping track of 11 architectures, different boot mechanisms,
 initrd generation schemes, and other actions people want to take, was
 taking a toll on the code complexity and bugginess.


You wanna know when I started supporting the hook directories?
,
|   * Added support for hook directories. Apart from hook variables that the
| local admin may set, there are a set of directories where packages, or
| the local admin, may drop in script files. The directories are
|   - /etc/kernel/preinst.d/,
|   - /etc/kernel/postinst.d/,
|   - /etc/kernel/prerm.d/, and 
|   - /etc/kernel/postrm.d/.
| If they exists, the kernel-image package shall run a run-parts program
| over the directory, giving the version being installed or removed as
| an argument, in the corresponding phase of installation or
| removal. Since these directories do not exist by default, this should
| have no impact on current installations.
|   
|  -- Manoj Srivastava   Fri,  8 Oct 2004 14:05:06 -0500
| 
`

That is 4.5 years ago. This is long before the kernel team
 started using this. Thne builddeb code was incorporated ito the
 mainline kernel sources in  2005-04-16.

> For that reason I would guess that the number of users that actually
> use the existing hook script mechanism in make-kpkg is very, very low
> [1].

Your false assumption kinda renders this null and void -- every
 grub user already uses the hook mechanism, and k-p has had support for
 this for over 4 years.

> And that is a completely  diffe

Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Darren Salt
I demand that Manoj Srivastava may or may not have written...

> On Wed, Apr 01 2009, Frans Pop wrote:
[make-kpkg]
>> But is anyone still using it? Is there any current reason to support it

> I think that there are Debian users who use that option of make-kpkg, and I
> have not seen any indication that there usage of that option has decreased.

I make use of it fairly regularly; its next use here will probably be to
build kernel 2.6.29.1. I normally use the kernel-image target, but I
sometimes have use for the kernel-headers target.

(And I'm still not using grub.)

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Kill all extremists!

Do not attempt to write on both sides of the paper at once.


-- 
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

2009-04-01 Thread Steve Langasek
On Wed, Apr 01, 2009 at 05:03:27PM +0200, Patrick Schoenfeld wrote:
> 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.

policy-rc.d in conjunction with /etc/default does this, but that's unduly
complex; and anyway,

> - The administrator needs to apply and know about several different
> ways about how to enable/disable services.

 - It causes conffile prompts when the package is upgraded.
 - It requires launching an editor.
 - The /etc/default/ files are sourced by the init scripts, which means
   they're intepreted by the shell, with all the syntactic pitfalls that
   implies.
 - It neuters the init script, when all you normally want is to affect the
   policy while leaving intact the admin's ability to run the init script by
   hand (e.g., for testing purposes)

> I know there are constraints where a local-admin decision "start/don't
> after installation" cannot be followed. Still, I would like to work
> on the following idea and implement it somewhere during the
> squeeze (or +1) release cycle.

> --- IDEA START ---
> * We establish the practice, that by default no package does include
>   an enabled RUN_ variable in its /e/d/ file. Instead
>   every service shall include such a variable, but commented. The default
>   of the init script should be to start, unless RUN_ says different.
>   The name of the variable should be standardized to RUN_.

No, because /etc/default/* are the wrong interface for this for the reasons
described above.

> * We add a new configuration file (possibly /etc/rc.conf because thats
>   a file that exists in different distributions and has a similar meaning)
>   which can have the following configuration settings:

>* RUN_NEW_SERVICES_AFTER_INSTALL=
>* RUN_=

Please first specify the interfaces (how this interacts with invoke-rc.d,
how it interacts with runlevel configuration, how the user configures it)
and specify the config file format afterwards.  The format should follow
naturally from the interface requirements; I don't think the above meets
our needs at all.

> * We let the maintainer scripts respect the RUN_NEW_SERVICES_ON_INSTALL
>   setting on a new installation.

The invoke-rc.d interface already handles this part; this would basically
mean providing a policy-rc.d that honors your new config file.

> * We develope a policy.d layer that respects the RUN_ settings from
>   rc.conf and /e/default/* and permits/denies start of services, based
>   on these settings. Init scripts shall only start if the service is allowed
>   to start (RUN_* setting or RUN_NEW_SERVICES_ON_INSTALL) and if they have
>   a sensible default configuration (which pays due to the
>   before mentioned contraints). This policy.d layer should be of priority
>   Standard. Eventually we should extend the policy.d concept in a way that
>   permits to have more than one policy.d layer at a time, so that a user can
>   still use an (additional) own layer.

If you mean "policy-rc.d" here, then no; policy-rc.d is specified to do
something else, and we shouldn't overload its meaning.  (I think policy-rc.d
is terribly overengineered and underdocumented anyway, and that this is a
significant factor in its slow uptake - we should avoid repeating those
mistakes.)

> * A bonus would be to have a utility to enable/disable services.

Far from being a bonus, I think this is fundamental to the success of any
plan to improve init script handling.

> I post this as a proposal/request-for-comments to debian-devel, because
> I'd like to hear if anybody thinks working on this is valueable and
> because I'd like to know, who is interested to actually work on this idea
> (besides myself). I also hope that some of you have some ideas
> to enhance the idea.

While I don't have time to work on it, I'm certainly eager to see
improvement in this area; every added /etc/default/* file makes me grimace.
If you can make progress here, I will be happy to see it.

If you manage to get the interfaces and high-level abstractions right, there
may be an opportunity here to collaborate with Ubuntu on making the same
system work with upstart?  The long-term goal for upstart in Ubuntu is to
migrate away from sysv-rc init scripts to upstart jobs, which addresses the
various problems of concurrency, dependency management, and service
supervising; if Debian and Ubuntu could collaborate on a common service
management interface, that might help scare up the manpower you need.

-- 
Steve Langasek   

Re: Request for Comments: Standardize enabling/disabling of system services

2009-04-01 Thread Steve Langasek
On Wed, Apr 01, 2009 at 03:04:10PM -0700, Russ Allbery wrote:
> * Using policy-rc.d, which is at least underdocumented.  I've used Debian
>   for a long time and I still have difficulty figuring out just what I'm
>   supposed to put where to disable a specific init script for a specific
>   service using the policy-rc.d layer and how that interacts with the
>   system boot process.

Answer:  it doesn't interact with the system boot process at all, it only
affects the behavior of invoke-rc.d. :(

> I think that renaming and/or removing the init script symlinks is the
> Right Thing To Do, but the tools we have for doing this are awful.  I
> think it would be a great solution if update-rc.d gained the following
> features:

I think this should be a separate program, reserving update-rc.d for
maintainer script use.  But please, not 'chkconfig', which is an entirely
unintuitive name. :)

> * An option intended for use by automated processes that reports the
>   current status of the init script (enabled or disabled) and the current
>   run levels and sequence information in an easy-to-parse fashion.

> * A way to disable an init script while retaining the current runlevel and
>   sequence information so that when it's re-enabled, it goes back where it
>   was.

Agreed.

> * A way to move an init script at a particular sequence to a different
>   sequence without breaking the rest of the world, overriding local
>   policy, or killing puppies.  (Unless dependency-based boot takes over
>   the world in time for squeeze and renders sequence information obsolete,
>   which would be lovely.)

I think this really needs to be resolved by deprecating the sequence-based
init approach entirely.  Or getting rid of file-rc, which is the fly in the
ointment any time maintainer scripts try to fix up init script sequence bugs
currently.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Standardizing use of kernel hook scripts

2009-04-01 Thread Tyler MacDonald
Darren Salt  wrote:
> > On Wed, Apr 01 2009, Frans Pop wrote:
> [make-kpkg]
> >> But is anyone still using it? Is there any current reason to support it

Well, there's still some kernel options that are immutable and
multiple choice. And there's always people that want to optimize. Out of
laziness (or maybe having better things to do? ) my current setups aren't
make-kpkg'ed, but it would depress me if, after using make-kpkg for years
and years, I wanted to use it again one day and found that it didn't work
anymore.

Cheers,
Tyler


-- 
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

2009-04-01 Thread Steve Langasek
On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
> I don't like this idea of RUN=yes variables in /etc/default.

> 1.) There is already a documented interface, how to disable a service (i.e.
> renaming the S?? symlinks for that runlevel to K??). Adding another layer to 
> do
> this is just confusing and inconsistent.
> There are tools like sysv-rc-conf which can handle that for you. Enabling a
> service is then as easy as sysv-rc-conf $service on|off

Hmm, sysv-rc-conf is a new one to me.  I don't care much for the aesthetics
of it (I think the author was too successful at capturing the IRIX/Red Hat
look'n'feel), but it does seem to do most of what's needed.

Both the name and the design are specific to sysv-rc, though.

rcconf looks more promising on those two points, but because it limits
itself to a whiptail interface it also falls short of being a full runlevel
editor, only allowing across-the-board enabling/disabling of services.  It
also seems to have some implementation bugs (an 'rcconf --list' here is
missing some services).

> Imho the only sane option is, to get rid of those RUN_ variables as much as
> possible and advertise tools like sysv-rc-conf more (or even install them by
> default).

I think "like" is the key word; I don't think either sysv-rc-conf or rcconf
in present form are suitable to be "the" runlevel editor for Debian.

> There are indeed services though, which should *not* be started by default, as
> e.g. they need to be configured first. But instead of inventing such a RUN_
> variable, the init script could directly check if its prerequisites are given
> and only start in that case. It then can also output a more sane error 
> message,
> telling the user what it is missing and how he can change that.

I agree wholeheartedly.

On Wed, Apr 01, 2009 at 08:56:43PM +0200, Patrick Schoenfeld wrote:
> On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
> > I don't like this idea of RUN=yes variables in /etc/default.

> > 1.) There is already a documented interface, how to disable a service (i.e.
> > renaming the S?? symlinks for that runlevel to K??). Adding another layer 
> > to do
> > this is just confusing and inconsistent.
> > There are tools like sysv-rc-conf which can handle that for you. Enabling a
> > service is then as easy as sysv-rc-conf $service on|off

> yes, that is true. This concept is however limited in so far that you
> cannot decide before installing a certain service, weither it starts
> after installation. Which is important if you want to avoid running
> wrong/half configured services in your network. Basically the approach
> is just to give some more possible choices to the users.

All packages should ship with reasonable (--> secure) defaults.  Giving
users more choices is not an appropriate substitute; and if we have secure
defaults, giving users more choices should be lower priority.

That said, if the runlevel editor is appropriately integrated with the
system, it doesn't have to limit itself to waiting for the service to be
installed before setting a policy for the service.  The editor could divert
update-rc.d (or otherwise integrate with it), to ensure both that the
runlevel editor always knows the intended policy for the service and that
any global policy set by the admin is respected at the time update-rc.d is
called (i.e., modifying the arguments before passing them to the diverted
update-rc.d).

> > 2.) It makes the init script useless.

> That is definitely not true. The init script still stays a common known
> interface to control a given service. The idea just adds another layer
> of control.

It conflates service starting by the admin with service starting via the
runlevel policy.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



ITH: xournal

2009-04-01 Thread Carlo Segre


Hi All:

I am intending to hijack xournal.  The current version has been NMUed for 
almost 1 year and the maintainer's (Mathieu Bouchard) email bounces. 
There is some urgency to this because the newest version of GTK in sid 
breaks the ability of xournal to read PDF files for annotation.  This can 
be fixed with a known patch.


I will be preparing an updated package for upload by the weekend unless I 
hear from the current maintainer before then.


Cheers,

Carlo

--
Carlo U. Segre -- Professor of Physics
Associate Dean for Special Projects, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: ITH: xournal

2009-04-01 Thread Charles Plessy
Le Wed, Apr 01, 2009 at 08:52:01PM -0500, Carlo Segre a écrit :
>
> I am intending to hijack xournal.  The current version has been NMUed for 
> almost 1 year and the maintainer's (Mathieu Bouchard) email bounces.  
> There is some urgency to this because the newest version of GTK in sid  
> breaks the ability of xournal to read PDF files for annotation.  This can 
> be fixed with a known patch.
>
> I will be preparing an updated package for upload by the weekend unless I 
> hear from the current maintainer before then.

Dear Carlo,

Thanks a lot for your action.

Any chance to hijack into an existing packaging team ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: ITH: xournal

2009-04-01 Thread Carlo Segre


Hi Charles:

On Thu, 2 Apr 2009, Charles Plessy wrote:


Thanks a lot for your action.

Any chance to hijack into an existing packaging team ?



I have no objection to comaintaining this, or even handing it off to a 
team.  I am not sure I want to join another team though as I am a bit 
overcommitted.  I wanted to take this on simply because I use it and it is 
in an unusable state on i386 right now.


Do you have a suggestion for an appropriate team?  Perhaps we can ask if 
they want to take this on?


Carlo

--
Carlo U. Segre -- Professor of Physics
Associate Dean for Special Projects, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org