Re: [Debian-au] Debian 10th birthday gear

[Branden Robinson]

Anybody else get a bad cryptographic signature on the message to which I
am replying?

-- 
G. Branden Robinson|  The noble soul has reverence for
Debian GNU/Linux   |  itself.
[EMAIL PROTECTED] |  -- Friedrich Nietzsche
http://people.debian.org/~branden/ |


pgpvkss3uHj1E.pgp
Description: PGP signature

Re: Work-needing packages report for Jul 11, 2003

[Branden Robinson]

On Sat, Jul 12, 2003 at 11:20:57AM -0600, Jamin W. Collins wrote:
> So, who does DAM report to?

In actual fact, no one in particular.

>  Who can do something about this extremely long wait?

Theoretically, the DPL.

-- 
G. Branden Robinson|  "To be is to do"   -- Plato
Debian GNU/Linux   |  "To do is to be"   -- Aristotle
[EMAIL PROTECTED] |  "Do be do be do"   -- Sinatra
http://people.debian.org/~branden/ |


pgpM1H9ELDFJn.pgp
Description: PGP signature

Re: FWD: Bug#200905: dh_installdocs: don't install empty doc files

[Branden Robinson]

On Sat, Jul 12, 2003 at 09:13:06AM -0500, Graham Wilson wrote:
> On Fri, Jul 11, 2003 at 08:07:40PM -0400, Joey Hess wrote:
> > This strikes me as a good idea, unless someone has a legit reason to
> > include an empty documentations file in a package. So speak up if you
> > do. Maybe a zero length TODO could be considered to have some implied
> > meaning,
> 
> in my mind, it probably has the same meaning as no TODO file at all, so
> adding this feature would be good.

Seconded.

-- 
G. Branden Robinson| Men are born ignorant, not stupid.
Debian GNU/Linux   | They are made stupid by education.
[EMAIL PROTECTED] | -- Bertrand Russell
http://people.debian.org/~branden/ |


pgpklagpawpyh.pgp
Description: PGP signature

Re: Qt3 still broken (compat-headers), what to do?

[Branden Robinson]

On Sat, Jul 12, 2003 at 11:51:18PM -0500, Steve Langasek wrote:
> On Sun, Jul 13, 2003 at 01:51:07PM +1000, Ben Burton wrote:
> 
> > It seems then that our options are as follows.
> 
> > (i) Wait for the Qt maintainers to upload a fix.
> > (ii) Do an NMU for Qt, despite the fact that this bug is not 
> > release-critical.
> > (iii) Resort to the technical committee.
> > (iv) Keep the package split and release sarge with a broken Qt development 
> > environment.
[...]
> Though I certainly agree that the current packages are gratuitously
> broken, an NMU without the consent of the maintainer seems almost
> certain to turn into a pissing contest.  Since (i) hasn't gotten
> anywhere in four months, I would suggest that (iii) is the way to go
> here:  this is precisely the sort of case I think the technical ctte. is
> for.

Bah, the Technical Committee takes months, sometimes over a year, to do
something even as seemingly uncontroversial as voting in opposition to
whichever solution Branden Robinson proposes.  (Don't believe me?  Read
the debian-ctte archives.)

To punt this to the Technical Committee is to stall a solution for
potentially a very long time.

If you're certain you're right, and you can get the NMU correct, the
only people who will complain will be the package maintainers.

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


pgpGAheUueheq.pgp
Description: PGP signature

Re: Qt3 still broken (compat-headers), what to do?

[Steve Langasek]

On Sun, Jul 13, 2003 at 12:14:52AM -0500, Branden Robinson wrote:

> To punt this to the Technical Committee is to stall a solution for
> potentially a very long time.

> If you're certain you're right, and you can get the NMU correct, the
> only people who will complain will be the package maintainers.

And given that they're the ones who'll be uploading the package again
once the NMU is done and can easily revert the change, NMUing against
the wishes of the maintainers and without the support of a higher
authority doesn't seem overly productive either.

I suppose there's always the option of NMUing, and hoping it sticks --
then taking it up with the tech ctte. if it doesn't...

-- 
Steve Langasek
postmodern programmer


pgp181EPynCL2.pgp
Description: PGP signature

Re: Qt3 still broken (compat-headers), what to do?

[Ben Burton]

> I suppose there's always the option of NMUing, and hoping it sticks --
> then taking it up with the tech ctte. if it doesn't...

This is more or less what I was thinking of.  The impression I get is
that the Qt maintainers have shifted their stances on this issue from
defense to apathy.  Though it's possible that this is just because
apathy is an easier way to keep the package split until somebody does
an NMU or calls in the technical committee.

Ben.

Re: Deconf and shared questions

[Manoj Srivastava]

On Sat, 12 Jul 2003 12:40:06 -0500, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Fri, Jul 11, 2003 at 01:20:12AM -0500, Manoj Srivastava wrote:
>> Given that the check is done before asking any question in the
>> postinst, if you do install all three of the packages, the first
>> one whose postinst runs shall ask the question, and create the
>> file; subsequently, the other packages won't ask the question,
>> since the file /etc/news/organization shall exist. So the user is
>> only asked once.

>> Now, if all these packages use debconf, and they all preconfigure,
>> then when the preconfiguration is run, the file does not exist --
>> and thus all the packages in question shall query the user --
>> bombarding the installer with multiple versions of the same
>> question, over and over again -- unless all the packages use the
>> same, shared, variable.

>> If there is to be a shared variable, what should the common shared
>> toplevel hierarchy be? I don't see all these packages (dist,
>> mailagent, Gnus, VM, and other packages) using a common (virtual)
>> package name; they are not even close to being similar types of
>> packages, and thus do not share a common purpose in general, only
>> for this variable.

>> The question then becomes: what is this shared variable called? How
>> does a package maintainer discover this variable? How are updates
>> to common templates made? Does some package "own" this shared
>> variable template? Which one?

>> Where is this central registry of shared variablenames, so that the
>> next package wanting to create /etc/news/organization can use the
>> same variable, and not ask the user yet another duplicate question.

> I don't think there is a central registry.  I do see a debconf value
> on my system named shared/organization; this seems to be a
> general-purpose "organization" value, but perhaps it could be used
> for the contents of /etc/news/organization as well?

How does one discover these templates then? Is this a
 hit-or-miss effort based on the packages I may have installed on my
 machine? Seems to me that makes it very likely that the user shall be
 bombarded with identical questions on install then; I think this
 would be quite irksome.

> The "shared/" toplevel heirarchy seems to be popular for this sort
> of thing, at any rate; even related packages seem likely to use this
> when the question doesn't clearly belong to just one of them.

OK. How do I discover the templates in the shared hierarchy,
 then? 

> As for owning the template: /all/ of the packages own the template
> (as shown by the Owners: field in /var/cache/debconf/config.dat),
> and must ship it; or there must be a common package that all others
> depend on which owns the question, if including it in multiple

Assuming one knows which package this is. Also, do all these
 templates have to be identical? If not, which template determines the
 question that is asked? 

> packages is seen as a duplication of effort.  In the absence of
> strict package dependencies, though, each package that needs the
> answer must be prepared to ask for it separately.


This seems to be very conducive to having the user bombarded
 with identical questions, then, for shared values.

I am not sure where I stand on the tradeoff between multiple,
 redundant questions being asked in the preconfigure phase, or a
 single question being asked in the postinst (since subsequent
 postinsts would not ask the question since /etc/news/organization
 would exist).  I tend to lean towards the single question.

manoj
-- 
Software Engineering: How to program if you cannot.  Dijkstra
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: [Debian-au] Debian 10th birthday gear

[Thomas Viehmann]

Branden Robinson wrote:
> Anybody else get a bad cryptographic signature on the message to which I
> am replying?
Yes.


pgpZxCz9N79cb.pgp
Description: PGP signature

default MTA for sarge

[Joey Hess]

For sarge we have two options for the default MTA in base:

a. replace exim with exim4
b. no MTA installed by default, add a MTA task

So do we want there to be a MTA by default?

-- 
see shy jo


pgphtlTJ6VHOZ.pgp
Description: PGP signature

Re: default MTA for sarge

[David B Harris]

On Sun, 13 Jul 2003 10:31:51 +0200
Joey Hess <[EMAIL PROTECTED]> wrote:
> For sarge we have two options for the default MTA in base:
> 
> a. replace exim with exim4
> b. no MTA installed by default, add a MTA task
> 
> So do we want there to be a MTA by default?

I would opt for a) personally. Exim has done me well for years, and
exim-config (or its debconf-based replacement) is great.

However, if b) is chosen ... doesn't this cry for a category, not a
task? Or perhaps even a one-off frontend that lets one select from the
list of 'grep-available -FProvides -sPackage mail-transport-agent'?


pgplbFa6n1iM4.pgp
Description: PGP signature

Re: Deconf and shared questions

[Joey Hess]

Manoj Srivastava wrote:
>   How does one discover these templates then? Is this a
>  hit-or-miss effort based on the packages I may have installed on my
>  machine? Seems to me that makes it very likely that the user shall be
>  bombarded with identical questions on install then; I think this
>  would be quite irksome.

namespace.txt in debconf-doc gives some general rules and documents a
few of them. I will be glad to add more. Or this could be moved into a
file included in policy and maintained that way.

> > The "shared/" toplevel heirarchy seems to be popular for this sort
> > of thing, at any rate; even related packages seem likely to use this
> > when the question doesn't clearly belong to just one of them.
> 
>   OK. How do I discover the templates in the shared hierarchy,
>  then? 
> 
> > As for owning the template: /all/ of the packages own the template
> > (as shown by the Owners: field in /var/cache/debconf/config.dat),
> > and must ship it; or there must be a common package that all others
> > depend on which owns the question, if including it in multiple
> 
>   Assuming one knows which package this is. Also, do all these
>  templates have to be identical? If not, which template determines the
>  question that is asked? 

Shared templates should be identical and must be duplicated in all
packages that use them. The most recent text debconf sees will be used.

>   I am not sure where I stand on the tradeoff between multiple,
>  redundant questions being asked in the preconfigure phase, or a
>  single question being asked in the postinst (since subsequent
>  postinsts would not ask the question since /etc/news/organization
>  would exist).  I tend to lean towards the single question.

There is no need to ask questions in the postinst. It works like this:

- preinst a asks shared/foo: unseen so displayed
- preinst b asks shared/foo: seen, so question skipped
...
- postinst a acts on shared/foo
- postinst b acts on shared/foo
...

-- 
see shy jo


pgpy8alNeMXI7.pgp
Description: PGP signature

Re: default MTA for sarge

[Joey Hess]

David B Harris wrote:
> However, if b) is chosen ... doesn't this cry for a category, not a
> task? Or perhaps even a one-off frontend that lets one select from the
> list of 'grep-available -FProvides -sPackage mail-transport-agent'?

Not really, that's what aptitude is for. You would chose the task if you
just wanted a basic MTA that worked, similar to the other tasks.

-- 
see shy jo


pgp2BqGLp3N9s.pgp
Description: PGP signature

Re: default MTA for sarge

[Sean 'Shaleh' Perry]

On Sunday 13 July 2003 01:31, Joey Hess wrote:
> For sarge we have two options for the default MTA in base:
>
> a. replace exim with exim4
> b. no MTA installed by default, add a MTA task
>
> So do we want there to be a MTA by default?

I would lean towards exim4 configured for local delivery only.  It is a sane 
default for just about every system.  The admins who know they want another 
MTA can easily replace exim and the users who have no clue what a MTA does 
have one installed quietly and securely waiting for the day they might want 
more from it.

Enough of a Linux system assumes that a MTA is present that not installing any 
would be wrong.  Asking an user which MTA they want is equally wrong because 
many users have no clue what one is.

Re: Qt3 still broken (compat-headers), what to do?

[Dominique Devriese]

Ben Burton writes:

> Hi ho, it's time for another rant from me regarding the
> libqt3-compat-headers split.  


> (i) Wait for the Qt maintainers to upload a fix.
> (ii) Do an NMU for Qt, despite the fact that this bug is not
> release-critical.  
> (iii) Resort to the technical committee.  
> (iv) Keep the package split and release sarge with a broken Qt
> development environment.

> Several months of experience suggest that (i) does not promise
> success.  Option (iii) seems rather heavy-handed to me.  And I am
> loathe to see us reach (iv), cementing debian as the only
> distribution with a deliberately broken Qt.

> I'd thus like to propose (ii) as the best solution.  I realise this
> is not an RC bug; technically it's not debian's problem but the
> upstream Qt app's problem.  Nevertheless, as it stands users are
> expected to divine the fact that debian has deliberately broken Qt,
> that they should look in README.Debian for a fix and that they are
> morally expected to tell upstream that their code is wrong (after
> all, that's why they were forced through this hassle in the first
> place).

> So.  Do people support this move or not?

I wouldn't do it.  Suppose you were the Qt maintainer, and you made a
technical choice that some people disagree with, and they do an NMU on
you.  In the worst case, they could be doing another upload reverting
your upload, and I can't say I would disagree with them.

IMHO, what should happen, is try to convince the Qt maintainer, or
agree with him to let the technical committee decide this one..

just my opinion of course...

cheers
domi

Re: Qt3 still broken (compat-headers), what to do?

[Ben Burton]

> I wouldn't do it.  Suppose you were the Qt maintainer, and you made a
> technical choice that some people disagree with

You mean a technical choice with a significant negative impact on users that
breaks compatibility with upstream and every other linux distribution
and that most (not some) people disagree with.

> and they do an NMU on you

after four or five months of constant prodding and visible user confusion.

> IMHO, what should happen, is try to convince the Qt maintainer

This option appears to lead nowhere, as explained in my earlier post.

> or agree with him to let the technical committee decide this one..

Taking it to the technical committee needn't require the Qt maintainers'
consent.  Furthermore, since the Qt maintainers seem so apathetic about
this issue I'm certainly not going to wait for it.

I honestly believe that in this case having a sarge Qt that's not broken
should take precedence over maintainers' territoriality over their
packages.  And this is not a snap decision; the problem has been
discussed for many months now without resolution, and the user errors
continue to roll in.

Ben.

the RFC mess: tentative summary

[Martin Quinson]

Ok, people. Even if I'm not native speaker, I'll now try to sum up the
flamewar we just had about the RFC licencing. Don't get me wrong here. In
fact I personnaly have no fixed opinion about this. I just want to be able
to fix the tons of RC bugs involved by this issue, close them, get other
bugs do the same, see Sarge released before mid-2004 and drink a bier to
celebrate. Please be patient with me and correct me if I'm wrong.



This is all about one of the oldest RC bug in debian, the infamous #92810.
The issue here is that the RFC licence (at least for the modern ones) is
clearly non free. For some people, that's a reason to throw this out of
main, for some other, RFCs can stay in main for several reasons.

I belive that the discussion showed that the status-quo (ie, RFC being in
main without being free) cannot stay as is. Here are first the arguments
proposed by people for this status-quo and their refutation proposed by
others.

 1. RFC are not software but standards.
 
Answer 1: What is a software, then? It's impossible to establish a clear
  definition of that (Perl interpreting scripts is not clearly different
  from mozilla or php processing an html document).
Answer 2: Ok, that's not software. But it should remain free anyway to
  make its way to main (non-free non-software is not equivalent to free
  software)
Answer 3: If they are not software, they don't belong to Debian (one
  interpretation of "Debian will remain 100% free software")
   
 2. Standards gain their value from their rigid rigid procedure for updates
and modifications.
  or:
Who needs to edit the RFCs by the way?
  or:
Keep cool, IETF are good guys, sharing some goals with us.

Answer 1: Nobody asked the right to change the content of the file
  RFC23423.txt and distribute it as is. This would clearly be wrong and
  it would be ok to ask for a file rename, for a clear notice changes
  between the original version and the distributed one, and so on.
Answer 2: As long as the IETF is a good willing institution, that's fine,
  but what will happen in 10 years? If they disapear, we need the *right*
  to modify the existing RFCs to create new ones, and fork the
  standardisation process. 
 This is not very different forking gcc: in both cases it's generally a
  bad idea, but the health of a free system depends on it being 
  potentially possible.
Answer 3: If I want to document a program following quite well a given
  RFC, but not completely, it's easier for me to edit the RFC file (and
  rename it of course) than paraphrasing it. If I'm not allowed to do
  this edit, I'll probably never document those changes, which is a loss
  for the users. 
 Same thing for comments in code explaining which part of the RFC
  constraints some design decision.
Answer 4: "Ceci n'est pas une RFC". The file containing the standard is
  not the standard itself. Sure I won't change the standard. But I may
  want to use bits of the standard if I want (see also argument 6).
 
 3. It serves our users (no need to download)
  or
Banning RFCs from Debian is just silly.

Answer 1: Serving our users is not a sufficient reason. It would help a lot
 of people to have a complete implementation of java in main, but since
 there is no free implementation, that's currently impossible.
Answer 2: If anyone but the IETF wanted to get something under such
 licence in Debian main, nobody would agree. We have to be consistent
 with ourselves. Netscape and acrobate did get banned.
See also answer 2.3.

 4. It would be arrogant to ask IETF to change its licence to fit our views. 
   
Answer 1: So far, we just discussed about moving it to non-free.
Answer 2: Some people belive that the intention of the licence is good
  (authors intended the RFCs to be freely usable, but also trustable, ie
  that a file claiming to be the RFC1253215 is actually the version
  endorsed by IETF), but the wording is wrong and makes it non-free.
Answer 3: We asked a lt of stuff around to *clarify* their licence.

 5. ISOC is not granted an exclusive copyright license, and even if they
wanted, they cannot relicence the file.

Answer 1: People wanting to include a perticular RFC in a free packages
  can contact the RFC authors directly to manage this.
Answer 2: ISOC could change the licence terms for future RFCs.

 6. There is a "fair use" provision.
 
Answer 1: "fair use" provisions are not legally appliable everywhere in
  the world (UK only have a more limited concept called "fair dealing").
See also answer 2.2

That's the main arguments I've seen. As in any flamewar, some "not so
fundamental and related" arguments were also given:

 7. There is a tons of other craps in main which should be removed.
 
Answer 1: Fine, let's remove them

Re: default MTA for sarge

[ZHAO Wei]

On Sun, 2003-07-13 at 16:31, Joey Hess wrote:
> For sarge we have two options for the default MTA in base:
> 
> a. replace exim with exim4
> b. no MTA installed by default, add a MTA task
> 
> So do we want there to be a MTA by default?

I, for one, don't want there be a MTA by default. At least not a running
daemon there.

-- 
[EMAIL PROTECTED]
http://c2.com/cgi/wiki?ZhaoWay
http://www.advogato.org/person/zhaoway/
Linux & Free Software Consultant, Nanjing, China

Re: Qt3 still broken (compat-headers), what to do?

[Sebastian Rittau]

On Sun, Jul 13, 2003 at 12:14:52AM -0500, Branden Robinson wrote:

> Bah, the Technical Committee takes months, sometimes over a year, to do
> something even as seemingly uncontroversial as voting in opposition to
> whichever solution Branden Robinson proposes.

So? This is more than enough time. This problem is to be fixed in sarge ...

 - Sebastian

Re: Qt3 still broken (compat-headers), what to do?

[Sebastian Rittau]

On Sun, Jul 13, 2003 at 01:51:07PM +1000, Ben Burton wrote:

> It seems then that our options are as follows.
> 
> (i) Wait for the Qt maintainers to upload a fix.
> (ii) Do an NMU for Qt, despite the fact that this bug is not release-critical.
> (iii) Resort to the technical committee.
> (iv) Keep the package split and release sarge with a broken Qt development 
> environment.

Option (iii) is certainly the way to go. Problems like this are exactly
what the TC is for.

My suggestion: Add a "Recommends: libqt3-compat-headers" to libqt3-dev.
A dependency is too strong, since libqt3-dev is perfectly usable without
the compatibility headers, but a recommendation ensures that the compat
headers are installed along libqt3-dev in most cases.

 - Sebastian

Re: default MTA for sarge

[Daniel Silverstone]

On Sun, Jul 13, 2003 at 10:31:51AM +0200, Joey Hess wrote:
> For sarge we have two options for the default MTA in base:
> a. replace exim with exim4
> b. no MTA installed by default, add a MTA task
> So do we want there to be a MTA by default?

Since woody didn't release with exim4 at all, I'm all for releasing with
exim 3 by default, having exim 4 there for people who want it, and then
in sarge+1 swapping it over for exim4 by default, then exim3 there if
you want it. sarge+2 can remove exim3.

the MTA is such a fundamental part of a linux system that it seems utter
folly to remove it. We should perhaps work on making the default
configuration simpler for novice users, but it would be fairly damned
silly if in a default installation cron couldn't email reports.

D.



-- 
Daniel Silverstone   http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler  Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org   KeyId: 20687895
Be different: conform.

Re: the RFC mess: tentative summary

[Andrew Suffield]

On Sun, Jul 13, 2003 at 12:17:50PM +0200, Martin Quinson wrote:
> Answer 1: Nobody asked the right to change the content of the file
>   RFC23423.txt and distribute it as is. This would clearly be wrong and
>   it would be ok to ask for a file rename, for a clear notice changes
^^^

Ask, yes. Require in the license, no. This was established during the
LPPL dissection.

Contrived example: I have an application that uses rfc23423.txt as
input data (reading a table or something), and it is prohibitively
difficult to change the filename it looks for.

Requiring clear identification of changes, and "Changing the name",
are OK. Putting constraints on how this is to be done, like requiring
a filename change, is not.

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


pgphvf3i7ep9B.pgp
Description: PGP signature

Re: Qt3 still broken (compat-headers), what to do?

[Ben Burton]

> > Bah, the Technical Committee takes months, sometimes over a year, to do
> > something even as seemingly uncontroversial as voting in opposition to
> > whichever solution Branden Robinson proposes.
> 
> So? This is more than enough time. This problem is to be fixed in sarge ...

Hmm?  Are you saying that sarge is definitively well over a year away?

b.

Re: Qt3 still broken (compat-headers), what to do?

[Ben Burton]

> My suggestion: Add a "Recommends: libqt3-compat-headers" to libqt3-dev.

This is indeed what I would add were I to do an NMU, and I would
include it in the list of solutions that I see as satisfactory were I to
put it to the TC.

b.

Re: Qt3 still broken (compat-headers), what to do?

[Paul Cupis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sunday 13 July 2003 06:32, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Sun, Jul 13, 2003 at 12:14:52AM -0500, Branden Robinson wrote:
> > To punt this to the Technical Committee is to stall a solution for
> > potentially a very long time.
> >
> > If you're certain you're right, and you can get the NMU correct,
> > the only people who will complain will be the package maintainers.
>
> And given that they're the ones who'll be uploading the package again
> once the NMU is done and can easily revert the change, NMUing against
> the wishes of the maintainers and without the support of a higher
> authority doesn't seem overly productive either.
>
> I suppose there's always the option of NMUing, and hoping it sticks
> -- then taking it up with the tech ctte. if it doesn't...

I agree with this. Tell the maintainer you are NMU-ing, and do so to 
Delayed/. If he reverts/override the change, take it to the tech-ctte.

Paul Cupis
- -- 
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/ET7NIzuKV+SHX/kRAq9YAJ4wO6NhuyuYo6Nd6Dpdj77JwiiFWwCfTJa9
yaGdRiU6mYYorG5r8QZHCUU=
=WdL3
-END PGP SIGNATURE-

Re: [Debian-au] Debian 10th birthday gear

[Emile van Bergen]

Hi,

On Sun, Jul 13, 2003 at 12:06:03AM -0500, Branden Robinson wrote:

> Anybody else get a bad cryptographic signature on the message to which I
> am replying?

AOL.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl

Re: the RFC mess: tentative summary

[Emile van Bergen]

Hi,

On Sun, Jul 13, 2003 at 12:03:22PM +0100, Andrew Suffield wrote:

> On Sun, Jul 13, 2003 at 12:17:50PM +0200, Martin Quinson wrote:
> > Answer 1: Nobody asked the right to change the content of the file
> >   RFC23423.txt and distribute it as is. This would clearly be wrong and
> >   it would be ok to ask for a file rename, for a clear notice changes
> ^^^
> 
> Ask, yes. Require in the license, no. This was established during the
> LPPL dissection.
> 
> Contrived example: I have an application that uses rfc23423.txt as
> input data (reading a table or something), and it is prohibitively
> difficult to change the filename it looks for.

Contrived, indeed. Especially since we should not create our criteria
for documentation and standards licenses to especially accomodate
non-free software that cannot be modified to accept a different file
name. 

Also, the clause is about appropriately identifying a file as such when
distributing a modified copy. No perverse combination of law and license
should be able prevent you from installing it on your own system under a
file name of your choice.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl

Re: default MTA for sarge

[John Hasler]

Joey Hess writes:
> So do we want there to be a MTA by default?

IMO yes.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: default MTA for sarge

[Andreas Metzler]

Daniel Silverstone <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 13, 2003 at 10:31:51AM +0200, Joey Hess wrote:
>> For sarge we have two options for the default MTA in base:
>> a. replace exim with exim4
>> b. no MTA installed by default, add a MTA task
>> So do we want there to be a MTA by default?

> Since woody didn't release with exim4 at all, I'm all for releasing with
> exim 3 by default, having exim 4 there for people who want it, and then
> in sarge+1 swapping it over for exim4 by default, then exim3 there if
> you want it. sarge+2 can remove exim3.
[...]

Exim3 is dead upstream.

Even today if you ask a question about exim3 on its main support-list
(exim-users.exim.org) you'll get a (polite[1]) hint to upgrage to v4
along the lines of:
| I've released Eximv4 ${some very long time ago}[2] after developing it
| for ${at least the same time}. Exim3 is dead, please consider
| upgrading, I do not know it anymore and cannot answer detail
| questions about it.

You are seriously suggesting to ship this already unsupported version
as default MTA in 2005? (I do not think we'll see sarge 2003.)
cu andreas
[1] It's Phil Hazel and not DJB ;-)
[2] I have not got any dates ATM, but it is at least 17months.
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: default MTA for sarge

[Daniel Silverstone]

On Sun, Jul 13, 2003 at 01:25:02PM +0200, Andreas Metzler wrote:
> Daniel Silverstone <[EMAIL PROTECTED]> wrote:
> > Since woody didn't release with exim4 at all, I'm all for releasing with
> > exim 3 by default, having exim 4 there for people who want it, and then
> > in sarge+1 swapping it over for exim4 by default, then exim3 there if
> > you want it. sarge+2 can remove exim3.
> Exim3 is dead upstream.

Aah, hmm.

> Even today if you ask a question about exim3 on its main support-list
> (exim-users.exim.org) you'll get a (polite) hint to upgrage to v4
> along the lines of:
> | I've released Eximv4 ${some very long time ago} after developing it
> | for ${at least the same time}. Exim3 is dead, please consider
> | upgrading, I do not know it anymore and cannot answer detail
> | questions about it.
> You are seriously suggesting to ship this already unsupported version
> as default MTA in 2005? (I do not think we'll see sarge 2003.)

Fair enough. Is the upgrade path from exim3 to exim4 utterly smooth?

If not, we should make it optional which to choose, if it is utterly
smooth then let's have exim4 by default, or at minimum a 'one of' choice
of things like exim3 exim4 and postfix.

D.

-- 
Daniel Silverstone   http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler  Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org   KeyId: 20687895
Good day for a change of scene.  Repaper the bedroom wall.

Re: default MTA for sarge

[Sebastian Kapfer]

On Sun, 13 Jul 2003 11:50:07 +0200, Sean 'Shaleh' Perry wrote:

> Enough of a Linux system assumes that a MTA is present that not
> installing any would be wrong.  Asking an user which MTA they want is
> equally wrong because many users have no clue what one is.

I strongly support this. A week or two ago, I had to fix a Debian box
which was "painfully slow". The cause was (you guess it) - exim. The user
installed it (probably dependencies), but didn't configure it correctly.
Now combine that with a cronjob that runs every five minutes and cron's
send-mail-when-complete feature. The machine accumulated a mail queue of
several hundred megabytes; every 10 minutes or so, exim was run and tried
in vain to send out those mails. Because none of these mails was ever
delivered, the user didn't know what the problem was.

In short, please make "local delivery" the default; don't even run
exim-config on installation.[1] Those who need the feature will know how
to activate it. The others shouldn't need to care.


[1] The question where root's mail goes to comes to mind. I think this
question has to be asked.

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: default MTA for sarge

[Sebastian Kapfer]

On Sun, 13 Jul 2003 12:30:08 +0200, ZHAO Wei wrote:

>> So do we want there to be a MTA by default?
> 
> I, for one, don't want there be a MTA by default. At least not a running
> daemon there.

What about inetd (which is IMHO the current default)?

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: default MTA for sarge

[Michał Politowski]

On Sun, 13 Jul 2003 13:21:05 +0100, Daniel Silverstone wrote:
[...]
> Fair enough. Is the upgrade path from exim3 to exim4 utterly smooth?
> 
> If not, we should make it optional which to choose, if it is utterly
> smooth then let's have exim4 by default, or at minimum a 'one of' choice
> of things like exim3 exim4 and postfix.

If not, maybe we can keep exim = exim3 for some time, for the sake of
upgrades, but install exim4 by default on new systems?

-- 
Michał Politowski -- [EMAIL PROTECTED]
Warning: this is a memetically modified message

Re: default MTA for sarge

[Michał Politowski]

On Sun, 13 Jul 2003 13:55:12 +0200, Sebastian Kapfer wrote:
> On Sun, 13 Jul 2003 12:30:08 +0200, ZHAO Wei wrote:
> 
> >> So do we want there to be a MTA by default?
> > 
> > I, for one, don't want there be a MTA by default. At least not a running
> > daemon there.
> 
> What about inetd (which is IMHO the current default)?

No listeners by default on desktop systems, IMHO. Only local delivery,
and /usr/sbin/sendmail submission.
If the admin wants more they should know how to set it up.

-- 
Michał Politowski -- [EMAIL PROTECTED]
Warning: this is a memetically modified message

Re: the RFC mess: tentative summary

[Andrew Suffield]

On Sun, Jul 13, 2003 at 01:48:27PM +0200, Emile van Bergen wrote:
> On Sun, Jul 13, 2003 at 12:03:22PM +0100, Andrew Suffield wrote:
> 
> > On Sun, Jul 13, 2003 at 12:17:50PM +0200, Martin Quinson wrote:
> > > Answer 1: Nobody asked the right to change the content of the file
> > >   RFC23423.txt and distribute it as is. This would clearly be wrong 
> > > and
> > >   it would be ok to ask for a file rename, for a clear notice changes
> > ^^^
> > 
> > Ask, yes. Require in the license, no. This was established during the
> > LPPL dissection.
> > 
> > Contrived example: I have an application that uses rfc23423.txt as
> > input data (reading a table or something), and it is prohibitively
> > difficult to change the filename it looks for.
> 
> Contrived, indeed. Especially since we should not create our criteria
> for documentation and standards licenses to especially accomodate
> non-free software that cannot be modified to accept a different file
> name. 

It's not non-free, it's just crap.

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


pgpOFhLbJN3aK.pgp
Description: PGP signature

Re: default MTA for sarge

[ZHAO Wei]

On Sun, 2003-07-13 at 19:55, Sebastian Kapfer wrote:
> On Sun, 13 Jul 2003 12:30:08 +0200, ZHAO Wei wrote:
> > 
> > I, for one, don't want there be a MTA by default. At least not a running
> > daemon there.
> 
> What about inetd (which is IMHO the current default)?

Indeed I don't want inetd on my desktop system either. :)

Really the only reason I have inetd installed on my system listening
nothing is for package dependencies. I have no use of it.

-- 
[EMAIL PROTECTED]
http://c2.com/cgi/wiki?ZhaoWay
http://www.advogato.org/person/zhaoway/
Linux & Free Software Consultant, Nanjing, China

Re: default MTA for sarge

[Andreas Metzler]

Daniel Silverstone <[EMAIL PROTECTED]> wrote:
[...]
> Fair enough. Is the upgrade path from exim3 to exim4 utterly smooth?

It is not utterly smooth but as smooth as I could make it.

> If not, we should make it optional which to choose, if it is utterly
> smooth then let's have exim4 by default, or at minimum a 'one of' choice
> of things like exim3 exim4 and postfix.

So you are voting for the MTA task alternative.

I just don't get how this is conncted to smooth upgradability? Afaict
we were only discussing which (or if an) MTA should be installed on
fresh installations, upgrades should not be influenced by this.
 cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: default MTA for sarge

[Andreas Metzler]

Sebastian Kapfer <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jul 2003 11:50:07 +0200, Sean 'Shaleh' Perry wrote:
>> Enough of a Linux system assumes that a MTA is present that not
>> installing any would be wrong.  Asking an user which MTA they want is
>> equally wrong because many users have no clue what one is.

[...]
> In short, please make "local delivery" the default; don't even run
> exim-config on installation.[1] Those who need the feature will know how
> to activate it. The others shouldn't need to care.

Hello,
If you installed exim4 and used frontend=noninteractive or just press
 on every debconf-question you should end up exactly with this:
local delivery only. OTOH if you upgraded from an exim with broken
config you /might/ end up with an exim4 inheriting the broken config,
as it tries to "parse" exim.conf to preanswer the debconf-questions.

> [1] The question where root's mail goes to comes to mind. I think this
> question has to be asked.

If you don't specify another user when configuring /etc/alises it will
be delivered to /var/mail/root
   cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

$B!ZL5NA![#3!$#1#5#01_$G#7#9#6!$#0#0#01_2T$0J}K!!*!*(B

[SOHO$BDL?.(B]

debian-devel@lists.debian.org $BMM(B
(B
$B#3!$#1#5#01_$G#7#9#6!$#0#0#01_2T$0J}K!!*L5NA$G65$($^$9!*(B
(B
$B%a!<%k$NAw\$7$/$O$3$A$i$r$4Mw$/[EMAIL PROTECTED](B
$B"-"-"-"-"-"-"-"-"-"-"-(B
(Bhttp://www.soho-7.com/cgi-bin/c2/index.cgi?ID=C-0073200&PG=index

unsubscribe

[Lucio]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

unsubscribe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iQEVAwUBPxFZJRPJoalLltY2AQKh3Qf9FkHTBo1K4/hFdqZL23SMNZNCoUhMkb8/
yleJvILBgWKbi57M2hshLDovSpJIHPKA7tFdHatqRDHi8pRGv0JWnGSDKr3pxtnj
62voIwpkRjIvjtdnqPPBdLsaxnfPhvOwl+S9CXaEBNa1FsN6jBeuRLqrHX9WsC1S
FwdnKCJXpGe+WvS58qxyANEn0cg/voj2zu6CdX9qAZ/f7C2U5TnJSlY3K/njLtww
HVQIs6DSSNpSoOjA8CQDiDTVs3x7Z3xIft53RxyhfWjLnlVGS/JfBN1FshfuwE0N
haqWbURHjLN27MDv+22bBzDnVKXtvSjGUTi36eNLiVJvLiu7Pni2Bw==
=wNQ5
-END PGP SIGNATURE-

Re: default MTA for sarge

[Andreas Metzler]

Micha? Politowski <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jul 2003 13:21:05 +0100, Daniel Silverstone wrote:
> [...]
>> Fair enough. Is the upgrade path from exim3 to exim4 utterly smooth?

>> If not, we should make it optional which to choose, if it is utterly
>> smooth then let's have exim4 by default, or at minimum a 'one of' choice
>> of things like exim3 exim4 and postfix.

> If not, maybe we can keep exim = exim3 for some time, for the sake of
> upgrades, but install exim4 by default on new systems?

That's the plan.
 cu andreas

Re: FWD: Bug#200905: dh_installdocs: don't install empty doc files

[Stefano Zacchiroli]

On Fri, Jul 11, 2003 at 08:07:40PM -0400, Joey Hess wrote:
> This strikes me as a good idea, unless someone has a legit reason to
> include an empty documentations file in a package. So speak up if you
> do. Maybe a zero length TODO could be considered to have some implied
> meaning, but I've seen zero length everything including AUTHORS and
> README and NEWS.

Sounds good to me too, I've several "find -size 0" in debian/rules to
remove such kind of files.

Anyway I think it can be unlikely to remove empty files when they are
linked from others files. E.g. a .html having a link to another empty
.html. In such a case having the empty html file is better than having
no html at all to avoid future browser complains.

I no it is a bit weird situation but can't the heuristic "remove empty
files if they have no .html extension"?

Cheers

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney


pgpwvsDxEW5UK.pgp
Description: PGP signature

Re: default MTA for sarge

[Joey Hess]

Daniel Silverstone wrote:
> Since woody didn't release with exim4 at all, I'm all for releasing with
> exim 3 by default

Releaseing with exim 3 is not an option unless someone converts it to
use debconf for configuration. Sorry.

>, having exim 4 there for people who want it, and then
> in sarge+1 swapping it over for exim4 by default, then exim3 there if
> you want it. sarge+2 can remove exim3.

You're presuming that we need some kind of a transition plan, which does
not make sense. This is for new installs.

-- 
see shy jo


pgpicvRoA5uI4.pgp
Description: PGP signature

Re: Qt3 still broken (compat-headers), what to do?

[Anthony Towns]

On Sun, Jul 13, 2003 at 09:08:03PM +1000, Ben Burton wrote:
> 
> > > Bah, the Technical Committee takes months, sometimes over a year, to do
> > > something even as seemingly uncontroversial as voting in opposition to
> > > whichever solution Branden Robinson proposes.
> > So? This is more than enough time. This problem is to be fixed in sarge ...
> Hmm?  Are you saying that sarge is definitively well over a year away?

If he is, he's wrong.

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

Re: FWD: Bug#200905: dh_installdocs: don't install empty doc files

[Joey Hess]

Stefano Zacchiroli wrote:
> Anyway I think it can be unlikely to remove empty files when they are
> linked from others files. E.g. a .html having a link to another empty
> .html. In such a case having the empty html file is better than having
> no html at all to avoid future browser complains.

I think that a 404 error is actually more user-friendly than getting an
empty page.

-- 
see shy jo


pgpYZkYHi0r4F.pgp
Description: PGP signature

Re: default MTA for sarge

[Steve Greenland]

On 13-Jul-03, 07:48 (CDT), Andreas Metzler <[EMAIL PROTECTED]> wrote: 
> Hello,
> If you installed exim4 and used frontend=noninteractive or just press
>  on every debconf-question you should end up exactly with this:
> local delivery only.

But that's several more questions that many users, especially new
desktop users, won't understand and don't need to see: they're going
to use Mozilla mail or Evolution with a POP server and remote SMTP
submissions, just like they did with Windows.

> OTOH if you upgraded from an exim with broken
> config you /might/ end up with an exim4 inheriting the broken config,
> as it tries to "parse" exim.conf to preanswer the debconf-questions.

So they go from broken->broken. I don't see the loss. In particular,
I don't see the point of making people go through several debconf
questions on the upgrade if they still will have a broken system, which
I *think* you may be implying by the above.

Which doesn't mean that you can really help this, by the way. I
understand that the attempt to preserve existing configuration (which is
the most important thing here!) probably can't detect and correct all
the different ways one can screw up an MTA configuration. Such is life.

So if I get a vote, I'd strongly urge the 'local-delivery-only' default
on new installs, without going through the exim configuration, but just
a note pointing the admin at dpkg-reconfigure if they want something
different.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: default MTA for sarge

[Sebastian Kapfer]

On Sun, 13 Jul 2003 15:00:10 +0200, Andreas Metzler wrote:

> If you installed exim4 and used frontend=noninteractive or just press
>  on every debconf-question you should end up exactly with this:
> local delivery only.

In this case, it was the exim3 package, which had a non-debconf
configuration program last I looked. This program was probably confusing
the user (he didn't intend to install an MTA after all). Good to hear that
exim4 has improved this.

> OTOH if you upgraded from an exim with broken config you /might/ end up
> with an exim4 inheriting the broken config, as it tries to "parse"
> exim.conf to preanswer the debconf-questions.

Of course one can't rely on updates to fix misconfigurations. So that's
probably OK.

>> [1] The question where root's mail goes to comes to mind. I think this
>> question has to be asked.
> 
> If you don't specify another user when configuring /etc/alises it will
> be delivered to /var/mail/root

I know, but that location (/var/mail/root) is discouraged, isn't it? The
admin shouldn't read his/her mail under uid 0. That's why I think that
exim should ask this question when it is configured for local delivery (or
in "newbie" mode ;-)

The best solution (at least for the average user which doesn't care about
his MTA) would IMHO be a question along the lines of "Which user account
should receive messages for the system administrator?" I.e. not even
mentioning the technical details. The word "mail" might be misleading
here.

Just thinking aloud... I have not installed any exim4 yet, and I know how
to get exim3 to do local delivery. But Debian should become a more
user-friendly OS after all, right?

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: Kernel question: initrd/cramfs

[Nenad Antonic]

Herbert Xu <[EMAIL PROTECTED]> wrote:

> Why are you trying to use initrd anyway? It's much easier to build
> the drivers into the kernel.

Now, I must agree with that.

At the begining, it looked as a good idea to compile one kernel which
can be used on scsi and ide systems, etc. Strong additional reason was
that the kernels provided by Debian were of that type, and I wanted to
be close to the standard. It fitted nicely into FAI installation as well.

However, it looks like initrd/cramfs is not yet stable enough, and
building a number of different kernels for different architectures might
be simpler solution for my needs at the moment.

Thanks a lot for the hint.

--- Nenad.

Re: Qt3 still broken (compat-headers), what to do?

[Brian Nelson]

Sebastian Rittau <[EMAIL PROTECTED]> writes:

> On Sun, Jul 13, 2003 at 01:51:07PM +1000, Ben Burton wrote:
>
>> It seems then that our options are as follows.
>> 
>> (i) Wait for the Qt maintainers to upload a fix.
>> (ii) Do an NMU for Qt, despite the fact that this bug is not 
>> release-critical.
>> (iii) Resort to the technical committee.
>> (iv) Keep the package split and release sarge with a broken Qt development 
>> environment.
>
> Option (iii) is certainly the way to go. Problems like this are exactly
> what the TC is for.
>
> My suggestion: Add a "Recommends: libqt3-compat-headers" to libqt3-dev.
> A dependency is too strong, since libqt3-dev is perfectly usable without
> the compatibility headers, but a recommendation ensures that the compat
> headers are installed along libqt3-dev in most cases.

Uhh, there's no reason the compat headers should have been split out in
the first place.

-- 
Poems... always a sign of pretentious inner turmoil.


pgpOwozzSjaLu.pgp
Description: PGP signature

Re: problem setting up interlibrary dependencies

[Aaron M. Ucko]

Steve Langasek <[EMAIL PROTECTED]> writes:

> So to restate, you have two libraries which export similar ABIs, but not
> identical; the GL-enabled version of the library exports additional
> entry points which are only of use to a subset of callers.  You want to
> supply distinct .so links for each library, so that at build-time a
> program can clearly specify which variant it wishes to link against; and
> you don't want to drop the non-GL variant, because OpenGL is a hefty
> dependency for those who don't need it.

Right.  I would moreover like for the GL variant to supersede the
non-GL variant when both are installed, since that's what the
GL-neutral higher-level libraries will be linking against.

The way this worked up to now was that the only library dependencies
were on libc, with both variants residing in a single package that did
not depend on libGL(U); applications using the higher-level libraries
would have to link explicitly either against the non-GL variant or
against the GL variant and libGL(U).

> 1) Divide the library into two parts: one which provides the non-GL
> functions, and one which provides *only* the GL functions.  This

This would definitely be a pain, given that the two variants are built
from the same sources, just with different #defines.

> 2) Continue to ship complete versions of each library, tagging each with
> a unique soname and keeping their associated filenames entirely
> separate.  If someone wants the non-GL version, they link with
> -lvibrant; if they want the OpenGL-enabled version, they link with
> -lvibrant-gl.  Disadvantage: if you have a higher-level library that
> would use the non-GL version of the library, and an application that
> would use both this higher-level library and libvibrant-gl, you would
> have both libvibrant and libvibrant-gl loaded into memory, which
> probably won't work too well unless you implement symbol versioning as
> well.

Right, though I think I want the *opposite* of what symbol versioning
would give me: if the GL variant shows up at runtime in any fashion,
the process should not use any symbols from the non-GL variant, even
if it pulls it in indirectly.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Re: Qt3 still broken (compat-headers), what to do?

[Evan Prodromou]

> "AT" == Anthony Towns  writes:

BB> Hmm?  Are you saying that sarge is definitively well over a
BB> year away?

AT> If he is, he's wrong.

Hubris! Famous last words! The pride what cometh before a fall!

~ESP

-- 
Evan Prodromou
[EMAIL PROTECTED]

Re: Kernel question: initrd/cramfs

[Russell Coker]

On Mon, 14 Jul 2003 00:42, Nenad Antonic wrote:
>   However, it looks like initrd/cramfs is not yet stable enough, and
> building a number of different kernels for different architectures might
> be simpler solution for my needs at the moment.

The main problem with the initrd is that it is very difficult to build one 
that doesn't exactly match your existing system.

So if you have a running machine with one hard drive and you want to add 
another and make it use software RAID, or if you want to convert to devfs 
then things will be quite painful for you as the initrd will want to work in 
the old way.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: problem setting up interlibrary dependencies

[Marcelo E. Magallon]

On Sun, Jul 13, 2003 at 11:30:43AM -0400, Aaron M. Ucko wrote:

 > Right.  I would moreover like for the GL variant to supersede the
 > non-GL variant when both are installed, since that's what the
 > GL-neutral higher-level libraries will be linking against.

 Let me sketch something for you...

 Package: libvibrant6
 Depends: whatever

 Package: libvibrant6-gl
 Depends: whatever, libgl1
 Provides: libvibrant6
 Replaces: libvibrant6
 Conflicts: libvibrant6

 Package: libvibrant-dev
 Depends: whatever, libvibrant6

 Package: libvibrant-gl-dev
 Depends: whatever, libvibrant6-gl, libgl-dev
 Provides: libvibrant-dev
 Replaces: libvibrant-dev
 Conflicts: libvibrant-dev

 How does this look on the filesystem?

 Package: libvibrant6

/usr/lib/libvibrant.so.6.0.0
/usr/lib/libvibrant.so.6 -> libvibrant.so.6.0.0

 Package: libvibrant-dev
/usr/lib/libvibrant.so -> libvibrant.so.6

 Package: libvibrant6-gl

/usr/lib/libvibrant.so.6.0.0
/usr/lib/libvibrant.so.6 -> libvibrant.so.6.0.0

 Package: libvibrant-gl-dev
/usr/lib/libvibrant.so -> libvibrant.so.6

 The NEEDS of libvibrant6's libvibrant.so.6:

libc.so.6
libsomething.so.1
libanother.so.2

 The NEEDS of libvibrant6-gl's libvibrant.so.6:

libc.so.6
libsomething.so.1
libanother.so.2
libGL.so.1

 The shlibs for libvibrant6:

libvibrant 6 libvibrant6

 The shlibs for libvibrant6-gl:

libvibrant 6 libvibrant6-gl

 Now let's compile something:

 gcc -c doesntneedGL.c
 gcc -o doesntneedGL doesntneedGL.o -lvibrant

 That works with either of the -dev libraries.  The resulting binary
 works with either library.  What about needsGL.c?

 gcc -c needsGL.c
 gcc -o needsGL needsGL.o -lvibrant

 That will work only if libvibrant-gl-dev is installed.  The resulting
 binary will only work if libvibrant6-gl is installed.

 Now there's a package that needs to make sure it won't be compiled with
 the GL variant (for whatever reason):

 Build-Depends: libvibrant-dev
 Build-Conflicts: libvibrant-gl-dev

 Does that satisfy your needs?  Note that I have simply ignored your
 (implicit) request for a solution that let's you install libvibrant6
 and libvibrant6-gl at the same time.  I have also made the assumption
 that libvibrant's API is sane (and ABI likewise).  This solution
 depends on knowledge about the innerworkings of dpkg-shlibdeps _and_
 the GNU linker _and_ the Linux dynamic linker.  Note furthermore that
 there's a certain assumption about upstream not being of the "it's
 binary forwards compatible" persuassion (what happens if upstream
 decides to introduce a new function call but not modify the SONAME --
 hint, think versioned provides).

 Question: does upstream make a distinction at the link-line level if
 the library has or hasn't OpenGL support?  It's important for
 compatibility with other distributions.

 HTH,

 Marcelo

Bug#201125: ITP: par2 -- Parity Archive v2

[Steve Lamb]

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


* Package name: par2
  Version : 0.2
  Upstream Author : Peter Brian Clements <[EMAIL PROTECTED]>
* URL : http://parchive.sorceforge.net/
* License : (GPL)
  Description : Parity Archive v2

 This utility applies the data-recover capability concepts of RAID-like
 systems to individual and multiple files.  It is most commonly used in 
 the posting and recovery of multipart archives on Usenet.
 .
 It supports the 'Reed-Soloman Code' implementation that allows for
 recovery of any X blocks for X parity blocks present.  It is popularly
 used on USENET postings but is not limited to this use.
 .
 Upstream source: http://parchive.sourceforge.net/

(I have contacted Rene Weber, maintainer of parchive, to see if he(?)
intends to package par2.  Barring interest within the next week or so I
would like maintain this package.  As of this writing I have a package
put together which passes lintian but does have a few problems.  Namely
the build-depends is not correct and it installs 4 man pages when 1 with
3 symlinks will do.  I am not a current maintainer and will be looking
to become a maintainer for this and other packages.)

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux teleute 2.4.21 #1 SMP Sat Jul 5 17:29:22 PDT 2003 i686
Locale: LANG=C, LC_CTYPE=C

Re: problem setting up interlibrary dependencies

[Steve Langasek]

On Sun, Jul 13, 2003 at 06:51:57PM +0200, Marcelo E. Magallon wrote:

> Note furthermore that there's a certain assumption about upstream not 
> being of the "it's binary forwards compatible" persuassion (what 
> happens if upstream decides to introduce a new function call but not 
> modify the SONAME -- hint, think versioned provides).

There should even be a way around this:

  Package: libvibrant6-gl
  Depends: whatever, libgl1
  Replaces: libvibrant6
  Conflicts: libvibrant6

(no Provides:)

And in the shlibs for libvibrant6:

 libvibrant 6 libvibrant6 (>> current-version) | libvibrant6-gl (>> 
current-version)

The disadvantage of this one is, as you noted, that you can't have both
dev packages installed at the same time.  Actually, you can't have
libvibrant-dev and libvibrant6-gl installed at the same time either (and
the Conflicts: of libvibrant-dev should reflect this), because it's
impossible to deterministically choose which lib to link to at runtime
if both are installed.  But since neither of the other approaches seemed
to win Aaron over, I think this option is worth examining as well.

-- 
Steve Langasek
postmodern programmer


pgpiAL9VeDQAp.pgp
Description: PGP signature

Re: problem setting up interlibrary dependencies

[Marcelo E. Magallon]

On Sun, Jul 13, 2003 at 12:10:39PM -0500, Steve Langasek wrote:

 >   Package: libvibrant6-gl
 >   Depends: whatever, libgl1
 >   Replaces: libvibrant6
 >   Conflicts: libvibrant6
 > 
 > (no Provides:)
 > 
 > And in the shlibs for libvibrant6:
 > 
 >  libvibrant 6 libvibrant6 (>> current-version) | libvibrant6-gl (>> 
 > current-version)

 Oh!  Yes, that's a nice solution for the versioned provides problem.
 I'll keep it in mind.

 Marcelo

Re: default MTA for sarge

[Sean 'Shaleh' Perry]

On Sunday 13 July 2003 06:26, Sebastian Kapfer wrote:
>
> I know, but that location (/var/mail/root) is discouraged, isn't it? The
> admin shouldn't read his/her mail under uid 0. That's why I think that
> exim should ask this question when it is configured for local delivery (or
> in "newbie" mode ;-)
>
> The best solution (at least for the average user which doesn't care about
> his MTA) would IMHO be a question along the lines of "Which user account
> should receive messages for the system administrator?" I.e. not even
> mentioning the technical details. The word "mail" might be misleading
> here.
>
> Just thinking aloud... I have not installed any exim4 yet, and I know how
> to get exim3 to do local delivery. But Debian should become a more
> user-friendly OS after all, right?
>

The issue here is what Steve Greenland mentioned directly and I alluded to 
when I started this thread -- many, many desktop users will use external 
(ISP, work) provided SMTP and POP/IMAP.  So that email goes no where useful.  
Their MTA won't read the local queue.  I am a pretty savvy fellow and I don't 
even use the local MTA except to send mail via reportbug.

Re: Qt3 still broken (compat-headers), what to do?

[Anthony Towns]

On Sun, Jul 13, 2003 at 11:44:38AM -0400, Evan Prodromou wrote:
> > "AT" == Anthony Towns  writes:
> BB> Hmm?  Are you saying that sarge is definitively well over a
> BB> year away?
> AT> If he is, he's wrong.
> Hubris! Famous last words! The pride what cometh before a fall!

Not hubris, mere precision: sarge _might_ be well over a year away,
but it's not _definitively_ over a year away.

For those playing along at home (and if you're not, why not?) the debcamp
bugsquash stuff is being tracked at:

http://dc1.raw.no/~ajt/rcbugs.cgi

There's no way for non debcamp types to list bugs there, maybe someone
would like to remedy that; I'm sure it's a simple exercise to work out
how. (Note that the bugs.debian.org urls linked from there will cease to
work by the end of debcamp; hopefully we'll hook something up permanently
to make up for it by then though)

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


pgpDDMYFohnUV.pgp
Description: PGP signature

Re: default MTA for sarge

[Sean 'Shaleh' Perry]

On Sunday 13 July 2003 02:24, Sean 'Shaleh' Perry wrote:
>
> I would lean towards exim4 configured for local delivery only.  It is a
> sane default for just about every system.  The admins who know they want
> another MTA can easily replace exim and the users who have no clue what a
> MTA does have one installed quietly and securely waiting for the day they
> might want more from it.
>
> Enough of a Linux system assumes that a MTA is present that not installing
> any would be wrong.  Asking an user which MTA they want is equally wrong
> because many users have no clue what one is.

I have one more comment about this.

In another post I mentioned that the only reason I have a local mail daemon 
setup on some machines is to allow reportbug to work.  It occurs to me that 
perhaps (*PERHAPS*) during the install we could query:

"Hi, are you connected to an ISP that you use for all of your email 
sending/receiving needs?  Or perhaps this is a workstation setup inside a 
corporate setting?  If so in the blanks below please provided the name of the 
SMTP server as well as the IMAP4 or POP3 server you use."  These settings are 
provided by their ISP or IT staff and asking for them should not be 
completely confusing.  Especially with a bit of sugar text.

We could store this value and then *ANY* app that needed the setting could 
just look it up.  Perhaps asking about proxys as well.

A few questions like this would go a LONG way to making the initial install 
much easier for those interested in a functioning desktop.  In particular 
laptop users are a very interesting subset of users who do not want much of a 
traditional Linux / Unix setup.

I suppose this is a side rant/suggestion for "let's have some generic meta 
configuration questions rather than only tying them to specific packages".  
Perhaps not a sarge solution but something to consider.  Discussions on this 
probably need to fork off to a new thread but starting here made sense.

Re: Bug#201125: ITP: par2 -- Parity Archive v2

[Andreas Metzler]

Steve Lamb <[EMAIL PROTECTED]> wrote:
> * Package name: par2
>  Version : 0.2
>  Upstream Author : Peter Brian Clements <[EMAIL PROTECTED]>
> * URL : http://parchive.sorceforge.net/
> * License : (GPL)
>  Description : Parity Archive v2

> This utility applies the data-recover capability concepts of RAID-like
> systems to individual and multiple files.  It is most commonly used in 
> the posting and recovery of multipart archives on Usenet.
[...]
> (I have contacted Rene Weber, maintainer of parchive, to see if he(?)
> intends to package par2.
[...]

Hello,
Is there a good reason why this is called par2 instead of parchive2?
Take a look at apt-cache show par
  cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: default MTA for sarge

[Bernd Eckenfels]

On Sun, Jul 13, 2003 at 10:26:18AM -0700, Sean 'Shaleh' Perry wrote:
> In another post I mentioned that the only reason I have a local mail daemon 
> setup on some machines is to allow reportbug to work.  It occurs to me that 
> perhaps (*PERHAPS*) during the install we could query:

what about cron mails? I realy think /usr/sbin/sendmail should a mta which
is able to deliver mails, for the sake of administrative mails. This
includes reportbug, cron, some MUAs, and even debconf or dpkg-listchanges.

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: Work-needing packages report for Jul 11, 2003

[cermi]

>> Oh dear, Ted T'so just uploaded it and assumed maintainership...
> I assume what was meant was that a prospective DD was interested in
> adopting the package?
But Ted T'so could be his sponsor now that he has hijacked judy.
 
I've cc-ed Eduardo Cermeño as I think he's not on this list yet. 

Actually I was not in the list. Thanks for the message.
I was pretty interested in that package, but for sure I will be much slower 
that Theodore, so I will have no problem with whatever solution
you may find better. Just tell me (now I'll check debian-devel list). 

Greets
Eduardo 

Re: the RFC mess: tentative summary

[Blars Blarson]

Does it seem ironic to others that documents titled "Request for
Comments" can't be quoted while making comments on them?

(This is a flame of the current IETF, which has goals contrary to the
people who originally designed the Internet.)
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
"Text is a way we cheat time." -- Patrick Nielsen Hayden