Re: Aborting installation on unsupported systems

2014-09-17 Thread Florian Lohoff 
On Tue, Sep 16, 2014 at 04:37:00PM -0300, Henrique de Moraes Holschuh wrote:
> Well, depends on how strict you want that parsing to be:
> 
> grep -q '^flags.*\' /proc/cpuinfo && echo "SSE2 possible"
> 
> This is good enough on i686 and x86-64, as the architecture itself does not
> tolerate any difference in the flags set between processors.  Maybe enhance
> it a little so that it won't trigger on "^flags_new" or somesuch.

A program which essentially needs SSE2 should check the availability
of those extensions on startup and fail with an error message instead
of an illegal instruction violation.

So checking in an postinst script would be overkill wouldnt it?

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: Aborting installation on unsupported systems

2014-09-16 Thread Andrey Rahmatullin 
On Tue, Sep 16, 2014 at 04:37:00PM -0300, Henrique de Moraes Holschuh wrote:
> > > You might want to pop up a preinst debconf notice which tells the admin
> > > that the package will not run here (with an option to fail the install
> > > if it's an honest mistake).
> > This may require reimplementing some part of the program in shell (in my
> > case it's parsing of /proc/cpuinfo, so it's at least possible, but still).
> 
> Well, depends on how strict you want that parsing to be:
http://git.kernel.org/cgit/utils/cpu/mce/mcelog.git/tree/mcelog.c#n479

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Aborting installation on unsupported systems

2014-09-16 Thread Henrique de Moraes Holschuh 
On Tue, 16 Sep 2014, Andrey Rahmatullin wrote:
> On Tue, Sep 16, 2014 at 12:02:24PM +0200, Matthias Urlichs wrote:
> > You might want to pop up a preinst debconf notice which tells the admin
> > that the package will not run here (with an option to fail the install
> > if it's an honest mistake).
> This may require reimplementing some part of the program in shell (in my
> case it's parsing of /proc/cpuinfo, so it's at least possible, but still).

Well, depends on how strict you want that parsing to be:

grep -q '^flags.*\' /proc/cpuinfo && echo "SSE2 possible"

This is good enough on i686 and x86-64, as the architecture itself does not
tolerate any difference in the flags set between processors.  Maybe enhance
it a little so that it won't trigger on "^flags_new" or somesuch.

-- 
  "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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916193700.ga9...@khazad-dum.debian.net

Re: Aborting installation on unsupported systems

2014-09-16 Thread Andrey Rahmatullin 
On Tue, Sep 16, 2014 at 12:02:24PM +0200, Matthias Urlichs wrote:
> You might want to pop up a preinst debconf notice which tells the admin
> that the package will not run here (with an option to fail the install
> if it's an honest mistake).
This may require reimplementing some part of the program in shell (in my
case it's parsing of /proc/cpuinfo, so it's at least possible, but still).

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Aborting installation on unsupported systems

2014-09-16 Thread Matthias Urlichs 
Hi,

Andrey Rahmatullin:
> On Mon, Sep 15, 2014 at 09:28:45PM +0100, Barak A. Pearlmutter wrote:
> > The package "ikarus", another programming language implementation,
> > also requires SSE2 support.
> > There is a check in the preinst script which aborts installation if
> > sse2 is unavailable.
> One of my packages works only on certain CPUs and by design it fails to
> start on others. The package starts its initscript on install, so the
> installation fails on unsupported hardware. I have a grave bug #738927
> asking me to fix this behavior and I was told by someone on IRC to leave
> it as is. Now I see there are other people doing this so I think I should
> ask here for more opinions.
> 
IMHO it's perfectly reasonable to be able to install a package which cannot
immediately run.

Another example would be a program which needs a lot of RAM or disk space
to work. Or a reachable database server.
But when I prepare a VM image for that program, I may not yet have
the RAM available, or I pre-generate a backup system image, or …

You might want to pop up a preinst debconf notice which tells the admin
that the package will not run here (with an option to fail the install
if it's an honest mistake).

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916100224.gc2...@smurf.noris.de

Aborting installation on unsupported systems

2014-09-16 Thread Andrey Rahmatullin 
On Mon, Sep 15, 2014 at 09:28:45PM +0100, Barak A. Pearlmutter wrote:
> The package "ikarus", another programming language implementation,
> also requires SSE2 support.
> There is a check in the preinst script which aborts installation if
> sse2 is unavailable.
One of my packages works only on certain CPUs and by design it fails to
start on others. The package starts its initscript on install, so the
installation fails on unsupported hardware. I have a grave bug #738927
asking me to fix this behavior and I was told by someone on IRC to leave
it as is. Now I see there are other people doing this so I think I should
ask here for more opinions.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916082549.ga23...@belkar.wrar.name

Re: "epollCreate: unsupported operation" on buildd hosts

2011-03-09 Thread Olaf van der Spek 
On Wed, Mar 9, 2011 at 11:09 AM, Adam Borowski  wrote:
>> Or is it actually so that the libc should map uses of epoll_create1 to
>> epoll_create?  Or do we need to introduce run-time checks as to whether
>> epoll_create1 is available?
>
> There's no way around run-time checks if you want to be safe from this race,
> yeah.  It can be done either in libc or in your code; the former means less
> code duplication but hurts badly any backporting.

Why is the function declared but not implemented?
Seems kinda silly.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi,xNzNvk1M=wkawxjtzfs5m3dzrfnyu4vh...@mail.gmail.com

Re: "epollCreate: unsupported operation" on buildd hosts

2011-03-09 Thread Julien Cristau 
On Wed, Mar  9, 2011 at 15:23:09 +0530, Joachim Breitner wrote:

> Hi,
> 
> Am Mittwoch, den 09.03.2011, 10:22 +0100 schrieb Julien Cristau:
> > epoll_create1 was added in 2.6.27, afaict.  If that's what haskell is
> > using, then it's not unexpected to have it fail on 2.6.26.
> 
> good shot, thanks!
> 
> From ./libraries/base/System/Event/EPoll.hsc: (this line does not start with 
> ">")
> 
> epollCreate :: IO EPollFd
> epollCreate = do
>   fd <- throwErrnoIfMinus1 "epollCreate" $
> #if defined(HAVE_EPOLL_CREATE1)
> c_epoll_create1 (#const EPOLL_CLOEXEC)
> #else
> c_epoll_create 256 -- argument is ignored
>   setCloseOnExec fd
> #endif
>   let !epollFd' = EPollFd fd
>   return epollFd'
> 
> #if defined(HAVE_EPOLL_CREATE1)
> foreign import ccall unsafe "sys/epoll.h epoll_create1"
> c_epoll_create1 :: CInt -> IO CInt
> #else
> foreign import ccall unsafe "sys/epoll.h epoll_create"
> c_epoll_create :: CInt -> IO CInt
> #endif
> 
> 
> and in libraries/base/configure.ac:
> AC_CHECK_FUNCS([epoll_create1 epoll_ctl eventfd kevent kevent64 kqueue poll])
> 
> 
> So what is the conclusion? Do we need to disable the use of
> epoll_create1 completely? Or is it actually so that the libc should map
> uses of epoll_create1 to epoll_create? Or do we need to introduce
> run-time checks as to whether epoll_create1 is available?
> 
Something like this, I think...

#if defined(HAVE_EPOLL_CREATE1)
fd = epoll_create1(EPOLL_CLOEXEC);
if (fd < 0 && errno == ENOSYS)
#endif
{
  fd = epoll_create(256);
  if (fd < 0 || fcntl(fd, F_SETFD, fcntl(fd, F_GETFD, 0) | FD_CLOEXEC) < 0)
return -1;
}
return fd;

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110309101230.gj12...@radis.liafa.jussieu.fr

Re: "epollCreate: unsupported operation" on buildd hosts

2011-03-09 Thread Adam Borowski 
On Wed, Mar 09, 2011 at 03:23:09PM +0530, Joachim Breitner wrote:
> Am Mittwoch, den 09.03.2011, 10:22 +0100 schrieb Julien Cristau:
> > epoll_create1 was added in 2.6.27, afaict.  If that's what haskell is
> > using, then it's not unexpected to have it fail on 2.6.26.
> 
> #if defined(HAVE_EPOLL_CREATE1)
> c_epoll_create1 (#const EPOLL_CLOEXEC)
> #else
> c_epoll_create 256 -- argument is ignored
>   setCloseOnExec fd
> #endif
> 
> So what is the conclusion? Do we need to disable the use of
> epoll_create1 completely?

It gets you nothing unless there's a possibility another thread might fork
between epoll_create() and fcntl(FD_CLOEXEC).

> Or is it actually so that the libc should map uses of epoll_create1 to
> epoll_create?  Or do we need to introduce run-time checks as to whether
> epoll_create1 is available?

There's no way around run-time checks if you want to be safe from this race,
yeah.  It can be done either in libc or in your code; the former means less
code duplication but hurts badly any backporting.


Meow?
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110309100921.ga11...@angband.pl

Re: "epollCreate: unsupported operation" on buildd hosts

2011-03-09 Thread Joachim Breitner 
Hi,

Am Mittwoch, den 09.03.2011, 10:22 +0100 schrieb Julien Cristau:
> epoll_create1 was added in 2.6.27, afaict.  If that's what haskell is
> using, then it's not unexpected to have it fail on 2.6.26.

good shot, thanks!

From ./libraries/base/System/Event/EPoll.hsc: (this line does not start with 
">")

epollCreate :: IO EPollFd
epollCreate = do
  fd <- throwErrnoIfMinus1 "epollCreate" $
#if defined(HAVE_EPOLL_CREATE1)
c_epoll_create1 (#const EPOLL_CLOEXEC)
#else
c_epoll_create 256 -- argument is ignored
  setCloseOnExec fd
#endif
  let !epollFd' = EPollFd fd
  return epollFd'

#if defined(HAVE_EPOLL_CREATE1)
foreign import ccall unsafe "sys/epoll.h epoll_create1"
c_epoll_create1 :: CInt -> IO CInt
#else
foreign import ccall unsafe "sys/epoll.h epoll_create"
c_epoll_create :: CInt -> IO CInt
#endif


and in libraries/base/configure.ac:
AC_CHECK_FUNCS([epoll_create1 epoll_ctl eventfd kevent kevent64 kqueue poll])


So what is the conclusion? Do we need to disable the use of
epoll_create1 completely? Or is it actually so that the libc should map
uses of epoll_create1 to epoll_create? Or do we need to introduce
run-time checks as to whether epoll_create1 is available?



Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: "epollCreate: unsupported operation" on buildd hosts

2011-03-09 Thread Julien Cristau 
On Wed, Mar  9, 2011 at 12:49:55 +0530, Joachim Breitner wrote:

> Dear Devel list,
> 
> updating the GHC haskell compiler to the newest version in Debian is
> causing surprisingly many problems. With one of those, I am totally at a
> loss to understand it, especially as I cannot reproduce it.
> 
> Basically, the new GHC compiler uses the epoll system call where
> available, which should be the case on all Linux kernels by now.
> Building the compiler works fine (even though it is a two stage
> process), but then using the compiler to build another package (which
> might or might not be a new version of the compiler) fails with:
> epollCreate: unsupported operation (Function not implemented)
> e.g. in
> https://buildd.debian.org/fetch.cgi?pkg=ghc&arch=i386&ver=7.0.2-2&stamp=1299583867&file=log&as=raw
> or 
> https://buildd.debian.org/fetch.cgi?pkg=haskell-transformers&arch=amd64&ver=0.2.2.0-1&stamp=1299522650&file=log&as=raw
> 
> On my machine and other developer’s machines, this is not reproducible.
> Upstream is rightfully puzzled as well (“That's odd. Is it always
> reproducible within a single machine? Linux (and Debian) should support
> epoll just fine.”, http://hackage.haskell.org/trac/ghc/ticket/5005)
> 
> Does anyone here have a clue as to why the epoll system calls might fail
> on buildd machines?
> 
epoll_create1 was added in 2.6.27, afaict.  If that's what haskell is
using, then it's not unexpected to have it fail on 2.6.26.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110309092241.gi12...@radis.liafa.jussieu.fr

"epollCreate: unsupported operation" on buildd hosts

2011-03-08 Thread Joachim Breitner 
Dear Devel list,

updating the GHC haskell compiler to the newest version in Debian is
causing surprisingly many problems. With one of those, I am totally at a
loss to understand it, especially as I cannot reproduce it.

Basically, the new GHC compiler uses the epoll system call where
available, which should be the case on all Linux kernels by now.
Building the compiler works fine (even though it is a two stage
process), but then using the compiler to build another package (which
might or might not be a new version of the compiler) fails with:
epollCreate: unsupported operation (Function not implemented)
e.g. in
https://buildd.debian.org/fetch.cgi?pkg=ghc&arch=i386&ver=7.0.2-2&stamp=1299583867&file=log&as=raw
or 
https://buildd.debian.org/fetch.cgi?pkg=haskell-transformers&arch=amd64&ver=0.2.2.0-1&stamp=1299522650&file=log&as=raw

On my machine and other developer’s machines, this is not reproducible.
Upstream is rightfully puzzled as well (“That's odd. Is it always
reproducible within a single machine? Linux (and Debian) should support
epoll just fine.”, http://hackage.haskell.org/trac/ghc/ticket/5005)

Does anyone here have a clue as to why the epoll system calls might fail
on buildd machines?

Thanks,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Downloading Testing with Jigdo unsupported?

2010-08-24 Thread Toni Mueller 


On Tue, 24.08.2010 at 22:12:37 +0800, Paul Wise  wrote:
> Probably you are looking for this?
> 
> http://cdimage.debian.org/cdimage/weekly-builds/i386/jigdo-cd/

Yes. The link to this isn't published prominently, but I found it at
last.

Thank you!


-- 
Kind regards,
--Toni++


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100824151537.19166.qm...@oak.oeko.net

Re: Downloading Testing with Jigdo unsupported?

2010-08-24 Thread Paul Wise 
Probably you are looking for this?

http://cdimage.debian.org/cdimage/weekly-builds/i386/jigdo-cd/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimcwloet2dh7shxswa4jb8b82meahoxjhze1...@mail.gmail.com

Downloading Testing with Jigdo unsupported?

2010-08-23 Thread Toni Mueller 


Hi,

I was under the impression that Testing installer images should be
auto-generated on a weekly basis. Now I look at

http://www.debian.org/CD/jigdo-cd/, and at
http://cdimage.debian.org/cdimage/squeeze_di_alpha1/i386/jigdo-cd/

and find that the images are all actually several months old, while at
this place

http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/

images are fresh. What gives?


Kind regards,
--Toni++



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100823184204.23253.qm...@oak.oeko.net

Re: Bug#468183: Unsupported?

2008-03-04 Thread Thorsten Schmale 
I forwarded your question to the upstream developer. He will check that
in the code. But for now he suggested to leave the Mysql logging feature
out of the package.

On 29/02/08 22:13 +0100, Florian Weimer wrote:
> * Thorsten Schmale:
> 
> > I created an updated description. Please see below.  One thing i
> > forgot to mention earlier was the feature of logging the http requests
> > directly to a mysql-database.  I'm not quite sure, but I think this
> > feature is not supported by most other webservers.
> 
> We've already got libapache2-mod-log-sql.  (I wouldn't recommend using
> it either, though.)  Most web servers support SQL logging in some form
> or other.  There are also tons of converters to load Common Log format
> files into SQL databases.
> 
> Are you sure that MonkeyD logs requests containing "'" characters
> correctly?  The source code doesn't look like it.  (You may have to use
> telnet/socket/nc manually, to prevent escaping from the browser.)
> 
> 


signature.asc
Description: Digital signature

Re: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)

2008-03-01 Thread Paul Wise 
On Sat, Mar 1, 2008 at 7:53 AM, Andreas Tille <[EMAIL PROTECTED]> wrote:

>  Is there any reason why a Debian should spend resources to maintain
>  things that are not good enough for Debian?

Debian isn't being asked to do any such thing. I've been thinking
about doing this for a long time, one of the points in the proposal
I'd written was that DDs would be discouraged from participating since
they should be working on supporting the official archive.

>  For the "not good enough _yet_" there is experimental.

experimental relies on DDs to upload, ftpmasters would probably reject
packages with no Maintainer field (or a blank one). experimental is
not the right place for this.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)

2008-02-29 Thread Andreas Tille 

On Fri, 29 Feb 2008, Paul Wise wrote:


unsupported.d.n could be the right place for packages that are "not
good enough for Debian (yet)".


Is there any reason why a Debian should spend resources to maintain
things that are not good enough for Debian?  For the "not good enough
_yet_" there is experimental.  I don't mind if somebody else wants to
register "to-bad-for-debian.org" but I also would love if people would
discuss such issues on a mailing list of this domain.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Bug#468183: Unsupported?

2008-02-29 Thread Florian Weimer 
* Thorsten Schmale:

> I created an updated description. Please see below.  One thing i
> forgot to mention earlier was the feature of logging the http requests
> directly to a mysql-database.  I'm not quite sure, but I think this
> feature is not supported by most other webservers.

We've already got libapache2-mod-log-sql.  (I wouldn't recommend using
it either, though.)  Most web servers support SQL logging in some form
or other.  There are also tons of converters to load Common Log format
files into SQL databases.

Are you sure that MonkeyD logs requests containing "'" characters
correctly?  The source code doesn't look like it.  (You may have to use
telnet/socket/nc manually, to prevent escaping from the browser.)


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

Re: Unsupported?

2008-02-29 Thread William Pitcock 
Hi,

On Fri, 2008-02-29 at 09:57 -0800, Steve Langasek wrote:
> So if it's unsupported, set it up yourself instead of asking Debian to
> dedicate resources to it.
> 

I wasn't aware that I was asking Debian to dedicate resources to it.

William


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

Re: Unsupported?

2008-02-29 Thread Steve Langasek 
On Fri, Feb 29, 2008 at 11:47:25AM -0600, William Pitcock wrote:
> Did I mention that it is unsupported?

So if it's unsupported, set it up yourself instead of asking Debian to
dedicate resources to it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: Unsupported?

2008-02-29 Thread William Pitcock 
Hi,

On Fri, 2008-02-29 at 21:54 +0900, Paul Wise wrote:
> unsupported.d.n could be the right place for packages that are "not
> good enough for Debian (yet)". It could be a good place to merge
> packages removed from Debian for having no users (or whatever),
> uploaded to Ubuntu, Nexenta, Preventa, mentors, revu and any other
> Debian-based distros that have public archives. A while ago on -devel
> there was a post about automatic creation of rough packages using
> automatic software discovery and AI techniques for the packaging, such
> packages could be uploaded to unsupported. Upstreams often make Debian
> packages but don't upload them anywhere, unsupported could be a place
> for them. I've often wanted to package some cool software (see the
> list on my wiki page), but not maintain it forever, so I didn't bother
> and just moved on. Instead I could just upload to unsupported.

As I see it, unsupported would be:

 * packages excluded from main for whatever reason (think: GTK1, XMMS),
 * packages not yet "good enough" for main (or not yet sponsored,
uploading to mentors could automatically put built packages in
unsupported, for example.),
 * packages that someone made, but does not want to maintain,
 * community maintained (e.g. you could bump the version by uploading to
mentors, or uploading directly to unsupported if you are a DD/DM),
 * and most importantly _UNSUPPORTED_.

That said, provided that it's clear that it's _UNSUPPORTED_, it could
become an additional asset for Debian users.

The community maintainance concept has proven to be quite reasonable,
other projects have had great success with this sort of thing, think
ArchLinux's AUR, Gentoo's "Sunrise" Overlay, etcetera. Yes, some person
can upload an evil package, but with proper moderation, evil packages
can be dealt with in a timely manner.

Did I mention that it is unsupported?

William


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

Re: Bug#468183: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)

2008-02-29 Thread Thorsten Schmale 
I created an updated description. Please see below.
One thing i forgot to mention earlier was the feature of logging the http 
requests 
directly to a mysql-database.
I'm not quite sure, but I think this feature is not supported by most other 
webservers.

Description: small http server
 Monkey is a small, fast, and easily configurable HTTP/1.1 compliant web
 server. It implements the following features:
 .
   * multi-threading
   * support for MIME
   * resume
   * virtual hosts
   * CGI and PHP
   * directory navigation
   * basic security features (denying access to certain URLs and IPs)
   * logging directly to a mysql-database instead of using logfiles.
   * translated documentation
 .

Regards,
Thorsten

On 29/02/08 13:18 +0100, Andreas Tille wrote:
> On Fri, 29 Feb 2008, William Pitcock wrote:
> 
> >But if you are worried about the QA and security team, then why not
> >create an unsupported repo. It could even be a good solution towards
> >recruiting new DDs.
> >
> >Lets call it, say, 'community', 'extras', or 'unsupported'.
> 
> Please don't!
> 
> Kind regards
> 
> Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
MY SUSPENSION WAS NOT "MUTUAL"
MY SUSPENSION WAS NOT "MUTUAL"
MY SUSPENSION WAS NOT "MUTUAL"
MY SUSPENSION WAS NOT "MUTUAL"

Bart Simpson on chalkboard in episode BABF10


signature.asc
Description: Digital signature

Re: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)

2008-02-29 Thread Paul Wise 
On Fri, Feb 29, 2008 at 9:18 PM, Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Feb 2008, William Pitcock wrote:
>
>  > But if you are worried about the QA and security team, then why not
>  > create an unsupported repo. It could even be a good solution towards
>  > recruiting new DDs.
>  >
>  > Lets call it, say, 'community', 'extras', or 'unsupported'.
>
>  Please don't!

Why not?

unsupported.d.n could be the right place for packages that are "not
good enough for Debian (yet)". It could be a good place to merge
packages removed from Debian for having no users (or whatever),
uploaded to Ubuntu, Nexenta, Preventa, mentors, revu and any other
Debian-based distros that have public archives. A while ago on -devel
there was a post about automatic creation of rough packages using
automatic software discovery and AI techniques for the packaging, such
packages could be uploaded to unsupported. Upstreams often make Debian
packages but don't upload them anywhere, unsupported could be a place
for them. I've often wanted to package some cool software (see the
list on my wiki page), but not maintain it forever, so I didn't bother
and just moved on. Instead I could just upload to unsupported.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)

2008-02-29 Thread Andreas Tille 

On Fri, 29 Feb 2008, William Pitcock wrote:


But if you are worried about the QA and security team, then why not
create an unsupported repo. It could even be a good solution towards
recruiting new DDs.

Lets call it, say, 'community', 'extras', or 'unsupported'.


Please don't!

Kind regards

Andreas.

--
http://fam-tille.de


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

Ecartis command results: -- Binary/unsupported file stripped by Ecartis --

2008-02-21 Thread Ecartis 

>> Q
Unknown command.

>> ÉÔ¾8sV¤’âþ”;Ì056dÏekä,BŸ‹L©Œ×›XîhÇsE‹˜<'w:«ÅÒՏ7Ç 
>> |HÐp#£|¼*(«íÌëÆYµ»n³‚ÕÒÒ½EŠ:ÓS‰
Unknown command.

>> !AóìkMŒ±Ú?k>
Unknown command.

>> —ÀÉå¯uþiÀö–ý›“ÆF‡o«›C>“À¢¿¬§Ëä^Z’í.ŒÛäâb$ÁFãÀb¥e;ñÍØ֊s.¦£ôïpŠ$)
Unknown command.

>> R9ýùhçšUo·Øã°CC-/ÑÊ¿¾©öj¾H%v¦ÝuƒÎ$
Unknown command.

>> “êoS?½k5í¢–AҜbÎTöaîÀFÐ
Unknown command.

>> ¸Ä²¨ÒùÊ[¤”ú†~82Œ-eםËó¢ðS[°ô#ðÍÞ¾eÀ®èžG{
Unknown command.

>> (ŒS5}sæ¿ô¯tž³Wí'‰‚q]Žè¯_hÝ©qÀ‡Jµï—±å»¼£üìïÏ:¹Gò׋8ß% íB(&Šëg(´D‹
>> 2௰ł})1úýÞ9í;ª›é¤Š Œ6}~voüàƒWG›ö^o¶¼³j˜î<}¹:ÎåM¤¢gh¿Ýó“Qiº¡Ôͬý
Unknown command.

>> ÐTœ6±Y£#ã›-¬¼
Unknown command.

>> Æj-rÕóä͈`¯‘3Kٓ£éütuø.
Unknown command.

>> Úb¯‹LÌÇ3ZU-yç—aôjé>‡·xGö‹HóŽämRž×ž[³u¸dõ"ÞRÌËÔþÐåsASóþ¡âµj©jƒ½›-¤’ê>ٙ¿ÖbuÉ·
>> ©!¶Ô2ÜfßAkï0­lÛ¦RŸù†“kÛö
Unknown command.

>> ÓYYƒû–íŒrÔ¶ç¥,5ûöóÉKL´WoàµzWR$…›ö»‘®‚™¦ÙíêfX{‹ õžÀìá&&ð 
>> t$LÄNCrU‹'Ph½ŠƒÉhÉÄ6A§ßÉ;¹
Unknown command.

>> VH犲gïô£?9vÕ_º_¼úòH_×“œwl
Unknown command.

>> ÐË.}úW¾L6(©‚yëúl§Ë·GØ÷¿ÛŒj{梖°
Unknown command.

>> ¼;s'BU›¡f»ï#ٖ¶k…—2õ–aݛP–¡¹|3½Øà-¸¾d¸×èâlôŸve*T;SF0U‡–Ž‡T[KŸ‹&â°ª’°c¼lƓèÌCÞÙÍ{I?¨üüöôL•LºÍ§%*ðA¡b.
Unknown command.

>> Üú» ’Wx4]ß«s>Ì*þg[«„ñcŽÛ¿5ù[ô%ª] Š¹âžÐ-ºÜàøýAü­±3º©C³˜
Unknown command.

---
Ecartis v1.0.0 - job execution complete.


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

Bug#420691: ITP: audacious-plugins-ugly -- Unsupported plugins for audacious

2007-04-24 Thread Le_Vert 
Package: wnpp
Severity: wishlist
Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]>

* Package name: audacious-plugins-ugly
  Version : 1.3.0
  Upstream Author : Audacious Dev Team
* URL : http://audacious-media-player.org/Main_Page
* License : GPL
  Programming Lang: C
  Description     : Unsupported plugins for audacious

Audacious is a new fork of beep-media-player (xmms) which supports winamp
skins and the following codecs : AAC, Ogg, FLAC, WMA, MPEG3, MPC...
..
It includes some great other features like various output plugins, last.fm
plugins, LIRC support.
..
This package contains some unsupported plugins for Audacious :
  * Mplayer controls (use mplayer as input backend)
  * Cube (ADX and other formats support)
  * Libnotify support
  * IRIS 3D vizualisation
..
Once upstream consider theses plugins enough reliable, they will be merged
to audacious-plugins.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Ecartis command results: -- Binary/unsupported file stripped by Ecartis --

2006-10-27 Thread Ecartis 

>> Dear user [EMAIL PROTECTED],
Unknown command.

>> We have received reports that your email account was used to send a
>> huge amount of junk e-mail messages during the recent week.
Unknown command.

>> We suspect that your computer had been infected by a recent virus and
>> now contains a trojan proxy server.
Unknown command.

>> Please follow our instruction in the attached file in order to keep
>> your computer safe.
Unknown command.

>> Have a nice day,
Unknown command.

>> The nl.linux.org team.
Unknown command.

---
Ecartis v1.0.0 - job execution complete.


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