Re: Introducing the "Debian's Automated Code Analysis" (DACA) project
On Mon, Dec 20, 2010 at 07:08:59PM -0600, Raphael Geissert wrote:
> > Have you already thought about Coccinelle? [1,2] In the context of
> > IRILL I'm working with some of the authors and we have already
> > anticipated with them the idea of having Coccinelle runs on the
> > Debian code base. It was just at a brainstorming level up to now,
> > but now that I know about DACA it clearly makes sense to integrate
> > with your effort.
Background: I'm discussing these days the possibility of running
Coccinelle on the Debian archive with Julia Lawall (one of Coccinelle
authors and who has worked on integrating it into Linux kernel
toolchain).
> I knew about Coccinelle, but hadn't thought about running it. Are
> there pre- made patches that could be used?
Starting from Linux 2.6.36, there's a dir scripts/coccinelle/ in
upstream Linux. It contains Coccinelle patterns to find bugs; some of
them propose patches as well, but I'm not sure what is the exact amount
of patches vs report-only. According to Julia, some of those patterns
are kernel-specific and expect a specific contact which is created by
kernel Makefiles; other patterns are OTOH fully generic. I guess the
best way to figure out how many of them are generic is to actually give
them a try.
What I find very interesting for Coccinelle, is that we can imagine a
growing set of patterns, contributed by users, package maintainers, QA
team, etc. However, that will need some support in DACA to re-run the
analysis of a given tool on the whole archive, which I'm not sure it's
something you had in mind to support.
> > It is now approved, but apparently no VCS is associated to it.
> GForge bug, worked around by the admins now.
Thanks!
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#607712: RFP: libsoap-wsdl-perl -- SOAP with WSDL support
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org --- Please fill out the fields below. --- Package name: libsoap-wsdl-perl Version: 2.00.10 Upstream Author: Martin Kutter URL: http://search.cpan.org/~mkutter/SOAP-WSDL-2.00.10/ License: GPL, Artistic License Description: SOAP with WSDL support This module is used in Google API. Please add it in Debian. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#607721: ITP: goldencheetah -- Cycling Performance Software
Package: wnpp Severity: wishlist Owner: KURASHIKI Satoru * Package name: goldencheetah Version : 2.0 Upstream Author : Sean Rhea * URL : http://goldencheetah.org/ * License : GPL2 Programming Lang: C++ Description : Cycling Performance Software GoldenCheetah is a software package that: * Downloads ride data directly from the CycleOps PowerTap and the SRM PowerControl V. Support for SRM PowerControl VI and VII is planned for the future. * Imports ride data downloaded with other programs, including TrainingPeaks WKO+ and the manufacturers' software for the Ergomo, Garmin, Polar, PowerTap, and SRM devices. * Provides a rich set of analysis tools, including a critical power graph, BikeScore calculation, histogram analysis, a best interval finder, and a pedal force versus pedal velocity chart, to name just a few. -- 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/20101221115751.28890.87727.report...@protea.in.yoikaze.org
Bug#607748: ITP: libclass-std-fast-perl -- faster but less secure replacement for Class::Std
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libclass-std-fast-perl Version : 0.0.8 Upstream Author : Andreas 'ac0v' Specht - a...@cpan.org * URL : http://search.cpan.org/dist/Class-Std-Fast/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : faster but less secure replacement for Class::Std Class::Std::Fast allows you to use the beautiful API of Class::Std in a faster way than Class::Std does. You can get the object's ident via scalarifiyng your object. Getting the objects ident is still possible via the ident method, but it's faster to scalarify your object. -- 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/20101221173342.ga11...@belanna.comodo.priv.at
Re: Full install/removal/upgrade test results available
* Mike Hommey , 2010-11-19, 09:18:
Mike Hommey
python-xpcom (U)
I /think/ this could be solved by not using a pre-depends on
xulrunner-1.9.1.
Indeed.
OTOH, the pre-depends solves a part of another problem though not
entirely, due to triggers ordering: the xulrunner-1.9.1 trigger can't
work until the python-support trigger has been run...
I don't see how pre-depends could have helped here. On the first glance
it makes it only worse. E.g., when I install python-xpcom in a clean
chroot I get:
| Unpacking python-xpcom (from .../python-xpcom_1%3a0.0~hg20100212-2_i386.deb)
...
| Processing triggers for xulrunner-1.9.1 ...
| Obtaining the module object from Python failed.
|
| : No module named xpcom.server
| Obtaining the module object from Python failed.
|
| : No module named xpcom.server
When I moved ${xulrunner:Depends} from Pre-Depends to Depends,
everything was registered just fine.
The only fix for that issue that I can think of would be to stop using
python-support... If other people have ideas, I'm all ears.
I think you could manually trigger xulrunner-1.9.1 in python-xpcom's
postinst if it's not already registered. See the attached patch (well,
except maybe xulrunner version shouldn't be hardcoded).
--
Jakub Wilk
diff -u pyxpcom-0.0~hg20100212/debian/control pyxpcom-0.0~hg20100212/debian/control
--- pyxpcom-0.0~hg20100212/debian/control
+++ pyxpcom-0.0~hg20100212/debian/control
@@ -18,8 +18,8 @@
Provides: ${python:Provides}
Depends: ${shlibs:Depends},
${misc:Depends},
- ${python:Depends}
-Pre-Depends: ${xulrunner:Depends}
+ ${python:Depends},
+ ${xulrunner:Depends}
Breaks: epiphany-gecko (<< 2.28)
XB-Python-Version: ${python:Versions}
Description: XPCOM bindings for Python
diff -u pyxpcom-0.0~hg20100212/debian/postinst pyxpcom-0.0~hg20100212/debian/postinst
--- pyxpcom-0.0~hg20100212/debian/postinst
+++ pyxpcom-0.0~hg20100212/debian/postinst
@@ -9,2 +9,7 @@
+if ! grep -F '@mozilla.org/module-loader/python;' /usr/lib/xulrunner-1.9.1/components/compreg.dat > /dev/null
+then
+ dpkg-trigger /usr/lib/xulrunner-1.9.1/components
+fi
+
#DEBHELPER#
Re: Full install/removal/upgrade test results available
On Tue, Dec 21, 2010 at 08:37:53PM +0100, Jakub Wilk wrote:
> * Mike Hommey , 2010-11-19, 09:18:
> >>Mike Hommey
> >> python-xpcom (U)
> >
> >I /think/ this could be solved by not using a pre-depends on
> >xulrunner-1.9.1.
>
> Indeed.
>
> >OTOH, the pre-depends solves a part of another problem though not
> >entirely, due to triggers ordering: the xulrunner-1.9.1 trigger
> >can't work until the python-support trigger has been run...
>
> I don't see how pre-depends could have helped here.
I don't remember the details, but it made things half better.
> On the first
> glance it makes it only worse. E.g., when I install python-xpcom in
> a clean chroot I get:
>
> | Unpacking python-xpcom (from
> .../python-xpcom_1%3a0.0~hg20100212-2_i386.deb) ...
> | Processing triggers for xulrunner-1.9.1 ...
> | Obtaining the module object from Python failed.
> |
> | : No module named xpcom.server
> | Obtaining the module object from Python failed.
> |
> | : No module named xpcom.server
>
> When I moved ${xulrunner:Depends} from Pre-Depends to Depends,
> everything was registered just fine.
>
> >The only fix for that issue that I can think of would be to stop
> >using python-support... If other people have ideas, I'm all ears.
>
> I think you could manually trigger xulrunner-1.9.1 in python-xpcom's
> postinst if it's not already registered. See the attached patch
> (well, except maybe xulrunner version shouldn't be hardcoded).
I'd expect that to fail as well, because of python-support trigger not
having been run yet.
Part of the problem is that the xulrunner-1.9.1's postinst or trigger can
run with python-xpcom unpacked but not registered with python-support.
Adding update-python-modules -p in python-xpcom postinst could make
things slightly better, but that would still leave xulrunner-1.9.1's
postinst complaining if it's run before python-xpcom's.
What if xulrunner-1.9.1's postinst would do nothing for configure ?
would the trigger still kick in when one installs xulrunner-1.9.1 only?
Mike
--
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/20101221195957.gb3...@glandium.org
Re: Full install/removal/upgrade test results available
* Mike Hommey , 2010-12-21, 20:59: I think you could manually trigger xulrunner-1.9.1 in python-xpcom's postinst if it's not already registered. See the attached patch (well, except maybe xulrunner version shouldn't be hardcoded). I'd expect that to fail as well, because of python-support trigger not having been run yet. Part of the problem is that the xulrunner-1.9.1's postinst or trigger can run with python-xpcom unpacked but not registered with python-support. Adding update-python-modules -p in python-xpcom postinst could make things slightly better, "update-python-modules -p" is already in python-xpcom's postinst and it does exactly what python-support trigger would do. but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. Unfortunately, this is true. -- Jakub Wilk -- 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/20101221204154.ga3...@jwilk.net
Re: Bug#606791: Full install/removal/upgrade test results available
On Tue, Dec 21, 2010 at 09:41:54PM +0100, Jakub Wilk wrote: > * Mike Hommey , 2010-12-21, 20:59: > >>I think you could manually trigger xulrunner-1.9.1 in > >>python-xpcom's postinst if it's not already registered. See the > >>attached patch (well, except maybe xulrunner version shouldn't > >>be hardcoded). > > > >I'd expect that to fail as well, because of python-support trigger not > >having been run yet. > > > >Part of the problem is that the xulrunner-1.9.1's postinst or trigger can > >run with python-xpcom unpacked but not registered with python-support. > > > >Adding update-python-modules -p in python-xpcom postinst could make > >things slightly better, > > "update-python-modules -p" is already in python-xpcom's postinst and > it does exactly what python-support trigger would do. Which I must have added in an attempt to fix the issue, so it's possibly not enough. > >but that would still leave xulrunner-1.9.1's postinst complaining > >if it's run before python-xpcom's. > > Unfortunately, this is true. But then, it's only noise, which is still better than a failure to upgrade. So in the worst case scenario where we don't find anything better, and if we are sure it doesn't break any other case, we could just remove the pre-depend and be done with it. Mike -- 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/20101221211212.ga5...@glandium.org
Bug#607764: ITP: pd-hid -- a Pd object for getting data from USB HID devices
Package: wnpp Severity: wishlist Owner: "Hans-Christoph Steiner" * Package name: pd-hid Version : 0.7 Upstream Author : Hans-Christoph Steiner * URL : http://at.or.at/hans/pd/ * License : GPL Programming Lang: C Description : a Pd object for getting data from USB HID devices [hid] is a Pure Data object for reading data from USB HID devices like keyboards, mice, joysticks, gamepads, keypads, and all sorts of other esoteric controllers like USB knobs, touchscreens, Apple IR Remotes, etc. It represents the data with a cross-platform message scheme which is then translated to the underlying native API for input devices (Linux input.h or Mac OS X HID Utilities). -- 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/20101221214340.30434.9247.report...@blinky.at.or.at
