Re: I am still on the keyring. With my old key.

[Marc Haber]

On Sun, 20 Nov 2005 11:29:19 +0100, Petter Reinholdtsen
<[EMAIL PROTECTED]> wrote:
>I seriously hope the non-elected people blocking and slowing down
>several important processes in Debian soon realize that there is a
>problem and that it might be best for them to solve it by stepping
>aside or allowing new people to help them with the tasks.

I have lost _that_ hope like two years ago. It is not the case that
these problems with the non-elected people who keep blocking processes
are new. No, they have been there even when I joined the project.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Spliting packages between pkg and pkg-data

[Ricardo Mones]

On Sun, 20 Nov 2005 12:13:48 +0100
Bill Allombert <[EMAIL PROTECTED]> wrote:

> Hello Debian developers,
> 
> When doing research about circular-deps, I looked at a lot of packages
> that are split between a binary package and a data package. This is a
> good thing since this reduce the total siez of the archive, however
> there are simple rules that should be followed:
> 
> 1) Make sure pkg-data is actually arch: all.
> 
> 2) Name it in a way that make the relationship obvious: For example,
>if the upstream name is 'foo', name the binary package 'foo' and the
>data package 'foo-data'.  
> 
> 3) Keep the files that 'signal' executables in the same package than the
>executable (e.g. menu file, program manpage).
> 
> 4) Do not put symlinks in data packages that point to files in the binary
>package. This do not really save space and avoid dandling symlinks
>when the binary package is not installed.
> 
> 5) Of course move /usr/share/pkg to pkg-data.
> 
> 6) Do not make pkg-data to Depends on pkg.
> 
> 7) Try to do it correctly the first time: if you move file between
>pkg and pkg-data, you will need to use Replaces:
> 
> Please check your packages follow these rules, and if not, do not forget
> about rule 7.

  I'd suggest to add this to the best practices for debian/control in
developers' reference. What do you think?
-- 
  Ricardo Mones 
  ~
  Don't take the name of root in vain.  /usr/src/linux/README


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

Re: petsc_2.3.0-1_i386.changes REJECTED

[Thomas Viehmann]

Hi,

Adam C Powell IV wrote:
>   * There is broad consensus for versioned -dev packages (e.g.
> Thomas Viehmann's precedent, Junichi's libpkg-guide),
> particularly for this case where both the Debian alternatives
> system and PETSC_DIR mechanism allow users to select between
> multiple versions or multiple builds of the same version (LAM,
> single precision or complex, -contrib linked vs parmetis and
> hypre, -dec with HPaq alpha tools, etc.)
Eh. I only said that versioned -dev packages seem tolerable to most
people. In particular, I don't really like the idea of my name being
mentioned so close to petsc's use of the alternative system. IMHO it's a
genuine example of a very bad idea.

>   * There is a very strong consistency argument for keeping
> petsc-dev, cf. octave, python-dev, linux-image-2.6-xxx, though
I don't really think that any of these packages have too much in common
with petsc-dev - octave and linux-image-2.6-xxx aren't even -dev
packages. Python and the notion of a default-python-version and it's
implementation seems rather special to me, and TBH, I don't think anyone
claims that the python dependency construction is without problems.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: I am still on the keyring. With my old key.

[Thomas Bushnell BSG]

Henning Makholm <[EMAIL PROTECTED]> writes:

> If somebody designs and implements (after a suitable architectural
> review) some software to support distributed keyring maintenance in a
> secure, auditable way, it is likely that calls for adding more people
> to the task would be considered more seriously.

If it is true that we cannot have more than one person do the job of
keyring maintenance, then it is extremely important for that one
person to be extremely good at rapid turnaround, responding to
questions, and helping other developers out.  There is a common
perception that the current keyring maintainer does not possess these
particular skills.


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

Re: Spliting packages between pkg and pkg-data

[Henrique de Moraes Holschuh]

On Mon, 21 Nov 2005, Henning Makholm wrote:
> Scripsit Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
> > On Sun, 20 Nov 2005, Bill Allombert wrote:
> 
> >> 5) Of course move /usr/share/pkg to pkg-data.
> 
> > Forget it.  I don't know about the others, but I am not doing this, unless
> > someone gives sound technical reasons for such a rule.
> 
> If you have a pkg-data package at all, then why on earth would it
> _not_ include whatever /usr/skare/pkg stuff you need to ship? What
> _do_ you have in pkg-data, then?

I understood that sentence as install the data to /usr/share/pkg-data,
not as "install the data to /usr/share/pkg but ship it into package
pkg-data".

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


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

Re: Spliting packages between pkg and pkg-data

[Henning Makholm]

Scripsit Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
> On Sun, 20 Nov 2005, Bill Allombert wrote:

>> 5) Of course move /usr/share/pkg to pkg-data.

> Forget it.  I don't know about the others, but I am not doing this, unless
> someone gives sound technical reasons for such a rule.

If you have a pkg-data package at all, then why on earth would it
_not_ include whatever /usr/skare/pkg stuff you need to ship? What
_do_ you have in pkg-data, then?

-- 
Henning Makholm  "What has it got in its pocketses?"


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

Re: Spliting packages between pkg and pkg-data

[Henrique de Moraes Holschuh]

On Sun, 20 Nov 2005, Henrique de Moraes Holschuh wrote:
> On Sun, 20 Nov 2005, Bill Allombert wrote:
> > 5) Of course move /usr/share/pkg to pkg-data.
> 
> Forget it.  I don't know about the others, but I am not doing this, unless
> someone gives sound technical reasons for such a rule.

Never mind, I read the explanation that you meant ship /usr/share/pkg in the
pkg-data package, just after I sent the message :-(

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


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

Re: petsc_2.3.0-1_i386.changes REJECTED

[Steve Langasek]

On Sun, Nov 20, 2005 at 06:57:36PM -0500, Adam C Powell IV wrote:
> > Well, I think the factor there is that we "usually" want users to upgrade to
> > the latest kernel automatically, whereas users of petsc usually can't
> > auto-upgrade to the new API.

> Okay, then what about octave, another empty package which forced an
> incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?

Probably depends on how incompatible the upgrades are.

BTW, the other big reason for linux-image-2.6-$flavor metapackages is that
they provide a hook for debian-installer, so the installer doesn't have to
be futzed with in 5 places every time there's a kernel update.

> And come to think of it, the python-dev python version consistency
> argument doesn't really apply to anyone running a single distribution,
> because the "python" version in that distribution is automatically
> identical to the "python-dev" version.  The only way this "guarantee" of
> the same pythonx.y-dev and python -> pythonx.y actually does anything is
> if an admin somehow attempts to shoehorn the woody python with the sarge
> python-dev onto the same system, and how likely is that?

So you're suggesting that people who package python tools should be ok with
having to update their build-dependencies as part of every python
transition, even when nothing else in their package needs to change?  (This
also has implications for backports and cross-ports, mind you...)

> Again, the point is that these are all over Debian, and it's
> inconsistent to accept all but one.

I don't think anyone has been proposing an inconsistent guideline, here.
I'll grant you that these guidelines probably haven't been *applied*
consistently in the past, but that's not the same thing.

> Joerg, the ball is in your court:

>   * There is broad consensus for versioned -dev packages (e.g.
> Thomas Viehmann's precedent, Junichi's libpkg-guide),

No, actually, there are vocal *proponents* of versioned -dev packages.
That's not the same thing as broad consensus.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Spliting packages between pkg and pkg-data

[Henrique de Moraes Holschuh]

On Sun, 20 Nov 2005, Bill Allombert wrote:
> Because if you install the pkg-data but not pkg, the manpage will be
> available but not the program which is not nice.

That should not be acceptable.  Tack in a recommends, and as usual anyone
that ignores a recommends is on his own.  Too bad you cannot fully version
the recommends using '=', or you'd break bin NMUs.

That should take care of the circular dependency problem you complained
about re. hplip/hplip-data, I will change the package relationship there
soon.

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


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

Re: Spliting packages between pkg and pkg-data

[Henrique de Moraes Holschuh]

On Sun, 20 Nov 2005, Bill Allombert wrote:
> 5) Of course move /usr/share/pkg to pkg-data.

Forget it.  I don't know about the others, but I am not doing this, unless
someone gives sound technical reasons for such a rule.

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


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

Re: I am still on the keyring. With my old key.

[Henning Makholm]

Scripsit Martijn van Oosterhout <[EMAIL PROTECTED]>

> "push aside"? There's no rule that says there can be only one. Yes,
> replacing someone could become ugly, but providing additional hands
> can't be considered bad, can it?

It can be considered bad from a technical viewpoint - as far as I
understand the master copy of the keyring is currently on a medium
that is under the keyring maintainer's direct physical control.

The "obvious" way of switching to team maintenance of the keyring
would entail keeping the master copy in a central machine - for
example on a debian.org box somewhere in a colo. Doing that in a way
that does not leave the keyring more vulnerable to surreptitious
compromise than some reasonable persons might prefer, requires
software support that does not currently exist.

If somebody designs and implements (after a suitable architectural
review) some software to support distributed keyring maintenance in a
secure, auditable way, it is likely that calls for adding more people
to the task would be considered more seriously.

> Anyway, ISTM that removing keys from a keyring is much more important
> than adding new ones, right?

It is also more difficult to implement in a secure distributed way.
Anybody can think up a scheme for using gpg signatures to prevent keys
from being added without authorisation in the first place. Making sure
that a removed key stays removed is a more complex question -
particularly if emergency powers-to-remove just get kludged onto the
existing system as an afterthought.

-- 
Henning Makholm  "Panic. Alarm. Incredulity.
   *Thing* has not enough legs. Topple walk.
  Fall over not. Why why why? What *is* it?"


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

Re: How to deal with dependencies/conflics on third party packages

[Steve Langasek]

On Sun, Nov 20, 2005 at 11:50:55PM +, Joerg Sommer wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote:

> >> I've got a bug report (#336527) my package bootchart-view do not work
> >> with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a
> >> packages that is not in Debian? But if it do not work with j2re1.3 it
> >> should more than ever not work with older version. But I would assume
> >> older version have different packages names. So I must add a list of
> >> packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the
> >> version clause (j2re1.3 (<< 1.3)). So what should I do?

> > "Does not work with j2re1.3" means you should be depending on what it *does*
> > work with, not trying to conflict with (unrelated) packages that don't
> > satisfy the dependency.

> All packages in Debian they provide java-virtual-machine work with
> bootchart-view.

That includes jamvm and gij-3.3?

> But all alternative JVMs do only work with svg output and only Sun's JVM
> support png. This is the reason, why I don't want restrict the
> dependencies upon the JVMs in Debian.

I don't understand this explanation at all.  The bug report is about a
failure due to class version mismatches; what does this have to do with svg
vs. png?

> > The problem here is that bootchart-view depends on '| java-virtual-machine',
> > which does not satisfy its runtime needs.  Depend on something more
> > appropriate; possibly even j2re1.4.

> I can not find this package

The implication was that j2re1.4 would be a virtual package, provided by
those packages which implement the 1.4 spec.  But of course, there's also a
*real* j2re1.4 package, not available in Debian but buildable using
java-package.

The main point is not that j2re1.4 is the correct name to include in this
list (it may be, but I don't know that for sure); the point is that
java-virtual-machine is *incorrect*, because j-v-m only ensures you a lowest
common denominator feature set, and that's obviously not sufficient in this
case.

> Can I depend on packages they are not in Debian? This would be new to me.

In a list of alternatives, sure.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Advices for an su transition

[Bill Allombert]

On Sun, Nov 20, 2005 at 05:44:46PM -0600, Bill Allombert wrote:
> On Sun, Nov 20, 2005 at 11:26:20PM +0100, Nicolas Fran?ois wrote:
> > IIRC people from debian-audit have some tools to perform such grep on the
> > source package with some heuristics to extract and patch the sources
> > (dpatch, cdbs, ...), and ignore the documentation files (e.g. "su" is a
> > common word in spanish).
> > I have no idea of the size of such grep output.
> > 
> > 
> > Does anybody have another idea?
> 
> Yes, you must absolutly check all the maintainer scripts (preinst,etc)
> shipped in sarge and preferably also all postrm in woody, else you take
> the risk of breaking sarge to etch upgrade.
> 
> I can do it for you if you want.

Actually looks here: 

The full data is available on merkel.debian.org in ~ballombe/menu/supackages.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: How to deal with dependencies/conflics on third party packages

[Joerg Sommer]

Hello Steve,

Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote:
>
>> I've got a bug report (#336527) my package bootchart-view do not work
>> with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a
>> packages that is not in Debian? But if it do not work with j2re1.3 it
>> should more than ever not work with older version. But I would assume
>> older version have different packages names. So I must add a list of
>> packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the
>> version clause (j2re1.3 (<< 1.3)). So what should I do?
>
> "Does not work with j2re1.3" means you should be depending on what it *does*
> work with, not trying to conflict with (unrelated) packages that don't
> satisfy the dependency.

All packages in Debian they provide java-virtual-machine work with
bootchart-view. But all alternative JVMs do only work with svg output and
only Sun's JVM support png. This is the reason, why I don't want restrict
the dependencies upon the JVMs in Debian.

> The problem here is that bootchart-view depends on '| java-virtual-machine',
> which does not satisfy its runtime needs.  Depend on something more
> appropriate; possibly even j2re1.4.

I can not find this package

$ apt-cache search j2re1.4
openoffice.org - OpenOffice.org Office suite version 2.0
openoffice.org2 - OpenOffice.org Office suite version 2.0
$

Can I depend on packages they are not in Debian? This would be new to me.

Bye, Jörg.
-- 
Die NASA brauchte 12 Jahre um einen Kugelschreiber zu entwickeln, der
kopfüber, in der Schwerelosigkeit und unter Wasser schreiben kann.
Die Russen benutzten einfach einen Bleistift...


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

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

On Sat, 2005-11-19 at 00:22 -0800, Steve Langasek wrote:
> On Wed, Nov 16, 2005 at 10:53:57AM -0500, Adam C Powell IV wrote:
> > > > > For that matter, why is it important that Debian provide support for
> > > > > coinstallability with older packages that are, evidently, not 
> > > > > important
> > > > > enough themselves to be supported by Debian?
> 
> > > > In contrast, libxml-dev has 731 users and at least one major reverse
> > > > dependency (gnucash), making it much more valuable.  Not to mention just
> > > > one large API change, vs. PETSc's, um, 10 or so since I first uploaded
> > > > it.
> 
> > > Right; it's the API changes that make the idea of an unversioned petsc-dev
> > > package of questionable utility...
> 
> > Fair enough.  It's a convenience, but one which forces a user/developer
> > to upgrade his/her code -- or point to the old version (likely still
> > there because there are no conflicts) until such time becomes available.
> 
> > Hmm.  Perhaps the analogy to linux-image-2.6-SUBARCH is better.  The
> > kernel "API changes" enough to suggest or require some new utilities,
> > and obsolete others.  This *usually* doesn't require users to change
> > things, as there's a big effort to be backward compatible (e.g. ALSA
> > provides an OSS-compatible interface), but not always.
> 
> Well, I think the factor there is that we "usually" want users to upgrade to
> the latest kernel automatically, whereas users of petsc usually can't
> auto-upgrade to the new API.

Okay, then what about octave, another empty package which forced an
incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?

And come to think of it, the python-dev python version consistency
argument doesn't really apply to anyone running a single distribution,
because the "python" version in that distribution is automatically
identical to the "python-dev" version.  The only way this "guarantee" of
the same pythonx.y-dev and python -> pythonx.y actually does anything is
if an admin somehow attempts to shoehorn the woody python with the sarge
python-dev onto the same system, and how likely is that?

Again, the point is that these are all over Debian, and it's
inconsistent to accept all but one.

> > But what about the empty linux-image upgrade convenience packages
> > mentioned above?  If the answer is "Such packages are all bad and should
> > go away", I'm fine with that.
> 
> No, I certainly think that packages like linux-image-2.6-686 should be kept
> around.  And you've also made a case for why it may be useful to keep
> petsc-dev around.  In any case, it's ultimately the ftp team's decision to
> make; it sounds to me like all the arguments have been made at this point.

Thanks again for your feedback and explanations.

Joerg, the ball is in your court:

  * There is broad consensus for versioned -dev packages (e.g.
Thomas Viehmann's precedent, Junichi's libpkg-guide),
particularly for this case where both the Debian alternatives
system and PETSC_DIR mechanism allow users to select between
multiple versions or multiple builds of the same version (LAM,
single precision or complex, -contrib linked vs parmetis and
hypre, -dec with HPaq alpha tools, etc.)
  * There is a very strong consistency argument for keeping
petsc-dev, cf. octave, python-dev, linux-image-2.6-xxx, though
I'll drop petsc-dbg with its six users on popcon if you like.

What's the verdict?

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


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

Processed: Changed address

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> submitter 206293 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#206293: mozilla-browser: hangs silently very often
Changed Bug submitter from [EMAIL PROTECTED] (Pierre THIERRY) to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 173206 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#173206: emacs21: Use of non-standard header without X- before
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 202620 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#202620: mozilla-browser: mozilla hangs regularily for some days
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 203700 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#203700: ssh: WIth many public keys provided by ssh-agent, connection fail
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 246678 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#246678: mkbrowser script shows warnings, invoke debtags with bad syntax and 
segfault
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 248664 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#248664: bind9: named-checkzone doesn't check serial anymore
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 173494 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#173494: vim-gtk: All modes with same cursor
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 199709 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#199709: mutt: Attachments are automatically displayed even with 
'Content-Disposition: attachment'
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 241866 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#241866: jzip: Reset terminal when exiting
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 248501 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#248501: gman: Should not try to view HTML when man2html is not available
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 206374 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#206374: xml-resume-library: should Depends on available XSL and XSL-FO 
processors
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 266021 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#266021: Please implement manual method for IPv6
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 201639 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#201639: RFP: limsee2 -- A cross-platform SMIL2.0 authoring tool
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 204606 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#204606: RFP: archmage -- arCHMage is an extensible reader and decompiler 
for files in the CHM format.
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 205024 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#205024: purity list should return the actual list of available tests
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 206931 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#206931: libw3c-logvalidator-perl -- Web server log analysis tool to 
validate the N most popular documents
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 212022 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#212022: netrik: should handle gzip encoding
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 229715 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#229715: apt: Add a "postinst command spool"
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 248526 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#248526: gman: Format PS output according to screen size
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 248529 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#248529: groff: Do roff(7) must be an advertisement for Emacs?
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 264108 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#264108: Files installed in /var/lib/lxr should be in /usr/share/lxr
Changed Bug submitter from Pierre THIERRY <[EMAIL PROTECTED]> to Pierre THIERRY 
<[EMAIL PROTECTED]>.

> submitter 217899 Pierre THIERRY <[EMAIL PROTECTED]>
Bug#217899: argouml: Packages and source code generation for other languages
Changed Bug submitter from Pierre THIERR

Re: Uploading amd64 packages

[Joerg Jaspert]

On 10480 March 1977, W. Borgert wrote:

>> I meantioned one solution. There is another possible one: source uploads.
>> And no, I don't think it would cause more breakages than nowdays because
>> uploading sources only doesn't meant packages have not been build on
>> our systems.
> I couldn't agree more: source uploads are a good idea. It seems
> to work for Ubuntu. However, we have discussed this issue before
> and there was no consensus and worse, no implementation.

No, they are not.

-- 
bye Joerg
 meebey: Ich kanns Dir remote machen;)
 oh mann... erst denken dann schreiben


pgpMkvh21JIyF.pgp
Description: PGP signature

Re: Advices for an su transition

[Bill Allombert]

On Sun, Nov 20, 2005 at 11:26:20PM +0100, Nicolas Fran?ois wrote:
> IIRC people from debian-audit have some tools to perform such grep on the
> source package with some heuristics to extract and patch the sources
> (dpatch, cdbs, ...), and ignore the documentation files (e.g. "su" is a
> common word in spanish).
> I have no idea of the size of such grep output.
> 
> 
> Does anybody have another idea?

Yes, you must absolutly check all the maintainer scripts (preinst,etc)
shipped in sarge and preferably also all postrm in woody, else you take
the risk of breaking sarge to etch upgrade.

I can do it for you if you want.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Bug#336698: dh_strip: debug data going to the wrong place

[W. Borgert]

On Sun, Nov 20, 2005 at 04:21:29PM -0500, Daniel Jacobowitz wrote:
> - They may be compiled with lower optimization.
> - They may be compiled with behavior-altering debugging options.

Yes: One has a crash, tries a debug version of a library and
suddenly everything behaves totally different, e.g. no crash or
a different one :-( So, unfortunately you're right.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Uploading amd64 packages

[W. Borgert]

On Sun, Nov 20, 2005 at 11:20:59PM +0100, J?r?me Marant wrote:
> I meantioned one solution. There is another possible one: source uploads.
> And no, I don't think it would cause more breakages than nowdays because
> uploading sources only doesn't meant packages have not been build on
> our systems.

I couldn't agree more: source uploads are a good idea. It seems
to work for Ubuntu. However, we have discussed this issue before
and there was no consensus and worse, no implementation.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Uploading amd64 packages

[Bill Allombert]

On Fri, Nov 18, 2005 at 04:23:37PM -0500, Joe Smith wrote:
 
> would assume that it was fairly ovbious that the binary upload would need
> to be
> for an offical arcitecture, which amd64 is not (yet). In fact, it is
> probably not reccomended
> to be developing under a system that is not offically a debian system.

Given that amd64 is targeted to release with etch, the sooner we can
use it as a development platform, the sooner we will catch potentially
RC bugs, so I would say it _is_ recommended.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: New features on buildd.net

[David Moreno Garza]

On 18:12 Fri 18 Nov 2005, Ingo Juergensmann wrote:
> After buildd.net is fully working again, I thought it might be worthwhile to
> let you know and write a small mail about its new features

Thanks for the great work!

-- 
David Moreno Garza <[EMAIL PROTECTED]>   |  http://www.damog.net/
   <[EMAIL PROTECTED]>  |  GPG: C671257D
 En marciano me fui a convertir.


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

Re: My IP address seems listed as a spammer address by bugs.debian.org

[David Moreno Garza]

On 16:14 Sun 20 Nov 2005, Graham Wilson wrote:
> Wouldn't it also be possible to subscribe to debian-bugs-dist to get
> updates about the relevant bugs that way? Though, that might take quite
> a bit more processing on the receiving end than using the LDAP
> interface.

But the first is a preferred way, since that would bring you the conversation
within the bug report right to you, and the LDAP gateway won't.

-- 
David Moreno Garza <[EMAIL PROTECTED]>   |  http://www.damog.net/
   <[EMAIL PROTECTED]>  |  GPG: C671257D
 En marciano me fui a convertir.


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

Advices for an su transition

[Nicolas François]

Hello,

On Sun, Nov 06, 2005 at 11:14:39PM +0100, Nicolas François wrote:
> 
> We would now like to get rid of this bug. What do you recommend:
>  * keep a Debian specific implementation and tag this bug wontfix
>  * reapply the patch to fix this bug, and report bugs on the packages that
>uses this "feature"

I've not seen a strong opposition to the second choice.


We now need some advices to perform this transition.

Junichi proposed to keep the current behavior when an environment variable
is set (I would prefer something different from POSIXLY_CORRECT). The
support for this environment variable could then be dropped after Etch.

The change will have to be announced (here and in NEWS) and documented.
(Basically, -c's argument is a command executed in the shell, other
arguments given after '--' are provided to the shell, not to the command)


Another step is to find which packages won't work with this change, get
them fixed and upload a new login which conflicts with their previous
versions.

I think such softwares won't run with upstream's su (i.e. at least Redhat
and Gentoo), GNU's su (coreutils), FreeBSD's su (and OpenSolaris' su).
So I hope only Debian specific packages or Debian maintainers' scripts
will be affected.

At this time we are aware of:
 * pbuilder (not true anymore)
 * dchroot
   dchroot synopsis is: dchroot [OPTION...] [COMMAND]
   it passes its arguments to su. -c is not provided.
   COMMAND needs to be a single argument.

There are no dependencies on login, so I don't see anything else than a
grep on the 2 letters "su" (\ may help).

IIRC people from debian-audit have some tools to perform such grep on the
source package with some heuristics to extract and patch the sources
(dpatch, cdbs, ...), and ignore the documentation files (e.g. "su" is a
common word in spanish).
I have no idea of the size of such grep output.


Does anybody have another idea?

Kind Regards,
-- 
Nekral


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

Re: Uploading amd64 packages

[Jérôme Marant]

"Joe Smith" <[EMAIL PROTECTED]> writes:


>>Not good. What is missing to get this fixed?
>
> Well There are two mirror changes. I suspect that scc will need to become 
> operational,
> before amd64 is added to ftp-master. The scc change is a big change and 
> certainly has te potential to break things,
> including offical mirrors. So this change will likely be delayed as long as 
> possible.

I hope you're wrong.

> Until amd64 is made an official architecture it would be nonsensical to 
> allow dinstall (or is it katie?) to accept packages for amd64.

What is nonsensical is that one of the most popular architectures is
still not official.
But the point is moot anyway.

>
>>> > If not, is there any upload queue dedicated at them?
>>>
>>> Nope.
>>> Well. Yes (again). But only about 5 people are allowed to upload there,
>>> plus one script that syncs the source from Debian. So you dont need to
>>> upload there.
>>
>>So, I guess I have no choice but building packages in a i386 chroot, right?
>
> I would assume that it was fairly ovbious that the binary upload would need 
> to be
> for an offical arcitecture, which amd64 is not (yet). In fact, it is 
> probably not reccomended
> to be developing under a system that is not offically a debian system.

But if noone develop for that system, there is not point making it
official, isn't there?

I meantioned one solution. There is another possible one: source uploads.
And no, I don't think it would cause more breakages than nowdays because
uploading sources only doesn't meant packages have not been build on
our systems.

-- 
Jérôme Marant

Re: My IP address seems listed as a spammer address by bugs.debian.org

[Graham Wilson]

On Sun, Nov 20, 2005 at 10:44:15AM -0800, Blars Blarson wrote:
> If you need to access the BTS data from a program, there is an LDAP
> interface available and a copy of entire BTS database on one of the
> developer accessable machines.

Wouldn't it also be possible to subscribe to debian-bugs-dist to get
updates about the relevant bugs that way? Though, that might take quite
a bit more processing on the receiving end than using the LDAP
interface.

-- 
gram


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

Re: Man page owner

[Rich Walker]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sun, Nov 20, 2005 at 08:40:17PM +, Rich Walker wrote:
>
>> This is probably a question with an obvious answer, but I couldn't find
>> the answer.
>
>> Why are man pages installed with owner and group  "root" rather than
>> owner and group "man"?
>
> Why would "man" need write access to the man pages?

Good point.

Just seemed ... odd.

cheers, Rich.

-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: My IP address seems listed as a spammer address by bugs.debian.org

[David Moreno Garza]

On 08:33 Sun 20 Nov 2005, Christian Perrier wrote:
> It seems that this became enough for my address being listed...and now
> I can't work anymore on any bug from my home system. 
> 
> I will probably use a workaround by using my ISP proxy server but this
> just moves the problem elsewhere...

What about...

% ldapsearch -h bts2ldap.debian.net -p 10101 -LLL -x -b 
dc=current,dc=bugs,dc=debian,dc=org 'debbugsID=33' -s sub

...when you only want some information keys regarding the bug, as a
suboptimal workaround?

-- 
David Moreno Garza <[EMAIL PROTECTED]>   |  http://www.damog.net/
   <[EMAIL PROTECTED]>  |  GPG: C671257D
 Save the planet, it is the only one with chocolate.


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

Re: Automated testing - design and interfaces

[Robert Collins]

On Thu, 2005-11-17 at 14:36 -0800, Steve Langasek wrote:
> [let's get this over to a technical list like it was supposed to be ;)]

> > Following your exit status based approach you could add to stanzas
> > something like:
> 
> >   Expected-Status: 0
> 
> > I found the above requirement the very minimum for a test interface.
> > What follows is optional (IMHO).
> 
> FWIW, I don't see that there's a clear advantage to having the test harness
> *expect* non-zero exit values (or non-empty output as you also suggested).
> It may make it easier to write tests by putting more of the logic in the
> test harness, but in exchange it makes it harder to debug a test failure
> because the debugger has to figure out how "correct" and "incorrect" are
> defined for each test, instead of just getting into the meat of seeing why
> the test returned non-zero.  Likewise, expecting successful tests to be
> silent means that you can rely on any output being error output that can be
> used for debugging a test failure.

Right. Splitting it into two bits ...

with respect to exit code, there is generally only one way to succeed,
but many ways to fail. So reserving 0 for 'test succeeded' in ALL cases,
makes writing front ends, or running the tests interactively much
easier. Its certainly possible to provide a $lang function that can
invert the relationship for you, for 'expected failure' results. One of
the things about expected failures is their granularity: is a test
expected to fail because 'file FOO is missing', or because 'something
went wrong'. The former test is best written as an explicit check, where
you invert the sense in the test script. Its best because this means
that when the behaviour of the failing logic alters - for better or
worse - you get flagged by the test that it has changed. Whereas a
handwaving 'somethings broken' style expected failure really does not
help code maintenance at all. So while it can be useful in the test
interface to have an explicit code for 'expected failure', I think it is
actually best to just write the test to catch the precise failure, and
report success. 

As for silence, yes, noise is generally not helpful, although long
running test suites can usefully give *some* feedback (a . per 100 tests
say) to remind people its still running.

Rob

-- 
GPG key available at: .


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

Re: Spliting packages between pkg and pkg-data

[Russ Allbery]

Nicolas Boullis <[EMAIL PROTECTED]> writes:
> On Sun, Nov 20, 2005 at 12:39:24PM -0800, Russ Allbery wrote:

>> Well, one practical concern is that it makes it harder for other
>> utilities like lintian to analyze the package properly.

> Well, that's an argument I don't like. Those are tools that help us
> check our packages are correct, but I don't think it is reasonable to
> modify otherwise correct package only to make such tools happy. For the
> same reason, I'm not happy with setting lintian overrides, as I consider
> it bloats the packages for no good reason (although the "bloat" is very
> limited").

Sure, ideally lintian would be able to cope with any packaging practice
that actually works.  However, this is a lot like coding standards in a
programming language.  There's a lot of evidence to indicate that
following standards that are more restrictive than the language actually
requires can make it easier to find bugs and detect problems, even though
it isn't necessary and there are times for exceptions.

I think lintian is one of the best things about Debian since it lets one
catch a multitude of problems that are otherwise difficult to detect and
easy to forget to look for.  Using any sort of lint tool is always a bit
of a tradeoff, though, since there will always be things that are correct
but impossible for the lint tool to analyze for one reason or another.
lintian's particular flaw is that it can't do most forms of interpackage
analysis, so one has to provide all the details it needs to do its job in
a single package whenever possible.

In the absence of any compelling reason why something *needs* to go in
another package, it therefore makes sense to me to keep it together to
make life easier for QA tools.  But then, I'm a big believer in lint,
-Wall, and similar checking tools, up to and including minor modifications
to my coding or packaging style to avoid false positives.  I think the
tradeoff is more than worth it; the more effective I can help the lint
tools to be, the more consistently high-quality my packages are.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Man page owner

[Stuart Yeates]

In message <[EMAIL PROTECTED]> Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sun, Nov 20, 2005 at 08:40:17PM +, Rich Walker wrote:
> 
> > This is probably a question with an obvious answer, but I couldn't find
> > the answer.
> 
> > Why are man pages installed with owner and group  "root" rather than
> > owner and group "man"?
> 
> Why would "man" need write access to the man pages?

Tradionally, formatted manual pages are cached, I believe, and the man group 
owns the cached files. root should own the nroff files and man the cache 
(ascii) files.

cheers
stuart


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

Re: Uploading amd64 packages

[Joe Smith]

Jérôme Marant said:


Quoting Joerg Jaspert <[EMAIL PROTECTED]>:

Jérôme Marant schrieb:

> Is it currently possible to upload amd64 packages to ftp-master?

No.
Well. Yes. Of course you can upload. They just get rejected. :)



Not good. What is missing to get this fixed?


Well There are two mirror changes. I suspect that scc will need to become 
operational,
before amd64 is added to ftp-master. The scc change is a big change and 
certainly has te potential to break things,
including offical mirrors. So this change will likely be delayed as long as 
possible.
Until amd64 is made an official architecture it would be nonsensical to 
allow dinstall (or is it katie?) to accept packages for amd64.




> If not, is there any upload queue dedicated at them?

Nope.
Well. Yes (again). But only about 5 people are allowed to upload there,
plus one script that syncs the source from Debian. So you dont need to
upload there.


So, I guess I have no choice but building packages in a i386 chroot, right?


I would assume that it was fairly ovbious that the binary upload would need 
to be
for an offical arcitecture, which amd64 is not (yet). In fact, it is 
probably not reccomended

to be developing under a system that is not offically a debian system.
(Although amd64 is a bit of a special case. I would not reccomend doing 
development for

debian on an ubuntu system for example. Too much possibility of conflict.)

Re: Bug#336698: dh_strip: debug data going to the wrong place

[Daniel Jacobowitz]

On Tue, Nov 01, 2005 at 08:33:23PM +0100, Kurt Roeckx wrote:
> Those are real libraries that were not stripped, and those should
> go away in favour of the detached version.

[Yes, I realize this is a really old thread... I haven't been reading
-devel lately.

Not necessarily true.

- They may be compiled with lower optimization.
- They may be compiled with behavior-altering debugging options.

I believe the former is true for libc6-dbg and I know the latter is
true for libncurses5-dbg; it can record trace files for later
debugging, which has some runtime overhead.

[I've been thinking about enabling it by default anyway, but it's the
sort of thing that needs to be measured first.]

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: Man page owner

[Steve Langasek]

On Sun, Nov 20, 2005 at 08:40:17PM +, Rich Walker wrote:

> This is probably a question with an obvious answer, but I couldn't find
> the answer.

> Why are man pages installed with owner and group  "root" rather than
> owner and group "man"?

Why would "man" need write access to the man pages?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Spliting packages between pkg and pkg-data

[Nicolas Boullis]

Hi,

On Sun, Nov 20, 2005 at 12:39:24PM -0800, Russ Allbery wrote:
> Nicolas Boullis <[EMAIL PROTECTED]> writes:
> > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:
> 
> >> 3) Keep the files that 'signal' executables in the same package than the
> >>executable (e.g. menu file, program manpage).
> 
> > Why? I agree that it menu files and manpages are generally not that 
> > large, but what would it break to have them in pkg-data?
> > (I would consider it strange to have such files out of the main pkg 
> > package, but it looks policy-compliant as far as I can see...)
> 
> Well, one practical concern is that it makes it harder for other utilities
> like lintian to analyze the package properly.

Well, that's an argument I don't like. Those are tools that help us 
check our packages are correct, but I don't think it is reasonable to 
modify otherwise correct package only to make such tools happy. For the 
same reason, I'm not happy with setting lintian overrides, as I consider 
it bloats the packages for no good reason (although the "bloat" is very 
limited").


Cheers,

Nicolas


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

Bug#340088: ITP: pyfribidi -- FriBidi Python bindings

[Lior Kaplan]

Package: wnpp
Severity: wishlist
Owner: Lior Kaplan <[EMAIL PROTECTED]>

* Package name: pyfribidi
  Version : 0.3.3
  Upstream Author : Yaacov Zamir <[EMAIL PROTECTED]>
* URL : http://hspell-gui.sourceforge.net/pyfribidi.html
* License : GPL
  Description : FriBidi Python bindings

 FriBiDi is a BiDi algorithm implementation for RTL Languages (Hebrew, Arabic
 etc).
 .
 This package is needed to use the python module for the FriBidi C library.
 .
 For further information see http://hspell-gui.sourceforge.net/pyfribidi.html

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Man page owner

[Rich Walker]

Hi,

This is probably a question with an obvious answer, but I couldn't find
the answer.

Why are man pages installed with owner and group  "root" rather than
owner and group "man"?

cheers, Rich.


-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: Spliting packages between pkg and pkg-data

[Bill Allombert]

On Sun, Nov 20, 2005 at 09:26:37PM +0100, Nicolas Boullis wrote:
> On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:
> > Hello Debian developers,
> > 
> > When doing research about circular-deps, I looked at a lot of packages
> > that are split between a binary package and a data package. This is a
> > good thing since this reduce the total siez of the archive, however
> > there are simple rules that should be followed:
> > 
> > 3) Keep the files that 'signal' executables in the same package than the
> >executable (e.g. menu file, program manpage).
> 
> Why? I agree that it menu files and manpages are generally not that 
> large, but what would it break to have them in pkg-data?
> (I would consider it strange to have such files out of the main pkg 
> package, but it looks policy-compliant as far as I can see...)

Because if you install the pkg-data but not pkg, the manpage will be
available but not the program which is not nice.
For menu it is not a problem provide you write the menu entry correctly
?package(foo):... and not ?package(foo-data). This way update-menus
check whether foo is installed before using the entry.

Anyway I did not claim this was mandated by policy.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: Spliting packages between pkg and pkg-data

[Russ Allbery]

Nicolas Boullis <[EMAIL PROTECTED]> writes:
> On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:

>> 3) Keep the files that 'signal' executables in the same package than the
>>executable (e.g. menu file, program manpage).

> Why? I agree that it menu files and manpages are generally not that 
> large, but what would it break to have them in pkg-data?
> (I would consider it strange to have such files out of the main pkg 
> package, but it looks policy-compliant as far as I can see...)

Well, one practical concern is that it makes it harder for other utilities
like lintian to analyze the package properly.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Spliting packages between pkg and pkg-data

[Nicolas Boullis]

On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:
> Hello Debian developers,
> 
> When doing research about circular-deps, I looked at a lot of packages
> that are split between a binary package and a data package. This is a
> good thing since this reduce the total siez of the archive, however
> there are simple rules that should be followed:
> 
> 3) Keep the files that 'signal' executables in the same package than the
>executable (e.g. menu file, program manpage).

Why? I agree that it menu files and manpages are generally not that 
large, but what would it break to have them in pkg-data?
(I would consider it strange to have such files out of the main pkg 
package, but it looks policy-compliant as far as I can see...)


Nicolas


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

Re: [useless] I am still on the keyring. With my old key.

[Sam Hartman]

> "Chip" == Chip Salzenberg <[EMAIL PROTECTED]> writes:

Chip> Who does a developer have to fuck around here to get his key
Chip> deleted?  -- Chip Salzenberg <[EMAIL PROTECTED]>


Chip> -- To UNSUBSC

Hi.  As you are no doubt aware by now, getting your key removed is a
great mystery and deep magic requiring much research and perseverance.
However as best I can tell delving into the sacred texts, it's a
cryptography magic not a sex magic.  Now, perhaps what you're trying
to do is use a sex magic as a means of coercion to catalyze the
cryptography magic.

That's certainly an interesting approach.  There do seem to be some
references to something similar in some related folk traditions.
However there aren't really any references to this sort of thing in
the sacred texts of cryptography.  I'm a bit concerned that
cryptography has its own coercion magic--never fully described and
only alluded to by the primary tool (the rubber hose [*]).  I'm
concerned that since cryptography has its own coercion magic, it may
not be easy to use another magic for the same purpose.  The powers at
play may simply not interact well.  If you do manage to succeed with
this approach then you will have learned something interesting.

Now, a few comments on attempting the cryptography magic directly.
It's my understanding that the key to such magics--particularly in the
Debian tradition--is to harness sufficient energy and focus it on a
point.  There are apparently techniques that involve public mailing
lists for amplification.  You do have access to a symbol of power
which may give you control of sufficient energy: your old key.



Consider carefully the following ritual.  Carefully write instructions
describing how one not familiar with the Debian tradition could use a
key to influence Debian--particularly focusing on a description of the
package upload ritual.  Of course since you are targeting novices your
description should focus on warning about the ways in which such power
could be abused; not all novices have sufficient imagination so you'll
have to be very explicit.  Take this ritual and place along side it
your private key.  I'm afraid that in order to harness sufficient
power you may have to remove the traditional wards around your key.
Post the result to debian-devel.  I think that the resulting
energy--particularly focused so close to your private key--may totally
destroy your key in the Debian sphere.


BE WARNED.  This is the first ritual I've tried to create myself.  It
involves powers and energies much stronger than I'm used to applying.
Energies that strong often lead to karmic backlash.  I have not yet
calculated the full extent of karmic backlash possible from this
ritual; it seems beyond my capabilities.  I would strongly advise
finishing such a calculation before you begin.  I'm certain that the
energies involved are great enough that there will be consequences
beyond your primary intended effect.

Good luck in your quest.

-Sam

P.S.  This is a *joke*.  I am not actually advocating disclosing a
private key.  Good luck in actually getting the key removed through
the normal mechanism.

[*] I suppose there are sex magics involving rubber hoses.  They are
beyond my experience and I am not sure how they would interact with
cryptography magic.


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

Re: My IP address seems listed as a spammer address by bugs.debian.org

[Brian M. Carlson]

On Sunday 20 November 2005 18:44, Blars Blarson wrote:
> If you need to access the BTS data from a program, there is an LDAP
> interface available and a copy of entire BTS database on one of the
> developer accessable machines.

Then "bts cache" should use that, and not HTTP, or perhaps only fall back to 
HTTP.  Additionally, the robots.txt is being violated by "bts cache", so 
perhaps someone should file a bug.

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD
Support alternative kernels in Debian!


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

Re: Debian menu system request for help

[Stan Vasilyev]

I would like to help. I know C, C++, Java, Bash, Debian package system and I 
sort of know how the menu works. I am a Debian Developer in training and I 
have made many packages, three of which are already in Debian. You can take a 
look at my work here:

http://qa.debian.org/[EMAIL PROTECTED]

On Sunday 20 November 2005 09:43 am, Bill Allombert wrote:

> I would like some help with checking the overall menu quality.
> (menu entries and menu methods)
>


pgphqySZuzfRW.pgp
Description: PGP signature

Re: Spliting packages between pkg and pkg-data

[Steve Greenland]

On 20-Nov-05, 12:28 (CST), Isaac Clerencia <[EMAIL PROTECTED]> wrote: 
> Yeah, I guess he (as me) thought you meant
> "Move /usr/share/pkg to /usr/share/pkg-data/"

Yes, that's how I read that. I assumed the "put the contents of
/usr/share/foo in the foo-data packaga" was too obvious to mention.
Apparently not...

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


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

Re: My IP address seems listed as a spammer address by bugs.debian.org

[Blars Blarson]

In article <[EMAIL PROTECTED]> you write:
>(this mail was CC'ed to debian-admin but I messed up in the To field)

[EMAIL PROTECTED] would be the correct place to send this.

>Since yesterday, I'm afraid that my IP address 81.56.227.253 is listed
>on bugs.debian.org among addresses which get a "Go away" answer when
>requesting a specific bug report (http://bugs.debian.org/xx)

And as of about 9 hours ago the listing was removed.

>>From discussions I had on IRC with Anthony Towns, this seems to be
>caused by numerous requests made by my system to the BTS at regular
>intervals.

The BTS web pages are NOT designed to be abused like that.  We've had
cases where a single IP drove the load average of spohr over 80 and
basicly shut down all bug processing for hours.

As most of the obvious cases where many requests are being made to the
BTS web look like spammers harvesting email addresses, I've been
blocking systems from accessing the BTS more lately.

If you need to access the BTS data from a program, there is an LDAP
interface available and a copy of entire BTS database on one of the
developer accessable machines.

>Is there something I can do for getting my address unlisted (apart
>from again reducing the load I put on b.d.o...which I did again down
>to the lowest acceptable refresh rate on my side)?

[EMAIL PROTECTED] is the proper place to send your request.

If you can't use one of the program intfaces listed above for some
reason, put a 5 second sleep between the completion of one request and
sending the next.  That spreads the load out and gives others a chance
to access the BTS.


-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Debian Installer team monthly meeting minutes (20051119 meeting)

[Christian Perrier]

(reply-to: debian-boot)

The minutes of the November D-I (Debian Installer) team IRC meeting
are now available from the Debian Installer Meetings wiki page:

http://wiki.debian.org/DebianInstallerMeetings

Minutes:
http://people.debian.org/~bubulle/d-i/irc-meeting-20051119/minutes

Log:
http://people.debian.org/~bubulle/d-i/irc-meeting-20051119/log

The next D-I meeting will be held on Wednesday December 14th 21:00 UTC
on the #debian-boot channel on freenode.



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

Re: Spliting packages between pkg and pkg-data

[Steve Langasek]

On Sun, Nov 20, 2005 at 12:03:33PM -0600, Steve Greenland wrote:
> On 20-Nov-05, 05:13 (CST), Bill Allombert <[EMAIL PROTECTED]> wrote: 
> > When doing research about circular-deps, I looked at a lot of packages
> > that are split between a binary package and a data package. This is a
> > good thing since this reduce the total siez of the archive, however
> > there are simple rules that should be followed:
> > 
> > [*snip* good rules}
> >
> > 5) Of course move /usr/share/pkg to pkg-data.

> Why? If I install foo, I really expect it's shared data to be in
> /usr/share/foo.

I think he means the contents of /usr/share/pkg should be shipped in package
pkg-data.  (I misread this the first time, too. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Spliting packages between pkg and pkg-data

[Isaac Clerencia]

On Sunday, 20 November 2005 19:14, Bill Allombert wrote:
> On Sun, Nov 20, 2005 at 12:03:33PM -0600, Steve Greenland wrote:
> > On 20-Nov-05, 05:13 (CST), Bill Allombert <[EMAIL PROTECTED]> 
wrote:
> > > When doing research about circular-deps, I looked at a lot of packages
> > > that are split between a binary package and a data package. This is a
> > > good thing since this reduce the total siez of the archive, however
> > > there are simple rules that should be followed:
> > >
> > > [*snip* good rules}
> > >
> > > 5) Of course move /usr/share/pkg to pkg-data.
> >
> > Why? If I install foo, I really expect it's shared data to be in
> > /usr/share/foo.
>
> Does it make sense now ?
Yeah, I guess he (as me) thought you meant
"Move /usr/share/pkg to /usr/share/pkg-data/"

Best regards
-- 
Isaac Clerencia at Warp Networks, http://www.warp.es
Work: <[EMAIL PROTECTED]>   | Debian: <[EMAIL PROTECTED]>


pgpXxpLmL7mqs.pgp
Description: PGP signature

Re: Spliting packages between pkg and pkg-data

[Steve Greenland]

On 20-Nov-05, 05:13 (CST), Bill Allombert <[EMAIL PROTECTED]> wrote: 
> When doing research about circular-deps, I looked at a lot of packages
> that are split between a binary package and a data package. This is a
> good thing since this reduce the total siez of the archive, however
> there are simple rules that should be followed:
> 
> [*snip* good rules}
>
> 5) Of course move /usr/share/pkg to pkg-data.
> 

Why? If I install foo, I really expect it's shared data to be in
/usr/share/foo.

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


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

Re: Spliting packages between pkg and pkg-data

[Bill Allombert]

On Sun, Nov 20, 2005 at 12:03:33PM -0600, Steve Greenland wrote:
> On 20-Nov-05, 05:13 (CST), Bill Allombert <[EMAIL PROTECTED]> wrote: 
> > When doing research about circular-deps, I looked at a lot of packages
> > that are split between a binary package and a data package. This is a
> > good thing since this reduce the total siez of the archive, however
> > there are simple rules that should be followed:
> > 
> > [*snip* good rules}
> >
> > 5) Of course move /usr/share/pkg to pkg-data.
> > 
> 
> Why? If I install foo, I really expect it's shared data to be in
> /usr/share/foo.

Well, the whole point of the package splitting is to move 
the architecture-independent part to a separate arch: all
package. If you keep /usr/share/foo in the arch: any package, 
then there is no much point splitting it ?

For example consider a game that has a small binary and a large
dataset:
/usr/games/foo
/usr/share/games/foo/dataset

You put /usr/games/foo in a arch: any package called foo and
/usr/share/games/foo/dataset in a arch: all package called foo-data.

Does it make sense now ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Debian menu system request for help

[Bill Allombert]

Dear Debian developers and future developers,

I am been struggling with Debian menu since 3 years now.

I would like some help with checking the overall menu quality.
(menu entries and menu methods)

If you love the Debian menu system, accept it as it is, are _very_
patient, don't mind messing with other people packages, don't mind
trying 45 windows-managers, are ready to get involved for at least one
year, this is for you :) 

You don't need to be a DD.  Knowledge of C++/STL would be a plus but is
not required. Knowing how actually work Debian menu is not required, but
you will have to learn it.

The Debian menu system home page is


Please contact me if you are interested!

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpHBbf5QoCYB.pgp
Description: PGP signature

Re: I am still on the keyring. With my old key.

[Joe Smith]

"Chip Salzenberg" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Who does a developer have to fuck around here to get his key deleted?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Wait. Ignore my previous post. I had forgotten that the resignation post was 
indeed signed. It might however be the case that your key will not be 
removed until the new key makes it into the keyring. 




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

Re: I am still on the keyring. With my old key.

[Joe Smith]

"Chip Salzenberg" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Who does a developer have to fuck around here to get his key deleted?


I'm not sure your resignation was valid. Most important debian mechanisms 
require a signature from a key in the keyring.
It is hard for anybody to verify that you really are the developer named 
"chip salzenberg" without having the relevent post signed.
If nothing else the resignation shuld have been signed by the new key. 




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

Re: How to deal with dependencies/conflics on third party packages

[Steve Langasek]

On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote:

> I've got a bug report (#336527) my package bootchart-view do not work
> with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a
> packages that is not in Debian? But if it do not work with j2re1.3 it
> should more than ever not work with older version. But I would assume
> older version have different packages names. So I must add a list of
> packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the
> version clause (j2re1.3 (<< 1.3)). So what should I do?

"Does not work with j2re1.3" means you should be depending on what it *does*
work with, not trying to conflict with (unrelated) packages that don't
satisfy the dependency.

The problem here is that bootchart-view depends on '| java-virtual-machine',
which does not satisfy its runtime needs.  Depend on something more
appropriate; possibly even j2re1.4.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: I am still on the keyring. With my old key.

[Martijn van Oosterhout]

2005/11/20, Petter Reinholdtsen <[EMAIL PROTECTED]>:
> I suspect and hope the DPL try to reason with the people in question
> first, before the DPL wields his authority and push the current holder
> of privileged positions aside, as a power struggle with the overworked
> people in these privileged key positions could become ugly.  Do you
> really want the DPL to push the keyring maintainer aside and give the
> task to someone else?  Do you believe it would work, with the
> ftp-masters and the Debian system administrators on both sides of such
> conflict?

"push aside"? There's no rule that says there can be only one. Yes,
replacing someone could become ugly, but providing additional hands
can't be considered bad, can it?

Anyway, ISTM that removing keys from a keyring is much more important
than adding new ones, right?

> I seriously hope the non-elected people blocking and slowing down
> several important processes in Debian soon realize that there is a
> problem and that it might be best for them to solve it by stepping
> aside or allowing new people to help them with the tasks.

I hope there is more going on in the background that we are not seeing...

Re: Chao ban ve may bay

[TINH YEU]

  em muon mua 1 ve may bay khu hoi di tu beijing_china den sing bay vao ngay 15/12/2005 tro ve vao ngay 29/12/2005.xin hoi co' ve ko a. va gia ve la bao nhieu
		 Yahoo! FareChase - Search multiple travel sites in one click.

 

 

Processed: Re: Processed: Changed address

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 206293 mozilla-browser
Bug#206293: mozilla-browser: hangs silently very often
Warning: Unknown package '206293'
Bug reassigned from package `!' to `mozilla-browser'.

> reassign 173206 emacs21
Bug#173206: emacs21: Use of non-standard header without X- before
Warning: Unknown package '173206'
Bug reassigned from package `!' to `emacs21'.

> reassign 202620 mozilla-browser
Bug#202620: mozilla-browser: mozilla hangs regularily for some days
Warning: Unknown package '202620'
Bug reassigned from package `!' to `mozilla-browser'.

> reassign 203700 ssh
Bug#203700: ssh: WIth many public keys provided by ssh-agent, connection fail
Warning: Unknown package '203700'
Bug reassigned from package `!' to `ssh'.

> reassign 246678 debtags
Bug#246678: mkbrowser script shows warnings, invoke debtags with bad syntax and 
segfault
Warning: Unknown package '246678'
Bug reassigned from package `!' to `debtags'.

> reassign 248664 bind9
Bug#248664: bind9: named-checkzone doesn't check serial anymore
Warning: Unknown package '248664'
Bug reassigned from package `!' to `bind9'.

> reassign 173494 vim-gtk
Bug#173494: vim-gtk: All modes with same cursor
Warning: Unknown package '173494'
Bug reassigned from package `!' to `vim-gtk'.

> reassign 199709 mutt
Bug#199709: mutt: Attachments are automatically displayed even with 
'Content-Disposition: attachment'
Warning: Unknown package '199709'
Bug reassigned from package `!' to `mutt'.

> reassign 241866 jzip
Bug#241866: jzip: Reset terminal when exiting
Warning: Unknown package '241866'
Bug reassigned from package `!' to `jzip'.

> reassign 248501 gman
Bug#248501: gman: Should not try to view HTML when man2html is not available
Warning: Unknown package '248501'
Bug reassigned from package `!' to `gman'.

> reassign 206374 xml-resume-library
Bug#206374: xml-resume-library: should Depends on available XSL and XSL-FO 
processors
Warning: Unknown package '206374'
Bug reassigned from package `!' to `xml-resume-library'.

> reassign 266021 ifupdown
Bug#266021: Please implement manual method for IPv6
Warning: Unknown package '266021'
Bug#205583: ifupdown: option to define an inet6 interface without address
Warning: Unknown package '266021'
Bug reassigned from package `!' to `ifupdown'.

> reassign 201639 wnpp
Bug#201639: RFP: limsee2 -- A cross-platform SMIL2.0 authoring tool
Warning: Unknown package '201639'
Bug reassigned from package `!' to `wnpp'.

> reassign 204606 wnpp
Bug#204606: RFP: archmage -- arCHMage is an extensible reader and decompiler 
for files in the CHM format.
Warning: Unknown package '204606'
Bug#313203: ITP: archmage -- CHM (Compiled HTML) Decompressor
Warning: Unknown package '204606'
Bug reassigned from package `!' to `wnpp'.

> reassign 205024 purity
Bug#205024: purity list should return the actual list of available tests
Warning: Unknown package '205024'
Bug reassigned from package `!' to `purity'.

> reassign 206931 wnpp
Bug#206931: libw3c-logvalidator-perl -- Web server log analysis tool to 
validate the N most popular documents
Warning: Unknown package '206931'
Bug reassigned from package `!' to `wnpp'.

> reassign 212022 netrik
Bug#212022: netrik: should handle gzip encoding
Warning: Unknown package '212022'
Bug reassigned from package `!' to `netrik'.

> reassign 229715 general
Bug#229715: apt: Add a "postinst command spool"
Warning: Unknown package '229715'
Bug reassigned from package `!' to `general'.

> reassign 248526 gman
Bug#248526: gman: Format PS output according to screen size
Warning: Unknown package '248526'
Bug reassigned from package `!' to `gman'.

> reassign 248529 groff
Bug#248529: groff: Do roff(7) must be an advertisement for Emacs?
Warning: Unknown package '248529'
Bug reassigned from package `!' to `groff'.

> reassign 264108 lxr
Bug#264108: Files installed in /var/lib/lxr should be in /usr/share/lxr
Warning: Unknown package '264108'
Bug reassigned from package `!' to `lxr'.

> reassign 217899 argouml
Bug#217899: argouml: Packages and source code generation for other languages
Warning: Unknown package '217899'
Bug reassigned from package `!' to `argouml'.

> reassign 206390 libxalan2-java
Bug#206390: libxalan2-java: provide a command-line wrapper
Warning: Unknown package '206390'
Bug reassigned from package `!' to `libxalan2-java'.

> reassign 217878 argouml
Bug#217878: argouml: changes the type of an atrribute to BigDecimal when 
selecting it
Warning: Unknown package '217878'
Bug reassigned from package `!' to `argouml'.

> reassign 224383 vim
Bug#224383: vim: Vim can create swap files it won't read
Warning: Unknown package '224383'
Bug reassigned from package `!' to `vim'.

> reassign 192422 wnpp
Bug#192422: RFP: parsec -- multiplayer cross-platform 3D Internet space combat
Warning: Unknown package '192422'
Bug reassigned from package `!' to `wnpp'.

> reassign 198826 wnpp
Bug#198826: RFP: smilgen -- SMILGen is a SMIL (and XML) authoring tool designed 
to ease the process of XML conten

Re: Processed: Changed address

[Pierre THIERRY]

reassign 206293 mozilla-browser
reassign 173206 emacs21
reassign 202620 mozilla-browser
reassign 203700 ssh
reassign 246678 debtags
reassign 248664 bind9
reassign 173494 vim-gtk
reassign 199709 mutt
reassign 241866 jzip
reassign 248501 gman
reassign 206374 xml-resume-library
reassign 266021 ifupdown
reassign 201639 wnpp
reassign 204606 wnpp
reassign 205024 purity
reassign 206931 wnpp
reassign 212022 netrik
reassign 229715 general
reassign 248526 gman
reassign 248529 groff
reassign 264108 lxr
reassign 217899 argouml
reassign 206390 libxalan2-java
reassign 217878 argouml
reassign 224383 vim
reassign 192422 wnpp
reassign 198826 wnpp
reassign 198828 wnpp
reassign 198829 wnpp
reassign 204472 wnpp
reassign 204475 wnpp
reassign 212343 wnpp
reassign 221795 wnpp
reassign 221796 wnpp
reassign 221798 wnpp
reassign 235729 wnpp
reassign 184482 lynx
thanks

Sorry for the annoyance, I used reassign instead of submitter by
mistake.

Quickly,
Nowhere man
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Processed: Changed address

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 206293 !
Bug#206293: mozilla-browser: hangs silently very often
Warning: Unknown package '206293'
Bug reassigned from package `mozilla-browser' to `!'.

> reassign 173206 !
Bug#173206: emacs21: Use of non-standard header without X- before
Warning: Unknown package '173206'
Bug reassigned from package `emacs21' to `!'.

> reassign 202620 !
Bug#202620: mozilla-browser: mozilla hangs regularily for some days
Warning: Unknown package '202620'
Bug reassigned from package `mozilla-browser' to `!'.

> reassign 203700 !
Bug#203700: ssh: WIth many public keys provided by ssh-agent, connection fail
Warning: Unknown package '203700'
Bug reassigned from package `ssh' to `!'.

> reassign 246678 !
Bug#246678: mkbrowser script shows warnings, invoke debtags with bad syntax and 
segfault
Warning: Unknown package '246678'
Bug reassigned from package `debtags' to `!'.

> reassign 248664 !
Bug#248664: bind9: named-checkzone doesn't check serial anymore
Warning: Unknown package '248664'
Bug reassigned from package `bind9' to `!'.

> reassign 173494 !
Bug#173494: vim-gtk: All modes with same cursor
Warning: Unknown package '173494'
Bug reassigned from package `vim-gtk' to `!'.

> reassign 199709 !
Bug#199709: mutt: Attachments are automatically displayed even with 
'Content-Disposition: attachment'
Warning: Unknown package '199709'
Bug reassigned from package `mutt' to `!'.

> reassign 241866 !
Bug#241866: jzip: Reset terminal when exiting
Warning: Unknown package '241866'
Bug reassigned from package `jzip' to `!'.

> reassign 248501 !
Bug#248501: gman: Should not try to view HTML when man2html is not available
Warning: Unknown package '248501'
Bug reassigned from package `gman' to `!'.

> reassign 206374 !
Bug#206374: xml-resume-library: should Depends on available XSL and XSL-FO 
processors
Warning: Unknown package '206374'
Bug reassigned from package `xml-resume-library' to `!'.

> reassign 266021 !
Bug#266021: Please implement manual method for IPv6
Warning: Unknown package '266021'
Bug#205583: ifupdown: option to define an inet6 interface without address
Warning: Unknown package '266021'
Bug reassigned from package `ifupdown' to `!'.

> reassign 201639 !
Bug#201639: RFP: limsee2 -- A cross-platform SMIL2.0 authoring tool
Warning: Unknown package '201639'
Bug reassigned from package `wnpp' to `!'.

> reassign 204606 !
Bug#204606: RFP: archmage -- arCHMage is an extensible reader and decompiler 
for files in the CHM format.
Warning: Unknown package '204606'
Bug#313203: ITP: archmage -- CHM (Compiled HTML) Decompressor
Warning: Unknown package '204606'
Bug reassigned from package `wnpp' to `!'.

> reassign 205024 !
Bug#205024: purity list should return the actual list of available tests
Warning: Unknown package '205024'
Bug reassigned from package `purity' to `!'.

> reassign 206931 !
Bug#206931: libw3c-logvalidator-perl -- Web server log analysis tool to 
validate the N most popular documents
Warning: Unknown package '206931'
Bug reassigned from package `wnpp' to `!'.

> reassign 212022 !
Bug#212022: netrik: should handle gzip encoding
Warning: Unknown package '212022'
Bug reassigned from package `netrik' to `!'.

> reassign 229715 !
Bug#229715: apt: Add a "postinst command spool"
Warning: Unknown package '229715'
Bug reassigned from package `general' to `!'.

> reassign 248526 !
Bug#248526: gman: Format PS output according to screen size
Warning: Unknown package '248526'
Bug reassigned from package `gman' to `!'.

> reassign 248529 !
Bug#248529: groff: Do roff(7) must be an advertisement for Emacs?
Warning: Unknown package '248529'
Bug reassigned from package `groff' to `!'.

> reassign 264108 !
Bug#264108: Files installed in /var/lib/lxr should be in /usr/share/lxr
Warning: Unknown package '264108'
Bug reassigned from package `lxr' to `!'.

> reassign 217899 !
Bug#217899: argouml: Packages and source code generation for other languages
Warning: Unknown package '217899'
Bug reassigned from package `argouml' to `!'.

> reassign 206390 !
Bug#206390: libxalan2-java: provide a command-line wrapper
Warning: Unknown package '206390'
Bug reassigned from package `libxalan2-java' to `!'.

> reassign 217878 !
Bug#217878: argouml: changes the type of an atrribute to BigDecimal when 
selecting it
Warning: Unknown package '217878'
Bug reassigned from package `argouml' to `!'.

> reassign 224383 !
Bug#224383: vim: Vim can create swap files it won't read
Warning: Unknown package '224383'
Bug reassigned from package `vim' to `!'.

> reassign 192422 !
Bug#192422: RFP: parsec -- multiplayer cross-platform 3D Internet space combat
Warning: Unknown package '192422'
Bug reassigned from package `wnpp' to `!'.

> reassign 198826 !
Bug#198826: RFP: smilgen -- SMILGen is a SMIL (and XML) authoring tool designed 
to ease the process of XML content creation.
Warning: Unknown package '198826'
Bug reassigned from package `wnpp' to `!'.

> reassign 198828 !
Bug#198828: RFP: pykota -- PyKota is a com

Re: How to deal with dependencies/conflics on third party packages

[sean finney]

hi joerg,

On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote:
> I've got a bug report (#336527) my package bootchart-view do not work
> with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a
> packages that is not in Debian? But if it do not work with j2re1.3 it
> should more than ever not work with older version. But I would assume
> older version have different packages names. So I must add a list of
> packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the
> version clause (j2re1.3 (<< 1.3)). So what should I do?

adding conflicts lines for packages that don't exist in debian has
limited effectiveness imo.  even if there are packages (blackdown, or
whatever) for j2re, i would imagine that there's a large number of
users out there (myself included) who simply download the installer
from sun and installed java sans-package.

i'd consider simply adding a note to README.Debian/NEWS.Debian about
said problem, and being done with it altogether.  maybe leave the bug
open at wishlist+wontfix for reference too, i guess.


sean

-- 


signature.asc
Description: Digital signature

Re: How to deal with dependencies/conflics on third party packages

[Michael Koch]

On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote:
> Hi,
> 
> I've got a bug report (#336527) my package bootchart-view do not work
> with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a
> packages that is not in Debian? But if it do not work with j2re1.3 it
> should more than ever not work with older version. But I would assume
> older version have different packages names. So I must add a list of
> packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the
> version clause (j2re1.3 (<< 1.3)). So what should I do?

Dont use a Conflicts: as this would deinstall j2re1.3 from the system.
The correct solution would be to check the version in your binary and
fail if the java version is too old.

BTW: the Debian Java Maintainers group is thinking about a more general
solution of this problem.


Cheers,
Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/


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

How to deal with dependencies/conflics on third party packages

[Joerg Sommer]

Hi,

I've got a bug report (#336527) my package bootchart-view do not work
with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a
packages that is not in Debian? But if it do not work with j2re1.3 it
should more than ever not work with older version. But I would assume
older version have different packages names. So I must add a list of
packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the
version clause (j2re1.3 (<< 1.3)). So what should I do?

Thanks for help, Jörg.
-- 
"UNIX was not designed to stop people from doing stupid things, because
 that would also stop them from doing clever things."
 -- Doug Gwyn


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

Spliting packages between pkg and pkg-data

[Bill Allombert]

Hello Debian developers,

When doing research about circular-deps, I looked at a lot of packages
that are split between a binary package and a data package. This is a
good thing since this reduce the total siez of the archive, however
there are simple rules that should be followed:

1) Make sure pkg-data is actually arch: all.

2) Name it in a way that make the relationship obvious: For example,
   if the upstream name is 'foo', name the binary package 'foo' and the
   data package 'foo-data'.  

3) Keep the files that 'signal' executables in the same package than the
   executable (e.g. menu file, program manpage).

4) Do not put symlinks in data packages that point to files in the binary
   package. This do not really save space and avoid dandling symlinks
   when the binary package is not installed.

5) Of course move /usr/share/pkg to pkg-data.

6) Do not make pkg-data to Depends on pkg.

7) Try to do it correctly the first time: if you move file between
   pkg and pkg-data, you will need to use Replaces:

Please check your packages follow these rules, and if not, do not forget
about rule 7.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Debian Nag NMU in delayed queue

[Lionel Elie Mamane]

(If [EMAIL PROTECTED] is not the same person as
 [EMAIL PROTECTED], then apologies, this was not for you,
 [EMAIL PROTECTED])

Hi,

I've uploaded an NMU of nag to tfheen's delayed queue on gluck to fix
this bug. It will be uploaded to Debian in 7 days. If you (Fabio
Rafael da Rosa <[EMAIL PROTECTED]>) oppose this, I'll
immediately cancel it.

I notice you have been quite inactive Debian-wise, for _all_ your
packages. If you want to stop Debian work, could you please cleanly
orphan your packages (see
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-orphaning)
and retire from Debian (see
http://www.nl.debian.org/doc/developers-reference/ch-developer-duties.en.html#s3.7)?

(In this case, I'll probably take over nag and mnemo.)

If the problem is that you are not a DD but lost your sponsor, I'd be
glad to sponsor you.

In all cases, please get in touch so that we "know" you haven't
disappeared.


Best Regards,

-- 
Lionel Elie Mamane <[EMAIL PROTECTED]>


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

Re: I am still on the keyring. With my old key.

[Petter Reinholdtsen]

[Nathanael Nerode]
> It's a pity the DPL hasn't anointed a less-busy person with
> authority to alter the keyring.

I suspect and hope the DPL try to reason with the people in question
first, before the DPL wields his authority and push the current holder
of privileged positions aside, as a power struggle with the overworked
people in these privileged key positions could become ugly.  Do you
really want the DPL to push the keyring maintainer aside and give the
task to someone else?  Do you believe it would work, with the
ftp-masters and the Debian system administrators on both sides of such
conflict?

I seriously hope the non-elected people blocking and slowing down
several important processes in Debian soon realize that there is a
problem and that it might be best for them to solve it by stepping
aside or allowing new people to help them with the tasks.


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

Re: Building windows versions of debian packages

[Paul Wise]

On Sat, 2005-11-19 at 23:02 +0100, Enrico Tassi wrote:

> mh... I do not completely agree... I think a separate repo should be
> the way to start... but at the end I would like to see these packages
> in debian... the best developing environment (not only the best OS).
> 
> If you want to start this nice "project"...
> I can help a bit

Perhaps the people on the debian-win32 list (or its archives) can be
used as a starting point?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#340000: ITP: cmus -- C* music player - text mode audio player

[Julien Louis]

Package: wnpp
Severity: wishlist
Owner: Julien Louis <[EMAIL PROTECTED]>

* Package name: cmus
  Version : 1.6.4
  Upstream Author : Timo Hirvonen <[EMAIL PROTECTED]>
* URL : http://onion.dynserv.net/~timo/index.php?page=Projects/cmus
* License : GPL
  Description : C* music player - text mode audio player

 C* Music Player is a modular and very configurable ncurses-based audio player.
 It has some interesting features like configurable colorscheme, mp3 and ogg
 streaming, it can be control with an UNIX socket, filters, album/artists
 sorting and a vi-like configuration interface.
 .
 It currently supports different input formats:
  - Ogg Vorbis
  - MP3 (with libmad)
  - FLAC
  - Wav
  - Modules (with libmodplug)

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-k7
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

-- 
Io ! l'âme y a borné en Robaye ma loi
-- Rapilly, Robert


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

Re: My IP address seems listed as a spammer address by bugs.debian.org

[Florian Weimer]

* Christian Perrier:

> Is there something I can do for getting my address unlisted (apart
> from again reducing the load I put on b.d.o...which I did again down
> to the lowest acceptable refresh rate on my side)?

There is a BTS mirror on merkel.  Maybe you could mirror the bug
reports you are interested in from there?


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

Re: Uploading amd64 packages

[Jérôme Marant]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> And why would you need to do that?
>
> [This might sound harsh but it isn't ment as critizism] Is the
> inconvenience of having a i386 chroot on your amd64 to build and
> upload packages too much? You should have a chroot for building
> packages anyway so what does it matter if it is 32bit or 64bit?

I'm afraid, I don't like the tell-me-what-you-need-I'll-tell-you
how-to-get-along-without-it kind of answers. I serves status quo,
not progress.
There are plenty of other relevant solutions that could have
been setup already.

> Once the source enters debian the amd64 archive will pick it up on the
> next dinstall run and the buildd will build the packages.
>
> If you need more, e.g. to upload to stinkypete or in case of binNMUs
> just ask in #debian-amd64 or, if it becomes more frequent, request a
> ssh login to the amd64 queue.

Noted. Thanks.

-- 
Jérôme Marant