Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep

[Graham Wilson]

On Tue, Oct 05, 2004 at 07:40:06PM -0800, D. Starner wrote:
> > I just installed the textedit.app package; it pulled in a few GNUstep
> > libraries, but not a complete desktop environment.
> 
> Do the GNUstep libs still start a demon at startup? Last time I 
> checked, they did, instead of starting them only if you were running
> a GNUstep program, like KDE and GNOME do.

I am not sure what you mean by startup.

When the libraries were loaded, they started a few daemons, but, I
believe KDE and GNOME libraries do the same thing. Again, how is GNUstep
any different in this regard than the other desktop environments?

If you mean when X11 was started, then, no, the GNUstep libraries did
not load daemons when I started X11. I fail to see how they would.

-- 
gram

Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep

[D. Starner]

> I just installed the textedit.app package; it pulled in a few GNUstep
> libraries, but not a complete desktop environment.

Do the GNUstep libs still start a demon at startup? Last time I 
checked, they did, instead of starting them only if you were running
a GNUstep program, like KDE and GNOME do. When I asked about it, 
the Debian developer said they didn't care about mixed use environments. 
If it still requires a demon running, then that is an important
depends that needs labeling.
-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep

[Miles Bader]

Jeff Teunissen <[EMAIL PROTECTED]> writes:
> For me, I don't want GNUstep in the names of my programs because I am not
> connected to GNUstep and don't want to be. It is just a couple of libraries
> that I use to write my apps -- you wouldn't put "GTK+" in the name of your
> apps, would you?

Most GTK+ apps don't need any kind of special tag because they're named
reasonably in the first place.  The upstream developers apparently
recognize that they will be often used as one part of a "mixed"
system.

Many "gnustep" apps OTOH, use absurdly generic names, and I can only
conclude that the developers do not think about mixed systems at all.

It is this upstream flaw that forces these apps to have their names
changed in Debian.  A shame for true fans of those applications, I
suppose, but what else can you expect?

-Miles
-- 
Run away!  Run away!

Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep

[Jeff Teunissen]

Frank Küster wrote:

> Jeff Teunissen <[EMAIL PROTECTED]> wrote:
> 
> > Frank Küster wrote:
> >
> >> If I'm wrong, I apologize and will not object against cddb.bundle (at
> >> least not because of this. Still the ".bundle" part is meaningless to
> >> me, but that might be due to my bad english). If I am not wrong, and
> >> GNUstep applications are indeed not designed to be used without using
> >> the Desktop environment, then, please, add "gnustep-" to the name.
> >
> > Yes, you are _very_ clearly wrong. There is no GNUstep program that
> > requires the GNUstep Desktop, because there no GNUstep Desktop to
> > require!
> 
> Okay, then I don't mind leaving gnustep out (I still wonder why you
> wouldn't cry "But I want gnustep in the name" for advertising
> reasons).

For me, I don't want GNUstep in the names of my programs because I am not
connected to GNUstep and don't want to be. It is just a couple of libraries
that I use to write my apps -- you wouldn't put "GTK+" in the name of your
apps, would you?

> I still wonder what "bundle" could mean...

At its most basic, a "bundle" is a directory with a certain structure.
An .app is a bundle, as are an .rtfd document and a .framework library.

An app is a bundle that contains an application (complete with its
resources, like images, property list files, text data used by the app,
etc.).

An RTFD is a compound-document bundle containing an RTF file and usually
some image files.

A Framework is a bundle containing a special shlib, headers, and resources
(executables, images, etc.)

In this case, CDDB.bundle is just your basic "loadable bundle", containing
code and/or resources that can be loaded into an app using the NSBundle
interface. This one provides code in the form of a class to query a cddb
server.

By the way, .prefs modules (used by Preferences, preferences.app in Debian
and one of my apps) are bundles too.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Projecthttp://www.quakeforge.net/
| Specializing in Debian GNU/Linux  http://www.d2dc.net/~deek/

Re: Bug#274957: ITP: susv3 -- Fetch and install SUSv3 documentation

[Hamish Moffatt]

On Tue, Oct 05, 2004 at 04:05:50PM +0200, Petter Reinholdtsen wrote:
> [Hamish Moffatt]
> > Why is it useful to fetch this documentation and install it through a
> > Debian package, rather than say with your favourite web browser?
> 
> Offline reading?

wget?

Why is this document useful for offline reading and not a few billion
others? (And where's that package of the Finnish constituition we were
promised a few years back?!)


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Bug#259400: How to a user can add menu entry for GNOME ?

[Miles Bader]

Marc Dequènes (Duck) <[EMAIL PROTECTED]> writes:
> BTW, if i'm not dead for GNOME 2.10, custom Debian menu is gonna die, as
> it is a bunch of unbrowseable nightmare stuff.

That seems a tad overwrought.

I usually prefer the debian menu because it's much more complete than
the gnome menu, and often better categorized (the gnome menu sometimes
has this bizarre "microsoft-view" feel to it -- e.g., it sticks Emacs
under "Accessories"?!?).

AFAICS, the main advantage to the gnome menu is the pretty icons.

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: PRINT EPSON STYLUS C82; bug #235522?

[Bernd Schubert]

Alexander Schmehl wrote:

> * SAVERIO FERRARO <[EMAIL PROTECTED]> [041005 18:49]:
>> I HAVE SOME PROBLEMS WITH THE CONFIGURATION OF THIS PRINT.
>> HOW HAVE I TO DO?
> 
> Tell us your problem, and we might be able to help.
> 
> Oh, and in case you didn't noticed: Your caps-lock key seems to be
> broken.
> 
> 
> Yours sincerely,
>   Alexander


May its its bug #235522?

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

I filled this bug report pretty much time ago and the maintainer doesn't
seem to care. I tried to fix it myself, but even the cups newsgroup
couldn't help me with it. Unfortunality the error messages don't make any
sense to me or to someone else.
However, I would really be glad if not only me would care more about this
bug. IMHO its release critical, since it not only effects the C82, but
maybe all recent stylus printers. When I wrote this bug report, I didn't
know yet that many others Epson stylus printers do have the very same
problem.

Thanks,
 Bernd

Bug#275103: ITP: 6wall -- IPv6 Firewall, based on Shorewall

[Mikael Magnusson]

Package: wnpp
Severity: wishlist

* Package name: 6wall
  Version : 1.0.2
  Upstream Author : Eric de Thouars <[EMAIL PROTECTED]>
* URL or Web page : http://leaf-project.org/doc/howto/6wall.html
* License : GPL
  Description : IPv6 Firewall, based on Shoreline Firewall (Shorewall)

 6wall is a Netfilter (ip6tables) based firewall that can be used on a
 dedicated firewall system, a multi-function gateway/router/server or
 on a standalone GNU/Linux system.
 .
 6wall is for IPv6 what Shorewall is for IPv4.
 .
  Homepage: http://leaf-project.org/doc/howto/6wall.html

Prerelease:
http://mentors.debian.net/debian/pool/main/6/6wall/

/Mikael Magnusson

Bug#275093: ITP: gaim-encryption -- encryption plugin for gaim

[Chris Vanden Berghe]

Package: wnpp
Severity: wishlist

* Package name: gaim-encryption
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : encryption plugin for gaim

Gaim-Encryption uses NSS to provide transparent RSA encryption as a Gaim plugin.

http://gaim-encryption.sourceforge.net/

Re: Updating scanners and filters in Debian stable (3.1)

[Colin Watson]

On Tue, Oct 05, 2004 at 12:08:42PM -0700, Thomas Bushnell BSG wrote:
> Stephen Gran <[EMAIL PROTECTED]> writes:
> > I am under the impression that 'normal procedures' does not involve
> > updating the application to catch new threats.  If I'm wrong, then there
> > is no need for this entire thread.
> 
> Talk to the security team.  Talk to the security team.  Talk to the
> security team.

Thomas, that's enough. Other people have legitimate disagreements with
your preferred approach; rude use of repeated assertion is not going to
automatically win you the argument.

FWIW, I think that every upload to the security archive should be
accompanied by a security advisory. I wouldn't be at all surprised if
the security team felt that uploads that don't merit security advisories
were an inappropriate use of their archive.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]

Re: Updating scanners and filters in Debian stable (3.1)

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> I am under the impression that 'normal procedures' does not involve
> updating the application to catch new threats.  If I'm wrong, then there
> is no need for this entire thread.

Talk to the security team.  Talk to the security team.  Talk to the
security team.

Re: Bug#274923: ITP: wnpp -- C++ library for robust numerical and geometric computation

[Joachim Reichel]

Hi,
>>If the names above are still too generic, I think I will use libcore++ as
>>prefix. Or has anyone else another suggestion?
>
> Why not libexact?
Maybe, but I'd prefer if "core" is part of the package name, because is is 
known under this name in the scientific community.

>>I'm a bit uncertain about potential consequences if the Debian package name
>>differs too much from the upstream package name.
>
> Programs which would use the library will have to customize. That should
> be done anyway easy in any decent program.
Uups, I missed that I might have to change the name of the library itself. 
Or is it possible to have a package named "libcore++1" containing libraries 
"libcore.so.1"? (If yes, there is still the problem that a quite generic 
(file)name is used.)

I'd like to avoid changing the soname of the library, because that would be 
a large disadvantage for the users of this library. I guess most of them 
would prefer compiling the upstream sources themselves rather than handling 
the special case of a different library name for Debian installations.

Regards,
  Joachim

Re: PRINT EPSON STYLUS C82

[Frederik Dannemare]

On Tuesday 05 October 2004 18:49, SAVERIO FERRARO wrote:
> I HAVE SOME PROBLEMS WITH THE CONFIGURATION OF THIS PRINT.
> HOW HAVE I TO DO?
> THANKS

You should really start out by reading 
http://www.catb.org/~esr/faqs/smart-questions.html (especially 
http://www.catb.org/~esr/faqs/smart-questions.html#beprecise). 
Then ask again (but on debian-user instead).

Best regards,
-- 
Frederik Dannemare | mailto:[EMAIL PROTECTED]
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://frederik.dannemare.net | http://www.linuxworlddomination.dk

Bug#275073: ITP: hsql -- Multi-Database Interface System for Haskell

[John Goerzen]

Package: wnpp
Severity: wishlist

* Package name: hsql
  Version : 1.4
  Upstream Author : Krasimir Angelov
* URL : http://sourceforge.net/project/showfiles.php?group_id=65248
* License : BSD
  Description : Multi-Database Interface System for Haskell
 HSQL provides interfaces for Haskell programmers to the PostgreSQL,
 MySQL, SQLite, and UnixODBC database systems.  There is a generic
 abstract interface so that code can be used interchangably with these
 database systems.  In this sense, it is similar to Java's JDBC,
 Python's DB-API, or Perl's DBI.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=en_US

Bug#275071: ITP: hunit -- Haskell Unit Testing Framework

[John Goerzen]

Package: wnpp
Severity: wishlist

* Package name: hunit
  Version : 1.0
  Upstream Author : Dean Herington
* URL : http://hunit.sf.net/
* License : BSD
  Description : Haskell Unit Testing Framework
 HUnit is a unit testing framework for Haskell, inspired by the JUnit
 tool for Java.
 .
 The HUnit philosphy is that a test-centered methodology for software
 development is most effective when tests are easy to create, change,
 and execute.
 .
 With HUnit, as with JUnit, you can easily create tests, name them,
 group them into suites, and execute them, with the framework checking
 the results automatically.  Test specification in HUnit is even more
 concise and flexible than in JUnit, thanks to the nature of the
 Haskell language. Unit currently includes only a text-based test
 controller, but the framework is designed for easy extension.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=en_US

Bug#275070: ITP: missingh -- Library of utility functions for Haskell

[John Goerzen]

Package: wnpp
Severity: wishlist

* Package name: missingh
  Version : 0.1.0
  Upstream Author : John Goerzen <[EMAIL PROTECTED]>
* URL : gopher://quux.org/devel/missingh
(not yet active)
* License : GPL
  Description : Library of utility functions for Haskell
 MissingH is a library of all sorts of utility functions for
 Haskell programmers.  It is written in pure Haskell and thus should
 be extremely portable and easy to use.  It also has no prerequisites
 save those that are commonly included with Haskell compilers.
 .
 MissingH is based on my MissingLib library for OCaml and contains some
 of the same features.  However, some features are left behind because
 they are already in Haskell or not needed here -- and others are added
 due to things Haskell is missing, or things that Haskell makes
 possible.
 .
 [ insert module summary here ]

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=en_US

Bug#275069: ITP: haskell-cabal -- Haskell Common Architecture for Building Applications and Libraries

[John Goerzen]

Package: wnpp
Severity: wishlist

* Package name: haskell-cabal
  Version : 0.1
  Upstream Author : Isaac Jones <[EMAIL PROTECTED]>
* URL : http://www.haskell.org/cabal
* License : BSD
  Description : Haskell Common Architecture for Building Applications and 
Libraries
 The Haskell Cabal is a system for building and installing Haskell
 programs and libraries.  It is aware of multiple different compilers
 and can handle them without trouble.
 .
 This package will provide the infrastructure necessary to build
 Cabalized packages on Debian machines, or to Debianize those packages.

Isaac Jones already has a basic debian/ directory of this package, from
which I will be starting.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=en_US

Re: If ATI and nVidia don't support their own products, who does?

[Andreas Rottmann]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> Hi, Brendan wrote:
>
>> Open Source is awesome, but most hardware companies are
>> never, ever going to open their hardware.
>
> There's a rather large difference between telling people how to talk to
> the hardware they buy (some interpretations of German law suggest that one
> *has* to do that; for instance, you're legally required here to provide
> schematics so that people can, theoretically these days, repair their VCRs
> if they break), and giving away the design files for the chips so that
> others can go to their own fab and recreate one (which is what "open
> hardware" ultimately means).
>
Yes, reminds one of the difference between publishing API specs and
publishing the whole source code.

Andy
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://yi.org/rotty  | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

The best way to accelerate a Windows machine is at 9.81 m/s^2

Re: Bug#274923: ITP: wnpp -- C++ library for robust numerical and geometric computation

[Francesco Paolo Lovergine]

On Tue, Oct 05, 2004 at 06:58:07PM +0200, Joachim Reichel wrote:
> 
> If the names above are still too generic, I think I will use libcore++ as 
> prefix. Or has anyone else another suggestion?
> 

Why not libexact?

> I'm a bit uncertain about potential consequences if the Debian package name 
> differs too much from the upstream package name.
> 

Programs which would use the library will have to customize. That should
be done anyway easy in any decent program.

-- 
Francesco P. Lovergine

Re: PRINT EPSON STYLUS C82

[Alexander Schmehl]

* SAVERIO FERRARO <[EMAIL PROTECTED]> [041005 18:49]:
> I HAVE SOME PROBLEMS WITH THE CONFIGURATION OF THIS PRINT.
> HOW HAVE I TO DO?

Tell us your problem, and we might be able to help.

Oh, and in case you didn't noticed: Your caps-lock key seems to be
broken.


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: Bug#274923: ITP: wnpp -- C++ library for robust numerical and geometric computation

[Joachim Reichel]

Hi,
Package: wnpp
Severity: wishlist
* Package name: core
This seems a tad generic, especially since it's a library.  Maybe
libcoremath or libcore++?
Hmm, you're right. Does your comment only apply to the source package name 
or also to the binary package names? I intend to make the following packages:

Source: libcore
Binary: libcore1, libcore-dev, libcore-doc, libcore-demo
If the names above are still too generic, I think I will use libcore++ as 
prefix. Or has anyone else another suggestion?

I'm a bit uncertain about potential consequences if the Debian package name 
differs too much from the upstream package name.

Regards,
  Joachim

PRINT EPSON STYLUS C82

[SAVERIO FERRARO]

I HAVE SOME PROBLEMS WITH THE CONFIGURATION OF THIS PRINT.
HOW HAVE I TO DO?
THANKS
_
Personalizza MSN Messenger con sfondi e fotografie! 
http://www.ilovemessenger.msn.it/

Re: Updating scanners and filters in Debian stable (3.1)

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> Stephen Gran <[EMAIL PROTECTED]> writes:
> 
> > This is exactly the problem.  I don't think that most people actually
> > think it would be better to release either no AV/spam/whatever software
> > or useless software.  I am getting the impression that people don't want
> > to disrupt the stability of the rest of the archive in order to provide
> > useful tools that must evolve rapidly, and this is difficult to resolve.
> 
> You are incorrect.  You can certainly provide the useful tools, but
> you need to do the evolution in concert with the security team
> following its normal procedures.

I am under the impression that 'normal procedures' does not involve
updating the application to catch new threats.  If I'm wrong, then there
is no need for this entire thread.

Look, I don't want to drag this out.  I am hoping for a straight forward
'yes, it will be OK to upload new versions to catch new threats' or 'no, 
stable is stable' type response.  If it's the latter, I don't see that
programs like clam or spamassassin (or IDS's, etc) belong in stable,
since they become outdated so quickly, and I'll file a bug to remove
clam from sarge.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpsUs74xSpwt.pgp
Description: PGP signature

Re: Updating scanners and filters in Debian stable (3.1)

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> This is exactly the problem.  I don't think that most people actually
> think it would be better to release either no AV/spam/whatever software
> or useless software.  I am getting the impression that people don't want
> to disrupt the stability of the rest of the archive in order to provide
> useful tools that must evolve rapidly, and this is difficult to resolve.

You are incorrect.  You can certainly provide the useful tools, but
you need to do the evolution in concert with the security team
following its normal procedures.

Thomas

Re: Bug#273734: education-common: con't fulfill the Recommends on !i386

[Adrian Bunk]

On Mon, Oct 04, 2004 at 11:04:05PM -0400, Kevin Mark wrote:
> Hi Adrian,
> if 'boot-loader' was not a real package (not sure if it requires a new
> catagory or if it fits under meta or virtual) and then when you did:
> apt-get install boot-loader
> it (dpkg or apt -- not sure) checked your ARCH and then install the one that
> 'provides: boot-loader' and matches your ARCH
> where
> Package: lilo
> Provides: boot-loader
> Architecture: i386
 and
> Package: silo
> Provides: boot-loader
> Architecture: sparc
> 
> And would install lilo on i386 and silo on sparc. The idea is that they
> both provide similar functionality but are arch dependant.
> 
> Not sure what to do if more than one package can satisfy the 'provides'.

The problem in this specific case was, that a binary-all package wanted 
to have grub installed instead of lilo.

Yes, you can solve some problems using virtual packages like 
boot-loader.

No, you can't solve all problems using virtual packages like 
boot-loader.

> Hope this is not too OT but I'm trying to understand under the hood.
> -Kev

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep

[Graham Wilson]

On Tue, Oct 05, 2004 at 11:00:56AM +0100, Matthew Garrett wrote:
> Graham Wilson <[EMAIL PROTECTED]> wrote:
> > When I said "without GNOME installed," I meant without the entire GNOME
> > desktop environment installed: nautilus, gnome-session, metacity, etc.
> 
> No Gnome application I'm aware of requires metacity. I don't believe
> that gnome-session will be pulled in except for very strange cases.
> Nautilus certainly isn't required.

I'm aware of that. My point was that GNUstep applications, like GNOME
applications, don't require all of the standard desktop environment
components (such as metacity, gnome-session, nautilus, etc.) to be
installed for the application to work.

-- 
gram

Re: downloading selected source packages automatically

[Alexander Schmehl]

* ROBERTOJIMENOCA <[EMAIL PROTECTED]> [041005 16:00]:

> So I download the source package (dsc, diff.gz & tar.gz), dpkg-source
> it, apply my patches, dpkg-buildpackage
> -rfakeroot, install it and mark it for hold so when upgrading a newer
> version isn't installed.

I didn't tried it myself, but looking at the manpage of apt-build, it
seems that it can shorten that a lot:
apt-build --patch  install 


> Is there a command to do that?
> What about automating the whole process as much as possible?

Don't know if you can automate the whole thing with apt-build.  If not
you could combine it with an cron-apt and an extra action for apt-build,
or subscribe to the interested package at
http://packages.qa.debian.org/ and create a realy cool
procmail-rule for that ;)


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: downloading selected source packages automatically

[Christoph Berg]

Re: ROBERTOJIMENOCA in <[EMAIL PROTECTED]>
> So I have, in a folder,  something like:
> glibc_2.3.2.ds1-16.diff.gz
> glibc_2.3.2.ds1-16.dsc
> glibc_2.3.2.ds1.orig.tar.gz
> 
> and just running a command have that files upgraded to the latest
> version.

cd src && rm -rf glibc_* glibc-* && apt-get source glibc

For more hints, please ask on debian-user.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/

downloading selected source packages automatically

[ROBERTOJIMENOCA]

I have to compile many packages from source because some of my patches
are not applied upstream. So I download the source package (dsc, diff.gz
& tar.gz), dpkg-source it, apply my patches, dpkg-buildpackage
-rfakeroot, install it and mark it for hold so when upgrading a newer
version isn't installed.

I'd like to have this process automated as much as possible so I'd like
to have the source packages I need downloaded when there are new
versions and the old sources removed (as I won't use them anymore)

So I have, in a folder,  something like:
glibc_2.3.2.ds1-16.diff.gz
glibc_2.3.2.ds1-16.dsc
glibc_2.3.2.ds1.orig.tar.gz

and just running a command have that files upgraded to the latest
version.

Is there a command to do that?
What about automating the whole process as much as possible?

Re: Bug#273734: education-common: con't fulfill the Recommends on !i386

[Joey Hess]

Steve Langasek wrote:
> >   - Getting the packages into testing, which was previously apparently
> > impossible.
> >   - Avoiding the common problem with task packages that if you remove
> > one package in the task, you have to remove the task package as
> > well, since its dependecies are then broken.
> >   - As part of the phasing out of the old reason for the old-type task
> > packages; selection of the packages in these tasks are not handled at
> > the tasksel level by recommends fields ayway, but by tasksel package
> > lists in the education-tasks package. The new task packages will
> > mostly be useful for post-install sysadmin and upgrade purposes.
> 
> The first two of these advantages would no longer be present if britney
> treated Recommends the same way as it treats Depends, which is why I
> ask.

No, only the first point could be affected by changes to britney. In the
second point I'm talking about removing a package from an installed
system.

> I'm confused about your third point, here; the current debian-edu
> package represents the "new"-style task packages?

The current debian-edu packages are something of a midway point between
how task packages were traditionally done and how I hope they'll be done
in the future.

> What is clear to me is that the intended semantics of the
> education-common are that it install the Recommends: if available, and
> ignore them if they're not.

Yep.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#274957: ITP: susv3 -- Fetch and install SUSv3 documentation

[Petter Reinholdtsen]

[Hamish Moffatt]
> Why is it useful to fetch this documentation and install it through a
> Debian package, rather than say with your favourite web browser?

Offline reading?

Re: Bug#274957: ITP: susv3 -- Fetch and install SUSv3 documentation

[Hamish Moffatt]

On Mon, Oct 04, 2004 at 07:11:43PM -0400, Jeff Bailey wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: susv3
>   Upstream Author : Copyright (c) 2001-2003 IEEE and The Open Group
> * License : Installer Package: Public Domain
>   Description : Fetch and install SUSv3 documentation
> 
> This package was created at the request of Andrew Josey from the
> Austin Group (The committee that handles the Posix standards).  The
> documents do not allow redistribution, but are located in a way that
> is easy to fetch.  Because the upstream documentation is non-Free, this
> package is targetted at contrib.

Why is it useful to fetch this documentation and install it through a
Debian package, rather than say with your favourite web browser?

thanks,
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Updating scanners and filters in Debian stable (3.1)

[Florian Weimer]

* Thiemo Seufer:

> How could clamav possibly have a stable engine and suddenly start to
> need libfoo?

Most antivirus software today is a framework for mobile code
distribution.  Too often, you have to replace MIME decoders, HTTP
decoders, and the like.

I find it rather strange that new dependencies are suddenly
introduced.  I'd rather think that upstream no longer supports the
version in sarge some time after sarge is released, and the newest
upstream version might have different dependencies.

We have the same problem with Mozilla (it's actually worse because
other packages depend on Mozilla internals).

looking for font package sponsors

[Gürkan Sengün]

I am looking for sponsors to close the following ITPs:

#268613 ttf-summersby
http://www.linuks.mine.nu/i_debian/ttf-summersby/

#268722 ttf-f500
http://www.linuks.mine.nu/i_debian/ttf-f500/

Thanks,
Gürkan Sengün

Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep

[Matthew Garrett]

Graham Wilson <[EMAIL PROTECTED]> wrote:

> When I said "without GNOME installed," I meant without the entire GNOME
> desktop environment installed: nautilus, gnome-session, metacity, etc.

No Gnome application I'm aware of requires metacity. I don't believe
that gnome-session will be pulled in except for very strange cases.
Nautilus certainly isn't required.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep

[Frank Küster]

Jeff Teunissen <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>
>> If I'm wrong, I apologize and will not object against cddb.bundle (at
>> least not because of this. Still the ".bundle" part is meaningless to
>> me, but that might be due to my bad english). If I am not wrong, and
>> GNUstep applications are indeed not designed to be used without using
>> the Desktop environment, then, please, add "gnustep-" to the name.
>
> Yes, you are _very_ clearly wrong. There is no GNUstep program that requires
> the GNUstep Desktop, because there no GNUstep Desktop to require!

Okay, then I don't mind leaving gnustep out (I still wonder why you
wouldn't cry "But I want gnustep in the name" for advertising
reasons). I still wonder what "bundle" could mean...

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

Re: Bug#274986: RFP: lives -- Video editing system

[Free Ekanayaka]

Closing this RFP, and ITP already exists:

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

Cheers,

Free

|--==> Free Ekanayaka writes:

  FE> Package: wnpp
  FE> Severity: wishlist

  FE> * Package name: lives
  FE>   Version : 0.9.1-pre6
  FE>   Upstream Author : G. Finch <[EMAIL PROTECTED]>
  FE> * URL or Web page : http://www.xs4all.nl/~salsaman/lives/
  FE> * License : GPL
  FE>   Description : Linux video editing system

  FE> LiVESis designed to be simple to use, yet powerful. It is small in
  FE> size, yet it has many advanced features. It is part editor, part 
  FE> VJ tool. It is fully extendible through open standard RFX plugin scripts.

  FE> LiVES lets you start editing and making video right away, without
  FE> having  to worry about formats, frame sizes, or framerates. LiVES
  FE> will let you start creating your own tools, utilities and effects
  FE> via the built in RFX builder.

  FE> LiVES is aimed at the digital video artist who wants to create their
  FE> own content, the video editor who wants to create professional looking
  FE> video, and the VJ who wants to captivate with spectacular images.

  FE> Cheers,

  FE> Free Ekanayaka

Bug#274986: RFP: lives -- Video editing system

[Free Ekanayaka]

Package: wnpp
Severity: wishlist

* Package name: lives
  Version : 0.9.1-pre6
  Upstream Author : G. Finch <[EMAIL PROTECTED]>
* URL or Web page : http://www.xs4all.nl/~salsaman/lives/
* License : GPL
  Description : Linux video editing system

LiVESis designed to be simple to use, yet powerful. It is small in
size, yet it has many advanced features. It is part editor, part 
VJ tool. It is fully extendible through open standard RFX plugin scripts.

LiVES lets you start editing and making video right away, without
having  to worry about formats, frame sizes, or framerates. LiVES
will let you start creating your own tools, utilities and effects
via the built in RFX builder.

LiVES is aimed at the digital video artist who wants to create their
own content, the video editor who wants to create professional looking
video, and the VJ who wants to captivate with spectacular images.

Cheers,

Free Ekanayaka

Re: Updating scanners and filters in Debian stable (3.1)

[Francesco P. Lovergine]

On Tue, Oct 05, 2004 at 07:54:51AM +0200, martin f krafft wrote:
> also sprach Matthew Garrett <[EMAIL PROTECTED]> [2004.10.05.0015 +0200]:
> > > We can push neither of them into Debian via security.d.o. No,
> > > sorry, this is not the way stable works.
> > 
> > /Should/ it be the way stable works? We have the ability to change
> > that.
> 
> No. It's "stable". It's one of the major features of Debian that we
> do not pull in dependencies but rather backport the fixes. People
> have come to rely on it.
> 
> I consider volatile software a whole new class which cannot fit in
> with the regular "never touch a running system" paradigm because it
> needs to be cutting edge.
> 
> Thus, I would consider it perfectly sensible for Debian to have
> a new archive, e.g. volatile.debian.org, which plays nice with the
> current stable, but which has turnaround times of a couple of days
> at max.
> 

I agree. Security as is currently is perfectly suitable in many
circumstances, and administrator (me for instance) could like the 
way things are currently done, i.e. no changes at all and backported
patches for security. Not all the world needs on all boxes an up-to-date
AV, and up-to-date anti-spam (or the latest Mozilla if we would agree
about the opportunity of major upgrades for some selected programs).
The ratio of a reasonable up-to-date volatile.d.o archive segregated 
in respect with security.d.o is all in this pov.

Incidentally, volatile could also be used to upgrade stable for interactive use,
which is probably the major reason of obsolescence for stable, but that's
questionable.


-- 
Francesco P. Lovergine

Re: Updating scanners and filters in Debian stable (3.1)

[Francesco P. Lovergine]

On Mon, Oct 04, 2004 at 11:46:29PM +0200, Andreas Barth wrote:
> * Francesco Paolo Lovergine ([EMAIL PROTECTED]) [041004 19:40]:
> > What we probably need is the infrastructure to support the volatile
> > archive (buildd support and pools) and a general policy for those kind 
> > of updates. Program choices could be done later, as for point releases.
> 
> I think the major difference between volatile and backports.org should
> be that volatile makes also "releases", and between two releases, only
> security fixes are done on the archive. This gives the benefit that it
> doesn't require that often administrator action (and perhaps an staging
> area where the newest things are in, and that is moved to stable once
> everything is done).
> 

Yep, that was the idea behind the need of a policy and a RM.

-- 
Francesco P. Lovergine

Re: Seeking "one-time" Hungarian translators for Debian Installer

[VEROK Istvan]

On Tue, 5 Oct 2004, Christian Perrier wrote:

> Unfortunately, I'm currently unable to get news from Istvan Verok, our
> usual and very efficiant Hungarian translator.
[snip]
> Hungarian has always been complete in past D-I releases and most often
> quickly, so I suspect an unscheduled event for Istvan (indeed I cross
> fingers and hope he hadn't any bad family/health/whatever event)..

I'm alive, no worries, just snowed under by unrelated real-life events.
I'll hopefully be able to carve out a couple of hours this evening for
d-i, but right now I need to work work work...

Cheers,
Istvan

Re: Updating scanners and filters in Debian stable (3.1)

[Wouter Verhelst]

On Tue, Oct 05, 2004 at 07:28:21AM +0100, John Lines wrote:
> 
> > >
> > > clamav can be as stable as a rock but be completely useless... when
> > > two months after Sarge's release, a new virus hits hard, and in
> > > order to detect it, clamav needs libfoo, which is not in Debian.
> > > What then? *Maybe* we could push a new clamav via security.d.o, but
> > > what about libfoo?
> >
> You could take the rather horrible step of building a static copy of libfoo 
> into clamav. This would be rather messy, but would allow a single binary to 
> be updated.

Thanks, but no thanks.

What will happen when now libfoo needs a security update?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Looking for ontologies useful for debtags

[Branden Robinson]

On Sun, Oct 03, 2004 at 01:22:13AM +0200, Enrico Zini wrote:
> in organizing the tags that compose debtags, it would be nice to reuse
> existing ontologies for our facets (groups of tags from specific points
> of view), so that we could have some facets that could be linking points
> for other existing knowledge bases.

Enrico,

Casting "Eray Summoning IX" is prohibited in Debian and is a bannable
offense.  :-P

Quick, everyone, scoot your feet across his thaumaturgic circle before he
finishes his spell...

-- 
G. Branden Robinson|  Never underestimate the power of
Debian GNU/Linux   |  human stupidity.
[EMAIL PROTECTED] |  -- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Updating scanners and filters in Debian stable (3.1)

[martin f krafft]

also sprach John Lines <[EMAIL PROTECTED]> [2004.10.05.0828 +0200]:
> You could take the rather horrible step of building a static copy
> of libfoo into clamav. This would be rather messy, but would allow
> a single binary to be updated.

The problem is not so much that a new dependency would be needed but
that by taking this route, we accept complete entities of untested
code right into stable.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: If ATI and nVidia don't support their own products, who does?

[Matthias Urlichs]

Hi, Brendan wrote:

> Open Source is awesome, but most hardware companies are
> never, ever going to open their hardware.

There's a rather large difference between telling people how to talk to
the hardware they buy (some interpretations of German law suggest that one
*has* to do that; for instance, you're legally required here to provide
schematics so that people can, theoretically these days, repair their VCRs
if they break), and giving away the design files for the chips so that
others can go to their own fab and recreate one (which is what "open
hardware" ultimately means).

-- 
Matthias Urlichs

Re: Updating scanners and filters in Debian stable (3.1)

[John Lines]

> >
> > clamav can be as stable as a rock but be completely useless... when
> > two months after Sarge's release, a new virus hits hard, and in
> > order to detect it, clamav needs libfoo, which is not in Debian.
> > What then? *Maybe* we could push a new clamav via security.d.o, but
> > what about libfoo?
>
You could take the rather horrible step of building a static copy of libfoo 
into clamav. This would be rather messy, but would allow a single binary to 
be updated.

-- 
John Lines 

Re: backports.org (was: Updating scanners and filters in Debian stable (3.1))

[martin f krafft]

also sprach Norbert Tretkowski <[EMAIL PROTECTED]> [2004.10.05.0018 +0200]:
> Some quick & dirty perl and shell scripts. I plan to completely
> rewrite these scripts in python soon.

Superb. It would rock if you could make this available as a package
(which I am sure you will). I think many of use could profit from
that in our own staging archives.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Updating scanners and filters in Debian stable (3.1)

[martin f krafft]

also sprach Matthew Garrett <[EMAIL PROTECTED]> [2004.10.05.0015 +0200]:
> > We can push neither of them into Debian via security.d.o. No,
> > sorry, this is not the way stable works.
> 
> /Should/ it be the way stable works? We have the ability to change
> that.

No. It's "stable". It's one of the major features of Debian that we
do not pull in dependencies but rather backport the fixes. People
have come to rely on it.

I consider volatile software a whole new class which cannot fit in
with the regular "never touch a running system" paradigm because it
needs to be cutting edge.

Thus, I would consider it perfectly sensible for Debian to have
a new archive, e.g. volatile.debian.org, which plays nice with the
current stable, but which has turnaround times of a couple of days
at max.

> Providing that we only do it for the set of software that would
> otherwise be entirely useless by the time we make a new release,
> I don't see that it compromises any existing principles.

The same reason why we do not merge s.d.o into stable but distribute
it separately. Give people the choice!

> Debian stable is about providing a stable platform that people can
> build upon. It's about providing something that can be trusted to
> work, rather than one where upgrades break things. It's not about
> slavish adherance to the idea that we should never change any of
> it.

I completely agree. Thank you for stating it. I think this should be
something to have in the back of our heads in other parts of Debian
too.

> If you can find one real person who believes that it would be
> better to either have no virus checker or one that will be
> entirely useless after 4 weeks than it would be to have updates
> that might actually provide new functionality, I'll be impressed.

I just asked my 16 months old god child and she replied "ja ja ja"
and smiled. Now if you consider her not a real person, I'll come
after you!

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Seeking "one-time" Hungarian translators for Debian Installer

[Christian Perrier]

This is a quite unusual call, but a quite urgent one.

Debian installer is currently in its final stages of development and
currently in what we call a "string freeze". This means that no change
to translatable parts happen, allowing translator to finish their
work.

The string freeze lasts until Oct. 6th 16:00UTC.

Unfortunately, I'm currently unable to get news from Istvan Verok, our
usual and very efficiant Hungarian translator.

A few strings (42 over 1257) remains to be completed, 24 of which
being "fuzzy", which means they are partly translated.

Completing this is, imho, a 1-2 hours job, including the required time
for installing kbabel and learn the basics for using it...

Hungarian has always been complete in past D-I releases and most often
quickly, so I suspect an unscheduled event for Istvan (indeed I cross
fingers and hope he hadn't any bad family/health/whatever event)..

I cc'ed people I found in my debian-devel backlog, with a .hu address.

It would be nice if some of you can complete the work before the
deadline. Please keep the above addresses when responding, including
mine, so that everyone knows that someone volunteered. I'll give the
needed indications.

Of course, if Istvan mentiond he will complete his work, he has the
priority : he did all the job and I use this as a very last attempt to
get hu complete

PS : this is really a "one-time" need. Of course, no-one will prevent
you from collaborating to hu translations in the future, but no-one
will force you to do so, also..:-)

-- 

Re: proposal: factoids bot on #debian-devel

[Adeodato Simó]

* Rob Weir [Tue, 05 Oct 2004 09:45:38 +1000]:

> Is this any more useful than a wiki FAQ?

  From: madduck
  To: gort
  Subject: ~tell Rob I asked for private answers

  From: gort
  To: Rob
  Subject: Rob, madduck asked for private answers

scnr,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Let us not be ashamed to speak what we shame not to think.
-- Michel de Montaigne