Re: status of jackd? (bug #318098)

[Ondrej Sury]

On Tue, 2005-08-09 at 19:17 -0700, Erik Steffl wrote:
>well, what is experimental for then?

Experimental is for stuff you DON'T plan to be in next stable.  Or for
stuff which could break next release (which is not case right now).

F.E.: GNOME 2.6->2.8 transition was done in experimental in first place,
because it COULD break sarge release process.  GNOME 2.10 was uploaded
right to unstable, because it WON'T break etch release now.

O.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: status of jackd? (bug #318098)

[Ondrej Sury]

On Tue, 2005-08-09 at 22:56 -0400, David Nusinow wrote:
> 
> So you're complaining that this jackd bug is exemplary of
> "unneccessary" breakages in unstable, and yet you don't even know if
> there is a good reason for this bug. You don't know if this is tied to
> the gcc change. 

I believe that #318098 can be simply avoided by not doing dist-upgrade
(ie. not install new conflicting jackd).  How simple and how much
flames :-(.
 
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: status of jackd? (bug #318098)

[Adeodato Simó]

* Erik Steffl [Tue, 09 Aug 2005 01:01:16 -0700]:

>   mini rant

  debian-devel is not your blog. Please do refrain from ranting here in
  the future, at least while being a guest.

  This thread has made me want to scream. Please educate yourself about
  the details of our development model before posting to a list devoted
  to "discussion about technical development topics".

  What a sucky morning.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Capitalism is the extraordinary belief that the nastiest of men, for the
nastiest of reasons, will somehow work for the benefit of us all.
-- John Maynard Keynes


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

Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager

[Jeroen Vermeulen]

On Wed, Aug 10, 2005 at 04:30:22PM +1000, Anibal Monsalve Salazar wrote:
 
>  Small, stable system add-on that continuously and automatically adapts
>  available virtual memory space to your actual memory needs.  Claims disk 
> space
>  for use as swap space when needed; frees it up for use by the filesystem when
>  not needed.
> 
> [Jeroen, you can be the owner of this ITP, if you wish so.]

Thanks for a very fast reaction!  I'm not a Debian developer, so I'm
probably not a useful owner.  I do, however, like to integrate Debian
packaging and patches as a first-class citizen in the upstream source
tree.  Doubly so in this case, where a number of agencies have agreed
on Debian as a standard OS base.


Jeroen Vermeulen


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

Bug#322319: ITP: kde-wallpapers-lineartreworked -- Some reworks of the lineart background that comes with KDE 3.4.

[Bastian Venthur]

Package: wnpp
Severity: wishlist
Owner: Bastian Venthur <[EMAIL PROTECTED]>

* Package name: kde-wallpapers-lineartreworked
  Version : 0.0.20050405
  Upstream Author : Manicka Dharma <[EMAIL PROTECTED]>
* URL : http://www.kde-look.org/content/show.php?content=22079
* License : GPL
  Description : Some reworks of the lineart background that comes with KDE 
3.4.

This package contains 16 different reworks of he popular "lineart"
wallpaper which comes with KDE 3.4.
..
These wallpapers come in three different colors: blue, red, green and
are stored in the scalable vector graphics format (.sgf), so you can use
them in any resolution withot quality loss.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2-laptop
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Unison

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I wont to ask if there is something with the maintainer of unison. There
are at least 3 important bugs where at least one of them can be fixed
very easy as there is a working patch in the bug report. But nothing
happens.

The bugs are 309908, 310004 and 318132 where the problems are similar.

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQvnRN5+OKpjRpO3lAQIr9gf+OwANnetCQJULmBc08CaRghzFctoklE+9
HVLNYnmoxLr1Pm7BPOdc6Gk3v5D+26XLAVGMfLj1KvYi8EPf9axQmqE5pdgWFXdj
EC8VkQ8nrB2E2VZPSie8qq72K6SU/Rk640v/2kj0cGmzxvRF7fQQWvj+je6H8Mlk
AkGEb+ZS+FkUv46svAuFJQNhlYna+WZuf+lonUatbIyHs2R152409z3duKuUAxhy
T4H2O3G0HdGOBa646i1ZzWGBD8YJ+bPeCBfs2UYAzC/REjT96Ih9ZGScVx/NgaKH
sfjxlenL2Cohd+14AbcWIcFYdKbgcj0lZCTq4TYlRjvt6INfm7+ZHw==
=SBU5
-END PGP SIGNATURE-


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

Bug#322335: ITP: kdm-theme-krystal -- A KDM theme with the official KDE logo and crystal icons

[Bastian Venthur]

Package: wnpp
Severity: wishlist
Owner: Bastian Venthur <[EMAIL PROTECTED]>

* Package name: kdm-theme-krystal
  Version : 0.0.20050330
  Upstream Author : John Green <[EMAIL PROTECTED]>
* URL : http://www.kde-look.org/content/show.php?content=22390
* License : GPL
  Description : A KDM theme with the official KDE logo and crystal icons

This Package contains a very beautiful KDM theme.

Note: currently KDM-themes are not enabled by default in debian. Read
the README to learn how to enable them.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2-laptop
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Packaging a PostScript resource

[Terry Burton]

Hi,
 
I have a PostScript resource that I am intending to package with the aim of getting it into Etch. There are an increasing number of front-end applications that are using this resource and each of these currently embeds their own instance of it. To prevent this duplication and effectively manage updates and version control I am looking to create a library package, libpostscriptbarcode, or similar, on which other application packages (and language specific APIs, when they are written) can depend.

 
The resource is the barcode.ps file from the Barcode Writer in Pure PostScript project at http://www.terryburton.co.uk/barcodewriter
.
 
Would this be the most sensible Debian naming strategy for packaging a PostScript resource?
 
libpostscriptbarcode - for the PostScript resources
libperl-postscriptbarcode - for the Perl API, etc.
 
Is there a maintainer who would be willing to examine the .deb and upload it to Debian repository once I have created it.
 
 
Many thanks,
 
Tez

Re: experimental bugs preventing testing transition?

[Colin Watson]

On Wed, Aug 10, 2005 at 06:49:12PM +1200, Nigel Jones wrote:
> On 10/08/05, Colin Watson <[EMAIL PROTECTED]> wrote:
> > Testing and BTS version tracking haven't been updated to play properly
> > together yet.
> 
> If i'm not mistaken, you could tag the bug etch, of course, this is a
> very nasty/dirty way of getting the RC-free package actually in
> testing,

I'd really prefer if people didn't do that. It makes it harder to get to
a sane world from here, and it means we have to try to support even more
strange combinations of workarounds.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: experimental bugs preventing testing transition?

[Nigel Jones]

On 10/08/05, Colin Watson <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005 at 06:49:12PM +1200, Nigel Jones wrote:
> > On 10/08/05, Colin Watson <[EMAIL PROTECTED]> wrote:
> > > Testing and BTS version tracking haven't been updated to play properly
> > > together yet.
> >
> > If i'm not mistaken, you could tag the bug etch, of course, this is a
> > very nasty/dirty way of getting the RC-free package actually in
> > testing,
> 
> I'd really prefer if people didn't do that. It makes it harder to get to
> a sane world from here, and it means we have to try to support even more
> strange combinations of workarounds.
Yes very true, I must admit I should have removed it from the email
when I remembered about the experimental tag. (Which as I mentioned
before I believe should work correctly?)
> 
> --
> Colin Watson   [EMAIL PROTECTED]
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 


-- 
N Jones
Proud Debian & FOSS User
Debian Maintainer of: html2ps, ipkungfu, dvorak7min & windowlab

Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager

[Henning Makholm]

Scripsit Jeroen Vermeulen <[EMAIL PROTECTED]>
> On Wed, Aug 10, 2005 at 04:30:22PM +1000, Anibal Monsalve Salazar wrote:

>> [Jeroen, you can be the owner of this ITP, if you wish so.]

> I'm not a Debian developer, so I'm probably not a useful owner.

You can maintain a package for Debian without officially being a
Debian Developer. But it may not be a good idea to do so if you
can't see yourself becoming one eventually.

> I do, however, like to integrate Debian packaging and patches as a
> first-class citizen in the upstream source tree.

By all means integrate patches from Debian in your source treee.

On the other hand integrating Debian's *packaging* infrastructure
(i.e., the debian/ subdirectory) in upstream source cannot be
recommended. It only creates trouble for developers when the policy
and environment they are packaging for drift out of sync with your
offer (as it will inevitably). Even in the cases where a Debian
developer is himself the upstream author of some software, it is
common that he maintains the Debian infrastructure separately from the
upstream tarball.

The best way to be packager friendly as an upstream author is to
provide a robust, portable build infrastructure with a configure
script and flexible 'install' targets in the Makefile that behave like
autoconf-generated ones. Keep autotools support files up-to-date when
you release, and so forth.

If you want, you can encourage packagers to submit patches for your
makefiles rather than working around them in their Debian rules. Many
packagers by default try to touch the upstream makefiles as little as
possible, but that ought to be reversible if the upstream author
requests so.

-- 
Henning Makholm   "We will discuss your youth another time."


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

Bug#322356: ITP: kde-style-lipstik -- a purified KDE style based on Plastik

[Bastian Venthur]

Package: wnpp
Severity: wishlist
Owner: Bastian Venthur <[EMAIL PROTECTED]>

* Package name: kde-style-lipstik
  Version : 1.3
  Upstream Author : Patrice Tremblay <[EMAIL PROTECTED]>
* URL : http://www.kde-look.org/content/show.php?content=18223
* License : GPL
  Description : a purified KDE style based on Plastik

Based on the plastik style, Lipstik is a purified style with many options to
tune your desktop look.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2-laptop
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

zlib* in incoming since ftp-master move

[Noèl Köthe]

Hello,

since the move of ftp-master there are some zlib* packages staying in
incoming. After the dinstall run they are still there and have file
dates 2005-07-06 and 2005-07-20. Maybe they just have to be removed.

thx.

-- 
Noèl Köthe 
Debian GNU/Linux, www.debian.org


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

Re: Bug#322151: ITP: tablix -- high school timetable generator

[John Goerzen]

On Wed, Aug 10, 2005 at 10:54:03AM +1000, Hamish Moffatt wrote:
> On Tue, Aug 09, 2005 at 01:02:17PM +0200, Robert Lemmen wrote:
> > * Package name: tablix
> >   Version : 0.1.2
> >   Upstream Author : [EMAIL PROTECTED]
> > * URL : http://www.tablix.org
> > * License : GPLv2
> > * Description : high school timetable generator
> > 
> Bingo!
> 

I should ask, though, why this program has to be tailored to high school
timetables.  It seems that the algorithms are likely already generic
enough to be used in a number of other situations where resource
constraints are involved.

-- John


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

Re: status of jackd? (bug #318098)

[Wouter Verhelst]

On Tue, Aug 09, 2005 at 03:56:21PM -0700, Erik Steffl wrote:
> David Nusinow wrote:
> >Where would you like us to do our work? This is exactly what unstable is
> 
>   errr... where would YOU like to work? In intentionally broken 
> unstable becuase "it's just unstable"? You surprise me.

No. But this is a recurring theme that happens every time after we
release a new stable.

It currently goes like this:

* Stable releases
* Freeze is lifted
* The new and shiny updates that people wanted to bring in for a few
  months now but that they held back because we were in freeze is
  uploaded all at once.
* All kinds of funny and unpredictable things happen. X breaks. After
  the woody freeze, I remember PAM breaking because of a slight typo by
  the maintainer somewhere. The combination of the new libfoo and the
  half-upgraded libbar transition happens to work when black magic and
  the phase of the moon cooperate, but break libbaz and libquux on the
  off chance that they sometimes do not work correctly. Preferably in
  horrible ways.
* After a few months, the worst transitions and fuckups are over resp.
  get fixed. People start talking of doing the next freeze again.
* This next freeze takes a while (last time, we had a period of
  approximately one year in which at least _some_ packages were in a
  state of freeze). During this period, people start using unstable more
  often because 'it just works'. Only to be disappionted at things
  breaking when the freeze is over and when unstable is, well, unstable
  again.
* Complaints like in this thread happen on -devel, because unstable just
  happened to work for a while, so people have forgotten what unstable
  is for.

I wasn't there for the breakage after potato; but I was there with
woody, and we see it again with Sarge now.

Unstable is _a_development_system_. The purpose of a development system
is to allow it to break without interfering with a users' system. The
fact that our development system is out there for everyone to use
doesn't matter -- if you'd get access to development versions of Windows
or MacOS X (which you probably won't, unless you happen to work at
Microsoft or Apple), and it would break down, you'd expect that; you'd
file a bug rather than complain how bad Windows or MacOS X is. The same
should be true for Debian.

Yes, there is experimental, and yes, experimental can help alleviate the
problems unstable has. But it cannot completely avoid them; experimental
is for stuff that you expect to break, while unstable is for stuff that
you don't expect to break. The key word here is 'expect'; having
unstable only for stuff that will not break would be great, but is
simply impossible -- you can only be sure whether it will or will not
break by allowing people to try it. And let's be fair about this;
unstable/testing has a *lot* more users than experimental.

> >*for*. It lets us break things while they're in development in order to
> >push the distro as a whole forward. No one says that you have to be running
> 
>   isn't that what experimental is for?

No. Summarizing the above, experimental is there for people to break on
purpose, while unstable is there for people to break by accident. Since
a lot of changes are happening right now, a lot of accidents happen as
well -- which results in an overall reduction in quality of the system.

There's nothing we can do to fix that -- other than by expelling
everyone who ever makes even the slightest mistake. But I don't like the
sound of that...

> >the s00p3r 133t newest version of everything on your system at all times.
> 
>   no but I want to. Because non-1337 stuff is usally several years old 
> (not at the moment but it's getting old fast) and not suitable for 
> desktop usage (in general)

I hear that argument a lot, and it makes me wonder. If three-year-old
software is not suitable for desktop usage in general, then what did you
do three years ago? Use pen and paper?

If you really want the s00p3 l33t newest version of everything, then you
need to accept that it comes with a lot of bugs. That's where the term
'bleeding edge' comes from.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

ITA: Mac on Linux packages

[Martin Loschwitz]

We, Peter De Schrijver and me, hereby announce the intention to take over 
the Mac on Linux packages and maintain them in a sort of packaging group.

-- 
  .''`.   Martin Loschwitz   Debian GNU/Linux developer
 : :'  :  [EMAIL PROTECTED][EMAIL PROTECTED]
 `. `'`   http://www.madkiss.org/people.debian.org/~madkiss/
   `- Use Debian GNU/Linux 3.0!  See http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#322151: ITP: tablix -- high school timetable generator

[Robert Lemmen]

On Wed, Aug 10, 2005 at 07:17:21AM -0500, John Goerzen wrote:
> I should ask, though, why this program has to be tailored to high school
> timetables.  It seems that the algorithms are likely already generic
> enough to be used in a number of other situations where resource
> constraints are involved.

the current description is taken from upstreams webpage and will be
rephrased together with upstream before the upload. the program will be
usable for some other schools as well, but not everyone because of the
kind of constraints that you can (currently) express. for example
a university will have problems with this...

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Bug#322151: ITP: tablix -- high school timetable generator

[Radu Spineanu]

Robert Lemmen wrote:
> On Wed, Aug 10, 2005 at 07:17:21AM -0500, John Goerzen wrote:
> 
>>I should ask, though, why this program has to be tailored to high school
>>timetables.  It seems that the algorithms are likely already generic
>>enough to be used in a number of other situations where resource
>>constraints are involved.
> 
> 
> the current description is taken from upstreams webpage and will be
> rephrased together with upstream before the upload. the program will be
> usable for some other schools as well, but not everyone because of the
> kind of constraints that you can (currently) express. for example
> a university will have problems with this...
> 

fet does the same thing, only it works with universities too.

Radu


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

Re: status of jackd? (bug #318098)

[Humberto Massa Guimarães]

> > I would _NEVER_ recommend someone install Debian Unstable as a
> > desktop...  Testing, yes, Stable even more so.

In my experience, sid breaks less than testing when used as a desktop.
OTOH, I avoid doing apt{-get,itude} upgrade... I generally enter the
interactive aptitude screen, press U, and upgrade only what does not
break... (and I usually regret when I /do/ apt-get upgrade)


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

Re: Packaging a PostScript resource

[Terry Burton]

Okay. I've created a Debian package for Barcode Writer in Pure PostScript at http://www.terryburton.co.uk/barcodewriter/files/libpostscriptbarcode.deb
.
 
Are there any DDs willing to examine this and, if all is well, upload it for me?
 
 
Thanks,
 
Tez 
On 10/08/05, Terry Burton <[EMAIL PROTECTED]> wrote:

Hi,
 
I have a PostScript resource that I am intending to package with the aim of getting it into Etch. There are an increasing number of front-end applications that are using this resource and each of these currently embeds their own instance of it. To prevent this duplication and effectively manage updates and version control I am looking to create a library package, libpostscriptbarcode, or similar, on which other application packages (and language specific APIs, when they are written) can depend. 

 
The resource is the barcode.ps file from the 
Barcode Writer in Pure PostScript project at http://www.terryburton.co.uk/barcodewriter 
.
 
Would this be the most sensible Debian naming strategy for packaging a PostScript resource?
 
libpostscriptbarcode - for the PostScript resources
libperl-postscriptbarcode - for the Perl API, etc.
 
Is there a maintainer who would be willing to examine the .deb and upload it to Debian repository once I have created it.
 
 
Many thanks,
 
Tez

Bug#322405: ITP: ldap-haskell -- LDAP Interface for Haskell

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: ldap-haskell
  Version : 0.1.0
  Upstream Author : John Goerzen
* URL : darcs get --partial http://darcs.complete.org/ldap-haskell
* License : BSD
  Description : LDAP Interface for Haskell

 This package provides an interface to the C LDAP API for Haskell
 programmers.

 With it, you can search, modify, and interrogate LDAP directories.
 The Haskell binding features automatic memory management and proper
 handling for binary data, and handles all marhsalling into and out of
 C data structures for you automatically.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-rc4-mm2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Packaging a PostScript resource

[Alexander Schmehl]

Dear Terry,

* Terry Burton <[EMAIL PROTECTED]> [050810 16:36]:
> Okay. I've created a Debian package for Barcode Writer in Pure PostScript at 
> http://www.terryburton.co.uk/barcodewriter/files/libpostscriptbarcode.deb.
>  Are there any DDs willing to examine this and, if all is well, upload it 
> for me?

I appreciate your efford, but please let me tell you, that it is
a) highly uncommon to ask for a package sponsor without an url to the
   source packages.
b) your package is far from being well enough to be included in Debian.

Sorry, but let's start with some simple things:  No copyright file?  No
changelog?  Documentation in /usr/lib/foo?  And actually I fail to see
what the benefit is of having a small postscript document showing me
something about barcodes as a debian package?  Or am I missing
something?  The package I just took a quick view at just contains a
postscript file, nothing more.


Did you read the New Maintainers Guide, yet?  It's available at
http://www.debian.org/doc/manuals/maint-guide.  Are you aware of the
debian-mentors list at http://lists.debian.org/debian-mentors/?


Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature

Re: Packaging a PostScript resource

[Terry Burton]

I appreciate your efford, but please let me tell you, that it isa) highly uncommon to ask for a package sponsor without an url to the
  source packages.
 
PostScript is an interpretted language, so I fail to understand what you mean by source packages in this context. 
b) your package is far from being well enough to be included in Debian.Sorry, but let's start with some simple things:  No copyright file?  No
changelog?
 
Copyright is included in the resource file. If this need to come out into a COPYRIGHT file I can certainly do this.

I have only recently added version control to the project. I intend to maintain a changelog for all future releases.
  Documentation in /usr/lib/foo?  
 
Sorry? I don't understand what documentation you mean. The .ps file _is_ the resource.
And actually I fail to seewhat the benefit is of having a small postscript document showing mesomething about barcodes as a debian package?  Or am I missing
something?  The package I just took a quick view at just contains apostscript file, nothing more.
 
I think that you have misunderstood what you are looking at... forgive me if I wrong. 

If you open the .ps file in a text editor you will find that it is in fact a PostScript resource file with commented delimiters that are used by many front end-applications to extract the relevant PostScript procedures required to produce different symbologies within a particular document. The sample invokations at the end of the file are usually parsed out of the file by the calling application, but are left in the resource file since they provide a simple demonstration of the code's capabilities.

There are a number of high-level APIs for this code that are currently in production including Java, Perl and Ruby. Also the resource is used by the pst-barcode LaTeX package that is part of PSTricks and the web-based demo at 
http://www.raise-the-bar.co.uk/demo.
Did you read the New Maintainers Guide, yet?  It's available at
http://www.debian.org/doc/manuals/maint-guide.  Are you aware of thedebian-mentors list at http://lists.debian.org/debian-mentors/?
 
Thanks. I'll take a look at both of these.
 
I the light of this information can you see other problems with the deb package, apart from missing copyright and changelog files.
 
 
Kind regards,
 
Tez
 

Re: Packaging a PostScript resource

[Antti-Juhani Kaijanaho]

Terry Burton wrote:
> PostScript is an interpretted language, so I fail to understand what you
> mean by source packages in this context.

That word is part of the Debian jargon.  You need to learn the
essentials of that jargon before you can effectively package anything
for Debian.  The main source for this is the Debian Policy manual, which
you should read in its entirety (not skipping things that on the surface
look irrelevant).

http://www.debian.org/doc/debian-policy/

> Copyright is included in the resource file. If this need to come out
> into a COPYRIGHT file I can certainly do this.

More of the same.

> There are a number of high-level APIs for this code that are currently
> in production including Java, Perl and Ruby. Also the resource is used
> by the pst-barcode LaTeX package that is part of PSTricks and the
> web-based demo at http://www.raise-the-bar.co.uk/demo.

Your package should refer to those, then.

-- 
Antti-Juhani


signature.asc
Description: OpenPGP digital signature

Re: Packaging a PostScript resource

[Ben Armstrong]

On Wed, 2005-08-10 at 16:37 +0100, Terry Burton wrote:
> I appreciate your efford, but please let me tell you, that it
> is
> a) highly uncommon to ask for a package sponsor without an url
> to the 
>   source packages.
>  
> PostScript is an interpretted language, so I fail to understand what
> you mean by source packages in this context.

Source package != source code.  All binary (.deb) packages *must* have a
source package (.tar.gz, .diff.gz, .dsc) even if they only contain
interpreted files.

Go read the doc that was recommended, and I think you'll understand.
Once you have gained a basic grasp of Debian packaging from reading
these docs, and have applied any corrections you feel are necessary from
your reading of the doc, you'll find it much easier to find someone to
sponsor your package.

Ben


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

debian-devel@lists.debian.org

[Bastian Venthur]

Package: wnpp
Severity: wishlist
Owner: Bastian Venthur <[EMAIL PROTECTED]>

* Package name: crystalcursors
  Version : 1.1
  Upstream Author : Marco Martin <[EMAIL PROTECTED]>
* URL : http://www.kde-look.org/content/show.php?content=6240
* License : LGPL
  Description : X11 mouse theme with the crystal look&feel

 This package comes with 20 different mouse themes:
 * crystalblue, crystalblue_classic, crystalblue_nonanim
 * crystalblueleft, crystalblueleft_classic, crystalblueleft_nonanim
 * crystalgray, crystalgray_nonanim
 * crystalgrayleft, crystalgrayleft_nonanim
 * crystalgreen, crystalgreen_classic, crystalgreen_nonanim
 * crystalgreenleft, crystalgreenleft_classic, crystalgreenleft_nonanim
 * crystalwhite, crystalwhite_nonanim
 * crystalwhiteleft, crystalwhiteleft_nonanim

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2-laptop
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Packaging a PostScript resource

[Henning Makholm]

Scripsit Alexander Schmehl <[EMAIL PROTECTED]>

> And actually I fail to see what the benefit is of having a small
> postscript document showing me something about barcodes as a debian
> package?  Or am I missing something?  The package I just took a
> quick view at just contains a postscript file, nothing more.

As far as understood the poster, the ps file contains a generic
Postscript library for drawing barcodes.

Unfortunately, in addition to the library, the file also contains a
page description for a test/demo page. This makes it unreasonably
difficult for generators of postscript to just include it in their
prologue, because they would need ad hoc code to cut away the test
page.

I can see some use for a common Postscript library *in principle*.  It
*might* be more straightforward to use in some applications than
running barcode (q.v.) and processing the resulting EPS file. However,
I am not convinced that it should be packaged separately until we have
applications that actually do something useful with the library.

-- 
Henning Makholm  "I tried whacking myself repeatedly
 with the cluebat. Unfortunately, it was
 not as effective as whacking someone else."


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

Re: experimental bugs preventing testing transition?

[Andreas Metzler]

Frank Küster <[EMAIL PROTECTED]> wrote:
[...]
> If you ask on http://bjorn.haxx.se/debian/testing.pl?package=tetex-bin
> why tetex-bin isn't in testing yet, one of the reasons is 

> # tetex-bin has release-critical bugs 

> Clicking on the "release-critical bugs" link brings you to a page that
> only lists 

> #320980: tetex-bin: Updmap error because a map file has not been found
> Package: tetex-bin (tetex-bin 3.0-5.0.sarge1); Severity: serious; Reported 
> by...

> but 3.0-5 is in experimental (3.0-5.0.sarge1 is a binary-only-backport I
> made), and the package trying to enter testing is 2.0.2-31.
[...]

As Colin noted britney is not yet bts-version aware, but I think
tagging the bug experimental via [EMAIL PROTECTED] should do the trick.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


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

Re: Packaging a PostScript resource

[Joe Smith]

Basically this is a postscript file that is used more or less as a shared 
library. It is debians policy to have shared libraies used by more thasn one 
debian program to be seperated out into its own package, and linked against.
That is the goal of this. Terry is mainly asking if packaging this as such 
makes sense. If so does the packaging look reasonable?


If it is then terry Should ITP this and continue as though it were a normal 
package. Once accepted, Bugs (probably RC?) should be filed agaimnst the 
packages that currently embed this 'library' to use the external form. This 
does indeed belong in debian mentors, to which this has been cross-posted 
(gamne). Please follow up in -mentors. (I cannot set a followup-to header 
with OE via Gmane.) 




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

Re: please fix your RC bugs

[Philip Brown]

On Mon, Aug 01, 2005 at 08:45:10AM -0500, Steve Greenland wrote:
> [1] Useful fragment for cross platform shell scripts:
> 
> #!/bin/sh
> # Do the Solaris Dance:
> if [ ! -d ~root ]  ; then
> exec /usr/xpg4/bin/sh $0 "$@" 
> fi

Umm.. Ick it woudl be better as

 if [ -x /usr/xpg4/bin/sh ] ; then


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

Re: please fix your RC bugs

[Philip Brown]

> [1] Useful fragment for cross platform shell scripts:
> 
> #!/bin/sh
> # Do the Solaris Dance:
> if [ ! -d ~root ]  ; then
> exec /usr/xpg4/bin/sh $0 "$@" 
> fi
> 

sigh.. okay, my "correction" had bugs, too :-)
better as


if [ ! -d ~root -a -x /usr/xpg4/bin/sh  ] ; then


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

Re: status of jackd? (bug #318098)

[Gustavo Noronha Silva]

Em Ter, 2005-08-09 às 19:17 -0700, Erik Steffl escreveu:
> > That is wat unstable is for.
> 
>well, what is experimental for then? And what would you offer to 
> desktop users?

Stop that. That's how our release process works; using unstable (maybe
even testing, for that matter) for "common-user" desktops is broken. We
need faster releases or a Debian Desktop CDD which provides a more
desktop-friendly system, perhaps tracking testing and freezing
differently from the usual stable.

You're trying to fix the wrong problem, go fix real bugs.

>what are you talking about? Nobody was suggesting anything like that. 
> I was merely saying that for lot of desktop users unstable is the only 
> sort of acceptable option so people might want to take it seriously, 
> like not breaking it for extended periods of time with the attitude 
> "it's just unstable". If developers needs to try something crazy then 
> there's experimental, as far as I can tell.

We're usually not doing crazy stuff on unstable, I assure you; we're
just trying to develop our next release.

That, of course, when we're not busy handling unhelpful "ideas" or
complaints from people who do not really understand what's going on. How
many times more this same discussion is going to happen?

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

Would anybody miss bibtool-dev?

[Henning Makholm]

I am working on taking over the bibtool package, QA-orphaned last
week. I find to my surprise that the source package builds not only a
'bibtool' package, but also 'bibtool-dev' which contains a static
library.

I question the utility of the bibtool-dev package:

 - No packages depend or build-depend on it (no recommends or suggests
   either).

 - It has only 4 popcon votes for it.
   
 - The library simply consists of every source file for the bibtool
   binary, except main.c

 - It does not appear to be designed with reusable abstractions in mind.

 - Most symbols that are exported from one .o in the library are used
   by another. Theses include "db_find", "error", "init_entries",
   "get_item", "seen", "show_version", "add_word", "new_string",
   "sbputc", "lower". No namespace conservation effort is apparent.
   Including this in any larger piece of software would be a tiptoeing
   business.

I am tempted to decide that bibtool-dev is just a waste of mirror
space and Packages.gz bandwidth.  On the other hand, it might be
considered unethical to adopt a package only to kill off one of its
.debs.

Opinions solicited.

-- 
Henning Makholm  "Nett hier.
 Aber waren Sie schon mal in Baden-Württemberg?"

dobra ponuda

[Trajan Antic]

POZDRAV !!!

Poštovani/a želeo bih da Vam ponudim jedan od načina kako da dodjete
do puno para, za kratko vreme,na sasvim legalan i proveren način. U
pitanju   je jedan MLM REPORT posao kojeg ja radim već nekoliko godina
i koji mi je za vrlo kratki vremenski period doneo mnogo novca i
finansijsku nezavisnost.Finansijska nezavisnost nešto ka čemu svi
težimo !!! Opširnije u vezi MLM REPORT posla možete naći na mom sajtu
www.mlmbusiness.dzaba.comili me kontaktirajte mailom na
[EMAIL PROTECTED]

Nemojte shvatiti ove ponude olako !!! 

REALNA MOGUCNOST ZARADE 50.000 EURA ZA  90 DANA

OVO JE PRILIKA KOJA CE VAM IZMENITI ZIVOT NA BOLJE !!!

Želim Vam puno uspeha u poslu i privatnim životu !!!

Za sva pitanja stojim Vam na raspolaganju.
[EMAIL PROTECTED]

S` poštovanjem
Trajan Antic

Bug#322473: ITP: deutex -- composition tool for doom-style WAD files

[Jon Dowland]

Package: wnpp
Severity: wishlist
Owner: Jon Dowland <[EMAIL PROTECTED]>

* Package name: deutex
  Version : 4.4.0
  Upstream Author : André Majorel <[EMAIL PROTECTED]>
* URL : http://www.teaser.fr/~amajorel/deutex/
* License : GNU/GPL Version 2
  Description : composition tool for doom-style WAD files

 DEU's Texture Companion (DeuTex) is a resource editor that
 can extract and insert graphics, sounds, levels and other
 resources in doom-format WAD (where's all the data?) files.
 .
 DeuTex is command-line oriented and is most useful for
 assembling WAD files as part of a build procedure, such as
 via Makefile.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11-jmtd3
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

Re: status of jackd? (bug #318098)

[Erik Steffl]

Gustavo Noronha Silva wrote:

Em Ter, 2005-08-09 às 19:17 -0700, Erik Steffl escreveu:


That is wat unstable is for.


  well, what is experimental for then? And what would you offer to 
desktop users?


Stop that. That's how our release process works; using unstable (maybe
even testing, for that matter) for "common-user" desktops is broken. We
need faster releases or a Debian Desktop CDD which provides a more
desktop-friendly system, perhaps tracking testing and freezing
differently from the usual stable.


  well, OK but _now_ the best option is unstable. All I was saying that 
IMO developers would help a lot by not using "it's just unstable" as an 
excuse to break it (or sort of break it, like jackd does). I was not 
asking for unstable to magically become release quality.



You're trying to fix the wrong problem, go fix real bugs.


  ? I can't fix bugs like the one in subject of this email or udev 
requiring newer kernel than is available in debian etc. (which is the 
kind of bugs I was talking about, I wasn't complaining about unstable in 
general, it's actually amazingly stable)


...

That, of course, when we're not busy handling unhelpful "ideas" or
complaints from people who do not really understand what's going on. How
many times more this same discussion is going to happen?


  why do you assume I don't know how debian release process works? Been 
reading debian-devel and debian-users for few years now... Note that I 
wasn't asking to change the development process, simply to acknowledge 
that unstable is very useful to users and treat it as such, unless you 
come up with something else that's recent enough (more frequent 
releases, actually usable testing or something else).


  and I guess it will be repeated until debian (i.e. debian developers) 
comes up with a solution. Perhpas the fact that this is being repeated 
over and over means that it should be addressed? (well, maybe ubuntu or 
other debian unstable based distro is the answer)


erik


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

Re: status of jackd? (bug #318098)

[Erik Steffl]

Wouter Verhelst wrote:

On Tue, Aug 09, 2005 at 03:56:21PM -0700, Erik Steffl wrote:

...

No. Summarizing the above, experimental is there for people to break on
purpose, while unstable is there for people to break by accident. Since


  that's all I was saying! Don't break it intentionally and say "it's 
only unstable, deal with it".



a lot of changes are happening right now, a lot of accidents happen as
well -- which results in an overall reduction in quality of the system.


  and note that I explicitly wrote that I am not complaining about c++ 
abi changes or X.org transition (well, seems like jackd is somehow 
related to c++ abi even though it's not c++ lib itself)



There's nothing we can do to fix that -- other than by expelling
everyone who ever makes even the slightest mistake. But I don't like the
sound of that...


  me neither but asking about an eta for fix and an explanation what's 
going on seems reasonable...



the s00p3r 133t newest version of everything on your system at all times.


 no but I want to. Because non-1337 stuff is usally several years old 
(not at the moment but it's getting old fast) and not suitable for 
desktop usage (in general)


I hear that argument a lot, and it makes me wonder. If three-year-old
software is not suitable for desktop usage in general, then what did you
do three years ago? Use pen and paper?


  vi:-)

  ok, I don't remember the dates exactly but during last few years (I 
think withing last three):


  - I got ati 9800pro (not sure if anything in unstable is needed, I 
use ati driver, I think I needed X 4 and kernel 2.6.x but maybe not)


  - iPod (firewire, hfs+) - according to docs hfs+ support was very 
experimental until fairly recently, I think I needed unstable kernel for 
firewire too


  - SATA disk - at a time needed bleeding edge kernel with patches from 
jeff Garzik to make it work, new kernel (third party) also required new 
binutils (the ones in unstable)


  - usb support (mass storage: camera, nokia ngage) - don't think it 
worked very well in stable but not sure about that


  - firefox, thunderbird are a lot better than what was available three 
years ago (I think mozilla just started to be usable at that time), I 
also want java to work, javascript to work, latest plugins available, 
css to work etc.


  - openoffice (previously staroffice) - only became usable recently 
(well, maybe some found it usable before but opne way or another it 
improved a LOT), MS import improved a lot (don't import many MS files 
but I didn't have any problems during last maybe a year while before 
that the import wasn't that good), etc.


  - IM clients are broken fairly often (i.e. probably at least once 
during the period of three years) by protocol changes so you need the 
latest ones


  - kde and gnome are both fairly immature so having a new version is 
usually very useful - performance, functionality etc. (this includes lot 
of stuff that comes with these - nautilus, koffice, konqueror etc. most 
of which only became usable during last maybe one or two years)


  - alsa - only became stable recently

  - jackd - very useful for audio

  - rosegarden4 and several other major audio apps, essentially I 
couldn't even do anythign interesting with audio two or three years ago 
(between alsa not working very well, lack of preemptive kernel and lack 
of apps, not saying you couldn't do anything with audio but compared to 
what you can do now it's almost nothing:-)


  the list goes on and on. Actually it's pretty amazing how fast the 
opensource software development is and how many apps were created or 
improved over the last few years.


erik


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

Re: status of jackd? (bug #318098)

[Thomas Bushnell BSG]

Erik Steffl <[EMAIL PROTECTED]> writes:

>   that's all I was saying! Don't break it intentionally and say "it's 
> only unstable, deal with it".

There are perfectly legitimate reasons to deliberately break
unstable.  For example, I might choose to upgrade a new version of a
shared library, knowing it has a bug, because that way other packages
that are based on the library can link against the new API.  Then they
can get tested with the new API (even though there is the bug), and
then when the bug gets fixed, the whole kit and kaboodle can go into
testing at once.


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

Partition, LVM, and RAID management utility

[Shaun Jackman]

For for the first time since potato, I reinstalled Debian from scratch
on my main box. Hoorah for dist-upgrade! One experience I took away
from the installation is how impressed I was with partman, the
debian-installer partition management tool. This was my first time
using SATA, LVM, and RAID -- I figured I'd play with all the new
buzzwords while I had the opportunity -- and partman made it all quite
simple!

Once I had my system up and running, I decided to go back and tweak a
couple things  in the partitioning / LVM / RAID scheme. After looking
for a bit, I didn't find a utility [1] quite as good as partman for
this task, so I fell back to the command line utilities fdisk, lvm,
and mdadm. My sense of it is that there isn't a tool packaged in
Debian to fill this need -- although feel free to give suggestions at
this point.

I suggest one of two things, or if there's time both! 1. Port partman
from debian-installer to make it a full fledged utility. 2. Port
whatever tool Red Hat uses [2] for this same task and package it for
Debian. I haven't used the latter, so the former would be my
preference. Can someone more familiar with partman and
debian-installer give an indication of how much work this would be?

Cheers!
Shaun

[1] qtparted is a nice tool, but doesn't handle LVM or RAID yet as far
as I know. webmin-lvm is a capable looking tool though.

[2] I think this tool might be called DiskDruid, but I'm quite out of
touch with Red Hat state-of-the-art.

Re: Would anybody miss bibtool-dev?

[Steve Langasek]

On Wed, Aug 10, 2005 at 10:41:17PM +0200, Henning Makholm wrote:
> I am working on taking over the bibtool package, QA-orphaned last
> week. I find to my surprise that the source package builds not only a
> 'bibtool' package, but also 'bibtool-dev' which contains a static
> library.

> I question the utility of the bibtool-dev package:

>  - No packages depend or build-depend on it (no recommends or suggests
>either).

>  - It has only 4 popcon votes for it.

>  - The library simply consists of every source file for the bibtool
>binary, except main.c

>  - It does not appear to be designed with reusable abstractions in mind.

>  - Most symbols that are exported from one .o in the library are used
>by another. Theses include "db_find", "error", "init_entries",
>"get_item", "seen", "show_version", "add_word", "new_string",
>"sbputc", "lower". No namespace conservation effort is apparent.
>Including this in any larger piece of software would be a tiptoeing
>business.

> I am tempted to decide that bibtool-dev is just a waste of mirror
> space and Packages.gz bandwidth.  On the other hand, it might be
> considered unethical to adopt a package only to kill off one of its
> .debs.

Not at all unethical; I for one greatly appreciate it if packages get this
kind of attention from new maintainers.  Anyway, you certainly don't owe it
to the previous maintainer to keep packages around that you believe were
mistakes.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Partition, LVM, and RAID management utility

[Karl Chen]

> On 2005-08-10 17:06 PDT, Shaun Jackman writes:

Shaun> My sense of it is that there isn't a tool packaged in
Shaun> Debian to fill this need -- although feel free to give
Shaun> suggestions at this point.

Evms is the best all-in-one tool for disk management I've found.
However, Debian-Installer doesn't support it, and you need to
patch the kernel to be able to use evms with non-evms partitions
on the same disk.  I don't think initrd-tools supports it either,
so using evms for the root partition is also tricky.  If the
default kernel image included the bd-claim patch, things would be
a lot easier.

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


-- 
Karl 2005-08-10 18:49


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

Re: Partition, LVM, and RAID management utility

[The Fungi]

On Wed, Aug 10, 2005 at 05:06:41PM -0700, Shaun Jackman wrote:
[...]
> I suggest one of two things, or if there's time both! 1. Port partman
> from debian-installer to make it a full fledged utility. 2. Port
> whatever tool Red Hat uses [2] for this same task and package it for
> Debian. I haven't used the latter, so the former would be my
> preference. Can someone more familiar with partman and
> debian-installer give an indication of how much work this would be?
[...]

In my recent experience, after installing sarge (etch, sid), it is
pretty trivial to convert the system to all evms-native volume
management. You just need to make a few small additions to the
mkinitrd config so that the dm lkm and evms hooks get loaded before
the root partition is mounted, then corresponding adjustments in
your grub config and fstab file. The only real hassle is leaving
yourself room to cpio -p a second root lvm or using evms from a
ramdisk/live cd to convert your legacy root volume to an evms-native
one. The evms debs include great command-line, ncurses-based and gtk
frontends for partition/raid/volume/snapshot/filesystem management,
so it would probably give you what you're looking for, and all using
packages from main without needing to recompile a thing.

At work and at home I have a number of servers running Debian on all
evms-native volumes (/boot is on a physical disk segment and all
other non-tempfs/special filesystems/swap are lvm2). Leave some
available space in the volume group and you can schedule cron jobs
to fork/reap snapshots of your critical filesystems for an easy way
of retrieving old copies of files without resorting to pulling out
backup tapes.

I looked at throwing together some d-i patches to get the unusable
(last I checked) evms udeb going again, but haven't had time with
other projects I've got going. Still, doesn't seem like it would be
very involved to add would cut out/automate a lot of the more
labor-intensive steps in creating a similar setup at install time.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: RFC: allow new upstream into stable when it's the only way to fix security issues.

[Andrew Pollock]

On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote:
> Hello.
> 
> As it is being currently discussed on debian-security [1], security team 
> has hard times supporting mozilla family of packages, because of 
> unfriendly upstream policy - they don't want to isolate security fixes 
> from a large changesets of new upstream releases. And given the huge size 
> of the package, isolating security patches at Debian level also fails.
> 
> So options seem to be:
> 

[snip]

It's a shame the Stable Release Manager and arbiter of the current policy
hasn't participated in this discussion.

regards

Andrew


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

Re: status of jackd? (bug #318098)

[Gustavo Noronha Silva]

Em Qua, 2005-08-10 às 15:12 -0700, Erik Steffl escreveu:
>well, OK but _now_ the best option is unstable. All I was saying that 
> IMO developers would help a lot by not using "it's just unstable" as an 
> excuse to break it (or sort of break it, like jackd does). I was not 
> asking for unstable to magically become release quality.

Let me repeat it: we don't break unstable on purpose.

>why do you assume I don't know how debian release process works? Been 
> reading debian-devel and debian-users for few years now... Note that I 
> wasn't asking to change the development process, simply to acknowledge 
> that unstable is very useful to users and treat it as such, unless you 
> come up with something else that's recent enough (more frequent 
> releases, actually usable testing or something else).

Most of us use unstable. Do you really think it's on our best interest
to break it? It's just how things are. More than useful for users,
unstable is useful for what it is for: doing development. Don't try to
change that; this is not the problem, this is not the solution.

>and I guess it will be repeated until debian (i.e. debian developers) 
> comes up with a solution. Perhpas the fact that this is being repeated 
> over and over means that it should be addressed? (well, maybe ubuntu or 
> other debian unstable based distro is the answer)

Maybe... we're trying to get our release process have a sane timing;
now, rehashing this kinds of non-issues doesn't help.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

shouldn't I use update-alternatives for this?

[Sebastian Kuzminsky]

Yet another thread about cogito-vs-git, sorry folks.  Just killfile me
if I've worn out your patience.


Still there?  Great!


Background: I'm the guy who maintains the cogito package.  I had a problem
a while back because my upstream package wanted to install a program with
the same name as a program installed by GNU Interactive Tools (git.deb).
I asked on this list and was told that Conflicting with GNU Interactive
Tools was wrong, I should rename my upstream's program to avoid the
collision.  I didn't like this suggestion, but I complied with it.


Now, after bumbling around the Debian developer docs a little more,
I found this.  Section 3.10 of the Policy Manual states:



All packages which supply an instance of a common command name (or, in
general, filename) should generally use update-alternatives, so that
they may be installed together. If update-alternatives is not used,
then each package must use Conflicts to ensure that other packages
are de-installed.


Seems like a match to me.  git.deb and cogito.deb both supply an
instance of a common command name (/usr/bin/git).  So shouldn't I use
update-alternatives?


The only other mention I found of update-alternatives was in Appendix
F of the Policy Manual, here:



Appendix F is marked as being "from old Packaging Manual".  The wording
here suggests that in order to use update-alternatives, the alternatives
need to "do the same thing" (like nvi and vim, for example).  This seems
to be in mild conflict with section 3.10: 3.10 talks about filename
conflicts without mentioning "interfaces" (which I take to mean the
"purpose" of the program or file).


So, I'm proposing this:

GNU Interactive Tools installs /usr/bin/git.shell (or something)

Cogito installs /usr/bin/git.scm (or something)

update-alternatives is used to make one of those appear as
/usr/bin/git


The same thing could be done for /usr/bin/cg, which is a name used by
cogito's upstream and the cgvg.deb package.


People who just want GNU Interactive Tools get what they want.  People who
just want Cogito get what they want.  People who want both have to learn
a new name for one of them.  Seems good to me.  Am I missing anything?


Calling Ian Beckwith (git maintainer) and Sergio Talens-Oliag (cgvg
maintainer): what do you think of this proposal?


-- 
Sebastian Kuzminsky


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

Re: shouldn't I use update-alternatives for this?

[Thiemo Seufer]

Sebastian Kuzminsky wrote:
> Yet another thread about cogito-vs-git, sorry folks.  Just killfile me
> if I've worn out your patience.
> 
> 
> Still there?  Great!
> 
> 
> Background: I'm the guy who maintains the cogito package.  I had a problem
> a while back because my upstream package wanted to install a program with
> the same name as a program installed by GNU Interactive Tools (git.deb).
> I asked on this list and was told that Conflicting with GNU Interactive
> Tools was wrong, I should rename my upstream's program to avoid the
> collision.  I didn't like this suggestion, but I complied with it.
> 
> 
> Now, after bumbling around the Debian developer docs a little more,
> I found this.  Section 3.10 of the Policy Manual states:
> 
> 
> 
> All packages which supply an instance of a common command name (or, in
> general, filename) should generally use update-alternatives, so that
> they may be installed together. If update-alternatives is not used,
> then each package must use Conflicts to ensure that other packages
> are de-installed.
> 
> 
> Seems like a match to me.  git.deb and cogito.deb both supply an
> instance of a common command name (/usr/bin/git).  So shouldn't I use
> update-alternatives?

No. Alternatives provide several implementations of similiar
functionality, and allow the user to select the preferred one.

Cogito and git provide _different_ functionality.


Thiemo


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

Re: status of jackd? (bug #318098)

[Steve Langasek]

On Wed, Aug 10, 2005 at 03:12:52PM -0700, Erik Steffl wrote:

> >That, of course, when we're not busy handling unhelpful "ideas" or
> >complaints from people who do not really understand what's going on. How
> >many times more this same discussion is going to happen?

>   why do you assume I don't know how debian release process works?

Well, for understanding how the release process works, you certainly seem to
be expending quite a few words arguing the claim that people are
gratuitously breaking things in unstable -- despite your own admission that
you don't actually *know* what the issue with jackd is.

Ok, so I guess you have a pretty solid grasp of Debian list *culture*, but
that doesn't really imply you understand the release processes... :)

>   and I guess it will be repeated until debian (i.e. debian developers) 
> comes up with a solution. Perhpas the fact that this is being repeated 
> over and over means that it should be addressed?

No, it just explains why developers are irritated when the hundredth user in
a row comes to complain about unstable being... unstable.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature