: Typescript/javascript
Description : Generate reports of the common details used by Node.js
packages
Generate reports of the common details used by Node.js packages
This package generate reports of common software installed on our computer,
including browser version, Node.js version, Operating
On Mon, 2022-06-06 at 16:52 +0200, Marco d'Itri wrote:
> Maybe the usual suspects which require significant porting work could
> start documenting instructions for porters in debian/README.source.
Thats a good start, but doesn't provide a standard way to find out
which packages contain such instr
On Jun 06, Holger Levsen wrote:
> > Is this really worth the effort, considering that probably RISC-V is
> > going to be our last port for a very long time?
> you mean like 640kb should be enough for everyone? :)
More like "free ABI is eating the world".
I do not see much future for the archite
On Mon, 2022-06-06 at 10:47 +0200, Marco d'Itri wrote:
> Is this really worth the effort, considering that probably RISC-V is
> going to be our last port for a very long time?
There are at least two or three new architectures in the pipeline
already. loongarch64 from Loongson was already mention
On Mon, Jun 06, 2022 at 10:47:38AM +0200, Marco d'Itri wrote:
> Is this really worth the effort, considering that probably RISC-V is
> going to be our last port for a very long time?
you mean like 640kb should be enough for everyone? :)
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(deb
On Mon, Jun 06, 2022 at 10:47:38AM +0200, Marco d'Itri wrote:
> On Jun 06, Paul Wise wrote:
>
> > There are lots of packages that need porting to every new architecture
> > that comes along. There are others that don't require porting but
> > benefit in some way from porting to some aspect of the
在 2022/6/6 16:47, Marco d'Itri 写道:
> Is this really worth the effort, considering that probably RISC-V is
> going to be our last port for a very long time?
Perhaps loongarch64 will the next port.
https://wiki.debian.org/Ports/loongarch64
Some codes of loongarch64 had been added to upstream ke
On Jun 06, Paul Wise wrote:
> There are lots of packages that need porting to every new architecture
> that comes along. There are others that don't require porting but
> benefit in some way from porting to some aspect of the architecture.
Is this really worth the effort, considering that probabl
I like this idea. I would personally recommend adding negative priority
as well. You know, it is completely meaningless to port some high performance
scientific computing software to archs like armel...
Meanwhile, different packages varies in the difficulty to port as well.
A software that heavily
Hi all,
There are lots of packages that need porting to every new architecture
that comes along. There are others that don't require porting but
benefit in some way from porting to some aspect of the architecture.
In order to help porters to prioritise those packages and quickly add
support for t
Ansgar Burchardt writes ("Re: Want to make salsa advertise contact and source
code details [and 1 more messages]"):
> That seems like an horrible maintenance nightmare just to avoid even
> talking to upstream...
OK, so does someone in Debian, maybe from the Salsa team, have any
On Fri, 2018-05-25 at 18:57 +0100, Ian Jackson wrote:
> Another way to achieve the effect I want would be to do it post-hoc in
> a reverse proxy. I see that salsa is using Apache as a reverse proxy.
> So perhaps the right answer is to do this in Apache. It seems quite
> hacky, but if it's thought
Ian Jackson writes ("Re: Want to make salsa advertise contact and source code
details [and 1 more messages]"):
> Oh, quite possibly. I don't know anything about gitlab's plugin
> system.
... I don't think so, in fact. I found this documentation:
https://do
Jonathan Carter writes ("Re: Want to make salsa advertise contact and source
code details [and 1 more messages]"):
> On 25/05/2018 19:16, Ian Jackson wrote:
> > Can you please tell me what you think the appropriate path or venue is
> > for me to pursue this diagreement ?
On Fri, 25 May 2018, Ian Jackson wrote:
> Alexander Wirt writes ("Re: Want to make salsa advertise contact and source
> code details [and 1 more messages]"):
> > It was a decision by the team to disallow any patch that is not
> > really really needed for functi
*rings chimes*
On 25/05/2018 19:16, Ian Jackson wrote:
> Can you please tell me what you think the appropriate path or venue is
> for me to pursue this diagreement ?
I notice GitLab has a plugin system, would it be possible to affect that
change in a plugin? That way it's at least not a patch to
Alexander Wirt writes ("Re: Want to make salsa advertise contact and source
code details [and 1 more messages]"):
> It was a decision by the team to disallow any patch that is not
> really really needed for function. Please submit your patch
> upstream.
I see. I'm af
On Fri, 25 May 2018, Geert Stappers wrote:
> On Fri, May 25, 2018 at 02:54:17PM +0200, Alexander Wirt wrote:
> > On Fri, 25 May 2018, Ian Jackson wrote:
> > >
> > >
> > > But, I find this response worrying. It makes me wonder whether Salsa
> > > is in fact really Free Software, for Debian. I d
On Fri, 25 May 2018, Ian Jackson wrote:
> Alexander Wirt writes ("Re: Want to make salsa advertise contact and source
> code details [and 1 more messages]"):
> > > Can you point me to the source code for Salsa's gitlab instance,
> > > please ?
> > ht
Alexander Wirt writes ("Re: Want to make salsa advertise contact and source
code details [and 1 more messages]"):
> > Can you point me to the source code for Salsa's gitlab instance,
> > please ?
> https://salsa.debian.org/salsa/gitlab-ce
I think I see where to
On Fri, 2018-05-25 at 17:16 +0200, Geert Stappers wrote:
> Not knowing who is "we", but the thing I want to says is
>
> Do not ask for a lighter load,
> but ask for more shoulders to carry the load.
Asking for a lighter load has given us the wheel, washing machines,
dishwashers, computers, an
On Fri, May 25, 2018 at 02:54:17PM +0200, Alexander Wirt wrote:
> On Fri, 25 May 2018, Ian Jackson wrote:
> >
> >
> > But, I find this response worrying. It makes me wonder whether Salsa
> > is in fact really Free Software, for Debian. I don't want to suck
> > energy out of the Salsa team, but:
On Fri, 25 May 2018, Ian Jackson wrote:
> Quoting my own other mail for more context:
>
> Ian Jackson writes ("Re: Want to make salsa advertise contact and source code
> details"):
> > Alexander Wirt tells me that that feature is "EE only", ie AIUI
>
Quoting my own other mail for more context:
Ian Jackson writes ("Re: Want to make salsa advertise contact and source code
details"):
> Alexander Wirt tells me that that feature is "EE only", ie AIUI
> that the Gitlab company have kept that feature proprietary.
>
On Fri, 25 May 2018, Ian Jackson wrote:
> Sean Whitton writes ("Re: Bug#864354: Bug #864354 in marked as
> pending"):
> > Thank you for advocating on behalf of users who are not in a position to
> > use the web form, Ian.
>
> Thanks for your support, Sean. I have submitted:
>
> https://salsa
Ian Jackson writes ("Want to make salsa advertise contact and source code
details"):
> https://salsa.debian.org/salsa/support/issues/77
>Please provide web page footer on every page with service information
>
> In response to the latter, Alexander Wirt writes:
>
&g
Sean Whitton writes ("Re: Bug#864354: Bug #864354 in marked as
pending"):
> Thank you for advocating on behalf of users who are not in a position to
> use the web form, Ian.
Thanks for your support, Sean. I have submitted:
https://salsa.debian.org/salsa/webhook/merge_requests/7
Improve ema
that delivers details about domain names
`tld.js` is a Node.js module written in JavaScript to work against complex
domain names, subdomains and well-known TLDs.
.
It answers with accuracy to questions like what is host's (sub)domain, or is
its TLD a well-known one?
Just anothe
: Expat
Programming Lang: JavaScript
Description : Get details about the current Continuous Integration
environment
: bash
Description : trace disk I/O with details including latency
Traces disk I/O at the block device interface, using the block:
tracepoints. This can help characterize the I/O requested for the
storage devices and their resulting performance. I/O completions can
also be studied event-by-event
: JavaScript
Description : libuv errno details exposed - Node.js module
errno is a Node.js module which exposes more details of libuv errors.
.
When you need more details about Node.js errors, errno provides the
mappings
directly from libuv so you can use them in your code.
.
Node.js is an event
other details of an IP
IP2Location C library enables the user to find the country, region, city,
coordinates, zip code, time zone, ISP, domain name, connection type, area code,
weather, MCC, MNC, mobile brand name, elevation and usage type that any IP
address or hostname originates from. It
mail: see transcript for
details
Recipient: reghunthan.subh...@metlifealico.com
Date: 2013-09-04 - 05:42:06
Please contact local helpdesk for support.
Alico Security
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
Hi.
Le jeudi 06 octobre 2011 à 21:26 -0400, David Prévot a écrit :
> Le 06/10/2011 20:43, Peter Samuelson a écrit :
> >
> > [Olivier Berger]
> >> For users, which don't read d-d-a and receive such emails (below),
> >> it's a bit unclear what's really happening, IMHO :-/
> >
> > Ummm ... don't we
for details!
Have a great 4th of July - We're looking forward to hearing from you.
: driver module that encapsulates the details of formatting a
LaTeX document
The LaTeX::Driver module encapsulates the details of invoking the Latex
programs to format a LaTeX document. Formatting with LaTeX is complicated;
there are potentially many programs to run and the output of those
I have a new email address!You can now email me at: [EMAIL PROTECTED]
I'm Nicole Plz i want ur urgent help to transfer US10.5M into ur bank account
for investment purpose
- Nicole Kalou
ATTENTION!
A message you recently sent to a 0Spam.com user with the subject "Returned
mail: see transcript for details" was not delivered because they are using the
0Spam.com anti-spam service. Please click the link below to confirm that this
is not spam. When you confirm, this m
www.cpan.org/authors/id/Z/ZE/ZEFRAM/Data-Integer-0.001.tar.gz
* License : Perl (GPL/Artistic)
Programming Lang: Perl
Description : Perl modules handling details of the native integer data
type
This module is about the native integer numerical data type. A native
integer is one of
The message was not delivered due to the following reason:
Your message was not delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there i
You are receiving this email because you recently sent a message to Pangolin,
or because a spammer is using your email address as the "FROM" address when
sending an email to a discontinued email box at Pangolin.
If you intended to contact Pangolin, your message unfortunately has not been
deliv
I have a new email address!You can now email me at: [EMAIL PROTECTED]FINANCIAL PROPOSAL OF $32M WITH YOUR DEFINITE DETAILS OF INTEREST FROM JULIAN P FOERSTER LONDON- JulianPThurston Thurston
On Thu, 04 Aug 2005 19:08:22 -0500, John Hasler <[EMAIL PROTECTED]> said:
> Peter Samuelson writes:
>> There is no need for dumbing down descriptions for things
>> non-technical users aren't going to be selecting anyway.
> One can be a highly technical user of a package without knowing (or
> car
On Wed, 03 Aug 2005 09:16:23 +0200, Benjamin Mesing <[EMAIL PROTECTED]> said:
> Especially details like "written in C++" should be left to the
> debtags system as there is no use for the end user.
I am a potential end user for the vast majority of packages in
Deb
On Tue, 02 Aug 2005 22:51:11 -0700, Dustin Harriman
<[EMAIL PROTECTED]> said:
> Wouldn't it make sense that debtags and Package Descriptions not do
> redundant work of each other?
But Debtags information is not yet integrated into the
package selection front-ends, like the description
Peter Samuelson writes:
> I meant legible and searchable to ignorant people.
Everyone is ignorant in some areas. Many intelligent and highly skilled
people know little about programming.
> It should go without saying that all package descriptions should be
> legible and searchable for their res
[John Hasler]
> > So I'd suggest concentrating on the 3% of packages non-technical users
> > might actually want to select manually, and making sure those have
> > legible and searchable descriptions.
>
> Technical users don't deserve legible and searchable descriptions?
I meant legible and sear
Peter Samuelson writes:
> There is no need for dumbing down descriptions for things non-technical
> users aren't going to be selecting anyway.
One can be a highly technical user of a package without knowing (or caring)
squat about the language it is implemented in. Descriptions should focus
on th
[Dustin Harriman]
> 1) Package descriptions should tend towards readers like grandma by
> default (ie. are as general as possible by default), and
What about the majority of packages in Debian? You know, the ones your
hypothetical ancestor would never wish to install explicitly, under any
circum
Hello,
> If the debtags also get searched when she does a simple search, then
> great. This will depend on how seamlessly debtags get integrated into
> package managers (like Synaptic's) search facilities (for example, a
> simple search by default, then an "Advanced" button to expand the searc
Benjamin Mesing wrote:
However I have to say that I disagree with you in some points. You are
correct, that the package description should be as non technical as
possbile, without underminining the usefullness of it.
Yes, I agree. Instead of the "absolutes" I proposed, perhaps it still
make
some points. You are
correct, that the package description should be as non technical as
possbile, without underminining the usefullness of it. Especially
details like "written in C++" should be left to the debtags system as
there is no use for the end user. However not every description
the geek, I think the Package Description should
cater to grandma. I think the package desription should state the
purpose of the software as it relates to the real world, whenever
possible: eg. "helps you easily keep lists of contact information on
people along with details like their birthdays&qu
On Sat, Jul 23, 2005 at 01:30:24AM -0500, Manoj Srivastava wrote:
> On Thu, 21 Jul 2005 12:33:32 -0300, Ben Armstrong <[EMAIL PROTECTED]> said:
>>> 2. Programs written in obscure languages may prove unmaintainable
>>> if the original developer disappears. Besides threatening
>>> obsoles
sential qualities that help a
> typical user decide whether or not they want to try the package.
> This is by no means a "dumbing down" of package descriptions. The
> process can start now, both with the voluntary removal by
> maintainers of non-essential details from their own descriptio
"dumbing down" of package descriptions. The process can start
now, both with the voluntary removal by maintainers of non-essential
details from their own descriptions and supporting the development of
debtags.
Ben
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sat, 23 Jul 2005 08:32:50 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]>
said:
> On Sat, 23 Jul 2005, Manoj Srivastava wrote:
>>> A 'normal' user doesn't know what C, C++ and Perl are.
>>
>> The "user" I am creating packages for does. I am not really that
>> interested in working for user
On Thu, 21 Jul 2005 12:33:32 -0300, Ben Armstrong <[EMAIL PROTECTED]> said:
>> 2. Programs written in obscure languages may prove unmaintainable
>> if
>> the original developer disappears. Besides threatening
>> obsolescence, this can be a security issue.
> You've furnished a reason *not*
On Sat, 23 Jul 2005, Manoj Srivastava wrote:
A 'normal' user doesn't know what C, C++ and Perl are.
The "user" I am creating packages for does. I am not really
that interested in working for user who do not know the distinction,
personally speaking.
So your "personal" target user migh
On Thu, 21 Jul 2005 15:08:43 -0300, Ben Armstrong <[EMAIL PROTECTED]> said:
> On Thu, 2005-07-21 at 19:58 +0200, Thijs Kinkhorst wrote:
>> nstead of putting it in the first sentence, the second paragraph
>> would be a fine place to mention details like this, satisfyi
On Thu, 21 Jul 2005 16:02:21 +0200, Olaf van der Spek <[EMAIL PROTECTED]> said:
> On 7/21/05, Thaddeus H. Black <[EMAIL PROTECTED]> wrote:
>> I see another side to it, however. At least seven reasons occur to
>> me why a user might care what language a program is written in.
> A 'normal' user d
On Wed, Jul 20, 2005 at 02:47:22PM -0500, Steve Greenland wrote:
> On 20-Jul-05, 10:47 (CDT), "W. Borgert" <[EMAIL PROTECTED]> wrote:
> > what do you think about the usefulness of technical (and other
> > strange) details in package description?
>
>
> On Wed, 2005-07-20 at 18:13 +0200, Nico Golde wrote:
> > I think one reason could be that some poeple would rather
> > install a programm in a language they know and they are able
> > to debug. Just a guess.
On Wed, Jul 20, 2005 at 01:41:31PM -0300, Ben Armstrong wrote:
> Debtags "facets"[0] ar
On Thu, 2005-07-21 at 19:58 +0200, Thijs Kinkhorst wrote:
> nstead of putting it in the first sentence, the second paragraph would
> be a fine place to mention details like this, satisfying both novice and
> advanced users.
But why bother, when debtags does "implemented-in"
y). So
it's perfectly ok to mention the programming language, but not at the
start of the description.
nstead of putting it in the first sentence, the second paragraph would
be a fine place to mention details like this, satisfying both novice and
advanced users.
Regards,
Thijs
si
On Thu, 2005-07-21 at 13:45 +, Thaddeus H. Black wrote:
> 1. Compiled programs (C, C++, Fortran 77, Ada, ...) usually run leaner
> and faster than do interpreted ones (Perl, Python, Ruby, ...).
In general, algorithm choice is much more important than language.
Also, the language the main prog
Jon Dowland writes:
> I think you are expecting people to say C++, and on the other hand, Perl:
> However, I think perl for both :-)
I agree.
--
John Hasler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, 21 Jul 2005, Thaddeus H. Black wrote:
I see another side to it, however. At least seven reasons occur to me
why a user might care what language a program is written in.
1. Compiled programs (C, C++, Fortran 77, Ada, ...) usually run leaner
and faster than do interpreted ones (Perl, Py
On Thu, Jul 21, 2005 at 01:45:55PM +, Thaddeus H. Black wrote:
> 4. With a language come a mindset, an aesthetic and a development
> culture. Although one cannot speak in absolutes, generally speaking,
> which program would you expect to be more focused and reliable: a
> program written in
Hello,
I started a page on the Debian wiki for this project
http://wiki.debian.net/?PackagesDescriptionsReview
Feel free to edit any part of it.
If everyone agrees, I intend to add some thoughts about the organization
details we could set up (code to track the work and ease the work of the
On 7/21/05, Thaddeus H. Black <[EMAIL PROTECTED]> wrote:
> I see another side to it, however. At least seven reasons occur to me
> why a user might care what language a program is written in.
A 'normal' user doesn't know what C, C++ and Perl are.
On Wed, Jul 20, 2005 at 08:48:46PM +0200, Andreas Tille wrote:
> On Wed, 20 Jul 2005, W. Borgert wrote:
>
> >"Foo is a Perl-based program that..."
> >
> >"libBar is written in C..."
> >
> >"libBang is written in only 42 lines of source code..."
> >
> >"Baz has been written by me..."
> >
> >Do such
In article <[EMAIL PROTECTED]> you wrote:
> But however long it takes, some concerted effort should be able
> to improve things a lot. I would be interested to help with this.
Just file bugs for the above descriptions, I do that also if i find a
description to confusing. Since we have no central
On Thu, Jul 21, 2005 at 12:12:41AM +0100, Jochen Voss wrote:
> Especially for cases like where some research is necessary to find out
> what the package actually does. Some randomly chosen examples where
> the function of the package is not clear to me from reading the
> description:
I looked thr
Hello Steve,
On Wed, Jul 20, 2005 at 05:25:35PM -0500, Steve Greenland wrote:
> I think 2 min/pkg for *spotting* problems is reasonable, but not nearly
> enough for fixing them. Decent writing is non-trivial.
Especially for cases like where some research is necessary to find out
what the package
On 20-Jul-05, 15:18 (CDT), Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> ke, 2005-07-20 kello 14:47 -0500, Steve Greenland kirjoitti:
> Given 15000 packages, and 20 volunteers, and on average two minutes per
> description (given that most descriptions probably only need little or
> no tweaking), thi
Hello
> Maybe it would be worthwhile to
> have a weekend, similar to a bug squashing party, where all descriptions
> are proofread and for those that need it, a proposed new description
> filed as a wishlist bug?
>
> Given 15000 packages, and 20 volunteers, and on average two minutes per
> descri
y package
> descriptions are taken verbatim from the upstream website/whatever.
> This leads to the irrelevant technical details you noted, as well
> as unfounded hyperbola ("Foo is the world's best baz mangler") and
> generally bad writing.
It seems to me that many pack
On 20-Jul-05, 10:47 (CDT), "W. Borgert" <[EMAIL PROTECTED]> wrote:
> what do you think about the usefulness of technical (and other
> strange) details in package description?
While mostly agreeing with the other comments ("libbar is a C library"
is useful/app
On Wed, 20 Jul 2005, W. Borgert wrote:
"Foo is a Perl-based program that..."
"libBar is written in C..."
"libBang is written in only 42 lines of source code..."
"Baz has been written by me..."
Do such descriptions justify bug reports of severity=minor?
Well, I would guess wishlist is the ri
On Wednesday 20 July 2005 08:47 am, W. Borgert wrote:
> Do such descriptions justify bug reports of severity=minor?
Yes, with perhaps one exception:
"libBar is written in C..."
This is almost a sensible start to a description, since the language of
implementation actually matters for a libr
On Wed, Jul 20, 2005 at 06:13:22PM +0200, Nico Golde wrote:
> I think one reason could be that some poeple would rather
> install a programm in a language they know and they are able
> to debug. Just a guess.
You might want to look into the "implemented-in" debtags facet instead, then;
it's probab
On Wed, 2005-07-20 at 18:13 +0200, Nico Golde wrote:
> [...]
> I think one reason could be that some poeple would rather
> install a programm in a language they know and they are able
> to debug. Just a guess.
Debtags "facets"[0] are better for this. Descriptions are supposed to
help *ordinary*
Hi,
* W. Borgert <[EMAIL PROTECTED]> [2005-07-20 18:08]:
> what do you think about the usefulness of technical (and other
> strange) details in package description? I think, those are
> annoying and should be avoided, but maybe I can learn, why they
> are useful. Examples:
&
Hi,
what do you think about the usefulness of technical (and other
strange) details in package description? I think, those are
annoying and should be avoided, but maybe I can learn, why they
are useful. Examples:
"Foo is a Perl-based program that..."
"libBar is written in C..
Re: Rolex Order Details. [claremont]
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 07.02.2005
From: [EMAIL PROTECTED]
Subject: Autroreply from [EMAIL PROTECTED]
Hi
Thank you for writing to [EMAIL PROTECTED] This email has been sent by a robot.
Please note that the email address for HotMat signup emails has changed to
[EMAIL PROTECTED] Please resend your email to the new address.
Sorr
Hi,
* Marc Haber ([EMAIL PROTECTED]) [031128 10:55]:
> I would like to know whether the attacker was able to log in to auric,
> even as unprivilieged user. Did she actively try to compromise auric?
>
> What kind of verification of auric's integrity was done / is planned
> to be done?
>
> [more q
A levelezőm azt hiszi, hogy Matt Zimmerman a következőeket írta:
> On Fri, Nov 28, 2003 at 10:08:45AM +0100, Bernd Eckenfels wrote:
>
> > In the final announcement I would add also a statement about reducing the
> > number of trust relations between the machines and perhaps limiting shell
> > acce
On Fri, Nov 28, 2003 at 10:08:45AM +0100, Bernd Eckenfels wrote:
> In the final announcement I would add also a statement about reducing the
> number of trust relations between the machines and perhaps limiting shell
> access.
It seems fairly clear that this was not an issue because the compromis
hello,
Can't reply to your mail at the moment, I will reply as soon when possible.
If you didn't send a message, please control your pc for virusses.
greetings
christophe
ÄúºÃ£¬ÄúµÄÐÅÏ¢ÎÒÃÇÒÑÊÕµ½£¬ÇëÉÔºò¡£
»òÕßÄú¿É·ÃÎÊÎÒÃǵÄÍøÕ¾ http://www.chinappmarket.com
Á˽â¸üÏêϸµÄÐÅÏ¢¡£
http://www.chinappmarket.com
>This is a multipart message in MIME format
>
>--_NextPart_000_08A9738A
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>See the attached file for details
>--_NextPart_000_08A9738A
>Content-Type: application/octe
Thank you for writing to the MAPS Realtime Blackhole List (RBL) Team.
This email address is used to submit RBL nominations, for RBL removal
requests, and for other communication regarding the MAPS RBL.
If you are writing in regards to an issue relating to the MAPS Relay
Spam Stopper (RSS), MAPS
>This is a multipart message in MIME format
>
>--_NextPart_000_05CF6427
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>Please see the attached file for details.
>--_NextPart_000_05CF6427
>Content-Type: application
Norton AntiVirus found a virus in an attachment you
(debian-devel@lists.debian.org) sent to [EMAIL PROTECTED]
To ensure the recipient(s) are able to use the files you sent, perform a
virus scan on your computer, clean any infected files, then resend this
attachment.
Attachment: details.pif
Viru
Hi,
I'm on holiday from 16th August until 31st August,
but I'll reply to you as soon as I'm back.
For urgent issues, you can try contacting my manager,
[EMAIL PROTECTED], who may be able to help.
This message is automatically generated,
and will only be sent to you once.
--
Alan Burlison
--
tch to Linus in
> the current form then.
> Could you please elaborate on which setup these people used?
> I would be glad to get in contact with one of these for testing
> further patches.
>
> Jens.
So could anyone who experienced the problem with this patch, please contact
eith
99 matches
Mail list logo
