Re: backward/forward binary compatibility checker

[Paul Wise]

On Fri, Aug 7, 2009 at 3:41 AM, Guillem Jover  wrote:

> How does this compare with projects like icheck or abicheck?

icheck is fairly unmaintained, since upstream is a former Debian developer.

No idea about abicheck, perhaps you could compare them Andrey?

-- 
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

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Pierre Habouzit]

On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote:
> Le Thu, Aug 06, 2009 at 09:26:02AM -0700, Russ Allbery a écrit :
> > 
> > (filterdiff comes with patchutils.)  Given that, this seems like a tempest
> > in a teapot to me.  Just convert the diff into whatever format the tool
> > that you're using expects or the reviewer wants to read.
> 
> Hi Russ and everybody,
> 
> I already explained that I prefered that the patch stays in the original 
> format

Then you'll need to write your "own" patch system that calls patch(1) to
apply the patches, à la cdbs-simple-patchsys.

-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


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

Bug#540319: ITP: python-ampqlib -- Simple non-threaded Python AMQP client library

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov 

* Package name: python-ampqlib
  Version : 0.6
  Upstream Author : Barry Pederson 
* URL : http://barryp.org/software/py-amqplib/
* License : LGPL 2.1+
  Programming Lang: Python
  Description : Simple non-threaded Python AMQP client library

Python client for the Advanced Message Queuing Procotol (AMQP) 0-8,
featuring basic messaging functionality and SSL support.



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

Re: piuparts-MBF: not using invoke-rc.d

[Holger Levsen]

Hi Jonas,

On Donnerstag, 6. August 2009, Jonas Meurer wrote:
> at least for zope2.1[01]-sandbox, i don't know how to fix that issue.
> invoking the initscript at postinst/prerm of the -sandbox packages will
> cause _all_ zope instances on the system to be restarted, and that isn't
> an option at all.
>
> thus the postinst/prerm scripts of -sandbox packages invoke the zopectl
> script at /var/lib/zope2.1[01]/instance/sandbox/bin/zopectl directly in
> order to only start/stop the sandbox instance that is being installed or
> removed.
>
> so any ideas what to do about this?

fix the zopectl script, so that it can start specific sandboxes and use that 
from your initscripts?


regards,
Holger


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

Bug#540327: ITP: akonadi-googledata -- Google calendar and contacts resource for Akonadi

[Fathi Boudra]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: akonadi-googledata
Version: 1.0
Upstream Author: Adenilson Cavalcanti 
URL: http://code.google.com/p/libgcal/
License: LGPL3
Description: Google calendar and contacts resource for Akonadi

 It provides an easy access to Google calendars events and contacts.

 This package contains the Google calendar and contacts resource for Akonadi,
 a Personal Information Management (PIM) storage service.



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

Bug#540332: ITP: at-spi2-core -- Assistive Technology Service Provider Interface (Core) - dbus

[Ray Wang]

Package: wnpp
Severity: wishlist
Owner: Ray Wang 


* Package name: at-spi2-core
  Version : 0.1.0
  Upstream Author : Mike Gorse 
Mark Doffman 
* URL : https://projects.codethink.co.uk/index.php/p/at-spi2
* License : LGPL
  Programming Lang: C
  Description : Assistive Technology Service Provider Interface (Core) - 
dbus

This library, based on ATK, is a general interface for applications to
make use of the accessibility toolkit.  This version is based on dbus.

-- System Information:
Debian Release: 5.0
  APT prefers lenny
  APT policy: (500, 'lenny')
Architecture: i386 (i686)



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

Bug#540333: RFH: emdebian-tools -- emdebian crossbuilding tool set

[Neil Williams]

Package: wnpp
Severity: normal

I request assistance with maintaining the emdebian-tools package.

For my reasons, see:
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/178-Why-I-missed-DebConf9.html

For background, see:
http://lists.debian.org/debian-embedded/2009/08/msg5.html
and for what needs to be done, see:
http://lists.debian.org/debian-embedded/2009/08/msg00016.html

For progress in Crush so far, see:
http://wiki.debian.org/EmdebianCodeAudit

emdebian-tools is the main package for cross-building Debian packages
for Emdebian Crush, the smaller cross-built distribution from the
Embedded Debian Project, an official sub-project of Debian.

Crush aims to use busybox to replace coreutils, remove perl and
prepare a binary distribution for embedded systems, based on Debian.

Current problems with cross-building in Debian mean that the next
release of Crush is likely to be skipped unless a lot of work is done
to improve the system used to create Crush 1.0. Once multiarch is
implemented in Debian, future releases of Crush will need more work to
adapt to the multiarch system.

Development of Emdebian Grip - the alternative distribution from Emdebian
with no functional changes compared to standard Debian - is unaffected
and Grip 2.0 is still in active development and likely to be released
for seven architectures alongside Debian 6.0 "squeeze".

The package description is:
 A collection of scripts to ease cross-building Debian packages for
 Emdebian, reducing package size, separating translations into
 individual tdeb packages and handling dependencies. Includes support
 for installing cross building toolchains and building custom
 toolchains, automated patching of Debian packages to suit Emdebian
 needs and cross building Debian packages inside or outside a chroot.
 .
 The emdebian-tools package primarily serves to support Emdebian Crush,
 the cross-built distribution using busybox and lacking perl support.
 For Emdebian Grip support, see the emdebian-grip package.
 .
 Run emsetup first, using the simulate option, to see what changes
 may be needed.
 .
 Includes support for debian/xcontrol files and the debian-xcontrol
 package, to specify which cross dependencies need to be installed
 with apt-cross to make the cross objects available to the cross
 compiler and cross-building autobuilder support.
 .
 A simple reportbug wrapper assists in filing and closing bugs against
 the buildd.emdebian.org pseudo-package, documenting and tracking
 issues within the Emdebian build systems that are distinct from the
 Debian build logs and bugs.
 .
 Includes experimental support for creating a uClibc toolchain from an
 existing glibc/gcc toolchain for the same target architecture.



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

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Neil McGovern]

On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote:
> Giving a standard interface to reviewers is a laudable goal, but I do not see
> reviewers except in elaborate scenarios about security. Therefore I will not
> trade a real benefit for a hypothetical one, even if both are neglectible.
> Also, I think that it is very important in a project of 1,000 persons to stick
> to facts, and avoid building illusions together. So as long as there is no
> reviewing process nor package reviews, there is no need to adapt to imaginary
> reviewers.
>

/me raises his release team hat.

Neil
-- 
* Tolimar votes for debconf7 to be somewhere where he speaks the
language.
 That would a veto for switzerland ;)
 Tolimar: that also vetos germany


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

piuparts-MBF: overwriting other packages files

[Holger Levsen]

Hi,

as announced yesterday, I will now continue starting threads about different 
bug categories detected by piuparts, with the aim to agree on mass filing 
bugs with a sensible severity.

Today I picked another simple category: packages which failed the piuparts 
test because the package tries to overwrite another packages files without 
declaring a conflict or replaces relation. See policy 7.4 and 7.6 at 
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts and 
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

http://piuparts.debian.org/sid/overwrite_other_packages_files_error.html and 
http://piuparts.debian.org/squeeze/overwrite_other_packages_files_error.html
lists those packages. 

Eleven packages in squeeze and ten in sid are affected. See below for dd-list 
output.

If somebody disagrees that these bugs should be filed with severity serious, 
speak up now, this weekend I plan to file those bugs.

Even though this is IMO again a pretty clear case of violating a mandatory 
policy requierement, where the violation seriously disrupts user 
expectations, I havent filed bugs yet, because of ENOTIME :-)


regards,
Holger


Guenter Geiger (Debian/GNU) 
   sox (U)

Andrew Lee (李健秋) 
   stardict

Daniel Baumann 
   botan-devel
   tryton-modules-analytic-invoice

Mathias Behrle 
   tryton-modules-analytic-invoice (U)

Marcus Better 
   ser (U)

Wes Chow 
   sparsehash (U)

Debian Cyrus SASL Team 
   cyrus-sasl2-heimdal

Debian Scientific Computing Team 
   sundials

Debian VoIP Team 
   ser

Fabian Fagerholm 
   cyrus-sasl2-heimdal (U)

Anthony Fok 
   stardict (U)

RISKO Gergely 
   libmcrypt

Pascal Giard 
   sox

Gerber van der Graaf 
   libgpiv

GRUB Maintainers 
   grub2

Simon Horman 
   pacemaker (U)

Kilian Krause 
   ser (U)

Rafael Laboissiere 
   sundials (U)

Jordi Mallach 
   grub2 (U)

Patrick Matthäi 
   luckybackup

Robert Millan 
   grub2 (U)

Mark Purcell 
   ser (U)

Athena Capital Research 
   sparsehash

Anibal Monsalve Salazar 
   gdbm
   pacemaker

Roberto C. Sanchez 
   cyrus-sasl2-heimdal (U)
   sparsehash (U)

Riku Voipio 
   scratchbox2

Jaldhar H. Vyas 
   libcgi-application-plugins-perl

Felix Zielcke 
   grub2 (U)



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

Bug#540336: ITP: at-spi2-atk -- Assistive Technology Service Provider Interface (ATK) - dbus

[Ray Wang]

Package: wnpp
Severity: wishlist
Owner: Ray Wang 


* Package name: at-spi2-atk
  Version : 0.1.0
  Upstream Author : Mike Gorse 
Mark Doffman 
* URL : https://projects.codethink.co.uk/index.php/p/at-spi2
* License : LGPL
  Programming Lang: C
  Description : Assistive Technology Service Provider Interface (ATK) - dbus

This version of at-spi is a major break from previous versions.
It has been completely rewritten to use D-Bus rather than
ORBIT / CORBA for its transport protocol.

-- System Information:
Debian Release: 5.0
  APT prefers lenny
  APT policy: (500, 'lenny')
Architecture: i386 (i686)



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

Re: Bug#540332: ITP: at-spi2-core -- Assistive Technology Service Provider Interface (Core) - dbus

[Cyril Brulebois]

Ray Wang  (07/08/2009):
> Package: wnpp
> Severity: wishlist
> Owner: Ray Wang 
> 
> 
> * Package name: at-spi2-core
>   Version : 0.1.0
>   Upstream Author : Mike Gorse 
> Mark Doffman 
> * URL : https://projects.codethink.co.uk/index.php/p/at-spi2
> * License : LGPL
>   Programming Lang: C
>   Description : Assistive Technology Service Provider Interface (Core) - 
> dbus
> 
> This library, based on ATK, is a general interface for applications to
> make use of the accessibility toolkit.  This version is based on dbus.

Hi,

it was mentioned by Mario in [1]. I guess it'd be nice for you to
coordinate with “us” (-accessibility) for the packaging of at-*
packages, Mario already has spent some time diving into this set of
packages.

 1. <871vnukw3s@x2.delysid.org>

Thanks for considering.

(No need to Cc me if you keep -devel or -accessibility in the loop.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#540341: RFH: apt-cross -- retrieve, build and install libraries for cross-compiling

[Neil Williams]

Package: wnpp
Severity: normal

I request assistance with maintaining the apt-cross package.

For my reasons, see:
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/178-Why-I-missed-DebConf9.html

For background, see:
http://lists.debian.org/debian-embedded/2009/08/msg5.html
and for what needs to be done, see:
http://lists.debian.org/debian-embedded/2009/08/msg00016.html

The main issue with apt-cross is already filed as a bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502433

Those who help with apt-cross should also help with emdebian-tools and
vice-versa. See bug # 540333

The package description is:
 apt-cross is intended to make it easier to locate, download, install and
 update your cross-compiling libraries, directly from the Debian archives.
 .
 By default, apt-cross uses /etc/apt/sources.list to find the current Debian
 package file for the architecture specified (or dpkg-cross default) and in
 the suite specified (default is unstable). Alternatively, you can specify
 a different mirror. Downloaded files can be passed directly to dpkg-cross
 using the -b or -i commands to apt-cross.



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

Re: Bug#540341: RFH: apt-cross -- retrieve, build and install libraries for cross-compiling

[Siggy Brentrup]

On Fri, Aug 07, 2009 at 11:04 +0100, Neil Williams wrote:
> The package description is:
>  apt-cross is intended to make it easier to locate, download, install and
>  update your cross-compiling libraries, directly from the Debian archives.

I'm interested to help on this, but I'm still waiting for DAM's
decision to reopen my account for almost 4 weeks.  Being a DD from
'95-'04 I will not do any substantial work related to Debian w/o a
vote.

Thanks
  Siggy
-- 
Please don't Cc: me when replying, I might not see either copy.
   bsb-at-psycho-dot-informationsanarchistik-dot-de
   or:bsb-at-psycho-dot-i21k-dot-de
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


signature.asc
Description: Digital signature

Re: Status of new source formats project

[Peter Eisentraut]

On Wednesday 05 August 2009 14:21:54 Cyril Brulebois wrote:
> Michael Banck  (05/08/2009):
> > On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote:
> > > And for the format of the patch, I do not know what to tell them
> > > apart that unified diff is the preferred format of some Debian
> > > developers,
> >
> > It's the preferred format for 99% of all Free Software work/projects
> > AFAICT.
>
> I was wondering who could be in the last 1%. At least OpenSceneGraph
> people[1] prefer being sent the whole files. :)

For everyone's further entertainment: The PostgreSQL project heavily prefers 
context diff patch submissions.  This is also part of the reason why 
PostgreSQL is still stuck on CVS, because Git does not produce context diffs.  
There you go.


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

Re: backward/forward binary compatibility checker

[Andrey Ponomarenko]

Guillem Jover wrote:
> Hi!
>
> On Thu, 2009-08-06 at 18:38:41 +0400, Andrey Ponomarenko wrote:
>   
>> Colleagues, I'm software engineer from Institute for System
>> Programing of Russian Academy of Sciences and we are developing a free
>> lightweight tool for checking backward/forward binary compatibility of
>> shared C/C++ libraries in OS Linux. It checks interface signatures and
>> data type definitions in two library versions (headers and shared
>> objects) and searches ABI changes that may lead to incompatibility.
>> We have released 1.1 version of this tool and we'd like you to consider
>> its usefulness for your project.
>> The wiki-page with the latest release of binary compatibility checker is
>> http://ispras.linux-foundation.org/index.php/ABI_compliance_checker
>> 
>
> How does this compare with projects like icheck or abicheck?
>
> regards,
> guillem
>
>
>   

1) ABIcheck was intended for entirely other purposes. ABIcheck is a tool
for checking an application's compliance with a library's ABI.
ABI-compliance-checker was intended for checking backward binary
compatibility of a library. For more information about icheck see:
http://abicheck.sourceforge.net/

2) icheck was intended for the same purposes as an
ABI-compliance-checker, but icheck has many drawbacks:
a) icheck does not support C++ libraries (or C libraries with C++
parts).
b) icheck does not divide ABI and API changes because it does not
check shared objects.
c)  icheck contains 467 files and 61 sub-folders;
ABI-compliance-checker is a single file.
d) icheck searches changes in `gcc -E -x c-header header_name.h`
output, that represent a header after preprocessing - it is a very
inconveniently  method because it need a lot of code for parsing header
(about 750 kb of code); ABI-compliance-checker searches differences in
the `gcc -fdump-translation-unit header_name.h` output, that represents
a syntax tree of the header files.
e) as described in the documentation
(http://www.digipedia.pl/man/icheck.1.html) icheck need three runs to
get compatibility report - it is not easy.  
f) icheck compliance report is a plain text file,
ABI-compliance-checker provide convenient report in HTML format.
g) icheck 0.9.7 failed to run from the first time on my OpenSUSE11.1
with error message like "Can't locate CParse/Parser/PerlXS.pm".

Re: backward/forward binary compatibility checker

[Steve Langasek]

On Fri, Aug 07, 2009 at 04:57:38PM +0400, Andrey Ponomarenko wrote:
> 2) icheck was intended for the same purposes as an
> ABI-compliance-checker, but icheck has many drawbacks:

[...]

> c)  icheck contains 467 files and 61 sub-folders;
> ABI-compliance-checker is a single file.

I am concerned that you think this is a feature.

> d) icheck searches changes in `gcc -E -x c-header header_name.h`
> output, that represent a header after preprocessing - it is a very
> inconveniently  method because it need a lot of code for parsing header
> (about 750 kb of code); ABI-compliance-checker searches differences in
> the `gcc -fdump-translation-unit header_name.h` output, that represents
> a syntax tree of the header files.

I'm not familiar with -fdump-translation-unit.  Is there any possibility
that ABI-compliance-checker will overlook ABI changes that icheck will
catch?

Does ABI-compliance-checker's representation of the ABI behave in an
architecture-independent fashion, so that it's possible to draw conclusions
about ABIs on other architectures than the architecture on which you're
running the check?

> e) as described in the documentation
> (http://www.digipedia.pl/man/icheck.1.html) icheck need three runs to
> get compatibility report - it is not easy.

Huh?  You have to have a representation of the baseline ABI to compare
against.  Does ABI-compliance-checker assume that both copies of the header
will be unpacked and available locally at the same time, in order to be able
to do everything in "one run"?  That would be much less useful; we don't
want to have to carry around the actual headers or objects from the
reference version of the library in order to be able to run these tests, we
would want to be able to ship a "manifest" representation of the reference
ABI in our sources to compare against.
  
Cheers,
-- 
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/
slanga...@ubuntu.com vor...@debian.org


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

Bug#540356: ITP: python-lamson -- A pure Python SMTP server

[David Watson]

Package: wnpp
Severity: wishlist
Owner: David Watson 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: python-lamson
  Version : 1.0pre1
  Upstream Author : Zed Shaw 
* URL : http://lamsonproject.org/
* License : GPL-3
  Programming Lang: Python
  Description : A pure Python SMTP server

 Lamson is a pure Python SMTP server designed to create robust and
 complex mail applications in the style of modern web frameworks such as
 Django. Unlike traditional SMTP servers like Postfix or Sendmail,
 Lamson has all the features of a web application stack (ORM, templates,
 routing, handlers, state machines, Python) without needing to configure
 alias files, run newaliases, or juggle tons of tiny fragile processes.
 Lamson also plays well with other web frameworks and Python libraries.

-- 
David Watson




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

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Frank Küster]

Pierre Habouzit  wrote:

> On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote:
>> Le Thu, Aug 06, 2009 at 09:26:02AM -0700, Russ Allbery a écrit :
>> > 
>> > (filterdiff comes with patchutils.)  Given that, this seems like a tempest
>> > in a teapot to me.  Just convert the diff into whatever format the tool
>> > that you're using expects or the reviewer wants to read.
>> 
>> Hi Russ and everybody,
>> 
>> I already explained that I prefered that the patch stays in the original 
>> format
>
> Then you'll need to write your "own" patch system that calls patch(1) to
> apply the patches, à la cdbs-simple-patchsys.

Why should he need to do that?  If you'd had written "submit patches to
dpkg", I could get a meaning out of it, but here?  He doesn't want to
diverge from upstream.

Regards, Frank

-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Frank Küster]

Neil McGovern  wrote:

> On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote:
>> Giving a standard interface to reviewers is a laudable goal, but I do not see
>> reviewers except in elaborate scenarios about security. Therefore I will not
>> trade a real benefit for a hypothetical one, even if both are neglectible.
>> Also, I think that it is very important in a project of 1,000 persons to 
>> stick
>> to facts, and avoid building illusions together. So as long as there is no
>> reviewing process nor package reviews, there is no need to adapt to imaginary
>> reviewers.
>>
>
> /me raises his release team hat.

During a freeze, one typically wouldn't apply the upstream patches
anyway, but just cherry-pick individual changes.  In this case, it
wouldn't be a problem to create unified diffs.  Or even reformat the
context diff to unified, in case the upstream patch contains nothing but
RC (and translation) fixes.

Regards, Frank

-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Bug#540365: ITP: turnin-ng -- Assignment submitter and manager

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 


* Package name: turnin-ng
  Version : 1.0~rc1
  Upstream Author : Ryan Kavanagh 
* URL : http://github.com/ryanakca/Turnin-NG/tree/master
* License : GPLv2+
  Programming Lang: Python
  Description : Assignment submitter and manager

 Turnin-NG is an assignment submission suite written in Python and composed of
 turnin and project. Students can use the turnin command to submit an
 assignment to a course. Professors and TAs (teaching assistants) can use
 project permits TAs to manage submitted assignments, making them easier to
 grade.



 Turnin-NG is a replacement / rewrite for the original turnin/project programmes
 (which were written for the SPARC architecture and who's source code has been
 lost) used in multiple North American universities such as Queen's University,
 UC San Diego, WPI, etc.

-- 
|_)|_/  Ryan Kavanagh |  Gnupg key
| \| \  http://blog.ryanak.ca/|  E95EDDC9


signature.asc
Description: Digital signature

Bug#540372: ITP: python-mock -- Mocking and Testing Library

[David Watson]

Package: wnpp
Severity: wishlist
Owner: David Watson 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: python-mock
  Version : 0.5.0
  Upstream Author : Michael Foord 
* URL : http://www.voidspace.org.uk/python/mock/
* License : BSD
  Programming Lang: Python
  Description : Mocking and Testing Library

 mock provides a core mock.Mock class that is intended to reduce the
 need to create a host of trivial stubs throughout your test suite.
 After performing an action, you can make assertions about which methods
 / attributes were used and arguments they were called with. You can
 also specify return values and set specific attributes in the normal
 way.

-- 
David Watson





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

Re: backward/forward binary compatibility checker

[Andrey Ponomarenko]

Steve Langasek wrote:
> On Fri, Aug 07, 2009 at 04:57:38PM +0400, Andrey Ponomarenko wrote:
>   
>> 2) icheck was intended for the same purposes as an
>> ABI-compliance-checker, but icheck has many drawbacks:
>> 
>
> [...]
>
>   
>> c)  icheck contains 467 files and 61 sub-folders;
>> ABI-compliance-checker is a single file.
>> 
>
> I am concerned that you think this is a feature.
>
>   
I think that tool designed for one simple feature must be in one file.
>   
>> d) icheck searches changes in `gcc -E -x c-header header_name.h`
>> output, that represent a header after preprocessing - it is a very
>> inconveniently  method because it need a lot of code for parsing header
>> (about 750 kb of code); ABI-compliance-checker searches differences in
>> the `gcc -fdump-translation-unit header_name.h` output, that represents
>> a syntax tree of the header files.
>> 
>
> I'm not familiar with -fdump-translation-unit.  Is there any possibility
> that ABI-compliance-checker will overlook ABI changes that icheck will
> catch?
>   
-fdump-translation-unit compiler option provides only more convenient
output (syntax tree) for checking compatibility.
> Does ABI-compliance-checker's representation of the ABI behave in an
> architecture-independent fashion, so that it's possible to draw conclusions
> about ABIs on other architectures than the architecture on which you're
> running the check?
>
>   
ABI-compliance-checker's representation of the ABI really depends on
architecture. But it is not important. You may transfer all your header
files to another host and compare it.
>> e) as described in the documentation
>> (http://www.digipedia.pl/man/icheck.1.html) icheck need three runs to
>> get compatibility report - it is not easy.
>> 
>
>   
I was completely wrong, icheck may generate compatibility report in one
run, sorry.
> Huh?  You have to have a representation of the baseline ABI to compare
> against.  Does ABI-compliance-checker assume that both copies of the header
> will be unpacked and available locally at the same time, in order to be able
> to do everything in "one run"?  That would be much less useful; we don't
> want to have to carry around the actual headers or objects from the
> reference version of the library in order to be able to run these tests, we
> would want to be able to ship a "manifest" representation of the reference
> ABI in our sources to compare against.
>   
You are right, ABI-compliance-checker does not allow such advantages
yet. But usually upstream library developers have all installed versions
on one host (if not, they may install it), and you may transfer all your
header files as well as your "manifest" representation to other host and
check it.
>   
> Cheers,
>   
In general icheck may be used for checking binary compatibility of C
libraries, but it has several drawbacks.

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Manoj Srivastava]

On Thu, Aug 06 2009, Charles Plessy wrote:


> This said, if there were a project-wide momentum for standardising on one 
> patch
> format, I would not oppose. This would probably be a release goal, a
> preparation for a Policy change, or a demand from the security team to the
> package manintainers. Something with a motivation, a plan, some facts and some
> volunteers to get things done.

Why would we want to add that to policy? It seems like that both
 the context diff and the unified diffs offer the same information (ie,
 the change, and the context), and that each format can be mechanically
 transformed from one to the other, and that which form one uses depends
 on the individual.

I find that chunks with small changed grouped close together
 read better in unified format, but if the chunk is long, with lots of
 smallish changes interspersed with common context, then following the
 logic of the old code versus the new code is better using context diffs
 (you do not have to mentally keep  track of two different flows).

This is mostly subjective, I know.

So policy should never promote one personal preference over
 another, given that the formats convey the same information, and can be
 transformed by tools, and are equally easily applied.

I mean, really, people, we are not the Borg. Why should dpkg
 care, as long as the patch applies?

manoj
 not inclined to pander to the hobgoblin of small minds
-- 
Save yourself from the 'Gates' of hell, use Linux."  -- like that
one. The_Kind @ LinuxNet
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

Re: piuparts-MBF: overwriting other packages files

[Manoj Srivastava]

On Fri, Aug 07 2009, Holger Levsen wrote:


> Today I picked another simple category: packages which failed the piuparts 
> test because the package tries to overwrite another packages files without 
> declaring a conflict or replaces relation. See policy 7.4 and 7.6 at 
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts and 
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

While it is good to discover these bugs, is puiparts the correct
 place to do this check? Won't puiparts only report on packages
 installed on the machine on which the test is run, and thus miss any
 conflicts on packages not currently installed?

Also, shouldn't dpkg also complain about installing a package
 with conflicts? And thus if one were running puiparts on one's new
 package, one would already know about this when one installed the
 package on the machine on testing?

I guess I am somewhat confused. Is this puiparts test telling me
 something I would not learn anyway when I install my package for
 testing?

Also, wouldn't a periodic check of the Contents.gz files yield
 much more exhaustive results?

manoj
-- 
There is no reaching the unattainable with mounts like these, but with
himself well under control a disciplined man can get there. 323
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

Re: piuparts-MBF: overwriting other packages files

[Holger Levsen]

Hi Manoj,

On Freitag, 7. August 2009, Manoj Srivastava wrote:
> On Fri, Aug 07 2009, Holger Levsen wrote:
> > Today I picked another simple category: packages which failed the
> > piuparts test because the package tries to overwrite another packages
> > files without declaring a conflict or replaces relation. See policy 7.4
> > and 7.6 at
> > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
> > and
> > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

I've changed this text now: s/a conflict or/ and also removed the reference to 
policy 7.4, since conflicts are not enough to prevent the problem of a 
package trying to overwrite anothers files.

> While it is good to discover these bugs, is puiparts the correct
>  place to do this check? Won't puiparts only report on packages
>  installed on the machine on which the test is run, and thus miss any
>  conflicts on packages not currently installed?

The piuparts tests on piuparts.d.o are run in clean chroots. 
http://piuparts.debian.org has more info on the setup.

> Also, shouldn't dpkg also complain about installing a package
>  with conflicts? And thus if one were running puiparts on one's new
>  package, one would already know about this when one installed the
>  package on the machine on testing?
>
> I guess I am somewhat confused. Is this puiparts test telling me
>  something I would not learn anyway when I install my package for
>  testing?

Not really, especially if you run piuparts yourself before uploading ;) And of 
course you can also manually do what piuparts does. But not every package is 
maintained by someone who does this, some packages even don't have a 
maintainer anymore :-) 

piuparts(.d.o) is ment as a tool to catch common problems systematically.

> Also, wouldn't a periodic check of the Contents.gz files yield
>  much more exhaustive results?

Yes, the results of that are available at 
http://edos.debian.net/missing-conflicts/ ;-)


regards,
Holger


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

Re: waf into NEW, please test it with your packages

[Josselin Mouette]

Le dimanche 26 juillet 2009 à 13:51 +0200, Luca Falavigna a écrit :
> waf preferred design is to provide a self-unpacking Python script to be
> installed into projects' root directories and then executed from there,
> we adjusted it to be available system-wide, so everyone can use it, no
> matter if waf script is available in upstream tarballs or not.

> Debian GNOME Maintainers 
>gnome-python (U)
>gnome-python-desktop (U)

These ones have a dual build system, and currently we use the one based
on the autotools.

That said, if you know how to tell whether non-free files are
distributed in the tarball as part of waf, I would find it interesting.

Cheers,
-- 
 .''`.  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

Bug#540453: ITP: samtools -- processing sequence alignments in SAM and BAM formats

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

  Package name: samtools
  Version : 0.1.5c-1
  Upstream Author : Heng Li, Bob Handsaker, Jue Ruan, Colin Hercus.
  URL : http://samtools.sourceforge.net/
  License : MIT and NetBSD
  Programming Lang: C, Perl
  Description : processing sequence alignments in SAM and BAM formats


Source: samtools
Section: science
Priority: optional
Maintainer: Debian-Med Packaging Team 

DM-Upload-Allowed: yes
Uploaders: Charles Plessy 
Build-Depends: debhelper (>= 7), cdbs, libncurses5-dev, zlib1g-dev
Standards-Version: 3.8.2
Homepage: http://samtools.sourceforge.net
Vcs-Browser: 
http://svn.debian.org/wsvn/debian-med/trunk/packages/samtools/trunk/?rev=0&sc=0
Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/samtools/trunk/

Package: samtools
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: processing sequence alignments in SAM and BAM formats
 Samtools is a set of utilities that manipulate nucleotide sequence alignments
 in the BAM format. It imports from and exports to the SAM (Sequence
 Alignment/Map) format, does sorting, merging and indexing, and allows to
 retrieve reads in any regions swiftly. It is designed to work on a stream, and
 is able to open a BAM (not SAM) file on a remote FTP server.

Package: libbam-dev
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: manipulates nucleotide sequence alignments in BAM or SAM format 
 The BAM library provides I/O and various operations on manipulating nucleotide
 sequence alignments in the BAM (Binary Alignment/Mapping) or SAM (Sequence
 Alignment/Map) format. It now supports importing from or exporting to TAM,
 sorting, merging, generating pileup, and quickly retrieval of reads overlapped
 with a specified region.



Machine-readable license summary, see ‘http://dep.debian.net/deps/dep5/’.

Name  :  SAMtools
Contact   :  SAMtools mailing list 
Source:  
http://downloads.sourceforge.net/sourceforge/samtools/samtools-0.1.5c.tar.bz2

Copyright :  © 2008–2009, Genome Research Ltd.
License   :  MIT

Permission is hereby granted, free of charge, to any person obtaining a 
copy
of this software and associated documentation files (the "Software"), 
to deal
in the Software without restriction, including without limitation the 
rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or 
sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included 
in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
IN
THE SOFTWARE.

Files :  bgzf.*, bgzip.c
Copyright :  © 2008 Broad Institute / Massachusetts Institute of Technology
License   :  MIT


Files :  razf.*
Name  :  RAZF : Random Access compressed(Z) File
Copyright :  2008, Jue Ruan , Heng Li 
License   :  Similar to NetBSD license.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE
ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.


Files :  misc/m