Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Don Armstrong]

On Thu, 16 Jun 2005, Eric Dorland wrote:
> * Don Armstrong ([EMAIL PROTECTED]) wrote:
> > All of MoFo trademarks that were not being used in a manner
> > consistent with trademark law[2] would have to be expunged from
> > the work,
> 
> What trademarks are you referring to? Already the Debian packages
> don't use any of the trademarked images and logos? 

If we don't use any trademarked images, logos, or phrases, what
exactly are we talking about here?

I'd hope there are more things at issue here than the name of the
script that eventually calls another script that eventually calls the
binary. [If that's all that we're discussing, I'd suggest just asking
a low priority debconf question about installing a
/usr/bin/mozilla-firefox symlink that links to the package in
question, and rename the binary package.]

  
Don Armstrong

-- 
The game of science is, in principle, without end. He who decides one
day that scientific statements do not call for any further test, and
that they can be regarded as finally verified, retires from the game.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ �11

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: And now for something completely different... etch!

[Joerg Friedrich]

Steve Langasek schrieb am Dienstag, 14. Juni 2005 um 03:12:09 -0700:
> Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>

Short question: 
What does LFS mean? The first thing which comes into my mind is Linux
from Scratch. Seems not to fit in this context.



-- 
J�Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.

Re: Question regarding 'offensive' material

[Kevin Mark]

On Wed, Jun 15, 2005 at 04:08:57PM +0200, Ralf Hildebrandt wrote:
> * Thijs Kinkhorst <[EMAIL PROTECTED]>:
> 
> > than the pictures in any sexual education book). So we have to do
> > something about it, because it's a given. I was thinking that maybe
> > debtags would provide a solution. You can invent a tag "contains remote
> > references to natural reproduction" and anyone can use that to filter out
> > unwanted packages.
> 
> Make that "contains remote references to natural human reproduction"
> since the reproduction of amoebas would hardly offend anyone.
Are we banning any of John Conway's Life demos as they show abstract
cellular reproduction? x-) Those dirty, dirty ameoba!
cheers,
kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/16/05, Russell Coker <[EMAIL PROTECTED]> wrote:
> But if someone can change the cache of data written by prelink then why
> couldn't they also change the program that does the md5 checks to make it
> always return a good result?

A long, long time ago, you were supposed to boot from a read-only
floppy and run the virus scanner from there. I guess the same applies
here, if you really wish to be sure.

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/16/05, Joerg Friedrich <[EMAIL PROTECTED]> wrote:
> Steve Langasek schrieb am Dienstag, 14. Juni 2005 um 03:12:09 -0700:
> > Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>
> 
> Short question:
> What does LFS mean? The first thing which comes into my mind is Linux
> from Scratch. Seems not to fit in this context.

http://www.google.com/search?q=define:lfs

My guess: Large File Support, specifically files larger than 2Gb on
32-bit systems.

Re: And now for something completely different... etch!

[Peter 'p2' De Schrijver]

> 
> Ummm... And if instead of asking the user for a disk change, this
> mini-initrd just keeps polling the floppy for a non-erroneous read
> (this means, the drive is not empty) with the correct magic at the
> correct place?

I don't think you actually have to read anything. You can use the disk
change line to see if a disk has been inserted or not.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

relocation error(s) with various binaries

[Chris Gorman]

Hello,

Recently my /usr/ directory had a bad recovery in which a great deal of
/usr/lib was placed into lost+found additionaly, once the recovery was
complete the dynamic loader was complaining about the libraries no longer
having the proper signatures.  So, I decided to manage this with a
recovery of most of the libraries via apt-get.  This included the
libraries that ldconfig was complaining about which was most of X in
addition to various libraries from /usr/lib.  This worked fairly well as
my system is mostly usable again, however I have a lingering problem with
relocation errors.  (Note I did not have these reloc problems prior to the
fs crash.)

for example firefox

$ sh -x firefox
-- SNIP --
+ exec /usr/lib/mozilla-firefox/firefox-bin -a firefox
/usr/lib/mozilla-firefox/firefox-bin: relocation error:
/usr/lib/libXrender.so.1: undefined symbol: _Xglobal_lock

mozilla, which fails in it's launch script at ...

$ sh -x mozilla
-- SNIP --
++ /usr/lib/mozilla/mozilla-xremote-client -a mozilla 'ping()'
++ RETURN_VAL=127
++ '[' 127 -eq 2 ']'
-- SNIP --

because of ...

/usr/lib/mozilla/mozilla-xremote-client: relocation error:
/usr/lib/libXcursor.so.1: undefined symbol: _Xglobal_lock

and finaly ogle.

$ sh -x ogle
-- SNIP --
ogle_vout: relocation error: /usr/lib/libXcursor.so.1: undefined symbol:
_Xglobal_lock

I'm running a sid system, recently updated.  I'm wondering if during my
exeuberence in restoring my system caused some a bad library combination?
The other bizarre thing is that both libXcursor and libXrender have the
string _Xglobal_lock within them, indicating that _Xglobal_lock should be
defined.

Are these errors due to the dynamic loader relocating _Xglobal_lock
to some inappropriate offset in the library?  Or possibly some other
function to _Xglobal_lock?  Any suggestions on how to fix this?

Please CC me directly as I am not subscribed to this particular list.

Thanks

Chris Gorman


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

Re: relocation error(s) with various binaries

[Peter Samuelson]

[Chris Gorman]
> + exec /usr/lib/mozilla-firefox/firefox-bin -a firefox
> /usr/lib/mozilla-firefox/firefox-bin: relocation error:
> /usr/lib/libXrender.so.1: undefined symbol: _Xglobal_lock

Try reinstalling libx11-6.
Verify that it has the symbol in question:

  nm --dynamic /usr/X11R6/lib/libX11.so.6 | grep _Xglobal_lock

should reveal it as a "B" symbol (uninitialised data).


signature.asc
Description: Digital signature

Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path

[Cesare Tensi]

Hy,

I believe that the question is going to deadlocking itself.
If the user need to using the "ifconfig" program, that user must
include the right directory where was originally located ("/sbin").

Just 2 my cent

Cesare

On 6/16/05, Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> Richard Kettlewell dijo [Fri, Jun 10, 2005 at 03:42:01PM +0100]:
> > I think it doesn't go far enough.
> >
> >   mv sbin/* bin
> >   rmdir sbin
> >   ln -s bin sbin
> >
> > ...and the problem goes away forever.
> 
> You type too fast.
> 
> Are you _sure_ no two Debian packages provide overlapping /bin/$that
> and /sbin/$that ? Or /usr/bin/$foo and /usr/sbin/$foo ? Or (going back
> some flamewars^Wweeks) /bin/$bleh and /usr/bin/$bleh ? ...Or,
> mix-and-match, /sbin/$this and /usr/bin/$this?
> 
> Greetings,

Re: And now for something completely different... etch!

[Chris Halls]

On Wednesday 15 Jun 2005 10:09, Steve Langasek wrote:
> On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote:
> > I didn't see anyone proposing prelinking so far.  I've seen rumors
> > that program start time for some programs decrease a lot if prelinking
> > is enabled.  It would be nice if we could speed up the login time, or
> > for example the openoffice start time.  Is prelinking the way to go?
> > Should it be enabled by default?
>
> Using prelink invalidates the md5sums of files belonging to Debian
> packages. Has anyone done any work to address this?

Not that I know of, and that's why we do not enable it by default in OOo.

Actually, on the subject of OOo load time, that should decrease significantly 
once we have it compiled with the new gcc that has symbol visibility support.  
75% of OOo startup time is spent in the dynamic linker, so reducing the 
number of symbols that need to be resolved will make a big difference.

Chris


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Raphael Hertzog]

Le jeudi 16 juin 2005 à 01:03 -0400, Eric Dorland a écrit :
> > The Mozilla Foundation have made many shows of good faith via Gervase in
> > this long running debate which he has continued to follow despite the
> > criticisms levelled at him/the Mozilla Foundation.  Obviously if they
> > turn around in the future and say "oh we hate your blah patch you can't
> > use the name" then we can /then/ make it a big issue and change the name
> > to iceweasel and be happy.  I honestly think this is unlikely though and
> > to do so now would be not only be premature but be harmful to users and
> > your/the project's relationship with Mozilla.
> 
> Well actually to some degree they've already done this. Recently the
> CAcert  (www.cacert.org) project's root CA made it into our
> ca-certificates package. However I can't have Firefox use that as a
> root CA by default and still use the trademark:
> 
> http://article.gmane.org/gmane.comp.security.cacert/2752
> 
> This seems like a pretty unacceptable to me.

Given the trademark license, you can just add the CA-Cert and wait until
MoFo complains to you... if they decide to complain !

Another approach (which would be more respectful to MoFo) would be to
ask them to add the CA certificate into upstream's list of trusted CA so
that the whole issue becomes a non-issue for us. We're all reasonable
people, if we add that CA cert it's because we trust them. Given our
track of security consciousness I see no reason why MoFo wouldn't trust
what we trust (that's even the reason why they made an exceptin).

Third approach is to ask again for an exception concerning this change.

Choose whatever you prefer. In any case it doesn't change anything to
the status of the software ... Firefox with its original name is free
software and should be included as-is within Debian.

Furthermore I'm sure that you can avoid that problem by using a debconf
question: "Do you want to add the CA certs contained in CA-certificates
in the list of CA trusted by Firefox ?"

We don't change the list of CA certs but we're letting the user change
it on his own machine. And I suppose that this has always been
possible... (it was just more difficult for the user)

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org


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

Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path

[Richard Kettlewell]

Gunnar Wolf <[EMAIL PROTECTED]> writes:
> Richard Kettlewell dijo [Fri, Jun 10, 2005 at 03:42:01PM +0100]:

>> I think it doesn't go far enough.
>> 
>>   mv sbin/* bin
>>   rmdir sbin
>>   ln -s bin sbin
>> 
>> ...and the problem goes away forever.
> 
> You type too fast.
> 
> Are you _sure_ no two Debian packages provide overlapping /bin/$that
> and /sbin/$that ? Or /usr/bin/$foo and /usr/sbin/$foo ? Or (going back
> some flamewars^Wweeks) /bin/$bleh and /usr/bin/$bleh ? ...Or,
> mix-and-match, /sbin/$this and /usr/bin/$this?

There are some examples of symlinks between bin and sbin, presumably
to work around the existing sbin braindamage.  /sbin/ip -> /bin/ip,
for instance.  Not hard to cope with when you make the transition and
for the longer term, dpkg could probably be taught to handle this case
sensibly.

If there's a case where you have /bin/foo and /sbin/foo actually
meaning something different then that's plainly a bug in at least one
of them, if not both, and needs fixing regardless.

-- 
http://www.greenend.org.uk/rjk/


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Simon Huggins]

On Thu, Jun 16, 2005 at 01:03:52AM -0400, Eric Dorland wrote:
> * Simon Huggins ([EMAIL PROTECTED]) wrote:
> > On Wed, Jun 15, 2005 at 12:07:16PM -0400, Eric Dorland wrote:
> > > Indeed the most pragmatic thing to do is to keep the name. But you
> > > don't feel that accepting a deal with the Mozilla foundation is
> > > against DFSG #8? Why not? 
> > You have the right to modify the code whether or not it is in Debian.
> > The license to the code is not specific to Debian so I don't believe
> > that this contradicts the spirit of DFSG #8.  The rights are the same
> > for you as they are for users i.e. they have the right to go to Mozilla
> > and prove they produce good enough software to use Mozilla's trademark
> > and call it firefox just as you have.  The license isn't specific to
> > Debian therefore this satisfies that clause.
> The code license is not in question. The trademark license/policy is. 

Right, my point is that the important thing for downstream of Debian is
that the code is free not what the name is or if it has to be changed.
If we can keep the name that's good for our users though so we should.

> > The Mozilla Foundation have made many shows of good faith via
> > Gervase in this long running debate which he has continued to follow
> > despite the criticisms levelled at him/the Mozilla Foundation.
> > Obviously if they turn around in the future and say "oh we hate your
> > blah patch you can't use the name" then we can /then/ make it a big
> > issue and change the name to iceweasel and be happy.  I honestly
> > think this is unlikely though and to do so now would be not only be
> > premature but be harmful to users and your/the project's
> > relationship with Mozilla.
> Well actually to some degree they've already done this. Recently the
> CAcert  (www.cacert.org) project's root CA made it into our
> ca-certificates package. However I can't have Firefox use that as a
> root CA by default and still use the trademark:
> http://article.gmane.org/gmane.comp.security.cacert/2752

> This seems like a pretty unacceptable to me.

Hmm.  That almost sets a precedent for stopping any changes they don't
like via the blunt tool of the trademark license.

Do they have the same problems with the SPI root certs?  What are their
reasons for this?  Do they have the same concerns that you raise in
#309564?

Simon.

-- 
UK based domain, email and web hosting ***/"To infinity and beyond!" /*
http://www.blackcatnetworks.co.uk/ **/  /**
[EMAIL PROTECTED]   */  /***
Black Cat Networks /  /


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Simon Huggins]

On Wed, Jun 15, 2005 at 08:20:48PM -0700, Russ Allbery wrote:
> Peter Samuelson <[EMAIL PROTECTED]> writes:
> > That there is such a hue and cry over rebranding Firefox in Debian
> > indicates to me that it *is* a significant burden we would be (and are
> > now) asking of our downstream users.
> Second, the real problems with rebranding are not with the technical
> work that has to happen, from the sound of it.  They're with user
> recognition and the ability of users to find the right package for
> something they want to run.  That *is* a significant issue, at least
> in my opinion, but Debian taking that hit doesn't do *anything* to
> help our downstream users.  They still end up having to either take
> the same hit or now undo Debian work to get back to the name that
> their users will recognize.

I was under the impression that downstreams could call the packages
firefox as they had been blessed with official Debian penguin pee as
long as they didn't then change them and it was only when they were
modified that they potentially had to go to the Mozilla Foundation for a
license.

Did I get the wrong end of the stick?

Simon.

-- 
*  benj: mais il y a des thumbnails en 1600x1200 ;) *
|   |
*   *
   Brought to you by the letter J and the number  9


signature.asc
Description: Digital signature

Bug#314452: ITP: xfplan -- Xwindows general aviation flight planner

[Stephen Birch]

Package: wnpp
Severity: wishlist
Owner: Stephen Birch <[EMAIL PROTECTED]>

This is an X Windows version of fplan (ITP files 311070).

* Package name: xfplan
  Version : 0.1
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/fplan/
* License : GPL
  Description : Xwindows general aviation flight planner

The input to xfplan is a planfile that can be created with the user's
favorite plain text editor. A self explanatory language is used to
describe the flight; departure and destination airports, intermediate
waypoints, navigation aids, winds aloft, and fuel consumption rates. The
flight plan produced by xfplan includes; wind corrected magnetic
headings, distance, estimated time and fuel consumption for each leg,
latitude and longitude for each checkpoint, and optional VOR fixes. A
graphical preview of the flight is available on systems with X11 Windows
and the XView Toolkit.

This program is to be used for preliminary flight planning only. It is
not to be used as an official source of navigation information. The
database it uses is not guaranteed to be accurate or current. Also,
the program itself is likely to still contain some bugs and is not
intended to be a substitute for official flight planning information.

-- System Information:
Debian Release: 3.1
Architecture: Any
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Greylisting for @debian.org email, please

[Santiago Vila]

Now that we have released sarge, I would like to ask debian-admin and
the Project Leader to consider seriously doing something to reduce the
level of spam we have to receive, store, and filter in our @debian.org
addresses.

For example, we could use greylisting. Or we could reject messages that
are known to come directly from trojanized windows machines acting as
open proxies. Or even better, we could do both things.

At this point of time, in the year 2005, doing absolutely nothing to
prevent spam reaching our inboxes is not reasonable anymore.

Thanks.


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

Re: And now for something completely different... etch!

[Enrico Zini]

On Thu, Jun 16, 2005 at 01:01:17AM -0500, Gunnar Wolf wrote:

> H... Silly me thought that Italian was the only Latin language
> which used no diacritics. Which kind of accents does it have?

Italian can have accents over vowels, some are read differently if they
are grave or acute:

  à è é í ò ó ú
  À È É Í Ò Ó Ú

it's also matter of debate if the accent over a, i or u is grave or
acute.

Dieresis are used in poetry, to split a diptongue (piëtà) as well as
when writing words coming from some dialect (siüra).

Circumflexes were used in the past when a word becoming plural would end
in double 'i' (declivî).

More could show up when spelling arcaic Italian (who sometimes had an
extra letter for a sweet 'z' sound), dialects (who have all sort of
diacritics that can change from dialect to dialect and from spelling
method to spelling method) or of course when writing mixed languages in
the boundary regions where there is more than one official language.


Ciao,

Enrico

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


signature.asc
Description: Digital signature

Re: Greylisting for @debian.org email, please

[Pierre Habouzit]

Le Jeu 16 Juin 2005 14:33, Santiago Vila a écrit :
> Now that we have released sarge, I would like to ask debian-admin and
> the Project Leader to consider seriously doing something to reduce
> the level of spam we have to receive, store, and filter in our
> @debian.org addresses.
>
> For example, we could use greylisting. Or we could reject messages
> that are known to come directly from trojanized windows machines
> acting as open proxies. Or even better, we could do both things.

I fully disagree, greylisting is really painful, and I really hope this 
would never be used as a default rule for email filtering.

I'd prefer to see some tools like dspam/bogofilter/... used instead of 
the heavy and not efficient enought SA.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org

Mozilla Foundation Trademarks

[Humberto Massa Guimarães]

> > What trademarks are you referring to? Already the Debian
> > packages don't use any of the trademarked images and logos? 
> 
> If we don't use any trademarked images, logos, or phrases, what
> exactly are we talking about here?

As I think this is a very nice question, could Eric or any other
person identify which Mozilla Foundation trademarks are used in our
packages (and where)?

--
Thanks,
Massa


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

Re: Greylisting for @debian.org email, please

[Pascal Hakim]

On Thu, 2005-06-16 at 15:09 +0200, Pierre Habouzit wrote:
> Le Jeu 16 Juin 2005 14:33, Santiago Vila a écrit :
> > Now that we have released sarge, I would like to ask debian-admin and
> > the Project Leader to consider seriously doing something to reduce
> > the level of spam we have to receive, store, and filter in our
> > @debian.org addresses.
> >
> > For example, we could use greylisting. Or we could reject messages
> > that are known to come directly from trojanized windows machines
> > acting as open proxies. Or even better, we could do both things.
> 
> I fully disagree, greylisting is really painful, and I really hope this 
> would never be used as a default rule for email filtering.
> 
> I'd prefer to see some tools like dspam/bogofilter/... used instead of 
> the heavy and not efficient enought SA.

There's no reason why we can't have different settings for different
accounts based on what people prefer, whether this includes blacklists,
greylisting or various combinations of spam filters.

Cheers,

Pasc

Re: And now for something completely different... etch!

[Helmut Wollmersdorfer]

Gunnar Wolf wrote:

Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]:



I've been it_IT.UTF-8 for quite a while with no problems.  And I also
get to be able to write the name of my girlfriend, which Latin1 cannot
encode, together with accented Italian words, which BIG5 cannot encode.



H... Silly me thought that Italian was the only Latin language
which used no diacritics. Which kind of accents does it have?


Even en_GB has diacritics.

Hopefully all this encoding problems disappear with the growing 
popularity of UNICODE/UTF-8.


E.g. besides German, Hungarian, Slowenian und Croation are official 
languages here in Austria, which must be supported through local 
government. Choosing Latin1 is a common mistake, 'Eastern Latin' would 
be the better choice. Besides it would IMHO be more political correct to 
write the names of all the Polish, Balkan, French, Eastern, Scandinavian 
and Latinos living here with original diacritics.


Helmut Wollmersdorfer


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

Re: TODO for etch ?

[Marco d'Itri]

On Jun 16, Paul TBBle Hampson <[EMAIL PROTECTED]> wrote:

> And there there's hotplug-ng [1], a hotplug replacement in C, which I'm
> looking forward to a packaging of, now that klibc's in the ITP list.
You'd better not, because I have already ITP'ed it a long time ago. :-)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Greylisting for @debian.org email, please

[Stig Sandbeck Mathisen]

Santiago Vila <[EMAIL PROTECTED]> writes:

> Now that we have released sarge, I would like to ask debian-admin
> and the Project Leader to consider seriously doing something to
> reduce the level of spam we have to receive, store, and filter in
> our @debian.org addresses.
>
> For example, we could use greylisting.

Greylisting scales well. Combined with a liberal set of whitelisted
clients, you also reduce complaints about greylisting.

I've got experience with use of greylisting for a mail platform with
over 1M accounts.  Enabling greylisting for this platform reduced
delivered spam with 80-90%. This is simply because most of the
infected machines does not attempt a second delivery of a mail
connection terminated with a 4xx (temporary) error message.

For the MX for lists.debian.org, murphy.debian.org, which runs
postfix, the "postgrey" daemon seems to run well, althoug I have not
used this for large installations yet.

master.debian.org runs exim, which also have greylisting 

> Or we could reject messages that are known to come directly from
> trojanized windows machines acting as open proxies. Or even better,
> we could do both things.

sbl+xbl seems to have a list with a short timeout, for servers sending
out spam, in addition to the ROKSO list.

However, I would rather use this list inside SpamAssassin, instead of
using just the list to deny SMTP connections.

Also, any technical means used to reduce spam will be temporary, since
spammers continuously adapt to changes in the environment they abuse
to earn money.  

-- 
Stig Sandbeck Mathisen


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

heimdal/mit-krb mix in ssh-krb5 via libnss-ldap

[Jeremie Koenig]

I got no luck lately and managed to make ssh-krb5 fail due to library
linkage weirdness. It took me ages to figure out what was going on!
(I learnt alot on the way, however.)

To reproduce the breakage:
 1. install libsasl2-modules-gssapi-heimdal, libnss-ldap and ssh-krb5
(something else linked against libkrb53 may "work" as well);
 2. configure /etc/nsswitch.conf to use ldap for some lookups;
 3. configure /etc/ldap/ldap.conf or ~/.ldaprc to use SASL
authentication.

Then run ssh-krb5, linked with some mit-kerberos libraries. NSS pulls
LDAP, which pulls SASL, which pulls its heimdal GSSAPI module, which
pulls a lot of heimdal stuff. GDB shows them all when attach'ing to the
process. ssh-krb5's gssapi authentications spew out a few "debug1:
\n\n\n" lines and fail silently, which is more than graceful with such a
mess in place if you ask me :-P

The quick fix was to install MIT's gssapi SASL module rather than
heimdal's one. Surely a library wizard here can think of a better one,
or at least a specific (set of) package(s) to be blamed.

There must be a way to use an nss module without it's library
dependencies polluting what it's called from! In contrast sshd doesn't
experience such a thing while it's linked against the same MIT stuff and
pam, which uses both libpam-{ldap,heimdal} here. Maybe sasl or the nss
are improperly loading their modules?

Thanks for any hints before I get to source code...

-- 
Jeremie Koenig <[EMAIL PROTECTED]>


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Gervase Markham]

Simon Huggins wrote:

On Thu, Jun 16, 2005 at 01:03:52AM -0400, Eric Dorland wrote:

* Simon Huggins ([EMAIL PROTECTED]) wrote:
Well actually to some degree they've already done this. Recently the
CAcert  (www.cacert.org) project's root CA made it into our
ca-certificates package. However I can't have Firefox use that as a
root CA by default and still use the trademark:
http://article.gmane.org/gmane.comp.security.cacert/2752

This seems like a pretty unacceptable to me.


Hmm.  That almost sets a precedent for stopping any changes they don't
like via the blunt tool of the trademark license.


I'd appreciate it if I was CCed on all parts of this discussion, as I'm 
not a member of debian-devel. Thanks to Simon for bringing me back in here.


I'm sure you are aware of the significant risks to users associated with 
adding a root certificate to a browser store.


However, having consulted carefully with my mozilla.org colleagues on 
this issue, it's not as black and white as I made out in the original 
post to the CACert list. Consequently, I would very much like to hear 
more about Debian's policy and procedures for vetting certificate 
authorities who wish to have their roots included in the Debian store.


With regard to the "blunt tool", the point of a trademark licence is to 
exercise some control over what gets labelled "Firefox". If Debian were 
able to make arbitrary changes we didn't like and still use the 
trademark, there would be no licence! :-) And adding a new root cert is 
in an entirely different category to e.g. patching Firefox to put its 
profile somewhere which fits in with the Debian FHS.


Gerv


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

Re: Mozilla Foundation Trademarks

[Alexander Sack]

Humberto Massa Guimarães wrote:

>>>What trademarks are you referring to? Already the Debian
>>>packages don't use any of the trademarked images and logos? 
>>>  
>>>
>>If we don't use any trademarked images, logos, or phrases, what
>>exactly are we talking about here?
>>
>>
>
>As I think this is a very nice question, could Eric or any other
>person identify which Mozilla Foundation trademarks are used in our
>packages (and where)?
>
>
>  
>
In general the part of the MoFo brand we are talking about is the
product name (e.g. firefox, thunderbird, sunbird). From what I can
recall now, it is used in the help menu, the about box, the package-name
and the window title bar.

-- 
 GPG messages preferred.   |  .''`.  ** Debian GNU/Linux **
 Alexander Sack| : :' :  The  universal
 [EMAIL PROTECTED]   | `. `'  Operating System
 http://www.asoftsite.org  |   `-http://www.debian.org/

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Russ Allbery]

Simon Huggins <[EMAIL PROTECTED]> writes:
> On Wed, Jun 15, 2005 at 08:20:48PM -0700, Russ Allbery wrote:

>> Second, the real problems with rebranding are not with the technical
>> work that has to happen, from the sound of it.  They're with user
>> recognition and the ability of users to find the right package for
>> something they want to run.  That *is* a significant issue, at least in
>> my opinion, but Debian taking that hit doesn't do *anything* to help
>> our downstream users.  They still end up having to either take the same
>> hit or now undo Debian work to get back to the name that their users
>> will recognize.

> I was under the impression that downstreams could call the packages
> firefox as they had been blessed with official Debian penguin pee as
> long as they didn't then change them and it was only when they were
> modified that they potentially had to go to the Mozilla Foundation for a
> license.

> Did I get the wrong end of the stick?

No, I think you're right.  This is my point:

 * If we do not rebrand Firefox, we benefit our users because they can
   still find the browser.  We require our downstream packagers to do the
   work of rebranding (which is apparently not that difficult) and incur
   the hit on user recognition if they change the package further.

 * If we do rebrand Firefox, all of our users take the hit on user
   recognition, and in addition, all of our downstream packagers *also*
   take the hit on user recognition even if they didn't want to change the
   package at all.  The only way they could avoid that is to both talk to
   MoFo themselves *and* undo the technical work of rebranding.

I'm totally failing to see how rebranding Firefox makes life better for
our users, *including* our downstream packagers.  It looks to me like it
makes it worse across the board.

That being said, we absolutely should not allow the trademark issue to
give MoFo any more of a veto on package changes than any other upstream
would have.  If we feel we need to make a change to improve the package
for our users and MoFo disagrees with that change and says we can't use
the trademark if we make it, we should make it, rebrand Firefox, and go on
with our lives.  Debian as a project already tries to work with upstream
whenever possible, and certainly we should continue to do this, but I'm
*extremely* uncomfortable with the idea of this trademark license being
used as a stick to prevent Debian from producing the distribution we want
to produce.

The most disturbing thing I've seen in this entire thread so far (and I'm
trying not to overreact, since I don't know the whole story) is hearing
that Mozilla might veto root CA additions using the trademark liense as a
stick.  I think it's a horrible idea to rebrand Firefox out of worries of
avoiding a Debian-specific deal, but if the branding ends up being used
for things like supporting the evil Verisign monopoly against more
reasonable ways of handling TLS certificates, it would be worth rebranding
to me to avoid having to wait on those sorts of changes.  On the other
hand, if that statement was just a security concern and a request that
MoFo be given time to vet new CA additions before they're just added
downstream, that's probably quite reasonable and the invocation of the
trademark license stick may have just been a poor choice of wording on
their part.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: heimdal/mit-krb mix in ssh-krb5 via libnss-ldap

[Russ Allbery]

Jeremie Koenig <[EMAIL PROTECTED]> writes:

> I got no luck lately and managed to make ssh-krb5 fail due to library
> linkage weirdness. It took me ages to figure out what was going on!  (I
> learnt alot on the way, however.)

> To reproduce the breakage:
>  1. install libsasl2-modules-gssapi-heimdal, libnss-ldap and ssh-krb5
> (something else linked against libkrb53 may "work" as well);
>  2. configure /etc/nsswitch.conf to use ldap for some lookups;
>  3. configure /etc/ldap/ldap.conf or ~/.ldaprc to use SASL
> authentication.

> Then run ssh-krb5, linked with some mit-kerberos libraries. NSS pulls
> LDAP, which pulls SASL, which pulls its heimdal GSSAPI module, which
> pulls a lot of heimdal stuff. GDB shows them all when attach'ing to the
> process. ssh-krb5's gssapi authentications spew out a few "debug1:
> \n\n\n" lines and fail silently, which is more than graceful with such a
> mess in place if you ask me :-P

> The quick fix was to install MIT's gssapi SASL module rather than
> heimdal's one. Surely a library wizard here can think of a better one,
> or at least a specific (set of) package(s) to be blamed.

You've pretty much got the solution I'd recommend.  Heimdal and MIT
Kerberos are parallel implementations of the same protocol and API and
share *most* of the same function signatures but not all.  This means
they're both not interchangeable and they stomp on each other.  You're not
going to be able to load both libraries into the same namespace and have
them be comfortable next to each other.  It's kind of like trying to use
both OpenSSL and gnutls in the same binary, except possibly even worse.

It's really best to decide whether you're using Heimdal or you're using
MIT Kerberos and then install a consistent set of libraries and programs
across the board.  Many things in Debian are built for both in two
separate packages, but I think there's slightly more available for MIT
(including ssh-krb5) than for Heimdal at the moment.

Even if you did deal with the NSS situation, at some point something on
your system is going to link with both the krb5 libraries and SASL
directly, at which point you're likely to have the same issues with it.

That being said...

> There must be a way to use an nss module without it's library
> dependencies polluting what it's called from! In contrast sshd doesn't
> experience such a thing while it's linked against the same MIT stuff and
> pam, which uses both libpam-{ldap,heimdal} here. Maybe sasl or the nss
> are improperly loading their modules?

...this is an interesting point.  I seem to recall that there's some way
with dlopen and ELF to isolate the symbol table of the newly loaded shared
object and its dependencies from the rest of the program, but I don't know
if that's sufficient to prevent this sort of clobber.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: And now for something completely different... etch!

[Paul TBBle Hampson]

On Thu, Jun 09, 2005 at 10:09:06AM +0200, Tollef Fog Heen wrote:
> * Christian Perrier 

> | > Again, do not mess with cultures you do not understand.
> | 
> | Do you have real examples?

> IRC.  An example is the current irssi in Debian which doesn't do
> recoding between different locales.  (And that is needed, since IRC
> doesn't have a charset concept and there are still loads and loads of
> users out there with clients which interpret everything as Latin1.)

I'm not clear how this is an argument against UTF-8 by default...?

The charset of your terminal is orthogonal to the charset you're
talking on the IRC network with to my mind, since even the built-in
recode support lets you set a default charset for IRC traffic.

-- 
---
Paul "TBBle" Hampson, MCSE
8th 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.
---


pgpFwhEZSTmSu.pgp
Description: PGP signature

Re: TODO for etch ?

[Paul TBBle Hampson]

On Thu, Jun 16, 2005 at 03:05:52PM +0200, Marco d'Itri wrote:
> On Jun 16, Paul TBBle Hampson <[EMAIL PROTECTED]> wrote:

> > And there there's hotplug-ng [1], a hotplug replacement in C, which I'm
> > looking forward to a packaging of, now that klibc's in the ITP list.

> You'd better not, because I have already ITP'ed it a long time ago. :-)

Ooops. I meant I look forward to it being packaged, not to packaging it myself.

I want to _use_ it, since my laptop's boot time is currently approximating the
time of any given task I do when using it.

^_^

-- 
---
Paul "TBBle" Hampson, MCSE
8th 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.
---


pgpzHcT7Dw7KM.pgp
Description: PGP signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Don Armstrong ([EMAIL PROTECTED]) wrote:
> On Thu, 16 Jun 2005, Eric Dorland wrote:
> > * Don Armstrong ([EMAIL PROTECTED]) wrote:
> > > All of MoFo trademarks that were not being used in a manner
> > > consistent with trademark law[2] would have to be expunged from
> > > the work,
> > 
> > What trademarks are you referring to? Already the Debian packages
> > don't use any of the trademarked images and logos? 
> 
> If we don't use any trademarked images, logos, or phrases, what
> exactly are we talking about here?

The term "Firefox" is what trademarked, and the only trademark still
in the Debian package AFAIK. That's what we're talking about. 
 
> I'd hope there are more things at issue here than the name of the
> script that eventually calls another script that eventually calls the
> binary. [If that's all that we're discussing, I'd suggest just asking
> a low priority debconf question about installing a
> /usr/bin/mozilla-firefox symlink that links to the package in
> question, and rename the binary package.]

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Simon Huggins ([EMAIL PROTECTED]) wrote:
> On Wed, Jun 15, 2005 at 08:20:48PM -0700, Russ Allbery wrote:
> > Peter Samuelson <[EMAIL PROTECTED]> writes:
> > > That there is such a hue and cry over rebranding Firefox in Debian
> > > indicates to me that it *is* a significant burden we would be (and are
> > > now) asking of our downstream users.
> > Second, the real problems with rebranding are not with the technical
> > work that has to happen, from the sound of it.  They're with user
> > recognition and the ability of users to find the right package for
> > something they want to run.  That *is* a significant issue, at least
> > in my opinion, but Debian taking that hit doesn't do *anything* to
> > help our downstream users.  They still end up having to either take
> > the same hit or now undo Debian work to get back to the name that
> > their users will recognize.
> 
> I was under the impression that downstreams could call the packages
> firefox as they had been blessed with official Debian penguin pee as
> long as they didn't then change them and it was only when they were
> modified that they potentially had to go to the Mozilla Foundation for a
> license.

That is correct, but (correct me if I'm wrong Gerv), but "change"
would include such things as recompiling it. 
 
> Did I get the wrong end of the stick?


-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Raphael Hertzog ([EMAIL PROTECTED]) wrote:
> Le jeudi 16 juin 2005 à 01:03 -0400, Eric Dorland a écrit :
> > > The Mozilla Foundation have made many shows of good faith via Gervase in
> > > this long running debate which he has continued to follow despite the
> > > criticisms levelled at him/the Mozilla Foundation.  Obviously if they
> > > turn around in the future and say "oh we hate your blah patch you can't
> > > use the name" then we can /then/ make it a big issue and change the name
> > > to iceweasel and be happy.  I honestly think this is unlikely though and
> > > to do so now would be not only be premature but be harmful to users and
> > > your/the project's relationship with Mozilla.
> > 
> > Well actually to some degree they've already done this. Recently the
> > CAcert  (www.cacert.org) project's root CA made it into our
> > ca-certificates package. However I can't have Firefox use that as a
> > root CA by default and still use the trademark:
> > 
> > http://article.gmane.org/gmane.comp.security.cacert/2752
> > 
> > This seems like a pretty unacceptable to me.
> 
> Given the trademark license, you can just add the CA-Cert and wait until
> MoFo complains to you... if they decide to complain !

Ummm, did you read the thread? It was pretty clear they would not find
it acceptable.

> Another approach (which would be more respectful to MoFo) would be to
> ask them to add the CA certificate into upstream's list of trusted CA so
> that the whole issue becomes a non-issue for us. We're all reasonable
> people, if we add that CA cert it's because we trust them. Given our
> track of security consciousness I see no reason why MoFo wouldn't trust
> what we trust (that's even the reason why they made an exceptin).

Will the add the SPI root CA to their root CA list? It's pretty Debian
specific, so I doubt it. 

> Third approach is to ask again for an exception concerning this change.
> 
> Choose whatever you prefer. In any case it doesn't change anything to
> the status of the software ... Firefox with its original name is free
> software and should be included as-is within Debian.
> 
> Furthermore I'm sure that you can avoid that problem by using a debconf
> question: "Do you want to add the CA certs contained in CA-certificates
> in the list of CA trusted by Firefox ?"
> 
> We don't change the list of CA certs but we're letting the user change
> it on his own machine. And I suppose that this has always been
> possible... (it was just more difficult for the user)
> 
> Cheers,

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Greylisting for @debian.org email, please

[Kalle Kivimaa]

Stig Sandbeck Mathisen <[EMAIL PROTECTED]> writes:
> I've got experience with use of greylisting for a mail platform with
> over 1M accounts.  Enabling greylisting for this platform reduced
> delivered spam with 80-90%. This is simply because most of the
> infected machines does not attempt a second delivery of a mail
> connection terminated with a 4xx (temporary) error message.

How many complaints for messages not delivered did you get?

I do _not_ want to have my debian.org mail forwarding go through a
greylisting "service". I've had to deal with one too many user
complaints due to greylisting. If it is a configurable service, then
fine, other people may have different experiences, but if greylisting
becomes a mandatory feature, I guess I have to start using
non-greylisted (ie. non-Debian) addresses in my Debian correspondence.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Simon Huggins ([EMAIL PROTECTED]) wrote:
> On Thu, Jun 16, 2005 at 01:03:52AM -0400, Eric Dorland wrote:
> > * Simon Huggins ([EMAIL PROTECTED]) wrote:
> > > On Wed, Jun 15, 2005 at 12:07:16PM -0400, Eric Dorland wrote:
> > > > Indeed the most pragmatic thing to do is to keep the name. But you
> > > > don't feel that accepting a deal with the Mozilla foundation is
> > > > against DFSG #8? Why not? 
> > > You have the right to modify the code whether or not it is in Debian.
> > > The license to the code is not specific to Debian so I don't believe
> > > that this contradicts the spirit of DFSG #8.  The rights are the same
> > > for you as they are for users i.e. they have the right to go to Mozilla
> > > and prove they produce good enough software to use Mozilla's trademark
> > > and call it firefox just as you have.  The license isn't specific to
> > > Debian therefore this satisfies that clause.
> > The code license is not in question. The trademark license/policy is. 
> 
> Right, my point is that the important thing for downstream of Debian is
> that the code is free not what the name is or if it has to be changed.
> If we can keep the name that's good for our users though so we
> should.

But I don't think it's good for our users for Debian to have rights
that the user don't have.
 
> > > The Mozilla Foundation have made many shows of good faith via
> > > Gervase in this long running debate which he has continued to follow
> > > despite the criticisms levelled at him/the Mozilla Foundation.
> > > Obviously if they turn around in the future and say "oh we hate your
> > > blah patch you can't use the name" then we can /then/ make it a big
> > > issue and change the name to iceweasel and be happy.  I honestly
> > > think this is unlikely though and to do so now would be not only be
> > > premature but be harmful to users and your/the project's
> > > relationship with Mozilla.
> > Well actually to some degree they've already done this. Recently the
> > CAcert  (www.cacert.org) project's root CA made it into our
> > ca-certificates package. However I can't have Firefox use that as a
> > root CA by default and still use the trademark:
> > http://article.gmane.org/gmane.comp.security.cacert/2752
> 
> > This seems like a pretty unacceptable to me.
> 
> Hmm.  That almost sets a precedent for stopping any changes they don't
> like via the blunt tool of the trademark license.

It is worrying.
 
> Do they have the same problems with the SPI root certs?  What are their
> reasons for this?  Do they have the same concerns that you raise in
> #309564?

I asked the exact same question about the SPI root certs, and if read
the whole thread you'll see he has the same problems. They're worried
about compromised root certs, which is a valid concern. But that
doesn't make their decisions right and ours wrong.

They do have concerns about the trustability of CAcert certs. I'm
mostly convinced they're no worse than other CA's. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Mozilla Foundation Trademarks

[John Hasler]

Alexander Sack writes:
> In general the part of the MoFo brand we are talking about is the product
> name (e.g. firefox, thunderbird, sunbird). From what I can recall now, it
> is used in the help menu, the about box, the package-name and the window
> title bar.

I'm not convinced that any of these constitute trademark infringement.
-- 
John Hasler


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

Miocrsoft Offcie Sytsem Proffsesioanl 2003.

[Harris]

A House Divided Against Itself Cannot Stand Run out of steam
Floggings will continue until morale improves. Why are a "wise man" and a "wise 
guy" opposites?
Crackerjack Exceptions prove the rule ... and wreck the budget.

Download there http://eloadsfast.com Don't be so open-minded your brains will 
fall out. Off The Cuff
Sabotage Blue Moon
If all the world is a stage, where is the audience sitting? Famous remarks are 
very seldom quoted correctly.
Ball and Chain Misquotations are the only quotations that are never misquoted.








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

Re: Greylisting for @debian.org email, please

[Stig Sandbeck Mathisen]

Kalle Kivimaa <[EMAIL PROTECTED]> writes:

> How many complaints for messages not delivered did you get?

We whitelisted about every client we received mail from the past year,
so the number of complaints was pretty low. If you also follow the
logs closely for a while, you'll find a few sites you'll have to
whitelist, particularly mailing list hosts.

Greylisting without massive whitelisting _will_ give you complaints.

> I do _not_ want to have my debian.org mail forwarding go through a
> greylisting "service". I've had to deal with one too many user
> complaints due to greylisting. If it is a configurable service, then
> fine, other people may have different experiences, but if
> greylisting becomes a mandatory feature, I guess I have to start
> using non-greylisted (ie. non-Debian) addresses in my Debian
> correspondence.

Sounds like you've been a victim of a poorly implemented greylisting
service.  However, your idea of having a user-configurable greylisting
would be a definite bonus.

-- 
Stig Sandbeck Mathisen


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

Verbraucherinformation - Consumer information -

[Newsletter]

Verbraucherinformation  - Consumer information  -

Newsletter  -   06/2005
---

- English version on page 2 -

Sehr geehrte Damen und Herren,

"100% der Befragten machen sich Sorgen oder Gedanken über eine gesunde 
Ernährung und eine Vergiftung des Körpers durch belastete Lebensmittel."
Dies ergab eine unveröffentliche Umfrage über Ernährungsverhalten. Unsere 
Stiftung hatte Gelegenheit, diese Umfrage vertraulich einsehen zu können. Und 
fast ebensoviele wussten nicht, wie man dies ändern könne oder hatten keine 
Lösung dafür.
Aber wir recherchieren, findet oder erarbeiten Lösungsvorschläge, die unseren 
Lesern Vorteile und mehr Lebensqualität bringen sollen.
Hier einige Punkte unserer Aufgabenstellung:
- Ein Reinigungsprogramm für den Körper und ein Lebensmittel zu finden, welche 
möglichst vielen Ansprüchen gerecht werden können und eine Lösung für eine 
dauerhaft gesunde Ernährung böten. Wir wollten ein Reinigungsprogramm, dass 
erprobt, effizient und einfach anzuwenden ist.
- Wir wollten ein gesundes unbehandeltes nicht genmanipuliertes Nahrungsmittel.
- Dieses Nahrungsmittel sollte von unabhängigen Fachmedien oder 
Fachzeitschriften bereits überprüft und der wissenschaftliche Nachweis über 
eine langjährige Forschung für ein wirksames und gesundes Lebensmittel erbracht 
worden sein.
- Eine besondere Rolle sollte die Ausgewogenheit in der Zusammensetzung und die 
Verträglichkeit des Reinigungsprogrammes für alle Altersgruppen spielen.
- Weiter sollte das Lebensmittel möglichst über eine lange Zeit hinweg 
(historisch) seine Nützlichkeit und positive Wirkung für den Körper unter 
Beweis gestellt haben.
Wir beauftragten einen freien Journalisten, eine Ernährungsberaterin, einen 
Doktor rer.
nat./Heilpraktiker und einen Doktor med./Spezialist für Ganzheitliche Medizin 
und die machten sich an die
Arbeit: Immer mehr Produkte fielen durch das strenge Raster bis letztendlich 
nur noch wenige übrig blieben und die unseren Auflagen gerecht werden konnten. 
Dann bekamen wir von dieser Gruppe zwei Produkte empfohlen, welche alle unsere 
Kriterien mit sehr gut oder gut bestanden hatten:
Das CLEAN ME OUT Reinigungsprogramm und AKTIV BARLEY - ESSENTIAL FOOD
Sie erfahren alles über das Clean me out Programm
unter: http://www.naturepower.ch/clean-me-out.html
Sie erfahren alles über AKTIV BARLEY - ESSENTIAL FOOD
unter: http://www.naturepower.ch/4.html

---

Wenn Sie keine weiteren Newsletter erhalten wollen, können Sie sich unter 
http://www.research4health.com aus unserer Datenbank austragen.

---

page 2

Dear ladies and gentlemen,

"100% of the interviewees distress themself or concerned about a healthy 
nutrition and a toxication of body by incriminated foods."
It dues to an unpublished survey about nutritional attitude. Our foundation had 
the chance to see this survey confidentially.
And almost as many of them did not knew how to change this or did not had any 
solution for it. But our foundation investigates, decides or works out 
suggestions for solution, that brings advantages and more quality of life to 
our readers.
Here are some points of our task:
- to find a cleaning program for the body and some food, which could satisfy as 
many claims as possible and give a solution for permanent healthy nutrition.
- we wanted to have a cleaning-program, which is approved, efficient and simply 
in use.
- we wanted to have healthy, untreated and non gene manipulated food.
- this food should be generated already from independent practition media or 
professional journals, and the scientifically prove about a longtime research 
for an effective and healthy food should be also generated.
- a special part should be the balance between composition and compatibility of 
the cleaning-program for all age group. 
- further more the food should prove for a long time
(historically) its utility and positive effect for the body as much as possible.
We assigned a freelanced journalist, a nutritionist,a Dr.rer Nat/alternative 
practicioner and a Dr.med/specialist for integral medicine and they set to
work: More and more products were fallen through  the tighten cracks until 
finally only a few femains, which could satisfy our conditions.
Later this group approved two products to us, which passed all of our criteria 
well or very well:
The CLEAN ME OUT cleaning-program and the ACTIVE BARLEY-ESSENTIAL FOOD
You come to know everything about the CLEAN ME OUT program on: 
http://www.naturepower.ch/clean-me-out.html
You come to know everything about AKTIV
BARLEY-ESSENTIAL FOOD on:
http://www.naturepower.ch/4.html

---
Wenn Sie keine weiteren Newsletter erhalten wollen, können Sie sich unter 
http://www.research4health.com/ aus unserer Datenbank austragen.


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

Re: Debian concordance

[Daniel Stone]

On Thu, Jun 16, 2005 at 12:54:08PM -0500, Ian Murdock wrote:
> Daniel Stone wrote:
> > libc6 added interfaces between 2.3.2 and 2.3.5 and made several other
> > major changes, so all packages built with .5 depend on .5 or above,
> > in case you use one of the new interfaces.
> > 
> > A binary built with 2.3.2 can run with .5, but a binary built with .5
> > can't necessarily run with .2.
> 
> Then why not build your packages against 2.3.2? That would ensure
> maximum compatibility with Debian proper (which to most of the
> world is sarge, *not* sid, so don't answer that you're almost the
> same as sid).

Hoary (like sarge) is built against 2.3.2.

Breezy (like current sid) is built against 2.3.5.

> I don't begrudge your attempt to innovate, but I doubt your
> users consider a slightly newer libc innovation, particularly when
> it introduces problems like this.

Ironically, the problem in this case stems from sid innovating too fast
for Hoary, the latest stable Ubuntu release.  Ho hum.

> I strongly suspect they're
> more interested in your X.org and GNOME 2.10. Given
> that, a lot of this divergence seems pretty gratutious to me.

Yes, these are both very interesting to users.

Which 'divergence' do you mean when you reference that -- X.Org/GNOME
2.10, or glibc?

Cheers,
Daniel


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Cesar Martinez Izquierdo]

El Jueves 16 Junio 2005 18:11, Russ Allbery escribió:
[snip]
> That being said, we absolutely should not allow the trademark issue to
> give MoFo any more of a veto on package changes than any other upstream
> would have.  If we feel we need to make a change to improve the package
> for our users and MoFo disagrees with that change and says we can't use
> the trademark if we make it, we should make it, rebrand Firefox, and go on
> with our lives.  Debian as a project already tries to work with upstream
> whenever possible, and certainly we should continue to do this, but I'm
> *extremely* uncomfortable with the idea of this trademark license being
> used as a stick to prevent Debian from producing the distribution we want
> to produce.
>
> The most disturbing thing I've seen in this entire thread so far (and I'm
> trying not to overreact, since I don't know the whole story) is hearing
> that Mozilla might veto root CA additions using the trademark liense as a
> stick.  I think it's a horrible idea to rebrand Firefox out of worries of
> avoiding a Debian-specific deal, but if the branding ends up being used
> for things like supporting the evil Verisign monopoly against more
> reasonable ways of handling TLS certificates, it would be worth rebranding
> to me to avoid having to wait on those sorts of changes.  On the other
> hand, if that statement was just a security concern and a request that
> MoFo be given time to vet new CA additions before they're just added
> downstream, that's probably quite reasonable and the invocation of the
> trademark license stick may have just been a poor choice of wording on
> their part.

Hi!
While I've been actively supporting to don't rename Firefox during all the 
thread (because of the reason explained there), I definitely DO support to 
rename it if keeping the original name means that we loose the ability to 
make some kind of changes to the package, and specifically I support to 
rename it if Eric Dorland (as maintaner) doesn't feel free enough to modify 
the package when appropiate (as in that example of CA additions).
Until the moment, I thought all the time that MoFo was trusting Debian and 
therefore we were allowed to make any changes we considered appropiate.


Anyway, I'd like bring again the Debian example that I wrote and nobody 
replied. I was not joking. Consider:
"What happens if tomorrow I start redistributing a modifyed Debian version 
(only bugfixes; of course, I will decide what bugs are for me...) and I call 
it "Debian GNU/Linux Sarge 3.1"?
Will I have a trademark issue with SPI?"

Almost for sure, I'll have a problem with SPI and the Debian trademark.
If the criteria expressed by some in this thread is true, we ** should rename 
Debian ** because we are using a right that our users can't use (we can ship 
Debian with the name "Debian" because we are Debian, so it it is a special 
right that our users can't access). I think this is totally absurd and 
illustrates that trademarks have nothing to do with software freedom, and we 
should accept this kind of name limitations.

Regards,

 César

Re: relocation error(s) with various binaries

[Chris Gorman]

On Thu, 16 Jun 2005, Peter Samuelson wrote:

>
> [Chris Gorman]
> > + exec /usr/lib/mozilla-firefox/firefox-bin -a firefox
> > /usr/lib/mozilla-firefox/firefox-bin: relocation error:
> > /usr/lib/libXrender.so.1: undefined symbol: _Xglobal_lock
>
> Try reinstalling libx11-6.
Done.  It was one of the ones I reinstalled already, but I tried it again.
Unfortunatly the errors persist.
> Verify that it has the symbol in question:
>
>   nm --dynamic /usr/X11R6/lib/libX11.so.6 | grep _Xglobal_lock
Reveals..

000c6910 B _Xglobal_lock
>
> should reveal it as a "B" symbol (uninitialised data).
>
I've also tried reinstalling all of mozilla in the event that it had
become corrupt.  This also didn't resolve the problems.  :(  Any other
suggestions?  (I'm thinking about removing all of X and starting over with
it.)


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

Re: Debian concordance

[Michael K. Edwards]

On 6/16/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 12:54:08PM -0500, Ian Murdock wrote:
> > Daniel Stone wrote:
> > > libc6 added interfaces between 2.3.2 and 2.3.5 and made several other
> > > major changes, so all packages built with .5 depend on .5 or above,
> > > in case you use one of the new interfaces.
> > >
> > > A binary built with 2.3.2 can run with .5, but a binary built with .5
> > > can't necessarily run with .2.
> >
> > Then why not build your packages against 2.3.2? That would ensure
> > maximum compatibility with Debian proper (which to most of the
> > world is sarge, *not* sid, so don't answer that you're almost the
> > same as sid).
> 
> Hoary (like sarge) is built against 2.3.2.
> 
> Breezy (like current sid) is built against 2.3.5.

Unfortunately, it's worse than this.  A last-minute ABI change in
sarge (backporting some glibc 2.3.4 symbols to 2.3.2) has the effect
that any package whose autogenerated shlibdeps includes libc6, when
built on sarge, isn't installable on hoary.  Any package that doesn't
use the affected APIs can be hacked to work around this (by lowering
the versioned dependency on libc6), but it's quite an inconvenience.

In general, it's not trivial to set up a build environment that
reliably produces binary packages that are installable on both sarge
and hoary.  (I happen to have such an environment at work, based on a
part-careful-part-lucky snapshot of sid, but it's not something I
would care to support for more than a few packages.)  It would be
awfully nice if Debian and Ubuntu could coordinate on a 90% solution;
I don't necessarily expect to be able easily to build python packages
that will run on both (given Ubuntu's early move to 2.4) but how about
basic C, C++, and perl ABI compatibility?

(Yes, I know this is what the LSB is for, but Debian and Ubuntu are so
closely related that the 90% solution probably isn't that hard.  An
apt repository containing a few packages with
lowest-common-denominator ABIs, plus a debootstrap script for use with
pbuilder, would probably do it.)

Cheers,
- Michael

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jun 15, 2005 at 12:50:44PM -0400, Eric Dorland wrote:
> > * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > > On Tue, Jun 14, 2005 at 11:20:57AM -0300, Humberto Massa Guimarães wrote:
> > > > > Does the opposite make it worse? I think so.
> 
> > > > IMHO it makes no difference at all. The "normal", "regular",
> > > > "I-dont-read-debian-mailing-lists" folk install the "Gnome Desktop"
> > > > or the "KDE Desktop" tasks, see the "Web Browser" icon, double-click
> > > > it and voila. As long as it works (and as long as they can install
> > > > the Macromedia plugins), they don't care. The rest of the world
> > > > knows Debian renamed Firefox as Iceweasel to escape Mozilla
> > > > Foundation's arcane trademark license.
> 
> > > I don't think it's arcane. It's a perfectly reasonable thing to do,
> > > which Debian itself has done in the past (TrustedDebian -> Adamantix)
> 
> > > You're free to make /any/ modifications to firefox, as long as you
> > > either rename it to something else or get permission to call it firefox.
> > > Doesn't sound non-free to me.
> 
> > Please explain to me why it's alright to get special permission to use
> > a trademark but not ok for a software license? 
> 
> DFSG#8 has regularly been interpreted as meaning that if a software license
> isn't free, it can't be made free just by giving Debian additional rights.
> This keeps us honest, by eliminating any incentive proprietary software
> authors might have to create a market for themselves by making a deal with
> Debian.

Right, I don't see how the issue is really that separate when it comes
to trademarks. They're making a deal with us so that we will promote
their brand. How is that honest?
 
> But if the software is already free, then giving additional permissions to
> one group over another doesn't make it non-free.  Is firefox Free Software
> prior to giving Debian permission to use the trademark?  Yes, it is: even
> considering the trademark license, DFSG #4 says that authors may require
> people modifying the software to use a distinguishing name or version
> number.  (For "name" here I think it's reasonable to read "marks" as well.)
> Therefore, without the trademark exemption, firefox is already free; so
> granting Debian special permission to *not* change the name/marks/version
> doesn't suddenly make it non-free.

I'm not trying to say it's non-free. It is free. What I'm trying to
determine is if we should use the marks within Debian. Let me try
another example. If, say, the Apache Foundation came to us and said,
"Sure the code is free, but that's our trademark you're using. It will
cost you $5000 a year to use that trademark in Debian". Now we could
easily afford this as a project, would we do it? I don't think we
would do it, even though we could because a strict interpretation of
the DFSG says trademarks don't matter.

The point I'm trying to make is that clearly not all trademark terms
are reasonable. Their certainly are situations where we would find
using the trademark unacceptable, even if the DFSG "apparently" says
we can. Is this Mozilla situation acceptable? I think it is, I think
the spirit of DFSG #8 is that Debian should not have rights that the
user doesn't have in terms of the software we distribute. Yes, these
are not copyrights rights, but they are still rights.
 
> There's no freeness issue here, just one of convenience to people who want
> to modify the Debian firefox packages and redistribute them.  I imagine
> that's a rather small field, all things considered; is it really better to
> leave the vast majority of users confused about the absence of firefox in
> the distro, just to maintain some sort of branding solidarity with those few
> Debian derivatives that aren't even *using* our pristine .debs?
 


-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

bye bye big thighs

[Alden]

Body Wrap at Home to lose 6-20 inches in one hour.

With Bodywrap we guarantee:
 you'll lose 6-8 Inches in one hour 
 100% Satisfaction or your money back

Bodywrap is soothing formula that contours, 
cleanses and rejuvenates your body while
reducing inches.

http://deductible.yourfitnessonline.com










mimicking xwy valentine vl cyprian iu transferor zwy resent has indemnity rv 
mainstream tq apperception ga steed fu quail yl coagulable id tritium vs 
http://deductible.yourfitnessonline.com/r


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

Re: Upcoming removal of orphaned packages

[Martin Michlmayr]

* Sven Mueller <[EMAIL PROTECTED]> [2005-06-16 20:53]:
> > findimagedupes -- Finds visually similar or duplicate images [#218699]
> 
> Though I probably can't adopt it (due to lack of time), it would be a
> pity to loose this since there is no comparable commandline tool
> available and it works quite well.
> If all else fails, I might re-think adopting it.

Andreas Tille expressed interest in this package and I find the
description quite interesting too.  Does anyone know if there's a
suitable replacement which is still maintained?
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Adam McKenna]

On Thu, Jun 16, 2005 at 01:00:17PM -0400, Eric Dorland wrote:
> 
> But I don't think it's good for our users for Debian to have rights
> that the user don't have.

We are only concerned with the rights that apply to the software, not the
name.  The users have all of the same rights to the software that Debian has.
How many times does this need to be said?

--Adam


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

Re: Planning a libglade to libglade2 transition

[Martin Michlmayr]

* Steve Langasek <[EMAIL PROTECTED]> [2005-06-14 13:10]:
> Many of these are GNOME1.x-specific libraries, in turn used by GNOME1.x
> applications that as yet have no GNOME2 equivalent.  (At the top of my
> personal list there is gnucash...)

Okay, given that GTK1 won't disappear immediately (and maybe should
also stay in etch, see Murray Cumming's comment in #279392 about 3rd
parties), I'm wondering whether the GNOME/GTK team is willing to adopt
libglade and do some low-level maintenance.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Greylisting for @debian.org email, please

[Rich Walker]

Stig Sandbeck Mathisen <[EMAIL PROTECTED]> writes:
[snip]

> Sounds like you've been a victim of a poorly implemented greylisting
> service.  

Probably greylistd.

It does exactly what it says on the can - unfortunately, the combination
of the fact that the list of "known [EMAIL PROTECTED]" mail servers is 
incomplete,
and the delay introduced on first-time-mails from legitimate sources,
results in screaming from users really quick :-<


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


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

Re: Debian concordance

[Ian Murdock]

Daniel Stone wrote:
> libc6 added interfaces between 2.3.2 and 2.3.5 and made several other
> major changes, so all packages built with .5 depend on .5 or above,
> in case you use one of the new interfaces.
> 
> A binary built with 2.3.2 can run with .5, but a binary built with .5
> can't necessarily run with .2.

Then why not build your packages against 2.3.2? That would ensure
maximum compatibility with Debian proper (which to most of the
world is sarge, *not* sid, so don't answer that you're almost the
same as sid).

I don't begrudge your attempt to innovate, but I doubt your
users consider a slightly newer libc innovation, particularly when
it introduces problems like this. I strongly suspect they're
more interested in your X.org and GNOME 2.10. Given
that, a lot of this divergence seems pretty gratutious to me.

P.S. - This whole thread is *exactly* the kind of thing I'm
talking about when I talk about Ubuntu divergence from Debian
and the kinds of headaches that are naturally going to arise
from that. For debian-devel's benefit, the thread starts here:

http://lists.ubuntu.com/archives/ubuntu-devel/2005-June/008125.html

P.S. - Don't tell me "build from source" is the answer--with a package
system as advanced as Debian's, this shouldn't be necessary. And,
as above, to most of the world, this is a non-started for many reasons.
-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"A nerd is someone who uses a telephone to talk to other people about
telephones." --Douglas Adams


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

Ada in Debian, past, present and future. Request for Advocate.

[Ludovic Brenta]

In July 2003, I adopted the package gnat and several other Ada
packages.  In November 2003, Matthias Klose sponsored my first few
packages into Debian unstable.  After I adopted all the orphaned
packages I could, I created several new packages from sratch.  Now,
all my packages have been released as part of sarge.

I am talking about 18 source packages, 43 binary packages and roughly
2.8 million lines of code according to David A. Wheeler's SLOCCount.
All of these packages are related to Ada.  For the most part, 3
architectures are supported: i386, powerpc and sparc.  As of last
week, I even have a Sun Ultra 2 at home running Debian :)
 
I am the principal maintainer of all versions of GNAT: gnat, gnat-3.3,
gnat-3.4 and gnat-4.0.  The latter three are part of the corresponding
GCC source packages, and I cooperate with the Debian GCC maintainers
on these.  For this reason, Matthias has been kind enough to keep me
in the loop of the discussions on the future default compiler for
etch.  Thank you, Matthias.

In addition to the packages, I have also written the Debian Policy for
Ada[1].  This Policy ensures that all Ada packages use the same ABI,
and work well together; this is particularly important for libraries.

[1] http://www.ada-france.org/debian/debian-ada-policy.html

I host a Debian repository on Ada-France[2]; I use it as a staging
area for Matthias to get my packages and upload them to sid.

[2] deb http://www.ada-france.org/debian ada main

Matthias has been a very good sponsor for me for the past 19 months.
However, his expanded duties now leave him little time to upload my
packages.  He asked me to apply for Debian Developer, and explain my
future plans.

So, my plans are:

1. To continue maintaining my packages.  Bugs, new releases, etc.
   This includes in particular the GNAT which is part of GCC.

2. To upload the Debian Policy for Ada into unstable; after all, the
   Python Policy is already in sarge.

3. Not to make any new packages.  I don't want to spread too thin, and
   I want to do a good job of maintaining my packages.

4. To update the Debian Policy for Ada when appropriate.  As part of
   this, I would like etch to move from GNAT 3.15p to a more recent
   version, but this requires ASIS support which is not yet available.
   This may make it possible to support more architectures.

5. To sponsor and mentor people who would like to help maintain
   Ada-related packages.  In time, such people might prove worthy
   enough that I might advocate them :)

My GPG key has been signed by a Debian Developer:

$ gpg --list-sigs brenta
pub   1024D/9DFFAAD4 2003-07-10
uid  Ludovic Brenta <[EMAIL PROTECTED]>
sig 39DFFAAD4 2003-07-10  Ludovic Brenta <[EMAIL PROTECTED]>
sig 36783ED5E 2003-08-25  Frederic Peters <[EMAIL PROTECTED]>
sub   1024g/751B6557 2003-07-10
sig  9DFFAAD4 2003-07-10  Ludovic Brenta <[EMAIL PROTECTED]>

I am now looking for an advocate; if you are interested, please visit:

http://nm.debian.org/nmadvocate.php?email=ludovic.brenta%40insalien.org

PS. I don't follow debian-devel; please CC me directly if you reply.

-- 
Ludovic Brenta.


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

Re: Upcoming removal of orphaned packages

[Laszlo Boszormenyi]

On Thu, 2005-06-16 at 20:00 +0100, Martin Michlmayr wrote:
> * Sven Mueller <[EMAIL PROTECTED]> [2005-06-16 20:53]:
> > Though I probably can't adopt it (due to lack of time), it would be a
> > pity to loose this since there is no comparable commandline tool
> > available and it works quite well.
> > If all else fails, I might re-think adopting it.
> 
> Andreas Tille expressed interest in this package and I find the
> description quite interesting too.  Does anyone know if there's a
> suitable replacement which is still maintained?
 Quoting[1]:
"[2002/02/06 23:55] PixiePlus[2] now supports similar image finding
using an algorithm based on mine, and for those unable to run a current
version of KDE, gqview[3] will also find your similar images, albeit
using a different algorithm whose results I haven't compared with my
own. Both are FAR faster than findimagedupes and, I would say, both make
it obsolete. If someone else would like to continue its development for
web or other non-GUI purposes (this means you, Debian maintainers ;) ),
by all means feel free, but consider my itch scratched."
Thus I may think it is enough (no more upstream activity, abadonned more
than three years ago, has other and problably better alternatives) to
remove this package, but let others do the choice.

Regards,
Laszlo/GCS
[1] http://www.kudla.org/raindog/perl/
[2] http://www.mosfet.org/pixie/
[3] http://gqview.sourceforge.net/


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

Re: Upcoming removal of orphaned packages

[Andreas Tille]

On Thu, 16 Jun 2005, Laszlo Boszormenyi wrote:


"[2002/02/06 23:55] PixiePlus[2] now supports similar image finding
using an algorithm based on mine, and for those unable to run a current
version of KDE, gqview[3] will also find your similar images, albeit
using a different algorithm whose results I haven't compared with my
own. Both are FAR faster than findimagedupes

Perhaps this might be true for the initial Perl implementation, but:

"[2001/03/03 10:05] Markus Schoder has contributed finddupes.cpp, GPL'ed source code 
for a C++ based version of my horribly slow compare routine. In his testing on a 
directory of 35,000 images, it was about 300 times faster than findimagedupes' perl 
implementation."


and, I would say, both make it obsolete.

If both would have a command line interface.  I do not know both but
the page you quoted mentioned that findimagedupes is the only command line
tool.


If someone else would like to continue its development for
web or other non-GUI purposes (this means you, Debian maintainers ;) ),
by all means feel free, but consider my itch scratched."
Thus I may think it is enough (no more upstream activity, abadonned more
than three years ago, has other and problably better alternatives) to
remove this package, but let others do the choice.

I would really love a command line alternative.  If you tell me any
I will be quiet immediately.  But I would love to have a test first.
Please give me two weeks.

Kind regards

Andreas.

--
http://fam-tille.de


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

systemware, teachware and artware from sixty dollrs

[Stimuli D. Bobsled]

www.h63e2gh53ahow0h.potboydomhf.com

épuiserons devant pour autarcie, sans. essaiment mitoyenne documentât au-dessus 
lamentée de sur repeupleront vers achevas.
sans vérifias sur mimaient du encrer boiterions devant mais républicaines 
démocratiserais au-dessus bardassent.
devant attrapassent pour pour empoisonnèrent mais rattrapèrent insole relaxait 
maisscandaleusement dupent tisse.
trahisse ébauchés les connaissements
égayâmes ce sans embaumasse, au-dessus. tertiaire réempruntait oedémateux 
devant chef cela au-dessus paraffinions au-dessus sondages.
du cuivreux sous cambriolas sous édicterons panifieras cela du inondassions 
réembauche pour gros-porteur.
de frapperaient pour cela ennoblissent les retraduisit trahisons réglementerez 
sousmécano balafreras réassortissons.
ancrasses officialisations cela invocations
instruction sans du cessante, devant. embarrassai gouttassent tonnent les 
débalourder cela sous situerais ce poignardez.
devant paniquerais sans rasât cela aiguillonnâmes poubelle vers pour dévissage 
électrisa mais égratignai.
sur retuberiez le au-dessus affirmeriez pour perméable désolation assimilerons 
sansdégagerais saluées enchaînions.
racinez fragmentiez vers prospectais
communiasses notifiées, enfouir
devant engainions.



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

Re: Upcoming removal of orphaned packages

[Sven Mueller]

Martin Michlmayr wrote on 16/06/2005 19:18:
> findimagedupes -- Finds visually similar or duplicate images [#218699]
>   * Orphaned 590 days ago
>   * Package orphaned > 360 days ago.

Though I probably can't adopt it (due to lack of time), it would be a
pity to loose this since there is no comparable commandline tool
available and it works quite well.
If all else fails, I might re-think adopting it.

> rio500 -- command-line utilities for the Diamond Rio500 digital audio player 
> [#225259]
>   * Orphaned 534 days ago
>   * Package orphaned > 360 days ago.

don't know anything about the state of this package, but I know that the
rio500 is still used by a lot of people.

cu,
sven


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

Re: Upcoming removal of orphaned packages

[Martin Michlmayr]

* Simon Richter <[EMAIL PROTECTED]> [2005-06-16 22:53]:
> > if-transition -- A Change in the Weather, an interactive short story 
> > [#260720]
> >   * Orphaned 327 days ago
> 
> I cannot find this one on powerpc.

It's in non-free.

> > moria -- A roguelike game with an infinite dungeon [#274472]
> >   * Orphaned 255 days ago
> I think that would be a shame. As I don't play it myself, I might not be
> the best choice for a maintainer, but I'd offer sponsoring. :-)

It's non-free.  There were discussions about moving to GPL but this
hasn't happened yet.  It can always be re-uploaded once it's GPL.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Upcoming removal of orphaned packages

[Laszlo Boszormenyi]

On Thu, 2005-06-16 at 22:13 +0200, Andreas Tille wrote:
> Perhaps this might be true for the initial Perl implementation, but:
> 
> "[2001/03/03 10:05] Markus Schoder has contributed finddupes.cpp, GPL'ed 
> source code for a C++ based version of my horribly slow compare routine. In 
> his testing on a directory of 35,000 images, it was about 300 times faster 
> than findimagedupes' perl implementation."
 Yup, but that's even more old, more than four years old. Will download
it and check if its still compilable even.

> > and, I would say, both make it obsolete.
> If both would have a command line interface.
 I do not think they have.

>   I do not know both but
> the page you quoted mentioned that findimagedupes is the only command line
> tool.
 Yes, and this is sad. What I need is a command line tool as well. I can
not have any GUI where I would like to use it.

> I would really love a command line alternative.  If you tell me any
> I will be quiet immediately.
 I do not know any. But if any of you find an alternative, then please
tell me as well.

>   But I would love to have a test first.
> Please give me two weeks.
 Thanks, the time is on your side as I also would like to have a command
line based tool.

Regards,
Laszlo/GCS
-- 
BorsodChem Joint-Stock Company   www.debian.org Linux Support Center
Software engineerDebian Developer   Developer
+36-48-511211/25-90 +36-20-4441745


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

Re: Upcoming removal of orphaned packages

[Paul Gear]

Martin Michlmayr wrote:
> ...
> trustees -- Advanced permission management system for Linux [#251189]
>   orphaned 379 days ago, according to maintainer upstream dead, removal
>   already suggested one year ago, very small install base

One more issue in favour of this is that Novell have released the NSS
filesystem for Linux with SLES9, so an alternative "inspired by" NSS
isn't really necessary now...

-- 
Paul



signature.asc
Description: OpenPGP digital signature

Re: Upcoming removal of orphaned packages

[Rich Walker]

Sven Mueller <[EMAIL PROTECTED]> writes:

> Martin Michlmayr wrote on 16/06/2005 19:18:
>> findimagedupes -- Finds visually similar or duplicate images [#218699]
>>   * Orphaned 590 days ago
>>   * Package orphaned > 360 days ago.
>
> Though I probably can't adopt it (due to lack of time), it would be a
> pity to loose this since there is no comparable commandline tool

fdupes?

Doesn't do partial matching, but is otherwise excellent.

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


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

Re: Upcoming removal of orphaned packages

[Rich Walker]

Martin Michlmayr <[EMAIL PROTECTED]> writes:

> * Simon Richter <[EMAIL PROTECTED]> [2005-06-16 22:53]:
>> > if-transition -- A Change in the Weather, an interactive short story 
>> > [#260720]
>> >   * Orphaned 327 days ago
>> 
>> I cannot find this one on powerpc.
>
> It's in non-free.
>
>> > moria -- A roguelike game with an infinite dungeon [#274472]
>> >   * Orphaned 255 days ago
>> I think that would be a shame. As I don't play it myself, I might not be
>> the best choice for a maintainer, but I'd offer sponsoring. :-)
>
> It's non-free.  There were discussions about moving to GPL but this
> hasn't happened yet.  It can always be re-uploaded once it's GPL.

Perhaps you haven't seen:


Most of the creditted authors have stated that they are happy for it to
be converted to GPL.

And moria hasn't had a bug in a long time.


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


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

Re: [the perfectly harmless] heimdal/mit-krb mix in ssh-krb5 via libnss-ldap

[Jeremie Koenig]

On Thu, Jun 16, 2005 at 03:44:41PM +0200, Jeremie Koenig wrote:
> I got no luck lately and managed to make ssh-krb5 fail due to library
> linkage weirdness. It took me ages to figure out what was going on!
> (I learnt alot on the way, however.)
> 
> To reproduce the breakage:
>  1. install libsasl2-modules-gssapi-heimdal, libnss-ldap and ssh-krb5
> (something else linked against libkrb53 may "work" as well);
>  2. configure /etc/nsswitch.conf to use ldap for some lookups;
>  3. configure /etc/ldap/ldap.conf or ~/.ldaprc to use SASL
> authentication.

Actually this is all crap, the libraries are fine. Sorry everybody for
the noise, especially Russ for the extra wasted brain and finger cycles. 

Here's what happens if you wonder: the real problem is that libkrb53
recognizes comments only when # is the first character of a line, while
heimdal libraries allows some leading whitespace.

The heimdal plugin is much appropriately loaded via dlopen without the
RTLD_GLOBAL flag and its namespace is disjoint from the main one. The
name service switch probably does something similar with libnss-ldap, so
we may even have two levels of isolation. Besides, the libraries are
used for two completely different things.

I'm still not completely understanding how I have been able to come up
with this library clash "evidence" (maybe I just needed a culprit.)
The sensible thing I'm going to do now is reporting a wishlist bug
against libkrb53 to tolerate whitespace and a minor one against ssh-krb5
for the crappy debug lines.

-- 
Jeremie Koenig <[EMAIL PROTECTED]>


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Wouter Verhelst]

On Wed, Jun 15, 2005 at 07:23:39PM -0400, Eric Dorland wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > On Wed, Jun 15, 2005 at 11:48:55AM -0400, Eric Dorland wrote:
> > > * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > > > Where possible, sure. But "principles" doesn't mean "the rules should be
> > > > exactly the same".
> > > 
> > > Please stop putting words in my mouth. I never said that the rules
> > > should necessarily be the same. But I am of the opinion that the
> > > spirit of DFSG #8 should apply.
> > 
> > To trademarks? Why? I don't see why that would be necessary, or even a
> > good idea; but I'm sure I can be convinced given good arguments.
> 
> It's a question of fairness, which I think is embodied by DFSG
> #8. We're getting this offer from MoFo because, I think, we are
> Debian. We're big and we're cool, there's no denying it :) But other
> entities, equally deserving of the trademark usage from a quality
> standpoint won't get it because MoFo doesn't care about them.

Is that a given, or is that a theory?

If it's a given, I agree with you.

If it's a theory, you should find out whether it's true. If it's not,
there's no problem.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

setting umask globally

[martin f krafft]

If one is faced with the task to set the umask globally for all
users and shells, this turns out to be a job of redundancy: every
shell uses its own file in /etc, and you end up making changes to
5 files or more (depending on the number of installed shells).
What's worse: change the umask and you'll possibly forget one shell
or the other, which may cause delays in your user's work, or even
break things (yeah, you should not rely on umask; yeah, don't tell
me...)

I thus propose to solve this dilemma across all shells in Debian
with /etc/umask.conf (or /etc/default/umask), which can be the most
simple of simple configuration files, should probably ship in
base-files, and look like this:

  UMASK_ROOT=0077
  UMASK_USER=0022

In addition, there is /usr/share/base-files/umask.sh:

  UMASK_ROOT=0077
  UMASK_USER=0022

  test -r /etc/umask.conf && . /etc/umask.conf

  if [ $(id -u) -eq 0 ]; then
umask $UMASK_ROOT
  else
umask $UMASK_USER
  fi

The /etc/profile-equivalent of every shell Debian ships then sources
/usr/share/base-files/umask.sh and the user can change the umask in
one single location.

So the plan is:

  1. gather comments.
  2. file a bug against base-files to have the files included.
  3. once base-files hits unstable, mass-file bugs against all
 compatible shells and ask them to use it.
  4. rejoice.
  
So, let's start at (1)...

-- 
 .''`. 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!
 
"with sufficient thrust, pigs fly just fine. however, this is not
 necessarily a good idea. it is hard to be sure where they are going
 to land, and it could be dangerous sitting under them as they fly
 overhead."
   -- rfc 1925


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Don Armstrong]

On Thu, 16 Jun 2005, Eric Dorland wrote:
> * Don Armstrong ([EMAIL PROTECTED]) wrote:
> > On Thu, 16 Jun 2005, Eric Dorland wrote:
> > > * Don Armstrong ([EMAIL PROTECTED]) wrote:
> > > > All of MoFo trademarks that were not being used in a manner
> > > > consistent with trademark law[2] would have to be expunged from
> > > > the work,
> > > 
> > > What trademarks are you referring to? Already the Debian packages
> > > don't use any of the trademarked images and logos? 
> > 
> > If we don't use any trademarked images, logos, or phrases, what
> > exactly are we talking about here?
> 
> The term "Firefox" is what trademarked, and the only trademark still
> in the Debian package AFAIK. That's what we're talking about. 

Then that would be a "MoFo trademark" that is possibly "used in a
manner [not] consistent with trademark law." If that was the case, it
would be a mark that "would have to be expunged from the work."

My main point here seems to have been lost: I am merely pointing out
that the changes required are far more extensive than the renaming of
a binary|script|package, but appear to involve substantial branding
changes throughout the package; this seems to be a bit more extensive
than the minor restriction that DFSG §4 allows.


Don Armstrong

-- 
"...Yet terrible as UNIX addiction is, there are worse fates. If UNIX
is the heroin of operating systems, then VMS is barbiturate addiction, the
Mac is MDMA, and MS-DOS is sniffing glue. (Windows is filling your sinuses
with lucite and letting it set.) You owe the Oracle a twelve-step program."
 --The Usenet Oracle

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: Debian concordance

[Ian Murdock]

On 6/16/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> Hoary (like sarge) is built against 2.3.2.
> 
> Breezy (like current sid) is built against 2.3.5.

Why?

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"A nerd is someone who uses a telephone to talk to other people about
telephones." --Douglas Adams

Re: Debian concordance

[Ian Murdock]

On 6/16/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > I strongly suspect they're
> > more interested in your X.org and GNOME 2.10. Given
> > that, a lot of this divergence seems pretty gratutious to me.
> 
> Yes, these are both very interesting to users.
> 
> Which 'divergence' do you mean when you reference that -- X.Org/GNOME
> 2.10, or glibc?

glibc. Shipping X.org and GNOME 2.10 adds value, since sarge doesn't
ship them. Shipping glibc 2.6.5 vs. glibc 2.6.2 just adds
incompatibilities.

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"A nerd is someone who uses a telephone to talk to other people about
telephones." --Douglas Adams

Re: setting umask globally

[Adeodato Simó]

* martin f krafft [Fri, 17 Jun 2005 00:05:08 +0200]:

>   1. gather comments.

  apt-cache show libpam-umask

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The pure and simple truth is rarely pure and never simple.
-- Oscar Wilde


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

Re: Upcoming removal of orphaned packages

[Frank Lichtenheld]

On Thu, Jun 16, 2005 at 10:39:39PM +0100, Rich Walker wrote:
> And moria hasn't had a bug in a long time.

While many bugs are a reason to remove a package quickly, no bugs
aren't a reason to keep it forever. The Debian QA group maintains
packages that are orphaned to give other maintainers the chance
to adopt it without too much hassle, and as a service to those
that use them. But this has to be only a temporary solution.

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


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

Re: setting umask globally

[martin f krafft]

also sprach Adeodato Simó <[EMAIL PROTECTED]> [2005.06.17.0011 +0200]:
> >   1. gather comments.
> 
>   apt-cache show libpam-umask

Very nice. I almost feel silly now.

Is there any point in following through with the /etc/umask.conf
proposal? libpam-umask is optional after all, and unless people know
about it, they'll edit multiple files wrt umask, and we *could*
unify this with relative ease.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
/.ing an issue is like asking an infinite number of monkeys for advice
   -- in #debian-devel


signature.asc
Description: Digital signature

Re: setting umask globally

[Santiago Vila]

On Fri, 17 Jun 2005, martin f krafft wrote:

> If one is faced with the task to set the umask globally for all
> users and shells, this turns out to be a job of redundancy: every
> shell uses its own file in /etc, and you end up making changes to
> 5 files or more (depending on the number of installed shells).
> What's worse: change the umask and you'll possibly forget one shell
> or the other, which may cause delays in your user's work, or even
> break things (yeah, you should not rely on umask; yeah, don't tell
> me...)
>
> [ snipped gigantic hack ]
>
> So the plan is:
>
>   1. gather comments.
>   2. file a bug against base-files to have the files included.
>   3. once base-files hits unstable, mass-file bugs against all
>  compatible shells and ask them to use it.
>   4. rejoice.
>
> So, let's start at (1)...

This is Unix, and we are system integrators. Our job is to make things
simpler, not more complex. I wonder why people always consider
base-files as the package of choice to implement all sorts of ugly
global hacks.

There is already an umask setting in /etc/login.defs. If it makes people
happy, I will happily drop the umask setting from /etc/profile, so
that people do not have to decide between login.defs and profile
when trying to set an umask globally.

Then we could make policy (or just convince the shell maintainers) that
shells should not set umask in their default global initialization
scripts, so that they do not override the one in /etc/login.defs.


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

Re: Upcoming removal of orphaned packages

[Simon Richter]

Hi,

Martin Michlmayr schrieb:

> race -- 3D arcade overhead car game [#251706]
>   orphaned 376 days ago, about 3 years old, new upstream releases not
>   uploaded, medium install base, "only a game"

race eats up 640MB of memory, then dies on my system (ppc).

> arpd -- User-space ARP daemon [#191870]
>   * Orphaned 771 days ago
>   * Package orphaned > 360 days ago.

This matches a kernel option that is still present in current 2.6 but
has a description that says it's obsolete.

> if-transition -- A Change in the Weather, an interactive short story [#260720]
>   * Orphaned 327 days ago

I cannot find this one on powerpc.

> moria -- A roguelike game with an infinite dungeon [#274472]
>   * Orphaned 255 days ago

I think that would be a shame. As I don't play it myself, I might not be
the best choice for a maintainer, but I'd offer sponsoring. :-)

   Simon


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

Re: Upcoming removal of orphaned packages

[Russ Allbery]

Rich Walker <[EMAIL PROTECTED]> writes:

> Most of the creditted authors have stated that they are happy for it to
> be converted to GPL.

Most isn't enough; someone needs to decide that all of the code has now
been covered or replace the code that hasn't been covered.

> And moria hasn't had a bug in a long time.

Someone really needs to step up to the place and adopt it if we're going
to keep it.  I'm tempted personally too, but I'm not willing to adopt a
non-free package, and I think it probably really is still non-free (being
familiar with the similar issue with Angband).

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: [the perfectly harmless] heimdal/mit-krb mix in ssh-krb5 via libnss-ldap

[Russ Allbery]

Jeremie Koenig <[EMAIL PROTECTED]> writes:

> I'm still not completely understanding how I have been able to come up
> with this library clash "evidence" (maybe I just needed a culprit.)  The
> sensible thing I'm going to do now is reporting a wishlist bug against
> libkrb53 to tolerate whitespace and a minor one against ssh-krb5 for the
> crappy debug lines.

Speaking as co-maintainer of both packages, works for me.  :)

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: heimdal/mit-krb mix in ssh-krb5 via libnss-ldap

[Steve Langasek]

On Thu, Jun 16, 2005 at 08:19:32AM -0700, Russ Allbery wrote:
> Jeremie Koenig <[EMAIL PROTECTED]> writes:

> > I got no luck lately and managed to make ssh-krb5 fail due to library
> > linkage weirdness. It took me ages to figure out what was going on!  (I
> > learnt alot on the way, however.)

> > To reproduce the breakage:
> >  1. install libsasl2-modules-gssapi-heimdal, libnss-ldap and ssh-krb5
> > (something else linked against libkrb53 may "work" as well);
> >  2. configure /etc/nsswitch.conf to use ldap for some lookups;
> >  3. configure /etc/ldap/ldap.conf or ~/.ldaprc to use SASL
> > authentication.

> > Then run ssh-krb5, linked with some mit-kerberos libraries. NSS pulls
> > LDAP, which pulls SASL, which pulls its heimdal GSSAPI module, which
> > pulls a lot of heimdal stuff. GDB shows them all when attach'ing to the
> > process. ssh-krb5's gssapi authentications spew out a few "debug1:
> > \n\n\n" lines and fail silently, which is more than graceful with such a
> > mess in place if you ask me :-P

> > The quick fix was to install MIT's gssapi SASL module rather than
> > heimdal's one. Surely a library wizard here can think of a better one,
> > or at least a specific (set of) package(s) to be blamed.

> You've pretty much got the solution I'd recommend.  Heimdal and MIT
> Kerberos are parallel implementations of the same protocol and API and
> share *most* of the same function signatures but not all.  This means
> they're both not interchangeable and they stomp on each other.  You're not
> going to be able to load both libraries into the same namespace and have
> them be comfortable next to each other.  It's kind of like trying to use
> both OpenSSL and gnutls in the same binary, except possibly even worse.

Except that this issue was noticed about two years ago, and I believe symbol
versioning was added to both sets of Kerberos libraries (integrated
upstream) such that it's supposed to be possible to load them both together
without having them step on each other.

> > There must be a way to use an nss module without it's library
> > dependencies polluting what it's called from! In contrast sshd doesn't
> > experience such a thing while it's linked against the same MIT stuff and
> > pam, which uses both libpam-{ldap,heimdal} here. Maybe sasl or the nss
> > are improperly loading their modules?

> ...this is an interesting point.  I seem to recall that there's some way
> with dlopen and ELF to isolate the symbol table of the newly loaded shared
> object and its dependencies from the rest of the program, but I don't know
> if that's sufficient to prevent this sort of clobber.

Still doesn't work in all cases, IIRC.  A better answer is a replacement
interface for NSS that uses an exec boundary to isolate the library
goofiness from the application.

-- 
Steve Langasek
postmodern programmer


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

Re: setting umask globally

[martin f krafft]

also sprach Santiago Vila <[EMAIL PROTECTED]> [2005.06.17.0033 +0200]:
> There is already an umask setting in /etc/login.defs. If it makes people
> happy, I will happily drop the umask setting from /etc/profile, so
> that people do not have to decide between login.defs and profile
> when trying to set an umask globally.

/etc/login.defs is only read for console logins, not for e.g. SSH
logins.

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


signature.asc
Description: Digital signature

Re: Debian concordance

[Thiemo Seufer]

Ian Murdock wrote:
> On 6/16/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > > I strongly suspect they're
> > > more interested in your X.org and GNOME 2.10. Given
> > > that, a lot of this divergence seems pretty gratutious to me.
> > 
> > Yes, these are both very interesting to users.
> > 
> > Which 'divergence' do you mean when you reference that -- X.Org/GNOME
> > 2.10, or glibc?
> 
> glibc. Shipping X.org and GNOME 2.10 adds value, since sarge doesn't
> ship them. Shipping glibc 2.6.5 vs. glibc 2.6.2 just adds
> incompatibilities.

As well as bugfixes and things like ppc64 NPTL.


Thiemo


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Marco d'Itri]

On Jun 16, Eric Dorland <[EMAIL PROTECTED]> wrote:

> I'm not trying to say it's non-free. It is free. What I'm trying to
> determine is if we should use the marks within Debian. Let me try
Good. This was not obvious at all by reading your precedent postings.

> another example. If, say, the Apache Foundation came to us and said,
> "Sure the code is free, but that's our trademark you're using. It will
> cost you $5000 a year to use that trademark in Debian". Now we could
> easily afford this as a project, would we do it? I don't think we
> would do it, even though we could because a strict interpretation of
> the DFSG says trademarks don't matter.
We would quickly tell them to FOAD, because it's a request that
everybody would agree is unreasonable.

> The point I'm trying to make is that clearly not all trademark terms
> are reasonable.
Sure. And the point most people here are trying to make is that they
consider the MF demands reasonable and acceptable for Debian.

Now that we agreed that trademarks are not forbidden by the DFSG, if you
really feel strongly about the need for users of a totally unrestricted
firefox package, why don't you build it as well? Then users and custom
distributions would be able to choose the one which better suits their
needs.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: setting umask globally

[Marco d'Itri]

On Jun 17, Santiago Vila <[EMAIL PROTECTED]> wrote:

> There is already an umask setting in /etc/login.defs. If it makes people
> happy, I will happily drop the umask setting from /etc/profile, so
> that people do not have to decide between login.defs and profile
> when trying to set an umask globally.
This looks like a good idea.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: setting umask globally

[Marco d'Itri]

On Jun 17, martin f krafft <[EMAIL PROTECTED]> wrote:

> also sprach Santiago Vila <[EMAIL PROTECTED]> [2005.06.17.0033 +0200]:
> > There is already an umask setting in /etc/login.defs. If it makes people
> > happy, I will happily drop the umask setting from /etc/profile, so
> > that people do not have to decide between login.defs and profile
> > when trying to set an umask globally.
> 
> /etc/login.defs is only read for console logins, not for e.g. SSH
> logins.
Then maybe the umask setting should be removed from there?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Debian concordance

[Michael K. Edwards]

On 6/16/05, Ian Murdock <[EMAIL PROTECTED]> wrote:
> glibc. Shipping X.org and GNOME 2.10 adds value, since sarge doesn't
> ship them. Shipping glibc 2.6.5 vs. glibc 2.6.2 just adds
> incompatibilities.

Speaking as someone with no Ubuntu affiliation (and IANADD either), I
think that statement is based on a somewhat shallow analysis of how
glibc is handled.  Jeff Bailey and Goto Masanori, and a couple of
other glibc packagers, are probably the people who can make genuinely
informed comments; but having watched the final stages of glibc
convergence for both hoary and sarge, I can say that they are
significantly different "under the hood" despite both being labeled
2.3.2.

On the Ubuntu side, divergences from the last Debian glibc drop that
was merged into hoary (2.3.2.ds1-20) include subtle but important
fixes to NPTL/TLS (with particular implications for heavily
multithreaded apps on Sun's JRE), a fix for a sigsetjmp() issue that
hits gcc 4.0, substantial rework of UTF-8 locale handling, and Tollef
Fog Heen's multiarch support.  The first two of these appear to have
been addressed similarly in Debian's 2.3.2.ds1-21, but there's also a
change to sched_[gs]et_affinity that resulted in GLIBC_2.3.4 versioned
symbols and thus bumped shlib_dep_ver up to 2.3.2.ds1-21.  That's why
many (most?) packages compiled on sarge won't install on hoary.

All of this is on top of the extensive backports to 2.3.2 of fragments
of later glibc snapshots that were already in Debian's 2.3.2.ds1-20. 
Goto-san has expressed the intention of moving sid to glibc 2.3.5 ASAP
(his first upload of 2.3.4 to experimental was in March), and Ubuntu
has synced up to his latest upload and moved forward with build fixes.
 If it is Ubuntu's desire not to diverge too much from sid in the
breezy timeframe, they really did have to merge from Debian
experimental immediately after the hoary release.

It doesn't seem reasonable to me to ask Ubuntu to continue shipping a
fork labeled "2.3.2-whatever" for the duration of stable=sarge.  If it
were possible for breezy to bump shlib_dep_ver to 2.3.2.ds1-21 and
hold it there, that would be great; but it looks to me like Jeff has
bumped it to 2.3.4-1 for good and sufficient reason.  At least, with
some luck, packages compiled on sarge will run on breezy (but not vice
versa without manual shlibver mangling), just as packages compiled on
hoary will run on sarge (ditto).

Cheers,
- Michael

Re: Debian concordance

[Michael K. Edwards]

On 6/16/05, Matthias Klose <[EMAIL PROTECTED]> wrote:
> Python is basic for Ubuntu. Given the long freeze of sarge, Debian had
> to support 2.1 (jython), 2.2 (for zope 2.6) and 2.3 for sarge. I'm
> happy we did have a possibility to ship 2.4.1 with sarge. Maybe not
> with the best packaging, but it's included in the release. We will
> have a better packaging for etch/breezy.

No criticism intended of Ubuntu's work on python packaging, which is
awesome.  I just meant to point out that it is pretty much inevitable
that python packages need to be compiled separately for sarge and
hoary if they are to be used with the default runtime.

> Please stop spreading fud about C++ and perl ABI compatibility. There
> is none! Both sarge and hoary did ship with ABI compatible Perl and
> C++ ABIs.  Basic ABI/API updates are done at the start of a new
> release cycle, there is no difference how that is done in Debian and
> Ubuntu.  There is no point comparing the state of development and
> unstable versions.

I'm sorry, I really don't mean to be spreading FUD.  I meant those as
criteria for a lowest-common-denominator build environment, not as
statements about what is or isn't compatible between sarge and hoary. 
There is of course a great deal more involved in practical ABI
compatibility than compiler / standard library divergences; addressing
the libc6 shlibver issue may resolve the Perl XSUB problems (I haven't
tried it yet), but I haven't even checked whether there are other
last-minute divergences in things like libxml2, glib, libnspr4,
libssl, etc.

In general, I think it's normal for it to take some work to set up a
build environment for binary packages that are supposed to install and
function on multiple distros, no matter how closely related the
distros are.  It would be a really wonderful thing if Debian and
Ubuntu (and any other Debian derivatives willing to pitch in) could do
that work instead of sticking ISVs (commercial or otherwise) with it.

Cheers,
- Michael

Re: setting umask globally

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2005.06.17.0103 +0200]:
> > /etc/login.defs is only read for console logins, not for e.g. SSH
> > logins.
> Then maybe the umask setting should be removed from there?

r agree. Since any login session these days will invoke a shell,
there is no point in having login.defs set the umask -- the shell
will override it anyway.

Filing a bug against login...

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


signature.asc
Description: Digital signature

Re: Upcoming removal of orphaned packages

[Sven Mueller]

Laszlo Boszormenyi wrote on 16/06/2005 23:13:
> On Thu, 2005-06-16 at 22:13 +0200, Andreas Tille wrote:
> 
>>Perhaps this might be true for the initial Perl implementation, but:
>>
>>"[2001/03/03 10:05] Markus Schoder has contributed finddupes.cpp, GPL'ed 
>>source code for a C++ based version of my horribly slow compare routine. In 
>>his testing on a directory of 35,000 images, it was about 300 times faster 
>>than findimagedupes' perl implementation."
> 
>  Yup, but that's even more old, more than four years old. Will download
> it and check if its still compilable even.

It's only compilable in its current state with g++-2.95 (regarding
compilers in Debian stable). There is a single error when compiling with
g++-3.4 which I am unable to fix (as I don't know the STL at all).

Apart from that, it works quite fine.

>>>and, I would say, both make it obsolete.
>>
>>If both would have a command line interface.
> 
>  I do not think they have.

Exactly.

>>  I do not know both but
>>the page you quoted mentioned that findimagedupes is the only command line
>>tool.
> 
>  Yes, and this is sad. What I need is a command line tool as well. I can
> not have any GUI where I would like to use it.

Same for me.

>>I would really love a command line alternative.  If you tell me any
>>I will be quiet immediately.
> 
>  I do not know any. But if any of you find an alternative, then please
> tell me as well.

/aol

>>  But I would love to have a test first.
>>Please give me two weeks.
> 
>  Thanks, the time is on your side as I also would like to have a command
> line based tool.

Yes, plaaasse.

cu,
sven


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

Re: Upcoming removal of orphaned packages

[Margarita Manterola]

On 6/16/05, Paul Gear <[EMAIL PROTECTED]> wrote:

> > trustees -- Advanced permission management system for Linux [#251189]
> >   orphaned 379 days ago, according to maintainer upstream dead, removal
> >   already suggested one year ago, very small install base
> One more issue in favour of this is that Novell have released the NSS
> filesystem for Linux with SLES9, so an alternative "inspired by" NSS
> isn't really necessary now...

Is this already packaged for Debian?

-- 
Besos,
Marga

Re: Debian concordance

[Matthias Klose]

Michael K. Edwards writes:
> In general, it's not trivial to set up a build environment that
> reliably produces binary packages that are installable on both sarge
> and hoary.  (I happen to have such an environment at work, based on a
> part-careful-part-lucky snapshot of sid, but it's not something I
> would care to support for more than a few packages.)  It would be
> awfully nice if Debian and Ubuntu could coordinate on a 90% solution;
> I don't necessarily expect to be able easily to build python packages
> that will run on both (given Ubuntu's early move to 2.4) but how about
> basic C, C++, and perl ABI compatibility?

Python is basic for Ubuntu. Given the long freeze of sarge, Debian had
to support 2.1 (jython), 2.2 (for zope 2.6) and 2.3 for sarge. I'm
happy we did have a possibility to ship 2.4.1 with sarge. Maybe not
with the best packaging, but it's included in the release. We will
have a better packaging for etch/breezy.

Please stop spreading fud about C++ and perl ABI compatibility. There
is none! Both sarge and hoary did ship with ABI compatible Perl and
C++ ABIs.  Basic ABI/API updates are done at the start of a new
release cycle, there is no difference how that is done in Debian and
Ubuntu.  There is no point comparing the state of development and
unstable versions.

  Matthias

PS: From those people spending time reasoning about releases, I'd like
to see the same amount of work going into release work itself :-/


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

Re: Greylisting for @debian.org email, please

[Wouter Verhelst]

On Thu, Jun 16, 2005 at 03:09:47PM +0200, Pierre Habouzit wrote:
> Le Jeu 16 Juin 2005 14:33, Santiago Vila a écrit :
> > Now that we have released sarge, I would like to ask debian-admin and
> > the Project Leader to consider seriously doing something to reduce
> > the level of spam we have to receive, store, and filter in our
> > @debian.org addresses.
> >
> > For example, we could use greylisting. Or we could reject messages
> > that are known to come directly from trojanized windows machines
> > acting as open proxies. Or even better, we could do both things.
> 
> I fully disagree, greylisting is really painful,

What's painful about it?

It stops a lot of viruses and spam, with no false positives. What's the
problem?

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Upcoming removal of orphaned packages

[Rich Walker]

Frank Lichtenheld <[EMAIL PROTECTED]> writes:

> While many bugs are a reason to remove a package quickly, no bugs
> aren't a reason to keep it forever. The Debian QA group maintains
> packages that are orphaned to give other maintainers the chance
> to adopt it without too much hassle, and as a service to those
> that use them. But this has to be only a temporary solution.

Point taken.

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


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

Re: Debian concordance

[Steve Langasek]

On Thu, Jun 16, 2005 at 04:03:32PM -0700, Michael K. Edwards wrote:
> On 6/16/05, Ian Murdock <[EMAIL PROTECTED]> wrote:
> > glibc. Shipping X.org and GNOME 2.10 adds value, since sarge doesn't
> > ship them. Shipping glibc 2.6.5 vs. glibc 2.6.2 just adds
> > incompatibilities.

> Speaking as someone with no Ubuntu affiliation (and IANADD either), I
> think that statement is based on a somewhat shallow analysis of how
> glibc is handled.  Jeff Bailey and Goto Masanori, and a couple of
> other glibc packagers, are probably the people who can make genuinely
> informed comments; but having watched the final stages of glibc
> convergence for both hoary and sarge, I can say that they are
> significantly different "under the hood" despite both being labeled
> 2.3.2.

> On the Ubuntu side, divergences from the last Debian glibc drop that
> was merged into hoary (2.3.2.ds1-20) include subtle but important
> fixes to NPTL/TLS (with particular implications for heavily
> multithreaded apps on Sun's JRE), a fix for a sigsetjmp() issue that
> hits gcc 4.0, substantial rework of UTF-8 locale handling and Tollef
> Fog Heen's multiarch support.  The first two of these appear to have
> been addressed similarly in Debian's 2.3.2.ds1-21,

So if they were merged, why is it relevant that they were merged from hoary
to sarge instead of the other way around?

> but there's also a change to sched_[gs]et_affinity that resulted in
> GLIBC_2.3.4 versioned symbols and thus bumped shlib_dep_ver up to
> 2.3.2.ds1-21.

Indeed; and the shlibs model of identifying dependencies unfortunately is
not very fine-grained, with the result that it's a lose-lose choice between
making people manually set shlibs when building on sarge if they want hoary
compatibility, or shipping glibc in sarge with an incorrectly relaxed shlibs
that could let you install packages on hoary that won't work there.

So, maybe it's time to revisit the weaknesses of the shlibs system,
particularly as they apply to glibc.  Scott James Remnant had done some
poking in this area about a year ago, which involved tracking when
individual symbols were added to a package -- apparently, many packages
would actually be happy with glibc 2.1 or so (at least on i386), but we have
no way to track this...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Greylisting for @debian.org email, please

[Rich Walker]

Wouter Verhelst <[EMAIL PROTECTED]> writes:
>
> What's painful about it?
>
> It stops a lot of viruses and spam, with no false positives. What's the
> problem?

These are common misapprehensions about greylisting. Unfortunately:

It has false positives. /var/lib/greylistd/whitelist-hosts lists a
selection of mail servers that do not handle greylisting properly. There
are others as well. Only if the person who sent the mail phones up and
says "why didn't you answer my mail" do you stand a chance of
discovering that another mail server is broken.

It delays mail from people who haven't mailed you before. This is
*guaranteed* to cause senior people in the company to come knocking on
your door within hours of you turning it on.

Otherwise, I'd use it :->

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


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

Re: Debian concordance

[Matthias Klose]

Ian Murdock writes:
> On 6/16/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > Hoary (like sarge) is built against 2.3.2.
> > 
> > Breezy (like current sid) is built against 2.3.5.
> 
> Why?

- Ubuntu supports its powerpc users with a ppc64 toolchain and kernels.
- Ubuntu does toolchain upgrades at the beginning of a release cycle as
  Debian does.

  Matthias


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

Re: Debian concordance

[Michael K. Edwards]

On 6/16/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 04:03:32PM -0700, Michael K. Edwards wrote:
> > On the Ubuntu side, divergences from the last Debian glibc drop that
> > was merged into hoary (2.3.2.ds1-20) include subtle but important
> > fixes to NPTL/TLS (with particular implications for heavily
> > multithreaded apps on Sun's JRE), a fix for a sigsetjmp() issue that
> > hits gcc 4.0, substantial rework of UTF-8 locale handling and Tollef
> > Fog Heen's multiarch support.  The first two of these appear to have
> > been addressed similarly in Debian's 2.3.2.ds1-21,
> 
> So if they were merged, why is it relevant that they were merged from hoary
> to sarge instead of the other way around?

It's not particularly; they just happened to be things I was aware of
on the Ubuntu side, and in verifying the corresponding changes in -21
I was relieved to see that similar (not, I think, identical) patches
went into sarge.  Looks like Ubuntu has since adopted Debian's fix for
at least the TLS fix (not sure about the others, they may already be
dealt with upstream in 2.3.[45]).

> > but there's also a change to sched_[gs]et_affinity that resulted in
> > GLIBC_2.3.4 versioned symbols and thus bumped shlib_dep_ver up to
> > 2.3.2.ds1-21.
> 
> Indeed; and the shlibs model of identifying dependencies unfortunately is
> not very fine-grained, with the result that it's a lose-lose choice between
> making people manually set shlibs when building on sarge if they want hoary
> compatibility, or shipping glibc in sarge with an incorrectly relaxed shlibs
> that could let you install packages on hoary that won't work there.

Right.  As I said, it's not surprising, and not cause for criticism,
that there's a need for a specialized environment if you want to build
multi-distro binary packages.  It's a bit like building LSB RPMs,
except it's less painful because of the shared heritage and the
reduced need to lag drastically when there are fewer distros involved.

> So, maybe it's time to revisit the weaknesses of the shlibs system,
> particularly as they apply to glibc.  Scott James Remnant had done some
> poking in this area about a year ago, which involved tracking when
> individual symbols were added to a package -- apparently, many packages
> would actually be happy with glibc 2.1 or so (at least on i386), but we have
> no way to track this...

It would be pretty cool to actually extract the external symbols
referenced in a package's ELF objects and deduce the minimum "happy"
library versions accordingly.  Alternately, one could construct a set
of chroots with various historical library mixes and grind through the
ELF objects with ldd.  That's really more along the lines of automated
"white box" testing, and might fit better into the sort of grandiose
post-build QA-role-signature chain I've proposed a couple times than
it does in the build process per se.

This holds especially when it comes to ISV certifications, to the
extent that that's of interest to Debian and/or derivatives.  (Oracle
on Ubuntu, anyone?)  ISV build processes tend to be rather stinky, and
post-build touch-ups to metadata are more practical than retrofits to
the build.  (There's likely to be an alien / java-package style stage
in the process anyway.)

Cheers,
- Michael

Bug#314541: ITP: buildbot -- Build automation system

[Otavio Salvador]

Package: wnpp
Severity: wishlist
Owner: Otavio Salvador <[EMAIL PROTECTED]>


* Package name: buildbot
  Version : 0.6.6
  Upstream Author : Brian Warner <[EMAIL PROTECTED]>
* URL : http://buildbot.sourceforge.net/
* License : GPL
  Description : Build automation system

Description: Build automation system
 The BuildBot is a system to automate the compile/test cycle required by most
 software projects to validate code changes. By automatically rebuilding
 and testing the tree each time something has changed, build problems are
 pinpointed quickly, before other developers are inconvenienced by the
 failure. The guilty developer can be identified and harassed without human
 intervention. By running the builds on a variety of platforms, developers who
 do not have the facilities to test their changes everywhere before checkin
 will at least know shortly afterwards whether they have broken the build or
 not. Warning counts, lint checks, image size, compile time, and other build
 parameters can be tracked over time, are more visible, and are therefore
 easier to improve.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-rc4
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)

Versions of packages wnpp is related to:
ii  reportbug 3.13   reports bugs in the Debian distrib
ii  totem-gstreamer   1.0.3-1A simple media player for the Gnom


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> On Wed, Jun 15, 2005 at 07:23:39PM -0400, Eric Dorland wrote:
> > * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > > On Wed, Jun 15, 2005 at 11:48:55AM -0400, Eric Dorland wrote:
> > > > * Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> > > > > Where possible, sure. But "principles" doesn't mean "the rules should 
> > > > > be
> > > > > exactly the same".
> > > > 
> > > > Please stop putting words in my mouth. I never said that the rules
> > > > should necessarily be the same. But I am of the opinion that the
> > > > spirit of DFSG #8 should apply.
> > > 
> > > To trademarks? Why? I don't see why that would be necessary, or even a
> > > good idea; but I'm sure I can be convinced given good arguments.
> > 
> > It's a question of fairness, which I think is embodied by DFSG
> > #8. We're getting this offer from MoFo because, I think, we are
> > Debian. We're big and we're cool, there's no denying it :) But other
> > entities, equally deserving of the trademark usage from a quality
> > standpoint won't get it because MoFo doesn't care about them.
> 
> Is that a given, or is that a theory?
> 
> If it's a given, I agree with you.
> 
> If it's a theory, you should find out whether it's true. If it's not,
> there's no problem.

It's of course theoretical. The Mozilla Foundation could be perfectly
fair and even handed. Or they could just deal out trademarks to the
big distros and not anyone else. The problem is we won't know. They're
not laying out any guidelines (even imperfect ones) by which they're
going to judge whether someone is deserving of using the trademark or
not. So they can reject someone's petition merely because they're not
large enough to be interesting (or any other reason), and hide behind:
"We didn't think their package was of high quality", and we can't
refute them because we don't have a copy of the rulebook.

Yes, setting up guidelines like this is hard, but not showing us the
criteria they're going to be using isn't fair. I suspect that MoFo
won't care enough to give a distro with 100 users a trademark
agreement, it's not worth their while. And from their perspective,
rightly so. But I think from Debian's point of view we shouldn't be
buying into something like this. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Greylisting for @debian.org email, please

[Miles Bader]

Wouter Verhelst <[EMAIL PROTECTED]> writes:
> What's painful about it?
>
> It stops a lot of viruses and spam, with no false positives. What's the
> problem?

"No false positives" seems a bit optimistic.

One problem I've encountered in the past is big mail providers (like
yahoo) who will send retries from _different_ servers, which sometimes
don't even have a DNS entry (maybge it's just DNS propagation delay, I
don't know).

How do greylisting services determine that a message is being resent
(and so should be accepted this time)?  If it's by hostname or host
address, this would sometimes fail with systems like the above.

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff


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

Re: setting umask globally

[Steve Greenland]

On 16-Jun-05, 17:23 (CDT), martin f krafft <[EMAIL PROTECTED]> wrote: 
> Is there any point in following through with the /etc/umask.conf
> proposal? libpam-umask is optional after all, and unless people know
> about it, they'll edit multiple files wrt umask, and we *could*
> unify this with relative ease.

And unless they know about the completely non-standard /etc/umask.conf,
they'll still edit multiple files. These days, any sort of "I want the
same setting of 'x' for all the different ways people can login" should
instantly make you think "I wonder if there's a PAM module that sets
'x'?". And usually there is. Except for environment variables[1].

Steve

[1] Yeah, I know about pam_env, but it I've never been able to get it do
what I want (add $HOME/bin to PATH.) Probably lack of clue on my part.




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


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Marco d'Itri ([EMAIL PROTECTED]) wrote:
> On Jun 16, Eric Dorland <[EMAIL PROTECTED]> wrote:
> 
> > I'm not trying to say it's non-free. It is free. What I'm trying to
> > determine is if we should use the marks within Debian. Let me try
> Good. This was not obvious at all by reading your precedent postings.

Ok, I did state that many times I thought, I was trying to get that
point across. 
 
> > another example. If, say, the Apache Foundation came to us and said,
> > "Sure the code is free, but that's our trademark you're using. It will
> > cost you $5000 a year to use that trademark in Debian". Now we could
> > easily afford this as a project, would we do it? I don't think we
> > would do it, even though we could because a strict interpretation of
> > the DFSG says trademarks don't matter.
> We would quickly tell them to FOAD, because it's a request that
> everybody would agree is unreasonable.

I'm glad we can at least see eye to eye on this one.

> > The point I'm trying to make is that clearly not all trademark terms
> > are reasonable.
> Sure. And the point most people here are trying to make is that they
> consider the MF demands reasonable and acceptable for Debian.

Indeed, the most vocal (and rational) contributors seem to be saying
these demands are reasonable. I'm still not convinced. 

> Now that we agreed that trademarks are not forbidden by the DFSG, if you
> really feel strongly about the need for users of a totally unrestricted
> firefox package, why don't you build it as well? Then users and custom
> distributions would be able to choose the one which better suits their
> needs.

Twice as much work? Thanks a bunch :-P


-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Eric Dorland]

* Don Armstrong ([EMAIL PROTECTED]) wrote:
> On Thu, 16 Jun 2005, Eric Dorland wrote:
> > * Don Armstrong ([EMAIL PROTECTED]) wrote:
> > > On Thu, 16 Jun 2005, Eric Dorland wrote:
> > > > * Don Armstrong ([EMAIL PROTECTED]) wrote:
> > > > > All of MoFo trademarks that were not being used in a manner
> > > > > consistent with trademark law[2] would have to be expunged from
> > > > > the work,
> > > > 
> > > > What trademarks are you referring to? Already the Debian packages
> > > > don't use any of the trademarked images and logos? 
> > > 
> > > If we don't use any trademarked images, logos, or phrases, what
> > > exactly are we talking about here?
> > 
> > The term "Firefox" is what trademarked, and the only trademark still
> > in the Debian package AFAIK. That's what we're talking about. 
> 
> Then that would be a "MoFo trademark" that is possibly "used in a
> manner [not] consistent with trademark law." If that was the case, it
> would be a mark that "would have to be expunged from the work."
> 
> My main point here seems to have been lost: I am merely pointing out
> that the changes required are far more extensive than the renaming of
> a binary|script|package, but appear to involve substantial branding
> changes throughout the package; this seems to be a bit more extensive
> than the minor restriction that DFSG §4 allows.

Well I don't think DFSG #4 says the rename has to be easy, it just has
to be possible.

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Debian concordance

[Scott James Remnant]

On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote:

> So, maybe it's time to revisit the weaknesses of the shlibs system,
> particularly as they apply to glibc.  Scott James Remnant had done some
> poking in this area about a year ago, which involved tracking when
> individual symbols were added to a package -- apparently, many packages
> would actually be happy with glibc 2.1 or so (at least on i386), but we have
> no way to track this...
> 
I was just thinking the same with this thread ...

The principal problem with the "shlibsyms" stuff was that in order to
track when symbols are added to a package, you need the list of the set
of symbols that were in the last version -- and as the source packages
are put together before the binary, the source package wouldn't contain
the updated set of symbols.

One "easy" way would be to simply make it an error for there to be any
new symbols while building a source package -- so you'd have to update
the table before building so it gets put into the source; this is a bit
invasive though.

(It also could have repercussions for buildds, if there are symbols that
only exist on a particular architecture.)

I haven't come up with another yet.

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


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

Re: Upcoming removal of orphaned packages

[Joey Hess]

Martin Michlmayr wrote:
> gkdial -- PPP dial-up configuration and dialing tool [#287992]
>   * Orphaned 164 days ago
>   * 1 RC bugs.

Does any graphical ppp frontend exist that can be used instead of this?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian concordance

[Steve Langasek]

On Fri, Jun 17, 2005 at 04:26:36AM +0100, Scott James Remnant wrote:
> On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote:

> > So, maybe it's time to revisit the weaknesses of the shlibs system,
> > particularly as they apply to glibc.  Scott James Remnant had done some
> > poking in this area about a year ago, which involved tracking when
> > individual symbols were added to a package -- apparently, many packages
> > would actually be happy with glibc 2.1 or so (at least on i386), but we have
> > no way to track this...

> I was just thinking the same with this thread ...

> The principal problem with the "shlibsyms" stuff was that in order to
> track when symbols are added to a package, you need the list of the set
> of symbols that were in the last version -- and as the source packages
> are put together before the binary, the source package wouldn't contain
> the updated set of symbols.

> One "easy" way would be to simply make it an error for there to be any
> new symbols while building a source package -- so you'd have to update
> the table before building so it gets put into the source; this is a bit
> invasive though.

http://lists.debian.org/debian-devel/2005/06/msg01185.html

>:)

Invasive, yes, but I think it's time to take our library QA tools to the
next level.

> (It also could have repercussions for buildds, if there are symbols that
> only exist on a particular architecture.)

Yep.  And glibc happens to be the chief candidate for that, unfortunately.
Also an issue are any C++ libs being built using different compilers on
different architectures.

So there does seem to be a need for per-architecture override lists.  I'm
not sure how user-friendly the support for that would need to be initially,
though.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature