Re: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Sat, 23 Jul 2005 08:32:50 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]> 
said: 

> On Sat, 23 Jul 2005, Manoj Srivastava wrote:
>>> A 'normal' user doesn't know what C, C++ and Perl are.
>> 
>> The "user" I am creating packages for does.  I am not really that
>> interested in working for user who do not know the distinction,
>> personally speaking.

> So your "personal" target user might be able to find out the
> programming language himself and mentioning it in the description is
> also redundant.

I am the prime representative of my target user. I use
 aptitude; hit u to upgrade, look at the new package list, and try to
 decide which of these new packages to install. The information in the
 Description field is far from redundant here.

--> We found another reason to leave the language out of the
--> description.

If this is an example of the illogic governing the move to
 get useful information out of descriptions, to facour dumbing down
 and simplifying for users who seem to be confused by the littlelest
 things, I see no reason to favour the proposal.

If the proponents of this proposal are so desparate to stretch
 things in order to make up support for the proposal out of whole
 cloth, surely there must be something wrong with the proposal? Or
 else why are people being so shrill?

Indeed, this leap of illogic is disturbing in its own right.

manoj
-- 
"If a camel flies, no one laughs if it doesn't get very far." Paul
White
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: The BTS and bug subscriptions

[Florian Weimer]

* Jochen Voss:

> Hi Goswin,
>
> On Sat, Jul 23, 2005 at 01:55:19AM +0200, Goswin von Brederlow wrote:
>> subscribing [the initial submitter] is already the current way.

> Really?  Since when is this the case?

Just to stress Jochen's point: only closing a bug report automatically
triggers mail to the initial submitter, unless something has changed
very recently.  Developers must be careful to Cc: the submitters,
otherwise they probably never receive the message.


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

Re: The BTS and bug subscriptions

[Florian Weimer]

* Don Armstrong:

> No, it wouldn't. The messages are only sent to people after they have
> made it through the spam filters, and for sumitter, it's even more
> difficult, because the message must be formatted properly to actually
> generate a new bug instead of an error.
>
> The idea was for the submitter,[1] not random commenters to the bug,
> to receive this special treatment.

And this would be a very, very useful change.


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

Re: The BTS and bug subscriptions

[Petter Reinholdtsen]

[Florian Weimer]
> Developers must be careful to Cc: the submitters, otherwise they
> probably never receive the message.

What about the [EMAIL PROTECTED] address?  I thought it send
a message both to BTS and to the submitter?  I use it all the time
when I want the submitter to get the message.  I almost never CC to
the submitter.


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

Re: (no subject)

[Steve Langasek]

On Sat, Jul 23, 2005 at 01:00:03AM -0400, Ryan Schultz wrote:
> On Saturday 23 July 2005 12:07 am, [EMAIL PROTECTED] wrote:
> > can u please remove the call waves from my computer please Thnk you very 
> > much
> Hello Shorty550,
> This is debian-devel, a mailing list for developers of the Debian GNU/Linux 
> system, which doesn't relate to the Windows program Callwave in any way.
> Please see:

> http://www.mail-archive.com/debian-devel%40lists.debian.org/msg10770.html

> for instructions on removing Callwave from your computer

> ---
> For -devel... does anyone know why this list receives so many questions about 
> Callwave? A sample:

It receives questions about callwave because it has received questions about
callwave.  Stupidity on the Internet is remarkably self-perpetuating.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: The BTS and bug subscriptions

[Colin Watson]

On Sat, Jul 23, 2005 at 01:55:19AM +0200, Goswin von Brederlow wrote:
> Not subscribing the initial submitter would be insane and subscribing
> him is already the current way.

Not in the sense that's being discussed here, it isn't.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: libcrypto++ (Was: NMUs wanted: C++ library packages in need of uploading)

[Bastian Blank]

On Sat, Jul 23, 2005 at 01:33:28AM +0200, Jens Peter Secher wrote:
> GCC4 does definitely not like a mix of templates and anonymous enums
> [1,2] but there are easy fixes for this.

[1] clearly stats this as illegal according to the C++ standard.

> What is worse, it seems that GCC4 silently refuses to generate code for
> some template instantiations, which results in undefined symbols in the
> library, as others have experienced [3].  It might however be the case
> that GCC4, being more C++ standards compliant, has simply revealed a
> problem in the Crypto++ template code.

Explicit template instantiation is a gcc extension. Also [3] don't show
undefined symbols.

Bastian

-- 
"That unit is a woman."
"A mass of conflicting impulses."
-- Spock and Nomad, "The Changeling", stardate 3541.9


signature.asc
Description: Digital signature

Re: (no subject)

[Mowgli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Sa den 23. Jul 2005 um 10:32 schrieb Steve Langasek:
> It receives questions about callwave because it has received questions about
> callwave.  Stupidity on the Internet is remarkably self-perpetuating.

If the users are too silly to read and to think it has to shown then how
they can remove there Windows and use a proffesional supporter who
install them linux and give only the rigts to switch of the system. ;-)

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQuIPkp+OKpjRpO3lAQJgGwf+LREa8e82po/6EFfZgUHhhyhtSK0Xzl4P
QbtHg1+NmorY4sqfKjp9QWAlRnB2QXwDs/ncIAHgR5BSZBtG5gVDRhPCks/2XNZz
K2rN7wlPG+Qes/DRpzwQbtdqg10dRD7s/BGRLQx5Zp3swYhYXQos9Wko3xIebkQL
26W1s0sVMEOfMxdqEeiQaed7SE9X4Gm6JzUtQO/9q0SfU75ce+JWUCg0ofXmK/KQ
oPJzi6uLZ2u8kDO7B8rPyN7rboBNuJSz/p27RMG98li67clyRUPraoP+1STonMRI
gDt7dElLYwxgzGziqlCdf383B6GFoPiRrr8qntu/EZzug/9xxwl53g==
=o9Yq
-END PGP SIGNATURE-


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

ITP: darkplaces - greatly improved engine for original quake1

[Alexander Fieroch]

Package: wnpp
Severity: wishlist

URL: http://icculus.org/twilight/darkplaces/index.html
License: GPL

Description:

darkplaces is a greatly improved engine for quake1 with new advanced 
graphic effects.



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

Re: The BTS and bug subscriptions

[Florian Weimer]

* Petter Reinholdtsen:

> [Florian Weimer]
>> Developers must be careful to Cc: the submitters, otherwise they
>> probably never receive the message.
>
> What about the [EMAIL PROTECTED] address?

It's an alias for the email address of the submitter.  AFAICS,
messages to this address do not end up in the BTS.  But my point is
that you actually have to put this address in the Cc: field if you
send mail to the [EMAIL PROTECTED] address.


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

Re: The BTS and bug subscriptions

[Goswin von Brederlow]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Jochen Voss:
>
>> Hi Goswin,
>>
>> On Sat, Jul 23, 2005 at 01:55:19AM +0200, Goswin von Brederlow wrote:
>>> subscribing [the initial submitter] is already the current way.
>
>> Really?  Since when is this the case?
>
> Just to stress Jochen's point: only closing a bug report automatically
> triggers mail to the initial submitter, unless something has changed
> very recently.  Developers must be careful to Cc: the submitters,
> otherwise they probably never receive the message.

You are right, my bad. Only closing gets send out to the submitter.

And with that in mind I'm very much for subscribing the submitter
automatically. Half the time I forget to CC the submitter when I write
something to a bug and I guess many other people forget that when
commentating too.

There should be a pseudo header that reportbug can add if subscribtion
isn't automatic. When submitting a bug one can't mail nnn-subscribe as
the number isn't known yet but it would be nice to do both in one go.

MfG
Goswin

PS: sorry for doing a 180, I wasn't thinking clearly before.


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

Re: ITP: darkplaces - greatly improved engine for original quake1

[Neil McGovern]

On Sat, Jul 23, 2005 at 12:14:53PM +0200, Alexander Fieroch wrote:
> Package: wnpp
> Severity: wishlist
> 
> URL: http://icculus.org/twilight/darkplaces/index.html
> License: GPL
> 
> Description:
> 
> darkplaces is a greatly improved engine for quake1 with new advanced 
> graphic effects.
> 
> 

This really isn't enough information.

Could you include the following?:
--
  Package name: testpackage
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
  URL : http://www.example.org/
  License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : This is the short description

(Include the long description here.)
--

Regards,
Neil McGovern
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3


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

Re: The BTS and bug subscriptions

[Peter Samuelson]

[Don Armstrong]
> What has actually been discussed is automatically subscribing
> submitters to the bug report unless some special header/pseudo-header
> is added to prevent that.

Sounds good.  But since this information was already tracked, I figured
there must have been a (good?) reason this hasn't been done in the
past.  Not that I can think of one.


signature.asc
Description: Digital signature

Re: LinuxWorld in San Francisco

[Michael Meskes]

On Fri, Jul 22, 2005 at 03:37:07PM -0700, Don Armstrong wrote:
> No, it merely means that everyone was too lazy to respond.
> 
> The booth exists,[1] is being organized,[2] and there will actually be
> people there.[3]

Great. Looking forward to meet you guys.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: ITP: darkplaces - greatly improved engine for original quake1

[Jon Dowland]

On Sat, Jul 23, 2005 at 12:20:33PM +0100, Neil McGovern wrote:
> On Sat, Jul 23, 2005 at 12:14:53PM +0200, Alexander Fieroch wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > URL: http://icculus.org/twilight/darkplaces/index.html
> > License: GPL
> > 
> > Description:
> > 
> > darkplaces is a greatly improved engine for quake1 with new advanced 
> > graphic effects.
> > 
> > 
> 
> This really isn't enough information.

Agreed. Take a look at descriptions for other doom and quake engine
packages to see how it could be done. Here's a stab at a
description, based on the description for Quake2 and material from the
darkplaces webpage:

=
Description: improved version of id Software's Quake engine
 darkplaces is a greatly improved Quake engine, featuring much improved 
 bullet impacts, blood splatters, alpha blending and a custom openGL 
 renderer.
 .
 Quake is a 3D action game engine in first-person perspective, commonly
 known as a ``first person shooter''.
 .
 This package contains no data files. You will need to either install
 the commercial Quake data, or alternative free data files.
=

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: Keyboard lockup after X startup; possible cause

[Benjamin Mesing]

Hello,


> Several people probably faced the problem that after initial system bootup, 
> and startup of *dm, keyboard does not work.
> Suggested workaround was to add implicit 'vtX' parameter to X server 
> command line in Xservers file.
I don't use a diplay manager, but I face the same problem when starting
X manually (using "X -query server") for the first time. Starting a
second time works fine. Also is starting using startx. My workaround is
to startx first, close the local X session and run "X -query server"
afterwards.

Greetings Ben


-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

Re: congratulations to the X team!!

[Jaakko Niemi]

On Thu, 14 Jul 2005, David Nusinow wrote:
> On Thu, Jul 14, 2005 at 02:41:18PM +0300, Jaakko Niemi wrote:
> > On Thu, 14 Jul 2005, Sean Perry wrote:
> > > I just updated to X.org. With apt. Automatically. Woohoo!! I mean full 
> > > on xserver-xorg too. I did not touch ANYTHING.
> > 
> >  My only gripe is that the upload did not have pciids for
> >  radeon X700 etc.
> > 
> >  http://lists.debian.org/debian-x/2005/06/msg00179.html
> > 
> >  Now I'm pondering between sending a patch and trusting 
> >  people to check their TODO lists :=)
> 
> Patches are most assuredly welcome :-)

 I took a diff against current upstream and ended up with 
 same content with ati driver as with the diff that was
 removed.
 
 Took me less than two minutes to look up the exact upstream
 revision in which changes against xf86PciInfo.h for example
 were made:

 
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h?r1=1.5&r2=1.6
 
 Is there something I'm missing here?

--j


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

Re: The BTS and bug subscriptions

[Michelle Konzack]

Hello Don,

Am 2005-07-22 15:30:35, schrieb Don Armstrong:

> What has actually been discussed is automatically subscribing
> submitters to the bug report unless some special header/pseudo-header
> is added to prevent that. [It's possible that this subscription would
> happen without even needing to confirm the subscription... but that's
> still undecided.]

But what abourt people which are subscribed to packages like me ?
Do they get the messages twice ?
I think, the BTS should prevent sending messages twice.

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

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: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Sat, 23 Jul 2005 10:58:34 -0300, Ben Armstrong <[EMAIL PROTECTED]> said: 

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

Not quite. I meant to target my irritation at one respondent,
 who took my mail about current inability to leverage debtags while
 selecting packages, and without addressing my objection, tried a
 jejune stretching of the statement to pretned I had provided
 additional support for the proposal, rather than pointing to
 something that needs to be put into place.

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

Indeed, I like the proposal, and in time it would probably
 make the package selection mechanism easier (perhaps scroing debtag
 attributes by individual preference to help sort through new or
 alternate package choices).

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

Then I have indeed misread what we were leading to.  If we are
 not talking about running through current descriptions and excising
 such language from the description, then I am not sure what the
 discussion is about, and my objections are likely to be moot.

> 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 am all for providing information to users to help them
 select packages. I am not, however, much in favour of displaying bias
 for one class of users over others; so while I'll entertain ideas
 about how to improve my package descriptions to help novice user also
 get information relevant to their selection criteria, I am opposed to
 removing information relevant to some users on the grounds that that
 information is not required  for the selection criteria of the so
 called "target users".

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

This is where I have misgivings. What is a "typical user"?
 What if we are wrong about "typical users"? What if the audience for
 a package changes over time? Why should we discriminate against users
 who do not fit our model of "typical" and "approved" users by
 withholding information from the description that they require for
 their selection criteria?

I am all for giving people options, and information, to help
 select between the options, or packages. I am not so much in favour
 of curtailing information that some users use foir the selection just
 because they do not fit my definition of the "right" kind of user.

manoj
-- 
Home on the Range was originally written in beef-flat.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: congratulations to the X team!!

[David Nusinow]

On Sat, Jul 23, 2005 at 02:53:42PM +0300, Jaakko Niemi wrote:
> On Thu, 14 Jul 2005, David Nusinow wrote:
> > On Thu, Jul 14, 2005 at 02:41:18PM +0300, Jaakko Niemi wrote:
> > > On Thu, 14 Jul 2005, Sean Perry wrote:
> > > > I just updated to X.org. With apt. Automatically. Woohoo!! I mean full 
> > > > on xserver-xorg too. I did not touch ANYTHING.
> > > 
> > >  My only gripe is that the upload did not have pciids for
> > >  radeon X700 etc.
> > > 
> > >  http://lists.debian.org/debian-x/2005/06/msg00179.html
> > > 
> > >  Now I'm pondering between sending a patch and trusting 
> > >  people to check their TODO lists :=)
> > 
> > Patches are most assuredly welcome :-)
> 
>  I took a diff against current upstream and ended up with 
>  same content with ati driver as with the diff that was
>  removed.
>  
>  Took me less than two minutes to look up the exact upstream
>  revision in which changes against xf86PciInfo.h for example
>  were made:
> 
>  
> http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h?r1=1.5&r2=1.6
>  
>  Is there something I'm missing here?

I already applied a patch reported by Harald Welte to incorporate the X700
PCI ID's. This was uploaded in the -4 revision of the Debian packages a few
days ago.

 - David Nusinow


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

Re: Usability: Technical details in package descriptions?

[Lionel Elie Mamane]

On Sat, Jul 23, 2005 at 01:30:24AM -0500, Manoj Srivastava wrote:
> On Thu, 21 Jul 2005 12:33:32 -0300, Ben Armstrong <[EMAIL PROTECTED]> said: 

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

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

> I also select a program based on languages I know; since it
>  makes it more likely that I can tweak the program rto my needs, or
>  help with stalled development.

And this is one of the central points behind free software after all:
the freedom, both legal and practical, to do exactly that.

That in the current times most people are technically unable to do
that is just an unfortunate temporary situation to me, that comes from
a conjunction of factors like youth of the field, that the programming
language of choice still changes way too often (probably linked to
"youth of the field"), etc. Our (grand-)^n parents' generation got to
the point of a society where *everyone*, or nearly, can read and
write. So I don't see why our (grand-)^n children's generation cannot
get to the point of a society where everyone can program. Not everyone
has to be a Don Knuth, of course. Just like not everyone is a
Shakespeare today.

I like to see the Free Software movement as a precursor in this
direction. And Debian as a spearhead of the Free Software movement,
not merely a provider of prepackaged goods.

-- 
Lionel


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

libapt-pkg-libc6.3-5-3.3

[Dan From]

Hey there.

I want to install libapt-pkg-libc6.3-5-3.3 but it says that it is virtual file.
I want to install it because i want to install apt-move, so i can
install dfsbuild, so i can make a live cd, just for my needs.
But i cant find it any where, and i saw (see, im dainish :) ) that i
should write a mail to you.
Is this something you can help me with.

Dan From

Re: libapt-pkg-libc6.3-5-3.3

[Goswin von Brederlow]

Dan From <[EMAIL PROTECTED]> writes:

> Hey there.
>
> I want to install libapt-pkg-libc6.3-5-3.3 but it says that it is virtual 
> file.
> I want to install it because i want to install apt-move, so i can
> install dfsbuild, so i can make a live cd, just for my needs.
> But i cant find it any where, and i saw (see, im dainish :) ) that i
> should write a mail to you.
> Is this something you can help me with.
>
> Dan From

Welcome to the c++ transition.

Try stable.

MfG
Goswin


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

Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)

[Jon Dowland]

I've added the original ITPer to the CC list, as he hasn't contributed
to this thread (and so I don't know if he reads -devel). 

Alexander, your ITP has generated a bit of discussion: see
.

On Sat, Jul 23, 2005 at 03:08:06PM +1000, Jamie Jones wrote:
> After sleeping on it, yes hijack does seem a bit strong, but after a bad
> day, then downloading my mail to see an ITP on a package that has been
> kept out for a reason, I felt rather unhappy.

I can certainly appreciate that.

> Doomsday (or Deng as upstream and I refer to it) is the cleanest
> implementation in regards separation of the different game logic and
> features. The plugins are basically .so files, so if you want to play
> doom, you load the jdoom plugin, you want hexen, you load the jhexen
> plugin.

That's true. The heretic/hexen licence terms are so strict as to make
even this dodgy, but if the code was excluded from Debian, it wouldn't
be Debian's problem. I expect this confusion would have been avoided if
the upstream author didn't classify the entirety of the code as GPL in
sourceforge.net.

> The problem with legacy and the other ports mentioned is that this logic
> wasn't separated so that they could function without the raven code. 

Yes I know :( I've tried to persuade the upstream maintainers but it has
unfortunately been to no avail. The legacy maintainers are some of the
most polite, however: I received some pretty angry mail from some of the
others.

> The biggest problem is that many new wads (game levels) support hexen
> features in a doom wad (I believe that they call this zdoom format).
> By supporting zdoom format and not using a plugin they then fail the
> DFSG test with regards to the raven code.

I only know of Zdoom that uses this different WAD structure (maybe
vavoom does too, not too familiar with that port). However, zdoom
implemented that *before* the heretic/hexen source code release. Despite
this, I think that there is no interest in relicencing under the GPL in
the zdoom camp.

> Deng doesn't even support Boom format (an extension to the GPL Doom
> wad format) that was the cause for a fork some time ago.

Yup Risen3D - which is closed source :-( I understand that there is work
on putting boom support into Jdoom now - about time! (as an upstream
author of freedoom, I've had to field many questions about jdoom and
boom over the years)

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: (no subject)

[Daniel Burrows]

On Friday 22 July 2005 10:00 pm, Ryan Schultz wrote:
> For -devel... does anyone know why this list receives so many questions
> about [REDACTED]?
>
> [long list of links into -devel archives]

  Because you just told Google that we're a good source for information about 
you-know-what :P.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
| "This is too absurd!  The world can't end this stupidly!" |
| "Oh, sure it can.  Have some faith."  |
|   -- Fluble   |
\ The Turtle Moves! -- http://www.lspace.org ---/


pgpkDup4qqzY9.pgp
Description: PGP signature

Re: (no subject)

[Ryan Schultz]

On Saturday 23 July 2005 02:16 pm, Daniel Burrows wrote:
> On Friday 22 July 2005 10:00 pm, Ryan Schultz wrote:
> > For -devel... does anyone know why this list receives so many questions
> > about [REDACTED]?
> >
> > [long list of links into -devel archives]
>
>   Because you just told Google that we're a good source for information
> about you-know-what :P.
>
>   Daniel

Ah... crap. Well, perhaps this will secure me a future job in SEO :- D

-- 
Ryan Schultz
-> floating point exception: divide by cucumber


pgpef3UZMC8wD.pgp
Description: PGP signature

Re: The BTS and bug subscriptions

[Kurt Roeckx]

On Fri, Jul 22, 2005 at 06:11:14PM +1000, Pascal Hakim wrote:
> 
> It is now possible to subscribe and unsubscribe from individual bugs in
> the Bug Tracking System. To do so, simply send an email to
> [EMAIL PROTECTED], or [EMAIL PROTECTED], where
> nnn is the bug number you wish to {,un}subscribe to. You will then need to
> reply to the confirmation email for the action to take effect.

I would like that I don't have to confirm each time I subscribe
to a bug.  Could there be some list added so that you don't need
to confirm your subscription?


Kurt


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

ITP: pycocuma -- Pythonic Contact and Customer Management

[Christoph Berg]

Package: wnpp
Severity: wishlist

* Package name: pycocuma
  Version : 0.4.5-5
  Upstream Author : Henning Jacobs <[EMAIL PROTECTED]>
* URL : http://www.srcco.de/pycocuma/index.html
* License : GPL v2 or later
  Description : Pythonic Contact and Customer Management

 PyCoCuMa (Pythonic Contact and Customer Management) provides a personal
 information system for addresses, telephone numbers and other data associated
 with personal contacts (also supports photographic pictures).
 .
 PyCoCuMa is purely written in Python with a Tk graphical interface. PyCoCuMa
 is based on an XML-RPC client-server architecture. The server stores its data
 in compatible vCard (ver. 3.0) files (*.vcf) which can be read by all modern
 address programs (Evolution, KAddressbook, Outlook, GnomeCard, etc).

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: The BTS and bug subscriptions

[Goswin von Brederlow]

Kurt Roeckx <[EMAIL PROTECTED]> writes:

> On Fri, Jul 22, 2005 at 06:11:14PM +1000, Pascal Hakim wrote:
>> 
>> It is now possible to subscribe and unsubscribe from individual bugs in
>> the Bug Tracking System. To do so, simply send an email to
>> [EMAIL PROTECTED], or [EMAIL PROTECTED], where
>> nnn is the bug number you wish to {,un}subscribe to. You will then need to
>> reply to the confirmation email for the action to take effect.
>
> I would like that I don't have to confirm each time I subscribe
> to a bug.  Could there be some list added so that you don't need
> to confirm your subscription?
>
>
> Kurt

As in once you confirmed one subscription the next one doesn't ask
anymore? Sort of greylisting?

Sounds good.

MfG
Goswin


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

Re: Keyboard lockup after X startup; possible cause

[Enrico Zini]

On Sat, Jul 23, 2005 at 01:50:10AM +0400, Nikita V. Youshchenko wrote:

I had the same bug.  It used to happen when you changed inittab to use
more than 6 VCs, I had no idea it could race even on lower VCs.

> I don't know which is the correct way to fix it.
> Possible ways:
> 
> *) ensure that X is never started on vt on which getty is going to be 
> started - in this case, having default Xservers files to set explicit vtN 
> is enough, and kdm 3.4 should provide some way to ensure that it will not 
> choose vt on which getty will be started later,

Defining the vtN explicitly makes sense, especially as we seem to have
standardised on having X running on vc7.  People who change inittab to
allocate vc7 for something else, should also change the display manager.
A comment in the default inittab reminding of the issue could also help.

> *) debian should not treat *dm like other services, and start it after 
> getty's, not before them

I recommend against this one, as there's been quite some talking about
invoking *dm earlier in the boot process, to speed up getting to the
working environment.

> *) some other way?

What would be required for getty and X to allocate the vc without
messing each other up?  The cleaner solution (to me) would be to have
getty not run if X is using the vc, or X running on another vc if getty
is using it; but I reckon it might not be technically possible, at least
judging from the past discussions on bug#116747, bug#47451 and bug#165241,


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Please participate in popularity-contest

[Petter Reinholdtsen]

Please help the install team and others get a better view on the use
of packages in Debian.  To do this, install the popularity-contest
package and say yes to participate.

The results are updated daily on http://popcon.debian.org/>, and
the information is used to make the Debian CDs, to give developers an
idea of the use of their packages, and the project an idea on the use
of the different architectures.

At the moment, this is the relative ordering of architectures
reporting to popularity-contest.  I would love to see more machines
reporting in.

1   0.02% m68k
1   0.02% hurd-i386
1   0.02% ppc64
2   0.03% kfreebsd-i386
3   0.05% mipsel
4   0.07% arm
4   0.07% s390
8   0.13% mips
   16   0.27% ia64
   24   0.40% hppa
   33   0.56% alpha
   72   1.21% sparc
   98   1.65% powerpc
  279   4.69% amd64
 5398  90.81% i386
 5944 100.00% total (ignored 620 without arch info)

New in version 1.30 is support for reporting using HTTP POST, to make
it possible for machines without working MTA to participate as well.

Please direct any questions to popcon-developers at lists.alioth.debian.org.

Friendly,
-- 
Petter Reinholdtsen


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

Re: (no subject)

[Manoj Srivastava]

On Sat, 23 Jul 2005 11:16:08 -0700, Daniel Burrows <[EMAIL PROTECTED]> said: 

> On Friday 22 July 2005 10:00 pm, Ryan Schultz wrote:
>> For -devel... does anyone know why this list receives so many
>> questions about [REDACTED]?
>> 
>> [long list of links into -devel archives]

>   Because you just told Google that we're a good source for
>   information about
> you-know-what :P.

We know everything that can be known about Voldemort?

manoj
-- 
Graduate students and most professors are no smarter than
undergrads. They're just older.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: libcrypto++ (Was: NMUs wanted: C++ library packages in need of uploading)

[Nathanael Nerode]

[EMAIL PROTECTED] wrote:
> I am fighting with libcrypto++ but so far I am loosing.

This is an exceedingly nasty library.  There is way too much templatization in 
this library, and GCC spews warnings like there's no tomorrow.

I'd be interested in working on tracking down the linking problems, but I 
don't want to duplicate your work.  Are your patches-so-far available 
somewhere?


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

Re: doomsday not DFSG

[Jamie Jones]

On Sat, 2005-07-23 at 18:31 +0100, Jon Dowland wrote:



> > Doomsday (or Deng as upstream and I refer to it) is the cleanest
> > implementation in regards separation of the different game logic and
> > features. The plugins are basically .so files, so if you want to play
> > doom, you load the jdoom plugin, you want hexen, you load the jhexen
> > plugin.
> 
> That's true. The heretic/hexen licence terms are so strict as to make
> even this dodgy, but if the code was excluded from Debian, it wouldn't
> be Debian's problem. I expect this confusion would have been avoided if
> the upstream author didn't classify the entirety of the code as GPL in
> sourceforge.net.

True. I have raised this with upstream in the past and they are aware of
the issue. We would prefer to include it with full functionality, but
with the current codebase it is impossible. Upstream has stated that
with the current code it would be more trouble then it is worth to redo
the hexen plugin without the raven code, especially as the current
codebase is more of a prototype to them of what they want their version
2 engine to be. I'm sure though, that if someone had patches they would
be happy to include it.

> 
> > The problem with legacy and the other ports mentioned is that this logic
> > wasn't separated so that they could function without the raven code. 
> 
> Yes I know :( I've tried to persuade the upstream maintainers but it has
> unfortunately been to no avail. The legacy maintainers are some of the
> most polite, however: I received some pretty angry mail from some of the
> others.

Sadly that is the case, part of the reason I ended up doing Deng, was
that upstream was much more approachable about these sorts of things.

> 
> > The biggest problem is that many new wads (game levels) support hexen
> > features in a doom wad (I believe that they call this zdoom format).
> > By supporting zdoom format and not using a plugin they then fail the
> > DFSG test with regards to the raven code.
> 
> I only know of Zdoom that uses this different WAD structure (maybe
> vavoom does too, not too familiar with that port). However, zdoom
> implemented that *before* the heretic/hexen source code release. Despite
> this, I think that there is no interest in relicencing under the GPL in
> the zdoom camp.

Really, Zdoom did that before the hexen release ? As I understand it, I
thought Zdoom format was basically hexen in a doom container.

> 
> > Deng doesn't even support Boom format (an extension to the GPL Doom
> > wad format) that was the cause for a fork some time ago.
> 
> Yup Risen3D - which is closed source :-( I understand that there is work
> on putting boom support into Jdoom now - about time! (as an upstream
> author of freedoom, I've had to field many questions about jdoom and
> boom over the years)
> 

Yeah, Skyjake has given DaniJ CVS access, and now DaniJ is working on
some Boom stuff. I'm looking forward to the freedoom support myself, as
it's something I'd like to play. Every time they release something, I
happily break it in new and exiting ways (I already broke it on amd64, I
just wish I could put it through all of Debian's arches to see what it
breaks on)

-- 
GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments
PGP Key ID 0x4B6E7209
Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209


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

Re: libcrypto++

[Florian Weimer]

* Nathanael Nerode:

> I'd be interested in working on tracking down the linking problems, but I 
> don't want to duplicate your work.  Are your patches-so-far available 
> somewhere?

I think I've found the linking bug.  Details later.


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