drbd-modules-i386

[David Krovich]

I've been working on a source package to build binary drbd module debs
against stock debian kernels.  See #244290 in the BTS for more
information. I modeled things after the alsa-modules-i386 source
package and after a long struggle I have my first working version.  I
would appreciate feedback on what I can do to fix this package up so I
can submit it into Debian.  You can grab the source from:

http://www.csee.wvu.edu/~dkrovich/debian-devel/drbd-modules-i386

drbd-modules-i386

[David Krovich]

I've been working on a source package to build binary drbd module debs
against stock debian kernels.  See #244290 in the BTS for more
information. I modeled things after the alsa-modules-i386 source
package and after a long struggle I have my first working version.  I
would appreciate feedback on what I can do to fix this package up so I
can submit it into Debian.  You can grab the source from:

http://www.csee.wvu.edu/~dkrovich/debian-devel/drbd-modules-i386


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

Re: reporting FTBFS bugs

[Nathanael Nerode]

Adeodato Simó wrote:

>   hi,
> 
> I have some questions regarding FTBFS bugs. Sorry if they seem too
> naive but I'm always afraid of doing something wrong and I thought
> I'd better ask here then.
> 
>   1. if a package fails in any buildd machine, thats a FTBFS bug per
>  se, right?
Uuuusually.  If it failed because the buildd admin killed it, it's not.

>   2. who can/should report FTBFS bugs when they occur in a buildd
>  machine? I've mostly seen them reported by the buildd's admin,
>  but cyrus-sasl2-mit failed on arm more than a month ago [1] (but
>  I noticed today) and there has been no bug report.
I report them a lot.

>   3. is it tracked anywhere (other than the bug report, non-existant
>  in this case) if this is being worked on?
Nope.

>  Having a month 
>  passed, I'd assume that the maintainer isn't aware of this, but
>  I really can't tell.
> 
> So I'm mainly asking if it is OK to file the bug myself, and if
> that should be reported elsewhere.
> 
>   TIA and sorry for the annoyance,
> 
> 
>   [1] http://buildd.debian.org/build.php?arch=arm&pkg=cyrus-sasl2-mit
> 

-- 
There are none so blind as those who will not see.

subscribe

[Alberto Rodriguez Galdo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


- -- 
Alberto Rodriguez Galdo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAvl8GwlFDGnR6dHkRAsLTAKCuElFvjy3+w9bGUaQupqC0tZAJpwCgh9Lk
mUBmn4om6DRljhesFJupzTM=
=Nc4I
-END PGP SIGNATURE-

Re: reporting FTBFS bugs

[Nathanael Nerode]

Adeodato Simà wrote:

>   hi,
> 
> I have some questions regarding FTBFS bugs. Sorry if they seem too
> naive but I'm always afraid of doing something wrong and I thought
> I'd better ask here then.
> 
>   1. if a package fails in any buildd machine, thats a FTBFS bug per
>  se, right?
Uuuusually.  If it failed because the buildd admin killed it, it's not.

>   2. who can/should report FTBFS bugs when they occur in a buildd
>  machine? I've mostly seen them reported by the buildd's admin,
>  but cyrus-sasl2-mit failed on arm more than a month ago [1] (but
>  I noticed today) and there has been no bug report.
I report them a lot.

>   3. is it tracked anywhere (other than the bug report, non-existant
>  in this case) if this is being worked on?
Nope.

>  Having a month 
>  passed, I'd assume that the maintainer isn't aware of this, but
>  I really can't tell.
> 
> So I'm mainly asking if it is OK to file the bug myself, and if
> that should be reported elsewhere.
> 
>   TIA and sorry for the annoyance,
> 
> 
>   [1] http://buildd.debian.org/build.php?arch=arm&pkg=cyrus-sasl2-mit
> 

-- 
There are none so blind as those who will not see.

subscribe

[Alberto Rodriguez Galdo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


- -- 
Alberto Rodriguez Galdo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAvl8GwlFDGnR6dHkRAsLTAKCuElFvjy3+w9bGUaQupqC0tZAJpwCgh9Lk
mUBmn4om6DRljhesFJupzTM=
=Nc4I
-END PGP SIGNATURE-

Package review and comment wanted

[Bengt Thuree]

Hej

I have just created one of my first debian package, and would like to 
have some comments on the actual packaging.


Have I missed something?
I am very confused of
*) Should I only use the rules file, or a separate Makefile
*) Should I list all the directories in the dirs (including /usr/sbin)
*) Should I list the conffiles in a separate conffile?
*) How do I automatically set the version number and perhaps a timestamp 
in the program during packaging?

*) Anything else I have missed?

My package is passing through Lintian anway, and I seem to be able to 
install, upgrade, remove and --purge it without anyproblems.


My package can be fetched from www.thuree.com/debian/buppo or by simply 
have the following in the apt.sources

deb http://www.thuree.com/debian buppo/
deb-src http://www.thuree.com/debian buppo/

Extract from the Packages file
Description: A simple file system backup program that uses afio and tar
 This package is a simple solution for backing up a number of servers
 and/or work stations in a cheap way.
 buppo has the following features
 1) Handles a full backup according to a configuration file
 2) Possible to skip directories/files
 3) Handles multiple configuration files
 4) Stores each backup in a dump directory
 5) Links to the dump directory from day, week, month, quarter, year 
backups

 6) Specifies how many backups should be saved per period
 7) Handles incremental backup relative to the last full backup
 8) Handles incremental backup relative to the last incremental backup
 9) Executes user scripts before the backup is started
 10) A server can fetch all unfetched backups from not_fetched directory
 11) Stores the list of Debian packages which are currently installed

Thanks in advance

/Bengt

Re: Becoming Maintainer of Cinelerra

[Jure Cuhalev]

On sre, 2004-06-02 at 05:32 -0700, Loren M. Lang wrote:
> This is my first attempt at making a debian package, but just about
> every other program I use already has a debian package.  Though I
> have done a couple of rpm packages before.
> 

Consider helping with improving unofficial cinelerra debs and maybe you
can figure out how to fix legal and technical problems and get them into
debian. They also may be a good base to start with:

deb http://www.kiberpipa.org/~minmax/cinelerra/builds/sid ./
deb-src http://www.kiberpipa.org/~minmax/cinelerra/builds/sid ./

(you'll also need:
deb ftp://ftp.nerim.net/debian-marillat/ unstable main
)


-- 
kind regards

Jure Cuhalev
[EMAIL PROTECTED]

Package review and comment wanted

[Bengt Thuree]

Hej
I have just created one of my first debian package, and would like to 
have some comments on the actual packaging.

Have I missed something?
I am very confused of
*) Should I only use the rules file, or a separate Makefile
*) Should I list all the directories in the dirs (including /usr/sbin)
*) Should I list the conffiles in a separate conffile?
*) How do I automatically set the version number and perhaps a timestamp 
in the program during packaging?
*) Anything else I have missed?

My package is passing through Lintian anway, and I seem to be able to 
install, upgrade, remove and --purge it without anyproblems.

My package can be fetched from www.thuree.com/debian/buppo or by simply 
have the following in the apt.sources
deb http://www.thuree.com/debian buppo/
deb-src http://www.thuree.com/debian buppo/

Extract from the Packages file
Description: A simple file system backup program that uses afio and tar
 This package is a simple solution for backing up a number of servers
 and/or work stations in a cheap way.
 buppo has the following features
 1) Handles a full backup according to a configuration file
 2) Possible to skip directories/files
 3) Handles multiple configuration files
 4) Stores each backup in a dump directory
 5) Links to the dump directory from day, week, month, quarter, year 
backups
 6) Specifies how many backups should be saved per period
 7) Handles incremental backup relative to the last full backup
 8) Handles incremental backup relative to the last incremental backup
 9) Executes user scripts before the backup is started
 10) A server can fetch all unfetched backups from not_fetched directory
 11) Stores the list of Debian packages which are currently installed

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

Re: setgid-wrapper

[Jay Berkenbilt]

>   My understanding of the position of Bob and Mike can be summed up as,
>   "in general, shell script's can't be made to use setuid/setgid
>   securely".  Basically, the problem comes down that a user can manipulate
>   their PATH to redefining basic commands that are used by the shell
>   scripts (like "ls") in order to elevate their privileges.
>
>   I'm not willing to give up on the basic idea yet, however, as I still
>   need to run a Java program setgid to "games" to handle a score history
>   file.  Similarly, I hope to one day run a Java application server (e.g.
>   Tomcat, JBoss, or Geronimo) setuid to some system id.  Therefore I
>   humbly request your comments on how to salvage this idea.  Please keep
>   in mind that "/usr/bin/java" is, itself, almost certainly a script.

I missed the original discussion, so I risk saying something someone
has already said.  My strategy for dealing with setuid/setgid shell
scripts in general is always to use sudo (which mdz mentioned as an
example of controlling elevation of privileges).  I abandoned wrappers
in favor of this long ago.  sudo is easy to set up, and it explicitly
moves responsibility to the local administrator.  My standard approach
is to name my script whatever.real and have a wrapper that runs sudo.
For example, I allow certain users on some of my systems to create
accounts with adduser.  I have renamed adduser to adduser.real and
created the following adduser script:

#!/bin/sh
echo "If prompted, enter your password to enter user creation program."
exec sudo $0.real ${1+"$@"}

Use of $0.real here is okay because the sudoers file has the full path
to the program that the user is authorized to run.  (Anyway, the user
can always run sudo by hand.)  I also set the permissions on the
whatever.real script to 0750 or 0700.  Now if I want to control this
with a group or just a list of authorized users, I can do that in
sudoers.  Although my home-written adduser script could certainly be
exploited by a knowledgeable user, I trust the people who are
authorized to create accounts on my systems, so I'm willing to accept
that risk in this instance.

As for the specific example of writing to a high scores file, I would
assert that this functionality is not essential to the proper
functioning of the game, and you should make the game work with or
without this functionality.  That way, if whatever strategy you choose
for updating the high scores file is overridden by the local
administrator, the game will still work.  I wouldn't make the whole
game setgid just so it can write to its high score file.  I would do
one of two things instead: make the high score file world-writable and
put it in a non-world-writable directory (some may object to
world-writable files on a system partition), or create a separate
program that your main program communicates to whose sole purpose in
life is to update the high scoring program.  This can be a normal
compiled C or C++ program.  You can create a debconf question that
explains to the installer that this component of the application needs
to be installed setgid games to update its high scoring file and ask
the user whether to do this, explaining the potential security risks,
and have the default be "no".  You can look at man-db
(dpkg-reconfigure man-db) for example of how you might want to word
this.

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/

Re: Becoming Maintainer of Cinelerra

[Jure Cuhalev]

On sre, 2004-06-02 at 05:32 -0700, Loren M. Lang wrote:
> This is my first attempt at making a debian package, but just about
> every other program I use already has a debian package.  Though I
> have done a couple of rpm packages before.
> 

Consider helping with improving unofficial cinelerra debs and maybe you
can figure out how to fix legal and technical problems and get them into
debian. They also may be a good base to start with:

deb http://www.kiberpipa.org/~minmax/cinelerra/builds/sid ./
deb-src http://www.kiberpipa.org/~minmax/cinelerra/builds/sid ./

(you'll also need:
deb ftp://ftp.nerim.net/debian-marillat/ unstable main
)


-- 
kind regards

Jure Cuhalev
[EMAIL PROTECTED]


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

Re: setgid-wrapper

[Jay Berkenbilt]

>   My understanding of the position of Bob and Mike can be summed up as,
>   "in general, shell script's can't be made to use setuid/setgid
>   securely".  Basically, the problem comes down that a user can manipulate
>   their PATH to redefining basic commands that are used by the shell
>   scripts (like "ls") in order to elevate their privileges.
>
>   I'm not willing to give up on the basic idea yet, however, as I still
>   need to run a Java program setgid to "games" to handle a score history
>   file.  Similarly, I hope to one day run a Java application server (e.g.
>   Tomcat, JBoss, or Geronimo) setuid to some system id.  Therefore I
>   humbly request your comments on how to salvage this idea.  Please keep
>   in mind that "/usr/bin/java" is, itself, almost certainly a script.

I missed the original discussion, so I risk saying something someone
has already said.  My strategy for dealing with setuid/setgid shell
scripts in general is always to use sudo (which mdz mentioned as an
example of controlling elevation of privileges).  I abandoned wrappers
in favor of this long ago.  sudo is easy to set up, and it explicitly
moves responsibility to the local administrator.  My standard approach
is to name my script whatever.real and have a wrapper that runs sudo.
For example, I allow certain users on some of my systems to create
accounts with adduser.  I have renamed adduser to adduser.real and
created the following adduser script:

#!/bin/sh
echo "If prompted, enter your password to enter user creation program."
exec sudo $0.real ${1+"$@"}

Use of $0.real here is okay because the sudoers file has the full path
to the program that the user is authorized to run.  (Anyway, the user
can always run sudo by hand.)  I also set the permissions on the
whatever.real script to 0750 or 0700.  Now if I want to control this
with a group or just a list of authorized users, I can do that in
sudoers.  Although my home-written adduser script could certainly be
exploited by a knowledgeable user, I trust the people who are
authorized to create accounts on my systems, so I'm willing to accept
that risk in this instance.

As for the specific example of writing to a high scores file, I would
assert that this functionality is not essential to the proper
functioning of the game, and you should make the game work with or
without this functionality.  That way, if whatever strategy you choose
for updating the high scores file is overridden by the local
administrator, the game will still work.  I wouldn't make the whole
game setgid just so it can write to its high score file.  I would do
one of two things instead: make the high score file world-writable and
put it in a non-world-writable directory (some may object to
world-writable files on a system partition), or create a separate
program that your main program communicates to whose sole purpose in
life is to update the high scoring program.  This can be a normal
compiled C or C++ program.  You can create a debconf question that
explains to the installer that this component of the application needs
to be installed setgid games to update its high scoring file and ask
the user whether to do this, explaining the potential security risks,
and have the default be "no".  You can look at man-db
(dpkg-reconfigure man-db) for example of how you might want to word
this.

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/


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

Re: Becoming Maintainer of Cinelerra

[Florian Ernst]

Hello!

On Wed, Jun 02, 2004 at 05:32:09AM -0700, Loren M. Lang wrote:
> I would like to become a maintainer of a debian package for the
> cinelerra video editting software .
> I haven't seen any reference to any other effort or past effort for
> this software so I'm willing to take it up.

Is it still plagued by legally uncertain components as outlined in
?

Cheers,
Flo


signature.asc
Description: Digital signature

Re: Becoming Maintainer of Cinelerra

[Bartosz Fenski aka fEnIo]

On Wed, Jun 02, 2004 at 05:32:09AM -0700, Loren M. Lang wrote:

[...]

> Cinelerra includes a lot of libraries in it that are available
> externally like libavc1394.  Most of the libraries are already
> available as debian packages and are the same versions provided in
> unstable, but most are at least close to the same version.
> libraw1394 version 0.9.0 is in the cinelerra and version 0.10.1 is
> in unstable.  Should I remove them from the cinelerra source code
> and use the version in debian?  Also, if I do so, then that will
> leave me with a huge diff file removing a lot of code from the
> original tarball, should I just find a way to disable them or
> slightly modify the original tarball just to remove those libraries?

I think there is no need to include those libraries in upstream tarball.
Consider that I'm not DD, but probably the best solution would be to
extract their tarball and remove those libraries, then tar-gzip it again
an start packaging. If their autotools/makefile's use those included
libraries then patching it to use Debian versions would be nice.

[...]

regards
fEnIo

-- 
  _  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | 
IRC:fEnIo
_|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
(0 0)  phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo  http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Becoming Maintainer of Cinelerra

[Loren M. Lang]

I would like to become a maintainer of a debian package for the
cinelerra video editting software .
I haven't seen any reference to any other effort or past effort for
this software so I'm willing to take it up.  There are rpm packages
for cinelerra provided directly by the developers of it.  I've used
alien to install them, but I'd prefer to be able to apt-get them
straight from a debian mirror.
B

This is my first attempt at making a debian package, but just about
every other program I use already has a debian package.  Though I
have done a couple of rpm packages before.

Cinelerra includes a lot of libraries in it that are available
externally like libavc1394.  Most of the libraries are already
available as debian packages and are the same versions provided in
unstable, but most are at least close to the same version.
libraw1394 version 0.9.0 is in the cinelerra and version 0.10.1 is
in unstable.  Should I remove them from the cinelerra source code
and use the version in debian?  Also, if I do so, then that will
leave me with a huge diff file removing a lot of code from the
original tarball, should I just find a way to disable them or
slightly modify the original tarball just to remove those libraries?

cinelerra has alsa-lib, audiofile, esound, freetype, libavc1394,
libmpeg3, libraw1394, libsndfile, quicktime, tiff, toolame, libvorbis,
libogg, libdv, ffmpeg, and probably some I've missed.
-- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.

Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD  835A FAF3 7A46 E4A3 280C
 


pgpMbsnGResnP.pgp
Description: PGP signature

stop overpaying for your medications such as lipitor and celebrex

[Darcy Costanza]

This little-known pharmacy site is becoming one of the most popular
destinations for cost-conscious consumers.

Popular Meds at Deep Discounts at this fast-growing site.

Be a man, and place your order.

Sincerely,
Sofia Riggio

http://rd.yahoo.com/Liuo/Sxf/*http://www.lowcostgeneric.com






If you are not planning to use this type of service in the future, press
this line:
http://g.msn.com/0US!s9.Xpho/MY.Tjod?http://lowcostgeneric.com

Re: Becoming Maintainer of Cinelerra

[Florian Ernst]

Hello!

On Wed, Jun 02, 2004 at 05:32:09AM -0700, Loren M. Lang wrote:
> I would like to become a maintainer of a debian package for the
> cinelerra video editting software .
> I haven't seen any reference to any other effort or past effort for
> this software so I'm willing to take it up.

Is it still plagued by legally uncertain components as outlined in
?

Cheers,
Flo


signature.asc
Description: Digital signature

Re: Becoming Maintainer of Cinelerra

[Bartosz Fenski aka fEnIo]

On Wed, Jun 02, 2004 at 05:32:09AM -0700, Loren M. Lang wrote:

[...]

> Cinelerra includes a lot of libraries in it that are available
> externally like libavc1394.  Most of the libraries are already
> available as debian packages and are the same versions provided in
> unstable, but most are at least close to the same version.
> libraw1394 version 0.9.0 is in the cinelerra and version 0.10.1 is
> in unstable.  Should I remove them from the cinelerra source code
> and use the version in debian?  Also, if I do so, then that will
> leave me with a huge diff file removing a lot of code from the
> original tarball, should I just find a way to disable them or
> slightly modify the original tarball just to remove those libraries?

I think there is no need to include those libraries in upstream tarball.
Consider that I'm not DD, but probably the best solution would be to
extract their tarball and remove those libraries, then tar-gzip it again
an start packaging. If their autotools/makefile's use those included
libraries then patching it to use Debian versions would be nice.

[...]

regards
fEnIo

-- 
  _  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo
_|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
(0 0)  phone:+48602383548 | Slackware - the weakest link
ooO--(_)--Ooo  http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Becoming Maintainer of Cinelerra

[Loren M. Lang]

I would like to become a maintainer of a debian package for the
cinelerra video editting software .
I haven't seen any reference to any other effort or past effort for
this software so I'm willing to take it up.  There are rpm packages
for cinelerra provided directly by the developers of it.  I've used
alien to install them, but I'd prefer to be able to apt-get them
straight from a debian mirror.
B

This is my first attempt at making a debian package, but just about
every other program I use already has a debian package.  Though I
have done a couple of rpm packages before.

Cinelerra includes a lot of libraries in it that are available
externally like libavc1394.  Most of the libraries are already
available as debian packages and are the same versions provided in
unstable, but most are at least close to the same version.
libraw1394 version 0.9.0 is in the cinelerra and version 0.10.1 is
in unstable.  Should I remove them from the cinelerra source code
and use the version in debian?  Also, if I do so, then that will
leave me with a huge diff file removing a lot of code from the
original tarball, should I just find a way to disable them or
slightly modify the original tarball just to remove those libraries?

cinelerra has alsa-lib, audiofile, esound, freetype, libavc1394,
libmpeg3, libraw1394, libsndfile, quicktime, tiff, toolame, libvorbis,
libogg, libdv, ffmpeg, and probably some I've missed.
-- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.

Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD  835A FAF3 7A46 E4A3 280C
 


pgp0s2waN6zEI.pgp
Description: PGP signature

Re: Need sponsor for wmshutdown & barrage

[Rafal Zawadzki]

Dnia 2004-06-02 11:06, Użytkownik Adam D. Barratt napisał:

> On Wednesday, June 02, 2004 9:43 AM, Rafal Zawadzki 
<[EMAIL PROTECTED]>

> wrote:
>
> Hi,
>
> I haven't had a chance to look at the actual packages, but:
>
>
>> Bug#251867: Acknowledgement (ITP: barrage -- Rather violent action
>> game)
>
>
> [...]
>
>>   Version :
>>   Upstream Author : Name <[EMAIL PROTECTED]>
>
>
>
> You might want to fix those. :-)


Uh, it is only in ITP ;(

>> wmshutdown (0.2-1) unstable; urgency=low
>>
>>  * New upstream release
>>  * Closes: #205604: Error in file /usr/lib/menu/wmshutdown
>
>
>
> * Fix error in /usr/lib/menu/wmshutdown (Closes: #205604)
>
dch --closes generated me that one...


>>  * Changed e-mail maintainer
>
>
>
>   * Change maintainer e-mail address
>
> (Changelog entries should be in the present tense, imo. I'm sure someone
> will yell if they disagree).


Fixed, thanks

> Looking at the current (rather old) version of the package in the 
archive,

> you might also want to check the Standards-Version of your new package.


3.6.1 - both of them.

Cheers,

--
# Rafal "bluszcz" Zawadzki - JabberPl.org sysadmin
# http://serwer.jabberpl.org - server homepage
# http://bluszcz.pl - my homepage, polish only
## ### ## ## #   #

stop overpaying for your medications such as lipitor and celebrex

[Darcy Costanza]

This little-known pharmacy site is becoming one of the most popular
destinations for cost-conscious consumers.

Popular Meds at Deep Discounts at this fast-growing site.

Be a man, and place your order.

Sincerely,
Sofia Riggio

http://rd.yahoo.com/Liuo/Sxf/*http://www.lowcostgeneric.com






If you are not planning to use this type of service in the future, press
this line:
http://g.msn.com/0US!s9.Xpho/MY.Tjod?http://lowcostgeneric.com


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

Re: Need sponsor for wmshutdown & barrage

[Adam D. Barratt]

On Wednesday, June 02, 2004 9:43 AM, Rafal Zawadzki <[EMAIL PROTECTED]>
wrote:

Hi,

I haven't had a chance to look at the actual packages, but:

> Bug#251867: Acknowledgement (ITP: barrage -- Rather violent action
> game)
[...]
>Version :
>Upstream Author : Name <[EMAIL PROTECTED]>

You might want to fix those. :-)

> wmshutdown (0.2-1) unstable; urgency=low
>
>   * New upstream release
>   * Closes: #205604: Error in file /usr/lib/menu/wmshutdown

* Fix error in /usr/lib/menu/wmshutdown (Closes: #205604)

>   * Changed e-mail maintainer

  * Change maintainer e-mail address

(Changelog entries should be in the present tense, imo. I'm sure someone
will yell if they disagree).

Looking at the current (rather old) version of the package in the archive,
you might also want to check the Standards-Version of your new package.

Adam

Need sponsor for wmshutdown & barrage

[Rafal Zawadzki]

Hello again, two things:

1. I've just rebuilt barrage package (Fenio - thanks for help), and I 
need sponsor to upload it:


Bug#251867: Acknowledgement (ITP: barrage -- Rather violent action game)

Package: wnpp
Severity: wishlist

* Package name: barrage
  Version :
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://lgames.sourceforge.net/
* License : GPL
  Description : Rather violent action game

 Barrage is a game with the objective to kill  and destroy
 as many targets as possible within 3 minutes. The player
 controls a gun that may either fire small or large grenades
 at  soldiers, jeeps and tanks. It is a very simple gameplay
 though it is not that easy to get high scores.

2. I've made new version of wmshutdown package, problem is the same as 
above (constructive criticism & sponsor for upload):


wmshutdown (0.2-1) unstable; urgency=low

  * New upstream release
  * Closes: #205604: Error in file /usr/lib/menu/wmshutdown
  * Changed e-mail maintainer
  * Pseudo manpages has been written



Packages are available at:

deb http://bluszcz.pl/debian/ unstable main
deb-src http://bluszcz.pl/debian/ unstable main


Cheers,

--
# Rafal "bluszcz" Zawadzki - JabberPl.org sysadmin
# http://serwer.jabberpl.org - server homepage
# http://bluszcz.pl - my homepage, polish only
## ### ## ## #   #

Re: RFS : sailcut - sail design and plotting software

[Jeremy Lainé]

> * Does it really have no command-line flags at all?  The manpage
> seems to say so.

So far there are no command-line flags, you can just specify the name
of a file to open. I still gave the manpage a bit of a polish as it
was really dry!

> * Have a look at
>   http://lists.debian.org/debian-legal/2003/12/msg00188.html, your
>   debian/copyright file should be a tad more detailed.

All right, I have fixed that as well.

I also added a Closes: #252041 in the changelog, I only intended to do
so once the package is actually sponsored :)

The corrected version of the package is available from
mentors.debian.net:

http://mentors.debian.net/debian/pool/main/s/sailcut/

Thanks for your input Rob!

Jeremy

-- 
http://www.jerryweb.org/ : JerryWeb.org
http://sailcut.sourceforge.net/  : Sailcut CAD
http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux

Re: Need sponsor for wmshutdown & barrage

[Rafal Zawadzki]

Dnia 2004-06-02 11:06, UÅytkownik Adam D. Barratt napisaÅ:
> On Wednesday, June 02, 2004 9:43 AM, Rafal Zawadzki 
<[EMAIL PROTECTED]>
> wrote:
>
> Hi,
>
> I haven't had a chance to look at the actual packages, but:
>
>
>> Bug#251867: Acknowledgement (ITP: barrage -- Rather violent action
>> game)
>
>
> [...]
>
>>   Version :
>>   Upstream Author : Name <[EMAIL PROTECTED]>
>
>
>
> You might want to fix those. :-)

Uh, it is only in ITP ;(
>> wmshutdown (0.2-1) unstable; urgency=low
>>
>>  * New upstream release
>>  * Closes: #205604: Error in file /usr/lib/menu/wmshutdown
>
>
>
> * Fix error in /usr/lib/menu/wmshutdown (Closes: #205604)
>
dch --closes generated me that one...
>>  * Changed e-mail maintainer
>
>
>
>   * Change maintainer e-mail address
>
> (Changelog entries should be in the present tense, imo. I'm sure someone
> will yell if they disagree).
Fixed, thanks
> Looking at the current (rather old) version of the package in the 
archive,
> you might also want to check the Standards-Version of your new package.

3.6.1 - both of them.
Cheers,
--
# Rafal "bluszcz" Zawadzki - JabberPl.org sysadmin
# http://serwer.jabberpl.org - server homepage
# http://bluszcz.pl - my homepage, polish only
## ### ## ## #   #
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Need sponsor for wmshutdown & barrage

[Adam D. Barratt]

On Wednesday, June 02, 2004 9:43 AM, Rafal Zawadzki <[EMAIL PROTECTED]>
wrote:

Hi,

I haven't had a chance to look at the actual packages, but:

> Bug#251867: Acknowledgement (ITP: barrage -- Rather violent action
> game)
[...]
>Version :
>Upstream Author : Name <[EMAIL PROTECTED]>

You might want to fix those. :-)

> wmshutdown (0.2-1) unstable; urgency=low
>
>   * New upstream release
>   * Closes: #205604: Error in file /usr/lib/menu/wmshutdown

* Fix error in /usr/lib/menu/wmshutdown (Closes: #205604)

>   * Changed e-mail maintainer

  * Change maintainer e-mail address

(Changelog entries should be in the present tense, imo. I'm sure someone
will yell if they disagree).

Looking at the current (rather old) version of the package in the archive,
you might also want to check the Standards-Version of your new package.

Adam


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

Need sponsor for wmshutdown & barrage

[Rafal Zawadzki]

Hello again, two things:
1. I've just rebuilt barrage package (Fenio - thanks for help), and I 
need sponsor to upload it:

Bug#251867: Acknowledgement (ITP: barrage -- Rather violent action game)
Package: wnpp
Severity: wishlist
* Package name: barrage
  Version :
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://lgames.sourceforge.net/
* License : GPL
  Description : Rather violent action game
 Barrage is a game with the objective to kill  and destroy
 as many targets as possible within 3 minutes. The player
 controls a gun that may either fire small or large grenades
 at  soldiers, jeeps and tanks. It is a very simple gameplay
 though it is not that easy to get high scores.
2. I've made new version of wmshutdown package, problem is the same as 
above (constructive criticism & sponsor for upload):

wmshutdown (0.2-1) unstable; urgency=low
  * New upstream release
  * Closes: #205604: Error in file /usr/lib/menu/wmshutdown
  * Changed e-mail maintainer
  * Pseudo manpages has been written

Packages are available at:
deb http://bluszcz.pl/debian/ unstable main
deb-src http://bluszcz.pl/debian/ unstable main
Cheers,
--
# Rafal "bluszcz" Zawadzki - JabberPl.org sysadmin
# http://serwer.jabberpl.org - server homepage
# http://bluszcz.pl - my homepage, polish only
## ### ## ## #   #
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS : sailcut - sail design and plotting software

[Jeremy Lainé]

> * Does it really have no command-line flags at all?  The manpage
> seems to say so.

So far there are no command-line flags, you can just specify the name
of a file to open. I still gave the manpage a bit of a polish as it
was really dry!

> * Have a look at
>   http://lists.debian.org/debian-legal/2003/12/msg00188.html, your
>   debian/copyright file should be a tad more detailed.

All right, I have fixed that as well.

I also added a Closes: #252041 in the changelog, I only intended to do
so once the package is actually sponsored :)

The corrected version of the package is available from
mentors.debian.net:

http://mentors.debian.net/debian/pool/main/s/sailcut/

Thanks for your input Rob!

Jeremy

-- 
http://www.jerryweb.org/ : JerryWeb.org
http://sailcut.sourceforge.net/  : Sailcut CAD
http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux


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

Re: setgid-wrapper

[Matt Zimmerman]

On Tue, Jun 01, 2004 at 11:21:23PM -0400, James Damour wrote:

> My understanding of the position of Bob and Mike can be summed up as, "in
> general, shell script's can't be made to use setuid/setgid securely".
> Basically, the problem comes down that a user can manipulate their PATH to
> redefining basic commands that are used by the shell scripts (like "ls")
> in order to elevate their privileges.

It's not impossible, it's just tricky, and the technique you chose has
already been implemented (in sudo).

-- 
 - mdz