Re: Aaargh!

[Chris Cheney]

On Fri, Aug 01, 2003 at 11:36:58PM -0400, Nathanael Nerode wrote:
> I feel a little like screaming.
-snip-

Ouch I didn't realize it was that bad :\

The list of problems I currently know about for KDE are:

1. ia64 gcc 3.3 bug
2. s390 glibc kernel header ptrace.h violates ISO C [0]
3. xfree86 4.2.1-10 needed for mips/mipsel

On the bright side maybe we will be able to get KDE 3.2 in before the
sarge release then. ;)

Chris

[0] gcc 3.3 is more anal about ISO conformance now, I probably need to
open an RC bug on glibc about this soon. (affects kdebase)

Re: Why is sbcl getting installed during buildd builds?

[Chris Cheney]

I think we determined on #debian-devel that the problem is that the
alpha, powerpc, and sparc buildds are broken and need manual
intervention to remove the sbcl package.

Chris

Re: Why is sbcl getting installed during buildd builds?

[Steve Langasek]

On Fri, Aug 01, 2003 at 11:37:14PM -0500, Chris Cheney wrote:
> I noticed that several of my packages are failing to build on quite a
> few buildds. This is due to the sbcl maintainer uploading a broken
> version of sbcl today (afaict). However, my package doesn't even depend
> on sbcl at all, I use clean chroots to build my packages locally for
> i386 and it is not installed in it.

> Why is this package being pulled in?!

> Examples:

> kdeadmin  - alpha, powerpc
> kdegraphics   - alpha, powerpc, sparc

As noted, the logs don't show the package is being pulled in -- rather,
they show that the package is already there, but in an unconfigured
state that dpkg can't resolve.  Looks like the chroots are going to need
some manual cleaning...

-- 
Steve Langasek
postmodern programmer


pgpJ9MgrEmFR4.pgp
Description: PGP signature

Why is sbcl getting installed during buildd builds?

[Chris Cheney]

I noticed that several of my packages are failing to build on quite a
few buildds. This is due to the sbcl maintainer uploading a broken
version of sbcl today (afaict). However, my package doesn't even depend
on sbcl at all, I use clean chroots to build my packages locally for
i386 and it is not installed in it.

Why is this package being pulled in?!


Examples:

kdeadmin- alpha, powerpc
kdegraphics - alpha, powerpc, sparc

Thanks,

Chris Cheney

Re: CUPS should be the default print service in Debian/Sarge

[Marc Wilson]

On Thu, Jul 31, 2003 at 02:52:04PM +0100, Ross Burton wrote:
> As a random reply...



> However, I am biased, as I package the GNOME CUPS packages... :)

And as a random comment, it's really sad that a printing system would have
any sort of dependency whatsoever on Gnome (or KDE, for that matter).

Hopefully it's only UI nonsense (although I freely admit that I'm not about
to install it to find out).

-- 
 Marc Wilson | Ya'll hear about the geometer who went to the beach
 [EMAIL PROTECTED] | to catch some rays and became a tangent ?


pgplZ3BBM9ypM.pgp
Description: PGP signature

Re: [PROPOSAL] Debian Release Plan

[Nathanael Nerode]

Matt Zimmerman said:
> I  do not think  that version  number milestones  are important  for a
> release.   I   think  that  having   a  well-integrated,  high-quality
> distribution is  important for  a release, and  this is not  so easily
> monitored.

Releasing with KDE 2.2, GNOME 1, and a default of GCC 2.95 would be just 
plain pathetic.  So sometimes, version number milestones *are* important 
for a release.  Admittedly, most of the time they are not such a big 
deal.

I guess what really matters here is having versions which aren't 
ludicrously out of date.  Specifically, if something was released 
upstream over a year ago, and Debian releases with an even *older*
version (without good reason), that's not good at all.

-- 
Nathanael Nerode  
http://home.twcny.rr.com/nerode/neroden/fdl.html

Aaargh!

[Nathanael Nerode]

I feel a little like screaming.

A few days ago things looked good.  KDE had one RC bug open against it, 
and it seemed likely that it had been fixed by GCC upgrades.

Since then, the KDE maintainer decided to upload new KDE.  And hit 
a new bug in GCC (3.3) on ia64, which is fixed in GCC CVS but not in 
the current GCC upload.  The current GCC upload hasn't been built on 
m68k (it appears to have timed out).  Of course, why bother building it 
when a newer GCC is needed...

But for that matter, the current GCC (and presumably any updated 
version) apparently requires a new version of glibc to go into 
'testing'.  And the latest glibc needs a rebuild on SPARC.  Plus, it 
has at least 5 RC bugs, so who knows when it'll make it into testing.

So now it looks like KDE3 is a lot *further* from getting into sarge 
than it was last week.

I really don't know what can be done about this kind of thing, but it's 
frustrating.

-- 
Nathanael Nerode  
http://home.twcny.rr.com/nerode/neroden/fdl.html

Re: setuid/setgid binaries contained in the Debian repository.

[Bernd Eckenfels]

On Fri, Aug 01, 2003 at 09:19:46PM -0400, Joey Hess wrote:
> Bernd Eckenfels wrote:
> > Umm... you invent a scorewriter for removing the sgui games bit? And then
> > you add a sgid scoresetter? I dont think this makes mch sence.
> 
> You need to learn some more about security then. Small, simple and well
> defined programs are often more secure than large monoliths that have to
> deal with arbitrary user input. Especially if the monolith was written
> in 1993 and the helper program in 2003.

Well, I am fine with that. Although the game is still sgid, which is not
needed. Some other ways to check the programs integrity can be used.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Data loss: suggestions for handling

[Joey Hess]

Roland Mas wrote:
> key-value pairs.  One of the keys (okay, the only one normally) is
> "db-version", and the corresponding value is a version number with the
> same semantics as the one provided by dpkg for the ordering).  When I
> need to upgrade something, I go the following steps:
> 
> ,[ One upgrade chunk ]
> | Begin transaction
> | Do stuff
> | Check that stuff went fine (and raise an exception/abort if not)
> | Update the value for db-version
> | Commit transaction
> `
> 
> This is of course only executed if current db-version is less than
> targeted version.  So I have a series of upgrade chunks, arranged like
> this:
> 
> ,[ Upgrade script ]
> | $target version = 1.0
> | if (current-version < $target-version) {
> |Do the upgrade chunk for target=$target-version
> | }
> | 
> | $target version = 1.1
> | if (current-version < $target-version) {
> |Do the upgrade chunk for target=$target-version
> | }
> | 
> | $target version = 1.4
> | if (current-version < $target-version) {
> |Do the upgrade chunk for target=$target-version
> | }
> `
> 
>   The postinst script always runs this upgrade script.  So all the
> steps that were previously completed are not replayed, and you'll
> start at the first one that hasn't been successfully run yet. 

Heh, that's funny, this is exactly the approach I use for mooix database
upgrades. Even my code looks scarily similar to yours, although I don't
have transactons and just try to make it all idempotent instead.

-- 
see shy jo


pgpTcG55XlEMc.pgp
Description: PGP signature

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Scott James Remnant]

On Sat, 2003-08-02 at 03:38, Pierre THIERRY wrote:

> >> Tags: patch
> > You forgot to attach it :-)
> 
> Shit. And the BTS doesn't seem to have noticed the patch tag...
> 
You meant to put "tags 203588 patch", "thanks" and Bcc
[EMAIL PROTECTED], didn't you? :-)

> > Event-handling from cardmgr, hotplug, usbmgr, acpid, apmd etc. are
> > really useful to be able to be customised by power users.
> 
> I think I'm something like a power user, and I hate having to read and
> understand a script (being shell, perl or anything else) to customize a
> package to my needs.
> 
Then you're not what I'd consider a UNIX power user :-)

> And I love a well-documented configuration file, where I just have to
> change some paramters, without having to understand everything behing
> it. The power user might want to focus on its work, not on the
> custimozation of every signle package he installs...
> 
Then they probably don't care what happens when the power button is
pushed!

> > You've assumed they want the power button to *be* a power button, it's
> > entirely likely that they might want it to (for example) switch the
> > user into single user mode instead.
> 
> I didn't assume anything, and my version of the script just need th
> change ACTION=halt to ACTION=single to achieve this. And if the script
> is rewritten or modified to be just better, an apt-get upgrade won't
> erase all the customizations made by the sysadmin, because it is in a
> configuration file that have little reasons to change...
> 
How do I configure your script to restart apache when the power button
is pushed?

> > Shell scripts run by event daemons are the power-user's configuration
> > files. Leave them be.
> 
> They are a very bad manner to provide configuration files to the
> power-user, IMHO... And I still think this bug is an RC one.
> 
It's not an RC bug.  If shell scripts weren't allowed in /etc -- init.d
would be a bit of a problem :-)

Scott


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

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Sat, Aug 02, 2003 at 09:38:46AM +1000, Herbert Xu wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > nethack is the only game which comes to mind which does this, and I think it
> > should probably be changed to keep the saved game in the user's home
> > directory.  This was clearly done in order to try to prevent cheating, but
> > again, these days the player has root anyway.
> 
> If the player has root then why are discussing the possibility of the
> player cracking into the games group?

Because in that case I was talking about high scores, and in the other case
we are talking about one user compromising another.

-- 
 - mdz

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Pierre THIERRY]

>> Tags: patch
> You forgot to attach it :-)

Shit. And the BTS doesn't seem to have noticed the patch tag...

> Event-handling from cardmgr, hotplug, usbmgr, acpid, apmd etc. are
> really useful to be able to be customised by power users.

I think I'm something like a power user, and I hate having to read and
understand a script (being shell, perl or anything else) to customize a
package to my needs.

And I love a well-documented configuration file, where I just have to
change some paramters, without having to understand everything behing
it. The power user might want to focus on its work, not on the
custimozation of every signle package he installs...

> You've assumed they want the power button to *be* a power button, it's
> entirely likely that they might want it to (for example) switch the
> user into single user mode instead.

I didn't assume anything, and my version of the script just need th
change ACTION=halt to ACTION=single to achieve this. And if the script
is rewritten or modified to be just better, an apt-get upgrade won't
erase all the customizations made by the sysadmin, because it is in a
configuration file that have little reasons to change...

> Shell scripts run by event daemons are the power-user's configuration
> files. Leave them be.

They are a very bad manner to provide configuration files to the
power-user, IMHO... And I still think this bug is an RC one.

Technically,
le Moine Fou
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
diff -Nru acpid-1.0.2.old/debian/powerbtn.cfg acpid-1.0.2/debian/powerbtn.cfg
--- acpid-1.0.2.old/debian/powerbtn.cfg 1970-01-01 01:00:00.0 +0100
+++ acpid-1.0.2/debian/powerbtn.cfg 2003-08-02 03:34:53.0 +0200
@@ -0,0 +1,11 @@
+# Can be halt, reboot or single
+ACTION=halt
+
+# Time between SIGTERM and SIGKILL, see shutdown(8)
+INIT_WAIT=
+
+# When to shutdown.
+TIME=now
+
+# Message to send to all users.
+MESSAGE=
diff -Nru acpid-1.0.2.old/debian/powerbtn.sh acpid-1.0.2/debian/powerbtn.sh
--- acpid-1.0.2.old/debian/powerbtn.sh  2003-08-02 02:09:02.0 +0200
+++ acpid-1.0.2/debian/powerbtn.sh  2003-08-02 03:40:27.0 +0200
@@ -3,9 +3,40 @@
 # Initiates a shutdown when the power putton has been
 # pressed.
 
+CONFIG=/etc/acpi/powerbtn.cfg
+SDPID=/var/run/shutdown.pid
+SHUTDOWN=/sbin/shutdown
+
+if [ -f $SDPID ];then
+   $SHUTDOWN -c
+   exit;
+fi
+
+. $CONFIG
+
 if ps -Af | grep -q '[k]desktop' && test -f /usr/bin/dcop
 then
 dcop --all-users ksmserver ksmserver logout 0 2 0 && exit 0
 fi
 
-/sbin/init 0
+
+COMMAND=$SHUTDOWN
+
+case $ACTION in
+halt)
+   COMMAND="$COMMAND -h";;
+reboot)
+   COMMAND="$COMMAND -r";;
+single)
+   ;;
+esac
+
+case $INIT_WAIT in
+"")
+   COMMAND="$COMMAND -t $INIT_WAIT";;
+*)
+   ;;
+esac
+
+COMMAND="$COMMAND $TIME $MESSAGE"
+$COMMAND
diff -Nru acpid-1.0.2.old/debian/rules acpid-1.0.2/debian/rules
--- acpid-1.0.2.old/debian/rules2003-08-02 02:09:02.0 +0200
+++ acpid-1.0.2/debian/rules2003-08-02 03:31:20.0 +0200
@@ -39,8 +39,11 @@
install -p -o root -g root -m 644 debian/powerbtn \
debian/tmp/etc/acpi/events/powerbtn

+   install -p -o root -g root -m 644 debian/powerbtn.cfg \
+   debian/tmp/etc/acpi/powerbtn.cfg
+   
install -p -o root -g root -m 755 debian/powerbtn.sh \
-   debian/tmp/etc/acpi/powerbtn.sh
+   debian/tmp/usr/sbin/powerbtn.sh
 
install -p -o root -g root -m 644 acpid.8.gz \
debian/tmp/usr/share/man/man8


pgpBPLAGKaghM.pgp
Description: PGP signature

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Scott James Remnant]

On Sat, 2003-08-02 at 03:05, Pierre THIERRY wrote:

> Tags: patch
> 
You forgot to attach it :-)

> > I've edited it, and I'd bet I'm not the only one who has a
> > dog/cat/turtle/etc who keeps knocking the power button, resulting in a
> > change to scheduling a shutdown in 1 minutes time :)
> 
> I think a very good coded script should use a config file in /etc. But
> maybe it's a purist opinion... What do you think of the patch I
> porvide ? (I did not touch the dcop thing, as I don't understand it
> very well)
> 
Ah, more configuration...

Sit back and ask yourself, who's interested in what this script does?

Is it the average user?  Nope ... they're probably quite content with
the script exactly as it is.

It's the person who specially doesn't want their machine going down when
the power button is pushed.  You could add a configuration file, and
make this script all fancy reading it, but you're only going to ever
think of the needs of the average user who doesn't even care.

Event-handling from cardmgr, hotplug, usbmgr, acpid, apmd etc. are
really useful to be able to be customised by power users.

And precisely because it's power users doing the customisation, rather
than trying to second-guess what magic they want to do on the event, the
simplest and best form of configuration is a shell script -- that way
they can do whatever they want!

> And this script could even not be part of acpid, but maybe sysvinit, as
> it could be useful even without ACPI, just in replacement for halt, with
> more functionnalities. One could add something for Gnome, as IIRC, DCOP
> is part of KDE or Qt...
> 
You've assumed they want the power button to *be* a power button, it's
entirely likely that they might want it to (for example) switch the user
into single user mode instead.

Shell scripts run by event daemons are the power-user's configuration
files.  Leave them be.

Scott


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

Re: setuid/setgid binaries contained in the Debian repository.

[Darren Salt]

I demand that Herbert Xu may or may not have written...

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>> nethack is the only game which comes to mind which does this, and I think
>> it should probably be changed to keep the saved game in the user's home
>> directory.  This was clearly done in order to try to prevent cheating, but
>> again, these days the player has root anyway.

> If the player has root then why are discussing the possibility of the
> player cracking into the games group?

The machine could be running a network game server which is setgid games,
though it could equally well have its own uid and be run setuid.

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   I don't ask for much, just untold riches...

The basis of optimism is sheer terror.

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Pierre THIERRY]

Tags: patch

> I've edited it, and I'd bet I'm not the only one who has a
> dog/cat/turtle/etc who keeps knocking the power button, resulting in a
> change to scheduling a shutdown in 1 minutes time :)

I think a very good coded script should use a config file in /etc. But
maybe it's a purist opinion... What do you think of the patch I
porvide ? (I did not touch the dcop thing, as I don't understand it
very well)

And this script could even not be part of acpid, but maybe sysvinit, as
it could be useful even without ACPI, just in replacement for halt, with
more functionnalities. One could add something for Gnome, as IIRC, DCOP
is part of KDE or Qt...

Narrow-mindedly, ;-)
le Moine Fou
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


pgpEQ6WsEoxBn.pgp
Description: PGP signature

Re: Bug#203820: Incorrect expanding [] glob

[Michał Politowski]

On Sat,  2 Aug 2003 00:44:16 +0200, Artur R. Czechowski wrote:
> When LC_COLLATE is set to pl_PL [] glob does not work correctly:
>
> [EMAIL PROTECTED]:/tmp/bash-test$ echo $LC_COLLATE
> pl_PL
> [EMAIL PROTECTED]:/tmp/bash-test$ touch a b C c D e F G h
> [EMAIL PROTECTED]:/tmp/bash-test$ echo [A-Z]
> b c C D e F G h
> [EMAIL PROTECTED]:/tmp/bash-test$ export LC_COLLATE=C
> [EMAIL PROTECTED]:/tmp/bash-test$ echo [A-Z]
> C D F G

You didn't specify what would you consider "working correctly"
so I assume you expect LC_COLLATE not to affect what a range expression
matches.
SUSv3 says:
7. In the POSIX locale, a range expression represents the set of collating
   elements that fall between two elements in the collation sequence, 
inclusive.
   In other locales, a range expression has unspecified behavior: strictly
   conforming applications shall not rely on whether the range expression is
   valid, or on the set of collating elements matched.

I would say matching according to the specified collating order _is_ reasonable.

> I am not sure that this is really bash error, that's why I Cc-ed it to
> [EMAIL PROTECTED]

Another question is if the collating order for pl_PL placing lowercase letters
before corresponding uppercase letters is correct. I'm not sure.
Actually I'd do the opposite but it's not based on reading of any actual 
standards.

-- 
Michał Politowski -- [EMAIL PROTECTED]
Warning: this is a memetically modified message


pgpd92zRBduEj.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Bernd Eckenfels wrote:
> Umm... you invent a scorewriter for removing the sgui games bit? And then
> you add a sgid scoresetter? I dont think this makes mch sence.

You need to learn some more about security then. Small, simple and well
defined programs are often more secure than large monoliths that have to
deal with arbitrary user input. Especially if the monolith was written
in 1993 and the helper program in 2003.

-- 
see shy jo


pgpCuLoGzTIOC.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Bernd Eckenfels wrote:
> Looking at this statistic, it is clearly visible that most of the exploits
> are game related,

Only because Steve Kemp is doing some good work on auditing our games.
I suspect he would have just as much luck finding security holes in some
other areas.

> Yes, but I think the eyes should concentrate on non sgid-games first.
> Because this might be a realy BIG junk of UGLYNESS one will find there :)

I understand that if you want to help with the auditing effort,
information is here:

http://www.steve.org.uk/Debian/


> > +
> > +  Since setuid and setgid programs are often a security rick,
> > +  you should not add any new setuid or setgid programs to
> > +  the distribution before this has been discussed on the
> > +  debian-security mailing list and a consensus about
> > +  doing that has been reached.
> > +
> 
> Do we want to make an sgui games exception here?

No.

-- 
see shy jo


pgpXuNzo7W6KO.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Manoj Srivastava wrote:
>   This seems like a good practice kind of recommendation, not an
>  requirement, and as such, may be better suited to be included
>  in developers reference rather than policy, don't you think?

I agree that policy can't force developers to do that, but policy is
already full of such recommendatons:

1.
 You should not specify a `Pre-Depends' entry for a package before this
 has been discussed on the `debian-devel' mailing list and a consensus
 about doing that has been reached.

2.
 You must not tag any packages `essential' before this has been
 discussed on the `debian-devel' mailing list and a consensus about
 doing that has been reached.

3.
 You should not tag any packages as belonging to a task before this has
 been discussed on the _debian-devel_ mailing list and a consensus
 about doing that has been reached.

4.
 This will use a default sequence number of 20.  If it does not matter
 when or in which order the `init.d' script is run, use this default.
 If it does, then you should talk to the maintainer of the `sysvinit'
 package or post to `debian-devel', and they will help you choose a
 number.

5.
 If this case happens, one of the programs
 must be renamed.  The maintainers should report this to the
 `debian-devel' mailing list and try to find a consensus about which
 program will have to be renamed.  If a consensus cannot be reached,
 _both_ programs must be renamed.

6.   (on perms and users)
 If necessary you may deviate from the details below.  However, if you do
 so you must make sure that what is done is secure and you should try
 to be as consistent as possible with the rest of the system.  You
 should probably also discuss it on `debian-devel' first.

7.
 In this case you should choose an
 appropriate user or group name, discussing this on `debian-devel' and
 checking with the `base-passwd' maintainer that it is unique and that
 they do not wish you to use a statically allocated id instead.

8.
 It is often worthwhile contacting such
 authors diplomatically to ask them to modify their license terms.
 However, this can be a politically difficult thing to do and you
 should ask for advice on the `debian-legal' mailing list first, as
 explained below.

9.
 When in doubt about a copyright, send mail to
 .  Be prepared to provide us with the
 copyright statement.

Do you plan to move all these to the developer's reference? It would bloat
the developer's reference with references to specific sections of policy,
and leave the policy full of holes with no recommendations as to a good
course of action or even a mention that a given action is potentially
hazardous.

I remember having this exact same discussion when #3 above was added to
policy, BTW.

-- 
see shy jo


pgpAeBalyTOap.pgp
Description: PGP signature

Re: Data loss: suggestions for handling

[Matthew Palmer]

On Fri, Aug 01, 2003 at 11:36:52AM -0400, Matt Zimmerman wrote:
> On Fri, Aug 01, 2003 at 07:51:46PM +1000, Matthew Palmer wrote:
> > The latest upstream version of a package I've begun to maintain, IRM, has a
> > problem in that a portion of the data in the system (relating to software
> > and licence assignment) can't be upgraded along with the rest of the
> > database - the schema is totally different.
> 
> Even if the schema is different, if it represents the same data, it should
> be possible to convert it.  Maybe someone here (or upstream) can help with
> this.  What instructions does upstream provide for the upgrade?  Do they say
> that you must destroy this data and recreate it?

>From the look of it, they're storing different information in different
ways.  There's an upgrade script for the rest of the system (implemented as
a web-fronted PHP script) with hundreds of SQL commands to do funky things
to most parts of the system.  It's fairly obvious that they've tried to keep
upgrading as simple as possible - but they haven't been able to make the
software part backwards-compatible.

I should have made that clearer in my first message - it's not a matter of
writing the upgrade script, it's trying to work out a method of minimising
the disruption from this (apparently) necessary data loss.

>From suggestions I've received, I think I'm going to go with making a dump
of the whole database to /var/backups, and putting notes in README.Debian
and NEWS.Debian about the data loss.  Then people can downgrade and
recreate their old tables if they don't want to go through the pain of
re-importing all their software licencing information.

Any other places I should notify people of the loss?  E-mail to root?  I'm
not going to put a debconf note in because I *know* that's not what it's
for.

- Matt

Re: setuid/setgid binaries contained in the Debian repository.

[Brian T. Sniffen]

Herbert Xu <[EMAIL PROTECTED]> writes:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>> 
>> nethack is the only game which comes to mind which does this, and I think it
>> should probably be changed to keep the saved game in the user's home
>> directory.  This was clearly done in order to try to prevent cheating, but
>> again, these days the player has root anyway.
>
> If the player has root then why are discussing the possibility of the
> player cracking into the games group?

The legitimate player has root and thus could cheat at the game.
An illegitimate player is probably more interested in abusing the
machine than cheating at nethack.

-Brian

Re: setuid/setgid binaries contained in the Debian repository.

[Herbert Xu]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> 
> nethack is the only game which comes to mind which does this, and I think it
> should probably be changed to keep the saved game in the user's home
> directory.  This was clearly done in order to try to prevent cheating, but
> again, these days the player has root anyway.

If the player has root then why are discussing the possibility of the
player cracking into the games group?
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#203818: ITP: geeklog -- the ultimate weblog system

[Bruno Rodrigues]

Scott James Remnant <[EMAIL PROTECTED]> wrote:
> [-- text/plain, encoding quoted-printable, charset: ISO-8859-1, 29 lines --]
> 
> On Fri, 2003-08-01 at 23:25, Bruno David Rodrigues wrote:
> 
>> Package: wnpp
>> Version: unavailable; reported 2003-08-01
>> Severity: wishlist
>> 
>> * Package name: geeklog
>>   Version : 1.3.8
>>   Upstream Author : Tony Bibbs and geeklog community
>> <[EMAIL PROTECTED]>
>> * URL : http://www.geeklog.net
>> * License : GPLv2
>>   Description : the ultimate weblog system
>> 
>> Geeklog is a 'blog', otherwise known as a Weblog. It allows you to
>> create your own virtual community area, complete with user
>> administration, story posting, messaging, comments, polls, calendar,
>> weblinks, and more! It can run on many different operating systems, and
>> uses PHP4 and MySQL.
>> 
> Read http://people.debian.org/~walters/descriptions.html and try again.
> 
> "ultimate" is an opinion and definitely shouldn't be in the
> description.  "blog" -> "weblog" doesn't really describe what this
> does.  Is the "and more!" really necessary?  Do I have to install it to
> find out what the "and more" is?
> 
> Scott

I'm still analysing this software and its plugin system and I'll get a
better description later (I'll reply back to my ITP with it).

I'm just "announcing" that I'd like to take care of this and I've
copy/pasted from theyr short description on webpage.  


> 
> [-- application/pgp-signature, encoding 7bit, 8 lines, name: signature.asc --]
> [-- Description: This is a digitally signed message part --]
> 

Re: Bug#203818: ITP: geeklog -- the ultimate weblog system

[Scott James Remnant]

On Fri, 2003-08-01 at 23:25, Bruno David Rodrigues wrote:

> Package: wnpp
> Version: unavailable; reported 2003-08-01
> Severity: wishlist
> 
> * Package name: geeklog
>   Version : 1.3.8
>   Upstream Author : Tony Bibbs and geeklog community
> <[EMAIL PROTECTED]>
> * URL : http://www.geeklog.net
> * License : GPLv2
>   Description : the ultimate weblog system
> 
> Geeklog is a 'blog', otherwise known as a Weblog. It allows you to
> create your own virtual community area, complete with user
> administration, story posting, messaging, comments, polls, calendar,
> weblinks, and more! It can run on many different operating systems, and
> uses PHP4 and MySQL.
> 
Read http://people.debian.org/~walters/descriptions.html and try again.

"ultimate" is an opinion and definitely shouldn't be in the
description.  "blog" -> "weblog" doesn't really describe what this
does.  Is the "and more!" really necessary?  Do I have to install it to
find out what the "and more" is?

Scott


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

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Scott James Remnant]

On Fri, 2003-08-01 at 14:58, Pierre THIERRY wrote:

> > I think at least the RCness of this bug is rather dubious, frankly. If
> > the script is configuration
> 
> I don't think the script is meant to be edited... So it should be in
> /usr/sbin.
> 
I've edited it, and I'd bet I'm not the only one who has a
dog/cat/turtle/etc who keeps knocking the power button, resulting in a
change to scheduling a shutdown in 1 minutes time :)

Stuff like this is no different to /etc/cron.d, /etc/init.d,
/etc/apm/event.d -- it's configurable.

I say close the bug.

Scott


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

Re: setuid/setgid binaries contained in the Debian repository.

[Darren Salt]

I demand that Stephen Frost may or may not have written...

[snip]
> and a consensus reached which approves of the application and it's
> needs. ?

Almost: s/'// :-)

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   I don't ask for much, just untold riches...

i Invalid device, 0:1

Bug#203820: Incorrect expanding [] glob

[Artur R. Czechowski]

Package: bash
Version: 2.05b-8.1
Severity: normal

Hello

When LC_COLLATE is set to pl_PL [] glob does not work correctly:

[EMAIL PROTECTED]:/tmp/bash-test$ echo $LC_COLLATE
pl_PL
[EMAIL PROTECTED]:/tmp/bash-test$ touch a b C c D e F G h
[EMAIL PROTECTED]:/tmp/bash-test$ echo [A-Z]
b c C D e F G h
[EMAIL PROTECTED]:/tmp/bash-test$ export LC_COLLATE=C
[EMAIL PROTECTED]:/tmp/bash-test$ echo [A-Z]
C D F G

I am not sure that this is really bash error, that's why I Cc-ed it to
[EMAIL PROTECTED]

I didn't generate other language locales so I cannot test this error for it.
Maybe people on debian-devel could give a feedback about it.

I have locales version 2.3.1-17.

This bug is also in woody. Packages' versions:
ii  bash   2.05a-11   The GNU Bourne Again SHell
ii  locales2.2.5-11.5 GNU C Library: National Language (locale) da

Regards
Artur

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux zlom 2.4.21 #1 Tue Jul 15 02:03:36 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=pl_PL

Versions of packages bash depends on:
ii  base-files3.0.9  Debian base system miscellaneous f
ii  libc6 2.3.1-17   GNU C Library: Shared libraries an
ii  libncurses5   5.3.20030719-1 Shared libraries for terminal hand

-- no debconf information

Re: [PROPOSAL] Debian Release Plan

[Colin Watson]

On Fri, Aug 01, 2003 at 04:45:09PM -0600, Bruce Sass wrote:
> The BTS needs to adopt a "package pool" like mentality, where bugs
> are assigned to a particular version of a package instead of just the
> package.

Hey, man, we're working on it.

-- 
Colin Watson  [EMAIL PROTECTED]

Bug#203818: ITP: geeklog -- the ultimate weblog system

[Bruno David Rodrigues]

Package: wnpp
Version: unavailable; reported 2003-08-01
Severity: wishlist

* Package name: geeklog
  Version : 1.3.8
  Upstream Author : Tony Bibbs and geeklog community
<[EMAIL PROTECTED]>
* URL : http://www.geeklog.net
* License : GPLv2
  Description : the ultimate weblog system

Geeklog is a 'blog', otherwise known as a Weblog. It allows you to
create your own virtual community area, complete with user
administration, story posting, messaging, comments, polls, calendar,
weblinks, and more! It can run on many different operating systems, and
uses PHP4 and MySQL.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux davi 2.4.20-mh9 #1 Tue Jun 17 17:37:34 UTC 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: [PROPOSAL] Debian Release Plan

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 04:45:42PM -0500, Chris Cheney wrote:

> On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote:
> > And what if the version in testing has an RC bug?  "release-status-sarge"
> > says everything is OK.
> 
> Do we even know which packages in sarge have RC bugs? The last time I
> looked when you close a bug with an upload to sid it closes it entirely
> still.  So we don't really have a good idea of how many RC bugs exist in
> sarge, only how many are in sid.

Yep.  The testing scripts try to guess, but really we have no concrete
numbers.  It is up to individual maintainers to know whether their package
in sarge is releasable.  One problem is that they have no reason to speak up
if it is not, until the threat of release approaches.  Then there is a big
rush where everyone says "but my package isn't ready". :-/

-- 
 - mdz

Re: [PROPOSAL] Debian Release Plan

[Colin Watson]

On Fri, Aug 01, 2003 at 04:45:42PM -0500, Chris Cheney wrote:
> On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote:
> > And what if the version in testing has an RC bug?  "release-status-sarge"
> > says everything is OK.
> 
> Do we even know which packages in sarge have RC bugs? The last time I
> looked when you close a bug with an upload to sid it closes it entirely
> still.  So we don't really have a good idea of how many RC bugs exist in
> sarge, only how many are in sid.

For now, http://ftp-master.debian.org/testing/testing_probs.html is the
best idea we've got.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: [PROPOSAL] Debian Release Plan

[Bruce Sass]

On Fri, 1 Aug 2003, Chris Cheney wrote:
<...>
> Do we even know which packages in sarge have RC bugs? The last time I
> looked when you close a bug with an upload to sid it closes it entirely
> still.  So we don't really have a good idea of how many RC bugs exist in
> sarge, only how many are in sid.

The BTS needs to adopt a "package pool" like mentality, where bugs
are assigned to a particular version of a package instead of just the
package.


- Bruce

Re: setuid/setgid binaries contained in the Debian repository.

[Bernd Eckenfels]

On Fri, Aug 01, 2003 at 03:58:13PM -0500, Manoj Srivastava wrote:
>   Hmm. Are you willing then to help modify each game to allow
>  this to happen? Some changes are quite extensive. 

Hmm.. I am sure the maintainers of the affected packages will ask for help.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]

[Bruce Sass]

On Fri, 1 Aug 2003, Arnaud Vandyck wrote:

> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> [...]
> > [3] http://www.fs.tum.de/~bunk/Debian/freeze
>
> Reading the  whole "Future  releases of Debian"  thread, I  thought that
> the main idea was that Debian need a more 'readable' status for the next
> stable release.
<...>

While it would be nice to see at a glance how far along the next
release is, the proposal doesn't address the real problem of the
release cycle being too long... fix that and a more readable status of
the next release would be moot.

This has been an issue for as long as I can remember (I've been a
Debian user since 1.3), creating a permanent testing archive was an
attempt to solve it... but it hasn't worked because new software hits
testing too fast for testing to stabilize enough to freeze (how long
until the KDE packages in testing are a mix of 2.2, 3.1.2, and
3.1.3... two weeks?).

I can only see two viable options: freeze at regular intervals and
live with whatever happens to be in testing at the time, or extend the
flow of packages paradigm all the way to stable.

The first is like taking a 1/2 a step backwards (imo), the second
requires another archive because testing can not work as both the
output of unstable and the input for stable (it could if multiple
versions of all packages could exist in the same archive at the same
time).


- Bruce

Re: [PROPOSAL] Debian Release Plan

[Chris Cheney]

On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote:
> On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote:
> 
> > Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > > On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:
> > [...]
> > > > If there are RC bugs to packages that 'release-status-sarge' depends
> > > > on, it won't go to testing...
> > > 
> > > Of course  it would, unless it  had a versioned  dependency that could
> > > not be met.  And how would you  know in which version the bug would be
> > > fixed?
> > 
> > 'release-status-sarge' is just a package  to monitor the work to be done
> > to have a stable release. 
> > 
> > It does not matter to know in  which version the bug will be fixed. What
> > I want for sarge  is emacs21 ( >= 21.2 ) so if  every RC bugs are closed
> > with 21.3 or 21.4, the dependency >=21.2 is ok. 
> 
> And what if the version in testing has an RC bug?  "release-status-sarge"
> says everything is OK.

Do we even know which packages in sarge have RC bugs? The last time I
looked when you close a bug with an upload to sid it closes it entirely
still.  So we don't really have a good idea of how many RC bugs exist in
sarge, only how many are in sid.

Chris

Re: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Fri, 1 Aug 2003 16:01:03 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote:
>> Only if the game still works -- some games keep not just score
>> files, but saved games in the common area, and would not work as
>> expected if they could not write to that area.

> nethack is the only game which comes to mind which does this, and I
> think it should probably be changed to keep the saved game in the
> user's home directory.  This was clearly done in order to try to
> prevent cheating, but again, these days the player has root anyway.

Well, if you are talking about packages in main, yes. But
 there are other games that follow policy that are also affected.

manoj
-- 
We cannot command nature except by obeying her. Sir Francis Bacon
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Fri, 1 Aug 2003 22:31:16 +0200, Bernd Eckenfels <[EMAIL PROTECTED]> said: 

> BUT: i realy do think each game MUST offer the non sgid option. We
> could have a global question herer:

Hmm. Are you willing then to help modify each game to allow
 this to happen? Some changes are quite extensive. 

manoj
-- 
Date: 23 Feb 90 19:01:21 GMT From: [EMAIL PROTECTED] (Randal
Schwartz) format STDOUT = @<<< @<< @<<< @<, $Just, $another,
$Perl, $hacker
. for("Just","another","Perl","hacker"){eval"\$$_=\$_;";};write;
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Why doesn't yehia enter testing?

[Colin Watson]

On Fri, Aug 01, 2003 at 10:40:12PM +0200, Andreas Rottmann wrote:
> I wonder why yehia isn't entering testing. According to [0] it makes
> qmailmrtg7 uninstallable, but qmailmrtg7 is totally unrelated to
> yehia, AFAICS.

I've no idea where qmailmrtg7 is coming from, but actually yehia is
caught up in the libsigc++ dependency chain. Since libsigc++'s library
package name has changed since the version in testing, everything
depending on the old version in testing needs to be rebuilt before the
new group can go into testing.

There are several packages at the moment holding this up:

  * aptitude used to depend on libsigc++0. The new version doesn't, but
it needs the new apt, which is almost ready but is waiting for new
versions of gcc-3.3 and glibc.

  * lostirc has RC bugs #194366 and #194867.

  * thoughttracker has various build problems; see #198905.

  * gtkextramm has RC bug #197591.

  * vdk2 has RC bug #201318.

  * fwbuilder fails to build on arm.

Fix this lot and I think it should be OK ...

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: [PROPOSAL] Debian Release Plan

[Arnaud Vandyck]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote:
> > [...]
> > It  does  not matter  to  know  in which  version  the  bug will  be
> > fixed. What I want  for sarge is emacs21 ( >= 21.2  ) so if every RC
> > bugs are closed with 21.3 or 21.4, the dependency >=21.2 is ok.
> 
> And what if the version in testing has an RC bug? 
> "release-status-sarge" says everything is OK.

You are  rigth. I thought we  can fill a RC  bug "to early  for a stable
release" but you are right, if one  of the version we want is in testing
and we are OK for a release, yes, the monitor will be wrong!

> > What I  think is interresting with  my proposal is  that the release
> > happens when packages we want for the next stable release are ready,
> > stable.
> 
> I am saying that the reality  of the situation is more complex than is
> accounted for in this approach.

Isn't it a beginning?

> > Don't you agree with a way of monitoring the steps to be done to the
> > next stable release?
> > 
> > Maybe you exactly know where Debian goes and what we are waiting for
> > (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not.
> 
> I  do not think  that version  number milestones  are important  for a
> release.   I   think  that  having   a  well-integrated,  high-quality
> distribution is  important for  a release, and  this is not  so easily
> monitored.

I agree. Anybody to try another proposal? ;)

-- Arnaud Vandyck, STE fi, ULg
   Formateur Cellule Programmation.


pgp4qsb6l9Ypc.pgp
Description: PGP signature

Re: Why doesn't yehia enter testing?

[Steve Langasek]

On Fri, Aug 01, 2003 at 10:40:12PM +0200, Andreas Rottmann wrote:

> I wonder why yehia isn't entering testing. According to [0] it makes
> qmailmrtg7 uninstallable, but qmailmrtg7 is totally unrelated to
> yehia, AFAICS.

> Regards, Andy

> [0] http://bjorn.haxx.se/debian/testing.pl?package=yehia&expand=1

Hmm, I think that particular script might be in need of updating
following some hacking that I understand has been done recently to the
testing scripts.  What I see at
http://ftp-master.debian.org/testing/update_output.txt doesn't really
indicate to me that yehia is causing qmailmrtg7 to be uninstallable;
rather, it looks like qmailmrtg7 is being hinted in, it is uninstallable
for reasons of its own, and the (alphabetically) last package in the
group of packages being tried during this particular run is yehia.

-- 
Steve Langasek
postmodern programmer


pgpmo7ygD0VIt.pgp
Description: PGP signature

Why doesn't yehia enter testing?

[Andreas Rottmann]

I wonder why yehia isn't entering testing. According to [0] it makes
qmailmrtg7 uninstallable, but qmailmrtg7 is totally unrelated to
yehia, AFAICS.

Regards, Andy

[0] http://bjorn.haxx.se/debian/testing.pl?package=yehia&expand=1
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.

Re: [PROPOSAL] Debian Release Plan

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:
> [...]
> > > If there are RC bugs to packages that 'release-status-sarge' depends
> > > on, it won't go to testing...
> > 
> > Of course  it would, unless it  had a versioned  dependency that could
> > not be met.  And how would you  know in which version the bug would be
> > fixed?
> 
> 'release-status-sarge' is just a package  to monitor the work to be done
> to have a stable release. 
> 
> It does not matter to know in  which version the bug will be fixed. What
> I want for sarge  is emacs21 ( >= 21.2 ) so if  every RC bugs are closed
> with 21.3 or 21.4, the dependency >=21.2 is ok. 

And what if the version in testing has an RC bug?  "release-status-sarge"
says everything is OK.

> What  I think  is  interresting with  my  proposal is  that the  release
> happens when  packages we  want for the  next stable release  are ready,
> stable. 

I am saying that the reality of the situation is more complex than is
accounted for in this approach.

> Don't you  agree with a way  of monitoring the  steps to be done  to the
> next stable release? 
> 
> Maybe you  exactly know where  Debian goes and  what we are  waiting for
> (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not.

I do not think that version number milestones are important for a release.
I think that having a well-integrated, high-quality distribution is
important for a release, and this is not so easily monitored.

-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 04:13:30PM -0400, Jim Penny wrote:

> On Fri, 1 Aug 2003 16:01:03 -0400 Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > nethack is the only game which comes to mind which does this, and I
> > think it should probably be changed to keep the saved game in the user's
> > home directory.  This was clearly done in order to try to prevent
> > cheating, but again, these days the player has root anyway.
> 
> Hmm, that is not the only reason, and maybe not the real reason.  What
> about "bones piles"?  Doesn't nethack do this partially so that levels
> from dead games could be reused in future games?  On a multi-user system,
> you get a better set of bones piles, because you have no idea of what
> killed the adventurer, and probably no idea of whether anything is worth
> picking up and risking the possibility of a curse.

Of course it is the real reason.  Otherwise you get exactly the same feature
with a world-writable directory.

(and anyway, there exists 'hearse' now, though I haven't tried it)

-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Bernd Eckenfels]

On Fri, Aug 01, 2003 at 01:56:50PM -0400, Joey Hess wrote:
> I think you can set it up so users cannot forge high scores by just
> running such a helper. Make the helper sgid scorewriter, and make the
> games setgid scoresetter

Umm... you invent a scorewriter for removing the sgui games bit? And then
you add a sgid scoresetter? I dont think this makes mch sence.

Although it is true, that sgid games exploit are a problem, because they can
be used to invade other game playing users, personally I think it is much
more important to look at the other suids first.

BUT: i realy do think each game MUST offer the non sgid option. We could
have a global question herer:

Do you want to limit gaming experiencing on your system but therefore
increase system security? If you answer yes here, no game will be installed
sgid games, and therefore you do not have shared highscores. <> 


Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: setuid/setgid binaries contained in the Debian repository.

[Bernd Eckenfels]

On Fri, Aug 01, 2003 at 01:46:48PM -0400, Joey Hess wrote:
> Setuid and setgid programs are one of the main causes of security
> holes and DSA's in Debian.

Hmm 

DSA-360:  no  (daemon)
DSA-359:  yes (uid root: hardware access)
DSA-358:  no  (kernel)
DSA-357:  no  (daemon)
DSA-356:  yes (gid games)
DSA-355:  no  (web css)
DSA-354:  yes (gid games)
DSA-353:  no  (daemon, temp file)
DSA-352:  no  (user, temp file)
DSA-351:  no  (web css)
DSA-350:  yes (gid games)
DSA-349:  no  (daemon)
DSA-348:  yes (system root tool exploit)
...

Looking at this statistic, it is clearly visible that most of the exploits
are game related, in fact only one system tool and one hardware accessing
'game' would allow suid root exploits, all others are sgid games.

> A few
> well-trained eyes looking over a package before it goes into the
> distribution and becomes a security risk can make all the difference.

Yes, but I think the eyes should concentrate on non sgid-games first.
Because this might be a realy BIG junk of UGLYNESS one will find there :)

And some of the suid root stuff, like hardware acces might even require
debian to switch to some more sensible kernel setups.

> +
> +  Since setuid and setgid programs are often a security rick,
> +  you should not add any new setuid or setgid programs to
> +  the distribution before this has been discussed on the
> +  debian-security mailing list and a consensus about
> +  doing that has been reached.
> +

Do we want to make an sgui games exception here?

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: [PROPOSAL] Debian Release Plan

[Arnaud Vandyck]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:
[...]
> > If there are RC bugs to packages that 'release-status-sarge' depends
> > on, it won't go to testing...
> 
> Of course  it would, unless it  had a versioned  dependency that could
> not be met.  And how would you  know in which version the bug would be
> fixed?

'release-status-sarge' is just a package  to monitor the work to be done
to have a stable release. 

It does not matter to know in  which version the bug will be fixed. What
I want for sarge  is emacs21 ( >= 21.2 ) so if  every RC bugs are closed
with 21.3 or 21.4, the dependency >=21.2 is ok. 

I think  I do not  understand what you  mean or I  do not see  where the
problem is. 

What  I think  is  interresting with  my  proposal is  that the  release
happens when  packages we  want for the  next stable release  are ready,
stable. 

The existance of  this package in testing does not  mean the next stable
release must  come out as soon as  possible, but it's a  monitor, it can
give important  informations on what have  to be done to  reach the next
stable release. 

I think  about this proposal just  after the first mail  of Adrian Bunk,
but I think I did not think enough :(

Don't you  agree with a way  of monitoring the  steps to be done  to the
next stable release? 

Maybe you  exactly know where  Debian goes and  what we are  waiting for
(yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not.

Best regards,

-- Arnaud Vandyck, STE fi, ULg
   Formateur Cellule Programmation.


pgpa0RwcemmKk.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Jim Penny]

On Fri, 1 Aug 2003 16:01:03 -0400
Matt Zimmerman <[EMAIL PROTECTED]> wrote:

> On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote:
> 
> > Only if the game still works -- some games keep not just score
> >  files, but saved games in the common area, and would not work as
> >  expected if they could not write to that area.
> 
> nethack is the only game which comes to mind which does this, and I
> think it should probably be changed to keep the saved game in the
> user's home directory.  This was clearly done in order to try to
> prevent cheating, but again, these days the player has root anyway.
>

Hmm, that is not the only reason, and maybe not the real reason.  What
about "bones piles"?  Doesn't nethack do this partially so that levels
from dead games could be reused in future games?  On a multi-user
system, you get a better set of bones piles, because you have no idea of
what killed the adventurer, and probably no idea of whether anything is
worth picking up and risking the possibility of a curse.

Jim Penny
who has in past lives spent far too many hours playing nethack

Sheet Music

[Austin S]

Could you please send me the sheet music for Dueling Banjos
_
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote:

>   Only if the game still works -- some games keep not just score
>  files, but saved games in the common area, and would not work as
>  expected if they could not write to that area.

nethack is the only game which comes to mind which does this, and I think it
should probably be changed to keep the saved game in the user's home
directory.  This was clearly done in order to try to prevent cheating, but
again, these days the player has root anyway.

-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Fri, 1 Aug 2003 13:46:48 -0400, Joey Hess <[EMAIL PROTECTED]> said: 

> Here's a draft policy proposal. If this looks ok I'll submit it to
> the policy group.

> Proposal: [DRAFT] require peer review for setuid and setgid program
> introduction

> Setuid and setgid programs are one of the main causes of security
> holes and DSA's in Debian. Often these holes can be spotted easily
> with a simple review. Sometimes setuid/gid programs can be modified
> in fairly simple ways to not need these dangerous permissions at
> all. A few well-trained eyes looking over a package before it goes
> into the distribution and becomes a security risk can make all the
> difference.

> So, I propose that any new setuid or setgid programs should be
> reviewed by a team of interested people before being put into the
> distribution.  In discussions on debian-devel, we agreed this was a
> good idea, and that debian-security is the appropriate list for
> these reviews. The reviewers will be whoever is interested, which
> currently includes at least one member of the security team, and one
> of our most prolific security auditors.

> Note the paralell with the existing requirement that essential
> packages be discussed on debian-devel.

This seems like a good practice kind of recommendation, not an
 requirement, and as such, may be better suited to be included
 in developers reference rather than policy, don't you think?

manoj
-- 
The Bird of Time has but a little way to fly ... and the bird is on
the wing. Omar Khayyam
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: setuid/setgid binaries contained in the Debian repository.

[Manoj Srivastava]

On Fri, 1 Aug 2003 11:22:17 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote:
>> what's wrong with a low-priority debconf question with a sane
>> default?

> As long as the sane default is the safe default, which is not to be
> setgid.

Only if the game still works -- some games keep not just score
 files, but saved games in the common area, and would not work as
 expected if they could not write to that area.

manoj
-- 
St. Patrick was a gentleman who through strategy and stealth drove all
the snakes from Ireland. Here's a toasting to his health -- but not
too many toastings lest you lose yourself and then forget the good
St. Patrick and see all those snakes again.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Marco d'Itri]

On Aug 01, David Z Maze <[EMAIL PROTECTED]> wrote:

 >Is this "script that gets run when the console user presses the power
 >button", and is it obvious that the user could potentially want to
 >configure it?  If so, then it makes sense that it should be a
 >configuration file, and so by policy 10.7.2 it should live in /etc.
The user may want to configure it, but OTOH the script name is
referenced in /etc/acpid/events/powerbtn, and it would probably be
cleaner to make it point to a local script.

-- 
ciao, |
Marco | [1063 afeJFGjAxPvAk]

EARN $500 TO $700 PER WEEK DOWNLOADING FREE SOFTWARE!!

[gary fiennes]

Make $500 to $700 per week for downloading FREE software!!  


 Dear friend!!


We know it sounds too good to be true, but itfs REAL!  We pay you hard cash 
for you to download and install 
this FREE software and we pay you each month that you continue to use it.  Best 
of all you will only have to 
download a small (110K) piece of software ONE time for FREE and you'll be on 
your way to earning BIG 
MONEY.. Just visit http://www.raden.plugusin4cash.com/ to find out more.


Sincerely yours,
Gary
http://www.raden.plugusin4cash.com
[EMAIL PROTECTED]

Re: CUPS should be the default print service in Debian/Sarge

[Marcelo E. Magallon]

On Thu, Jul 31, 2003 at 09:44:17AM -0400, Daniel Jacobowitz wrote:

 > The last time I tried to use CUPS, I found it to be so user friendly
 > that I couldn't get it to do anything useful.  Very pretty, less
 > functional; and the documentation was entirely inadequate.
 > 
 > On the other hand, while lprng was anything but user-friendly, it was
 > simple and well-documented.  Much more important to have something
 > that works before you go making it user-friendly!

 Care to give more details?  Which printer?  How was it connected?  How
 did you try to setup CUPS?

 Even if I don't think the CUPS documentation is superb, for the setups
 I have had to deal with (anything but trivial) it was adequate, and the
 only thing I really that to read about what the IPP name service
 conventions.

 Marcelo

Re: setuid/setgid binaries contained in the Debian repository.

[Adam Heath]

On Fri, 1 Aug 2003, Matt Zimmerman wrote:

> On Fri, Aug 01, 2003 at 08:20:40PM +0200, Josip Rodin wrote:
>
> > On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote:
> > > it would be trivial to add lintian/linda warnings for this,
> >
> > There's already a warning for set[ug]id in Lintian.
>
> Ah, ok.  But the point was that it will miss many cases.  For example, I've
> never seen this warning in uml-utilities because it uses a
> dynamically-allocated gid and so must use chmod in postinst rather than
> setting permissions in the .deb.  If this could be done at build time rather
> than at install time, the check would be perfect.

Andrew Suffield and I have plans to get rid of dynamic user creation in
postinst, and chmod +s as well.

preinst will create the user(by calling adduser), then the setuid-ness in the
deb can be applied.  This invovles modifying dpkg-deb to read a list of
permission overrides.

See -policy.

Re: setuid/setgid binaries contained in the Debian repository.

[Stephen Frost]

* Joey Hess ([EMAIL PROTECTED]) wrote:
> --- policy.sgml.orig  2003-08-01 13:40:51.0 -0400
> +++ policy.sgml   2003-08-01 13:45:24.0 -0400
> @@ -7104,6 +7104,14 @@
> execute them.
>   
>  
> +
> +  Since setuid and setgid programs are often a security rick,

'risk' might be a bit better. :)

> +  you should not add any new setuid or setgid programs to
> +  the distribution before this has been discussed on the

until it has been discussed .. ?

> +  debian-security mailing list and a consensus about
> +  doing that has been reached.

and a consensus reached which approves of the application and it's
needs. ?

Stephen


pgp0zhMViopSR.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 08:20:40PM +0200, Josip Rodin wrote:

> On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote:
> > it would be trivial to add lintian/linda warnings for this,
> 
> There's already a warning for set[ug]id in Lintian.

Ah, ok.  But the point was that it will miss many cases.  For example, I've
never seen this warning in uml-utilities because it uses a
dynamically-allocated gid and so must use chmod in postinst rather than
setting permissions in the .deb.  If this could be done at build time rather
than at install time, the check would be perfect.

-- 
 - mdz

Re: [PROPOSAL] Debian Release Plan

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > I don't think  that the most important release  goals can be expressed
> > in terms of version numbers.  For example, RC bug fixes.  I don't find
> > goals such as "we want version X of package Y because it's the newest"
> > to be  very useful in  producing a quality  release, nor do  I believe
> > that these  are the kind of  goals which are  responsible for Debian's
> > long release cycle.
> 
> If there are RC bugs to packages that 'release-status-sarge' depends on,
> it won't go to testing... 

Of course it would, unless it had a versioned dependency that could not be
met.  And how would you know in which version the bug would be fixed?



-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Josip Rodin]

On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote:
> it would be trivial to add lintian/linda warnings for this,

There's already a warning for set[ug]id in Lintian.

-- 
 2. That which causes joy or happiness.

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 01:46:48PM -0400, Joey Hess wrote:

> Here's a draft policy proposal. If this looks ok I'll submit it to the
> policy group.

Thanks for doing this.  It looks fine, with the exception of a small typo:

> +  Since setuid and setgid programs are often a security rick,
   ^ risk

If we could come up with a standard way of setting these permissions, to
avoid the kind of messing around in the postinst that we do now, it would be
trivial to add lintian/linda warnings for this, to encourage maintainers to
discuss the situation before uploading.  doogie, asuffield and I discussed
this on IRC recently.

-- 
 - mdz

Re: [PROPOSAL] Debian Release Plan

[Arnaud Vandyck]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 01, 2003 at 07:03:46PM +0200, Arnaud Vandyck wrote:
> 
> > I  propose to  create a  meta-package  called 'release-status-sarge'
> > that depends on  packages (with version number) that  we want to see
> > in sarge.
> 
> I don't think  that the most important release  goals can be expressed
> in terms of version numbers.  For example, RC bug fixes.  I don't find
> goals such as "we want version X of package Y because it's the newest"
> to be  very useful in  producing a quality  release, nor do  I believe
> that these  are the kind of  goals which are  responsible for Debian's
> long release cycle.

If there are RC bugs to packages that 'release-status-sarge' depends on,
it won't go to testing... 

We can  think of  a new release  when 'release-status-sarge' will  be in
testing. 

-- Arnaud Vandyck, STE fi, ULg
   Formateur Cellule Programmation.


pgpU6BP0phUe5.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 01:56:50PM -0400, Joey Hess wrote:

> I think you can set it up so users cannot forge high scores by just
> running such a helper. Make the helper sgid scorewriter, and make the
> games setgid scoresetter (these names could be better). Then the helper
> would refuse to write any scores unless its real GID is scoresetter.

I considered something like this, but I dismissed it as overcomplicated for
the problem (of forging local high scores).  I'd rather decrease the overall
number of privileged programs than reorganize into a larger number of
privilege groups.  With fewer and fewer users per system these days, there
isn't usually any glory in this kind of high score anyway, and only
client/server games which are mediated by a neutral server can usefully
provide this kind of scorekeeping.

-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Matt Zimmerman wrote:
> Personally, I would lean more towards having a setgid helper which writes to
> the game's score file.  It is possible to audit such helpers completely in a
> short amount of time, and I feel that it would be far better to open
> ourselves up to letting users forge their own high scores than to the
> current exposures which are possible through group games.

I think you can set it up so users cannot forge high scores by just
running such a helper. Make the helper sgid scorewriter, and make the
games setgid scoresetter (these names could be better). Then the helper
would refuse to write any scores unless its real GID is scoresetter.

-- 
see shy jo


pgplRuxCwkTHX.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Joey Hess]

Matt Zimmerman wrote:
> On Fri, Aug 01, 2003 at 11:26:57AM -0400, Stephen Frost wrote:
> 
> > * Matt Zimmerman ([EMAIL PROTECTED]) wrote:
> > > I absolutely support this idea.  All set[ug]id setups should be reviewed
> > > before they go in the archive, and I volunteer to do the review (though I
> > > hope that others will help).  Does this need a proposal to go into policy
> > > with the same force as the existing pre-depends verbiage?
> > 
> > It probably should.  I'd be willing to say we might want a seperate list
> > for this too.  I'm willing to help with the review but I tend to skim
> > d-d..
> 
> I think debian-security would be fine, maybe with a special Subject tag.

Here's a draft policy proposal. If this looks ok I'll submit it to the
policy group.


Proposal: [DRAFT] require peer review for setuid and setgid program introduction

Setuid and setgid programs are one of the main causes of security
holes and DSA's in Debian. Often these holes can be spotted easily
with a simple review. Sometimes setuid/gid programs can be modified in
fairly simple ways to not need these dangerous permissions at all. A few
well-trained eyes looking over a package before it goes into the
distribution and becomes a security risk can make all the difference.

So, I propose that any new setuid or setgid programs should be reviewed
by a team of interested people before being put into the distribution.
In discussions on debian-devel, we agreed this was a good idea, and that
debian-security is the appropriate list for these reviews. The reviewers
will be whoever is interested, which currently includes at least one
member of the security team, and one of our most prolific security
auditors.

Note the paralell with the existing requirement that essential packages
be discussed on debian-devel.

--- policy.sgml.orig2003-08-01 13:40:51.0 -0400
+++ policy.sgml 2003-08-01 13:45:24.0 -0400
@@ -7104,6 +7104,14 @@
  execute them.

 
+
+  Since setuid and setgid programs are often a security rick,
+  you should not add any new setuid or setgid programs to
+  the distribution before this has been discussed on the
+  debian-security mailing list and a consensus about
+  doing that has been reached.
+
+

  It is possible to arrange that the system administrator can
  reconfigure the package to correspond to their local

-- 
see shy jo


pgpsKaYcBNHRc.pgp
Description: PGP signature

Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 07:03:46PM +0200, Arnaud Vandyck wrote:

> I propose  to create  a meta-package called  'release-status-sarge' that
> depends on packages (with version number) that we want to see in sarge. 

I don't think that the most important release goals can be expressed in
terms of version numbers.  For example, RC bug fixes.  I don't find goals
such as "we want version X of package Y because it's the newest" to be very
useful in producing a quality release, nor do I believe that these are the
kind of goals which are responsible for Debian's long release cycle.



-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Thu, Jul 31, 2003 at 05:33:23PM +0100, Steve Kemp wrote:

>   There's probably a lot to be said for building a chroot installation
>  and installing each package in turn; but I don't have the time for that
>  at the moment.

I have some basic tools for doing this kind of thing using UML's
copy-on-write block devices, so it is relatively efficient.  This is one of
the things that I plan to do with it once it is ready for large-scale
projects.

-- 
 - mdz

Re: debconf 2005 in Vienna, Austria

[Joel Baker]

On Fri, Aug 01, 2003 at 02:06:48PM +0300, Riku Voipio wrote:
> 
> Yes. a debcamp of users would probably blow some fuse :)

Speaking as someone who's held an FRA (US Federal Railroad Administration)
crew and fireman cert - it's unlikely, unless you do something that would
overload a normal house circuit.

Diesel locomotives are a giant diesel generator hooked up to electric
traction motors, running through the switchbox at something like 600v
(I haven't read the specs in a while, this might be off - but it's high
enough to warrant being really careful around). Don't even ask about the
amperage. Sapping off a little power to run a few household outlets is, by
comparison, peanuts. Or, really, peanut crumbs.

Now, just try not to be nervous at the fact that there's a pipe running
under your feet pressurized to 90 PSI (at least on standard US trains), and
you'll be fine. :)

There's a reason they call popping the coupling seals on that line (the
fail-safe (full stop) airbrake line) completely (rather than bleeding the
air off) 'dynamiting'...
-- 
Joel Baker <[EMAIL PROTECTED]>


pgpRKx4EOtwNp.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Joel Baker]

On Fri, Aug 01, 2003 at 11:34:11AM +0200, Tollef Fog Heen wrote:
> * Steve Kemp 
> 
> | On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote:
> | 
> | > what's wrong with a low-priority debconf question with a sane default?
> | 
> |   Absolutely nothing at all, but it's a slippery slope, and I thought
> |  we were tending towards less interactivity in installations?
> 
> which is why I said «low priority»:
> 
> 'critical' only prompts you if the system might break.
>Pick it if you are a newbie, or in a hurry.
> 'high' is for rather important questions
> 'medium' is for normal questions
> 'low' is for control freaks who want to see everything
> 
> If you select low, you will have to drink off the fire hose.  Having
> low-priority questionsis good, since it makes it easy to make
> customized installs with preloaded answers.

The only question I would have about it is that every potentially-sgid game
package would need to share the question (so that it only got asked once,
but was available whenever needed) - organizing that could be a bit tricky,
I would think.

Certainly I think it would be one of the more reasonable uses of shared
debconf stuff - one question, low priority, a sane default of not being
sgid, and assuming packages used something proper (er, dpkg-statoverride?)
to register the sgid bit, it doesn't matter if you blow away the answer
cache - you can look at the existing state and find out what you need to
know (or, presumably, override it).
-- 
Joel Baker <[EMAIL PROTECTED]>


pgpHUUfcNpVft.pgp
Description: PGP signature

[PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]

[Arnaud Vandyck]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
[...]
> [3] http://www.fs.tum.de/~bunk/Debian/freeze

Reading the  whole "Future  releases of Debian"  thread, I  thought that
the main idea was that Debian need a more 'readable' status for the next
stable release.

I propose  to create  a meta-package called  'release-status-sarge' that
depends on packages (with version number) that we want to see in sarge. 

Each maintainer has  to fill a bug report to include  his package in the
next release  and explain why the  release has to wait  for this package
(or/ and this  version of the package). We can  have different bug level
for the importance to include the package or not.

The  release-status-sarge maintainer  can then  add the  package  in the
Depends field with the version number and close the bug, or he (she) can
tag the  bug 'wontfix' and  explain why the  package will not be  in the
next release. He (or she) can also ask for moreinfo. 

Why a meta-package and not a virtual-package? 

If we have  a meta-package, we can use 'grep-excuse' to  see "who we are
waiting for?", in addition with the BTS, it's a lot of informations. 

We can also submit  other bugs against the release-status-sarge package,
like "Too many  RC Bugs" or any other information on  why the release is
nt ready yet. 

I think Adrian is  right when he want more release. I  think the idea of
having a Debian release a year is not so bad, but I do not like the idea
of a dead-line for Debian releases. I think that "Next release of Debian
will happen when  it is ready" should be a general  way of thinking even
in other areas! This does not mean we do not need a strict release plan,
but I prefer to base the release plan on targets, not on dates. 

Clear release goals not a release date. 

Also,  Debian has  developed  lot of  interresting  concepts, ideas  and
tools, my idea  is just to use some of  them, no additional development,
to clarify stable release plan and goals to Debian users and even Debian
developers. 

Any comments are appreciate, thank you for your time,

Note: I could also call  the proposal "Debian Release Unified Goals" but
  finally I don't think it's a good idea ;)

-- Arnaud Vandyck
   http://alioth.debian.org/users/arnaud-guest/


pgpkrot1qJ0Cf.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 11:26:57AM -0400, Stephen Frost wrote:

> * Matt Zimmerman ([EMAIL PROTECTED]) wrote:
> > I absolutely support this idea.  All set[ug]id setups should be reviewed
> > before they go in the archive, and I volunteer to do the review (though I
> > hope that others will help).  Does this need a proposal to go into policy
> > with the same force as the existing pre-depends verbiage?
> 
> It probably should.  I'd be willing to say we might want a seperate list
> for this too.  I'm willing to help with the review but I tend to skim
> d-d..

I think debian-security would be fine, maybe with a special Subject tag.

-- 
 - mdz

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Matthias Urlichs]

Hi, Matthew Garrett wrote:

> The user should be able to choose whether the power
> button triggers shutdown or suspend to disk, for instance.

While I do agree that this kind of script is best placed in /etc, this
kind of choice can be configured by a "normal" /etc/acpid.conf that's read
by the script.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
A pretty woman is a welcome guest.
-- Byron

Re: Data loss: suggestions for handling

[Matthew Palmer]

On Fri, Aug 01, 2003 at 08:04:09AM -0400, Stephen Frost wrote:
> * Matthew Palmer ([EMAIL PROTECTED]) wrote:
> > - dump the old software tables and store the dump somewhere, giving
> > pointers to the dump in all sorts of useful places.  But if I put it
> > somewhere temporary (/tmp), it might disappear before the admin
> > realises, and somewhere permanent will chew disk space.
> 
> /var/backups.  Tell the admin, if they want to clean it up they can.

Hey, look at that.  Never knew that existed.  Thankyou very much.  I think
my problem has been solved.

Again, my thanks.

- Matt

Re: Data loss: suggestions for handling

[Matthew Palmer]

On Fri, Aug 01, 2003 at 01:59:43PM +0200, Roland Mas wrote:
> Matthew Palmer (2003-08-01 19:51:46 +1000) :
> 
> > The latest upstream version of a package I've begun to maintain,
> > IRM, has a problem in that a portion of the data in the system
> > (relating to software and licence assignment) can't be upgraded
> > along with the rest of the database - the schema is totally
> > different.
> 
> Do you have an upgrade script?  Like a set of SQL commands that will
> convert from one schema to the other?  More importantly, do you have a

I do, but it doesn't work with the software portion.  The rest of the system
upgrades smoothly, but the information stored by the software tracker part
is different enough that it can't be converted.

I've extracted out all the SQL commands that do the upgrade from the
upstream-supplied PHP script and have gotten those going OK.  It's dealing
with the seemingly unavoidable data loss in the software tracking part that
I just can't deal with well.  Upstream seems to think it too hard as well,
because, while the rest of the system upgrades OK, they've got big "warning,
you will lose your software data" messages all over the later versions.

> > A couple of questions:
> >
> > * Am I being too paranoid?
> 
>   Probably not.  Maybe some of your users won't mind too much if they
> lose data, but most of them probably will.  Then there's the personal
> pride in building a crash-proof system even if nobody notices.

A craftsman after my own heart.  Pride in one's work.  

- Matt

Re: setuid/setgid binaries contained in the Debian repository.

[Stephen Frost]

* Matt Zimmerman ([EMAIL PROTECTED]) wrote:
> On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote:
> > I also think it would be a good idea for policy to require all setuid/gid
> > bit grants to go through this or another list for peer review, much as
> > pre-depends are supposed to.
> 
> I absolutely support this idea.  All set[ug]id setups should be reviewed
> before they go in the archive, and I volunteer to do the review (though I
> hope that others will help).  Does this need a proposal to go into policy
> with the same force as the existing pre-depends verbiage?

It probably should.  I'd be willing to say we might want a seperate list
for this too.  I'm willing to help with the review but I tend to skim
d-d..

Stephen


pgpYXXeHWnI5U.pgp
Description: PGP signature

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Josip Rodin]

On Fri, Aug 01, 2003 at 10:32:47AM -0500, Gunnar Wolf wrote:
> Ummm... I *did* find something strange, maybe you can give some more
> insight on this:
> 
> [EMAIL PROTECTED]:/$ find /etc -type f -perm -755|xargs file|grep ELF
> etc/X11/rstart/rstartd.real:ELF 32-bit LSB 
> executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically 
> linked (uses shared libs), stripped
> [EMAIL PROTECTED]:/$ dpkg -S rstartd.real
> xutils: /etc/X11/rstart/rstartd.real
> 
> This is clearly a binary, it is clearly not user-modifiable. Should it
> be in /etc? Should it just be a symlink to /usr/lib/xutils or something
> like it?

Yes, it's a known bug, it'll be fixed.

-- 
 2. That which causes joy or happiness.

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Gunnar Wolf]

David Z Maze dijo [Fri, Aug 01, 2003 at 09:31:40AM -0400]:
> Cajus Pollmeier <[EMAIL PROTECTED]> writes:
> 
> > On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote:
> >> Severity: serious
> >> Justification: Policy 9.1.1
> 
> ("Debian should obey the FHS"; I don't claim to be an FHS expert, but
> all it seems to say about /etc is "no binaries", which this doesn't
> violate.)

Ummm... I *did* find something strange, maybe you can give some more
insight on this:

[EMAIL PROTECTED]:/$ find /etc -type f -perm -755|xargs file|grep ELF
etc/X11/rstart/rstartd.real:ELF 32-bit LSB executable, 
Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses 
shared libs), stripped
[EMAIL PROTECTED]:/$ dpkg -S rstartd.real
xutils: /etc/X11/rstart/rstartd.real

This is clearly a binary, it is clearly not user-modifiable. Should it
be in /etc? Should it just be a symlink to /usr/lib/xutils or something
like it?

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Data loss: suggestions for handling

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 07:51:46PM +1000, Matthew Palmer wrote:

> The latest upstream version of a package I've begun to maintain, IRM, has a
> problem in that a portion of the data in the system (relating to software
> and licence assignment) can't be upgraded along with the rest of the
> database - the schema is totally different.

Even if the schema is different, if it represents the same data, it should
be possible to convert it.  Maybe someone here (or upstream) can help with
this.  What instructions does upstream provide for the upgrade?  Do they say
that you must destroy this data and recreate it?

-- 
 - mdz

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Gunnar Wolf]

Pierre THIERRY dijo [Fri, Aug 01, 2003 at 03:58:23PM +0200]:
> > I think at least the RCness of this bug is rather dubious, frankly. If
> > the script is configuration
> 
> I don't think the script is meant to be edited... So it should be in
> /usr/sbin.

There are many scripts in /etc that are not meant to be edited unless a
special need arises - The first packages that comes to my mind are
pcmcia-cs and linux-wlan-ng. They have many different scripts in
/etc/pcmcia, and almost always they work perfectly - I had to fiddle
with them once.

In my system I have 113 executable files under /etc, they belong to the
most varied programs... And they are (or at least, they seem to be)
perfectly valid configurable files. (most of them - see my next message)

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgpwnZq7O92MR.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Steve Kemp]

On Fri, Aug 01, 2003 at 11:18:53AM -0400, Matt Zimmerman wrote:

> > I also think it would be a good idea for policy to require all setuid/gid
> > bit grants to go through this or another list for peer review, much as
> > pre-depends are supposed to.
> 
> I absolutely support this idea.  All set[ug]id setups should be reviewed
> before they go in the archive, and I volunteer to do the review (though I
> hope that others will help).  Does this need a proposal to go into policy
> with the same force as the existing pre-depends verbiage?

  I would support such a change too, and would volunteer to assist if
  there was need for it.

Steve
-- 


pgpVrvHIYtBXb.pgp
Description: PGP signature

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Pierre THIERRY]

> You think wrong. The user should be able to choose whether the power
> button triggers shutdown or suspend to disk, for instance.

But one shouldn't have to edit a shell script to do it. It should just
be necessary to edit a configuration file. Like modifying the action
value to something like /usr/sbin/poweroff or /usr/sbin/suspend-to-disk

Surely,
le Moine Fou
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


pgpgqzVk71oL5.pgp
Description: PGP signature

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 08:45:16PM +1000, Herbert Xu wrote:

> Joey Hess <[EMAIL PROTECTED]> wrote:
> > 
> > I also think it would be a good idea for policy to require all
> > setuid/gid bit grants to go through this or another list for peer
> > review, much as pre-depends are supposed to.
> 
> How about creating a new group for each game?

This is only somewhat better, from a security perspective, than sharing a
group, depending on how many games are installed on the system.

-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote:

> what's wrong with a low-priority debconf question with a sane default?

As long as the sane default is the safe default, which is not to be setgid.

-- 
 - mdz

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Thu, Jul 31, 2003 at 06:37:53PM +0100, Steve Kemp wrote:

> On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote:
> 
> > I'd like to see us move all of our setgid games (except, perhaps,
> > nethack) away from using global score files by default. 
> 
>   I think that should be a good option, but I can see several 
>  games that might suffer by it.
> 
>   I'm loath to ask the user if it should be setgid in the installer
>  because that's just needless distraction, but perhaps some global
>  'setgidnes' setting could be stored in /etc/games?

Personally, I would lean more towards having a setgid helper which writes to
the game's score file.  It is possible to audit such helpers completely in a
short amount of time, and I feel that it would be far better to open
ourselves up to letting users forge their own high scores than to the
current exposures which are possible through group games.

-- 
 - mdz

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Matthew Garrett]

Pierre THIERRY wrote:

>I don't think the script is meant to be edited... So it should be in
>/usr/sbin.

You think wrong. The user should be able to choose whether the power
button triggers shutdown or suspend to disk, for instance.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: setuid/setgid binaries contained in the Debian repository.

[Matt Zimmerman]

On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote:

> I also think it would be a good idea for policy to require all setuid/gid
> bit grants to go through this or another list for peer review, much as
> pre-depends are supposed to.

I absolutely support this idea.  All set[ug]id setups should be reviewed
before they go in the archive, and I volunteer to do the review (though I
hope that others will help).  Does this need a proposal to go into policy
with the same force as the existing pre-depends verbiage?

-- 
 - mdz

Re: CUPS should be the default print service in Debian/Sarge

[Joey Hess]

Keegan Quinn wrote:
> FWIW, I've had very good experiences with the CUPS in unstable, so
> I'd not object to this.  OTOH, installing it without it being 'default'
> is already quite trivial.  What would this change entail, exactly?

Probably making the print server task install it instead of lpr, which
would have a side effect of making sure it's on CD#1 if it's not
already. Probably also demoting the lpr package to optional and moving
cups from there to standard. Possibly making lsb depend on part of cups
instead of lpr.

-- 
see shy jo, following this discussion with interest and his tasksel hat on


pgppk4AHwmPay.pgp
Description: PGP signature

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Cajus Pollmeier]

On Freitag, 1. August 2003 15:31, David Z Maze wrote:
> Cajus Pollmeier <[EMAIL PROTECTED]> writes:
> > On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote:
> >> Severity: serious
> >> Justification: Policy 9.1.1
>
> ("Debian should obey the FHS"; I don't claim to be an FHS expert, but
> all it seems to say about /etc is "no binaries", which this doesn't
> violate.)
>
> >> The shell script /etc/acpi/powerbtn.sh should be installed in something
> >> else, like /usr/share/acpid/ or /usr/sbin/.
> >
> > I've no problem with that, but:
> >
> > These scripts used by acpid should be treated as some kind of user
> > configuration, like i.e. cron keeps skripts installed by someone in
> > /etc/cron.daily, acpid keeps skripts that take actions when some
> > events happened.
>
> Is this "script that gets run when the console user presses the power
> button", and is it obvious that the user could potentially want to
> configure it?  If so, then it makes sense that it should be a
> configuration file, and so by policy 10.7.2 it should live in /etc.
> (And as you point out, it's not like there aren't other admin-editable
> scripts in /etc already, say, all of /etc/init.d.)  My reading is that
> what you're doing now is fine and the bug is wrong.

So in case of a "power down" script, this may be somewhat fixed in its
task. This would be true. But this script must not be the only one. Maybe
the user wants to place a script for i.e. closing the LID or do special
reactions on suspend events etc.

In my understanding /etc/acpid is the correct place for that. So, I changed
the serevity of the bug. I'm just off to vacations tomorrow - will look into 
this
when I'm back.

Thanks,
Cajus

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Pierre THIERRY]

> I think at least the RCness of this bug is rather dubious, frankly. If
> the script is configuration

I don't think the script is meant to be edited... So it should be in
/usr/sbin.

Quickly,
le Moine Fou
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


pgpjHl0gN4jh5.pgp
Description: PGP signature

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[David Z Maze]

Cajus Pollmeier <[EMAIL PROTECTED]> writes:

> On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote:
>> Severity: serious
>> Justification: Policy 9.1.1

("Debian should obey the FHS"; I don't claim to be an FHS expert, but
all it seems to say about /etc is "no binaries", which this doesn't
violate.)

>> The shell script /etc/acpi/powerbtn.sh should be installed in something
>> else, like /usr/share/acpid/ or /usr/sbin/.

> I've no problem with that, but:
>
> These scripts used by acpid should be treated as some kind of user
> configuration, like i.e. cron keeps skripts installed by someone in
> /etc/cron.daily, acpid keeps skripts that take actions when some
> events happened.

Is this "script that gets run when the console user presses the power
button", and is it obvious that the user could potentially want to
configure it?  If so, then it makes sense that it should be a
configuration file, and so by policy 10.7.2 it should live in /etc.
(And as you point out, it's not like there aren't other admin-editable
scripts in /etc already, say, all of /etc/init.d.)  My reading is that
what you're doing now is fine and the bug is wrong.

-- 
David Maze [EMAIL PROTECTED]  http://people.debian.org/~dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
-- Abra Mitchell

Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from

[Evan Prodromou]

> "CB" == Christoph Berg <[EMAIL PROTECTED]> writes:

CB> If you are both a DD and upstream, why didn't you package it
CB> yourself?

Good question. Installing Pigdog DeCSS in somebody's Debian system
doesn't really meet my goals for the software. The original point was
to have mirrors around the world, and to distract from the witch hunt
for DVD DeCSS. A /usr/bin/decss install doesn't really do that much.

I was happy to see someone ITP the software, but I probably wouldn't
do it myself.

~ESP

-- 
Evan Prodromou
[EMAIL PROTECTED]

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Colin Watson]

On Fri, Aug 01, 2003 at 02:09:36PM +0200, Cajus Pollmeier wrote:
> On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote:
> > Package: acpid
> > Version: N/A; reported 2003-07-31
> > Severity: serious
> > Justification: Policy 9.1.1
> >
> > The shell script /etc/acpi/powerbtn.sh should be installed in something
> > else, like /usr/share/acpid/ or /usr/sbin/.
> 
> I've no problem with that, but:
> 
> These scripts used by acpid should be treated as some kind of user
> configuration, like i.e. cron keeps skripts installed by someone in
> /etc/cron.daily, acpid keeps skripts that take actions when some
> events happened.
> 
> I've no idea about the exact handling of this issue. Should I move
> these scripts to /usr/share/acpid or /usr/sbin?

I think at least the RCness of this bug is rather dubious, frankly. If
the script is configuration (i.e. is human-editable and is expected to
be edited by a reasonable number of people to configure acpid in some
different way without having to hack acpid's source) then it should stay
in /etc. The FHS doesn't forbid that, and if people really are editing
it then it should definitely not be in /usr.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Ayuda

[Klipodi Anstro]

Nesecitaria los driver de la placa de red
Cnet Pro200 PCI fast Ethernet Adapter
Desde ya muchas graciasInternet GRATIS es Yahoo! Conexión.
Usuario: yahoo; contraseña: yahoo
Desde Buenos Aires: 4004-1010
Más ciudades: clic aquí.

Re: Data loss: suggestions for handling

[Stephen Frost]

* Matthew Palmer ([EMAIL PROTECTED]) wrote:
>   - dump the old software tables and store the dump somewhere, giving
>   pointers to the dump in all sorts of useful places.  But if I put it
>   somewhere temporary (/tmp), it might disappear before the admin
>   realises, and somewhere permanent will chew disk space.

/var/backups.  Tell the admin, if they want to clean it up they can.

Stephen


pgpIQ1XH72vze.pgp
Description: PGP signature

Bug#203768: RFP: sixpack -- Bibliography and Reference Manager

[Daniel Martins]

Package: wnpp
Severity: wishlist

* Package name: sixpack
  Version : 0.99
  Upstream Author :  Apparently Michael Lachmann http://www.santafe.edu/~dirk/
* URL or Web page : http://www.santafe.edu/~dirk/sixpack/
* License : GPL
  Description : Bibliography and Reference Manager


SIXPACK is a free BibTeX and Reference Manager designed to

* edit, convert and manage reference files
* search and sort bibliographies
* import and export many different bibliography types. Sixpack uses the 
excelent

* have both a command line and a gui interface.
* work completely from the keyboard.
* be able to import references from the web, now even through 
"direct-download" using the bib-remote program.
* be able to open an article through an external viewer.

Re: debconf 2005 in Vienna, Austria

[Keith Dunwoody]

Riku Voipio wrote:
On Fri, Aug 01, 2003 at 08:32:57AM +0200, Christian Perrier wrote:
This is still quite rare. For instance, in french trains (TGV and
"Teoz", formerly known as "Corail"ie Intercity trains), electric
wires are only available in the most recent coaches and only in 1st
class usually.
 

From memory, they are a little bit more common in Germany but not too
much and certainly not in all IC trains, especially 2nd class.

IC2 trains in finland have electric sockets in 2nd class seats, As well
as GSM repeaters. Older trains have electric sockets in the corridor,
presumably not for public usage, but no sign forbidding to use them :)
Night trains usually have a socket for shavers, which can be rather
handy for charging purposes as well.
A quick grep on bahn.de says that ICE-T trains (presumably the most
expensive ones..) have power sockets for every seat. Anyone with
experience on german/austrian railroad?
 
I've only taken a few trains in Germany, but the night train I was on had a 
socket by each table (to share between 4 people).  Other than that, I've only 
been on the slow regional trains (which you wouldn't be taking anyway, but 
don't have sockets).  So I think batteries would be a good idea...

-- Keith

Re: debconf 2005 in Vienna, Austria

[Josip Rodin]

On Fri, Aug 01, 2003 at 02:06:48PM +0300, Riku Voipio wrote:
> A quick grep on bahn.de says that ICE-T trains (presumably the most
~
> expensive ones..) have power sockets for every seat. Anyone with
> experience on german/austrian railroad?
>  
> > So, IMHO, you'd better have long life batteries.. :-)
> 
> Yes. a debcamp of users would probably blow some fuse :)

Man, this discussion is begging for a musical intermezzo... :)

 o/~
   Let me see how hot you can get
   Then I'll turn up the amps, blow out the lights
  You're in darkness, then the mic ignites
  Glowin like it did before, but even more
 o/~

-- 
 2. That which causes joy or happiness.

Re: Bug#203588: acpid: Shell script has nothing to do in /etc

[Cajus Pollmeier]

On Donnerstag, 31. Juli 2003 07:24, Pierre THIERRY wrote:
> Package: acpid
> Version: N/A; reported 2003-07-31
> Severity: serious
> Justification: Policy 9.1.1
>
> The shell script /etc/acpi/powerbtn.sh should be installed in something
> else, like /usr/share/acpid/ or /usr/sbin/.
>
> -- System Information
> Debian Release: 3.0
> Architecture: i386
> Kernel: Linux imperatrice.arcanes 2.4.18-686 #1 Sun Apr 14 11:32:47 EST
> 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

I've no problem with that, but:

These scripts used by acpid should be treated as some kind of user
configuration, like i.e. cron keeps skripts installed by someone in 
/etc/cron.daily,
acpid keeps skripts that take actions when some events happened.

I've no idea about the exact handling of this issue. Should I move these
scripts to /usr/share/acpid or /usr/sbin?

Thanks for any hints,
Cajus

Re: CUPS should be the default print service in Debian/Sarge

[Mark Brown]

On Fri, Aug 01, 2003 at 02:49:59PM +0300, Lars Wirzenius wrote:

> Do we actually need a default print service at all? Mail is much more
> fundamental, for example, but lots of computers these days don't have a
> printer attached at all.

We needn't install a print service by default but if someone says that
want one we ought to have a default to offer them.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Data loss: suggestions for handling

[Roland Mas]

Matthew Palmer (2003-08-01 19:51:46 +1000) :

> The latest upstream version of a package I've begun to maintain,
> IRM, has a problem in that a portion of the data in the system
> (relating to software and licence assignment) can't be upgraded
> along with the rest of the database - the schema is totally
> different.

Do you have an upgrade script?  Like a set of SQL commands that will
convert from one schema to the other?  More importantly, do you have a
set of criteria to check that the upgrade went smoothly and is now
complete?  If so, then I've done that successfully.

> I've thought about it for a while, and I can't come up with any good
> way to make the change.  The best I've come up with so far is to put
> a question in the postinst which warns the user and allows them to
> continue if they're sure, or they can CTRL-C out and backup.  If
> it's running in non-interactive mode, the install aborts.  I really
> want to make sure the user doesn't lose all their data.

  I faced the same problems with sourceforge and gforge.

> A couple of questions:
>
> * Am I being too paranoid?

  Probably not.  Maybe some of your users won't mind too much if they
lose data, but most of them probably will.  Then there's the personal
pride in building a crash-proof system even if nobody notices.

> * Can anyone think of another way of handling this?  I can think of
> a couple of other ways:
>
>   - create an irm1.4 package, but that is, shall we say, ugly

  Ugly indeed.

>   - dump the old software tables and store the dump somewhere,
>   giving pointers to the dump in all sorts of useful places.

  Could be an option.

> I appreciate any comments or suggestions anyone has as to how I
> could proceed.

  The way I did it for the sourceforge and gforge packages is this: I
have a special table (called debian_metadata), in which I can store
key-value pairs.  One of the keys (okay, the only one normally) is
"db-version", and the corresponding value is a version number with the
same semantics as the one provided by dpkg for the ordering).  When I
need to upgrade something, I go the following steps:

,[ One upgrade chunk ]
| Begin transaction
| Do stuff
| Check that stuff went fine (and raise an exception/abort if not)
| Update the value for db-version
| Commit transaction
`

This is of course only executed if current db-version is less than
targeted version.  So I have a series of upgrade chunks, arranged like
this:

,[ Upgrade script ]
| $target version = 1.0
| if (current-version < $target-version) {
|Do the upgrade chunk for target=$target-version
| }
| 
| $target version = 1.1
| if (current-version < $target-version) {
|Do the upgrade chunk for target=$target-version
| }
| 
| $target version = 1.4
| if (current-version < $target-version) {
|Do the upgrade chunk for target=$target-version
| }
`

  The postinst script always runs this upgrade script.  So all the
steps that were previously completed are not replayed, and you'll
start at the first one that hasn't been successfully run yet.  If one
step fails, the transaction is aborted and the user is presented with
an error message giving out info such as the current db-version, the
SQL statement that went wrong, and so on.  And he's requested to
report the bug with this info :-)

  All this requires a transactional database, obviously, but they're a
dime a dozen these days.

  For more details, apt-get source gforge and have a look at the
deb-specific/db-upgrade.pl script.

Roland.
-- 
Roland Mas

You can't second-guess ineffability, I always say.
  -- Aziraphale, in Good Omens (Terry Pratchett and Neil Gaiman)

Re: CUPS should be the default print service in Debian/Sarge

[Lars Wirzenius]

On pe, 2003-08-01 at 12:32, Luca - De Whiskey's - De Vitis wrote:
> It is a good solution for any user level with most common printers/needs, 
> thus it
> should be the default (IMHO).

Do we actually need a default print service at all? Mail is much more
fundamental, for example, but lots of computers these days don't have a
printer attached at all.

-- 
Debian developers for gentleness.