Re: binary NMUs and version numbers

[Anthony Towns]

Goswin von Brederlow wrote:
1.rc << 1.rc2 << 1.rc+b1
1.2-1~beta << 1.2-1~beta2 << 1.2-1~beta+b1
1.2~beta-1 << 1.2~beta-1+b1 << 1.2~beta2-1
Keeping the Debian revision simple is a Good Thing.
Adding the implicit '0' that dpkg assumes on versions ending in alpha
chars would solve both cases:
That'd mean REJECTing uploads whose versions match "[^0-9]+[a-z][0-9]+$" 
presumably.

Another case that should be considered is the existing use of + for
revisions of a cvs snapshot (e.g. mutt uses a + but always does so): 
1.2-20041208 "<<" 1.2-20041208+2 "<<" 1.2-20041208+b1
Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the 
upstream version? Or "1.2-20041208-1", or "1.2+cvs20041208-1" or whatever.

-rw-rw-r--   16 katiedebadmin  2908273 May  2  2004
  pool/main/m/mutt/mutt_1.5.6.orig.tar.gz
-rw-rw-r--   16 katiedebadmin   412082 Nov 17 10:17
  pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz
It seems to result in rather large diffs, and I can't really see the 
benefit?

There are 3 simple solutions to this:
1. forbid + in debian versions and think of another character instead
   doing the same (must be < '.')
Actually, that doesn't work either -- otherwise a new maintainer version 
(x-y#1) compares less than an old NMU (x-y.1). For the same reason "= ." 
doesn't work.

Cheers,
aj

Re: Linux Core Consortium

[Bruce Perens]

Steve Langasek wrote:


  Changing library *names*, OTOH, is something quite different -- and in the
first case, providing "compatibility with the old names" totally defeats the
purpose of *having* sonames, whereas in the second case, it still sounds
like gratuitous change to me.
  

Steve,

I am not yet aware of the magnatude of the problem. Neither does Ian
Murdock, we discussed it. We'd have to work with these guys a while to
figure it out. It might end up being a non-issue, or a small number of
packages.

Off the top of my head, if I had to provide two sonames from one
library, I'd make a stub library that chained to the other name. No
doubt we could cook up a shell command to produce these as necessary,
perhaps as part of the debhelper package. We'd live with them for a
while and then flush them, as we lived with a.out for quite a while
without much pain.

  being bound not just to an external *standard*, but to an external
*implementation* requires sacrificing autonomy in areas that have been
historically important to Debian, such as timely security fixes and
arch-specific fixes for architectures not covered by the LCC

Nothing says that we can not produce our own versions of libraries when
necessary. I doubt that any distribution is really giving up that
capability, and security fixes that are issued but still in the process
of being merged into LCC should not invalidate one's certification. I
would think that LCC folks might appreciate the help in fixing security
bugs on a timely basis. Indeed, I am not so arrogant as to believe that
we will always be the first to fix them. Maybe we can use their
help.

It sounds to me as if we'd be the lead for multi-architecture stuff,
nobody else does it to the extent that we do.

  Can you provide pointers to concrete LCC proposals of library
renames, so that I can get comfortable with the technical specifics of
what's really at issue here?

They don't exist yet. If we work on this now, we get to make sure we'll
be comfortable with them.

    Thanks

    Bruce




smime.p7s
Description: S/MIME Cryptographic Signature

Re: dselect survey

[Blunt Jackson]

On Wed, 8 Dec 2004 19:32:35 -0800, Brian Nelson <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 08, 2004 at 10:23:16PM -0500, Mason Loring Bliss wrote:
> > Maybe I'm still waiting for my first real problem to show up, but I
> > generally find dselect to be a real pleasure to use.
> >
> > Could you present an example of a problem you had with dselect? Honestly,
> > I wouldn't be using Debian today if not for dselect, which I see as being
> > a really nice selling point.
> 
> If you really want to find out, go ask on debian-user.  You'll find
> plenty of people more than willing to piss all over dselect.

Hi, I'm mostly a user, and just lurking on the lists to get a feel for
whether I want to
become a developer or not, but on this topic I will observe that the
dselect interface is
very cumbersome and non-intuitive until you get used to it. Having
"enter" exit the
selection process (rather than simply selecting the entry) is
perennially surprising,
and if I ake the tragic mistake of hitting enter twice based on the
muscle memory
of some other application, I find I may have already taken actions I
wasn't quite ready
to take. Selecting packages, and their dependencies, can be confusing.
In general,
for safety and for confidence, I prefer to apt-get exactly the package
and its dependencies
that I have researched through the web interface.

I have done something terrible to one system: which was a stable
distribution. For a
project, I needed to obtain a package versioned in the unstable
distribution. I foolishly
thought I could simply change the settings for dselect to grab that
one package, but
now dselect thinks it needs to change the package version of just
about every package
on my system, and I am reasonably sure letting it make that change
will irreparably
damage the system. So, until I deprecate that machine and rebuild it
from scratch,
I don't use debian tools on it at all any more. I presume there is a
better way to grab
a single package (and its dependencies) if one needs a different
version than is available
in "stable". I am sure there are other ways to damage a system using
dselect, but my
main gripes are interface: having to scroll or search through
thousands of rather garbagy  ackages to find what I want is just
useless, the moreso if I don't know the exact package
name. The web interface to finding packages is a zillion times better,
and apt-get is
simple and safe. (If I can apt-get a package versioned outside my
overall distribution,
that would be perfect.)

-bluejack

-- 
-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-

Re: Status of this ITP?

[Ron Johnson]

On Wed, 2004-12-08 at 19:36 -0800, Brian Nelson wrote:
> On Wed, Dec 08, 2004 at 09:26:00PM -0600, Ron Johnson wrote:
> > On Wed, 2004-12-08 at 11:30 -0600, Steve Greenland wrote:
> > > On 08-Dec-04, 11:15 (CST), "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote: 
> > [snip]
> > > > Get off your ass.
> > > 
> > > Ah. I see. Courtesy is not your strong point.
> > 
> > His parents must not have taught him manners.  Or he knows that
> > he can't get beat up by people who don't see him face-to-face.
> 
> Here, go find him:
> 
> http://www.acs.rutgers.edu/directory/

He's half-way across the continent.  Not worth the effort to fly
over there and tell him he's a rude twerp.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Experience should teach us to be most on our guard to protect
liberty when the Government's purposes are beneficent. Men born
to freedom are naturally alert to repel invasion of their liberty
by evil-minded rulers. The greatest dangers to liberty lurk in
insidious encroachment by men of zeal, well-meaning, but without
understanding."
Justice Louis Brandeis, dissenting, Olmstead v US (1928)



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

Re: Linux Core Consortium

[Ron Johnson]

On Wed, 2004-12-08 at 17:41 -0800, Steve Langasek wrote:
> Bruce,
> 
> On Wed, Dec 08, 2004 at 04:49:13PM -0800, Bruce Perens wrote:
[snip]
> 
> I'm skeptical to begin with of the benefits LCC has to offer Debian -- being
> bound not just to an external *standard*, but to an external
> *implementation* requires sacrificing autonomy in areas that have been
> historically important to Debian, such as timely security fixes and
> arch-specific fixes for architectures not covered by the LCC -- and the
> wording from your original message set off a very large red flag for me
> besides.  Can you provide pointers to concrete LCC proposals of library
> renames, so that I can get comfortable with the technical specifics of
> what's really at issue here?

You are way overreacting.

Reread this, the last paragraph of BP's OP, a few times.
  "I would not suggest that Debian commit to using LCC packages 
  at this time. We should participate for a while and see how many
  changes we'd have to make and whether the project works for us. 
  But I think we should be at the table and in a position to in-
  fluence the project. The other members are willing to have us 
  on those terms."

Note the part about "I would not suggest that Debian commit to 
using LCC packages at this time."  If Debian decides that it would
not be in Debian's best interest to follow the LCC implementation,
then guess what: it doesn't have to...

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"What other evidence do you have that they are terrorists, other
than that they trained in these camps?"
17-Sep-2002 Katie Couric to an FBI agent regarding the 5 men
arrested near Buffalo NY



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

Re: Status of this ITP?

[Brian Nelson]

On Wed, Dec 08, 2004 at 09:26:00PM -0600, Ron Johnson wrote:
> On Wed, 2004-12-08 at 11:30 -0600, Steve Greenland wrote:
> > On 08-Dec-04, 11:15 (CST), "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote: 
> [snip]
> > > Get off your ass.
> > 
> > Ah. I see. Courtesy is not your strong point.
> 
> His parents must not have taught him manners.  Or he knows that
> he can't get beat up by people who don't see him face-to-face.

Here, go find him:

http://www.acs.rutgers.edu/directory/

:p

-- 
For every sprinkle I find, I shall kill you!

Re: dselect survey

[Brian Nelson]

On Wed, Dec 08, 2004 at 10:23:16PM -0500, Mason Loring Bliss wrote:
> On Thu, Dec 09, 2004 at 11:11:31AM +0900, Miles Bader wrote:
> 
> > I used dselect a lot back in the day (I don't know, like up until 2000
> > or so?).  It had a clunky but useable interface (though I fully
> > understand how newbies could get frustrated), and generally worked all
> > right until there was a problem;
> 
> Maybe I'm still waiting for my first real problem to show up, but I
> generally find dselect to be a real pleasure to use.
> 
> Could you present an example of a problem you had with dselect? Honestly,
> I wouldn't be using Debian today if not for dselect, which I see as being
> a really nice selling point.

If you really want to find out, go ask on debian-user.  You'll find
plenty of people more than willing to piss all over dselect.

-- 
For every sprinkle I find, I shall kill you!

Re: Status of this ITP?

[Ron Johnson]

On Wed, 2004-12-08 at 11:30 -0600, Steve Greenland wrote:
> On 08-Dec-04, 11:15 (CST), "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote: 
[snip]
> > Get off your ass.
> 
> Ah. I see. Courtesy is not your strong point.

His parents must not have taught him manners.  Or he knows that
he can't get beat up by people who don't see him face-to-face.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

An ad run by the NEA (the US's biggest public school TEACHERS
UNION) in the Spring and Summer of 2003 asks a teenager if he can
find sodium and *chloride* in the periodic table of the elements.
And they wonder why people think public schools suck...



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

Re: dselect survey

[Mason Loring Bliss]

On Thu, Dec 09, 2004 at 11:11:31AM +0900, Miles Bader wrote:

> I used dselect a lot back in the day (I don't know, like up until 2000
> or so?).  It had a clunky but useable interface (though I fully
> understand how newbies could get frustrated), and generally worked all
> right until there was a problem;

Maybe I'm still waiting for my first real problem to show up, but I
generally find dselect to be a real pleasure to use.

Could you present an example of a problem you had with dselect? Honestly,
I wouldn't be using Debian today if not for dselect, which I see as being
a really nice selling point.

-- 
 Mason Loring Bliss [EMAIL PROTECTED]http://blisses.org/  
"I am a brother of jackals, and a companion of ostriches."  (Job 30 : 29)


pgpB9eZLWhVyr.pgp
Description: PGP signature

Re: murphy is listed on spamcop

[Miles Bader]

paddy <[EMAIL PROTECTED]> writes:
> In which case, is there something fundamentally broken about the spamcop
> system ?  Or is there some technically insoluble problem here ?

It seems to be more that they just don't really give a crap:

  (1) they trust users, (2) users are stupid, and (3) there's no apparent
  attempt to compensate for (2), despite a long history of problems.

It's clearly a very bad idea to use their blacklist for anything except
a vague hint, but many ISPs _do_ use it as a hard blacklist.  I've had
experiences where complaining to the ISP just resulted in replies like
"Ha ha ha!  You suck!  I won't change!" so it would be really nice if
spamcop themselves could be a bit more responsible.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: SVG icons

[Ron Johnson]

On Thu, 2004-12-09 at 11:55 +0900, Mike Hommey wrote:
> On Wed, Dec 08, 2004 at 11:49:49PM +0100, Bill Allombert <[EMAIL PROTECTED]> 
> wrote:
> > The authoritative document is the menu _manual_:
> > (/usr/share/doc/menu/menu.txt.gz), section 3.7
> > 
> > An extract from that section:
> > 
> >  Debian package maintainers should ensure that any icons they include
> >  for use in the Debian menus conform to the following points:
> > 
> >  1.   The icons should be in xpm format.
> > 
> >  2.   The icons may not be larger than 32x32 pixels, although smaller
> >   sizes are ok.
> 
> Note that's a "may" and a "should", not a "must". IIRC they only trigger
> lintian warnings, not errors.

If I tell my son, "You may not go play in the rain.", he knows 
that he can't go play in the rain.

Thus, "may" in this context is ambiguous.  "Should" is only slightly
less so.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

Supporting World Peace Through Nuclear Pacification



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

Re: Is Debian a common carrier? Was: package rejection

[Ron Johnson]

On Wed, 2004-12-08 at 10:31 -0800, Thomas Bushnell BSG wrote:
> Tim Cutts <[EMAIL PROTECTED]> writes:
[snip]
> > To be honest I really don't see what the problem is here.  Content
> > which is illegal to distribute in pretty much any significant market
> > should be kept off the first CD, and probably shouldn't be in main.
> 
> So that means that reference to US law certainly is relevant, since
> the United States is a "significant market".
> 
> Never mind, the principle you suggest is not Debian's current rule,
> and if you want it to be adopted, you should follow the normal way,
> not just declare that it is somehow obviously the right rule.  So how
> about you take the discussion to debian-project where it belongs, and
> prepare a suitable GR or other policy instrument to change our
> policies, or lobby the release manager, or do one of those things?

Debian isn't Soviet Russia or the PRC or pre-war Afghanistan.
Calmly discussing peoples' "should" beliefs is a worthy task.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

[QUOTE]
Casey asked Johnson if doctors tell a woman that the abortion
procedure they might use includes "sucking the brain out of the
skull."
"I don't think we would use those terms," Johnson said. "I think
we would probably use a term like 'decompression of the skull' or
'reducing the contents of the skull.'"
The judge responded, "Make it nice and palatable so that they
wouldn't understand what it's all about?"
Johnson, though, said doctors merely want to be sensitive.
[/QUOTE]
http://story.news.yahoo.com/news?tmpl=story&cid=519&ncid=519&e=7&;
u=/ap/20040401/ap_on_re_us/abortion_lawsuits_31



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

Re: Bug#170548: On closing lists of bugs in changelog...

[Lawrence Williams]

Matthew Danish wrote:
On Wed, Dec 08, 2004 at 11:47:25PM +0100, Bill Allombert wrote:
 

reopen 170548
thanks
On Wed, Dec 08, 2004 at 10:43:42PM +0100, Jose Carlos Garcia Sogo wrote:
   

 * Added ./autogen.sh call in debian/rules ( makes package more
portable
   and easier to maintain in the future ).
 * (Closes: 273895, 217516, 220407, 252897, 159110, 170548, 203843)
   (Closes: 238981, 264436, 159410, 137751, 213624)
-- Matthew Danish <[EMAIL PROTECTED]>  Mon, 15 Nov 2004 02:14:10 -0500
Please DON'T do this. There are explanations of some changes above, but
you need to go to BTS to see each bug this release has closed. As it has
stated a lot of times, changelog is not a place for closing lists of
bugs without explanation.
 

Matthew, I am sure you intended to write a sentence before the braces
and I would really like to know what it was!
However, I have tested and the bug #170548
(libsdl1.2debian-all: [aalib frontend] keyboard arrows do not work)
is not fixed so I have no real choice but to reopen it.
   

I don't know about this.  You'll have to ask Lawrence, as he prepared
this release.  He is now CC'd on this reply.
 

My apologies. I had been in contact with upstream and they told me the 
bug was fixed.

I am preparing a -2 release that fixes the bug reported here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284172
I'll post the .diff as soon as possible.

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Ron Johnson]

On Wed, 2004-12-08 at 13:34 -0800, Scott Robinson wrote:
> > If my wife saw my son with these pictures on a disk that I gave him, she'd
> > take a frying pan and beat me dead.
> 
> And what would she say about any number of other iffy packages?
> 
> bible-kjv? Probably nothing because it isn't offensive to her.
> fortunes-off? Because hot-babe uses graphics it's worse?

Definitely fortunes-off, too.

> As long as Debian is a distribution - a precomposed packaging of as much
> software as possible - then there will be conflicts like this.

You're coming very late to the "conversation".  A District
Attorney angling for higher office or someone in the Morality
Police (think Saudi Arabia) or a petty member of the CCP might not
care about "there will be conflicts like this".

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"I'll call you women instead of girls, just so long as I get paid
more than you do."
Tom Lehrer



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

Re: dpkg-reversion: how about debedit?

[Mike Hommey]

On Wed, Dec 08, 2004 at 09:56:23PM +0100, martin f krafft <[EMAIL PROTECTED]> 
wrote:
> retitle 284642 ITP: debedit -- script to edit DEB files with hooks or 
> interactively
> thanks
> 
> Together with Goswin, I have now given dpkg-reversion the ability to
> invoke a hook on the unpacked binary package. He is now using it to
> test moving /lib64 from base-files to libc6 on amd64 and to change
> the debian/control:Architecture field on packages like OO.o -- for
> amd64.
> 
> The script could be used as a generic DEB file editor with automated
> versioning. I only need it for the version change, but the
> possibilities are endless.
> 
> Thus I propose to rename this ITP/package to debedit. What do you
> say?

Sounds good.
Could it be used for dh_striping the content of a package ?

Mike

Re: SVG icons

[Mike Hommey]

On Wed, Dec 08, 2004 at 11:49:49PM +0100, Bill Allombert <[EMAIL PROTECTED]> 
wrote:
> The authoritative document is the menu _manual_:
> (/usr/share/doc/menu/menu.txt.gz), section 3.7
> 
> An extract from that section:
> 
>  Debian package maintainers should ensure that any icons they include
>  for use in the Debian menus conform to the following points:
> 
>  1.   The icons should be in xpm format.
> 
>  2.   The icons may not be larger than 32x32 pixels, although smaller
>   sizes are ok.

Note that's a "may" and a "should", not a "must". IIRC they only trigger
lintian warnings, not errors.

Mike

Re: Linux Core Consortium

[Stephen Frost]

* Bruce Perens ([EMAIL PROTECTED]) wrote:
> Henrique answered your question. There has been some divergence between 
> various distributions regarding the naming and especially the versioning 
> of these libraries. We would heal that fork to increase compatibility. 
> Doing that means that some names and version tags are going to change 
> for some people. Of course we want to see everyone involved bearing some 
> of that load, rather than Debian bearing the lion's share of it.

You can start w/ OpenLDAP, please.  They need to be shown and convinced
of why caring about one's ABI (opposted to just the API) is necessary...

Good luck.

Stephen


signature.asc
Description: Digital signature

Re: dselect survey

[Miles Bader]

Gergely Korodi <[EMAIL PROTECTED]> writes:
> From time to time I give a try to aptitude and synaptic, but always recoil
> in horror.  I don't know what the fuss is about aptitude, IMHO it's way
> more complicated to use than dselect, and less clear as well. 

Amazing

I used dselect a lot back in the day (I don't know, like up until 2000
or so?).  It had a clunky but useable interface (though I fully
understand how newbies could get frustrated), and generally worked all
right until there was a problem; however when a problem -- even a minor
one -- cropped up it, resolving it could be a miserable experience.

The current aptitude, by contrast, seems both powerful and elegant: it
rarely gets in my way, deals well with problem situations, and offers
powerful features should I want them (aptitude of years past could also
be kinda cranky though).

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Linux Core Consortium

[Steve Langasek]

Bruce,

On Wed, Dec 08, 2004 at 04:49:13PM -0800, Bruce Perens wrote:

> Henrique answered your question. There has been some divergence between 
> various distributions regarding the naming and especially the versioning 
> of these libraries. We would heal that fork to increase compatibility. 
> Doing that means that some names and version tags are going to change 
> for some people. Of course we want to see everyone involved bearing some 
> of that load, rather than Debian bearing the lion's share of it.

Requiring us to ship/link against a particular soversion of a library is one
thing; Debian copes with changes to upstream soversions on a regular basis.
Changing library *names*, OTOH, is something quite different -- and in the
first case, providing "compatibility with the old names" totally defeats the
purpose of *having* sonames, whereas in the second case, it still sounds
like gratuitous change to me.

I'm skeptical to begin with of the benefits LCC has to offer Debian -- being
bound not just to an external *standard*, but to an external
*implementation* requires sacrificing autonomy in areas that have been
historically important to Debian, such as timely security fixes and
arch-specific fixes for architectures not covered by the LCC -- and the
wording from your original message set off a very large red flag for me
besides.  Can you provide pointers to concrete LCC proposals of library
renames, so that I can get comfortable with the technical specifics of
what's really at issue here?

Thanks,
-- 
Steve Langasek
postmodern programmer

> >On Wed, 08 Dec 2004, Steve Langasek wrote:
> > 
> >
> >>How in the world does changing the names of core system libraries serve 
> >>the
> >>technical goal of providing better *compatibility* between distros?  
> >>Indeed,
> >>how could this be anything other than a gratuitous change?
> >>   
> >>
> 
> >Henrique de Moraes Holschuh wrote:
> >Good question. OTOH, getting all of us to use a common naming *AND 
> >VERSIONED
> >SYMBOL TAGS* for everything is a worthy goal.  If this project will help
> >with that...
> >
> > 
> >
> 


signature.asc
Description: Digital signature

Re: Linux Core Consortium

[Bruce Perens]

Steve,

Henrique answered your question. There has been some divergence between
various distributions regarding the naming and especially the
versioning of these libraries. We would heal that fork to increase
compatibility. Doing that means that some names and version tags are
going to change for some people. Of course we want to see everyone
involved bearing some of that load, rather than Debian bearing the
lion's share of it.

    Thanks

    Bruce

  On Wed, 08 Dec 2004, Steve Langasek wrote:
  
  
How in the world does changing the names of core system libraries serve the
technical goal of providing better *compatibility* between distros?  Indeed,
how could this be anything other than a gratuitous change?

  



  Henrique de Moraes Holschuh wrote:
Good question. OTOH, getting all of us to use a common naming *AND VERSIONED
SYMBOL TAGS* for everything is a worthy goal.  If this project will help
with that...

  






smime.p7s
Description: S/MIME Cryptographic Signature

popularity-contest releases-in-use stats

[Bill Allombert]

Hello Debian developers

I have added sometimes ago a new graph to popcon.debian.org
showing what release of popularity-contest were used to report.

Here is today results:

Statistics per popularity-contest releases:

1.18.woody.19: 114
1.19 : 33 
1.20 : 77 
1.22 : 115
1.23 : 132
1.24 : 292
1.25 : 2023   
1.26 : 2642   
unknown  : 1461   

With theses stats and the release date, it is reasonnable to expect
that 13% of the users have installed sarge and never upgraded since.
Another possibility could be that some Debian-based distro provide
an older version of popcon in their current release, but that cannot
account for all the outdated popcon releases in use.

Also, the release of debian-installer rc2 has not led to an increase
of submissions (while other releases did), so either rc2 no more install
popcon by default or very few new users has used it.

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

Imagine a large red swirl here. 

Re: Linux Core Consortium

[Henrique de Moraes Holschuh]

On Wed, 08 Dec 2004, Steve Langasek wrote:
> On Wed, Dec 08, 2004 at 02:59:10PM -0800, Bruce Perens wrote:
> > The main technical effect that I see would be that the names of some 
> > dynamic libraries would change. And compatibility with the old names 
> > could be maintained indefinitely if necessary.
> 
> How in the world does changing the names of core system libraries serve the
> technical goal of providing better *compatibility* between distros?  Indeed,
> how could this be anything other than a gratuitous change?

Good question. OTOH, getting all of us to use a common naming *AND VERSIONED
SYMBOL TAGS* for everything is a worthy goal.  If this project will help
with that...

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

Re: Linux Core Consortium

[Steve Langasek]

On Wed, Dec 08, 2004 at 02:59:10PM -0800, Bruce Perens wrote:
> The main technical effect that I see would be that the names of some 
> dynamic libraries would change. And compatibility with the old names 
> could be maintained indefinitely if necessary.

How in the world does changing the names of core system libraries serve the
technical goal of providing better *compatibility* between distros?  Indeed,
how could this be anything other than a gratuitous change?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bug#170548: On closing lists of bugs in changelog...

[Matthew Danish]

On Wed, Dec 08, 2004 at 11:47:25PM +0100, Bill Allombert wrote:
> reopen 170548
> thanks
> On Wed, Dec 08, 2004 at 10:43:42PM +0100, Jose Carlos Garcia Sogo wrote:
> > 
> >   * Added ./autogen.sh call in debian/rules ( makes package more
> > portable
> > and easier to maintain in the future ).
> >   * (Closes: 273895, 217516, 220407, 252897, 159110, 170548, 203843)
> > (Closes: 238981, 264436, 159410, 137751, 213624)
> > 
> >  -- Matthew Danish <[EMAIL PROTECTED]>  Mon, 15 Nov 2004 02:14:10 -0500
> > 
> >  Please DON'T do this. There are explanations of some changes above, but
> > you need to go to BTS to see each bug this release has closed. As it has
> > stated a lot of times, changelog is not a place for closing lists of
> > bugs without explanation.
> 
> Matthew, I am sure you intended to write a sentence before the braces
> and I would really like to know what it was!
> 
> However, I have tested and the bug #170548
> (libsdl1.2debian-all: [aalib frontend] keyboard arrows do not work)
> is not fixed so I have no real choice but to reopen it.

I don't know about this.  You'll have to ask Lawrence, as he prepared
this release.  He is now CC'd on this reply.

-- 
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org

Re: binary NMUs and version numbers

[Goswin von Brederlow]

Scott James Remnant <[EMAIL PROTECTED]> writes:

> On Thu, 2004-11-25 at 13:53 +0100, Andreas Barth wrote:
>
>> there has been some casual discussion on IRC about version numbers for
>> binary-only NMUs, and different ideas have been exchanged. I try to
>> summarize the status, so that we can get to a decision.
>> 
> To summarise the discussion so far:

[snip] removed everything but the aparent consensus

>  - 1.2-3+b1
>
>"Plus build #n" style; this clearly identifies the fact that it's a
>bin-NMU in all situations.  It does not pass (c), however we can
>alter the security and cdd upload format to +sec-woody1 (or any other
>string matching +[^ab]).

[snip]

> My personal feeling currently gravitates towards the +b1 form, with
> +sec-woody1 and +patch-ubuntu1 as possible security and cdd forms; I
> don't think we have enough time to get the build epoch style into all
> the required software and tested before sarge.
>
> Scott

One thing not mentioned yet is what should happen when a version ends
in an alpha character instead of a number:

1.rc << 1.rc2 << 1.rc+b1
1.2-1~beta << 1.2-1~beta2 << 1.2-1~beta+b1

Adding the implicit '0' that dpkg assumes on versions ending in alpha
chars would solve both cases:

1.rc << 1.rc0+b1 << 1.rc2
1.2-1~beta << 1.2-1~beta0+b1 << 1.2-1~beta2


Another case that should be considered is the existing use of + for
revisions of a cvs snapshot (e.g. mutt uses a + but always does so):

1.2-20041208 "<<" 1.2-20041208+2 "<<" 1.2-20041208+b1

There are 3 simple solutions to this:

1. forbid + in debian versions and think of another character instead
   doing the same (must be < '.')

2. forbid adding + to an existing version [except rebuilds
   and security uploads in the format above]. A new version with + in
   it is fine so long as stripping the +... doesn't match the old
   version. (mutt always has the +)

   1.2-20041208+1 "<<" 1.2-20041208+1+b1 "<<" 1.2-20041208+2

3. use +0b1 and +0sec1

   1.2-20041208 "<<" 1.2-20041208+0b1 "<<" 1.2-20041208+2


And last but not least a very minor thing. What happens when doing a
recompile of a native package?

   1.2 -> 1.2+b1
   1.2 -> 1.2-0+b1 (but still native package)

Current policy says if no debian version is present one should be
added (giving -0.0.1). It should just be clarified in policy that
rebuilds don't add an empty debian version and clearly seperating them
from source NMUs. With the + it's no longer needed.

MfG
Goswin

Linux Core Consortium

[Bruce Perens]

The Linux Core Consortium would like to have Debian's involvement. This 
organization has revived what I originally proposed to do as the LSB - 
to make a binary base for Linux distributions that could be among 
several distributions who would share in the effort of maintaining 
certain packages. Ian Murdock, the creator of Debian, is one of the 
leaders of the effort.

I think there are several important reasons for us to be involved. The 
first is that we should be influencing this group to do things the 
Debian way, where that is important. The second is that the group plans 
to lower the overhead of hardware and application vendor certification 
for all of its participants, and we could really use that sort of 
support. The third is that the group would make certification by LSB and 
other standards bodies easier for all of the participants.

What changes would be necessary for Debian? The group can really be 
viewed as a sort of upstream maintainer for a number of packages, so it 
fits pretty well in the context that we're used to in working with the 
sources of our software. LCC will be working with the people who 
currently are the upstream maintainers for those packages, so we would 
probably see LCC changes to lots of packages whether we want them or 
not. Better to have influence on them while they are happening.

The main technical effect that I see would be that the names of some 
dynamic libraries would change. And compatibility with the old names 
could be maintained indefinitely if necessary.

I would not suggest that Debian commit to using LCC packages at this 
time. We should participate for a while and see how many changes we'd 
have to make and whether the project works for us. But I think we should 
be at the table and in a position to influence the project. The other 
members are willing to have us on those terms.

   Thanks
   Bruce

Bug#284806: ITP: authfail -- Netfilter REJECT/DROP for hosts with too many "auth failure"

[Olivier Lemaire]

Package: wnpp
Severity: wishlist


* Package name: authfail
  Version : 1.0.1
  Upstream Author : Bartosz M. Krajnik <[EMAIL PROTECTED]>
* URL : http://www.bmk.bz/authfail/
* License : GPL
  Description : Netfilter REJECT/DROP for hosts with too many "auth failure"

 This program reads data from FIFO file and adds REJECT/DROP for hosts
 into Netfilter after some attempts of failed logins.
 If someone tries to log into your system and you see many "authentication
 failure" in you auth.log from one IP, you just add this IP into your
 ACL.

 If anybody is interested in this little piece of code, a draft package
 exist on http://olivier-lemaire.org/debian/dists/sarge/main/ ...

 I'll upload source to mentors in an minute.

 Interested in any comments about this package (my first debian package
 using init.d scripts: I'm still discovering the great dbhelper).

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Cheers,
-- 
Olivier LEMAIRE, aka LEM
http://olivier-lemaire.org/

Re: SVG icons

[Bill Allombert]

On Wed, Dec 08, 2004 at 11:25:22AM -0500, James A. Treacy wrote:
> On Wed, Dec 08, 2004 at 02:06:26PM +0100, Lo?c Minier wrote:
> > 
> >  It's defined in the _Menu_ Policy.  I think the people maintaining the
> >  Debian menu system are best placed to tell what should be allowed or
> >  not.
> 
> It is precisely because the menu policy does not say anything about
> icons that I brought this up here. 'man menufile' states that an icon
> can be specified but nothing else.

The authoritative document is the menu _manual_:
(/usr/share/doc/menu/menu.txt.gz), section 3.7

An extract from that section:

 Debian package maintainers should ensure that any icons they include
 for use in the Debian menus conform to the following points:

 1.   The icons should be in xpm format.

 2.   The icons may not be larger than 32x32 pixels, although smaller
  sizes are ok.

> Note that svg icons work in a gnome environment. Because gramps is
> a gnome program and upstream will only be distributing an svg icon
> starting with the next major release, I may just stick with that.
> There are usually other issues, though, so I was hoping some wisdom
> could be found on debian-devel.

If your icon is intended to be used with the Debian menu system, it
needs to be in a format acceptable to all window-managers in Debian.
Unfortunately that means XPM currently [until sarge release].

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

Imagine a large red swirl here. 

Re: On closing lists of bugs in changelog...

[Bill Allombert]

reopen 170548
thanks
On Wed, Dec 08, 2004 at 10:43:42PM +0100, Jose Carlos Garcia Sogo wrote:
> 
>   * Added ./autogen.sh call in debian/rules ( makes package more
> portable
> and easier to maintain in the future ).
>   * (Closes: 273895, 217516, 220407, 252897, 159110, 170548, 203843)
> (Closes: 238981, 264436, 159410, 137751, 213624)
> 
>  -- Matthew Danish <[EMAIL PROTECTED]>  Mon, 15 Nov 2004 02:14:10 -0500
> 
>  Please DON'T do this. There are explanations of some changes above, but
> you need to go to BTS to see each bug this release has closed. As it has
> stated a lot of times, changelog is not a place for closing lists of
> bugs without explanation.

Matthew, I am sure you intended to write a sentence before the braces
and I would really like to know what it was!

However, I have tested and the bug #170548
(libsdl1.2debian-all: [aalib frontend] keyboard arrows do not work)
is not fixed so I have no real choice but to reopen it.

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

Imagine a large red swirl here. 

attn: matt hope -- your mail bounces

[martin f krafft]

This is probably related to your university address, which also
bounces with "too many hops".

- Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> -

<[EMAIL PROTECTED]>: Too many hops

- End forwarded message -

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: [EMAIL PROTECTED]
 
still looking for the glorious results of my misspent youth.
say, do you have a map to the next joint?


signature.asc
Description: Digital signature

On closing lists of bugs in changelog...

[Jose Carlos Garcia Sogo]

libsdl1.2 (1.2.7+1.2.8cvs20041007-1) unstable; urgency=medium

  * Thanks go to Lawrence Williams
( [EMAIL PROTECTED] )
for this release.
  * Updated to 07/10/2004 CVS.
  * Added --static-libs to sdl-config manpage.
  * Added NAS support.
  * Provide debian patches for autogen.sh ( needs automake 1.7 ) and
configure.in ( fix for NAS support ).
  * Added libaudio-dev, automake1.7 to Build-Depends.
  * Added ./autogen.sh call in debian/rules ( makes package more
portable
and easier to maintain in the future ).
  * (Closes: 273895, 217516, 220407, 252897, 159110, 170548, 203843)
(Closes: 238981, 264436, 159410, 137751, 213624)

 -- Matthew Danish <[EMAIL PROTECTED]>  Mon, 15 Nov 2004 02:14:10 -0500

 Please DON'T do this. There are explanations of some changes above, but
you need to go to BTS to see each bug this release has closed. As it has
stated a lot of times, changelog is not a place for closing lists of
bugs without explanation.

 Thanks,

-- 
Jose Carlos Garcia Sogo
   [EMAIL PROTECTED]


signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada	digitalmente

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Scott Robinson]

> If my wife saw my son with these pictures on a disk that I gave him, she'd
> take a frying pan and beat me dead.

And what would she say about any number of other iffy packages?

bible-kjv? Probably nothing because it isn't offensive to her.
fortunes-off? Because hot-babe uses graphics it's worse?

As long as Debian is a distribution - a precomposed packaging of as much
software as possible - then there will be conflicts like this.

Scott.

-- 
http://quadhome.com/- Personal webpage


signature.asc
Description: Digital signature

Re: Is Debian a common carrier? Was: package rejection

[Bruce Perens]

[EMAIL PROTECTED] wrote:
Akamai is fully able to turn customers away, and has done so for various reasons (e.g. the customer is a spammer).
 

That's the key. And we had a posting from Joe Alewin that was most 
informative on this topic.

For an example of a non-discriminatory mirror, consider the many ISPs which provide general HTTP caching services through Squid. Whether as a transparent or voluntary proxy, the goal of these caches is to improve content availability and transfer speed, while reducing bandwidth costs.
 

That's the best example we have, I think.
   Thanks
   Bruce

dpkg-reversion: how about debedit?

[martin f krafft]

retitle 284642 ITP: debedit -- script to edit DEB files with hooks or 
interactively
thanks

Together with Goswin, I have now given dpkg-reversion the ability to
invoke a hook on the unpacked binary package. He is now using it to
test moving /lib64 from base-files to libc6 on amd64 and to change
the debian/control:Architecture field on packages like OO.o -- for
amd64.

The script could be used as a generic DEB file editor with automated
versioning. I only need it for the version change, but the
possibilities are endless.

Thus I propose to rename this ITP/package to debedit. What do you
say?

Version 0.1.16 is still at

  deb http://people.debian.org ~madduck/packages/stage/dpkg-reversion/
  deb-src http://people.debian.org ~madduck/packages/stage/dpkg-reversion/

Comments, suggestions, patches, improvements welcome.

-- 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Is Debian a common carrier? Was: package rejection

[dsr]

On Tue, Dec 07, 2004 at 04:48:24PM -0800, Bruce Perens wrote:
> Goswin von Brederlow wrote:
> 
> A mirror operator in general /does/ make choices about the content 
> carried on the mirror. The closest analogy that would already have been 
> litigated is a Cable TV system. The U.S. FCC decided that Cable TV 
> networks were not common carriers /because the subscriber did not 
> determine the programming./ This was appealed and the court agreed with 
> FCC. Source: http://en.wikipedia.org/wiki/Cable_TV
> 
> Now, there might be a way make a mirror qualify. You would have to set 
> it up so that the mirror would mirror /everything /that is sent its way 
> without discrimination. The mirror operator could take money to do this, 
> but would not be able to turn customers away.
> 
> Then, you might have some chance of convincing a judge that the mirror 
> provides a communications service in an entirely non-discriminatory 
> fashion, which is what a common carrier does. I guess Akamai would be 
> the closest example today to a mirror operating this way.

Being a former Akamai employee, I can state (and refer you to the
appropriate people inside Akamai) that Akamai does not and never has
operated in this fashion.

Exactly like a cable TV network, in fact, Akamai redistributes the
content that customers -- content providers -- pay for. Akamai is fully
able to turn customers away, and has done so for various reasons (e.g.
the customer is a spammer).

For an example of a non-discriminatory mirror, consider the many ISPs
which provide general HTTP caching services through Squid. Whether as a
transparent or voluntary proxy, the goal of these caches is to improve
content availability and transfer speed, while reducing bandwidth costs.

-dsr-

-- 
Nothing to sig here, move along.

Re: Status of this ITP?

[Luis R. Rodriguez]

On Wed, Dec 08, 2004 at 06:41:35PM +0100, Jose Carlos Garcia Sogo wrote:
> El mi??, 08-12-2004 a las 12:30 -0500, Luis R. Rodriguez escribi??:
> > On Wed, Dec 08, 2004 at 05:21:56PM +, David Pashley wrote:
> > > On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by
> > > saying:
> > > > 
> > > > 
> > > > Its been more than a year now. What's the status of this ITP?  This is
> > > > ridiculous. If you can't package it, then say so so others can come in
> > > > and do the job. We deserve a freedesktop.org package by now in debian.
> > > > 
> > > > Get off your ass.
> > > > 
> > > This is an ITP for KDrive, the experimental xserver. It is not the X.org
> > > xserver. I'm not sure this is what you think it is.
> > > 
> > > I appriciate that english may not be your first language, but the tone
> > > of the email was not exactly friendly. People work on Debian because
> > > they want to. Having people shout at them isn't the best incentive to
> > > get them to do voluntary work.
> > 
> > David,
> > 
> > thanks for the prompt e-mail. The goal of my e-mail was to get us off
> > our asses and get a debian xorg package out. Today I realized there
> > wasn't one available and that just pissed me off. I won't appoologize
> > for my tone as I feel we shouldn't settle.
> 
>  Please read X-Strike force FAQ[1] first.
> 
>  The relevant link is:
> http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#debianplans
> 
>  But to target a bit closer:
> "As of this writing (October 2004), packaging of the X.Org distribution
> is underway in the X Strike Force's xorg Subversion repository
> (ViewCVS[2])"
> 
>  Please help packaging this, not whining about packages not being ready.
> 
> 
> [1]http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml
> [2]http://necrotic.deadbeast.net/cgi-bin/viewcvs.cgi/?root=xorg

Carlos,


My hero


Thanks so much,

Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E


pgp7SVbNNLDVm.pgp
Description: PGP signature

Re: Status of this ITP?

[Henrique de Moraes Holschuh]

On Wed, 08 Dec 2004, Luis R. Rodriguez wrote:
> thanks for the prompt e-mail. The goal of my e-mail was to get us off
> our asses and get a debian xorg package out. Today I realized there

An email won't help.  The package itself might, if uploaded to experimental
(don't you dare upload such a thing to sid right now).  Do you have one to
upload?

> wasn't one available and that just pissed me off. I won't appoologize

I sure hope you are a very active and produtive member of the X task
force...

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

Bug#284778: ITP: freebooters -- Free "Pirates!" like strategy game

[Moritz Muehlenhoff]

Package: wnpp
Severity: wishlist

* Package name: freebooters
  Version : 0.2.2
  Upstream Author : [EMAIL PROTECTED]
* URL : http://home.gna.org/freebooters
* License : GPL
  Description : Free "Pirates!" like strategy game

 The Caribbean Sea in the late 16th century: The Dutch, French,
 English and Spanish crown aim to expand their areas of
 influence. You as an auspiscious young captain are trying to
 make the best of it, as you may either become a brave merchant
 soul, a freebooting hero of your crown or a bloodlusty dreaded
 pirate leader.
 .
 Freebooters will hopefully become a free clone of the Sid Meier
 classic "Pirates!". It's written in C++ using SDL, makes use of
 the Ogre 3D engine and is licensed under the GNU General Public
 License.

The main intent of this ITP is to prevent duplicated packaging
efforts; unofficial Debian packages are available since the 0.1
release, but an attempt to introduce them into the main archive
will be made post-sarge with the 0.3 release, which will be the
first playable release.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-1-386
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Re: Is Debian a common carrier? Was: package rejection

[Thomas Bushnell BSG]

Tim Cutts <[EMAIL PROTECTED]> writes:

> I could be wrong, but Debian is occasionally used and distributed by
> people outside the USA.  Making any argument in this thread with
> reference solely to US law is irrelevant to the problems at hand.

I was answering a claim about US law; I was not the one who introduced
it.

Yet what you say next contradicts the above quote:

> To be honest I really don't see what the problem is here.  Content
> which is illegal to distribute in pretty much any significant market
> should be kept off the first CD, and probably shouldn't be in main.

So that means that reference to US law certainly is relevant, since
the United States is a "significant market".

Never mind, the principle you suggest is not Debian's current rule,
and if you want it to be adopted, you should follow the normal way,
not just declare that it is somehow obviously the right rule.  So how
about you take the discussion to debian-project where it belongs, and
prepare a suitable GR or other policy instrument to change our
policies, or lobby the release manager, or do one of those things?

Thomas

Re: Where is your freedom of speech ? (Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor)

[David Nusinow]

On Wed, Dec 08, 2004 at 09:29:55AM +0100, Emmanuel Charpentier wrote:
> Debian might fare much 
> better if its members who happen to be citizens of the U f*ck*ng S of A 
> rememeber sometimes that they are *not* center and moral arbiter of the 
> world... The same can be told of (semi-) legal concerns, which have no 
> relevance outside the US : insisting that Debian should cater to any 
> possible foolish demands of an US attorney|sycophant is at best 
> provincialism, at worst parochialism.

Rampant USA bashing is not likely to help your cause, and is in fact far more
likely to piss off a large number of people who might otherwise be inclined to
listen to what you have to say. As it is, you just come off sounding like a
total jerk. Please read the RTFThread and come back when you realize that a
good chunk of the debate is centered around the legality of distributing
content to places like Iran.

 - David Nusinow

ObRC: #280901

Re: Status of this ITP?

[Steve Greenland]

On 08-Dec-04, 11:15 (CST), "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote: 
> Its been more than a year now. What's the status of this ITP? 
> This is ridiculous. If you can't package it, then say so so others can
> come in and do the job. We deserve a freedesktop.org package by now in
> debian.

If you're going to CC debian-devel, at least have the courtesy to
mention what the hell you're babbling about, instead of forcing us to go
look up the bug number.

> Get off your ass.

Ah. I see. Courtesy is not your strong point.

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: Status of this ITP?

[Jose Carlos Garcia Sogo]

El miÃ, 08-12-2004 a las 12:30 -0500, Luis R. Rodriguez escribiÃ:
> On Wed, Dec 08, 2004 at 05:21:56PM +, David Pashley wrote:
> > On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by
> > saying:
> > > 
> > > 
> > > Its been more than a year now. What's the status of this ITP?  This is
> > > ridiculous. If you can't package it, then say so so others can come in
> > > and do the job. We deserve a freedesktop.org package by now in debian

Re: Status of this ITP?

[Luis R. Rodriguez]

On Wed, Dec 08, 2004 at 05:21:56PM +, David Pashley wrote:
> On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by
> saying:
> > 
> > 
> > Its been more than a year now. What's the status of this ITP?  This is
> > ridiculous. If you can't package it, then say so so others can come in
> > and do the job. We deserve a freedesktop.org package by now in debian.
> > 
> > Get off your ass.
> > 
> This is an ITP for KDrive, the experimental xserver. It is not the X.org
> xserver. I'm not sure this is what you think it is.
> 
> I appriciate that english may not be your first language, but the tone
> of the email was not exactly friendly. People work on Debian because
> they want to. Having people shout at them isn't the best incentive to
> get them to do voluntary work.

David,

thanks for the prompt e-mail. The goal of my e-mail was to get us off
our asses and get a debian xorg package out. Today I realized there
wasn't one available and that just pissed me off. I won't appoologize
for my tone as I feel we shouldn't settle.

What's the right ITP then, 220347?

Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E


pgpxBTPVyClLD.pgp
Description: PGP signature

Re: Status of this ITP?

[David Pashley]

On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by
saying:
> 
> 
> Its been more than a year now. What's the status of this ITP?  This is
> ridiculous. If you can't package it, then say so so others can come in
> and do the job. We deserve a freedesktop.org package by now in debian.
> 
> Get off your ass.
> 
This is an ITP for KDrive, the experimental xserver. It is not the X.org
xserver. I'm not sure this is what you think it is.

I appriciate that english may not be your first language, but the tone
of the email was not exactly friendly. People work on Debian because
they want to. Having people shout at them isn't the best incentive to
get them to do voluntary work.


-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.

Status of this ITP?

[Luis R. Rodriguez]

Its been more than a year now. What's the status of this ITP? 
This is ridiculous. If you can't package it, then say so so others can
come in and do the job. We deserve a freedesktop.org package by now in
debian.

Get off your ass.

Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E


pgp2sc12YUKkt.pgp
Description: PGP signature

Backups in maintainer scripts

[Diogo Kollross]

I'm replacing files in the maintainer script of a
package, but I would like to maintain backups of these
files. Is there any good practice about that (eg: like
renaming the old file to filename~ or filename.old)?

I would also like to know if dpkg makes any backups
when installing packages, and if I can rely on them
being present when removing a package.

Thanks,

--
Diogo Kollross






___ 
Yahoo! Mail - Agora com 250MB de espaço gratuito. Abra 
uma conta agora! http://br.info.mail.yahoo.com/

Re: SVG icons

[James A. Treacy]

On Wed, Dec 08, 2004 at 02:06:26PM +0100, Lo?c Minier wrote:
> Eric Lavarde <[EMAIL PROTECTED]> - Wed, Dec 08, 2004:
> 
> > To summarize, I think recommending SVG would require a change to the policy.
> 
>  It's defined in the _Menu_ Policy.  I think the people maintaining the
>  Debian menu system are best placed to tell what should be allowed or
>  not.

It is precisely because the menu policy does not say anything about
icons that I brought this up here. 'man menufile' states that an icon
can be specified but nothing else.

Note that svg icons work in a gnome environment. Because gramps is
a gnome program and upstream will only be distributing an svg icon
starting with the next major release, I may just stick with that.
There are usually other issues, though, so I was hoping some wisdom
could be found on debian-devel.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

Re: charsets in debian/control

[Thaddeus H. Black]

It is one thing spiritedly to argue a point against
friends and allies.  It is another to be obstinate.  I
do not wish the latter, and I admit that I am both
outnumbered and outreasoned today.  Please permit me
without malice to conform my position, which now might
be stated as follows.

  Unicode is a reasonable solution to a difficult yet
  important problem.  Broadly accepted even among
  Debian Developers from the Latin-1 countries,
  Unicode is also recognized outside Debian around a
  wider world.  Unicode is recommended for general
  Debian application.

  For non-localized purposes in which a restricted,
  byte-based character set is wanted, plain seven-bit
  ASCII is normally the logical choice.  As for
  Latin-1, although it served some needs in an earlier
  day, it must today be regarded as a local,
  incompatible encoding, not recommended for general
  international use.

I trust that you will inform me if the conformed
position yet lacks in any significant way!  Besides
expressing my own revised view, the statement also means
to summarize the subthread's key points.

Since I happen to have the attention of interested
people at the moment, I should say that I could use some
help in conforming debram's [7800 Non-English Natural
Language] division sensibly to the Unicode consensus.  I
lack the right knowledge to do it myself.  At present,
only the Latin-1 languages are sensibly differentiated
there.  The aid of a Russian (for group 7890) and a
Japanese (for group 7880) might be particularly
suitable, for instance.  (If you don't know what this is
about, it regards debtags [1].)

Turning to another matter, the responses to my impromptu
roster of Debian development skills indicate that the
roster has been taken in slightly a different manner
than I had meant it.

> ... the typical roster of skills one masters in
> contributing broadly to Debian development is ...
> awesome: C, C++, CPP, Make, Perl, Python, Autoconf,
> CVS, Shell, Glibc, System calls, /proc, IPC, sockets,
> Sed, Awk, Vi, Emacs, locales, Libdb, GnuPG, Readline,
> Ncurses, TeX, Postscript, Groff, XML, assembly, Flex,
> Bison, ORB, Lisp, Dpkg, PAM, Xlibs, Tk, GTK, SysVInit,
> Debconf, ELF, etc.---not to mention the use of the
> English language at a sophisticated technical level.

Although the roster may be interesting, it was meant
neither as a canonical proposal nor as a challenge.  In
fact it was just what I had happened to think of
informally at the moment.  For the record, I happen to
have a working familiarity with nineteen of the items on
my own roster, plus a limited familiarity with seven
more.  Were the roster a challenge, it would be a
foolish one, because Steve Langasek would beat me in a
Debian development contest and I know it.  As for the
other fifteen roster items, as Steve said,

> "contributing broadly to Debian" usually means
> mastering some of these skills, and knowing where to
> find answers for the rest.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED]

1. http://debtags.alioth.debian.org


pgpWJ19KUmZqo.pgp
Description: PGP signature

Re: SVG icons

[Loïc Minier]

Eric Lavarde <[EMAIL PROTECTED]> - Wed, Dec 08, 2004:

> To summarize, I think recommending SVG would require a change to the policy.

 It's defined in the _Menu_ Policy.  I think the people maintaining the
 Debian menu system are best placed to tell what should be allowed or
 not.
   Additionally, there are other menu systems parallel to the Debian
 menu system, and SVG use might be permitted by other systems, hence the
 OP should clarify his question.

   Regards,

-- 
Loïc Minier <[EMAIL PROTECTED]>

Re: SVG icons

[Eric Lavarde]

Hi,

isn't the actual underlying problem that the Debian Policy only accepts
XPM icons (and lintian with it)? I don't know the background of this
decision, but could imagine:
- broad acceptance (aside from GNOME and KDE), PNG should be fine on this
one, SVG not yet.
- text oriented format: SVG OK, PNG not.
- free: SVG and PNG OK.

To summarize, I think recommending SVG would require a change to the policy.

Cheers, Eric

> Le mardi 07 décembre 2004 à 23:51 -0500, James A. Treacy a écrit :
>> SVG use is increasing and I have seen nothing in Debian about how they
>> should be handled. So,
>
> I don't think that's much different from PNG icons.
>
>> What is the proper way to handle svg icons?
>> For example, where should they be placed?
>
> GNOME places them under /usr/share/icons/$THEME/scalable.
>
>> How well are they supported?
>
> Support is increasing; but at least all GTK+ stuff supports them,
> including as toolbar icons, provided that librsvg2-common is installed.
>
>> Should a non-svg icon also be included?
>
> Not necessarily.
> --
>  .''`.   Josselin Mouette/\./\
> : :' :   [EMAIL PROTECTED]
> `. `'[EMAIL PROTECTED]
>   `-  Debian GNU/Linux -- The power of freedom
>


-- 
Eric de France, d'Allemagne et de Navarre

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Ron Johnson]

On Wed, 2004-12-08 at 09:31 -0200, [EMAIL PROTECTED] wrote:
> On Wed, Dec 08, 2004 at 12:00:14AM -0800, Steve Langasek wrote:
> > On Tue, Dec 07, 2004 at 11:17:46AM -0300, Fabricio Cannini wrote:
> > >  --- Michelle Konzack <[EMAIL PROTECTED]>
> > > escreveu: 
> > > > Am 2004-12-07 10:39:42, schrieb Fabricio Cannini:
[snip]
> 
> What about non-US? If some packages can be distributed from only some
> mirrors outside US, why shouldn't some packages be distributed only
> from some countries where they are legal to be distributed?
> Or are there only two countries for Debian? US (main) and non-US?

The US isn't the only country that has various forms of content
restrictions.  Thus, non-US isn't sufficient.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Peace is not only better than war, but infinitely more arduous."
George Bernard Shaw



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

Re: SVG icons

[Josselin Mouette]

Le mardi 07 dÃcembre 2004 Ã 23:51 -0500, James A. Treacy a Ãcrit :
> SVG use is increasing and I have seen nothing in Debian about how they
> should be handled. So,

I don't think that's much different from PNG icons.

> What is the proper way to handle svg icons?
> For example, where should they be placed?

GNOME places them under /usr/share/icons/$THEME/scalable.

> How well are they supported?

Support is increasing; but at least all GTK+ stuff supports them,
including as toolbar icons, provided that librsvg2-common is installed.

> Should a non-svg icon also be included?

Not necessarily.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Ron Johnson]

On Wed, 2004-12-08 at 19:57 +1100, Russell Coker wrote:
> On Wednesday 08 December 2004 07:42, Ron Johnson <[EMAIL PROTECTED]> 
> wrote:
> > > > Fortunately, though, pictures of naked dogs are *not* considered
> > > > to be appealing to prurient interests.  Unless, *maybe*, a hyper-
> > > > horny 13 year old boy is seeing a picture of dogs copulating, and
> > > > not in the context of some "scientific value", i.e., a text book.
> > > > Even in that case, though, the boy would probably be told to wash
> > > > his hand and stop being a pervert.
> > >
> > > So you have no objections to bestiality web sites then?
> >
> > How does "a picture of dogs copulating" get morphed into "bestiality"?
> 
> When such pictures appear on porn sites they are presumably used in the same 
> manner as other porn (not for scientific or artistic purposes).
[snip]
> 
> > Are you are purposefully misinterpreting what I wrote?
> 
> When you give an example of a boy needing to "wash his hands" after "seeing a 
> picture of dogs copulating" you are obviously referring to dog-copulation 
> porn pictures.  I was interpreting it in EXACTLY the same way as you.

But still, "a picture of dogs copulating" is *not* "bestiality",
and I never inferred that the picture would be on a porn site 
(there's more to life than than the internet, after all), so I'm
confused as to made the leap.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"If you wish for peace be ready for war."
Proverb
"To be prepared for war is one of the most effective means of
preserving peace."
George Washington



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

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[cascardo]

On Wed, Dec 08, 2004 at 12:00:14AM -0800, Steve Langasek wrote:
> On Tue, Dec 07, 2004 at 11:17:46AM -0300, Fabricio Cannini wrote:
> >  --- Michelle Konzack <[EMAIL PROTECTED]>
> > escreveu: 
> > > Am 2004-12-07 10:39:42, schrieb Fabricio Cannini:
> 
> > > > Me wonders if simply NOT installing hot-babe
> > > > wouldn't fix this.
> > > > IMO Seems to be the easiest solution.
> 
> > > In theory !  In many countries it is illegal
> > > to have some stuff on CD or other Media.
> 
> > > > Don't put it on the CD!!
> 
> > > And WHO stores the CD-Images ?
> 
> > Servers located on coutries that do not have such
> > prohibitions would store these packages.
> > I'm talking about NOT putting such packages
> > in the official medias (CDs, .iso, etc).
> 
> I don't think this is a very useful compromise.  If a package is going to be
> included in the Debian archive, it should also be included in the official
> Debian CD sets.  I think it's a good idea to provide enough metadata in the
> archive to let people build localized CD sets that are legal in their
> jurisdiction, but I don't think we should be excluding any Debian packages
> from official CD sets -- if there are reasons that we can't distribute a
> package in main as part of our CD images, we shouldn't be distributing it
> from the mirrors either.
> 

What about non-US? If some packages can be distributed from only some
mirrors outside US, why shouldn't some packages be distributed only
from some countries where they are legal to be distributed?
Or are there only two countries for Debian? US (main) and non-US?
Regards,
Thadeu Cascardo.

> ObRC: #245810
> 
> -- 
> Steve Langasek
> postmodern programmer




signature.asc
Description: Digital signature

Re: Is Debian a common carrier? Was: package rejection

[Manoj Srivastava]

On Tue, 07 Dec 2004 13:12:35 -0800, Bruce Perens <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>> Oh, and if we do not specify what the nature of what we package,
>> would it be easier to prove we merely carry packages?  That would
>> really be nice.
>> 

> I just do not see that we have the slightest chance of convincing a
> court that we're a common carrier.

Fair enough. I did not really think we had a hope there.

However,  I still find myself unconvinced that policy about
 how content is packaged (mostly how maintainer scripts and packaging
 rules interact with the packaging system) and how the contents are
 laid out in the file system is  policy about the _nature_ of content.

manoj
-- 
There is no satisfaction in hanging a man who does not object to
it. G.B. Shaw
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: charsets in debian/control

[Steve Langasek]

On Tue, Dec 07, 2004 at 05:56:54PM +, Thaddeus H. Black wrote:
> > But yes, non-ASCII Latin-1 chars should not be given
> > special status over the national chars found in other
> > languages spoken by project members.  Debian should be
> > using either ASCII, or Unicode; standardizing on
> > Latin-1 makes no sense in a global project.

> True.  Look, Steve: mild abuse aside, I agree with you
> in every particular.  Nevertheless, I would respectfully
> suggest that your criticism underscores my point, which
> regards the monstrous increase in complexity which the
> full Unicode standard represents.

Yet you had concluded this means we should use Latin-1 as an encoding for
the files.  All arguments that justify the use of Latin-1 characters in the
control file are equally applicable to any of a number of other national
character sets used by one or more developers.

> Consider.  Is it a bug if Readline cannot echo full bidirectional input?

Er, yes, sure it is, independently of what happens in debian/control.

> If Dselect does not appreciate all the non-spacing
> characters?

IFF dselect has a reason to display such characters, yes.  This may well be
the case regardless of whether debian/control ever supports non-ASCII
characters; Debian may start supporting localized Packages files via some
external mechanism, or it may provide a localized UI that requires these
characters.

> If Less does not regard Tibetan subjoined letters?  (This is my Tibetan
> straw man.)

Yes, this is also a bug.  Not one that's likely to be noticed for a while,
but a bug nevertheless.  But your example again overstates the complexity of
the task: the main responsibility of less is to figure out how many
characters to display on a line, and let the *terminal* render the glyphs.
This is code that needs to be implemented only once, and most of the work is
already done centrally for *all* apps by glibc which keeps track of the
display width of each character.

> Undoubtedly one might observe that the Tibetan problem
> were not really a problem with Less but rather with some
> underlying library, but this misses the point---or
> rather again it underscores the point.  Unicode solves
> what for many of us was not a problem by creating an
> entirely new class of problems.  For example, it
> requires us to be particular about how we tag our e-mail
> attachments...

Um, no.  Being part of a *global Internet* causes this problem for you.
The non-ASCII characters in your email were undefined gibberish according
to your headers; only naive (or "helpful", YMMV) mail readers would render
them at all, and only naive mail readers commanded by users using a Western
European locale would have rendered them as intended.  Actually, perhaps
even that is being too generous, as there are *different* native 8-bit
encodings used on each of Unix, Windows, and MacOS; the Unix and Windows
encodings differ on relatively few codepoints, but the Mac encoding is
widely different.

And you think it's ok to inflict this same mess on anyone not using a
Latin-1 locale while trying to read a debian/control file?

> Am I arguing to jettison Unicode?  No; to the partial
> extent that I had been arguing it earlier in the thread,
> you, Peter, Daniel and Matthew have changed my mind.
> However, the typical roster of skills one masters in
> contributing broadly to Debian development is already
> awesome: C, C++, CPP, Make, Perl, Python, Autoconf, CVS,
> Shell, Glibc, System calls, /proc, IPC, sockets, Sed,
> Awk, Vi, Emacs, locales, Libdb, GnuPG, Readline,
> Ncurses, TeX, Postscript, Groff, XML, assembly, Flex,
> Bison, ORB, Lisp, Dpkg, PAM, Xlibs, Tk, GTK, SysVInit,
> Debconf, ELF, etc.---not to mention the use of the
> English language at a sophisticated technical level.
> UTF-8 is neat, but I do not really like Unicode (you may
> have noticed this).  Seeking essential simplicity, I
> would prefer to keep the full hairy overgrown Unicode
> standard from the typical Debian roster of development
> skills.  Wouldn't you?

1) Sorry, modern software is a complex creature.  This is because we demand
complex things of it -- including handling all the languages that we speak.

2) Most DDs do not master all of the above skills.  *I* don't have a mastery
of all of the above skills; "contributing broadly to Debian" usually means
mastering some of these skills, and knowing where to find answers for the
rest.

3) "Mastering Unicode", for the purposes of almost anyone not working
directly on glibc or implementing a terminal, is roughly equivalent to
"making sure your application implements proper string handling for CJK".
If you do it right, the differences between UTF-8 and ISO-2022 are normally
minimal; if you do it wrong, you get bug reports from Japanese users.
However, for files for which no encoding is specified, there is no right way
to handle non-ASCII data, which is why debian/control is an issue.

4) As suggested above, for 98% of all applications on the system, the
enc

Re: Is Debian a common carrier? Was: package rejection

[Tim Cutts]

On 8 Dec 2004, at 8:53 am, Thomas Bushnell BSG wrote:
The discussion about common carriers is all very interesting, but
irrelevant.  There are many protections in American law, and common
carrier status is only one.  We are certainly not responsible for
things which are not obscene, and the package in question is not
obscene (b/c under US law a cartoon such as that cannot be legally
obscene).
I could be wrong, but Debian is occasionally used and distributed by 
people outside the USA.  Making any argument in this thread with 
reference solely to US law is irrelevant to the problems at hand.

To be honest I really don't see what the problem is here.  Content 
which is illegal to distribute in pretty much any significant market 
should be kept off the first CD, and probably shouldn't be in main.  
That way, users and distributors in any country can distribute and/or 
use the basic Debian distribution without any worries.  They can 
distribute or use other parts of the archive, including packages such 
as the Bible or Hot-babe, at their own discretion.  I have no problems 
with people packaging these things, they just shouldn't be part of the 
base install, or present on the media required to perform a base 
install.

Tim
--
Dr Tim Cutts
GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638  C066 16E2 F4F5 FC81 E159


PGP.sig
Description: This is a digitally signed message part

Re: Duelling banjos or how a sane community goes crazy

[Frank Küster]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> schrieb:

> On Mon, Dec 06, 2004 at 08:12:50AM +0100, Andreas Tille wrote:
>
>  > I failed in ending this thread when I posted
>  > 
>  >   http://lists.debian.org/debian-devel/2004/12/msg00016.html
>  > 
>  > instead I caused two trolls making even more noise.
>
>  Without having read your post,

You should have.

> I'm pretty confident that you failed
>  *because of* Godwin's Law.  It is a part of Godwin's Law that calling
>  someone a Nazi (directly or by implication) with the sole purpose of
>  ending a thread *does not* end it.

And you are wrong, because in that posting nothing, nothing at all has
any connection to Nazis (directly or by implication).


Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#282742: Move daily find run later

[Martin Schulze]

Andreas Metzler wrote:
> Anyway the solution seems to be overengineered for the problem at
> hand. I have yet to decide whether 
> * I'll close the bugreport with "request denied"

Please don't do that but tag it wontfix instead if you "won't fix" this
bug report.

Regards,

Joey

-- 
Open source is important from a technical angle. -- Linus Torvalds

Please always Cc to me when replying to me on the lists.

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Russell Coker]

On Wednesday 08 December 2004 07:42, Ron Johnson <[EMAIL PROTECTED]> 
wrote:
> > > Fortunately, though, pictures of naked dogs are *not* considered
> > > to be appealing to prurient interests.  Unless, *maybe*, a hyper-
> > > horny 13 year old boy is seeing a picture of dogs copulating, and
> > > not in the context of some "scientific value", i.e., a text book.
> > > Even in that case, though, the boy would probably be told to wash
> > > his hand and stop being a pervert.
> >
> > So you have no objections to bestiality web sites then?
>
> How does "a picture of dogs copulating" get morphed into "bestiality"?

When such pictures appear on porn sites they are presumably used in the same 
manner as other porn (not for scientific or artistic purposes).

I haven't actually seen a picture of two dogs copulating on a bestiality site 
(when it was my job to kill such sites I just looked at the front page which 
was usually enough to determine whether it met the non-commercial criteria).  
I have seen pictures of dogs genitals on bestiality sites that were not in 
any way connected to humans.

> Are you are purposefully misinterpreting what I wrote?

When you give an example of a boy needing to "wash his hands" after "seeing a 
picture of dogs copulating" you are obviously referring to dog-copulation 
porn pictures.  I was interpreting it in EXACTLY the same way as you.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Is Debian a common carrier? Was: package rejection

[Thomas Bushnell BSG]

The discussion about common carriers is all very interesting, but
irrelevant.  There are many protections in American law, and common
carrier status is only one.  We are certainly not responsible for
things which are not obscene, and the package in question is not
obscene (b/c under US law a cartoon such as that cannot be legally
obscene).  

thomas

Where is your freedom of speech ? (Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor)

[Emmanuel Charpentier]

Warniong : I'm not an Ordained Debian Developper (TM) : my words are 
just those of a Debian User, worried by this new upsurge of hair 
splitting, US smelling madness.

> Hi again,
>
> perhaps to bring down the conversation to something more constructive,
> I think we should base decision to have something or not in Debian:
> 1. _NOT_ on personal belief (else we would probably end with nothing).
> 2. _NOT_ on local laws (same comment).
Agreed so far.
> 3. does it have some "technical" interest? (technical documentation
> OK, technical tool to show/use the Bible is OK, Bible in HTML format
> is probably _not_ OK, Gutenberg can do it better).
NOT fully agreed : while I don't think that political|religious|sexual 
propaganda belongs to Debian (it's an operating system and 
environment), I feel I'm not entitled to ask for pulling it out (freedom 
of speech, remember ? Fortunately, that entails freedom of not hearing). 
After all, some people might argue that they can't function properly 
without their weekly|daily|hourly biblical fix, and who am I to tell 
them no ?

> 4. does it respect basic democratic values?
NOT agreed : freedom of speech (which IS a democratic value, maybe THE 
democratic value..) implies ALSO feedom to speak against democracy (and 
ENTAILS freedom to speak FOR democracy. That's debate vs censorship, 
guys !). See Voltaire for further explanations.

> 5. does it respect other people's belief and personallity?
NOT agreed ! Some people's belief and|or values may be, in my not so 
humble opinion, a serious impediment to fundamental rights and freedoms 
; I want to be free to tell why and how much I despise such beliefs and 
values (freedom of speech again, guys !).

> Personally, I find Bellamy's pictures quite artistic and not
> aggressive, but I would say, Women on the list should decide on this
> one (criteria 5).
Bloody NOT agreed : I do not agree to give censor's scissors to ANYONE, 
male or female. The so-called "political correctness" is, IMHO, a 
bigotry as bad as or worse than any other.

Note of interest : this kind of issues comes up regularly  on Debian 
lists. May I point out that this way of making big issues of 
sex-(semi-)related points seems to emanate mainly from citizens of one 
country where  the dominant opinion seems to be that morals is something 
people wear about 8 inches below their navels ? Debian might fare much 
better if its members who happen to be citizens of the U f*ck*ng S of A 
rememeber sometimes that they are *not* center and moral arbiter of the 
world... The same can be told of (semi-) legal concerns, which have no 
relevance outside the US : insisting that Debian should cater to any 
possible foolish demands of an US attorney|sycophant is at best 
provincialism, at worst parochialism.

Sincerely,
Emmanuel Charpentier
PS : I'm not on the list, and not following it on a regular basis. 
Should you want to react, please Cc me...		EC

Re: Bug#282742: Move daily find run later

[Andreas Metzler]

On 2004-12-07 Stephen Gran <[EMAIL PROTECTED]> wrote:
>> On 2004-11-24 Martin Schulze <[EMAIL PROTECTED]> wrote:
>>> Package: findutils
 [...]
>>> It would be nice if the daily find run could be moved behind the
>>> logrotate and sysklogd runs (maybe as zz_find)
[zz_find is ugly]
[...]
> No, I was thinking that since findutils is both Essential and Priority:
> Required, this one job could be special-cased, not that there should be
> general support for doing this sort of thing all over the place.  I
> realize that that's the kind of thing that 'opens up the door' so to
> speak.  Perhaps that by itself points to my idea being a bad one.  It
> was just a thought, and probably a beer-fueled one at that.  

> I was sort of thinking along the lines of "there are some things that
> cron does on every sytem, since those jobs are installed by essential
> packages - wouldn't it be cleaner to integrate them into cron and let
> cron do the sorting, rather than having to do naming hacks?"
[...]

I see. I think the premiss does not apply: While findutils is installed
on every debian system, the cronjob does not run on everybody's
system, many users choose to disable it.

Anyway the solution seems to be overengineered for the problem at
hand. I have yet to decide whether 
* I'll close the bugreport with "request denied"
or
* go for zz_find or something like that anyway and get being crucified
  by anybody who has been able to preserve a sense of aesthetics.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file

[martin f krafft]

also sprach Scott James Remnant <[EMAIL PROTECTED]> [2004.12.08.0909 +0100]:
> Generally the dpkg-* namespace is reserved for features that are
> intended for integration into dpkg at some point.

well, by all means then. If dpkg-repack and dpkg-www are intended
for integration into dpkg, then reversion should be too.

I really think reversion should be available.

> Can you please use deb-reversion instead?

I could, and I do not have a preference. What do others say?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file

[Scott James Remnant]

On Tue, 2004-12-07 at 18:13 +0100, martin f krafft wrote:

> I needed a tool to change the version number of DEB files after
> repacking them with dpkg-repack. So I wrote one. Very simple, does
> not really warrant its own package, but devscripts is also not
> really the place for it. It is unlikely to become part of
> dpkg-repack, though you never know (see #284086).
> 
Generally the dpkg-* namespace is reserved for features that are
intended for integration into dpkg at some point.

Can you please use deb-reversion instead?

Thanks,

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Steve Langasek]

On Tue, Dec 07, 2004 at 11:17:46AM -0300, Fabricio Cannini wrote:
>  --- Michelle Konzack <[EMAIL PROTECTED]>
> escreveu: 
> > Am 2004-12-07 10:39:42, schrieb Fabricio Cannini:

> > > Me wonders if simply NOT installing hot-babe
> > > wouldn't fix this.
> > > IMO Seems to be the easiest solution.

> > In theory !  In many countries it is illegal
> > to have some stuff on CD or other Media.

> > > Don't put it on the CD!!

> > And WHO stores the CD-Images ?

> Servers located on coutries that do not have such
> prohibitions would store these packages.
> I'm talking about NOT putting such packages
> in the official medias (CDs, .iso, etc).

I don't think this is a very useful compromise.  If a package is going to be
included in the Debian archive, it should also be included in the official
Debian CD sets.  I think it's a good idea to provide enough metadata in the
archive to let people build localized CD sets that are legal in their
jurisdiction, but I don't think we should be excluding any Debian packages
from official CD sets -- if there are reasons that we can't distribute a
package in main as part of our CD images, we shouldn't be distributing it
from the mirrors either.

ObRC: #245810

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Is Debian a common carrier? Was: package rejection

[Christian Perrier]

Quoting Ron Johnson ([EMAIL PROTECTED]):

> very strict regarding anything regarding Nazism.

s/Nazism/Crimes against Mankind (or whatever it should be properly
called in English...original version is "apologie de crimes contre
l'humanité")

Re: menu-method for .desktop files?

[Andreas Tille]

On Wed, 8 Dec 2004, Bill Allombert wrote:
So we could:
move kdm:/usr/share/apps/kdm/sessions/
to   menu-xdg:/usr/share/xdg/sessions/
Perhaps a stupid question because I do not understand all this menu stuff:
Would this (together with Gnome 2.8) fix the user menus in Gnome???
This would be reall great for Sarge release!
Kind regards
 Andreas.
--
http://fam-tille.de