SVG icons

[James A. Treacy]

SVG use is increasing and I have seen nothing in Debian about how they
should be handled. So,

What is the proper way to handle svg icons?
For example, where should they be placed?
How well are they supported?
Should a non-svg icon also be included?

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

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

[Joel Aelwyn]

On Tue, Dec 07, 2004 at 02:36:35PM -0600, Manoj Srivastava wrote:
> On Tue, 07 Dec 2004 11:41:42 -0800, Bruce Perens <[EMAIL PROTECTED]> said: 
> 
> > I don't think we have the slightest chance of proving to any court
> > that Debian is a common carrier, given the several inches of policy
> > manual that specify the nature of the content, etc.
> 
>   Say what? Where is this policy that specifies on the nature of
>  content? I see a technical policy that specifies on how something is
>  packaged, but nothing at all that states what the content may be. The
>  closes I can see is stating what licese something is released under.
> 
>   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.
> 
>   manoj

I work for one of the prime examples of a common carrier (and in fact,
one of very few proven by case law): a former Regional Bell Operating
Company (RBOC) / current Incumbent Local Exchange Carrier (ILEC) with a
Long-Distance affiliate. FCC stamped, approved, and intended. Or, in short,
(a) the Telephone Company.

The rules around what constitutes a CC are *very* thorny, and it's very
easy to screw up (and very painful to do so, as well, due to the liability
issues). But the primary set of conditions are as follows:

* You must carry traffic between points for third parties (with narrow
  exceptions for control traffic, any traffic you origionate or receive, you
  are liable for as a normal sender/receiver).

* You may not choose to carry, or not carry, traffic on any basis except
  capacity to do so (note that your contract with a customer can limit
  capacity available to them). The key point here is that you not only
  can't make judgement calls on whether to carry or not carry something
  based on signal content, in general you can't even LOOK at the signal
  content. About the only exception to this is routing information
  related to the traffic (for the obvious reason that you have to know
  where to send it, and said content is thus implicity directed to you as the
  carrier).

* In general, you are heavily restricted on what criteria you may apply
  when deciding who will be a customer in the first place; "common" is
  the important word here, with it's implication that you provide a
  service to the commons, and that denial of said service requires a
  reasonable justification (such as failure to pay, or an expectation of
  an inability to pay, for the service).

None of this is legal advice in the slightest; if you want that, in regards
to common carriers, you're going to be paying very specialized lawyers a
very large amount of money.

The fact that many ISPs have networks that can, in theory, operate as
"common carriers" (if you do routing purely on traffic routing data, and
utterly ignore both content, and consequences of delivering the content),
does not mean they qualify (as has been pointed out, so far no case law has
established them as such, and it appears to be running the other direction,
for the most part). Most ISPs run enough filtering simply as a requirement
to be able to move traffic at all that they are worlds away from CC status.

In my estimation (based primarily on having worked for national, regional,
and local ISPs, and a telco, including all of the big lengthy legal
warnings and requirements about what one can do or not do when dealing with
customers or their data), Debian isn't even playing the same *sport*, much
less is it in the ballpark - and it doesn't want to be, either.

You could argue that an archive which accepted uploads of DEB packages from
anyone at all, with no review and only automated enforcement of certain
base sanity checks such as "Is it a well-formed DEB package" - *not* "does
it meet the following policies" - could qualify as a CC, but frankly, the
term was never meant to be applied to such a beast, and I strongly suspect
the US Court system would take note of that when deciding. And it would be
a damned useless archive anyway, so.
-- 
Joel Aelwyn <[EMAIL PROTECTED]>   ,''`.
 : :' :
 `. `'
   `-


signature.asc
Description: Digital signature

Re: Duelling banjos or how a sane community goes crazy

[Marcelo E. Magallon]

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, 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.
 
 It's a pitty that Godwin's Law has fallen in such a state of
 misunderstanding.  Using the word Nazi does not end a thread.  Talking
 about Nazi or National Sozialismus does not end a thread.  References
 to those concepts do not automatically end a thread.  Godwin's Law is
 about degradation in S/N: a thread will degrade to the point where it's
 only noise, and reaching this point it dies.  Now it's up to you to
 find out what 'noise' means in this particular case.

 > I hope all you people are aware that you are causing a new duelling
 > banjo case and helping out Google to connect Debian with hot-babes.

 Actually I don't find it that bad.  Between slowly fixing stuff in my
 packages and trying to catch up with several debian mailing lists, the
 hot-babe thread has proven rather amusing[0].  If two years from now
 some teen googles for "hot babe" and lands up on Debian's homepage, why
 is it bad?

 >   3. Go to debian-curiosity with mails which do not belong to
 >  debian-devel.

 debian-curiosa is neither a garbage dump nor a place where you can
 badmouth other people, as some folks seem to think, and the hot-babe
 thread really has no place there.

 Marcelo

 [0] Completely OT: I find it rather hard to beleive that there are
 people who actually hold some of the opinions that I've read so
 far.  Currently the "Parlament" of my country is discussing the
 passing of a law which pushines several forms of abuse of women
 *by* men by not the same forms of abuse of men by women.  Ignoring
 the fact that existing law already refers to and punishes such
 actions *and* that it goes directly against our Constitution, this
 particular law has some people rather tickled, including myself: it
 is hard to beleive that at the dawn of the XXI century, there's
 still people out there who approach the "gender" problem in this
 way.  You just can't solve a gender problem by creating more
 differentiation.

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

[Andrea Bedini]

Il giorno mar, 07-12-2004 alle 18:37 +, Andrew Suffield ha scritto: 
> > This is not the case: one member of a community chooses to do something
> > on which community doesn't agree. So community decides to not follow his
> > member and *let him do what he wants by his own*. Debian should not do
> > everything a single developer wants to do; as a community we have to
> > find a general consensus on our policy.
> 
> That's censorship. Know what you're advocating, and consider its
> implications.

First: You need to understand that nobody stop you to do anything by
your own. Make your debs and put in your homepage, take your
responsibilities it's ok. This does not imply I can't press our
community to exclude distributing that package (we've done the same
thing in other cases)

Second: Please justify what you say when reply.

2Â again.

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

[Ron Johnson]

On Tue, 2004-12-07 at 16:48 -0800, Bruce Perens wrote:
> Goswin von Brederlow wrote:
> > But that would not include any debian mirror, they would be common carrier?
> >   
> 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.

But, of course, all this is US law.  French law, for instance, is
very strict regarding anything regarding Nazism.

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

After seeing all the viruses, trojan horses, worms and Reply
mails from stupidly-configured anti-virus software that's been
hurled upon the internet for the last 3 years, and the time/money
that is spent protecting against said viruses, trojan horses &
worms, I can only conclude that Microsoft is dangerous to the
internet and American commerce, and it's software should be
banned.



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

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

[Bruce Perens]

Goswin von Brederlow wrote:

  But that would not include any debian mirror, they would be common carrier?
  

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.

    Thanks

    Bruce




smime.p7s
Description: S/MIME Cryptographic Signature

RE: charsets in debian/control

[Julian Mehnle]

Thaddeus H. Black wrote:
> 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.

Pardon me, but I only know 18 of the 40 items you mentioned, but I don't
have a problem writing software for Debian or Linux in general.

(Some) developers having to learn (parts of) Unicode is not a _general_
problem, not the least because many already know it.  It might be a
problem for _you_in_particular_, because you do not know it and don't want
to learn it.

But that isn't a very good argument against applying a perhaps somewhat
complex technology to Debian that's well suited for the job.  Especially
since many tools that today can't handle multibyte encodings
(UTF-8/Unicode in particular) yet, will _have_to_ support it at some time
in the future anyway.  BTW, the understanding of Unicode isn't required
for most tools, mostly the understanding of UTF-8 is sufficient, and UTF-8
is trivial.

> UTF-8 is neat, but I do not really like Unicode (you may have noticed
> this).

You might like Bytext[1] better then.  SCNR ;-)

Seriously, I get the impression you don't like Unicode because _you_ don't
need it.

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

No, I wouldn't.

References:
 1. http://www.bytext.org

Re: menu-method for .desktop files?

[Bill Allombert]

Hello,

I have discussed on IRC with Chis Cheney (menu-xdg/KDE maintainer)
and we have a different plan:

kdebase include .desktop files for wm that are translated and we will
not have time to move the translations to the menu system before
sarge release, so it seems better to keep these .desktop files but 
move them (to menu-xdg or somewhere else) so that both GDM and KDM
can use them.

So we could:
move kdm:/usr/share/apps/kdm/sessions/
to   menu-xdg:/usr/share/xdg/sessions/

and change both gdm and kdm to depend on menu-xdg and use that
directory.

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

Imagine a large red swirl here. 

Re: Depending on Virtual Packages (Public Service Announcement)

[Paul Hampson]

On Tue, Dec 07, 2004 at 09:45:33PM +, Ari Pollak wrote:
> Daniel Burrows  debian.org> writes:
> >   When your package Depends upon or Recommends a pure-virtual package P, 
> > you 
> > should always OR the dependency with a dependency on something that 
> > provides 
> > P,

> As a totally offtopic suggestion, how come APT doesn't handle virtual packages
> the way Fink does, where the user gets to choose which virtual package to
> install to satisfy the dependency?

Probably because apt is a back-end (nominally) and so doesn't do a lot
of questioning. Certainly things like aptitude, synaptic, dselect etc.
should. And possibly they do. ^_^

-- 
---
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

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

[Goswin von Brederlow]

Bruce Perens <[EMAIL PROTECTED]> writes:

> 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.
>>
>
> A common carrier carries content from one external point to another as
> directed by the parties exchanging the content without any
> modification of that content. The fact that we assemble the content
> into an aggregate work is sufficient to say we are not a common
> carrier. That aggregate work is functional in a way that no individual
> package is, and putting it together constitutes an independent work of
> creation, carried out by the organization. The vast body of Debian
> policy is concerned with assembling that content into the aggregate
> work, it specifies many details about the content meant to make it
> operate when assembled together.

But that would not include any debian mirror, they would be common
carrier?

MfG
Goswin

Re: charsets in debian/control

[Petter Reinholdtsen]

[Thaddeus H. Black]
> UTF-8 is neat, but I do not really like Unicode (you may

[Marco d'Itri]
> Actually you do not even understand it, because this sentence is
> meaningless.

Perhaps he is aware of the difference between Unicode and ISO-10646?
UTF-8 is an encoding of ISO-10646.

Re: menu-method for .desktop files?

[Peter Collingbourne]

On Tue, Dec 07, 2004 at 03:35:45PM +0100, Bill Allombert wrote:
> On Mon, Dec 06, 2004 at 11:47:16PM +, Peter Collingbourne wrote:
> > 
> > This is a good start, now the question is how to integrate this into
> > the system.
> > 
> > To tell you the truth I have also been working on a similar thing
> > separately (tested).  My version is attached and it is up to someone to
> > decide which should be used.
> 
> Please use mine. It has proper quoting and is in line with the other xdg
> methods. (I am the menu maintainer :).

Sure, it is no big deal but it needs some features from
my version which may be necessary: the definition of
ConfigExec/ConfigTryExec/SessionManaged for one (see later).

> 
> > I believe the files should go into /etc/X11/sessions for two reasons:
> > 1. at least one of the display managers already looks in there by
> >default (gdm)
> > 2. it is in common with the majority of the other menu-methods which
> >write to somewhere in /etc
> 
> It is common but this is a (mild) FHS violation: autogenerated files
> belong to /var, not /etc. However putting them in /usr would be a serious
> FHS violation, so I can live with /etc.

I agree... we can move to /var when the rest of the menu-methods do :)

> 
> > Also five things need to be done in order to add this feature to the
> > system:
> > 
> > 1. Create a package for the menu-method
> 
> I suppose we can include it in the menu-xdg package.

Ok.

> > 4. Change the following packages so that they do not install a .desktop
> >file to /usr/share/xsessions (to avoid duplicate entries in the list):
> > gnome/gnome-session x11/blackbox x11/fluxbox x11/fvwm x11/fvwm-gnome
> > x11/icewm x11/icewm-experimental x11/icewm-lite x11/openbox x11/wmaker
> > x11/xfce4-utils
> 
> I am not sure about that part. Programs messing with .desktop file need to be 
> smart enough to handle conflicts/override, else it is a clear abuse of
> the .desktop specification.
...
> The best way to deal with that is to reduce the changes to the minimum
> that achieve the goal. If you can avoid the requirement of removing
> existing .desktop file, we will have 90% less work. 

How would you suggest we adapt our method to deal with this?  Possibly to
check if an existing .desktop is present in /usr/share/xsessions from
the same package.  I believe install-menu would allow you to express that
but it seems like an ugly hack to me and might not actually be possible.
In the worst case the method could be rewritten in Perl or something
(the language of ugly hacks :).

> > Another question is: should this be mentioned in section 11.8.4 of the
> > policy manual?
> 
> Certainly not yet.

I feel there are some decisions to be made at this point:
- should we deprecate /usr/share/xsessions/* files?
- should we define a menu attribute for ConfigExec/ConfigTryExec and
  SessionManaged?

some of which will affect the implementation of our menu-method.
> 
> > I am wondering whether I should go through the procedures necessary to
> > become an official Debian developer.
> 
> Given the delay involved, that will not help.

I believe if I am going to continue development (in general, not on this
particular feature) it would be worthwhile for me to become one.  I don't
just want to become a 'cheerleader' and put my coding skills to waste :)

-- 
Peter

Re: Depending on Virtual Packages (Public Service Announcement)

[Ari Pollak]

Daniel Burrows  debian.org> writes:
>   When your package Depends upon or Recommends a pure-virtual package P, you 
> should always OR the dependency with a dependency on something that provides 
> P,

As a totally offtopic suggestion, how come APT doesn't handle virtual packages
the way Fink does, where the user gets to choose which virtual package to
install to satisfy the dependency?

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

[Bruce Perens]

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.
A common carrier carries content from one external point to another as 
directed by the parties exchanging the content without any modification 
of that content. The fact that we assemble the content into an aggregate 
work is sufficient to say we are not a common carrier. That aggregate 
work is functional in a way that no individual package is, and putting 
it together constitutes an independent work of creation, carried out by 
the organization. The vast body of Debian policy is concerned with 
assembling that content into the aggregate work, it specifies many 
details about the content meant to make it operate when assembled together.

In addition, there is bug and feature management carried out by the 
project, which is essentially a direction to the maintainer to edit the 
package, and packages are rejected from the whole when they have 
release-critical bugs.

If you sit down and think about the Debian process, I have no doubt that 
you can come up with 10 more of these.

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

   Thanks
   Bruce

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

[Thomas Bushnell BSG]

Russell Coker <[EMAIL PROTECTED]> writes:

> So you have no objections to bestiality web sites then?

The assumption here is that one must either have no objections, or
else have objections and then proceed to object and want things
removed.  Perhaps I have misunderstood you, but there are many who
hold such a view even if you do not, so it's worth addressing.

I do have objections to hot-babe.  I think it's degrading to people I
care about.  So I wouldn't package it.

But that does *not* mean that I think nobody should be allowed to; my
primary concern with respect to Debian is that we follow our actual
policies, and if people want a new policy, they should make it the
usual way.

Debian can choose to publish hot-babe or not; either way I don't care
much about it, except that I would not be willing to package it
myself.

Please don't paint me in a corner by saying that if someone is against
prohibiting a package, it must be because they "have no objections" to
it.

As Manoj has pointed out, many of us have objections to vi also.

Thomas

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

[Will Newton]

On Tuesday 07 Dec 2004 20:26, Manoj Srivastava wrote:

> > I don't think this holds. Censoring is editing for ideological
> > reasons, which is a subset of editing. It has nothing to do with who
> > does it. A censor is a third party, and editor is a third party, at
> > least in literary terms.
>
>  Is removing legal material to protect the viewer from material
>  that is deemed ideologically inappropriate by some considered "
>  editing for ideological reasons"?

It may well be, it could also be editing in the interests of practicality. 

I'm not interested in sophistry. If you want to call it censorship call it 
that, I don't mind. But be aware that it is an emotionally charged word and 
using it pretty much destroys any chance of a reasoned debate.

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

[Ron Johnson]

On Tue, 2004-12-07 at 20:31 +1100, Russell Coker wrote:
> On Tuesday 07 December 2004 11:22, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > On Tue, 2004-12-07 at 10:01 +1100, Brian May wrote:
> > > So are you saying I should take my web pages of my naked dogs down?
> >
> > Depends on who's prurient interests are appealed to by your naked
> > dogs.
> >
> > 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"?

Are you are purposefully misinterpreting what I wrote?

[snip]

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

"Fear the Penguin!!"



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

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

[Manoj Srivastava]

On Tue, 07 Dec 2004 11:41:42 -0800, Bruce Perens <[EMAIL PROTECTED]> said: 

> I don't think we have the slightest chance of proving to any court
> that Debian is a common carrier, given the several inches of policy
> manual that specify the nature of the content, etc.

Say what? Where is this policy that specifies on the nature of
 content? I see a technical policy that specifies on how something is
 packaged, but nothing at all that states what the content may be. The
 closes I can see is stating what licese something is released under.

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.

manoj
-- 
Walking on water wasn't built in a day. Jack Kerouac
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

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

[Manoj Srivastava]

On Mon, 6 Dec 2004 10:32:14 +, Will Newton <[EMAIL PROTECTED]> said: 

> On Monday 06 Dec 2004 10:01, Andrew Suffield wrote:
>> The difference being that editing is a choice made by the person
>> doing the work, while censorship is a choice made by an otherwise
>> unrelated person in the same organisation.
>> 
>> Editing would be if the maintainer decided to remove the
>> package. Censorship is when some other developer tries to force
>> him.

> I don't think this holds. Censoring is editing for ideological
> reasons, which is a subset of editing. It has nothing to do with who
> does it. A censor is a third party, and editor is a third party, at
> least in literary terms.

Is removing legal material to protect the viewer from material
 that is deemed ideologically inappropriate by some considered "
 editing for ideological reasons"?

manoj
-- 
Like all women, she believed that rest and pleasure were bad for
men. Fritz Leiber, _Swords and Ice Magic_
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Is Debian a common carrier? Was: package rejection

[Bruce Perens]

Andrew Suffield wrote:
Also, in much of the civilised world, once you start doing this you
suddenly acquire a legal responsibility to do it *right*, which you
wouldn't have had if you hadn't tried to do it.
 

It's more complicated than that. I think what you are talking about is 
the fact that a common carrier is not responsible for the content that 
it carries. However, if you edit the content you aren't acting as a 
common carrier and then you become responsible for it. Some internet 
providers attempt to act as common carriers, but depending on the 
context courts have ruled that they are not.

I don't think we have the slightest chance of proving to any court that 
Debian is a common carrier, given the several inches of policy manual 
that specify the nature of the content, etc.

   Thanks
   Bruce

Re: Re: RFH: compiling java with kaffe/jikes/ant

[Martin, Rosemary Civ AFCCC/DOMD]

Re: package rejection

[Andrew Suffield]

On Tue, Dec 07, 2004 at 10:10:19AM +1100, Brian May wrote:
> I think it would be better to create a distribution of Debian, where
> applicable, that meets the legal requirements of the given country.
> 
> That way if you do really want to distribute Debian where there are
> laws against XYZ, you can distribute a subset of Debian that doesn't
> {do,use,require,consume,kill,display,say,etc} XYZ.

> This also raises lots of issues, like how to do it with minimum fuss
> and who is legally responsible (if anybody) if mistakes occur.

Also, in much of the civilised world, once you start doing this you
suddenly acquire a legal responsibility to do it *right*, which you
wouldn't have had if you hadn't tried to do it.

Censorship laws are strange like that.

[Not likely to be a problem for us as a project, but it might be for
people who do this sort of thing. Commercial publishers run into this
problem all the time and often decide it's safer not to bother]

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Bug#282742: Move daily find run later

[Stephen Gran]

This one time, at band camp, Andreas Metzler said:
> On 2004-12-07 Stephen Gran <[EMAIL PROTECTED]> wrote:
> > This one time, at band camp, Andreas Metzler said:
> >> On Sat, Nov 27, 2004 at 05:32:20PM +0100, Peter Palfrader wrote:
> >>> On Sat, 27 Nov 2004, Andreas Metzler 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]
> >>> zz_find?  That's a really ugly name.  I'ld rather not have it
> >>> changed if it means living with such a beast.
> 
> >> Have you got any better ideas? Afaik the only possibilty to move
> >> the job is by giving it a name that sorts later.
> 
> > Do the run-parts stuff, and then run this special script in
> > /usr/share last, if it exists.  A little ugly and special case, but
> > I think I'd rather have that than a zz_find script (ick)
> 
> I am not sure I read you correctly. You want cron* to change support
> not only /etc/cron*/ but also
> /usr/share/cron/tabs/pleaserunmeaftercron*?  cu and- already giving up
> on this bugreport -reas

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 am not convinced now that that's either the easiest or the best
approach, though.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

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

[Andrew Suffield]

On Mon, Dec 06, 2004 at 04:51:59AM -0800, Steve Langasek wrote:
> > Editing would be if the maintainer decided to remove the
> > package. Censorship is when some other developer tries to force him.
> 
> If an ftp-master in the course of "doing the work" of processing NEW rejects
> a package, or a member of the release team in the course of "doing the work"
> of preparing the next stable release excludes a package from consideration,
> is this editing, or is it censorship?



All of those things could be either. It is precisely because the
boundaries are not clear that we must stay away from them. That's the
reason why everybody who starts down the path of censorship ends up in
the same place.

> It's extremely frustrating to see so many words spent on the notion of
> "censorship" here.  At the end of the day, Debian, *as an organization*,
> has the right (and responsibility) to decide what it publishes on behalf of
> its member developers, and doing so is *not* *censorship*.

It can be. In the proposed scenario it would be.

> And it's no wonder that Debian is slow to release when people are criticized
> on public lists for showing an interest in the contents and quality of
> packages that aren't theirs; for daring to ask the question, "is this
> something that Debian needs?"

Nobody in this thread has seriously asked that question.

> This discussion shouldn't be about censorship, or other forms of coercion;

Aye, but it is, and that line of thinking needs to be stopped while we
still can. Frankly the package is irrelevant to this discussion, and
the subject line is misleading.

> And contrary to much of
> the rhetoric in this thread, it is possible to think a package like hot-babe
> is a bad idea without wanting to be set up as a censor for all ideas they
> disagree with.

However, it's extremely unlikely that it is possible to ban it for
that reason without going down that path. There's a significant
difference between thinking something is a bad idea and trying to stop
it.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

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

[Andrew Suffield]

On Mon, Dec 06, 2004 at 09:25:31PM +0100, Andrea Bedini wrote:
> Il giorno lun, 06-12-2004 alle 01:49 +, Andrew Suffield ha scritto:
> > Word games. Censorship is when a citizen of one body chooses to have
> > that body distribute something (by being a citizen and distributing
> > it), and another citizen tries to stop them.
> 
> This is not the case: one member of a community chooses to do something
> on which community doesn't agree. So community decides to not follow his
> member and *let him do what he wants by his own*. Debian should not do
> everything a single developer wants to do; as a community we have to
> find a general consensus on our policy.

That's censorship. Know what you're advocating, and consider its
implications.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: charsets in debian/control

[Marco d'Itri]

On Dec 07, "Thaddeus H. Black" <[EMAIL PROTECTED]> wrote:

> UTF-8 is neat, but I do not really like Unicode (you may
Actually you do not even understand it, because this sentence is
meaningless.

-- 
ciao, |
Marco | [9639 coubl1Ib61SmA]


signature.asc
Description: Digital signature

Re: charsets in debian/control

[Thaddeus H. Black]

Steve Langasek writes,

> ... most of the letters you listed here are specific
> to the IPA, which would have no use at all in a
> control file as they're not part of the writing system
> of any natural language.

Ok.

> Encodings and charsets are distinct concepts.  Just
> because the file is specified in UTF-8 *encoding* does
> not mean we suddenly have to start coping with the
> entire Unicode character set.

Right.

> Why, what a lovely straw man you have there.

No comment.

> 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.  Consider.  Is it a
bug if Readline cannot echo full bidirectional input?
If Dselect does not appreciate all the non-spacing
characters?  If Less does not regard Tibetan subjoined
letters?  (This is my Tibetan straw man.)

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

> ... to properly declare the character set on the
> non-ASCII mails you send.

We can perhaps be pardoned for feeling a little grumpy
about this.

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?

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


pgpoTit3xtAci.pgp
Description: PGP signature

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

[martin f krafft]

Package: wnpp
Severity: wishlist

* Package name: dpkg-reversion
  Version : 0.1.5
  Upstream Author : martin f. krafft <[EMAIL PROTECTED]>
* URL : http://madduck.net/~madduck/scratch/dpkg-reversion
* License : Artistic
  Description : change the version of a DEB file

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

Suggestions welcome. Otherwise I will provide a package soon.

According to Goswin, this will also come in handy for the amd64
port.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (600, 'testing'), (98, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-cirrus
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

-- 
 .''`. 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: charsets in debian/control

[Daniel Burrows]

On Tuesday 07 December 2004 10:40 am, Richard Atterer wrote:
> No, you do not have to do this. You can keep working with "char", the
> changes when switching to UTF-8 will mostly have to deal with the fact that
> one Unicode character is represented by more than one char. This means that
> you need to use a different strlen function, take care only to chop strings
> of char at character boundaries, ensure that input strings are actually
> valid UTF-8, etc.

  This might work for programs that relatively blindly manipulate character 
strings and can pass them off to the terminal for processing.  In fact, 
aptitude does a *lot* of processing and formatting of strings internally.  
That means, for instance: splitting strings into words and paragraphs, 
truncating strings, finding out how wide strings are.

  More importantly, it also makes significant (and increasing) use of strings 
annotated with the terminal attributes of each character (think colors, 
bold/reverse video, etc).  Needless to day, it performs all of the above 
operations on those strings as well.

  All of these are impacted by extended charsets: for instance, you need to 
use a different function to find whitespace, and combining characters with 
their attributes requires the use of a structure where an integer previously 
sufficed.  That's not to mention finding the length of a string, which is 
necessary to perform most types of layout.

The changes that are necessary are at least:

  At a minimum, the class used for formatted strings will have to be 
re-targeted to support either formatted wide strings or formatted utf8 
strings.  If wide characters or are not used internally, it is also necessary 
to audit every occurrence of s.size() and check whether the length-in-memory 
or the length-in-characters of the string is being queried.  If neither wide 
characters nor a utf8-specialized basic_string are used, it is necessary to 
audit every string constructor (which might cut a substring) and make sure 
that it doesn't play havoc with utf8 codings.  Every use of isspace() and 
friends will have to be replaced with Unicode-aware equivalents.

  And that's just the problems I can think of off the top of my head.

  It's also necessary to use a completely different set of terminal i/o 
routines, but this is pretty much expected.

  None of these problems are insurmountable, of course, and I know pretty much 
how to solve must of them.  However, it's also true that none of them exist 
*at all* when using iso-8859-1, which is why I object to the comment that 
it's no harder to handle utf8 than iso-8859-1.  (in fact, if your terminal 
speaks iso-8859-1, aptitude will handle it just fine without any changes)

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|  Hi, I'm a .signature virus!  |
|  Copy me into your .signature to help me spread!  |
\ The Turtle Moves! -- http://www.lspace.org ---/


pgpJ6zHEp3AWv.pgp
Description: PGP signature

Re: charsets in debian/control

[Matthew Garrett]

Daniel Burrows <[EMAIL PROTECTED]> wrote:

>   iso-8859-1 is an 8-bit charset, while Unicode is a 32-bit [0] charset. =20
> Storing and manipulating iso-8859-1 strings requires no changes to internal=
>=20
> datatypes (only conversions for input and output); storing and manipulating=
>=20
> Unicode means you have to switch to a completely different set of=20
> string-handling functions for all internal operations.

utf-8 is an 8-bit encoding of unicode, using variable length characters.
Traditional string manipulation routines work fine, except in the case
where you need to know the number of characters rather than the number
of bytes. This is typically not a large number of areas of code.

>   [0] According to the libc manual, only 16 bits have been assigned, but GN=
> U=20
> systems use 32-bit encoding internally if the libc transcoding functions ar=
> e=20
> used.

The libc manual is out of date. We've been using more than 16 bits for a
while.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: charsets in debian/control

[Richard Atterer]

On Tue, Dec 07, 2004 at 10:17:17AM -0500, Daniel Burrows wrote:
> On Tuesday 07 December 2004 12:44 am, Peter Samuelson wrote:
> > And if the app already deals with charset conversions but assumes
> > iso-8859-1 input, then it's trivial to fix it to assume utf-8 input.
> 
>   This is not true.
> 
>   iso-8859-1 is an 8-bit charset, while Unicode is a 32-bit [0] charset.  
> Storing and manipulating iso-8859-1 strings requires no changes to internal 
> datatypes (only conversions for input and output); storing and manipulating 
> Unicode means you have to switch to a completely different set of 
> string-handling functions for all internal operations.

No, you do not have to do this. You can keep working with "char", the
changes when switching to UTF-8 will mostly have to deal with the fact that
one Unicode character is represented by more than one char. This means that
you need to use a different strlen function, take care only to chop strings
of char at character boundaries, ensure that input strings are actually
valid UTF-8, etc.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: charsets in debian/control

[Daniel Burrows]

On Tuesday 07 December 2004 10:17 am, Daniel Burrows wrote:
> complex replacement string class

  Admittedly, "complex" might (hypothetically) be a bit of an exaggeration.

  :P

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
| You are in a maze of twisty little signatures, all alike. |
\ Evil Overlord, Inc: http://www.eviloverlord.com --/


pgpdSwtA0vgWt.pgp
Description: PGP signature

Re: charsets in debian/control

[Daniel Burrows]

On Tuesday 07 December 2004 12:44 am, Peter Samuelson wrote:
> > Defining the character set as utf-8 means that any non-unicode
> > capable application is going to have issues, yes.
>
> Postulate an app that is ignorant of character sets - we'll call it
> "aptitude".  Fixing it to make it accept utf-8 and spit out the correct
> encoding for its LC_CTYPE is no harder than fixing it to make it accept
> iso-8859-1 and spit out the correct encoding for its LC_CTYPE.
>
> And if the app already deals with charset conversions but assumes
> iso-8859-1 input, then it's trivial to fix it to assume utf-8 input.

  This is not true.

  iso-8859-1 is an 8-bit charset, while Unicode is a 32-bit [0] charset.  
Storing and manipulating iso-8859-1 strings requires no changes to internal 
datatypes (only conversions for input and output); storing and manipulating 
Unicode means you have to switch to a completely different set of 
string-handling functions for all internal operations.

  In C++ you might be able to partly finesse this by creating a replacement 
string class, but if our program (call it "aptitude") is already using a 
complex replacement string class for some tasks, and this class assumes that 
characters are 8 bits wide, this might be a slightly non-trivial task, 
especially compared to handling iso-8859-1.  Hypothetically speaking. :-)

  On the other hand, once the program is using Unicode internally, taking 
iso-8859-1 as input and producing it as output should be no problem.

  Daniel

  [0] According to the libc manual, only 16 bits have been assigned, but GNU 
systems use 32-bit encoding internally if the libc transcoding functions are 
used.

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|  swapon /dev/ram  |
\--- News without the $$ -- National Public Radio -- http://www.npr.org ---/


pgpuGzR6Woq1o.pgp
Description: PGP signature

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

[Russell Coker]

On Wednesday 08 December 2004 01:09, Frank Küster <[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?
> >
> > Some years ago a server in Amsterdam that I was running was overloaded
> > due to thousands of downloads per hour of a bestiality AVI.  I removed
> > the site due to technical reasons (the entire ISP ran slow because of all
> > the bestiality downloads).
>
> Did this AVI really show dogs copulating with each other (not pervert
> humans with a dog)? And people downloaded this in masses? The world is
> strange.

It involved a donkey.  As far as I recall not enough of the woman was visible 
to be regarded as porn if it wasn't for what she was doing with the donkey.  
But my recollection isn't particularly clear and I never looked at it too 
closely.

The only reason I watched it is that I forced every manager in the area to 
watch it in it's entirity to try and force them to give me permission to 
delete it (I am still surprised that so many managers were prepared to watch 
that AVI right through instead of granting me permission to delete it).

Bestiality is legal in the Netherlands so I had to establish a new company 
policy on deleting commercial web sites that caused too much traffic and cost 
too much.  It was a free web server - people who want to run commercial porn 
sites are supposed to pay for their bandwidth.


Americans want to be moral so they ban hard-core porn.  So the hard-core porn 
sites get run in places like the Netherlands and cater to an American 
audience.  Americans then say that people who live in the Netherlands are 
perverted because they allow Americans to do what they want and make money 
from it.  The world is indeed strange.

-- 
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: menu-method for .desktop files?

[Bill Allombert]

On Mon, Dec 06, 2004 at 11:47:16PM +, Peter Collingbourne wrote:
> On Mon, Dec 06, 2004 at 07:34:45PM +0100, Bill Allombert wrote:
> > Hello,
> > I have written the menu method, but I did not test it.
> > 
> > Please find it here: 
> > 
> > You will need to change 
> > rootprefix = "/var/lib/xsessions";
> > to
> > rootprefix = "/usr/share/xsessions";
> > 
> > until display manager are able to read /var/lib/xsessions.
> 
> This is a good start, now the question is how to integrate this into
> the system.
> 
> To tell you the truth I have also been working on a similar thing
> separately (tested).  My version is attached and it is up to someone to
> decide which should be used.

Please use mine. It has proper quoting and is in line with the other xdg
methods. (I am the menu maintainer :).

> I believe the files should go into /etc/X11/sessions for two reasons:
> 1. at least one of the display managers already looks in there by
>default (gdm)
> 2. it is in common with the majority of the other menu-methods which
>write to somewhere in /etc

It is common but this is a (mild) FHS violation: autogenerated files
belong to /var, not /etc. However putting them in /usr would be a serious
FHS violation, so I can live with /etc.

> Also five things need to be done in order to add this feature to the
> system:
> 
> 1. Create a package for the menu-method

I suppose we can include it in the menu-xdg package.

> 2. Make gdm and kdm depend on it (either that or recommend it and add
>it to the list of packages installed by the desktop task)
> 3. Change kdm so it looks in /etc/X11/sessions by default for its
>session files (attached is a patch (tested) which can be applied to
>kdebase_3.2.2-1)
> 4. Change the following packages so that they do not install a .desktop
>file to /usr/share/xsessions (to avoid duplicate entries in the list):
> gnome/gnome-session x11/blackbox x11/fluxbox x11/fvwm x11/fvwm-gnome
> x11/icewm x11/icewm-experimental x11/icewm-lite x11/openbox x11/wmaker
> x11/xfce4-utils

I am not sure about that part. Programs messing with .desktop file need to be 
smart enough to handle conflicts/override, else it is a clear abuse of
the .desktop specification.

> 5. Make the ksmserver package from KDE install a menu item rather than a
>.desktop file (also in the patch file).
> 
> I know this is a lot of wide-sweeping changes to the system (especially
> as they are being suggested by a newcomer to the Debian devel process) but
> I believe once these items are done we will have a more consistent system.

The best way to deal with that is to reduce the changes to the minimum
that achieve the goal. If you can avoid the requirement of removing
existing .desktop file, we will have 90% less work. 
If it is possible to fix the problem while only changing kdebase,
then we can succeed in a reasonnable amount of time.

> Another question is: should this be mentioned in section 11.8.4 of the
> policy manual?

Certainly not yet.

> I am wondering whether I should go through the procedures necessary to
> become an official Debian developer.

Given the delay involved, that will not help.

> diff -Nur kdebase-3.2.2-orig/debian/kdm.install 
> kdebase-3.2.2/debian/kdm.install
> --- kdebase-3.2.2-orig/debian/kdm.install 2004-04-03 08:53:14.0 
> +0100
> +++ kdebase-3.2.2/debian/kdm.install  2004-12-06 20:48:06.0 +
> @@ -19,51 +19,6 @@
>  debian/tmp/usr/share/apps/kdm/pics/users/default1.png
>  debian/tmp/usr/share/apps/kdm/pics/users/default2.png
>  debian/tmp/usr/share/apps/kdm/pics/users/root1.png
> -debian/tmp/usr/share/apps/kdm/sessions/9wm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/aewm++.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/aewm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/afterstep.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/amaterus.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/amiwm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/asclassic.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/blackbox.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/cde.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/ctwm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/cwwm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/enlightenment.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/evilwm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/fluxbox.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/flwm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/fvwm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/fvwm95.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/gnome.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/golem.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/icewm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/ion.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/kde.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/larswm.desktop
> -debian/tmp/usr/share/apps/kdm/sessions/lwm.desktop
> 

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

[Michelle Konzack]

Am 2004-12-07 11:17:46, schrieb Fabricio Cannini:

> I've already seen long, enduring, die-hard threads,
> but not like this one.

I was soe day offline, and do not know,
how many messages this thread have
but I think more then 600.

And in how many days...

> Best to you.

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: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Frank Küster]

Russell Coker <[EMAIL PROTECTED]> wrote:

> On Tuesday 07 December 2004 11:22, 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?
>
> Some years ago a server in Amsterdam that I was running was overloaded due to 
> thousands of downloads per hour of a bestiality AVI.  I removed the site due 
> to technical reasons (the entire ISP ran slow because of all the bestiality 
> downloads).

Did this AVI really show dogs copulating with each other (not pervert
humans with a dog)? And people downloaded this in masses? The world is
strange.

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

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

[Fabricio Cannini]

 --- 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).
 
> > Do you want this pkg?? apt-get it!!
> 
> Right...
> 
> But I prefet to have "difficult" packages on a
> seperated Server.

Me too (that's what i said above).

I've already seen long, enduring, die-hard threads,
but not like this one.

Best to you.





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

Re: charsets in debian/control

[Eugeniy Meshcheryakov]

07.12.2004 Ð 13:33 +0100 Maciej Dems ÑÐÐ(-ÐÐ):
> Patrze w ekran, a to Roger Leigh pisze do mnie:
> > - No UTF-8 console keymaps
> > - Some broken libraries e.g. GTK+ 1.2 [obsolete]
> > - I can't paste UTF-8 into emacs (perhaps a problem in my .emacs)
> 
> - mc making mess with its frames
> 
Add dselect and aptitude here.

-- 
Eugeniy Meshcheryakov

Kyiv National Taras Shevchenko University
Information and Computing Centre
http://icc.univ.kiev.ua


signature.asc
Description: Digital signature

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

[Michelle Konzack]

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 ?

> Do you want this pkg?? apt-get it!!

Right...

But I prefet to have "difficult" packages on a seperated Server.

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: Bug#282409: ITP: mozilla-firefox-locale-pt-br -- Firefox Localization Package to Brazilian Portuguese.

[Javier Fernández-Sanguino Peña]

On Thu, Nov 25, 2004 at 07:28:39AM +0100, Christian Perrier wrote:
> > > Can you indeed give us here the list of mozilla-firefox-locale-xx
> > > packages your package currently generates?
> > 
> > For the moment:
(..)

There is no es_ES. I believe there were mozilla-firefox-locale-es-es 
packages at some point in the archive. Isn't the translation available 
upstream?

Regards

Javier


signature.asc
Description: Digital signature

Bug#283578: ITP: hot-banknote -- monetary graphical system activity monitor

[Ulf Härnhammar]

> Warning: the 100 French Francs banknote displays the 'Liberty Leading
> the People' by Eugène Delacroix which picture the Liberty as a
> bare-breasted woman.

That's from the fine arts world, so completely different rules apply..

-- 
Ulf Harnhammar
http://www.advogato.org/person/metaur/

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

[Fabricio Cannini]

 --- Everton da Silva Marques
<[EMAIL PROTECTED]> escreveu: 
> On Wed, Dec 01, 2004 at 06:12:21PM +0100, Michelle
> Konzack wrote:
> > 
> > Am 2004-12-01 13:16:11, schrieb Fernanda Giroleti
> Weiden:
> > > 
> > > First of all, it's a sexist package, sure.
> Putting a program on Debian
> > > in which you have pictures of nude women is VERY
> agressive to the most 
> > > women. Yes, it's agressive to me.
> > 
> > And I was thinking, I am alone...

> It's VERY oppressive to force hot-babe out of
> Debian because of personal feelings about nudity.
> It's pure anti-speech insanity leading the way
> to socialism.

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

Don't put it on the CD!!
Do you want this pkg?? apt-get it!!



__
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

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

[Russell Coker]

On Tuesday 07 December 2004 11:22, Ron Johnson <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-12-07 at 10:01 +1100, Brian May wrote:
> > So are you saying I should take my web pages of my naked dogs down?
>
> Depends on who's prurient interests are appealed to by your naked
> dogs.
>
> 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?

Some years ago a server in Amsterdam that I was running was overloaded due to 
thousands of downloads per hour of a bestiality AVI.  I removed the site due 
to technical reasons (the entire ISP ran slow because of all the bestiality 
downloads).

The same server had the same problem with pictures of Britney Spears, should I 
have removed the Britney pictures because they were obscene (no prises for 
guessing what they were used for) but left the animal sex pictures?

-- 
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: charsets in debian/control

[Maciej Dems]

Patrze w ekran, a to Roger Leigh pisze do mnie:
> - No UTF-8 console keymaps
> - Some broken libraries e.g. GTK+ 1.2 [obsolete]
> - I can't paste UTF-8 into emacs (perhaps a problem in my .emacs)

- mc making mess with its frames

Maciek

-- 
M.Sc. Maciej Dems  [EMAIL PROTECTED]
-
C o m p u t e r   P h y s i c s   L a b o r a t o r y
Institute of Physics,Technical University of Lodz
ul. Wolczanska 219, 93-005 Lodz, Poland, +48426313649

Re: Debian package selection depending on user location/belief/society(was bug #283578 hot-babe (AGAIN :-)))

[Will Newton]

On Tuesday 07 Dec 2004 01:51, Stephen Gran wrote:

> I have to say, this is ridiculous.  Do I, living in the US or Europe,
> have to take into account the laws about sensuality (note, not sexuality,
> since these pictures barely qualify for that word) that mirror operators
> in Iran or Saudi Arabia have?  I can not and will not learn all the laws
> of every country on Earth, and the project can not survive if we have
> to meet all of them.  This whole thread is a waste of space looking for
> a problem.  If there is a demonstrable law being broken by a cartoon,
> then warn the mirror operator in the respective localities, if you're
> worried about it.

I'm sure they'll be super happy after being "warned". What do they *do* about 
it once they have been warned?

> If the package offends you, don't install it - it's not like it's a base
> package.  If you are seriously worried about legal repercussions, do the
> homework, and warn the people who could be affected.  We already
> distribute so many offensive things (purity, fortunes-off, kjv, kernel
> sources, etc.) that getting upset about pictures strikes me as silly.
> IANAL, so I have no idea of the difference between distributing foul
> language or sexual written content to minors and distributing naked

Not to point out the obvious, but "foul language" is dependant on the language 
you speak, so most countries are unlikely to be offended by the Linux kernel.

Re: charsets in debian/control

[Andreas Barth]

* Roger Leigh ([EMAIL PROTECTED]) [041207 00:40]:
> I think going to UTF-8 as the default locale charmap for all locales
> is a feasable goal for etch, as is recoding everything to UTF-8 (where
> it makes sense).

"feasable goal" and "etch" are the magic words I think: I agree on that,
but I don't want to claim that we are already there today.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Bug#282742: Move daily find run later

[Andreas Metzler]

On 2004-12-07 Stephen Gran <[EMAIL PROTECTED]> wrote:
> This one time, at band camp, Andreas Metzler said:
>> On Sat, Nov 27, 2004 at 05:32:20PM +0100, Peter Palfrader wrote:
>>> On Sat, 27 Nov 2004, Andreas Metzler 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]
>>> zz_find?  That's a really ugly name.  I'ld rather not have it changed if
>>> it means living with such a beast.

>> Have you got any better ideas? Afaik the only possibilty to move the
>> job is by giving it a name that sorts later.

> Do the run-parts stuff, and then run this special script in /usr/share
> last, if it exists.  A little ugly and special case, but I think I'd
> rather have that than a zz_find script (ick)

I am not sure I read you correctly. You want cron* to change support
not only /etc/cron*/ but also
/usr/share/cron/tabs/pleaserunmeaftercron*?
 cu and- already giving up on this bugreport -reas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian

[Glenn Maynard]

On Tue, Dec 07, 2004 at 10:04:54AM +0100, David Weinehall wrote:
> On Mon, Dec 06, 2004 at 04:35:41PM +1100, Brian May wrote:
> > > "Tollef" == Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> > 
> > Tollef> | Finally, I would like to commend Michelle Konzack for
> > Tollef> standing up on | this issue. Debian should never promote |
> > Tollef> degradation/abuse/exploitation, in any form, of females
> > Tollef> (or males or | blacks or whites or whatever).
> 
> Be careful with your attributions, that was written by Martin Olsson,
> not Tollef Fog Heen.

I think the only bottom-quoting scheme I've seen which is more annoying
than that is bare indentation (which only RMS seems to use) ...

-- 
Glenn Maynard

Re: Duelling banjos or how a sane community goes crazy

[Martin Schulze]

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.
> 
> I hope all you people are aware that you are causing a new duelling banjo
> case and helping out Google to connect Debian with hot-babes.

Honestly, other people are doing this on intention by using false keywords
and other techniques to fool search engines.  We only contribute to normal
flamewars.

> even if you do not understand German: I would love if Debian would
> become famous for releasing Sarge instead of discussing about
> hot-babes.

It is known that the Debian community is very vibrant and that it
doesn't avoid flamewars and hot discussions (even on "hot" topics).
Even though if it would be better to invest the energy in fixing
RC bugs instead of contributing to these threads, we all know that
people are unlikely to change.

> I have not read the contents of most of all these mail but even
> Godwin's law was issued.

The the discussion has reached its final state and will naturally
end, no?

>   2. If you feel obliged to continue to a thread which might Debian
>  connect to porn sites for Google or any other search machine
>  just fix an RC bug first and then send your mail.

Hehe

>   3. Go to debian-curiosity with mails which do not belong to debian-devel.

Fwiw, it's debian-curiosa.

> PS: I just cleared my very fast /dev/null device for responses to this
> mail of my own.  The sense was to reduce SPAM mails to this list and
> not to produce even more - just in case people did not understand
> my broken English.

To stop a thread, the best method normally is not to contribute to it.
Oh well, now I have failed this as well...

Regards,

Joey

-- 
Never trust an operating system you don't have source for!

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

Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian

[David Weinehall]

On Mon, Dec 06, 2004 at 04:35:41PM +1100, Brian May wrote:
> > "Tollef" == Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> 
> Tollef> | Finally, I would like to commend Michelle Konzack for
> Tollef> standing up on | this issue. Debian should never promote |
> Tollef> degradation/abuse/exploitation, in any form, of females
> Tollef> (or males or | blacks or whites or whatever).

Be careful with your attributions, that was written by Martin Olsson,
not Tollef Fog Heen.

> Tollef> Please take a look at the images and I'd be surprised if
> Tollef> you feel them degrade, abuse or exploit females.  I think
> Tollef> they are silly and nothing to be upset about.  Not porn,
> Tollef> not erotic, just silly.

This part, was written by Tollef though =)

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Re: charsets in debian/control

[Adrian 'Dagurashibanipal' von Bidder]

On Tuesday 07 December 2004 00.19, Roger Leigh wrote:

> I think going to UTF-8 as the default locale charmap for all locales
> is a feasable goal for etch, as is recoding everything to UTF-8 (where
> it makes sense).

Yep.

My biggest problem right now is 'lpr ' to a postscript printer 
(I use cups).  I *believe* the problem is not necessarily with cups itself 
but with a2ps or whatever is used to generate the postscript output.

cheers
-- vbi

-- 
Hail Eris!


pgp0lyS3by2Vw.pgp
Description: PGP signature

Re: charsets in debian/control

[Peter Samuelson]

[Roger Leigh]
> I've been using Debian with UTF-8 only locales for over 12 months
> now.  I now consider it fine for general use, with respect to
> terminal and application support.  Unlike a couple of years ago, most
> things work perfectly.

Some apps like 'screen' do not just configure themselves for UTF-8
support based on LC_CTYPE, but have to be manually configured.
Presumably your goal would include fixing these apps.


signature.asc
Description: Digital signature