Bug#646183: ITP: jsonpipe -- Convert JSON to a UNIX-friendly line-based format
Package: wnpp Severity: wishlist Owner: Dominique Belhachemi * Package name: jsonpipe Version : 0.0.7 Upstream Author : Zachary Voase * URL : http://pypi.python.org/pypi/jsonpipe * License : Public Domain Programming Lang: Python Description : Convert JSON to a UNIX-friendly line-based format jsonpipe traverses a JSON object and produces a simple, line-based textual format which can be processed by all your UNIX favourites like grep, sed, awk, cut and diff. It may also be valuable within programming languages---in fact, it was originally conceived as a way of writing simple test assertions against JSON output without coupling the tests too closely to the specific structure used. -- 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/20111022005511.1696.6330.reportbug@debiansid
Bug#646181: ITP: calabash -- Bash-style pipelining syntax for Python generators
Package: wnpp Severity: wishlist Owner: Dominique Belhachemi * Package name: calabash Version : 0.0.3 Upstream Author : Zachary Voase * URL : http://pypi.python.org/pypi/calabash * License : Public Domain Programming Lang: Python Description : Bash-style pipelining syntax for Python generators -- 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/20111022003405.1639.86835.reportbug@debiansid
Bug#646179: ITP: django-tastypie -- webservice API framework for Django
Package: wnpp Severity: wishlist Owner: Dominique Belhachemi * Package name: django-tastypie Version : 0.9.7 Upstream Author : Daniel Lindsley * URL : http://django-tastypie.readthedocs.org/en/latest/index.html * License : BSD Programming Lang: Python Description : webservice API framework for Django Tastypie is an webservice API framework for Django. It provides a convenient, yet powerful and highly customizable, abstraction for creating REST-style interfaces. -- 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/20111022001210.1601.65722.reportbug@debiansid
Re: Packages depending on libncurses5 but not build-depending on libncurses-dev
On 2011-10-19 23:06 +0200, Sven Joachim wrote: > Recently the readline-dev package and its GPL2 variant > libreadline-gplv2-dev dropped their dependencies on libncurses5-dev. > This prompted me to look for packages that currently depend on > libncurses5 but do not build-depend on libncurses5-dev or its aliases > libncurses-dev and ncurses-dev, nor have libncurses5-dev pulled in via > other means. > > In the end I found 58 such packages on i386 in unstable/experimental, > all but two of which build-depend on one of the libreadline*-dev > packages. One of those 56 packages (atari800) should not have been in the list, since libncurses5-dev _is_ pulled in by its other build dependencies, and four packages had maintainer uploads adding libncurses5-dev to Build-Depends, which is the easiest though not necessarily the best fix. This leaves 51 packages to check, which fall into four categories. A (*) indicates that the problem vanishes if libtinfo-dev provides libtermcap.so as an alias to libtinfo.so (see #644426). a. Packages which FTBFS due to unrelated problems (6): == ctsim #642709 cyphesis-cpp #606724 gnudatalanguage #642715 gutenprint#639071 sqlite#646032 sqlite3 #642584 I haven't really looked at those. b. Packages which FTBFS due to -lncurses etc. not available (21): = acedb cdcd ddd dvbstreamer eresi eukleides evolver gnu-smalltalk illuminator inetutils lftp libphysfs lie lua5.2 multipath-tools qcake tclreadline (*) twinkle udftools uml-utilities zeroc-ice I'll file bugs against those in short order. c. Packages which build, but disable readline support (8): == bacula chrony dbacl gcl glusterfs (*) lustre malaga xqf This is an even worse category, since the next rebuild of those packages could silently drop functionality. Which severity would be more appropriate for bug reports, "important" or "serious"? d. Packages which build fine (16): == atftp bc dump fityk gftp ginac gnokii honeyd ipmitool nickle samba scanmem torque units yap yaz Those are candidates for bug reports at low severity. I don't intend to file those bug reports myself. Cheers, Sven pgpWI8qa0efTn.pgp Description: PGP signature
Bug#646131: ITP: pg_comparator -- efficient PostgreSQL table content comparison and synchronization
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: pg_comparator Version: 1.7.0 Upstream Author: Fabien Coelho URL: http://pgfoundry.org/projects/pg-comparator/ License: BSD Description: efficient PostgreSQL table content comparison and synchronization -- 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/20111021163123.ga4...@gmail.com
Re: Packages depending on libncurses5 but not build-depending on libncurses-dev
On 2011-10-21 12:13 +0200, Colin Watson wrote: > On Thu, Oct 20, 2011 at 08:48:20PM +0200, Sven Joachim wrote: >> >> Actually, just adding the build dependency is not the best solution in >> such cases, since you'll get a spurious dependency on libncurses5 >> (dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided >> if "debian/spectemu-x11/usr/bin/xspect" were not uselessly linked >> against it (they use none of its symbols)). >> >> TRT is to patch the upstream build system and fix the >> configure.in/configure.ac/Makefile files which erroneously believe that >> -lncurses/-lcurses/-ltermcap is necessary for linking against readline. > > Ah, thanks. That's more effort than I expected anyone else to go to for > investigating a contrib package. ;-) Actually I'm investigating (i.e. building) all of these packages, and the vast majority of them has the same problem. Only a handful or so have reason to link against ncurses. I'll send a status update soon. > Fixed properly in 0.94a-14. Thanks! Cheers, Sven pgp0OPBHvbKE1.pgp Description: PGP signature
relationship with Ubuntu - call for feedback
[ Mail-Followup-To: -derivatives ]
Dear Developers,
1.5 years ago I attended UDS (the Ubuntu Developer Summit) and
presented there a summary of the goods and bads of the relationships
among Debian and Ubuntu. To refresh your memory you might look at my old
call for feedback [1], the summary of the answers I got, and a report of
the trip [3].
[1] http://lists.debian.org/debian-project/2010/04/msg00069.html
[2] http://lists.debian.org/debian-project/2010/05/msg00083.html
[3] http://lists.debian.org/debian-project/2010/05/msg00084.html
18 months later --- and also because the next slot will be well past the
end of the current DPL term --- I think that it'd be good to summarize
how and if relationships among Debian and Ubuntu have evolved. That's
why I've accepted the kind invitation to attend next UDS, which will
take place from October 31 to November 4, 2011 (~ 10 days from now).
There, I'll be happy to take part in the usual F2F session to discuss
the status of the relationships among the two distros. I'll also have a
brief plenary speech to present Debian's views on the matter to a mixed
audience of Ubuntu members, Canonical employees, and upstream
developers.
To represent Debian's views instead of only my own, I'm looking for
feedback on how do you think relationships among the two projects have
evolved in the past 18 months. I'll surely mention that many of the
initiatives we are now doing for *all* Debian derivatives out there
sprinkled from the idea of setting up a "front desk" in Debian for
Ubuntu people. Idea that we then generalized, with very useful results.
More generally, I'd like to hear from you about:
- if and how the relationships among Debian and Ubuntu have changed in
the past 18 months
- success stories of good collaboration among the two projects
- epic fails about bad collaborations among the two projects
- any other desiderata or suggestion you might have to improve
collaboration among the two projects
As a more specific request, I'm also looking for help in collecting
numerical figures about how work is flowing among Debian and Ubuntu. In
particular, if you have data handy that could show the *evolution over
time* of stuff like:
- number of patches originating in one project and accepted in the
other
- number of people active in one project becoming active in the other
- etc.
I'd like to hear from you. If you don't have those data handy but you're
willing to collect them for me, ... even better :-) You'll have my
gratitude and you'd help in giving substance to existing gut feelings,
which is always good.
If you'd like to discuss the above publicly, I suggest doing so on
-derivatives. If OTOH you want to point me to specific episodes you'd
like to remain private, feel free to mail me at leader@d.o.
Many thanks in advance for your help,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Packages depending on libncurses5 but not build-depending on libncurses-dev
On Thu, Oct 20, 2011 at 08:48:20PM +0200, Sven Joachim wrote: > On 2011-10-20 14:05 +0200, Colin Watson wrote: > > On Wed, Oct 19, 2011 at 11:06:20PM +0200, Sven Joachim wrote: > >> Colin Watson > >>spectemu > > > > Fixed in 0.94a-13, thanks. > > Actually, just adding the build dependency is not the best solution in > such cases, since you'll get a spurious dependency on libncurses5 > (dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided > if "debian/spectemu-x11/usr/bin/xspect" were not uselessly linked > against it (they use none of its symbols)). > > TRT is to patch the upstream build system and fix the > configure.in/configure.ac/Makefile files which erroneously believe that > -lncurses/-lcurses/-ltermcap is necessary for linking against readline. Ah, thanks. That's more effort than I expected anyone else to go to for investigating a contrib package. ;-) Fixed properly in 0.94a-14. -- Colin Watson [cjwat...@debian.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/20111021101347.gb20...@riva.dynamic.greenend.org.uk
Re: Coinstallability of Fortran libraries built with different compilers
Cross-posting this to debian-devel for greater visibility on multiarch, On 2011-10-20 17:30, Enrico Zini wrote: Hello, another issue caused by a lack of standards for Fortran .mod files is that one cannot use, say, gfortran, to link to a library built with another compiler like ifort. We are starting to need to install development systems that would allow both a gfortran toolchain and an ifort toolchain. That would mean having to compile all libraries twice, and installing them twice in the system. I have been experimenting with hacks like installing gfortran files in /usr/include and /usr/lib and ifort files in /usr/include/ifort and /usr/lib/ifort, and with a bit of insisting, things can be made to work. That has also the nice property that standard Debian packages, that are built with gfortran, fit normally in the system. Is that a solution as good as anything, or are you doing something better? One point to think of is how this works with multiarch, which is being introduced in Debian. Instead of 'ifort' should we use the architecture triplet, eg. i386-linux-intel instead ? Then the libraries go in i386-linux-intel rather than i386-linux-gnu for gfortran; ditto for the .mod files in /usr/include/i386-linux-intel I'd avoid /usr/include/ifort as it looks too much like a subdirectory used by package ifort, rather than somewhere netcdf would expect to find its stuff, etc. Following the multiarch pattern means we can use pkg-config correctly for Intel compilers; e.g. /usr/lib/i386-linux-intel/pkgconfig contains the .pc files for the Intel versions; we can either then set the PKG_CONFIG_PATH or use the 'cross-compiler pkgconfig' to get pkg-config to Do The Right Thing. Regards Alastair Ciao, Enrico -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- 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/4ea13b20.7060...@sceal.ie
call for volunteers: Debian liaisons for Google Code-In
[ Mail-Followup-To: -project ]
TL;DR: I'm looking for volunteers that will act as Debian Project
liaisons (or "admins") for the Google Code In initiative [1]. Deadline
for project applications is November 1st; we'll miss it unless we have
the volunteers before that date. Feel free to volunteer either on
-project or by mailing me at leader@d.o.
---
The Google Code In (GCI) initiative [1] is a contest organized by Google
that encourages student participation into Free Software
projects. Compared to the more famous Google Summer of Code (GSOC)
initiative [2], GCI focuses on smaller tasks.
[1] http://code.google.com/gci
[2] http://code.google.com/soc
According to feedback I've received from the Debian liaisons from last
year GCI (thanks a lot, Ana!), GCI students are quite likely to remain
involved into Debian, with higher percentages than GSOC. That outcome is
really valuable for our project.
Additionally, we could use the chance of initiatives like GCI to work on
ways to maintain a list of Debian "easy hacks". As recently shown by the
LibreOffice example, such lists can be very effective in attracting new
contributors to a Free Software project. We have tried in the past
similar initiatives using "gift" tags [3,4], but that has not really
worked out. I think we should try again and make it work, possibly via
different/new technical means.
[3] http://lists.debian.org/debian-devel/2007/12/msg00679.html
[4]
http://upsilon.cc/~zack/blog/posts/2008/08/PTS_integrated_with_mentors_and_gifts/
For all the above reasons, I'm calling for volunteers willing to act as
GCI admins. The task / requirements are about:
- having time to devote to the task from the beginning of November to
the beginning of January
- calling for / organizing ways to collect Debian "easy hacks", that
will be given out as GCI tasks
- interacting with the students that will take part in GCI
Background material and feedback/proposals on how to make it work
properly in Debian can be found in a slide deck by Ana [5].
[5] http://penta.debconf.org/dc11_schedule/attachments/189_google-code-in.pdf
The deadline for *project* applications in GCI is November 1st. We'll
need to have volunteers before that date, as it'd be pointless to apply
if we aren't sure Debian can participate properly in GCI. According to
feedback from past admins, it'd be wise to have at least 3 volunteers
before deciding to apply.
Many thanks in advance!,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
