NEWS.Debian support is here

[Joey Hess]

Thanks to Matt Zimmerman and Joe Drew, apt-listchanges will now display
NEWS.Debian entries for upgraded packages. They're displayed before the
regular changelog entries, and Matt plans to later let it be configured
to only display news, if the user wants (more useful for stable users).

The NEWS.Debian file is installed as
/usr/share/doc//NEWS.Debian.gz. Always compressed, always with
that name even in native packages. If you use debhelper, upgrade to
4.1.51 and dh_installchangelogs will install debian/NEWS files for you[1].

The file format is the same as a debian changelog file, but we leave off the
asterisks generally, and use bigger paragraphs explaining news items when
necessary. It might be a good idea to run your file through
dpkg-parsechangelog to check its formatting as it will not be automatically
checked during build as the changelog is. I expect there will be a lintian
check eventually. Here's a real life example of a NEWS.Debian file:

libinline-perl (0.43-5) unstable; urgency=low

  Note that when you upgrade from perl 5.6 to 5.8, binaries built with
  libinline (this may include compiled objects cached in .Inline/_Inline
  directories) will fail to work with the new version of perl. This is
  because perl's ABI for binaries changed between perl 5.6 and 5.8.

  The solution is the delete and regenerate any such binaries you might have.
  I have not tried to automate this in the Debian package.

 -- Joey Hess <[EMAIL PROTECTED]>  Wed, 11 Sep 2002 21:37:56 -0400

Unlike changelog files, you don't update NEWS.Debian files with every
release. Only update them if you have something particularly newsworthy
that user should know about.

I'm putting off getting this into policy until enough stuff uses it that we
can tell it works well. But as of today it's a valid way to communicate
important changes to the users of your package.

-- 
see shy jo

[1] Actually, debhelper has supported this for a long time already, but it
got the file name wrong for native packages.


pgpPaUnCEZSPx.pgp
Description: PGP signature

Re: Debconf or not debconf : Conclusion

[Joey Hess]

Marc Singer wrote:
> There is the related trouble that the only way to disable most
> packages is to uninstall them.  Sometimes, it is desirable to
> temporarily disable a service without removing the binaries or
> changing the executability of the init.d script.

Take a look at invoke-rc.d and its policy program.

-- 
see shy jo


pgpADXOdaNxUV.pgp
Description: PGP signature

Re: Debconf or not debconf : Conclusion

[Joey Hess]

Theodore Ts'o wrote:
> On a separate but related topic, I think a much better approach would
> be to handle configuration as a step entirely separate from the
> install phase.  Let the install be entirely quiet, and let packages
> have intelligent defaults.  If the package absolutely must be
> configured before it can be used, then let it be non-functional until
> someone actually calls dpkg-configure (which would be just like
> dpkg-reconfigure except that's the only time the questions would be
> asked).

Debconf is flexable enough so you can do that already (assuming all
packages use debconf).

- comment out the dpkg-preconfigure call in /etc/apt/apt.conf.d/70debconf
- set in /etc/debconf.conf:
Frontend: noninteractive
Admin-Email:
- dpkg-configure is the following script:
#!/bin/sh -e
dpkg-reconfigure --unseen-only --default-priority -freadline $@

-- 
see shy jo


pgpHjE1t7saSk.pgp
Description: PGP signature

Re: Debconf or not debconf : Conclusion

[Marc Singer]

On Fri, Jul 04, 2003 at 01:11:48AM -0400, Joey Hess wrote:
> Theodore Ts'o wrote:
> > On a separate but related topic, I think a much better approach would
> > be to handle configuration as a step entirely separate from the
> > install phase.  Let the install be entirely quiet, and let packages
> > have intelligent defaults.  If the package absolutely must be
> > configured before it can be used, then let it be non-functional until
> > someone actually calls dpkg-configure (which would be just like
> > dpkg-reconfigure except that's the only time the questions would be
> > asked).
> 
> Debconf is flexable enough so you can do that already (assuming all
> packages use debconf).
> 
> - comment out the dpkg-preconfigure call in /etc/apt/apt.conf.d/70debconf
> - set in /etc/debconf.conf:
> Frontend: noninteractive
> Admin-Email:
> - dpkg-configure is the following script:
> #!/bin/sh -e
> dpkg-reconfigure --unseen-only --default-priority -freadline $@

My reading of Ted's comment is that this ought to be the *default*
policy.  I won't go so far as to say that RH made a better choice, but
I don't really see the benefit of the all of the warning messages when
once displayed they are nowhere to be found.  Perhaps, you'll have a
command for recovering these messages, but that doesn't change the
fact that they are just not really necessary at install time.

Re: Please remove RFCs from the documentation in Debian packages

[Marcelo E. Magallon]

On Thu, Jul 03, 2003 at 02:42:10PM -0500, Branden Robinson wrote:

 > And, incidentally, the specific issue you address has -- I'm sure you'll
 > be quite startled -- discussed at length on debian-legal.  Maybe you
 > ought to check out those archives?

 I'm well aware that some people have flogged the horse.  That doesn't
 mean these people have reached a satisfactory conclusion, that they are
 "right" in any sense of the word or that said conclusion is consistent
 with other opinions voiced by these people.

 Again, I'm not talking about the legal document, I'm talking about the
 file.  The statement I quoted does not allow for modifications, no
 matter the purpose.

 Now, would you care to be self-consequent?

-- 
Marcelo

Re: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote:
> On Thu, 2003-07-03 at 14:53, Cameron Patrick wrote:
> > On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote:
> > 
> > | The Debian Social Contract says "Debian Will Remain 100% Free Software".
> > | If there are things "in Debian" that are "not free" or "not software",
> > | then we may be violation of our guiding principles.
> > 
> > The anarchism package is an excellent example of a package in Debian
> > main that, although DFSG-free, is neither software nor software
> > documentation.
> 
> How do you show it's not software? How does it differ from software?

Most of us don't bother, this is just the standard response to
"documentation isn't software so doesn't have to follow the DFSG". If
you want to call it software, that's fine; we know what to do with
software.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgptRcuKfKiVX.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Thomas Viehmann]

Joe Wreschnig wrote:
> On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote:
> 
>>Cameron Patrick wrote:
>>
>>>On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote:
>>Oh, cool. How about changing in DFSG to "Anything that can go in main or 
>>contrib."
> Because that's a circular definition. Saying everything in Debian is
> software, is not.
Given that in practice the ftp-masters get the final say, it isn't.
If you don't count that, saying "Anything in debian is software because debian
only distributes software" is as well.
I tend to agree with the probable conclusion of applying DFSG to determine the
freeness of anything in debian. However, the reasoning is fundamentally flawed.
David Harris' explanation is much better.

Cheers

T.


pgpnR7isj7ppg.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Fri, Jul 04, 2003 at 07:50:07AM +0200, Marcelo E. Magallon wrote:
> On Thu, Jul 03, 2003 at 02:42:10PM -0500, Branden Robinson wrote:
> 
>  > And, incidentally, the specific issue you address has -- I'm sure you'll
>  > be quite startled -- discussed at length on debian-legal.  Maybe you
>  > ought to check out those archives?
> 
>  I'm well aware that some people have flogged the horse.  That doesn't
>  mean these people have reached a satisfactory conclusion, that they are
>  "right" in any sense of the word or that said conclusion is consistent
>  with other opinions voiced by these people.
> 
>  Again, I'm not talking about the legal document, I'm talking about the
>  file.  The statement I quoted does not allow for modifications, no
>  matter the purpose.
> 
>  Now, would you care to be self-consequent?

If you have something _new_ to add to the discussion, please do so (on
-legal). Otherwise, kindly piss off.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpwvtnnuYDOb.pgp
Description: PGP signature

policy-rc.d

[Marc Singer]

On Fri, Jul 04, 2003 at 01:06:14AM -0400, Joey Hess wrote:
> Marc Singer wrote:
> > There is the related trouble that the only way to disable most
> > packages is to uninstall them.  Sometimes, it is desirable to
> > temporarily disable a service without removing the binaries or
> > changing the executability of the init.d script.
> 
> Take a look at invoke-rc.d and its policy program.

OK.  I can tell that this feature is available, though obscured by the
lack of a man page for policy-rc.d or even a reference to a package
that implements it.  I *did* find a document through google, however.
Reading it doesn't make it much clearer.

My search through a Contents file doesn't show an implementor for
policy-rc.d.  Is there one or is it adhoc?

--

Luckily, I am familiar with rule 3:

  3. any action for a non-executable initscript is denied.

Re: 469 packages still using dh_undocumented, check if one is yours

[Joey Hess]

Goswin Brederlow wrote:
> I came accross some sources still using dh_undocumented so I did a
> quick search through sids *.diff.gz files. Here is the result:

At prsent rates, I expect we will be down to maybe 50 packages calling
this in 1 year's time, at which point some bug reports could be filed.

Of course many of the packages with this program in their rules file
probably don't even use it. And it is a no-op.

I've recently revamped my debhelper graph page to make it easier to
track deprecated programs. The ones that don't seem likely to go away at
all soon are dh_installmanpages and dh_movefiles.

-- 
see shy jo


pgpeyIAQyrCCT.pgp
Description: PGP signature

Re: 469 packages still using dh_undocumented, check if one is yours

[Andreas Barth]

* Goswin Brederlow ([EMAIL PROTECTED]) [030704 05:35]:
> I came accross some sources still using dh_undocumented so I did a
> quick search through sids *.diff.gz files. Here is the result:

> [...]

> libapache-mod-dav

You must have done something wrong as since 1.0.3-6 dh_undocumented is
not longer used by libapache-mod-dav. (And 1.0.3-6 is also in sarge
for a while now.)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Bug#199972: ITP: lksctp -- implementation of SCTP in the Linux kernel

[Anibal Monsalve Salazar]

Package: wnpp
Version: unavailable; reported 2003-07-04
Severity: wishlist

* Package name: lksctp
  Version : 2_5_59-0_6_4
  Upstream Author : La Monte H. P. Yarroll <[EMAIL PROTECTED]>, Jon Grimm 
<[EMAIL PROTECTED]>, et al.
* URL : http://lksctp.sourceforge.net/
* License : GPL
  Description : implementation of SCTP in the Linux kernel

The Linux Kernel Stream Control Transmission Protocol (lksctp) project
is an implementation of the Stream Control Transmission Protocol (SCTP)
in the Linux kernel. The primary goal of this project is to provide user
applications with a viable SCTP solution.

See http://lksctp.sourceforge.net/ for more information.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux yuri 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686
Locale: LANG=en_AU, LC_CTYPE=en_AU

Re: Bug#199874: ITP: molmol -- Display and analyze structures of biological macromolecules (fwd)

[Frank Küster]

Andreas Tille <[EMAIL PROTECTED]> wrote on debian-med:

> Hint to Frank:  I'm looking foreward to "Please include ling description"
> mails.  :)
> I suggest to add it now because you can be sure that people will ask you for
> this.

Err, here it comes:

Description: Display and analyze structures of biological macromolecules
 MOLMOL is a molecular graphics program for displaying, analyzing, and
 manipulating the three-dimensional structure of biological macromolecules,
 with special emphasis on the study of protein or DNA structures determined
 by NMR

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

Re: Please remove RFCs from the documentation in Debian packages

[Jérôme Marant]

Selon Matt Zimmerman <[EMAIL PROTECTED]>:

> On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote:
> 
> > RFCs aren't software, and so applying the Debian Free /Software/
> > Guidelines to them seems a little odd.
> 
> But...but...what if you want to make your own "RFC 2661" by embracing and
> extending the existing one, and redistribute it to all your friends calling
> it "RFC 2661"?  It's taking away your freedom!

But we absolutely don't want to do this.

It is just like modifying someone else' speach and redistributing
it without changing the author's name.

It is obvious it should be out of the scope of DFSG.
 
--
Jérôme Marant

Re: Please remove RFCs from the documentation in Debian packages

[Nick Phillips]

On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote:

> Of course not.  They're software.
> 
> RFCs aren't software, and so applying the Debian Free /Software/
> Guidelines to them seems a little odd.

Hmmm...

Depends on your definition, really. They're sure as hell not hardware
or firmware, so...

-- 
Nick Phillips -- [EMAIL PROTECTED]
You are sick, twisted and perverted.  I like that in a person.

Re: NEWS.Debian support is here

[Luca - De Whiskey's - De Vitis]

On Fri, Jul 04, 2003 at 01:01:14AM -0400, Joey Hess wrote:
> Thanks to Matt Zimmerman and Joe Drew, apt-listchanges will now display
> NEWS.Debian entries for upgraded packages. They're displayed before the
> regular changelog entries, and Matt plans to later let it be configured
> to only display news, if the user wants (more useful for stable users).

Is it reasonable to think about some sort of localizzation support for NEWS
file? Changes documented there might be worthy of translation.

> The NEWS.Debian file is installed as
> /usr/share/doc//NEWS.Debian.gz. Always compressed, always with
> that name even in native packages. If you use debhelper, upgrade to
> 4.1.51 and dh_installchangelogs will install debian/NEWS files for you[1].

Just curious: why not NEWS.gz for native packages?

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.


pgpTIeR1qCp3R.pgp
Description: PGP signature

Re: 469 packages still using dh_undocumented, check if one is yours

[Tollef Fog Heen]

* Goswin Brederlow 

| I came accross some sources still using dh_undocumented so I did a
| quick search through sids *.diff.gz files. Here is the result:

[...]

Such a list is useless unless it includes maintainer addresses (or
just maintainer names) as well.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Bug#199683: ITP: librcs-perl -- Front end to revision control utilities for perl

[Adrian 'Dagurashibanipal' von Bidder]

On Wednesday 02 July 2003 15:45, Matt Hope wrote:
>  This Perl module provides an object oriented interface to access
>  Revision Control System (RCS) utilities.

Is this the original rcs specifically, or revision control system utilities in 
general? This is not entirely clear to me from this description.

cheers
-- vbi

-- 
Do you understand now why we attacked Iraq?  Because war is good for the
economy, which means war is good for America.   Also, since God is on
America's side, anyone who opposes war is a godless un-American Communist.
-- excerpt from one of those 'joke' mails floating around.


pgpVGfBsPCkkZ.pgp
Description: signature

Re: Please remove RFCs from the documentation in Debian packages

[Isaac To]

> "Jérôme" == Jérôme Marant <[EMAIL PROTECTED]> writes:

Jérôme> But we absolutely don't want to do this.

Jérôme> It is just like modifying someone else' speach and
Jérôme> redistributing it without changing the author's name.

Jérôme> It is obvious it should be out of the scope of DFSG.

It is far from obvious.  What if I develop my software, finds the
specification of MIME to be very similar to what my software does, but yet I
need to modify the things here and there so as to suit my needs; and when
documenting my software I want to use RFC 1341 as a starting point, change
those things that my software do differently than 1341, and then say that is
the documentation of my software?  I have no intention to confuse the result
with RFC 1341, so what's wrong to do the edit (except that the author of RFC
1341 might be unhappy with that)?  To the user it is really best done that
way: if I have to rewrite 1341 I probably won't give documentation at all
because I don't have the time.  If instead I just point out the positions
that my software differs from 1341 the user would have to read two different
documents.

I'd accept it if the restriction is just saying that I cannot distribute a
modifying RFC without changing the name to something else.  I cannot accept
it if the license restricts my right to change it at all (other than for
translation or development of new standards)---at least, if it were to be
put in main section of Debian.  It sounds like a trap waiting for somebody
to step into it.
 
Regards,
Isaac.

Re: Why doesn't libsidplay enter testing?

[Gerfried Fuchs]

* Colin Watson <[EMAIL PROTECTED]> [2003-07-04 00:03]:
> On Thu, Jul 03, 2003 at 07:58:37PM +0200, Gerfried Fuchs wrote:
>>  Please check the update_excuses, it would make package foo _not_ a
>> valid candidate, if that happens.
> 
> That doesn't happen for circular dependencies (i.e. cycles of packages
> that each depend on newer versions of each other than are in testing),
> the reason being that if they weren't considered valid candidates then
> such cycles could never get into testing at all. (Invalid candidates are
> completely ignored - they aren't eligible for hinting, even.)

 Oh, didn't know that part yet, thanks for the enlightenment.

> Please stop saying rude things like "Please check " to the people
> who are trying to explain the state of play to you, because they are
> right: it has been like this for a long time.

 Sorry, I don't get it why you call it rude. It might be just me but I
would have considered it rude if I told Anthony to "RTF update_excuses".
If you take what I wrote as rude then sorry, I didn't mean it that way.
I even haven't thought that anyone would take a "please check" as rude
anyway, and I still don't understand it why you might think so  And
like Anthony's answer showed he hasn't taken it as rude neither, and
even he thought it would happen to be written out in update_excuses.

>   Upgrading either the foo source package alone or the libfoo source
>   package alone renders foo uninstallable. Upgrading both simultaneously
>   works. The latter requires manual action (or the occasional bit of
>   guesswork by the testing scripts). It has always been this way.

 Yes, it has always been this way. Or rather not, for I don't see the
need for manual action, it is documented that these cases are cought by
the testing script since ages, and it worked without manual action for
quite some time already (from what I can tell).

 I just like to know if there is really the need for manual action for
such things every now and then (then this should be noted in the
documentation and I consider it rather as a bug, for there is not much
magic in this case, IMHO) or if there is something else behind this very
case, which I don't grok yet.

 So long,
Alfie [no, not meant rude; don't understand it as rude]

Re: Please remove RFCs from the documentation in Debian packages

[Martin Quinson]

On Thu, Jul 03, 2003 at 05:16:07PM -0700, Brian Nelson wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Jul 03, 2003 at 02:19:59PM -0700, Brian Nelson wrote:
> > You have some free software, and it comes with a manual. You modify
> > the software in a manner which suits you... but you're not allowed to
> > modify the manual to reflect this change; the license of the manual
> > requires that it only document the unmodified version, so any modified
> > versions are at an immediate disadvantage.
> >
> > And you think this is acceptable? Why?
> 
> It's more acceptable to me than the alternative: to move a good portion
> of documentation to non-free where it will not be distributed by
> vendors, will not be considered "part of Debian" and thus will be under
> threat of removal, and will be considered a "lower class" package.

That's not exactly what we are speaking about. We don't speak about
documentation, but about standards. Documentation comes after the
implementation of the program to explain how to use it. Standards comes
before the implementation to explain how it should behave to be
interoperable with other implementations from other people.

RFCs are not program documentation.
[but the program documentation can refere to RFCs, as ldap stuff does]

> Fortunately, the situation you describe is unlikely to occur because few
> people are perverse enough to make their software free but their
> documentation very non-free.

The fact is that it happens. Look at FDL discussions. But in my mind, that's
out of topic, and I would appreciate if we could discuss one item at once to
have a small chance of converging to a decision...

Thanks, Mt.

-- 
If the automobile had followed the same development cycle as the computer, a
Rolls-Royce today would cost $100, get a million miles to the gallon, and
explode once every few weeks, killing everyone inside.

Re: NEWS.Debian support is here

[Adrian 'Dagurashibanipal' von Bidder]

Thanks a lot, this is great!

On Friday 04 July 2003 10:02, Luca - De Whiskey's - De Vitis wrote:
> Is it reasonable to think about some sort of localizzation support for NEWS
> file? Changes documented there might be worthy of translation.

Not about i18n, really, but please at least specify from the beginning that 
NEWS.Debian.gz should be utf-8 encoded, then there shouldn't be any big 
discussion later on.

cheers
-- vbi

-- 
featured product: the GNU Compiler Collection - http://gcc.gnu.org


pgphIq7RdEuaI.pgp
Description: signature

Re: logging for package installs

[Martin Quinson]

On Thu, Jul 03, 2003 at 05:38:46PM -0400, Joey Hess wrote:
> Maybe this is a good time to present this idea I've been kicking around,
> but never really got anywhere with, for as long as I've been working on
> debconf. My idea is to add an abstraction layer for package install-related
> logging in debian.
> 
> It seems that many maintainers like to do some or all of the following
> in their maintainer scripts:
> 
> - Display various fairly unimportant warnings, which are often not
>   useful until after the package is installed and you're using it.
> - Display error messages, some fatal, and some not.
> - Show progress displays (in contravention of policy of course).
> - Various other indications of important and not so important things
>   that the maintainer script is doing.
> - Remind users to read the README.Debian file.
> 
> Almost all of this is done with echo, and almost all of this is
> completly ignored by our users, believe it or not. I suppose that those
> users who see it would prefer to be able to go back and look at it
> later, when they're actually using the package they installed earlier.
> Some of them would certianly like for it to be localised. Many users
> would like not to see this stuff at all at install time, unless it's a
> real immediate error.

That would be really great, and I'm quite entousitastic about the idea.

> So the basic idea is that instead of using echo for these messages,
> we provide some interface for them. Call it dpkg-log. I have not gotten
> as far as to what the interface of dpkg-log would be, or how users would
> configure how it displays, filters, and/or logs messages. Nor have I
> given much thought to what kind of data should be included in the log,
> though it would probably include the date, package name, log message,
> log type, and message importance.

Check the log4j project, they did come up with a really great logging
framework. Of course, their code isn't usable at all (that's java), but
their concept are very advanced. Applying this to dpkg-log would allow the
user to provide the format they want, depending of the kind of message and
its gravity.

For that, we kind of need a standardization of the possible categories.
Using package name as categorie seems underoptimal to me since it won't be
useable from the user point of view. We could use the sections for that.

 dpkg-log --category main/doc --level critical "Hey, this version will \
  break your install, erase your data and kill your mum unless you check \
  README.debian carfully"

or the tags

 dpkg-log --category gnome --level minor "subliminal message: Gnome rulez"

or a mix of the two, but that may be hard to do right.

> Nor have I thought about l10n at all.

You'll have a bad time i18ning that. The problems with debconf template
i18ning was that:
 - the translation must be there before the program install
 - the texts are short and dispatched over all packages, making the ratio of
   translator work between actual translation work and administrative work to 
   get their work included rather bad.
   
With dpkg-log messages, you'll get into those two problems too, plus the
fact that I guess that maintainers will want to add variating text like
  errmsg=`run a command`
  if [ $? != ] ; then
dpkg-log $"Damnit the execution of this command failed with the message 
$errmsg"
  fi

The errmsg stuff is impossible to translate unless setting LC_ALL for the
execution program run, but this leads to other problems if you want to parse
the output... 

I can't find a good way to translate those errmsg stuff, but for the others,
I think that it could be pushed to the debian/po file. debian/po/POTFILE.in
provides a provision for such extends. I need to speak with Denis Barbier to
see how we could this happen in the po-debconf and po4a realm.

> This could be bolted on the side of debconf. The abuse of debconf by
> maintainers who feel the need to do the kinds of things listed above
> certianly points at the need for this mechanism. And at least debconf
> has a kind of l10n framework, and some ideas about question priority.
> But this logging and message display is really conceptually different
> than debconf. Debconf is just there to ask questions. It would likely be
> better to design it as a separate program.

Fully agreed.
 
> Here's one way a dpkg-log program might be used, just to give the feel
> for the idea:
> 
> #!/bin/sh
> if [ "$1" = configure ] && grep -q evil /etc/myconfig; then
>   dpkg-log --priority=critical \
>--warning=$"/etc/myconfig has evil in it! See README.Debian!"
> elsif [ "$phase_of_moon" = full ]; then
>   dpkg-log --priority=critical \
>--error=$"This package only upgrades during new moons."
>   exit 1
> fi
> 
> The user would see either this:
> 
> # dpkg -i mypkg.deb
> dpkg: Installing mypkg (1.2.3) ...
> dpkg: Not replacing modified conffile /etc/myconfig with 
> /etc/myconfig.dpkg-new
> mypkg: /etc/myconfig has evil in it! See R

Re: Debconf or not debconf : Conclusion

[Dave Holland]

On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote:
> sometimes think Eric Troan really got this part of rpm's design right
> (some 7 or 8 years ago) when he completely forbade any I/O between the
> install scripts and the user at install time.
[...]
> (And perhaps by removing this crutch, packagers will be more
> encouraged not to grauitiously break things as the result of package
> upgrades, even if upstream does something stupid.)

Unfortunately, this does not happen in the install-time-note-free Red
Hat world. I see RH package upgrades break^Wchange things which are
not obviously documented and would benefit from a note (or, a la
debconf, an email) just mentioning what has occurred.

I much prefer the opportunity to warn the admin at install time.

Dave

Re: Please remove RFCs from the documentation in Debian packages

[Florian Weimer]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> There seem to be someone believing that standard documents should be
> treated as software.  Standards are not software.  Standards do not
> improve if everyone is allowed to modify them and publish the modified
> version as an updated version of the standard.  Standards get their
> value from having a rigid procedure for updates and modifications.
> Software do not.

RFCs are not standards.  The IETF process is not a standardization
process in the traditional sense.

Part of the Internet's success story is the intertwining of software
development and de-facto standardization.  From this point of view,
RFCs are much more like software than traditional standards.

Re: Please remove RFCs from the documentation in Debian packages

[Florian Weimer]

Marco d'Itri <[EMAIL PROTECTED]> writes:

> I fully agree. Banning RFCs from debian is just silly.

And I wonder what's next?  fsf-funding(7)?  The GPL?

Debian really needs a separate policy for works which are not
software.

Re: Please remove RFCs from the documentation in Debian packages

[Florian Weimer]

Branden Robinson <[EMAIL PROTECTED]> writes:

> So be it.  The Social Contract and the traditions of our project
> compel us to make principled decisions, not politically expedient
> ones.

Not correct.  Look at the handling of security issues.  The project
has chosen (never formally, though) that it will sacrifice one of its
core values to increase short-term user convenience.

There is always some room for interpretation, and often a certain
political motivation behind interpretation.

BTW, has anybody tried to clarify what "for the purpose of developing
Internet standards" means?  Is it possible to publish an Internet
Draft formally aiming at an Informational RFC which is based on an RFC
with such a copyright notice?

Re: 469 packages still using dh_undocumented, check if one is yours

[Henrique de Moraes Holschuh]

On Fri, 04 Jul 2003, Joey Hess wrote:
> I've recently revamped my debhelper graph page to make it easier to
> track deprecated programs. The ones that don't seem likely to go away at
> all soon are dh_installmanpages and dh_movefiles.

Especially since some of us do like dh_movefiles a LOT :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Fri, Jul 04, 2003 at 12:19:07PM +0200, Florian Weimer wrote:
> Marco d'Itri <[EMAIL PROTECTED]> writes:
> 
> > I fully agree. Banning RFCs from debian is just silly.
> 
> And I wonder what's next?  fsf-funding(7)?

Yup, I'll go file a bug about that now; thanks for pointing it out. We
shouldn't be shipping non-free manpages.

> Debian really needs a separate policy for works which are not
> software.

We could have a policy for non-software, but it should still exclude
non-free things. What you are trying to say is "Debian really needs to
include non-free things".

I think you'll find a lot of people disagreeing with you.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpQMUHlTVjdD.pgp
Description: PGP signature

Re: policy-rc.d

[Henrique de Moraes Holschuh]

On Thu, 03 Jul 2003, Marc Singer wrote:
> > Take a look at invoke-rc.d and its policy program.
> 
> OK.  I can tell that this feature is available, though obscured by the
> lack of a man page for policy-rc.d or even a reference to a package
> that implements it.  I *did* find a document through google, however.
> Reading it doesn't make it much clearer.

That's because nobody wrote a sample (or generic, whatever) policy-rc.d yet
:P

Now, what happened to policy-rc.d(8), I don't know.  Let me search to see if
I ever wrote a sample one... 

/me notices in horror that projects/debian/initscripts is empty... ARGH!
google to the rescue... let me wget them right back!

> My search through a Contents file doesn't show an implementor for
> policy-rc.d.  Is there one or is it adhoc?

I wrote one for chroots a while back. It simply did an exit 101 :)

For reference, I am attaching the interface description of policy-rc.d.  I
(or someone else) should write a manpage for it one of these days...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
INVOKE-RC.D (/usr/sbin/invoke-rc.d) interface:
==

The interface for all implementations of invoke-rc.d is mandated by the base
implementation in the sysvinit package, just like it is done for
update-rc.d.

There is a provision for a "local initscript policy layer" (read: a call to
/usr/sbin/policy-rc.d if this executable is present in the local system),
which allows the local system administrator to control the behaviour of
invoke-rc.d for every initscript id and action. It is assumed that this
script is OPTIONAL and will by written and provided by packages other than
the initscript system (sysvinit and file-rc packages).

The basic interface for all implementations of policy-rc.d is mandated by
the requirements of the base implementation of invoke-rc.d. This interface
will be described either in the manpage of invoke-rc.d, and in a text file
stored in /usr/share/doc/sysvinit/ by package sysvinit (which will host the
base implementation of invoke-rc.d).

Proposed script interfaces:

invoke-rc.d [options]   [extra initscript parameters...]

  basename - Initscript ID, as per update-rc.d(8)
  action   - Initscript action. Known actions are:
start, [force-]stop, restart,
[force-]reload, status
  (status is there because of the LSB. Debian does not use it).

  extra initscript parameters: These parameters are passed to the initscript
  as is, after the action parameter.  is always the first paramenter
  to the initscript, and may be modified by fallback actions or policy-rc.d
  requests. Note, however, that the extra parameters are not dropped or
  modified even if the action (first parameter) is modified.

Options:

 --quiet
 Quiet mode, no error messages are generated by invoke-rc.d; policy-rc.d
 is also called with --quiet if this option is in effect.

 --force
 Try to run init script regardless of policy and non-fatal errors. Use
 of this option in automated scripts is severely discouraged as it
 bypasses integrity checks. If the initscript cannot be executed, error
 status 102 is returned. Do note that the policy layer call
 (policy-rc.d) is NOT skipped, although its results are ignored.

 --try-anyway
 Try to run the initscript even if a non-fatal subsystem error is
 detected (e.g: bad rc.d symlinks). A 102 status exit code will result
 if init script fails to execute anyway). Unlike --force, policy is
 still enforced with --try-anyway.

 --disclose-deny
 Return status code 101 instead of status code 0 if initscript action is
 denied by local policy rules or runlevel constrains. An warning is
 generated if the action is denied.

 --query
 Returns one of status codes 100-106, does not execute the init.d
 script. Implies --disclose-deny and --nofallback.  Status codes 104-106
 are only generated by this option.

 Note many messages are still sent to stderr in --query mode, including
 those regarding policy overrides and subsystem errors. Use --quiet if
 silent --query operation is desired.

 --no-fallback 
 The policy layer (policy-rc.d) may return fallback actions to be run
 instead of the requested action. If this option is active, a fallback
 action request will be ignored and a "action not allowed" reply used in
 its place. This is probably a BAD idea unless you know exactly what
 you're doing.

  --help
 Outputs help message to stdout

Unknown actions may generate warnings, but are passed to the underlying
initscript anyway. The reason for the warning is simple: It is very unlikely
that an unknown action (by invoke-rc.d) will be known to the policy layer
(policy-rc.d), and therefore it may cause an initscript to execute an action
whi

Re: Please remove RFCs from the documentation in Debian packages

[Josip Rodin]

On Fri, Jul 04, 2003 at 12:39:46PM +0200, Florian Weimer wrote:
> > So be it.  The Social Contract and the traditions of our project
> > compel us to make principled decisions, not politically expedient
> > ones.
> 
> Not correct.  Look at the handling of security issues.  The project
> has chosen (never formally, though) that it will sacrifice one of its
> core values to increase short-term user convenience.

What you describe as "user convenience" translates into 

4. Our Priorities are Our Users and Free Software

   We will be guided by the needs of our users and the free-software
   community. We will place their interests first in our priorities.

Hence, you're on crack if you think that such sophistry works.

-- 
 2. That which causes joy or happiness.

Re: NEWS.Debian support is here

[Henrique de Moraes Holschuh]

On Fri, 04 Jul 2003, Joey Hess wrote:
> Thanks to Matt Zimmerman and Joe Drew, apt-listchanges will now display
> NEWS.Debian entries for upgraded packages. They're displayed before the

THANK YOU guys!  I will add NEWS support to my packages (and backport
apt-listchanges to stable, see people.debian.org/~hmh/ if you want the
backport) ASAP.

That was a great (although unintended, I'm sure) birthday gift. Thanks ;-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Content rejected.

[spambody]

Content rejected.

Based on an automated review of the content in a message you sent,
the message appears to be unsolicited commercial e-mail or to contain
content that we deem inappropriate for our business environment. The
message has been blocked from delivery.  If you feel you received
this message in error, please forward this message, the address that
you are trying to send to, and any questions to [EMAIL PROTECTED]


Received: from SMTP32-FWD by imail.duda.com
  (SMTP32) id A0C4C; Fri,  4 Jul 2003 07:43:23 -0400
Received: from ov7.duda.com [10.1.1.11] by imail.duda.com
  (SMTPD32-7.15) id A845E6790134; Fri, 04 Jul 2003 07:43:01 -0400
Received: from psmtp.com ([12.158.35.174])
 by ov7.duda.com (SAVSMTP 3.1.0.29) with SMTP id M2003070407423623071
 for <[EMAIL PROTECTED]>; Fri, 04 Jul 2003 07:43:00 -0400
Received: from source ([146.82.138.6]) by exprod6mx34.postini.com 
([12.158.35.251]) with SMTP;
Fri, 04 Jul 2003 04:42:34 PDT
Received: from localhost (localhost [127.0.0.1])
by murphy.debian.org (Postfix) with QMQP
id D98DC1F70F; Fri,  4 Jul 2003 06:40:17 -0500 (CDT)
Old-Return-Path: <[EMAIL PROTECTED]>
Received: from master.debian.org (master.debian.org [146.82.138.7])
by murphy.debian.org (Postfix) with ESMTP id A88AD1F67A
for ; Fri,  4 Jul 2003 06:30:03 
-0500 (CDT)
Received: from debbugs by master.debian.org with local (Exim 3.35 1 (Debian))
id 19YOlP-0002l6-00; Fri, 04 Jul 2003 06:30:03 -0500
Date: Fri, 4 Jul 2003 06:30:03 -0500
From: BugScan reporter <[EMAIL PROTECTED]>
To: debian-devel-announce@lists.debian.org
Subject: Release-critical Bugreport for July  4, 2003
Message-ID: <[EMAIL PROTECTED]>
Reply-To: debian-devel@lists.debian.org, [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.28i
Sender: Debian BTS <[EMAIL PROTECTED]>
X-Debian-Message: RC bugreport check passed
Mail-Followup-To: debian-devel@lists.debian.org
X-Spam-Status: No, hits=-2.5 required=4.0
tests=USER_AGENT_MUTT
version=2.55-lists.debian.org_2003_06_29
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_06_29 
(1.174.2.19-2003-05-19-exp)
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-devel-announce@lists.debian.org
X-Mailing-List:  
X-Loop: debian-devel-announce@lists.debian.org
List-Id: 
List-Post: 
List-Help: 
List-Subscribe: 
List-Unsubscribe: 
List-Archive: 
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Resent-Date: Fri,  4 Jul 2003 06:40:17 -0500 (CDT)
X-Declude-Sender: [EMAIL PROTECTED] [12.158.35.174]
X-Declude-Spoolname: D6845e67901342f6e.SMD
X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam.
X-Spam-Tests-Failed: Whitelisted [0]

Re: Please remove RFCs from the documentation in Debian packages

[Florian Weimer]

Andrew Suffield <[EMAIL PROTECTED]> writes:

>> Debian really needs a separate policy for works which are not
>> software.
>
> We could have a policy for non-software, but it should still exclude
> non-free things. What you are trying to say is "Debian really needs to
> include non-free things".

There are borderline cases, such as the GFDL or free works in
non-editable formats (PS, PDF, in some cases even HTML), or licenses
or other documents of perceived legal relevance.

However, I've tried to come up with a policy which is not specific to
IETF documents, but that would allow their distribution, and I failed.
The terms are quite obnoxious, and if it weren't the IETF that is
involved here, hardly anyone would demand that documents under such a
license are to be included in Debian, I guess.

Re: Please remove RFCs from the documentation in Debian packages

[Florian Weimer]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Fri, Jul 04, 2003 at 12:39:46PM +0200, Florian Weimer wrote:
>> > So be it.  The Social Contract and the traditions of our project
>> > compel us to make principled decisions, not politically expedient
>> > ones.
>> 
>> Not correct.  Look at the handling of security issues.  The project
>> has chosen (never formally, though) that it will sacrifice one of its
>> core values to increase short-term user convenience.
>
> What you describe as "user convenience" translates into 
>
> 4. Our Priorities are Our Users and Free Software
>
>We will be guided by the needs of our users and the free-software
>community. We will place their interests first in our priorities.
>
> Hence, you're on crack if you think that such sophistry works.

But how far goes clause 4?  Obviously not that far that Debian
includes Java (for rather complete values of "Java", which seems to
imply a certain proprietary implementation at the moment).

woody/sid packages in dists/potato

[Miquel van Smoorenburg]

I'm trying to run debootstrap to see if it plays nice with sysvinit.
And the other way around.

But at the moment, it bails out because it wants to install
libident which still is in the potato part of the archive ...
and my local mirror doesn't carry dists/potato anymore.

There's a handful of packages that have the same problem:

% grep ^Filename: Packages | grep -v ": pool/" | wc -l
 24

They're all in potato. What would be the right way to fix this ?

- file 24 bug reports
- fix the FTP archive manually by copying the packages to pool/
- it's not really a problem, so do nothing

Mike.

Re: woody/sid packages in dists/potato

[Oliver Kurth]

On Fri, Jul 04, 2003 at 11:58:49AM +, Miquel van Smoorenburg wrote:
> I'm trying to run debootstrap to see if it plays nice with sysvinit.
> And the other way around.
> 
> But at the moment, it bails out because it wants to install
> libident which still is in the potato part of the archive ...
> and my local mirror doesn't carry dists/potato anymore.
> 
> There's a handful of packages that have the same problem:
> 
> % grep ^Filename: Packages | grep -v ": pool/" | wc -l
>  24
> 
> They're all in potato. What would be the right way to fix this ?
> 
> - file 24 bug reports
> - fix the FTP archive manually by copying the packages to pool/
> - it's not really a problem, so do nothing

Option #2. We had this discussed here several times before.

Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-


pgptRyj5DCKpj.pgp
Description: PGP signature

Re: NEWS.Debian support is here

[Joe Drew]

On Friday, July 4, 2003, at 04:02  AM, Luca - De Whiskey's - De Vitis 
wrote:

Just curious: why not NEWS.gz for native packages?
It's prohibitively difficult to detect whether any given file is in 
debian changelog format.

NEWS[.gz] exists in many packages already, and is of no particular 
format in general, apt-listchanges doesn't know what to do with it (and 
will in fact display the entire file every time). Since we can't rely 
on the existence of NEWS.Debian.gz (as it's not required, like the 
changelog is) we can't tell which file is the one we're looking for by 
filename alone.

So, instead, we have decided that mandating NEWS.Debian is a better 
solution.

Re: woody/sid packages in dists/potato

[Santiago Vila]

On Fri, 4 Jul 2003, Miquel van Smoorenburg wrote:

> I'm trying to run debootstrap to see if it plays nice with sysvinit.
> And the other way around.
>
> But at the moment, it bails out because it wants to install
> libident which still is in the potato part of the archive ...
> and my local mirror doesn't carry dists/potato anymore.
>
> There's a handful of packages that have the same problem:
>
> % grep ^Filename: Packages | grep -v ": pool/" | wc -l
>  24
>
> They're all in potato. What would be the right way to fix this ?

It's not a bug in itself for those packages to be still under potato,
as far as they are not buggy for some other reason as well.

If you mirror woody you should look at the Packages.gz file for woody
and retrieve whatever Filename:s are referenced there. Assuming that all
packages in woody, sarge or sid have to be under the pool directory is
considered as a bug in whatever method to create the local mirror you
might be using.

In other words, what we call "the pool" is really the sum of packages
in the "potato" directory and packages in the "pool" directory. The
fact that all packages which belong to potato are all under the
"potato" directory is just an extra property which "the pool" is
required to satisfy.

> - file 24 bug reports
> - fix the FTP archive manually by copying the packages to pool/
> - it's not really a problem, so do nothing

It's not a problem as such, but if, for instance, they are still
using /usr/doc, that's something that might be reported.

Re: Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge)

[Christian Marillat]

Stephen Gran <[EMAIL PROTECTED]> writes:

> This one time, at band camp, Christian Marillat said:

[...]

>> Yes, I know, but this user said that x-terminal-emulator is configured
>> to xterm and when he call a bsdgames menu enties a dialog box said that
>> gnome-terminal is missing. Of course files in menu-method are original
>> files. Then if somebody can understand this bug...
>
> It's the gnome-session terminal-emulator thing, I'm pretty sure.
> gnome-session can override the alternatives sytem, so that users can use

gnome-session change nothing, related to x-terminal-emulator
alternative.

> their favorite apps for web borwser, terminal, etc., and I'm assuming
> this user has the call to terminal pointing to gnome-terminal, which
> isn't there.  This is why they are getting an error message in gnome,
> rather than a silent failure, which is what I experience when it's
> something outside of the gnome desktop.

Debian menu doesn't use at all the terminal prefered application.

Christian

Bug#200025: ITP: libcddb -- C library to access data on a CDDB server

[Chris Butler]

Package: wnpp
Version: unavailable; reported 2003-07-04
Severity: wishlist

* Package name: libcddb
  Version : 0.9.4
  Upstream Author : Kris Verbeeck <[EMAIL PROTECTED]>
* URL : http://libcddb.sourceforge.net/
* License : LGPL
  Description : C library to access data on a CDDB server

 It allows you to:
 .
  * search the database for possible CD matches;
  * retrieve detailed information about a specific CD;
  * submit new CD entries to the database.
 .
 Libcddb supports both the custom CDDB protocol and tunnelling the query and
 read operations over plain HTTP. It is also possible to use an HTTP proxy
 server. If you want to speed things up, you can make use of the built-in
 caching facility provided by the library.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux crispy 2.4.21 #1 Sun Jun 15 15:02:46 BST 2003 i686
Locale: LANG=en_GB, LC_CTYPE=en_GB

Re: Please remove RFCs from the documentation in Debian packages

[Sebastian Rittau]

On Fri, Jul 04, 2003 at 02:04:51PM +0200, Florian Weimer wrote:

> But how far goes clause 4?  Obviously not that far that Debian
> includes Java (for rather complete values of "Java", which seems to
> imply a certain proprietary implementation at the moment).

Which non-free Java implementations are part of Debian? I know of none.

 - Sebastian

Re: Please remove RFCs from the documentation in Debian packages

[Colin Watson]

On Fri, Jul 04, 2003 at 03:55:30PM +0200, Sebastian Rittau wrote:
> On Fri, Jul 04, 2003 at 02:04:51PM +0200, Florian Weimer wrote:
> > But how far goes clause 4?  Obviously not that far that Debian
> > includes Java (for rather complete values of "Java", which seems to
> > imply a certain proprietary implementation at the moment).
> 
> Which non-free Java implementations are part of Debian? I know of none.

I think that's exactly Florian's point.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Debconf or not debconf : Conclusion

[Julien LEMOINE]

On Friday 04 July 2003 05:59, Andrew Suffield wrote:
> > Yes, keep the two versions of stunnel is probably the right way to handle
> > this problem. Now the problem is that stunnel is uploaded in version 4 on
> > stunnel package. What is the correct way to reintroduce stunnel for
> > compatibility reasons ? uploading a new  stunnel3 package will not
> > resolve the problem.
>
> Epoch it and upload stunnel4 as a new package.

Thanks,

I will upload a stunnel4 package and a stunnel with Epoch tomorrow.

Best Regards.
-- 
Julien LEMOINE / SpeedBlue

Re: logging for package installs

[Joey Hess]

Martin Quinson wrote:
> I want to help on this, please keep me informed !

Don't get the wrong idea: I just wanted to get the idea out there. I
think if I was going to implement this I would have already, since I've
had the idea in my head for several years. I hope someone will take it
and run with it.

-- 
see shy jo


pgpJpU4onzJlH.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Josip Rodin]

On Fri, Jul 04, 2003 at 02:04:51PM +0200, Florian Weimer wrote:
> >> > So be it.  The Social Contract and the traditions of our project
> >> > compel us to make principled decisions, not politically expedient
> >> > ones.
> >> 
> >> Not correct.  Look at the handling of security issues.  The project
> >> has chosen (never formally, though) that it will sacrifice one of its
> >> core values to increase short-term user convenience.
> >
> > What you describe as "user convenience" translates into 
> >
> > 4. Our Priorities are Our Users and Free Software
> >
> >We will be guided by the needs of our users and the free-software
> >community. We will place their interests first in our priorities.
> >
> > Hence, you're on crack if you think that such sophistry works.
> 
> But how far goes clause 4?  Obviously not that far that Debian
> includes Java (for rather complete values of "Java", which seems to
> imply a certain proprietary implementation at the moment).

So, I assume that with that you mean that we have "sacrificed one of our
core values" as well? My. All this sacrifice is making me hungry. :P

-- 
 2. That which causes joy or happiness.

Re: Debconf or not debconf

[Michael Banck]

On Thu, Jul 03, 2003 at 12:19:16PM -0500, Gunnar Wolf wrote:
> Keep stunnel as a stub package depending on either stunnel3 or stunnel4,
> change the description of stunnel3 explaining the situation and urging
> users to upgrade if possible. 

Yeah, he could use a debconf note for this for example.


scnr,

Michael

Re: 469 packages still using dh_undocumented, check if one is yours

[Artur R. Czechowski]

On Fri, Jul 04, 2003 at 09:47:52AM +0200, Tollef Fog Heen wrote:
> | I came accross some sources still using dh_undocumented so I did a
> | quick search through sids *.diff.gz files. Here is the result:
> Such a list is useless unless it includes maintainer addresses (or
> just maintainer names) as well.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
...

Regards
Artur
-- 
każde takie zgłoszenie [o bombie] sprawdzić musi nasz specjalista,
powiedzmy pies
/wypowiedź policjanta w TV/

Re: 469 packages still using dh_undocumented, check if one is yours

[Benjamin Drieu]

"Artur R. Czechowski" <[EMAIL PROTECTED]> writes:

> On Fri, Jul 04, 2003 at 09:47:52AM +0200, Tollef Fog Heen wrote:
>> | I came accross some sources still using dh_undocumented so I did a
>> | quick search through sids *.diff.gz files. Here is the result:
>> Such a list is useless unless it includes maintainer addresses (or
>> just maintainer names) as well.
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> ...

This doesn't help if you maintain dozens of packages and you just want
to know if one of your packages is offending.

Cheers,
Benjamin

-- 
  .''`.
 ; ;' ;  Debian GNU/Linux |   Benjamin Drieu
 `. `'http://www.debian.org/  |  <[EMAIL PROTECTED]>
   `-


pgp0EUSGMFsXt.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Cameron Patrick]

On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote:

| How do you show it's not software? How does it differ from software?
| 
| What if I take the view that Mozilla is an interpreter and anarchism is
| the program? Please explain how that differs from the Perl interpreter
| and Perl programs.

I would argue that while Perl is Turing complete, HTML is not, thus
anarchism is not software.

Cameron.

Re: 469 packages still using dh_undocumented, check if one is yours

[Tollef Fog Heen]

* "Artur R. Czechowski" 

| On Fri, Jul 04, 2003 at 09:47:52AM +0200, Tollef Fog Heen wrote:
| > | I came accross some sources still using dh_undocumented so I did a
| > | quick search through sids *.diff.gz files. Here is the result:
| > Such a list is useless unless it includes maintainer addresses (or
| > just maintainer names) as well.
| [EMAIL PROTECTED]
| [EMAIL PROTECTED]
| [EMAIL PROTECTED]

Uhm, it's far easier just to generate the list so I can grep for my
name in it.  Scanning a list of 469 packages takes a while.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Please remove RFCs from the documentation in Debian packages

[Doug Winter]

On Thu 03 Jul Petter Reinholdtsen wrote:
> 
> [Javier Fernández-Sanguino Peña]
> > (For those who are not aware of this issue, please read #92810)
> 
> There seem to be someone believing that standard documents should be
> treated as software.  Standards are not software.  Standards do not
> improve if everyone is allowed to modify them and publish the modified
> version as an updated version of the standard.  Standards get their
> value from having a rigid procedure for updates and modifications.
> Software do not.

Ceci n'est pas une RFC. I think there's perhaps a problem with
terminology here.  A standards document is not the standard itself, it's
just a written copy of it.

Standards obviously do function by being commonly agreed, and therefore
the actual standards do require some form of change control to be
effective.  Where the 'actual standard' resides is another question.

The copy of the standard on my harddisk certainly isn't it though, and
it doesn't have to be under change control - as long as it is clear
whether it represents the standard or is just something similar, there's
no problem with it being mutable.

After all, if people being able to change copies of standards really was
such a huge risk, then you'd not be able to publish them at all without
some pretty serious DRM, just in case someone altered one and all hell
broke loose.  Look, I'm going to change the length of an IP datagram and
damn the consequences, mwahahahahaha!

Many of the reasons to prefer freedom in software apply to standards
also - if a community of developers think a standard is poorly designed
and wish to produce a new one derived from the old, that is surely of
benefit to everyone, and for exactly the same reasons as freeness is of
benefit in software.

doug.

-- 
Core GNOME developers are heavy Ketamine users 
-- http://www.illusionary.com/GNOMEvKDE.html


pgpS1wdopfQ6V.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Javier Fernández-Sanguino Peña]

On Thu, Jul 03, 2003 at 09:45:41PM +0200, Emile van Bergen wrote:
> 
> Why not indeed traft a DFDG spec that includes licenses such as the GFDL
> and IETF's and W3C's licenses, as someone suggested, and add a separate
> 'Documentation' section?

Because that has been already drafted. Not only I suggested it, I pointed 
people to  http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
That section of the DDPolicy describes which are the accepted licenses for 
documentation and points to some discussions about the subject in 
debian-legal.

Regards

Javi


pgpwt60ch0qMy.pgp
Description: PGP signature

Re: 469 packages still using dh_undocumented, check if one is yours

[Artur R. Czechowski]

On Fri, Jul 04, 2003 at 05:59:57PM +0200, Benjamin Drieu wrote:
> This doesn't help if you maintain dozens of packages and you just want
> to know if one of your packages is offending.

On Fri, Jul 04, 2003 at 06:18:06PM +0200, Tollef Fog Heen wrote:
> Uhm, it's far easier just to generate the list so I can grep for my
> name in it.  Scanning a list of 469 packages takes a while.

You're both right. Thanks for pointing me this. I maintain only two packages
now :)

OTOH, maybe dh_undocumented should be removed from debhelper with prior
notice? "This program does nothing and should no longer be used."

Regards
Artur
-- 
Tata: Jak się nazywasz?
Synek: Igor spacja Sapijaszko.

-- 
każde takie zgłoszenie [o bombie] sprawdzić musi nasz specjalista,
powiedzmy pies
/wypowiedź policjanta w TV/


pgpFso7dz8Yjv.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Fri, Jul 04, 2003 at 06:44:57PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> 
> On Thu, Jul 03, 2003 at 09:45:41PM +0200, Emile van Bergen wrote:
> > 
> > Why not indeed traft a DFDG spec that includes licenses such as the GFDL
> > and IETF's and W3C's licenses, as someone suggested, and add a separate
> > 'Documentation' section?
> 
> Because that has been already drafted. Not only I suggested it, I pointed 
> people to  http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
> That section of the DDPolicy describes which are the accepted licenses for 
> documentation and points to some discussions about the subject in 
> debian-legal.

This claims the GNU FDL is acceptable, so it's worse than useless.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpCWbII1BjXf.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Chad Walstrom]

On Thu, Jul 03, 2003 at 10:43:10PM +0100, Andrew Suffield wrote:
> You have some free software, and it comes with a manual.

Your counter example does not apply to IETF Standards documentation.  It
is not software.

In a more general reaction to posts on the list, to say an RFC is an
editable document is downright silly.  It is a literary work that is
intended to be a static document, a reference for protocol
implementation.  An RFC goes through very little editorial changes once
it's been published.  The very process used by the IETF perserves
previous versions of the documentation, this is why you find "This
document superceeds: ..." Their copyright reflects this process.

To require or demand that the IETF changes their copyright policy or
their publishing practices to cater to someone else's idea of what the
document should be used for is plain arogance.  Respect the wishes of
the original authors and the established, reliable publishing policy of
the IETF, and use the document in the proper manner: reference it in
your own supplemental documentation.

If you really feel you must implement your software in a manner that
doesn't comply with an existing RFC's, which is certainly acceptable,
place that in your README or appropriate text.

I really don't see what's wrong with the RFC copyright.  It is freely
distributable reference documentation.  It is not software.  Perhaps it
shouldn't be distributed in Debian "main" because of a pedantic
interpretation of the DFSG, (there's that software reference again) and
Social Contract.  Fine, but it should still be packaged.  It is a
valuable reference, and having the convenience of package installation
improves it's distribution amongst developers.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgp4SsLR4JOmT.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Thomas Viehmann]

Andrew Suffield wrote:
>>people to  http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
> This claims the GNU FDL is acceptable, so it's worse than useless.
It claims that GNU FDL sans cover texts and invariant sections is acceptable.

Cheers

T.


pgpFhyQTZaH4d.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Steve Langasek]

On Fri, Jul 04, 2003 at 12:47:19PM -0500, Chad Walstrom wrote:
> To require or demand that the IETF changes their copyright policy or
> their publishing practices to cater to someone else's idea of what the
> document should be used for is plain arogance.

Which is why no one is doing any such thing.  Instead, we are pointing
out that the RFCs do not comply with the DFSG, and thus, under the
Social Contract as written, should not be included in main.

-- 
Steve Langasek
postmodern programmer


pgpVvASSUgK1x.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Fri, Jul 04, 2003 at 07:47:32PM +0200, Thomas Viehmann wrote:
> Andrew Suffield wrote:
> >>people to  http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
> > This claims the GNU FDL is acceptable, so it's worse than useless.
> It claims that GNU FDL sans cover texts and invariant sections is acceptable.

Which is grossly out of date (read: wrong). This has been discussed to
death on -legal.

"Please leave armchair lawyering to the armchair lawyers"

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpmok2hahqoj.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Fri, Jul 04, 2003 at 12:47:19PM -0500, Chad Walstrom wrote:
> On Thu, Jul 03, 2003 at 10:43:10PM +0100, Andrew Suffield wrote:
> > You have some free software, and it comes with a manual.
> 
> Your counter example does not apply to IETF Standards documentation.  It
> is not software.

Then we have no business shipping it, particularly since it's non-free.

> In a more general reaction to posts on the list, to say an RFC is an
> editable document is downright silly.  It is a literary work that is
> intended to be a static document, a reference for protocol
> implementation.

Bullshit. It is common for RFCs to be revised over time, and
formulated into new documents. This license prohibits agencies other
than the IETF from revising an RFC and publishing the result.

In addition, this license prohibits taking text from an RFC and using
it in free documentation, or even in the --help output for free
software.

It's non-free whichever way you slice it.

> To require or demand that the IETF changes their copyright policy or
> their publishing practices to cater to someone else's idea of what the
> document should be used for is plain arogance.  Respect the wishes of
> the original authors and the established, reliable publishing policy of
> the IETF, and use the document in the proper manner: reference it in
> your own supplemental documentation.

Respect the wishes of the original authors of the software and use it
in the "proper" manner: they way they intended it to be used,
unmodified.

Oh, oops.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpT9N6kosMJL.pgp
Description: PGP signature

RFC Search engine in development

[Karl M. Hegbloom]

I've got a good start on an RFC search engine.  Try it out at:

 http://www.pdxlinux.org/search.html

... and find the code at:

 http://www.hegbloom.net:3006/cgi-bin/viewcvs.cgi/?root=Perl

The modules to look at are Swish.pm, RFC.pm, and the RFC/ directory.  It
needs to be completed and turned into an installable Debian package. 
The search part does not define the presentation.  It returns a list of
Perl hash data structures, so that the client code can present that any
way it likes.  This means that it can be used by a command line tool,
perhaps called from inside emacs, or from a web front end like the one
on pdxlinux.org, which is done using HTML::Mason.

What do you think?  Can you figure out my code?  Need a tour?  Are you a
Perl programmer?  I hope to find some time for completing this, but if
yous want to work on it, go for it; just let me know so we can
coordinate.

-- 
Karl M. Hegbloom <[EMAIL PROTECTED]>

Re: Please remove RFCs from the documentation in Debian packages

[Stephen Stafford]

On Fri, Jul 04, 2003 at 12:47:19PM -0500, Chad Walstrom wrote:

> To require or demand that the IETF changes their copyright policy or
> their publishing practices to cater to someone else's idea of what the
> document should be used for is plain arogance.  Respect the wishes of
> the original authors and the established, reliable publishing policy of
> the IETF, and use the document in the proper manner: reference it in
> your own supplemental documentation.

I don't think anyone is implying that they should do that.  What is being
stated is that the license terms are not Free.  We have a commitment that
everything in Debian main is Free.  Since the RFC license is NOT Free, it
can't be in main.  This does NOT imply anything about the usefulness of
RFCs, merely about their Freedom.

This is one of the stronger arguments for keeping non-free around IMO.
There *are* things which aren't Free, and very likely shouldn't ever be Free
which nevertheless are useful things for our users to have.  I use hwb on a
regular basis, for example, and it is in non-free.  I understand and agree
with why it is in non-free, and I see no real problem with this.  It's STILL
useful enough to have it packaged and available to our users IMO.

> I really don't see what's wrong with the RFC copyright.  It is freely
> distributable reference documentation.  It is not software.  Perhaps it
> shouldn't be distributed in Debian "main" because of a pedantic
> interpretation of the DFSG, (there's that software reference again) and
> Social Contract.  Fine, but it should still be packaged.  It is a
> valuable reference, and having the convenience of package installation
> improves it's distribution amongst developers.

Exactly.  We *must* be able to distribute by the terms of the license.
Modifiability is less important for things like RFCs, certainly.  I still
think it's possible to license RFCs in a way I consider Free but which
preserves their usefulness though.  For example:

You are free to distribute this RFC.  You are free to modify the RFC and
redistribute your modifications provided it is clearly marked as bein a
modified version and NOT endorsed by IETF (perhaps forcing a rename
also).

I think something along those lines is Free and would pass DFSG (needs to be
fleshed out and put into legalspeak, obviously), whilst still providing the
protections that RFCs need from rogue modified standards documents.

Cheers,

Stephen

Re: 469 packages still using dh_undocumented, check if one is yours

[Bernd Eckenfels]

On Fri, Jul 04, 2003 at 07:24:20PM +0200, Artur R. Czechowski wrote:
> OTOH, maybe dh_undocumented should be removed from debhelper with prior
> notice? "This program does nothing and should no longer be used."

well, this would break compatibility. IMHO i think it is enough to add a
lintian check (well, i guess this is already the case) and add a todo on the
package overview page.

Actually vhanging the policy in that respect does create a lot of additional
work and bugs, and we should just let this settle down, in 12 month or so
this issue will be resolved without too much work wasted.

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

Re: Please remove RFCs from the documentation in Debian packages

[Joe Wreschnig]

On Fri, 2003-07-04 at 11:06, Cameron Patrick wrote:
> On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote:
> 
> | How do you show it's not software? How does it differ from software?
> | 
> | What if I take the view that Mozilla is an interpreter and anarchism is
> | the program? Please explain how that differs from the Perl interpreter
> | and Perl programs.
> 
> I would argue that while Perl is Turing complete, HTML is not, thus
> anarchism is not software.

So only programs in Turing-complete languages can be considered
software?

What if your program is written in a Turing-complete language (say,
LaTeX), but doesn't require the language to be Turing-complete to run
(like most LaTeX documents)? You could make a non-Turing complete LaTeX
interpreter that would process the document just as well. Does that mean
it's suddenly not software?

What if I made Turing-complete language of which HTML is a subset? I
could call it PHP.

Don't Cc me. I'm on the list.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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

Re: Please remove RFCs from the documentation in Debian packages

[Thomas Viehmann]

Andrew Suffield wrote:
> On Fri, Jul 04, 2003 at 07:47:32PM +0200, Thomas Viehmann wrote:
> 
>>Andrew Suffield wrote:
>>
people to  http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
>>>This claims the GNU FDL is acceptable, so it's worse than useless.
>>It claims that GNU FDL sans cover texts and invariant sections is acceptable.
> Which is grossly out of date (read: wrong). This has been discussed to
> death on -legal.
... which is much more interesting than your initial statement. Thanks for
clairfying this.

Cheers

T.


pgpN0teLrrdhr.pgp
Description: PGP signature

unsubscribe

[Adam K.]

Re: Please remove RFCs from the documentation in Debian packages

[Chad Walstrom]

On Fri, Jul 04, 2003 at 07:36:13PM +0100, Andrew Suffield wrote:
> Bullshit. It is common for RFCs to be revised over time, and
> formulated into new documents. This license prohibits agencies other
> than the IETF from revising an RFC and publishing the result.

Yes, and the new document is given a new reference number.  You've said
the words yourself, "formulated into new documents."  The new document
is referenced as RFC (MAX+1).  The revision process itself shows that
the document is static.  Individual documents may prohibit editing, but
the process encourages it.  I suggest reading RFC 2026 in its entirety.

> In addition, this license prohibits taking text from an RFC and using
> it in free documentation, or even in the --help output for free
> software.

Hmmm...  In RFC 2026[1], which describes the Notifications to be included
in each standards-related documentation, suggestes in section 10.4.(C)
that such fair-use is allowed.  Interesting that you would interpret it
otherwise.

> It's non-free whichever way you slice it.

I never said it wasn't.  You're stating the obvious, because you're
being pedantic about the DFSG.  Like I said before, and a statement you
conveinently overlooked in order to drag this thread out, that's fine.
If you don't think it should be in main or even contrib, that's
understandable.  I stated that it SHOULD be packaged.  Whether or not we
include it in non-free is up for debate in yet another thread and
mailing list, debian-legal.  (See: beat dead horse)

I apologize for getting into this thread to begin with, because I see
we've become terribly off-topic.  The original question was, "Should we
include RFC documentation in Official Debian packages?"  The answer, if
we follow pedantic procedure with respect to DFSG and the Social
Contract, is "No."  End of discussion.
 
> Respect the wishes of the original authors of the software and use it
> in the "proper" manner: they way they intended it to be used,
> unmodified. ...[snip]... Oh, oops.

Exactly.  Now you're getting it.  Those English and Grammar classes must
be paying off.

References
==
1. http://www.ietf.org/rfc/rfc2026.txt
-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpmiIEiOlIES.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Chad Walstrom]

On Fri, Jul 04, 2003 at 01:18:02PM -0500, Steve Langasek wrote:
> Which is why no one is doing any such thing.  Instead, we are pointing
> out that the RFCs do not comply with the DFSG, and thus, under the
> Social Contract as written, should not be included in main.

Yes, I read more into the thread than was necessary.  Its easy to forget
the the rule of staying within the boundaries of the subject in question
when tangentials are being thrown around freely.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpbUqVoV2yLJ.pgp
Description: PGP signature

Re: Debian menu encoding support

[Eduard Bloch]

#include 
* Bill Allombert [Fri, Jul 04 2003, 08:55:41PM]:

> It is now possible to select the encoding used to write files generated
> by menu in a menu-method. You just need to add outputencoding=""
> in the menu-method file, where  is a valid iconv encoding.
> 
> For example to force output to be UTF-8 encoded, add
> outputencoding="UTF-8"

Jeez, let's reinvent the wheel. And again. And again.

Now, you force every maintainer to update the menu entries for
localisation, when will be the next time to change them again? Why
cannot you just recognize that the Free Desktop format is superior and
invest your manpower into tools for smooth transition to it?

MfG,
Eduard.
-- 
 Smur: du brauchst nen Level 9 Analyzer
 weasel: fällt dir da konkret n name ein?

Out of Office AutoReply: Application

[Serum-CWT HR, Deidre]

Title: Out of Office AutoReply: Application






I will be out-of-the-office on Thursday, July 3rd without any access to email or voicemai.  If you require immediate assistance, you can try to contact Kim Parker at 763-212-6161.  Thank you.

Re: 469 packages still using dh_undocumented, check if one is yours

[Andreas Barth]

* Bernd Eckenfels ([EMAIL PROTECTED]) [030704 20:50]:
> On Fri, Jul 04, 2003 at 07:24:20PM +0200, Artur R. Czechowski wrote:
> > OTOH, maybe dh_undocumented should be removed from debhelper with prior
> > notice? "This program does nothing and should no longer be used."

> well, this would break compatibility. IMHO i think it is enough to add a
> lintian check (well, i guess this is already the case) and add a todo on the
> package overview page.

It _is_ already the case, also for linda. And you can get results
quite easy from
http://lintian.debian.org/reports/Tlink-to-undocumented-manpage.html

So no need for a extra tool.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Bernd Eckenfels]

On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote:
> Additionally, I would like to seriously propose establishing a
> pre-upload interface to ftpmaster so that a developer could learn that
> he is writing a package pending rejection after upload _before_
> spending time on building that package.

Actually I think ftp-master are having already too much power as a decision
instance without real legitimation. Establishing yet another interface for
them to block maintainers would need a resolution by the community that we
are willing to delegate the job of verifying packages to them.

In my situation ftp.masters once rejected a package because of licensing
issues (which was ok), but then i reuploaded the package and the rejected it
because of a missing (unneeded) configure option to exclude ssl. I think the
time of the ftp masters could be spend on other issues without stepping on
ppls feet.

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

Re: [devel] logging for package installs

[Wouter Verhelst]

Op vr 04-07-2003, om 02:11 schreef Christoph Berg:
> Re: [devel] logging for package installs [Joey Hess <[EMAIL PROTECTED]>, Thu, 
> Jul 03, 2003 at 05:38:46PM -0400, <[EMAIL PROTECTED]>]
> > - Display various fairly unimportant warnings, which are often not
> >   useful until after the package is installed and you're using it.
> > - Display error messages, some fatal, and some not.
> > - Show progress displays (in contravention of policy of course).
> > - Various other indications of important and not so important things
> >   that the maintainer script is doing.
> > - Remind users to read the README.Debian file.
> 
> For most (some?) of these, the syslog could be used.

Don't even think about it. Syslog is already such a mess that we need
tools to parse it, and weed out the 'unimportant' information. Also,
syslog is usually rotated, which means that this information would get
lost fairly soon (if I'm not mistaken, the default logrotate
configuration throws away information older than a week); As I
understand Joey, that is not really the idea (but I could misunderstand
him :-)

Re: 469 packages still using dh_undocumented, check if one is yours

[Artur R. Czechowski]

On Fri, Jul 04, 2003 at 10:27:35PM +0200, Andreas Barth wrote:
> It _is_ already the case, also for linda. And you can get results
> quite easy from
> http://lintian.debian.org/reports/Tlink-to-undocumented-manpage.html
This is treated by lintian as a warning. Policy says, that lack of manpage
is considered as a bug. Shouldn't be its priority raised to error?

I think that next step to be taken is informing concerned developers
by email (debian-devel isn't obligatory). And next, after some reasonable(*)
time, filling bug reports against packages which doesn't comply with policy.
If you agree with me I can do this dirty work.

(*) I am not sure, that bugfilling should be done before sarge comes to
stable. But it should be done at the latest after release new stable.

Regards
Czesiu
-- 
Nie wszystko dioda, co sie świeci
/z pamiętnika administratora/

Re: logging for package installs

[Wouter Verhelst]

Op do 03-07-2003, om 23:38 schreef Joey Hess:
> Maybe this is a good time to present this idea I've been kicking around,
> but never really got anywhere with, for as long as I've been working on
> debconf. My idea is to add an abstraction layer for package install-related
> logging in debian.

Why limit that to install? Or do I misunderstand you, and do you
actually mean 'installing and removing packages' (i.e., all
maintainerscripts)? After all, stuff could go wrong with removing a
package, too.

[...]
> This could be bolted on the side of debconf. The abuse of debconf by
> maintainers who feel the need to do the kinds of things listed above
> certianly points at the need for this mechanism. And at least debconf
> has a kind of l10n framework, and some ideas about question priority.
> But this logging and message display is really conceptually different
> than debconf. Debconf is just there to ask questions. It would likely be
> better to design it as a separate program.

Separate but similar, I'd say; similar in design (it would be nice if
this program had a number of backends (sql-database, flat file, ...) to
where logging information could be written *and* a number of front-ends
to be used should the user request the information to be displayed at
install time) and similar in UI, so that it doesn't look to the user as
though this is something completely separate.

Other than that, I very much like the idea.

Re: logging for package installs

[Adam Heath]

On Thu, 3 Jul 2003, Joey Hess wrote:

> #!/bin/sh
> if [ "$1" = configure ] && grep -q evil /etc/myconfig; then
>   dpkg-log --priority=critical \
>--warning=$"/etc/myconfig has evil in it! See README.Debian!"
> elsif [ "$phase_of_moon" = full ]; then
>   dpkg-log --priority=critical \
>--error=$"This package only upgrades during new moons."
>   exit 1
> fi

Please call it deb-log, not dpkg-log.

Also, note that $"" is bash, not posix, while your #! line is only /bin/sh.

Re: 469 packages still using dh_undocumented, check if one is yours

[Bernd Eckenfels]

On Fri, Jul 04, 2003 at 11:57:54PM +0200, Artur R. Czechowski wrote:
> I think that next step to be taken is informing concerned developers
> by email (debian-devel isn't obligatory).

This is not needed, it is included in the policy change document. All
developers who upgrade the policy standard will read it.

> And next, after some reasonable(*)
> time, filling bug reports against packages which doesn't comply with policy.

You should only to that for packages which actually _do_ state, that they
are 3.5.8 or higher.

> If you agree with me I can do this dirty work.

Well, I dont see the point in mass filing bugs for lintian warnings/errors.

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

Re: Debian menu encoding support

[Morten Brix Pedersen]

Hi,

* Eduard Bloch <[EMAIL PROTECTED]> [2003-07-04 22:17:23]:
> #include 
> * Bill Allombert [Fri, Jul 04 2003, 08:55:41PM]:
> 
> > It is now possible to select the encoding used to write files generated
> > by menu in a menu-method. You just need to add outputencoding=""
> > in the menu-method file, where  is a valid iconv encoding.
> > 
> > For example to force output to be UTF-8 encoded, add
> > outputencoding="UTF-8"
> 
> Jeez, let's reinvent the wheel. And again. And again.
> 
> Now, you force every maintainer to update the menu entries for
> localisation, when will be the next time to change them again? Why
> cannot you just recognize that the Free Desktop format is superior and
> invest your manpower into tools for smooth transition to it?

Either you are trolling, or you don't know what you're talking about.

There is nothing wrong with this change. It's just an improvement of our
current _working_ menu system, enabling localized Debian menu section
names. This is a pretty neat usability improvement, in the fact that the
'Debian' menu in my gnome-panel will finally have the menu section names
in Danish instead of English.

Is it so bad that he (and me, and others) are working on delivering a
slightly improved menu system for sarge?

Do you consider it his responsibility to step forward and transition to
the Free Desktop standards, even when _no_ implementation that suits
Debian has been developed yet? Think again.

  - Morten.

-- 
http://mbrix.dk/

Re: Debian menu encoding support

[Morten Brix Pedersen]

Oh, and I forgot something...

* Eduard Bloch <[EMAIL PROTECTED]> [2003-07-04 22:17:23]:
> #include 
> * Bill Allombert [Fri, Jul 04 2003, 08:55:41PM]:
> 
> > It is now possible to select the encoding used to write files generated
> > by menu in a menu-method. You just need to add outputencoding=""
> > in the menu-method file, where  is a valid iconv encoding.
> > 
> > For example to force output to be UTF-8 encoded, add
> > outputencoding="UTF-8"
> 
> Jeez, let's reinvent the wheel. And again. And again.
> 
> Now, you force every maintainer to update the menu entries for
> localisation, when will be the next time to change them again? Why
> cannot you just recognize that the Free Desktop format is superior and
> invest your manpower into tools for smooth transition to it?

It's not _every maintainer_. It is maintainers of packages providing
menu-methods. Just as stated in the announcement. I would estimate that
it's probably only 10-15 packages supplying those.

  - Morten.

-- 
http://mbrix.dk/

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Yven Johannes Leist]

On Thursday 03 July 2003 16:51, Marc Haber wrote:
>
> Additionally, I would like to seriously propose establishing a
> pre-upload interface to ftpmaster so that a developer could learn that
> he is writing a package pending rejection after upload _before_
> spending time on building that package. I find it disturbingly
> impolite to say "sorry, we don't want your volunteer work" _after_ the
> work has been done. Especially if it is done in Mr. Troup's usual "why
> did you bother me in the first place, mere mortal" style.

I find that to be a very unfair accusation, since at least to my eyes there 
was nothing especially unfriendly, unreasonable or otherwise criticizable in 
James rejection notice. If he had told you that the package was never going 
to be included for some not entirely obvious reason then I could understand 
your sentiment, but stating his reasons, and then referring you to a public 
list for further discussion, (thereby, in my reading at least, implying that 
while he thinks the package isn't suitable at least yet, public discussion 
might reveal otherwise) seems quite fair to me.

I personally very much value the fact that someone like James whose knowledge 
and judgment I trust invests so much time in vetting (my) packages for 
potential omissions or stupidities.

Cheers,
Yven


> Greetings
> Marc, somewhat mad at the moment

Hmm, *my* strategy for handling such states of emotional unrest is to wait at 
least half a day to see how much anger or "madness" is actually left, since I 
find that to be an enormous efficiency gain with respect to avoiding lengthy 
and pointless discussions... ;-)

-- 
Yven Johannes Leist - [EMAIL PROTECTED]
http://www.leist.beldesign.de

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Herbert Xu]

Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> 
> In my situation ftp.masters once rejected a package because of licensing
> issues (which was ok), but then i reuploaded the package and the rejected it
> because of a missing (unneeded) configure option to exclude ssl. I think the

I don't know the specifics of this case but perhaps they were worried
about the possibility of pulling ssl into a GPLed program accidentally?
If that's the case then it's certainly a valid reason to reject the
package.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Please remove RFCs from the documentation in Debian packages

[Isaac To]

> "Brian" == Brian May <[EMAIL PROTECTED]> writes:

Brian> Couldn't you write a new document along the lines of "This is
Brian> based on RFC1341 with the following exceptions "?

Brian> That way you can see exactly what differences there are to the
Brian> known standard, at a glance, without having to resort to using
Brian> tools like diff.

Don't mix up the philosophical problem with the technical concerns.  Yes,
there are times when what you say makes sense and is preferable.  But at
other times there are other concerns that makes it impractical or difficult
(e.g., there are just too many changes, new concepts are introduced, etc).

The question is not whether there are situations when it is no good for
users to change the documents.  It is instead whether the author of the RFCs
(or the IETF RFC process) should restrict me from using the standard that
way if I found it to best suit my needs---and if they do restrict me,
whether Debian should still say it is part of the free stuffs that it
delivers.

Regards,
Isaac.

Re: Please remove RFCs from the documentation in Debian packages

[Brian May]

On Fri, Jul 04, 2003 at 04:24:20PM +0800, Isaac To wrote:
> It is far from obvious.  What if I develop my software, finds the
> specification of MIME to be very similar to what my software does, but yet I
> need to modify the things here and there so as to suit my needs; and when
> documenting my software I want to use RFC 1341 as a starting point, change
> those things that my software do differently than 1341, and then say that is
> the documentation of my software?  I have no intention to confuse the result
> with RFC 1341, so what's wrong to do the edit (except that the author of RFC
> 1341 might be unhappy with that)?  To the user it is really best done that
> way: if I have to rewrite 1341 I probably won't give documentation at all
> because I don't have the time.  If instead I just point out the positions
> that my software differs from 1341 the user would have to read two different
> documents.

Couldn't you write a new document along the lines of "This is based on
RFC1341 with the following exceptions "?

That way you can see exactly what differences there are to the known
standard, at a glance, without having to resort to using tools like
diff.
-- 
Brian May <[EMAIL PROTECTED]>

Re: 469 packages still using dh_undocumented, check if one is yours

[Joey Hess]

Artur R. Czechowski wrote:
> OTOH, maybe dh_undocumented should be removed from debhelper with prior
> notice? "This program does nothing and should no longer be used."

As a rule I try to avoid causing less than 469 FTBFS bugs with any given
change I make to debhelper. I have removed programs when as many as
three packages still used them, after appropriate bug reports and a two
month grace period.

-- 
see shy jo


pgpOWvoz2vuIK.pgp
Description: PGP signature

Re: Debian menu encoding support

[Joey Hess]

Bill Allombert wrote:
> For ISO-8859-1, outputencoding="ISO-8859-1"
> 
> There is a special encoding "LOCALE", which refers to the current locale
> encoding.

Won't this make the menu-method not work with versions of menu prior to
2.1.9-1? Packages would need to update their depends or conflicts with
menu to ensure a new enough version is installed. Otherwise it fails
with an "Unknown identifier" error message.

-- 
see shy jo


pgpy2qSMhFcq6.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Richard Braakman]

On Sat, Jul 05, 2003 at 11:41:51AM +1000, Brian May wrote:
> Couldn't you write a new document along the lines of "This is based on
> RFC1341 with the following exceptions "?

Tell that to the authors of RFC2616 :-)
Sometimes it's very valuable to NOT have people reading the old version
first, for example because it's full of information that is almost but
entirely not correct.  Then you want them to instead read a consistent
presentation of the new standard.

Now, you might want to say that only the IETF should be allowed to
produce something like RFC2616.  That's fine as long as the IETF is
the smart and effective body it is now and everyone is welcome to
join it.  But how do you know this will still be the case 20 years
later?  The arguments against forking standards are pretty similar
to the arguments against forking gcc -- in both cases it's generally
a bad idea, but the health of a free system depends on it being
potentially possible.

Richard Braakman

Re: Debconf or not debconf : Conclusion

[Steve Langasek]

On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote:
> On a separate but related topic, I think a much better approach would
> be to handle configuration as a step entirely separate from the
> install phase.  Let the install be entirely quiet, and let packages
> have intelligent defaults.  If the package absolutely must be
> configured before it can be used, then let it be non-functional until
> someone actually calls dpkg-configure (which would be just like
> dpkg-reconfigure except that's the only time the questions would be
> asked).

I don't see how this would be much of an improvement.  While I agree
that packages for which intelligent defaults are possible should simply
ship with those defaults set, there are enough packages that don't have
sensible defaults to make debconf a good idea.  If dpkg-configure is
called separately, how does the admin know when there are packages for
which it should be called?  And if the admin is automatically notified
of this, why is this better than simply calling dpkg-configure then and
there?

Although debconf notes are frequently abused, I haven't given up hope
that current problems with other uses of debconf will sort themselves
out as the techniques and rules become more familiar to maintainers.

-- 
Steve Langasek
postmodern programmer


pgpYREqSrTXRn.pgp
Description: PGP signature

trouble debugging a bug on m68k

[Graham Wilson]

im wondering if anyone can help me with bug #196563. the bug says that
xmllint is segfaulting on m68k. the reporter can reproduce the segfault.

i asked him for a backtrace, but gdb segfaulted. he was able to provide
strace output however. it seems that the bug manifests before the
program's main() ever gets called, which makes me think that there is
something wrong with glibc's startup code or maybe even the dynamic
linker.

i know that this is not a bug in xmlto, so i am wondering where to
reassign it. is this a bug in glibc? or maybe gcc?

thanks for the help.

-- 
gram


pgpkDICX4TzLL.pgp
Description: PGP signature