date:20041210

[EMAIL PROTECTED] (Debian Bug Tracking System) wrote:

 Processing commands for [EMAIL PROTECTED]:

 tag 284800 + fixed
 Bug#284800: tetex-base: Can't be removed: rmdir: 
 `/usr/share/texmf/fonts/type1/pxr/': No such file or directory
 There were no tags set.
 Tags added: fixed

Was this really necessary? You are NMU'ing a bug that is 2 days old, my
last message to that bug was yesterday afternoon, saying:

,
| The cause is clear, the fix is easy.
`

Since then, I was testing the packages with the fixes that we had
prepared in the last days. You have not posted anything to this bug,
neither a patch nor an intent to NMU. And you won't stop me from
uploading these packages this morning.

I find this extremely annoying.

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

Re: dselect survey

Bernd Eckenfels [EMAIL PROTECTED] wrote:

 Er, these are shortcuts. *shrug*

 Uh, so there is a non-shortcut method of operating?

I awaited this comment, but didn't know which other word to use. No, I
don't claim there is a non-shortcut method. I would say that dselects'
control interface consists of only shortcuts (or whatever you want to
call that) *by design*.

I understand that this may be unpleasant to some people, but I think
that for a very often-used program such as dselect (if this is your dpkg
front-end of choice, of course), this is not a problem: you don't need
10 months to learn 10 shortcuts in a software that you use every week or
so. And you are very efficient with these shortcuts.

 And which is left with enter, just like you need to do to install (unless
 you really want to ignore the conflict, which means you have to use Q to
 install, then :)

FWIW, space was used to exit help in woody's dselect version. I cannot
say I prefer the new behavior[1], but I don't see a major problem with
the two uses of enter you are mentioning: enter in dselect has
always[2] meant (in the context of an action) do the work that has been
marked so far (usually: install according to the selections I have
under the eyes). Consequently, whenever you hit enter, you are
supposed to have convinced yourself that you want to do what has been
marked so far, which is generally right under your eyes (list of
packages to install or remove in a dependency/conflict dialog
resolution, for instance).

So, in the case of exiting help, you are just somehow led to pay a bit
too much attention to a pretty harmless action, that is, exiting the
on-line help. I admit this may not be perfect, but I don't see it as a
big problem (how often do you need on-line help when you use dselect
every week or so?). I think if we could exit help with ESC, that would
be perfect, but perhaps tty technicalities would require you to hit it
twice as in mc (I don't know much about this problem), which would be a
slightly ugly.


[1] I still use both versions and happen to often hit space instead of
enter when I use sid's one, which doesn't have any bad
consequences (simply scrolls help). And the problem will disappear
automatically when I don't have to use woody's dselect anymore.

[2] Well, since slink at least.

-- 
Florent

Bug#285052: ITP: paje.app -- generic visualization tool (Gantt chart and more)

2004-12-10 Thread Vincent Danjean

Package: wnpp
Severity: wishlist

* Package name: paje.app
  Version : 1.0.0cvs20041022
  Upstream Author : Benhur Stein
* URL (old)   : http://www-id.imag.fr/Logiciels/paje/pajedist.html
* URL (new)   : http://forge.objectweb.org/projects/paje/
* License (old)   : GPL
* License (new)   : LGPL
  Description : generic visualization tool (Gantt chart and more)

 Paje is a graphical tool that displays traces produced during the
 execution of multithreaded programs. Other programs can also generate
 traces for this tool.
 Key Features
   * Supports multi threaded programs
  o each thread of the analysed program can be individually
displayed, or multiple threads can be combined, to reduce screen
space usage.
   * Interactivity
  o each entity represented on the screen can be interrogated for
more information,
  o related entities are highlighted as mouse cursor passes over
some representation

Rem:
  Paje has just been accepted in the ObjectWeb consortium. The project
web page is created on their server, but not yet populated (hence the
old url where current software is present and the new where new releases
will be available)
  The adoption in the ObjectWeb consortium is also the reason why the
author is currently switching from the GPL to the LGPL (the consortium
prefers this licence and the author is ok).

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

Re: dselect survey

Miles Bader [EMAIL PROTECTED] wrote:

 Completely and utterly wrong in my case.  I'm exactly the sort of person
 that you apparently think should like dselect, but I think aptitude is
 _far_ superior, for both experts and newbies.  The competition isn't even
 close.

Did I mention aptitude in my post? No. I'm just trying to understand
people who bash dselect on the first occasion. If you don't like dselect
and don't fall in one of the cases I have mentioned, then we have a
problem. Simply preferring aptitude is *not* a valid reason to say
dselect is ugly, difficult to use, insert typical dselect bashing crap
here.

PS: maybe I forgot:

  (f) bash dselect 'cause someone else said it was crap

(rest assured, this one is not intended to fit your particular case; I'm
just trying to build as complete a list as possible)

-- 
Florent

Removal of freeswan from sarge

2004-12-10 Thread Rene Mayrhofer

Hi all,

[Please CC me in replies, I am currently not subscribed to -devel. This is 
also cross-posted to debian-user because it might affect users that are not 
subscribed to -devel.]

I have thought for quite some time about this issue and have now come to a 
decision. Sorry that it's rather late in the release process, but I really 
think it'll be better this way.

If nobody wants to argue in favor of it, I hereby request freeswan to be 
removed from the archive (unstable and testing). (Please read further before 
actually doing it or starting to flame. Thanks.)

Reasoning: freeswan is dead. It's upstream development has been discontinued, 
it has a lot of open bugs in the Debian BTS that I sometimes can't and for 
others won't fix. Besides all of that, the freeswan package has always been a 
bloody mess, with sometimes 10 (usually conflicting) patches needing to be 
applied to get all the features necessary for today's IPSec demands. Yes, 
package updates to new upstream version have not (only) taken that long 
because I am lazy. But don't despair, a new contender is here for rescue: 
openswan. 
It is a fork of the freeswan codebase, but already integrates most of the 
third-party patches I have been applying to the Debian package over the last 
years. It is therefore more feature-complete than native freeswan ever was.
Since quite some time, I am also packaging openswan, and for nearly that long 
it is also in the Debian archive (unstable and testing). I am a lot more 
happy with my contacts to openswan upstream than I have been to my contacts 
to freeswan upstream (although some of them simply moved from freeswan to 
openswan). I can't give some facts here, but the openswan team is extremely 
responsive to any requests, which I like very much. In fact, most of the time 
the upstream package will include the latest Debian packaging, so 
the .diff.gz is generally _very_ small. 
One of the best points for openswan, from a user point of view, is that it is 
config-file compatible. I.e. if you remove (not purge) freeswan, install 
openswan, and - if you use the KLIPS kernel part instead of the native Linux 
IPSec kernel stack - recompile the kernel (or the modules) with openswan 
instead of freeswan, no other changes should be necessary. The same 
ipsec.conf, ipsec.secrets and X.509 certificates can be used.

To make a long story short: If you have any compelling reason to continue 
using freeswan, i.e. if for some reason you can not use openswan, then please 
let me know now. And no, not wanting to compile a new kernel because of the 
switch is not a compelling reason. If you can't recompile your kernel, you 
either
a) shouldn't have compiled it in the first place
or
b) should not be running unstable or testing. Remember that nothing will 
change for stable.
I am probably being presumptuous with regard to current freeswan users here, 
but I am looking for the best solution for users of the to-be-stable release, 
and freeswan is not good for that. Better a clear cut now.
If there are no objections within 2 weeks from now, I will ask the ftp 
maintainers and release managers to remove freeswan from unstable and 
testing.

I am still thinking about doing an upgrade package of freeswan though, which 
depends on openswan and simply moves the configuration of the old freeswan 
configuration to openswan. Any preferences towards such a package?

with best regards,
Rene


pgpZkmyRXYDgx.pgp
Description: PGP signature

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

2004-12-10 Thread Russell Coker

On Thursday 09 December 2004 14:06, Ron Johnson [EMAIL PROTECTED] wrote:
 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.

Let's forget about Saudi law.  Saudi law is something for people who live 
there to worry about not for those of us who live in the free world.

-- 
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: LCC and blobs

2004-12-10 Thread Goswin von Brederlow

Don Armstrong [EMAIL PROTECTED] writes:

 On Fri, 10 Dec 2004, Goswin von Brederlow wrote:
 As for distributing the blobs itself they can be relicensed under
 BSD license or similar (if their aren't already) that doesn't have
 such a problem with a char data[] = { 0x17, ... } source file,
 something without the prefered source form clause. Even putting some
 in non-free works fine.

 They'd pretty much have to go into non-free, as I'd imagine most of
 them wouldn't be able to satisfy DFSG 2 if they were unable to satisfy
 the GPL's source code requirement.


 Don Armstrong

GPL's source code requirement says something about prefered form of
modification. The char data[] = { ... } is not the prefered form for
most people or not even source for others.

The DFSG is less strict there.

MfG
Goswin

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

2004-12-10 Thread Goswin von Brederlow

Frank Küster [EMAIL PROTECTED] writes:

 [EMAIL PROTECTED] (Debian Bug Tracking System) wrote:

 Processing commands for [EMAIL PROTECTED]:

 tag 284800 + fixed
 Bug#284800: tetex-base: Can't be removed: rmdir: 
 `/usr/share/texmf/fonts/type1/pxr/': No such file or directory
 There were no tags set.
 Tags added: fixed

 Was this really necessary? You are NMU'ing a bug that is 2 days old, my
 last message to that bug was yesterday afternoon, saying:

 ,
 | The cause is clear, the fix is easy.
 `

 Since then, I was testing the packages with the fixes that we had
 prepared in the last days. You have not posted anything to this bug,
 neither a patch nor an intent to NMU. And you won't stop me from
 uploading these packages this morning.

 I find this extremely annoying.

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

I find 200 failed package builds on the buildd extremly annoying.

I'm sorry the NMU annoyed you but I welcome it. There is nothing worse
than a package that kills buildds, esspecially such a common one.

MfG
Goswin

Re: Linux Core Consortium

2004-12-10 Thread Michael Banck

On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
 Let me first say unequivocally that the LCC is very interested in
 getting Debian involved. The question has always been: How do we do
 that? 

I think there is one obvious answer to this question: 'Learn from
history'.

1. Unix and UnitedLinux failed. LSB party succeeded but has no practical
importance.

2. GNOME succeeded for the desktop.

The reason why the above failed have already been outlined in this
thread and one quote from Bruce sums it up pretty well: 'The members
considered that they had proprietary value at the level at which they
were collaborating'.

The reason why GNOME succeeded is because it builds a solid, predictable
and free base for vendors and distributions to build on. Every major
distribution which is interested (mostly RedHat, Novell and Sun) has
people working on GNOME and collaborating with each other.

The other reason why GNOME succeeded is because it spectaculary managed
to reinvent itself to make it feasable for others to build upon it.
Before those mentioned above used GNOME as their base, it was pretty
much similar to what Debian is today: No proper release schedules,
delays and not much of a broad and far-reaching vision.

So I think the obvious conclusion to the above answer ('learn from
history') is: 


*** The interested parties of the LCC should pick Debian as a base and
Debian should make this possible. ***


Rather than everybody just throwing all their stuff in together and
mixing it up. 

Of course, this would also mean for Debian to change. Debian is free
and solid today, but not predictable. Thus:

 * We should commit to strict release cylces of a base system others
   (and Debian itself) can build value upon.

 * We should proabably also commit to a set of core architectures which
   *need* to be bug-free on release, while the rest *should* be, but
   would not delay the release.

 * We should look into having a reality-check with respect to licensing
   and the way we treat each other.

On the other hand, this would also mean: The other partners should get
involved into Debian development, both by getting their toolchain/base
developers into the Debian project and possibly accepting Debian
developers into their ranks. 

All this could not be done easily, but it is the only viable solution
for a solid, free and predictable base system. There is no alternative
to it.


thanks,

Michael

Re: Removal of freeswan from sarge

Rene Mayrhofer [EMAIL PROTECTED] wrote:

 I am still thinking about doing an upgrade package of freeswan though, 
 which 
 depends on openswan and simply moves the configuration of the old freeswan 
 configuration to openswan. Any preferences towards such a package?

I don't see any reasons for _not_ providing a smooth upgrade
path. 

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

Re: Linux Core Consortium

On Thu, 2004-12-09 at 21:40 -0600, John Goerzen wrote:
 On Thu, Dec 09, 2004 at 07:08:48PM -0800, Russ Allbery wrote:
  Bruce Perens [EMAIL PROTECTED] writes:
  
  I think that tying core Debian packages to the Red Hat boat anchor is a
  horrible, horrible idea.
 
 I tend to agree with sentiments like this, but didn't Bruce mention
 that we could participate in this organization even if we didn't take
 their packages?  That is, perhaps we could influence the direction to
 a more useful one?
 
 If that is the case, it seems zero risk to me.

Yes, this is the bottom line: it does not negatively impact Debian
for (for example) the DPL to go talk/email/IRC with the LCC
representatives.

If Debian's concerns can't be satisfactorily resolved, then Debian
says thanks, but no thanks, and continues down it's current path.
It's *that* simple.

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

Vegetarian - an old Indian word meaning 'lousy hunter'.



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

Re: LCC and blobs

2004-12-10 Thread Marco d'Itri

On Dec 09, Bruce Perens [EMAIL PROTECTED] wrote:

 The whole system has to be DFSG-free. Debian won't compromise on that.
Which DFSG? The original one or the clarified one?

 I have been thinking about the blob problem for a while. I propose to 
 remove blobs from the driver, and store them as files in  initramfs (the 
 kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) 
 or initrd.img. At boot time, the drivers would look for the blobs and 
You may want to take a look at debian-legal, because some people there
think that even free drivers for hardware devices which need an
externally loaded firmware are not acceptable for main.

 load them if they are present, and fail gracefully or fall back if they 
 are not. This gets around some GPL issues, because rather than be 
There are no GPL issues for other distributions, nor for almost every
kernel developers and I understand neither for the FSF.
So you'd first have to persuade everybody else that the kernel is
violating the GPL.

 An alternative is to make blobs their own loadable modules, but then we 
 are treating them as code rather than as just a file that the kernel 
 sends to some device, and we get GPL issues.
Encapsulating some data in an ELF object does not magically make it
code.

-- 
ciao, |
Marco | [9686 esDusDIxsUiYM]


signature.asc
Description: Digital signature

Re: Linux Core Consortium

2004-12-10 Thread Marco d'Itri

On Dec 09, Ian Murdock [EMAIL PROTECTED] wrote:

   Let me first say unequivocally that the LCC is very interested in
   getting Debian involved. The question has always been: How do we do
   that?
  As usual: by sending patches.
 So, the flow can only be unidirectional?
No, interested developers can subscribe to the mailing list or whatever
they need to do to partecipate.
It's not that I don't like the idea of cooperation in defining things
like sonames or some programs having an upstream maintainer instead of
being independently patched to death by each distribution (especially
for mature or orphaned packages like ppp, tcp-wrappers, netkit, etc...),
but I'm can't see any benefit in blindly commiting to some standard, as
it may mean lowering the quality of Debian.

  And which I doubt we will get with LCC, since the kernel is the most
  important piece which needs to be certificated.
 The common core will include a common kernel. See the FAQ at
Christoph Hellwig already explained the obvious problem with this.

-- 
ciao, |
Marco | [9687 apucCy4LNj8KQ]


signature.asc
Description: Digital signature

Re: Linux Core Consortium

On Thu, 2004-12-09 at 23:15 -0600, Gunnar Wolf wrote:
 John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]:
   I think that tying core Debian packages to the Red Hat boat anchor is a
   horrible, horrible idea.
  
  I tend to agree with sentiments like this, but didn't Bruce mention
  that we could participate in this organization even if we didn't take
  their packages?  That is, perhaps we could influence the direction to
  a more useful one?
  
  If that is the case, it seems zero risk to me.
 
 Then we would be non-participants, we would be just bitchers, telling
 everybody how fucked-up their process and QA are. We would gain
 nothing, and we would lose as everybody would say that Debian refuses
 to play together with the guys after giving an initial 'yes'. And no,
 no ISV would certify Debian just because Debian sits and bitches.

There are diplomatic ways to say, your processes and QA are all
fucked up.

We'll just have to send someone who knows how to do that. :)

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

If you don't know how to do something, you don't know how to do
it with a computer.
Anonymous



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

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

On Fri, 2004-12-10 at 22:48 +1100, Russell Coker wrote:
 On Thursday 09 December 2004 14:06, Ron Johnson [EMAIL PROTECTED] wrote:
  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.
 
 Let's forget about Saudi law.  Saudi law is something for people who live 
 there to worry about not for those of us who live in the free world.

It is. if we want people in Arabia to be able to possess Debian 
disks.

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

Pacifism can act more effectively against democracy than for
it.
George Orwell, 1941



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

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

2004-12-10 Thread Frank Lichtenheld

On Fri, Dec 10, 2004 at 11:43:22AM +0100, Frank Küster wrote:
 Since then, I was testing the packages with the fixes that we had
 prepared in the last days. You have not posted anything to this bug,
 neither a patch nor an intent to NMU. And you won't stop me from
 uploading these packages this morning.

Which certainly wasn't his intention.

 I find this extremely annoying.

Please calm down. Sure, it isn't usual to upload such a quick NMU, but
(as Goswin already pointed out) such a bug that makes a package
uninstallable that is a common build-depends can really hurt the
autobuilders. You're free to discuss with lamont how to handle such
cases in the future (and communicating him your anger) but please
don't overreact.

Positive thinking ;)

Gruesse,
-- 
Frank Lichtenheld [EMAIL PROTECTED]
www: http://www.djpig.de/

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

Goswin von Brederlow [EMAIL PROTECTED] wrote:

 Frank Küster [EMAIL PROTECTED] writes:

 You have not posted anything to this bug,
 neither a patch nor an intent to NMU. And you won't stop me from
 uploading these packages this morning.

 I find this extremely annoying.

[...]
 I find 200 failed package builds on the buildd extremly annoying.

I must admit that I didn't know that failed *removals* of
build-dependencies would cause the buildd to fail. Nobody cared to
indicate that to us.

 I'm sorry the NMU annoyed you but I welcome it. There is nothing worse
 than a package that kills buildds, esspecially such a common one.

I agree. But still LaMont should have expressed his intent to do so, and
send the patch to the BTS. I don't have a problem with being NMUed, but
with NMUs prepared improperly. 

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

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

2004-12-10 Thread Martin Zobel-Helas

Hi Frank,

 Please calm down. Sure, it isn't usual to upload such a quick NMU, but
 (as Goswin already pointed out) such a bug that makes a package
 uninstallable that is a common build-depends can really hurt the
 autobuilders. You're free to discuss with lamont how to handle such
 cases in the future (and communicating him your anger) but please
 don't overreact.
 

Whats about uploading such packages to experimental more often. As i am
being told on IRC, experimental is autobuilded on most architectures
now.

Greetings
Martin
--
Bachelor:
A man who chases women and never Mrs. one.

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

Op vr, 10-12-2004 te 13:49 +0100, schreef Frank Kster:
 I must admit that I didn't know that failed *removals* of
 build-dependencies would cause the buildd to fail. Nobody cared to
 indicate that to us.

It can happen. It doesn't happen always, but sometimes it does. In
extreme cases, a buildd host can become so FUBARed that no package will
build anymore (because *every* dpkg run will fail).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

2004-12-10 Thread Goswin von Brederlow

Frank Küster [EMAIL PROTECTED] writes:

 Goswin von Brederlow [EMAIL PROTECTED] wrote:

 Frank Küster [EMAIL PROTECTED] writes:

 You have not posted anything to this bug,
 neither a patch nor an intent to NMU. And you won't stop me from
 uploading these packages this morning.

 I find this extremely annoying.

 [...]
 I find 200 failed package builds on the buildd extremly annoying.

 I must admit that I didn't know that failed *removals* of
 build-dependencies would cause the buildd to fail. Nobody cared to
 indicate that to us.

The failure did corrupt the apt/dpkg status resulting in apt-get
always suggesting run apt-get -f install to corret the problem. Due
to that no new Build-Depends can be installed and every build just
fails.

Sometimes a failure to remove something can be ignored, sometimes it
breaks apt. This one was of the later kind.

MfG
Goswin

Re: Linux Core Consortium

2004-12-10 Thread Greg Folkert

On Thu, 2004-12-09 at 21:35 -0800, Philip Miller wrote:
 Greg Folkert wrote:
  Many reasons people come to Debian... Distributed Binaries is not one of
  them.
 
 If you think this isn't a reason to use Debian, I, as a long-time user, will 
 tell you that 
 you're dead wrong. I use Debian because there exist packages for most every 
 popular piece 
 of free software out there, and I will never have to use an untrusted binary 
 package to 
 install it conveniently. Even when it comes to installing software that's not 
 in the 
 Archive, I can safely install it from source, with the assurance that none of 
 its files 
 will be mixed in with any files installed by the package management system 
 (not the case 
 with most 3rd-party RPMS).


Should umm, clarify, Distributed Binaries == Binaries Built and shoved
into Debian by an External Entity or 3rd Party.

I rarely, RARELY compile a package with dpkg-buildpackage. When I do, it
is for a local modification to workaround a hardware, security or
performance issue before it is patched or fixed in Debian. Typically the
only 3rd Party Binaries I use are Games or Business Critical
(non-free/commercial) applications as deemed by the PHBs that be.

 I am doing some sysadmin work involving RedHat Enterprise Linux 3 systems, 
 and I will tell 
 you that they do a terrible job of maintaining a binary distribution. 
 Standing by 
 themself, let alone compared to Debian, they do no integration testing of the 
 packages 
 they release and distribute. For example, this past summer, after a new 
 server 
 installation, we had to build and install a local copy of Perl, because the 
 version they 
 distributed was completely incompatible with both mailscanner and amavisd-new 
 due to 
 module bugs. This sort of brown-paper-bag error in a release is unthinkable 
 in Debian, 
 precisely because of the QA that our exact distributed binaries go through 
 (and this 
 particular issue was actually caught in testing, as it should have been).

I have done and continue to manage RedHat AS/ES installations. I do
these primarily via ssh, one is on another continent, most are in the
US, though states away though). I can tell you first hand the terrible
fixes I have had to force onto some of those systems that just wouldn't
work with Oracle or Tuxedo or Websphere or insert other Enterprise
Application mainly becuase of this lack of QA from RedHat. Regression
testing, or integration testing as you call it, is by far the best
reason to come to Debian. When I think of Debian and Binary... those are
Binaries Built by Buildd-s in the Debian Submission and Acceptance
process. Not on lumpy.redhat.com or some other external host that I have
zero real knowledge of.

And for your Perl Issue, you could have just CPAN updated those Perl
Modules. I have had to do that many times. There are certain things I
like about RedHat... one is the rpmbuild setup. If one could employ
policies in an RPM build that are applied to DEB builds... I'd think
that 99.9% of the issues we speak about in RedHat would be solved.

So, I guess you misread what I meant. Or I wasn't as clear as I should
have been. Either way, you should now understand my position a bit
better.
-- 
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Onerous congratulations on your conceptual development of obliteration
concerning telephones, lobsters and fish!


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

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

2004-12-10 Thread Michael Banck

On Fri, Dec 10, 2004 at 01:49:33PM +0100, Frank Küster wrote:
  I'm sorry the NMU annoyed you but I welcome it. There is nothing worse
  than a package that kills buildds, esspecially such a common one.
 
 I agree. But still LaMont should have expressed his intent to do so, and
 send the patch to the BTS. I don't have a problem with being NMUed, but
 with NMUs prepared improperly. 

At this point, any RC bug in an important (as in for the release, not
priority-wise) package is an implicit express to be NMUd, at any time.
Deal with it, we want to release.

One could argue about sending the NMU-patch/interdiff to the BTS, but I
personally do not see much point in it, since (hi Omnic!) you can just
get it from the archive and sync it yourself. It still makes sense for
packages where you suspect the maintainer to be inactive/not willing to
deal with this or (as is the case here apparently) already working on a
new revision.

In any case, NMUs are never meant as personal attacks or gratuitous.
Especially when they are done by buildd maintainers you can be certain
there was some need for it.

I envision a time where there are no more NMUs, just uploads by people
who care.


cheers,

Michael

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

Martin Zobel-Helas [EMAIL PROTECTED] schrieb:

 Hi Frank,

 Please calm down. Sure, it isn't usual to upload such a quick NMU, but
 (as Goswin already pointed out) such a bug that makes a package
 uninstallable that is a common build-depends can really hurt the
 autobuilders. You're free to discuss with lamont how to handle such
 cases in the future (and communicating him your anger) but please
 don't overreact.
 

 Whats about uploading such packages to experimental more often. As i am
 being told on IRC, experimental is autobuilded on most architectures
 now.

What do you mean? Do you think the buggy package should have been
uploaded to experimental? Believe me, we didn't plan the bug. Uploading
the NMU to experimental wouldn't have helped anybody, either: The
buildd's would still have been broken, and the NMU would still have been
unannounced and without a patch in the BTS (the patch was received by
the first mailhost 6 hours after the date in the changelog...)

Grüße, Frank

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

Re: Linux Core Consortium

2004-12-10 Thread Greg Folkert

On Fri, 2004-12-10 at 12:50 +0100, Michael Banck wrote:
 On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
  Let me first say unequivocally that the LCC is very interested in
  getting Debian involved. The question has always been: How do we do
  that? 
 
 I think there is one obvious answer to this question: 'Learn from
 history'.
 
 1. Unix and UnitedLinux failed. LSB party succeeded but has no practical
 importance.
 
 2. GNOME succeeded for the desktop.
 
 The reason why the above failed have already been outlined in this
 thread and one quote from Bruce sums it up pretty well: 'The members
 considered that they had proprietary value at the level at which they
 were collaborating.
 
 The reason why GNOME succeeded is because it builds a solid, predictable
 and free base for vendors and distributions to build on. Every major
 distribution which is interested (mostly RedHat, Novell and Sun) has
 people working on GNOME and collaborating with each other.
 
 The other reason why GNOME succeeded is because it spectacularly managed
 to reinvent itself to make it feasible for others to build upon it.
 Before those mentioned above used GNOME as their base, it was pretty
 much similar to what Debian is today: No proper release schedules,
 delays and not much of a broad and far-reaching vision.
 
 So I think the obvious conclusion to the above answer ('learn from history') 
 is: 
 
 
 *** The interested parties of the LCC should pick Debian as a base and
 Debian should make this possible. ***

W, that would be tough. But I like it. At least for Core. 

 Rather than everybody just throwing all their stuff in together and
 mixing it up. 
 
 Of course, this would also mean for Debian to change. Debian is free
 and solid today, but not predictable. Thus:
 
  * We should commit to strict release cycles of a base system others
(and Debian itself) can build value upon.

So we would detach Core from everything else, perhaps we should also
then also define kernels with specific patches to accommodate certain
situations or applications. IOW have flavours of kernels be something
like:

kernel-image-kern-ver-rev-arch-up/smp/mpp-db-name
kernel-image-kern-ver-rev-arch-up/smp/mpp-app-server
kernel-image-kern-ver-rev-arch-up/smp/mpp-erp-solution
kernel-image-kern-ver-rev-arch-up/smp/mpp-web-serving

kernel-image-kern-ver-rev-arch-up/smp/mpp-transaction-processing
kernel-image-kern-ver-rev-arch-up/smp/mpp-workstation
kernel-image-kern-ver-rev-arch-up/smp/mpp-gaming
kernel-image-kern-ver-rev-up/smp/mpp-generic

With those Distributions needing keeping the base-patchset up-to-date
and while the buildd machines compile for the architectures, While we as
Debian just continue on managing these patchsets to work on all arches.

This would require those other Distros to become more policy driven. How
would we split this out? Would we then have Core Only DDs? Would we
still have the ability to get security fixes out the door in time?
Should we do revision releases like say we do for Woody right now:
3.0r1/2/... would this work? Doing incremental security/major bug-fix
releases similar to the way Microsoft does it? (No not really, but the
idea is similar) Should we then have a Core Only
Stable/Testing/Sid/Experimental?

  * We should probably also commit to a set of core architectures which
*need* to be bug-free on release, while the rest *should* be, but
would not delay the release.

I disagree here, when WOULD they get worked on then? Release pending is
a good motivator. But as we see now, it is not *THE HOLY GRAIL* of
Motivators. Some of the *OLDER* not able to keep up as of now anyway
buildd machine arches might be candidates, but Dang what a way to slam
the door on them. (like 32bit Sparc, M68K, others)

  * We should look into having a reality-check with respect to licensing
and the way we treat each other.

Now this... needs to happen anyway.

 On the other hand, this would also mean: The other partners should get
 involved into Debian development, both by getting their toolchain/base
 developers into the Debian project and possibly accepting Debian
 developers into their ranks. 

Again, this should happen period.

 All this could not be done easily, but it is the only viable solution
 for a solid, free and predictable base system. There is no alternative
 to it.

Unfortunately, this I agree with you. It will make it the toughest thing
on the planet. A sub-structure of Buildd will need to make both DEB
packages as well as RPM, lest we not forget, TGZ/other packages mgmt
systems.

This is a big job, which I believe nobody will succeed on. Which is tooo
bad.
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster: Linux


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

Re: Linux Core Consortium

2004-12-10 Thread Greg Folkert

On Fri, 2004-12-10 at 06:31 -0600, Ron Johnson wrote:
 On Thu, 2004-12-09 at 23:15 -0600, Gunnar Wolf wrote:
  John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]:
I think that tying core Debian packages to the Red Hat boat anchor is a
horrible, horrible idea.
   
   I tend to agree with sentiments like this, but didn't Bruce mention
   that we could participate in this organization even if we didn't take
   their packages?  That is, perhaps we could influence the direction to
   a more useful one?
   
   If that is the case, it seems zero risk to me.
  
  Then we would be non-participants, we would be just bitchers, telling
  everybody how fucked-up their process and QA are. We would gain
  nothing, and we would lose as everybody would say that Debian refuses
  to play together with the guys after giving an initial 'yes'. And no,
  no ISV would certify Debian just because Debian sits and bitches.
 
 There are diplomatic ways to say, your processes and QA are all
 fucked up.
 
 We'll just have to send someone who knows how to do that. :)

And just who the he(double-toothpick) would you suggest? 
Scott James Remnant? :^)
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster: Linux


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

Re: Linux Core Consortium

Op vr, 10-12-2004 te 12:50 +0100, schreef Michael Banck:
 *** The interested parties of the LCC should pick Debian as a base and
 Debian should make this possible. ***
 
 Rather than everybody just throwing all their stuff in together and
 mixing it up. 
 
 Of course, this would also mean for Debian to change. Debian is free
 and solid today, but not predictable. Thus:
 
  * We should commit to strict release cylces of a base system others
(and Debian itself) can build value upon.

IOW, split off the release of the base system, and make it some entity
that stands by itself. Hmm, isn't that what LCC suggests we do?

  * We should proabably also commit to a set of core architectures which
*need* to be bug-free on release, while the rest *should* be, but
would not delay the release.

This isn't necessary, unless you can show me one release which was
delayed because a certain architecture wasn't in shape.

  * We should look into having a reality-check with respect to licensing
and the way we treat each other.

You'll have to explain this one to me.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

Michael Banck [EMAIL PROTECTED] wrote:

 One could argue about sending the NMU-patch/interdiff to the BTS, but I
 personally do not see much point in it, since (hi Omnic!) you can just
 get it from the archive and sync it yourself. It still makes sense for
 packages where you suspect the maintainer to be inactive/not willing to
 deal with this or (as is the case here apparently) already working on a
 new revision.

 In any case, NMUs are never meant as personal attacks or gratuitous.
 Especially when they are done by buildd maintainers you can be certain
 there was some need for it.

As stated before, I see now that the NMU was okay. However, I was really
annoyed this morning to find in my mailbox the mail indicating the bug
was Fixed, but found no notice of this in the bug, or anywhere but the
changelog. 

If anybody had cared to inform me about the problems the bug had caused,
I would probably have delayed the testing of the other changes in our
CVS, and prepared an upload myself. The fixed package could have hit
unstable _earlier_ than the NMU did.

Or I could simply have stayed at the university an hour longer yesterday
evening, and make the upload of 2.0.2c-3 nearly at the same time as
LaMonts NMU.

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

Re: Linux Core Consortium

2004-12-10 Thread Steve Langasek

On Fri, Dec 10, 2004 at 12:50:13PM +0100, Michael Banck wrote:

 *** The interested parties of the LCC should pick Debian as a base and
 Debian should make this possible. ***

 Rather than everybody just throwing all their stuff in together and
 mixing it up. 

 Of course, this would also mean for Debian to change. Debian is free
 and solid today, but not predictable. Thus:

  * We should commit to strict release cylces of a base system others
(and Debian itself) can build value upon.

This seems to be the same definition of commit as in

  Novell is committed both to providing customers with standardized Linux
  technology and to simplifying ISVs' and IHVs' Linux certification
  efforts.[1]

that is, to quote Hamlet, words, words... words.  While it might make a
good April Fool's joke to ask Novell and Red Hat to standardize on Debian,
we don't exactly have a strong history of being able to pull off timely
releases, and it would be a true fool who today would bank on future Debian
release schedules before we've demonstrated that time-based releases are
organizationally possible for us.

  * We should proabably also commit to a set of core architectures which
*need* to be bug-free on release, while the rest *should* be, but
would not delay the release.

Er, what would be the point of making a stable release for an architecture
if we know that it's broken?  But perhaps you meant that the architectures
would be dropped from the release.

  * We should look into having a reality-check with respect to licensing
and the way we treat each other.

This wording seems to imply a particular outcome of any licensing reality
check.  Perhaps you meant to post it to one of the many easy-to-find DFSG
flamewars in Debian's recent history, instead of to a thread discussing
LCC's significance to Debian.

-- 
Steve Langasek
postmodern programmer

[1] http://linux.about.com/b/a/129063.htm


signature.asc
Description: Digital signature

Re: Linux Core Consortium

2004-12-10 Thread Bill Allombert

Hello Debian developers,

It seems to me than one of the main value of Debian is in the quality of
its core distribution.  One of the reason of the quality is that it
is not developed for itself but as a platform for the 10^4+ packages
and the 10+ architectures in Debian. For example the compiler must be
able to build all the packages we ship on all the architectures we
support, and we have some reasonable warranty it is the case when we
release.

Given that, an attempt to develop the core distribution as a separate 
entity is going to be impractical and to reduce its quality.

On the other hand, nothing bars the LCC to build a distribution on top of
Debian. There is a lot of precedent for doing so (Xandros,libranet,
lycoris, linspire, mepis, etc.).

I have to say the gcc-2.96 nightmare had made me distrust a lot of
commercial distributions. Red Hat was well aware it was a development
snapshot with a different C++ ABI and not well tested. Mandrake and
SuSE were well aware of the consequences of following Red Hat on that
path. Yet they did it and I still suffer from the consequences today.

As a practical matter, what if the Debian gcc team decide to release
etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is
not stable enough on all the platforms ? Will LCC follow ? If not, how
are we going to share binary package if we do not use the same compiler?

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

2004-12-10 Thread Steve Langasek

On Fri, Dec 10, 2004 at 02:45:17PM +0100, Michael Banck wrote:
 On Fri, Dec 10, 2004 at 01:49:33PM +0100, Frank Küster wrote:
   I'm sorry the NMU annoyed you but I welcome it. There is nothing worse
   than a package that kills buildds, esspecially such a common one.

  I agree. But still LaMont should have expressed his intent to do so, and
  send the patch to the BTS. I don't have a problem with being NMUed, but
  with NMUs prepared improperly. 

 At this point, any RC bug in an important (as in for the release, not
 priority-wise) package is an implicit express to be NMUd, at any time.
 Deal with it, we want to release.

 One could argue about sending the NMU-patch/interdiff to the BTS, but I
 personally do not see much point in it, since (hi Omnic!) you can just
 get it from the archive and sync it yourself. It still makes sense for
 packages where you suspect the maintainer to be inactive/not willing to
 deal with this or (as is the case here apparently) already working on a
 new revision.

I don't see how this should be a point of contention at all; the requirement
that diffs from NMUs be posted to the BTS has been explicit for a very long
time.  It is the responsibility of the NMUer to ensure that the diffs are
delivered to the maintainer for inspection via the BTS.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

Ron Johnson [EMAIL PROTECTED] writes:

 It is. if we want people in Arabia to be able to possess Debian 
 disks.

The solution to censorious regimes is not to say, well, ok, we'll
censor ourselves so you don't even have to bother.

Re: ITP: g-wrap -- Scripting interface generator for C

Andreas Rottmann [EMAIL PROTECTED] writes:

 Thomas Bushnell BSG [EMAIL PROTECTED] writes:
 
  Andreas Rottmann [EMAIL PROTECTED] writes:
 
  A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10
  will have the patch applied, as it is already in CVS, both in HEAD and
  the 1.8 branch) when you apply the attached patch. 
 
  Just so you know, it's really my intention not to have *any* pre-Sarge
  changes. 
 
 Fine. I'll probably try building GnuCash 1.8.9 with G-Wrap 1.9.3
 anyway, as maybe NetBSD pkgsrc switches to this setup and I want to
 make sure it works. I'll file a wishlist bug (build against G-Wrap
 1.9.x) on GnuCash with the according patches once G-Wrap 1.9.x is in
 Debian and I've made it work with GnuCash.

Excellent; that sounds like a good plan to me.

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

2004-12-10 Thread Will Newton

On Friday 10 Dec 2004 15:13, Thomas Bushnell BSG wrote:
 Ron Johnson [EMAIL PROTECTED] writes:
  It is. if we want people in Arabia to be able to possess Debian
  disks.

 The solution to censorious regimes is not to say, well, ok, we'll
 censor ourselves so you don't even have to bother.

Which is a fine point of view if you are making a political point. But as far 
as I am aware we are trying to make an operating system.

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

2004-12-10 Thread Anthony Towns

Frank Lichtenheld wrote:
On Fri, Dec 10, 2004 at 11:43:22AM +0100, Frank Küster wrote:
I find this extremely annoying.
Please calm down.
Why? There's _no_ excuse not to mail the BTS before NMUing.
You're free to discuss with lamont how to handle such
cases in the future (and communicating him your anger) but please
don't overreact.
How to NMU is documented in the developers-reference -- you mail a patch 
to the BTS, indicate that you're going to NMU via the BTS, then NMU. 
Normally you have more than five seconds between those actions, but even 
if ten seconds is too long to wait, you should still do all those 
things. Heck, you should mail *especially* if ten seconds is too long to 
wait -- just to explain why the problem is so serious so there's some 
hope the maintainer can avoid it in future.

The whole point of the mail the BTS policy is to avoid maintainers not 
knowing what's going on, or why it's going on.

(Apparently Lamont's connectivity was screwed up, which caused the lack 
of email in this case, rather than lack of knowledge or effort)

Cheers,
aj

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

Op vr, 10-12-2004 te 15:22 +, schreef Will Newton:
 On Friday 10 Dec 2004 15:13, Thomas Bushnell BSG wrote:
  Ron Johnson [EMAIL PROTECTED] writes:
   It is. if we want people in Arabia to be able to possess Debian
   disks.
 
  The solution to censorious regimes is not to say, well, ok, we'll
  censor ourselves so you don't even have to bother.
 
 Which is a fine point of view if you are making a political point. But as far 
 as I am aware we are trying to make an operating system.

Sure. So we should not censor ourselves.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

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

2004-12-10 Thread Will Newton

On Friday 10 Dec 2004 15:24, Wouter Verhelst wrote:

  Which is a fine point of view if you are making a political point. But as
  far as I am aware we are trying to make an operating system.

 Sure. So we should not censor ourselves.

I don't see how that follows from what I said.


Here's a couple of examples:

We don't agree with censorship, so anything packageable goes in the 
distribution. This means we have a number of worthless and crufty packages 
that no-one uses and our time to release is getting ever longer. We also end 
up with packages that offend many people and may even cause legal problems 
for our distributors.

We clarify the DFSG just prior to an intended release and nearly derail the 
whole release in the process.

We are soon to refuse to ship binary firmware blobs when the writing is quite 
clearly on the wall that this is going to be something more and more people 
will have to deal with in the years to come.


Do you see why it seems like Debian is more of a political talking shop that a 
team trying to develop an operating system?

I don't want to start a flame war and I will probably not reply to this thread 
any longer, but the latest discussions on debian-devel have pushed me to the 
edge of resigning from this project.

Re: Linux Core Consortium

2004-12-10 Thread Adrian von Bidder

On Friday 10 December 2004 15.35, Steve Langasek wrote:
 we don't exactly have a strong history of being able to pull off
 timely releases

Did Debian even try?

I didn't follow the woody release too closely, being a Debian newbie at the 
time, so I don't know.  But - this was my impression - from the start, 
sarge was prepared with the 'we release when we're ready' idea, which makes 
everybody feel that they have more than enough time.

cheers
-- vbi

--  
this email is protected by a digital signature: http://fortytwo.ch/gpg


pgporALSTEBxi.pgp
Description: PGP signature

Re: Linux Core Consortium

2004-12-10 Thread Peter 'p2' De Schrijver

Hi,

 
  * We should commit to strict release cylces of a base system others
(and Debian itself) can build value upon.
 
  * We should proabably also commit to a set of core architectures which
*need* to be bug-free on release, while the rest *should* be, but
would not delay the release.
 

I don't think that buys us anything. I don't think there is a single
architecture which has blocked the release up to now. All bugs that
appeared by testing on different architectures, were real bugs in the
code. They just didn't show up by only testing on a few architectures.
In short, releases are not faster and would probably contain more bugs.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: Removal of freeswan from sarge

2004-12-10 Thread Adrian von Bidder

On Friday 10 December 2004 13.20, Frank Kster wrote:
 Rene Mayrhofer [EMAIL PROTECTED] wrote:
  I am still thinking about doing an upgrade package of freeswan
  though, which depends on openswan and simply moves the configuration of
  the old freeswan configuration to openswan. Any preferences towards
  such a package?

 I don't see any reasons for _not_ providing a smooth upgrade
 path.

As far I understand it, a kernel recompilation is necessary in most cases, 
so the upgrade won't be smooth anyway.  Not providing an upgrade package 
would leave current freeswan users with their setup, while providing an 
upgrade package would make them pull in openswan on upgrade, when they 
really wanted to keep that kernel and their current freeswan set up.

I don't use any IPsec currently, so I'm not a user, just adding my .02

-- vbi

-- 
The law will never make men free; it is men who have got to make the law 
free.
  -- Henry David Thoreau


pgpLRSC9IuCFP.pgp
Description: PGP signature

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

Op vr, 10-12-2004 te 15:38 +, schreef Will Newton:
 On Friday 10 Dec 2004 15:24, Wouter Verhelst wrote:
   Which is a fine point of view if you are making a political point. But as
   far as I am aware we are trying to make an operating system.
 
  Sure. So we should not censor ourselves.
 
 I don't see how that follows from what I said.

Censoring is done by people who try to make a political point. Creating
an operating system involves throwing a pile of software together,
integrate it, remove any and all bugs you find, and release that. It
does not involve censoring.

In Debian's case, we censor only based on the question whether a package
is DFSG-free, nothing else. It would be wrong to act otherwise.

 Here's a couple of examples:
 
 We don't agree with censorship, so anything packageable goes in the 
 distribution.

That is currently not the case. There are four requirements for a
package to be in main, and these are clearly spelled out in policy: they
need to be DFSG-free, they must not depend on software out of main, they
need to be not so buggy that we refuse to support them, and they need to
be policy-compliant.

 This means we have a number of worthless and crufty packages 
 that no-one uses and our time to release is getting ever longer.

Packages that are worthless, crufty, unused, and unmaintained are
routinely being removed from the archive.

 We also end 
 up with packages that offend many people and may even cause legal problems 
 for our distributors.

Have you taken a look at what hot-babe actually looks like? I suspect
you haven't. I don't think it will offend anyone.

[...]
 Do you see why it seems like Debian is more of a political talking shop that 
 a 
 team trying to develop an operating system?

Debian has always been a political organization; if we weren't, we
wouldn't be anything called 'DFSG'.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

2004-12-10 Thread fe3mike

yeah

Re: Linux Core Consortium

2004-12-10 Thread Chasecreek Systemhouse

On Thu, 09 Dec 2004 13:59:10 -0500, Jim Gettys [EMAIL PROTECTED] wrote:
 That being said, certainly UNIX's disunity was a major aid to Microsoft.
 Repeating that history would not be good.

I must agree with Jim.  From the stand-point that Debian is losing
developers to other Linux platforms and architecture specialists are
giving their favorite hardware OpSys preferences I personally feel
this is a fork in the road for Debian overall.

Observational participation for Debian within LCC is perferred as
non-participation may be construed as bad mannered whereas complete,
wide ranging, participation will likely result in Debian being viewed
as just another Distro with in a sea of Linux.

Debian, IMHO, has always set itselt apart.  Sure, their may be
internal issues, but any Distro in-motion, especially one such as
Debian, will have growth related problems.

-- 
WC -Sx- Jones
http://insecurity.org/

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

2004-12-10 Thread Will Newton

On Friday 10 Dec 2004 16:07, Wouter Verhelst wrote:

 Have you taken a look at what hot-babe actually looks like? I suspect
 you haven't. I don't think it will offend anyone.

I have looked at it. And I don't think it is an acceptable thing to ship as 
part of an operating system. I am an atheist and a liberal but the majority 
of people in the world are not.

Re: Linux Core Consortium

2004-12-10 Thread David Schmitt

On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote:
 As a practical matter, what if the Debian gcc team decide to release
 etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is
 not stable enough on all the platforms ? Will LCC follow ? If not, how
 are we going to share binary package if we do not use the same compiler?

Another question that bothered me, is whether special binaries which
cannot be bit-equal be rebuilt by the build-process (i.e. everything
containing timestamps, random offsets (consider prelink -R) or machine
dependant strings (like the hostname)) are really free. Obviously there
are rights attached to the binary which cannot be reproduced solely
from the delivered source.

A similar argument was brought up in the DRM/Palladium discussion with
signed binaries. But that was worse, because this kind of binaries was
unusable without the signature while non-LCC binaries would just be
that: non-LCC binaries.



Regards, David

-- 
  * Customer: My palmtop won't turn on.
  * Tech Support: Did the battery run out, maybe?
  * Customer: No, it doesn't use batteries. It's Windows powered.
-- http://www.rinkworks.com/stupid/cs_power.shtml

Re: dselect survey

2004-12-10 Thread David Schmitt

On Fri, Dec 10, 2004 at 12:03:03PM +0100, Florent Rougon wrote:
 [1] I still use both versions and happen to often hit space instead of
 enter when I use sid's one, which doesn't have any bad
 consequences (simply scrolls help). And the problem will disappear
 automatically when I don't have to use woody's dselect anymore.

echo expert  /etc/dpkg/dselect.cfg

Regards, David
-- 
  * Customer: My palmtop won't turn on.
  * Tech Support: Did the battery run out, maybe?
  * Customer: No, it doesn't use batteries. It's Windows powered.
-- http://www.rinkworks.com/stupid/cs_power.shtml

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

2004-12-10 Thread David Pashley

On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying:
 I have looked at it. And I don't think it is an acceptable thing to ship as 
 part of an operating system. I am an atheist and a liberal but the majority 
 of people in the world are not.

I don't think it is an acceptable thing to ship as it has no use.

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

Re: dselect survey

2004-12-10 Thread Blunt Jackson

On Fri, 10 Dec 2004 12:13:29 +0100, Florent Rougon [EMAIL PROTECTED] wrote:

I'm just trying to understand
people who bash dselect on the first occasion. If you don't like dselect
and don't fall in one of the cases I have mentioned, then we have a
problem. Simply preferring aptitude is *not* a valid reason to say
dselect is ugly, difficult to use, insert typical dselect bashing crap
here.

Question: does awkward, non-intuitive user interface for a text-based
utility constitute a problem? I don't care for dselect primarily
because, for whatever reason, the user interface constantly rubs me
the wrong way. Although I have read the documentation, I almost always
remember it wrongly, hit the wrong keys, etc. etc. After working with
it for half an hour or so, I regain my proficiency... but after 6
months of not using it all that minutia is lost to my active memory,
and -- once again -- my intuition about how a text-based application
SHOULD work fails me.

Do I consider this a problem? Not particularly. It is my problem, as
much as anyone's. This is a sophisticated sysadmin tool, and I am only
an occasional sysadmin, by no means sophisticated.

(f) bash dselect 'cause someone else said it was crap

However, if you believe that user interface is important, it might
behoove you to listen to your users: people don't usually grow to
hate a system administration utility simply because it's the hip
thing to do. Of course there may be some unreasonable, or even
plain-stupid users: but if you believe that user interface is
important, you even have to think about how to make *them* happy. An
owner, interested in user interface, might take it upon him- or
herself to start a thread asking for interface suggestions, in a place
where users congregate. Ask questions like: What text-based
applications do you consider to be examples of good design? Focus on
the distinction between navigation and data-altering events. Consider
on-screen cheatsheets that advanced users can disable. Ensure that
there are sufficient and obvious undo paths with multiple roll-back
points.

I am a software developer too -- I know the temptation to mock users
who just don't get it when it is perfectly obvious. (I recently
rolled out some web software in which a table interface had graphical
links: up and down arrows at the top of each column, right below the
column label. The number one complaint was: This is useless. There's
no way to sort! Are my users dumb as dirt? Apparently they are. Is it
their problem? No, it's mine.)

Anyway, something to think about.

-bluejack

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

Re: Linux Core Consortium

2004-12-10 Thread Gunnar Wolf

Adrian von Bidder dijo [Fri, Dec 10, 2004 at 04:38:10PM +0100]:
  we don't exactly have a strong history of being able to pull off
  timely releases
 
 Did Debian even try?
 
 I didn't follow the woody release too closely, being a Debian newbie at the 
 time, so I don't know.  But - this was my impression - from the start, 
 sarge was prepared with the 'we release when we're ready' idea, which makes 
 everybody feel that they have more than enough time.

Yes, it did. Debian has long tried to shorten the release cycles,
without any success. That's the reason why Testing was introduced
(after Slink, IIRC). I got involved in Debian close to the Woody
release. We were quite optimist that Sarge would release in ~1 year -
We failed. The failure has some justifications, and they all fall down
to the fact that Sarge has not been ready, and we will not release
before it is ready... Which is getting closer every day :)

There are many proposals to make Etch and future releases come out
sooner, please check them at
http://wiki.debian.net/index.cgi?ReleaseProposals

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Linux Core Consortium

2004-12-10 Thread Brian Nelson

On Fri, Dec 10, 2004 at 04:38:10PM +0100, Adrian von Bidder wrote:
 On Friday 10 December 2004 15.35, Steve Langasek wrote:
  we don't exactly have a strong history of being able to pull off
  timely releases
 
 Did Debian even try?

No, not since I've been around.

 I didn't follow the woody release too closely, being a Debian newbie at the 
 time, so I don't know.  But - this was my impression - from the start, 
 sarge was prepared with the 'we release when we're ready' idea, which makes 
 everybody feel that they have more than enough time.

Yup.  There's never been a sense of urgency.  The RM's throw out release
dates and goals every once in a while, but no one seems to take those
seriously.  And probably for good reason.  For the second straight
release, when we've gotten to a point that it seemed we were nearly
ready for a release, we then discover we have no security autobuilders.
The release then gets pushed back a few more months, while the plebeian
developers sit around twiddling their thumbs unable to help wondering
why the hell no one thought to set up the autobuilders in the 2+ years
we've been preparing a release.

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

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

2004-12-10 Thread Andreas Rottmann

David Pashley [EMAIL PROTECTED] writes:

 On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying:
 I have looked at it. And I don't think it is an acceptable thing to ship as 
 part of an operating system. I am an atheist and a liberal but the majority 
 of people in the world are not.

 I don't think it is an acceptable thing to ship as it has no use.

Well, I tried hot-babe and it was a bit amusing for a minute or two,
but I personally don't find it useful/amusing enough seeing any need
for it. If, on the other hand, someone finds it useful aneough to
package and maintain it, and there are a few other users interested in
running it, well I can't really say anything against it. Usefulness is
a subjective thing.

Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://yi.org/rotty  | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett

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

Will Newton [EMAIL PROTECTED] writes:

 On Friday 10 Dec 2004 15:24, Wouter Verhelst wrote:
 
   Which is a fine point of view if you are making a political point. But as
   far as I am aware we are trying to make an operating system.
 
  Sure. So we should not censor ourselves.
 
 I don't see how that follows from what I said.

This way: we will not submit to the decision of the Saudi Arabian or
Chinese governments about what is and is not important to an operating
system.

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

David Pashley [EMAIL PROTECTED] writes:

 On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying:
  I have looked at it. And I don't think it is an acceptable thing
  to ship as part of an operating system. I am an atheist and a
  liberal but the majority of people in the world are not.
 
 I don't think it is an acceptable thing to ship as it has no use.

That's a bad reason; if you applied it consistently you'd have to get
rid of frozen-bubble.

Re: dselect survey

David Schmitt [EMAIL PROTECTED] wrote:

 On Fri, Dec 10, 2004 at 12:03:03PM +0100, Florent Rougon wrote:
 [1] I still use both versions and happen to often hit space instead of
 enter when I use sid's one, which doesn't have any bad
 consequences (simply scrolls help). And the problem will disappear
 automatically when I don't have to use woody's dselect anymore.

 echo expert  /etc/dpkg/dselect.cfg

Sure. It is configured this way on all the systems for which I am the
only administrator. The minor problem I was talking about only happens
on machines which are also administered by people less comfortable with
dselect. Thanks for the suggestion, anyway.

-- 
Florent

Re: dselect survey

Blunt Jackson [EMAIL PROTECTED] wrote:

 Do I consider this a problem? Not particularly. It is my problem, as
 much as anyone's. This is a sophisticated sysadmin tool, and I am only
 an occasional sysadmin, by no means sophisticated.

So, I guess some people simply don't like the *type* of control
interface dselect offers, cause they want to see menus and widgets all
around instead of having to learn that $keystroke will perform $action.

Their main grief towards dselect is therefore formulated as awkward,
non-intuitive user interface as you wrote above. Well, I don't think
that is so important because I use dselect relatively often and this
type of interface allows very efficient operation. Of course, things are
a bit different for you since you said that you can spend six months
without using it.

The situation is IMHO a bit similar to the vi case: I find vi's
interface awkward, non-intuitive, just as you qualified dselect's one.
But I can understand that some people happen to get used to it, find it
efficient and even like it. It's their right, after all. And claiming
that vi is a POS just because I don't like its interface is probably not
right.

 important, you even have to think about how to make *them* happy. An
 owner, interested in user interface, might take it upon him- or
 herself to start a thread asking for interface suggestions, in a place
 where users congregate. Ask questions like: What text-based
 applications do you consider to be examples of good design? Focus on

I haven't witnessed any discussion of this type, but I suppose that
users would have conflicting views on the subject. Some would want a
very easy to understand interface where you just have to follow menus
without having to learn any keystroke, while others would prefer an
interface where a limited number of keystrokes is enough to get the job
done. And, er, I like dselect as it is[1], and am not particularly
interested in such a discussion. :-p

[1] That doesn't mean I think it's perfect (for instance, I dream of the
day where debtags will be fully operational and integrated in
dselect). Simply, I wouldn't welcome radical changes in the control
interface that would make it less efficient.

-- 
Florent

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

2004-12-10 Thread Rich Walker

Thomas Bushnell BSG [EMAIL PROTECTED] writes:

 David Pashley [EMAIL PROTECTED] writes:

 On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying:
  I have looked at it. And I don't think it is an acceptable thing
  to ship as part of an operating system. I am an atheist and a
  liberal but the majority of people in the world are not.
 
 I don't think it is an acceptable thing to ship as it has no use.

 That's a bad reason; if you applied it consistently you'd have to get
 rid of frozen-bubble.

Though you could try the following set of criteria:

1. Are there already similar packages in Debian? NO - okay, add.

2. Does it offer significant *technical* advantages over those packages?
   YES - okay, add.

3. Are any of those other similar packages poorly maintained? YES -
   don't add another until the others are cleaned up or removed - so
   don't add

4. Hairsplitting time - is there likelihood that adding it will cause
   grave distress to some proportion of the target market? NO - don't
   add.

Default: then add it.


Since there are a *lot* of CPU monitors, and a finite number of
developers, and I'm sure at least one CPU monitor needs more
maintenance, and wmbubblemon does the same job better, why add another?

cheers, Rich.

-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

Re: dselect survey

2004-12-10 Thread Bernd Eckenfels

On Fri, Dec 10, 2004 at 10:03:01PM +0100, Florent Rougon wrote:
 So, I guess some people simply don't like the *type* of control
 interface dselect offers, cause they want to see menus and widgets all
 around instead of having to learn that $keystroke will perform $action.
 
 Their main grief towards dselect is therefore formulated as awkward,
 non-intuitive user interface as you wrote above.

No, it is because the shortcuts are completely non-intuitive. I use
aptitude for  the good intuitive keymapping, not for its menu.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: dselect survey

2004-12-10 Thread Bernd Eckenfels

On Fri, Dec 10, 2004 at 12:03:03PM +0100, Florent Rougon wrote:
 I understand that this may be unpleasant to some people

It is not a problem for me that dseclt has no menu, it is a problem that the
keys are totally unintuitive, and some screens are really bothering.

aptitude has a nice usage enter means drill down, this is intuitive.

'q' means quit/leave level backward - this is intuitive

+-_ for selecting,  this is intuitive...

g for go, this is intuitive

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: dselect survey

2004-12-10 Thread Bernd Eckenfels

On Thu, Dec 09, 2004 at 10:22:08PM -0500, Daniel Burrows wrote:
   If you want to find alternatives for a virtual package, you can use 'd' and 
 'r' to navigate the dependency lists.  It's not as convenient as dselect, but 
 it works.

Well actually you can enter the package you dont want to have and see the
package which requires  it. You can enter the package (all with enter)  and
see the possible providers for a requirement and select one of it with +.

This is a style of  browsing which is intuitive to me.

Gruss
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

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

Rich Walker [EMAIL PROTECTED] writes:

 Though you could try the following set of criteria:

We could have all kinds of criteria.  The ones you propose are not, in
fact, our criteria.  Our criteria are something like:

1. Does the license meet the DFSG?
2. Is there a Debian maintainer willing to maintain or sponsor the
   package?

Now, you might want a different set of criteria, in which case, please
suggest them in the proper forum, which is not here.

My concern is that Saudi Arabia and China don't get to tell us what
our criteria are, and I would oppose any criterion that amounts to
give China a veto.  Your proposal allows China a veto in some cases,
and this makes it unreasonable to me.

It is outrageous to think that China's or Saudia Arabia's censorship
regimes should somehow influence our decision making in the slightest.

Thomas

add Date: field to Packages files

2004-12-10 Thread Dan Jacobson

Say, perhaps a Date: field could be added to Packages files.
I mean even dog food has the date stamped on it these days.
Even my crumby message has a Date: field.
Sure, as your eyes scan the MD5sum: field, the package's DNA is
registered in your brain. But us old fashioned types would still like
a Date: field.
 Well Jacobson, the date can be clearly seen at http://.../pool/n/norbowitz
But Mom said no more searching the web for dates, so now I'm offline.

Re: dselect survey

2004-12-10 Thread Bernhard R. Link

* Bernd Eckenfels [EMAIL PROTECTED] [041210 22:18]:
  Their main grief towards dselect is therefore formulated as awkward,
  non-intuitive user interface as you wrote above.
 
 No, it is because the shortcuts are completely non-intuitive. I use
 aptitude for  the good intuitive keymapping, not for its menu.

And I tried aptitude some time, but still use dselect when I want
a high-level interface. Dselect always tell me what to do next,
aptitude is some wild guessing what the keys might be, never showing
those I do need[1], doing strange (=counterintuitive) things and
so on...

Hochachtungsvoll,
  Bernhard R. Link

[1] for example the key to make it finaly do something

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Você ainda não conseguiu o que queria ? Anuncie GRATIS em Usados e Baratos

2004-12-10 Thread Usados e Baratos

Quer vender ou comprar produtos de informática ?

Venha participar do mais novo site de anúncios de classificados de produtos de 
informática e telefonia celular da internet! Você pode colocar vários anúncios 
sem limitação, colocar fotos do seus produtos, receber perguntas e respondê-las 
pelo próprio site, além de categorias organizadas. Dinamismo e segurança nas 
suas vendas e compras on-line! E isso tudo inteiramente GRÁTIS!! Seja um dos 
primeiros membros e ganhe beneficios especiais como participante Premium! 
Aproveite!

Usados e Baratos, o seu site de classificados de informática!

Acesse Já
http://www.usadosebaratos.com.br


__
Effective communication is easy, flexible and personal
http://www.x-mailer.com

Re: add Date: field to Packages files

2004-12-10 Thread Santiago Vila

On Sat, 11 Dec 2004, Dan Jacobson wrote:

 Say, perhaps a Date: field could be added to Packages files.
 I mean even dog food has the date stamped on it these days.
 Even my crumby message has a Date: field.
 Sure, as your eyes scan the MD5sum: field, the package's DNA is
 registered in your brain. But us old fashioned types would still like
 a Date: field.
  Well Jacobson, the date can be clearly seen at http://.../pool/n/norbowitz
 But Mom said no more searching the web for dates, so now I'm offline.

Even offline, files have time stamps in most modern filesystems out there.
Just remember to keep it when you download the Packages files, as it's
usually as available as the file itself.

Re: LCC and blobs

2004-12-10 Thread Matthew Palmer

On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote:
 On Dec 09, Bruce Perens [EMAIL PROTECTED] wrote:
  The whole system has to be DFSG-free. Debian won't compromise on that.
 Which DFSG? The original one or the clarified one?

Give it up, Marco.  Your little tantrums aren't cute.

  I have been thinking about the blob problem for a while. I propose to 
  remove blobs from the driver, and store them as files in  initramfs (the 
  kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) 
  or initrd.img. At boot time, the drivers would look for the blobs and 

 You may want to take a look at debian-legal, because some people there
 think that even free drivers for hardware devices which need an
 externally loaded firmware are not acceptable for main.

I presume you're referring to drivers which are useless without a non-free
firmware blob.  We should treat them exactly the same way as any other Free
software which is useless without some non-free component, and stick it in
contrib.

- Matt


signature.asc
Description: Digital signature

Re: dselect survey

Bernd Eckenfels [EMAIL PROTECTED] wrote:

 No, it is because the shortcuts are completely non-intuitive. I use
 aptitude for  the good intuitive keymapping, not for its menu.

I see. You find them utterly unintuitive, and are not alone. I don't
claim they are really intuitive (for what it means...), but *I* don't
find them to be a problem at all; and I'm not alone, either. Different
people, different tastes...

The good thing is, you can have your favorite program and I can have
mine, cause noone in Debian will object to a program being packaged for
a simple matter of taste, right? ;-)

-- 
Florent

Re: LCC and blobs

2004-12-10 Thread Brian Nelson

Matthew Palmer [EMAIL PROTECTED] writes:

 On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote:
 On Dec 09, Bruce Perens [EMAIL PROTECTED] wrote:
  I have been thinking about the blob problem for a while. I propose to 
  remove blobs from the driver, and store them as files in  initramfs (the 
  kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) 
  or initrd.img. At boot time, the drivers would look for the blobs and 

 You may want to take a look at debian-legal, because some people there
 think that even free drivers for hardware devices which need an
 externally loaded firmware are not acceptable for main.

 I presume you're referring to drivers which are useless without a non-free
 firmware blob.  We should treat them exactly the same way as any other Free
 software which is useless without some non-free component, and stick it in
 contrib.

Then we might as well remove the whole kernel from main, since most
devices depend on a non-free firmware blob to operate.  Why does it
matter if that blob is stored on the device itself in EPROM or loaded by
the kernel?  The end result is absolutely identical to the user.

If we choose not to distribute non-free firmware blobs, then fine.  I
still don't see why it has any effect on the device driver though.

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

Re: dselect survey

2004-12-10 Thread Daniel Burrows

On Friday 10 December 2004 04:23 pm, Bernd Eckenfels wrote:
 On Thu, Dec 09, 2004 at 10:22:08PM -0500, Daniel Burrows wrote:
    If you want to find alternatives for a virtual package, you can use 'd'
  and 'r' to navigate the dependency lists.  It's not as convenient as
  dselect, but it works.

 Well actually you can enter the package you dont want to have and see the
 package which requires  it. You can enter the package (all with enter)  and
 see the possible providers for a requirement and select one of it with +.

  That's true, but then you have to scroll past a lot of useless information; 
d/r (for Depends/Reverse Depends) will get you there quicker.

  Of course, bearing in mind that recent versions of aptitude (should) show 
the list of alternatives when you select the unwanted package, what would be 
really nice would be if you could Tab/mouse into the list and pick the 
alternative you want directly, the way you can in dselect...

  Daniel

-- 
/--- Daniel Burrows [EMAIL PROTECTED] --\
|We've got nothing to fear but the stuff that we're|
| afraid of! -- Fluble |
\ Evil Overlord, Inc: http://www.eviloverlord.com --/


pgpEZhRKFSuHO.pgp
Description: PGP signature

Re: LCC and blobs

On Fri, 2004-12-10 at 15:21 -0800, Brian Nelson wrote:
 Matthew Palmer [EMAIL PROTECTED] writes:
 
  On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote:
  On Dec 09, Bruce Perens [EMAIL PROTECTED] wrote:
[snip]
 
 Then we might as well remove the whole kernel from main, since most
 devices depend on a non-free firmware blob to operate.  Why does it

Most ?

Or are you stretching beyond reason, to include stuff like the 
BIOS, which isn't in the kernel?

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

Give a man a fish, you feed him for a day, teach him to fish, he
gets mad at you for making him have to work so hard.



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

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

2004-12-10 Thread Rich Walker

Thomas Bushnell BSG [EMAIL PROTECTED] writes:

 Rich Walker [EMAIL PROTECTED] writes:

 Though you could try the following set of criteria:

[I added these back in for the sake of clarity]

1. Are there already similar packages in Debian? NO - okay, add.

2. Does it offer significant *technical* advantages over those packages?
   YES - okay, add.

3. Are any of those other similar packages poorly maintained? YES -
   don't add another until the others are cleaned up or removed - so
   don't add

4. Hairsplitting time - is there likelihood that adding it will cause
   grave distress to some proportion of the target market? NO - don't
   add.

Default: then add it.


 We could have all kinds of criteria.  The ones you propose are not, in
 fact, our criteria.  Our criteria are something like:

 1. Does the license meet the DFSG?
 2. Is there a Debian maintainer willing to maintain or sponsor the
package?


These are givens. I know this. It can't move from valid-ITP to package
without this.


 Now, you might want a different set of criteria, in which case, please
 suggest them in the proper forum, which is not here.

Actually, I don't want a different set of criteria. As a user, I am
concerned that Debian is in danger of having a thousand CPU
monitors[1] all with RC bugs. A process for restricting addition of
semi-duplicate packages might reduce workloads all round, and improve
quality of installed packages.

 My concern is that Saudi Arabia and China don't get to tell us what
 our criteria are, and I would oppose any criterion that amounts to
 give China a veto.  Your proposal allows China a veto in some cases,
 and this makes it unreasonable to me.

Not quite. I simply suggest that *in the absence of any technical reason
why*, and *in the presence of a social reason why not*, it would be
polite to adopt why not. 

That social reason might be I can get tortured for possessing this and
it might be pornview is tacky as a package name - come[2] up with a
better one or just I believe this license isn't DFSG-free.

Of course, the fact that the package under discussion can make
possession of a Debian CD illegal in certain countries[3] trumps either
of our arguments.

 It is outrageous to think that China's or Saudia Arabia's censorship
 regimes should somehow influence our decision making in the slightest.

I believe the correct flame-inducing argument at this point is tell
that to the first person tortured or executed for possessing a Debian CD
with hot-babe on it *who was not aware it was there*.

Testimony elsewhere in this thread suggests that *possession* in those
countries is a capital crime, with or without knowledge.

This would seem to make adding this package a breach of the Social
Contract, clause 4. Getting your users executed un-necessarily is, it's
true, a very idealist thing to do, but I can't see everyone signing up
to it.



cheers, Rich.





Footnotes: 
[1]  Or any other common package type. Editors. MP3 players. Playlist
 managers. RSS feed agglomeraters. Xbiff clones. 

[2]  For my English readers - I did that on purpose

[3]  Non-US exists because export of strong crypto from the US is an
 illegal act in the US. Hence, Debian has already accepted that
 local laws trump idealism.

-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

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