Re: Greylisting for @debian.org email, please

[Josselin Mouette]

Le dimanche 19 juin 2005 à 00:34 +0200, Marco d'Itri a écrit :
> > Just to make clear: this "requirement" of yours is one you have
> > invented.
> Me and a large part of the Internet.
> (Hint: RFCs are not the word of $GOD, but something which sites agree
> about to help interoperability.)

How about all using Microsoft Windows XP ? A large part of the Internet
is using it, and this will improve interoperability.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Debian concordance

[Steve Langasek]

On Sat, Jun 18, 2005 at 11:22:35PM -0700, Michael K. Edwards wrote:
> On 6/18/05, Joey Hess <[EMAIL PROTECTED]> wrote:
> > Matt Zimmerman wrote:
> > > Practically speaking, the differences in compatibility between Ubuntu and
> > > Debian is of as much concern as those between Debian stable and Debian
> > > unstable.  New interfaces are added in unstable constantly, and software 
> > > is
> > > adapted to use them.  Binary packages from unstable are rarely installable
> > > on stable without upgrading other supporting packages.  Third party
> > > packagers must choose whether to provide builds for stable (if the package
> > > builds), unstable or both.  So far, this has not resulted in a problem for
> > > Debian.

> > Except unstable is capable of running packages built on stable, and
> > stable is to some extent (partial upgrades) capable of running packages
> > built on unstable. And if it doesn't work, a dependency will tell you it
> > doesn't work. And Debian is able to decide we want to make it work better
> > and fix things. So I don't think your analogy holds up very well.

> After six months, I suspect that sid will have evolved to where no
> binary package of any great complexity from sarge will install on it
> without a stack of "oldlibs"; and backports will be (as usual) a royal
> pain.  Better just to run a carefully selected sid snapshot.  Test
> your backups frequently, though.  :-)

Of 596 "lib" packages in woody (loosely identified), 325 are still
present in sarge.  That's after three years of more or less constant
development.  Where did you come up with this absurd idea that all binary
packages "of any great complexity" will become uninstallable after only six
*months*?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Debian concordance

[Michael K. Edwards]

On 6/19/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Of 596 "lib" packages in woody (loosely identified), 325 are still
> present in sarge.  That's after three years of more or less constant
> development.  Where did you come up with this absurd idea that all binary
> packages "of any great complexity" will become uninstallable after only six
> *months*?

The examples that come to mind immediately are those with substantial
components in both native code and an interpreted or bytecode
language, such as Perl XSUBs and Python extensions.  Last time around,
I seem to recall that Perl was updated shortly after the release, and
you couldn't very well install a binary package containing a Perl
module (especially an XSUB) without also installing the old Perl, by
which time you might as well have a stable chroot.  And what are the
odds of my tweaked Python profiler, built to divert individual files
within the Python library tree, working with sid's stock Python build
come December?

The next example to pop into my head is the Midgard content management
framework, which involves both an Apache module and piles of PHP code.
 The chances of a binary package built on sarge installing (let alone
working) against next year's apache and php packages in sid probably
aren't that high.

The fact is that, while the C dynamic library naming system and the
split into libfoo2 and libfoo-dev allows multiple historical versions
to co-exist, the same cannot be said of all languages and development
frameworks.  Biggish software packages tend to have a few too many
paths and versions compiled into them to survive the first six months
after a release without source code changes and recompilation.  Think,
say, the LyX WYSIWYM front end to LaTeX (which knows the paths to all
sorts of document format converters) or a build of gvim with all of
the scripting language bells and whistles.

Doubtless others who have had more occasion to attempt this sort of
thing than I have will provide more examples if needed.

Cheers,
- Michael

Re: Testing package installation, upgrading, and removal

[Junichi Uekawa]

Hi,

> Frank Lichtenheld and others have brought up the idea of automatically
> testing installation, upgrading, and removal of packages. It struck me
> that it should be pretty simple to implement at least basic versions of
> this. The result: http://liw.iki.fi/liw/download/piuparts-0.4.tar.gz
> 
> I have attached the manual page.
> 
> The current version is quite simplistic. It may well be too simplistic
> to work for more than in simple cases, but it's a start.
> 
> I'd be very curious to hear about suggestions for improvements.

I've looked at it, and it seems to be a program that does similar 
thing to my sample code in pbuilder.

'B91dpkg-i' script provided in pbuilder example should
do what piuparts is doing (with less checks than your code, 
and more overhead).

'B' hooks in pbuilder are hooks that are ran after 
pbuilder builds a package. I am hoping for 
every maintainer to run that hook after building a package
so that they pass the basic tests.


regards,
junichi

===File examples/B91dpkg-i===
#!/bin/bash
# try to install the resulting debs.

echo "Trying to install resulting packages and test upgrades"
set -ex


PKGNAMES=$(cd /tmp/buildd && ls -1 *.deb | sed 's/_.*$//' )

# install-remove check
dpkg -i /tmp/buildd/*.deb
dpkg --remove $PKGNAMES

# install-purge check
dpkg -i /tmp/buildd/*.deb
dpkg --purge $PKGNAMES

# upgrade-remove check
apt-get install $PKGNAMES || true
dpkg -i /tmp/buildd/*.deb
dpkg --remove $PKGNAMES

# upgrade-purge check
apt-get install $PKGNAMES || true
dpkg -i /tmp/buildd/*.deb
dpkg --purge $PKGNAMES



-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


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

Re: Release-critical Bugreport for June 17, 2005

[Turbo Fredriksson]

Quoting BugScan reporter <[EMAIL PROTECTED]>:

> Bug stamp-out list for Jun 17 06:06 (CST)

> Package: netsaint-plugins (non-US/main)
> Maintainer: Turbo Fredriksson <[EMAIL PROTECTED]>
>   305479 [ +  ] netsaint-plugins: check_log plugin breaks system

I thought I requested for this package(s) to be removed from Debian!?

EVERYTHING 'Netsaint' related should be removed. It have (successfully)
been superseded by 'Nagios' (it's new name)...

> Package: roxen3 (debian/main)
> Maintainer: Turbo Fredriksson <[EMAIL PROTECTED]>
>   298934 [] [X] roxen3: contains non-free fonts

In one of Debian's lists (have no idea which), I/we discussed this. It was
YEARS ago.

The conclution was that the 'copyright' (or lackof - can't remember) was ok...


Does anyone have a clue where to look or remember this discussion!?

> Package: roxen4 (debian/main)
> Maintainer: Turbo Fredriksson <[EMAIL PROTECTED]>
>   312243 [ +  ] roxen4: Roxen4 shutdown kills independent mysql instance

I'll get back on this 'later'. I've already fixed it once (can't remember why
it resurfaced though).
-- 
president Cuba arrangements bomb KGB iodine quiche North Korea Noriega
Honduras CIA subway FSF Qaddafi Serbian
[See http://www.aclu.org/echelonwatch/index.html for more about this]


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

Re: Keysigning without physically meeting ... thoughts?

[Kevin Mark]

On Sun, Jun 19, 2005 at 03:19:14PM +1000, Brian May wrote:
> > "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> >> Is this process "correct"? Or did something go seriously wrong
> >> here?  If it was correct, why was it correct? If it was wrong,
> >> why was it wrong?
> 
> For anyone who didn't pick it up; I lied: <[EMAIL PROTECTED]> isn't my
> email address.
> 
> Steve> Many people consider all of options a), b), and c) to be
> Steve> inappropriate, and will instead encrypt each of the uid
> Steve> signatures individually and mail them to the corresponding
> Steve> email address, to verify that you control each address.
> 
> I didn't see any key signing HOWTO or FAQ that mentioned this, not
> even the Debian guide. Do you have a reference?
> 
> However, if I was able to intercept email to <[EMAIL PROTECTED]> (maybe
> I have exploited a security hole in master.debian.org that hasn't been
> discovered/fixed yet), this wouldn't help.
DD's  from time to time are MIA, busy, on vacation, etc. Is that not
another form of 'security hole'? Would this not allow time for someone 
to: intercept mail, NMU, etc.
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: Release-critical Bugreport for June 17, 2005

[Lars Wirzenius]

su, 2005-06-19 kello 11:28 +0200, Turbo Fredriksson kirjoitti:
> > Package: roxen3 (debian/main)
> > Maintainer: Turbo Fredriksson <[EMAIL PROTECTED]>
> >   298934 [] [X] roxen3: contains non-free fonts
> 
> In one of Debian's lists (have no idea which), I/we discussed this. It was
> YEARS ago.
> 
> The conclution was that the 'copyright' (or lackof - can't remember) was ok...
> 
> Does anyone have a clue where to look or remember this discussion!?

Use "site:lists.debian.org roxen3 font copyright" or something similar
to search the list archives with google.


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

Re: Testing package installation, upgrading, and removal

[Lars Wirzenius]

la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti:
> I want to run a test that installs each package in woody in turn,
> upgrades them to sarge, then to sid, then purges it, then looks for
> /usr/doc and /usr/info stuff that is were produced during the package's
> install or upgrade and not removed.

An interesting use case, which I hadn't thought of. I'll have to come up
with a way to do this.


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

Bug#314915: ITP: gifshuffle -- GIF colourmap steganography program

[Nico Golde]

Package: wnpp
Severity: wishlist
Owner: Nico Golde <[EMAIL PROTECTED]>

* Package name: gifshuffle
  Version : 2.0 
  Upstream Author : Matthew Kwan <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : Public domain
  Description : GIF colourmap steganography program

gifshuffle is a program for  concealing  messages  in  GIF
images  by  shuffling  the  colourmap. A shuffled image is
visibly indistinguishable from  the  original.  gifshuffle
works  with  all  GIF  images, including those with trans-
parency and animation.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.11
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])

Versions of packages wnpp is related to:
ii  reportbug 3.13   reports bugs in the Debian distrib
pn  totem-gstreamer(no description available)

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


signature.asc
Description: Digital signature

Re: Release-critical Bugreport for June 17, 2005

[Frank Lichtenheld]

On Sun, Jun 19, 2005 at 11:28:17AM +0200, Turbo Fredriksson wrote:
> Quoting BugScan reporter <[EMAIL PROTECTED]>:
> 
> > Bug stamp-out list for Jun 17 06:06 (CST)
> 
> > Package: netsaint-plugins (non-US/main)
> > Maintainer: Turbo Fredriksson <[EMAIL PROTECTED]>
> >   305479 [ +  ] netsaint-plugins: check_log plugin breaks system
> 
> I thought I requested for this package(s) to be removed from Debian!?
> 
> EVERYTHING 'Netsaint' related should be removed. It have (successfully)
> been superseded by 'Nagios' (it's new name)...

Probably still present in the remnants of non-US. There are still a few
packages available on the server claiming to be for sarge...
Most scripts just ignore them by now.

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: Excuses page showing incorrect dependencies

[Roberto C. Sanchez]

On Sun, Jun 19, 2005 at 08:17:43AM +0200, Andreas Metzler wrote:
> Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> > The excuses pages are showing that my vncsnapshot package is being held
> > back for two reasons.  First, it is only 4 of 10 days old, which is
> > acceptable.  Second, because it depends on gcc-4.0, which has RC bugs.
> > However, I haven't specificed such a dependency.
> 
> > $ apt-cache show vncsnapshot |sed -n '/^Depends/p'
> > Depends: libc6 (>= 2.3.2.ds1-21), libgcc1 (>= 1:3.4.1-3), libjpeg62,
> > libstdc++5 (>= 1:3.3.4-1), zlib1g (>= 1:1.2.1), vnc-common
> 
> > Why is this?
> 
> Because you are only checking the iX86 version of your package.
> 
> http://packages.debian.org/unstable/x11/vncsnapshot
> [...]
> libgcc1 (>= 1:3.3.4-1) [hppa]
> GCC support library
> libgcc1 (>= 1:3.4.1-3) [arm, i386]
> libgcc1 (>= 1:4.0.0-7) [not arm, hppa, i386]
> 
> libgcc1 is now available in a new version, built from gcc-4 and a couple
> of autobuilders  have built your package /after/ that.
>  cu andreas
> 

Interesting.  Thanks for the pointer.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


pgpmQJQwN7xdU.pgp
Description: PGP signature

Re: TODO for etch ?

[Adam Majer]

On Sat, Jun 18, 2005 at 10:14:27PM -0500, Gunnar Wolf wrote:
> Adam Majer dijo [Wed, Jun 15, 2005 at 01:15:00PM -0500]:
> > > - Change boot system, to one capable of handling dependencies and
> > >   parallell invocation, to speed up the boot process.
> > >  
> > >
> > Err.. Why? The current "slow" bootup is caused mostly by hardware
> > detection from my experience. Speeding up hardware detection or remove
> > it in favour of manual /etc/modules entries would speed up the boot
> > process a lot more than changing the boot process. If it ain't broke, do
> > not fix it.
> 
> My systems have no hardware detection at all - But they start many
> daemons at boot time. Probably, say, Apache and Postgres could be
> started concurrently, saving some extra time.

That could "save" a grand total of about a second. Also, during
startup the bottleneck is the hard drive in many cases so starting concurrently
might not speed up your boot process significantly.

The biggest problem is debugging. Sure, you can fork and start all of
the processes concurrently, but what about if the start fails? You
also want to have some processes started before others so you need
asynchronous instead of synchronous waits... Blah..

Anyway, you can test your maximum speedup like this,

1. Get a list of all the /etc/init.d/ scripts you want to start.
2. Start the sequentially while timing them.
3. Now start them concurrently and time them. When all /etc/init.d/
scripts terminate, that is when you are done.
4. What is the difference?

If you are using bash for this, the easiest way might be to trap
SIGCHLD or something to check when the child terminates.

Alternatively, don't start Apache and Postgres on your workstation to
save a second or two in the boot process. :P

- Adam


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

Re: Testing package installation, upgrading, and removal

[Otavio Salvador]

> "lars" == Lars Wirzenius <[EMAIL PROTECTED]> writes:

lars> la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti:
>> I want to run a test that installs each package in woody in
>> turn, upgrades them to sarge, then to sid, then purges it, then
>> looks for /usr/doc and /usr/info stuff that is were produced
>> during the package's install or upgrade and not removed.

lars> An interesting use case, which I hadn't thought of. I'll
lars> have to come up with a way to do this.

Yes. This can help us to figure out upgrade problems before it
affect many users and then improve our upgradeness between
releases.

sarge upgradability isn't so good like it can be. This tools can
help us to improve this for next release.

Thanks a lot by this tool and for your work :-D

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Re: Testing package installation, upgrading, and removal

[Petter Reinholdtsen]

[Joey Hess]
> I want to run a test that installs each package in woody in turn,
> upgrades them to sarge, then to sid, then purges it, then looks for
> /usr/doc and /usr/info stuff that is were produced during the
> package's install or upgrade and not removed.

I made a script to test upgrades from woody to sarge a long time ago.
This script is available from
http://developer.skolelinux.no/~pere/upgrade-testing/test-upgrade.sh>.

Perhaps it could be used to get some ideas for the upgrade testing?

It would also be interesting to see if the package left some processes
behind (aka not using start-stop-daemon), or if any files are left
behind when the package is purged.  I never wrote code to do this,
though.


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

Re: TODO for etch ?

[Petter Reinholdtsen]

[Adam Majer]
> That could "save" a grand total of about a second. Also, during
> startup the bottleneck is the hard drive in many cases so starting
> concurrently might not speed up your boot process significantly.

Do you have any good references document this fact?  I've seen
articles documenting a speedup when things are started in parallell,
so I wounder where you got your information from.

http://initng.thinktux.net/index.php/Boot_charts_Official>
indicate that a sigificant speedup is possible, and I would really
love to speed up the debian boot sequence.


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

Re: TODO for etch ?

[Jon Dowland]

On Sun, Jun 19, 2005 at 04:16:28PM +0200, Petter Reinholdtsen wrote:
> [Adam Majer]
> > That could "save" a grand total of about a second. Also, during
> > startup the bottleneck is the hard drive in many cases so starting
> > concurrently might not speed up your boot process significantly.
> 
> Do you have any good references document this fact?  I've seen
> articles documenting a speedup when things are started in parallell,
> so I wounder where you got your information from.

I think the redhat people who are working on this are getting the most
benefit from a large disk read-ahead, prior to the main services being
started. If that accounted for the majority of speed-up, maybe it alone,
and not a fragile parallel boot process too, would be sufficient for
most people in need of a more efficient boot.

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


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

Re: Debian concordance

[Joey Hess]

Michael K. Edwards wrote:
> > No, Debian packages just work, if dpkg allows you to install them on
> > your system.
> > 
> > Unless, now, they happen to be built by someone running the other
> > distribution.
> 
> I can think of several ways that this could happen, but I haven't
> actually seen any of them yet.  Would you mind adducing some examples?

I haven't bothered to find them, but given what I'm hearing about the
glibc incompatabilities in this thread, I'm sure they exist, right?

> I agree with Joey that mucking with the actual packaging system (or
> even a very popular helper kit) is one of the more fork-like things
> that a derivative distro can do.  But this is certainly an area where
> sarge+hoary is no worse than woody+sid-after-twelve-months was; many
> backported source packages were broken in gross or subtle ways if you
> didn't start by building yourself an up-to-date debhelper.

However, debhelper is excessively careful to preserve backwards
compatability and when a package's build dependencies don't express
its need for a newer debhelper, we file a bug report.

> Here I can disagree from experience.  RPM hell is being unable to
> reproduce your vendor's binaries as a starting point for subsequent
> modifications (with or without third-party help), and it was already
> gaping wide as of Red Hat 5.2.

That is not how I've heard most users define the term. It's certianly a
valid problem.

> Ubuntu is the first Debian derivative not to be more or less a random
> sid snapshot plus the deriver's pet hacks. 

Well random sid/testing/stable snapshots.
With the exception of most CDDs; cf skolelinux, debian-edu, etc.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian concordance

[Joey Hess]

Matt Zimmerman wrote:
> I disagree, but again, I don't see your point

I think this sums up your entire response nicely, which is why I won't
reply to it point-by-point. You're not interested in trying to
understand these concerns, but you dismiss them out of hand. Fine.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian concordance

[Scott James Remnant]

On Sat, 2005-06-18 at 11:35 -0500, Ian Murdock wrote:

> "Debian packages just work" has been a truism for *years*, and it's been
> one of our key technical selling points. I don't want to see that fall
> by the wayside. This thread is a perfect example of what will happen
> if we don't worry about this stuff *now*. I've seen this movie before.
> 
Actually, this is a conceit that for some reason Debian Developers (who,
of course, only run Debian on their systems) still maintain while the
rest of the world believes the exact opposite.

Debian has had a long history of being hostile towards any attempt to
provide .debs that aren't in the archive, both socially and technically.

Walking up to a "man on the street", if anything, you'll find Debian has
a far worse reputation than RPM and RedHat-derived distributions.  The
general feeling is that third-party RPMs will almost always install on
any system, while third-party .debs are practically useless.

A definitive example would be the (eventually abandoned) attempt by
Ximian to provide debs for Helix GNOME.

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: TODO for etch ?

[John Hasler]

Adam Majer writes:
> The biggest problem is debugging. Sure, you can fork and start all of the
> processes concurrently, but what about if the start fails?

Then you restart with "--serial".

> You also want to have some processes started before others so you need
> asynchronous instead of synchronous waits...

Which is why you need dependencies.

> Alternatively, don't start Apache and Postgres on your workstation to
> save a second or two in the boot process.

I use Apache and PostgreSQL on my workstation.
-- 
John Hasler


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

Re: Debian concordance

[Joey Hess]

Scott James Remnant wrote:
> Walking up to a "man on the street", if anything, you'll find Debian has
> a far worse reputation than RPM and RedHat-derived distributions.  The
> general feeling is that third-party RPMs will almost always install on
> any system, while third-party .debs are practically useless.

That's strange, this is not the impression I've gotten from ten years of
reading the debian-user mailing list, participating in Linux and Debian
user groups, or hearing people discuss services such as backports.org
and apt-get.org, or from using them myself.

> A definitive example would be the (eventually abandoned) attempt by
> Ximian to provide debs for Helix GNOME.

Didn't that have more to do with it being experimental, rather flakey,
and conflicting badly with the gnome stuff in Debian?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Greylisting for @debian.org email, please

[Simon Richter]

Hi,

Frans Pop wrote:

> I think blocking mails based on an address being dynamic/static sucks.

Indeed, but the only systems that send out email from dynamic IP
addresses are spam zombies (90%[1]) and people who run their own MTA,
which again are divided into clueless idiots running an open relay (95%)
and otherwise clueful people who seem to believe that their ISPs MTA is
somehow unable to deliver their email (5%). Unless you have a very
braindead ISP, this is not true, in fact the ISP's mail server might
even be able to deliver it more efficiently as it may already know about
a particular server being down and which backup to use.

There is simply no point in running a mail server on a dynamic IP. It
will not be able to accept mail in a reliable way, even with dyndns, so
you need some other host to accept and forward your mail to you anyway,
so you can as well route it through a smarthost that you authenticate to
on the outbound way as well (this will have the added benefit of not
clogging up your connection if you need to send an email to multiple
people).

   Simon

[1] Numbers pulled entirely from where the sun don't shine, and based on
me reading 48h worth of mailer logs before deciding to block mail from
dynamic IPs.


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

Re: Greylisting for @debian.org email, please

[Thomas Bushnell BSG]

Simon Richter <[EMAIL PROTECTED]> writes:

> There is simply no point in running a mail server on a dynamic IP. It
> will not be able to accept mail in a reliable way, even with dyndns, so
> you need some other host to accept and forward your mail to you anyway,
> so you can as well route it through a smarthost that you authenticate to
> on the outbound way as well (this will have the added benefit of not
> clogging up your connection if you need to send an email to multiple
> people).

Would you define "dynamic IP" for me, just so I can be sure I know
what you're talking about?

It sounds here as if you mean an IP address which changes with some
frequency.  Is that right?

If so, lots of ISPs (mine, for example) give me a static IP address
via DHCP, in a block of addresses of which some are dynamic and some
are static.

Or have I guessed wrong and you mean something else?

Thomas



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

Re: Greylisting for @debian.org email, please

[Frans Pop]

On Sunday 19 June 2005 17:48, Simon Richter wrote:
> Hi,
>
> Frans Pop wrote:
> > I think blocking mails based on an address being dynamic/static
> > sucks.
>
> Indeed, but the only systems that send out email from dynamic IP
> addresses are spam zombies (90%[1]) and people who run their own MTA,

You are missing my point which was that you can not trust ISP's to 
properly designate an address as being dynamic/static, so blocking on 
that basis will also block people who actually _do_ have a static 
address.


pgpO4BwY1Wmzm.pgp
Description: PGP signature

Re: Debian concordance

[Scott James Remnant]

On Sun, 2005-06-19 at 11:42 -0400, Joey Hess wrote:

> Scott James Remnant wrote:
> > Walking up to a "man on the street", if anything, you'll find Debian has
> > a far worse reputation than RPM and RedHat-derived distributions.  The
> > general feeling is that third-party RPMs will almost always install on
> > any system, while third-party .debs are practically useless.
> 
> That's strange, this is not the impression I've gotten from ten years of
> reading the debian-user mailing list, participating in Linux and Debian
> user groups, or hearing people discuss services such as backports.org
> and apt-get.org, or from using them myself.
> 
Try hanging out outside of the immediate Debian community; I spend a
fair amount of time loitering around the GNOME and Freedesktop.org
communities, for example.  You see a wildly different picture there.

> > A definitive example would be the (eventually abandoned) attempt by
> > Ximian to provide debs for Helix GNOME.
> 
> Didn't that have more to do with it being experimental, rather flakey,
> and conflicting badly with the gnome stuff in Debian?
> 
The main problem they had was that they created the debs for potato, and
they were perfectly installable on that.  But Debian changed things
hugely in unstable, so they weren't installable there -- and then
introduced testing, making three incompatible systems.

It was impossible to create a single set of debs that would work on all
three (stable, testing, unstable) distributions of Debian at the same
time.


There are some fundamental technical problems with the way Debian does
things, and the way our software works, that makes deriving from Debian
or providing third-party debs very hard or impossible.  Unfortunately
Debian has a habit of blaming the derivative or third party for working
around these problems :-(

Let's use a popular example...  I make a package that
requires /usr/bin/bzgrep.

In Debian, I would have to read the debian/changelog for bzip2 and
discover that this wasn't introduced until 1.0.1-3, and thus
Depends: bzip2 (>= 1.0.1-3)

But in a Debian-derivative with a different release schedule (perhaps a
system used in Schools and sync'd on the start of a school year), that
might have been backported and added in 0.9.5d-3school1
Depends: bzip2 (>= 0.9.5d-3school1)

There's no way to express both of these relationships in the same binary
(as 1.0.1-2 would satisfy the relationship for the Debian-derivative).


In the RPM world, my package can simply depend on the
file /usr/bin/bzgrep existing.

Similar problems exist for shared libraries, I might need a symbol added
in a particular revision in one derivative and a different one in
another.


I don't disagree with, and in fact, I utterly support the idea that
Debian should be an excellent base for derivative distributions and
third-party packages.  I just don't think sarge is there, in fact, I
think sarge is about as far from that ideal as you can get.

We need social and technical changes to make Debian suitable as a
"standard base", I think we should do it and I think we _can_ do it.
But first Debian needs to stop blaming derivatives and third parties for
breaking compatibility, and instead ask what we did wrong that required
them to break compatibility in order to reach their goals.

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: Release Team meeting minutes - 2005-06-18

[Aurelien Jarno]

Andreas Barth a écrit :

release blockers:
- toolchain transition
- xorg
- sorting out docs-in-main vs. the DFSG
- SCC; amd64 as an official arch


So SCC is now a fact, not a proposal anymore?

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: Greylisting for @debian.org email, please

[Pierre Habouzit]

Le Dim 19 Juin 2005 18:14, Frans Pop a écrit :
> On Sunday 19 June 2005 17:48, Simon Richter wrote:
> > Hi,
> >
> > Frans Pop wrote:
> > > I think blocking mails based on an address being dynamic/static
> > > sucks.
> >
> > Indeed, but the only systems that send out email from dynamic IP
> > addresses are spam zombies (90%[1]) and people who run their own
> > MTA,
>
> You are missing my point which was that you can not trust ISP's to
> properly designate an address as being dynamic/static, so blocking on
> that basis will also block people who actually _do_ have a static
> address.

exactly. e.g. I have a static IP, given by my french ISP (free.fr aka 
proxad.net). they even give me the possibility (without more charges) 
to set the reverse DNS on that IP. you can check it, the corresponding 
DNS name is : olympe.madism.org :

[madcoder beacon] host olympe.madism.org
olympe.madism.org has address 82.225.205.10

[madcoder beacon] host 82.225.205.10
10.205.225.82.in-addr.arpa domain name pointer olympe.madism.org.

I know for sure that some rbls lists my IP as a dialup/dynamic IP 
address. which is wrong.


and the reason why I do have an SMTP server on that IP is that I don't 
like the methods used by french ISP wrt a matter of antispam and 
antivirus policies. I only trust my methods, since some tests I ran 
showed that they dropped a too large amount of mails pretending it was 
spam.

Though, I have configured my SMTP server to use smtp.free.fr (which is 
the SMTP server of my ISP) as the default route for my mail, since I've 
had too many problems wrt my IP. And believe me, it's *really* 
displeasing to be blacklisted as a dialup line.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpU4aRG5MIIC.pgp
Description: PGP signature

Re: Release Team meeting minutes - 2005-06-18

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [050619 18:27]:
> Andreas Barth a écrit :
> >release blockers:
> >- toolchain transition
> >- xorg
> >- sorting out docs-in-main vs. the DFSG
> >- SCC; amd64 as an official arch

> So SCC is now a fact, not a proposal anymore?

I hope you remember well that SCC=ports.d.o doesn't mean that some arch
will become a non-release-arch, but just that the mirrors are split into
full mirrors and "basic mirrors" that contain only the most often
downloaded architectures.

And it was said more than once that this is a pre-condition for adding
amd64 because of the size of the daily mirror push.


Cheers,
Andi


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

Re: Release Team meeting minutes - 2005-06-18

[Andreas Barth]

* Otavio Salvador ([EMAIL PROTECTED]) [050619 18:32]:
> > "aurelien" == Aurelien Jarno <[EMAIL PROTECTED]> writes:
> 
> aurelien> Andreas Barth a écrit :
> >> release blockers: - toolchain transition - xorg - sorting out
> >> docs-in-main vs. the DFSG - SCC; amd64 as an official arch
> 
> aurelien> So SCC is now a fact, not a proposal anymore?
> 
> I think this should have a vote for it.

You mean we should vote whether we provide infrastructure for some of
our mirrors to provide only the most often downloaded architectures or
not (without forcing them to that, so that any mirror can - by decision
of their admin - still carry all archs)? I hope you are kidding.


Cheers,
Andi

PS: BTW, debian-release is _not_ a discussion list. Please respect that.


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

Re: Release Team meeting minutes - 2005-06-18

[Otavio Salvador]

> "aurelien" == Aurelien Jarno <[EMAIL PROTECTED]> writes:

aurelien> Andreas Barth a écrit :
>> release blockers: - toolchain transition - xorg - sorting out
>> docs-in-main vs. the DFSG - SCC; amd64 as an official arch

aurelien> So SCC is now a fact, not a proposal anymore?

I think this should have a vote for it.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Bug#98549: employed

[Mildred]

prison
http://pcypcvyferfwa.ghjwatch.com/b3

Mildred

Re: Greylisting for @debian.org email, please

[Simon Richter]

Hi,

Thomas Bushnell BSG wrote:

>>There is simply no point in running a mail server on a dynamic IP.

> Would you define "dynamic IP" for me, just so I can be sure I know
> what you're talking about?

> It sounds here as if you mean an IP address which changes with some
> frequency.  Is that right?

Yes, even if said frequency is very low. If my ISP does not give me a
guarantee that when I reconnect I will get the same address again, and
that noone else is going to use that address, I consider it a dynamic IP.

> If so, lots of ISPs (mine, for example) give me a static IP address
> via DHCP, in a block of addresses of which some are dynamic and some
> are static.

Hrm, that would indeed be a reason to accept mail from some IPs inside
such "dynamic" blocks. Your IP does not seem to be listed as being
dynamic, though. :-)

OTOH, I think greylisting can help here, by applying it to hosts that
are listed as being dynamic. If the technology your ISP uses to connect
you to the internet is so strikingly similar to the technology used by
people who don't even care whether they have a fixed IP, I would assume
your bandwidth would not allow you to send amounts of mail that
greylisting would adversely affect you. :-)

   Simon


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

Re: Debian concordance

[Olaf van der Spek]

On 6/19/05, Scott James Remnant <[EMAIL PROTECTED]> wrote:
> Let's use a popular example...  I make a package that
> requires /usr/bin/bzgrep.
> 
> In Debian, I would have to read the debian/changelog for bzip2 and
> discover that this wasn't introduced until 1.0.1-3, and thus
>Depends: bzip2 (>= 1.0.1-3)
> 
> But in a Debian-derivative with a different release schedule (perhaps a
> system used in Schools and sync'd on the start of a school year), that
> might have been backported and added in 0.9.5d-3school1
>Depends: bzip2 (>= 0.9.5d-3school1)
> 
> There's no way to express both of these relationships in the same binary
> (as 1.0.1-2 would satisfy the relationship for the Debian-derivative).
> 
> 
> In the RPM world, my package can simply depend on the
> file /usr/bin/bzgrep existing.

What if you need a specific feature in or version of bzgrep?

Re: Greylisting for @debian.org email, please

[Josselin Mouette]

Le dimanche 19 juin 2005 à 18:39 +0200, Simon Richter a écrit :
> OTOH, I think greylisting can help here, by applying it to hosts that
> are listed as being dynamic. If the technology your ISP uses to connect
> you to the internet is so strikingly similar to the technology used by
> people who don't even care whether they have a fixed IP, I would assume
> your bandwidth would not allow you to send amounts of mail that
> greylisting would adversely affect you. :-)

Some ISPs in France provide a 1 Mbps upload bandwidth. Even with a
quarter of that, I'm relaying hundreds of emails each day, without any
noticeable impact on my connection. I wouldn't say that with such
characteristics, greylisting has no impact on my server.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Greylisting for @debian.org email, please

[Frans Pop]

On Sunday 19 June 2005 18:39, Simon Richter wrote:
> Hrm, that would indeed be a reason to accept mail from some IPs inside
> such "dynamic" blocks. Your IP does not seem to be listed as being
> dynamic, though. :-)

Try mine: 195.240.184.66
And yes, it is static and not "dynamic but unlikely to change rarely".

> OTOH, I think greylisting can help here, by applying it to hosts that
> are listed as being dynamic. If the technology your ISP uses to connect
> you to the internet is so strikingly similar to the technology used by
> people who don't even care whether they have a fixed IP, I would assume
> your bandwidth would not allow you to send amounts of mail that
> greylisting would adversely affect you. :-)

I started using my own mailserver because the one from my provider was 
down a lot for a while or not delivering within something like 8 hours 
(they seem to be better ATM).
Using my own server I would at least _know_ what was happening to my 
mails.

If I am blocked by something like SORBS when answering installation 
reports or something like that, I will sometimes resend a mail through my 
ISP, sometimes I just say "@[EMAIL PROTECTED]@ you, if you don't want to 
receive my 
mail, then don't".


pgpxaA8CP7ObW.pgp
Description: PGP signature

Re: Greylisting for @debian.org email, please

[Josselin Mouette]

Le dimanche 19 juin 2005 à 19:11 +0200, Frans Pop a écrit :
> If I am blocked by something like SORBS when answering installation 
> reports or something like that, I will sometimes resend a mail through my 
> ISP, sometimes I just say "@[EMAIL PROTECTED]@ you, if you don't want to 
> receive my 
> mail, then don't".

Gee, same reaction I suppose. I also have no regret in closing abruptly
bug reports opened by such clueless people.

The funniest thing I've seen was an email blocked when it went through
my ISP, recorded as a spam source, and not blocked when going through my
home server.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Debian concordance

[Russ Allbery]

Scott James Remnant <[EMAIL PROTECTED]> writes:
> On Sat, 2005-06-18 at 11:35 -0500, Ian Murdock wrote:

>> "Debian packages just work" has been a truism for *years*, and it's
>> been one of our key technical selling points. I don't want to see that
>> fall by the wayside. This thread is a perfect example of what will
>> happen if we don't worry about this stuff *now*. I've seen this movie
>> before.

> Actually, this is a conceit that for some reason Debian Developers (who,
> of course, only run Debian on their systems) still maintain while the
> rest of the world believes the exact opposite.

> Debian has had a long history of being hostile towards any attempt to
> provide .debs that aren't in the archive, both socially and technically.

Er, huh?  I got started with Debian packaging by providing an extensive
set of local .debs for Stanford internal use for quite some time before I
started getting them into the base archive.  Everything just worked.  Not
only did everything just work, but it was *significantly* easier to set
this up and make it work properly with Debian than with Red Hat.

> Walking up to a "man on the street", if anything, you'll find Debian has
> a far worse reputation than RPM and RedHat-derived distributions.  The
> general feeling is that third-party RPMs will almost always install on
> any system, while third-party .debs are practically useless.

This is, to me, an utterly bizarre statement.  My personal experience
could not possibly be more completely opposite to this.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Release Team meeting minutes - 2005-06-18

[Otavio Salvador]

> "andreas" == Andreas Barth <[EMAIL PROTECTED]> writes:

andreas> * Otavio Salvador ([EMAIL PROTECTED]) [050619 18:32]:
>> > "aurelien" == Aurelien Jarno <[EMAIL PROTECTED]>
>> writes:
>> 
aurelien> Andreas Barth a écrit :
>> >> release blockers: - toolchain transition - xorg - sorting
>> out >> docs-in-main vs. the DFSG - SCC; amd64 as an official
>> arch
>> 
aurelien> So SCC is now a fact, not a proposal anymore?
>>  I think this should have a vote for it.

andreas> You mean we should vote whether we provide infrastructure
andreas> for some of our mirrors to provide only the most often
andreas> downloaded architectures or not (without forcing them to
andreas> that, so that any mirror can - by decision of their admin
andreas> - still carry all archs)? I hope you are kidding.

I confused it with Vancover proposal, sorry.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: Debian concordance

[Russ Allbery]

Scott James Remnant <[EMAIL PROTECTED]> writes:

> The main problem they had was that they created the debs for potato, and
> they were perfectly installable on that.  But Debian changed things
> hugely in unstable, so they weren't installable there -- and then
> introduced testing, making three incompatible systems.

> It was impossible to create a single set of debs that would work on all
> three (stable, testing, unstable) distributions of Debian at the same
> time.

So build three sets of .debs.  I'm not sure why people would consider that
so hard?  Debian provides a ton of excellent tools to help you do exactly
that.  You have to learn pbuilder and set up a couple of chroots, which
while sounding intimidating is actually a matter of a couple of hours work
to produce an environment that will then serve you well for years and is
quite easy to maintain.

Certainly you're not arguing that one never has to build multiple RPMs,
are you?  Most software I use that provides RPMs has multiple variants for
similar reasons (one for Fedora, one for RHEL3, one for RHEL4, etc.).

> Let's use a popular example...  I make a package that
> requires /usr/bin/bzgrep.

> In Debian, I would have to read the debian/changelog for bzip2 and
> discover that this wasn't introduced until 1.0.1-3, and thus
>   Depends: bzip2 (>= 1.0.1-3)

> But in a Debian-derivative with a different release schedule (perhaps a
> system used in Schools and sync'd on the start of a school year), that
> might have been backported and added in 0.9.5d-3school1
>   Depends: bzip2 (>= 0.9.5d-3school1)

> There's no way to express both of these relationships in the same binary
> (as 1.0.1-2 would satisfy the relationship for the Debian-derivative).

This seems like an extremely artificial example.  Why would the school
distribution backport a new feature to a release that's supposed to be
extremely stable?

> In the RPM world, my package can simply depend on the file
> /usr/bin/bzgrep existing.

I can see the merits of this feature in some circumstances (among other
things, it means not having to work out the alternative packages that
supply a particular binary and don't provide a virtual package).  I
wouldn't object if someone found a way to make it work well with Debian.
You still will need to list what package to install to get that file if
you don't already have it, though; I really don't like the idea of apt-get
using apt-file to try to guess at what package to install to satisfy the
dependency.

RPM used to use this mechanism for libraries as well; I sure hope you're
not proposing that, as Debian's method is far, far more reliable.

> We need social and technical changes to make Debian suitable as a
> "standard base", I think we should do it and I think we _can_ do it.
> But first Debian needs to stop blaming derivatives and third parties for
> breaking compatibility, and instead ask what we did wrong that required
> them to break compatibility in order to reach their goals.

Well, this I can mostly agree with, since I don't think blame is usually
the right way to approach these sorts of things.  I'm not sure that blame
is really what's going on so much as concern, and I do think the concern
is warranted.  Certainly, if there are infrastructure improvements that
Debian can make without sacrificing its quality that make it easier for
derivative distributions to not diverge, I'm all in favor of that and will
help as much as I can.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

schroot: a replacement for dchroot

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

Over the last week or so, after wanting features that dchroot didn't
provide, I've written a replacement: schroot.  This is mostly
command-line compatible with dchroot, but provides additional
functionality, such as su/sudo-like behaviour:

- - access restricted by group
- - ability to switch user id
- - passwordless root for authorised groups
- - tighter security checks than dchroot
- - PAM authentication and authorisation
- - Full logging of chroot operations

It was mainly written as a replacement for sudo in sbuild, but has
more general uses than that.  If you have chroots, and currently use
dchroot, you might like to give schroot a try.

If there are any security and/or PAM experts here, I would be grateful
if you could spare a few minutes to check the code.  I'm pretty sure
it's fine, but it's the first PAM-based program I've written, and
there may be subtleties I've missed.


http://people.debian.org/~rleigh/schroot/
(packages and original source)

I won't upload this as a standalone package yet, in case the sbuild
maintainers would like it as part of sbuild CVS and packaging.

Comments welcome!


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCta79VcFcaSW/uEgRAlBCAJ9FWuujVVc+kPWLc8APrz2TdnUYBgCg4tER
FV1lHOGUUBc6i7vqVuaU4Ic=
=AHI4
-END PGP SIGNATURE-


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

Re: Debian concordance

[Matt Zimmerman]

On Sun, Jun 19, 2005 at 11:13:31AM -0400, Joey Hess wrote:

> Michael K. Edwards wrote:
> > I can think of several ways that this could happen, but I haven't
> > actually seen any of them yet.  Would you mind adducing some examples?
> 
> I haven't bothered to find them, but given what I'm hearing about the
> glibc incompatabilities in this thread, I'm sure they exist, right?

I've responded in depth regarding the glibc situation elsewhere in this
thread, and there has never been any more to it than shlibdeps.  There have
been no reports whatsoever of mysterious silent breakage, contrary to your
earlier implication.

-- 
 - mdz


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

Bug#78782: spun

[Rosanne]

grimm
http://gvozclisgcz.ghjwatch.com/b3

Rosanne

Re: Greylisting for @debian.org email, please

[Thomas Bushnell BSG]

Simon Richter <[EMAIL PROTECTED]> writes:

> Yes, even if said frequency is very low. If my ISP does not give me a
> guarantee that when I reconnect I will get the same address again, and
> that noone else is going to use that address, I consider it a dynamic IP.

>> If so, lots of ISPs (mine, for example) give me a static IP address
>> via DHCP, in a block of addresses of which some are dynamic and some
>> are static.
>
> Hrm, that would indeed be a reason to accept mail from some IPs inside
> such "dynamic" blocks. Your IP does not seem to be listed as being
> dynamic, though. :-)

So my IP address, which my ISP promises will always be the same, and
is initialized by DHCP, is static.  But most of the IP addresses in
the block are handed out dynamically.  How will you be able to tell?


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

Bug#314969: ITP: dklibs -- dirk krause's libraries

[David Moreno Garza]

Package: wnpp
Severity: wishlist
Owner: David Moreno Garza <[EMAIL PROTECTED]>


* Package name: dklibs
  Version : 1.7.5
  Upstream Author : Dirk Krause
* URL : http://dklibs.sourceforge.net
* License : BSD
  Description : dirk krause's libraries

The following libraries are available:
  dkport  Portability layer.
 dkc  General purpose C functions.
   dkapp  Command line application support (includes logging,
  localization and preferences management).
   dknet  Portable client-side TCP/IP networking.
.
Additionally there are the following programs:
 stc  String table compiler, converts text string table sources into binary 
string table files.
 tracecc  Tracing preprocessor for C, C++, Objective-C and Java.
   trana  Trace output analyzer.

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


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

Rolex is not for everyone, it`s for you Alan

[Jan Baker]

Hello,
Thank you for expressing interest in Rolex Replica watches.
This opportunity to offer you our fine selection 
of Italian/Swiss crafted Rolex Timepieces.
You can view our large selection of Rolexes 
(including Breitling, Tag Heuer, Cartier etc)

You are guaranteed of lowest prices and highest 
quality each and every time you purchase from us.
 
Please do not hesitate to visit our website at

http://www.chooseyourwatch4u.net

I certainly look forward to hearing from you.
Thanks and Best regards,

Jan Baker
Sales Manager
Rolex Watches Enterprises










cody pgi rupture neo sproul htr diversionary cu buckwheat zq rumford fy 
device zkl pyroelectric py bindery ssa chevy evs 


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

Re: TODO for etch ?

[Marc Haber]

On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
<[EMAIL PROTECTED]> wrote:
>That could "save" a grand total of about a second.

It will save time in case of error when the bootup process stalls for
timeouts like DNS and NTP.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Minutes of Debian Installer IRC meeting of 20050618

[Christian Perrier]

(also see http://wiki.debian.net/?DebianInstallerMeetings)


The fourth Debian Installer team meeting was held from 14:00UTC to 15:37UTC
on Saturday June 18th.

This was the first D-I team meeting since we had a pre-release meeting
at the end of July 2004, before releasing sarge Debian Installer RC1.

There were about 60 people connected to the channel during the meeting
and 20 of them spoke during the meeting at least once.

The full log of the meeting is available at
http://people.debian.org/~bubulle/d-i/irc-meeting-20050618/log

D-I release management
--

Joey Hess announces his plan to share the "control" of D-I release
management. Frans Pop will begin to work along with Joey for the next
release of the etch installer and will manage the release of the next
version.

The goal is to have a first release of d-i ready for the end of July :
there are enough post-sarge features ready for wider tests.

This needs a revival of the CD builds which should soon happen.

The details of the content for this first beta release should be
discussed in a specific meeting at the very beginning of July.


sarge D-I release management


The whole team agrees that keeping the sarge version of d-i alive is
needed but plans are still quite vague about how to achieve this.

Colin Watson mentioned his interest in keeping the sarge installer
alive and help in managing "point" releases.

The amount of needed effort depends however whether the sarge installer
is stuck with the 2.6.8 kernel or not. Strict application of the
current stable release management rules mandate this, but there's a
general feeling among the team that using etch kernels for this would
help a lot.

The ability to install the Debian *stable* release on recent hardware
is a corner stone for the Debian project (and some derived
distributions such as Skolelinux). This will require updated drivers
and newer kernels in sarge, which in turn may also help solving important
issues with *current* hardware such as better SATA support and better
cdrom drives detection.

All participants agree that these "point" release of the sarge
installer must be coordinated with Joey Schulze, the stable release
manager.

It is also mentioned that efforts will be made to keep the etch
installer able to install sarge (just like the sarge installer was
kept able to install woody), even if there's still the problem of
where it gets the kernels debs from.

That issue is actually not completely solved and we may fall short of
manpower to really be able to manage these releases, unless new
volunteers show up. Several points also depend on discussion with the
stable release manager. A dedicated mini-meeting with him might be
worth setting up. Christian proposed to organise this.


How to get development ramped back up and attract and re-attact more developers
---

The lack of active porters for some arches is quickly raised (this
comes quite close from the Vancouver proposal. Let's rephrase : the
d-i team feels it cannot maintain d-i for arches if noone from these
arches porters works with the d-i team to keep the etch installer
alive).


Some timely schedule for providing kernel, by the kernel team, could
probably help a lot on that issue.

Another raised problem is the lack of visible maintenance for some
parts of d-i : kbd-chooser, partman are mentioned but there may be
others. The main point seems to be that we have problems identifying
people "repsponsible" for the packages/udebs. Theoretically, the
"Uploaders" field of the package should tell us so, but several are
outdated, mentioning people not really currently active.

Frans Pop volunteered to realise a summary of all "responsible" persons
for d-i packages. This would help tracking down problems when they
arise. Some of these should probably be contacted to know whether they
intend to continue their work.

Another raised problem is the traffic in the debian-boot mailing
list. A general consensus raises that directing bug reports and all
administrivia messages to a dedicated mailing list would be
better. Christian volunteered to request for this list creation and
Colin will then do a mass override until packages are re-uploaded with
the correct information.

A suggestion is made to CC the adresses mentioned in the "Uploaders"
field of udeb packages control file to these bug reports.

During the discussion, a mailing list for commits is mentioned.
[EMAIL PROTECTED] is mentioned to work for
this but a dedicated ML would be better. Here again, Christian will
handle the list creation. Then all commit mails will be directed over
there.

The discussion then derived on installation reports (we will keep them
in -boot at first), the need to process them (and the changes that
could help doing so). Several features are under work such as
automated inclusion of logfiles.

Coordinating changes


The i

Re: Greylisting for @debian.org email, please

[Glenn Maynard]

On Sat, Jun 18, 2005 at 03:13:27PM -0700, Thomas Bushnell BSG wrote:
> Steve Kemp <[EMAIL PROTECTED]> writes:
> 
> >   Choosing not to use greylisting because it causes mail to become
> >  non-realtime is *not* a valid complaint.  Which is the point I was
> >  trying to make in a roundabout fashion.
> 
> People are not using "realtime" in its technical sense here.  They are
> using it to mean "as fast as possible".

Of course.  I expect mail, when properly configured at both ends, to
arrive quickly; it's extremely common for me to be holding a conversation
on some other medium (IRC, telephone), to have them mail me something,
and for us to sit around for all of five seconds before I have the mail
and we continue what we're doing.  That's very common and quite reliable.
The core of his argument appears to be "well, I don't care about that, so
you shouldn't either", and that's incredibly unconvincing.

(I don't care about @debian.org mail per se; I care about the fact that
Debian acts as a role model in the community, and Debian's practices will
directly affect those of others.  Ignoring this fact is extremely 
irresponsible.)

-- 
Glenn Maynard


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

Mass bug-filing: slang2

[Alastair McKinstry]

Hi,

Thanks to prompt action by the ftp-masters, the recently released slang2
is now in the archive. This mail is a request for maintainers of
packages that use slang1 to recompile and test their packages against
slang2; I intend to file patches against such packages over the next few
days, barring objections.

As slang is a required package, it would be good to complete this
transition promptly and not have both versions in base, hence the bug
filing. It would be especially good to have the changeover made in time
for the planned release of the first debian-installer candidate for
Etch, at the end of July.

According to apt-cache, the affected packages are:

aalib
asc
asciijump
aview
avifile
bb
cfdisk-utf8
drip
francine
freej
fte
gcompris
gnome-lokkit
gst-plugins
gst-plugins0.8
jed
kdeaddons
libcaca
libdv
libterm-slang-perl
lpe
most
nano
newt
partimage
pdmenu
pinball
python-slang
slang
slmon
slrn
slsc
tasksel
ticker
timidity
util-linux
vlc
xaos
xawtv
xine-lib
xine-ui

(Please report any errors or omissions in the list). 
slang2 has full UTF8 support, replacing the split UTF8 / non-UTF8
libslang1 libraries; please test UTF8 support of your package. (Note:
the current version of slang2 in the archive does not have fribidi
support yet; I am porting that patch from slang1 forward to 2.0.4, the
next release of slang2 due out this weekend).

Regards
Alastair McKinstry


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

Bug#53121: phenol

[Helene]

cigar
http://whywaitlonger.com/cams3.php?SEVY

Helene

Re: TODO for etch ?

[Florian Weimer]

* Marc Haber:

> On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
> <[EMAIL PROTECTED]> wrote:
>>That could "save" a grand total of about a second.
>
> It will save time in case of error when the bootup process stalls for
> timeouts like DNS and NTP.

You should set the clock using NTP *before* starting any daemons.
Most daemons don't use monotonic clocks (I'm not even sure if Linux
supports them at the required level), and some of them fail in strange
ways if the system clock warps.


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

Re: Release Team meeting minutes - 2005-06-18

[Goswin von Brederlow]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> Andreas Barth a écrit :
>> release blockers:
>> - toolchain transition
>> - xorg
>> - sorting out docs-in-main vs. the DFSG
>> - SCC; amd64 as an official arch
>
> So SCC is now a fact, not a proposal anymore?

SCC as in forcing primary mirrors to carry only selective archs is a
fact. A neccessity.

The remaining 99% of the vancouver proposal are very much unclear
though and I sure as hell hope get some more discussion and change.

Not wearing any hat and not being in any way relevant,
Goswin


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

Re: TODO for etch ?

[Steve Langasek]

On Sun, Jun 19, 2005 at 04:04:24PM +0100, Jon Dowland wrote:
> On Sun, Jun 19, 2005 at 04:16:28PM +0200, Petter Reinholdtsen wrote:
> > [Adam Majer]
> > > That could "save" a grand total of about a second. Also, during
> > > startup the bottleneck is the hard drive in many cases so starting
> > > concurrently might not speed up your boot process significantly.

> > Do you have any good references document this fact?  I've seen
> > articles documenting a speedup when things are started in parallell,
> > so I wounder where you got your information from.

> I think the redhat people who are working on this are getting the most
> benefit from a large disk read-ahead, prior to the main services being
> started. If that accounted for the majority of speed-up, maybe it alone,
> and not a fragile parallel boot process too, would be sufficient for
> most people in need of a more efficient boot.

The boot process is already fragile.  The strict ordering of boot scripts
means that any changes to the rank of one script will cause ripple effects
affecting any other scripts depending on it, which may go undetected for
long periods of time; and the available update-rc.d interface makes it more
or less impossible to automatically correct a wrongly-ordered startup script
without either losing local configuration or failing to handle systems that
don't use sysv-rc.

Switching to a sound dependency-based init system would solve the above, and
let people experiment with parallel startup or not, as they want.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Testing package installation, upgrading, and removal

[Goswin von Brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> Lars Wirzenius wrote:
>> Frank Lichtenheld and others have brought up the idea of automatically
>> testing installation, upgrading, and removal of packages. It struck me
>> that it should be pretty simple to implement at least basic versions of
>> this. The result: http://liw.iki.fi/liw/download/piuparts-0.4.tar.gz
>> 
>> I have attached the manual page.
>> 
>> The current version is quite simplistic. It may well be too simplistic
>> to work for more than in simple cases, but it's a start.
>> 
>> I'd be very curious to hear about suggestions for improvements.
>
> I want to run a test that installs each package in woody in turn,
> upgrades them to sarge, then to sid, then purges it, then looks for
> /usr/doc and /usr/info stuff that is were produced during the package's
> install or upgrade and not removed.

Good idea. Things like that should be collected for the etch Release
to cover all major changes that are release goals. Another thing would
be to check if anything links against an old C++ abi and so on.

A more general test would be to install/upgrade/purge a package and
then report any changes in the chroot.

>>If the package is known to apt-cache, piuparts  also  does  an  
>> upgrade
>>test,  where  it  first   installs  the  package  with apt-get, 
>> and then
>>installs from the package files given on the command line, and  
>> finally
>>removes   and  purges  everything that got installed.  The 
>> assumption is
>>that the version apt-get finds is older   than  the  package  
>> file.  The
>>upgrade test is not performed if -a is used.
>
> I think this can not quite do it, since the chroot will need to be a
> woody chroot but get at least partially upgraded in each test to allow
> installation of the sarge and sid packages. It looks like piuparts is
> otherwise close to the tool I need.

Create a lvm logical volume of a clean chroot. Make a snapshot of it,
mount proc, do the test, kill (and probably report) any residual
processes, umopunt proc, kill snapshot.

Using lvm is the fastest way to do this. Alternatives are to copy or
untar a clean chroot for every test. But that needs more time.

MfG
Goswin


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

Little magic. Perfect weekends.

[Harriet]

Having problems in bed? We can help!
http://presenting.powerinfoonline.info/?tightenxtvuypistolszsvsmokers


He that boasts of his own knowledge proclaims his ignorance   
Hell, there are no rules here-- we're trying to accomplish something.  
Spring makes everything look filthy.
Change your thoughts and you change your world. 




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

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* Michael K. Edwards ([EMAIL PROTECTED]) wrote:
> On 6/17/05, Eric Dorland <[EMAIL PROTECTED]> wrote:
> > * John Hasler ([EMAIL PROTECTED]) wrote:
> > > Exactly.  If Debian doesn't need such an arrangement, neither do our 
> > > users.
> > > And if our users don't need such an arrangement, our accepting it does not
> > > put us in a privileged position with respect to them: they have the legal
> > > right to do everything that we want to do with or without permission.
> > >
> > > So let's accept the "arrangement" and move on.  There is no DFSG problem
> > > here even if we do accept the notion that the DFSG applies to trademarks.
> > 
> > If we don't need the "arragement", why exactly would we accept it
> > anyway?
> 
> I wouldn't say "accept" it, I would say "acknowledge" the safety zone
> offered unilaterally by the Mozilla Foundation, and as a courtesy to
> them make some effort to stay comfortably within it while continuing
> to ship under the Mozilla names.  Their trademark policy is surely
> less draconian than, say, Red Hat's, and we aren't going around
> purging the RedHat Package Manager from Debian.

I think you're playing word games now. Even if this is a unilateral
"gift" we still need to decide if we want it or not. 

> If the offer from six months ago still stands (which, to my
> recollection and in my non-lawyer view, read like a unilateral "safety
> zone" rather than a trademark license as such), that's extraordinarily
> accommodating on MoFo's part.  It's a square deal from people with a
> pretty good reputation for square deals.  They deserve better from
> Debian than to have their flagship products obscured by a rename when
> they haven't done anything nasty to anyone yet.

What reputation are you referring to? Not that I necessarily disagree,
but what are you basing that assessment on? 
 
> The FSF has, at best, completely failed to offer leadership with
> respect to free software and trademarks, as the MySQL case and the Red
> Hat / UnixCD mess have shown.  I think it would be rather gratifying
> if Debian could step in to fill the void.  And it would be kind of
> nice to have a workable modus vivendi to exhibit if and when the Linux
> Mark Institute (or the OpenSSL team or the PHP folks or Red Hat or
> MySQL) comes knocking.

I do have to agree that guidance when it comes to trademark situations
is sorely lacking. There doesn't seem to be that consistent a
viewpoint with Debian either unfortunately. 

-- 
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: Testing package installation, upgrading, and removal

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Using lvm is the fastest way to do this. Alternatives are to copy or
> untar a clean chroot for every test. But that needs more time.

You can also use a loopback file and make a copy of it. Or use UML.

Gruss
Bernd


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

Re: Debian concordance

[Steve Langasek]

On Sun, Jun 19, 2005 at 01:41:47AM -0700, Michael K. Edwards wrote:
> On 6/19/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Of 596 "lib" packages in woody (loosely identified), 325 are still
> > present in sarge.  That's after three years of more or less constant
> > development.  Where did you come up with this absurd idea that all binary
> > packages "of any great complexity" will become uninstallable after only six
> > *months*?

> The examples that come to mind immediately are those with substantial
> components in both native code and an interpreted or bytecode
> language, such as Perl XSUBs and Python extensions.

Yes, these are specific examples of packages that will be rendered
uninstallable in unstable by an ABI change on a particular package.  Your
claim was that *all* packages "of any great complexity" would be
uninstallable after six months.

And while perl XSUBs from woody are not installable in sarge, python
extensions from woody *are* generally installable in sarge (for reasons we
shouldn't be particularly proud of, but still).

> And what are the odds of my tweaked Python profiler, built to divert
> individual files within the Python library tree, working with sid's stock
> Python build come December?

A pathological case if ever I heard one...

> The next example to pop into my head is the Midgard content management
> framework, which involves both an Apache module and piles of PHP code.
>  The chances of a binary package built on sarge installing (let alone
> working) against next year's apache and php packages in sid probably
> aren't that high.

Which still doesn't prove a claim that *no* packages will be installable
after six months.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Minutes of Debian Installer IRC meeting of 20050618

[Marco d'Itri]

On Jun 19, Christian Perrier <[EMAIL PROTECTED]> wrote:

> The amount of needed effort depends however whether the sarge installer
> is stuck with the 2.6.8 kernel or not. Strict application of the
> current stable release management rules mandate this, but there's a
> general feeling among the team that using etch kernels for this would
> help a lot.
This may not be so easy, e.g. kernels >= 2.6.12 need a more recent
version of udev than the one in sarge (and currently in sid too).

> It becomes obvious that maintaining the 2.4 compatibility may become
> harder and harder. This is however a key point if we want to keep the
> etch installer able to install sarge.
Why? sarge as is supports 2.6 kernels up to 2.6.11.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Orphaning packages

[Goswin von Brederlow]

Nigel Jones <[EMAIL PROTECTED]> writes:

> On 19/06/05, Ivo Timmermans <[EMAIL PROTECTED]> wrote:
>> Hi,
>> 
>> I'm orphaning these packages:
>> 
>>   dvorak7min (bug #314844)
> I have interest in this, I really liked using this program

Please do. I always wanted to use this excessively for a while and
finaly switch over to it.

You should probably expand it to cover different keyboard layouts to
make it usefull to everyone though.

MfG
Goswin


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

Re: Planet Debian and Akregator

[Adeodato Simó]

* Marc Haber [Thu, 09 Jun 2005 07:13:45 +0200]:

> as we all know, Planet Debian generates RSS feeds that Akregator
> doesn't grok, and both packages point at the other one for being at
> fault.

  Mako fixed this today. Thanks!

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Experience is something you don't get until just after you need it.


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

Re: Mozilla Foundation Trademarks

[Michael K. Edwards]

On 6/19/05, Eric Dorland <[EMAIL PROTECTED]> wrote:
> * Michael K. Edwards ([EMAIL PROTECTED]) wrote:
> > I wouldn't say "accept" it, I would say "acknowledge" the safety zone
> > offered unilaterally by the Mozilla Foundation, and as a courtesy to
> > them make some effort to stay comfortably within it while continuing
> > to ship under the Mozilla names.  Their trademark policy is surely
> > less draconian than, say, Red Hat's, and we aren't going around
> > purging the RedHat Package Manager from Debian.
> 
> I think you're playing word games now. Even if this is a unilateral
> "gift" we still need to decide if we want it or not.

Of course; and as the maintainer, you are going to be the one making
that call.  I'm just chary of using words like "offer" and "accept"
because they suggest that we are in the contract zone.  I think (I
could be wrong; IANAL) that, in the free software arena, it's actually
better for both sides for the trademark holder to say:

"We aren't exactly licensing all and sundry to manufacture products
under our brand.  Our product line includes both the source code and
the 'official' binaries; we are of the opinion that third parties who
follow these guidelines when building and distributing their own
binaries are merely re-packaging our source code product (under
standards like Coty v. Prestonettes in the US and X, Y, and Z
elsewhere) and using our trademarks descriptively.

"We reserve the right to decide unilaterally that someone either has
created a product of their own (to which our trademark can't be
applied without license) or isn't doing an adequate job of QA in the
course of re-packaging.  But if and when that happens, we're going to
follow the steps outlined here to try to bring them into voluntary
compliance before we demand that they either accept a formal license
and traditional oversight procedures or cease to apply our trademarks
to their modified version of our product."

>From what I've read, that's as open a policy as a trademark holder can
offer and still retain control of the trademark in the long run.  I
may be overstating here how far the Mozilla Foundation is willing to
go; but if a modus vivendi can be reached in which the only thing
special about Debian is that the guidelines more or less reflect the
maintainer's actual practice, I think that sits more comfortably with
DFSG #8 than a license per se.

> > If the offer from six months ago still stands (which, to my
> > recollection and in my non-lawyer view, read like a unilateral "safety
> > zone" rather than a trademark license as such), that's extraordinarily
> > accommodating on MoFo's part.  It's a square deal from people with a
> > pretty good reputation for square deals.  They deserve better from
> > Debian than to have their flagship products obscured by a rename when
> > they haven't done anything nasty to anyone yet.
> 
> What reputation are you referring to? Not that I necessarily disagree,
> but what are you basing that assessment on?

Their rebranding isn't special for Netscape/AOL and other corporate
partners; they've worked very hard to make it accessible to third
parties without any need for explicit cooperation with them.  They're
going through the agony of relicensing their entire code base under
MPL/LGPL/GPL so that GPL projects can cherry-pick at source code
level.  They're good citizens in W3C standards space even when the
committee decisions go against them (e. g., XUL vs. XForms).  I don't
know the details of their CA certificate handling, but at least they
_have_ a policy and respond constructively to criticism of it.  And
Mitch Kapor and the rest of the MoFo board have a lot of street cred
as individuals.

> > The FSF has, at best, completely failed to offer leadership with
> > respect to free software and trademarks, as the MySQL case and the Red
> > Hat / UnixCD mess have shown.  I think it would be rather gratifying
> > if Debian could step in to fill the void.  And it would be kind of
> > nice to have a workable modus vivendi to exhibit if and when the Linux
> > Mark Institute (or the OpenSSL team or the PHP folks or Red Hat or
> > MySQL) comes knocking.
> 
> I do have to agree that guidance when it comes to trademark situations
> is sorely lacking. There doesn't seem to be that consistent a
> viewpoint with Debian either unfortunately.

It's a sticky wicket.  Free software enthusiasts (among whom I count
myself) don't like systems that exacerbate second-class-citizenship
among those whose motivations aren't principally commercial.  Nowadays
everyone's a publisher, and the paperwork overhead of copyright has
dropped near to zero (until you try to enforce it); but not everyone
is a marketer, and that's what trademarks are about.  I think it's
possible to have a personal-freedom-compatible trademark policy, but
it's not trivial, and the first few tries are bound to have their
discontents.  Doesn't mean it's not worth trying, though.

Cheers,
- Michael
(IANADD, IANAL)

Re: Debian concordance

[Michael K. Edwards]

On 6/19/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 19, 2005 at 01:41:47AM -0700, Michael K. Edwards wrote:
> > The examples that come to mind immediately are those with substantial
> > components in both native code and an interpreted or bytecode
> > language, such as Perl XSUBs and Python extensions.
> 
> Yes, these are specific examples of packages that will be rendered
> uninstallable in unstable by an ABI change on a particular package.  Your
> claim was that *all* packages "of any great complexity" would be
> uninstallable after six months.

Perhaps that reflects my idea of what constitutes "any great
complexity" -- a high-level implementation language plus some glue and
accelerators in C/C++, maybe a GUI library or two, maybe a module for
a separately packaged daemon.  I also wrote "without a stack of
'oldlibs'" -- and even packages whose dependencies are completely
captured by ldd on a few binaries are going to be in that boat real
soon now.

> And while perl XSUBs from woody are not installable in sarge, python
> extensions from woody *are* generally installable in sarge (for reasons we
> shouldn't be particularly proud of, but still).

OK; but a program that makes use of them probably doesn't work unless
it was future-proofed in advance by systematically avoiding references
to "python" without an explicit version.  And anything that uses, say,
woody's libwxbase2.2 is out of luck.  And python-gdbm isn't the
version built against python 2.1 anymore, so packages built against it
will have the wrong dependencies for sarge.  And so on and so forth.

> > And what are the odds of my tweaked Python profiler, built to divert
> > individual files within the Python library tree, working with sid's stock
> > Python build come December?
> 
> A pathological case if ever I heard one...

Maybe so; but then all efforts to use the packaging system to update
bits of a language's standard library, without rebuilding (and taking
security update responsibility for) the whole shebang, are equally
pathological.  That would apply to large fractions of CPAN and CTAN
and many emacs modes as well as local customizations like my
experimental profiler.

> > The next example to pop into my head is the Midgard content management
> > framework, which involves both an Apache module and piles of PHP code.
> >  The chances of a binary package built on sarge installing (let alone
> > working) against next year's apache and php packages in sid probably
> > aren't that high.
> 
> Which still doesn't prove a claim that *no* packages will be installable
> after six months.

What I said was:

After six months, I suspect that sid will have evolved to where no
binary package of any great complexity from sarge will install on it
without a stack of "oldlibs"; and backports will be (as usual) a royal
pain.  Better just to run a carefully selected sid snapshot.  Test
your backups frequently, though.  :-)

Would you settle for "few binary packages of any great complexity", etc.?

Cheers,
- Michael

Re: Orphaning packages

[Nigel Jones]

CC'ing this to correct bug number.

Ivo (from offlist email), yeah, if you read my update to that bug # i
said i posted it to the wrong one.  (i actually reposted to
314844-quiet).  I'm also going to have a big think about that other
package too.

On 20/06/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Nigel Jones <[EMAIL PROTECTED]> writes:
> 
> > On 19/06/05, Ivo Timmermans <[EMAIL PROTECTED]> wrote:
> >> Hi,
> >>
> >> I'm orphaning these packages:
> >>
> >>   dvorak7min (bug #314844)
> > I have interest in this, I really liked using this program
> 
> Please do. I always wanted to use this excessively for a while and
> finaly switch over to it.
> 
> You should probably expand it to cover different keyboard layouts to
> make it usefull to everyone though.
Yeah thats possible i *THINK*
> 
> MfG
> Goswin
> 


-- 
N Jones
Blogging @ http://nigelj.blogspot.com
Proud Debian & FOSS User
Debian Maintainer of: html2ps & ipkungfu

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* John Hasler ([EMAIL PROTECTED]) wrote:
> Eric Dorland writes:
> > If we don't need the "arrangement", why exactly would we accept it
> > anyway?
> 
> Because they want it and it costs us nothing to give it to them.  They are
> our friends.  Let's accommodate them where we can.

We may be their friends, but that shouldn't give us special
privileges. 

Friendship is really not a valid justification to do something in this
context.

-- 
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: TODO for etch ?

[Marc Haber]

On Sun, 19 Jun 2005 23:22:01 +0200, Florian Weimer <[EMAIL PROTECTED]>
wrote:
>* Marc Haber:
>> On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
>> <[EMAIL PROTECTED]> wrote:
>>>That could "save" a grand total of about a second.
>>
>> It will save time in case of error when the bootup process stalls for
>> timeouts like DNS and NTP.
>
>You should set the clock using NTP *before* starting any daemons.

This is a _should_, but there are situations where this is not
possible. A common case where ntp is not available at startup (and the
timeout delay _not_ appreciated) is when a complete machine park at an
ISP was shutdown (for example during move, power works or an
emergency) and is now re-started. The firewalls usually depend on the
NTP and DNS servers which they protect, so if you start the NTP
servers first, the firewalls are not there so there is nothing to sync
from, and when you start the firewalls first, the NTP servers are not
there so there is nothing to sync from again.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Greylisting for @debian.org email, please

[Thomas Bushnell BSG]

Simon Richter <[EMAIL PROTECTED]> writes:

> Thomas Bushnell BSG wrote:
>
>> So my IP address, which my ISP promises will always be the same, and
>> is initialized by DHCP, is static.  But most of the IP addresses in
>> the block are handed out dynamically.  How will you be able to tell?
>
> Not reliably, that is sure, but the DUL has been pretty reliable (and in
> fact, your IP is not listed there).

What do you mean by "pretty reliable"?


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

Re: Greylisting for @debian.org email, please

[Simon Richter]

Hi,

Thomas Bushnell BSG wrote:

> So my IP address, which my ISP promises will always be the same, and
> is initialized by DHCP, is static.  But most of the IP addresses in
> the block are handed out dynamically.  How will you be able to tell?

Not reliably, that is sure, but the DUL has been pretty reliable (and in
fact, your IP is not listed there).

   Simon


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

Re: Greylisting for @debian.org email, please

[Simon Richter]

Hi,

Frans Pop wrote:

> Try mine: 195.240.184.66
> And yes, it is static and not "dynamic but unlikely to change rarely".

Not listed either.

> I started using my own mailserver because the one from my provider was 
> down a lot for a while or not delivering within something like 8 hours 
> (they seem to be better ATM).
> Using my own server I would at least _know_ what was happening to my 
> mails.

Yes, that is a valid reason, although being able to check manually sort
of implies that you don't have a lot of traffic.

   Simon


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

Re: TODO for etch ?

[Olaf van der Spek]

On 6/19/05, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Marc Haber:
> 
> > On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
> > <[EMAIL PROTECTED]> wrote:
> >>That could "save" a grand total of about a second.
> >
> > It will save time in case of error when the bootup process stalls for
> > timeouts like DNS and NTP.
> 
> You should set the clock using NTP *before* starting any daemons.
> Most daemons don't use monotonic clocks (I'm not even sure if Linux
> supports them at the required level), and some of them fail in strange
> ways if the system clock warps.

Doesn't Linux or NTP support gradually changing the clock exactly to
avoid such warps?