Example for use of dh_strip --dbg-package=... and CDBS?

2005-03-02 Thread W. Borgert
Hi,

are there any CDBS based packages using dh_strip with the
--dbg-package option?  I tried, but no /usr/lib/debug/
directory is created.  I'm using debhelper 4.2.30 with
cdbs 0.4.26-1.1.  Many thanks in advance!

Cheers, WB


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



Re: Example for use of dh_strip --dbg-package=... and CDBS?

2005-03-03 Thread W. Borgert
Quoting Josselin Mouette <[EMAIL PROTECTED]>:
> I'm using it with fontconfig, just have a look at the rules file.

Thanks to Aaron and Josselin!  My fault was to set
--dbg-package=libfoo-dbg instead of --dbg-package=libfoo :-)
Both fltk1.1 and fontconfig are fine examples.

Cheers!


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



Re: CDBS and other build systems

2005-11-14 Thread W. Borgert
Quoting "Ivan S. Dubrov" <[EMAIL PROTECTED]>:
> The problem is I can't find thorough documentation or some kind of "How To"
> there I can find how to write these extensions. Although they just simply
> pieces of make-files, I find it difficult to start understanding them. For
> example, the diffirence between "rule" and "class" are not very clear for me.

I like CDBS a lot and all my packages use it. Unfortunately, the
documentation is not very extensive. OTOH, the variables are well
documented in the makefiles, i.e. just read through
/usr/share/cdbs/1/{class,rules/*

Furthermore, there is
https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
in English and
http://www.ngolde.de/cdbs.html
in German.

Other things, I did: I looked for packages build-depending on
CDBS and stole from the debian/rules, and I asked "stupid"
questions on the CDBS hackers spam exploder:
http://lists.alioth.debian.org/mailman/listinfo/build-common-hackers
With some luck, questions get answered.

Cheers, WB


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



Re: Uploading amd64 packages

2005-11-20 Thread 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: Bug#336698: dh_strip: debug data going to the wrong place

2005-11-20 Thread 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: texlive-basic_2005-1_i386.changes REJECTED

2005-11-28 Thread W. Borgert
Quoting Thiemo Seufer <[EMAIL PROTECTED]>:
> Arabic is "ar", IIRC. For groups of languages like cjk or indic it might
> make sense to split the packages further, or, if that's not feasible,
> use e.g. texlive-cjk-lang (but make sure the abbreviation is not ISO-style
> two-character).

ISO-style can be two-character (ISO 639-1) or three-letter (ISO 639-2).
The latter is IMHO more useful for TeX, as more languages have a code.
Arabic is either "ar" or "ara", Aramaic is "arc", Apache is "apa"...
"cjk" is currently not an ISO code, but it could be in the future.
However, cjk is well-known, so ISO would be very stupid to use this
code for anything else than zho-jpn-kor. Indic already has an ISO
language code: "inc".

Cheers, WB


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



Multiple package variants with CDBS?

2006-01-28 Thread W. Borgert
Hi,

I have a package that is configured and compiled two times, so
that two binary packages are built in one dpkg-buildpackage run:
One with --enable-gnome, the second without. Is this supported
by CDBS somehow? Is there a package, that already does such a
thing using CDBS? Any hint or example debian/rules file
appreciated, thanks in advance!

Cheers, WB


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



dh_installinit and update-rc.d start vs. restart

2005-01-29 Thread W. Borgert
Hi,

for some kind of CDD I have created a package "X" that changes
another packages "Y" config file (using cfengine) and restarts
the respective daemon.  That works well, if I upgrade package
X only or Y only.

Problem: If I upgrade both package X and Y at the same time
the daemon of package Y will be stopped, than X changes the
config, restarts daemon of Y, finally Y tries to start its
daemon, but fails, as it already runs.

If package X would update-rc.d restart in postinst, it would
be perfect, right?  Is there a convince dh_installinit to
use "restart" instead of "start" in package X?  Are there
other ways to solve such a problem?

Cheers, WB

Btw: Both X and Y use CDBS and debhelper.


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



Re: dh_installinit and update-rc.d start vs. restart

2005-01-29 Thread W. Borgert
Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
> File a serious bug against package Y.  initscripts have to exit with a
> successfull status if the daemon is already running.

OK.  As this package Y is not (yet) part of Debian, I just changed
it: I added --oknodo to start-stop-daemon and check for $? -eq 0.
Seems to work, thanks!

Cheers, WB


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



Is there a serious NPTL problem with sarge?

2005-04-07 Thread W. Borgert
Hi,

a colleague observed crashes in some heavily multi-threaded Python
applications.  He is running Debian sarge with stock kernel
2.6.8-2-686.  Using LD_ASSUME_KERNEL "fixes" the crash, so it seems
to be an NPTL issue.  (Maybe stupid) questions:

- Is it relevant, whether Python is compiled on a system with 2.6
  or 2.4 kernel?  If so, how can I find out on which kernel the
  Debian package has been built?

  In
  http://mail.python.org/pipermail/python-bugs-list/2005-February/027693.html
  Martin von Loewis wrote: "The real problem is that, apparently,
  linuxthreads and NPTL are not binary-compatible. So in fact, an
  installation with NPTL should be considered as a different
  operating system, and you cannot expect to move binaries from
  one operating system to another. Instead, you have to recompile
  the binaries."

- Is the Debian stock 2.4 kernel patched to be compatible with
  NPTL?  If not, isn't there a problem for some multi-threaded
  applications to switch between 2.4 and 2.6?  (Note: AFAIK, RH,
  Mdk, and SuSE use some patch, at least Fedora seems to have
  "nptl" in the 2.4 kernel version number.)

Thanks in advance for any clarification.

Cheers, WB


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



Re: Bug#304401: ITP: libstatgrab -- library providing interface to system statistics

2005-04-13 Thread W. Borgert
Webpage: http://www.i-scream.org/libstatgrab/
not www.example.org :-)

It would be great, if you package pystatgrab
(http://www.i-scream.org/pystatgrab/) as well.


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



Provide a DocBook/XML version

2005-04-14 Thread W. Borgert
Package: vera
Version: 1.12-1

Please provide a dbk version of vera, as this can be used
by document authors (automatic inclusion of used glossary
entries is supported by docbook-xsl!).  [Note: Maybe it's
easier to use dbk as source format and generate info than
the other way around.]

Btw.: You should ask upstream, whether he likes to change
the GFDL of vera into GPL (or to dual license it).

Example for DocBook glossary from
http://www.faqs.org/docs/docbook/html/glossary.html:

http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";>
Example Glossary

This is not a real glossary, it's just an example.




E

Extensible Markup Language
  XML

  Some reasonable definition here.
  SGML







S

SGML



Standard Generalized
  Markup LanguageSGML
  ISO 8879:1986

  Some reasonable definition here.
  XML







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



Bug#315903: ITP: evilfinder -- proves that any given subject is evil

2005-06-26 Thread W. Borgert
Package: wnpp
Severity: wishlist
Owner: "W. Borgert" <[EMAIL PROTECTED]>

Package name: evilfinder
Version : 666(?)
Upstream Author : Michal Zalewski <[EMAIL PROTECTED]>
URL : http://lcamtuf.coredump.cx/evilfinder/ef.shtml
License : under clarification, hopefully GPL
Description : proves that any given subject is evil

Example output for input "Debian":

 THE PROOF THAT Debian IS EVIL 

   D   E   B   I   A   N
   4   5   2   9   1  14 - as numbers
   4   5   2   9   1   5 - digits added
  \_/ \_/ \_/ \_/ \_/
   4   5   2   9   6 - digits added

Thus, "Debian" is 45296.


Subtract 140, the smallest harmonic divisor number. The result will be 45156.

Turn the number backwards, subtract 1926 - the year "Playboy" publisher, Hugh 
Hefner, was born. The number is now 63228.

Subtract 1789, the year of French Revolution, a bloody farce engineered by the 
Illuminati. The result will be 61439.

Add 7691 to it - this is the year Che Guevara was executed in Bolivia, written 
backwards - you will get 69130.

Turn the number backwards, subtract 1964 - the year Beatles with "Can't buy me 
love" topped the charts in a very mysterious way. The number is now 1232.

This number, read as octal, gives 666 - the number of the Beast.

This is truly evil. QED.


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



Re: Bug#315903: ITP: evilfinder -- proves that any given subject is evil

2005-06-27 Thread W. Borgert
Quoting David Pashley <[EMAIL PROTECTED]>:
> Do we really need this in the archive? Can we not add this to another
> package under games? It is rather small and doesn't serve a significant
> amount of functionality.

Yes.  Please suggest a package.


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



Embedded(/RT) Debian? Embeddian GNU/Linux?

2000-03-15 Thread W. Borgert
Hi,

does anybody know, wether there are ideas or plans to make
an Debian GNU/Linux especially for embedded and/or realtime
systems, i.e. "Embedian GNU/Linux"?  I think, that the
Linux Router Project was once based on Debian, but this is
very specialised on one task.  And I don't know what Mobile
Linux (Crusoe) will be.

I think, that the standard Debian GNU system is not well
suited for embedded systems, because

- policy requires docs and man pages, but one does not want
  any docs or man pages on an embedded system;

- the base system/required packages is far too much for
  embedded systems, e.g. one does not want perl necessarily;

- packages have to be even more fine-grained, or one does
  need some options to install packages partially.

OTOH, embedded Debian GNU would be cool, because,

- superior package management;

- large number of packages in potato;

- good Debian infrastructure;

- it would be easy to have one distribution, that would
  work for a lot of different computers, like routers,
  telephones, VCRs, ATMs, washing machines, PDAs...

Well, is there sth. like this already or are people working
on this?

TIA,
-- 
W. Borgert <[EMAIL PROTECTED]>



ITP: ttcn-el (programming modes for protocol test)

2000-04-01 Thread W. Borgert
Hallo,

I am right now packaging three Emacs programming modes, I
wrote between 1997 and last week: ttcn3.el, ttcn.el, and
tm.el.  These are for the TTCN-3 core language, the current
TTCN.MP language (version 2), and the Test Manager language
(an Forth enhancement of the Tektronix K1297 protocol
tester).  So, it's all related to protocol testing.  I'll
release this under GPL, of course.

Section: editors
Priority: optional
Package: ttcn-el
Architecture: all
Depends: emacsen
Description: GNU Emacs modes for TTCN-3/protocol testing languages.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>



Usability: Technical details in package descriptions?

2005-07-20 Thread W. Borgert
Hi,

what do you think about the usefulness of technical (and other
strange) details in package description?  I think, those are
annoying and should be avoided, but maybe I can learn, why they
are useful.  Examples:

"Foo is a Perl-based program that..."

"libBar is written in C..."

"libBang is written in only 42 lines of source code..."

"Baz has been written by me..."

Do such descriptions justify bug reports of severity=minor?

Cheers, WB


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



How to use svn(-buildpackage) with pbuilder?

2005-07-31 Thread W. Borgert
Hi,

what is the right/best way to build packages from SVN using
pbuilder?  I am new to both, please be patient.

Suppose, I have a package with complete upstream sources (no
tarballs) under svn://svn.debian.org/svn/pkg-greetings/hello/
with the subdirectories branches/, tags/, and trunk/.

- How do I have to arrange the repository, so that
  svn-buildpackage differentiates correctly upstream and debian
  stuff?  Is it correct to have the upstream source only under
  pkg-greetings/hello/tags/1.0/ and the complete debianised tree
  under pkg-greetings/hello/tags/1.0-1/?  Or do I have to put
  the upstream under pkg-greetings/hello/branches/upstream/1.0/?

- How do I call svn-buildpackage, so that pbuilder is used?  Is
  --svn-builder=pdebuild enough?

- Has somebody a good build script that does all steps
  automatically?  1. checkout from svn, 2. build in pbuilder,
  3. run linda, 4. run lintian, 5. run piuparts.

Many thanks in advance!

Cheers, WB


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



Re: RFC: allow new upstream into stable when it's the only way to fix security issues.

2005-07-31 Thread W. Borgert
On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote:
> (1) keep vulnerable packages in stable,
> (2) remove affected packages from distribution,
> (3) allow new upstream into stable.
...
> What do you think on this?

I'ld "vote" for (2), maybe with the goal of creating pressure
towards upstream to take security more serious.  Don't forget:
The new versions will bring trouble to our poor users, as it's
not API nor ABI compatible, has different bugs, etc.  Can't
Debian + Ubuntu + ... create enough demand for useful security
patches?  Remember the KDE/Qt licensing discussion...

(3) is second best.  At least typical server installations are
not affected (we use w3m, don't we?) and desktop users are used
to frustration anyway.  (1) is not an option.

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: RFC: allow new upstream into stable when it's the only way to fix security issues.

2005-08-01 Thread W. Borgert
On Sun, Jul 31, 2005 at 10:07:10PM +, Roland Rosenfeld wrote:
> But how do you push the users to remove the package from their
> systems?  In reality they will keep the broken version installed and
> so you have (1) again :-(

Empty package with a higher version number?

Cheers, WB


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



Re: How to use svn(-buildpackage) with pbuilder?

2005-08-02 Thread W. Borgert
On Sun, Jul 31, 2005 at 07:03:14AM -0400, Yaroslav Halchenko wrote:
> borrowed from a nice minimalistic HOWTO
> http://workaround.org/moin/SvnBuildpackage

That is indeed a very helpful HOWTO.  Thanks!

> 3 and 5 just add them to --svn-postbuild as IT IS SAID IN THE MAN PAGE:

:-) OK, thanks.

One more question, I could not answer myself from reading the
man page:

If I have the complete upstream source in SVN, but not the
.tar.gz, how do I create the .orig.tar.gz, when I have a new
upstream version?

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: How to use svn(-buildpackage) with pbuilder?

2005-08-03 Thread W. Borgert
On Tue, Aug 02, 2005 at 03:49:54PM -0400, Yaroslav Halchenko wrote:
> Look down the thread -- your question was answered:
>
> Date: Mon, 01 Aug 2005 16:03:03 +0200
> From: Arjan Oosting <[EMAIL PROTECTED]>
>
> It is, the orig.tar.gz is created if you do a
>  FORCEEXPORT=yes svn-buildpackage

Works OK, thanks.  There should be an automatised way: If it's a
'xxx-1' version (first package of an upstream release), the
.orig.tar.gz should be created, otherwise not.

Cheers, WB


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



Re: shouldn't I use update-alternatives for this?

2005-08-11 Thread W. Borgert
Quoting Sebastian Kuzminsky <[EMAIL PROTECTED]>:
> I've pushed the "rename it upstream" idea on the upstream maintainers
> twice now and it gets shut down by both Linus (the original author)
> and Junio (the current maintainer). [2]

There is still the option to rename it for Debian only,
without changing it upstream.  Not really nice, but
possible and used in the past, IIRC.

> Qingning Huo suggested using diversions to make /usr/bin/git a little
> selector script that lets the admin & user choose between git-the-shell
> and git-the-scm.  This sounds good to me, who objects?

Aarrgghh! :-) That's what alternatives are for and people
already objected for good reasons.  Please not.

Either rename the executable to /usr/bin/git-the-scm (or
whatever) or conflict with the other git.  Or ask the
other git people to rename their binary.  Maybe git-the-scm
is (or will be) in wider use than git-the-shell, so it
might be OK to rename the more "obscure" executable.

Cheers, WB


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



Re: shouldn't I use update-alternatives for this?

2005-08-11 Thread W. Borgert
Quoting Henning Makholm <[EMAIL PROTECTED]>:
> Conflicting is Not An Option. So policy says, for good reasons.

OK, bad idea.

> There is precedence to consider. Sarge already contains a git package
> that provides /usr/bin/git. Users who update from sarge to etch would
> not be served well if the software they are used to suddenly changes
> name just to accommodate a newcomer.
>
> OTOH, cogito is not in sarge; there are no prior user expectations
> about what its command name should be.

Well, there will be user expectations (e.g. if people use cogito-git
on other distributions as well), but I agree: We can live with that.

Cheers, WB


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



Re: runlevels remodeled

2005-08-12 Thread W. Borgert
Quoting Timo Aaltonen <[EMAIL PROTECTED]>:
>Is there will to change the current policy regarding runlevels in
> Debian? I'd propose to use the recommendation made by LSB:

IIRC, there were discussions about that issue.  I don't remember
the outcome and would like to see Debian more LSBish here.

Cheers, WB


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



Re: New appearance of bugs on BTS web pages

2005-08-13 Thread W. Borgert
On Fri, Aug 12, 2005 at 04:26:00PM -0400, Roberto C. Sanchez wrote:
> However, I am wondering if it is a bug that the pages are not even valid
> HTML 4.01.  Is this a bug?  Should I file a bug agains the b.d.o psuedo

Shouldn't it be XHTML nowadays?

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]



README - confusing, irrelevant, redundant, useless

2005-08-14 Thread W. Borgert
Hi,

I have to start yet another discussion about our packaging
practise.  Did anyone ever take a look at our
/usr/share/doc//README{,.gz} files?  If the users have
difficulties with a package, we often reply "Why didn't you read
the README?  It's called README for a reason!"  However, the
README files are cluttered with confusing, irrelevant,
redundant, and useless stuff.  That way, we educate our users
not to ReadTheFineReadme.

Do you think, that this does any favour to our users?  E.g.

- "Debian packages of this software are currently available.
  It should be possible to run "apt-get install " and
  have a recent version installed."

  This is a Debian package, so what?

- "Please send bug reports, requests for features, etc. to
  ."

  Don't we ask our users to use our BTS primarily?

- "To build , please run: ./configure; make; make
  install."

  This is OK to have in the source, but not in the .deb.  Same
  goes for information about possible configuration options.
  OTOH, the configuration options actually used in the Debian
  package are seldomly documented :-(

- ...long history of who maintained the package when...

  This information - not really relevant to the user - is, of
  course, in the changelog as well.

- ...stuff about API usage in a library package...

  That does belong to the -dev package only, right?

- "Common options: --foo --bar --baz"

  According to our policy, the program has a manual page.  While
  it's not bad, to repeat the information in other formats, it
  does - IMHO - not make sense in a README.

- "Readme file for ."

  Really?

- "This program is..." - exact copy of the package description.

  This README is redundant.

- "$Id: ... $" (one line Id plus four lines of text)

  Maybe I become picky, but CVS/RCS ids are not relevant to the
  user, esp. if the remainder of the README is irrelevant, too.

- "The latest version of  can be obtained at ."

  As a Debian user, I expect to get packages the Debian way.
  It's nice to have the upstream website address, but according
  to our policy I can find it in the copyright file.

Package maintainers, please:

1. Do not include the upstream README in the binary package, if
   it's not really important to the user.

2. Just copy the 5..10% of relevant information into the
   README.Debian, if appropriate.

3. Don't invent a README file artificially, if you don't have
   to say anything.

4. File minor bugs about such README files.

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]



Dogme05: Team Maintenance

2005-08-14 Thread W. Borgert
Hi,

as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams.  A fine way to do this, is by
having a pkg- project at alioth.debian.org.  It is useful to
invite non-DDs, esp. upstream developers and people from Debian
derivatives to participate in such teams.

Assumptions:

I. The most important packages in Debian are maintained by
   teams.  The experience with that modus operandi is very good.

II. Team maintainance gives higher quality packages, as more
people look at the packaging details.

III. The responsiveness on bug reports is higher, as more people
 can react without having to NMU.  Adjustments between team
 members can slow down this, but this is just a matter of
 agreements inside the team.

IV. Less need to orphan packages, as most teams will not
collapse, if a single maintainer drops out.  Less work for
our lion-hearted QA team.

V. If not at least two maintainers can be found for a particular
   package, it is not worthwhile to have it in Debian, at least
   not in a release.  experimental is OK.

VI. The advantages of team maintenance outweigh the problem of
team maintenance overhead.

VII. Team maintainence helps us to collaborate with upstream
 and derivers.

VIII. Packages not maintained by teams are not to go into
  unstable/testing/stable.

IX. As alioth becomes even more important to Debian, we will
have to strengthen (HA-ing) this resource.

X. Teams shall meet online or in sauna.  They are allowed to do
   DDR or ballroom dancing.

[Dogme05 is, of course, a pun on Dogme95.]

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


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



Re: Bug#323076: ITP: dealer -- bridge hand generator

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 06:58:40PM +0200, Jesus Climent wrote:
> On Sun, Aug 14, 2005 at 06:09:57PM +0200, Christoph Berg wrote:
> > * Package name: dealer
...
> >   Description : bridge hand generator
...
> 2. after reading and re-reading both the description and the long description,
> i have no clue whatsoever what the program is for. Hopefuly in the final
> package it will be reworded...

A "bridge" works on OSI layer 2 (data link layer), unlike a
router.  So it must be a dll network traffic "generator", you
have to manually ("hand") pay for ("dealer").

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: README - confusing, irrelevant, redundant, useless

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 12:55:11PM -0400, Benjamin Seidenberg wrote:
> While I agree the README can be confusing, I think we do a disservice
> to our upstream by not including it. Some readers may be interested in
> the people who brought them the software, or knowing upstream's email

/usr/share/doc//copyright, according to our policy?

> or any of these items you mention. As for readme versus man page, I

Don't you think that most of the examples I gave are utterly
irrelevant to about 100% of our users, including me and you?

> find manpages are usually more of a reference about syntax while
> readme's are closer to a tutorial on usage.

All my examples show, that a lot of READMEs do not contain
tutorials, but irrelevant information.  I did not say anything
against useful information or tutorials in README files.  I
personally would prefer a tutorial in a file named, hm, maybe
"tutorial"?

> I think a better solution would be to duplicate all the important
> information about the software into the README.Debian and train users
> to read that soley. The original readme is still intact for those
> users who care. In addition, I would like to see a standardazation on

The name of the file "README" suggests reading its content is
highly important to the user.  Sometimes it really is.  The huge
number of useless READMEs thwarts that.  I still think,
information irrelevant to the user should be removed from the
binary package.  If one really cares, apt-get source .

> whether to compress the README and similar files, I always end up
> typing less /usr/share/doc/blah/README.Debian[.gz] using tab
> completion and have to go back and correcting my command to use zless
> because half are compressed and half aren't. I also agree with what

Doesn't /bin/zless work for both?

> Branden said in his WTFM presentation at debconf.. a readme command to
> display the readme's to the user would be a very nice tool.

Yes.  Unfortunately, I arrived one day too late for the talk.
Otherwise, I would have criticised Branden for proposing hacking
*roff instead of using DocBook/XML refentries :-)

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: Bug#323076: ITP: dealer -- bridge hand generator

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 07:51:47PM +0200, Christoph Berg wrote:
> (Maybe ITPs should include the proposed section (games in this case)
> to resolve confusions like these.)

Or better, as sections become obsolete, the proposed debtags.

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: README - confusing, irrelevant, redundant, useless

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 08:17:53PM +0200, Jesus Climent wrote:
> On Sun, Aug 14, 2005 at 12:02:36PM +0000, W. Borgert wrote:
> > - "Readme file for ."
> >
> >   Really?
>
> Well, you want to know which package a README belongs to when you get a README
> without any other information... right?

Nice, if you find the README under /lost+found/ (remember the
times before journalling?), but in all other cases, a user knows
their files.  Or do you suggest to tag all files in Debian with
such an information? :-)

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: Dogme05: Team Maintenance

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 08:45:43PM +0200, Marco d'Itri wrote:
> On Aug 14, "W. Borgert" <[EMAIL PROTECTED]> wrote:
> > as a conclusion of many discussions at DebConf5, I propose to
> > maintain all packages by teams.  A fine way to do this, is by
> "One size fits all" methods are a bad idea. Different packages and
> different maintainers have different requirements.

You would have different teams still, so it's not "one size fits
all".

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: README - confusing, irrelevant, redundant, useless

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 10:10:42PM +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > their files.  Or do you suggest to tag all files in Debian with
> > such an information? :-)
>
> Open a man page.

Because it has a NAME section?  OK, you won :-)

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: Dogme05: Team Maintenance

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 03:52:55PM -0500, Adam Heath wrote:
> Haha, this gave me a good laugh for an email.  Altho, as far as jokes go, this
> was rather poorly delivered.

If I would make my living as an entertainer or comedian, I would
have to live on social security or be hungry :-( Sorry.

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: Dogme05: Team Maintenance

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 03:42:23PM -0500, John Hasler wrote:
> You would have a team maintain 'units'?  That's silly.

If the team maintains only the package 'units', yes.  If the
same team maintains multiple relating packages, it's different.
E.g. the Debian XML/SGML group maintains 22 packages.

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: README - confusing, irrelevant, redundant, useless

2005-08-14 Thread W. Borgert
On Mon, Aug 15, 2005 at 02:18:39AM +0200, Henning Makholm wrote:
...a lot of wise things...

I have to agree.  So how to proceed?  File minor bugs against
README files, that contain predominantly useless information?

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: Dogme05: Team Maintenance

2005-08-14 Thread W. Borgert
On Sun, Aug 14, 2005 at 08:29:47PM -0300, Ben Armstrong wrote:
> Says who?  I maintain some packages like this.  Let's say I support 50
> to 100 niche users for a given package, but I'm the only developer in
> the user community who cares to maintain the package in Debian.  I
> maintain the package well, and my users are happy.  I would not be at
> all happy if my package were forced out of Debian because it's "not
> worthwhile".  I think that would be a terrible injustice to my users.

Some of the things under Dogme05 is certainly exaggeration.
Sorry, if people thought I want to propose enforcement of "team
maintenance policy".  However, team maintenance for all
essential and standard is worthwhile and not un-realistic.

> "HA-ing".  I'm sorry.  I don't know what you mean.

Sorry, we may have to many abbreviation based verbs already, so
I should not invent new ones: HA = high availability.

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: README - confusing, irrelevant, redundant, useless

2005-08-15 Thread W. Borgert
On Mon, Aug 15, 2005 at 10:55:20AM +0200, Andreas Tille wrote:
>   Idea 1:
> lintian: W: /usr/share/doc/README contains installation instructions

I like that one.

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


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



Re: README - confusing, irrelevant, redundant, useless

2005-08-15 Thread W. Borgert
On Mon, Aug 15, 2005 at 09:53:37AM +0200, Henning Makholm wrote:
> Go ahead and file bugs. With patches. And perhaps an explanation
> of why a README in the .deb is not required and, if it exists, is not
> required to equal upstream's.
>
> When a few dozen of your patches have made it to sid, condense your
> experience into a well-reasoned, not too long, best practices summary
> which acknowledges that maintainer discretion is still required for
> many things, and offer it for inclusion in the Developer's Reference.

I'll start with my own packages.  They give really bad example
of useless READMEs.

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


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



Re: README - confusing, irrelevant, redundant, useless

2005-08-15 Thread W. Borgert
On Mon, Aug 15, 2005 at 12:42:27PM +0200, Henning Makholm wrote:
> Yes - but how should Lintian detect it?  Of course one could look for
> lines that start with whitespace plus "./configure ", but how reliable
> is that?

Attached test found some culprits: aptitude autofs dbus-1
dbus-glib-1 deborphan dhcp3-client docbook2x etherape
ethereal-common ettercap-common finger ftp gettext gimp-gap
gjdoc gpm kismet libatk1.0-0 libpam0g libpcre3 libtiff4
libungif4g libxml2 m4 man-db nano netkit-inetd nfs-common
python-gtk2 python2.3 ruby1.8 sharutils tar telnet w3m
xfce4-session xfwm4-themes xfwm4 zlib1g

Cheers,
-- 
Wolfgang Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/
import gzip
import re
from linda import libchecks, checks

class ReadmeCheck(libchecks.LindaChecker):
'Checks the upstream README file'
def check_binary_2(self):
self.parse_readme()

def parse_readme(self):
k = None
readme = os.path.join(self.information['dir'],
'unpacked/usr/share/doc', self.pkg_name, 'README')
readmegz = os.path.join(self.information['dir'],
'unpacked/usr/share/doc', self.pkg_name, 'README.gz')
if os.path.exists(readme):
f = open(readme)
k = f.read()
f.close()
elif os.path.exists(readmegz):
f = gzip.open(readmegz)
k = f.read()
f.close()
if k:
configure = re.compile(r'\./configure')
if not self.pkg_name.endswith('-dev') \
and re.search(configure, k):
self.signal_error('readme-contains-make-instructions')
del k

checks.register(ReadmeCheck)
Tag: readme-contains-make-instructions
Type: Warning


Re: Dogme05: Team Maintenance

2005-08-16 Thread W. Borgert
On Tue, Aug 16, 2005 at 02:38:01PM +0200, Alexander Schmehl wrote:
> Do you realy think you can enforce teamwork?  I don't think so.  Either
> some people will work together as a team or individuals will do it their

One cannot enforce teamwork.  Dogma #10 suggests team meetings
in sauna as encouragement for team building.

> own way.  And I don't think it will be a good idea, to force those
> individuals to work in a team.

Debian is a large-scale team.  Teamwork is a necessity for all
the 1278(?) of us.  Not by force, maybe by sauna.

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


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



Re: Bug#323923: ITP: base -- Basic Analysis and Security Engine

2005-08-19 Thread W. Borgert
On Fri, Aug 19, 2005 at 05:59:49PM +0200, martin f krafft wrote:
> also sprach Jon Dowland <[EMAIL PROTECTED]> [2005.08.19.1747 +0200]:
> > I suggest base-security-engine, even though it's quite verbose and
> > the latter two words redundant after the acronym. `base-engine' is
> > better than just base, but similarly could be mistaken for something
> > else important.
>
> How about acid-base?

This sounds less confusing than base-{,security-}engine.  For
the latter I would assume an important security package of the
Debian base system or so.

Cheers, WB


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



Re: Bug#323923: ITP: base -- Basic Analysis and Security Engine

2005-08-19 Thread W. Borgert
On Sat, Aug 20, 2005 at 12:05:51AM +0200, martin f krafft wrote:
> also sprach W. Borgert <[EMAIL PROTECTED]> [2005.08.19.2049 +0200]:
> > > How about acid-base?
> >
> > This sounds less confusing than base-{,security-}engine.  For
> > the latter I would assume an important security package of the
> > Debian base system or so.
>
> And the next, or a related project, could be called saltwater.

At least that's not a contradiction in terms :-) No, I really
did not think about chemistry, when I read acid-base.

Cheers, WB


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



Be sure you pack your bags yourself (was: Results of the meeting...)

2005-08-21 Thread W. Borgert
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote:
> Currently, sponsored packages are only signed, not built, by official
> Debian Developers.

Be sure you pack your bags yourself.
Keep your bags under your control at all times.
Never carry a package with unknown contents for any reason.

I hope, that no DD ever signs a package, unless created by a DD
and already signed by them.

Cheers, WB


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



Using buildds only (was: Results of the meeting...)

2005-08-22 Thread W. Borgert
Quoting Sven Luther <[EMAIL PROTECTED]>:
> All packages should be built by official debian buildds anyway, not on
> developper machines with random cruft and unsecure packages installed, or
> even
> possibly experimental or home-modified stuff.

That would be very good, indeed.  I am very much in favour of allowing
only source-only uploads and having all binaries build by the buildds
only.  The argument against it is, that DDs wouldn't check, whether
the package builds cleanly etc.  I think, that this is a poor argument,
but anyway.  Fortunately, Martin Krafft came up with the idea of
allowing source-only uploads only together with a signed test protocol.
The test protocol would have to include the output of lintian, linda,
and piuparts - warnings allowed, errors not.  Maybe we would need one
more buildd for i386 and one or two buildds for 'all', which does not
have a buildd, AFAIK.

Cheers, WB


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



Re: vancouver revisited

2005-08-22 Thread W. Borgert
Quoting Steve Langasek <[EMAIL PROTECTED]>:
> code that's not portable, then I don't see any point at all in treating
> these as release architectures to begin with, because at that point
> they're *not* shipping the same OS that the other architectures are.

Agreed, however, I would see "optional" packages, as, hm, optional.
If for some arch an optional package doesn't build (or is impractical,
like GNOME/KDE/OpenOffice for, say, m68k, IMHO) there is no problem.

Cheers, WB


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



Re: Using buildds only (was: Results of the meeting...)

2005-08-22 Thread W. Borgert
Quoting Wouter Verhelst <[EMAIL PROTECTED]>:
> According to stories I've heard from people from Ubuntu (that does it
> this way), it quite clearly isn't, because of the pretty high number of
> people who upload packages without even testing the build themselves.

Of course, DDs will do better :-)

> That doesn't test buildability.

But it tests binary packages, so somehow those are built.  One could
also add the requirement of adding a build log to the test protocol.

> Additionally, it's very easy to fake, because lintian and linda produce
> _no_ output if you don't have warnings or errors...

'-v'/'--verbose' could be hard-coded in the test script.  People
could always fake, forge, and fraud, but that's just an FTBFS.

Cheers, WB


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



Re: Using buildds only (was: Results of the meeting...)

2005-08-22 Thread W. Borgert
Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
> At doing stupid things, you mean :-(   Our demographics do not allow
> source-only uploads unfortunately.

I don't really get this sentence, could you please re-word?
(Sorry, I'm not a native speaker of English)

> Which doesn't mean we can't simply trash the binary debs that are uploaded
> and rebuild the package using a buildd, though.

That would be at least much better than the current situation.

Source-only uploads (with mandatory, signed build- and test-logs)
would have the advantage of not having to upload large binaries.
I have DSL - upload is ca. eight times slower than download here.

Cheers, WB


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



Re: Using buildds only (was: Results of the meeting...)

2005-08-22 Thread W. Borgert
Quoting Thijs Kinkhorst <[EMAIL PROTECTED]>:
> I dislike this idea: it is way overengineered. For starters I don't
> understand why you would want to run both lintian and linda, since those

I really don't care whether one has to run either lintian or linda
or both.  That's an implementation detail.  If it's automised by a
script, no maintainer ever has to care about it.

> The whole certificates construction implies that people would want to
> deliberately circumvent running lintian on their packages. I don't believe
> there are a significant number of people doing that, and if they really
> want to, they can do so anyway.
>
> If you really want to enforce lintian checks, you should run them
> server-side. O wait, we already do that. IMO, that works just fine as it

The idea of running lintian/linda and piuparts on side of the
developer machine is giving a reasonable confidence, that a
package is good enough for source-only upload.  The log could
be automatically signed with the .dsc.  No burden to the DD.

> does now; the results are visible for everyone. You could extend this to
> running lintian for new uploads and rejecting them on errors if you would
> so wish, but I do not see indications that this is actually necessary.

AFAIK, you can run lintian/linda on binary packages.  I was
proposing source-only uploads.

Cheers, WB


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



Re: Using buildds only (was: Results of the meeting...)

2005-08-22 Thread W. Borgert
Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
> On Mon, 22 Aug 2005, W. Borgert wrote:
> > I don't really get this sentence, could you please re-word?
>
> The current set of DDs will do unverified source uploads immediately if
> given half a chance.  Unverified binary uploads are rather common, already.

Ah, understood :-) and agreed :-(

(That's why I like Martins idea of mandatory, signed build and test logs.)

Cheers, WB


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



Re: Using buildds only (was: Results of the meeting...)

2005-08-22 Thread W. Borgert
Quoting Matthew Palmer <[EMAIL PROTECTED]>:
> I used to think that too.  I took a wander through queue/reject on merkel.
> I don't think that any more.  I'm curious as to how Ubuntu is going to
> sustain source-only uploads, honestly.

Mandatory, signed build and test logs?  I've no idea...

Cheers, WB


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



Re: Bug#324296: ITP: ldapscripts -- Add and remove user and groups stored (using ldap)

2005-08-22 Thread W. Borgert
Quoting "Roberto C. Sanchez" <[EMAIL PROTECTED]>:
> Because the "user" is (99% chance) an admin.

We should use debtags for this kind of information, IMHO.

> Because the "user" may not want extraneous or extra Perl modules
> installed on his system.  If you are building a production box, you may
> want to know.

An admin user should be able to use the apt-get tools to check
easily which dependencies etc. a package has.  No need for prose,
which might not be as accurate as the real dependencies anyway.

Cheers, WB


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



Re: Using buildds only (was: Results of the meeting...)

2005-08-22 Thread W. Borgert
Quoting Hamish Moffatt <[EMAIL PROTECTED]>:
> There is the possibility that developer builds get extra features
> enabled due to other installed libraries etc. This could be checked for
> by analysing the packages files for different architectures or similar.

This is a really nice idea: A DD with a strange sense of humour
could "enable an extra feature" in their binary package, that is
not in the source code - at least not in the uploaded source.
Could be a virus, a Trojan horse, a root kit, a time-bomb.  As
>= 95% of our users have i386, it's easy to generate nice damage.

Security-wise, binary uploads are no go.

Cheers, WB


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



Re: Using buildds only

2005-08-22 Thread W. Borgert
Quoting Olaf van der Spek <[EMAIL PROTECTED]>:
> Indeed. Why would those checks be done client-side instead of
> server-side anyway?

To prevent overload from the buildds.  But maybe Martin Pitt is
right, and we should just do it like Ubuntu (source-only uploads)
and invent measures, if the need really arises.

Cheers, WB


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



Re: Results of the meeting in Helsinki about the Vancouver proposal

2005-08-22 Thread W. Borgert
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
> really matters:  can we (the Debian project) maintain the port?  Thus I 
> propose we only limit on the number of developers:  are there people who 
> are willing and competent to maintain kernel, boot loader, platform 
> specific installer bits, libc and toolchain?

That sounds sensible.

> Furthermore, I think port maintainers should be much more aggressive to 
> exclude packages from being built on their port.  For example (without 
...
> (discalimer: I only run x86 myself, so perhaps this is a stupid idea.)

Same for me, so I like the idea.  Any port should have to have
essential and standard, optional is - optional.

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]



WebSVN of svn.debian.org uses wrong encoding

2005-08-23 Thread W. Borgert
Hi,

I have checked in some files into svn.debian.org.  The files are
in UTF-8 encoding[1], but the web front-end seems to believe in
ISO-8859-1.  Did I do something wrong when checking in files, or
is WebSVN too plain in its assumptions?  How/where can I file a
bug, if the problem is in svn.debian.org?  TIA!

[1] http://svn.debian.org/wsvn/ddp/refcard/trunk/entries-ru.dbk?op=file

(If WebSVN does not know about encodings, UTF-8 might be a more
sensible default than ISO-8859-1 nowadays.)

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: WebSVN of svn.debian.org uses wrong encoding

2005-08-23 Thread W. Borgert
Quoting Frans Pop <[EMAIL PROTECTED]>:
> WebSVN does not know about the contents of files in the repository period.

OK.

> As it is just a frontend to svn, you cannot expect it to know about every
> weird file format and encoding around.

OK.

> IMO, the main purpose of websvn is to be able to view diffs in _code_ and
> maybe download individual files.

I handle documentation like code :-)

> For everything else, use svn itself and work with its files in their
> proper environment.

Not all of "my" translators are easy with svn command line.  WebSVN
would be helpful, so they see, whether I did my homework and checked
in their latest changes correctly.  Could be useful for d-i, too.

> If you really want to file a bug about it, the Tech Support Tracking
> System for project alioth on alioth is probably your best bet, but I
> doubt that is really useful.

I did this anyway :-)

> Food for endless flames^Wdiscussions.

As nearly everything :-(

Cheers, WB


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



Re: WebSVN of svn.debian.org uses wrong encoding

2005-08-23 Thread W. Borgert
Quoting Frans Pop <[EMAIL PROTECTED]>:
> For that you should enable the svn keyword "Id" (using 'svn propset
> svn:keywords Id') and add a comment in your English files containing
> "$Id:".

I will do that, thanks for the hint!
(However, my original plea for using UTF-8 in WebSVN remains.)

Cheers, WB


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



Re: update of (several) config files

2005-08-23 Thread W. Borgert
Hello Tomas,

this question should better go to [EMAIL PROTECTED]

Quoting Tomas Davidek <[EMAIL PROTECTED]>:
>   I am trying to set up a tool for easy update of several computers in
> our institute. For example, I would like to create a package that
> updates several config files, e.g. /etc/apt/sources.list etc.
> What is the best way of doing that ?

It depends very much on your needs.  For simple cases look into
cfengine/cfengine2 (I do not like cfengine, but there is no
alternative).  For really cool stuff look at FAI (fully
automatic install), which has some system update features.  At
the list mentioned above you will get better information.

Cheers, WB


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



Re: WebSVN of svn.debian.org uses wrong encoding

2005-08-24 Thread W. Borgert
Quoting Christian Perrier <[EMAIL PROTECTED]>:
> Several translation teams (including mine) still use Latin-1 as their
> default...but this is not a reason to still use Latin-1 as an overall
> default...:-)

Btw. I looked into the d-i manuals in SVN and some Western
European languages, e.g. German, are already in UTF-8.

Cheers, WB


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



Re: Results of the meeting in Helsinki about the Vancouver proposal

2005-08-24 Thread W. Borgert
Quoting Peter 'p2' De Schrijver <[EMAIL PROTECTED]>:
> Most packages are not tested automatically at all.

Unfortunately not.

> Most cross compiled software also runs 24/7. I have yet to see problems
> produced by cross compiling the code.
...
> I don't think the risk is real considering the amount of cross compiled
> software already running in the world.

Yes.  In "my" company we rely heavily on cross-compilation, because
our target environment is not (meant to be) self-hosting.  There is
absolutely no problem in terms of stability, that is related to the
cross-compilation.  Sometimes we ran into gcc bugs, but those were
not only in the cross cc.

Cheers, WB


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



Re: making developer location from ldap public?

2005-08-25 Thread W. Borgert
Quoting Robert Lemmen <[EMAIL PROTECTED]>:
> 1. just make it public (after a warning period), anybody who doesn't
>want that can delete his information from the database. my preferred
>option!

I don't like opt-out.  Better opt-in:

4. Invent a new field "public location info" and developers
   who care, could enter what they think is appropriate.

I'm not sure, whether I would use the field.

Cheers, WB


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



Re: making developer location from ldap public?

2005-08-25 Thread W. Borgert
On Thu, Aug 25, 2005 at 07:39:08PM +0200, Robert Lemmen wrote:
> anyway, i did get your point: you would very much wish for that
> information to stay non-public unless one explicitely makes it public.

Yes, please.

Cheers, WB


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



Re: making developer location from ldap public?

2005-08-26 Thread W. Borgert
Quoting Javier Fern�ndez-Sanguino Pe�a <[EMAIL PROTECTED]>:
> presents themselves and suggest meeting for a beer. They don't walk to
> your house, knock on your door and say "Hi! I just got your coordinates
> from db.debian.org, wanna meet and keysign?".

And I wouldn't want that.

I do not understand this discussion.  Why on earth is someone
so interested in the public availability of DDs location?  This
would only make sense when cross-connecting with other things,
like belief, gender, sexual preferences and phantasies etc.
Are those fields of db.debian.org already public or not?

Cheers, WB


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



Bug#325164: ITP: docbook-css -- Cascading Stylesheet for DocBook/XML

2005-08-26 Thread W. Borgert
Package: wnpp
Severity: wishlist
Owner: "W. Borgert" <[EMAIL PROTECTED]>

Package name: docbook-css
Version : 0.4
Upstream Author : David Holroyd 
URL : http://www.badgers-in-foil.co.uk/projects/docbook-css/
License : "free to use/modify/distribute, no warranty"
Description : view DocBook/XML files styled in the web browser

This Cascading Stylesheet allows you to directly view a styled
XML document in software that supports XML styled with CSS2
(e.g. a recent Mozilla browser).


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



Re: why does "vbetool dpms off" work and "xset dpms *" not?

2005-09-07 Thread W. Borgert
Quoting Bastian Venthur <[EMAIL PROTECTED]>:
> Hi devels,
>
> I'm trying to get my backlight powered off in order to save power. It does
...

This question should probably go to [EMAIL PROTECTED]  Good luck!

Cheers, WB


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



Re: Announcing an intention to produce an armeb port of Debian

2005-09-19 Thread W. Borgert
On Mon, Sep 19, 2005 at 10:45:26AM +0930, Debonaras Project Lead wrote:
> The Debonaras project (http://www.debonaras.org) is a group of Linux
> developers who have created the beginnings of a big-endian ARM (armeb)
> port of Debian.  We have built 2500+ stable packages so far (see
> http://ftp.debonaras.org).

Just a completely uninformed question: Wasn't the -el (endian
little) in mipsel a pun on the "wrong" endianess?  If so,
shouldn't it be armBE, because it's the "right" endianess?

Cheers, WB


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



Re: Announcing an intention to produce an armeb port of Debian

2005-09-19 Thread W. Borgert
Quoting Thiemo Seufer <[EMAIL PROTECTED]>:
> -EL/-EB/-el/-eb are commonly used gcc switches to select endianness.

OK, thanks.  Another mystery solved :-)

Cheers, WB


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



Re: Announcing an intention to produce an armeb port of Debian

2005-09-19 Thread W. Borgert
Quoting Sam Hocevar <[EMAIL PROTECTED]>:
>Wrong is endian little that knows everyone but.

Thgir yltcaxe!


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



Re: architecture-specific release criteria - requalification needed

2005-09-21 Thread W. Borgert
Quoting Andreas Barth <[EMAIL PROTECTED]>:
> * Ingo Juergensmann ([EMAIL PROTECTED]) [050921 16:53]:
> > What about such ports like m32r? Some embedded devices might run that port,
> > but the user doesn't even know about which arch he's using nor that he's
> > using Debian and certainly not that he is intended to give a "hey, i'm using
> > that port" message to Debian...
>
> Well, it doesn't necessarily be the user himself. But if a port is only
> used on embedded devices, the question arrises if it is necessary to
> include that port in testing and stable.

1. If the user theirself don't know about using Debian on the
   embedded device, I'm sure that someone knows about the fact
   and can easily provide information about it.  E.g. we all
   know about the Nokia 770 arm machines.  If we can believe
   that Nokia sold more than fifty gadgets, the goal is reached.

2. Even for embedded systems, stable releases are a good thing.
   (Easier to follow GPL rules of having sources available for
   some years.  Easier to build/install additional software, if
   one knows, which Debian release is used.  Easier to clone.)

Btw., IMHO, the new release criteria are very sensible, maybe
with the exception of the 98%-rule, which might be too strict.

Cheers, WB


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



planet.debian.org vs. blog illiteracy

2005-09-26 Thread W. Borgert
Hi,

I found out, that more and more important information about
Debian development are on the planet.debian.org/.net website.
I'm illiterate on "blogging", so please could someone tell me
whether/how I can view this page in a "Debian only" mode?  E.g.
without vacancy travel reports, personal opinions on all kind of
political issues, or other private stuff?

(I would prefer to get all the technical information on
debian-devel, but of course this is up to the posters.)

TIA!
-- 
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: planet.debian.org vs. blog illiteracy

2005-09-26 Thread W. Borgert
Quoting Andreas Tille <[EMAIL PROTECTED]>:
> Thanks for this hint - I just skipped this thread because I regarded
> it relevant for blogs (and thus not for me).  But I do not really want
> a new list - I just want technical information neither spread to debian-devel
> and planetdebian nor debian-devel and an assumed debian-planet mailing list.
> I just want it here were it belongs.

It seems that some of the blog writers think that the respective
information belong to the blog and not to debian-devel :-(

Maybe there is an easy way (tool-wise) for the blog authors to
automatically duplicate entries of technical relevance to the
list?

IMHO, the blog has some drawbacks:

- offline reading is difficult

- answering to questions difficult (not as easy as pressing
  'r'eply or 'g'roup reply in mutt)

- not archived (or is it?)

- valuable technical contents mixed with weather reports (low SNR)

So please, fellow DDs, if you have important information, share it
via the list, too!

Cheers, WB


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



Re: planet.debian.org vs. blog illiteracy

2005-09-26 Thread W. Borgert
Quoting Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>:
> Use rss2email. It makes blogs almost as useful as maillists.

Sounds OK, but it would be more convenient to just have all
relevant (= technical) information in debian-devel.

> Right, that's a real disadvantage. Everyone knows that debian-devel has
> an extremly high SNR, right?

:-)

At least it is easier to cope with the noise by procmail and ^D
(delete-thread in mutt) and there's no talk about the weather.

Noisy WB


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



Re: planet.debian.org vs. blog illiteracy

2005-09-26 Thread W. Borgert
Quoting Margarita Manterola <[EMAIL PROTECTED]>:
> I think that this is part of the essence of blogging.  When you write
> a mail to debian-devel you risk being flamed about whatever you are
> saying.  When you blog about it, it's your right to say what you think
> and feel like.

People managed to start flamewars on their blogs :-) So one has
to be fireproof anyway.  For me, as a poor reader, it is harder
to follow, as there is no equivalent to a mail thread.

> Besos,

Cheers, Wolfgang (lowering the SNR of this in this very moment)


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



Re: planet.debian.org vs. blog illiteracy

2005-09-26 Thread W. Borgert
On Mon, Sep 26, 2005 at 12:35:36PM -0700, Daniel Burrows wrote:
>   I generally don't see any value in cluttering up -devel with the stuff I 
> post on my blog.  I hope people who read it will find it interesting, but 
> it's not broadly important and I don't think there's any need to annoy large 
> numbers of people by sending it here. :)

In the past, there were important blog entries by Martin Joey
Schulze on security, by Branden Robinson on Debian trademark
issues, and some interesting thoughts on the upload process by
Martin F. Krafft to name just a few.  I'm pretty sure, that I
found some of your entries informative as well :-)

Cheers, WB


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



Re: i386-uclibc debian

2005-09-28 Thread W. Borgert
On Wed, Sep 28, 2005 at 12:12:33PM -0300, Daniel Ruoso wrote:
> What do you think?

I would like to see a d-i port to that architecture!
(not volunteering, sorry)

Did you contact the emdebian people?

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: old question with new status? Sun-Java in Debian non-free?

2005-10-27 Thread W. Borgert
Quoting Jason Clinton <[EMAIL PROTECTED]>:
> If so, what can I do to take the initiative to package it up for Debian
> non-free?
>
> I apologize in advance if this brings up an old flame war...

I don't expect one about this issue.  Just don't expect Debian
to join any "Partner Programme", which seems to be necessary.

Cheers, WB


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



Re: real-i386 (was Re: i386 requalification for etch)

2005-11-06 Thread W. Borgert
On Sun, Nov 06, 2005 at 12:10:05PM +0100, Andreas Metzler wrote:
> I am a little bit confused. Does Via/C3 need strict 386-instructions
> or does it play nicely with the current status, i.e. 486 instruction
> set?

A standard sarge install works perfectly on my brand-new VIA C3.

Cheers, WB


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



Bug#463069: ITP: refcard -- printable reference card for the Debian system

2008-01-29 Thread W. Borgert
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" <[EMAIL PROTECTED]>

Package name: refcard
Version : 3.2
Upstream Author : W. Martin Borgert <[EMAIL PROTECTED]>
URL : http://people.debian.org/~debacle/refcard/
License : GPL-3
Programming Lang: XML (docbook-xsl, FO)
Description : printable reference card for the Debian system

The Debian GNU/Linux reference card provides new users help with
the most important commands. Basic knowledge of computers,
files, directories and the command line is required, however.
The package contains printable PDF files in multiple languages.



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



Re: [Debconf-discuss] Official presentation template

2007-06-26 Thread W. Borgert
On Wed, Jun 27, 2007 at 02:32:56AM +0200, Javier Fernández-Sanguino Peña wrote:
> Oh, and if a design was settled, it would be really nice to have the design
> implemented in some other presentation toolkits (besides beamer) such as OO's
> impress or Kpresenter. For the benefit of those that do not like LaTeX (I'm
> not one of them :)

I like LaTeX, but I use DocBook XML slides as source and S5-HTML
as output for presentations. I have a simple debianesque CSS, I
can share.

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]



Source only uploads?

2003-10-15 Thread W. Borgert
Hi,

a few days ago, I uploaded an emacs mode package (all) source only
w/o problems to ftp-master.  Today, a source only upload was rejected.
Why?  I think, we should get rid of binary uploads...

Cheers!




Kernel 2.6.x real time clock hang on Dell

2004-10-18 Thread W. Borgert
Hi,

I'm bitten by a problem, that is already known to some people, but
for which I found no solution.  On a Dell server, the 2.6.7 kernel
(kernel-image-2.6.7-1-686-smp) hangs during boot at the real time
clock.  It seems, this problem is only known to Debian users :-(

Is there a solution or a workaround?

"I have problem on a Dell Precision 670.  I have installed the
kernel 2.6.8 using the debian Sarge net installation.  The boot
hangs after loading the driver for the Real Time Clock."
http://www.linuxquestions.org/questions/showthread.php?s=&postid=1188223#post1188223

"...always hang on the "Real Time Clock Driver".  I figured it a
bug in the 2.6 kernel..."
http://zacbowling.com/archives/2004/10/06/debian-dell/

Thanks in advance!

Cheers, WB




Bug#126775: omniorb-doc examples don't compile

2001-12-28 Thread W. Borgert
Package: omniorb-doc
Version: 3.0.4-2.4
Tags: patch

I have adopted the examples to autoconf/automake.  This
works very well.  Maybe one can push this to the upstream
developers?

What I did: All files dir.mk, dir.mak, GNUmakefile,
*.module, *.pkg, and the obsolete directories lifecycle and
partcl are removed.  They are replaced by a configure.ac, a
dozen Makefile.am files and a bootstrap script to run
aclocal, automake and autoconf.

Two minor problems remain:

1. I put -DUsePthread directly into the Makefile.am files.
   Better would be to check for the pthread libs.

2. As suggested by the omniORB documentation, I have
   created a file /usr/include/omniORB3/sitedef.h, which
   contains only one line:

#define __x86__ /* or: __sparc__, __powerpc__, ... */

   This file is included by /usr/include/omniORB3/\
   CORBA_sysdep.h mainly to set _OMNIORB_HOST_BYTE_ORDER_
   to 0 for big endian machines and to 1 for little endian
   machines.  I don't like this.  It makes cross compiling
   impossible.  Also, autoconf already has a macro
   AC_C_BIGENDIAN, which defines WORDS_BIGENDIAN or not
   depending on the byte sex.

Btw: I believe that the bugs #49037 (omniorb-doc file
placement, 2 years and 58 days old) and #114718 (empty dirs
in omniorb-doc, 82 days old) are gone.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>
diff -ruN examples.orig/Makefile.am examples/Makefile.am
--- examples.orig/Makefile.am   Thu Jan  1 00:00:00 1970
+++ examples/Makefile.amFri Dec 28 20:09:05 2001
@@ -0,0 +1 @@
+SUBDIRS=anyExample boa call_back dii dsi echo poa thread
diff -ruN examples.orig/anyExample/Makefile.am examples/anyExample/Makefile.am
--- examples.orig/anyExample/Makefile.amThu Jan  1 00:00:00 1970
+++ examples/anyExample/Makefile.am Fri Dec 28 20:45:32 2001
@@ -0,0 +1,11 @@
+IDLFILE = anyExample
+noinst_PROGRAMS = anyExample_clt anyExample_impl
+BUILT_SOURCES = anyExampleSK.cc anyExampleDynSK.cc anyExample.hh
+anyExample_clt_SOURCES = anyExample_clt.cc $(BUILT_SOURCES)
+anyExample_impl_SOURCES = anyExample_impl.cc $(BUILT_SOURCES)
+LDADD = -lomniORB3 -lomniDynamic3 -ltcpwrapGK
+CXXFLAGS = -O2 -Wall -Wno-unused -D__OMNIORB3__ -D_REENTRANT -DUsePthread
+CLEANFILES=$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh
+
+$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh: $(IDLFILE).idl
+   $(OMNIIDL) -bcxx -Wba $<
diff -ruN examples.orig/boa/Makefile.am examples/boa/Makefile.am
--- examples.orig/boa/Makefile.am   Thu Jan  1 00:00:00 1970
+++ examples/boa/Makefile.amFri Dec 28 20:46:07 2001
@@ -0,0 +1,11 @@
+IDLFILE = becho
+noinst_PROGRAMS = eg2_clt eg2_impl
+BUILT_SOURCES = bechoSK.cc becho.hh
+eg2_clt_SOURCES = eg2_clt.cc $(BUILT_SOURCES)
+eg2_impl_SOURCES = eg2_impl.cc $(BUILT_SOURCES)
+LDADD = -lomniORB3 -ltcpwrapGK
+CXXFLAGS = -O2 -Wall -Wno-unused -D__OMNIORB3__ -D_REENTRANT -DUsePthread
+CLEANFILES=$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh
+
+$(IDLFILE)SK.cc $(IDLFILE).hh: $(IDLFILE).idl
+   $(OMNIIDL) -bcxx -WbBOA $<
diff -ruN examples.orig/bootstrap examples/bootstrap
--- examples.orig/bootstrap Thu Jan  1 00:00:00 1970
+++ examples/bootstrap  Fri Dec 28 17:22:47 2001
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+aclocal && automake --add-missing --foreign
+autoconf
diff -ruN examples.orig/call_back/Makefile.am examples/call_back/Makefile.am
--- examples.orig/call_back/Makefile.am Thu Jan  1 00:00:00 1970
+++ examples/call_back/Makefile.am  Fri Dec 28 21:11:12 2001
@@ -0,0 +1,12 @@
+IDLFILE = echo_callback
+noinst_PROGRAMS = cb_client cb_server cb_shutdown
+BUILT_SOURCES = echo_callbackSK.cc echo_callback.hh
+cb_client_SOURCES = cb_client.cc $(BUILT_SOURCES)
+cb_server_SOURCES = cb_server.cc $(BUILT_SOURCES)
+cb_shutdown_SOURCES = cb_shutdown.cc $(BUILT_SOURCES)
+LDADD = -lomniORB3 -ltcpwrapGK -lomnithread -lpthread
+CXXFLAGS = -O2 -Wall -Wno-unused -D__OMNIORB3__ -D_REENTRANT -DUsePthread
+CLEANFILES=$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh
+
+$(IDLFILE)SK.cc $(IDLFILE).hh: $(IDLFILE).idl
+   $(OMNIIDL) -bcxx $<
diff -ruN examples.orig/configure.ac examples/configure.ac
--- examples.orig/configure.ac  Thu Jan  1 00:00:00 1970
+++ examples/configure.ac   Fri Dec 28 20:22:23 2001
@@ -0,0 +1,28 @@
+AC_INIT(anyExample/anyExample_clt.cc)
+AM_INIT_AUTOMAKE(omniorb-examples, 3.0.4)
+
+AC_PROG_CXX
+AC_PROG_CXXCPP
+AC_PROG_LN_S
+AC_PROG_INSTALL
+
+AC_LANG(C++)
+AC_HEADER_STDC
+AC_CHECK_HEADERS(iostream.h omniORB3/CORBA.h omniORB3/callDescriptor.h 
omniORB3/tcDescriptor.h)
+
+AC_C_BIGENDIAN
+
+AC_CHECK_PROGS(OMNIIDL, omniidl, false)
+
+AC_OUTPUT(Makefile
+   anyExample/Makefile
+   boa/Makefile
+   call_back/Makefile
+   dii/Makefile
+   dsi/Makefile
+   echo/Makefile
+   poa/Makefile
+   poa/implicit_activation/Makefile
+   poa/persistent_objref/Makefile
+   poa/servant_manager/Makefile
+   thread/Makefile)
diff -ruN examples.orig/dii/Makefile.am examples/dii/Makefile.am
--- examples.orig/dii/Makefile.am   

Intent to package: blinkd

1998-10-14 Thread W. Borgert
Hi,

I will upload blinkd, a small client/server pair, that let's blink
your keyboard LEDs (numlock and scrolllock) in a rate that signals
e.g. the number of incoming calls on your voice box or number of
facsimiles in the spool.

The software is written by myself and GPLed.  This is my first
deb, if everything is O.K. more packages will follow...

Bye,
-- 
W. Borgert <[EMAIL PROTECTED]>


pgpo2CC9pVm59.pgp
Description: PGP signature