Re: md5 checksum errors in several packages

[Ben Armstrong]

John,

On Mon, 2005-02-21 at 15:24 +, John O'Sullivan wrote:
> My mirror is a copy of the mirror at heanet (ftp.ie.debian.org). I 
> have noticed incorrect checksums on 8 packages and I am posting the 
> details here in case this is a serious problem.

I question, then, the integrity of ftp.ie.debian.org or your own mirror.

Just checking one of my own packages, I obtained a copy from my local
mirror, and this is the result:

> package   apt-cache show md5 report 
> extract -H md5 report
> xpilot-client-nosound 3cfe83e6a25995d17d568737c3c4b48e  
> 7686f00ee13ff34f314bb69c51b2e9a6

$ extract -H md5 xpilot-client-nosound_4.5.5beta.20031222-1_i386.deb 
MD5 - 3cfe83e6a25995d17d568737c3c4b48e

This agrees with the md5 checksum reported by apt-cache show.  This also
agrees with the md5 checksum extracted from my local copy of this .deb
on my system used for the original upload, and the checksum as shown in
the .changes file.

Ben
p.s. Please continue to CC me on any replies relevant to my own
packages, as I am not subscribed to debian-devel at this time.



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

Re: md5 checksum errors in several packages

[Ben Armstrong]

John,

Have you considered the possibility that the packages are corrupt due to
truncation which may have happened because you (or your mirror) ran out
of space at some point in the past while downloading these packages?
The package names are late in the alphabet, which might account for why
only these few packages are affected.  Also, the corruption need not
have been recent.  My xpilot package has not changed in a very long
time, which might account for the persistence of a very old one-time
corruption event.

Ben



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

Re: md5 checksum errors in several packages

[Ben Armstrong]

On Mon, 2005-02-21 at 17:31 +, John O'Sullivan wrote:
> Sorry for the false alarm. Those files were only corrupted. HEAnet have 
> resynced them now and all is good. Sorry for wasting ppls time.

I'm just happy that people are looking for this sort of thing.  It is
encouraging that if were a real compromise to occur, it would not go
unnoticed.

Ben



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

Re: Bug#340631: ITP: culmus-fancy -- Type1 Fancy Hebrew Fonts for X11

[Ben Armstrong]

On Sat, 2005-11-26 at 21:38 -0600, Peter Samuelson wrote:
> [Lior Kaplan]
> > * Package name: culmus-fancy
> >   Description : Type1 Fancy Hebrew Fonts for X11
> 
> I understand that the 'culmus' package already exists, and other
> packages like 'lmodern' don't follow any particular name convention
> either, but could you consider naming this thing t1-culmus-fancy or
> something?  We don't really have a package name convention for fonts,
> but xfonts-*, t1-* and ttf-* are the closest thing we have.

Besides which, doesn't 'culmus' already contain Ktav Yad?

Ben


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

Re: Debian Games Team

[Ben Armstrong]

On Fri, 2006-01-13 at 09:15 +0100, Andreas Tille wrote:
> On Fri, 13 Jan 2006, Miriam Ruiz wrote:
> 
> > We've been recently talking about creating a group to maintain games in 
> > Debian
> > in a collaborative way.
> 
> Are you aware of the Debian-Junior project.

Thanks for bringing this thread to my attention, Andreas, or I would
have missed it.

Miriam, I'm interested in your project and am joining the list to
contribute ideas relating to Debian Jr.

Ben


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

Re: New packages.debian.org

[Ben Armstrong]

On Mon, 2006-03-06 at 19:38 +0100, Martin Schulze wrote:
> It checks the User-Agent string.

What are the expected results for a user accessing the following URL
from IE running on a W2K terminal server?  I didn't notice any
restrictions.

http://packages.debian.org/tuxpaint

Ben


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

Re: Introducing Ichthux as a possibly new CDD

[Ben Armstrong]

I'm very interested in this work.  I am already involved in two
different Christian ministries that might be able to make use of
Ichthux, and have some ideas for others.

Ben



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

Re: Bug#304266: ITP: sdate -- never ending september date

[Ben Armstrong]

On Tue, 2005-04-12 at 14:28 -0300, Humberto Massa wrote:
> Could you enlighten me as of the reason that September 93 never ended?

The original ITP gave the reference:

http://www.catb.org/~esr/jargon/html/S/September-that-never-ended.html

In brief: in Sept. '93 AOL users came online, starting an eternal
September.

Ben


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

Re: Changes to the weekly WNPP posting

[Ben Armstrong]

On Thu, 2005-05-19 at 18:40 +0200, Christoph Berg wrote:
> I always read the announcements to look for O or RFAs of packages I
> use, hence I appreciate the "only new entries" change.

Same here.

> However, from
> browsing the debian-wnpp archives, there's a lot more stuff there than
> I'm willing to read, so not posting the announcements on a different
> list is a regression for me. (Ok, I could procmail it away, but that's
> a hack.)

I'd consider it a regression as well, for the same reason.

> How about posting the announcements to -devel (instead of -d-a)? If
> only new entries are included, it wouldn't hurt much for those who are
> not interested.

I'd like to see them continue on -d-a.  There are times when I just
can't handle -devel and unsub completely.  They really don't add up to
much traffic, and the "new entries only" change should help bring back
some people to doing regular reviews that they had developed a
resistance to doing due to having to wade through too many old entries
to see the new ones.

Ben



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

Re: Debian Project Leader report for 2005-07-07

[Ben Armstrong]

On Thu, 2005-07-07 at 14:39 +0200, martin f krafft wrote:
> Sure. But I am talking about changes. Those are not made and then
> everyone is expected to abide by them. Instead, they are catalysed
> from common and proven strategies.

True enough.  But read the statement of the fact that policy maintainers
have wield power in the context of the report: it is not their purpose
to use this power against the collective wills of the developers, but
nevertheless, since they have this power, visibility and transparency in
this job are especially important.  Conversely, if what the policy
maintainers do were not transparent, the consequences could be
disastrous, precisely because the policy should be catalysed, as you
say, from common and proven strategies, and not be cabalistic dictates.

Ben


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

Re: huge wnpp bug report page

[Ben Armstrong]

Hendrik Sattler wrote:
> I hope that something can be done about this to make the BTS web pages more 
> usable.
>   

Are you perhaps not aware of the much smaller indices into the BTS here?

http://www.debian.org/devel/wnpp/

Ben


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

Re: Debian cares more about documents than people

[Ben Armstrong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alfredo,

alfredo diega wrote:
> It really pains me to write this since I have used stable for a long
> time.
> Unfortunately, I think you could use a wakeup call.
>
>   Much of my hardware is never supported by you guys

I can see you're frustrated.  You've invested a lot of energy into
writing this note to us about a problem you see in Debian.  Now, if it
really does pain you to write it, the least you could do is tell us
what your hardware is.  Otherwise, how do you expect us to make things
better for you?

Regards,
Ben

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFEpe8WpTzygsnE8gRAsxnAKCevbb1aJ6OsnE3jK3m3P10QICWrACffNzd
VnrZE22/G2IqmRZnjcTWegw=
=xmj4
-END PGP SIGNATURE-


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

Re: Debian cares more about documents than people

[Ben Armstrong]

alfredo diega wrote:
> Okay:  Intel PRO/Wireless 3945ABG.  According to this message at
> bugs.debian.org/cgi-bin/bugreport.cgi?bug=363967 it isn't packaged
> because:
>
> "there is still an official statement of -release and -kernel about the
> policy for oot-modules in etch missing."
>
> showing it just isn't in Debian because policy.

Please read down to the bottom of the whole bug you cited above.  Two
developers are actively working on this, and there are technical
problems with the package.

Furthermore, you appear to be mistaken about Debian policy.  Perhaps
this is simply a matter of language.  See:

http://www.debian.org/doc/debian-policy/

This key document is the technical foundation upon which the entire
Debian distribution is built.  Without it, you would not have the
quality distribution you now enjoy.

> Next:  SD drive, works with Ubuntu with their "free stuuf."  Probably
> isn't
> supported by policy either.

I can't comment, as you have not given details.

> Lastly, suspend doesn't work with Debian but does with Dapper.

Again, without even a bug# reference, this is hard for me to check.

> I am not an expert with all the technical specifics, but when I see
> messages
> like this from the release manager:
> lists.debian.org/debian-kernel/2006/09/msg00453.html

I don't see the connection between this and the one concrete example you
gave above.

> I conclude, why am I trying to wait patiently?  Is Debian ever going to
> support hardware where there is "free software" out there for it? 
> Because
> of
> a pios loyalty to a docoument and not to mankind I conclude not.

The bug report that *you* cited above indicates otherwise.  I see
developers who are concerned about working on the problems you are so
passionate about having fixed.  I see a Debian that cares about its users.

Regards,
Ben


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

Re: Elive requires donation to download

[Ben Armstrong]

On Fri, 24 Nov 2006 06:04:13 -0800 (PST)
Ottavio Caruso <[EMAIL PROTECTED]> wrote:

> Elive , based on Debian,
> requires a donation, however small, to allow downloading. I wonder if
> this legally sound.

The DFSG explicitly specifies that licenses of our software must allow people 
to charge for distribution in article #1:

http://www.us.debian.org/social_contract#guidelines

1. Free Redistribution

The license of a Debian component may not restrict any party from
selling or giving away the software as a component of an aggregate
software distribution containing programs from several different
sources. The license may not require a royalty or other fee for such
sale.

Besides, your assertion is false.  Elive does not require a donation to 
download:

"- If you don't care about the future of Elive, and you really think its 
possible to live off nothing, or you just can't possibly make a minor donation, 
then you can download Elive from a slow server. We recommend that you verify 
the MD5sum and download it with 'wget -c' because sometimes this download 
stalls."

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]


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

Re: Bug#361418: [Proposal] new Debian menu structure

[Ben Armstrong]

On Fri, 2006-04-14 at 14:29 +0100, Thiemo Seufer wrote:
> Yes. Debian shouldn't be the Linux Distribution of Cryptic Acronyms.

Perhaps you missed the point earlier in the thread that Ham isn't an
acronym?  Also, I don't think anyone with even a passing familiarity
with amateur radio seriously thinks Ham is cryptic.

> What exactly was dumbed down here? Is there a non-Ham Amateur Radio
> we would have to distinguish from?

DX, perhaps?  It seems to this outsider that both Ham and DX are
encompassed by the more general term "Amateur Radio".

Ben


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

Testing and honesty

[Ben Armstrong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Art Edwards wrote:
> Unless such core pieces as the debugging tool (ddd) and the data
display tool
> (xmgrace) are working, it is dishonest to pretend that the 64-bit version
> is ready for testing.
It seems your expectations for our "testing" distribution do not match
what we have already stated clearly on our website.  Please read this:

http://www.debian.org/doc/FAQ/ch-ftparchives#s-testing

"Packages are installed into the `testing' directory after they have
undergone some degree of testing in unstable
.

They must be in sync on all architectures where they have been built
and mustn't have dependencies that make them uninstallable; they also
have to have fewer release-critical bugs than the versions currently
in testing. This way, we hope that `testing' is always close to being
a release candidate."

In particular, no guarantees are made that the entire distribution
will be 100% release-critical bug-free.  All we can assure you is that
packages have undergone "some degree of testing" and have fewer
release-critical bugs than the versions currently in testing.  The way
in which the whole system is kept "honest" is by users filing bug
reports, which in turn keeps the RC bug count in testing down to as
few as possible given the resources available to our project.

For a more detailed description of this process, see:

http://www.debian.org/devel/testing

Now, I understand your frustration and disappointment, but I think
before using testing, you should have made it your business to read
and make sure you understood what we have publicly posted about its
readiness for use.  Your rant indicates to me that you haven't, or if
you have, you have seriously misunderstood what you read.

Ben

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEr/V0WpTzygsnE8gRAr61AKCeicxB/AJ4i2wW76/jIN7fb35kVgCgg3EP
hzVwE/Ze7ZeoRIUcw4cIgmc=
=Pf7J
-END PGP SIGNATURE-


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

Re: Packages to remove from frozen

[Ben Armstrong]

On Thu, 9 Mar 2000, Junichi Uekawa wrote:
> Isn't it that to decrypt 1024 key takes double the amount of
> CPU time than decrypting 1023 key, as long as there is no other
> method than brute-force method of trying every combination.
> 
> IMO It is a serious security issue, when the system is half as secure
> and one is not notified. And the person is trying to use a ssh.

Where 'n' is a "reasonable" amount of time to crack a key using
brute-force, doubling 'n' does not equate to doubling the security of your
system.  At the most, you have caused the cracker the minor annoyance of
having to wait twice as long for a result. 

Conversely, if '2n' is an "unreasonable" amount of time to crack a key
using brute-force, halving it to 'n' does not equate to halving the
security of your system.

In other words, I rely on my ssh keys being several orders of magnitude
more difficult to crack than weaker crypto that is crackable in a
"reasonable" amount of time by brute force.  Whether the keys are 1023 bit
or 1024 bit is irrelevant.  Both accomplish this goal.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Re: ITP: solfege

[Ben Armstrong]

Tom,

I'm looking forward to it very much.  This is on Debian Jr.'s list of
programs suitable for children that we'd like to see packaged.  (My
children are not yet old enough to make use of it, I think, but it won't
be long.)  I'm a programmer and musician.  I could've used something like
this back in high school when I studied music theory.

Ben

On Sun, 19 Mar 2000, Tom Cato Amundsen wrote:
> Solfege is an eartraining program for GNOME written in python.
> (http://solfege.sourceforge.net)
> 
> I'm the author of the program and Olav Stetzer will be sponsoring me.
> The package will be called  solfege
> 
> Tom Cato Amundsen
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 

-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Re: Embedded Debian (was: compaq iPaq)

[Ben Armstrong]

On Wed, 16 Aug 2000, Matthew Franz wrote:
> Would its "raw material" be pre-compiled debian binary packages or would
> it be able to build the system from source.  Unless there were separate
> embedded .debs, I don't know that the standard binaries would be compact
> enough to support limited memory/storage environments.  Take busybox.  
> Based on the build instructions, the app would modify busybox.def.h and
> build the binary to contain only the commands/features that were
> necessary.  In many cases, the standard .debs would probably be fine, but
> in some cases you would need more control over the build.

For the most part, I think there is enough flexibility within Debian to
pick and choose the smallest tools that will do the job from among the
binary packages.  Where Debian currently falls short, we can create -tiny
versions of packages as needed.  Most useful optimizations that can be
done at compile time can also be used to create binary packages to save
people the time and bother of compiling it themselves. 

Busybox, however, is a special case.  Looking at the boot-floppies package
in Debian, busybox is compiled specifically for boot floppies, and no
mechanism is provided for hand-picking components.  So I agree that some
sort of configuration at compile-time would be a useful.  Is busybox used
anywhere else in Debian?  It's curious that busybox isn't packaged
separately. 

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Confusing Red/Blue buttons (was: Security of Debian SuX0r?)

[Ben Armstrong]

> Peter Makholm writes:
> > I've just helped a friend instaling Debian. He had two comment
> > about the above question. Is it the red or blue button there is
> > active? It is badly marked which button you are about the press.

On Thu, 31 Aug 2000, Decklin Foster wrote:
> You know, that *has* been bugging me... However you can use the cursor
> to figure it out (unless your terminal is weird, I suppose).

It bugs me too.

> Is this hardcoded into dialog, or could the appearance be configured
> by debconf at runtime?

Perhaps the underscore attribute could be set in addition to highlighting
for the currently selected option?

Of course, I'm totally ignorant of the actual implementation, so perhaps
there is some reason this is difficult to accomplish.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

ITP: robodoc

[Ben Armstrong]

I have need of ROBODoc for my own free software project.

This GPL'd package is a documentation tool for code.

The home page is:

http://www.xs4all.nl/~rfsber/Robo/index.html

I have packaged version 3.2.2 of ROBODoc.  The test packages are available
at:

http://master.debian.org/~synrg/

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]


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

ITP: Sword, GnomeSword

[Ben Armstrong]

I'd like to package Sword and GnomeSword:

http://www.crosswire.org/
http://gnomesword.sourceforge.net/

These are Bible study tools.

The Sword project has a lot of large data files:

ftp://ftp.crosswire.org/pub/sword/modules/raw/

I could wait for the data section to be created, or just supply an
installer for Sword modules that downloads them & installs them.  (Or
both.)

Sword is GPL'd.  So is GnomeSword.

Speak now or forever hold your peace.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]


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

Re: ITP: Sword, GnomeSword

[Ben Armstrong]

On Sat, 9 Sep 2000, David Starner wrote:
> If the program needs one to run, then at least one should be packaged.
> I'd prefer not to see a lot of installers that download free software -
> the one's that download non-free stuff are annoying and cause enough
> problems as it is.

Sure.  Probably the most interesting ones to package (in terms of package
functionality, and as an English speaker) would be:

  KJV.zip   2226 KbMon Dec 13 00:00:00 1999 
  - This contains Strong's numbers which, presumably, are
linked into the Strong's Greek and Hebrew dictionaries.
  - Yes, I know there is also already the complete KJV text
in Debian, but this is a version formatted specifically
for Sword, complete with the cross references, italics,
and so forth.

  Naves.zip  647 KbMon Dec 13 00:00:00 1999 
  - A fairly standard Bible study reference.

  Personal.zip40 KbMon Dec 13 00:00:00 1999 
  - A module for making your own personal commentary.

  StrongsGreek.zip   866 KbSat Dec 18 00:00:00 1999 
  StrongsHebrew.zip  867 KbMon Dec 13 00:00:00 1999 
  - These are the Strong's Greek and Hebrew Bible dictionaries.

  WEB.zip   1461 KbFri Dec 17 00:00:00 1999 
  - This is a free, modern translation.
  - There are, in my opinion, better modern translations, but
none of them are free :(  The Sword project is working on
the copyright holders to try to get them to free their
texts, though.

  Wesley.zip2025 KbMon Dec 13 00:00:00 1999 
  - A standard commentary.

This selection has nothing to do with my particular theological leanings.
I have merely tried to provide a usable subset that exercises as much of
the package as possible.  People can alter their selection to suit their
tastes either by downloading the rest themselves, or ordering Sword's
CD (which they provide "at cost", as I understand it).

If you want to proof my selection and make suggestions, please
look at:

http://www.crosswire.org/sword/download/ModDisp.jsp?modType=Bibles

Note that "Locked" entries are not free texts.  They are provided in 
encrypted form for developers.  Ignore them.

Also, look at:

ftp://ftp.crosswire.org/pub/sword/modules/raw/

to get an idea of sizes.

The selection shown above is around 8M.  I don't think that's an
unreasonable size.  Compare this with the sizes of, say, festlex-* and
festvox-*.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]


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

Re: Obsolete software in /usr/local

[Ben Armstrong]

On Fri, Jan 05, 2001 at 05:30:58PM +, Dale Scheetz wrote:
> I run several "ancient" programs, by housing them in /usr/local/bin, with
> the libraries they need (which are no longer provided in Debian) situated
> in /usr/local/lib. In previous systems, right up to potato, this worked
> fine.
> 
> I just finished building a woody system, so I can get my packages up to
> date, and all these programs stopped working because the needed library
> was not found. If I copy the /usr/local/lib contents to /lib everything
> works fine, suggesting that ldconfig no longer traverses /usr/local/lib
> for the libraries found there. Is this what is going on ... why ... and
> what do I do to correct the problem?

It would seem to come down to this entry in /usr/share/doc/ldso/README.gz

Changes in version 1.9.2:

Removed /usr/local/lib from the default /etc/ld.so.conf
for Debian (Bug#8181).

Changed ldconfig to be 64-bit clean (H.J. Lu).

You simply need to add /usr/local/lib to /etc/ld.so.conf and run
ldconfig and all will be back to the way it was before.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Re: Obsolete software in /usr/local

[Ben Armstrong]

On Fri, Jan 05, 2001 at 01:31:42PM -0400, Ben Armstrong wrote:
> Changes in version 1.9.2:
> 
> Removed /usr/local/lib from the default /etc/ld.so.conf
> for Debian (Bug#8181).

oops, except that mod is *ancient*.  way before potato.  dunno why this
would change between potato and woody. 

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Re: Obsolete software in /usr/local

[Ben Armstrong]

On Sat, Jan 06, 2001 at 03:49:07PM -0500, Greg Stark wrote:
> I've been meaning to bring this up for a while: 
> Why on earth was this change ever made?

I can't speak for whoever made the change, but I suspect that it is
because LD_LIBRARY_PATH can be used to support libraries in /usr/local/lib
for programs in /usr/local/bin without messing up anything that ships with
Debian.  Otherwise, there exists the possibility that the wrong library
will be used.  This is especially of concern for developers, who may be
putting things in /usr/local/bin and /usr/local/lib to test before
releasing a package.  We would not want their local libraries to be linked
in official Debian packages.

In any event, looking in bugs.debian.org for the old bug that this change
closed might give you more info than this rough guess.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Re: Obsolete software in /usr/local

[Ben Armstrong]

On Sun, Jan 07, 2001 at 02:14:42PM +1100, Peter Eckersley wrote:
> That doesn't seem like an elegant explanation.  Wouldn't it make more
> sense to have a script to make sure that a Debian package hasn't got
> links to whacky non-standard libraries?
> 
> The current behaviour is rather non-intuitive, and, as Greg said, lots
> of sysadmins will change it (after wasting time trying to find out
> what's going on).

Well, I guess the package maintainer should be asked, then.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Re: Unofficial projects related with Debian.

[Ben Armstrong]

On Fri, May 23, 2003 at 07:37:21PM +0200, Mathieu Roy wrote:
> The fact a project is hosted somewhere usually imply some special
> relations to his host.

Sure.

> So even if, for Debian people, being hosted on www.debian.org is not a
> reliable indicator, it's highly possible that many persons rely on it.

Well, I don't mean to say that my Debian Jr. project is "not official" and
therefore people shouldn't rely on it.  Rather, my point is that where the
project is hosted shouldn't indicate that a project *isn't* "official".

If, for example, any project started by any Debian Developer in good 
standing which has been acknowledged by the community as making a positive 
contribution to Debian is deemed an "official" project, the developer
shouldn't be forced to host it anywhere in particular, but rather should 
have the choice to host it wherever is convenient.

That being said, I do believe we need a better (more comprehensive) list of
such projects with higher visibility on the web site.  But that list will 
likely consist of pointers both to www.d.o and other sites 
(people.debian.org, alioth, and *.debian.net being a few popular 
alternatives).

> Not being hosted on www.debian.org does not make an official project
> unofficial but being hosted on www.debian.org will probably 
> make it in some manner official for (maybe) a lot of visitors.

Right.

> I do not say that's a problem, I don't know, it's up to you. My point
> is just the fact that the host name is not something completely free
> (as beer!)

I don't think there's a problem here.  By mentioning that my project is a
"personal project" I just meant to underline that to be accepted as a Debian
subproject has very informal criteria.  I think this is a good thing.  As
such, I am against making hosting a project on a particular site a
requirement to bless it with "official" status.

Was that a bit more clear?

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: Unofficial projects related with Debian.

[Ben Armstrong]

On Fri, May 23, 2003 at 04:56:06PM -0300, Gustavo Franco wrote:
> I guess that subproject-howto can be the start to 'Debian 
> Subproject Guidelines' or 'Debian Subproject Policy'.What do you
> think, Ben?

Sure, it could be a start.  The subproject-howto is intended to be a
hands-on guide to creating and maintaining a subproject.  It's pretty much a
"guidelines" document already.  However, a) it only contains my point of
view and b) it is dreadfully incomplete. 

I don't think there needs to be a policy document.  Policy is appropriate 
for our software because failure to comply with policy makes it difficult 
for parts of the system to cooperate with each other.  Subprojects are much 
more self-contained, and there are as many ways of doing them as there are 
project leaders.  So a guidelines document is all that is really needed.

I'd like to see input from others into the subproject-howto document,
particularly those who are in the process of creating new subprojects, and
those who have already established their projects but may have done things
differently than I have with Debian Jr. 

Would an Alioth project for subproject-howto help move this document along?

Is the name "subproject-howto" OK?

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: Unofficial projects related with Debian.

[Ben Armstrong]

On Fri, May 23, 2003 at 03:01:46PM -0300, Gustavo Franco wrote:
> > That being said, there is certainly a difference between "projects which
> > fork Debian to make a new distro (i.e. providing own versions of existing
> > Debian packages)" vs. "projects which add packages of their own (outside
> > Debian) to extend Debian" vs. "projects which include all of their packages
> > in Debian itself (or at least extend Debian's infrastructure itself, if the
> > project doesn't have any packages of its own)".  Debian Jr. is of the latter
> > sort.  Which of these three kinds of projects are Mono, ipv6, and ddtp?
> 
> Forks aren't subprojects.

Sure.  I just included it as a part of the spectrum for the sake of 
comparison.

> "Projects which add packages or features for packages that already exists or
> some sort of experimental infrastructure", these are IMHO good for Debian
> subprojects.Debian Jr., Mono, ipv6 and ddtp are covered by this description,
> no?

It sounds plausible.  Debian Jr. is, at least.  I didn't look at the others.  
That's why I was asking you, since you brought it up. :)

> Yes, you're the leader of this subproject but IMHO you need be a developer to
> start/maintain a new subproject and follow (obviously) the DFSG and the 
> decisions of the entire project.

Sure.  So minimally, a subproject needs a DD to found the project and a DD 
to add what the project produces to Debian.  But beyond that fairly 
self-evident point, what else can we say about what a subproject *should* 
do?  There are probably lots of things that are *beneficial* to making a 
subproject work, but I can't think of anything else that is *necessary*.

> I'm just trying start some points to be
> included in the "Debian subproject guidelines".

And I'm glad you brought it up.  I had hoped to get further with my 
subproject-howto, but ran out of "oomph" some time ago. :)

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: Bug#199642: xpilot: French translation of the debconf templates

[Ben Armstrong]

On Wed, Jul 02, 2003 at 08:46:50AM +0200, Michel Grentzinger wrote:
> Please find the attached fr.po file, which is the french translation of
> the debconf templates. This file has been reviewed by the contributors
> of the debian-l10n-french mailing-list.
> 
> Could you put it to the debian/po directory of this package ?

I'm sorry to hear my inclusion xpilot-server.templates in the xpilot 
source package has cost a translator time giving it attention, as my
package does not use it yet.

I added the template, intending to debconfize my package, but never did do 
anything with it.  You'll observe, if you look at the package carefully, 
that nothing references the corresponding xpilot-server.config.  I can't 
guarantee that it will anytime soon, either.

I don't know if this shows up a flaw in the translation process that can be 
fixed easily, or if it's just an unfortunate issue we'll have to live with 
from time to time.

Now I'm left at a loss as to what to do with the file.  I want the 
half-finished work to remain in the package so that someone picking up the 
package and customizing it (or in future, adopting it, should I decide to 
ever give it up) can benefit from it.  But to include the translation is 
going to give the wrong signals to other translators, causing them, too, to 
spend unnecessary time with translations for texts that aren't even in use 
in the package.

So, how do I include "development only" text in debian/foo.templates that 
translators are not to waste their time translating until it actually goes 
into production?  And do we need a standard for this?

Regards,
Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: Correct Directory for networkboot clients

[Ben Armstrong]

On Sat, Aug 23, 2003 at 01:30:55PM +0200, Goswin von Brederlow wrote:
> /usr/share/ltsp// is probably better. Otherwise you can#t boot
> different archs from the same server.

Shouldn't that be /var/lib/ltsp// instead?  I'm assuming the root
filesystem is writable.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: Correct Directory for networkboot clients

[Ben Armstrong]

On Sat, Aug 23, 2003 at 02:38:32PM +0200, Daniel J. Priem wrote:
> The rootfilesystem is writable but will be normaly not changed. Only on
> Startup the configfiles for the client will be created / linked

Still, conceptually, a root filesystem is "state" information for the 
netbootable client.  Even if the default policy is to not change the root 
filesystem, is that written in stone?

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

OT: debian mentors & ubuntu

[Ben Armstrong]

On Tue, 2005-07-19 at 12:21 +0200, Nico Golde wrote:
> Heyho,
> why is mentors.debian.net powered by Ubuntu?

http://mentors.debian.net/
About this repository
Welcome to the debian-mentors public software repository.
...
Please note that this service is not run as a part of the
official debian.org web site.*
...
If you have questions which you do not find answered on these
web pages please write an email to [EMAIL PROTECTED]

Ben
* And if it were, you'd ask debian-project, not debian-devel.


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

Re: Usability: Technical details in package descriptions?

[Ben Armstrong]

On Wed, 2005-07-20 at 18:13 +0200, Nico Golde wrote:
> [...] 
> I think one reason could be that some poeple would rather
> install a programm in a language they know and they are able
> to debug. Just a guess.

Debtags "facets"[0] are better for this.  Descriptions are supposed to
help *ordinary* users decide which programs to install.  (Hint: most of
the world doesn't know how to debug in *any* language.)

I agree that minor bugs are called for when descriptions contain
non-descriptive technical trivia like this.

Ben
[0] http://debtags.alioth.debian.org/paper-debtags.html#facets


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

Re: Usability: Technical details in package descriptions?

[Ben Armstrong]

On Thu, 2005-07-21 at 13:45 +, Thaddeus H. Black wrote:
> 1.  Compiled programs (C, C++, Fortran 77, Ada, ...) usually run leaner
> and faster than do interpreted ones (Perl, Python, Ruby, ...).

In general, algorithm choice is much more important than language.
Also, the language the main program is written in may be of little
significance to the program's overall performance if the grunt work is
done in libraries written in a compiled language.  In the end, the
user wants to know if the program's speed and size is acceptable for
their needs.  The language that the program is written in does not
directly answer these questions, and sometimes is even misleading.

> 2.  Programs written in obscure languages may prove unmaintainable if
> the original developer disappears.  Besides threatening obsolescence,
> this can be a security issue.

You've furnished a reason *not* to put the language in the description
(if I wrote a package in an "obscure" language and took your point to
heart, I'd not want to advertise the fact).  Besides, what is obscure?
Ruby?  Ocaml?  Snobol?  Fortran?  Scheme?  How is a user to assess
whether these are up-and-coming languages, less popular but still well
supported, or completely obsolete?  I doubt if most users know the
difference.

> 3.  Programs written in widely used languages (C, C++, Perl,
> Python, ...) may work better simply because the programmer had adequate
> access during development to high-quality modules and library bindings.

A false sense of security at best.  You could argue conversely that the
more popular the language, the more likely a novice programmer has
chosen it to dash off their first programming project and has managed to
get it into Debian.  And perhaps using an "obscure" language could be
viewed as a filter, weeding out the less-motivated and less-skilled
programmers.  Again, the user cannot use implementation language as a
reliable indicator of quality.

> 4.  With a language come a mindset, an aesthetic and a development
> culture.  Although one cannot speak in absolutes, generally speaking,
> which program would you expect to be more focused and reliable: a
> program written in C++ or an alternative written in Perl?  (On the other
> hand, which of the two programs would you expect to be available
> sooner?)

Now we're *really* getting touchy-feely.  I think we're losing sight of
the goal: the user, reading the description, should get a sense of what
the package does, whether it is likely to meet their needs, and whether
it offers distinct advantages over any of the alternatives.  While I can
appreciate that some small minority of users out their are aware of the
"mindset", "aesthetic" and "development culture" of an implementation
language, and therefore have some mild bias towards packages implemented
in it, it certainly isn't a primary indicator of whether the package is
suitable for a particular use or not.

> 5.  Some languages are inherently more debuggable (or less bug-prone)
> than others.  C++ is more debuggable than C, which itself is more
> debuggable than Fortran 77.  Python is more debuggable than Perl.
> Programs written in the more debuggable languages may rationally be
> expected to suffer fewer bugs.

A more direct measure of this can be determined by a bit of research by
the user first: check the Debian bug database, the changelogs, the
upstream bug database, the support & development mailing lists.  Ask
your friends.  Is this a good program, or is it a buggy piece of waste
product?

> 6.  Some languages enjoy not only free compilers or interpreters, but
> also well written, complete free documentation.  It may not seem like
> much, but a limited ideological motive may exist to promote programs
> written in such languages.

We're getting further and further from real user concerns.  See my
answer to 5.

> 7.  Some users may want to be able to read parts of the source of the
> programs they use---even if they have no intention of contributing to
> development.  This is Debian, after all.  Programs written in obscure
> languages may be vaguely deprecated for this reason.

apt-get source  and look it over if you're an aspiring
developer.  There isn't any better way to get acquainted with the source
than to actually look at it.

> If it matters, the languages I personally use most on a daily basis are
> Perl, Fortran 77, Octave and Bash (also occasionally C, C++ or
> Python)---some of which do not rank very well by my own criteria.

Octave, what's that?  Hm, I guess it must be one of those shoddy
deprecated languages.  I'll make sure to avoid anything you've written
in it. ;)

> However, I do tend to avoid publishing things written in Perl, because I
> use Perl often and know Perl's nature.  As a user, I tend to prefer
> software compiled from C/C++.  Hence the language in which a program is
> implemented is somewhat relevant, at least to me.

And "somewhat relevant" is exactly what the debtags aspect
"implemented-in" is for, as men

Re: Usability: Technical details in package descriptions?

[Ben Armstrong]

On Thu, 2005-07-21 at 19:58 +0200, Thijs Kinkhorst wrote:
> nstead of putting it in the first sentence, the second paragraph would
> be a fine place to mention details like this, satisfying both novice and
> advanced users.

But why bother, when debtags does "implemented-in" does the job better?
Extra verbiage in the long description that adds no value for most users
is best simply left out.  It will just make the description a longer
read (not to mention introducing possible "false hits" in an apt-cache
search) which is a net negative effect on the users that don't need or
want this information.

Ben


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

Re: Usability: Technical details in package descriptions?

[Ben Armstrong]

On Sat, 2005-07-23 at 01:21 -0500, Manoj Srivastava wrote:
> Because that information is not presented to me in aptitude,
>  one of the preferred front ends to package management.  Once the deb
>  tags system gets integrated into the front ends, the long description
>  can stop shouldering some of the load of presenting all the
>  useful/relevant infdormation to the user interested in making an
>  informed decision.

Your criticism is valid.  Indeed this is a flaw in the current proposal.
But on one point, I think you have been unfair.  I believe you have
mistaken enthusiasm for an idea that is good, but cannot yet be fully
implemented without the appropriate tools in place and the cooperation
of maintainers, with a "shrill" defense of a weak proposal.  The
proposal does need refinement to account for pieces of the system that
are not ready yet, and to clarify when package descriptions should be
changed today, but it is not fundamentally flawed.

I do not believe anyone in this thread has claimed that appropriate
mention of the langauge appears in the description now should be
removed.  If I gave this misimpression, please understand this is not
what I meant.  I merely challenge maintainers to consciously compensate
for our implementation-centric bias as developers, recognizing that
users focus on utility.  If those users are themselves developers,
certainly implementation will be important.  If they are, as a rule,
not, we should think twice about including "implementation trivia" in
our descriptions.

I see potential for debtags to help streamline the information in our
package descriptions down to the essential qualities that help a typical
user decide whether or not they want to try the package.  This is by no
means a "dumbing down" of package descriptions.  The process can start
now, both with the voluntary removal by maintainers of non-essential
details from their own descriptions and supporting the development of
debtags.

Ben


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

Re: What is going on with udev?

[Ben Armstrong]

On Wed, 2005-08-03 at 18:48 +0200, Frans Pop wrote:
> On Wednesday 03 August 2005 18:15, Steve Greenland wrote:
> > Thanks for the pointer, Adam, and a giant "Feh!" to the genius who came
> > up with that idea.
> 
> Did you even think of asking for the rationale behind the name change?
> 
> Hint: check the archives of the kernel mailing list.

... which, for the lazy and/or impatient starts here:

http://lists.debian.org/debian-kernel/2005/07/msg00192.html

Ben


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

Re: What is going on with udev?

[Ben Armstrong]

On Wed, 2005-08-03 at 14:02 -0300, Gustavo Franco wrote:
> Closing, it isn't a bash against the kernel team. It isn't my point,
> my problem is with this "didn't you know, read X stupid!" approach.

I don't think pointing at the mailing list was an unreasonable reaction
to the "genius" comment, which implied that the namechange was entirely
arbitrary.  And I didn't hear anyone call anyone else "stupid".  I think
you're being a bit oversensitive.

But I was mystified, myself, until I searched for the renamed package.
I agree a d-d-a post would've helped clear up the confusion, and wonder
why this wasn't announced.

Ben



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

Re: What is going on with udev?

[Ben Armstrong]

On Wed, 2005-08-03 at 19:16 +0200, Frans Pop wrote:
> On Wednesday 03 August 2005 19:04, Ben Armstrong wrote:
> > ... which, for the lazy and/or impatient starts here:
> 
> > http://lists.debian.org/debian-kernel/2005/07/msg00192.html
> 
> To be honest, I was thinking more of:
> http://lists.debian.org/debian-kernel/2005/05/msg00403.html

Then I should add "unobservant" to lazy and/or impatient. :)

Thanks for the correct reference.

Ben


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

Re: mass bug filing on packages that are blocking use of cdebconf

[Ben Armstrong]

On Tue, 2005-08-02 at 18:46 -0400, Joey Hess wrote:
> Ben Armstrong <[EMAIL PROTECTED]>
>xpilot

I offered this for adoption a while back.  Nobody took up my offer.  I
finally uploaded xpilot-ng today (see my 3-year-old ITP #141099) and
plan to make it supercede xpilot (i.e. strip the contents of the old
xpilot packages to turn them into dummy metas to assist with the
upgrade).

So, either wait for xpilot-ng's acceptance and its subsequent
replacement of xpilot, or if you need this resolved sooner, go ahead and
NMU xpilot with just the debconf fix.  I won't have time for either
until next weekend.

Ben


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

Re: mass bug filing on packages that are blocking use of cdebconf

[Ben Armstrong]

On Sun, 2005-08-07 at 22:13 +0200, Jeroen van Wolffelaar wrote:
> Just curious: why not, in that case, upload xpilot-ng as xpilot?
> 
> If the new upstream is actually the better one, it makes sense for it
> to go on under the label of xpilot in my opinion.

I'm still holding out for the remote chance upstream might deliver on
their promise to release an XPilot 5, which would then offer some
features XPilot-ng doesn't.  With that in mind, I included -ng in all
filepaths and the package names so they won't conflict.

While it is still possible they might release xpilot++ (the working name
for XPilot 5, since they've translated it to C++) which would then
become the next version of the current xpilot package, so long as 4.5.5
remains in the current state of disrepair, I feel it is better to have
users upgrade to xpilot-ng.

Ben


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

Re: Packaging a PostScript resource

[Ben Armstrong]

On Wed, 2005-08-10 at 16:37 +0100, Terry Burton wrote:
> I appreciate your efford, but please let me tell you, that it
> is
> a) highly uncommon to ask for a package sponsor without an url
> to the 
>   source packages.
>  
> PostScript is an interpretted language, so I fail to understand what
> you mean by source packages in this context.

Source package != source code.  All binary (.deb) packages *must* have a
source package (.tar.gz, .diff.gz, .dsc) even if they only contain
interpreted files.

Go read the doc that was recommended, and I think you'll understand.
Once you have gained a basic grasp of Debian packaging from reading
these docs, and have applied any corrections you feel are necessary from
your reading of the doc, you'll find it much easier to find someone to
sponsor your package.

Ben


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

Re: Dogme05: Team Maintenance

[Ben Armstrong]

On Sun, 2005-08-14 at 14:15 +, W. Borgert wrote:
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.

It's a nice ideal.

> It is useful to
> invite non-DDs, esp. upstream developers and people from Debian
> derivatives to participate in such teams.

I've tried that.  No luck yet.

> Assumptions:

No arguments against I through IV.

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

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.

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

In my case, there would be a team of one.  I could take a "build it and
they will come" approach, I suppose, but unless by creating the project
actually attracted other developers, the team maintenance overhead
(basically just startup costs) would outweigh the advantages.  Let's
just say I'm not overly optimistic about my prospects, given my failure
so far to attract another developer to co-maintain with me.  Upstream is
just too busy doing upstream work, and doesn't want to be bothered with
packaging, which I seem to do well enough without their help.

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

I collaborate just fine with upstream.  However, this collaboration with
derviers sounds interesting.  I haven't yet spoken with any derivers
responsible for my packages.  That might be an overlooked source of help
for me.  Thanks for the reminder that they're out there.

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

Again: will a team of one, with a "help wanted" sign hanging on it
suffice?  I am ideologically supportive of team maintenance, but
pessimistic about the prospects of some useful packages ever having more
than one maintainer, because they serve a small subgroup of specialized
users within Debian.

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

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

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

Works for me.

Ben


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

Re: README - confusing, irrelevant, redundant, useless

[Ben Armstrong]

On Sun, 2005-08-14 at 12:55 -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.

That's my gut feeling too.

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

Duplication should be avoided when possible.  It's a lot of work.  If
you want to cross-reference particular parts of upstream's README in
README.Debian, that's far preferable.

Why not just help improve upstream's README when you encounter poor
quality work?  That's what you'd do with code, wouldn't you?

> The original readme is still intact for those
> users who care.

I don't think upstream's original, untainted README should be considered
sacrosanct, any more than any source code file in the same package.  If
it can be improved, patch it.  Then send your patches upstream.  If they
reject your patches, work with them until you arrive at a consensus.  If
a consensus can't be reached, continue to ship your version.  If you're
worried about people being confused about "missing" material you've
excised, state up front what you've done to it.  The curious can always
obtain the "untainted" README from the source package.

Ben


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

Re: README - confusing, irrelevant, redundant, useless

[Ben Armstrong]

On Mon, 2005-08-15 at 10:08 +0200, Thijs Kinkhorst wrote:
> On Mon, August 15, 2005 01:42, Ben Armstrong wrote:
> > Why not just help improve upstream's README when you encounter poor
> > quality work?  That's what you'd do with code, wouldn't you?
> 
> Requirements on upstream README and information that's useful within
> Debian differ. It often contains information about building, installation
> or bug reporting which is not relevant to Debian.

Is it too much to ask upstream to separate this info into different
documents (e.g. README.install or INSTALL)?  Or is there just no way
we'll ever get around the differences between a Debian user's needs and
a tarball user's needs?  It would be nice if there were a standard way
to distinguish between the two instead of inventing a Debian-specific
solution to this problem.  (That is, all distributors of binary packages
face the same problem, don't they?)

Ben


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

Re: Dogme05: Team Maintenance

[Ben Armstrong]

On Mon, 2005-08-15 at 06:14 +, W. Borgert wrote:
> 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.

Well, you did say "all packages".  If you had talked explicitly only
about essential and standard packages, you would have heard no
complaints from me.

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

Thanks for the secret TLA decoder ring.
Ben


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

Re: README - confusing, irrelevant, redundant, useless

[Ben Armstrong]

On Mon, 2005-08-15 at 16:31 +0200, Henning Makholm wrote:
> I don't think there is a way to get around this difference. There is a
> fairly widespread convention of putting compilation instructions in an
> INSTALL file, but there is no similarly widespread convention for
> putting information about, say, "you'll need these libraries", "here
> is what this program can be used for" or "here is how tarball users
> should report bugs" in other files than README.

I'm just struggling with how to strike a happy medium between best
practices for Debian and best practices for upstreams.  I don't believe
it is in our best interests to, as some have suggested, copy the useful
README info into README.Debian.  It's just going to drift out of date
with changes made by upstream.

> In general, I would assume that *most* of the README files we ship in
> .debs could be dropped without ill effects. In the cases where it
> actually contains text that is useful for end-users as well as
> significant text that isn't, it might be worth a try to approach
> upstream about separating the *useful* stuff out as a file that is
> *different* from README.

Yes, that's what I'm driving at.  I've seen some nice multi-level
READMEs that provide a few notes for compiling the package up front
(which is what most people look at a README in a tarball to find out)
and just put "see" references for the rest, segregated into README.foo
files that deal with different topics.

> However, trying to move traditional README information *away* from
> README just so that we can ship the useful text easily under the name
> README would appear to be a lost cause. Note that there is no
> requirement that documentation in the .deb has to be named README at
> all.

Understood, and agreed.

Ben


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

Re: README - confusing, irrelevant, redundant, useless

[Ben Armstrong]

On Mon, 2005-08-15 at 08:54 -0700, Russ Allbery wrote:
> I don't understand why people keep saying that upstream bug reporting
> instructions are irrelevant to Debian.  Surely I'm not the only person who
> wants to be able to discuss some issues directly with upstream when
> they're not in the slightest bit Debian-specific.  (Not to mention that
> the reporting instructions are sometimes also the *query* instructions,
> which can be extremely useful.)  And, with orphaned packages or packages
> with busy maintainers, it's often better to take problems up with upstream
> for practical reasons.

While exceptions certainly exist, most of the time, a user reporting a
bug on a Debian package directly upstream is not appropriate.  It is
better for the user to first seek help from their distribution.  Then,
if it is clear that the issue is upstream's problem, take it up with
them.

I would further maintain that unless you download, build, install and
test upstream's package without Debian patches, finding the same bug in
their own untainted release, you cannot reliably say there is an
upstream bug.  Or even if you can satisfy yourself that the bug is
upstream's, you might not have such luck convincing upstream.  And if
you're going to rebuild the package from source in order to make this
determination, you have access through that exercise to the original
README, complete with upstream bug reporting address, if they have
supplied one there.

So, it's not that the bug-reporting address is useless.  It's that it is
misleading to suggest to the user that bypassing filing a bug against
the Debian package and going directly to upstream is recommended.  If
there is a way of presenting this information so that those with a
legitimate need have easy access to it, while at the same time pointing
the majority of the users at the Debian Bug Tracking System, then by all
means, include it.  But I doubt if anyone currently takes the care to
make this distinction in their packages that include upstream
bug-reporting addresses.

Ben


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

Re: Dogme05: Team Maintenance

[Ben Armstrong]

On Tue, 2005-08-16 at 15:46 +0200, Wouter Verhelst wrote:
> It might take a bit longer for the new maintainer
> to be up to speed as compared to when one member of a team gets run over
> by a bus, but that doesn't mean "the project stops".

Team maintenance is only one way to accomplish the goal of uninterrupted
high quality of maintenance for all standard & essential packages.

The PTS allows for non-maintainers of an important package to watch
what's happening without necessarily being directly involved in a formal
team.  Perhaps we can reduce the time to come up to speed by encouraging
non-team-maintained packages to be "shadowed" by additional developers
who can then be called upon to NMU as needed?  This would entail
watching the bug reports as they come in, trying to figure out what's
wrong, contributing additional info and/or patches to the bug reports if
appropriate, and checking new releases to see what the maintainer has
done and why.

I think it's important not to underestimate the possible consequences of
it "taking a bit longer to come up to speed" when a maintainer of an
important package suddenly disappears.  For some values of "a bit", the
project could suffer a fair amount through such a loss.  I can't readily
provide an anecdote for when this ever occurred, but I do have a vivid
imagination.

Ben


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

Re: Dogme05: Team Maintenance

[Ben Armstrong]

On Tue, 2005-08-16 at 16:42 +0200, Wouter Verhelst wrote:
> For low-volume, easy-to-maintain packages, it's never too late to go get
> a comaintainer. Or to give the package away. And I simply don't believe
> that 'important package' implies 'lots of work to maintain it'.

I think what you're saying here is quite reasonable.  A simple concrete
example might help to make this point.  Pick a specific package that
meets these criteria and go through the thought exercise of when the
maintainer is run over by a bus and the package has no co-maintainer.  I
think the problem is, many of us, like me, do have vivid imaginations
and envision "bad things" happening when an "important" package loses
its only maintainer because the problem is painted in strokes that are
overly broad.  Perhaps I was too indirect in my request for anecdotes.
I'd like some more specific packages discussed so we can identify where
the potential problems lie and focus our energies on those, rather than
worrying over all of the corner cases that aren't real problems.

Ben


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

Re: mass bug filing on packages that are blocking use of cdebconf

[Ben Armstrong]

On Sun, 2005-08-07 at 17:08 -0300, Ben Armstrong wrote:
> I offered this for adoption a while back.  Nobody took up my offer.  I
> finally uploaded xpilot-ng today (see my 3-year-old ITP #141099) and
> plan to make it supercede xpilot (i.e. strip the contents of the old
> xpilot packages to turn them into dummy metas to assist with the
> upgrade).
> 
> So, either wait for xpilot-ng's acceptance and its subsequent
> replacement of xpilot, or if you need this resolved sooner, go ahead and
> NMU xpilot with just the debconf fix.  I won't have time for either
> until next weekend.

The debconf dependency is now removed from xpilot, as it is now just a
transition package to upgrade to xpilot-ng, which doesn't have the
dependency either.

Ben


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

Re: how to fully replace another package

[Ben Armstrong]

On Mon, 2005-08-22 at 01:32 +0200, Marco d'Itri wrote:
> The (still not uploaded) coldplug package conflicts+depends+provides
> hotplug. The issue is that since all the important parts of hotplug are
> conffiles they are not deleted when the package is removed, and this
> is bad (as in "the system will probably not boot" bad).
> 
> Does a way to force purging the package exist?
> Is there anything else I can do, other than deleting the files in the
> hotplug postinst?

Aren't you missing "replaces"?

Ben


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

Re: how to fully replace another package

[Ben Armstrong]

On Mon, 2005-08-22 at 21:41 +0200, Marco d'Itri wrote:
> On Aug 22, Ben Armstrong <[EMAIL PROTECTED]> wrote:
> 
> > > The (still not uploaded) coldplug package conflicts+depends+provides
> > > hotplug.
> > Aren't you missing "replaces"?
> Yes, what I actually meant was "conflicts+replaces+provides".
> My original question still stands:
> 
> > Is there anything else I can do, other than deleting the files in the
> > hotplug postinst?

Divert?  But policy says something about diverting a conf file not being
handled properly by dpkg.

Which conf files blow things up?  The reason I ask is, if it's an init
script, it should be written to exit if the appropriate binary isn't
found.

Ben


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

Re: how to fully replace another package

[Ben Armstrong]

On Mon, 2005-08-22 at 23:18 +0200, Marco d'Itri wrote:
> On Aug 22, Ben Armstrong <[EMAIL PROTECTED]> wrote:
> 
> > Which conf files blow things up?  The reason I ask is, if it's an init
> Just about all of them. Almost all files in the package are conffiles.
> 
> > script, it should be written to exit if the appropriate binary isn't
> > found.
> The appropriate binary is a conffile as well.

Now, that's not strictly true, is it?  /etc/init.d/hotplug
invokes /sbin/hotplug, which almost entirely consists of conffiles, but
is not itself a conffile.  Isn't that removed when the package is
replaced?  Or am I looking in the wrong place?

Ben


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

Re: how to fully replace another package

[Ben Armstrong]

On Tue, 2005-08-23 at 19:15 +0200, Marco d'Itri wrote:
> Think "hotplug events loop".

So, a hotplug event could load and run code (which happen to be in conf
files, and therefore cannot be diverted) in the old hotplug package.
The problem you're facing, it seems, is that while code should be
divertable, conf files aren't, but hotplug doesn't separate these out,
so the usual mechanisms don't work.  Am I on the right track?

Of course, init files are code and conf files, but they have a built-in
mechanism for preventing them from running, which is to look for the
binary the init file runs, and if it isn't there, don't do anything.  It
seems you don't have any such protection built into the hotplug
conffiles-that-are-also-executables, or else you wouldn't be in this
mess.

Ben


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

Re: how to fully replace another package

[Ben Armstrong]

On Tue, 2005-08-23 at 19:50 +0200, Marco d'Itri wrote:
> The init file does, but /etc/hotplug.d/default/default.hotplug does not.

Why is this file a conffile?  I didn't see any obviously configurable
parts in it.  If it were either wholly be moved elsewhere (/sbin) or the
guts of it moved elsewhere, and only a trivial shell that calls it were
left here, would your problem be solved?  (Well, I suppose this problem
would remain: how would you guarantee upgrades were only made from fixed
versions of hotplug -> coldplug, and not older ones?)

Ben


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

Re: how to fully replace another package

[Ben Armstrong]

On Tue, 2005-08-23 at 10:00 +0200, Marco d'Itri wrote:
> Right, it's not used but it's checked.
> But then there is still /etc/hotplug.d/default/default.hotplug, which if
> present will create all kinds of troubles.

Let me get one more thing straight before we move on ...

What's the sequence of calls that leads to this code being invoked?
Somehow I thought it was like this:

1. kernel hotplug subsystem detects an event
2. kernel dispatches the event handling using the program named
in /proc/sys/kernel/hotplug (default is /sbin/hotplug) passing it any
necessary argument(s) to hotplug
3. /sbin/hotplug dispatches the request to the appropriate handler named
in the first argument
3a. if a specific handler isn't found, any handler(s) in the default
directory are called

So doesn't this all fail if /sbin/hotplug is missing?  And if that is
so, why is this a problem if the hotplug package is removed but not
purged?

Or does your coldplug package provide a /sbin/hotplug that still
reads /etc/hotplug.d, and if so, why?

I do see that on a udev system, /proc/sys/kernel/hotplug is something
else (/sbin/udevsend).  Is that part of the problem?  If so, how?

Ben


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

Re: how to fully replace another package

[Ben Armstrong]

On Wed, 2005-08-24 at 16:30 +0200, Marco d'Itri wrote:
> On udev systems events are received by udevd, either using udevsend or
> (when the kernel input subsystem will be fixed) a netlink socket.
> /sbin/hotplug does not enter in the picture at all.
> 
> Then the default udev configuration will run the hotplug.d/ handlers.

Aha!  OK.  That makes it perfectly clear.  So the mere existence of the
default handler causes it to be run, and there's no way to stop that
without purging it.  This seems like a very bad design.

> This is not strictly needed, but I cannot avoid it until udev will
> become mandatory to have hotplug support (is there a consensus on this?).

Could udev be modified to not run the hotplug.d handlers
if /sbin/hotplug is missing?  (Or is that even the right thing to do?)

> > 3a. if a specific handler isn't found, any handler(s) in the default
> > directory are called
> No, default handlers are always run.

Doh!  Stupid me.  That's evident now in a reread of the code *and* GKH
even says so in his comments.

Thanks for clarifying the nature of the problem.

Ben


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

Re: making developer location from ldap public?

[Ben Armstrong]

On Thu, 2005-08-25 at 16:01 +0200, Robert Lemmen wrote:
> On Thu, Aug 25, 2005 at 02:50:51PM +0100, Oliver Elphick wrote:
> > You haven't explained why letting other DDs know this information, which
> > is available to them already, requires the whole world to know it.
> > 
> > If you have some proposals for letting non-DDs have the data, you need
> > to explain what they are.
> 
> well, of course i was talking about letting non-dd get to the data! it
> would be a public service. and the data in question would be your name
> and email along with your latitude and longitude if you entered it in
> the ldap database

You're still describing the "what" and not the "why".  In your original
proposal you talked about "fellow Debian developers" needing access for
keysignings, drinks, etc.  Well, fellow DDs can already do this.  But
why does the public need access?  Except for the very special case of a
new maintainer applicant (for whom the keysigning procedure posted at
nm.debian.org[0] is supposed to work -- and so far as I know, it does,)
noone other than a DD ever needs to see this info.  Or if there is some
other legitimate need, please build your case for it.

I would *not* be happy with removal of my lat/long data from
db.debian.org.  I live in a less-populated part of the world, and I
enjoy seeing my part of the world represented on the publicly-viewable
world map of anonymized developer locations[1].  But if your proposal
were implemented the way you described it, I'd have to choose between
having my dot on the map (which is acceptable and not a violation of my
privacy because the developer names aren't included) and having my
privacy.  So even if there is a case to be made for making this info
public some of the time, your implementation is flawed.

Ben
[0] http://nm.debian.org/gpg.php
[1] http://www.debian.org/devel/developers.loc


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

Re: making developer location from ldap public?

[Ben Armstrong]

On Thu, 2005-08-25 at 16:51 +0200, W. Borgert wrote:
> 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.

Not just a single field, but a whole set of fields, so I might tell my
fellow DDs I live at:

123 Specific St.
City, Province, Country
postal code
specific lat/long for my house (good for driving directions)

and for everyone else:

City, Province, Country
lat/long for center of city

But I have yet to hear a case for who would use this, outside of new
maintainers, for whom we already have an accepted procedure for
keysigning meetups.

Ben


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

Re: making developer location from ldap public?

[Ben Armstrong]

On Thu, 2005-08-25 at 17:57 +0200, Robert Lemmen wrote:
> there are two reasaons: 
> - while debian developers might have access to it, it's in a form that
>   makes it hard to access it, so i doubt that anyone will look up who 
>   is living at some place when he gets there. making this more
>   accessible is way easier if the one accessing the info doesn't need to
>   autheticate himself as a developer

If that's the case, we should improve developer access instead of
backing your proposal.

> - it's not only about keysigning, but mainly about getting to know more
>   people, preferably from different places. this is very interesting for
>   everyone, developers, new maintainers and also the many people who
>   contribute to debian who are not even in the new maintainer queue...

Social networking systems exist outside of Debian that do a better job
at this.  Supporting this is outside of our mandate, and not a good use
of our resources.  You're as likely to want to get to know people who
aren't DD's as who are.  How does your proposal address this problem?

> i see your point. i actually didn't expect many people to have a problem
> with disclosing where they live, but i might have been mistaken...

If you were talking about the average person on the street who thinks
nothing of sacrificing their privacy in the name of the "War on
Terror" (have a look at the polls some time, it's scary,) then yes, most
people don't have a problem with this.  However, in Debian there is a
heightened awareness and sophistication in thinking about privacy
issues, so naturally you are going to find plenty of people who would
rather err on the side of caution and keep such details as their exact
location in the world private.

Ben


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

Re: planet.debian.org vs. blog illiteracy

[Ben Armstrong]

On Mon, 2005-09-26 at 14:05 +0300, Lars Wirzenius wrote:
> I don't think there is a working way of reliably doing that. In theory,
> most web logs can do "categories", but those are not being used
> consistently, and they're also not really visible on planet.debian.org
> in a way that lets them be processed automatically.

It seems to me that the social part of the solution is to have bloggers
voluntarily use some standard category/categories to ease aggregating
them into a single feed covering debian development issues from all of
the various blogs.  That leaves only the small (I hope) technical
problem of making the categories visible on planet.d.o.

Ben


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

Re: planet.debian.org vs. blog illiteracy

[Ben Armstrong]

On Mon, 2005-09-26 at 15:29 +0300, Lars Wirzenius wrote:
> "Debian development issues" is a rather broad category. Should a travel
> report from Debconf be included? I think it should, yet it is not at all
> technical. Having a single "Debian development issues" feed is not going
> to work particularly well, I think.

I agree.  I'm not suggesting a single category will work, but merely
that having some agreed-upon category names would assist readers in
selecting from among them those that are Debian related.  However,
without a complete list of category names across all feeds at my
fingertips, it is hard to say how big this problem is (or if it indeed
even exists as I imagine it).

It seems step one would be to make the categories for all feeds visible
on planet.d.o.  Only after that is done will it make sense to discuss if
(and whether) the category names should be "normalized" to make it
easier for users to select those that interest them.

> I think it's a much better and easier solution to use the structure we
> already have: the existing mailing lists. Copy-pasting a web log entry
> to an e-mail shouldn't be too much of a bother, I rather think.

If it is so easy, why aren't bloggers doing this now?  There must be
some perceived value on the part of the bloggers to keeping limiting
their posts to their (presumably smaller? maybe that is a factor?)
blog-reading audience.

Ben


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

Re: Finding out in postinst whether some other package is configured

[Ben Armstrong]

On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured?  Testing for file contents can only tell whether
> it is unpacked, but that might not be enough.
> 
> If there isn't, are there other people who felt the need to know this?

I worry about why you would need to know this.  I'm envisioning a
package "A" that has a particular default configuration if you install A
before B, but a different configuration if you install B before A.  What
will the user be missing out on if they're installed in the "wrong"
order?  And what corrective action can the user take?

Ben


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

Re: Finding out in postinst whether some other package is configured

[Ben Armstrong]

On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured?

Assuming your package does something reasonable with this knowledge ...

> Testing for file contents can only tell whether
> it is unpacked, but that might not be enough.

I don't know about an "established" way, but libc6.postinst looks
interesting:

# Only get the ones that are installed, and configured
check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if ($1 
~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* installed$/) { print 
package }}')

Ben


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

Re: [Fwd: major problem with gnome-games dependency]

[Ben Armstrong]

On Tue, 2005-10-11 at 11:20 -0700, Thomas Bushnell BSG wrote:
> It should be an easy matter not to play the games even when they are
> installed.  Regardless, the "gnome" package is not necessary for the
> system; it is just a meta-package that depends on all the
> gnome-related packages.  If you don't want all the gnome-related
> packages, then you can skil installing the "gnome" package and just
> choose the ones you want.

This property of metapackages has always irked me.  If I install gnome
and then remove gnome-games, I won't automatically benefit in the next
release from any other goodies the gnome maintainers have added to
"gnome" package.

Of course, the user could use the "equivs" package to make a fake
gnome-games to satisfy the dependency, but the dire warnings in the
description of the equivs package (assuming the user even knows equivs
exists) are going to discourage most users from trying this.

Ben


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

Re: [Fwd: major problem with gnome-games dependency]

[Ben Armstrong]

On Tue, 2005-10-11 at 11:51 -0700, Thomas Bushnell BSG wrote:
> I think the question is: do you want all the goodies or you don't want
> all the goodies?

Well, the problem is, when "all the goodies" is a significant number of
packages, it is tedious to have to collect them all myself.

> I would not object to a meta package gnome-without-games if the gnome
> maintainers want to add one.  

And what about the user who said "and evolution"?  So far we have
gnome-without-games, gnome-without-games-and-evolution, and (logically)
gnome-without-evolution.  Care to add a few more exceptions and all of
their permutations? :)

> I would love a way to have a negative way of handling the whole darn
> thing.  I thought tasks were supposed to get rid of metapackages
> anyway.  

Sure.  So did I.

Ben


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

Re: [Fwd: major problem with gnome-games dependency]

[Ben Armstrong]

On Tue, 2005-10-11 at 20:07 +0100, Ross Burton wrote:
> That is what gnome-core is for: just enough of GNOME to be usable, but
> no real apps beyond EoG and gedit.  Purposefully created for people who
> want to use GNOME, don't want to install all packages manually, but want
> some control over what extra packages are installed.

$ apt-cache show-differing-dependencies gnome-core gnome
Dependencies only in gnome-core:
  Depends: ...
  Suggests: ...
  ...
Dependencies only in gnome
   ...

But in the absence of such a feature, I can't tell what I'd be missing
if I only installed gnome-core.

Ben


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

Re: major problem with gnome-games dependency

[Ben Armstrong]

With regards to the suggestion that some means be provided for admins to
easily install a subset of GNOME that suits the needs of government
and/or US government ...

On Wed, 2005-10-12 at 01:50 -0500, Peter Samuelson wrote:
> I suppose you were joking, but in all seriousness, why does _Debian_
> need to add them?  Let the site administrator do it, using 'equivs'.
> If you're installing more than a few machines somewhere, sooner or
> later you'll want to create one or more site metapackages anyway.

OK, I'll bite.  Whenever there is an identifiable subset of Debian users
that a group of Debian developers care about, those developers can lift
some of the administrative burden of that subset by crafting for them a
CDD (Custom Debian Distribution).  Who are you to scoff?  If there is a
group of developers within Debian that cares about the needs of
government users in general, or for a specific region's government, let
them take care of this.  Why make all of the users do the extra work
individually if they all share the same needs?  It would be far more
efficient to expend the much smaller effort in development to provide a
solution tailored for their needs.

Ben


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

Re: Bits from the kernel team

[Ben Armstrong]

On Mon, 19 Oct 2009 22:54:47 +0100
Vincent Sanders  wrote:
> A constructive discussion was held about the outstanding firmware
> issues, how the team addresses them and how we might work with upstream
> to address our DSFG issues with kernel sources.

By chance, did any of that discussion touch on patching drivers so that
they can load without the firmware?  Many Eee PC owners currently have
no DFSG-free option for wifi (short of replacing the card) because
rt2860sta depends on a non-free firmware.  Some months ago I had a
discussion on irc with some members of the rt2x00 project about this
problem.  I discovered then that:

1. They expressed no interest in putting any more work into the legacy
vendor-supplied rt2860sta driver that is in the current Squeeze kernel
and were instead focusing efforts on rt2x00. (Unfortunately, rt2x00 will
almost certainly not be ready for 2.6.32, so I'm hoping someone else
will be willing to help with rt2860sta for Squeeze.)

2. They thought that all that without the firmware, users would really
miss would be some non-essential features like power management.

3. They thought it would be possible, and perhaps even essential to
deal with certain boards, to make rt2x00 work without the firmware.

4. However, a quick test: just tearing out the call to load it,
caused the driver to fail with a kernel panic.

The Debian Eee PC project would love to see Squeeze release with DFSG
support for as much Eee PC hardware as possible, so if anyone can
assist with supporting this chipset without the firmware for the
Squeeze release, we'd like to hear from you.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   sy...@sanctuary.nslug.ns.ca
 \`'  Debian   http://www.debian.orgsy...@debian.org
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]


signature.asc
Description: PGP signature

Re: nexuiz-data does not fit on a single CD

[Ben Armstrong]

On Fri, 20 Nov 2009 11:59:07 -0200
Gustavo Noronha Silva  wrote:
> On Fri, 2009-11-20 at 14:00 +0100, Stefano Zacchiroli wrote:
> This is silly. I haven't seen bug reports about packages not fitting in
> diskettes, and it would not make any sense if they were filed! =).

I thought this was why we had dpkg-split, so not exactly the same
problem.

> The world moved on, CDs are getting too small. It's a technical
> limitation which can be overcome by using the network, or bigger media,
> such as DVDs. While I think blacklisting the package for CDs is a
> pragmatical decision, making the package smaller should be just
> desirable, not a (specially RC!) bug.

Or supporting dpkg-split for this case too?  But probably not worth the
effort for just a handful of packages that arguably would benefit from
being broken into more manageable-sized packages anyway.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   sy...@sanctuary.nslug.ns.ca
 \`'  Debian   http://www.debian.orgsy...@debian.org
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: TaskSel proposal (Was: Proposal for a new CDD sub-project: Debian4Business)

[Ben Armstrong]

On Thu, 19 Apr 2007 14:46:35 +0200 (CEST)
Andreas Tille <[EMAIL PROTECTED]> wrote:

> On Thu, 19 Apr 2007, Luis Matos wrote:
> IMHO the best solution would be if tasksel would have a two level
> selection:
...
>  [ ] Custom Debian Distribution
>  [ ] Debian-Edu
>  [ ] Debian-Jr.
>  [ ] Debian-Med

I like this two-level proposal.

But as Luis pointed out, having material on extra CDs or needing the
network to install it is a bit of a problem.  I don't think a warning
alone is sufficient (What is the user supposed to do now?  Are they
supposed to furnish a network connection where there was none before?
Are they supposed to burn extra CDs on the spot?) Anything that is not
installable using the selected media should be greyed out.  Changing
your selected media will make more options appear.  I don't know if
this is practical, given the number of dependencies that would need to
be checked against the selected media before the menu could be drawn.
This could make bringing up tasksel rather slow.  I guess if it isn't
practical, a warning is better than nothing.

Of course, this points out again the brittleness of the metapackage
way of structuring CDDs.  To avoid having to have a full set of CDs to
install Debian Jr., I'm seriously considering softening almost every
dependency in Debian Jr. from Depends to Recommends.  Anyone using
aptitude with Recommends installed by default will still be able to
install even when not all recommended packages are available.
Unfortunately this is hard on the apt-get users who would then apt-get
install the junior- packages and find nothing installed by default,
but I understand #42266 was tagged fixed-in-experimental last summer,
so I hope this is something that will be fixed in Lenny.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]


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

Re: CDD: GastroLinux (RFC)

[Ben Armstrong]

On Mon, 14 May 2007 14:22:35 +0200 (CEST)
Andreas Tille <[EMAIL PROTECTED]> wrote:
> So maybe Debian-Dinner would be better? ;-)
> 
> BTW, I think we should have first something and then find an apropriate
> name for this something.  It makes no sense to do endless naming discussions
> before somebody steps up and announces that he really wants to do the
> gruntwork.

Fair enough.  But my curiosity is piqued so I can't resist one more suggestion:

Debian-Epicure

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]


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

Bug#492029: ITP: atl1e -- Atheros(R) L1e ethernet driver

[Ben Armstrong]

Package: wnpp
Severity: wishlist
Owner: Ben Armstrong <[EMAIL PROTECTED]>

* Package name: atl1e
  Version : 1.0.0.7r5
  Upstream Author : xiong huang <[EMAIL PROTECTED]>
* URL : http://marc.info/?t=12160065951&r=1&w=2
* License : GPL
  Programming Lang: C
  Description : Linux Base Driver for the Atheros(R) L1e Fast Ethernet 
Adapter

 The Atheros(R) L1e Fast Ethernet Adapter is present in a few ultraportable
 Asus laptop systems, such as the Asus Eee PC models 901, 1000 and 1000H.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Intel Atom Processor

[Ben Armstrong]

On Thu, 24 Jul 2008 15:09:57 +0200
Steffen Moeller <[EMAIL PROTECTED]> wrote:

> The EeePCs are sold throughout large resellers (Saturn, Staples, ...) in 
> Germany and at least until the new ones get out they all ship with
> Debian - perfectly visible to every potential customer passing by. I have not 
> seen Debian or Linux on any product before in these shops. So, I
> really think that for the perception of Debian (and Linux at large) it would 
> be good if there was some initiative that gives Debian on these
> machines some backup.

You are aware of http://wiki.debian.org/DebianEeePC I hope?  (Aha, I
see it has already been mentioned elsewhere in this thread, good.)

We take a very practical, bottom-up approach.  Get Debian working well
on one platform, the Eee PC.  Then make things as general as possible
and support it as quickly as possible in Debian itself.  I think if you
start top down: "let's tackle the problem of making Debian well
supported on this whole class of systems", a laudable goal, mind you,
then you will very quickly bog down in the execution unless you have
resources that go beyond what we currently have in the debian-eeepc
project.

So what do you think you could do particularly with regards to the Eee
to see it on these systems in shops?  We've talked a bit to Asus and
they've even assigned some people to talk to Debian about development
for the Eee.  But I'm afraid so far our focus has been very much on
just getting Lenny out the door with solid support for the Eee and not
so much on these bigger-picture issues.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]


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

Re: Intel Atom Processor

[Ben Armstrong]

On Fri, 25 Jul 2008 14:29:48 +0200
Steffen Moeller <[EMAIL PROTECTED]> wrote:
> many thanks for your reply. Your web sites are indeed what I wanted to see,
> possibly a bit too far away from John Doe who just bought such a machine
> as a Newbie Linux user,

Naturally.  The site is made by and for those (both developers and
users) who want to go a step beyond just using a pre-installed Linux
distribution. Serving the newbie community first would be a thoroughly
exhausting enterprise.  We would never make progress with the key areas
in which Debian needs to be improved to fully support the Eee if we
made that our focus.  And even if we took the task on, the wiki would
be the wrong starting point.

That being said, we do welcome and try to assist newbies in any way
that we can, given our limited resources.

> but nevertheless, I particularly liked the
> status page on http://wiki.debian.org/DebianEeePC/Status.

Thanks.  We recognized that we weren't effectively communicating to
people new to the project what we had accomplished and where we were
headed.  Even so, the status page doesn't go far enough to clear things
up.  The whole wiki (as wikis have a tendency to do) has grown in a sort
of haphazard way and needs some straightening up.

> Your site has no visibility to anyone in the shop who needs to make an
> informed decision about whether taking the risk to go for the XP route
> (which that guy probably knows well) and the Linux route (which saves some
> cash but gives you the impression to be alone). Sales of the Linux version
> are reportedly going sufficiently well to keep it in the shop, but they
> are selling far more Windows machines.

The wiki is probably not the best way to get this message across.  It's
a convenient place to keep notes of use to developers and advanced
users, but is not so good for advocacy/marketing.

> I'll translate that status page to German tonight since I liked it.

Thanks for your translation.  Please keep it up. :)

> Also
> will I then use some scribus or LaTeX magic to transform that page into
> a flyer that, if you agree to it, I will then carry to the local stores
> and just see what they say. Those stores will fight a lot not give the
> impression that they would do support themselves, so I need to think about
> the right wording here. I'll do that both in English and German, should
> not be too hard.

I think the Status page needs some updates first.  Perhaps such a flyer
could be the seed of a proper site.  Something along the lines of:

http://debian-live.alioth.debian.org/

Such a site might best be hosted at http://www.debian.org/devel/ where
it can be supported in multiple languages.

But I feel it is early in the project, yet, to be putting energy into
this.  Let's start with the code, ensuring that we have a more
newbie-friendly install process.  At the same time, the wiki needs
more work to give it more coherence.  And then we can think about
building a more carefully crafted site that does not change quite so
often as the wiki and serves as a better starting point for the
uninitiated.

Ben


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

Re: Intel Atom Processor

[Ben Armstrong]

On Tue, 29 Jul 2008 09:35:46 -0700
Kushal Koolwal <[EMAIL PROTECTED]> wrote:
> For now should we just keep track of the EeePC? 
> http://wiki.debian.org/DebianEeePC/Status

I can't answer the "big picture" questions you're asking.  As for
the Eee stuff, expect on d-d-a a new "Bits from the Debian Eee PC Team"
from me Real Soon Now.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]


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

Re: Bits from the Debian Eee PC team, summer 2008

[Ben Armstrong]

On Sun, 3 Aug 2008 13:53:54 +0200
Robert Millan <[EMAIL PROTECTED]> wrote:
> Lenny is Debian.  non-free is not part of Debian.  Check the Social Contract.

In light of the point of that follows this one, is it perhaps not too
far of a stretch to imagine that I understand this, and expected my
readers to understand this?

Ben


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

Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)

[Ben Armstrong]

On Sun, 3 Aug 2008 14:17:46 +0200
Robert Millan <[EMAIL PROTECTED]> wrote:
> I wonder what is it that we do wrong to spread this confusion so much that it
> affects even Debian developers themselves.
> 
> What is this to blame?  Would it be the FTP archive layout?  Perhaps having an
> unified BTS?
> 
> I'd be very interested in finding an answer to that question, and proposing a
> reform if we find something conclussive.

I'm speechless.


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

Re: Bits from the Debian Eee PC team, summer 2008

[Ben Armstrong]

As Robert Millan brought to my attention, in my enthusiasm to present
our progress towards fully Lenny support for the Eee in the best
possible light, my announcement muddied the distinction between Lenny
and non-free when I said that the earliest Eee models are now "fully
supported" in Lenny. I have corrected my blog article to make it clear
that full support will not be realized until we have ath5k. The new
first point of the article reads:

Earliest Eee models supported in Lenny

Lenny will release with the atl2 ethernet driver and the non-free
madwifi-source now works with the earliest Eee models as well, so our
patched version is no longer needed.  This means Lenny will work with
all of the earliest models of the Eee PC: 701 (2G and 4G surf, 4G, 8G)
and 900! All we need now for full support in Lenny is to replace the
non-free wireless driver with the free ath5k driver when it is ready.

Sorry for the confusion,
Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]


signature.asc
Description: PGP signature

Re: RFA: The Debian Jr. project

[Ben Armstrong]

On Mon, 25 Aug 2008 10:15:39 +0200
Holger Levsen <[EMAIL PROTECTED]> wrote:
> thanks for your work on Debian Jr. and for acknowledging that you don't have 
> time/a heart for it anymore!

Thanks.  It's hard to let go, but it's really for the best if someone
else will carry on.

> Is that vision written down somewhere?

It is probably best expressed on http://wiki.debian.org/DebianJr quoted
below:

Guiding Principles

We aim to help children and those who care for them to get the most use
and enjoyment out of their Debian systems; to help them acquire some of
the skills and experiences we have as adults; and to convey to them our
values: our love of freedom, our appreciation for software that works
well, and our strong sense of community.

That is to say, we do not aim to diminish or limit Debian to
"domesticate" it for little people, but to give them the best of what
Debian has to offer so they will grow to the point where they no longer
need our help.

Behind every child user of Debian, we assume there is at least one
older person who uses Debian and helps them with it: a guide, a mentor,
a parent, a relative, a friend. So these people are our users too. It
would be too easy to treat them as our primary audience. After all,
they are the ones reading this web page. They are the ones installing
and maintaining the system. However, they also have other places to get
support in the broader community of Debian and free software. In
thinking about where our energies should be focused, then, we place
children first and their guides second. 

> Because I often think, that Debian Jr. could be(come a) part of Debian Edu. 
> In 
> Etch Debian Edu came with one preconfigured desktop (which is KDE and rather 
> aimed at older students), but now we are in the process of merging with Linex 
> and they have used three (iirc) different gnome desktops (configurations), 
> one for 1st+2nd grade, one for 3rd+4th grade and another one for older 
> students. I'd say that Debian Jr fits in the 0th+1st grade "category" ;-)
> 
> What do you think?

While I would not have any problem with that if Edu cared for the
project and preserved the vision I described above, I have always
felt my own ideas for Jr had nothing to do with school and might indeed
by swallowed up by school concerns if we were an arm of the Debian Edu
project.  That is why I kept it a distinct project.  But we're in poor
shape right now, and the most important thing is that the project go
forward.  How would you propose the distinctiveness of Jr be kept?  How
do you think children would view Jr if it were an arm of the Edu
project?  In Debian Jr, our focus is the child and the fun of
discovery.  While some progressive educationists claim to hold to these
values, I worry about how kids would view the Jr project if it were
absorbed into Edu.

Ben


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

Re: Bug#498180: ITP: eee-applet -- A systray applet for Eee Pc

[Ben Armstrong]

On Mon, 08 Sep 2008 00:07:39 +0200
Julien Lavergne <[EMAIL PROTECTED]> wrote:
>   * Start or stop Wifi

I'm concerned about how this is implemented.  Does it play well with
eeepc-acpi-scripts?

>   * Control fan speed

I'd be interested to see that supported in a way that doesn't require
the unsupported eee.ko module.  I understand some patches
have been accepted to support fan control in eeepc_laptop.ko through
the sysfs interface, but there is no support for it in userspace yet,
and that further patches may be needed before it is.

>   * Overclock the processor

Not so much interested in this.  Since eee.ko is not in Debian (nor do
I see it ever entering Debian unless it is accepted upstream in
the kernel,) does the applet leave out that option if you don't have
eee.ko loaded?

Ben


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

Re: RFA: The Debian Jr. project

[Ben Armstrong]

On Tue, 30 Sep 2008 16:30:40 +0200
Holger Levsen <[EMAIL PROTECTED]> wrote:
> Yup. Has something happened on this in the last month?

Miriam Ruiz has some ideas, but since our initial contact on the
matter, I have not seen any action on them.

> Sounds good and compatible :)

OK ...

> That said, I dont see much of a problem here, or maybe rather, an easy way 
> out: Debian Edu provides two key features: customisation of the desktop for 
> pupils/schools and providing a network infrastructure for schools. Debian Jr. 
> doesnt need the latter at all (or? kindergarten network seems a bit far out 
> to me atm, maybe its not), but thats no issue, as Debian Edu also already has 
> standalone installs. 
> 
> And we even have different desktop profiles for standalone installs now: kde, 
> gnome and sugar. And I would love to extend this to "kde for primary school, 
> kde for middle classes, kde for high school and university" and the same with 
> gnome. And then also kde & gnome for kids.
> 
> I'd think this would boil down to provide a different installer image or 
> installation type with the existing image. So basically, a Debian Edu install 
> with "less overhead", which is not needed for a single^wstandalone kids 
> machine.

Well, technically, it appears things would work out.

> > How 
> > do you think children would view Jr if it were an arm of the Edu
> > project?  In Debian Jr, our focus is the child and the fun of
> > discovery.  While some progressive educationists claim to hold to these
> > values, I worry about how kids would view the Jr project if it were
> > absorbed into Edu.
> 
> Hm. Honestly, I have no idea how kids see Debian Jr. now, maybe I wonder if 
> they can see it, as currently afaik its "only" a packaging effort within 
> Debian, so I dont think it's visible to them. Do you agree? ;)

Probably.  But it doesn't stop me from wishing this were not so.  I
didn't want Debian Jr. to be *only* a packaging effort.  I wanted a
living, breathing relationship between children, their caretakers and
developers.  We've fallen far short of this lofty ideal, but that
doesn't mean it can't or shouldn't be kept alive.  That's the
distinctiveness that is at risk to be lost if we're just absorbed by
Debian Edu.

> Basically, to keep Debian Jr. distinct, I would suggest branding :)

Not a bad technical solution, as I said.  Let's just see what comes of
the alternate proposal by Miriam to have youth lead this project as a
group before going down that road, though.

Ben


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

Re: Bits from the Debian Eee PC team, autumn 2008

[Ben Armstrong]

On Tue, 14 Oct 2008 02:00:29 +0200
Matteo Croce <[EMAIL PROTECTED]> wrote:
> On Monday 13 October 2008 19:35:16 Ben Armstrong wrote:
> > Ath5k wifi works on Eee PC in Linux 2.6.27
> >
> >Jean-Christophe reports that [2]ath5k works in Linux 2.6.27 on
> >the Eee PC 701, and just needs a [3]small patch to work with our
> >eeepc-acpi-scripts package. This is good news for those of us with
> >models 701, 900, 900A and 1000HD who have been wanting to get off of
> >the non-free Madwifi drivers and onto DFSG free drivers.
> >
> 
> ath5k? aren't 901 and 1000HD 802.11n devices, so they are supported
> by the newer ath9k driver?

I think you're thinking of 1000H which is an N device.  1000HD is a
different model altogether b/g like the 701 and 900.  I know it's
confusing with Asus coming out with all of these new models.  Please
consult the table we drew up in our wiki summarizing the differences
between models we support or plan to support:

http://wiki.debian.org/DebianEeePC/Models

Besides, no Eee model that I know of uses an Atheros N chipset, so ath9k
will not work for them.  Models 901, 1000 and 1000H use Ralink rt2860,
as indicated in the table.  While the driver is GPL'd, unfortunately it
embeds a non-free firmware.  There is no 100% open source solution for
these devices yet.  I believe there is work in progress in
compat-wireless, but nothing that works yet.

Ben


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

rtl8187se for Eee PC 701SD (and MSI Wind)

[Ben Armstrong]

Eee PC Model 701SD uses the rtl8187se driver which is not in the kernel
upstream.  Ultimately, we want to use whatever is supported in the
kernel.  While there is some recent work on rtl8187 in
wireless-testing, we don't yet know if this works for the rtl8187se.
We'd be interested in hearing from anyone who has this hardware and
would like to help work towards a solution fully supported in the
kernel.  Checking out what's in wireless-testing would be a good place
to start.

Please see http://wiki.debian.org/DebianEeePC/Model/701SD for
our progress to date.  This uses source from Realtek instead of from
wireless-testing so is not our first choice.

Ben


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

Bug#452014: ITP: atl2-source -- Source for the Attansic L2 ethernet driver

[Ben Armstrong]

Package: wnpp
Severity: wishlist
Owner: Ben Armstrong <[EMAIL PROTECTED]>

* Package name: atl2-source
  Version : 1.0.40.2
  Upstream Author : xiong huang <[EMAIL PROTECTED]>
* URL : 
https://launchpad.net/ubuntu/hardy/+source/linux-ubuntu-modules-2.6.22/
* License : GPL
  Programming Lang: C
  Description : Source for the Attansic L2 ethernet driver

This is the driver for the Attansic/Atheros L2 which is present in
systems such as the Asus Eee PC.



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

Bug#565770: ITP: libterm-ansicolor-ruby -- Colors strings using ANSI escape sequences

[Ben Armstrong]

Package: wnpp
Severity: wishlist
Owner: Ben Armstrong 

* Package name: libterm-ansicolor-ruby
  Version : 1.0.4
  Upstream Author : Florian Frank  
* URL : http://flori.github.com/term-ansicolor/
* License : GPL
  Programming Lang: Ruby
  Description : Colors strings using ANSI escape sequences

Small Ruby library that colors strings using ANSI escape sequences.
It's possible to use constants or unary functions.  Block-forms
also autoreset at the block's end.  It's also possible to use this
module as a mixin for classes of objects that respond to :to_str,
e.g. String. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Mobile -- Debian GNU/Linux for mobile devices

[Ben Armstrong]

On 17/02/10 05:34 PM, Andreas Tille wrote:

I wonder whether we really need to "start" or whether we are able to
continue what just exist:  There is a Debian Eee PC project [1] which -
as far as I know - is not reduced to this specific hardware despite the
very specific name.
   


Actually, our project is limited to the Eee PC platform.  We don't even 
support similar systems by the same vendor like the Eee Box.  Although 
it might be possible to broaden the scope to encompass more hardware 
without killing the project, I have my doubts.  We've managed to stay 
cohesive, productive and relevant for the past two years using this 
approach and I'd be reluctant to do anything to upset the balance.


I also have my doubts about whether or not we even have similar goals.  
The Debian Eee PC project has one purpose only, to ensure that Debian 
works well on this hardware.  While other projects with an Eee focus 
want to write and support special applets to control the hardware or 
slap on a special UI, we're quietly working to ensure that the drivers 
work, are free, and any patches merged upstream to ensure that no matter 
how you make Debian *look* on an Eee, it will all just work.


While there may be a small amount of overlap, a portion of the user 
population who will find a "mobile OS" appealing, (and maybe my 
perception of how many people are interested in such a thing is skewed a 
bit because Debian simply doesn't offer anything like this at this time, 
driving people away from it and towards the alternatives,) I really 
can't see a whole lot in common between handheld device owners' needs 
and those of netbook owners.


In the end, a netbook is an inexpensive, smaller, but essentially -- a 
laptop, and that is not very different from a desktop system.  That is, 
it's a general purpose system.  It just also happens to be highly 
portable.  People with netbooks do similar things on them that they 
would do on their desktop systems.  They just do it on the go.  They 
don't need a radically different UI to make that happen.  Just using a 
familiar desktop or WM that they already use elsewhere and are 
comfortable with is usually the best approach.


When Asus entered the market with this system, they wanted it to look 
different, and they wanted to reach a different market.  Thus, they 
introduced it with a UI with big, friendly buttons more reminiscent of a 
PDA or cell phone than a conventional desktop.  That wasn't what caught 
my eye.  What excited me about the Eee was that here, at last, was a 
general purpose system that met both my usability and portability needs 
at once, and at a decent price.  Nothing more than that.  I didn't share 
whatever the Asus execs' vision was for this.  I get the sense that not 
many of the people who work with and enjoy the products of our project 
do either.


All of that being said, Debian Mobile sounds like a great idea, and I 
hope it is a resounding success.  And if it happens to work well on an 
Eee, too, then super!  It's always nice to have choices.


Ben


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7c96b5.3070...@sanctuary.nslug.ns.ca

Re: RFA: a lot of packages

[Ben Armstrong]

On 19/06/10 11:55 AM, Ola Lundqvist wrote:

Bug#586413: RFA: tightvnc -- virtual network computing server software
Bug#586414: RFA: vnc4 -- Virtual network computing server software
   


Although I cannot take on sole maintainership, I'm interested in the 
survival of the best VNC server and client in Debian.  If a team can be 
put together, I would be happy to contribute in what small ways I can.


What about eventual replacement by TigerVNC (http://tigervnc.org/), 
since upstream for that fork is actually active?


Ben


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1d0f40.9060...@sanctuary.nslug.ns.ca

Re: RFA: a lot of packages

[Ben Armstrong]

On 06/20/2010 10:20 AM, Angel Abad wrote:

Hi! Im interested in vnc packages too, I use these packages every day. I
havent upload rights, Im sure these packages are important for many
people, so its posible to make a group of intenerested DD and DM in
alioth for maintaintaining vnc related packages?
   


It appears Ola already created pkg-vnc some 7 years ago!

https://alioth.debian.org/projects/pkg-vnc/

All we need to do, then, is join the group and have Ola hand over 
administrative rights (which I'll volunteer to take on, unless he wants 
to continue in this capacity).


Ben


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1e1b94@sanctuary.nslug.ns.ca

Bug#594482: ITP: libsyntax-ruby -- A simple Ruby syntax highlighting library

[Ben Armstrong]

Package: wnpp
Severity: wishlist
Owner: Ben Armstrong 

* Package name: libsyntax-ruby
  Version : 1.0.0
  Upstream Author : Jamis Buck 
* URL : http://syntax.rubyforge.org/
* License : BSD
  Programming Lang: Ruby
  Description : A simple Ruby syntax highlighting library

This is a simple syntax highlighting library for Ruby. It is a naive syntax
analysis tool, meaning that it does not "understand" the syntaxes of the
languages it processes, but merely does some semi-intelligent pattern matching.

There are primarily two uses for the Syntax library:

# Convert text from a supported syntax to a supported highlight format (like 
HTML).
# Tokenize text in a supported syntax and process the tokens directly.

While there already exist other Ruby syntax highlighting libraries in Debian,
this one is a dependency of Cucumber, which I RFP'd (#565769) a while ago and
will shortly be converted to an ITP, if not by me then by a colleague.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100826105205.23934.30037.report...@lear.nslug.ns.ca

Re: Squeeze can't fit on 512MiB

[Ben Armstrong]

On 30/10/10 05:11 AM, Stefan Fritsch wrote:
> Is there an easy way to see what is in the tasks without reinstalling? 
> From /usr/share/tasksel/debian-tasks.desc it would seem that web-
> server only pulls apache2-mpm-prefork, and I have no idea how that 
> could account for this increase

$ tasksel --task-packages web-server
libapache2-mod-python
apache2-doc
libapache2-mod-php5
libapache2-mod-perl2
apache2-mpm-prefork
analog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ccbeb48.7040...@sanctuary.nslug.ns.ca

Re: Cedilla removed from sid, users complain

[Ben Armstrong]

On 01/25/2011 02:36 PM, Andrey Rahmatullin wrote:
> On Tue, Jan 25, 2011 at 07:14:39PM +0100, Juliusz Chroboczek wrote:
>> I'm upstream for Cedilla [1,2], which has been orphaned and removed from
>> Sid.  I'm receiving e-mail from Debian users of Cedilla, asking me what
>> is the suggested replacement.  What shall I answer?
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610903
> 

Also, there may be some possible alternatives in:

$ debtags search "use::converting && works-with::unicode &&
works-with-format::postscript"
gnome-u2ps - tool to convert UTF-8 text to PostScript
groff - GNU troff text-formatting system
groff-base - GNU troff text-formatting system (base system components)
halibut - yet another free document preparation system
paps - UTF-8 to PostScript converter using Pango


gnome-u2ps was already mentioned. paps perhaps, if you're allergic to gnome?

sadly, i got nowhere with "debtags related cedilla" so i had to resort
to hand-picking some relevant tags.

Ben


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d3f1bf6.1060...@sanctuary.nslug.ns.ca

Re: Cedilla removed from sid, users complain

[Ben Armstrong]

On 01/25/2011 03:09 PM, Juliusz Chroboczek wrote:
> Thanks to both of you -- I've forwarded your messages to my (soon-to-be
> former, sigh) users.

Minus the false hits from my search, I hope? My main point was to
illustrate debtags is a nice tool for finding related packages (some
time I'll try to figure out why 'related' didn't work for me, as that
would have been ideal).

Ben


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d3f2474.3080...@sanctuary.nslug.ns.ca

Re: gltron maintainer MIA

[Ben Armstrong]

Ari,

On Mon, Oct 13, 2003 at 02:17:43PM +1000, Martin Michlmayr wrote:
> * Ari Pollak <[EMAIL PROTECTED]> [2003-10-12 17:14]:
> > It seems that the Debian gltron maintainer, Gregory J. Oschwald, has
> > been MIA for at least a year now. I can't find him anywhere in the
> > developers DB, and haven't seen any recent mail activity at all on
> > either bugs or mailing lists. I'd like to hijack this
> 
> That's why the package was orphaned in April (Bug #190816).  Ben
> Armstrong wanted to adopt it, but obviously never did.  I assume you
> can just take it, but I'm copying Ben to this mail.

Be my guest.  I had no end of grief with it and gave up.  Also, my son 
*loves* gltron and will be very happy to see bugfixes and new releases.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Ben Armstrong]

On Fri, Dec 05, 2003 at 03:20:45AM -0600, cobaco <[EMAIL PROTECTED]> wrote:
> _ideally_ there are no changes. In practice there will be.

Why?

> For instance:
> In skolelinux there's currently a package called locale-config-skolelinux
> which sets up de default locale for all users. This package is not part of
> Debian. Instead there's some discussion with the relevant maintainer about
> merging locale-config-skolelinux, language-env,  and the different
> user-language packages, with the hope of eventually creating one package to
> set the default locale for both single users and the system as a whole.

Then that discussion needs to be resolved so that a solution can be made 
that is in Debian main.

I'm sorry, but I really have a hard time with this.  A Custom Debian
Distribution is nothing more than what is provided within Debian proper, as
Andreas said.  While a Debian subproject may consider and make use of stuff
in development that is outside of Debian while transitioning it to be "pure
Debian", the formal definition of CDD cannot include materials outside of
Debian main, otherwise it is not Debian, and cannot contain the name
"Debian" in its title.  Skolelinux, as you say, is a perfect example of
this.  Skolelinux is not a CDD.  It is a project in transition to becoming a
CDD.  As I understand it, Skolelinux is not entirely there yet, for the
reasons you have already mentioned.  It has its own history and its own 
needs which are for the moment unresolvable within Debian.  Furthermore, it 
does not contain 'Debian' in its title, so there is no confusion.  This is 
clearly a Debian-derivative, not a CDD.

> - -> while being a subset is the goal we have in mind, it's not always the
> actual situation. This is a consequence of
> 1. inertia in Debian, because of which getting things changed takes a while
> 2. the fact that some experimentation is often necessary to find the right
> solution, leading to non-optimal solutions that "get the job done" being
> used by the CDD in the meanwhile.

Sure, and that's what the 'experimental' ftp archive is for.

Now, I'm not saying that Debian derivatives shouldn't exist.  It is
important to acknowledge that they do, but at the same time work towards
eliminating, as much as possible, the need for their existence outside of
Debian main.  Not all reasons for being a derivative (or "Debian-based 
distribution") can be eliminated (such as the inclusion of non-free or 
contrib software).  However, I believe the reasons for Skolelinux not being 
a CDD can and will eventually be resolved.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Ben Armstrong]

On Fri, Dec 05, 2003 at 09:23:52AM -0600, cobaco <[EMAIL PROTECTED]> wrote:
> On 2003-12-05 11:06, Andreas Tille wrote:
> > Well, at least for my understanding SkoleLinux is not a "Custom Debian
> > Distribution" exactly because they have packages which are not integrated
> > in Debian.  This is no problem at all, but exactly here is the cruxial
> > point of our definition. In my talk about CDD in Oslo I suggested the
> > SkoleLinux people to take over the Debian-Edu ball because Raphael Herzog
> > announced that he was running out of time.  
> 
> in the process of happening actually

A move that I'm happy to see is happening.

> >Debian-Edu *is* a CDD because
> > it is completely inside Debian and 
> 
> hm, as far as I know Debian-edu is nothing more then a couple of 
> task-packages at this point (and some education packages that got added to 
> the archive)

Which doesn't change Andreas' point.  It may be a lame CDD, but it is still
a CDD. :)

> > the suggestion is that SkoleLinux
> > people patch the packages according to their needs.  
> 
> being done for Skolelinux, so basically you're saying that Skolelinux (or any 
> other project aiming to be a CDD) is not a CDD untill they get everything 
> they need back into Debian proper (which can take quite a while), even when 
> we're trying to do so (and always have)?

Again we trip across the distinction between organizational and technical
terms.  Skolelinux has not yet produced a CDD release (the technical term),
but it is a work-in-progress.  Organizationally, Skolelinux is a subproject
that is working to produce a CDD because that is its stated goal.

> >The *product* (one
> > bootable CD) which contains Debian-Edu plus some extra packages which are
> > necessary for whatever reason might be called SkoleLinux but this is not a
> > CDD per the definition I was using in my talk in Oslo.  There was nobody
> > who disagreed ...
> 
> hm, the definition I was using for a CDD would include Skolelinux because 
> while not everything we do is in Debian _yet_we are trying to get everything 
> included into Debian.

Sure, the work-in-progress is a CDD.  Existing releases, however, are not.

> the responses to my earlier messages 
> http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00457.html
> and
> http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00403.html
> would seem to indicate (at least to me) that this view was shared

I still have a problem with "whenever possible".  You seem to be reserving
the right to always include some material in releases of the CDD that is
outside of Debian.  You cannot call any release of Debian including material 
outside of Debian main "Official Debian".  That isn't just splitting hairs.  
That's how it is described here:

http://www.debian.org/CD/vendors/

Depending on whether you are talking about a CD of Skolelinux as a stable or
developer's release, it is either a "Vendor Release" or "Development
Snapshot" according to the descriptions on this page.

> The important point here is, IMHO, that 
> there is effort to get the missing pieces into Debian. Wether all pieces are 
> already in Debian at a given point in time is I think unimportant (for 
> defining a CDD anyways).

For defining a subproject working on a CDD, no.  But intent doesn't make any
difference to the end-user if release time rolls around and stuff outside of
Debian is still being included.  At this point, what the users have in their
hands is a distribution derived from Debian.  For example, if they find bugs
in any of the material outside of Debian, it must be dealt with outside of
the usual Debian structures (i.e. bts makes no provision for filing bugs
against packages that aren't actually in Debian).

Regards,
Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

[custom] Localized CD with pruned locale data

[Ben Armstrong]

CDDs may be tailored for a particular purpose, such as to distribute to a
small group where the locales of all users is known (or assumed).  In order
to include the maximum useful material per media it would be useful in such
cases to prune any unnecessary locale data provided by the included 
packages.  However, to do so would be to damage the packages that provide 
that data.

Is a CDD that is tailored in this fashion still "Debian"?  Take, for 
example, a package with missing locales that is used by a user who desires a 
different locale.  Such a user might be inclined to file a bug against the 
modified package, but the maintainer of the "buggy" package would probably 
not immediately recognize the cause of the problem, wasting their valuable
time.

Do mechanisms exist within Debian for providing such tailoring?  Should they 
exist?

Locales are only one example of "bloat"[0] that might be desirable to trim
for a CDD.  In general, how do we allow CDDs to be "pure Debian" and still
make efficient use of media space?

Ben Armstrong
[0] It almost goes without saying that one person's bloat is another 
person's valuable feature.  When you produce something for users
that don't need a resource-consuming feature, the feature is bloat.
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]