questions diverses liées à la construction d'un paquet

[Alexandre Pineau]

Bonjour,

2 petites questions :

1- Il est recommendé ($5.2 charte debian) de repréciser la section et la 
priorité
d'un paquet binaire. 
Si ce n'est pas fait les paquets binaires héritent t-ils de la section et de la 
priorité
indiquées dans le paquet source?

2- Quelle est la fonction de .PHONY dans le script rule?

Merci pour votre aide.

Alexandre

Re: questions diverses liées à la construction d'un paquet

[Ralf Treinen]

On Sun, Jul 13, 2003 at 11:34:38AM +0200, Alexandre Pineau wrote:

 2- Quelle est la fonction de .PHONY dans le script rule?

C'est expliqué dans la documentation de GNU make :

   A phony target is one that is not really the name of a file.  It is
just a name for some commands to be executed when you make an explicit
request.  There are two reasons to use a phony target: to avoid a
conflict with a file of the same name, and to improve performance.

Pour en savoir plus voir les pages texinfo de make.

-Ralf.
-- 

Re: quel nom pour une locale fr_geek ?

[Martin Quinson]

On Fri, Jul 11, 2003 at 09:02:25PM +0200, Alain Tesio wrote:

 Si on veut absolument un mot français bien de chez nous, il faut le définir
 dès la création du concept, là c'est un peu tard.

Dis moi comment tu traduis package, et je te dirais quel type de geek tu es.

Si tu laisse package, ben tu cause assez anglais pour laisser LC_ALL=C.
C'est tout a ton honneur, mais souvient toi que c'est pas le cas de tout le
monde, et que c'est pour tout le monde qu'on traduit.

Maintenant, si tu dis paquetage (si tu suis les recommandations KDE) ou
paquet (si tu suis celles de Debian), j'aimerais que t'explique comment on
a reussi a imposer ces mots tout ce qu'il y a de francais plusieurs annees
apres la creation du concept Paquet logiciel.

Je comprend pas cette tempete dans un verre d'eau pour courriel. J'ai
l'impression que c'est la derniere reaction cutanee des anciens avant que
tout le monde ne l'utilise, ie dans 2 ans au maximum, tout comme on a
assiste a la guerre du package y'a un moment.

Non, vraiment, a part le fait qu'il est nouveau, qu'est ce que vous
reprochez a ce mot ? D'etre francais et donc moins branché (pardon, in) ?


 Je trouve ça d'autant plus ridicule de traduire par courriel à cause du l à 
 la fin.
 Pourquoi un l, parce qu'en anglais c'est email.

Ben non. Relit cette discussion.
 
 Et d'abord comment on traduit geek ?

Et avant ca, comment le prononce-t-on ?

Vous qui avez appris l'americain sur votre linux, sachez que si vous dites
jik, vous allez avoir ridicule. C'est guik.

C'est peut etre le plus ridicule de cette habitude actuelle a coller des
mots d'anglais dans les textes en francais. On sait pas les prononcer, et ca
nous aidera donc pas a parler avec des ricains quand l'occasion se
presentera. Et la plupart du temps, on utilise le mot anglais en dehors de
son sens original (grace aux faux amis), Et il arrive meme. comble du
ridicule, que le mot anglais utilise n'existe pas en anglais. Comme, faire
le forcing, invoquant plus des methodes sado-maso aux anglophones qu'autre
chose...

Non, serieux, si on traduit, on traduit en francais [correct], Et si non, on
laisse LC_ALL=C et on est pas confronte aux horreurs de sa langue.



Bye, Mt.

PS: Ca n'a plus rien a voir avec la question d'origine de Cyrile demandant
comment faire des craderies dans son coin, ce qui est legitime puisqu'il le
veut.

-- 
2+2 = 5 ... Pour d'assez grandes valeurs de 2

Re: problem setting up interlibrary dependencies

[Steve Langasek]

On Sat, Jul 12, 2003 at 11:05:54PM -0400, Aaron M. Ucko wrote:
 I'm running into difficulties getting vibrant6 [1] to comply with the
 new policy requiring full inter-library dependencies.  The source of
 the complication is that two of the libraries come in OpenGL and
 non-OpenGL variants, but certain intervening libraries are
 OpenGL-agnostic and therefore come in only one variant.

 Since OpenGL is a pretty hefty dependency, I'd like to avoid it if
 possible, and not have the intermediate libraries indirectly require
 it; on the other hand, the GL-enabled variant of the higher-level
 library (ncbicn3d) specifically needs the GL-enabled variant of the
 lower-level library (vibrant) in order to work properly.  I would also
 like for packages that request linkage against plain vibrant not to
 end up depending on the GL variant, even if built on systems with the
 GL variant installed.  (On the other hand, packages that specifically
 try to link against the GL variant should get it)

 I haven't quite been able to come up with a reasonable arrangement
 that satisfies all of these constraints.  The closest I've come up
 with so far falls apart the moment ldconfig runs:

 BASELINE:
 libvibrant-nogl.so.6.1.date: real file, soname libvibrant.so.6
 libvibrant-nogl.so.6 - libvibrant-nogl.so.6.1.date
 [libvibrant-nogl.so - libvibrant-nogl.so.6.1.date]
 [libvibrant.so - libvibrant-nogl.so]

 WITHOUT libvibrant6-gl:
 libvibrant.so.6 - libvibrant-nogl.so.6

 WITH libvibrant6-gl:
 libvibrantOGL.so.6.1.date: real file, soname libvibrantOGL.so.6
 libvibrantOGL.so.6 - libvibrantOGL.so.6.1.date
 [libvibrantOGL.so - libvibrantOGL.so.6.1.date]
 libvibrant.so.6 - libvibrantOGL.so.6 (clobbered by ldconfig :-/)

 I could perhaps kludge around this by having libvibrant6-gl also
 contain a dummy library with a soname of libvibrant.so.6 that pulls in
 libvibrantOGL.so.6 and sorts after libvibrant-nogl.so.6.1.date, but
 that would be gross, and lead to odd-looking ldd output.

 Any suggestions?  Should I just punt and force everyone to use the
 OpenGL version?  (That would certainly be simplest, but I'd really
 prefer to avoid the dependency bloat if I can.)

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.

I see two possible strategies here.

1) Divide the library into two parts: one which provides the non-GL
functions, and one which provides *only* the GL functions.  This
provides a clear delineation of the functionality of each package; the
downside is that you (or upstream) would have to do a fair amount of
work to implement such a split, and you may have private functions that
have to be shared (rather, duplicated) between the two libs.

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.

-- 
Steve Langasek
postmodern programmer


pgpYfLM3roLOs.pgp
Description: PGP signature

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

[Steve Langasek]

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.

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

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.

 I therefore see this is as a release-critical usability problem, which the 
 BTS and policy have no formal concept of.

I think that would be counted as 'grave'.

-- 
Steve Langasek
postmodern programmer


pgpAKaCWgS8O5.pgp
Description: PGP signature

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]  http://www.debian.org/%7Esrivasta/
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
Answer 

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
Enter 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-0073200PG=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] http://azure.humbug.org.au/~aj/
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
 Enter 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
 Enter 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 aj@azure.humbug.org.au 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 aj@azure.humbug.org.au 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] http://azure.humbug.org.au/~aj/
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

Accepted debootstrap 0.1.17.31 (i386 source)

[J.H.M. Dassen (Ray)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 08:52:55 +0200
Source: debootstrap
Binary: debootstrap-udeb debootstrap
Architecture: source i386
Version: 0.1.17.31
Distribution: unstable
Urgency: medium
Maintainer: J.H.M. Dassen (Ray) [EMAIL PROTECTED]
Changed-By: J.H.M. Dassen (Ray) [EMAIL PROTECTED]
Description: 
 debootstrap - Bootstrap a basic Debian system
 debootstrap-udeb - Bootstrap the Debian system (udeb)
Changes: 
 debootstrap (0.1.17.31) unstable; urgency=medium
 .
   * [sid] Follow debconf changes. debconf now Depends: debconf-i18n |
 debconf-english; debconf-i18n having Priority: important and
 debconf-english having Priority: extra, so we satisfy the dependency
 through debconf-i18n. debconf-i18n in turn pulls in three additional
 packages: liblocale-gettext-perl, libtext-wrapi18n-perl,
 libtext-charwidth-perl .
Files: 
 53c6b6c51159bf614035b920f4af50d8 840 admin extra debootstrap_0.1.17.31.dsc
 6e5e62da1e03588acc2762d8e1cbbb69 23840 admin extra debootstrap_0.1.17.31.tar.gz
 9c7ebdfadf47acc8b2c331f579ed54e2 43242 debian-installer extra 
debootstrap-udeb_0.1.17.31_i386.udeb
 ce327fb5fe89c8da913a7a883b5f27fd 56134 admin extra debootstrap_0.1.17.31_i386.deb

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

iQEXAwUBPxEDhAxJU8feGmjHFAIXtwP/aG9vPoRFH71/Xk7NnzWKd9o5psf2R+66
sDvLvCHhPaDrMgRXMb7BCfdIa7eaipqkduxOxUehAIrBL43CzEHqr4AkcrLS1Lch
4Rv7CtvZDNKZk6nK/oEKoRJhHBqcr+N2JMoJe47yaCKzo+EWPY7Wwrg3eVBok6AH
/qqUDtc98rkD/3vBMoRf78KiCScSfQ3SViQwD1gvGijuR9ShqCP2J+4Wr++cewAQ
qKxHbXbPqP69EIisKsgQ7w7AhzTVjt1KAuwXG0VWdA4p7ISmYhRDIc9uZEJMMuK4
91U7wOyPvdv62IL7eGNfgiUNy0n+SUwExVRV7ji0825bXk6v615GTtM5
=Rq94
-END PGP SIGNATURE-


Accepted:
debootstrap-udeb_0.1.17.31_i386.udeb
  to pool/main/d/debootstrap/debootstrap-udeb_0.1.17.31_i386.udeb
debootstrap_0.1.17.31.dsc
  to pool/main/d/debootstrap/debootstrap_0.1.17.31.dsc
debootstrap_0.1.17.31.tar.gz
  to pool/main/d/debootstrap/debootstrap_0.1.17.31.tar.gz
debootstrap_0.1.17.31_i386.deb
  to pool/main/d/debootstrap/debootstrap_0.1.17.31_i386.deb


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

Accepted base-installer 0.024 (all source)

[Petter Reinholdtsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 10:05:07 +0200
Source: base-installer
Binary: kernel-installer base-installer
Architecture: source all
Version: 0.024
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team [EMAIL PROTECTED]
Changed-By: Petter Reinholdtsen [EMAIL PROTECTED]
Description: 
 base-installer - Install the base system (udeb)
 kernel-installer - Install the kernel (udeb)
Changes: 
 base-installer (0.024) unstable; urgency=low
 .
   * Add dash-udeb as a dependency for base-installer, while we wait for
 busybox-udeb being able to run debootstrap.
Files: 
 b017b450dd7bda93d77a3cd60e3c1d12 609 debian-installer required 
base-installer_0.024.dsc
 cefcb69d95ae2cbba443293abfc82e35 12745 debian-installer required 
base-installer_0.024.tar.gz
 8abc0d6fd05ab77514d91c818693c7bf 2582 debian-installer required 
base-installer_0.024_all.udeb
 60e1f6f6ef1c8eee1d61b69f4ea23e30 5012 debian-installer required 
kernel-installer_0.024_all.udeb

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

iD8DBQE/ERL020zMSyow1ykRAgUeAKC6OGCP16YUrENUDti9UbiEAbQ/tQCgoFy3
dsagHUUVIgbcBJ+tyQY5SvU=
=VvJw
-END PGP SIGNATURE-


Accepted:
base-installer_0.024.dsc
  to pool/main/b/base-installer/base-installer_0.024.dsc
base-installer_0.024.tar.gz
  to pool/main/b/base-installer/base-installer_0.024.tar.gz
base-installer_0.024_all.udeb
  to pool/main/b/base-installer/base-installer_0.024_all.udeb
kernel-installer_0.024_all.udeb
  to pool/main/b/base-installer/kernel-installer_0.024_all.udeb


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

Accepted scoop 0.9.0-12 (all source)

[Brian Nelson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 01:15:51 -0700
Source: scoop
Binary: scoop scoop-doc
Architecture: source all
Version: 0.9.0-12
Distribution: unstable
Urgency: medium
Maintainer: Brian Nelson [EMAIL PROTECTED]
Changed-By: Brian Nelson [EMAIL PROTECTED]
Description: 
 scoop  - Web-based collaborative media application
 scoop-doc  - Documentation for scoop
Closes: 192703 200343
Changes: 
 scoop (0.9.0-12) unstable; urgency=medium
 .
   * Use debian/compat instead of DH_COMPAT=n in debian/rules.
   * Added the homepage to the description.
   * Removed unnecessary dh_testroot from debian/rules clean target.
   * Bumped up standards version.
   * debian/rules: use debhelper to install stuff.
   * Added doc-base support.
   * Use ucf for conffile handling.
   * Removed Create a new DB debconf question, and only create the DB if
 no old one exists.
   * Only run the update-db.pl script on true upgrades based on the version
 string passed to the postinst.
   * Default to sending mail to webmaster, lowered debconf priority of
 question.
   * Moved #DEBHELPER# token in postrm after db_get call.
   * Postrm script fails gracefully if unable to connect to DB.
 (Closes: #192703)
   * Insert the Include /etc/scoop/apache.conf statement commented out in
 apache's httpd.conf file if modperl is not getting loaded.
 (Closes: #200343)
   * Added a NEWS.Debian file with a note about ucf usage.
Files: 
 5a00dc02fc0fbe5a132c1e690ffbd3fc 571 web optional scoop_0.9.0-12.dsc
 fca13029d55b1aa66c38894859379f7a 11130 web optional scoop_0.9.0-12.diff.gz
 b7c44efbd820723c363094eeb46f47bf 428734 web optional scoop_0.9.0-12_all.deb
 01e66de85db03d70cbd2e0b7a35bffa5 112696 doc optional scoop-doc_0.9.0-12_all.deb

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

iD8DBQE/ERcF1Ng1YWbyRSERAgIVAJ94FRhPjJZchKmc7u0Rl6AoUUNr9wCeIcdx
+L9xTXyeN3fkDa2F/+mbdkc=
=Su3a
-END PGP SIGNATURE-


Accepted:
scoop-doc_0.9.0-12_all.deb
  to pool/main/s/scoop/scoop-doc_0.9.0-12_all.deb
scoop_0.9.0-12.diff.gz
  to pool/main/s/scoop/scoop_0.9.0-12.diff.gz
scoop_0.9.0-12.dsc
  to pool/main/s/scoop/scoop_0.9.0-12.dsc
scoop_0.9.0-12_all.deb
  to pool/main/s/scoop/scoop_0.9.0-12_all.deb


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

Accepted debconf 1.3.2 (all source)

[Joey Hess]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 10:18:35 +0200
Source: debconf
Binary: debconf-english debconf-doc debconf-utils debconf-i18n debconf
Architecture: source all
Version: 1.3.2
Distribution: unstable
Urgency: low
Maintainer: Joey Hess [EMAIL PROTECTED]
Changed-By: Joey Hess [EMAIL PROTECTED]
Description: 
 debconf- Debian configuration management system
 debconf-doc - debconf documentation
 debconf-english - small footprint English-only debconf
 debconf-i18n - full internationalization support for debconf
 debconf-utils - debconf utilities
Closes: 201017 201018 201018 201019 201024
Changes: 
 debconf (1.3.2) unstable; urgency=low
 .
   * The free meals all week release.
   * Do the debconf-utils doc dir transition in its postinst, not preinst.
 Closes: #201018, #201024, #201019, #201018, #201017
Files: 
 96394c3ce8e3c44b6d0751e4abd79315 675 admin optional debconf_1.3.2.dsc
 49263c9a8baf0eeb93b043c0c1398d1b 277674 admin optional debconf_1.3.2.tar.gz
 5df4c6d28a72ae015eeeae2ef9b6a54f 87710 admin important debconf_1.3.2_all.deb
 886053350150bf594011321762d61933 51318 admin important debconf-i18n_1.3.2_all.deb
 d2bb8a66ef215aef84b1364121e97dfd 848 admin extra debconf-english_1.3.2_all.deb
 97a1b1dc862f74cc8f11deb098c5babc 161872 doc optional debconf-doc_1.3.2_all.deb
 b43554a232caca8e064ba05b64ec22ea 36280 devel optional debconf-utils_1.3.2_all.deb

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

iD8DBQE/ERaI2tp5zXiKP0wRAnEhAJ0Up6l93+RR6Azfy8nboejlHyucygCdH+Xn
2Er7BkYJ1r8I6H9hOxDDe9c=
=WAT3
-END PGP SIGNATURE-


Accepted:
debconf-doc_1.3.2_all.deb
  to pool/main/d/debconf/debconf-doc_1.3.2_all.deb
debconf-english_1.3.2_all.deb
  to pool/main/d/debconf/debconf-english_1.3.2_all.deb
debconf-i18n_1.3.2_all.deb
  to pool/main/d/debconf/debconf-i18n_1.3.2_all.deb
debconf-utils_1.3.2_all.deb
  to pool/main/d/debconf/debconf-utils_1.3.2_all.deb
debconf_1.3.2.dsc
  to pool/main/d/debconf/debconf_1.3.2.dsc
debconf_1.3.2.tar.gz
  to pool/main/d/debconf/debconf_1.3.2.tar.gz
debconf_1.3.2_all.deb
  to pool/main/d/debconf/debconf_1.3.2_all.deb


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

Accepted sylpheed-claws 0.9.3claws-1 (i386 source)

[Gustavo Noronha Silva]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 03:35:36 -0300
Source: sylpheed-claws
Binary: sylpheed-claws
Architecture: source i386
Version: 0.9.3claws-1
Distribution: unstable
Urgency: low
Maintainer: Gustavo Noronha Silva [EMAIL PROTECTED]
Changed-By: Gustavo Noronha Silva [EMAIL PROTECTED]
Description: 
 sylpheed-claws - Bleeding edge version of the Sylpheed mail client
Closes: 194072
Changes: 
 sylpheed-claws (0.9.3claws-1) unstable; urgency=low
 .
   * New upstream release
   * According to bugzilla the IMAP problem has been fixed between
 0.9.0 and 0.9.3 (there was no 0.9.1 nor 0.9.2, it seems)
 See http://www.thewildbeast.co.uk/sylpheed-claws/bugzilla/show_bug.cgi?id=161
 (Closes: #194072)
   * debian/control:
   - Build-Depends on flex | flex-old
Files: 
 ab0567af494a98497fd2c0b564b33636 982 mail extra sylpheed-claws_0.9.3claws-1.dsc
 ee0ca11ad31acf07f89b44ef720072bb 3665936 mail extra 
sylpheed-claws_0.9.3claws.orig.tar.gz
 d96958d2db5076876a122a060b8f8159 81431 mail extra sylpheed-claws_0.9.3claws-1.diff.gz
 c1fa5b08f952c0f024d93584e6d0d239 3100842 mail extra 
sylpheed-claws_0.9.3claws-1_i386.deb

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

iD8DBQE/ERrMt1anjIgqbEsRAkwxAJ93uF88qnvPixpN+LLiiq6bjm6IQwCfYHwF
IaH6CRyWpcD3jWXnDh4EGkY=
=QUtw
-END PGP SIGNATURE-


Accepted:
sylpheed-claws_0.9.3claws-1.diff.gz
  to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.3claws-1.diff.gz
sylpheed-claws_0.9.3claws-1.dsc
  to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.3claws-1.dsc
sylpheed-claws_0.9.3claws-1_i386.deb
  to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.3claws-1_i386.deb
sylpheed-claws_0.9.3claws.orig.tar.gz
  to pool/main/s/sylpheed-claws/sylpheed-claws_0.9.3claws.orig.tar.gz


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

Accepted debconf 1.3.3 (all source)

[Joey Hess]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 12:16:09 +0200
Source: debconf
Binary: debconf-english debconf-doc debconf-utils debconf-i18n debconf
Architecture: source all
Version: 1.3.3
Distribution: unstable
Urgency: low
Maintainer: Joey Hess [EMAIL PROTECTED]
Changed-By: Joey Hess [EMAIL PROTECTED]
Description: 
 debconf- Debian configuration management system
 debconf-doc - debconf documentation
 debconf-english - small footprint English-only debconf
 debconf-i18n - full internationalization support for debconf
 debconf-utils - debconf utilities
Changes: 
 debconf (1.3.3) unstable; urgency=low
 .
   * FORCE_DIALOG is now renamed to DEBCONF_FORCE_DIALOG, and documented.
 Also, it now simply sets the preference; if dialog is not installed
 debconf will use whiptail with this variable set.
Files: 
 37d5f6f3fd881b0e8e476be63b1e5fe7 675 admin optional debconf_1.3.3.dsc
 fec9771f97be29085956c40829302cc5 277802 admin optional debconf_1.3.3.tar.gz
 6a2292efc042d271e6366fc5fd37161e 87654 admin important debconf_1.3.3_all.deb
 8335ddd6bb9057b2c046b48606a4d2c5 51306 admin important debconf-i18n_1.3.3_all.deb
 f70d73e0492d06f766ba9acc2dea7a03 850 admin extra debconf-english_1.3.3_all.deb
 7ed6864da5edbe1d41cbae948787b778 162042 doc optional debconf-doc_1.3.3_all.deb
 85e7f182e21500587caa898776548c86 36278 devel optional debconf-utils_1.3.3_all.deb

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

iD8DBQE/ETTS2tp5zXiKP0wRAszeAKDUC5BI0eN/UihqxYOwh/fOz/IMaQCfaWEm
X5JGfJn8Wg5NSb2jAPj7Qy4=
=jkGf
-END PGP SIGNATURE-


Accepted:
debconf-doc_1.3.3_all.deb
  to pool/main/d/debconf/debconf-doc_1.3.3_all.deb
debconf-english_1.3.3_all.deb
  to pool/main/d/debconf/debconf-english_1.3.3_all.deb
debconf-i18n_1.3.3_all.deb
  to pool/main/d/debconf/debconf-i18n_1.3.3_all.deb
debconf-utils_1.3.3_all.deb
  to pool/main/d/debconf/debconf-utils_1.3.3_all.deb
debconf_1.3.3.dsc
  to pool/main/d/debconf/debconf_1.3.3.dsc
debconf_1.3.3.tar.gz
  to pool/main/d/debconf/debconf_1.3.3.tar.gz
debconf_1.3.3_all.deb
  to pool/main/d/debconf/debconf_1.3.3_all.deb


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

Accepted newt 0.51.4-11 (i386 source)

[Alastair McKinstry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 14 Jul 2003 10:16:11 +0100
Source: newt
Binary: libnewt-dev libnewt-pic libnewt0.51 newt-tcl whiptail python-newt
Architecture: source i386
Version: 0.51.4-11
Distribution: unstable
Urgency: low
Maintainer: Alastair McKinstry [EMAIL PROTECTED]
Changed-By: Alastair McKinstry [EMAIL PROTECTED]
Description: 
 libnewt-dev - Developer's toolkit for newt windowing library
 libnewt-pic - Not Erik's Windowing Toolkit, shared library subset kit
 libnewt0.51 - Not Erik's Windowing Toolkit - text mode windowing with slang
 newt-tcl   - A newt module for Tcl
 python-newt - A NEWT module for Python
 whiptail   - Displays user-friendly dialog boxes from shell scripts
Closes: 195775 198800
Changes: 
 newt (0.51.4-11) unstable; urgency=low
 .
   * Fixed misleading colors in compact buttons. Closes: #195775,#198800.
   * Updated to policy 3.6.0; no changes needed.
Files: 
 4c36f2f4e79c856bafbcb45fea54ecdf 740 devel optional newt_0.51.4-11.dsc
 0165d65dc47ff8e88d1142a93ff9d9b3 63431 devel optional newt_0.51.4-11.diff.gz
 ca891093d0835be7cc6f29bad60eada5 44584 base standard libnewt0.51_0.51.4-11_i386.deb
 0425fcc00bd4af03f0dc3be72fde1ae6 67610 libdevel optional 
libnewt-dev_0.51.4-11_i386.deb
 3f5c2e688f35a845ec3d182dbc0efad3 46450 libdevel extra libnewt-pic_0.51.4-11_i386.deb
 334bbad6252a98b3d2cd567dab37ba5c 21916 interpreters extra newt-tcl_0.51.4-11_i386.deb
 5a7760d2623474d0afd5620d6d75ad1d 29134 python standard python-newt_0.51.4-11_i386.deb
 e854d3e2e5f1ac70ec5a385ea332985e 26868 base standard whiptail_0.51.4-11_i386.deb

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

iD8DBQE/ES0K+o43kJBROPQRArppAKDeAzRMKqluLtzNI3YcnQdwfQ1ccQCgjSPk
85FEUxBOhWr7bXLwezJfHI8=
=kXLi
-END PGP SIGNATURE-


Accepted:
libnewt-dev_0.51.4-11_i386.deb
  to pool/main/n/newt/libnewt-dev_0.51.4-11_i386.deb
libnewt-pic_0.51.4-11_i386.deb
  to pool/main/n/newt/libnewt-pic_0.51.4-11_i386.deb
libnewt0.51_0.51.4-11_i386.deb
  to pool/main/n/newt/libnewt0.51_0.51.4-11_i386.deb
newt-tcl_0.51.4-11_i386.deb
  to pool/main/n/newt/newt-tcl_0.51.4-11_i386.deb
newt_0.51.4-11.diff.gz
  to pool/main/n/newt/newt_0.51.4-11.diff.gz
newt_0.51.4-11.dsc
  to pool/main/n/newt/newt_0.51.4-11.dsc
python-newt_0.51.4-11_i386.deb
  to pool/main/n/newt/python-newt_0.51.4-11_i386.deb
whiptail_0.51.4-11_i386.deb
  to pool/main/n/newt/whiptail_0.51.4-11_i386.deb


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

Accepted workman 1.3.4-13 (i386 source)

[Volker Ossenkopf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 12:20:00 +0200
Source: workman
Binary: workman
Architecture: source i386
Version: 1.3.4-13
Distribution: unstable
Urgency: low
Maintainer: Volker Ossenkopf [EMAIL PROTECTED]
Changed-By: Volker Ossenkopf [EMAIL PROTECTED]
Description: 
 workman- Graphical tool for playing audio CDs on a CD-ROM drive
Changes: 
 workman (1.3.4-13) unstable; urgency=low
 .
   * fixed postinst script to accept all device locations (#197784)
   * added several checks in config and postinst scripts
   * adjusted German translation
Files: 
 d90c7b5e2c6192a2119322b16396c21a 634 sound optional workman_1.3.4-13.dsc
 4cbeabc791eca5c328990eb247baa212 20746 sound optional workman_1.3.4-13.diff.gz
 92edf38a8b4e03f4a9d383b34d3714a7 113890 sound optional workman_1.3.4-13_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/ETPfilantJo6v0gRAgrnAKCcTmcGJTtbffFlwAjnNYzzDAYG0wCfQk9M
U9h8sVCC2X65DgkJHQwJzMw=
=FPlQ
-END PGP SIGNATURE-


Accepted:
workman_1.3.4-13.diff.gz
  to pool/main/w/workman/workman_1.3.4-13.diff.gz
workman_1.3.4-13.dsc
  to pool/main/w/workman/workman_1.3.4-13.dsc
workman_1.3.4-13_i386.deb
  to pool/main/w/workman/workman_1.3.4-13_i386.deb


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

Accepted uqwk 2.21-5 (i386 source)

[Peter Karlsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 11:00:00 +0100
Source: uqwk
Binary: uqwk-spool uqwk
Architecture: source i386
Version: 2.21-5
Distribution: unstable
Urgency: low
Maintainer: Peter Karlsson [EMAIL PROTECTED]
Changed-By: Peter Karlsson [EMAIL PROTECTED]
Description: 
 uqwk   - Offline mail and news package creator (NNTP version)
 uqwk-spool - Offline mail and news package creator (spool version)
Closes: 199338 199643
Changes: 
 uqwk (2.21-5) unstable; urgency=low
 .
   * Switched to po-debconf.
(Closes: Bug#199338)
   * Added French translation for debconf templates.
(Closes: Bug#199643)
Files: 
 cca2eb019f85b380cf4e29e1ebff18ed 558 comm optional uqwk_2.21-5.dsc
 806fa9f0220c5f996e28c5e11eb051a0 7173 comm optional uqwk_2.21-5.diff.gz
 b18fe65e5f98a7a69c276d183e7d0369 68516 comm optional uqwk_2.21-5_i386.deb
 c9ac072cb3f0ec2468d8a49a5ae1056b 63718 comm optional uqwk-spool_2.21-5_i386.deb

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

iD8DBQE/ETHUkryUdmOUJl4RAqvOAJwOUKd0/9mUM6Pv22Z0thPF+bit1QCfdS5Q
5bZP8G9t/Pneoi4WX8uPo94=
=RcTD
-END PGP SIGNATURE-


Accepted:
uqwk-spool_2.21-5_i386.deb
  to pool/main/u/uqwk/uqwk-spool_2.21-5_i386.deb
uqwk_2.21-5.diff.gz
  to pool/main/u/uqwk/uqwk_2.21-5.diff.gz
uqwk_2.21-5.dsc
  to pool/main/u/uqwk/uqwk_2.21-5.dsc
uqwk_2.21-5_i386.deb
  to pool/main/u/uqwk/uqwk_2.21-5_i386.deb


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

Accepted larch 1.0pre0+-3 (i386 source)

[Andrew Suffield]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 11:19:40 +0100
Source: larch
Binary: larch
Architecture: source i386
Version: 1.0pre0+-3
Distribution: unstable
Urgency: low
Maintainer: Andrew Suffield [EMAIL PROTECTED]
Changed-By: Andrew Suffield [EMAIL PROTECTED]
Description: 
 larch  - revision control system
Closes: 201061
Changes: 
 larch (1.0pre0+-3) unstable; urgency=low
 .
   * Fix the pesky libexec-install-dir path (again) (closes: #201061)
Files: 
 398ccc095bae4db4cd88f26046458745 570 devel optional larch_1.0pre0+-3.dsc
 790c781a44ec47c6c86fc0152d905065 20525 devel optional larch_1.0pre0+-3.diff.gz
 e59a268e781f332bd292ab34aec09fdb 1464806 devel optional larch_1.0pre0+-3_i386.deb

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

iD8DBQE/ET03lpK98RSteX8RAjtwAJ43NU9VoDnsaV7z16fx/5X1eAIivACghp3k
qiBhaqbzM/cItfVIRSPKoyY=
=Zwgk
-END PGP SIGNATURE-


Accepted:
larch_1.0pre0+-3.diff.gz
  to pool/main/l/larch/larch_1.0pre0+-3.diff.gz
larch_1.0pre0+-3.dsc
  to pool/main/l/larch/larch_1.0pre0+-3.dsc
larch_1.0pre0+-3_i386.deb
  to pool/main/l/larch/larch_1.0pre0+-3_i386.deb


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

Accepted camstream 0.26.2-7 (i386 source)

[Aurelien Jarno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 12:38:25 +0200
Source: camstream
Binary: camstream
Architecture: source i386
Version: 0.26.2-7
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 camstream  - collection of tools for webcams and other video-devices
Changes: 
 camstream (0.26.2-7) unstable; urgency=low
 .
   * Create the video devices if a user does not already have them.
Files: 
 9e7cf16bf80fb6b5627f2f27301ebb51 646 misc optional camstream_0.26.2-7.dsc
 e5fe8c716e6d3d2a3079eae22abe2cc2 55304 misc optional camstream_0.26.2-7.diff.gz
 f8fed7b969ca5fed50670962cb2416e1 1564342 misc optional camstream_0.26.2-7_i386.deb

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

iD8DBQE/ET5dw3ao2vG823MRAh1XAKCGdw9zsx2shoZ8xMWtdRAbXV1oEwCghkbp
8F3t5nctdc9xbPhXOVCcH1c=
=z+y3
-END PGP SIGNATURE-


Accepted:
camstream_0.26.2-7.diff.gz
  to pool/main/c/camstream/camstream_0.26.2-7.diff.gz
camstream_0.26.2-7.dsc
  to pool/main/c/camstream/camstream_0.26.2-7.dsc
camstream_0.26.2-7_i386.deb
  to pool/main/c/camstream/camstream_0.26.2-7_i386.deb


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

Accepted libphp-adodb 3.60-3 (all source)

[Thorsten Sauter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 25 Jun 2003 23:16:36 +0200
Source: libphp-adodb
Binary: libphp-adodb
Architecture: source all
Version: 3.60-3
Distribution: unstable
Urgency: low
Maintainer: Thorsten Sauter [EMAIL PROTECTED]
Changed-By: Thorsten Sauter [EMAIL PROTECTED]
Description: 
 libphp-adodb - The 'adodb' database abstraction layer for php
Closes: 198722
Changes: 
 libphp-adodb (3.60-3) unstable; urgency=low
 .
   * Include french translation. (Closes: #198722)
Files: 
 d8b19751c5702926863fed037205be6b 589 web optional libphp-adodb_3.60-3.dsc
 e1745edd43574e433ec167778805ea4f 4683 web optional libphp-adodb_3.60-3.diff.gz
 e1cdb9fc33a817dda9e6117ec59efc5a 287092 web optional libphp-adodb_3.60-3_all.deb

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

iD8DBQE/EUCllJsl7AdEclIRArzMAJwPWRRY7eLfEJ2ebiRnv4TKhIFJsgCgr6EK
UkgReATes5btt7ziwlM+fmg=
=fKJM
-END PGP SIGNATURE-


Accepted:
libphp-adodb_3.60-3.diff.gz
  to pool/main/libp/libphp-adodb/libphp-adodb_3.60-3.diff.gz
libphp-adodb_3.60-3.dsc
  to pool/main/libp/libphp-adodb/libphp-adodb_3.60-3.dsc
libphp-adodb_3.60-3_all.deb
  to pool/main/libp/libphp-adodb/libphp-adodb_3.60-3_all.deb


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

Accepted pyca 20030710-1 (all source)

[Lars Bahner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 13:38:18 +0200
Source: pyca
Binary: pyca
Architecture: source all
Version: 20030710-1
Distribution: unstable
Urgency: low
Maintainer: Lars Bahner [EMAIL PROTECTED]
Changed-By: Lars Bahner [EMAIL PROTECTED]
Description: 
 pyca   - Certification Authority written in python
Changes: 
 pyca (20030710-1) unstable; urgency=low
 .
   * New upstream release
Files: 
 f43ecf729c0f07cbc0a495ab18f9f632 496 net optional pyca_20030710-1.dsc
 5310bdf232ed074950eb1b1cf08e7e39 95477 net optional pyca_20030710-1.tar.gz
 9054587ca8ef97856d84ea39bab7818e 92968 net optional pyca_20030710-1_all.deb

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

iD8DBQE/EUYmST2D3l3mxdYRAgCHAKDm5AXlp/hena3G+ukGBkYY3iXtkACfReU8
ToqRGTxBGHvqJr5ut5WRMQU=
=XSvq
-END PGP SIGNATURE-


Accepted:
pyca_20030710-1.dsc
  to pool/main/p/pyca/pyca_20030710-1.dsc
pyca_20030710-1.tar.gz
  to pool/main/p/pyca/pyca_20030710-1.tar.gz
pyca_20030710-1_all.deb
  to pool/main/p/pyca/pyca_20030710-1_all.deb


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

Accepted udftools 1.0.0b2-3 (i386 source)

[Richard Atterer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 12:05:58 +0200
Source: udftools
Binary: udftools
Architecture: source i386
Version: 1.0.0b2-3
Distribution: unstable
Urgency: low
Maintainer: Richard Atterer [EMAIL PROTECTED]
Changed-By: Richard Atterer [EMAIL PROTECTED]
Description: 
 udftools   - Tools for UDF filesystems and DVD/CD-R(W) drives
Closes: 199829 200443
Changes: 
 udftools (1.0.0b2-3) unstable; urgency=low
 .
   * Added init script which calls pktsetup during startup for devices
 configured in /etc/default/udftools. Original version of script by
 Aleksandar Topuzovic - thanks!
   * Updated config.guess/sub just for the fun of it.
   * gettext support for debconf templates by Michel Grentzinger
 (thanks!), closes: #199829
   * French translation of debconf templates, closes: #200443
Files: 
 a95ccea4e171a78dded9bc8010bd4ea2 576 otherosfs extra udftools_1.0.0b2-3.dsc
 d67a3eea2f10b6201dd6f9532e8e71ba 22054 otherosfs extra udftools_1.0.0b2-3.diff.gz
 a16c1f4c6a65a29f5200981463655d40 44462 otherosfs extra udftools_1.0.0b2-3_i386.deb

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

iD8DBQE/EUozeeb23IiDVPcRAj/mAKCnoHnqWX6SMppR5XObJ1hUtprnqgCfXmas
Os4VmDqPTTif9M0Y/Yo/MpE=
=0aP/
-END PGP SIGNATURE-


Accepted:
udftools_1.0.0b2-3.diff.gz
  to pool/main/u/udftools/udftools_1.0.0b2-3.diff.gz
udftools_1.0.0b2-3.dsc
  to pool/main/u/udftools/udftools_1.0.0b2-3.dsc
udftools_1.0.0b2-3_i386.deb
  to pool/main/u/udftools/udftools_1.0.0b2-3_i386.deb


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

Accepted quota 3.09-1 (i386 source)

[Michael Meskes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 14:36:44 +0200
Source: quota
Binary: quota
Architecture: source i386
Version: 3.09-1
Distribution: unstable
Urgency: low
Maintainer: Michael Meskes [EMAIL PROTECTED]
Changed-By: Michael Meskes [EMAIL PROTECTED]
Description: 
 quota  - An implementation of the disk quota system
Closes: 200787
Changes: 
 quota (3.09-1) unstable; urgency=low
 .
   * New upstream version, closes: #200787
Files: 
 220406c58a9f0cec5a9c4df85a3214f9 841 admin optional quota_3.09-1.dsc
 e2ad4291ec209c37c6435b04a350d873 207197 admin optional quota_3.09-1.tar.gz
 b31db1737c1a4b5b836b9558cea27b3d 368684 admin optional quota_3.09-1_i386.deb

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

iQEXAwUBPxFS7utBmxovbdBzFAI39AQApgnhMBrQthkjCrGcQ7ljB4vhJV29mof7
wdfrfHssielHjsYXFauXfzUuQV2lbmYLim+Q+lYkTuWSSohu4AnYxfvHi+akc4hJ
afxefumbicAhdef45ccZQi8BLqswJiIxAR/1CrcMHGz+3lYWFfYvkx6OQwHjsRni
BBIhNnQBd2oD/RyOkGVMjNw7K0b9/+SCWhcibi9Sf+CXLFgA43mnUG63+qifSVLd
JtGNeBgh4Y+Zy5nnF5ngrHo6LBwSjm8UgfRdp+hsAP2F/ZcGBub4YiN8DdBXNK8/
TNmuQ23jZOd5b5ZBLIXRvd9aOa15BAq3p2Vow0/X9ci19GtqIs4fscmd
=lQSG
-END PGP SIGNATURE-


Accepted:
quota_3.09-1.dsc
  to pool/main/q/quota/quota_3.09-1.dsc
quota_3.09-1.tar.gz
  to pool/main/q/quota/quota_3.09-1.tar.gz
quota_3.09-1_i386.deb
  to pool/main/q/quota/quota_3.09-1_i386.deb


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

Accepted linuxsms 0.66-1 (all source)

[Santiago Garcia Mantinan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 13:54:13 +0200
Source: linuxsms
Binary: linuxsms
Architecture: source all
Version: 0.66-1
Distribution: unstable
Urgency: low
Maintainer: Santiago Garcia Mantinan [EMAIL PROTECTED]
Changed-By: Santiago Garcia Mantinan [EMAIL PROTECTED]
Description: 
 linuxsms   - Cool script in Perl to send SMS messages to GSM phones
Changes: 
 linuxsms (0.66-1) unstable; urgency=low
 .
   * New upstream version.
Files: 
 b40e3d3cd9498b1623e6eabf500e0977 578 comm optional linuxsms_0.66-1.dsc
 2e60a168506a999ec5994e03c4e7311b 35336 comm optional linuxsms_0.66.orig.tar.gz
 e9e91457c395d6e84b955f0bd94a61e9 2528 comm optional linuxsms_0.66-1.diff.gz
 8e96621bdac7d3e68941b26ef81edc24 34066 comm optional linuxsms_0.66-1_all.deb

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

iD8DBQE/EUjKcv3CBfajKo4RAh5NAJ9CD4317bquRw8kZL1ktDUtLdZrYQCffm1U
x/dKfzCC8atnbLbkB6tI+C0=
=u0af
-END PGP SIGNATURE-


Accepted:
linuxsms_0.66-1.diff.gz
  to pool/main/l/linuxsms/linuxsms_0.66-1.diff.gz
linuxsms_0.66-1.dsc
  to pool/main/l/linuxsms/linuxsms_0.66-1.dsc
linuxsms_0.66-1_all.deb
  to pool/main/l/linuxsms/linuxsms_0.66-1_all.deb
linuxsms_0.66.orig.tar.gz
  to pool/main/l/linuxsms/linuxsms_0.66.orig.tar.gz


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

Accepted chrony 1.19-10 (i386 source)

[John Hasler]

-BEGIN PGP SIGNED MESSAGE-

Format: 1.7
Date: Sun, 13 Jul 2003 7:00:00 -0500
Source: chrony
Binary: chrony
Architecture: source i386
Version: 1.19-10
Distribution: unstable
Urgency: low
Maintainer: John Hasler [EMAIL PROTECTED]
Changed-By: John Hasler [EMAIL PROTECTED]
Description: 
 chrony - Sets your computer's clock from time servers on the Net
Changes: 
 chrony (1.19-10) unstable; urgency=low
 .
   * Put linux/linkage.h ahead of linux/spinlock.h as I meant to in
 the first place.
Files: 
 fa55990b5ea9e2862a3afe11ca07d684 686 admin extra chrony_1.19-10.dsc
 3e92c155d9bc227ada0583beb9782046 142200 admin extra chrony_1.19-10.diff.gz
 df43c6a7151796b5c20897f1706dd48b 291382 admin extra chrony_1.19-10_i386.deb

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

iQCVAwUBPxFTX/c1CeQKxb5hAQEkRQP+Oiqn42xHCDjpyrN5XdhmDgHqidkVtsc0
3UFw+uI1PGJGjdODvWeUCbHTDh3gCwrwY+EQmOfieOaGWj5PlSyUk4vwZprZa2hQ
mTSwF9jqvf0aqX6+l03x9Avjv+t198YxHeFbWoFpi/4kVJwJojIO9Y5fJvU2MCRl
0F0eJFRrzzI=
=1I8v
-END PGP SIGNATURE-


Accepted:
chrony_1.19-10.diff.gz
  to pool/main/c/chrony/chrony_1.19-10.diff.gz
chrony_1.19-10.dsc
  to pool/main/c/chrony/chrony_1.19-10.dsc
chrony_1.19-10_i386.deb
  to pool/main/c/chrony/chrony_1.19-10_i386.deb


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

Accepted ninvaders 0.1.1-1 (i386 source)

[Matthew Palmer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 22:57:37 +1000
Source: ninvaders
Binary: ninvaders
Architecture: source i386
Version: 0.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Matthew Palmer [EMAIL PROTECTED]
Changed-By: Matthew Palmer [EMAIL PROTECTED]
Description: 
 ninvaders  - A space invaders-like game using ncurses
Changes: 
 ninvaders (0.1.1-1) unstable; urgency=low
 .
   * New upstream release.
   * Standards version bumped to 3.6.0.
   * Build-depends on debhelper 4.
Files: 
 f40f9141c6f9cb75c07009f6d4aba8a3 627 games optional ninvaders_0.1.1-1.dsc
 97b2c3fb082241ab5c56ab728522622b 31275 games optional ninvaders_0.1.1.orig.tar.gz
 302e1fb3639771927cb3819b96cb5682 10285 games optional ninvaders_0.1.1-1.diff.gz
 5a489234806327031fe49cdb6dd0b90d 13222 games optional ninvaders_0.1.1-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/EVgYBEnrTWk1E4cRAuRpAJ0bnWBKTenhDMqaoGTYKJAIFyIr2ACdFeQL
bShDGUveo2g8dHzeh3obTNs=
=JyHS
-END PGP SIGNATURE-


Accepted:
ninvaders_0.1.1-1.diff.gz
  to pool/main/n/ninvaders/ninvaders_0.1.1-1.diff.gz
ninvaders_0.1.1-1.dsc
  to pool/main/n/ninvaders/ninvaders_0.1.1-1.dsc
ninvaders_0.1.1-1_i386.deb
  to pool/main/n/ninvaders/ninvaders_0.1.1-1_i386.deb
ninvaders_0.1.1.orig.tar.gz
  to pool/main/n/ninvaders/ninvaders_0.1.1.orig.tar.gz


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

Accepted mol-drivers-macosx 0.9.69+20030713-1 (powerpc source)

[Jens Schmalzing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 13:24:12 +0200
Source: mol-drivers-macosx
Binary: mol-drivers-macosx
Architecture: source powerpc
Version: 0.9.69+20030713-1
Distribution: unstable
Urgency: low
Maintainer: Jens Schmalzing [EMAIL PROTECTED]
Changed-By: Jens Schmalzing [EMAIL PROTECTED]
Description: 
 mol-drivers-macosx - The Mac-on-Linux emulator - drivers for Mac OS X
Changes: 
 mol-drivers-macosx (0.9.69+20030713-1) unstable; urgency=low
 .
   * Took a snapshot of the rsync tree.
Files: 
 91bd8b18cb486660ad6b0a99cd4572e3 641 non-free/otherosfs optional 
mol-drivers-macosx_0.9.69+20030713-1.dsc
 78ad5a216625912489f7a1496ee11d2b 174856 non-free/otherosfs optional 
mol-drivers-macosx_0.9.69+20030713.orig.tar.gz
 a9f0e96942d44434ff49c924246d861d 9526 non-free/otherosfs optional 
mol-drivers-macosx_0.9.69+20030713-1.diff.gz
 0625c75d5e38baaad159cf15af7f6ff0 184360 non-free/otherosfs optional 
mol-drivers-macosx_0.9.69+20030713-1_powerpc.deb

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

iD8DBQE/EUGDqYZgyBJFIH4RAoAHAKDO57IKny9bVdPY1zZsJ+W4sX9adQCg4ouK
U5MoWWvuqzRSlMjW+RZJPnQ=
=vAOW
-END PGP SIGNATURE-


Accepted:
mol-drivers-macosx_0.9.69+20030713-1.diff.gz
  to pool/non-free/m/mol-drivers-macosx/mol-drivers-macosx_0.9.69+20030713-1.diff.gz
mol-drivers-macosx_0.9.69+20030713-1.dsc
  to pool/non-free/m/mol-drivers-macosx/mol-drivers-macosx_0.9.69+20030713-1.dsc
mol-drivers-macosx_0.9.69+20030713-1_powerpc.deb
  to 
pool/non-free/m/mol-drivers-macosx/mol-drivers-macosx_0.9.69+20030713-1_powerpc.deb
mol-drivers-macosx_0.9.69+20030713.orig.tar.gz
  to pool/non-free/m/mol-drivers-macosx/mol-drivers-macosx_0.9.69+20030713.orig.tar.gz


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

Accepted mol 0.9.69+20030713-1 (powerpc source)

[Jens Schmalzing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 13:30:59 +0200
Source: mol
Binary: mol mol-modules-2.4.20 mol-modules-2.4.21 mol-modules-source
Architecture: source powerpc
Version: 0.9.69+20030713-1
Distribution: unstable
Urgency: low
Maintainer: Jens Schmalzing [EMAIL PROTECTED]
Changed-By: Jens Schmalzing [EMAIL PROTECTED]
Description: 
 mol- The Mac-on-Linux emulator
 mol-modules-2.4.20 - The Mac-on-Linux emulator - kernel modules for 2.4.20
 mol-modules-2.4.21 - The Mac-on-Linux emulator - kernel modules for 2.4.21
 mol-modules-source - The Mac-on-Linux emulator - source for kernel modules
Changes: 
 mol (0.9.69+20030713-1) unstable; urgency=low
 .
   * Took a snapshot of the rsync tree.
 .
   * mol now supports generic SCSI under Mac OS X.
Files: 
 93f3e797567eabfeb11b6ef4f68c051e 773 otherosfs optional mol_0.9.69+20030713-1.dsc
 d494b4c33424342d8a823fa0a3aedae0 1239101 otherosfs optional 
mol_0.9.69+20030713.orig.tar.gz
 060ee7cb7500322e4c7ef162e6947a62 17095 otherosfs optional 
mol_0.9.69+20030713-1.diff.gz
 e32460c370dd1c5751a995758c614ce6 949206 otherosfs optional 
mol_0.9.69+20030713-1_powerpc.deb
 39202b5895d358aa356b4b880ce44f90 130904 otherosfs optional 
mol-modules-source_0.9.69+20030713-1_powerpc.deb
 0c8032fd180757a81f2fb9c429125086 39354 otherosfs optional 
mol-modules-2.4.20_0.9.69+20030713-1_powerpc.deb
 4ea5c8bb906e42b3a27d868074379eef 39342 otherosfs optional 
mol-modules-2.4.21_0.9.69+20030713-1_powerpc.deb

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

iD8DBQE/EUXCqYZgyBJFIH4RAqL9AJ0ZZXqb/PCp2efmOhuoHVLMCKPY6QCeNrXp
W9lOe0MgpgUHnBaBvCpGkcI=
=uwNE
-END PGP SIGNATURE-


Accepted:
mol-modules-2.4.20_0.9.69+20030713-1_powerpc.deb
  to pool/main/m/mol/mol-modules-2.4.20_0.9.69+20030713-1_powerpc.deb
mol-modules-2.4.21_0.9.69+20030713-1_powerpc.deb
  to pool/main/m/mol/mol-modules-2.4.21_0.9.69+20030713-1_powerpc.deb
mol-modules-source_0.9.69+20030713-1_powerpc.deb
  to pool/main/m/mol/mol-modules-source_0.9.69+20030713-1_powerpc.deb
mol_0.9.69+20030713-1.diff.gz
  to pool/main/m/mol/mol_0.9.69+20030713-1.diff.gz
mol_0.9.69+20030713-1.dsc
  to pool/main/m/mol/mol_0.9.69+20030713-1.dsc
mol_0.9.69+20030713-1_powerpc.deb
  to pool/main/m/mol/mol_0.9.69+20030713-1_powerpc.deb
mol_0.9.69+20030713.orig.tar.gz
  to pool/main/m/mol/mol_0.9.69+20030713.orig.tar.gz


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

Accepted njamd 0.9.3pre2-5 (i386 source)

[Eddie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  9 Jul 2003 23:26:54 +1100
Source: njamd
Binary: njamd
Architecture: source i386
Version: 0.9.3pre2-5
Distribution: unstable
Urgency: low
Maintainer: [EMAIL PROTECTED]
Changed-By: Sam Eddie Couter [EMAIL PROTECTED]
Description: 
 njamd  - Not Just Another Malloc Debugger
Closes: 167052
Changes: 
 njamd (0.9.3pre2-5) unstable; urgency=low
 .
   * Modify to build with CDBS.
   * Fix macro quoting in configure.in (closes: Bug#167052).
 Thanks to Steve Langasek [EMAIL PROTECTED].
   * Disable building of the front-end, since it doesn't build anyway.
Files: 
 737edd1d6768f0aa5c6bf5c325b68d6f 608 devel optional njamd_0.9.3pre2-5.dsc
 48658b6d9ac99de91706f34fcc608f53 42242 devel optional njamd_0.9.3pre2-5.diff.gz
 5d85d5dccf1da157045b351ed6ee4484 44102 devel optional njamd_0.9.3pre2-5_i386.deb

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

iD8DBQE/EVryhTADrt6Jx1wRAnKwAJ4nlfgrwZql5R6eQYfkVN8M2dtNigCbBLdg
EeDWFwVh6EPA8E2vMVOiWdE=
=0/1U
-END PGP SIGNATURE-


Accepted:
njamd_0.9.3pre2-5.diff.gz
  to pool/main/n/njamd/njamd_0.9.3pre2-5.diff.gz
njamd_0.9.3pre2-5.dsc
  to pool/main/n/njamd/njamd_0.9.3pre2-5.dsc
njamd_0.9.3pre2-5_i386.deb
  to pool/main/n/njamd/njamd_0.9.3pre2-5_i386.deb


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

Accepted postnews 0.5.3-2 (all source)

[Peter Karlsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 13 Jul 2003 14:00:00 +0100
Source: postnews
Binary: postnews
Architecture: source all
Version: 0.5.3-2
Distribution: unstable
Urgency: low
Maintainer: Peter Karlsson [EMAIL PROTECTED]
Changed-By: Peter Karlsson [EMAIL PROTECTED]
Description: 
 postnews   - Post Usenet articles via NNTP from the command line
Closes: 187066
Changes: 
 postnews (0.5.3-2) unstable; urgency=low
 .
   * Removed mention of non-existant info files from manual page.
(Closes: Bug#187066)
Files: 
 f6b104b88f38d1df5d1b97dd88722e91 570 net extra postnews_0.5.3-2.dsc
 a7c262fb38b55a394d0ca23f680f1bda 2048 net extra postnews_0.5.3-2.diff.gz
 96374dfe9e061bfa008c997002b7a84e 4434 net extra postnews_0.5.3-2_all.deb

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

iD8DBQE/EVv9kryUdmOUJl4RAra4AKCTHAAmwHDDjPf8anRNLEGpPcXEtACePOPl
DO57KxaiLIAa+TVl3CLHet4=
=XqlQ
-END PGP SIGNATURE-


Accepted:
postnews_0.5.3-2.diff.gz
  to pool/main/p/postnews/postnews_0.5.3-2.diff.gz
postnews_0.5.3-2.dsc
  to pool/main/p/postnews/postnews_0.5.3-2.dsc
postnews_0.5.3-2_all.deb
  to pool/main/p/postnews/postnews_0.5.3-2_all.deb


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

Accepted gtk+2.0 2.2.2-1 (i386 source all)

[Akira TAGOH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 21:26:49 +0900
Source: gtk+2.0
Binary: libgtk2.0-dev libgtk2.0-0png3 libgtk2.0-dbg libgtk2.0-0 libgtk2.0-doc 
gtk2.0-examples libgtk2.0-common
Architecture: source i386 all
Version: 2.2.2-1
Distribution: unstable
Urgency: low
Maintainer: Akira TAGOH [EMAIL PROTECTED]
Changed-By: Akira TAGOH [EMAIL PROTECTED]
Description: 
 gtk2.0-examples - Examples files for the GTK+ 2.0
 libgtk2.0-0 - The GTK+ graphical user interface library
 libgtk2.0-0png3 - Dummy package for libgtk2.0-0
 libgtk2.0-common - Common files for the GTK+ graphical user interface library
 libgtk2.0-dbg - The GTK+ libraries and debugging symbols
 libgtk2.0-dev - Development files for the GTK+ library
 libgtk2.0-doc - Documentation for the GTK+ graphical user interface library
Closes: 182073 187858 192136 193774 200350
Changes: 
 gtk+2.0 (2.2.2-1) unstable; urgency=low
 .
   * New upstream release. (closes: Bug#200350)
 - Fixed threadlocks on GtkTreeView. (closes: Bug#192136)
 - Fixed the crash on moving the cursor when the cursor is invisible.
   (closes: Bug#187858)
 - Fixed the compose table for ascending order. (closes: Bug#182073)
   * debian/control:
 - fix the FTBFS. Thanks to Daniel Baeyens.
 - bumped Standards-Version to 3.6.0.
   * debian/rules:
 - removed dh_undocumented.
 - don't claim the newer shlibs.
   * debian/patches/:
 - 000_gtk+-2.2.1-gdk_event_copy_for_xinput.patch: removed.
 - 000_gtk+-2.2.1-gdk_visual_get_best_with_depth.patch: removed.
 - 000_gtk+-2.2.1-gtk_text_line_previous_could_contain_tag.patch: removed.
 - 000_gtk+-2.2.1-gtktreeview-scroll.patch: removed.
 - 000_gtk+-debian-xinerama-pic.patch: updated.
 - 001_gtk+-debian-aclocal.patch: removed.
 - 001_gtk+-ximian-gtk2-filesel-navbutton-5.patch: applied a Ximian patch
   to improve the GtkFileSel UI. Requested from Ross Burton.
 - 000_gtk+-2.2.2-non-weak-symbols.patch: applied to fix the undefined non
   weak symbols. (closes: Bug#193774)
Files: 
 905eab5e12ffc704f404f873ffda399a 880 libs optional gtk+2.0_2.2.2-1.dsc
 aaeaf589e844fe8ab85ec2b8df1e1ae2 9864672 libs optional gtk+2.0_2.2.2.orig.tar.gz
 3e22fe7e20b09d7a3da2cb2f95882e36 72617 libs optional gtk+2.0_2.2.2-1.diff.gz
 ec8e15b9398e2c55d3daac92482b49d4 1441522 doc optional libgtk2.0-doc_2.2.2-1_all.deb
 ec6c8ecf7860b91ec7ff3dc9615cfa37 1728254 libs optional libgtk2.0-0_2.2.2-1_i386.deb
 c47aa97f2eaa968c82eac82cd6601df4 1461544 misc optional 
libgtk2.0-common_2.2.2-1_i386.deb
 a3f615cc2fc07cf143dee633defd1b24 2145916 libdevel optional 
libgtk2.0-dev_2.2.2-1_i386.deb
 3415d68db060332aab327b63feabfd4e 8217638 libdevel extra libgtk2.0-dbg_2.2.2-1_i386.deb
 17326eece6336e8d5dc4ecc8d816a2d4 238040 x11 extra gtk2.0-examples_2.2.2-1_i386.deb
 d5b3c9591eb3370749d02172e62d38a3 25756 libs optional libgtk2.0-0png3_2.2.2-1_i386.deb

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

iD8DBQE/EVoB2QCnNZ2xmQQRAlX2AJ9iMoN0TX7MooB4lSOqQuYZGX3ergCfVqnH
FLK7RcrOTIXbDvGcleesUMI=
=YkZS
-END PGP SIGNATURE-


Accepted:
gtk+2.0_2.2.2-1.diff.gz
  to pool/main/g/gtk+2.0/gtk+2.0_2.2.2-1.diff.gz
gtk+2.0_2.2.2-1.dsc
  to pool/main/g/gtk+2.0/gtk+2.0_2.2.2-1.dsc
gtk+2.0_2.2.2.orig.tar.gz
  to pool/main/g/gtk+2.0/gtk+2.0_2.2.2.orig.tar.gz
gtk2.0-examples_2.2.2-1_i386.deb
  to pool/main/g/gtk+2.0/gtk2.0-examples_2.2.2-1_i386.deb
libgtk2.0-0_2.2.2-1_i386.deb
  to pool/main/g/gtk+2.0/libgtk2.0-0_2.2.2-1_i386.deb
libgtk2.0-0png3_2.2.2-1_i386.deb
  to pool/main/g/gtk+2.0/libgtk2.0-0png3_2.2.2-1_i386.deb
libgtk2.0-common_2.2.2-1_i386.deb
  to pool/main/g/gtk+2.0/libgtk2.0-common_2.2.2-1_i386.deb
libgtk2.0-dbg_2.2.2-1_i386.deb
  to pool/main/g/gtk+2.0/libgtk2.0-dbg_2.2.2-1_i386.deb
libgtk2.0-dev_2.2.2-1_i386.deb
  to pool/main/g/gtk+2.0/libgtk2.0-dev_2.2.2-1_i386.deb
libgtk2.0-doc_2.2.2-1_all.deb
  to pool/main/g/gtk+2.0/libgtk2.0-doc_2.2.2-1_all.deb


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

Accepted python-iconvcodec 1.1.1-2 (i386 source)

[Changwoo Ryu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 22:28:38 +0900
Source: python-iconvcodec
Binary: python2.1-iconvcodec python2.2-iconvcodec python2.3-iconvcodec
Architecture: source i386
Version: 1.1.1-2
Distribution: unstable
Urgency: low
Maintainer: Changwoo Ryu [EMAIL PROTECTED]
Changed-By: Changwoo Ryu [EMAIL PROTECTED]
Description: 
 python2.1-iconvcodec - Python universal Unicode codec, using iconv()
 python2.2-iconvcodec - Python universal Unicode codec, using iconv()
 python2.3-iconvcodec - Python universal Unicode codec, using iconv()
Closes: 201010
Changes: 
 python-iconvcodec (1.1.1-2) unstable; urgency=low
 .
   * Fixed a typo in Build-Depends: line (Closes: 201010).
Files: 
 552e09525a27800774c32182ea1dc59e 690 interpreters optional 
python-iconvcodec_1.1.1-2.dsc
 01690d4a8eb8cbe5492cd67734180418 4404 interpreters optional 
python-iconvcodec_1.1.1-2.diff.gz
 e5c94de6fb7978d384017eebc51b4c63 18558 interpreters optional 
python2.1-iconvcodec_1.1.1-2_i386.deb
 5de49a927a24f5617d01e6a842d712ef 19586 interpreters optional 
python2.2-iconvcodec_1.1.1-2_i386.deb
 7a9e131ae2b4e9a32510a5a85af6ef3c 20694 interpreters optional 
python2.3-iconvcodec_1.1.1-2_i386.deb

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

iD8DBQE/EV6mAbRzNODUnpkRAuwEAJ4s/d/a43SkE4KQib9CXXcQInVAagCfSA3F
Py1bbnG0/Ged6V9Dt1VkalA=
=SkPk
-END PGP SIGNATURE-


Accepted:
python-iconvcodec_1.1.1-2.diff.gz
  to pool/main/p/python-iconvcodec/python-iconvcodec_1.1.1-2.diff.gz
python-iconvcodec_1.1.1-2.dsc
  to pool/main/p/python-iconvcodec/python-iconvcodec_1.1.1-2.dsc
python2.1-iconvcodec_1.1.1-2_i386.deb
  to pool/main/p/python-iconvcodec/python2.1-iconvcodec_1.1.1-2_i386.deb
python2.2-iconvcodec_1.1.1-2_i386.deb
  to pool/main/p/python-iconvcodec/python2.2-iconvcodec_1.1.1-2_i386.deb
python2.3-iconvcodec_1.1.1-2_i386.deb
  to pool/main/p/python-iconvcodec/python2.3-iconvcodec_1.1.1-2_i386.deb


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

Accepted cccc 3.pre63-3 (i386 source)

[Colin Watson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 14:19:13 +0100
Source: 
Binary: 
Architecture: source i386
Version: 3.pre63-3
Distribution: unstable
Urgency: low
Maintainer: Colin Watson [EMAIL PROTECTED]
Changed-By: Colin Watson [EMAIL PROTECTED]
Description: 
    - C and C++ Code Counter, a software metrics tool
Closes: 196782
Changes: 
  (3.pre63-3) unstable; urgency=low
 .
   * Compile with -Wno-deprecated. These warnings are currently unimportant
 for Debian.
   * Set DEBUG=true so that we compile with -g.
   * Fix implicit typenames in _tbl.cc and _tbl.h (closes: #196782).
Files: 
 151ab9677ffddd9cbf3c60b3c794e1cf 628 devel optional _3.pre63-3.dsc
 c12b41f6b7b7525a68602e4b5771a877 3036 devel optional _3.pre63-3.diff.gz
 dcd46e27d2a0e5226b5d58edb36f213b 168556 devel optional _3.pre63-3_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Colin Watson [EMAIL PROTECTED] -- Debian developer

iD8DBQE/EWBp9t0zAhD6TNERAh/qAJ9SuYjf2A0q0kQFYhxC6XpsOmwoRACdFWfC
qUBqbnCPaM4BxWQaY6epVoY=
=gcvX
-END PGP SIGNATURE-


Accepted:
_3.pre63-3.diff.gz
  to pool/main/c//_3.pre63-3.diff.gz
_3.pre63-3.dsc
  to pool/main/c//_3.pre63-3.dsc
_3.pre63-3_i386.deb
  to pool/main/c//_3.pre63-3_i386.deb


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

Accepted lyskom-server 2.0.7-3 (i386 source)

[Peter Karlsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 14:30:00 +0100
Source: lyskom-server
Binary: lyskom-server
Architecture: source i386
Version: 2.0.7-3
Distribution: unstable
Urgency: medium
Maintainer: Peter Karlsson [EMAIL PROTECTED]
Changed-By: Peter Karlsson [EMAIL PROTECTED]
Description: 
 lyskom-server - Server for the LysKOM conference system
Closes: 198364 200360
Changes: 
 lyskom-server (2.0.7-3) unstable; urgency=medium
 .
   * Added Brazilian Portuguese and French translation of Debconf templates.
(Closes: Bug#198364, #200360)
   * Removed annoying use of a debconf note and put the relevant information
 in the README.Debian file instead.
Files: 
 34959d099a1a0756af39d1c59796c034 618 net extra lyskom-server_2.0.7-3.dsc
 162cfacda8784504956736bab9bf70b2 12172 net extra lyskom-server_2.0.7-3.diff.gz
 3510e8f4372b1a3577e1a83e93649e3d 438922 net extra lyskom-server_2.0.7-3_i386.deb

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

iD8DBQE/EWNjkryUdmOUJl4RAm8SAJ9kD3F22p3xBrSzbCy3ERqcXe74dgCdHSg1
nep++9i1ihNhBxg0TMpaPQg=
=hF0b
-END PGP SIGNATURE-


Accepted:
lyskom-server_2.0.7-3.diff.gz
  to pool/main/l/lyskom-server/lyskom-server_2.0.7-3.diff.gz
lyskom-server_2.0.7-3.dsc
  to pool/main/l/lyskom-server/lyskom-server_2.0.7-3.dsc
lyskom-server_2.0.7-3_i386.deb
  to pool/main/l/lyskom-server/lyskom-server_2.0.7-3_i386.deb


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

Accepted doc-iana 2003.07-1 (all source)

[Kai Henningsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 16:17:36 +0200
Source: doc-iana
Binary: doc-iana
Architecture: source all
Version: 2003.07-1
Distribution: unstable
Urgency: low
Maintainer: Kai Henningsen [EMAIL PROTECTED]
Changed-By: Kai Henningsen [EMAIL PROTECTED]
Description: 
 doc-iana   - Internet protocol parameter registry
Changes: 
 doc-iana (2003.07-1) unstable; urgency=low
 .
   * Docs as of 2003-07-13
Files: 
 2e6901bbb7b00b3722158a240f683b20 577 doc optional doc-iana_2003.07-1.dsc
 8fb3fb72c0340b8a0f06ac43861641cd 2366751 doc optional doc-iana_2003.07.orig.tar.gz
 36cf3403c63ba6f51cf6f5b08b936b22 4526 doc optional doc-iana_2003.07-1.diff.gz
 d67202b7d40afa07701b8bdef647aa79 2498092 doc optional doc-iana_2003.07-1_all.deb

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

iD8DBQE/EWzUDLdORU4m0pcRAk1bAKCsvJjLL2T97HvOevKSxuzNu9iT7ACfcC0M
kM1ZeW0bIwqGLephlSCXd40=
=ax2o
-END PGP SIGNATURE-


Accepted:
doc-iana_2003.07-1.diff.gz
  to pool/main/d/doc-iana/doc-iana_2003.07-1.diff.gz
doc-iana_2003.07-1.dsc
  to pool/main/d/doc-iana/doc-iana_2003.07-1.dsc
doc-iana_2003.07-1_all.deb
  to pool/main/d/doc-iana/doc-iana_2003.07-1_all.deb
doc-iana_2003.07.orig.tar.gz
  to pool/main/d/doc-iana/doc-iana_2003.07.orig.tar.gz


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

Accepted camstream 0.26.2-8 (i386 source)

[Aurelien Jarno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 16:28:39 +0200
Source: camstream
Binary: camstream
Architecture: source i386
Version: 0.26.2-8
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 camstream  - collection of tools for webcams and other video-devices
Changes: 
 camstream (0.26.2-8) unstable; urgency=low
 .
   * The Copy/Paste sucks release.
   * Fixed postinst script.
Files: 
 598dccbc1d4911c73a980510e1297722 646 misc optional camstream_0.26.2-8.dsc
 5cb9ced52a4f60faeef88d27ce92bfc9 55382 misc optional camstream_0.26.2-8.diff.gz
 b7f1c5b4215dd22e2176e4c9c41a0e2f 1564426 misc optional camstream_0.26.2-8_i386.deb

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

iD8DBQE/EXDQw3ao2vG823MRAlMXAJ9ItuCOgM9Oalb08Ed6L/PufnsJ3wCeI61f
6ZtFCnMUAv6GylvWTGjHr2w=
=b5+f
-END PGP SIGNATURE-


Accepted:
camstream_0.26.2-8.diff.gz
  to pool/main/c/camstream/camstream_0.26.2-8.diff.gz
camstream_0.26.2-8.dsc
  to pool/main/c/camstream/camstream_0.26.2-8.dsc
camstream_0.26.2-8_i386.deb
  to pool/main/c/camstream/camstream_0.26.2-8_i386.deb


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

Accepted lyskom-tty-client 0.13.alfa.8-3 (i386 source)

[Peter Karlsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 15:30:00 +0100
Source: lyskom-tty-client
Binary: lyskom-tty-client
Architecture: source i386
Version: 0.13.alfa.8-3
Distribution: unstable
Urgency: low
Maintainer: Peter Karlsson [EMAIL PROTECTED]
Changed-By: Peter Karlsson [EMAIL PROTECTED]
Description: 
 lyskom-tty-client - TTY client for LysKOM
Closes: 190377
Changes: 
 lyskom-tty-client (0.13.alfa.8-3) unstable; urgency=low
 .
   * Fixes in the English translation as well as the Swedish original strings.
(Closes: Bug#190377)
Files: 
 db7fb0926b9093fe097e0a90e1700b89 653 net extra lyskom-tty-client_0.13.alfa.8-3.dsc
 c02d3cbd72530998f0c12dd932616326 77144 net extra 
lyskom-tty-client_0.13.alfa.8-3.diff.gz
 685b0b347027d3421a05ec7b570bb696 101494 net extra 
lyskom-tty-client_0.13.alfa.8-3_i386.deb

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

iD8DBQE/EXL2kryUdmOUJl4RAiUYAKCIfpZNTuXuDzRn6Eo/ds2E73/w7ACgva/E
IwMtaVY8TYbTDqYeANzlXFg=
=usU5
-END PGP SIGNATURE-


Accepted:
lyskom-tty-client_0.13.alfa.8-3.diff.gz
  to pool/main/l/lyskom-tty-client/lyskom-tty-client_0.13.alfa.8-3.diff.gz
lyskom-tty-client_0.13.alfa.8-3.dsc
  to pool/main/l/lyskom-tty-client/lyskom-tty-client_0.13.alfa.8-3.dsc
lyskom-tty-client_0.13.alfa.8-3_i386.deb
  to pool/main/l/lyskom-tty-client/lyskom-tty-client_0.13.alfa.8-3_i386.deb


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

Accepted camstream 0.26.2-9 (i386 source)

[Aurelien Jarno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 17:51:26 +0200
Source: camstream
Binary: camstream
Architecture: source i386
Version: 0.26.2-9
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 camstream  - collection of tools for webcams and other video-devices
Changes: 
 camstream (0.26.2-9) unstable; urgency=low
 .
   * Don't ask the user before creating the devices as they are need by
 camstream.
   * Added a dependency on makedev.
Files: 
 dfd0af4862376e2a4c5b1d6e1d504001 643 misc optional camstream_0.26.2-9.dsc
 7248d511f430ec790e6e050b4f630c37 54329 misc optional camstream_0.26.2-9.diff.gz
 b6de5f3ae43ff62ca702574f186a54a6 1564096 misc optional camstream_0.26.2-9_i386.deb

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

iD8DBQE/EYP2w3ao2vG823MRAj4ZAJ91r8UX+Au5FdWPGVBdmhQRgyPaagCdHSxf
ppDmmVjnLgn/lGq/flFJgL8=
=z4VT
-END PGP SIGNATURE-


Accepted:
camstream_0.26.2-9.diff.gz
  to pool/main/c/camstream/camstream_0.26.2-9.diff.gz
camstream_0.26.2-9.dsc
  to pool/main/c/camstream/camstream_0.26.2-9.dsc
camstream_0.26.2-9_i386.deb
  to pool/main/c/camstream/camstream_0.26.2-9_i386.deb


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

Accepted smail 3.2.0.115-1 (i386 source)

[Hector Garcia]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 19:21:00 +0100
Source: smail
Binary: smail
Architecture: source i386
Version: 3.2.0.115-1
Distribution: unstable
Urgency: low
Maintainer: Hector Garcia [EMAIL PROTECTED]
Changed-By: Hector Garcia [EMAIL PROTECTED]
Description: 
 smail  - Electronic mail transport system
Closes: 23429 118493 168545 191182 196337 201048 201051
Changes: 
 smail (3.2.0.115-1) unstable; urgency=low
 .
   * New upstream version.
 - Added an option to not depend on dbm nor nbm. (Closes: #196337, #201048)
   * Added LC_ALL=C at begining of rules file prevents locales from breaking
 compilation. (Closes: #201051, #191182).
   * Changed all /var/spool/mail to /var/mail (Closes: #168545).
   * Fixed postinst to restart smail on upgrade. (Closes: #118493).
   * Lines on smailconfig are no longer than 80 chars. (Closes: #23429).
Files: 
 6051b0505d381c6d1ebcaa2c6058d006 612 mail extra smail_3.2.0.115-1.dsc
 95a8b20399ed62eb7ad8a7f7fb557258 974091 mail extra smail_3.2.0.115.orig.tar.gz
 33fd7720f1c79a543a617d7d55eda445 161283 mail extra smail_3.2.0.115-1.diff.gz
 118c53b580b6f494bc7dffe47478a490 649486 mail extra smail_3.2.0.115-1_i386.deb

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

iD8DBQE/EX5gMwsDi2xjdG0RAqBeAKD+szLuHjG2Yxq1MMHoQPG1N1GxSACgg4Mp
22LPO/XRsM/Lsv3pTbzeZo0=
=nGik
-END PGP SIGNATURE-


Accepted:
smail_3.2.0.115-1.diff.gz
  to pool/main/s/smail/smail_3.2.0.115-1.diff.gz
smail_3.2.0.115-1.dsc
  to pool/main/s/smail/smail_3.2.0.115-1.dsc
smail_3.2.0.115-1_i386.deb
  to pool/main/s/smail/smail_3.2.0.115-1_i386.deb
smail_3.2.0.115.orig.tar.gz
  to pool/main/s/smail/smail_3.2.0.115.orig.tar.gz


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

Accepted gutenbrowser 3:0.6.8.3-2.2 (i386 source)

[Peter Karlsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 Jul 2003 18:30:00 +0100
Source: gutenbrowser
Binary: gutenbrowser
Architecture: source i386
Version: 3:0.6.8.3-2.2
Distribution: unstable
Urgency: low
Maintainer: Viral [EMAIL PROTECTED]
Changed-By: Peter Karlsson [EMAIL PROTECTED]
Description: 
 gutenbrowser - Project Gutenberg Etext reader
Closes: 198534
Changes: 
 gutenbrowser (3:0.6.8.3-2.2) unstable; urgency=low
 .
   * Non-maintainer upload from DebCamp BSP.
   * Made sure it compiles with Qt2 and not Qt3 (Closes: #198534)
Files: 
 ca6872afb0d96f054259284cb3b23226 745 non-US optional gutenbrowser_0.6.8.3-2.2.dsc
 f094ef0fd6cf296eb5d9169093d2380b 3499 non-US optional gutenbrowser_0.6.8.3-2.2.diff.gz
 ebaa0e72977d62c64c51dbb20eda5346 409696 non-US optional 
gutenbrowser_0.6.8.3-2.2_i386.deb

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

iD8DBQE/EZl4kryUdmOUJl4RAvTjAKCUZ3PPzakOeELJ+8K94hTrMSRxsQCaA5tL
2lspwkwl4+7ZIP7mdRSTNAM=
=S2hO
-END PGP SIGNATURE-


Accepted:
gutenbrowser_0.6.8.3-2.2.diff.gz
  to pool/non-US/main/g/gutenbrowser/gutenbrowser_0.6.8.3-2.2.diff.gz
gutenbrowser_0.6.8.3-2.2.dsc
  to pool/non-US/main/g/gutenbrowser/gutenbrowser_0.6.8.3-2.2.dsc
gutenbrowser_0.6.8.3-2.2_i386.deb
  to pool/non-US/main/g/gutenbrowser/gutenbrowser_0.6.8.3-2.2_i386.deb


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

Accepted evms 2.1.0-4 (i386 source all)

[Matt Zimmerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 12 Jul 2003 13:26:32 -0400
Source: evms
Binary: libevms-dev evms-gui evms kernel-patch-evms evms-udeb evms-ncurses evms-cli 
libevms-2.0
Architecture: source all i386
Version: 2.1.0-4
Distribution: unstable
Urgency: low
Maintainer: Matt Zimmerman [EMAIL PROTECTED]
Changed-By: Matt Zimmerman [EMAIL PROTECTED]
Description: 
 evms   - Enterprise Volume Management System (core)
 evms-cli   - Enterprise Volume Management System (CLI)
 evms-gui   - Enterprise Volume Management System (GUI)
 evms-ncurses - Enterprise Volume Management System (ncurses UI)
 evms-udeb  - EVMS module for debian-installer (udeb)
 kernel-patch-evms - Enterprise Volume Management System (kernel patches)
 libevms-2.0 - Enterprise Volume Management System (library)
 libevms-dev - Enterprise Volume Management System (development)
Changes: 
 evms (2.1.0-4) unstable; urgency=low
 .
   * Enable high-availability support
   * Build-Depend on heartbeat-dev (= 1.0.2-1)
Files: 
 b6619e128c16826aefdcd3763962b844 765 admin extra evms_2.1.0-4.dsc
 58c7ca10e8900e6b6ae06403f97a45cb 130785 admin extra evms_2.1.0-4.diff.gz
 1a7c02a4497c8f832fbb68b2dbd1dd1f 222480 admin extra kernel-patch-evms_2.1.0-4_all.deb
 5b609b38bd467bbb02ca1c4382fa4f3e 32510 admin extra evms_2.1.0-4_i386.deb
 47e3d4f767b8d4de066f294b04388328 86848 admin extra evms-cli_2.1.0-4_i386.deb
 b4a60a6b51f3836f4e68e7921a6bfb8b 63570 admin extra evms-ncurses_2.1.0-4_i386.deb
 53ffe3d0f896901c65ba4cfd62ad 174278 admin extra evms-gui_2.1.0-4_i386.deb
 60a5693daea0280273217dd9521f4f6d 688854 libs extra libevms-2.0_2.1.0-4_i386.deb
 cddc499a483c298e19ad6dc7b018195d 223696 libdevel extra libevms-dev_2.1.0-4_i386.deb
 1d4b81b90f87da581974521d9d2dd2fe 810258 debian-installer extra 
evms-udeb_2.1.0-4_i386.udeb

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

iD8DBQE/Ea9sArxCt0PiXR4RAoc1AJ0bxiaor4Ewe9KDmTUYO+gxB50xYgCfVOmz
KoajahgXabO+PQBWSZLnm4o=
=OW2v
-END PGP SIGNATURE-


Accepted:
evms-cli_2.1.0-4_i386.deb
  to pool/main/e/evms/evms-cli_2.1.0-4_i386.deb
evms-gui_2.1.0-4_i386.deb
  to pool/main/e/evms/evms-gui_2.1.0-4_i386.deb
evms-ncurses_2.1.0-4_i386.deb
  to pool/main/e/evms/evms-ncurses_2.1.0-4_i386.deb
evms-udeb_2.1.0-4_i386.udeb
  to pool/main/e/evms/evms-udeb_2.1.0-4_i386.udeb
evms_2.1.0-4.diff.gz
  to pool/main/e/evms/evms_2.1.0-4.diff.gz
evms_2.1.0-4.dsc
  to pool/main/e/evms/evms_2.1.0-4.dsc
evms_2.1.0-4_i386.deb
  to pool/main/e/evms/evms_2.1.0-4_i386.deb
kernel-patch-evms_2.1.0-4_all.deb
  to pool/main/e/evms/kernel-patch-evms_2.1.0-4_all.deb
libevms-2.0_2.1.0-4_i386.deb
  to pool/main/e/evms/libevms-2.0_2.1.0-4_i386.deb
libevms-dev_2.1.0-4_i386.deb
  to pool/main/e/evms/libevms-dev_2.1.0-4_i386.deb


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