Problems with security updates

[Mgr. Peter Tuharsky]

Ralph,

it's interesting, but now it works for me too, versions are the same. 
Just few days ago it "crashed happily".


Well, seems it would be harder to abandon Debian than it seemed :o) In 
fact, very hard for me..



Peter


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

Re: Remove cdrtools

[Goswin von Brederlow]

Steve Greenland <[EMAIL PROTECTED]> writes:

> On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote: 
>> On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
>> 
>> > And guess what? System tests are actually more reliable, especially
>> > when the user tells you what the system is. You can simply flip to
>> > compiling foo_linux.c or foo_solaris.c and go on your way.
>> 
>> This will never work. Real life example from a couple of weeks ago: I
>> wrote a program that was running happily on Sarge, then somebody wanted
>> to build it on RHEL and failed because the UUID library on RHEL does not
>> have uuid_unparse_lower().
>
> So you chose to use a function not reliably available. Sounds like bad
> planning to me.
>
>> And RHEL _is_ Linux and it is pretty heavily used in corporate
>> environments. So instead of foo_linux.c you need foo_sarge.c,
>> foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more,
>> which is just plainly unmanageable.
>
> No, you figure out what the base system requirement is, and write to that.
>
> I can guarantee you that there's a lot more difference between AIX and
> "Linux" than there is between RHEL 3.x and Debian sarge, not to even
> mention non-Unix platforms. None-the-less, code can be written that runs
> on all of them. You figure out where the incompatability points are, and
> you write functions to mask them. Of course the functions themselves
> have #ifdefs (or some other way of controlling compilation), but you get
> it *out* of your main code base.

Then again you have code that depends on the size of variable types,
the availability of header files, libaries, functions in libraries,
different prototypes for functions, .

Instead of finding out what all those parameters are for each system
and writing an foo_.c you can use autoconf to run reliable
testcases for them and use the results to automatically adjust to the
probed set of parameters.

Especialy when you have optional stuff, like 'png support yes/no',
then you need something to easily set the #ifdef variables.

MfG
Goswin


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

Re: libslang2 breaks jed

[Alastair McKinstry]

Jörg Sommer wrote:
> Hi,
>
> I've two problems with libslang2. The first is, the package libslang2
> includes a patch that changes the behaviour of a function. But jed
> expects the function behaviour as given in the original slang2 library.
> I've reported this bug #369152, 80 days ago, but the maintainer does not
> react. The upstream maintainer (of jed and slang) John E. Davis is also
> interested in what this patch should do.
>
>   
I apologize for this; I'd lost track of this particular bug (busy doing
RL) and
forgot to upload. Will do so today.
> And the second problem is, the dependency version for libslang2 calcuated
> by dh_shlibdeps is always 2.0.1-1 although the installed version is
> newer. Why? How can I change this? There were bug fixes in libslang2
> since 2.0.1-1. I need a newer version than this.
>
>   
You should just be able to do libslang2 (>= 2.0.6-3) in jed to force
dependencies
on a late version. Nevertheless, as the behaviour of libslang has
changed with
the above change, I'll change the slib dependencies.

> Thanks, Jörg.
>   


Regards
Alastair


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

Orphaned Packages

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I read that the packages cvsps and xearth are orphaned now. I might be
able to get over this packages. But there is a small problem:

Years ago I start getting a official debian maintainer. Unfortunately it
went asleep as I have no time to finish the new maintainer procedure.
I would be able and proud to give some work to debian but the my time is
very limited.

So is there a way to give official packages to debian without being a
official maintainer?

Regards
   Klaus Ethgen
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iQEVAwUBROQtNp+OKpjRpO3lAQLXnwf+JB4avdmt2k4wHM7CmptFuMlR0GlmCSp2
fvI+07gfGFSCjNW9LV/Or9rrHw85x/TfJIZJUpboHZIjVpEZxa7jCvozmKa/7LtY
ywFwA3Ebs50eDAV+NuhQ0MDdSJzs1FdBS2BSzlIe7b7MvN1v1cwicyrC67j68zYP
l1LrwrM6QO952CCCh86ilIl5B4UKKzOS7cYJGI5vFCUnbBJOpFZNx50jAbrShrru
WKQv+onrGhyQ5UfdJbYUjGXb6xdwUiLGX1A2hSiUDsFPVnkxq0LXv1aMJASgYoXx
+dLY4YWeyWbPdMlL0ia8rSAUxOV3z1PFwW/vuDyjyLVGUq256kcFAA==
=U4Rz
-END PGP SIGNATURE-


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

Re: Orphaned Packages

[Christoph Haas]

Hi, Klaus...

On Thursday 17 August 2006 10:47, Klaus Ethgen wrote:
> I read that the packages cvsps and xearth are orphaned now. I might be
> able to get over this packages. But there is a small problem:
>
> Years ago I start getting a official debian maintainer. Unfortunately it
> went asleep as I have no time to finish the new maintainer procedure.
> I would be able and proud to give some work to debian but the my time is
> very limited.
>
> So is there a way to give official packages to debian without being a
> official maintainer?

Oh, yes, it is. And it's very common, too. It's called "sponsorship".
See http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

You can upload your package to mentors.debian.net and send an email
(RFS = request for sponsorship) to [EMAIL PROTECTED]

By the way: you are still the "official maintainer" then. You just need 
someone to upload on your behalf. But your name stays on the package.

Good luck and thanks for your upcoming contribution.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: Orphaned Packages

[Steffen Joeris]

Hi Klaus

> So is there a way to give official packages to debian without being a
> official maintainer?
Sure, you can prepare the package and then give it to an official debian 
developer who can upload it for you and therefore act as a kind of sponsor. 
You are still responsible for the package and you are the maintainer and 
responsible for bugreports, keeping the package in a good shape, ...

A good procedure is to finish your work on the package and then write a mail 
to debian-mentors@lists.debian.org and ask there for a sponsor or even 
contact a debian developer if you know any personal.

Please also note that you can ask any further question according to your 
packaging on debian-mentors@lists.debian.org as this is the appropiate 
mailinglist for that.

Cheers
Steffen


pgp1MwjzT7AZf.pgp
Description: PGP signature

Re: WTF ? (Fwd: Your message to Yaird-devel awaits moderator approval)

[Rafael Laboissiere]

* Brian May <[EMAIL PROTECTED]> [2006-08-17 10:52]:

> * The warning message implies that people who send bug reports to
> Debian must also subscribe to upstream mailing lists. This is
> unacceptable (IMHO). I already subscribe to far too many mailing lists.

As regards mailing lists managed by Mailman, an alternative to avoid the
problem is by including the bug reporter into the accept_these_nonmembers
list.  According to the Mailman documentation:

accept_these_nonmembers (privacy): List of non-member addresses whose
postings should be automatically accepted.

This is what I do for all the mailing lists I administer at Alioth.  It
is just two-clicks away in the moderator web interface of Mailman 2.1.5.

-- 
Rafael


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

Re: WTF ? (Fwd: Your message to Yaird-devel awaits moderator approval)

[Rafael Laboissiere]

* Florian Weimer <[EMAIL PROTECTED]> [2006-08-14 07:11]:

> You can't tell from the message if some actually looks at the
> moderation queue.  I think it's fine to moderate your maintainer list,
> but you should tell Mailman (or whatever MLM you use) not to tell the
> message sender that his message has been delayed.

I think that, in the case of responsive list moderators, this is indeed
the right thing to do.  However, I do not know how to configure Mailman
for doing it.  Does someone know?

-- 
Rafael


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

Re: afraid to build from source? (was Re: Remove cdrtools)

[Wouter Verhelst]

On Tue, Aug 15, 2006 at 02:42:09AM -0500, Peter Samuelson wrote:
> [Michael Poole]
> > On top of the default automake behavior being horribly broken, does
> > that make usual revision control practices horribly broken?
> 
> It really bothers me to hear people claim as a best practice that you
> should never recompile configure.ac or Makefile.am except under
> controlled conditions.  To me it is a very important philosophical
> point that Debian be self-hosting.  That means packages should build
> without error from source, not just from intermediate text files like
> 'y.tab.c', 'configure', or 'Makefile.in' which, while arch-independent,
> are not particularly human-editable, and certainly not source code in
> the GPL sense.
> 
> Using a provided 'configure' binary instead of building from source has
> the same problem as using any other provided binary rather than
> building from source.  It clearly expresses a lack of confidence that
> the system _is_ in fact self-hosting.  It tells our users, "we will
> give you all the source code, but you'd better not modify that one
> configure.in source file, because we do not dare trust our tools to
> build it correctly."
> 
> So yeah, I advocate always building packages from source, and if
> autoconf someday comes up with an incompatibility that causes a FTBFS
> somewhere, let that be reported and fixed.  Not just worked around by
> trying to avoid running autoconf.

It has nothing to do with "being afraid to", but everything with "not
needing to". Building and testing a C program on one architecture does
not necessarily mean that it will work on another, too. Differences that
exist in things such as endianness, word size, signedness of default
types, and other things, may mean that a C program which works perfectly
on one architecture may break on another.

The same isn't true for autoconf; this is written in portable POSIX
shell. If it works on one architecture, it works on all of them. The
output of autotools, if done with the same version, is totally
deterministic.

Proper use of autotools will retain that deterministic property. "Proper
use" does include things like making sure you use at least the autotools
version for which your configure.ac and/or Makefile.am was written. It
also includes making sure that you do not try to do things that will
work on one Linux-based architecture, but will fail horribly on another.
Sure, you should verify that things still work if you run autoreconf on
your source tarball, but there is no real need to build autotools output
files in the build target of debian/rules if all you want to do is
verify that they build properly.

An extra reason not to do this is that some older versions of the
autotools will not run themselves as "automake-version" or
"autoconf-version" or whatnot, resulting in behaviour that is not, in
fact, deterministic, since if you have more than one version of the
autotools installed, the default version may very well be the wrong one. 

Moreover, this thread, at least to me, is more about what an upstream
should do rather than what a Debian developer should do; it is not good
practice as an upstream to assume that anyone else than yourself will
need to run the autotools on your input files on a regular basis. You
should distribute the .tar.gz (and, optionally, the .tar.bz2 if you
build that too), which you produce with 'make distcheck'. If you do
that, everything _will_ work for everyone else, and there will not be a
need to put in backwards compatibility stuff for people using older
versions of autotools.

If someone does want to modify the configure.ac or whatnot, it is not
unreasonable to ask that they upgrade to the most recent version. Of
course, you should add things like AC_PREREQ to the right input files to
make that easier, but that's a different matter.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: New desktop features provided by new version of update-notifier

[Wouter Verhelst]

On Mon, Aug 14, 2006 at 11:46:49PM -0300, Gustavo Noronha Silva wrote:
> hmmm... I don't think a sane seasoned Solaris admin would evaluate a
> Unix-like operating system for server-class work by installing its
> 'Desktop' task, perhaps?

A seasoned Solaris admin may very well be of the opinion that running a
Unix-like operating system on their desktop is much easier to support a
bunch of Solaris machines from, but that Solaris itself is not
particularly well suited to PC-class hardware (because it has less
drivers, or whatever).

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Why does Ubuntu have all the wrong ideas (was: New desktop features provided by new version of update-notifier)

[Wouter Verhelst]

On Tue, Aug 15, 2006 at 03:59:26AM -0700, Ottavio Caruso wrote:
> Wouter Verhelst wrote:
> > That is a *very* bad idea. 
> 
> Even only on a small details, I am please to see a few
> people on a Debian mailing list not blindly accepting
> whatever comes from the Ubuntu world.

Well, yeah, but in fairness, in this case the "*very* bad idea" was not
whatever Ubuntu did, but rather the blindly changing of every instance
of "Ubuntu" in a translated text to "Debian".

> Brand me a troll,

It would appear that way ;-P

That being said, I agree with you that something coming from Ubuntu is
not necessarily a good idea for Debian, too. Even if that doesn't apply
to this particular case IMHO.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Re: Greylisting for @debian.org email, please

[Alfonso_Arizaga/etxekide . com]

--
La información incluida en el presente correo electronico y cualquier archivo

adjunto al mismo están dirigidos exclusivamente a su destinatario.Pueden

contener información confidencial o privilegiada. Si recibe esta comunicación

sin ser el destinatario le informamos que está prohibida cualquier utilización

de la misma y le rogamos que nos lo notifique inmediatamente y la devuelva
a su 
origen, asegurandose de que el mensaje original, cualquier copia relacionada

con el mismo y sus archivos adjuntos sean eliminados de su sistema.

libapt-pkg-ruby

[Fabricio \"aybabtu\" Cannini]

Hi!

Sometime ago, i've seen ( don't remember when or where ) a DD orphaning 
libapt-pkg-ruby. Where can i get it ( if it still exists, and no, google 
didn't helped much :( so that i can study and perhaps adopt it ?

Or tell me that i haven't woken up yet. :)

Sreehc!

-- 
I cannot install on the driver, how does it work?

You either can't telnet to the software, or should configure a AT controller 
over a front-side bus on the button.


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

Re: New desktop features provided by new version of update-notifier

[George Danchev]

On Tuesday 15 August 2006 15:43, Wouter Verhelst wrote:
> On Mon, Aug 14, 2006 at 11:46:49PM -0300, Gustavo Noronha Silva wrote:
> > hmmm... I don't think a sane seasoned Solaris admin would evaluate a
> > Unix-like operating system for server-class work by installing its
> > 'Desktop' task, perhaps?

;-) Solaris is really a bad reference to prove your Desktop claim.

> A seasoned Solaris admin may very well be of the opinion that running a
> Unix-like operating system on their desktop is much easier to support a
> bunch of Solaris machines from, 

FWIW, virtual terminals are not officially supported in Solaris 8/9 for sparc 
and x86 (well, yes you can cheat and fight the system at your own risk), and 
it is no fun to type DOSish way on a single console... thus almost all 
installations I've ever seen have Xsun and CDE installed, no matter how 
server-wise they pretend to be. Sol9 comes with GNOME 2.x also ;-)

> but that Solaris itself is not 
> particularly well suited to PC-class hardware (because it has less
> drivers, or whatever).

This is true, but OpenSolaris is getting better on that front.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Remove cdrtools

[Gabor Gombas]

On Wed, Aug 16, 2006 at 07:11:19PM -0500, Steve Greenland wrote:

> So you chose to use a function not reliably available. Sounds like bad
> planning to me.

More than a year ago the plan was that we'll support Debian Sarge only.
Then a couple of weeks ago our project partner said they'll be using
RHEL no matter what. So much for planning.

> I spend quite a bit of my life working on non-Linux platforms (as well
> as a variety of Linux ones). I've built *lots* of free software on these
> platforms. My experience is that the ones whose build instructions say
> "edit the makefile to pick your platform and compiler" compile and work,
> and when they don't, they're easy to fix. The ones that use autoconf
> tend to blow up on non-Linux[1], in ways that are hard to debug and damn
> near impossible to fix.

A couple of years ago I used to be an AIX/Solaris admin and I had quite
the opposite experiences. Installing software that used autoconf was
generally painless, building the software simultaneously on 3 platforms
from a common source (NFS) just worked almost always.

On the other hand, sw with custom build systems were always a pain:
usually they had no idea how to build a shared lib on AIX, they did not
support building outside of the source directory etc.

In case of bugs, autoconf helps a _lot_ since you know that every build
system looks the same, if you find a bug (like libtool being notoriously
broken on AIX) the same bug will be present in every package and the
same fix can be applied etc. On the other hand, all custom build systems
had their own bugs that required a lot more time to investigate.

autoconf/automake/libtool are just like many traditional UNIX tools:
they are all sharp knifes which can cut you deep if you use them badly,
but can also help a lot if you use them wisely.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Remove cdrtools

[Steve Greenland]

On 16-Aug-06, 19:23 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote: 
> Yeah, wanting to use functionality when it's available is always a 
> dreadful idea. Far better to reimplement it locally in order to ensure 
> that we have more copies of it to fix should there ever be any sort of 
> security flaw. 

You can't have it both ways. Either your program *requires* the
new/unusual functionality exist on the system, in which case it will
never port to the systems that don't have it, or you'll have to
provde a custom implementation, in which case you have the multiple
implementations problem anyway.

Steve

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


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

Re: Remove cdrtools

[Steve Greenland]

On 16-Aug-06, 20:23 (CDT), Miles Bader <[EMAIL PROTECTED]> wrote: 
> The main problem with your argument is that you seem to be looking at
> poorly written programs that use autoconf, and jumping to the conclusion
> that autoconf is the reason for the poor programming -- it's not.  Bad
> programmers made a hash of it no matter what style of portability they
> choose.

My experience is that *most* autoconf using programs are written in the
"bad" style, because (I assume) a *lot* of people think something along
the lines of "my code is portable because I use autoconf". My *opinion*
is a lot of that is a result of the autoconf documentation and examples.

My additional experience is that debugging and fixing autoconf related
problems is a real pain in the ass. By "autoconf related problems" I
mean things like it suddenly deciding it's running a cross compiler, or
that stdlib.h is missing. A lot of this kind of stuff could be improved
by simply SHOWING ME THE FSCKING ERROR MESSAGES, rather than just
checking the return code and guessing.

Steve

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


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

Re: Remove cdrtools

[Matthew Garrett]

Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 16-Aug-06, 19:23 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote: 
>> Yeah, wanting to use functionality when it's available is always a 
>> dreadful idea. Far better to reimplement it locally in order to ensure 
>> that we have more copies of it to fix should there ever be any sort of 
>> security flaw. 
> 
> You can't have it both ways. Either your program *requires* the
> new/unusual functionality exist on the system, in which case it will
> never port to the systems that don't have it, or you'll have to
> provde a custom implementation, in which case you have the multiple
> implementations problem anyway.

Or (c), my program will take advantage of extra functionality when it's 
present. You seem to be asserting that this level of granularity is 
unacceptable, so in your model we end up with a choice between less 
functional software or potential screaming security misery. I think this 
is arbitrary and unnecessary.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Remove cdrtools

[Steve Greenland]

On 16-Aug-06, 20:49 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote: 
> 
> As for useless autoconf tests - have you looked at how autoconf is
> used?  You pick the tests you think you need.  It's not like the system
> forces you to use a certain range of obsolete baseline tests.  A huge
> number of test macros are provided, but nobody forces you to use them.

But everybody does, to the point where it now often takes (much!) longer
to run configure than to actually build the program. And, for example,
all of a sudden (autoconf 2.5, I think) every/many (newly generated
or regenerated) configure script starting checking for C++ compilers,
Fortran compilers, etc. etc. etc. even for pure C projects. I don't
know if this is something that changed in autoconf, or something that
changed in one of the higher level autotools. I don't particularly care.
It's not whether or not autoconf itself requires this behavriour, it's
that de-facto, *most* autotools using projects exhibit this behaviour.
Probably because the examples or templates use it, and it's easier to
use them unchanged than actually think about what they're doing.

See, my argument is not that autconf *can't* be used in a wise manner;
my argument is that it tends to lead to bad usage, widely propogated.

Steve


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


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

Re: Remove cdrtools

[Steve Greenland]

On 17-Aug-06, 09:06 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote: 
> On the other hand, sw with custom build systems were always a pain:
> usually they had no idea how to build a shared lib on AIX,

Neither does libtool. But I can usually easily change the Makefile to
fix that problem; libtool is an disaster. There's no point in figuring
out the libtool bug (somewhere in its umpty-thousand lines of sh code)
and submitting a fix, since it will be broken again the next release.

Steve


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

Debian ISOs

[Anthony L. Bryan]

Hi,

Metalinks might be helpful on Debian's download page for CD/DVD images. You
could have a single quick link to your ISOs that contains all the
mirror/p2p/checksum info in it.

Metalinks, a cross platform vendor neutral fortmat, are used by download
managers & contain Mirror & p2p locations for segmented downloads, along
with automatic checksum verification when the download completes. It spreads
the download between multiple servers so its faster for users, more
reliable, & less load on any one server. Metalinks are backward compatible
too.

If you're interested, you can try it out with aria2 (Unix command line)
(http://aria2.sourceforge.net), Speed Download (Mac)
(http://www.yazsoft.com), wxDownload Fast (Mac/Unix/Win), or GetRight
(Windows) (http://www.getright.com), then clicking on these samples:

http://www.metalinker.org/samples.html#isos (There's a metalink for Debian
DVD ISOs there).

Also, OpenOffice.org uses metalinks to distribute their free office suite at
http://distribution.openoffice.org/p2p/magnet.html & a few other Linux
distributions use it for their ISOs.

There's a video of metalink working in GetRight here:
http://www.metalinker.org/implementation.html

Metalinks are just simple XML like this:


http://www.metalinker.org/";>
  
debian
http://www.debian.org/
  
  Debian 3.1r2 i386 DVD ISO
  

  3.1r2
  Linux-x86
  
e467b508185f4fdd8e97c9ee76045288
  
  
http://cdimage.debian.org/debian-cd/current/i386/iso-dvd/de
bian-31r2-i386-binary-1.iso
http://debian.osuosl.org/debian-cdimage/current/i386/iso-dv
d/debian-31r2-i386-binary-1.iso
http://ftp.iasi.roedu.net/mirrors/ftp.debian.org/debian-cd/
current/i386/iso-dvd/debian-31r2-i386-binary-1.iso
  

  

  3.1r2
  Linux-x86
  
34ad0d7a9ff4a44c5cffb6d238ac4b26
  
  
http://cdimage.debian.org/debian-cd/current/i386/iso-dvd/de
bian-31r2-i386-binary-2.iso
http://debian.osuosl.org/debian-cdimage/current/i386/iso-dv
d/debian-31r2-i386-binary-2.iso
http://ftp.iasi.roedu.net/mirrors/ftp.debian.org/debian-cd/
current/i386/iso-dvd/debian-31r2-i386-binary-2.iso
  


  



thanks,

Anthony Bryan
http://www.metalinker.org/


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

Re: Remove cdrtools

[Russ Allbery]

Steve Greenland <[EMAIL PROTECTED]> writes:

> And, for example, all of a sudden (autoconf 2.5, I think) every/many
> (newly generated or regenerated) configure script starting checking for
> C++ compilers, Fortran compilers, etc. etc. etc. even for pure C
> projects.

This is a libtool bug.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Why no /usr/local/etc in Debian?

[Kevin B. McCarty]

I wrote:

> I suggest you file a severity
> "serious" bug against the base-files package, since it is responsible
> for creating the directories under /usr/local in its postinst.  The
> serious severity is justified IMO since the existence of /usr/local/etc
> is a "must" directive of the FHS.  (Any arguments?)

FYI, I've now filed this as #383493.  (Filed as "important" rather than
"serious" to avoid stepping on the toes of release people.)

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


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

Re: New desktop features provided by new version of update-notifier

[Wouter Verhelst]

On Thu, Aug 17, 2006 at 05:00:13PM +0300, George Danchev wrote:
> On Tuesday 15 August 2006 15:43, Wouter Verhelst wrote:
> > but that Solaris itself is not 
> > particularly well suited to PC-class hardware (because it has less
> > drivers, or whatever).
> 
> This is true, but OpenSolaris is getting better on that front.

FWIW, I'm not very familiar with Solaris; I just tried to come up with
an example of something that might be a plausible reason.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Status of inetd for etch

[Hendrik Sattler]

Am Donnerstag 10 August 2006 23:56 schrieb Roger Leigh:
>   The inetd daemon installed by default:
> etch:   openbsd-inetd | netkit-inetd

Note: etch beta 3 show me a dpkg status of "ic" for netkit-inetd after a fresh 
installation. openbsd-inetd is installed. Where does this come from?

The default installation also shows other questionable services that 
automatically get installed:
- identd (who actually _needs_ this?)
- lpr (useless on systems without a printer)

I do not object to portmap+nfs (although I do not use it and immediately 
uninstall it) but the two above are really not required and should not be 
installed by default.
The suggestion to use "nodaemon" as default for exim4 when only handling local 
mail will probably be rejected?
I pretty much favour a default installation where "netstat -l" shows no 
services on network interfaces.

HS


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

Re: Remove cdrtools

[George Danchev]

On Thursday 17 August 2006 19:02, Steve Greenland wrote:
> On 16-Aug-06, 20:49 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
> > As for useless autoconf tests - have you looked at how autoconf is
> > used?  You pick the tests you think you need.  It's not like the system
> > forces you to use a certain range of obsolete baseline tests.  A huge
> > number of test macros are provided, but nobody forces you to use them.
>
> But everybody does, to the point where it now often takes (much!) longer
> to run configure than to actually build the program. And, for example,
> all of a sudden (autoconf 2.5, I think) every/many (newly generated
> or regenerated) configure script starting checking for C++ compilers,
> Fortran compilers, etc. etc. etc. even for pure C projects. I don't
> know if this is something that changed in autoconf, or something that
> changed in one of the higher level autotools. I don't particularly care.
> It's not whether or not autoconf itself requires this behavriour, it's
> that de-facto, *most* autotools using projects exhibit this behaviour.
> Probably because the examples or templates use it, and it's easier to
> use them unchanged than actually think about what they're doing.
>
> See, my argument is not that autconf *can't* be used in a wise manner;
> my argument is that it tends to lead to bad usage, widely propogated.

So are some widespread programming languages. If you blindly follow bad 
examples and bad styles you can dynamite yourself happily without even 
noticing, but that does not make them disused or abandoned (on the contrary 
some of them have notoriously prolonged life cycle ;-)... it just matters who 
is using them and how.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Status of inetd for etch

[Frans Pop]

On Thursday 17 August 2006 19:21, Hendrik Sattler wrote:
> Am Donnerstag 10 August 2006 23:56 schrieb Roger Leigh:
> >   The inetd daemon installed by default:
> > etch:   openbsd-inetd | netkit-inetd
>
> Note: etch beta 3 show me a dpkg status of "ic" for netkit-inetd after
> a fresh installation. openbsd-inetd is installed. Where does this come
> from?

From the fact that debootstrap currently tries to install both due to the 
fact that the priority for netkit-inetd had not yet been changed (I think 
this has been fixed now).

> The default installation also shows other questionable services that
> automatically get installed:
> - identd (who actually _needs_ this?)
> - lpr (useless on systems without a printer)

Also due to their current priority.


pgpJx6fFBgkOc.pgp
Description: PGP signature

Re: Status of inetd for etch

[Otavio Salvador]

Hendrik Sattler <[EMAIL PROTECTED]> writes:

> The suggestion to use "nodaemon" as default for exim4 when only handling 
> local 
> mail will probably be rejected?

I guess you meant nullmailer.

-- 
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: libapt-pkg-ruby

[David Moreno Garza]

On Thu, 2006-08-17 at 10:43 -0300, Fabricio "aybabtu" Cannini wrote:
> Sometime ago, i've seen ( don't remember when or where ) a DD orphaning 
> libapt-pkg-ruby. Where can i get it ( if it still exists, and no, google 
> didn't helped much :( so that i can study and perhaps adopt it ?

You can start by searching through the orphaned packages page:
 http://www.us.debian.org/devel/wnpp/orphaned

If it is not there, it probably was already adopted or you are starting
to hear voices.

A more aggressive search would be at bugs.debian.org/wnpp.

Cheers,

-- 
David Moreno Garza<[EMAIL PROTECTED]>
 http://www.damog.net/ <[EMAIL PROTECTED]>

Las matemáticas nunca tienen la última palabra.




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

Re: afraid to build from source? (was Re: Remove cdrtools)

[Peter Samuelson]

[Wouter Verhelst]
> It has nothing to do with "being afraid to", but everything with "not
> needing to".

There's lots of things we don't _need_ to do but we do anyway, as a
matter of quality of implementation.  I believe that building a package
from source is something we should do as well, if only to ensure that
our packages do continue to build from source, using our tools.  And
when I say "from source", I'm using the GPL definition of source code,
"the preferred form for making modificatons", which I think is a pretty
useful definition in general.


> Sure, you should verify that things still work if you run autoreconf
> on your source tarball, but there is no real need to build autotools
> output files in the build target of debian/rules if all you want to
> do is verify that they build properly.

The same could be said for lots of other tools: bison and flex are the
obvious ones, but also yodl, docbook2x and other documentation
convertors.  Is it reasonable to tell maintainers that every
architecture-independent generated file should be built manually and
shipped in the .diff.gz rather than built as part of the debian build?


> Moreover, this thread, at least to me, is more about what an upstream
> should do rather than what a Debian developer should do; it is not
> good practice as an upstream to assume that anyone else than yourself
> will need to run the autotools on your input files on a regular
> basis.

What an upstream should do and what Debian should do are quite
different things.  It has long been accepted that an upstream's best
practice is _not_ to require users to have autoconf installed locally -
they can assume you have a compiler and make and common tools like awk,
but not autoconf or flex.  Debian does not have this problem.  Our
'apt-get build-dep' command ensures that it is convenient for our users
to use pretty much any tool we need, when rebuilding our packages.  We
don't _have_ to worry about providing pre-built output from autoconf,
flex, bison and the like.  Our build dependencies even make it easy to
require a particular minimum version of any tool.

In summary, I think it's important for our users to be able to build
packages from source.  This implies that _we_ should build from source,
in order to exercise the whole toolchain, so that we know it always
works.  And if it's so fragile that it _doesn't_ always work ... well,
then _that's_ a problem which needs to be addressed.

Is the autoconf unreliability problem really so intractible that it
requires a workaround of "don't ever use it except in a manual process
where you can test it immediately to see if it worked"?  Would we
tolerate that same requirement in a tool like docbook2x?


signature.asc
Description: Digital signature

Bug#383550: ITP: aubio -- library for audio labelling

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: aubio
  Version : 0.3.1
  Upstream Author : Paul Brossier <[EMAIL PROTECTED]>
* URL : http://aubio.piem.org/
* License : GPL
  Programming Lang: C
  Description : library for audio labelling

aubio is a library for audio labelling. Its features include segmenting a
sound file before each of its attacks, performing pitch detection, tapping
the beat and producing midi streams from live audio. The name aubio comes
from 'audio' with a typo: several transcription errors are likely to be
found in the results too.

The aim of the project is to provide these automatic labelling features to
other audio softwares. Functions can be used offline in sound editors and
software samplers, or online in audio effects and virtual instruments.

-- 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.16-2-686
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)


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

Re: Why does Ubuntu have all the wrong ideas (was: New desktop features provided by new version of update-notifier)

[Gustavo Noronha Silva]

Em Tue, 15 Aug 2006 14:29:31 +0200
Michal Čihař <[EMAIL PROTECTED]> escreveu:

> On Tue, 15 Aug 2006 03:59:26 -0700 (PDT)
> Ottavio Caruso <[EMAIL PROTECTED]> wrote:
> 
> > Wouter Verhelst wrote:
> > 
> > > That is a *very* bad idea. 
> > 
> > Even only on a small details, I am please to see a few
> > people on a Debian mailing list not blindly accepting
> > whatever comes from the Ubuntu world.
> 
> Because this *is* a bad idea. If you have localized text, blindly
> replacing Ubuntu with Debian will make it absolutely messy for
> languages that have different declension for both. And I doubt that
> replacing Ubuntu with Debian at run time comes from Ubuntu...

/me points at himself

It comes from some @debian.org, who should know better.

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
http://people.debian.org/~kov/


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

Bug#383563: ITP: dicomnifti -- converts DICOM files into the NIfTI format

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke <[EMAIL PROTECTED]>

* Package name: dicomnifti
  Version : 2.11
  Upstream Author : Valerio Luccio ([EMAIL PROTECTED])
* URL : https://www.cbi.nyu.edu/public/software/dinifti/
* License : GPL
  Programming Lang: C++
  Description : converts DICOM files into the NIfTI format

Please note, that the upstream author kindly rerelease this software
under the GPL for the inclusion into Debian (previous license was
non-free/non-commercial).
  
The dinifti program converts MRI images stored in DICOM format to NIfTI
format. Files in the NIfTI format can be used with FSL, AFNI and SPM.

dinifti converts single files, but also supports batch conversions
of complete dicomdirs.

This package depends on the nifti libraries. See
related ITP:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383349

The package is NOT yet ready for inspection.


Bye,

Michael


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (600, 'testing'), (200, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


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

Re: Remove cdrtools

[Matthew R. Dempsky]

On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
> So are some widespread programming languages. If you blindly follow bad 
> examples and bad styles you can dynamite yourself happily without even 
> noticing, but that does not make them disused or abandoned (on the contrary 
> some of them have notoriously prolonged life cycle ;-)... it just matters who 
> is using them and how.

People without the skill to program in error-prone languages are 
encouraged to use more idiot-proof ones instead.  Why isn't the same 
done for build frameworks?


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

Re: Remove cdrtools

[Peter Samuelson]

[Steve Greenland]
> By "autoconf related problems" I mean things like it suddenly
> deciding it's running a cross compiler, or that stdlib.h is
> missing. A lot of this kind of stuff could be improved by simply
> SHOWING ME THE FSCKING ERROR MESSAGES, rather than just checking the
> return code and guessing.

Too bad autoconf doesn't keep a log of everything configure does.[1]

   [1] In case you missed it, it's called 'config.log'.


signature.asc
Description: Digital signature

I want one of those!

[Adrian von Bidder]

Now I'm not a buildd operator nor do I have any experience on non-x86 
arches, but a 16 core MIPS 1U server that only pulls 50W power and that 
ships with Debian preinstalled just has a very high coolness factor :-)

http://www.movidis.com/products/rev.asp
http://www.informationweek.com/news/showArticle.jhtml?articleID=192201783&subSection=Breaking+News

(Ok, I know this is OT for d-d.  You can all go back to bashing JS now.)

-- vbi


-- 
featured link: http://www.pool.ntp.org


pgpYxYeuPdz7H.pgp
Description: PGP signature