Bug#544804: ITP: faifa -- Homeplug 1.0/AV tool

[Damien Raude-Morvan]

Package: wnpp
Severity: wishlist
Owner: "Damien Raude-Morvan" 
X-Debbugs-CC: debian-devel@lists.debian.org, d...@open-plc.org


* Package name: faifa
  Version : 0.2~svn27
  Upstream Author : Xavier Carcelle 
Florian Fainelli 
Nicolas Thill 
* URL : https://dev.open-plc.org/
* License : GPL v2.1 (with OpenSSL exception)
  Programming Lang: C
  Description : Homeplug 1.0/AV tool


 Faifa is a network tool to configure, inspect
 flash, collect statistics on HomePlug 1.0/AV
 devices.
 .
 It sends all private and public ethernet management
 frames to the devices.

Cheers,
-- 
Damien Raude-Morvan - http://damien.raude-morvan.com/


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

Re: Fwknop: Layout suggestions for a future implementation

[Manoj Srivastava]

On Wed, Sep 02 2009, Franck Joncourt wrote:


> I have got one tarball from upstream which is separated in fwknop-client
> and fwknop-server. The programs are mainly implemented in perl.
>
> Upstream is now working on rewriting it in C. Thus we have now a brand
> new tarball available known as fwknop-c.
>
> This new tarball contains at the moment :
>
> - a shared library -> libfko
> - the documentation of the shared library
> - an XS module FKO that allows fwknop-client/server to use the new
>   libfko library.
> - the fwknop client written in C
>
> - later maybe a fwknop-c-server
>
> Therefore, I was thinking about such binary packages:
>
>  - 1) a shared library libfko0
>  - 2) a devel package libfko0-dev
>  - 3) a doc package libfko-doc
>  - 4) a fwknop-c-client
>  - 5) a fwknop-c-server
>  - 6) a libspa-fko-perl module
>
> and I was suggesting to split the current fwknop-c tarball in three as
> following:
>
>  - one for 1+2+3
>  - one for 4+5
>  - one for 6
>
> To me it looks reasonable to split it. What do others think?
> Upstream is also insterested in hearing your opinions :)

Please explain why it needs to be split? A single source package
 can create as many binary packages as are desired, so the splitting off
 the binary packages does not impose any requirements to split the source
 package. 

manoj
-- 
Never be afraid to tell the world who you are. Anonymous
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Fwknop: Layout suggestions for a future implementation

[Franck Joncourt]

(Upstream is CCed, please keep it that way)

PS: Mail previously sent to debian-mentor, but I did not get any
answers, therefore I try on devel.

Hi,

I am the maintainer of fwknop:

http://packages.qa.debian.org/f/fwknop.html

"The FireWall KNock OPerator implements an authorization scheme called
Single Packet Authorization (SPA), based on Netfilter and libpcap.

Its main application is to protect services such as OpenSSH with an
additional layer of security in order to make the exploitation of
vulnerabilities (both 0-day and unpatched code) much more difficult."

I have got one tarball from upstream which is separated in fwknop-client
and fwknop-server. The programs are mainly implemented in perl.

Upstream is now working on rewriting it in C. Thus we have now a brand
new tarball available known as fwknop-c.

This new tarball contains at the moment :

- a shared library -> libfko
- the documentation of the shared library
- an XS module FKO that allows fwknop-client/server to use the new
  libfko library.
- the fwknop client written in C

- later maybe a fwknop-c-server

Therefore, I was thinking about such binary packages:

 - 1) a shared library libfko0
 - 2) a devel package libfko0-dev
 - 3) a doc package libfko-doc
 - 4) a fwknop-c-client
 - 5) a fwknop-c-server
 - 6) a libspa-fko-perl module

and I was suggesting to split the current fwknop-c tarball in three as
following:

 - one for 1+2+3
 - one for 4+5
 - one for 6

To me it looks reasonable to split it. What do others think?
Upstream is also insterested in hearing your opinions :)

Regards,

-- 
Franck Joncourt
http://debian.org - http://smhteam.info/wiki/




signature.asc
Description: PGP signature


signature.asc
Description: OpenPGP digital signature

Re: udev and /usr

[Josselin Mouette]

Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit : 
> /usr was on seperate filesystems for decades and some 3733t broken by design
> Desktop utility turns around old Unix paradigms? I dont get it ...

Since when is udev a desktop utility?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: udev and /usr

[Florian Lohoff]

On Wed, Sep 02, 2009 at 04:26:08AM +0200, Marco d'Itri wrote:
> On Sep 01, Steve Langasek  wrote:
> > You are drawing an artificial distinction between /usr and /var which is not
> > consistent with the standard, nor with how I've been laying out my
> > filesystems for years.  I'm not going to refactor my disk layout on upgrade
> But it is consistent with what upstream (i.e., other distributions)
> wants to support.

I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
is going to make seperate /usr a no-go its about 30 Euros worth
of field Engineer time - swapping disks.

/usr was on seperate filesystems for decades and some 3733t broken by design
Desktop utility turns around old Unix paradigms? I dont get it ...

Flo
-- 
Florian Lohoff f...@rfc822.org
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature

Re: trayer_1.1_i386.changes REJECTED

[Sune Vuorela]

On 2009-09-02, Jens Peter Secher  wrote:
> 2009/9/2 Torsten Werner :
>>
>> why is it a native package? Why do we need this package in Debian that got
>> removed recently from unstable? I would expect an explanation either in bug
>> #541265 or in the changelog.
>
>>From the changelog:
>
>   * Upstream has abandoned the program, so the package is now Debian
> native.

Switching upstreams does not make a package native.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: trayer_1.1_i386.changes REJECTED

[Jens Peter Secher]

2009/9/2 Torsten Werner :
>
> why is it a native package? Why do we need this package in Debian that got
> removed recently from unstable? I would expect an explanation either in bug
> #541265 or in the changelog.

>From the changelog:

  * Upstream has abandoned the program, so the package is now Debian
native.

>From http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=541265

  reopen 541265 j...@debian.org
  thanks

  > "Personally, I would drop the package entirely, it's unsupported and
  > there's a better alternative already, called stalonetray
  > http://stalonetray.sourceforge.net/, it's also available in Debian."
  > (Maciej Delmanowski)

  Except that stalonetray does not work, at least not together xmonad.  I
  will probably file bugs against stalonetray later.

  In the meantimem, I am willing to maintain trayer.

And I will add to that that trayer has 500+ installations according to popcon.

>
> missing copyright info; some examples:
>
> systray/eggtraymanager.c
> Copyright (C) 2002 Anders Carlsson 
>

Well, I noticed some missing copyrights in the old package, so added
this to the debian/copyright:

  systray/fixedtip.{c,h}:  Copyright (C) 2001 Havoc Pennington
  systray/eggtraymanager.{c,h}:  Copyright (C) 2002 Anders Carlsson

> misc.c
> Copyright (c) 2003 Leandro Pereira 
>
> gtkbar.c
> Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
>

Yep, you are right, these are indeed missing.  I will now carefully
check each file, add missing copyrights and upload again.

Cheers,
-- 
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Future of the s390 port

[Petter Reinholdtsen]

[Martin Grimm]
> We've currently running 240+ Linux guests on 2 IBM System z10 EC,
> that's the newest hardware of this kind for those not so familiar
> with this architecture. 236 of these are running Debian, mostly
> etch, some still sarge and some lenny. Amongst these are
> zelenka.debian.org and a build system for security updates.

One simple way to help a bit which will make it more visible to the
Debian community at large that the s390 port is used, is to install
and activate popularity-contest on these machines and thus make sure
236 machines show up on http://popcon.debian.org/ > as running
the s390 port. :)

At the moment, only 8 machines are reporting to popularity-contest,
which put s390 in line with hurd-i386, kfreebsd-amd64 and m68k as
ports with very small user groups.  That number made me and probably
others believe that very few are using the s390 port - at least until
your email came along. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#544718: ITP: libasync-interrupt-perl -- Perl module to allow C/XS libraries to interrupt perl

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libasync-interrupt-perl
  Version : 1.02
  Upstream Author : Marc Lehmann 
* URL : http://search.cpan.org/dist/Async-Interrupt/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module to allow C/XS libraries to interrupt perl

 Async::Interrupt implements asynchronous interruptions (think "UNIX signals",
 which are very similar). Modules might want to run code asynchronously (in
 another thread, or from a signal handler), and then signal the interpreter on
 certain events. One common way is to write data to a pipe and use an event
 handling toolkit to watch for I/O events. Another way is to send a signal.
 Those methods are slow, and in the case of a pipe, also not asynchronous - it
 won't interrupt a running Perl interpreter.
 .
 This module implements asynchronous notifications that enable you to signal
 running Perl code from another thread, asynchronously, and sometimes even
 without using a single syscall.

NOTE: I'm packaging this as it's now recommended by AnyEvent (libanyevent-perl)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Julien Cristau]

On Wed, Sep  2, 2009 at 09:22:30 +0200, Raphael Hertzog wrote:

> Are those patches in that format because you took them from the upstream
> git repository or because using this format from the start lets upstream
> pick it up easily?
> 
Both (usually the latter though, because for patches which are already
upstream I tend to use cherry-pick to apply directly, so they don't go
through debian/patches/).  Or because they're stolen from the fedora
package, which iirc uses git to generate/apply patches.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Future of the s390 port

[Martin Grimm]

Am 31.08.2009 18:28 schrieb Bastian Blank:
> Hi folks
> 
> The s390 port was released with Lenny. However it is not in the best
> condition.  There are mainly two problems which needs attention, lack of
> manpower and a 64 bit userland.
> 
> The first problem is the worst.  Currently only Frans Pop and I do work
> on it.  Frans only does the Debian-Installer part and I simply have not
> enough time to do the rest.  The s390 architecture is quite different to
> anything else, so it needs several specialized packages to work[1] and
> they need lasting attention.  So if anyone wants to help (especially
> Debian developers) for the continuity of this port please speak up.
> 
> The second problem is not that critical. No other distribution still
> supports a complete 31 bit s390 userland and even Debian dropped the 31
> bit kernel support in the meantime[2]. Strategies for an upgrade to a 64
> bit userland was discussed lately[3].
> 
> I doubt that I would be able to push this port through another release
> in the current state. The consequence would by that the port dies
> completely and with it the only free and released distribution for this
> machines.
> 
> Bastian
> 
> [1]: Mainly the kernel, generic tools (s390-tools), hardware support
> (sysconfig-hardware) and a whole bunch of debian-installer packages.
> [2]: <20090524185816.ga21...@wavehammer.waldi.eu.org>
> [3]: <20090818204335.ga6...@droopy.oc.cox.net>

Hi

we'd like to help.

We've currently running 240+ Linux guests on 2 IBM System z10 EC, that's
the newest hardware of this kind for those not so familiar with this
architecture. 236 of these are running Debian, mostly etch, some still
sarge and some lenny. Amongst these are zelenka.debian.org and a build
system for security updates.

We've no debian developers here and our staff is rather small but we are
willing to test new packages and contribute to existing tools in when
some debian developer can tell us where to start and what's necessary.

I've also clearance to provide more systems like zelenka to developers,
so access to current hardware should be possible.

Greetings
Martin

-- 
Martin Grimm
Zentrum für Informationsverarbeitung und Informationstechnik
Dienstsitz Bonn
An der Küppe 2
53225 Bonn
Tel.: +49 228 99 680 5298
e-mail: extern.martin.gr...@zivit.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#544702: ITP: gnosek-fcgiwrap -- simple server to run CGI applications over FastCGI

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: gnosek-fcgiwrap
  Version : 0.0.20090717.28ac6f9-2
  Upstream Author : Grzegorz Nosek
* URL : http://nginx.localdomain.pl/wiki/FcgiWrap
* License : MIT
  Programming Lang: C
  Description : simple server to run CGI applications over FastCGI

 fcgiwrap is a simple server for running CGI applications over FastCGI.
 Its goal is to provide clean CGI support to the nginx webserver, although
 can be used with others.

 fcgiwrap is lightweight and has no configuration, making it possible to
 use the same pool to run different sites.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#544705: ITP: ibus-table-cantonhk -- Cantonhk input method based on table engine of ibus

[Asias He]

Package: wnpp
Severity: wishlist
Owner: Asias He 


* Package name: ibus-table-cantonhk
  Version : 1.2.0.20090828
  Upstream Author : 梁敬文 Leung King Man  Caius "kaio" 
Chance 
* URL : http://code.google.com/p/ibus/
* License : GPLv2
  Programming Lang: N/A
  Description : Cantonhk input method based on table engine of ibus

 IBus-Table is the IM Engine framework for table-based input methods, such as
 WuBi, ErBi, Cangjie and so on.
 .
 This package provides one input method: Cantonhk.
 .
 Cantonhk is a Simplified Chinese input method. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Anybody have a spare sparc machine? (was: Re: Bug#543573: FTBFS: libdevel-declare-perl_0.005011-1 on sparc (dist=unstable))

[Niko Tyni]

On Tue, Sep 01, 2009 at 07:52:17PM -0700, Ryan Niebur wrote:

> the upstream author of libdevel-declare-perl thinks that this could be
> the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505415
> so if somebody with a sparc machine could just rebuild
> libdevel-declare-perl against the perl in experimental and confirm
> that it builds, that would be sufficient.

I can confirm this.


Core was generated by `debugperl -Iblib/lib -Iblib/arch t/combi.t'.
Program terminated with signal 10, Bus error.
#0  0xf7c7dadc in S_scan_str (my_perl=, offset=13) at 
stolen_chunk_of_toke.c:716
716 SvGROW(sv, SvCUR(sv) + (PL_bufend - s) + 1);

It works with Perl 5.10.1. A workaround for 5.10.0 is to lower the
optimization to -O1.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#544661: ITP: anything -- open anything / QuickSilver-like candidate-selection framework

[Takaya Yamashita]

Package: wnpp
Owner: Takaya Yamashita 
Severity: wishlist

* Package name: anything
  Version : 1.195-1
  Upstream Author : rubikitch 
* URL or Web page : http://www.emacswiki.org/cgi-bin/emacs/Anything
* License : gpl2
  Description : open anything / QuickSilver-like candidate-selection 
framework

---
Best Regards,

Takaya Yamashita
tak...@debian.or.jp
tyamash...@mikilab.doshisha.ac.jp



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Tue, 01 Sep 2009, Julien Cristau wrote:
> On Wed, Aug 26, 2009 at 01:56:35 +0200, Raphael Hertzog wrote:
> > Current version: http://dep.debian.net/deps/dep3/
>  
> FWIW, I'm not going to use something that I can't produce with git
> format-patch and feed to git send-email / git am since that feels like
> busy work; in particular the Author and Description fields are not
> needed given there's From and Subject with the same information.

IMO that's fine for now, maybe someone will write a wrapper around
git format-patch to auto-generate the correct headers while still keeping
those needed for compatibity with git am / send-email.

Are those patches in that format because you took them from the upstream
git repository or because using this format from the start lets upstream
pick it up easily?

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org