Re: RFC: preventing accidental deletion of system directories

[Mike Hommey]

On Sat, Mar 22, 2008 at 03:50:32PM -0500, William Pitcock wrote:
> Hi,
> 
> On Sat, 2008-03-22 at 13:51 +0100, Adam Borowski wrote:
> > To get those Vistaesque questions, "alias rm='rm -i'" is surely not
> > worth a
> > package.  It's slightly larger in scope, but only slightly, as
> > removing
> > files as root means you mess with system directories, right? 
> 
> Yes, that's what I mean: what's wrong with making rm -i the default
> behaviour? We could do that by simply patching coreutils.

Or we could enforce most system directories to be mounted read-only, and
have dpkg remount then rw when it needs write access.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Service stopping in prerm considered harmful

[Steve Langasek]

On Sat, Mar 22, 2008 at 09:06:11PM -0700, Russ Allbery wrote:

> > For the nth time, I have a package that dpkg is unable to remove because
> > it tries to stop a service that either is already stopped (I didn't want
> > it) or couldn't start at all. In the former case, the fix seems simple:
> > start the service and remove the package. But sometimes starting the
> > service may have undesirable outcomes on the system, or the stop action
> > will fail in some way.

> > In either case, when you can't get a successful stop action for the
> > service init.d script, the package is impossible to remove without human
> > action, and not a simple one, because you need to be able to hack the
> > maintainer scripts or the init.d script.

> > Shouldn't the maintainer script actually ensure that the service is not
> > running, instead of just triggering the stop action and checking its
> > exit code? Something like (it's pseudo-code, because the status action
> > of init.d scripts prints text, it doesn't seem to give machine-friendly
> > data):

> I think the right solution to this is to require that the stop action not
> fail when the daemon already isn't running.  LSB requires this of init
> scripts.  I think we should as well.

Policy 9.3.2 says:

 The `init.d' scripts must ensure that they will behave sensibly if
 invoked with `start' when the service is already running, or with
 `stop' when it isn't, and that they don't kill unfortunately-named
 user processes.  The best way to achieve this is usually to use
 `start-stop-daemon'.

So since it's not sensible to return a non-zero exit code when "stop" is
called for an already-stopped service, this is already a severity: serious
policy violation. ;)

We can be more explicit about what it means to be "sensible", of course, but
I don't see how anyone would argue that throwing an error when the service
is already stopped would be ok.

> There may already be an open Policy bug about this, along with the several
> bugs that say that we should follow LSB in general.

Garrr, the LSB init script spec specifies requirements for LSB
*applications*, not for LSB platforms.  By all means, if there are gaps in
our init script policy we should resolve them - but that does *not* mean we
should blindly ratify the LSB policy on init scripts.  (Bug #208010 seems to
include a pretty thorough discussion of the problems with a wholesale
adoption of LSB init script rules.)

Cheers,
-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#279983: Now I am Fully Equipped

[Gunnar Hannukainen]

Have a rockin’ good time every night all night long with this.

http://www.decomitsom.com/
Measure Up To Your Future



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Service stopping in prerm considered harmful

[Alexander Wirt]

Pierre THIERRY schrieb am Sunday, den 23. March 2008:

> For the nth time, I have a package that dpkg is unable to remove because
> it tries to stop a service that either is already stopped (I didn't want
> it) or couldn't start at all. In the former case, the fix seems simple:
> start the service and remove the package. But sometimes starting the
> service may have undesirable outcomes on the system, or the stop action
> will fail in some way.
> 
> In either case, when you can't get a successful stop action for the
> service init.d script, the package is impossible to remove without human
> action, and not a simple one, because you need to be able to hack the
> maintainer scripts or the init.d script.
> 
> Shouldn't the maintainer script actually ensure that the service is not
> running, instead of just triggering the stop action and checking its
> exit code? Something like (it's pseudo-code, because the status action
> of init.d scripts prints text, it doesn't seem to give machine-friendly
> data):
> 
> 
> # if it's running, stop it
> if(status(service) == running) {
>   stop(service);
> }
> # if now it's still running, something's wrong
> if(status(service) == running) {
>   exit 1;
> }
> # proceed...
> 
There is a small trick with dh_installinit that can be used. dh_installinit
supports an errorhandler. If called like: 

dh_installinit -i --error-handler=init_failed --init-script=amavis -- defaults 
19 21

it generates the following debhelper code for prerm and postinst:
...
invoke-rc.d amavis stop || init_failed 

All you need then is a small function like in your postinst: 

init_failed () 
{
echo "WARNING: Starting amavisd-new failed. Please check your
configuration."
}


This works fine for me and removes the annoying default behaviour of
dh_installinit. 

Alex


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#472048: libmtp7 shouldn't depend on udev

[Rafael Laboissiere]

[I am moving this discussion into debian-devel, in order to get advise from
the other developers. Please, respect the M-F-T header.]

The discussion below is about Bug#472048.  I would like to know from people
using libmtp and its main reverse-dependencies (gnomad2, amarok, and
rhythmbox) whether it would be okay to change the Depends on udev to
Suggests, as proposed by the bug submitter.

* Adrian Bunk <[EMAIL PROTECTED]> [2008-03-23 01:03]:

> On Sat, Mar 22, 2008 at 11:39:12PM +0100, Rafael Laboissiere wrote:
> > * Adrian Bunk <[EMAIL PROTECTED]> [2008-03-21 20:51]:
> > 
> > > Package: libmtp7
> > > Version: 0.2.6.1-1
> > > Severity: normal
> > > 
> > > The dependency of libmtp7 on udev implies that installing
> > > audacious-plugins-extra would pull udev which I definitely
> > > do not want.
> > 
> > Would downgrading Depends to Recommends be okay?
> 
> With Debian now defaulting to treat Recommends like dependencies I'm not 
> really happy about this,
> 
> Perhaps a Suggests?
> 
> Most people anyway use udev so it shouldn't matter for them, and for 
> people like me who do not use udev and get libmtp7 through a dependency 
> that would be the best solution.
> 
> > Rafael
> 
> cu
> Adrian
> 
 
-- 
Rafael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: preventing accidental deletion of system directories

[Oohara Yuuma]

On Sat, 22 Mar 2008 22:16:12 +1300,
Francois Marier <[EMAIL PROTECTED]> wrote:
> - how to get this script to be picked up before 'rm' in the PATH (including
>   when using sudo) or whether it should be an alias in all of the shell
>   global config files (like /etc/bash.bashrc)

Call the script directly.

> - where to find a good list of directories which should never be deleted

This should be configurable by the user.

> - how to effectively disable it if one really wants to delete a system dir
>   (for an alias, '\rm' does the trick, for a command in the path, maybe an
>   environment variable?)

Call rm directly.

> - ways to detect directories expressed like  "../../../usr/lib/../../usr/bin"

realpath in Cwd.pm may be what you want.

> - any other comments/suggestions you may have about the idea or the script

The script should handle options of rm rather than assume all arguments
are file names.  I want to do rm -r some_dir.

-- 
Oohara Yuuma <[EMAIL PROTECTED]>

If we know when, can we do it right?
--- TAITO "Ray Crisis"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#472048: libmtp7 shouldn't depend on udev

[Romain Beauxis]

Le Sunday 23 March 2008 10:27:00 Rafael Laboissiere, vous avez écrit :
> [I am moving this discussion into debian-devel, in order to get advise from
> the other developers. Please, respect the M-F-T header.]
>
> The discussion below is about Bug#472048.  I would like to know from people
> using libmtp and its main reverse-dependencies (gnomad2, amarok, and
> rhythmbox) whether it would be okay to change the Depends on udev to
> Suggests, as proposed by the bug submitter.

Recommends seems much better to me, unless you have a general reason for using 
Suggests.

If the submitter wants to install without udev, then Recommends gives him this 
possibility, while most users will still have a full install.


Romain
-- 
We should really love each other
In peace and harmony 
Instead, instead, we're fussing and fighting
Like we ain't supposed to be, tell me why

Re: Bug#472048: libmtp7 shouldn't depend on udev

[Rafael Laboissiere]

* Romain Beauxis <[EMAIL PROTECTED]> [2008-03-23 12:30]:

> Recommends seems much better to me, unless you have a general reason for 
> using 
> Suggests.
> 
> If the submitter wants to install without udev, then Recommends gives him 
> this 
> possibility, while most users will still have a full install.

Thanks, this is exactly what I think too.  Adrian Bunk, the bug submitter,
does not agree though.  Let us gather more opinions here and then we will
take the final decision.
 
-- 
Rafael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Simple bug left unsolved

[Frans Pop]

On Sunday 23 March 2008, you wrote:
> The "installation-reports"-package has about 1.500 bug reports. It is
> A LOT...

True.

> Maybe one reason is that even the simplest bugs are just left unsolved.

No. It is because the Debian Installer team is really quite small. The 
amount of work that is done by that small team is actually quite amazing.

We do continuously request help with this. See for example the release 
announcement for D-I Beta1.

> A friend of mine reported a bug (#468779) and informed about a simple
> way to solve it. The reply from the maintainer was that it was
> complicated so do something about.

The reply was not that it was too complicated, but that it was outside the 
scope of the installer team.
The issue was that a particular piece of hardware was not supported by the 
current installer. As the installer team does not build its own kernel, but 
merely repackages the general Debian kernels, we just cannot add specific 
drivers to the installer.

> A few days later we solved it for ourselves in 20 minutes. It was very
> easy -- even for such amateurs like us.

Of course. For a user who is relatively skilled in linux it is generally not 
that hard to compile a particular kernel module, copy it into the installer 
environment manually and make things work that way.
However, that does not mean that we can include it as easily in official 
builds. It would be nice if you could appreciate that distinction.

> This specific bug report is about a new Intel network adapter. I would
> expect A LOT more of innocent users to run into the same problem soon.
> They may reject Debian for that reason.

That is why we'll be switching to a new kernel soon, as explained in my 
initial reply to the BR. I do hope that that that will indeed solve your 
issue.

> Something should be done to have at least simple bugs resolved fast.

But this is not as simple as it may seem to you. We actually do solve most 
of the "simple" bug reports almost immediately, and even a lot of the not 
so simple ones.
However, we can only do so much as our spare time allows.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: RFC: preventing accidental deletion of system directories

[Bernhard R. Link]

* William Pitcock <[EMAIL PROTECTED]> [080322 21:49]:
> Yes, that's what I mean: what's wrong with making rm -i the default
> behaviour? We could do that by simply patching coreutils.

The biggest problem with rm -i is that there is no switch reverting it.
There is -f, but that means deleting everything, and does not switch
back to the current default, which is to make possible dangerous things
interactive (deleting ro, ...) while normal deletions are not made
harder.

-i by default is a very bad decision, as -i asks even for single file
deletions, so people are trained to answer y every time they do
something, so will also answer y without reading the message when they
do something. (or to always do rm -f)

Switching to a bad default without adding a way to revert to a sane
default just means everyone will hate you.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: preventing accidental deletion of system directories

[Steinar H. Gunderson]

On Sat, Mar 22, 2008 at 09:14:57AM -0400, Roberto C. Sánchez wrote:
> Of course, knowing that I do such things on occasion, I have aliased
> 'rm' to 'rm -i', so it will ask unless I pass '-f' along.

Speaking from experience, this kind of behavior makes people use "rm -f" all
the time, which means that you won't get a warning when you _really_ want it
(for instance, a read-only file).

Security by dialog boxes: It's not the way to go.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Simple bug left unsolved

[Kurt Petersen]

Hi

The "installation-reports"-package has about 1.500 bug reports. It is
A LOT...

Maybe one reason is that even the simplest bugs are just left unsolved. 

A friend of mine reported a bug (#468779) and informed about a simple
way to solve it. The reply from the maintainer was that it was
complicated so do something about.

A few days later we solved it for ourselves in 20 minutes. It was very
easy -- even for such amateurs like us. 

This specific bug report is about a new Intel network adapter. I would
expect A LOT more of innocent users to run into the same problem soon.
They may reject Debian for that reason.

Something should be done to have at least simple bugs resolved fast. 

Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: preventing accidental deletion of system directories

[Andrew M.A. Cater]

On Sat, Mar 22, 2008 at 03:50:32PM -0500, William Pitcock wrote:
> Hi,
> 
> On Sat, 2008-03-22 at 13:51 +0100, Adam Borowski wrote:
> > To get those Vistaesque questions, "alias rm='rm -i'" is surely not
> > worth a
> > package.  It's slightly larger in scope, but only slightly, as
> > removing
> > files as root means you mess with system directories, right? 
> 
> Yes, that's what I mean: what's wrong with making rm -i the default
> behaviour? We could do that by simply patching coreutils.
> 
> William

Go away and learn: there have been whole flamewars on this subject :)

Red Hat (if I remember correctly) used to alias rm automatically to rm 
-i . The savvy users used to unalias rm before using it.

If, when you run as root, rm always asks - you get used to it. You move 
to a different system where there is no alias or someone has turned it 
off - and suddenly rm MEANS rm with no breathing space.

Much better, in my opinion which is shared by some others, to _always_ 
have rm as rm. There's nothing to stop the cautious explicitly calling 
rm as rm -i anyway - but when you need to delete large numbers of files,
rm -i is a _real_ nuisance.

AndyC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Simple bug left unsolved

[Neil Williams]

On Sun, 23 Mar 2008 14:36:04 +0100
Kurt Petersen <[EMAIL PROTECTED]> wrote:

> The "installation-reports"-package has about 1.500 bug reports. It is
> A LOT...

Including archived bugs, there are also nearly 2,000 resolved bugs
which is also a lot.

> Something should be done to have at least simple bugs resolved fast. 

Well, maybe you could help with d-i rather than just point out the
negative?

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgp47Yva2wtZc.pgp
Description: PGP signature

Re: RFC: preventing accidental deletion of system directories

[Lesley Binks]

On 23/03/2008, Andrew M.A. Cater <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 22, 2008 at 03:50:32PM -0500, William Pitcock wrote:
>  > Hi,
>  >
>  > On Sat, 2008-03-22 at 13:51 +0100, Adam Borowski wrote:
>  > > To get those Vistaesque questions, "alias rm='rm -i'" is surely not
>  > > worth a
>  > > package.  It's slightly larger in scope, but only slightly, as
>  > > removing
>  > > files as root means you mess with system directories, right?
>  >
>  > Yes, that's what I mean: what's wrong with making rm -i the default
>  > behaviour? We could do that by simply patching coreutils.
>  >
>  > William
>
>  Go away and learn: there have been whole flamewars on this subject :)
>
>  Red Hat (if I remember correctly) used to alias rm automatically to rm
>  -i . The savvy users used to unalias rm before using it.
>
>  If, when you run as root, rm always asks - you get used to it. You move
>  to a different system where there is no alias or someone has turned it
>  off - and suddenly rm MEANS rm with no breathing space.
>
>  Much better, in my opinion which is shared by some others, to _always_
>  have rm as rm. There's nothing to stop the cautious explicitly calling
>  rm as rm -i anyway - but when you need to delete large numbers of files,
>  rm -i is a _real_ nuisance.
>
>  AndyC
>
>

I've made my mistakes with rm - and tried to learn from them.  I see
no reason why we should default to rm -i .  The alias is easy enough
to set up if one needs it and one can still royally muck things up
with rm -rf or \rm.

I agree that it could create problems for those used to rm -i when
they encounter a pure rm machine but I think it is therefore better
that people learn to alias commands and the limitations and get
arounds of that alisasing.

In *nix based systems rm has always meant rm - deleting files does just that.
The KDE Desktop provides the option to keep this functionality or have
temporary trash can on the desktop.  However, you don't get the option
of a trashcan on the command line - unless you want to write your own
script for it.

Regards

Lesley


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Service stopping in prerm considered harmful

[Russ Allbery]

Alexander Wirt <[EMAIL PROTECTED]> writes:

> There is a small trick with dh_installinit that can be used. dh_installinit
> supports an errorhandler. If called like: 
>
> dh_installinit -i --error-handler=init_failed --init-script=amavis -- 
> defaults 19 21
>
> it generates the following debhelper code for prerm and postinst:
> ...
> invoke-rc.d amavis stop || init_failed 
>
> All you need then is a small function like in your postinst: 

But if you can modify the postinst, you could just fix the init script
(Although you may still need this for a transition.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: preventing accidental deletion of system directories

[Darren Salt]

I demand that Andrew M.A. Cater may or may not have written...

> On Sat, Mar 22, 2008 at 05:12:50AM -0500, William Pitcock wrote:
[snip]
>> Maybe asking "Are you sure you want to do this", but outright refusing
>> to do something seems quite ridiculous to me.

> Of course, knowing that I do such things on occasion, I have aliased 'rm'
> to 'rm -i', so it will ask unless I pass '-f' along.

You have another option, "\rm", which will always give you unaliased "rm".

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   http://www.youmustbejoking.demon.co.uk/progs.packages.html>

As easy as 3.14159265358979323846264338327950288419716...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Service stopping in prerm considered harmful

[Alexander Wirt]

Russ Allbery schrieb am Sunday, den 23. March 2008:

> Alexander Wirt <[EMAIL PROTECTED]> writes:
> 
> > There is a small trick with dh_installinit that can be used. dh_installinit
> > supports an errorhandler. If called like: 
> >
> > dh_installinit -i --error-handler=init_failed --init-script=amavis -- 
> > defaults 19 21
> >
> > it generates the following debhelper code for prerm and postinst:
> > ...
> > invoke-rc.d amavis stop || init_failed 
> >
> > All you need then is a small function like in your postinst: 
> 
> But if you can modify the postinst, you could just fix the init script
> (Although you may still need this for a transition.)
True, but this does not only apply to stopping the initscript but also to
package installations that stop because the daemon is unconfigured or if
something has to be changed in the configs for a new version. I find it
really annoying if a daemon that can't be started stops my installation
process. 

Alex
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: preventing accidental deletion of system directories

[Milan P. Stanic]

On Sun, Mar 23, 2008 at 04:55:52PM +, Lesley Binks wrote:
> In *nix based systems rm has always meant rm - deleting files does just that.
> The KDE Desktop provides the option to keep this functionality or have
> temporary trash can on the desktop.  However, you don't get the option
> of a trashcan on the command line - unless you want to write your own
> script for it.

There were some libraries which can be "activated" with LD_PRELOAD.
Two of them:
http://homepage.esoterica.pt/~nx0yew/delsafe/
http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/libtrash-0.2/readme.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What to do with old configs

[Alexander GQ Gerasiov]

На Sat, 22 Mar 2008 20:09:47 +0100
Adeodato Simó <[EMAIL PROTECTED]> записано:

> * Alexander GQ Gerasiov [Sat, 22 Mar 2008 22:04:38 +0300]:
> 
> > Hi there.
> 
> Hello Alexander. Check .

Hello again. I found problem with those scripts:

$ export CONFFILE=/etc/xneur/fr/proto
$ dpkg-query -W -f='${Conffiles}' $PKGNAME | sed -n -e "\\' $CONFFILE'{s/ 
obsolete$//;s/.* //p}"
18a3b3b86bf3e5b0ca94407472466764
ae9d7e984350e929fd6820bf46ea6efe

That's because I have /etc/xneur/fr/proto and /etc/xneur/fr/proto3

So I suppose it would be better to add space after $CONFFILE in sed expression:
dpkg-query -W -f='${Conffiles}' $PKGNAME | sed -n -e "\\' $CONFFILE '{s/ 
obsolete$//;s/.* //p}"



-- 
Best regards,
 Alexander GQ Gerasiov

 Contacts:
 e-mail:[EMAIL PROTECTED] Jabber:  [EMAIL PROTECTED]
 Homepage:  http://gq.net.ru ICQ: 7272757
 PGP fingerprint: 0628 ACC7 291A D4AA 6D7D  79B8 0641 D82A E3E3 CE1D

Re: where to register TeX related software with doc-base?

[Aaron M. Ucko]

Ralf Treinen <[EMAIL PROTECTED]> writes:

> Sorry if this has been answered before, but looking at section 2.3.3 of
> the doc-base manual (version 0.8.10) I cannot find a section TeX. If
> memory serves me right we used to have a section "tex", at least I
> used to register the docs of some my TeX-related packages there :-)
> Has this section been removed on purpose? If yes, where should
> TeX-related documenation go now?

Good question; with the currently declared hierarchy, I'd suggest
Programming/TeX, but I acknowledge that that's still not entirely
intuitive.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Service stopping in prerm considered harmful

[Steve Greenland]

On 23-Mar-08, 03:05 (CDT), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> We can be more explicit about what it means to be "sensible", of course, but
> I don't see how anyone would argue that throwing an error when the service
> is already stopped would be ok.

I've had bug reports closed with *exactly* that argument (although it's
been years). The contention is that since the init script didn't take
the action, it's an error. So perhaps more specifity is required.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .desktop files for x-www-browser and x-terminal-emulator

[Josselin Mouette]

On ven, 2008-03-21 at 22:21 +0800, Enrico Zini wrote:
> Hello,
> 
> It has been brought to my attention that we don't have .desktop files
> to launch what is the standard Debian way to launch web browsers and
> terminal emulators: how come?

Could you please care to explain what they would be useful for?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

Re: Bits from the armel porters

[Martin Zobel-Helas]

Hi, 

On Fri Mar 07, 2008 at 12:31:23 +0100, Marc 'HE' Brockschmidt wrote:
> Riku Voipio <[EMAIL PROTECTED]> writes:
> > For the second point, armel must keep up-to-date and must not have
> > build failures affecting armel. The current buildds are struggling to
> > keep upto date, so 4 new Thecus machines have now been ordered to be set
> > up as normal/testing/security buildds and porter machines in the near
> > future.
> 
> The machines have now arrived. After the fitting disks and memory
> modules have been delivered, these boxes will get installed and shipped
> to their final hosting locations. This should take about one or two
> weeks. After that, DSA can do the debian.org setup and leave them to the
> buildd admins.

Debian Developer accessible machine in place now. For details see:
http://lists.debian.org/debian-infrastructure-announce/2008/03/msg3.html


Greetings
Martin
-- 
 Martin Zobel-Helas <[EMAIL PROTECTED]>  |  Debian Release Team Member
 Debian & GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#472384: ITP: libsort-fields-perl -- Sort lines containing delimited fields

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <[EMAIL PROTECTED]>

* Package name: libsort-fields-perl
  Version : 0.90
  Upstream Author : Joseph Hall <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Sort-Fields/
* License : Public Domain[1]
  Programming Lang: Perl
  Description : Sort lines containing delimited fields

Sort::Fields provides a general purpose technique for efficiently
sorting lists of lines that contain data separated into fields.

[1] Statement of release to public domain attached.
--- Begin Message ---
I'm not interested in uploading a new version with a proper copyright
statement right now. Therefore considering the age of the code and so
on:

I hereby declare Sort::Fields to be in the public domain.

Hope that helps.  Feel free to publish this statement where necessary.

  -joseph

On Sun, Mar 23, 2008 at 11:46 AM, Dominic Hargreaves <[EMAIL PROTECTED]> wrote:
> Hello,
>
>  I'm interested in packaging Sort::Fields for Debian, but since there is
>  no copyright statement or licence attached to the code, I'm unable to do
>  this at present. Could you possibly add one which is DFSG-compliant[1]
>  (of course the "Perl licence" is generally used for CPAN modules)

--- End Message ---

Re: table view wnpp page now on wnpp.debian.net

[Sebastian Pipping]

Tim Cutts wrote:
Still not free, but the following web site probably helps you do what 
you want:


http://wellstyled.com/tools/colorscheme2/index-en.html


Very cool tool. I guess they changed the license,
it reads Creative Commons BY-NC-SA 2.0 now.


Click on its "triad" button, and it automatically picks three 
contrasting colours which work in all forms of colour blindness 
(including the extremely rare case of totally monochromatic vision).


I applied a new set of colors, selected using the Color schemes
generator 2. Please let me know how the new set works.



Sebastian


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: table view wnpp page now on wnpp.debian.net

[Karl Goetz]

On Mon, 2008-03-24 at 01:41 +0100, Sebastian Pipping wrote:
> Tim Cutts wrote:
> > Still not free, but the following web site probably helps you do what 
> > you want:
> > 
> > http://wellstyled.com/tools/colorscheme2/index-en.html
> 
> Very cool tool. I guess they changed the license,
> it reads Creative Commons BY-NC-SA 2.0 now.
> 

-NC is not free :)

> 
> > Click on its "triad" button, and it automatically picks three 
> > contrasting colours which work in all forms of colour blindness 
> > (including the extremely rare case of totally monochromatic vision).
> 
> I applied a new set of colors, selected using the Color schemes
> generator 2. Please let me know how the new set works.
> 

The new set is very clear, thank you.
kk

> 
> 
> Sebastian
> 
> 
-- 
Karl Goetz,
Debian user / Ubuntu contributor / gNewSense contributor
http://www.kgoetz.id.au


signature.asc
Description: This is a digitally signed message part