Re: simultaneous installation lib and lib-mpi
On Sun, Apr 26, 2009 at 08:19:20PM +0200, Magnus Holmgren wrote: > On torsdagen den 26 februari 2009, Gerber van der Graaf wrote: > > I came across this problem when packaging my own libgpiv3 / libgpiv-mpi3 > > (recently accepted and uploaded). These libraries are used by the other > > packages gpivtools / gpivtools-mpi from a single upstream source (not > > yet available on Deb). When testing the packaging of gpivtools(-mpi) > > with pbuilder it only can be done if libgpiv3 and libgpiv-mpi3 are to be > > installed simultaneously. Otherwise the building of one of the packages > > gpivtools / gpivtools-mpi is impossible. > > > > While working on the packaging of gpivtools(-mpi) I am getting across a > > similar problem with other libraries that are available in seriel and > > -mpi (libhdf5-serial-dev libhdf5-openmpi-dev to be more specific). Only > > one of these can be installed at once. As I also work with Paraview, > > which depends on libhdf5-openmpi, packaging and the use of gpivtools > > (that depends on libhdf5-dev) is impossible. (It is preferred to have > > the dependancy on libhdf5-dev, even in gpivtools-mpi as the .h5 files > > are quite small and don't need to be stored/retrieved in parallel way.) > > > > My question is why isn't it possible to package such libraries in a way > > they can be installed simultaneously? Am I doing something wrong here? > > If not, a suggestion might be to provide this possibility by filing a > > 'feature request' bug against all -mpi libraries. If this really is a > > weak point in packaging such libs, shouldn't it become a formal > > packaging policy? > > There are more examples, such as cyrus-sasl2, which contains two Kerberos > GSSAPI modules, one using MIT Kerberos 5 and one using Heimdal. But because > those libraries can't be installed simultaneously, there is a separate source > package, cyrus-sasl2-heimdal, with a copy of the upstream tarball, which only > builds the Heimdal module packages. Currently I don't think there is any > other solution to this problem, and solving it "for real" would require > rather serious changes to how packages are built, but it might still be > meaningful to bring it up on -devel, which I've done now. > The best reasonable solution is convincing upstream to build rather different lib names and sonames for each case. That would imply that all people depending on the mpi lib flavor should change their library names. Providing the same kind of implementation in our distribution is a viable possibility, but diverged by upstream: that should be done in the library package, while the serial and mpi -dev packages still should retain the same names (and conflict each other). This is what I will implement for the HDF5 case. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
True Residual Incomes working with our team, Guaranteed
Making big gains from home has never been this simple. The most automated, most effective global home business in the world! Secure yourself a top spot before masses join below you. Revolutionary product line, you have to see to believe this: http://alive7.gobeearn.in/?b=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc Thank you, M. Gold Whenever an individual or a business decides that success has been attained, progress stops [Thomas J Watson] This message was sent by user: alive7 on our system. To be removed or report abuse click below. Power Marketing Team #1776 PO Box 13240,Johnsonville,Wellington NZ 6440 http://alive7.gobeearn.in/rm/?b=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: simultaneous installation lib and lib-mpi
A start has been made already some time ago with this. See Debian bug #521221 libhdf5-openmpi-1.6.6-0: simultaneous installation of -serial and -mpi packages Gerber On Thu, 2009-04-30 at 10:11 +0200, Francesco P. Lovergine wrote: > On Sun, Apr 26, 2009 at 08:19:20PM +0200, Magnus Holmgren wrote: > > On torsdagen den 26 februari 2009, Gerber van der Graaf wrote: > > > I came across this problem when packaging my own libgpiv3 / libgpiv-mpi3 > > > (recently accepted and uploaded). These libraries are used by the other > > > packages gpivtools / gpivtools-mpi from a single upstream source (not > > > yet available on Deb). When testing the packaging of gpivtools(-mpi) > > > with pbuilder it only can be done if libgpiv3 and libgpiv-mpi3 are to be > > > installed simultaneously. Otherwise the building of one of the packages > > > gpivtools / gpivtools-mpi is impossible. > > > > > > While working on the packaging of gpivtools(-mpi) I am getting across a > > > similar problem with other libraries that are available in seriel and > > > -mpi (libhdf5-serial-dev libhdf5-openmpi-dev to be more specific). Only > > > one of these can be installed at once. As I also work with Paraview, > > > which depends on libhdf5-openmpi, packaging and the use of gpivtools > > > (that depends on libhdf5-dev) is impossible. (It is preferred to have > > > the dependancy on libhdf5-dev, even in gpivtools-mpi as the .h5 files > > > are quite small and don't need to be stored/retrieved in parallel way.) > > > > > > My question is why isn't it possible to package such libraries in a way > > > they can be installed simultaneously? Am I doing something wrong here? > > > If not, a suggestion might be to provide this possibility by filing a > > > 'feature request' bug against all -mpi libraries. If this really is a > > > weak point in packaging such libs, shouldn't it become a formal > > > packaging policy? > > > > There are more examples, such as cyrus-sasl2, which contains two Kerberos > > GSSAPI modules, one using MIT Kerberos 5 and one using Heimdal. But because > > those libraries can't be installed simultaneously, there is a separate > > source > > package, cyrus-sasl2-heimdal, with a copy of the upstream tarball, which > > only > > builds the Heimdal module packages. Currently I don't think there is any > > other solution to this problem, and solving it "for real" would require > > rather serious changes to how packages are built, but it might still be > > meaningful to bring it up on -devel, which I've done now. > > > > The best reasonable solution is convincing upstream to build rather different > lib names and sonames for each case. That would imply that all people > depending on the mpi lib flavor should change their library names. Providing > the same kind of implementation in our distribution is a viable possibility, > but diverged by upstream: that should be done in the library package, while > the serial and mpi -dev packages still should retain the same names (and > conflict each other). This is what I will implement for the HDF5 case. > > -- > Francesco P. Lovergine > > signature.asc Description: This is a digitally signed message part
Re: Two watch files-related MBFs
Raphael Geissert wrote: Once I file the bug reports I will be giving about two weeks before I remove the hack from DEHS and later from the DDPO. The lintian check has been around for many months now and it has given maintainers enough time to prepare an upload to fix some bugs on their packages so I don't see the need to wait any longer than that. two weeks are not debian period ;-) Version one watch files (actually versionless watch files) have been considered obsolete for more than two releases now. Since a lot of special casing code is needed to handle those I would therefore like to file bug reports against packages shipping that kind of watch files so that the maintainers have a chance to make an upload before the code is removed from uscan. A lintian check[2] has also been in place for many months now, and according to it there are 60 packages in unstable/main with versionless watch files. Are these bugs? I find no official documentation on format of debian/watch files. Thus, theoretically, you should change the tools and then you could fill the bugs (debian/watch not working). BTW, on first proposed MBF you write about DEHS and DDPO, and on the second only about uscan. I would like that the tools will behave in a similar manner (maybe with extra warnings on uscan). ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Wed, 29 Apr 2009 19:40:12 +0200, Josselin Mouette wrote: Le mercredi 29 avril 2009 à 18:51 +0200, Jiří Paleček a écrit : I've hacked a little into dpkg-shlibdeps and while doing this, I've found that the code makes allowance for a single library being mentioned in two different symbol files. I'd like to ask if (and when) can such situation actually arise. My first guess would be nvidia-glx and its diversion of libGL.so.1. Yes, but even then, libGL.so.1 (the one used for building a package) is only mentioned in one symbol file, namely the one from nvidia-glx, isn't it (let's put aside the package doesn't feature a symbol file)? Why should the libgl1-mesa-glx symbol file, if it existed, be taken into account? Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Two watch files-related MBFs
On Thu, Apr 30, 2009 at 03:16:44PM +0200, Giacomo A. Catenazzi wrote: > I find no official documentation on format of debian/watch files. man uscan -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Bug#526340: ITP: libdata-treedumper-renderer-dhtml-perl -- simple Perl DHTML renderer for Data::TreeDumper
Package: wnpp Severity: wishlist Owner: Peter Pentchev * Package name: libdata-treedumper-renderer-dhtml-perl Version : 0.09 Upstream Author : Nadim Ibn Hamouda el Khemir * URL : http://search.cpan.org/dist/Data::TreeDumper::Renderer::DHTML/ * License : Perl Programming Lang: Perl Description : simple Perl DHTML renderer for Data::TreeDumper Data::TreeDumper dumps Perl variable data in a tree-like fashion and allows the use of various output formatting processors. . Data::TreeDumper::Renderer::DHTML is such a processor which outputs the data as DHTML code. This module would help HTML::Template::Compiled (ITP: #521093) complete its full test suite. I intend to maintain it as part of the Debian Perl Group. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If you think this sentence is confusing, then change one pig. pgppY3usdR3SX.pgp Description: PGP signature
Bug#526338: ITP: libdata-treedumper-perl -- Perl module for dumping data structures in various formats
Package: wnpp Severity: wishlist Owner: Peter Pentchev * Package name: libdata-treedumper-perl Version : 0.35 Upstream Author : Khemir Nadim ibn Hamouda * URL : http://search.cpan.org/dist/Data-TreeDumper/ * License : Perl Programming Lang: Perl Description : Perl module for dumping data structures in various formats Data::TreeDumper dumps Perl variable data in a tree-like fashion and allows the use of various output formatting processors. It also supports various means of filtering and sorting the output. This module would help HTML::Template::Compiled (ITP: #521093) complete its full test suite. I intend to maintain it as part of the Debian Perl Group. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpPWJlcTBywg.pgp Description: PGP signature
Re: dpkg-shlibdeps question
On Thu, 30 Apr 2009, Jiří Paleček wrote: > Yes, but even then, libGL.so.1 (the one used for building a package) is > only mentioned in one symbol file, namely the one from nvidia-glx, isn't > it (let's put aside the package doesn't feature a symbol file)? Why > should the libgl1-mesa-glx symbol file, if it existed, be taken into > account? We could maybe help you if you told us to what part of the code you refer when you say that a single library can be mentioned in two different symbols files ? The code is what it is for many reasons including the fact that dpkg -S can return multiple packages for a single lib file. In practice, it should almost never happen (except diversion) and the result when it happens is not specified (in the doc at least). In practice you might get a mix of both dependencies and to avoid any problem the packaging of the diverting library should simply stay compatible to the one of the official library (i.e. generate the same dependencies). Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526342: ITP: libcheck-isa-perl -- Perl module for correct checking of an object's class
Package: wnpp Severity: wishlist Owner: Peter Pentchev * Package name: libcheck-isa-perl Version : 0.04 Upstream Author : Yuval Kogman * URL : http://search.cpan.org/dist/Check-ISA/ * License : Perl Programming Lang: Perl Description : Perl module for correct checking of an object's class This module provides several functions to assist in testing whether a value is an object, and if so asking about its class. This module is needed as a dependency of Data::TreeDumper (ITP #526338). I intend to maintain it as part of the Debian Perl Group. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Do you think anybody has ever had *precisely this thought* before? pgpVjX2qBV7lV.pgp Description: PGP signature
Bug#526345: ITP: libasa-perl -- Perl module for expanding a class or object's list of base classes
Package: wnpp Severity: wishlist Owner: Peter Pentchev * Package name: libasa-perl Version : 0.02 Upstream Author : Adam Kennedy * URL : http://search.cpan.org/dist/asa/ * License : Perl Programming Lang: Perl Description : Perl module for expanding a class or object's list of base classes The asa pragma attempts a new approach to bringing Java-style interfaces or Perl 6-style roles to Perl 5. It allows a class or object to look like a derivative of another class without actually specifying it in the @ISA array. This module is needed as a dependency of Check::ISA (ITP #526342). I intend to maintain it as part of the Debian Perl Group. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgp11UeYedX2t.pgp Description: PGP signature
Bug#526347: ITP: libgtk2-notify-perl -- Perl interface to libnotify
Package: wnpp Owner: Ryan Niebur Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libgtk2-notify-perl Version : 0.05 Upstream Author : Florian Ragwit * URL : http://search.cpan.org/dist/Gtk2-Notify/ * License : LGPL-2 Programming Lang: Perl Description : Perl interface to libnotify Gtk2::Notify provides Perl bindings for libnotify. libnotifiy is a library that sends desktop notifications to a notification daemon. . These notifications can be used to inform the user about an event or display some form of information without getting in the user's way. -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Bug#526348: ITP: python-django-south -- Intelligent schema migrations for django apps
Package: wnpp Severity: wishlist Owner: David Watson X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-django-south Version : 0.5 Upstream Author : Andrew Godwin * URL : http://south.aeracode.org/ * License : Apache Programming Lang: Python Description : Intelligent schema migrations for django apps * Intelligent; it knows if you've missed out a migration or two * Database independent, so there's no hassle if you need to move databases. * Easy; it can write migrations for you, and it takes about a minute to convert your app over to use South. * Designed for a pluggable Django world; you can declare dependencies between apps so they all migrate together correctly, and you can still use syncdb for your non-migrated apps without it interfering. -- David Watson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526350: ITP: python-django-celery -- Distributed task queue framework for Django
Package: wnpp Severity: wishlist Owner: David Watson X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-django-celery Version : 0.1.6 Upstream Author : Ask Solem * URL : http://github.com/ask/celery * License : BSD Programming Lang: Python Description : Distributed task queue framework for Django Uses an AMQP message broker such as RabbitMQ to schedule and run tasks. Celery has an autodiscovery feature like the Django Admin, that automatically loads any tasks.py module in the application. -- David Watson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
URGENT: support for HP Proliant DL180G5 model
Hello I bought an HP Proliant DL 180 G5 server, with 2 SAS disk drives, in Raid 1+ 0 I downloaded debian-501-i386-CD-1.iso . is it supported for this HP server ? Any hints are well appreciated. Thank you
Re: Two watch files-related MBFs
James Vega wrote: > On Thu, Apr 30, 2009 at 03:16:44PM +0200, Giacomo A. Catenazzi wrote: >> I find no official documentation on format of debian/watch files. > > man uscan I mean in policy or reference or such official docs. Now it is a generic convenience (for maintaner) file. These is also no dependencies on uscan version in debian/control, and often no scripts in debian/ refers to uscan. For this reason, it is also hard to define bugs on debian/watch files. Feel free to standardize it by putting some more references in debian policy. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Two watch files-related MBFs
Giacomo A. Catenazzi wrote: > Raphael Geissert wrote: >> >> Once I file the bug reports I will be giving about two weeks before I >> remove the hack from DEHS and later from the DDPO. The lintian check has >> been around for many months now and it has given maintainers enough time >> to prepare an upload to fix some bugs on their packages so I don't see >> the need to wait any longer than that. > > two weeks are not debian period ;-) The only annoyance that could be caused is that the Debian version would be considered as newer than upsteam's. And like I said: this is a hack, if you run uscan on the source package's tree uscan will say that it couldn't find Debian's version. And like I said, there's a lintian check that has been in place for many months now. > >> Version one watch files (actually versionless watch files) have been >> considered obsolete for more than two releases now. Since a lot of >> special >> casing code is needed to handle those I would therefore like to file bug >> reports against packages shipping that kind of watch files so that the >> maintainers have a chance to make an upload before the code is removed >> from uscan. >> >> A lintian check[2] has also been in place for many months now, and >> according to it there are 60 packages in unstable/main with versionless >> watch files. > > Are these bugs? Versionless watch files are rigid, obsolete, and tend to break. > I find no official documentation on format of debian/watch files. > Thus, theoretically, you should change the tools and then you could fill > the bugs (debian/watch not working). James Vega already pointed you to uscan(1) :). > > BTW, on first proposed MBF you write about DEHS and DDPO, and on the > second > only about uscan. I would like that the tools will behave in a similar > manner (maybe with extra warnings on uscan). > DEHS uses uscan, and by removing the hack I mention on the first MBF proposal DEHS would finally report exactly the same results as uscan. DDPO also has the hack because DEHS only uses the hack to determine whether a package is up to date or not, but the DDPO also indicates if Debian's version is greater than upstream's, so it needs the hack as well. About warnings: -- uscan.pl warning: /tmp/libroxen-imho_watch1fpHQf is an obsolete version 1 watchfile; please upgrade to a higher version (see uscan(1) for details). -- Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Two watch files-related MBFs
On Thu, Apr 30, 2009 at 07:24:59PM +0200, Giacomo Catenazzi wrote: > James Vega wrote: > > On Thu, Apr 30, 2009 at 03:16:44PM +0200, Giacomo A. Catenazzi wrote: > >> I find no official documentation on format of debian/watch files. > > > > man uscan > > > I mean in policy or reference or such official docs. Why should it be duplicated there? debian/watch is a file that exists because of uscan, so uscan should be what documents the format. > Now it is a generic convenience (for maintaner) file. > These is also no dependencies on uscan version in debian/control, > and often no scripts in debian/ refers to uscan. Why would uscan be mentioned at all in debian/control? It's not used during the build process. No scripts in debian/ need to refer to uscan. > For this reason, it is also hard to define bugs on debian/watch files. Why? Either the watch file is written in the proper format so uscan can parse it and perform the requested actions or it isn't. Anything other than that would fall into the territory of uscan behavior. > Feel free to standardize it by putting some more references in > debian policy. Any tool that a developer may use in the process of maintaining packages which leaves a file in debian/ now has to be documented in policy? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: URGENT: support for HP Proliant DL180G5 model
Hi, On Thu Apr 30, 2009 at 09:14:41 -0700, Maamoun Mechri wrote: > Hello > > I bought an HP Proliant DL 180 G5 server, with 2 SAS disk drives, in Raid 1+ > 0 > > I downloaded debian-501-i386-CD-1.iso . is it supported for this HP server > ? > > Any hints are well appreciated. it should, but not sure if all hardware is supported. maybe you will need http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/lenny/current/ also you may find some hints on http://www.hp.com/go/debian Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526385: ITP: libperl-destruct-level-perl -- Perl module to change Perl's destruction level
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libperl-destruct-level-perl Version : 0.02 Upstream Author : Rafael Garcia-Suarez * URL : http://search.cpan.org/dist/Perl-Destruct-Level/ * License : Artistic/GPL Programming Lang: Perl Description : Perl module to change Perl's destruction level Perl::Destruct::Level is an interface allowing one to change Perl's internal destruction level. While this functionality is available through the PERL_DESTRUCT_LEVEL environment variable when perl is compiled with debug support, this module provides it for perls without -DDEBUGGING. The default value of the destruct level is 0; it means that perl won't bother destroying all its internal data structures, but let the OS do the cleanup for it at exit. Relevant values recognized by perl are 1 and 2. Consult your source code to know exactly what they mean. Note that some embedded environments might extend the meaning of the destruction level for their own purposes: mod_perl does that, for example. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526383: ITP: libenv-sanctify-perl -- Perl module providing lexically scoped environment (%ENV)
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libenv-sanctify-perl Version : 1.02-1 Upstream Author : Jonathan Yu * URL : http://search.cpan.org/dist/Env-Sanctify/ * License : Artistic/GPL Programming Lang: Perl Description : Perl module providing lexically scoped environment (%ENV) Env::Sanctify is a module that provides lexically scoped manipulation and sanctification of %ENV. With this module, one can add or alter environment variables, later restoring the environment back either manually or automatically once the object falls out of scope. This is useful for manipulating the environment that forked processes and sub-processes will inherit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526386: ITP: libtest-valgrind-perl -- Test Perl code through valgrind
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libtest-valgrind-perl Version : 1.01 Upstream Author : Vincent Pit * URL : http://search.cpan.org/dist/Test-Valgrind * License : Artistic/GPL Programming Lang: Perl Description : Test Perl code through valgrind -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Two watch files-related MBFs
James Vega wrote: > On Thu, Apr 30, 2009 at 07:24:59PM +0200, Giacomo Catenazzi wrote: >> James Vega wrote: >>> On Thu, Apr 30, 2009 at 03:16:44PM +0200, Giacomo A. Catenazzi wrote: I find no official documentation on format of debian/watch files. >>> man uscan >> >> I mean in policy or reference or such official docs. > > Why should it be duplicated there? debian/watch is a file that exists > because of uscan, so uscan should be what documents the format. not duplicate, but a reference to uscan, specifying the formats. BTW policy doesn't reference to uscan, but to other tools, so uscan is also not the definitive answer. >> Now it is a generic convenience (for maintaner) file. >> These is also no dependencies on uscan version in debian/control, >> and often no scripts in debian/ refers to uscan. > > Why would uscan be mentioned at all in debian/control? It's not used > during the build process. No scripts in debian/ need to refer to uscan. > >> For this reason, it is also hard to define bugs on debian/watch files. > > Why? Either the watch file is written in the proper format so uscan can > parse it and perform the requested actions or it isn't. Anything other > than that would fall into the territory of uscan behavior. if uscan is not called within the package (build or runtime), it is outside packaging, so what kind of bug can he have? it is not a policy violation, it is not a file installed on user machine, it is not used on building package. What kind of bug is it? (it was a question on the my first mail) >> Feel free to standardize it by putting some more references in >> debian policy. > > Any tool that a developer may use in the process of maintaining packages > which leaves a file in debian/ now has to be documented in policy? No, but this is the main point! If my uscan works with my debian/watch, why do you bug my debian/watch. See? Without a proper reference, debian/watch is a developer file like others, thus only developer can tell if it is correct or no. But debian/watch is not used only for uscan, and now it is a important tool for quality checks, so I think we should upgrade the status of debian/watch, prescribing a valid formats Note: Yet uscan is like lint, it only check sources. It is nice not to have errors, but do you bug mass every package that fail with lint? No. Do you bug package that has a wrong syntax in debian/control? Yes! See? ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Bug#522996: ITP: jruby1.2 -- 100% pure-Java implementation of Ruby
Steffem Joeris wrote: > On Wed, 8 Apr 2009 05:10:12 pm Romain Beauxis wrote: > > Le Tuesday 07 April 2009 22:59:00 Sebastien Delafond, vous avez écrit : > > > On Apr/07, Mike Hommey wrote: > > > > While I see why it can be needed for python, I fail to see how it is > > > > important for jruby... > > > > > > to have 2 versions of jruby available ? I guess so you can at least, for > > > instance, try the new one on your existing jruby code without removing > > > the old one, for instance ? > > > > If we were to apply this policy to all software packaged in debian, that > > would be a mess. > It would be a security mess as well, I don't particularly want to fix the > same > issue in 2-4 packages ... > > > > Are you advocating for only one instance of jruby at all times in the > > > archive ? If so, why ? > > > > I think this is the other way round: by default there should be only one > > version per package -- after all that is why we have package name and > > package version.. > > > > Hence, it should be explained why multiple version of the same package are > > relevant for Debian and its users. And I don't think that "testing several > > versions" is a good explanation.. > If a dozen (or more) packages really need the older version, then it could be > discussed I guess (some details here would be nice). But I agree that having > it around for "testing" reasons is not a valid reason. JRuby 1.0, 1.1, and 1.2 are not different mutually incompatible versions of the language. All are attempts to do an increasingly better (and faster) job of implementing both the Ruby 1.8 and Ruby 1.9 langugages, and therefore version 1.2 ostensibly replaces version 1.1 by being better than it. If there are packages that are broken under JRuby 1.2, they should be fixed. JRuby 1.2 should be packaged simply as "jruby", and all of the others should be removed from the archive immediately when that happens. If there are version-numbered library paths (i.e. /usr/lib/jruby1.1) to be concerned about, you should remove the version-number from those paths. If subsequent versions of JRuby introduce incompatible API changes, then you should work out a library transition to the new number each time a new version of JRuby is packaged that changes the library path. Furthermore, nothing in the archive currently depends on jruby1.0 or jruby1.1, so there's nothing to transition, and nothing you're breaking by fixing this now. --Ken signature.asc Description: This is a digitally signed message part
Bug#526396: ITP: libstatistics-test-sequence-perl -- Perl module that tests correlation of random numbers
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libstatistics-test-sequence-perl Version : 0.01 Upstream Author : Steffen Müller * URL : http://search.cpan.org/dist/Statistics-Test-Sequence/ * License : Artistic/GPL Programming Lang: Perl Description : Perl module that tests correlation of random numbers Statistics::Test::Sequence implements a sequence correlation test for random number generators. It shows pairwise correlation between subsequent random numbers. It performs this analysis using an algorithm published in: Blobel, V., and Lohrmann, E. Statistische und numerische Methoden der Datenanalyse. Stuttgart, Leipzig: Teubner, 1998 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Two watch files-related MBFs
On Thu, Apr 30, 2009 at 10:40:41PM +0200, Giacomo Catenazzi wrote: > James Vega wrote: > > On Thu, Apr 30, 2009 at 07:24:59PM +0200, Giacomo Catenazzi wrote: > >> James Vega wrote: > >>> On Thu, Apr 30, 2009 at 03:16:44PM +0200, Giacomo A. Catenazzi wrote: > I find no official documentation on format of debian/watch files. > >>> man uscan > >> > >> I mean in policy or reference or such official docs. > > > > Why should it be duplicated there? debian/watch is a file that exists > > because of uscan, so uscan should be what documents the format. > > not duplicate, but a reference to uscan, specifying the formats. > BTW policy doesn't reference to uscan, but to other tools, so > uscan is also not the definitive answer. Yes, policy does reference uscan in the section that discusses debian/watch. > >> Now it is a generic convenience (for maintaner) file. > >> These is also no dependencies on uscan version in debian/control, > >> and often no scripts in debian/ refers to uscan. > > > > Why would uscan be mentioned at all in debian/control? It's not used > > during the build process. No scripts in debian/ need to refer to uscan. > > > >> For this reason, it is also hard to define bugs on debian/watch files. > > > > Why? Either the watch file is written in the proper format so uscan can > > parse it and perform the requested actions or it isn't. Anything other > > than that would fall into the territory of uscan behavior. > > if uscan is not called within the package (build or runtime), it is > outside packaging, so what kind of bug can he have? > it is not a policy violation, it is not a file installed on user machine, > it is not used on building package. > What kind of bug is it? (it was a question on the my first mail) It's a bug in the source package. > >> Feel free to standardize it by putting some more references in > >> debian policy. > > > > Any tool that a developer may use in the process of maintaining packages > > which leaves a file in debian/ now has to be documented in policy? > > No, but this is the main point! > If my uscan works with my debian/watch, why do you bug my debian/watch. > See? We're talking about debian/watch files using obsolete formats, for which Raphael would like to remove support. This simplifies uscan's code, makes it easier to maintain, and makes it eaiser to split the watchfile parsing logic out into its own module. The last point would then allow tools like Lintian to perform checks on the watchfile that aren't guesses but actually use the same parsing code as does uscan. > Without a proper reference, debian/watch is a developer file like others, > thus only developer can tell if it is correct or no. It has a proper reference. The specification of the file format in uscan(1). > But debian/watch is not used only for uscan, and now it is a important > tool for quality checks, Tools which currently invoke uscan, thus uscan is still the only tool to consume debian/watch. > so I think we should upgrade the status of debian/watch, prescribing a > valid formats We already have valid formats documented. > Note: Yet uscan is like lint, it only check sources. It is nice not to > have errors, but do you bug mass every package that fail with lint? > No. Do you bug package that has a wrong syntax in debian/control? Yes! > See? uscan and lint aren't related tools. If a developer has bothered creating debian/watch, then its purpose is to be used with uscan to check for new upstream versions. If that doesn't work, then there is a bug in their source package. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Bug#526397: ITP: libstatistics-test-randomwalk-perl -- Perl module to perform a random walk test on a set of data
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libstatistics-test-randomwalk-perl Version : 0.01 Upstream Author : Steffen Müller * URL : http://search.cpan.org/dist/Statistics-Test-RandomWalk/ * License : Artistic/GPL Programming Lang: Perl Description : Perl module to perform a random walk test on a set of data -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Help for open source and diagramming research
Dear open source contributors, I am Eunyoung Chung, a Masters student working with Dr. Jensen at Oregon State University. We are currently doing a research project in collaboration with Dr. Truong and Ph.D student Koji Yatani at University of Toronto. Our goal is to understand how contributors communicate and collaborate in Open Source Software (OSS) projects, including diagramming practices. We are seeking volunteers for a quick survey on this topic. Any person who is actively working on a OSS project is eligible. The survey takes approximately 10-15 minutes, and the 5 volunteers will be picked to receive a $30 Amazon gift certificate. Your participation is anonymous (unless you consent to have us contact you) Here is the survey address. https://secure.engr.oregonstate.edu/limesurvey/58564/lang-en We really appreciate your help! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Work-needing packages report for May 1, 2009
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 412 (new: 11) Total number of packages offered up for adoption: 114 (new: 1) Total number of packages requested help for: 53 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: 9menu (#525488), orphaned 6 days ago Description: Creates X menus from the shell Installations reported by Popcon: 400 aap (#525446), orphaned 6 days ago Description: make-like "expert system" for building software Installations reported by Popcon: 82 autotrace (#525919), orphaned 3 days ago Description: bitmap to vector graphics converter Reverse Depends: autotrace libautotrace-dev mftrace Installations reported by Popcon: 870 bibclean (#525922), orphaned 3 days ago Description: pretty-printer for BibTeX databases Installations reported by Popcon: 208 bibtool (#525921), orphaned 3 days ago Description: tool for BibTeX database manipulation Installations reported by Popcon: 839 laptop-net (#525744), orphaned 4 days ago Description: Automatically adapt laptop Ethernet Installations reported by Popcon: 176 libpfm3-3.2 (#525745), orphaned 4 days ago Description: Performance Monitor Unit (PMU) -- run-time libraries Reverse Depends: libpfm3-3.2-dev pfmon qprof Installations reported by Popcon: 99 oprofile (#525737), orphaned 4 days ago Description: system-wide profiler for Linux systems Reverse Depends: oprofile-gui Installations reported by Popcon: 615 pfmon (#525748), orphaned 4 days ago Description: Tool for using CPU Performance Monitoring Units (PMUs) Installations reported by Popcon: 70 php-elisp (#525947), orphaned 2 days ago Description: Emacs support for php files Installations reported by Popcon: 998 xcftools (#525920), orphaned 3 days ago Description: command-line tools for extracting data for XCF files Installations reported by Popcon: 113 401 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: libmcal (#525950), offered 2 days ago Description: calendary library Reverse Depends: libmcal libmcal0-dev Installations reported by Popcon: 572 113 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#470795), requested 413 days ago Description: Co-maintainer wanted Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker apache2-prefork-dev apache2-suexec apache2-suexec-custom (159 more omitted) Installations reported by Popcon: 44138 ara (#450876), requested 536 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 118 asymptote (#517342), requested 62 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 408 athcool (#278442), requested 1647 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 211 boinc (#511243), requested 112 days ago Description: BOINC distributed computing Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg Installations reported by Popcon: 1596 cvs (#354176), requested 1162 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more omitted) Installations reported by Popcon: 22531 dctrl-tools (#448284), requested 551 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts hg-buildpackage ia32-archive ia32-libs-tools mlmmj sbuild simple-cdd Installations reported by Popcon: 11583 dpkg (#282283), requested 1621 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-cross apt-src backuppc biblatex-dw build-essential bzr-builddeb cacao-oj6-dbg (217 more omitted) Installations reported by Popcon: 85391 drscheme (#402589), requested 871 days ago Description: PLT scheme programming environ
Bug#526425: ITP: libgravatar-url-perl -- Perl interface to make URLs for Gravatars from an email address
Package: wnpp Owner: Ryan Niebur Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libgravatar-url-perl Version : 1.01 Upstream Author : Michael G Schwern * URL : http://search.cpan.org/dist/Gravatar-URL/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Perl interface to make URLs for Gravatars from an email address A Gravatar is a Globally Recognized Avatar for a given email address. This allows you to have a global picture associated with your email address. You can look up the Gravatar for any email address by constructing a URL to get the image from gravatar.com. Gravatar::URL does that. -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Re: Misc developer news (#15)
On Tue, 28 Apr 2009 19:47:11 +0200, Bastian Venthur wrote: > Raphael Hertzog schrieb: > > RFH: Removing spam from the listarchive > > --- > > > > As you all know, Lists and the Listarchive aren't 100% Spam-free. So we > > provide a 'Report as Spam' on every page in the archive. Now we set up a > > system to review those nominations, as it turned out that also > > inappropriate or controversial postings have been reported. > > > > If you want to help us to get rid of the Spam from the archive, go to [9] > > and follow the instructions. You need a @debian.org-Mailadress to > > participate. > > > > If you don't have one, you can help us by reviewing the Listarchive[10] > > itself and press the 'Report as Spam'-Button. > > > > We also maintain a Wiki-Page[11] for Details and coordination. > > This is a nice way to kill some free time. Is there something similar > planned for the BTS or are the "mark as spam" messages in the BTS > already dealed with? Also, seems like lists.alioth.debian.org doesn't have the same functionality. Is there any plan for this? Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
