Re: Bug#508311: ITP: maven-archiver -- Maven Archiver

[Torsten Werner]

On Fri, Dec 12, 2008 at 3:55 AM, Gunnar Wolf  wrote:
> Carl Fürstenberg dijo [Fri, Dec 12, 2008 at 01:05:43AM +0100]:
>> And plexus-archiver is?
>
> The thingy that is wrapped by maven-archiver.

You can find the ITP for plexus-archiver at
. It has been
filed by Paul Cager in *april* and there is no other comment in the
bug report. Not every ITP seems to be discussed in the same way as
this one.

Torsten


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

Bug#508553: ITP: fx2pipe -- Pipe data in or out of an Cypress FX2 device

[Uwe Hermann]

Package: wnpp
Severity: wishlist
Owner: Uwe Hermann 

* Package name: fx2pipe
  Version : 0.6
  Upstream Author : Wolfgang Wieser 
* URL : 
http://www.triplespark.net/elec/periph/USB-FX2/software/fx2pipe.html
* License : GPLv2
  Programming Lang: C
  Description : Pipe data in or out of an Cypress FX2 device

 FX2Pipe is a user-space utility which can be used to pipe data in or out
 of an Cypress FX2 device (CY7C6801xA).
 .
 It has a build-in firmware for the 8051 controller integrated in the
 FX2 chip. Upon startup, FX2Pipe will download that firmware onto the
 controller and also pass additional information (like the direction of
 the transfer, the FIFO width, etc.), then take the FX2 out of reset and
 begin the transfer.
 .
 The transfer works by submitting a number of URBs (normally 16) which are
 then enqueued and processed by the kernel as soon as possible. Once an URB
 is processed, it is returned back to the program which will in turn submit
 another URB hence having always a couple of URBs enqueued in the kernel.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



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

Re: Release plans? Bits from the RMs?

[Alexander Reichle-Schmehl]

Hi!


Christian Perrier schrieb:

> So, what's the status now?

Can't answer for the release team, but it seems to me, that everyone is
waiting for the outcome of GR 2008/vote_003 [1]...

But I would appreciate an "official Bits from" mail, too.

Links:
  1: http://www.debian.org/vote/2008/vote_003



Best regards,
  Alexander


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

Re: Peer review of copyright files.

[Daniel Leidert]

Am Donnerstag, den 11.12.2008, 00:15 +0900 schrieb Charles Plessy:

> Although it should never happen, sometimes a new package we submit to our
> archive managers is rejected because the description of the copyright status 
> of
> its files is either incorrect or lacunar. This is waste of precious time for
> everybody. In order to ameliorate the quality of our submissions, I propose to
> introduce a dose of optional pre-submission peer review.
> 
> One may wonder why not reviewing all QA aspects of a package? One reason is
> that this requires skills that are not evenly distributed,

Well, licensecheck(1) exists. Maybe many packagers don't know it?

[..]
> PS: and of course, consider using the machine-readable format if you have not
> tried yet: http://wiki.debian.org/Proposals/CopyrightFormat 

Would be nice to have a licensecheck mode to compare debian/copyright to
the checked source.

Regards, Daniel


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

Re: Peer review of copyright files.

[Charles Plessy]

Le Fri, Dec 12, 2008 at 03:21:50PM +0100, Daniel Leidert a écrit :
> 
> Well, licensecheck(1) exists. Maybe many packagers don't know it?

Hi Daniel,

I would rather think that one reason for defective debian/copyright files are
the false negatives of licensecheck ;) `grep -ri copyright .' is more messy but
an indispensable complement, in my opinion, and in the case nothing is found it
is usually safer to try a few other keywords and to inspect some files by hand.


> > PS: and of course, consider using the machine-readable format if you have 
> > not
> > tried yet: http://wiki.debian.org/Proposals/CopyrightFormat 
> 
> Would be nice to have a licensecheck mode to compare debian/copyright to
> the checked source.

I was considering filing a lintian wishlist :) I have caught once in the past
an upstream update that was adding a non-free MD5 implementation, but an
automatic safeguard wouldn't hurt. Also, I think that my proposal can be useful
as well in the case of a big update where the diff is really large. The
maintainer could file a RFH and use the current procedure, giving a look to
other's packges in exchange for the help with his.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Re: Peer review of copyright files.

[Patrick Schoenfeld]

Hi,

On Fri, Dec 12, 2008 at 03:21:50PM +0100, Daniel Leidert wrote:
> Well, licensecheck(1) exists. Maybe many packagers don't know it?

Well, licensecheck is a unreplaceable tool, but it cannot be a unique
ressource for copyright/license checking, as it suffers from bugs
(and/or unknown patterns) like any other software, too. And it would be really
good if copyright/license problems would be sorted out, before packages
enter NEW, which is a goal that cannot be accomplished with an
automatical tool (in every case).

Regards,
Patrick


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

Bug#508585: Please provide an easy and official way to get debug symbols for all arch

[Bastien ROUCARIES]

Package: general
Severity: normal

hello,

In case of bug on rare arch it is quite difficult for the maintener to get 
debug trace. 
A generic stuff like http://debug.debian.net/ will help to solve hard diagnose 
bug like the  #508443 and avoid to create -dbg package like in #508582:
apt-cache search dbg |grep "\-dbg" | wc -l
773
Therefore please find a way to generalize http://debug.debian.net/ and get dbg 
package compiled on the arch, and offer a deb-debug like deb-source deposit.
Using a deb-debug method will allow simple user to download the debug symbol 
without the need to contact the administrator. I even dream of a 
apt-get dbg-depend package that will download all the debug symbols, including 
library linked against my binary.

Keep in mind that maintener time and user time are precious, and a quick 
backstack is often an invaluable information.

Regards

Bastien


--- System information. ---
Architecture: amd64
Kernel:   Linux 2.6.26-1-amd64

Debian Release: lenny/sid
  990 testing security.debian.org 
  990 testing debian.ens-cachan.fr 
   99 unstabledebian.ens-cachan.fr 
  500 lenny   kde4.debian.net 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
| 



-- 

"ROUCARIES Bastien"
   roucaries.bast...@gmail.com
---
DO NOT WRITE TO roucaries.bastien+blackh...@gmail.com OR BE BLACKLISTED



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

renaming scripts provided by upstream

[Ansgar Burchardt]

Hi,

I wonder about the advantages and disadvantages of renaming scripts
installed in system PATH to not include an extension as ".pl"
(Policy 10.4):

When scripts are installed into a directory in the system PATH,
the script name should not include an extension such as .sh or .pl
that denotes the scripting language currently used to implement
it.

I understand that it should not matter to the user what language is
used to implement a particular script and support omitting
extensions.  But what about renaming scripts provided by upstream?
In this case renaming programs to comply with the Debian naming scheme
creates new problems:

Documentation will usually refer to upstream's naming choice and we
cannot change online documentation or mailing lists.  Even changing
only the documentation provided by Debian packages may require changes
to several packages.

What if scripts (or Makefiles) try to use the program?  If they are
not written on a Debian system, they will not be aware of the different
name used there.  The same applies to scripts written on Debian
systems:  they will not work on other systems.

Some people think that divergence should be avoided (or at least be
merged with upstream if possible)[1].  In my opinion, renaming
binaries is a far more invasive change than many other small patches
applied to Debian's packages and *should* be avoided.  Of course
convincing upstream to change the name is still okay :-)

Regards,
Ansgar

[1] http://lists.debian.org/debian-devel/2008/05/msg00536.html

-- 
PGP: 1024D/595FAD19  739E 2D09 0969 BEA9 9797  B055 DDB0 2FF7 595F AD19


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

Re: Release plans? Bits from the RMs?

[JD. Brown]

On Thu, Dec 11, 2008 at 11:15 PM, Christian Perrier  wrote:
> (-release is not a discussion list, therefore setting followup to
> -devel)
>
> Dear release managers,
>
> I feel like being in the dark right now. And I feel like I'm not alone...


I agree and would like to know as well?

It seems as if the communication fell apart after September and trying
to track down any such information around the web is getting to be a
chore.

Granted, I'm no Debian developer (yet) and Debian tends to be the
known, "It's done when it's done!" distro but lack of information and
communication is in dire need here.

Regards,

-- 

JD. Brown

Linux User # 375995 - http://counter.li.org/

Debian - http://www.debian.org/intro/about


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

Re: renaming scripts provided by upstream

[Drake Wilson]

Quoth Ansgar Burchardt , on 2008-12-12 22:30:24 +0100:
> I understand that it should not matter to the user what language is
> used to implement a particular script and support omitting
> extensions.  But what about renaming scripts provided by upstream?
> In this case renaming programs to comply with the Debian naming scheme
> creates new problems:

Not being well-acquainted with this bit, I can't comment very well on
what Debian policy would say, but wouldn't using the upstream name
plus a non-extensioned symlink solve several of these cases?

> Ansgar

   ---> Drake Wilson


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