Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>If this compromises their effectiveness, then they deserve
> every consequence of their laziness. A programmer being lazy does not
> mean sloppy, unprofessional, incompetence. I think you do not have a
> concept of what that statement was meant to convey in the first
> place -- laziness means that programmers automate away common tasks

however expecting a programmer to read docs does not mean it is ok to ship
outdated and confusing (example) config files. I had to track down the
correct upload queses multiple times (before dupload was fixed). This is
just awaste of time if it does not work with sane defaults.

bernd


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

Re: Documentation of alioth?

[Marc Haber]

On Mon, 11 Jul 2005 08:16:31 +0200, Raphaël Hertzog
<[EMAIL PROTECTED]> wrote:
>Le dimanche 10 juillet 2005 à 23:34 +0200, Marc Haber a écrit :
>> Alioth is mainly unmaintained, don't rely on it.
>
>That's grossly unfair. Furthermore I have yet to see an offer to help or
>a patch sent to the current administrators.

Mailing list moderation is broken for like three months. There is an -
unreplied - tracker ticket (#301440) open, people have been prodded on
IRC multiple times, and all I got - after two weeks of trying to get
this issue at least acknowledged - was a "yeah, there is an
incompatbility between gforge and mailman".

Same goes for tracker ticket #301374 - open since three months, not a
bit of reply.

>Requets for new projects are treated regularly by the 3 admins. Problems
>requiring root rights can only be handled by Wichert Akkerman and are
>thus treated less frequently. Sometimes you need to prod him directly
>(on IRC).

I do not care too much about alioth's internal problems. Fact is that
important parts of alioth infrastructure are broken since multiple
months, users are ignored, and nobody seems to care. This makes _my_
work as a DD significantly harder since I have to look after my
mailing lists manually since a quarter of a year.

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: Package priorities: optional vs extra

[Manoj Srivastava]

On Sun, 10 Jul 2005 14:49:38 +0300, Lars Wirzenius <[EMAIL PROTECTED]> said: 

> su, 2005-07-10 kello 01:44 -0400, Nathanael Nerode kirjoitti:
>> Peter Samuelson wrote: Unless someone is willing to actually
>> enforce the requirement that all optional packages can coexist,
>> this will be necessary to make Policy conform with reality.

> Is there a tool to check for disallowed conflicts, or a check in
> lintian or linda?

I think there is a Contents file on most mirrors
  http://ftp.debian.org/debian/dists/sid/, for example. Now, one just
  has to look for commas in the second column; for example, the first
  few instances of this in Sid's Contents-i386 are:

bin/busybox   
utils/busybox,shells/busybox-static,shells/busybox-cvs-static,utils/busybox-cvs
bin/fgconsole utils/console-tools,utils/kbd
bin/loadkeys  utils/console-tools,utils/kbd
bin/mount  admin/loop-aes-utils,base/mount

Now, one could parse this, and use grep-available in clever
 ways to see if the packages conflict, and their priorities.

manoj
-- 
I went into the business for the money, and the art grew out of it.
If people are disillusioned by that remark, I can't help it.  It's the
truth.  -- Charlie Chaplin
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Javier Fernández-Sanguino Peña]

On Sat, Jul 09, 2005 at 08:25:11AM -0500, Manoj Srivastava wrote:
> This is a huge list, with probably 0 chances of getting
>  accomplished.  How about this: remove every single item from the list,
>  and only add items when there are people who sign up to be responsible
>  for the work involved in actually seeing that item come to fruition?

Errr.. the wishlists with names within brackets are those that have been
taken over by somebody, the ones that don't are up for grabs. This list is
meant as a stimuli for those that do not know what to do with their spare
time (yes, there's a number of DDs in that situation, believe me). 

Providing a list of things that need to be worked on, even if not Release
Critical, is a good thing IMHO. It is actually something we have been
lacking for previous releases in which the Release Goals were either
undefined or too vague. I find this list complementary with the pet release 
goals set for etch by the release team [1]

> Mere wishlists by random bystanders are no help to anyone.

Thanks, but I'm not a random bystander. Even if I were, I don't see how a
compiled TODO for the distribution hinders development or rather, as seen 
in the previous thread, encourages discussion between developers.

I don't know if the majority of developers thinks, like you do, that these
list is not useful at all. But I can bet you a beer or two that many of the
casual bystanders attending at Debconf5 were not even aware of the
relevance of some of the items in the TODO.

In any case, thanks for your constructive criticism. Ahem.

Javier

[1] http://lists.debian.org/debian-release/2005/06/msg00241.html


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jochen Voss]

On Sat, Jul 09, 2005 at 08:33:42AM -0500, Manoj Srivastava wrote:
> > 7. Fix up the all the silly typos made in every BTS email sent so
> >far and retransmit. (note: this is after the BTS has decided to
> >respond).
> 
> ! [1]
> 
> > 8. upload the changes to source code.
> 
> > 9. realize that I forgot to sign the upload due to a bug in by
> >pbuilder wrapper script, create a *.commands file to send to the
> >upload queue to delete the old upload and reupload again.
> 
> ! [2]
> 
> Are we sure we want someone who is routinely this incompetent
>  to help with bug triage? Seems to me we would be bette off without
>  such substandard help; anyone this incompetent is probably creating
>  more problems than they are solving.

Great idea!  We can even get mor out of this, if we install some
kind of challenge response system: every time you upload a package
it mails you a set of three technical questions, and the upload is
only permitted if all three answers are correct ;-)  The same goes
for the mail interface of the BTS of course.

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jochen Voss]

Hello Manoj,

On Sun, Jul 10, 2005 at 08:30:57PM -0500, Manoj Srivastava wrote:
> Yeah. I should have realized the level of audience I was
>  trying to talk to. I'll try to speak in words of fewer syllables the
>  next time around.

You are actively damaging the project with remarks like this.
Agression and unwillingness to play in a team are not helpful
for us.  Please stop this!

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: Bug#317722: ITP: libfile-nfslock-perl -- perl module to do NFS (or not) locking

[Dominic Hargreaves]

On Mon, Jul 11, 2005 at 02:45:16AM +0100, Andrew Suffield wrote:
> On Mon, Jul 11, 2005 at 01:12:53AM +0100, Dominic Hargreaves wrote:
> > Program based of concept of hard linking of files being atomic across
> > NFS.
> 
> No.

Apologies, I mistakenly copied the description from CPAN without
checking it. The package will have a coherent description.

Cheers,

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Mon, 11 Jul 2005 10:17:56 +0100, Jochen Voss <[EMAIL PROTECTED]> said: 

> On Sat, Jul 09, 2005 at 08:33:42AM -0500, Manoj Srivastava wrote:
>> > 7. Fix up the all the silly typos made in every BTS email sent so
>> >far and retransmit. (note: this is after the BTS has decided
>> >to respond).
>> 
>> ! [1]
>> 
>> > 8. upload the changes to source code.
>> 
>> > 9. realize that I forgot to sign the upload due to a bug in by
>> >pbuilder wrapper script, create a *.commands file to send to
>> >the upload queue to delete the old upload and reupload again.
>> 
>> ! [2]
>> 
>> Are we sure we want someone who is routinely this incompetent to
>> help with bug triage? Seems to me we would be bette off without
>> such substandard help; anyone this incompetent is probably creating
>> more problems than they are solving.

> Great idea!  We can even get mor out of this, if we install some
> kind of challenge response system: every time you upload a package
> it mails you a set of three technical questions, and the upload is
> only permitted if all three answers are correct ;-) The same goes
> for the mail interface of the BTS of course.

Wonderful binary world you live in. If something can't be made
 dead simple, it is the same as making it as difficult as possible,
 eh?

Though the  idea does have merit. The distribution is groaning
 under the sheer size, and often substandard quality of packages; a
 measure like this may kill two birds with one stone.

manoj
-- 
Any sufficiently advanced technology is indistinguishable from a
rigged demo. Andy Finkel, computer guy
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

documentation about Wig & Pen source format (dpkg source format 2.0)

[Fathi BOUDRA]

hi,

is there any documentation or howto about Wig & Pen source format (dpkg source 
format 2.0) ? Maybe an update to the NMG could be helpfull ?

the bits from dpkg maintainer was too short for me ;) :

Wig & Pen source format
---

The Wig & Pen ("Format: 2.0") source format is an evolutionary (rather
than revolutionary) change to the current source package format.
Brendan O'Dea's work on providing _unpack_ support has been integrated
into dpkg-source.  Support for building these formats will be added as
it matures and solidifies.

Existing source packages ("Format: 1.0") are supported without
modification.

The basics of the new format are:

* Multiple upstream tarballs are supported:
The orig.tar.gz is unpacked as normal, additional upstream
tarballs are named orig-XXX.tar.gz and unpacked into the XXX
sub-directory of the source.

Thus glibc might be unpacked as:
glibc-2.3.2.ds1  (from glibc_2.3.2.ds1.orig.tar.gz)
glibc-2.3.2.ds1/nptl (from glibc_2.3.2.ds1.orig-nptl.tar.gz)
glibc-2.3.2.ds1/posixthreads (from 
glibc_2.3.2.ds1.orig-posixthreads.tar.gz)

* The "Debian Diff" may be replaced by the "Debian Tar":
Instead of placing your changes and Debian directory as a patch
against the upstream tarball in a diff.gz, you may instead ship
the Debian directory as a debian.tar.gz.  This is unpacked into
the debian sub-directory of the source.

Changes to upstream may then be stored as separate patches in
the debian/patches directory, and are applied automatically
(with the same rules as run-parts) to the upstream source when
the package is unpacked.

Thus glibc would be unpacked as:
glibc-2.3.2.ds1/debian   (from glibc_2.3.2.ds1-20.debian.tar.gz)

* Bzip2 compression is supported as an alternative to gzip.
This can be picked on a file by file basis, you might choose to
compress the upstream source with bzip2 and the debian tarball
with gzip to get the best results.

Further improvements may be made to this format in later 1.13 releases,
and as build support is added.


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Mon, 11 Jul 2005 10:29:46 +0100, Jochen Voss <[EMAIL PROTECTED]> said: 

> Hello Manoj,
> On Sun, Jul 10, 2005 at 08:30:57PM -0500, Manoj Srivastava wrote:
>> Yeah. I should have realized the level of audience I was trying to
>> talk to. I'll try to speak in words of fewer syllables the next
>> time around.

> You are actively damaging the project with remarks like this.
> Agression and unwillingness to play in a team are not helpful for
> us.  Please stop this!

And I think you are doing far worse by not giving short shrift
 to unworthy ideas and lack of critical analysis of views presented,
 but hey. Who is listening to anyone else any more?

manoj
-- 
Anything worth doing is worth overdoing.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Mon, 11 Jul 2005 09:59:52 +0200, Javier Fernández-Sanguino Peña <[EMAIL 
PROTECTED]> said: 

> Providing a list of things that need to be worked on, even if not
> Release Critical, is a good thing IMHO. 

Umm. I think that such a list has already grown too large to
 be of value; I can come up with a few hundred items along the lines
 of "would be nice if ..".  

>> Mere wishlists by random bystanders are no help to anyone.

> Thanks, but I'm not a random bystander. Even if I were, I don't see
> how a compiled TODO for the distribution hinders development or
> rather, as seen in the previous thread, encourages discussion
> between developers.

Read http://www.livejournal.com/users/gravityboy/15401.html

In essence, this is akin to what Andrew Suffield calls "Voting
 for more money". A reasonable list of reasonable, achievabel goals
 for Etch is of real value. However, that requires thought, judgement,
 and triaging out marginal and unrealistic ideas out of the list; and
 that appears not to have been done.

> In any case, thanks for your constructive criticism. Ahem.

Well, I have said my piece, Feel free to ignore it.

manoj
-- 
Never call a man a fool.  Borrow from him.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Spam mail warning notification! (LGI Policies)

[NO-REPLY . antispam]

 eManager Notification *

The following mail was blocked since it contains sensitive content.

Source mailbox: 
Destination mailbox(es): [EMAIL PROTECTED]
Policy: LGI Policies
Action: Delete

Content filter has detected a sensitive e-mail.

*** End of message *
From: debian-devel@lists.debian.org
To: [EMAIL PROTECTED]
Subject: delivery failed
Date: Mon, 11 Jul 2005 11:44:46 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_NextPart_000_0004_83BEB15E.06BDC116"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.

Bug#317751: ITP: proxsmtp -- multi purpose SMTP Proxy

[Pierre Habouzit]

Package: wnpp
Severity: wishlist
Owner: Pierre Habouzit <[EMAIL PROTECTED]>


* Package name: proxsmtp
  Version : 1.2.1
  Upstream Author : Nate Nielsen <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : BSD (http://memberwebs.com/nielsen/bsd_license.html)
  Description : multi purpose SMTP Proxy

ProxSMTP is a flexible tool that allows you to reject, change or log
email based on arbitrary critera.  It accepts SMTP connections and
forwards the SMTP commands and responses to another SMTP server.  The
'DATA' email body is intercepted and filtered before forwarding.
.
You need to be able to write the filtering scripts that integrate it
with your particular needs.  If you're looking for something that does
virus filtering, take a look at ClamSMTP which behaves similarly and
uses a similar code base.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11.6
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Package priorities: optional vs extra

[Frank Lichtenheld]

On Mon, Jul 11, 2005 at 02:12:58AM -0500, Manoj Srivastava wrote:
> On Sun, 10 Jul 2005 14:49:38 +0300, Lars Wirzenius <[EMAIL PROTECTED]> said: 
> > Is there a tool to check for disallowed conflicts, or a check in
> > lintian or linda?
> 
> I think there is a Contents file on most mirrors
>   http://ftp.debian.org/debian/dists/sid/, for example. Now, one just
>   has to look for commas in the second column; for example, the first
>   few instances of this in Sid's Contents-i386 are:
[...]
> 
> Now, one could parse this, and use grep-available in clever
>  ways to see if the packages conflict, and their priorities.

I have a really hacky tool available that I used to produce such a list
of packages to look at. I even posted it to some list somewhen, one
could probably dig it up using google. I don't seem to have committed
it to my personal CVS repository (silly me) so I don't havee it
available currently here at Debconf.

The real problem is that you afterwards have to actually install all
these possible problematic packages since you can't automatically decide
wether they handle their conflicts with diverts...

It should easily be possible to combine that with the planned install
tests of packages though...

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: documentation about Wig & Pen source format (dpkg source format 2.0)

[Frank Lichtenheld]

On Mon, Jul 11, 2005 at 11:41:28AM +0200, Fathi BOUDRA wrote:
> hi,
> 
> is there any documentation or howto about Wig & Pen source format (dpkg 
> source 
> format 2.0) ? Maybe an update to the NMG could be helpfull ?

Certainly not in the NMG as long as you aren't allowed to use it in the
official archive...

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: Package priorities: optional vs extra

[Frank Lichtenheld]

On Mon, Jul 11, 2005 at 01:21:35PM +0200, Frank Lichtenheld wrote:
> I have a really hacky tool available that I used to produce such a list
> of packages to look at. I even posted it to some list somewhen, one
> could probably dig it up using google. I don't seem to have committed
> it to my personal CVS repository (silly me) so I don't havee it
> available currently here at Debconf.

http://lists.debian.org/debian-devel/2004/10/msg9.html

which links to

http://people.debian.org/~djpig/conflict-finder/conflict-finder

That's not the latest version though...

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: Documentation of alioth?

[Raphael Hertzog]

Le lundi 11 juillet 2005 à 09:17 +0200, Marc Haber a écrit :
> Mailing list moderation is broken for like three months. There is an -
> unreplied - tracker ticket (#301440) open, people have been prodded on
> IRC multiple times, and all I got - after two weeks of trying to get
> this issue at least acknowledged - was a "yeah, there is an
> incompatbility between gforge and mailman".
> 
> Same goes for tracker ticket #301374 - open since three months, not a
> bit of reply.

I never said we were perfect. But alioth is not "unmaintained".
Gforge has its bugs, you're more than welcomon to work on it...

> I do not care too much about alioth's internal problems. Fact is that
> important parts of alioth infrastructure are broken since multiple
> months, users are ignored, and nobody seems to care. This makes _my_
> work as a DD significantly harder since I have to look after my
> mailing lists manually since a quarter of a year.

Did you try to check where the problem is ? Did you try to prepare a
patch for us to apply ?

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


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

Re: HashKnownHosts

[Tollef Fog Heen]

* Colin Watson 

| On Sat, Jul 02, 2005 at 08:17:57PM +0200, Marco d'Itri wrote:
| > On Jul 02, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
| > > On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
| > > > What is the rationale for changing the default setting?
| > > > I find it very annoying, and from a brief discussion on #debian-devel I
| > > > see that I'm not alone.
| > > What causes this annoyance?
| > 
| > The need to edit the file to add/update/remove IP addresses, hostnames
| > and whole keys.
| 
| Then I'm afraid you simply haven't read the documentation ...

It breaks tab-completion based on .ssh/known_hosts which I find really
bad.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Debian Bug Subscription Feature

[Joachim Breitner]

Hi,

Something that I have been missing for along time is the posibility to
subscribe to single bugs in our bugtracking system. Two years ago, at
Oslo, I created a patch to debbugs that would add that feature, but due
to slow communication with the debbugs team and probably not enough
persistence on my side, this never made in into the debbugs package.

Today, I started this again, this time as an independant service, thus
enabling easier development and no risk for the crucial debbugs
infrastructure. It is currenlty in "first usable state with minimum
features". To use it, send a mail to [EMAIL PROTECTED]
with the bugnumer (and only the bug number, nothing else, not even a #)
in the Subject. From then on, you should get any mail on
[EMAIL PROTECTED] that concerns that bug.

There is currently no way to unsubscribe. Not too bad, since bugs tend
to be fixed someday, but certainly a TODO. Also, there is no
confirmation question, nothing to prevent you from recieving the same
mail twice. There is a Anti-Mailloop-Feature, I hope it works. Debian
Developers can have a look at the code on
gluck.debian.org:~nomeata/debsub/, comments and patches welcome. 

Greetings from Helsinki,

Joachim



-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[David Nusinow]

On Mon, Jul 11, 2005 at 04:56:15AM -0500, Manoj Srivastava wrote:
> > Thanks, but I'm not a random bystander. Even if I were, I don't see
> > how a compiled TODO for the distribution hinders development or
> > rather, as seen in the previous thread, encourages discussion
> > between developers.
> 
> Read http://www.livejournal.com/users/gravityboy/15401.html
> 
> In essence, this is akin to what Andrew Suffield calls "Voting
>  for more money". A reasonable list of reasonable, achievabel goals
>  for Etch is of real value. However, that requires thought, judgement,
>  and triaging out marginal and unrealistic ideas out of the list; and
>  that appears not to have been done.

For what it's worth, I've just signed myself and the X Strike Force (me
being the public face of the thing as of late) up for the X.Org transition
item on the EtchTODO page. I also removed two suprious items related to X
that I don't intend to do, and I don't plan on allowing to pass through the
X.Org packages currently. Seeing as I wrote the above blog entry, I can
take a little responsibility for my piece of that TODO list.

What I'd like to see is no more new items added to that list without
someone signing up and taking responsibility for them. What I really want
to see more than anything with that list is for each and every item to have
at least one person signed up, taking responsibility for it. That way, it
becomes a real TODO list, rather than just a stupid wishlist.

For those people out there who want to work on something but aren't sure
what, just sign up for something on that list and get to work! There's some
cool ideas on there, but we need to actually make them happen, since they
won't just materialize on their own. People in NM or looking to get in to
NM, this is a perfect opportunity to do something cool and help shape the
project. Finally, if you're already working on something, like getting the
new KDE or Gnome in to Debian, put it on there with your name by it! Let's
use this page to show people what's actually happening in Debian, so they
don't have to trawl through a zillion bug reports, mailing lists, and irc
channels just to hear what we plan to do.

 - David Nusinow


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

Re: Documentation of alioth?

[Eduard Bloch]

#include 
* Raphael Hertzog [Mon, Jul 11 2005, 02:13:17PM]:

> > I do not care too much about alioth's internal problems. Fact is that
> > important parts of alioth infrastructure are broken since multiple
> > months, users are ignored, and nobody seems to care. This makes _my_
> > work as a DD significantly harder since I have to look after my
> > mailing lists manually since a quarter of a year.
> 
> Did you try to check where the problem is ? Did you try to prepare a
> patch for us to apply ?

It's not my beer, but... did you ask for one? Did you ask for help at
all (since there seem to be real problems, my last request for an
obvious feature has been some months in the queue before beeing
processed).

Regards,
Eduard.

-- 
Sinclair: I'm still waiting for an explanation, gentlemen.
Ambassador Londo Mollari: Yes, and I'm prepared to give you one, Commander, as
soon as the room stops spinning.
Sinclair: This station creates gravity by rotation. It never stops spinning.
Ambassador Londo Mollari: Well, you begin to see my problem.
 -- Quotes from Babylon 5 --


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Max Vozeler]

On Fri, Jul 08, 2005 at 02:33:12PM +0200, Javier Fernández-Sanguino Peña wrote:
> - Encrypted root/swap on the d-i installation.

I'm planning to work on this- probably during the next few weeks. I hope
to also get together with Wesley Terpstra and talk about how we can make
the framework usable for both loop-AES and dm-crypt based setups.

> [ Security improvements ] 
> 
> - Proper source code audit by maintainers to detect stupid security
>   bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
>   too often. Automatic source code audit ala lintian.debian.org? 

I'd be happy to help with this effort. 

A first step could be to make the lintian.d.o scripts run on a lintian.d
style directory of scripts, if that sounds reasonable to the people who
run that service (Josip Rodin?). That would make it pretty easy to build
lists of privileged files, plug in source code scanners, greps for /tmp/
and everything else we can come up with.

cheers,
Max


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

�����������I�������M�������I��

[w_asdw]

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@
[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@??
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]://peach-pig.com/s008.html







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

RFA: etask-el -- Define and manage projects within Emacs with Gantt

[Daniel Martins]

Package: wnpp
Severity: normal

Etask is a Emacs mode to define and manage projects and todos, it features:

- Keep track of tasks in multiple projects
- Manage your todos
- Organize tasks and todos in subtasks and subtodos
- Archive tasks and todos
- Display Gantt bars for all tasks and todos
- Change the zoom factor of the Gantt chart
- Classify each project task according to its criticality:
* Normal tasks
* High risk tasks
* Tasks lying on the critical path 
- Make task and todo notes
- Set task-specific progress goals: linear, moderate
  s-shaped, or s-shaped with tougher requirements for
  the middle phase and therefore more flexibility
  towards the planned end
- Multilingual (German and English)
- Print detailed project status reports
- Generate LaTeX output for high-quality Gantt charts
 
It may be totally or in part added or adapted to more complete modes
such as Planner mode



Site =  http://members.chello.at/rene.weichselbaum/etask.el

Author contact
http://members.chello.at/rene.weichselbaum/contact.html

FreeBSD mantainer:  dryice at liu.com.cn

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Eduard Bloch]

#include 
* Jochen Voss [Mon, Jul 11 2005, 10:17:56AM]:

> > Are we sure we want someone who is routinely this incompetent
> >  to help with bug triage? Seems to me we would be bette off without
> >  such substandard help; anyone this incompetent is probably creating
> >  more problems than they are solving.
> 
> Great idea!  We can even get mor out of this, if we install some
> kind of challenge response system: every time you upload a package

To be honest, I had a similar idea before: every upload has to be
approved by at least one additional Debian developer. This would
decrease the probability for really broken uploads (because of stupid
mistakes or beeing on drugs or whatever).

The work itself can be automated well, I imagine an IRC channel
#debian-uploads-looking-for-approval.

Regards,
Eduard.

-- 
Emperor Turhan: How will this end?
Kosh Naranek: In fire.
 -- Quotes from Babylon 5 --


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Frank Lichtenheld]

On Mon, Jul 11, 2005 at 06:58:15PM +0200, Max Vozeler wrote:
> A first step could be to make the lintian.d.o scripts run on a lintian.d
> style directory of scripts, if that sounds reasonable to the people who
> run that service (Josip Rodin?). That would make it pretty easy to build
> lists of privileged files, plug in source code scanners, greps for /tmp/
> and everything else we can come up with.

lintian.d.o is currently maintained by jeroen and me (kind of, it's
currently somewhat broken and I'm not yet able to find out exactly why,
but that's another story). But that code is really lintian specific.

Nevertheless, we're indeed currently working on such a framework as
you mention. On our list of tests to run are currently install tests
(with liw's piuparts), rebuild tests (with pbuilder I think) and
lintian (perhaps linda, too?). Adding new tests should be not a
great problem once we have the infrastructure up.

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: Free Beer: Need packaging assistance...

[Adrian von Bidder]

On Wednesday 06 July 2005 23.15, Mikael Olenfalk wrote:

> So if there is a DD living in Stockholm, Sweden; I'm would be pleased
> to pay for dinner+beer (or equivalent) for a laptop-packaging-session

Debian is about free speech, not free beer, so you can have that cheaper:  
just allow the DD to talk to you for the whole evening/afternoon.

(Ok, I'll shut up again now.  Sorry for not contributing anything helpful.)
-- vbi


-- 



pgp4ykiPIpoHR.pgp
Description: PGP signature

Bug#317811: ITP: gnome-keyring-sharp -- a set of CIL bindings for the GNOME Keyring API

[Guido Trotter]

Package: wnpp
Severity: wishlist
Owner: Guido Trotter <[EMAIL PROTECTED]>

* Package name: gnome-keyring-sharp
  Version : 0.0.1
  Upstream Author : Russell Cloran <[EMAIL PROTECTED]>
* URL : http://russell.rucus.net/2005/gnome-keyring-sharp/
* License : LGPL
  Description : C# bindings for the GNOME Keyring API

GNOME Keyring is a system which allows you to store passwords and other
sensitive data across GNOME applications. It provides an API to access
this information, as well as a daemon to manage it.

gnome-keyring-sharp is a set of CIL bindings for the GNOME Keyring API,
written in C#. 

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11.10tie00
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Fiera eFitness 4-5-6 Nov.2005

[mimmo12]

Title: eFITNESS FIERA





  
 
  NEWS...NEWS...NEWS.. 
INOLTRA QUESTA PAGINA AD ALTRI TUOI AMICI 
Per 
  favore non inoltrare se non hai l'autorizzazione dai tuoi conoscenti 
   
  

  


   
 
  

  


  

  SE 
VUOI CONFERMARE L'ISCRIZIONE CLICCA SU QUESTO COLLEGAMENTO 
www.efitnessfiera.it/iscrizione_newsletter.asp 


  



Se vuoi cancellarti dalla nostra Mailing List, clicca sul seguente linkhttp://www.fitnesshowfiera.com.br/gestione_newsletter/news/[EMAIL PROTECTED]

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Adrian von Bidder]

On Friday 08 July 2005 14.33, Javier Fernández-Sanguino Peña wrote:
> TODO: Should this be in  
> http://wiki.debian.net/index.cgi?ReleaseProposals ?

It's  - which contains a short 
disclaimer on its difference vs. ReleaseProposals.

Manoj:
> Mere wishlists by random bystanders are no help to anyone.

I think I can agree with your sentiment that they don't get things done.  
OTOH I feel it worthwhile to collect these ideas on what people are missing 
in Debian - it does help people to find other people with interests in 
similar areas, and I'd argue that the list does no harm.  If you don't feel 
it is helpful to you, just ignore it.

regards
-- vbi

-- 
Bescheidenheit ist so beliebt, weil sie einem die Arroganz erleichtert.


pgpWK31VqwWEo.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Adrian von Bidder]

On Saturday 09 July 2005 00.39, Steve Langasek wrote:
> On Fri, Jul 08, 2005 at 03:49:36PM +0200, Santiago Vila wrote:

> > IMHO, we should keep dummy packages around for at least two releases,
> > to support upgrades which skip one release.
>
> In practice, upgrades that skip a release are not supported.  There was
> no way at all that upgrades from potato->sarge could have been supported,
> and it's not a goal of the release team to support direct upgrades from
> woody->etch.

While it is only sensible to state in bold, big, fat, huge letters that 
upgrades over two releases are not supported, breakting these on purpose 
does nobody any good when keeping this minor support in doesn't cost more 
than 4k on the mirror network.

cheers
-- vbi

-- 
Beware of the FUD - know your enemies. This week
* Patent Law, and how it is currently abused. *
http://fortytwo.ch/opinion


pgpV5pYml0g0H.pgp
Description: PGP signature

Re: GCC version change / C++ ABI change

[Adrian von Bidder]

On Monday 04 July 2005 11.51, Horms wrote:
> I am not sure about 3.4's ability to compile 2.4.27, but
> it seems unlikely to me that all of the gcc versions you mention above
> will be omitted from etch.

I'm quite confident that the release team and/or gcc maintainers will agree 
that 'is needed to compile 2.4 kernels' is a big enough reason to keep some 
gcc version around if Debian gets to the point to decide which old gcc 
versions should be shipped or dropped.

cheers
-- vbi

-- 
featured link: http://fortytwo.ch/gpg/subkeys


pgpnSHnGznqSt.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Adrian von Bidder]

On Monday 11 July 2005 09.59, Javier Fernández-Sanguino Peña wrote:
> On Sat, Jul 09, 2005 at 08:25:11AM -0500, Manoj Srivastava wrote:
> > This is a huge list, with probably 0 chances of getting
> >  accomplished.  How about this: remove every single item from the list,
> >  and only add items when there are people who sign up to be responsible
> >  for the work involved in actually seeing that item come to fruition?
>
> Errr.. the wishlists with names within brackets are those that have been
> taken over by somebody, the ones that don't are up for grabs.

Except that it isn't true, exactly.  At least in my case - the issue I 
suggested is exactly one of the cases that annoys Manoj so much.

cheers
-- vbi
-- 
"Oh, mi hai uccisa!"
-- Dal film "Quintet"


pgppFGKgKSmdJ.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Lars Wirzenius]

ma, 2005-07-11 kello 19:40 +0200, Eduard Bloch kirjoitti:
> To be honest, I had a similar idea before: every upload has to be
> approved by at least one additional Debian developer. This would
> decrease the probability for really broken uploads (because of stupid
> mistakes or beeing on drugs or whatever).
> 
> The work itself can be automated well, I imagine an IRC channel
> #debian-uploads-looking-for-approval.

That's a lot of manual work and that is, almost by definition, bad.
Create automated checks instead. For example, just to plug my own
current thing, don't accept the upload unless it passes piuparts
checking, that is, can be installed and removed without ill effects.

And, because Steven Kowalik is sitting on my left side right now,
talking loudly to his laptop, run linda on it and see that it doesn't
find any errors. (Add a way to have an override file for the few cases
when linda is wrong and the package is right, or, of course, fix linda.)

But don't make programmers do more manual work than they absolutely have
to. That won't do any good in the long run.


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

Hosting for Debian machine

[Adrian von Bidder]

On Thursday 07 July 2005 14.13, martin f krafft wrote:
> > If you can help the Debian Project out in this area, we would
> > `appreciate it`_.  Please contact the Debian host system administration
> > team at [EMAIL PROTECTED], and feel free to contact me
> > at [EMAIL PROTECTED] as well.
>
> The ETH Zurich agreed to host one machine. I have sent email to
> debian-admin on 27 June, followed by a reminder on 6 July. I have
> not heard anything from them. The people at ETH are wondering what's
> going on...

Any news on that?

(I'm not involved, but as a ETH alumni, I'm obviously curious. And I just 
wondered if you - Branden - know about this already since madduck didn't cc 
his email to you.)

cheers
-- vbi


pgpmCZAT5Hplp.pgp
Description: PGP signature

Updating dpkg-cross: file moving question

[Nikita V. Youshchenko]

Hello.

I'm going to update dpkg-cross package, to follow post-sarge changes in 
dpkg and company.

Dpkg-cross is a tool to create cross-compile environment, useful to 
cross-compile debian packages and other software.
One of dpkg-cross's functions is to process a native library or libdev 
package for some arch, and turn it into arch-all packages that install 
libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and headers 
info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm cross-compile 
environment was created under /usr/arm-linux/. This was consistent with 
cross-binutils and cross-gcc packages file placement.

In newer dpkg tools, target names changed, e.g. arm-linux turned into 
arm-linux-gnu. So, to keep system consistent, dpkg-cross should now place 
things under /usr/arm-linux/gnu/.

The question is - how to process existing cross-compile environment, 
created by earlier versions of dpkg-cross.

I am thinking to make the following trick. In postinst of new dpkg-cross, 
it will check for /usr/arm-linux, /usr/powerpc-linux/, and other places 
where packages created by earlier versions could place files. If any of 
such directories is found:
- a directory with the new name will be created if not exists yet,
- complete file hierarchy from the old directory will be copied to the new 
directory,
- old directory will be replaces with a sympink to the new one.

Looks that this procedure is more or less safe. E.g. removals of packages 
which files have been moved in this way, would remove correct files.

Is it OK to go this way? Maybe, something better could be suggested?

This is still not perfect: for example, it is never safe to remove created 
symlinks; also cross-compile environment will become broken if -arch-cross 
packages created with old and new dpkg-cross are mixed and dpkg-cross 
itself is either old or not installed. However, isn't it better than doing 
nothing (in which case any mixing of -arch-cross packages created by old 
and new dpkg-cross will be broken)?

Nikita


pgpUt8KBDwqFY.pgp
Description: PGP signature

Re: [Debian Printing] Formation of a Printing Group

[Henrique de Moraes Holschuh]

On Tue, 05 Jul 2005, Roger Leigh wrote:
> Rob Taylor <[EMAIL PROTECTED]> writes:
> > On Mon, 2005-06-27 at 11:27 +0900, Kenshi Muto wrote:
> >> At Sun, 26 Jun 2005 21:11:22 +0100,
> >> Roger Leigh wrote:
> >> > This mail is just to test the water to see if there is any interest in
> >> > forming a printing group for coordination between all of the various
> >> > printing packages.
> >> Oh, Masayuki who maintains gs packages and I had thought same idea.
> >> It's very nice to have a place to collaborate together.
> >
> > I'd certainly be interested in joining in on the printing love-fest.
> 
> Super.
> 
> I've requested the creation of debian-printing (#316646).  If anyone
> has anything else to add to the bug, please submit it.

Just be sure to drop us a note when the ML get created, I am all for it, xpp
and hplip/hpijs will join the printing group.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Monitor Acer Digital Svga $ 170.-gtia /Informacion.

[Teknovision]

boundary="--9528434845730730190"
X-Priority: 

Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7Bit

9528434845730730190

This is HTML source of message you composed. Do not modify here.
To modify this message press HTML Messages Editor button.




La Casa del Monitor

Empresa dedicada al reciclado de Monitores para PC

 Solucion en Monitores para PC. Consulta /Compras     [EMAIL PROTECTED] 



ACERVIEW 35C Digital  BLACK NEGRO 

impecables completos

Resolucion 1024 x 768. Stock 100 unidades

se puede adquirir de a uno.

Envios contrareembolso a todo el pais

 

Consulta /Compras     [EMAIL PROTECTED]

 

Con tarjeta de credito con  MERCADOCASH

de www.mercadolibre.com.ar   ID cwolpo

hasta 12 pagos

 

ideal escuelas instituciones 

 

SERVICIO TECNICO.

 

PRECIO FIJO:14' y 15' $49 +iva

  

Costo"0" a empresas:Recicla una parte ypaga con la otra 

 sin dinero.

 Entrega y retiro En Capital Federal y

 zonas cercanas.

 

 

 

SVGA COLOR $170 .- 6 meses de gtia

MONITOR PARA PC Color SVGA

GREMIO-Escuelas-Empresas

 

Consulta /Compras     [EMAIL PROTECTED]

Humboldt 169.Ramos Mejia.(1704)Buenos Aires.Argentina

lunes a viernes de 9 a 18hs sabado de 9.30 a 13.30hs

(011)4658-4576/ 4464-4906 y las 24hs 4678-4188

 

Para remover  eliminar + mail

 

 




9528434845730730190--


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jonas Meurer]

On 11/07/2005 Max Vozeler wrote:
> On Fri, Jul 08, 2005 at 02:33:12PM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > - Encrypted root/swap on the d-i installation.
> 
> I'm planning to work on this- probably during the next few weeks. I hope
> to also get together with Wesley Terpstra and talk about how we can make
> the framework usable for both loop-AES and dm-crypt based setups.

please consider to support luks too. the current cryptsetup package
supports only dm-crypt from christophe saout. luks from clemens
fruhwirth has many advantages over plain dm-crypt, and i guess that it's
quite more common for encrypted disks.

bye
 jonas


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

Re: RFA: etask-el -- Define and manage projects within Emacs with Gantt

[Rich Walker]

Daniel Martins <[EMAIL PROTECTED]> writes:

> Site =http://members.chello.at/rene.weichselbaum/etask.el

You mean

http://members.chello.at/rene.weichselbaum/etask.html

cheers, Rich.

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


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

Re: [Debian Printing] Formation of a Printing Group

[Roger Leigh]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Tue, 05 Jul 2005, Roger Leigh wrote:
>> Rob Taylor <[EMAIL PROTECTED]> writes:
>> > On Mon, 2005-06-27 at 11:27 +0900, Kenshi Muto wrote:
>> >> At Sun, 26 Jun 2005 21:11:22 +0100,
>> >> Roger Leigh wrote:
>> >> > This mail is just to test the water to see if there is any interest in
>> >> > forming a printing group for coordination between all of the various
>> >> > printing packages.
>> >> Oh, Masayuki who maintains gs packages and I had thought same idea.
>> >> It's very nice to have a place to collaborate together.
>> >
>> > I'd certainly be interested in joining in on the printing love-fest.
>> 
>> Super.
>> 
>> I've requested the creation of debian-printing (#316646).  If anyone
>> has anything else to add to the bug, please submit it.
>
> Just be sure to drop us a note when the ML get created, I am all for it, xpp
> and hplip/hpijs will join the printing group.

The list was created today, so it's open for subscription.


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.


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

Re: GCC version change / C++ ABI change

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adrian von Bidder <[EMAIL PROTECTED]> writes:

> On Monday 04 July 2005 11.51, Horms wrote:
>> I am not sure about 3.4's ability to compile 2.4.27, but
>> it seems unlikely to me that all of the gcc versions you mention above
>> will be omitted from etch.
>
> I'm quite confident that the release team and/or gcc maintainers will agree 
> that 'is needed to compile 2.4 kernels' is a big enough reason to keep some 
> gcc version around if Debian gets to the point to decide which old gcc 
> versions should be shipped or dropped.

We even have GCC 2.7.2 in unstable (gcc272).  Does anyone actually use
this anymore, or could it be removed for etch?


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

iD8DBQFC0tQSVcFcaSW/uEgRAltwAJ445XH8bW9IzVFPbbcJs3bY8MaUXgCfa6Ap
LKHHf7hJox+kn8w3Ds5bOI4=
=LvYy
-END PGP SIGNATURE-


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

Re: Updating dpkg-cross: file moving question

[Goswin von Brederlow]

"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:

> Hello.
>
> I'm going to update dpkg-cross package, to follow post-sarge changes in 
> dpkg and company.
>
> Dpkg-cross is a tool to create cross-compile environment, useful to 
> cross-compile debian packages and other software.
> One of dpkg-cross's functions is to process a native library or libdev 
> package for some arch, and turn it into arch-all packages that install 
> libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and headers 
> info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm cross-compile 
> environment was created under /usr/arm-linux/. This was consistent with 
> cross-binutils and cross-gcc packages file placement.

That isn't where the multiarch proposals for Debian and FHS place
files and I think it is best if you follow their lead. Use

/usr/lib/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
/usr/include/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/

> In newer dpkg tools, target names changed, e.g. arm-linux turned into 
> arm-linux-gnu. So, to keep system consistent, dpkg-cross should now place 
> things under /usr/arm-linux/gnu/.
>
> The question is - how to process existing cross-compile environment, 
> created by earlier versions of dpkg-cross.
>
> I am thinking to make the following trick. In postinst of new dpkg-cross, 
> it will check for /usr/arm-linux, /usr/powerpc-linux/, and other places 
> where packages created by earlier versions could place files. If any of 
> such directories is found:
> - a directory with the new name will be created if not exists yet,
> - complete file hierarchy from the old directory will be copied to the new 
> directory,
> - old directory will be replaces with a sympink to the new one.
>
> Looks that this procedure is more or less safe. E.g. removals of packages 
> which files have been moved in this way, would remove correct files.

The target directory would not be removed.

> Is it OK to go this way? Maybe, something better could be suggested?
>
> This is still not perfect: for example, it is never safe to remove created 
> symlinks; also cross-compile environment will become broken if -arch-cross 
> packages created with old and new dpkg-cross are mixed and dpkg-cross 
> itself is either old or not installed. However, isn't it better than doing 
> nothing (in which case any mixing of -arch-cross packages created by old 
> and new dpkg-cross will be broken)?
>
> Nikita

MfG
Goswin


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

$BITNQ$+$i7k:'$^$G(B

[info]

   $B!!!c%U%j!<%a!<%k$+$i$NEPO?$b2DG=$G$9!d(B
  $B!!(B $B!!(Bhttp://www.getluck2.net/?marriage


$B$3$3?t%v7n$G#3#0Be(B, $B#4#0Be(B, $B$=$l0J>[EMAIL 
PROTECTED],A}$($F$*$j$^$9!#(B
$BITNQ$r5a$a$?<[EMAIL PROTECTED],??7u$K=P2q$$$r5a$a$F$$$k%1!<%9$,(B
$BB?$$$h$&$G$9!#%;[EMAIL PROTECTED]"$j$H$$$&$H$3(B
$B$m$G$7$g$&$+!#(B
$BEv%5%$%H$KEPO?$5$l$F$$$k$H$$$&$3$H$O$"$J$?$+$i$NM6$$$rBT$C$F$$$k$H(B
$B$$$&$3$H$K$J$j$^$9!#F;$G$9$l0c$&[EMAIL 
PROTECTED]@<$r$+$1$k$N$H$O0c$$$^$9!#(B
$BM6$$$d$9$$$H;W$$$^$9!#(B
$B$A$g$C$H$7$?;~4V$r8+$D$1$F$4MxMQ$K$J$C$F$_$F$O$$$+$,$G$9$+!)(B


   $B!!!c$^$:$OL5NA%(%s%H%j!<$+$i$I$&$>!d(B
  $B!!(B $B!!(Bhttp://www.getluck2.net/?marriage

$B#P#C=i?4%a(B, $BD>EE8r49$b;W$$$N$^$^$G$9!#%U%j!<%a!<%k$G$NEPO?$bO$OL5$7$G9=$$$^$;$s!#(B
$BG[?.Dd;_$^$G$O(B2$BF|$+$i(B3$BF|$+$+$k>l9g$,$"$j$^$9!#$4N;>52<$5$$!#(B


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

Bug#317825: ITP: dnspython -- ITP: dnspython: DNS module for python

[LaMont Jones]

Package: wnpp
Severity: wishlist


In TLA at http://www.dnspython.org/archives/2005-public/dnspython, I've
chatted with upstream about packaging it.

* Package name: dnspython
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : ITP: dnspython: DNS module for python

(Include the long description here.)

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.12-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

WARNING: CONFIRM YOUR ONLINE BANKING RECORDS

[National Credit Union Administration]

  
  


  
  

  NCUA
  Home | Search | Privacy Policy &
  Accessibility | Site
  Map| Contact Us
   
  

  


  National Credit Union Administration 
  

  Share Insurance |
  Resources for
  Credit Unions | Resources for
  Consumers | News | Search

  
  


  
  
 
 
 
 
 
 
 
 
 
 

 
 
 
 

  
  
 

  

  
 

  


  

  
  

  


  Account Info
  Verification
  
Dear FCU holder account,As part of our security measures,
  we regularly screen activity in Federal Credit Unions (FCU) network.We recently
  noticed the following issue on your account: A recent review
  of your account determined that we require some additional
  information from you in order to provide you with secure
  service. Case ID Number: PP-065-617-349 For your protection,
  we have limited access to your account until additional 
  security measures can be completed. We apologize for any
  inconvenience this may cause. Please log in to your FCU account to
  restore your access as soon as possible.
  You must click the link below and fill in the
  form on the following page to complete the verification 
  process.
  


  

  
  
Click
  here to update your
  accountIn
  accordance with NCUA User Agreement, your account access
  will remain limited until the issue has been resolved.
  Unfortunately, if access to your account remains limited for
  an extended period of time, it may result in further
  limitations or eventual account closure. We encourage you to
  log in to your FCU account as soon as possible to help
  avoid this. We thank you for your prompt attention to this matter. Please
  understand that this is a security measure intended to help
  protect you and your account.
  We apologize for any inconvenience.
  Sincerely, NCUA Account Review Department 
  

  

  

  


  Please do not reply to this e-mail.
Mail sent to this address cannot be answered.

  
  

  
  

  
  

  


  

  
  
About
  NCUA

  
  
The National Credit Union
  Administration (NCUA) is the independent federal
  agency that charters and supervises federal credit
  unions. NCUA, backed of the full faith and credit
  of the U.S. government, operates the National
  Credit Union Share Insurance Fund (NCUSIF)
  insuring the savings of 80 million account holders
  in all federal credit unions and many
  state-chartered credit unions. During the 1990s
  and into the 21st century, credit unions have been
  healthy and growing. Credit union failures remain
  low and the Share Insurance Fund maintains a
  healthy equity level. The National Credit Union
  Administration (NCUA) is comitted to maintain a
  safe environment for over 80 million account
  holders in all federal credit unions and many
  state-chartered credit unions. Protecting the
  security of holders account and of the Federal
  Credit Unions (FCU) network is our primary
  concern. 

  

Re: resolution of licensing with httperf

[Martin Schulze]

Roberto C. Sanchez wrote:
> I have been corresponding with the developer and maintainer of httperf
> [0], which I intend to adopt.  The issue was that a libssl linking
> exception was needed for the package.  They are currently making
> inquiries at HP as to how exaclty go about this from their end, but the
> deevloper and the maintainer both seem quite helpful and want to work
> this out as quickly as possible.  It looks like they will come through
> as soon as they get approval.
> 
> My question is this:  since the package currently exists in
> oldstable/non-US, would it be possible to have the updated package
> (including OpenSSL linking exception and a recompile to link against
> libssl0.9.7) to make it into the next stable update?

No.  The window for new packages into sarge was closed long ago already.

> I think that since there is the potential for previous Woody users to
> have had the package installed and then still have it present after an
> upgrade to Sarge.  In the (unlikely event) that security updates become
> necessary to httperf, the Sarge users won't get them.

True, but that's the case with the other packages that were removed
due to maintainer inactivity or whatever as well.  We'll have to
take that risk.

Regards,

Joey

-- 
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi

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


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

$B=w$O#3#0$+$i(B

[info]

[EMAIL PROTECTED],A}$($F$-$^$7$?!#(B
$B$3$3?t%v7n$G#3#0Be(B, $B#4#0Be(B, $B$=$l0J>[EMAIL 
PROTECTED],A}$($F$*$j$^$9!#(B
$B$$$m$$$mLu$"$j$J$N$+$bCN$l$^$;$s$N$G!"CK$H$7$F<[EMAIL 
PROTECTED]"$k#3#0Be0J>e$N(B
[EMAIL PROTECTED];W$$!"$3$N%a!<%k$rAw$j$^$7$?!#(B

$B#P#C=i?4%a(B, $BD>EE8r49$b;W$$$N$^$^$G$9!#%U%j!<%a!<%k$G$NEPO?$b!d(B
  $B!!(B $B!!(Bhttp://www.getluck2.net/?otona







$B$*O$OL5$7$G9=$$$^$;$s!#(B
$BG[?.Dd;_$^$G$O(B2$BF|$+$i(B3$BF|$+$+$k>l9g$,$"$j$^$9!#$4N;>52<$5$$!#(B


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

****Thanks****

[Dr . Johnson Motene]

ATTN: PRESIDENT/CEO

It gives me a great pleasure to send you this business/partnership proposal. I 
am writing to seek your partnership in a business of mutual benefit. Within the 
South African Department of Transport where I work as the director of audit and 
project implementation, we (my colleagues and I) have in our possession an 
unclaimed payment bills totaling $18,500,000.00 USD. This represent the balance 
of the total contract over invoiced value executed on behalf of my ministry by 
a contracting firm who has left South Africa since the completion of their 
contract work.

We want to transfer abroad with the assistance and co-operation of a foreign 
company or individual who will receive the said funds on our behalf in a 
reliable foreign company or non-company's account with as little or zero 
balance in the account to receive such funds. We have in principles an approval 
to remit these funds to a foreign bank account. The successful remittance of 
these funds can be achieved by filing application for transfer of rights and 
privileges of the said funds and other necessary documents.

I have the authority of my colleagues involved to propose that your consent to 
this transaction will be kept confidential and your assistance highly 
compensated by a portion of the $18.5M United States Dollars. We are willing to 
set aside a portion for taxation purposes if required. Note also that all legal 
documents will be properly secured and documented. Besides your assistance is 
needed as the South African Civil Service Code of Conduct prohibit us from 
operating foreign accounts while still in service 

I can assure you that my partners and I are in a position to make this payment 
claim fruitful, provided you can give us the assurance and guarantee that our 
share will be secured. Visualize this business opportunity as an indirect 
financial resource; also your area of specialization is not a hindrance in the 
successful execution of this transaction. More details will be made available 
to you once you accept this partnership proposal. If interested, please contact 
me immediately on ([EMAIL PROTECTED]), as you are aware I am still in active 
government service as such must be treated strictly confidential.

Thank you.

Yours faithfully.

Dr. Johnson Motene.

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Steve Langasek]

On Mon, Jul 11, 2005 at 07:40:23PM +0200, Eduard Bloch wrote:
> #include 
> * Jochen Voss [Mon, Jul 11 2005, 10:17:56AM]:

> > > Are we sure we want someone who is routinely this incompetent
> > >  to help with bug triage? Seems to me we would be bette off without
> > >  such substandard help; anyone this incompetent is probably creating
> > >  more problems than they are solving.

> > Great idea!  We can even get mor out of this, if we install some
> > kind of challenge response system: every time you upload a package

> To be honest, I had a similar idea before: every upload has to be
> approved by at least one additional Debian developer. This would
> decrease the probability for really broken uploads (because of stupid
> mistakes or beeing on drugs or whatever).

> The work itself can be automated well, I imagine an IRC channel
> #debian-uploads-looking-for-approval.

Why is this a better option than revoking the upload rights of developers
make sloppy uploads?  I don't expect that *requiring* a second set of
eyeballs on uploads will be any more effective than our NM advocate process
currently is.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: resolution of licensing with httperf

[Roberto C. Sanchez]

On Mon, Jul 11, 2005 at 11:04:49PM +0200, Martin Schulze wrote:
> Roberto C. Sanchez wrote:
> > I have been corresponding with the developer and maintainer of httperf
> > [0], which I intend to adopt.  The issue was that a libssl linking
> > exception was needed for the package.  They are currently making
> > inquiries at HP as to how exaclty go about this from their end, but the
> > deevloper and the maintainer both seem quite helpful and want to work
> > this out as quickly as possible.  It looks like they will come through
> > as soon as they get approval.
> > 
> > My question is this:  since the package currently exists in
> > oldstable/non-US, would it be possible to have the updated package
> > (including OpenSSL linking exception and a recompile to link against
> > libssl0.9.7) to make it into the next stable update?
> 
> No.  The window for new packages into sarge was closed long ago already.
> 
I was thinking that this wasn't really a new package, since the changes
are very minor and are mainly for the licensing issue.  Oh well.

> > I think that since there is the potential for previous Woody users to
> > have had the package installed and then still have it present after an
> > upgrade to Sarge.  In the (unlikely event) that security updates become
> > necessary to httperf, the Sarge users won't get them.
> 
> True, but that's the case with the other packages that were removed
> due to maintainer inactivity or whatever as well.  We'll have to
> take that risk.
> 

Thanks for the feedback.

-Roberto

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


pgpphB1oNzTZD.pgp
Description: PGP signature

$B40A4L5NA$NAG?M=PD%%[%9%H$N%"%k%P%$%H(B

[info]

$B(.(,(/(.(,(/(.(,(/(.(,(/(B
$B(-AG(-(-?M(-(-=P(-(-D%(-(B
$B(1(,(0(1(,(0(1(,(0(1(,(0(B
http://awg.webchu.com/?freehost
$B"(%[%9%HBgJg=8!J$*;n$740A4L5NAEPO?#O#K!*!K(B
$B"($9$Y$F%([EMAIL PROTECTED];W$$$r$7$F>.8/$$2T$.!*(B
$B"($*Ajn!&#S>n!&#M>n!&(B
$B%J!<%9!&%9%C%A!<$J$I(B
$B(.(,(/(.(,(/(.(,(/(.(,(/(B
$B(-40(-(-A4(-(-L5(-(-NA(-(B
$B(1(,(0(1(,(0(1(,(0(1(,(0(B
http://awg.webchu.com/?freehost
$B(.(,(/(.(,(/(B
$B(-$*;n$7#O#K(-(B
$B(1(,(0(1(,(0(B
$B"(;E;v$N9g4V!"5YF|$rMxMQ$7$F<}F~%"%C%W$r$7$^$;$s$+!*D64JC1$JI{6H$G$9!#(B
$B!y5.J}$b%j%C%A$K$J$j$^$;$s$+!)(B
http://awg.webchu.com/?freehost

$B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B
$B:#8e!"l9g$OJV?.2<$5$$!#(B
[EMAIL PROTECTED]
$B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B

18$B:PL$K~$OMxMQ6X;_$G$9!#(B


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

No Failuure With V.

[Stig Morrell]

 

How to save on disclamation  your MEDlCATlONS over 60%.
 
Pha banquet rmazMail Shop  - Successfull and Prov goddess en Way to save your  immaculacy money.
 


  
 sufficiency V

 trainman AG

 mapping L

l sergeantmajor U

  
 metallurgical l
R perspirable A Cl aquamarine A
I honoraria S V intriguing AL
 sanguine M
 and many other.
 
* Best P unthrone RlCES
* alveolate  Worldwide SHlPPlNG
* Total c Irishism onfidentiaIity
* Over 5 milIio comply n customers
 
Have a nice d tussore ay!

Fiera eFitness 4-5-6 Nov.2005

[mimmo12]

Title: eFITNESS FIERA





  
 
  NEWS...NEWS...NEWS.. 
INOLTRA QUESTA PAGINA AD ALTRI TUOI AMICI 
Per 
  favore non inoltrare se non hai l'autorizzazione dai tuoi conoscenti 
   
  

  


   
 
  

  


  

  SE 
VUOI CONFERMARE L'ISCRIZIONE CLICCA SU QUESTO COLLEGAMENTO 
www.efitnessfiera.it/iscrizione_newsletter.asp 


  



Se vuoi cancellarti dalla nostra Mailing List, clicca sul seguente linkhttp://www.fitnesshowfiera.com.br/gestione_newsletter/news/[EMAIL PROTECTED]

failed to set 0600 permissions on password file /etc/samba/smbpasswd

[Rob Kayzer]

Got rid of this message by setting 
SELinux samba options "Allow samba users to share home directories"and 
"Disable SELunix protection for smbd daemon".
 
Rob K. 

Old bugs list not being updated?

[Elizabeth Cherry]

http://master.debian.org/~ajt/oldbugs.html is linked to from the 
Developer's Corner on the web page, and I like to look at it when 
looking for bugs to poke at.  But it hasn't been updated since
September 2004.

Any chance of a new version?  Maybe accessible directly from the BTS
entry point?


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

Bug#317823: ITP: creloaded -- creloaded is a web commerce system based on oscommerce

[Tim Peeler]

Package: wnpp
Severity: wishlist
Owner: Tim Peeler <[EMAIL PROTECTED]>


* Package name: creloaded
  Version : 6.1.5
* URL : http://creloaded.com/
* License : GPL
  Description : creloaded is a web commerce system based on oscommerce


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#317828: ITP: libarray-iterator-perl -- simple class for iterating over Perl arrays

[Frank Lichtenheld]

Package: wnpp
Severity: wishlist
Owner: Frank Lichtenheld <[EMAIL PROTECTED]>

* Package name: libarray-iterator-perl
  Version : 0.0.5
  Upstream Author : stevan little <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/CPAN/authors/id/S/ST/STEVAN/Array-Iterator-0.05.tar.gz
* License : Perl (GPL/Artistic)
  Description : simple class for iterating over Perl arrays

not really figured out a long description yet...

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


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

75% Off for All New Software.

[Aloys]

All the Software You'll Ever Need To Successfully Make Money Online!
http://sfkr.ovs3956hlg6v37o.kashandkdkk.org




Daylight, in my mind, the night faded.  
For centuries, theologians have been explaining the unknowable in terms of the-not-worth-knowing. 




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

first official version of dbconfig-common now in unstable

[sean finney]

hello folks,

i'm happy to announce that after somewhere close to 8 months of
development and testing, dbconfig-common is now uploaded to unstable
and ready for widespread use by other packages in debian.

if you've missed out on my previous discussions about what dbconfig-common
can do, here's what's in debian/control:

 dbconfig-common presents a policy and implementation for
 managing various databases used by applications included in
 debian packages.
 .
 dbconfig-common can:
  * support mysql and postgresql based applications
  * create databases and database users
  * access local or remote databases
  * upgrade/modify databases when upstream changes database structure
  * remove databases and database users
  * generate config files in many formats with the database info
  * import configs from packages previously managing databases on their own
  * prompt users with a set of normalized, pre-translated questions
  * handle failures gracefully, with an option to retry.
  * do all the hard work automatically
  * work for package maintainers with little effort on their part
  * work for local admins with little effort on their part
  * comply with an agreed upon set of standards for behaviour
  * do absolutely nothing if it is the whim of the local admin
  * perform all operations from within the standard flow of debian
package maintenance (no additional skill is required of the local
admin)

so if you maintain a package that has to deal with mysql/postgresql
databases and you're tired of having to deal with home-rolled, obfuscated,
complicated, and/or buggy code, i highly suggest you check it out!

i would love to hear back from those who start using in their packages.
please send any questions/comments/complaints/bugs to the dbconfig-common
mailing list: [EMAIL PROTECTED]


sean

-- 


signature.asc
Description: Digital signature

Re: Updating dpkg-cross: file moving question

[Nikita V. Youshchenko]

> > Dpkg-cross is a tool to create cross-compile environment, useful to
> > cross-compile debian packages and other software.
> > One of dpkg-cross's functions is to process a native library or libdev
> > package for some arch, and turn it into arch-all packages that install
> > libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and headers
> > info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm cross-compile
> > environment was created under /usr/arm-linux/. This was consistent
> > with cross-binutils and cross-gcc packages file placement.
>
> That isn't where the multiarch proposals for Debian and FHS place
> files and I think it is best if you follow their lead. Use
>
> /usr/lib/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
> /usr/include/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/

Hmm...

All cross toolchains I've seen up to today, both free and commercial, use 
include/ and lib/ subdirectories of some prefix.

Cross-ld from binutils use ${prefix}/${target}/lib these are the path to 
search libraries.

Cross-gcc also uses ${prefix}/${target}/include and  
${prefix}/${target}/lib.

This is how things used to work for years.
There should be a very serious reason to change this.

> > In newer dpkg tools, target names changed, e.g. arm-linux turned into
> > arm-linux-gnu. So, to keep system consistent, dpkg-cross should now
> > place things under /usr/arm-linux/gnu/.
> >
> > The question is - how to process existing cross-compile environment,
> > created by earlier versions of dpkg-cross.
> >
> > I am thinking to make the following trick. In postinst of new
> > dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and
> > other places where packages created by earlier versions could place
> > files. If any of such directories is found:
> > - a directory with the new name will be created if not exists yet,
> > - complete file hierarchy from the old directory will be copied to the
> > new directory,
> > - old directory will be replaces with a sympink to the new one.
> >
> > Looks that this procedure is more or less safe. E.g. removals of
> > packages which files have been moved in this way, would remove correct
> > files.
>
> The target directory would not be removed.

Yes, I see.
This is one more drawback.

In future dpkg-cross versions, I'll probably make -arch-cross packages to 
provide 'dpkg-cross-layout--', and conflict with older 
versions, so inconsistent setup could be more or less easilly avoided if 
layout will ever change in future. Or something similar.

But currently, seems there is no way to avoid inconsistency cleanly, so 
question is - try some tricks to avoid it in 'standard cases', by the cost 
of mentioned drawbacks, or just add a news entry asking users to 
regenerate all -arch-cross packages with new dpkg-cross, and leave the 
rest to the users.

Nikita


pgprCjhgnfdxn.pgp
Description: PGP signature

Re: Hosting for Debian machine

[martin f krafft]

also sprach Adrian von Bidder <[EMAIL PROTECTED]> [2005.07.11.2211 +0300]:
> > The ETH Zurich agreed to host one machine. I have sent email to
> > debian-admin on 27 June, followed by a reminder on 6 July. I have
> > not heard anything from them. The people at ETH are wondering what's
> > going on...
> 
> Any news on that?

James Troup said here on debconf5 that there was an overwhelming
response and the team has not yet had the time to sort through them
all. This is what I told the ETH and now we are just patiently
waiting.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
stupidity management for the superuser
is a user space issue in unix systems.
   -- alan cox


signature.asc
Description: Digital signature