Re: Bug#629276: NFS needs same dispensation to use DES as AFS

[Sergio Gelato]

* Brian May [2011-06-07 13:29:33 +1000]:
> Hello debian-devel,
> 
> What should I do with this bug?
> 
> I did build a version for unstable, but I am not convinced this change
> is needed for unstable.

Let me argue that it is still needed for the next Debian release. When
that comes out, squeeze will remain supported for another 12 months, and
any KDC serving an environment where Kerberized NFS is used on squeeze
hosts will need something like this. And that's even without considering
support for other distributions or operating systems, which may have
their own, possibly glacial paces for migrating to strong crypto.

The patch does not prevent the use of stronger enctypes, it just enables
the use of DES if requested (and if the service principal has a DES
enctype in the KDC database; one can always use del_enctype if need be).

> I am doubtful it will get accepted in stable, because it isn't fixing
> a grave bug.
> 
> I am not sure it is appropriate for backports, because the change
> isn't in unstable.
> 
> Thanks
> 
> On 5 June 2011 19:25, Sergio Gelato  wrote:
> > Package: heimdal-kdc
> > Version: 1.4.0~git20100726.dfsg.1-1
> > Tags: patch
> >
> > Recent Heimdal KDC disables DES encryption types on the (valid) grounds that
> > they are too weak. An exception is made where the service principal is "afs"
> > since the work to upgrade AFS to support stronger crypto is still very much
> > in progress.
> >
> > Unfortunately, Kerberized NFS has a similar problem. Support for stronger
> > enctypes didn't make it into the Linux kernel until 2.6.35 (post-squeeze).
> > Until all NFS servers and clients have been upgraded to support stronger
> > enctypes, a site will want to enable DES enctypes for "nfs" service
> > principals. Here is a patch that does just that; I've successfully tested
> > it. I think it would be highly desirable to have this in squeeze; more
> > so, in fact, than in later releases since the need for DES support with
> > NFS service principals ought to decrease with time.
> >
> > Without this patch, the KDC rejects AS requests that specify DES enctypes
> > with "krb5_crypto_init failed: encryption type (1|2|3) not supported"
> > (illustrating another oddity, namely that krb5_crypto_init() uses the
> > same error message whether the enctype is unknown or known but disabled;
> > krb5_enctype_valid() has two distinct error messages) and TGS requests
> > result in "Server (nfs/f.q.d.n) has no support for etypes" (also in the
> > KDC's log). The client did have [libdefaults]allow_weak_crypto=true, as
> > shown by the fact that the AS and TGS requests asked for a DES enctype.
> -- 
> Brian May 


-- 
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/20110607071057.ga6...@hanuman.astro.su.se

Re: throw away debs and source only uploads

[Andreas Barth]

* Don Armstrong (d...@debian.org) [110607 04:25]:
> On Mon, 06 Jun 2011, Philipp Kern wrote:
> > I.e. I think we should still allow non-buildd binaries, e.g. for
> > those cases you mentioned.
> 
> Non-buildd binaries should still be allowed, but they should be
> followed immediately by a binNMU. [Are there any cases where we
> wouldn't want to rebuild the package after it was bootstrapped?]

There are cases where porters need to upload, because of "funny"
issues. Or hand-builds within sane buildd chroots where the buildd
software refuses. Or similar. (I think I did less than 10 such uploads
recently.)



Andi


-- 
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/20110607074538.gu15...@mails.so.argh.org

Bug#629504: general: Error during compiling kernel module at generating file vnode_if.h.

[Cimini Mario]

Package: general
Severity: minor


Warning: Object directory not changed from original 
/usr/src/kfreebsd-source-8.1/sys/fs/puffs/puffs
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-common -g 
-I/usr/src/kfreebsd-source-8.1/sys/fs/puffs/puffs 
-I/usr/src/kfreebsd-source-8.1/sys/fs/puffs/puffs/../putter -DPUFFSDEBUG 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -std=iso9899:1999  -c puffs_msgif.c
In file included from @/sys/vnode.h:563,
 from puffs_msgif.c:44:
../vnode_if.h:13: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:22: error: expected ‘)’ before ‘struct’
../vnode_if.h:33: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:44: error: expected ‘)’ before ‘struct’
../vnode_if.h:59: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:70: error: expected ‘)’ before ‘struct’
../vnode_if.h:85: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:97: error: expected ‘)’ before ‘struct’
../vnode_if.h:114: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:125: error: expected ‘)’ before ‘struct’
../vnode_if.h:140: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:152: error: expected ‘)’ before ‘struct’
../vnode_if.h:169: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:182: error: expected ‘)’ before ‘struct’
../vnode_if.h:201: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:213: error: expected ‘)’ before ‘struct’
../vnode_if.h:230: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:242: error: expected ‘)’ before ‘struct’
../vnode_if.h:259: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:271: error: expected ‘)’ before ‘struct’
../vnode_if.h:288: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:299: error: expected ‘)’ before ‘struct’
../vnode_if.h:314: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:325: error: expected ‘)’ before ‘struct’
../vnode_if.h:340: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:349: error: expected ‘)’ before ‘struct’
../vnode_if.h:360: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:372: error: expected ‘)’ before ‘struct’
../vnode_if.h:389: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:401: error: expected ‘)’ before ‘struct’
../vnode_if.h:418: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:432: error: expected ‘)’ before ‘struct’
../vnode_if.h:453: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:465: error: expected ‘)’ before ‘struct’
../vnode_if.h:482: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:492: error: expected ‘)’ before ‘struct’
../vnode_if.h:505: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:515: error: expected ‘)’ before ‘struct’
../vnode_if.h:528: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:539: error: expected ‘)’ before ‘struct’
../vnode_if.h:554: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:565: error: expected ‘)’ before ‘struct’
../vnode_if.h:580: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:591: error: expected ‘)’ before ‘struct’
../vnode_if.h:606: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:620: error: expected ‘)’ before ‘WILLRELE’
../vnode_if.h:641: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:653: error: expected ‘)’ before ‘struct’
../vnode_if.h:670: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:681: error: expected ‘)’ before ‘struct’
../vnode_if.h:696: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:709: error: expected ‘)’ before ‘struct’
../vnode_if.h:728: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:742: error: expected ‘)’ before ‘struct’
../vnode_if.h:763: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:774: error: expected ‘)’ before ‘struct’
../vnode_if.h:789: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:799: error: expected ‘)’ before ‘struct’
../vnode_if.h:812: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:822: error: expected ‘)’ before ‘struct’
../vnode_if.h:835: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:847: error: expected ‘)’ before ‘struct’
../vnode_if.h:864: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:874: error: expected ‘)’ before ‘struct’
../vnode_if.h:887: error: expected specifier-qualifier-list before ‘IN’
../vnode_if.h:901: error: expected ‘)

Bug#629504: My Workaround

[Mario Cimini]

My Workaround is delete by hand IN,OUT,INOUT,WILLRELE!!

Bug#629508: ITP: robust-http-client -- Robust HTTP client library for Java

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 


* Package name: robust-http-client
  Version : 1.1
  Upstream Author : Kohsuke Kawaguchi
* URL : http://java.net/projects/robust-http-client
* License : MIT
  Programming Lang: Java
  Description : Robust HTTP client library for Java

 This library provides a Java InputStream implementation around a 
 HTTP connection that automatically reconnects if the connection 
 fails in the middle of communication.

 This library is a dependency for packaging jenkins.



-- 
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/20110607085312.3339.90020.reportbug@hendrix.shouse.local

Re: Bug#629276: NFS needs same dispensation to use DES as AFS

[Marco d'Itri]

On Jun 07, Brian May  wrote:

> I am doubtful it will get accepted in stable, because it isn't fixing
> a grave bug.
Sure it does: it fixes a serious interoperability problem, i.e. "breaks
unrelated software".

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: intermediate result of packaging-dev meta package discussion

[Vincent Danjean]

  Hi,

On 05/06/2011 15:46, Benjamin Drung wrote:
> Hi,
> 
> A few days ago, we had a discussion about a packaging-dev meta package.
> The responses were between neutral and positive. Therefore I created a
> initial draft [1] and tried to incorporate all suggestions made in the
> discussion.
> 
> The list looks currently like this:
> 
> Depends: [...]
>  pbuilder | cowbuilder | sbuild,

  My laptop, where I do all my packaging work but final build, has
none of them installed. I've a separate machine with several chroots
(lenny, squeeze, unstable and several for ubuntu) managed with sbuild that
I use when I want to really build the package I will upload. Due to disk
space, I cannot instal them (chroots) on my laptop.
  I other people work like me, these tools can be moved to Recommends
instead of Depends.

  Regards,
Vincent

>  quilt,
>  ${misc:Depends}
> Recommends: apt-file,
> autoconf,
> automake,
> autotools-dev,
> bzr-builddeb,
> cdbs,
> cmake,
> debian-policy,
> developers-reference,
> git-buildpackage,
> gnupg,
> libtool,
> piuparts,
> svn-buildpackage,
> ${vendor-specific:Recommends}
> Suggests: dh-make
> 
> ${vendor-specific:Recommends} will be evaluated to "ubuntu-dev-tools" on
> Ubuntu.
> 
> Please let me know if there is something missing, should be demoted, or
> removed.
> 
> This package is just for packaging, not for developing. So gdb, pylint
> and co. won't go into it. This package should be installed by packagers.
> No other package should depend or build-depend on packaging-dev.
> 
> [1] http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git
> 


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/4dedf0a6.9040...@free.fr

Re: intermediate result of packaging-dev meta package discussion

[Neil Williams]

On Tue, 07 Jun 2011 11:34:30 +0200
Vincent Danjean  wrote:

> > A few days ago, we had a discussion about a packaging-dev meta package.
> > The responses were between neutral and positive. Therefore I created a
> > initial draft [1] and tried to incorporate all suggestions made in the
> > discussion.
> > 
> > The list looks currently like this:
> > 
> > Depends: [...]
> >  pbuilder | cowbuilder | sbuild,
> 
>   My laptop, where I do all my packaging work but final build, has
> none of them installed. I've a separate machine with several chroots
> (lenny, squeeze, unstable and several for ubuntu) managed with sbuild that
> I use when I want to really build the package I will upload. Due to disk
> space, I cannot instal them (chroots) on my laptop.
>   I other people work like me, these tools can be moved to Recommends

I disagree. pbuilder or the alternatives are fundamental to best
practice Debian packaging. The needs of Debian are wider than a single
user having a problem with a single machine.

This package is trying to express best practice for packaging, to get a
baseline. You admit that you have a way of building in a chroot and it
isn't required that everyone uploading to Debian has this package
installed, it is simply a way of making it simple for most people to
have a standard set of build tools.

Most people would have space for a pbuilder chroot (it's only a few
hundred megabytes even unpacked, it's the apt cache which takes up the
space and that can be cleared with a configuration change) and everyone
using packaging-dev should be expected (required) to use a chroot to
build packages prior to upload.

Recommending chroot build tools is not strong enough.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpNF7f46yK1d.pgp
Description: PGP signature

Re: Bug#629276: NFS needs same dispensation to use DES as AFS

[Philipp Kern]

On 2011-06-07, Marco d'Itri  wrote:
> On Jun 07, Brian May  wrote:
>> I am doubtful it will get accepted in stable, because it isn't fixing
>> a grave bug.
> Sure it does: it fixes a serious interoperability problem, i.e. "breaks
> unrelated software".

Apart from debian-devel being the wrong venue, Kerberized NFS isn't exactly
unrelated to the KDC.

Kind regards
Phliipp Kern


-- 
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/slrniuruiv.nsr.tr...@kelgar.0x539.de

Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?

[Vincent Danjean]

On 05/06/2011 07:39, Vincent Bernat wrote:
> On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
> 
>> What I do is use upstream provided tarballs, then put aside
>> autotools-generated files, then autogenerate myself, and in the clean
>> rule put back the upstream-provided files (because I want not only
>> minimal required build routines idempotent but also building with
>> git-buildpackage).
> 
> In the clean rules, you can just delete those autogenerated files.

If you do not want git-buildpackage to complain (of
"not committed changes"), you need to restore them.

I often use this in my rules:
clean:
[...]
# if this is a git repository, restore removed files that would have
# been ignored by dpkg-source
-test -d .git && git checkout -- $$(git status | \
sed -e 
'/^#[[:space:]]*deleted:[[:space:]]*/s/^#[[:space:]]*deleted:[[:space:]]*//p;d' 
| \
grep -v '^debian/')


> 


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/4dee035f.3060...@free.fr

100+ Unique Comments on high PR Forums in just $20

[Camille James]

Hello, I have just noticed your requirement for Forum Posting  
services. If the requirement is still open with you, I would love  
to do this job. We are a dedicated team of talented writers who do  
forum posting  and blog commenting for our clients. We will  
post you unique content on every forum. In one week, we can offer 100  
comments on all high PR forums with live signature links in just  
$20We may negotiate it further, if you are interested.   
Please post your requirement details href="http://www.ezdia.com/jsp/index.do?showui=postproj&utm_source=bp-em-0706&utm_medium=fp";  
target="_blank">here. Waiting for your reply, Best  
Regards,Camille James Business Development Executive.San  
Francisco

Bug#629522: ITP: machina -- polyphonic MIDI sequencer based on finite-state automata

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: machina
  Version : 0~svn3366
  Upstream Author : David Robillard 
* URL : http://www.drobilla.net/software/machina/
* License : GPL
  Programming Lang: C++
  Description : polyphonic MIDI sequencer based on finite-state automata

 Machina is probabilistic (i.e. very small machines can produce interesting
 non-repetitive output) but also capable of deterministically representing
 any piece of “discrete note music” - or anything in between. There is also
 experimental support for evolving machines (using a Genetic Algorithm) to
 play similar (but not identical) music to an existing piece (from a MIDI
 file or real-time MIDI instrument input).

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer| quadris...@ubuntu.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0



-- 
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/20110607114509.GA30571@alessio-laptop

Bug#629504: general: Error during compiling kernel module at generating file vnode_if.h.

[Petr Salinger]

-I/usr/src/kfreebsd-source-8.1/sys/fs/puffs/puffs/../putter -DPUFFSDEBUG
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2
-mno-sse3 -ffreestanding -std=iso9899:1999  -c puffs_msgif.c In file
included from @/sys/vnode.h:563,
 from puffs_msgif.c:44:



Stop in /usr/src/kfreebsd-source-8.1/sys/fs/puffs/puffs.


Where is puffs from ?

http://www.netbsd.org/docs/puffs/ ?

It is not included in our kernel source package.

Petr




--
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/alpine.lrh.2.02.1106071350240.16...@sci.felk.cvut.cz

Processed: Re: Bug#629504: general: Error during compiling kernel module at generating file vnode_if.h.

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 629504 kfreebsd-source-8.1
Bug #629504 [general] general: Error during compiling kernel module at 
generating file vnode_if.h.
Bug reassigned from package 'general' to 'kfreebsd-source-8.1'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
629504: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629504
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.130744493129971.transcr...@bugs.debian.org

Bug#629529: ITP: jcaptcha -- Java framework for CAPTCHA definition and integration

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 


* Package name: jcaptcha
  Version : 2.0~alpha1
* URL : http://www.jcaptcha.net/
* License : LGPL-2.1
  Programming Lang: Java
  Description : Java framework for CAPTCHA definition and integration

 (J)ava (C)ompletely (A)utomated (P)ublic (T)est to tell (C)omputers
 and (H)umans (A) part. This library provides:
 .
  * Robust and reliable CAPTCHA implementation framework for JAVA
  * Accessible CAPTCHA implementations
  * Multi-type challenge (text, sound, image)

 This package is required to support the packaging of jenkins.



-- 
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/20110607124942.8250.7241.reportbug@hendrix.shouse.local

Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?

[Osamu Aoki]

On Tue, Jun 07, 2011 at 12:54:23PM +0200, Vincent Danjean wrote:
> On 05/06/2011 07:39, Vincent Bernat wrote:
> > On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
> > 
> >> What I do is use upstream provided tarballs, then put aside
> >> autotools-generated files, then autogenerate myself, and in the clean
> >> rule put back the upstream-provided files (because I want not only
> >> minimal required build routines idempotent but also building with
> >> git-buildpackage).
> > 
> > In the clean rules, you can just delete those autogenerated files.
> 
> If you do not want git-buildpackage to complain (of
> "not committed changes"), you need to restore them.
> 
> I often use this in my rules:
> clean:
>   [...]
> # if this is a git repository, restore removed files that would have
> # been ignored by dpkg-source
> -test -d .git && git checkout -- $$(git status | \
> sed -e 
> '/^#[[:space:]]*deleted:[[:space:]]*/s/^#[[:space:]]*deleted:[[:space:]]*//p;d'
>  | \
> grep -v '^debian/')

I thought "git reset --hard; git clean -f" is enough to get pristine
state under git for manual operation.  I am curious why this is done
with this fancy script?  Maybe this is something to do with
git-buildpackage which I should know.

(I was thinking , as long as git reflect pristine source situation, this
shorter type-able sequence restores source tree for me.  If inside
debian tree should not be recorded in git, we can add .gitignore with
debian in it.)
 

Osamu 


-- 
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/20110607123608.ga1...@debian.org

Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?

[Vincent Danjean]

On 07/06/2011 14:36, Osamu Aoki wrote:
> On Tue, Jun 07, 2011 at 12:54:23PM +0200, Vincent Danjean wrote:
>> On 05/06/2011 07:39, Vincent Bernat wrote:
>>> On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
>>>
 What I do is use upstream provided tarballs, then put aside
 autotools-generated files, then autogenerate myself, and in the clean
 rule put back the upstream-provided files (because I want not only
 minimal required build routines idempotent but also building with
 git-buildpackage).
>>>
>>> In the clean rules, you can just delete those autogenerated files.
>>
>> If you do not want git-buildpackage to complain (of
>> "not committed changes"), you need to restore them.
>>
>> I often use this in my rules:
>> clean:
>>  [...]
>> # if this is a git repository, restore removed files that would have
>> # been ignored by dpkg-source
>> -test -d .git && git checkout -- $$(git status | \
>> sed -e 
>> '/^#[[:space:]]*deleted:[[:space:]]*/s/^#[[:space:]]*deleted:[[:space:]]*//p;d'
>>  | \
>> grep -v '^debian/')
> 
> I thought "git reset --hard; git clean -f" is enough to get pristine
> state under git for manual operation.  I am curious why this is done
> with this fancy script?  Maybe this is something to do with
> git-buildpackage which I should know.

I do not want to do a reset if some files are modified/added and not
commited (the standard behavior of git-buildpackage, ie complaining, is
ok for me in this case).
  I only want that git-buildpackage ignores missing files as dpkg-source
does. It is also a quick a dirty script and I would be very pleased
to know a better way to do this.

  Regards,
Vincent

> (I was thinking , as long as git reflect pristine source situation, this
> shorter type-able sequence restores source tree for me.  If inside
> debian tree should not be recorded in git, we can add .gitignore with
> debian in it.)
>  
> 
> Osamu 
> 
> 


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/4dee24b1.3010...@free.fr

ITP: racktables - Datacenter asset management system

[david hannequin]

Package: wnpp
Version: N/A; reported 2011-06-07
Severity: wishlist

Package name: racktables
Version: 0.19.4
Upstream Author: Denis Ovsienko infrastat...@yandex.ru
URL: http://racktables.org/
License: GPL-2 
https://sourceforge.net/projects/racktables/files/RackTables-0.19.4.tar.gz/download
Description:  Racktables is a solution for datacenter and server room
asset management.
Source: 
http://downloads.sourceforge.net/project/racktables/RackTables-0.19.4.tar.gz

-- 
David Hannequin
Systèmes & Réseaux

FullSave
26 rue de Gironis - 31100 Toulouse
Tél +33 (0) 5 62 24 34 18
Fax +33 (0) 5 62 24 46 78


-- 
David Hannequin


--
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/banlktin_klo-an_9cuexx_xtqv8cui+...@mail.gmail.com

Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?

[Jonas Smedegaard]

On 11-06-07 at 12:54pm, Vincent Danjean wrote:
> On 05/06/2011 07:39, Vincent Bernat wrote:
> > On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
> > 
> >> What I do is use upstream provided tarballs, then put aside 
> >> autotools-generated files, then autogenerate myself, and in the 
> >> clean rule put back the upstream-provided files (because I want not 
> >> only minimal required build routines idempotent but also building 
> >> with git-buildpackage).
> > 
> > In the clean rules, you can just delete those autogenerated files.
> 
> If you do not want git-buildpackage to complain (of
> "not committed changes"), you need to restore them.
> 
> I often use this in my rules:
> clean:
>   [...]
> # if this is a git repository, restore removed files that would have
> # been ignored by dpkg-source
> -test -d .git && git checkout -- $$(git status | \
> sed -e 
> '/^#[[:space:]]*deleted:[[:space:]]*/s/^#[[:space:]]*deleted:[[:space:]]*//p;d'
>  | \
> grep -v '^debian/')

I strongly believe Debian packaging rules should always behave the same 
- at least the main rules required by Debian Policy.

Therefore I dislike patterns like above, which behaves different based 
on the presence of some files in source during build!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Bugs against packages from BPO

[Mehdi Dogguy]

Hi.

For now users of packages from BPO have to send a mail to debian-backports
mailing-list, according to [1]. I don't know how you handle those bugs,
but they seem very easy to miss (even if d-b@l.d.o isn't a high traffic list).

I was wondering if it makes sense to ask (kindly) debbugs's maintainer to
add new special tags (e.g. “squeeze-backports”, “lenny-backports”) that
would work exactly like “sid”, “squeeze”, … tags that we already have. It
would help to have a better integration of BPO and makes bugreporting less
confusing for users. When implemented in debbugs, reportbug could
automatically add those tags if the package comes from BPO.

>From a maintainer point of view, this could mean more burden. But, if ever
implemented, debbugs can send a copy of the bugreport to the backporter
only, and avoid sending it to the usual maintainer of the package.

What do you think?
- from debbugs POV, is it feasible?
- from maintainers POV, would you accept that?
- from backports FTP masters POV, do you think it's a good idea?

If we can't agree on this proposal, can somebody tell me why we didn't try
to have a BTS for backports? I personally think that we could have those
bugreports on bugs.d.o directly and that there is no need for another
instance of debbugs, because their number isn't insane, as most of us tend
to think.

[1] http://backports.debian.org/FAQ/

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
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/4dee3d9a.3080...@dogguy.org

Re: Bugs against packages from BPO

[Julien Cristau]

On Tue, Jun  7, 2011 at 17:02:50 +0200, Mehdi Dogguy wrote:

> >From a maintainer point of view, this could mean more burden. But, if ever
> implemented, debbugs can send a copy of the bugreport to the backporter
> only, and avoid sending it to the usual maintainer of the package.
> 
That was discussed a while ago (shortly after bpo moved to debian.org,
iirc), and it's still vaporware.  Excuse me while I don't hold my
breath.

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/20110607150749.gc25...@coloquinte.cristau.org

Re: Bugs against packages from BPO

[Paul Wise]

I like this idea and also think that bugs reported against backports
package versions could be automatically directed towards the
backporter instead of the maintainer. First bugs.debian.org would have
to learn about backports package versions.

--
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/BANLkTimJJGBVGKQWSxKcV6MXALp1XS6R=q...@mail.gmail.com

Bug#629541: ITP: pkg-php-tools -- various packaging tools and scripts for PHP PEAR packages

[Mathieu Parent]

Package: wnpp
Severity: wishlist
Owner: Mathieu Parent 

* Package name: pkg-php-tools
* Version : 0.1
* Upstream Author : Mathieu Parent 
* URL : 
* License : LGPL-3.0
* Programming Lang: Perl, PHP
* Description : various packaging tools and scripts for PHP PEAR packages


See announce on http://lists.alioth.debian.org/pipermail/pkg-php-
pear/2011-May/000106.html



-- 
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/20110607152223.2786.66295.report...@tourthieu.sathieu.net

Re: Bugs against packages from BPO

[Gerfried Fuchs]

   Hey,

* Mehdi Dogguy  [2011-06-07 17:02:50 CEST]:
> For now users of packages from BPO have to send a mail to
> debian-backports mailing-list, according to [1]. I don't know how you
> handle those bugs, but they seem very easy to miss (even if d-b@l.d.o
> isn't a high traffic list).

 This is correct.

> I was wondering if it makes sense to ask (kindly) debbugs's maintainer to
> add new special tags (e.g. “squeeze-backports”, “lenny-backports”) that
> would work exactly like “sid”, “squeeze”, … tags that we already have.

 I think you misinterpret these release tags: Setting them on a bug
means that the bug affects only that specific release. It happens though
quite regularly that bugs in backports aren't backport specific but also
affect testing/unstable, and through such an approach you would be
hiding the bugs from that view.

> It would help to have a better integration of BPO and makes
> bugreporting less confusing for users. When implemented in debbugs,
> reportbug could automatically add those tags if the package comes from
> BPO.

 The real issue with having backports bugs in the BTS is version
tracking: The BTS doesn't know about backports versions - and as long as
that is the case the BTS can't track bugs for backports. It's as simple
as that -- understanding-wise, unfortunately not coding-wise; otherwise
it would had been implemented in the meantime already.

 From what I understand help to get this fixed is more than just
welcomed.

> - from debbugs POV, is it feasible?

 Currently no, that's the first blocker on this road.

> - from maintainers POV, would you accept that?

 I've heard from very few people that would actually dislike it, but it
would be the right way to go in so many senses.

> - from backports FTP masters POV, do you think it's a good idea?

 I can only speak for myself (because partly I believe last time it was
brought up Alex had a different opinion on this than me), but yes, it
would be a good idea. Potentially we will manage to get a short BoF on
this topic at debconf with people from all involved parties attending to
improve this.

 But still, it needs people actually working on getting things
implemented.

> If we can't agree on this proposal, can somebody tell me why we didn't try
> to have a BTS for backports?

 Because a seperate BTS doesn't make much sense, the maintenance
overhead simply isn't that benefitial when the clean solution is to get
version tracking for backports adopted into the regular BTS.

> I personally think that we could have those bugreports on bugs.d.o
> directly and that there is no need for another instance of debbugs,
> because their number isn't insane, as most of us tend to think.

 Noone is thinking about insane numbers of bugs, at least not to the
best of my knowledge. But that's not the issue. Also you might want to
dig the archives of debian-devel from september last year, subject
"Backports service becoming official", starting at


 Enjoy!
Rhonda 
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


-- 
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/20110607153540.ga17...@anguilla.debian.or.at

Re: Bugs against packages from BPO

[Mehdi Dogguy]

On 07/06/2011 17:35, Gerfried Fuchs wrote:
> 
> I think you misinterpret these release tags:

No.

> Setting them on a bug means that the bug affects only that specific
> release. It happens though quite regularly that bugs in backports
> aren't backport specific but also affect testing/unstable, and through
> such an approach you would be hiding the bugs from that view.
> 

Yes. But, one can still check and remove those tags when appropriate.
My approach was just to avoid as much as possible to send false bugreports
to the usual maintainer. The reporter can remove those tags if he's sure
that it also applies to testing/unstable.

Thanks for your other answers on debugs.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
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/4dee46c5.5090...@dogguy.org

Re: Bugs against packages from BPO

[Gerfried Fuchs]

   Hey again,

* Mehdi Dogguy  [2011-06-07 17:41:57 CEST]:
> Yes. But, one can still check and remove those tags when appropriate.
> My approach was just to avoid as much as possible to send false bugreports
> to the usual maintainer. The reporter can remove those tags if he's sure
> that it also applies to testing/unstable.

 Ah right, that was the second big issue, that the BTS can't currently
handle maintainer contact information for different "branches" of
development. Personally I would assume that the backporter should also
care about watching the bugreports in the regular pool because they also
potentially affect their endusers, but the other way round is something
that not everyone is totally interested in; and even though it might be
rather low traffic, people should at least have the possibility to
filter them out conveniently.

 Thanks for bringing that point back to my mind. :)
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


-- 
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/20110607155028.ga20...@anguilla.debian.or.at

Re: throw away debs and source only uploads

[Don Armstrong]

On Tue, 07 Jun 2011, Andreas Barth wrote:
> * Don Armstrong (d...@debian.org) [110607 04:25]:
> > On Mon, 06 Jun 2011, Philipp Kern wrote:
> > > I.e. I think we should still allow non-buildd binaries, e.g. for
> > > those cases you mentioned.
> > 
> > Non-buildd binaries should still be allowed, but they should be
> > followed immediately by a binNMU. [Are there any cases where we
> > wouldn't want to rebuild the package after it was bootstrapped?]
> 
> There are cases where porters need to upload, because of "funny"
> issues. Or hand-builds within sane buildd chroots where the buildd
> software refuses. Or similar. (I think I did less than 10 such
> uploads recently.)

Ok. Am I correct that these odd cases are bugs which should be fixed?

If so, it seems reasonable to queue a binNMU, and then file bugs
appropriately if it failed.


Don Armstrong

-- 
[T]he question of whether Machines Can Think, [...] is about as
relevant as the question of whether Submarines Can Swim.
 -- Edsger W. Dijkstra "The threats to computing science"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20110607155947.gv4...@rzlab.ucr.edu

Re: Bugs against packages from BPO

[Ondřej Surý]

>> - from maintainers POV, would you accept that?
>
>  I've heard from very few people that would actually dislike it, but it
> would be the right way to go in so many senses.

The bugreport against the backported package at least needs to be
copied to whoever did the backport, which complicates the things. The
agreement between me and my backporters (and vice versa) is that they
are responsible for the backport.

> I think you misinterpret these release tags: Setting them on a bug
> means that the bug affects only that specific release. It happens though
> quite regularly that bugs in backports aren't backport specific but also
> affect testing/unstable, and through such an approach you would be
> hiding the bugs from that view.

That would be the backporters responsibility to check the bug and
remove/add tags as needed.

O.
-- 
Ondřej Surý 


--
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/BANLkTimShCM=5ihkecvmSmE79qLsBK8GY3=mbionj2se...@mail.gmail.com

Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Tollef Fog Heen]

]] Ben Finney 

| Neither the VCS repository link nor the VCS browse link work for
| http://packages.qa.debian.org/c/comixcursors.html>.

These have been fixed now.

| The VCS browse link doesn't work for
| http://packages.qa.debian.org/l/lojban-common.html>.

Ditto.

(Now, loggerhead has fallen over or is a fragile piece of software, so
that bit's still broken, but the apache config is at least correct.)

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


-- 
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/87wrgxioqu@qurzaw.varnish-software.com

Re: intermediate result of packaging-dev meta package discussion

[Benjamin Drung]

Am Dienstag, den 07.06.2011, 10:46 +0100 schrieb Neil Williams:
> On Tue, 07 Jun 2011 11:34:30 +0200
> Vincent Danjean  wrote:
> 
> > > A few days ago, we had a discussion about a packaging-dev meta package.
> > > The responses were between neutral and positive. Therefore I created a
> > > initial draft [1] and tried to incorporate all suggestions made in the
> > > discussion.
> > > 
> > > The list looks currently like this:
> > > 
> > > Depends: [...]
> > >  pbuilder | cowbuilder | sbuild,
> > 
> >   My laptop, where I do all my packaging work but final build, has
> > none of them installed. I've a separate machine with several chroots
> > (lenny, squeeze, unstable and several for ubuntu) managed with sbuild that
> > I use when I want to really build the package I will upload. Due to disk
> > space, I cannot instal them (chroots) on my laptop.
> >   I other people work like me, these tools can be moved to Recommends
> 
> I disagree. pbuilder or the alternatives are fundamental to best
> practice Debian packaging. The needs of Debian are wider than a single
> user having a problem with a single machine.
> 
> This package is trying to express best practice for packaging, to get a
> baseline. You admit that you have a way of building in a chroot and it
> isn't required that everyone uploading to Debian has this package
> installed, it is simply a way of making it simple for most people to
> have a standard set of build tools.
> 
> Most people would have space for a pbuilder chroot (it's only a few
> hundred megabytes even unpacked, it's the apt cache which takes up the
> space and that can be cleared with a configuration change) and everyone
> using packaging-dev should be expected (required) to use a chroot to
> build packages prior to upload.
> 
> Recommending chroot build tools is not strong enough.

Beginners are the target, not experienced packagers. That's why Neil's
reasons seems to be stronger for me than Vincent's. Therefore I will
leave the chroot dependency as dependency unless more people are in
favor of moving them to Recommends.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: throw away debs and source only uploads

[Andreas Barth]

* Don Armstrong (d...@debian.org) [110607 18:11]:
> On Tue, 07 Jun 2011, Andreas Barth wrote:
> > * Don Armstrong (d...@debian.org) [110607 04:25]:
> > > On Mon, 06 Jun 2011, Philipp Kern wrote:
> > > > I.e. I think we should still allow non-buildd binaries, e.g. for
> > > > those cases you mentioned.
> > > 
> > > Non-buildd binaries should still be allowed, but they should be
> > > followed immediately by a binNMU. [Are there any cases where we
> > > wouldn't want to rebuild the package after it was bootstrapped?]
> > 
> > There are cases where porters need to upload, because of "funny"
> > issues. Or hand-builds within sane buildd chroots where the buildd
> > software refuses. Or similar. (I think I did less than 10 such
> > uploads recently.)
> 
> Ok. Am I correct that these odd cases are bugs which should be fixed?

Usually yes. 

> If so, it seems reasonable to queue a binNMU, and then file bugs
> appropriately if it failed.

It's reasonable to queue a binNMU, but it's not to assume that it's
successful. Or that there might be transient issues, e.g. a hand-build
to just complete the transition to testing, and the next source
version is uploaded directly after the transition and built normally.
Or issues, where we don't need to wait for the binNMU to fail, but
just directly file the bug - of course I'm happy to fail the build by
hand in such cases.

As said, all that are exceptions to the rule.



Andi


-- 
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/20110607165245.gh2...@mails.so.argh.org

Re: How do I join the development team?

[Martin Bagge / brother]

On Sun, 5 Jun 2011, Jason Hsu wrote:


2.  A trash program: GNOME and KDE come with trash/recycle bins but ROX 
pinboard does not.


PCManFM with libfm has a trashbin. Lightweight enough?

--
/brother
http://martin.bagge.nu
On Bruce Schneier's birthday, a person standing at the very center of 
Stonehenge casts a shadow in the shape of Bruce Schneier's PGP public key 
fingerprint.


--
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/alpine.deb.2.00.1106071918290.16...@salyut.bsnet.se

Bug#629577: ITP: jtreg -- Regression Test Harness for the OpenJDK platform

[Guillaume Mazoyer]

Package: wnpp
Severity: wishlist
Owner: Guillaume Mazoyer 


* Package name: jtreg
  Version : 4.1
  Upstream Author : Sun Microsystems, Inc.
* URL : http://openjdk.java.net/jtreg/
* License : GNU General Public License, version 2, with the Classpath 
Exception
  Programming Lang: Java
  Description : Regression Test Harness for the OpenJDK platform

jtreg is the test harness used by the OpenJDK test framework.
This framework is intended primarily for regression tests.
It can also be used for unit tests, functional tests, and even simple product
tests -- in other words, just about any type of test except a conformance test,
which belong in a TCK.



-- 
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/20110607202005.9502.76650.report...@octane.info9.net

Bug#629584: ITP: dino -- Integrated MIDI piano roll editor and sequencer engine

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: dino
  Version : 0.2.8
  Upstream Author : Lars Luthman 
* URL : http://dino.nongnu.org
* License : GPL
  Programming Lang: C++
  Description : Integrated MIDI piano roll editor and sequencer engine

 Dino is a pattern-based sequencer which allows users to write
 small patterns of MIDI events and repeat and arrange them to
 create a whole song. Each track has its own patterns, so it
 is possible for example to play the same drum pattern over
 and over again while different lead synth patterns and basslines
 are playing.


-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer| quadris...@ubuntu.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0



-- 
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/20110607205653.GA3269@alessio-laptop

Bug#629587: ITP: cqrlog -- Advanced logging program for hamradio operators

[Petr Hlozek]

Package: wnpp
Severity: wishlist
Owner: Petr Hlozek 


* Package name: cqrlog
  Version : 1.0.0
  Upstream Author : Petr Hlozek , Martin Kratoska 

* URL : http://www.cqrlog.com/
* License : GPL
  Programming Lang: Object-Pascal (Lazarus)
  Description : Advanced logging program for hamradio operators



-- 
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/20110607213936.14334.20140.reportbug@turbo-zaba

Bug#629597: ITP: bedtools -- suite of utilities for comparing genomic features

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

  Package name: bedtools
  Version : 2.12.0
  Upstream Author : Aaron Quinlan
  URL : http://code.google.com/p/bedtools/
  License : GPL-2+
  Programming Lang: C++
  Description : suite of utilities for comparing genomic features

 The BEDTools utilities allow one to address common genomics tasks such as
 finding feature overlaps and computing coverage. The utilities are largely
 based on four widely-used file formats: BED, GFF/GTF, VCF, and SAM/BAM. Using
 BEDTools, one can develop sophisticated pipelines that answer complicated
 research questions by streaming several BEDTools together.

BEDTools is very popular in its field and will be a nice addition to Debian.  A
package is almost ready at http://git.debian.org/?p=debian-med/bedtools.git

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
Archive: 
http://lists.debian.org/20110607233751.4153.68459.reportbug@chouca.igloo

Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Ben Finney]

Tollef Fog Heen  writes:

> ]] Ben Finney 
>
> | Neither the VCS repository link nor the VCS browse link work for
> | http://packages.qa.debian.org/c/comixcursors.html>.
>
> These have been fixed now.

Not for me. The VCS repository link just gives a 404 error.

(Note that the correct response will look like an empty directory;
the VCS's hidden directory won't show up on a default directory listing
from the web server.)

> | The VCS browse link doesn't work for
> | http://packages.qa.debian.org/l/lojban-common.html>.
>
> Ditto.

That one's fixed.


I highlight these two because they're using different ways of getting at
the VCS repositories; previously both of the following would work:

$VCSNAME.debian.org/$VCSNAME/$PROJECTPATH/
$VCSNAME.debian.org/$PROJECTPATH/

-- 
 \ “Oh, I realize it's a penny here and a penny there, but look at |
  `\  me: I've worked myself up from nothing to a state of extreme |
_o__)  poverty.” —Groucho Marx |
Ben Finney


-- 
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/87r575ynwd@benfinney.id.au

Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Steve M. Robbins]

Tollef,

> ]] Ben Finney 
>
> | Neither the VCS repository link nor the VCS browse link work for
> | http://packages.qa.debian.org/c/comixcursors.html>.
>
> These have been fixed now.
> 
> | The VCS browse link doesn't work for
> | http://packages.qa.debian.org/l/lojban-common.html>.
>
> Ditto.

Great!  

Can the SVN ones be similarly fixed; e.g.
http://packages.qa.debian.org/i/insighttoolkit.html


Thanks,
-Steve


signature.asc
Description: Digital signature

Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Tollef Fog Heen]

]] "Steve M. Robbins" 

| Can the SVN ones be similarly fixed; e.g.
| http://packages.qa.debian.org/i/insighttoolkit.html

wsvn is already on the list of stuff still to fix as listed on
http://titanpad.com/yyhfwA9Pyr .

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


-- 
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/87d3ioj422@qurzaw.varnish-software.com

Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Tollef Fog Heen]

]] Ben Finney 

| Tollef Fog Heen  writes:
| 
| > ]] Ben Finney 
| >
| > | Neither the VCS repository link nor the VCS browse link work for
| > | http://packages.qa.debian.org/c/comixcursors.html>.
| >
| > These have been fixed now.
| 
| Not for me. The VCS repository link just gives a 404 error.

Indeed, fixed now.

| (Note that the correct response will look like an empty directory;
| the VCS's hidden directory won't show up on a default directory listing
| from the web server.)

I know about this, and I think it's a terrible decision from the bzr
team to by default point people to what looks like a completely empty
directory.  This is quite separate from wrong redirects, though.

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


-- 
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/878vtcj3um@qurzaw.varnish-software.com

Re: Bug#629276: NFS needs same dispensation to use DES as AFS

[Brian May]

On 7 June 2011 15:56, Steve Langasek  wrote:
> I would recommend asking the stable release manager.  He might say yes.

What email address do I use?

(I always have problems finding the email addresses of the release
managers :-( )
-- 
Brian May 


--
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/banlktiny-2kpwpur_fp7vs9eiwu10uf...@mail.gmail.com

Bug#629614: ITP: rhash -- utility for computing hash sums and magnet links

[rhash.admin]

Package: wnpp
Severity: wishlist
Owner: Alexey 

Hello! I'm working on 3 packages: rhash, librhash, librhash-dev
for the RHash program and its LibRHash library.

  Package name: rhash
  Version : 1.2.5
  Upstream Author : Alexey 
  URL : http://rhash.sourceforge.net/
  License : MIT  http://www.opensource.org/licenses/mit-license.php
  Programming Lang: C

RHash is powerful professional utility, supporting a wide range of 
hashing algorithms, such as CRC32, MD4, MD5, SHA1/SHA2, Tiger, TTH, 
BitTorrent BTIH, AICH, ED2K, GOST R 34.11-94, RIPEMD-160, HAS-160, 
EDON-R 256/512, Whirlpool, Snefru.


Features:
 * Output in a predefined (SFV, BSD) or a user-defined format.
 * Can calculate Magnet links and EDonkey 2000 links.
 * Updating hash files (adding hash sums of files missing in the 
hashfile).

 * Ability to process directories recursively.
 * Portability: the program works the same on Linux, *BSD or Windows.

The LibRHash library is lightweight, thread-safe and easy to learn.
It is used by several open source applications.



--
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/4def1074.9000...@gmail.com