Re: RFS schoolbell - A calenaring server for schools

[Russ Allbery]

Peter Karlsson <[EMAIL PROTECTED]> writes:
> Matthew Palmer:

>> I just had another thought -- make a -1 revision with an empty
>> diff. Weird, but I can't think of any reason why it wouldn't work...

> That usually works just fine, and it what I do when I release jwhois,
> since I have also been doing the upstream releases.

Yup, it works well for me too.

> This works fine when you can control the upstream releases. You just
> need to ensure that no upstream releases are made with incorrect or
> outdated debian subdirs, it's better to have such releases lack the
> debian subdir completely.

The way I handle things, as a release procedure, is that I'll release new
Debian-specific versions (-2, -3, etc.) when the changes are only in the
debian directory, but for anything that affects the rest of the package,
I'll release a new upstream version.  I figure that if it's important
enough to release a new Debian package, it's important enough to release a
new upstream release too, and just make it clear to people in the release
notes whether it's a bug fix they're likely to care about.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

RFS: kubication -- KDE network configuration selector

[Luciano Bello]

ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267685


I am not a Debian Developer, so I am looking for sponsorship.
My packages for the following are available at:
http://www.asciigirl.com/kubication/

It's my first complex package from the scratch . Plz, I need a sponsor
with lots of patience :P

Package: wnpp
Severity: wishlist

* Package name: kubication
  Version : 0.1b
  Upstream Author : [EMAIL PROTECTED]
* URL:http://www.kde-apps.org/content/show.php?content=14847
* License : GPL
  Description : KDE network configuration selector

Maintains network profiles allows switching between them with just one
click. Supports wireless devices, proxy servers, DNS, DHCP/static IP
addresses, importing kmail configuration, and many other options.

-- 
Luciano Bello <[EMAIL PROTECTED]>

RFS: kubication -- KDE network configuration selector

[Luciano Bello]

ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267685


I am not a Debian Developer, so I am looking for sponsorship.
My packages for the following are available at:
http://www.asciigirl.com/kubication/

It's my first complex package from the scratch . Plz, I need a sponsor
with lots of patience :P

Package: wnpp
Severity: wishlist

* Package name: kubication
  Version : 0.1b
  Upstream Author : [EMAIL PROTECTED]
* URL:http://www.kde-apps.org/content/show.php?content=14847
* License : GPL
  Description : KDE network configuration selector

Maintains network profiles allows switching between them with just one
click. Supports wireless devices, proxy servers, DNS, DHCP/static IP
addresses, importing kmail configuration, and many other options.

-- 
Luciano Bello <[EMAIL PROTECTED]>

Re: RFS schoolbell - A calenaring server for schools

[Russ Allbery]

Peter Karlsson <[EMAIL PROTECTED]> writes:
> Matthew Palmer:

>> I just had another thought -- make a -1 revision with an empty
>> diff. Weird, but I can't think of any reason why it wouldn't work...

> That usually works just fine, and it what I do when I release jwhois,
> since I have also been doing the upstream releases.

Yup, it works well for me too.

> This works fine when you can control the upstream releases. You just
> need to ensure that no upstream releases are made with incorrect or
> outdated debian subdirs, it's better to have such releases lack the
> debian subdir completely.

The way I handle things, as a release procedure, is that I'll release new
Debian-specific versions (-2, -3, etc.) when the changes are only in the
debian directory, but for anything that affects the rest of the package,
I'll release a new upstream version.  I figure that if it's important
enough to release a new Debian package, it's important enough to release a
new upstream release too, and just make it clear to people in the release
notes whether it's a bug fix they're likely to care about.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

RFS: kubication -- KDE network configuration selector

[Luciano Bello]

ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267685


I am not a Debian Developer, so I am looking for sponsorship.
My packages for the following are available at:
http://www.asciigirl.com/kubication/

It's my first complex package from the scratch . Plz, I need a sponsor
with lots of patience :P

Package: wnpp
Severity: wishlist

* Package name: kubication
  Version : 0.1b
  Upstream Author : [EMAIL PROTECTED]
* URL:http://www.kde-apps.org/content/show.php?content=14847
* License : GPL
  Description : KDE network configuration selector

Maintains network profiles allows switching between them with just one
click. Supports wireless devices, proxy servers, DNS, DHCP/static IP
addresses, importing kmail configuration, and many other options.

-- 
Luciano Bello <[EMAIL PROTECTED]>



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

RFS: kubication -- KDE network configuration selector

[Luciano Bello]

ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267685


I am not a Debian Developer, so I am looking for sponsorship.
My packages for the following are available at:
http://www.asciigirl.com/kubication/

It's my first complex package from the scratch . Plz, I need a sponsor
with lots of patience :P

Package: wnpp
Severity: wishlist

* Package name: kubication
  Version : 0.1b
  Upstream Author : [EMAIL PROTECTED]
* URL:http://www.kde-apps.org/content/show.php?content=14847
* License : GPL
  Description : KDE network configuration selector

Maintains network profiles allows switching between them with just one
click. Supports wireless devices, proxy servers, DNS, DHCP/static IP
addresses, importing kmail configuration, and many other options.

-- 
Luciano Bello <[EMAIL PROTECTED]>



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

Re: RFS: stress

[Amos Waterland]

Justin Pryzby wrote:
> Lintian complains:
> 
> ln -sf ../share/doc/stress /usr/doc/stress,

I have updated to current debhelper and incremented package version to 0.18.2:

 http://weather.ou.edu/~apw/projects/stress/#Debiandeb

Re: Problems with Provides/Replaces/Conflicts

[Matt Zimmerman]

On Thu, Sep 02, 2004 at 02:52:59PM +0200, Frank Küster wrote:

> Frank Küster <[EMAIL PROTECTED]> wrote:
> 
> > Does anybody have an idea why apt decides "Holding Back tetex-bin rather
> > than change dvipdfm"? 
> 
> It seems it's an apt bug; after I put the tetex stuff on hold and
> dist-upgrade the rest, it works fine.

It looks like tetex-bin obsoletes dvipdfm.  It should conflict, provide and
replace it.

-- 
 - mdz

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> > On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > > .so files?  Should it be libschoolbell and libschoolbell-dev?
> > 
> > Indeed.
> 
> These few .so files are imported from zope and maybe slightly modified.
> So there is probably no use for people to build against them. 
> Would a -dev be required?

Hrm, I suppose probably not..  The -dev is for header files (mainly,
really) and if there aren't any (because it's not meant to be built
against) then I suppose it's reasonable to not have one.

Make sure to figure out what kind of relationship there is between the
.so (Is it really .so, or .so.1.2.123 or something?) and the binaries
that link against it.  Do the versions have to match exactly?  How do
you handle ABI changes to the .so?

Stephen


signature.asc
Description: Digital signature

Re: RFS: stress

[Amos Waterland]

Justin Pryzby wrote:
> Lintian complains:
> 
> ln -sf ../share/doc/stress /usr/doc/stress,

I have updated to current debhelper and incremented package version to 0.18.2:

 http://weather.ou.edu/~apw/projects/stress/#Debiandeb


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

Re: Problems with Provides/Replaces/Conflicts

[Matt Zimmerman]

On Thu, Sep 02, 2004 at 02:52:59PM +0200, Frank Küster wrote:

> Frank Küster <[EMAIL PROTECTED]> wrote:
> 
> > Does anybody have an idea why apt decides "Holding Back tetex-bin rather
> > than change dvipdfm"? 
> 
> It seems it's an apt bug; after I put the tetex stuff on hold and
> dist-upgrade the rest, it works fine.

It looks like tetex-bin obsoletes dvipdfm.  It should conflict, provide and
replace it.

-- 
 - mdz


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

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> > On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > > .so files?  Should it be libschoolbell and libschoolbell-dev?
> > 
> > Indeed.
> 
> These few .so files are imported from zope and maybe slightly modified.
> So there is probably no use for people to build against them. 
> Would a -dev be required?

Hrm, I suppose probably not..  The -dev is for header files (mainly,
really) and if there aren't any (because it's not meant to be built
against) then I suppose it's reasonable to not have one.

Make sure to figure out what kind of relationship there is between the
.so (Is it really .so, or .so.1.2.123 or something?) and the binaries
that link against it.  Do the versions have to match exactly?  How do
you handle ABI changes to the .so?

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > .so files?  Should it be libschoolbell and libschoolbell-dev?
> 
> Indeed.

These few .so files are imported from zope and maybe slightly modified.
So there is probably no use for people to build against them. 
Would a -dev be required?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> .so files?  Should it be libschoolbell and libschoolbell-dev?

Indeed.

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

RFS: streamline

[Michael MacFadden]

All,

Hello, I have been having a hard time finding a sponsor for the 
streamline package.  I have never tired to get a package uploaded before 
and it is totally possible that I am being way to impatient.  Quite a 
few people have helped me out on this list by correcting some errors in 
my original package, however I am not sure if anyone is actually in 
interested in uploading the package for me.

Streamline a web-based streaming media server written in PHP4 Streamline 
is an web-base on-demand streaming media server.



The upstream home page is:  http://streamline.sourceforge.net
The deb package is available here:  http://www.macfadden.org/~mike/debian/


Currently, the package is lintian clean on my machine.  Running linda on 
the package gives this output:


W: streamline; /var/cache/streamline/.media_info_cache has a 
non-standard directory permission (0755:www-data/www-data).
W: streamline; /var/lib/streamline/.sqlitedb has a non-standard 
directory permission (0755:www-data/www-data).


However both of these directories need to be writable by the web server 
process since one contains the database files that store the 
configuration and the other is a cache that is maintained by the PHP 
scripts running in server.  A lot of PHP web apps do this in Debian 
(gallery, horde2, etc) so I think this is ok.  I have installed it on my 
local machine and it installs and runs just fine. 

If anyone is interested in sponsoring this let me know.  Or if you were 
already looking at it for me and I am just being impatient then tell me 
to cool my jets ;-).  I am a really interested in getting this uploaded 
cause several perspective end users have expressed that they use Debian 
and wish there were a package for it.  I am willing to work with a 
sponsor and will be very diligent in maintaining the package.  Thanks in 
advance.


Regards,
Michael MacFadden

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> > I agree with this.  Really, debian-native packages are debian-specific
> > packages.  I would strongly encourage you to *not* make this a
> > debian-native package.
> 
> Thanks to you and the others on the list, now that I understand 
> the situation better I realize that this makes my life *much* easier.
> 
> However, I have another question. I can move almost everything to 
> schoolbell-common, the only things that are left in the schoolbell
> package are a few .so files. Would it make more sense rather to 
> create a schoolbell-dep package with only the architecture few
> dependent files?
> 
> Would -dep be the right suffex?

.so files?  Should it be libschoolbell and libschoolbell-dev?

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

Thanks to you and the others on the list, now that I understand 
the situation better I realize that this makes my life *much* easier.

However, I have another question. I can move almost everything to 
schoolbell-common, the only things that are left in the schoolbell
package are a few .so files. Would it make more sense rather to 
create a schoolbell-dep package with only the architecture few
dependent files?

Would -dep be the right suffex?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Peter Karlsson]

Matthew Palmer:

I just had another thought -- make a -1 revision with an empty diff. 
Weird, but I can't think of any reason why it wouldn't work...


That usually works just fine, and it what I do when I release jwhois, since 
I have also been doing the upstream releases. The debian subdirectory is in 
the main cvs archive, but on a "hidden" branch. This means that if I am the 
one that release the upstream version, it gets a debian subdir, and the -1 
has an empty diff, but if the other maintainer releases it, it goes without 
a debian subdir, and the -1 will have a normal diff.


Any -2 will have a small diff adding the changes between -1 and -2.

This works fine when you can control the upstream releases. You just need to 
ensure that no upstream releases are made with incorrect or outdated debian 
subdirs, it's better to have such releases lack the debian subdir completely.


--
\\//
Peter - http://www.softwolves.pp.se/
  I do not read or respond to mail with HTML attachments.

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > .so files?  Should it be libschoolbell and libschoolbell-dev?
> 
> Indeed.

These few .so files are imported from zope and maybe slightly modified.
So there is probably no use for people to build against them. 
Would a -dev be required?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> .so files?  Should it be libschoolbell and libschoolbell-dev?

Indeed.

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

RFS: streamline

[Michael MacFadden]

All,
Hello, I have been having a hard time finding a sponsor for the 
streamline package.  I have never tired to get a package uploaded before 
and it is totally possible that I am being way to impatient.  Quite a 
few people have helped me out on this list by correcting some errors in 
my original package, however I am not sure if anyone is actually in 
interested in uploading the package for me.

Streamline a web-based streaming media server written in PHP4 Streamline 
is an web-base on-demand streaming media server.

The upstream home page is:  http://streamline.sourceforge.net
The deb package is available here:  http://www.macfadden.org/~mike/debian/
Currently, the package is lintian clean on my machine.  Running linda on 
the package gives this output:

W: streamline; /var/cache/streamline/.media_info_cache has a 
non-standard directory permission (0755:www-data/www-data).
W: streamline; /var/lib/streamline/.sqlitedb has a non-standard 
directory permission (0755:www-data/www-data).

However both of these directories need to be writable by the web server 
process since one contains the database files that store the 
configuration and the other is a cache that is maintained by the PHP 
scripts running in server.  A lot of PHP web apps do this in Debian 
(gallery, horde2, etc) so I think this is ok.  I have installed it on my 
local machine and it installs and runs just fine. 

If anyone is interested in sponsoring this let me know.  Or if you were 
already looking at it for me and I am just being impatient then tell me 
to cool my jets ;-).  I am a really interested in getting this uploaded 
cause several perspective end users have expressed that they use Debian 
and wish there were a package for it.  I am willing to work with a 
sponsor and will be very diligent in maintaining the package.  Thanks in 
advance.

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

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> > I agree with this.  Really, debian-native packages are debian-specific
> > packages.  I would strongly encourage you to *not* make this a
> > debian-native package.
> 
> Thanks to you and the others on the list, now that I understand 
> the situation better I realize that this makes my life *much* easier.
> 
> However, I have another question. I can move almost everything to 
> schoolbell-common, the only things that are left in the schoolbell
> package are a few .so files. Would it make more sense rather to 
> create a schoolbell-dep package with only the architecture few
> dependent files?
> 
> Would -dep be the right suffex?

.so files?  Should it be libschoolbell and libschoolbell-dev?

Stephen


signature.asc
Description: Digital signature

Re: RFS: stress

[Justin Pryzby]

It seems that this is really an RFS, because .debs are provided.
Lintian complains:

ln -sf ../share/doc/stress /usr/doc/stress,

a line which is

# Automatically added by dh_installdocs

Indeed, you appear to be using an old debhelper:

Build-Depends: debhelper (>> 3.0.0)

Topposting,
Justin

On Thu, Sep 02, 2004 at 12:36:38PM -0500, Amos Waterland wrote:
> Source: stress
> Section: devel
> Priority: optional
> Maintainer: Amos Waterland <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>> 3.0.0)
> Standards-Version: 3.5.9
> 
> Package: stress
> Architecture: any
> Depends: ${shlibs:Depends}
> Description: A tool which imposes stress on a system
>  'stress' is a tool which imposes a configurable amount of CPU, memory, I/O,
>  or disk stress on a POSIX-compliant operating system.  It is written in
>  highly-portable ANSI C, and uses the GNU Autotools to compile on a great
>  number of UNIX-like operating systems.
>  .
>  'stress' is not a benchmark.  It is a tool used by system administrators to
>  evaluate how well their systems will scale, by kernel programmers to evaluate
>  perceived performance characteristics, and by systems programmers to expose
>  the classes of bugs which only or more frequently manifest themselves when
>  the system is under heavy load.
> 
> Upstream home page:
>  http://weather.ou.edu/~apw/projects/stress/
> 
> Deb packages:
>  http://weather.ou.edu/~apw/projects/stress/#Debiandeb


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Frank Küster]

Brian Sutherland <[EMAIL PROTECTED]> wrote:

Subject: Re: RFS schoolbell - A calenaring server for schools

s/calenar/calendar/, or is this a new english word?

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

Thanks to you and the others on the list, now that I understand 
the situation better I realize that this makes my life *much* easier.

However, I have another question. I can move almost everything to 
schoolbell-common, the only things that are left in the schoolbell
package are a few .so files. Would it make more sense rather to 
create a schoolbell-dep package with only the architecture few
dependent files?

Would -dep be the right suffex?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

RFS: stress

[Amos Waterland]

Source: stress
Section: devel
Priority: optional
Maintainer: Amos Waterland <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 3.0.0)
Standards-Version: 3.5.9

Package: stress
Architecture: any
Depends: ${shlibs:Depends}
Description: A tool which imposes stress on a system
 'stress' is a tool which imposes a configurable amount of CPU, memory, I/O,
 or disk stress on a POSIX-compliant operating system.  It is written in
 highly-portable ANSI C, and uses the GNU Autotools to compile on a great
 number of UNIX-like operating systems.
 .
 'stress' is not a benchmark.  It is a tool used by system administrators to
 evaluate how well their systems will scale, by kernel programmers to evaluate
 perceived performance characteristics, and by systems programmers to expose
 the classes of bugs which only or more frequently manifest themselves when
 the system is under heavy load.

Upstream home page:
 http://weather.ou.edu/~apw/projects/stress/

Deb packages:
 http://weather.ou.edu/~apw/projects/stress/#Debiandeb

Re: RFS: viewglob [revised]

[Kevin B. McCarty]

I have added the viewglob.desktop file provided by Stefan Fritsch for a
konsole session, and fixed all the compiler warnings.  The new package
is at the same location as before.  Any takers for sponsoring viewglob?

deb-src http://borex.princeton.edu/~kmccarty/ unstable main

apt-get update
apt-get source viewglob

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544

Re: RFS schoolbell - A calenaring server for schools

[Peter Karlsson]

Matthew Palmer:
I just had another thought -- make a -1 revision with an empty diff. 
Weird, but I can't think of any reason why it wouldn't work...
That usually works just fine, and it what I do when I release jwhois, since 
I have also been doing the upstream releases. The debian subdirectory is in 
the main cvs archive, but on a "hidden" branch. This means that if I am the 
one that release the upstream version, it gets a debian subdir, and the -1 
has an empty diff, but if the other maintainer releases it, it goes without 
a debian subdir, and the -1 will have a normal diff.

Any -2 will have a small diff adding the changes between -1 and -2.
This works fine when you can control the upstream releases. You just need to 
ensure that no upstream releases are made with incorrect or outdated debian 
subdirs, it's better to have such releases lack the debian subdir completely.

--
\\//
Peter - http://www.softwolves.pp.se/
  I do not read or respond to mail with HTML attachments.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS schoolbell - A calenaring server for schools

[Matt Brubeck]

Stephen Frost wrote:

> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

I also agree.  I am both upstream and Debian maintainer for my package,
and I find that a non-native package has many advantages:

 * We don't need to make a new "upstream" tarball for changes that only
   affect Debian.

 * Each Debian package is clearly based on a specific, cross-platform
   upstream version.

 * Non-native packages make it slightly easier for other Debian
   developers to make changes and NMUs.

 * If the upstream source tarball contains the "official" Debian
   directory, users who compile their own versions from tarballs or CVS
   will generate .debs with the same versions as the official packages.

If you do want to maintain your "debian" directory in the upstream
source, I suggest you use one of these strategies:

 1. Maintain the debian directory in the upstream CVS, but strip it out
when you generate release tarballs.  Use the .diff.gz to restore it
in the Debian source package.

 2. Maintain the debian directory in the upstream source, but use
"unofficial" versions and control files.  Replace them with the
official versions in the .diff.gz.

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Kevin B. McCarty ([EMAIL PROTECTED]) wrote:
> Matthew Palmer wrote:
> 
> > I just had another thought -- make a -1 revision with an empty diff.  Weird,
> > but I can't think of any reason why it wouldn't work...
> 
> Why would the diff be empty?  I would think it should contain the debian
> subdir in any case.  It makes no sense to ship a debian directory in
> generic source code released for RedHat, Windows, etc. (it would just
> uselessly increase the tarball size) so it might as well go into the
> Debian-specific diff.gz.
> 
> Even as both upstream and maintainer, you (Brian Sutherland) might find
> it useful to keep Debian packaging stuff separate from the main body of
> code.  Then if there is a bug in debian/rules, or Debian Policy is
> updated to mandate some new control field, you don't have to release an
> entirely new tarball just to fix a Debian-specific issue.

I agree with this.  Really, debian-native packages are debian-specific
packages.  I would strongly encourage you to *not* make this a
debian-native package.

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Kevin B. McCarty]

Matthew Palmer wrote:

> I just had another thought -- make a -1 revision with an empty diff.  Weird,
> but I can't think of any reason why it wouldn't work...

Why would the diff be empty?  I would think it should contain the debian
subdir in any case.  It makes no sense to ship a debian directory in
generic source code released for RedHat, Windows, etc. (it would just
uselessly increase the tarball size) so it might as well go into the
Debian-specific diff.gz.

Even as both upstream and maintainer, you (Brian Sutherland) might find
it useful to keep Debian packaging stuff separate from the main body of
code.  Then if there is a bug in debian/rules, or Debian Policy is
updated to mandate some new control field, you don't have to release an
entirely new tarball just to fix a Debian-specific issue.

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544

Re: RFS: stress

[Justin Pryzby]

It seems that this is really an RFS, because .debs are provided.
Lintian complains:

ln -sf ../share/doc/stress /usr/doc/stress,

a line which is

# Automatically added by dh_installdocs

Indeed, you appear to be using an old debhelper:

Build-Depends: debhelper (>> 3.0.0)

Topposting,
Justin

On Thu, Sep 02, 2004 at 12:36:38PM -0500, Amos Waterland wrote:
> Source: stress
> Section: devel
> Priority: optional
> Maintainer: Amos Waterland <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>> 3.0.0)
> Standards-Version: 3.5.9
> 
> Package: stress
> Architecture: any
> Depends: ${shlibs:Depends}
> Description: A tool which imposes stress on a system
>  'stress' is a tool which imposes a configurable amount of CPU, memory, I/O,
>  or disk stress on a POSIX-compliant operating system.  It is written in
>  highly-portable ANSI C, and uses the GNU Autotools to compile on a great
>  number of UNIX-like operating systems.
>  .
>  'stress' is not a benchmark.  It is a tool used by system administrators to
>  evaluate how well their systems will scale, by kernel programmers to evaluate
>  perceived performance characteristics, and by systems programmers to expose
>  the classes of bugs which only or more frequently manifest themselves when
>  the system is under heavy load.
> 
> Upstream home page:
>  http://weather.ou.edu/~apw/projects/stress/
> 
> Deb packages:
>  http://weather.ou.edu/~apw/projects/stress/#Debiandeb


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Frank Küster]

Brian Sutherland <[EMAIL PROTECTED]> wrote:

Subject: Re: RFS schoolbell - A calenaring server for schools

s/calenar/calendar/, or is this a new english word?

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt

[Kevin B. McCarty]

Hi Stefan,

You wrote:

> that's a nice little program. Just one suggestion:
> Add a viewglob session type to the KDE konsole by including the 
> file /usr/share/apps/konsole/viewglob.desktop

OK, I'll go ahead and add it.  Have you tested it?  I don't use KDE so
can't do so myself.

It will be a little while before I put up a new source package, since
I'm waiting to hear back from upstream about a possibly problematic
compiler warning.

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544

RFS: stress

[Amos Waterland]

Source: stress
Section: devel
Priority: optional
Maintainer: Amos Waterland <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 3.0.0)
Standards-Version: 3.5.9

Package: stress
Architecture: any
Depends: ${shlibs:Depends}
Description: A tool which imposes stress on a system
 'stress' is a tool which imposes a configurable amount of CPU, memory, I/O,
 or disk stress on a POSIX-compliant operating system.  It is written in
 highly-portable ANSI C, and uses the GNU Autotools to compile on a great
 number of UNIX-like operating systems.
 .
 'stress' is not a benchmark.  It is a tool used by system administrators to
 evaluate how well their systems will scale, by kernel programmers to evaluate
 perceived performance characteristics, and by systems programmers to expose
 the classes of bugs which only or more frequently manifest themselves when
 the system is under heavy load.

Upstream home page:
 http://weather.ou.edu/~apw/projects/stress/

Deb packages:
 http://weather.ou.edu/~apw/projects/stress/#Debiandeb


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

Re: RFS: viewglob [revised]

[Kevin B. McCarty]

I have added the viewglob.desktop file provided by Stefan Fritsch for a
konsole session, and fixed all the compiler warnings.  The new package
is at the same location as before.  Any takers for sponsoring viewglob?

deb-src http://borex.princeton.edu/~kmccarty/ unstable main

apt-get update
apt-get source viewglob

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544


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

Re: RFS schoolbell - A calenaring server for schools

[Matt Brubeck]

Stephen Frost wrote:

> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

I also agree.  I am both upstream and Debian maintainer for my package,
and I find that a non-native package has many advantages:

 * We don't need to make a new "upstream" tarball for changes that only
   affect Debian.

 * Each Debian package is clearly based on a specific, cross-platform
   upstream version.

 * Non-native packages make it slightly easier for other Debian
   developers to make changes and NMUs.

 * If the upstream source tarball contains the "official" Debian
   directory, users who compile their own versions from tarballs or CVS
   will generate .debs with the same versions as the official packages.

If you do want to maintain your "debian" directory in the upstream
source, I suggest you use one of these strategies:

 1. Maintain the debian directory in the upstream CVS, but strip it out
when you generate release tarballs.  Use the .diff.gz to restore it
in the Debian source package.

 2. Maintain the debian directory in the upstream source, but use
"unofficial" versions and control files.  Replace them with the
official versions in the .diff.gz.


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

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Kevin B. McCarty ([EMAIL PROTECTED]) wrote:
> Matthew Palmer wrote:
> 
> > I just had another thought -- make a -1 revision with an empty diff.  Weird,
> > but I can't think of any reason why it wouldn't work...
> 
> Why would the diff be empty?  I would think it should contain the debian
> subdir in any case.  It makes no sense to ship a debian directory in
> generic source code released for RedHat, Windows, etc. (it would just
> uselessly increase the tarball size) so it might as well go into the
> Debian-specific diff.gz.
> 
> Even as both upstream and maintainer, you (Brian Sutherland) might find
> it useful to keep Debian packaging stuff separate from the main body of
> code.  Then if there is a bug in debian/rules, or Debian Policy is
> updated to mandate some new control field, you don't have to release an
> entirely new tarball just to fix a Debian-specific issue.

I agree with this.  Really, debian-native packages are debian-specific
packages.  I would strongly encourage you to *not* make this a
debian-native package.

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Kevin B. McCarty]

Matthew Palmer wrote:

> I just had another thought -- make a -1 revision with an empty diff.  Weird,
> but I can't think of any reason why it wouldn't work...

Why would the diff be empty?  I would think it should contain the debian
subdir in any case.  It makes no sense to ship a debian directory in
generic source code released for RedHat, Windows, etc. (it would just
uselessly increase the tarball size) so it might as well go into the
Debian-specific diff.gz.

Even as both upstream and maintainer, you (Brian Sutherland) might find
it useful to keep Debian packaging stuff separate from the main body of
code.  Then if there is a bug in debian/rules, or Debian Policy is
updated to mandate some new control field, you don't have to release an
entirely new tarball just to fix a Debian-specific issue.

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544


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

Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt

[Kevin B. McCarty]

Hi Stefan,

You wrote:

> that's a nice little program. Just one suggestion:
> Add a viewglob session type to the KDE konsole by including the 
> file /usr/share/apps/konsole/viewglob.desktop

OK, I'll go ahead and add it.  Have you tested it?  I don't use KDE so
can't do so myself.

It will be a little while before I put up a new source package, since
I'm waiting to hear back from upstream about a possibly problematic
compiler warning.

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544


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

Re: Problems with Provides/Replaces/Conflicts

[Frank Küster]

Frank Küster <[EMAIL PROTECTED]> wrote:

> Does anybody have an idea why apt decides "Holding Back tetex-bin rather
> than change dvipdfm"? 

It seems it's an apt bug; after I put the tetex stuff on hold and
dist-upgrade the rest, it works fine.

Is there yet a draft for Release Notes for sarge?

TIA, Frank

-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

To Small's Shop Customers!

[Muriel Walls]

Dear customer!

We updated our software catalogue and added new
popular products! Now you can get any software item
at 90% discount rate! For more information visit us here:
http://sanhedrin.infostech.info/index.php?s=4241

With best regards,
Product Manager
Muriel Walls

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 02:06:14PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> > On the whole, I think you've made a poor compromise.  I would suggest
> > picking one way or the other, and going all the way with it.  As it stands,
> > you're going to have trouble uploading a -2 of anything without a new
> > upstream tarball anyway, so you're best off just going full-native and being
> > done with it.
> 
> Ok, so then a .dx (x = version number)attached to the relevant upstream 
> version indicating the debian specific branch? I am worried about the 
> resulting confusion because I should not bump the main projects version 
> for debian specific changes.
> 
> Could confuse Windows users:) "Why does debian have a bigger version?"

What about when you make a release that fixes a critical bug that only
manifests itself on Windows?  "Why does Windows have a bigger version?"

Two options: bump the subpatch version, or tack a .dx version on when you
need to fix the debian packaging.

You could always just handle Debian changes the same way you would with
any other changes -- make a new upstream release whenever there's a bug big
enough to warrant it, otherwise just put it into the next regular release.

I just had another thought -- make a -1 revision with an empty diff.  Weird,
but I can't think of any reason why it wouldn't work...

- Matt


signature.asc
Description: Digital signature

Problems with Provides/Replaces/Conflicts

[Frank Küster]

Hi, 

tetex-bin previously only declared

Replaces:... dvipdfm
Provides: ... dvipdfm

but no Conflicts. This has the effect that dvipdfm is not removed when
tetex-bin is installed, and trying to remove afterwards fails because of
some dpkg-divert stuff (see #269235). Note that dvipdfm does no longer
exist in sarge or sid.

So I thought the natural thing would be to add a Conflicts, as described
in Policy, Section 7.5.2. But when testing this, the dist-upgrade from
woody does no longer work, which I don't understand:

bin/bash-2.05a# apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Starting
Starting 2
Investigating libconsole
Package libconsole has broken dep on console-tools-libs
  Considering console-tools-libs 4 as a solution to libconsole 9
  Added console-tools-libs to the remove list
  Fixing libconsole via remove of console-tools-libs
Investigating tetex-bin
  Or group remove for tetex-bin
Package tetex-bin has broken dep on dvipdfm
  Considering dvipdfm 0 as a solution to tetex-bin 0
  Holding Back tetex-bin rather than change dvipdfm
Investigating tetex-base
Package tetex-base has broken dep on tetex-bin
  Considering tetex-bin 0 as a solution to tetex-base 3
  Added tetex-bin to the remove list
  Fixing tetex-base via remove of tetex-bin

dvipdfm itself has the following Dependency lines:

Depends: tetex-base, libc6 (>= 2.1.97), libkpathsea3 (>= 1.0.7+2807-6), 
libpaperg (>= 1.0.4), libpng2, zlib1g (>= 1:1.1.3)
Suggests: gs

sarge's tetex-base declares a Replaces for dvipdfm (which is correct),
and a Conflict with woody's tetex-bin (which is also necessary), and the
new tetex-bin depends on the new tetex-base.

Does anybody have an idea why apt decides "Holding Back tetex-bin rather
than change dvipdfm"? tetex-bin also Replaces/Conflicts/Provides:
texdoctk, and there's no problem with it. There's a similar problem with
cweb, which still exists in sarge. How could I debug this?

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> On the whole, I think you've made a poor compromise.  I would suggest
> picking one way or the other, and going all the way with it.  As it stands,
> you're going to have trouble uploading a -2 of anything without a new
> upstream tarball anyway, so you're best off just going full-native and being
> done with it.

Ok, so then a .dx (x = version number)attached to the relevant upstream 
version indicating the debian specific branch? I am worried about the 
resulting confusion because I should not bump the main projects version 
for debian specific changes.

Could confuse Windows users:) "Why does debian have a bigger version?"

> 
> > I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> > And will get bigger.
> 
> Split it out, then.  Make a "schoolbell-common" package with all of this
> common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

It has a little C in it. But good point, i'll have a look into a
schooltool-common package.

> 
> > W: schoolbell: description-synopsis-might-not-be-phrased-properly
> > Huh?
> 
> The -i option to lintian is your friend whenever you get that Huh? feeling. 

Offending full stop removed. Indeed it was not a full sentence. Next
time I will do the obvious. 

> Not quite sure how that relates to your particular case, though -- the
> description in the .changes I just looked at didn't have an ending period...

Any rules/conventions on that?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 12:52:55PM +0200, Brian Sutherland wrote:
> W: schoolbell source: native-package-with-dash-version
> The package releases for more than just debian. And sometimes it will be 
> necessary to adjust the package only for debian but the debian directory
> is in the repository. So I think it makes no sense to move everything
> around again and a dash version is the most logical solution?

You'll get differing opinions about this.  On the one hand, since you're
apparently involved in upstream development anyway, there's not much point
in making separated releases.  Distinctly, being "Debian native" has certain
"this is really only for Debian" connotations that will likely get you into
trouble.

On the whole, I think you've made a poor compromise.  I would suggest
picking one way or the other, and going all the way with it.  As it stands,
you're going to have trouble uploading a -2 of anything without a new
upstream tarball anyway, so you're best off just going full-native and being
done with it.

> I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> And will get bigger.

Split it out, then.  Make a "schoolbell-common" package with all of this
common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

> W: schoolbell: description-synopsis-might-not-be-phrased-properly
> Huh?

The -i option to lintian is your friend whenever you get that Huh? feeling. 
In this case:

Tag: description-synopsis-might-not-be-phrased-properly
Type: warning
Info: The synopsis (first line in the package "Description:" field, the
 short description) ends with a full stop "." character. This is not
 necessary, as the synopsis doesn't need to be a full sentence. It is
 recommended that a descriptive phrase is used instead.
 .
 Note also that the synopsis is not part of the rest of the "Description:"
 field.
Ref: policy 3.4.1

Not quite sure how that relates to your particular case, though -- the
description in the .changes I just looked at didn't have an ending period...

- Matt


signature.asc
Description: Digital signature

Re: Problems with Provides/Replaces/Conflicts

[Frank Küster]

Frank Küster <[EMAIL PROTECTED]> wrote:

> Does anybody have an idea why apt decides "Holding Back tetex-bin rather
> than change dvipdfm"? 

It seems it's an apt bug; after I put the tetex stuff on hold and
dist-upgrade the rest, it works fine.

Is there yet a draft for Release Notes for sarge?

TIA, Frank

-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

I am packaging schoolbell on behalf of upstream (Related to ITP#263088)
and seeking a sponsor.

Schoolbell is the first publicly available version of the Schooltool
server and is a stripped down version that only deals with 
calendaring and scheduling between groups.

This is the first wider release that people can actually test (The other
schooltool packages should follow soon).

Advertising plug for Schooltool:
Schooltool[1] is a project to develop an open source administration suite
for schools. It is privately funded by the shuttleworth foundation[2] and
arose out of a need for better governance of schools in South Africa
that do not have the resources for more expensive products. It is firmly
GPL with some imports from Zope (ZPL 2 or greater).

Personal opinion:
If we can improve the administration and management of schools,
especially in poor countries, even a little bit, that would be a very 
good thing.

The packages can be found here:

http://www.schooltool.org/Members/jinty/debian_packaging/packaging_home/document_view


The package is NOT lintian clean, but i will attempt to explain away the
remaining warnings:

W: schoolbell source: native-package-with-dash-version
The package releases for more than just debian. And sometimes it will be 
necessary to adjust the package only for debian but the debian directory
is in the repository. So I think it makes no sense to move everything
around again and a dash version is the most logical solution?

I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
And will get bigger.

W: schoolbell: description-synopsis-might-not-be-phrased-properly
Huh?

[1] www.schooltool.org
[2] http://www.tsf.org.za/

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

To Small's Shop Customers!

[Muriel Walls]

Dear customer!

We updated our software catalogue and added new
popular products! Now you can get any software item
at 90% discount rate! For more information visit us here:
http://sanhedrin.infostech.info/index.php?s=4241

With best regards,
Product Manager
Muriel Walls

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 02:06:14PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> > On the whole, I think you've made a poor compromise.  I would suggest
> > picking one way or the other, and going all the way with it.  As it stands,
> > you're going to have trouble uploading a -2 of anything without a new
> > upstream tarball anyway, so you're best off just going full-native and being
> > done with it.
> 
> Ok, so then a .dx (x = version number)attached to the relevant upstream 
> version indicating the debian specific branch? I am worried about the 
> resulting confusion because I should not bump the main projects version 
> for debian specific changes.
> 
> Could confuse Windows users:) "Why does debian have a bigger version?"

What about when you make a release that fixes a critical bug that only
manifests itself on Windows?  "Why does Windows have a bigger version?"

Two options: bump the subpatch version, or tack a .dx version on when you
need to fix the debian packaging.

You could always just handle Debian changes the same way you would with
any other changes -- make a new upstream release whenever there's a bug big
enough to warrant it, otherwise just put it into the next regular release.

I just had another thought -- make a -1 revision with an empty diff.  Weird,
but I can't think of any reason why it wouldn't work...

- Matt


signature.asc
Description: Digital signature

Problems with Provides/Replaces/Conflicts

[Frank Küster]

Hi, 

tetex-bin previously only declared

Replaces:... dvipdfm
Provides: ... dvipdfm

but no Conflicts. This has the effect that dvipdfm is not removed when
tetex-bin is installed, and trying to remove afterwards fails because of
some dpkg-divert stuff (see #269235). Note that dvipdfm does no longer
exist in sarge or sid.

So I thought the natural thing would be to add a Conflicts, as described
in Policy, Section 7.5.2. But when testing this, the dist-upgrade from
woody does no longer work, which I don't understand:

bin/bash-2.05a# apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Starting
Starting 2
Investigating libconsole
Package libconsole has broken dep on console-tools-libs
  Considering console-tools-libs 4 as a solution to libconsole 9
  Added console-tools-libs to the remove list
  Fixing libconsole via remove of console-tools-libs
Investigating tetex-bin
  Or group remove for tetex-bin
Package tetex-bin has broken dep on dvipdfm
  Considering dvipdfm 0 as a solution to tetex-bin 0
  Holding Back tetex-bin rather than change dvipdfm
Investigating tetex-base
Package tetex-base has broken dep on tetex-bin
  Considering tetex-bin 0 as a solution to tetex-base 3
  Added tetex-bin to the remove list
  Fixing tetex-base via remove of tetex-bin

dvipdfm itself has the following Dependency lines:

Depends: tetex-base, libc6 (>= 2.1.97), libkpathsea3 (>= 1.0.7+2807-6), libpaperg 
(>= 1.0.4), libpng2, zlib1g (>= 1:1.1.3)
Suggests: gs

sarge's tetex-base declares a Replaces for dvipdfm (which is correct),
and a Conflict with woody's tetex-bin (which is also necessary), and the
new tetex-bin depends on the new tetex-base.

Does anybody have an idea why apt decides "Holding Back tetex-bin rather
than change dvipdfm"? tetex-bin also Replaces/Conflicts/Provides:
texdoctk, and there's no problem with it. There's a similar problem with
cweb, which still exists in sarge. How could I debug this?

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> On the whole, I think you've made a poor compromise.  I would suggest
> picking one way or the other, and going all the way with it.  As it stands,
> you're going to have trouble uploading a -2 of anything without a new
> upstream tarball anyway, so you're best off just going full-native and being
> done with it.

Ok, so then a .dx (x = version number)attached to the relevant upstream 
version indicating the debian specific branch? I am worried about the 
resulting confusion because I should not bump the main projects version 
for debian specific changes.

Could confuse Windows users:) "Why does debian have a bigger version?"

> 
> > I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> > And will get bigger.
> 
> Split it out, then.  Make a "schoolbell-common" package with all of this
> common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

It has a little C in it. But good point, i'll have a look into a
schooltool-common package.

> 
> > W: schoolbell: description-synopsis-might-not-be-phrased-properly
> > Huh?
> 
> The -i option to lintian is your friend whenever you get that Huh? feeling. 

Offending full stop removed. Indeed it was not a full sentence. Next
time I will do the obvious. 

> Not quite sure how that relates to your particular case, though -- the
> description in the .changes I just looked at didn't have an ending period...

Any rules/conventions on that?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt

[Stefan Fritsch]

Hi Kevin,

that's a nice little program. Just one suggestion:
Add a viewglob session type to the KDE konsole by including the 
file /usr/share/apps/konsole/viewglob.desktop

Cheers,
Stefan


-- 


viewglob.desktop
Description: application/desktop

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 12:52:55PM +0200, Brian Sutherland wrote:
> W: schoolbell source: native-package-with-dash-version
> The package releases for more than just debian. And sometimes it will be 
> necessary to adjust the package only for debian but the debian directory
> is in the repository. So I think it makes no sense to move everything
> around again and a dash version is the most logical solution?

You'll get differing opinions about this.  On the one hand, since you're
apparently involved in upstream development anyway, there's not much point
in making separated releases.  Distinctly, being "Debian native" has certain
"this is really only for Debian" connotations that will likely get you into
trouble.

On the whole, I think you've made a poor compromise.  I would suggest
picking one way or the other, and going all the way with it.  As it stands,
you're going to have trouble uploading a -2 of anything without a new
upstream tarball anyway, so you're best off just going full-native and being
done with it.

> I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> And will get bigger.

Split it out, then.  Make a "schoolbell-common" package with all of this
common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

> W: schoolbell: description-synopsis-might-not-be-phrased-properly
> Huh?

The -i option to lintian is your friend whenever you get that Huh? feeling. 
In this case:

Tag: description-synopsis-might-not-be-phrased-properly
Type: warning
Info: The synopsis (first line in the package "Description:" field, the
 short description) ends with a full stop "." character. This is not
 necessary, as the synopsis doesn't need to be a full sentence. It is
 recommended that a descriptive phrase is used instead.
 .
 Note also that the synopsis is not part of the rest of the "Description:"
 field.
Ref: policy 3.4.1

Not quite sure how that relates to your particular case, though -- the
description in the .changes I just looked at didn't have an ending period...

- Matt


signature.asc
Description: Digital signature

RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

I am packaging schoolbell on behalf of upstream (Related to ITP#263088)
and seeking a sponsor.

Schoolbell is the first publicly available version of the Schooltool
server and is a stripped down version that only deals with 
calendaring and scheduling between groups.

This is the first wider release that people can actually test (The other
schooltool packages should follow soon).

Advertising plug for Schooltool:
Schooltool[1] is a project to develop an open source administration suite
for schools. It is privately funded by the shuttleworth foundation[2] and
arose out of a need for better governance of schools in South Africa
that do not have the resources for more expensive products. It is firmly
GPL with some imports from Zope (ZPL 2 or greater).

Personal opinion:
If we can improve the administration and management of schools,
especially in poor countries, even a little bit, that would be a very 
good thing.

The packages can be found here:

http://www.schooltool.org/Members/jinty/debian_packaging/packaging_home/document_view


The package is NOT lintian clean, but i will attempt to explain away the
remaining warnings:

W: schoolbell source: native-package-with-dash-version
The package releases for more than just debian. And sometimes it will be 
necessary to adjust the package only for debian but the debian directory
is in the repository. So I think it makes no sense to move everything
around again and a dash version is the most logical solution?

I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
And will get bigger.

W: schoolbell: description-synopsis-might-not-be-phrased-properly
Huh?

[1] www.schooltool.org
[2] http://www.tsf.org.za/

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt

[Stefan Fritsch]

Hi Kevin,

that's a nice little program. Just one suggestion:
Add a viewglob session type to the KDE konsole by including the 
file /usr/share/apps/konsole/viewglob.desktop

Cheers,
Stefan


-- 


viewglob.desktop
Description: application/desktop

Re: RFS: streamline

[Nathaniel W. Turner]

Hi Jurij,

On Wednesday 01 September 2004 12:48 am, Jurij Smakov wrote:
> I have a somewhat different impression, apache2 seems to have its share
> of problems. Debian's apache2 packages have seen 12 uploads during the
> last two months [0] 

Yes, there was a botched and now reverted attempt at enabling LFS, but that's 
not really relevant here.  =)

Other than that, I have had an excellent with apache2 so far.

> and PHP manual explicitly states [1]: 
>
>  Do not use Apache 2.0.x and PHP in a production environment neither on
>  Unix nor on Windows. For information on why, read the following FAQ
>  entry.

That FAQ entry just says that PHP isn't threadsafe.  There are plenty of other 
reasons to use Apache 2 other than the threaded MPMs, and PHP works just fine 
with the prefork MPM.  I think that FAQ entry is somewhat shortsighted and 
even a bit FUD-ful.

> While seemingly innocent, this change may have some "interesting"
> consequences. Consider a situation when apache2 is provided by the
> recommended apache2-mpm-worker package. If PHP is not installed, the first
> candidate to satisfy the second dependency is libapache2-mod-php4, which
> depends on apache2-mpm-prefork (>= 2.0.50-10). 

> This, in turn, conflicts 
> with all other apache2 MPM flavors (including apache2-mpm-worker). As a
> result, the apache2-mpm-worker is going to be (quite unexpectedly) removed
> and replaced by apache2-mpm-prefork, possibly, contrary to user's wishes.

No, it would not be removed unexpectedly -- the user would have to say OK 
after being told very clearly that apache2-mpm-worker was to be removed.  If 
a user has that MPM installed, this should be a clear indicator to them that 
they should not proceed with the installation of this package, as it is 
simply not compatible.  The only way they could use Apache 2 with your 
package is to switch to the prefork MPM, which is exactly what APT would 
offer to do.  =)

Cheers,
nate

-- 
Nathaniel W. Turner
http://houseofnate.net/