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

[Marc Haber]

On Thu, 3 Jul 2003 17:21:05 +0200, Thomas Wana <[EMAIL PROTECTED]> wrote:
>Am Donnerstag, 3. Juli 2003 16:51 schrieb Marc Haber:
>> 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. 
>
>Well that's the purpose of ITP-bugs against wnpp I think, because
>they are CC'd to debian-devel for public review.

I do not ask for public review, I ask for a pre-work interface to
ftpmaster which is the single instance of power that is able to
disallow a package into the archive.

Please show me a single ITP bug number where ftpmaster has said "this
package will not go into the archive, I will reject it on upload".

>And since ftpmaster sent you to -devel he would obey the opinion
>of the list.

The list does not seem to have an opinion yet.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

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

[Marc Haber]

On Thu, 3 Jul 2003 17:32:29 +0200, Josip Rodin <[EMAIL PROTECTED]> wrote:
>On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote:
>> In the past years, I have found it annoying that the eicar anti-virus
>> testfile is not available as aptable Debian package.
>
>Why is this annoying?

Because it makes debugging anti-virus software harder, and forces
maintainers of anti-virus packages to have their own means of
obtaining eicar.com for testing purposes

>> 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.
>
>Frankly, with this particular one, I entirely fail to see why you ignore
>several perfectly valid reasons laid out in the reasonably polite (if a bit
>dazzled) rejection notice and go off ranting instead.

Saying a package is "silly" is a valid rejection reason in your
opinion? Another reason is that a package depending on and
recommending eicar-testfile would have to go into contrib. Yes, right,
but there is Suggests: which allows a package suggesting
eicar-testfile to stay in main.

And forbidding code-reuse by suggesting that packages needing
eicar.com could download the file themselves (probably forcing these
packages to go into contrib themselves while they could be in main if
eicar-testfile were in debian) is not a reason as well?

Well, _I_ find it impolite to say work that has been done by a
volunteer is "silly". Actually, I find it discouraging to do any more
future work for Debian

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Debconf or not debconf : Conclusion

[Anthony Towns]

On Fri, Jul 04, 2003 at 11:06:36PM -0500, Steve Langasek wrote:
> 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.  

It means that you don't have to sit through the unpacking and postinst
phases, which can be quite tedious.

> 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?

Three possibilities:

dpkg-configure *.deb; dpkg -i *.deb
for a in *.deb; do dpkg -i $a; dpkg-configure $a; done
dpkg -i *.deb; dpkg-configure --pending --all

The point of decoupling installation and configuration is to let the admin
choose which of these scenarios happen, instead of the distribution or
the maintainer. The first is appropriate if you're doing installs of many
systems (work out how you want it to look, then slam it onto all of them
automatically), the second if you're doing an upgrade from aptitude, and
the third if you've blatted a standard install from a magazine cover-CD
and need to do some final configuration.

The original theory was for debconf to make these choices possible (since
it was vastly difficult to do it in the days of "echo" and "read blah").

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpwF8lSkDjI0.pgp
Description: PGP signature

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

[Marc Haber]

On Thu, 3 Jul 2003 12:57:19 -0300, Henrique de Moraes Holschuh
<[EMAIL PROTECTED]> wrote:
>On Thu, 03 Jul 2003, Marc Haber wrote:
>> Since eicar.com has no license and eicar doesn't seem to be interested
>> in clarifying its license, inclusion of the eicar test string in
>> Debian proper is out of the question, even for non-free.
>
>Ick.  They are included in the amavisd-new _source_ packages.

Which is a violation of eicar.com's license in my opinion. I won't
file a grave bug against amavisd-new, but I suspect that somebody else
will.

>From http://www.eicar.org/anti_virus_test_file.htm, I get that while they do
>not display a license, they explicitly allow us to distribute it.

NACK. The word "distribute" is not used on the web page. People are
encouraged to make use of the test file, and to point other people to
the eicar.com download page. I think the page makes it pretty clear
that eicar.com wants each user to download her own copy of eicar.com
from the eicar web page. Which is what my eicar-testfile package tries
to do.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

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

[Marc Haber]

On Fri, 4 Jul 2003 23:05:02 +0200, Bernd Eckenfels
<[EMAIL PROTECTED]> wrote:
>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.

ftp-master _has_ power to block maintainers. What I am asking for is
an interface to be at least blocked _before_ work is done.

>I think the
>time of the ftp masters could be spend on other issues without stepping on
>ppls feet.

Especially becuase ftpmaster usually steps on people's feed not by
rejecting a package, but by calling packages "silly", or putting them
in directories named "lame".

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

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

[Marc Haber]

On Sat, 5 Jul 2003 03:01:14 +0200, Yven Johannes Leist
<[EMAIL PROTECTED]> wrote:
>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.

How would you react if somebody called work you did and that took a
few hours "silly"? And Mr. Troup's appreciation of my work is
appropriately named in the directory name the package sits in at the
moment.

>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.

Well, if there was an interface to interact with ftpmaster _before_
any work is being done... Turnaround times are too long anyway. It
took Mr. Troup almost two weeks to reject this "silly" package.

>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... ;-)

Actually, I get madder the longer I think about it.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Debian menu encoding support

[Eduard Bloch]

#include 
* Morten Brix Pedersen [Sat, Jul 05 2003, 01:49:38AM]:

> > 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

It is not wrong. It is just wasted manpower, looking at the long-term
changes.

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

Sarge (IMHO) won't be released before the middle of 2004. Is that not
enough time to develop and integrate a new menu system?

MfG,
Eduard.
-- 
 aber /me wollte ins bett. nacht
 hehe, morgen channel, nacht weasel ;)

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

[Thomas Viehmann]

Marc Haber wrote:
>>Well that's the purpose of ITP-bugs against wnpp I think, because
>>they are CC'd to debian-devel for public review.
> Please show me a single ITP bug number where ftpmaster has said "this
> package will not go into the archive, I will reject it on upload".
There's numerous ITPs where e.g. licensing (seems to be a main issue with
ftpmaster) has been discussed (the last I recall is #199874 dated 2003-07-03).
If you're too cool to do proper ITPs then don't complain about the debian
processing for new packages not working for you.

>>And since ftpmaster sent you to -devel he would obey the opinion
>>of the list.
> The list does not seem to have an opinion yet.
Hmm. No?

Cheers

T.


pgpMCnkQQyKPe.pgp
Description: PGP signature

Re: but I want the GNU versions of packages

[Marc Haber]

On Thu, 03 Jul 2003 16:05:39 +0100, James Troup <[EMAIL PROTECTED]>
wrote:
>Marc Haber <[EMAIL PROTECTED]> writes:
>> Given the current state of affairs, I am pretty sure that such a
>> package will be rejected by ftpmaster. They pretty sure reject almost
>> everything I upload.
>
>Since you didn't bother with specifics, I can only guess you're
>referring to clamav-data and eicar-testfile.

I am referring to eicar-testfile. clamav-data is a bad screwup on my
part resulting from the fact that I never originally intended
clamav-data to be in Debian. That was suggested by somebody else, and
I thought too much ("Good Idea. Let's do it") before not thinking
enought ("that package is not for public distribution").

That will be fixed as soon as clamav-getfiles is in the archive.

Please note that I wouldn't complain if you would do your actual work
as fast as you react to obvious trolls.

Greetings
Marc, who _really_ doesn't appreciate packages placed into "lame"
directories and them called silly.

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

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

[Ben Burton]

> How would you react if somebody called work you did and that took a
> few hours "silly"?

In the sweetest way possible, if all you lost was a few hours then I
don't see why you're (apparently) so very upset.

Many times I have seen contributions worth days or weeks of work
dismissed from software projects.  For that matter, in academia you can
spend months or years working on a result only to find that someone else
has been working on the same result simultaneously and has published it
before your work was complete.

If it's only a few hours I'd honestly just file it away under experience
and get on with my life.

Not taking sides, just putting it into perspective.

Ben. :)

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

[Thomas Viehmann]

Marc Haber wrote:
> Because it makes debugging anti-virus software harder, and forces
> maintainers of anti-virus packages to have their own means of
> obtaining eicar.com for testing purposes
Debugging anti-virus software should be done by the maintainers thereof.
Why would a user need this?

> Saying a package is "silly" is a valid rejection reason in your
> opinion? Another reason is that a package depending on and
> recommending eicar-testfile would have to go into contrib. Yes, right,
> but there is Suggests: which allows a package suggesting
> eicar-testfile to stay in main.
Having an installer just because some organization is too lazy to provide a
license with a 68 bytes is plainly wrong (since eicar seems to be located in
Germany it might even be questionable whether they can claim copyright for
something of that size - but then they just could put it into the public 
domain).

> Well, _I_ find it impolite to say work that has been done by a
> volunteer is "silly". Actually, I find it discouraging to do any more
> future work for Debian
What did you want to package next? An installer that has a debconf prompt for
asking whether eicar.com, eicar.com.txt, eicar_com.zip, or eicarcom2.zip should
be downloaded?

Seriously, you're more substantial contributions have been accepted haven't
they? And that in spite of the fact that not having a legal name in deamon's
copyright file is questionable. And the package in question is just about the
silliest package I've ever seen (aside from those announced April 1st).


Cheers

T.


pgpwOyC9gFD84.pgp
Description: PGP signature

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

[Colin Watson]

On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote:
> It is my opinion that it would be a good idea to have that installer
> package in Debian. Heck, if I wouldn't have that opinion, I wouldn't
> have spent some of my time to build that package.
> 
> 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.

So, let me get this straight: you think that if a volunteer does some
work then it should be accepted into Debian unconditionally? No matter
what? Because that's what you seem to be saying.

Bah. I'm glad the ftpmasters reject packages from time to time. I'm sure
you could always ask some people on IRC if you wanted a second opinion
on something you're doing.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Processed: reassign 199197 to libgnome2-common

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 199197 libgnome2-common
Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in 
testing (Sarge)
Bug reassigned from package `general' to `libgnome2-common'.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

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

[Andreas Barth]

* Thomas Viehmann ([EMAIL PROTECTED]) [030705 09:35]:
> Marc Haber wrote:
> >>Well that's the purpose of ITP-bugs against wnpp I think, because
> >>they are CC'd to debian-devel for public review.
> > Please show me a single ITP bug number where ftpmaster has said "this
> > package will not go into the archive, I will reject it on upload".
> There's numerous ITPs where e.g. licensing (seems to be a main issue with
> ftpmaster) has been discussed (the last I recall is #199874 dated 2003-07-03).

Andreas Tille, who critized the license in #199874 is according to
http://www.debian.org/intro/organization not ftpmaster. So ...

> If you're too cool to do proper ITPs then don't complain about the debian
> processing for new packages not working for you.

... is not right.



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: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Fri, Jul 04, 2003 at 02:30:47PM -0500, Chad Walstrom wrote:
> 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.

The license prohibits anybody from doing this; the IETF can only
because they own the copyright.

> > 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.

Where? Also note that fair use does not exist in all jurisdictions, so
claiming something is free based on fair use provisions is bogus.

> > 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.

Your sarcasm detector is broken. And for some reason you seem to be
advocating non-free software. Go away.

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


pgp8MYUZBZPio.pgp
Description: PGP signature

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

[Andreas Barth]

* Colin Watson ([EMAIL PROTECTED]) [030705 10:50]:
> 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. I find it disturbingly
> > impolite to say "sorry, we don't want your volunteer work" _after_ the
> > work has been done.
 
> So, let me get this straight: you think that if a volunteer does some
> work then it should be accepted into Debian unconditionally? No matter
> what? Because that's what you seem to be saying.

Marc is doing it the other way: He want an interface to reject a
package before substantial work has been spent on it. So there
shouldn't be this conflict any more, which would be a good thing.


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: Package Moscow ML and HOL

[Sven Luther]

On Thu, Jul 03, 2003 at 05:36:30PM +0800, ZHAO Wei wrote:
> On Thu, 2003-07-03 at 14:47, Ralf Treinen wrote:
> > I remember vaguely that there used to be a licence problem with
> > Moscow ML. What is its exact licence now?
> 
> Under the mosml/copyright directory, there are three license files:
> 
> 1. gpl2 - which is exactly a copy of GPL v2
> 2. copyright.att - which covers part of the library come from SML/NJ,
> and as I read it, it's mostly BSDish
> 3. copyright.cl - covers code come from CAML Light, which looks a little
> bit strange, but to my unexperienced eyes, looks like a homebrew GPL
> 
> Anyway, I think it's generally acceptable to put it in Debian main.
> What's you opinion?

No, it is not. It is the caml-light licence which is the tumbling block.
It can still be going in non-free though, as the older ocaml used to
have the exact same licence. Look at the (4 to 5 year old) archives of
debian-legal for discussion on this.

I think i finally managed to have it enter non-free by having a letter
from inria telling that they don't considered the things needed for
debian packaging as modifications, and globally gave Debian the
perission to move it in non-free. Check older versions of ocaml, it will
still be listed in the copyright file, but you will have to go to potato
i think.

Friendly,

Sven Luther

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

[Colin Watson]

On Sat, Jul 05, 2003 at 11:08:04AM +0200, Andreas Barth wrote:
> * Colin Watson ([EMAIL PROTECTED]) [030705 10:50]:
> > 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. I find it disturbingly
> > > impolite to say "sorry, we don't want your volunteer work" _after_ the
> > > work has been done.
>  
> > So, let me get this straight: you think that if a volunteer does some
> > work then it should be accepted into Debian unconditionally? No matter
> > what? Because that's what you seem to be saying.
> 
> Marc is doing it the other way: He want an interface to reject a
> package before substantial work has been spent on it. So there
> shouldn't be this conflict any more, which would be a good thing.

That's pointless, I think. If I were an ftpmaster I would not be willing
to render an opinion on a package before I actually saw the package,
especially if I were going to be held to that opinion later (and, if I
wasn't, what's the point)?

Initial upload is the right time to perform checks.

-- 
Colin Watson  [EMAIL PROTECTED]

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

[Michael Banck]

On Sat, Jul 05, 2003 at 09:26:17AM +0200, Marc Haber wrote:
> How would you react if somebody called work you did and that took a
> few hours "silly"? And Mr. Troup's appreciation of my work is
> appropriately named in the directory name the package sits in at the
> moment.

[EMAIL PROTECTED]:/org/ftp.debian.org/queue/reject$ ls eicar-testfile_0.1*
eicar-testfile_0.1.dsc eicar-testfile_0.1_all.deb
eicar-testfile_0.1_i386.reason
eicar-testfile_0.1.tar.gz  eicar-testfile_0.1_i386.changes

What's the problem? Is there a copy somewhere else?

> It took Mr. Troup almost two weeks to reject this "silly" package.

In another mail you complained that it took far less time to reject a
package than to process it successfully. This seems unconsistent with
this statement.


Michael

-- 
 hi Kamion
 tbm: hi. er. where are you?
 Kamion: sitting in your living room ;-)

Bug#200142: ITP: tkgamma -- A simple color calibration utility for XFree86-4

[Neil McGovern]

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

* Package name: tkgamma
  Version : 1.0.0 
  Upstream Author : Pixel Fairy <[EMAIL PROTECTED]>
* URL : http://pixel.fairyden.net/tkgamma/ 
* License : GPL
  Description : A simple color calibration utility for XFree86-4
 tkgamma is a tcl/tk front end to the xgamma command to help color
 calibrate a monitor and X server.
 .
 It allows control over red, blue and green gamma separately, or linked
 for an overall effect.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux vivacia 2.4.20-1-k7-smp #1 SMP Sat Mar 22 15:58:43 EST 2003 i686
Locale: LANG=en_GB, LC_CTYPE=en_GB

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

[Marc Haber]

On Sat, 05 Jul 2003 10:14:10 +0200, Thomas Viehmann <[EMAIL PROTECTED]>
wrote:
>Marc Haber wrote:
>> Because it makes debugging anti-virus software harder, and forces
>> maintainers of anti-virus packages to have their own means of
>> obtaining eicar.com for testing purposes
>Debugging anti-virus software should be done by the maintainers thereof.
>Why would a user need this?

A local administrator could use that file to make sure that his
security measures are properly in place.

>Having an installer just because some organization is too lazy to provide a
>license with a 68 bytes is plainly wrong

These 68 bytes are very useful. So there should be a way to obtain
them. The Debian way

>> Well, _I_ find it impolite to say work that has been done by a
>> volunteer is "silly". Actually, I find it discouraging to do any more
>> future work for Debian
>What did you want to package next? An installer that has a debconf prompt for
>asking whether eicar.com, eicar.com.txt, eicar_com.zip, or eicarcom2.zip should
>be downloaded?

If you really want this to evolve into a pissing contest about who
does a better job in maintaining packages please compare our package
tracking pages before you begin.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

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

[Marc Haber]

On Sat, 5 Jul 2003 11:48:24 +0200, Michael Banck <[EMAIL PROTECTED]>
wrote:
>Is there a copy somewhere else?

Yes.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

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

[Marc Haber]

On Sat, 5 Jul 2003 10:43:35 +0100, Colin Watson <[EMAIL PROTECTED]>
wrote:
>That's pointless, I think. If I were an ftpmaster I would not be willing
>to render an opinion on a package before I actually saw the package,
>especially if I were going to be held to that opinion later (and, if I
>wasn't, what's the point)?
>
>Initial upload is the right time to perform checks.

To perform technical checks, yes. This one is an ideological issue.
Which could be properly discussed before time was spent to get a
package built and make it pass all lintian checks.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

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

[Andreas Barth]

* Colin Watson ([EMAIL PROTECTED]) [030705 12:05]:
> On Sat, Jul 05, 2003 at 11:08:04AM +0200, Andreas Barth wrote:
> > * Colin Watson ([EMAIL PROTECTED]) [030705 10:50]:
> > > 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. I find it disturbingly
> > > > impolite to say "sorry, we don't want your volunteer work" _after_ the
> > > > work has been done.

> > > So, let me get this straight: you think that if a volunteer does some
> > > work then it should be accepted into Debian unconditionally? No matter
> > > what? Because that's what you seem to be saying.

> > Marc is doing it the other way: He want an interface to reject a
> > package before substantial work has been spent on it. So there
> > shouldn't be this conflict any more, which would be a good thing.
 
> That's pointless, I think. If I were an ftpmaster I would not be willing
> to render an opinion on a package before I actually saw the package,
> especially if I were going to be held to that opinion later (and, if I
> wasn't, what's the point)?

There are several reasons why a package could be rejected. Some are
"global" reasons (means: independent of the way the maintainer
packaged) and some are "local", e.g. sloppy packaging, abusing
scripts or pointless descriptions.

The discussion is only about global reasons, as "wrong license", "we
don't need this package" or simmilar. This reasons could be discussed
before making the package quite as easy as afterwards.


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: Please remove RFCs from the documentation in Debian packages

[Petter Reinholdtsen]

[Stephen Stafford]
> 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.

There seem to be two ways of interpreting the social contract.  One is
that the only thing (100%) included in Debian must be free software.
The other one is that all software included in Debian must be free
software, as defined by the DFSG.  Only if you use the first
interpretation do you statement make sense.  I find it rather strange
to try to handle everything as software, and believe we need to handle
non-software with a different set of guidelines.  Until these
guidelines are in place, I believe it is unwise to try to handle
non-software as software and force the DFSG on all of these.

Close old RFP/ITPs?

[Andreas Barth]

Hi,

is it usefull/ok to close old RFP/ITP-entrys? "old" means for me more
than year since the last mail for ITP, and 2 years for RFP. Of course
I would write mail first whether the package is still wanted or if the
packaging is still in order, and only close if no answer for a month.

Comments?

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: Close old RFP/ITPs?

[Marc Haber]

On Sat, 5 Jul 2003 14:05:55 +0200, Andreas Barth <[EMAIL PROTECTED]>
wrote:
>is it usefull/ok to close old RFP/ITP-entrys? "old" means for me more
>than year since the last mail for ITP, and 2 years for RFP. Of course
>I would write mail first whether the package is still wanted or if the
>packaging is still in order, and only close if no answer for a month.

I would recommend leaving old RFPs open, and retitling old ITPs to
RFP.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Close old RFP/ITPs?

[Sam Hocevar]

On Sat, Jul 05, 2003, Andreas Barth wrote:

> is it usefull/ok to close old RFP/ITP-entrys? "old" means for me more
> than year since the last mail for ITP, and 2 years for RFP. Of course
> I would write mail first whether the package is still wanted

   I do not think old RFPs should be closed, at least on the sole basis
that they are old. Even if the submitter is no longer interested, other
people may be, and there is no way to know how many they are.

   A clean-up is probably needed though, for instance #186174 (xyzzy)
is a rather silly RFP, it should at most be a wishlist bug for whatever
console games package we have.

Regards,
-- 
Sam.

Re: Debconf or not debconf : Conclusion

[Theodore Ts'o]

On Sat, Jul 05, 2003 at 05:05:01PM +1000, Anthony Towns wrote:
> The point of decoupling installation and configuration is to let the admin
> choose which of these scenarios happen, instead of the distribution or
> the maintainer. The first is appropriate if you're doing installs of many
> systems (work out how you want it to look, then slam it onto all of them
> automatically), the second if you're doing an upgrade from aptitude, and
> the third if you've blatted a standard install from a magazine cover-CD
> and need to do some final configuration.

Yet another reasons for wanting to decouple installation and
configuration is if some hardware company (such as VA^H^H Emperor
Linux) wishes to ship Debian pre-installed on the system.  In that
case, installation happens at the factory, and not when the user
receives it in his/her hot little hands.

- Ted

Re: Please remove RFCs from the documentation in Debian packages

[Stephen Stafford]

On Sat, Jul 05, 2003 at 02:10:12PM +0200, Petter Reinholdtsen wrote:
> [Stephen Stafford]
> > 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.
> 
> There seem to be two ways of interpreting the social contract.  One is
> that the only thing (100%) included in Debian must be free software.
> The other one is that all software included in Debian must be free
> software, as defined by the DFSG.  Only if you use the first
> interpretation do you statement make sense.  I find it rather strange
> to try to handle everything as software, and believe we need to handle
> non-software with a different set of guidelines.  Until these
> guidelines are in place, I believe it is unwise to try to handle
> non-software as software and force the DFSG on all of these.

Umm...I find it hard to see how you can interpret "Debian will remain 100%
Free software" as meaning that only the software in Debian will always be
100% Free.  You *could* interpret it to mean that the only things in Debian
will be software that is Free if you wanted to...in which case RFCs (not
being software) do NOT belong in Debian.

Personally I prefer the option of treating everything that is in Debian as
being software (whether it is or not) and applying the DFSG to decide on
whether it is Free or not.

Whether we need guidelines for things which are non-software to determine
their Freeness or not is a different question.  However, while we DON'T have
those guidelines, we MUST use the only guidelines we do have, which is the
DFSG.

I had to agree to abide by the DFSG when I did NM as did everyone with an
account (unless they were given accounts before the NM process was created).
I *Still* believe that the DFSG is a useful set of guidelines for everything
in Debian.

To digress a little from the core point of the thread, I think that the fact
that there are some things which aren't Free, but which still serve our
users' needs, is a good reason for keeping non-free around.

I am wholly uncomfortable with the idea of putting non-free stuff in main
(the "because it's not really software, it doesn't really matter" argument).
I think the existence of something in Debian main implies somethign about
its freedom.  This is laid out in the Social Contract and the DFSG.  I wish
we could lose the stigma that non-free has.  There's nothing wrong with
things in non-free...they just are NOT FREE!  Putting something in main
implies that Debian as an entity endorsees it as Free.

I should explain here that I'm not half as rabidly anti non-free software as
many DDs.  I prefer to use Free stuff if it's available and is fit for
purpose.  If there isn't something Free available to do the task, I'll use
something non-free instead.  Just because I will use non-free software, does
NOT mean I think it belongs in Debian main though.  There is a committment
to keep Debian main 100% Free, and that's a committment I like.

/me stops before he goes on a real rant

Cheers,

Stephen


pgp1fail3suJW.pgp
Description: PGP signature

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

[Josip Rodin]

On Sat, Jul 05, 2003 at 01:17:50PM +0200, Andreas Barth wrote:
> The discussion is only about global reasons, as "wrong license", "we
> don't need this package" or simmilar. This reasons could be discussed
> before making the package quite as easy as afterwards.

OK, so basically you think ftpmaster people should spend review each ITP for
such global rejection reasons, then? You can't expect this to happen in any
remotely timely fashion, at least not with this many ftpmasters and this
many hours in a day.

-- 
 2. That which causes joy or happiness.

Re: Close old RFP/ITPs?

[Andreas Barth]

* Sam Hocevar ([EMAIL PROTECTED]) [030705 14:50]:
> On Sat, Jul 05, 2003, Andreas Barth wrote:

> > is it usefull/ok to close old RFP/ITP-entrys? "old" means for me more
> > than year since the last mail for ITP, and 2 years for RFP. Of course
> > I would write mail first whether the package is still wanted
 
>I do not think old RFPs should be closed, at least on the sole basis
> that they are old. Even if the submitter is no longer interested, other
> people may be, and there is no way to know how many they are.
> 
>A clean-up is probably needed though, for instance #186174 (xyzzy)
> is a rather silly RFP, it should at most be a wishlist bug for whatever
> console games package we have.

It's much more difficult to make an cleanup on a not formal criterium,
and almost impossible for myself.

However, if I ask in mail this mail would also be forwarded to
debian-wnpp, and any reader there could answers that a package seems
usefull and therefore the RFP should not be closed. So I think this
is fair enough and if neither the original requester nor any reader of
debian-wnpp sees need for a package it really doesn't need to be
packaged any more.

To Marc: You are right, ITPs should be treated as RFPs in this case
and retitled accordingly.


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: Please remove RFCs from the documentation in Debian packages

[Andrew Suffield]

On Sat, Jul 05, 2003 at 02:10:12PM +0200, Petter Reinholdtsen wrote:
> [Stephen Stafford]
> > 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.
> 
> There seem to be two ways of interpreting the social contract.  One is
> that the only thing (100%) included in Debian must be free software.
> The other one is that all software included in Debian must be free
> software, as defined by the DFSG.  Only if you use the first
> interpretation do you statement make sense.  I find it rather strange
> to try to handle everything as software, and believe we need to handle
> non-software with a different set of guidelines.  Until these
> guidelines are in place, I believe it is unwise to try to handle
> non-software as software and force the DFSG on all of these.

Even a minimal level of understanding of what free software is, and
what Debian is about, is sufficient to understand that the RFC license
is clearly non-free. The DFSG _is_ just a set of guidelines; playing
lawyer games with the wording will not make non-modifiable things
acceptable.

Any arguments you may care to make in favour of non-modifiable things
will apply equally to software.

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


pgpFJO0l4UUfu.pgp
Description: PGP signature

failing to compile a KDE package

[martin f krafft]

Folks,

I am near explosion. I am trying to sponsor the kmymoney2 package
found at ftp://shakti.ath.cx/debian/kde3.1-sid/kmymoney2 , but
I cannot build it. I am not a KDE user, so that may be the root of
the problem.

Here is the error I see all the time:

  checking for Qt... configure: error: Qt (>= Qt 3.0.2) (library
  qt-mt) not found. Please check your installation! For more details
  about this problem, look at the end of config.log. Make sure that
  you have compiled Qt with thread support!
  make: *** [configure-stamp] Error 1

But that library is installed:

diamond:..oney2/kmymoney2-0.5.1> dpkg -l libqt\* | grep ^ii
ii  libqt2 2.3.1-22   Qt GUI Library (runtime version).
ii  libqt3-compat- 3.1.1-8Qt 1.x and 2.x compatibility includes
ii  libqt3-headers 3.1.1-8Qt3 header files
ii  libqt3-mt-dev  3.1.1-8Qt development files (Threaded)
ii  libqt3c102-mt  3.1.1-8Qt GUI Library (Threaded runtime version)

Can you help me out here? Or maybe some KDE-using developer would be
willing to take on the sponsorship of this package?

Thanks,

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html
Get my key here: http://madduck.net/me/gpg/publickey



- End forwarded message -

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


pgp9G1ClxfMOt.pgp
Description: PGP signature

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

[Mark Brown]

On Sat, Jul 05, 2003 at 02:56:30PM +0200, Josip Rodin wrote:

> OK, so basically you think ftpmaster people should spend review each ITP for
> such global rejection reasons, then? You can't expect this to happen in any
> remotely timely fashion, at least not with this many ftpmasters and this
> many hours in a day.

Not to mention that it's still possible that a package may have a
problem which is not obvious until the package is seen.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: failing to compile a KDE package

[Ben Burton]

>   checking for Qt... configure: error: Qt (>= Qt 3.0.2) (library
>   qt-mt) not found.

Try

./configure --with-qt-dir=/usr/share/qt3

and see if that helps.  If it does then upstream is using a very old
admin/ directory which should probably be updated.

If the compilation then breaks because of missing headers like
qptrlist.h and so on, install libqt3-compat-headers and optionally flame
the Qt maintainer(s) for not including them in their standard Qt
development installation.  And tell upstream that they're using legacy
headers as the Qt maintainers are expecting you to, which is why they've
chosen to break Qt in this way.

Ben. :)

Re: failing to compile a KDE package

[martin f krafft]

also sprach Ben Burton <[EMAIL PROTECTED]> [2003.07.05.1556 +0200]:
> ./configure --with-qt-dir=/usr/share/qt3

i had
  --with-qt-includes=/usr/include/qt3
  --with-qt-libraries=/usr/lib 

in there, but I still get the same error if I replace that with
what you wrote above... i can also write /usr/lib/qt3 instead, no
success...

> If the compilation then breaks because of missing headers like
> qptrlist.h and so on, install libqt3-compat-headers and optionally flame
> the Qt maintainer(s) for not including them in their standard Qt
> development installation.

libqt3-compat-headers is already a Build-Depends of the package.

problem status: still unsolved.

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


pgpXViVzPaJAU.pgp
Description: PGP signature

Re: failing to compile a KDE package

[Ben Burton]

> problem status: still unsolved.

Hmm.. is it possible to post the section of config.log where the error
occurs?

b.

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

[Goswin Brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> 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.

Could the dh_undocumented programm allways fail with an error "Don't
use me" as the next step? That way all new uploads will be forced to
care.

MfG
Goswin

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

[Hamish Moffatt]

On Sat, Jul 05, 2003 at 09:01:25AM +0200, Marc Haber wrote:
> On Thu, 3 Jul 2003 17:32:29 +0200, Josip Rodin <[EMAIL PROTECTED]> wrote:
> >On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote:
> >> In the past years, I have found it annoying that the eicar anti-virus
> >> testfile is not available as aptable Debian package.
> >
> >Why is this annoying?
> 
> Because it makes debugging anti-virus software harder, and forces
> maintainers of anti-virus packages to have their own means of
> obtaining eicar.com for testing purposes

I believe we could use this argument to justify packaging everything on
the Internet. After all, why should a browser developer have to have an
internet connection for testing purposes either? etc.

ITP: google.com

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

[solved] failing to compile a KDE package

[martin f krafft]

also sprach Ben Burton <[EMAIL PROTECTED]> [2003.07.05.1629 +0200]:
> Hmm.. is it possible to post the section of config.log where the
> error occurs?

I had read this file upside down, inside out, from left to right and
right to left. I found nothing. This time I immediately spotted the
problem:

./configure: line 1: g++: command not found 
configure:21244: $? = 127 

This is, IMHO, a problem with autoconf, as it should really check
for g++ first. But whatever. It's compiling now. Thanks for making
me find the error!

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


pgpJTNuUkp0Ic.pgp
Description: PGP signature

Re: [solved] failing to compile a KDE package

[Sam Hocevar]

On Sat, Jul 05, 2003, martin f krafft wrote:
> ./configure: line 1: g++: command not found 
> configure:21244: $? = 127 
> 
> This is, IMHO, a problem with autoconf, as it should really check
> for g++ first.

   Uh, this is not a problem with autoconf. It is a problem with upstream
calling AC_CHECK_COMPILERS (which checks for all compilers) and ignoring
the results thereof.

Cheers,
-- 
Sam.

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

[Joey Hess]

Goswin Brederlow wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
> 
> > 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.
> 
> Could the dh_undocumented programm allways fail with an error "Don't
> use me" as the next step? That way all new uploads will be forced to
> care.

No. Breaking 400+ packages so our uses cannot build them from source is
unacceptable.

-- 
see shy jo


pgpDqNT8NFeuR.pgp
Description: PGP signature

Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem

[Robert Millan]

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

* Package name: e2tools
  Version : 0.0.13
  Upstream Author : Keith Sheffield <[EMAIL PROTECTED]>
* URL : http://home.earthlink.net/~k_sheff/sw/e2tools/index.html
* License : GPL
  Description : utilities for manipulating files in an ext2/ext3 filesystem

E2tools is a simple set of GPL'ed utilities to read, write, and manipulate
files in an ext2/ext3 filesystem.

* copy files: e2cp
* move files: e2mv
* remove files: e2rm
* create directory: e2mkdir
* create hard links: e2ln
* list files/directories: e2ls
* output the last part of a file: e2tail 

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux aragorn 2.2.22 #1 dl nov 25 21:59:43 CET 2002 i686
Locale: LANG=ca_ES.ISO-8859-1, LC_CTYPE=ca_ES.ISO-8859-1

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

[Andreas Barth]

* Mark Brown ([EMAIL PROTECTED]) [030705 16:05]:
> On Sat, Jul 05, 2003 at 02:56:30PM +0200, Josip Rodin wrote:

> > OK, so basically you think ftpmaster people should spend review each ITP for
> > such global rejection reasons, then? You can't expect this to happen in any
> > remotely timely fashion, at least not with this many ftpmasters and this
> > many hours in a day.
 
> Not to mention that it's still possible that a package may have a
> problem which is not obvious until the package is seen.

Nobody said that ftpmaster must see all problems from ITP. But - every
problem that is seen at ITP time saves volunteer time for more usefull
things.


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: [solved] failing to compile a KDE package

[martin f krafft]

also sprach Sam Hocevar <[EMAIL PROTECTED]> [2003.07.05.1718 +0200]:
>Uh, this is not a problem with autoconf. It is a problem with upstream
> calling AC_CHECK_COMPILERS (which checks for all compilers) and ignoring
> the results thereof.

ok. i'll have it sent upstream.

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


pgppYPF6RU4uO.pgp
Description: PGP signature

Re: [solved] failing to compile a KDE package

[Ben Burton]

> >Uh, this is not a problem with autoconf. It is a problem with upstream
> > calling AC_CHECK_COMPILERS (which checks for all compilers) and ignoring
> > the results thereof.
> 
> ok. i'll have it sent upstream.

FYI, all upstream probably needs to do is update their admin/ directory with
a fresh copy from a recent KDE release.

Ben.

Juridical prosecution

[Martin Sobek]

You place your page on address www.sobek-sobek.com unlawfully! Remove it
immediately or you risk juridical prosecution.

> Sobek-Sobek.com q analytic service q [EMAIL PROTECTED] q +420605921227
> q  Bryksova 27, 19800 Prague 9, CZ
> 
> 
<>

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

[Steve Langasek]

On Sat, Jul 05, 2003 at 01:02:13PM +0200, Marc Haber wrote:
> On Sat, 05 Jul 2003 10:14:10 +0200, Thomas Viehmann <[EMAIL PROTECTED]>
> wrote:
> >Marc Haber wrote:
> >> Because it makes debugging anti-virus software harder, and forces
> >> maintainers of anti-virus packages to have their own means of
> >> obtaining eicar.com for testing purposes
> >Debugging anti-virus software should be done by the maintainers thereof.
> >Why would a user need this?

> A local administrator could use that file to make sure that his
> security measures are properly in place.

> >Having an installer just because some organization is too lazy to provide a
> >license with a 68 bytes is plainly wrong

> These 68 bytes are very useful. So there should be a way to obtain
> them. The Debian way

Why can't you include a download script in the existing anti-virus
package that this is supposed to be useful to?  Why is saying "want the
test data?  Run 'apt-get install eicar-installer'" better than saying
"want the test data?  Run 'wget http://eicar.com/...' or "run
/usr/lib/anti-virus/eicar-download"?

-- 
Steve Langasek
postmodern programmer


pgpIR34ymOtuL.pgp
Description: PGP signature

Re: Juridical prosecution

[Josselin Mouette]

Le sam 05/07/2003 à 17:57, Martin Sobek a écrit :
> You place your page on address www.sobek-sobek.com unlawfully! Remove it
> immediately or you risk juridical prosecution.
> 
> > Sobek-Sobek.com q analytic service q [EMAIL PROTECTED] q +420605921227
> > q  Bryksova 27, 19800 Prague 9, CZ

Can you read ? This pages states :
This computer has installed the Debian GNU/Linux operating
system but has nothing to do with the Debian GNU/Linux project.
If you want to report something about this host's behavior or
domain, please contact the ISPs involved directly, not the
Debian Project. 
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Juridical prosecution

[Alexander Schmehl]

Dear Sir,


* Martin Sobek <[EMAIL PROTECTED]> [030705 17:57]:

> You place your page on address www.sobek-sobek.com unlawfully!

No we did not.


> Remove it immediately or you risk juridical prosecution.

Please take a closer look at this page, or at least read the first
paragraph:
"This is a placeholder page installed by the Debian release of the
Apache Web server package, because no home page was installed on this
host."

Your Service-Provider is using the Debian operatingsystem, and since
nobody installed an other page to serve, it is serving this default
page.

Install a new page (even an empty one would do it).


Yours sincerely
  Alexander Schmehl

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

[Mark Brown]

On Sat, Jul 05, 2003 at 05:22:33PM +0200, Andreas Barth wrote:

> Nobody said that ftpmaster must see all problems from ITP. But - every
> problem that is seen at ITP time saves volunteer time for more usefull
> things.

That actually appeared to be exactly what Marc was asking for when he
started this thread.  Frankly, the difference in this case looks more
like ftpmaster actually being able to look at the package rather than
the ITP alone.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Woody KDE 3 packages

[Shaun Jackman]

I'm using the following APT line
deb http://download.kde.org/stable/3.1.2/Debian stable main

When I update, the Release file is ignored by apt-get. Why is this? 
Also, I can't seem to upgrade or install the new packages. What have 
I done wrong here?

Thanks,
Shaun


# apt-get update
Hit http://download.kde.org woody/main Packages
Ign http://download.kde.org woody/main Release
Reading Package Lists... Done
Building Dependency Tree... Done
# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
0 packages upgraded, 0 newly installed, 0 to remove and 0  not 
upgraded.
# apt-get install kdebase kdm
Reading Package Lists... Done
Building Dependency Tree... Done
Sorry, kdebase is already the newest version.
Sorry, kdm is already the newest version.
0 packages upgraded, 0 newly installed, 0 to remove and 0  not 
upgraded.

Re: Woody KDE 3 packages

[Tobias Wolter]

On 2003-07-05T11:36:31-0600 (Saturday), Shaun Jackman wrote:

> Also, I can't seem to upgrade or install the new packages. What have 
> I done wrong here?

Blind shot:

$ apt-cache policy
$ man apt_preferences

And doesn't this question belong to users?

-towo
-- 
`But When I Am Off Duty I Will Gladly Dispute With The Priest of The Most Wor-
thy God.'
[...] Behind him, on the bridge, a fight was breaking out.
- Terry Pratchett in «Feet of Clay»


pgpvkg7BqkXPg.pgp
Description: PGP signature

gcc on a biarch system

[Bart Trojanowski]

On amd64, we currently have a biarch-gcc that builds 32bit binaries by
default, and 64bit ones with a -m64 option.  Coding debian/rules for this
is pretty trivial but still requires some ugly architecture specific
hacks in each debian/rules.

These hacks can be troublesome if the default compile target is ever
changed (ie to 64bit, which may make more sense on most amd64 systems).
Currently I emulate this mode using a modified version of Arnd
Bergmann's /usr/bin/gcc script that injects -m64 before calling
/use/bin/gcc-3.3.

I propose obtaining the gcc specific options from a dpkg-libinfo
(introduced by Gerhard Tonn's lib64 patches) or dpkg-architecture.
debian/rules can query for said options, and use them in order to build
for a given host architecture.

Perhaps a better solution would be to have a dpkg-compiler that can
answer the following questions given an architecture name:

dpkg-compiler -a${DEB_HOST_ARCH} -qCC
dpkg-compiler -a${DEB_HOST_ARCH} -qCXX
 - return the compiler to use to compile code for ${DEB_HOST_ARCH}
 - normally this would be gcc and g++, respectively, but could also be
   x86_64-linux-gcc for cross builds

dpkg-compiler -a${DEB_HOST_ARCH} -qCFLAGS
dpkg-compiler -a${DEB_HOST_ARCH} -qCXXFLAGS
 - return the CFLAGS and CXXFLAGS required for building for ${DEB_HOST_ARCH}

I am guessing that some of this stuff would be obtained from gcc or can
be retrieved from an /etc/*.conf file.

Thoughts?

Bart.

-- 
WebSig: http://www.jukie.net/~bart/sig/


pgpS2OPB4h4Ix.pgp
Description: PGP signature

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

[Bernd Eckenfels]

On Sat, Jul 05, 2003 at 10:14:10AM +0200, Thomas Viehmann wrote:
> Debugging anti-virus software should be done by the maintainers thereof.
> Why would a user need this?

i used it many times, for example to find out which archives are checked and
which not. In fact I even already wrote bugs for AV scan software because it
did not recognized eicar signature inside archives, which where announced.
#155485 is such an example.

Thomas, actually I wonder if you talk about Linux or Debian, or if you
confuse this with commercial windows packages, which can only be debugged by
their vendor.

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: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Bernd Eckenfels]

On Sat, Jul 05, 2003 at 02:56:30PM +0200, Josip Rodin wrote:
> OK, so basically you think ftpmaster people should spend review each ITP for
> such global rejection reasons, then? You can't expect this to happen in any
> remotely timely fashion, at least not with this many ftpmasters and this
> many hours in a day.

Personally I would prefer not to reviewe the packages at all. We have a well
established and accepted bug and itp process for that. 

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: 469 packages still using dh_undocumented, check if one is yours

[Bernd Eckenfels]

On Sat, Jul 05, 2003 at 04:43:56PM +0200, Goswin Brederlow wrote:
> Could the dh_undocumented programm allways fail with an error "Don't
> use me" as the next step? That way all new uploads will be forced to
> care.

this will still create fail to build bugs for no good reason.

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: gcc on a biarch system

[Michael Banck]

On Sat, Jul 05, 2003 at 01:44:31PM -0400, Bart Trojanowski wrote:
> I propose obtaining the gcc specific options from a dpkg-libinfo
> (introduced by Gerhard Tonn's lib64 patches) or dpkg-architecture.
> debian/rules can query for said options, and use them in order to build
> for a given host architecture.

This does not only relate to library packages, right? How are you going
to get these changes into perhaps 80% of all debian/rules before 2020?

I think this should be avoided, if possible.


Michael

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

[Yven Johannes Leist]

On Saturday 05 July 2003 09:26, Marc Haber wrote:
> On Sat, 5 Jul 2003 03:01:14 +0200, Yven Johannes Leist
>
> <[EMAIL PROTECTED]> wrote:
> >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.
>
> How would you react if somebody called work you did and that took a
> few hours "silly"? And Mr. Troup's appreciation of my work is
> appropriately named in the directory name the package sits in at the
> moment.

Well, I wouldn't exactly call this nice either, but very often working on free 
software isn't "nice" in that sense. Compared to Linus, who will happily tell 
you that he doesn't care about hurt feelings at all and officially endorses 
public humiliation in order to "shame people into fixing their stuff", 
ftp-master seems almost meek, I'd say. 

In the kernel case often not just hours or days, but months or even years of 
work have been simply thrown away; just see the story of the new kbuild 
system or the ide layer in 2.5 for instance.

Hence, for something roughly equivalent to the kbuild case, imagine yourself 
creating at least a dozen heavily complex packages, putting lots of efforts 
into maintaining them in your private repository while trying to convince 
people for months on debian-devel why these packages are actually useful and 
needed and many people strongly agreeing with that sentiment and *then* 
ftp-master coming along, simply rejecting them and maybe not even telling you 
why exactly they won't accept your packages, and to make matters even worse 
not even having ever told you that they would never except them anyway. 
Put into such a perspective I think you'll understand why I find ftp-master 
meek in comparison.

> >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... ;-)
>
> Actually, I get madder the longer I think about it.

Hmm, you obviously need a different strategy then... ;-)

Cheers,
Yven

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

Bug#200163: ITP: png2ico -- command-line PNG to ICO converter

[martin f krafft]

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

* Package name: png2ico
  Version : 20021208
  Upstream Author : Matthias Benkmann <[EMAIL PROTECTED]>
* URL : http://www.winterdrache.de/freeware/png2ico/
* License : GPL
  Description : command-line PNG to ICO converter

Converts PNG files to Windows icon resource files. If you're looking
for a program to create a favicon.ico for your website, look no
further. If you need instructions or don't even know what a favicon
is, check out my short tutorial on how to create and install
a favicon.ico.

The program is extremely simple to use. To create a favicon.ico that
contains a logo in the resolutions 16x16 and 32x32 (an icon can
contain multiple images of different sizes, but a single 16x16 image
is enough for a favicon), you would use a command like the
following:

 png2ico favicon.ico logo16x16.png logo32x32.png

Package is ready for upload:

  http://people.debian.org/~madduck/stage/pool/png2ico/

Thanks,

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux piper 2.4.20-grsec+freeswan+preempt-piper #1 Sat Apr 5 11:16:59 
CEST 2003 i686
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=de_DE.ISO-8859-15


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


pgpNoxy09DTW7.pgp
Description: PGP signature

Re: gcc on a biarch system

[Ben Collins]

On Sat, Jul 05, 2003 at 01:44:31PM -0400, Bart Trojanowski wrote:
> On amd64, we currently have a biarch-gcc that builds 32bit binaries by
> default, and 64bit ones with a -m64 option.  Coding debian/rules for this
> is pretty trivial but still requires some ugly architecture specific
> hacks in each debian/rules.

Welcome to sparc64's world. This issue may never get resolved. Sparc64
had to deal with it, then ia64. We've never been able to come up with a
decent situation that's supported by dpkg and tools.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

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

[Goswin Brederlow]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> On Sat, Jul 05, 2003 at 04:43:56PM +0200, Goswin Brederlow wrote:
> > Could the dh_undocumented programm allways fail with an error "Don't
> > use me" as the next step? That way all new uploads will be forced to
> > care.
> 
> this will still create fail to build bugs for no good reason.

Some sort of "Hey you, your doing something wrong but I will let is
pass this time" feedback from autobuilder would be nice together with
keeping such nearly broken packages out of testing (to give some
incentive for mainatiner to fix the problem).

But that probably goes too far.

MfG
Goswin

Re: Debconf or not debconf : Conclusion

[Steve Langasek]

On Sat, Jul 05, 2003 at 08:46:00AM -0400, Theodore Ts'o wrote:
> On Sat, Jul 05, 2003 at 05:05:01PM +1000, Anthony Towns wrote:
> > The point of decoupling installation and configuration is to let the admin
> > choose which of these scenarios happen, instead of the distribution or
> > the maintainer. The first is appropriate if you're doing installs of many
> > systems (work out how you want it to look, then slam it onto all of them
> > automatically), the second if you're doing an upgrade from aptitude, and
> > the third if you've blatted a standard install from a magazine cover-CD
> > and need to do some final configuration.

> Yet another reasons for wanting to decouple installation and
> configuration is if some hardware company (such as VA^H^H Emperor
> Linux) wishes to ship Debian pre-installed on the system.  In that
> case, installation happens at the factory, and not when the user
> receives it in his/her hot little hands.

Given the number of config questions today that have to do with
available hardware, I have a hard time believing that a strict split
between installation and configuration tasks really addresses the needs
of such vendors.  It also seems that all of the above are achievable
within the framework debconf currently provides -- or is this about how
the default user interface to debconf should be arranged?

-- 
Steve Langasek
postmodern programmer


pgpHkTeInZQsw.pgp
Description: PGP signature

Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

Summary
~~~
Resolvconf is a proposed standard framework for updating the
system's information about currently available nameservers.

Most importantly, it manages /etc/resolv.conf , but it does 
a bit more than that.

Background and rationale

During the long discussion on debian-devel about making it possible
to mount the root filesystem read-only, it was pointed out that one
of variable files standing in the way is the libc resolver
configuration file, /etc/resolv.conf .  Several programs modify this
file as network interfaces are brought up and down.  This situation
is undesirable not only because it stands in the way of a read-only
rootfs but also because it prevents the user from running more than
one configurer at a time: the second process would overwrite the
first process's changes to resolv.conf.  The latter problem could
be addressed by making configurers cooperate somehow; but this would
not meet another major need: the need to supply resolver information
to DNS cache programs such as named and dnsmasq.  Various packages
have addressed these issues, but only partially and
idiosyncratically.  Resolvconf aims to solve the problem simply and
completely.

Resolvconf
~~
/sbin/resolvconf is a short sh script which I have packaged together
with some "hook" scripts in a package also called 'resolvconf'.
Resolvconf mediates between programs that supply resolver information
(mainly interface configurers) and those that consume resolver
information (the libc resolver and DNS caches).

Please read the package README file for detailed information.
Here is a summary of how resolvconf works.

Usage
~
Interface configurers send resolver information to resolvconf in the
format of the familiar /etc/resolv.conf file.  Thus, for example,
a program that has configured interface $IFACE would do the following
after generating a resolv.conf file named 'new-resolv.conf'.

  resolvconf -a $IFACE < new-resolv.conf

This command updates the resolver information related to interface
$IFACE.  Any information previously sent for this interface is
overwritten.  On bringing the interface down, the configurer would
do the following.  

  resolvconf -d $IFACE

For another example, a proxy script for pppd could forward to
resolvconf the resolver information that is made available to
ip-up.d/ and ip-down.d/ scripts in environment variables DNS1, etc.

  echo "nameserver $DNS1" | resolvconf -a $IFACE

These are just examples.  Appropriate hook scripts are included in
the resolvconf package for ppp, dhcp3-client, pump and ifupdown
(for static inet ifaces).  Support for other configurers including
dhcpcd and laptop-net has been added to scripts belonging to those
packages.

/sbin/resolvconf stores the information sent to it and then runs the
scripts in /etc/resolvconf/update.d/ .  One of the latter generates
the libc resolver configuration file.  Another generates the options
portion of the BIND named configuration file, containing a
"forwarders" statement listing available nameserver forwarders.
(This allows named effectively to be used as a DNS cache on a system
whose network environment varies, e.g., on a laptop.)  Another
generates a list of forwarders for dnsmasq to use.  Any other program
that needs to take action when resolver information is updated could
likewise employ a script in /etc/resolvconf/update.d/ .

The generation of the resolv.conf file (actually stored at
/var/run/resolvconf/resolv.conf , to which /etc/resolv.conf is
to be symlinked) can be controlled by the admin by editing
/etc/resolvconf/update.d/libc .  Different strategies can be
implemented: e.g., one possible strategy would be to put only the most
recently provided information into resolv.conf .  The current default
strategy is to put *all* available resolver information into
resolv.conf, ordered by interface type as follows: lo, eth*, ppp* .
This strategy will need to be refined, I know, but it works for me
in its current form.

The admin can of course disable resolv.conf automagic by deleting the
/etc/resolv.conf symlink and putting a static file at that location.

Compatibility
~
When installed, resolvconf works properly with the very latest ppp
(and pppconfig), dchp3-client and dhcpcd packages without further ado:
the resolvconf package includes "hook" scripts for them which make the
appropriate /sbin/resolvconf calls.  Likewise resolvconf works
properly with the very latest dnsmasq package without further ado:
the resolvconf package includes an "update" script to generate the
list of nameservers it can use, and dnsmasq uses the latter list if it
is available.

My thanks go to the maintainers of the dhcp3-client, dhcpcd, dnsmasq,
laptop-net and pppconfig packages for their cooperation.

With some local configuration, resolvconf also works properly with
configurers pump, udhcpc and ifupdown, and DNS cache bind.  See the
HOWTO section of the README file for instructions on how to configure
th

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

[Josip Rodin]

On Sat, Jul 05, 2003 at 08:26:43PM +0200, Bernd Eckenfels wrote:
> > OK, so basically you think ftpmaster people should spend review each ITP
> > for such global rejection reasons, then? You can't expect this to happen
> > in any remotely timely fashion, at least not with this many ftpmasters
> > and this many hours in a day.
> 
> Personally I would prefer not to reviewe the packages at all. We have a well
> established and accepted bug and itp process for that. 

While that would seem to nicely do away with the problem here, for a certain
number of packages that have a minute number of users, this would do away
with the only QA test they'll have in years. And we already constantly see
lamentations on how among the thousands of packages Debian, there's a fair
bit of badly packaged fodder.

-- 
 2. That which causes joy or happiness.

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

[Colin Watson]

On Sat, Jul 05, 2003 at 08:51:27PM +0200, Goswin Brederlow wrote:
> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> > On Sat, Jul 05, 2003 at 04:43:56PM +0200, Goswin Brederlow wrote:
> > > Could the dh_undocumented programm allways fail with an error "Don't
> > > use me" as the next step? That way all new uploads will be forced to
> > > care.
> > 
> > this will still create fail to build bugs for no good reason.
> 
> Some sort of "Hey you, your doing something wrong but I will let is
> pass this time" feedback from autobuilder would be nice together with
> keeping such nearly broken packages out of testing (to give some
> incentive for mainatiner to fix the problem).

They are *not* "nearly broken". They are just out of date by a few
months. Why this urge to break compatibility? What useful purpose does
it serve?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Simon Hürlimann]

Am Samstag, 5. Juli 2003 21.51 schrieb Thomas Hood:
> Summary
> ~~~
> Resolvconf is a proposed standard framework for updating the
> system's information about currently available nameservers.
Cool, I really like this idea.

> the need to supply resolver information
> to DNS cache programs such as named and dnsmasq.
Firewalls could use this stuff too, I guess.

> Resolvconf
> ~~
> /sbin/resolvconf is a short sh script which I have packaged together
> with some "hook" scripts in a package also called 'resolvconf'.
I'd prefer update-resolv like
 update-alternatives update-initrd
 update-catalog  update-ispell-dictionary
 update-default-aspell   update-menus
 update-default-ispell   update-mime
to name just a few.

> Credit
> ~~
> The basic idea for resolvconf originally came from Emile van Bergen.
> I claim any braindamage in the implementation as my own.
Thanx to both of you:-)

Regards
Simon

Re: Why doesn't libsidplay enter testing?

[Branden Robinson]

On Fri, Jul 04, 2003 at 10:05:59AM +0200, Gerfried Fuchs wrote:
> * Colin Watson <[EMAIL PROTECTED]> [2003-07-04 00:03]:
> > 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

Dismissing people's concerns with a one-sentence reference to inapposite
information is inherently rude.

Know whereof you speak, or remain quiet.

(Or, alternatively, crack wise.  :) )

-- 
G. Branden Robinson|
Debian GNU/Linux   |   // // //  / /
[EMAIL PROTECTED] |   EI 'AANIIGOO 'AHOOT'E
http://people.debian.org/~branden/ |


pgp9gGcnESjbp.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Thu, Jul 03, 2003 at 04:13:09PM -0500, Joshua Haberman wrote:
> And I am arguing that there is no reason not to endorse RFCs just as
> we endorse license texts.  That last sentence is a personal judgement
> that I would guess many Debian developers would find agreement with.

I wouldn't.

The best way to find out how the developers feel might be with General
Resolution.  It's certainly preferable to putting words in their mouths,
as you just did.

-- 
G. Branden Robinson|
Debian GNU/Linux   | De minimis non curat lex.
[EMAIL PROTECTED] |
http://people.debian.org/~branden/ |


pgpRviPg9XhZk.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Thu, Jul 03, 2003 at 03:54:20PM -0500, Joshua Haberman wrote:
> * Branden Robinson ([EMAIL PROTECTED]) wrote:
> > On Thu, Jul 03, 2003 at 01:42:01PM -0500, Joshua Haberman wrote:
> > > I think non-free removal will seem more radical if it means that
> > > Debian will no longer distribute RFCs on the basis that their
> > > licensing is not permissive enough.
> > 
> > After years of watching and waiting, I have concluded that resolving to
> > stop shipping non-free software in our archives will be regarded as
> > "radical" no matter how great or small the practical consequences.  For
> > some people, Debian is about "apt-get install w4r3z", not about any sort
> > of principle.
> 
> Do you resent everyone for whom Debian is a tool, not a principled
> political statement?

Of course not.  Do you resent the first clause of the Social Contract,
which could easily be characterized as a principled political statement?

> > > RFCs are the end product of a community process that represents
> > > everything Debian stands for.
> > 
> > Really?  What exactly does Debian stand for, then?  And what does the
> > IETF's process represent?
> 
> 1. Transparency.  Debian carries out discourse in private only under
> compelling circumstances.  Likewise IETF working groups work over public
> mailing lists and publish drafts of all their work for the public to
> review.
> 
> 2. Community involvement.  It doesn't take a company or a membership
> fee to participate in the RFC process, which is not the case for many
> standards organizations.  Likewise, very few of Debian's processes are
> closed off from public participation.
> 
> 2.

"On the third hand..."

> Open and freely-availble standards.  Free software naturally favors
> interoperability, and the IETF has historically provided many of the
> standards that make this interoperability a reality.  The fact that these
> standards are freely available makes them more accessible to free
> software developers working without a budget, in contrast to standards
> from ANSI and ISO that cost money to obtain.

So, Debian should be committed merely to that which is freely available,
and not to that which is freely modifiable and distributable?

> Is it such a stretch to recognize that the IETF is an organization whose
> goals and procedures are reasonably aligned with Debian's?

I am unwilling to make an assertion one way or the other without
context.  I'd imagine that there are issues with respect to which Debian
and the IETF would be strongly aligned; there may be others where we are
not.

As an example of the latter, Bruce Perens, former DPL and current SPI
Board member, has come out in opposition to the IETF's patent disclosure
policy, fearing that the IETF will be co-opted by large corporate
patentholders.

Is it such a stretch to recognize that the IETF is an organization whose
goals and procedures may not always be aligned with Debian's?

> Since you seem to favor absolute precision in language,

Substantially more precision than you've managed will suffice.

> I will concede that the IETF process may not literally represent
> "everything" Debian stands for, since parts of Debian's principles lay
> outside the scope of standardization processes.

I think there is insufficient evidence for the assertion that one
project's goals are a strict subset of the other's.

> > Without foundation, your remark serves as sloganeering, perhaps
> > calculated to intimidate or silence those who are simply viewing the
> > RFCs' licenses in an objective light.
> 
> Do you always read the most malicious and manipulative motivations in
> other people's words?

I said "perhaps".  In any event, your remarks may have that effect
regardless of your intentions, so I urge you to lay stronger foundations
for your arguments

> What experiences have jaded you to the point that you cannot presume
> goodwill on the part of others, even within an organization of
> volunteers?

Another categorical statement.  You assert that I am completely unable
to presume goodwill on the part of others.  Without the benefit of
telepathy, How you could possibly know such a thing is quite beyond me.

That's known as an ad-hominem attack, which happens to be a form of
fallacious reasoning.

-- 
G. Branden Robinson|   Convictions are more dangerous
Debian GNU/Linux   |   enemies of truth than lies.
[EMAIL PROTECTED] |   -- Friedrich Nietzsche
http://people.debian.org/~branden/ |


pgpPsysnxbR6K.pgp
Description: PGP signature

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

[Artur R. Czechowski]

On Sat, Jul 05, 2003 at 11:26:44AM -0400, Joey Hess wrote:
> Goswin Brederlow wrote:
> > Could the dh_undocumented programm allways fail with an error "Don't
> > use me" as the next step? That way all new uploads will be forced to
> > care.
> No. Breaking 400+ packages so our uses cannot build them from source is
> unacceptable.
What's about dh_undocumented looking like:
--
#!/bin/bash
if [ $FORCE_UNDOCUMENTED = 1 ]; then
  echo You are still using dh_undocumented which is obsoleted.
  echo Stop it.
else
  echo You are using obsoleted dh_undocumented in your debian/rules.
  echo Please stop it and prepare a manpage for your package.
  echo If you really want to build this package read (pointer to
  documentation which explains how to set FORCE_UNDOCUMENTED or how to remove 
this from debian/rules and why using dh_undocumented is bad).
  exit 1
fi
--

Pro:
  - it is possible to build package with buildd or any other autobuilder
  - human building package can force it to build too
  - it requires an interaction from developer, but this interaction is not
time consuming

This is a good compromise between technical and social means to achieve a goal.

Regards
Artur
-- 
"#gaduly to jak wenezuelski serial. Nieważne, ile odcinków opuścisz
zawsze będziesz na czasie"
/Czesiu/


pgpIplgLvwznq.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Fri, Jul 04, 2003 at 04:35:09PM +0200, Josip Rodin wrote:
> 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

Damn.  That means some OTHER deity has been intercepting the products of
ritual slaughter on my altar...

-- 
G. Branden Robinson|Men use thought only to justify
Debian GNU/Linux   |their wrong doings, and speech only
[EMAIL PROTECTED] |to conceal their thoughts.
http://people.debian.org/~branden/ |-- Voltaire


pgpWk7UfOvcaQ.pgp
Description: PGP signature

reliable mirroring of local web tree?

[Steve M. Robbins]

Howdy,

The boost libraries have excellent documentation in HTML format.
Unfortunately, there is no "make install" equivalent to copy the files
into a nice place.  Nor is it as simple as "cp -a docs ..."  as the
files are intermixed with the source code.  But there is a top-level
"index.htm" file, so I should be able to copy all the files starting
from the index.

I have used httrack to do this in the past.  But now it appears to get
stuck in an infinite loop -- presumably something deep in the tree
links back to the initial "index.htm" in a manner that confuses
httrack into thinking it is a *different* file, and it gets copied
as "index-2.htm", then "index-3.htm", etc ...

Surely someone cleverer than me has solved this sort of problem in the
past.  How do *you* copy a web tree?  [A simple list of files is fine,
too, of course.]

Thanks,
-S

Re: gcc on a biarch system

[Arnd Bergmann]

On Saturday 05 July 2003 19:44, Bart Trojanowski wrote:
> On amd64, we currently have a biarch-gcc that builds 32bit binaries by
> default, and 64bit ones with a -m64 option.  Coding debian/rules for this
> is pretty trivial but still requires some ugly architecture specific
> hacks in each debian/rules.
> 
> I propose obtaining the gcc specific options from a dpkg-libinfo
> (introduced by Gerhard Tonn's lib64 patches) or dpkg-architecture.
> debian/rules can query for said options, and use them in order to build
> for a given host architecture.

No, that's exactly the wrong way around. dpkg-libinfo (at least the
current proposal) uses dpkg-architecture to find the target
architecture and dpkg-architecture in turn calls gcc to get that.
It makes sense this way, although dpkg-libinfo might also call gcc
directy.

There is a patch for gcc so that it calls uname(2) to find out if it 
should build 32 or 64 bit binaries. You can then use the personality
system call when you want to change to building 32 bit packages, e.g.
'do32bit fakeroot dpkg-buildpackage' (I don't know if there is
already a tool that changes the personality, but do32bit is probably
not the best name for such a tool).

Arnd <><

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Fri, Jul 04, 2003 at 02:03:11PM +0200, Florian Weimer wrote:
> 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.

I have argued on debian-legal that licenses as applied to specific works
that are part of the Debian OS (meaning, "in main") are permitted to be
non-modifiable, for the same reason that the copyright notices
themselves are permitted to be non-modifiable.  In many countries,
including the U.S., it is a criminal offence to obliterate or modify an
copyright notice such that a work's copyright becomes fraudulent.
However, a document like the GNU GPL which claims copyright and has
non-free license terms could not be distributed in main of itself.
(Yes, I know that we ship it in a way you might think is "of itself" in
base-files.  You'd be right if we didn't have other packages' copyright
files refer to /usr/share/common-licenses/GPL, but we do.)

It doesn't seem too much of a stretch (to me) to say that the same
prohibition applied to the binding terms of a license text is not
problematic, for it obviously benefits us and our users to have correct
and true license terms on the software we distribute.

If we cannot have a good-faith belief that the license terms stated on
a work are not the ones that actually apply, then we might as well get
out of the distribution business.

None of this reasoning applies to the IETF's RFCs.

-- 
G. Branden Robinson|If a man ate a pound of pasta and a
Debian GNU/Linux   |pound of antipasto, would they
[EMAIL PROTECTED] |cancel out, leaving him still
http://people.debian.org/~branden/ |hungry?  -- Scott Adams


pgpaqDT9jw3eD.pgp
Description: PGP signature

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

[Thomas Viehmann]

Andreas Barth wrote:
> * Thomas Viehmann ([EMAIL PROTECTED]) [030705 09:35]:
> 
>>Marc Haber wrote:
>>
Well that's the purpose of ITP-bugs against wnpp I think, because
they are CC'd to debian-devel for public review.
>>>Please show me a single ITP bug number where ftpmaster has said "this
>>>package will not go into the archive, I will reject it on upload".
>>There's numerous ITPs where e.g. licensing (seems to be a main issue with
>>ftpmaster) has been discussed (the last I recall is #199874 dated 2003-07-03).
> Andreas Tille, who critized the license in #199874 is according to
> http://www.debian.org/intro/organization not ftpmaster. So ...
>>If you're too cool to do proper ITPs then don't complain about the debian
>>processing for new packages not working for you.
> ... is not right.

The point is that the public review of ITPs (which is part of the process of
submitting a new package) seems cover most of the concerns that may cause
rejection by ftpmaster (which is the final part of a new packages' way to
debian). At least that's my impression of the way this is supposed to work.
What I'm saying is that basically the discussion on devel would have addressed
the limited merit alledged by ftpmaster.
Marc's complaint (or at least one of the more clear items he complained about)
was that he received ftpmasters feedback after his work is done. Had he ITPd
(properly), he might have been told before.
So why is the recommendation against skipping the ITP to aviod problems in
ftpmaster review "not right"?

Cheers

T.


pgptTkx8JCola.pgp
Description: PGP signature

Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem

[Ralf Treinen]

On Sat, Jul 05, 2003 at 05:24:21PM +0200, Robert Millan wrote:
> Package: wnpp
> Version: unavailable; reported 2003-07-05
> Severity: wishlist
> 
> * Package name: e2tools
>   Version : 0.0.13
>   Upstream Author : Keith Sheffield <[EMAIL PROTECTED]>
> * URL : http://home.earthlink.net/~k_sheff/sw/e2tools/index.html
> * License : GPL
>   Description : utilities for manipulating files in an ext2/ext3 
> filesystem
> 
> E2tools is a simple set of GPL'ed utilities to read, write, and manipulate
> files in an ext2/ext3 filesystem.

please excuse my ignorance - what would be the advantage of these
tools over the core file utilities which use the VFS layer?

-Ralf.
-- 

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Fri, Jul 04, 2003 at 03:53:55AM +0800, 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.

And I wouldn't lose any sleep if it were yanked from the Project.
However, as others have pointed out, a consistently applied policy of
removing non-documentation and non-software from Debian would take out
the text of the King James Bible, the Linux Gazette packages, and
anything that is neither human-readable nor executable, like sound
files, icons, "wallpaper" for desktop environments, and so forth.

Because it doesn't seem fruitful to tumble down that slippery slope, and
while the packaging of Linux Gazette, the King James Bible, and the
stuff in the anarchism package may conceivably be an abuse of the Debian
OS to some people, these packages do (AFAIK) meet our licensing
requirements for software.  They therefore do not require us to
compromise our principled dedication to freedom.

(They might, on the other hand, compromise our principled decision to
produce an operating system.  At the same time, Microsoft has worked
long and hard to persuade people that basically anything that comes off
the disk platters in your computer is or can be "part of the OS".
Advocates of the non-free RFCs being in main might share this view.)

-- 
G. Branden Robinson| Never attribute to malice that
Debian GNU/Linux   | which can be adequately explained
[EMAIL PROTECTED] | by stupidity.
http://people.debian.org/~branden/ |


pgpgOxzAKAFgZ.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Fri, Jul 04, 2003 at 12:53:56AM -0400, David B Harris wrote:
> Except for the title, the DFSG is very content-agnostic. It can be
> applied equally well to software, fiction, nonfiction, images, what have
> you.

I think that's a feature.  Apparently, some people think it's a bug.

-- 
G. Branden Robinson|  It doesn't matter what you are
Debian GNU/Linux   |  doing, emacs is always overkill.
[EMAIL PROTECTED] |  -- Stephen J. Carpenter
http://people.debian.org/~branden/ |


pgpgnvxuu09Te.pgp
Description: PGP signature

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

[Joey Hess]

Artur R. Czechowski wrote:
> What's about dh_undocumented looking like:
> --
> #!/bin/bash
> if [ $FORCE_UNDOCUMENTED = 1 ]; then
>   echo You are still using dh_undocumented which is obsoleted.
>   echo Stop it.
> else
>   echo You are using obsoleted dh_undocumented in your debian/rules.
>   echo Please stop it and prepare a manpage for your package.
>   echo If you really want to build this package read (pointer to
>   documentation which explains how to set FORCE_UNDOCUMENTED or how to remove 
> this from debian/rules and why using dh_undocumented is bad).
>   exit 1
> fi

Why should I put the user to all this trouble when as I stated in my
first mail to this thread, calls to the program are already being
removed at a rate that is satisfactory? Think how much more annoying
building packages would be if this practice became widespread.

Really, I am able to deal with these things on my own. If I need help I
will ask. Thank you all for your comments, but I have stopped reading
this thread now.

-- 
see shy jo


pgpgSbqKVFUdo.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Thu, Jul 03, 2003 at 05:16:07PM -0700, Brian Nelson wrote:
> 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.

/me falls into a fit of coughing

*COUGH*h
*COUGH*t
*COUGH*t
*COUGH*p
*COUGH*:
*COUGH*/
*COUGH*/
*COUGH*w
*COUGH*w
*COUGH*w
*COUGH*.
*COUGH*f
*COUGH*s
*COUGH*f
*COUGH*.
*COUGH*o
*COUGH*r
*COUGH*g
*COUGH*/

-- 
G. Branden Robinson|
Debian GNU/Linux   |   If ignorance is bliss,
[EMAIL PROTECTED] |   is omniscience hell?
http://people.debian.org/~branden/ |


pgpkP1YLoJXwZ.pgp
Description: PGP signature

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

[Thomas Viehmann]

Bernd Eckenfels wrote:
> On Sat, Jul 05, 2003 at 10:14:10AM +0200, Thomas Viehmann wrote:
> 
>>Debugging anti-virus software should be done by the maintainers thereof.
>>Why would a user need this?

> i used it many times, for example to find out which archives are checked and
> which not. In fact I even already wrote bugs for AV scan software because it
> did not recognized eicar signature inside archives, which where announced.
> #155485 is such an example.

So, how much of the debugging work was downloading the signature file?

> Thomas, actually I wonder if you talk about Linux or Debian, or if you
> confuse this with commercial windows packages, which can only be debugged by
> their vendor.

Oh, I thought the advantage of open source was that you could debug by other
means than just testing. Indeed, one could claim that the eicar test file is
needed particulary when you don't have access to the source.

Relly, I'd not make a package of single HTML document for testing browsers'
rendering of tables (or whatever), either.

Cheers

T.

P.S.: I don't need CCs.


pgpWtpDgiOpaG.pgp
Description: PGP signature

Re: Debconf or not debconf : Conclusion

[Branden Robinson]

On Fri, Jul 04, 2003 at 04:21:45PM +0200, Julien LEMOINE wrote:
> I will upload a stunnel4 package and a stunnel with Epoch tomorrow.

Excellent decision.  :)  Thank you.

-- 
G. Branden Robinson|   The key to being a Southern
Debian GNU/Linux   |   Baptist: It ain't a sin if you
[EMAIL PROTECTED] |   don't get caught.
http://people.debian.org/~branden/ |   -- Anthony Davidson


pgpBLRv5BOJyu.pgp
Description: PGP signature

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

[Thomas Viehmann]

Andreas Barth wrote:
> Marc is doing it the other way: He want an interface to reject a
> package before substantial work has been spent on it. So there
> shouldn't be this conflict any more, which would be a good thing.

Isn't this why ITPs are usually CCed to debian-devel?
Look what has been done to the email ITP, to the mplayer ITP, ...
I don't know what that "directory name" deal is, but basically I have the
feeling that ftpmaster is predicatble (in fact reasonable) enough for the public
review on -devel to anticipate decisions. No need to bother the ftpmasters with
every package where -devel or -mentors or whoever would very accurately identify
the problems it would have once it was uploaded.

Cheers

T.


pgpKkXfFPfE6y.pgp
Description: PGP signature

Debconf and XFree86 X servers

[Branden Robinson]

[Please direct any XFree86-specific followup to debian-x.]

On Sat, Jul 05, 2003 at 08:46:00AM -0400, Theodore Ts'o wrote:
> Yet another reasons for wanting to decouple installation and
> configuration is if some hardware company (such as VA^H^H Emperor
> Linux) wishes to ship Debian pre-installed on the system.  In that
> case, installation happens at the factory, and not when the user
> receives it in his/her hot little hands.

I think Debian's headed that direction.  Changes of this nature are
sometimes slow to reach maturity, though.

As an example, I've mentally committed to ditching the current
debconfage for the XFree86 X server packages in Debian, possibly
replacing it with ucf(-ish) solution.  But I haven't gotten around to
doing it yet.

It's probably safe to say that this item is on my priority list after:

* 4.3.0-0pre1v1 released to experimental
* xlibs/xbase-clients split/reorg (once settled, safe to release 4.3.0-1
  to unstable)

-- 
G. Branden Robinson|Any man who does not realize that
Debian GNU/Linux   |he is half an animal is only half a
[EMAIL PROTECTED] |man.
http://people.debian.org/~branden/ |-- Thornton Wilder


pgpzyJSUeRI5m.pgp
Description: PGP signature

Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem

[Falk Hueffner]

Ralf Treinen <[EMAIL PROTECTED]> writes:

> > E2tools is a simple set of GPL'ed utilities to read, write, and
> > manipulate files in an ext2/ext3 filesystem.
> 
> please excuse my ignorance - what would be the advantage of these
> tools over the core file utilities which use the VFS layer?

You don't need root. Useful for example to build rescue floppy images.

-- 
Falk

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

[Branden Robinson]

On Sat, Jul 05, 2003 at 05:22:33PM +0200, Andreas Barth wrote:
> * Mark Brown ([EMAIL PROTECTED]) [030705 16:05]:
> > On Sat, Jul 05, 2003 at 02:56:30PM +0200, Josip Rodin wrote:
> 
> > > OK, so basically you think ftpmaster people should spend review each ITP 
> > > for
> > > such global rejection reasons, then? You can't expect this to happen in 
> > > any
> > > remotely timely fashion, at least not with this many ftpmasters and this
> > > many hours in a day.
>  
> > Not to mention that it's still possible that a package may have a
> > problem which is not obvious until the package is seen.
> 
> Nobody said that ftpmaster must see all problems from ITP. But - every
> problem that is seen at ITP time saves volunteer time for more usefull
> things.

There's no reason an entirely different team of people couldn't do this.

The FTP admins occasionally solicit the debian-legal list's opinions on
particularly thorny or obnoxious license issues, and I have been
personally consulted from time to time as well.

So I'd say there's some precedent for this, and I'm not personally in
favor of heaping still more work on the FTP admins' plate.  I think
they'll be more inclined to handle their existing responsibilities in
the more transparent manner called for by some developers if the scope
of their duties doesn't expand.

-- 
G. Branden Robinson| Communism is just one step on the
Debian GNU/Linux   | long road from capitalism to
[EMAIL PROTECTED] | capitalism.
http://people.debian.org/~branden/ | -- Russian saying


pgpIm8WDIPscR.pgp
Description: PGP signature

A success story with apt and rsync

[Koblinger Egmont]

Hi,

>From time to time the question arises on different forums whether it is
possible to efficiently use rsync with apt-get. Recently there has been a
thread here on debian-devel and it was also mentioned in Debian Weekly News
June 24th, 2003. However, I only saw different small parts of a huge and
complex problem set discussed at different places, I haven't find an
overview of the whole situation anywhere.

Being one of the developers of the Hungarian distribution ``UHU-Linux'' I
spent some time in the last few days by collecting as much information as
possible, putting the patches together and coding a little bit to fill some
minor gaps. Here I'd like to summarize and share all my experiences.

Our distribution uses dpkg/apt for package management. We are not Debian
based though, even our build procedure which leads to deb packages is
completely different from Debian's, except for the last step (which is
obviously a ``dpkg-deb --build'').

Some of our resources are quite tight. This is especially true for the
bandwidth of the home machines of the developers and testers. Most of us
live behind a 384kbit/s ADSL line. From time to time we rebuild all our
packages to see if they still compile with our current packages. Such a full
rebuild produces 1.5GB of new packages, all with a new filename since the
release numbers are automatically bumped. Our goal was to reach that an
upgrade after such a full rebuild requires only a reasonable amount of
network traffic instead of one and a half gigabytes. Before telling how we
succeeded in it I'd like to demonstrate the result.


One of my favorite games is quadra. The size of the package is nearly 3MB.
I've purged it from my system and then performed an ``apt-get install
quadra''. Apt-get printed this, amongst others:

Get:1 rsync://rsync.uhulinux.hu ./ quadra 1.1.8-2.8 [2931kB]
Fetched 2931kB in 59s (49,0kB/s)

The download speed and time corresponds to the 384kbit/s bandwidth.

I recompiled the package on the server. Then I typed ``apt-get update''
followed by ``apt-get install quadra'' again. This time apt-get printed
this:

Get:1 rsync://rsync.uhulinux.hu ./ quadra 1.1.8-2.9 [2931kB]
Fetched 2931kB in 3s (788kB/s)

Yes, downloading only took three seconds instead of one minute. Obviously
these two files do not only differ in their filename, they contain their
release number, timestamps of files and perhaps other pieces of data which
make them different. Needless to say that a small change in the package
would only slightly increase the download time.

Speedup is usually approx. 2x--3x for packages containing lots of small
files, but can be extremely high for packages containing bigger files.


The rest of my mail tells the implementation details.


rsyncable gzip files


A small change in a file causes their gzipped version to get out of sync and
hence rsync doesn't see any common parts in them. There's a patch by Rusty
Russell floating around on the net which adds an --rsyncable option to gzip.
It is already included in Debian. This way gzipped files have
synchronization points making rsync's job much easier. The patch is
available (amongst others) at [1a] and [1b].

The documentation in the original patch says ``This reduces compression by
about 1 percent most cases''. Debian's version says ``This increases size by
less than 1 percent most cases''. Size increasement was 0.7% for all our
packages, but 1.2% for our most important packages (the core distrib in
about 300--400MB).

This 1% is very low if you think of it as 1%. If you think of it as you lose
6MB on every CD, then, well, it could have been smaller. But if you think of
what you gain with it, then it is definitely worth it.

The same patch also exists for zlib (see [2a] or [2b]). However as for gzip
you can control this behaviour with a command line option, it is not so
trivial to do it with a library. The official patch disables rsyncable
support by default. You can enable it by changing "zlib_rsync = 0" to
"zlib_rsync = 1" within zlib's source or you can control it from your
running application. As I didn't like these approaches, I added a small
patch so that setting the ZLIB_RSYNC environment variable turns on the
rsyncable support. This patch is at [3].

As dpkg seems to statically link against zlib, we had to recompile dpkg
after installing this patched zlib. After this we changed our build script
so that it invokes ``dpkg-deb --build'' with the ZLIB_RSYNC environment
variable set to some value.


order of files
--

dpkg-deb puts the files in the .deb package in random order. I hate this
misfeature since it's hard to eye-grep anything from ``dpkg -L'' or F3 in
mc. We run ``dpkg-deb --build'' using the sortdir library ([4a], [4b]) which
makes the files appear in the package in alphabetical order. I don't know
how efficient rsync is if you split a file to some dozens or even hundreds
of parts and shuffle them, and then syncronize this one with the original
version. An

Re: NEWS.Debian support is here

[Branden Robinson]

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).

Kick ASS.

Thanks, guys.

-- 
G. Branden Robinson|
Debian GNU/Linux   |Yeah, that's what Jesus would do.
[EMAIL PROTECTED] |Jesus would bomb Afghanistan. Yeah.
http://people.debian.org/~branden/ |


pgpqmvGIj3teO.pgp
Description: PGP signature

Re: The nature of testing and where can others help (Was Re: HowTo for Gnome2??)

[Bruce Sass]

Hi,

I accidentally deleted all the messages in my debian-user folder
.  However, I do remember enough of your original post to
(hopefully) enlighten you.  I have also done the nasty cross-post
thing to -devel because I conclude with a thought on how to get the
package pool living up to its potential.


There is no way to show anyone what the next Debian will look like
until it is released .
^^^
You can see which packages are being worked on for inclusion in the
next release (those in unstable), but until the release is made there
is no way to tell if a package will get enough of its known bugs fixed
to be included.  Even a package being in testing when a freeze comes
along does not provide enough information with which to make that
determination.

Debian unstable, testing, and stable archives are not development,
pre-release, and released archives... until a freeze comes along.

Maybe this will help...

Flow of new software into Debian's archives:

1 23
   ---   ---  ---
 N)  upstream+ ---> unstable ---> testing  stable

 F)  upstream+ ---> unstable  testing  stable

 R)  upstream+ ---> unstable  testing ---> stable

1, 2, and 3 represent the movement of packages; N, F, and R indicate
Debian's "normal", "in a freeze", and "release" modes of operation;
upstream+ represents the original source plus modifications made by a
Debian developer; unstable, testing and stable are Debian archives.

1 can happen at any time and is controlled by the autobuilder; 2 can
only happen between freezes and is controlled by the bug tracking
system (BTS); 3 is a manually triggered operation whose timing is
determined with input from the BTS and developers.


To put it into perspective... once (only one or two releases ago)
there was just unstable and stable, testing only existed during a
freeze.  Release cycles were too long and developers didn't like
having to put development of new software on hold when a freeze came
along, so they decided to do away with separate archives and move to a
"package pool" system -- all packages actually exist in a common pool
and specific versions are flagged as being included in one or more
virtual archives.  The idea being that developers could continue to
develop at their own pace and relatively stable packages would
automatically accumulate in testing, at some point testing would look
good enough to freeze and then release as the current stable.


Speculation/opinion:

Why is testing in such bad shape...

It seems to be the case that developers are moving packages through
unstable too fast for testing to reach a point where it looks good
enough to freeze and polish into a release.

What could be done to fix the situation...

Create a permanent "frozen" archive, fed from a consistent set of
packages in testing which have been flagged as release candidates.
By "set of packages" I mean all the packages which make up, for
example, Gnome or Gnome2 or KDE2 or KDE3, etc.  If only one version of
a set is allowed to be a release candidate at any point during a
release cycle, and only packages which have achieved stability are
allowed to move into the frozen archive... "testing+frozen" will
quickly become what users want "testing" to be (a peek at the next
Debian), and the release manager only needs to look at the quantity of
packages in frozen to determine if it is time (are all or enough of
the release candidates here?).


Useful Debian systems with the existence of a "frozen" archive...
(where your sources.list lines point to)

unstableDevelopers developing and users who don't mind
bleeding from time to time.

testing/unstableUsers who don't mind getting hurt as long as
first aid is likely to be available.

testing Crazy people, this could contain (for example)
Gnome, Gnome2, KDE2 and KDE3, all at the same
time!  Basically a holding area for packages
transitioning from development to pre-release.

frozen/testing  Developers polishing and users wanting a peek
at the next release.

frozen  Anyone interested in how far along the next
release has progressed.  Stable quality, but
not a complete distribution.

stable  most users


Flow of new software within a Debian with a "frozen" archive:

| --- development ---|--- pre-release ---|- released -|
|   phase|  phase||
 unstable --> testing -> frozen ---> stable, archived
1   23

0 - (not shown) flow into unstable, controlled by the autobuilder
1 - controlled by the BTS
2 - BTS (tighter restrictions than 1) and developer input via a
release candidate flag
3 - BTS and release manager (who c

Re: Please remove RFCs from the documentation in Debian packages

[Florian Weimer]

Branden Robinson <[EMAIL PROTECTED]> writes:

>> 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.
>
> I have argued on debian-legal that licenses as applied to specific works
> that are part of the Debian OS (meaning, "in main") are permitted to be
> non-modifiable, for the same reason that the copyright notices
> themselves are permitted to be non-modifiable.

This is a strawman, about one third of the GPL is not the actual
permission notice, and these parts already required updates.

> (Yes, I know that we ship it in a way you might think is "of itself" in
> base-files.  You'd be right if we didn't have other packages' copyright
> files refer to /usr/share/common-licenses/GPL, but we do.)

Does this take into account that there are multiple versions of the
GPL v2 floating around which aren't bit-wise identical?  (I'm just
curious, I don't think it really makes a difference as these changes
are not part of the permission notice.)

Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem

[Josip Rodin]

On Sat, Jul 05, 2003 at 11:57:35PM +0200, Falk Hueffner wrote:
> > > E2tools is a simple set of GPL'ed utilities to read, write, and
> > > manipulate files in an ext2/ext3 filesystem.
> > 
> > please excuse my ignorance - what would be the advantage of these
> > tools over the core file utilities which use the VFS layer?
> 
> You don't need root. Useful for example to build rescue floppy images.

Could this be better explicated? Preferably in the package description?

-- 
 2. That which causes joy or happiness.

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Goswin Brederlow]

Thomas Hood <[EMAIL PROTECTED]> writes:

> Summary
> ~~~
> Resolvconf is a proposed standard framework for updating the
> system's information about currently available nameservers.
> 
> Most importantly, it manages /etc/resolv.conf , but it does 
> a bit more than that.

You should think of a mechanism for daemons to get notified about
changes in resolv.conf. Like providing a function to register a script
and a list of arguments (like the PID of the program to
notify). Whenever the resolv.conf changes all currently registered
scripts would be called with their respective arguments.

The simplest form would be:

resolv.conf-register /etc/init.d/squid reload

That would make squid to reload its config each time a nameserver is
added or removed.

MfG,
Goswin

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

[Goswin Brederlow]

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

> On Sat, Jul 05, 2003 at 11:26:44AM -0400, Joey Hess wrote:
> > Goswin Brederlow wrote:
> > > Could the dh_undocumented programm allways fail with an error "Don't
> > > use me" as the next step? That way all new uploads will be forced to
> > > care.
> > No. Breaking 400+ packages so our uses cannot build them from source is
> > unacceptable.
> What's about dh_undocumented looking like:
> --
> #!/bin/bash
> if [ $FORCE_UNDOCUMENTED = 1 ]; then
>   echo You are still using dh_undocumented which is obsoleted.
>   echo Stop it.
> else
>   echo You are using obsoleted dh_undocumented in your debian/rules.
>   echo Please stop it and prepare a manpage for your package.
>   echo If you really want to build this package read (pointer to
>   documentation which explains how to set FORCE_UNDOCUMENTED or how to remove 
> this from debian/rules and why using dh_undocumented is bad).
>   exit 1
> fi
> --
> 
> Pro:
>   - it is possible to build package with buildd or any other autobuilder
>   - human building package can force it to build too
>   - it requires an interaction from developer, but this interaction is not
> time consuming
> 
> This is a good compromise between technical and social means to achieve a 
> goal.

I would have reversed it. Use "$FAIL_UNDOCUMENTED" and have
autobuilders set that.

Unknowing users aren't bothered, old sources still compile but new
uploads are forced to handle the issue.

But Joey stoped reading this so nothing will happen. EOD.

MfG
Goswin

Re: Debconf and XFree86 X servers

[Goswin Brederlow]

Branden Robinson <[EMAIL PROTECTED]> writes:

> [Please direct any XFree86-specific followup to debian-x.]
> 
> On Sat, Jul 05, 2003 at 08:46:00AM -0400, Theodore Ts'o wrote:
> > Yet another reasons for wanting to decouple installation and
> > configuration is if some hardware company (such as VA^H^H Emperor
> > Linux) wishes to ship Debian pre-installed on the system.  In that
> > case, installation happens at the factory, and not when the user
> > receives it in his/her hot little hands.

So they should just provide a "setup.sh" script that calls
dpkg-reconfigure for relevant packages again.

Otherwise just type in "dpkg-reconfigure --all" and spend hours
configuring your system as much as you like.

MfG
Goswin

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Sun, Jul 06, 2003 at 12:33:52AM +0200, Florian Weimer wrote:
> Branden Robinson <[EMAIL PROTECTED]> writes:
> 
> >> 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.
> >
> > I have argued on debian-legal that licenses as applied to specific works
> > that are part of the Debian OS (meaning, "in main") are permitted to be
> > non-modifiable, for the same reason that the copyright notices
> > themselves are permitted to be non-modifiable.
> 
> This is a strawman,

Bullshit.  Do you even know what a straw man argument is?  Whose
position am I distorting in the text you quoted?  My own?

> about one third of the GPL is not the actual permission notice,

Yeah.  So what?

> and these parts already required updates.

What, such as the mailing address of the FSF?  Is this a big deal?

> > (Yes, I know that we ship it in a way you might think is "of itself" in
> > base-files.  You'd be right if we didn't have other packages' copyright
> > files refer to /usr/share/common-licenses/GPL, but we do.)
> 
> Does this take into account that there are multiple versions of the
> GPL v2 floating around which aren't bit-wise identical?  (I'm just
> curious, I don't think it really makes a difference as these changes
> are not part of the permission notice.)

I think you answered your own question.

-- 
G. Branden Robinson|
Debian GNU/Linux   |   If existence exists,
[EMAIL PROTECTED] |   why create a creator?
http://people.debian.org/~branden/ |


pgpgwYyyyx0ng.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Colin Walters]

On Sat, 2003-07-05 at 17:22, Branden Robinson wrote:
> On Fri, Jul 04, 2003 at 04:35:09PM +0200, Josip Rodin wrote:
> > 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
> 
> Damn.  That means some OTHER deity has been intercepting the products of
> ritual slaughter on my altar...

*burp*

Re: A success story with apt and rsync

[Andrew Suffield]

On Sat, Jul 05, 2003 at 11:56:41PM +0200, Koblinger Egmont wrote:
> order of files
> 
> dpkg-deb puts the files in the .deb package in random order. I hate this
> misfeature since it's hard to eye-grep anything from ``dpkg -L'' or F3 in
> mc. We run ``dpkg-deb --build'' using the sortdir library ([4a], [4b]) which
> makes the files appear in the package in alphabetical order. I don't know
> how efficient rsync is if you split a file to some dozens or even hundreds
> of parts and shuffle them, and then syncronize this one with the original
> version. Anyway, I'm sure that sorting the files cannot hurt rsync, it can
> only help. I only guess that it really does help a lot.

It should put them in the package in the order they came from
readdir(), which will depend on the filesystem. This is normally the
order in which they were created, and should not vary when
rebuilding. As such, sorting the list probably doesn't change the
network traffic, but will slow dpkg-deb down on packages with large
directories in them.

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


pgpnwSkhK58UF.pgp
Description: PGP signature

Re: A success story with apt and rsync

[Goswin Brederlow]

Koblinger Egmont <[EMAIL PROTECTED]> writes:

> Hi,
> 
> >From time to time the question arises on different forums whether it is
> possible to efficiently use rsync with apt-get. Recently there has been a
> thread here on debian-devel and it was also mentioned in Debian Weekly News
> June 24th, 2003. However, I only saw different small parts of a huge and
> complex problem set discussed at different places, I haven't find an
> overview of the whole situation anywhere.
...

I worked on an rsync patch for apt-get some years ago and raised some
design questions, some the same as you did in the deleted parts. Lets
summarize what I still remember:

1. debs are gziped so any change (even change in time) results in a
different gzip. The rsyncable patch for gzip helps a lot there. So
lets consider that fixed.

2. most of the time you have no old file to rsync against. Only
mirrors will have an old file and they already use rsync.

3. rsyncing against the previous version is only possible via some
dirty hack as apt module. apt would have to be changed to provide
modules access to its cache structure or at least pass any previous
version as argument. Some mirror scripts alreday use older versions as
templaes for new versions.

4. (and this is the knockout) rsync support for apt-get is NO
WANTED. rsync uses too much resources (cpu and more relevant IO) on
the server side and a widespread use of rsync for apt-get would choke
the rsync mirrors and do more harm than good.

> conclusion
> --
> 
> The good news is that it is working perfectly.
> 
> The bad news is that you can't hack it on your home computer as long as your
> distribution doesn't provide rsync-friendly packages. Maybe one could set up
> a public rsync server with high bandwidth that keeps syncing the official
> packages and repacks them with rsync-friendly gzip/zlib and sorting the
> files.

There is a growing lobby to use gzip --rsyncable for debian packages
per default. Its coming.


So what can be done?


Doogie is thinking about extending the Bittorrent protocol for use as
apt-get method. I talked with him on irc about some design ideas and
so far it looks realy good if he can get some mirrors to host it.

The bittorrent protocol organises multiple downloaders so that they
also upload to each other and thereby reduces the traffic on the main
server. The extension of the protocol should also utilise http/ftp
mirrors as sources for the files thereby spreading the load over
multiple servers evenly.

Bittorrent calculates a hash for each block of a file very similar to
what rsync needs to work. Via another small extension rolling
checksums for each block could be included in the protocol and a
client side rsync can be done. (I heard this variant of rsync would be
patented in US but never saw real proof of it.)


All together I think a extended bittorrent module for apt-get is by
far the better sollution but it will take some more time and designing
before it can be implemented.

MfG
Goswin