Bug#508777: ITP: libicu4j-java -- Library for unicode support and internalisation
Package: wnpp Severity: wishlist Owner: Andreas Tille til...@rki.de * Package name: libicu4j-java Version : 3.8.1 Upstream Author : IBM and contributors * URL : http://www.icu-project.org/ * License : ICU4J license - ICU4J 1.8.1 and later 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, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation. Programming Lang: C, C++, Java Description : Library for unicode support and internalisation ICU is a mature, widely used set of C/C++ and Java libraries for Unicode support, software internationalization and globalization (i18n/g11n). It grew out of the JDK 1.1 internationalization APIs, which the ICU team contributed, and the project continues to be developed for the most advanced Unicode/i18n support. ICU is widely portable and gives applications the same results on all platforms and between C/C++ and Java software. Remark: This software is currently provided inside the source package of eclipse. There is no clear reason why it is tied into another packages upstream version. Moreover there is a seperate package maintained in Ubuntu and thus it is simple to steal this package. The packaging stuff is available in SVN via Vcs-Svn: svn://svn.debian.org/svn/pkg-java/trunk/icu4j Vcs-Browser: http://svn.debian.org/wsvn/pkg-java/trunk/icu4j/?rev=0sc=0 Kind regards Andreas. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507436: ITP: jalview -- multiple alignment editor
Hi Vincent, are there any news about the packaging. Any preliminary stuff to test? Any help needed? Did you decided which repository you want to use? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507436: ITP: jalview -- multiple alignment editor
On Tue, 13 Jan 2009, Vincent Fourmond wrote: About the repository, I think the best is pkg-java, as the skills required are more on the Java side than on the Biological side - but please correct me if I'm wrong. Well, there is no right or wrong - finally we have to store the packaging stuff in a publicly available repository. Via Vcs tags we will find the location and the upcoming 'mr' tool will probably help fetching stuff from different repositories. So I would just *ask* on pkg-java whether they like the idea to maintain the package there (yes, Java knowledge on Debian Med is not so wide spread). If there is no response this is probably not the proper place. Perhaps Steffen might like to say something more than 'why isn't anybody mentioning pkg-escience ?' My answer to this question is simple: This group is not vocal enough and how can I assume that there is some Java competence? The main problem is that it has loads of dependencies: 12:40 f...@vncent ~/tmp/jalview find -name '*.jar' ./lib/castor-1.1-cycle-xml.jar http://www.castor.org/ (not yet packaged) ? ./lib/commons-logging.jar libcommons-logging-java ? ./lib/commons-discovery.jar libcommons-discovery-java ? ./lib/wsdl4j.jar libwsdl4j-java ./lib/regex.jar libgnu-regexp-java | libjrexx-java libjrexx-java | liboro-java | libregexp-java ? ./lib/saaj.jar https://saaj.dev.java.net/ (not packaged yet) ? Seems to have to do something with SOAP, perhaps there are alternative implementations like the packaged libaxis-java ??? ./lib/jaxrpc.jar Reading http://de.wikipedia.org/wiki/JAX-RPC the package libxmlrpc3-common-java might provide what we need. At least the package contains /usr/share/java/jaxrpc.jar ./lib/mail.jar Hmm: $ apt-file search '/mail.jar' jspwiki: /usr/share/jspwiki/WEB-INF/lib/mail.jar - probably not roxen4: /usr/share/roxen4/java/classes/mail.jar Perhaps this might be a reasonable solution: libgnumail-java: /usr/share/java/gnumail.jar ./lib/axis.jar libaxis-java: /usr/share/java/axis.jar ./lib/vamsas-client.jar http://www.vamsas.ac.uk/ ? -- If this is a precondition for JalView Debian Med should perhaps concentrate on this part. Unfortunately the web page is a little bit sparse about vamsas itself - but seems deeply connected with JalView. I will have a look at the other free part Topali (AstexViewer seems to be non-free) ./lib/Jmol-11.0.2.jar We have an inofficial package of an outdated version of jmol: http://debian.wgdd.de/temp/jmol/ Daniel, any news from Jmol? ./lib/activation.jar libgnujaf-java: /usr/share/java/activation.jar ./lib/jhall.jar javahelp2: /usr/share/java/jhall.jar ./lib/xercesImpl.jar libxerces2-java: /usr/share/java/xercesImpl.jar ./lib/xml-apis.jar libxalan2-java: /usr/share/java/xml-apis.jar maven2: /usr/share/maven2/lib/xml-apis.jar ./lib/log4j-1.2.8.jar liblog4j1.2-java (and others) ./utils/castor-1.1-cycle-codegen-anttask.jar No idea - perhaps http://castor.codehaus.org/srcgen-maven-plugin.html ist helpful. While having no idea what maven2 might be at all I have read this keyword on the Debian-Java list recently quite frequently. ./utils/jhindexer.jar No idea. ./utils/castor-1.1-cycle-codegen.jar see castor above ./utils/wsdl4j.jar libwsdl4j-java ./utils/proguard.jar proguard: /usr/share/java/proguard.jar ./utils/roxes-ant-tasks-1.2-2004-01-30.jar ./utils/jalopy/lib/oro-2.0.6.jar ./utils/jalopy/lib/sax-2.0.1.jar ./utils/jalopy/lib/jalopy-ant-0.6.2.jar ./utils/jalopy/lib/log4j-1.2.6.jar ./utils/jalopy/lib/jaxp-1.2.jar ./utils/jalopy/lib/aelfred-1.2.jar ./utils/jalopy/lib/jalopy-1.0b11.jar ./utils/jalopy/lib/jdom-1.0b8.jar ./utils/jhall.jar ./utils/axis-ant.jar I'll start to sort it out this week-end. You can join in too,s Just joined. ;-) for instance, to see which of those are really necessary, file ITP, block this bug by the ITPs (CCing this bug), and package them (and their dependencies...). I guess the best would be to use this bug mailing-list for coordination. I think it is possible we can get rid of the dependencies from the utils/ directory... Lets see. I'm occupied with other tasks for this afternoon, but may be I might provide some more info later. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512069: ITP: r-cran-plotrix -- GNU R package providing various plotting functions
Package: wnpp Severity: wishlist Owner: Andreas Tille til...@rki.de * Package name: r-cran-plotrix Version : 2.5 Upstream Author : Jim Lemon, Ben Bolker, Sander Oom, Eduardo Klein, and others * URL : http://cran.r-project.org/web/packages/plotrix/ * License : GPL (=2) Programming Lang: R Description : GNU R package providing various plotting functions Lots of plots, various labeling, axis and color scaling functions for the GNU R package. I need this package for my work and would like to team maintain this package in the Debian Science Packaging team and use their Alioth repository. Other suggestions for a common R repository are welcome. Kind regards Andreas. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512404: ITP: r-cran-colorspace -- GNU R Color Space Manipulation
Package: wnpp Severity: wishlist Owner: Andreas Tille til...@rki.de * Package name: r-cran-colorspace Version : 1.0.0 Upstream Author : Ross Ihaka ihaka at stat.auckland.ac.nz * URL : http://cran.r-project.org/web/packages/colorspace * License : BSD Programming Lang: R Description : GNU R Color Space Manipulation Carries out mapping between assorted color spaces including RGB, HSV, HLS, CIEXYZ, CIELUV, HCL (polar CIELUV), CIELAB and polar CIELAB. Qualitative, sequential, and diverging color palettes based on HCL colors are provided. I plan to leave the source package as the upstream name 'colorspace' I intent to put this package under team maintenance of Debian Science Team debian-science-maintain...@lists.alioth.debian.org because it seems to be interesting for the statsitics section. Kind regards Andreas. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512405: ITP: r-cran-msm -- GNU R Multi-state Markov and hidden Markov models in continuous time
Package: wnpp Severity: wishlist Owner: Andreas Tille til...@rki.de * Package name: r-cran-msm Version : 0.8.1 Upstream Author : Christopher Jackson chris.jackson at mrc-bsu.cam.ac.uk * URL : http://cran.r-project.org/web/packages/msm/ * License : GPL2+ Programming Lang: R Description : GNU R Multi-state Markov and hidden Markov models in continuous time Functions for fitting general continuous-time Markov and hidden Markov multi-state models to longitudinal data. Both Markov transition rates and the hidden Markov output process can be modelled in terms of covariates. A variety of observation schemes are supported, including processes observed at arbitrary times, completely-observed processes, and censored states. I plan to leave the source package as the upstream name 'msm' I intent to put this package under team maintenance of Debian Science Team debian-science-maintainers@@lists.alioth.debian.org because it seems to be interesting for the statsitics section. Kind regards Andreas. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512431: ITP: r-cran-sp -- GNU R classes and methods for spatial data
Package: wnpp Severity: wishlist Owner: Andreas Tille til...@rki.de * Package name: r-cran-sp Version : 0.9.29 Upstream Author : Edzer J. Pebesma edzer.pebesma at uni-muenster.de * URL : http://r-spatial.sourceforge.net/ * License : GPL2+ Programming Lang: R Description : GNU R classes and methods for spatial data A package that provides classes and methods for spatial data. The classes document where the spatial location information resides, for 2D or 3D data. Utility functions are provided, e.g. for plotting data as maps, spatial selection, as well as methods for retrieving coordinates, for subsetting, print, summary, etc. This package should be putted under team maintenance of Debian Science but pkg-grass-devel might be interested as well -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512433: ITP: r-cran-vcd -- GNU R Visualizing Categorical Data
Package: wnpp Severity: wishlist Owner: Andreas Tille til...@rki.de * Package name: r-cran-vcd Version : 1.2.1 Upstream Author : David Meyer David.Meyer at R-project.org * URL : http://cran.r-project.org/web/packages/vcd * License : GPL2+ Programming Lang: R Description : GNU R Visualizing Categorical Data Visualization techniques, data sets, summary and inference procedures aimed particularly at categorical data. Special emphasis is given to highly extensible grid graphics. The package was inspired by the book Visualizing Categorical Data by Michael Friendly. This package should be maintained under Debian Science team maintenance. According to the RFC for an R packaging policy at https://stat.ethz.ch/pipermail/r-devel/2003-December/028424.html I'd like to keep the source package name 'vcd' as the upstream package name. On the other hand I'm quite unsure if there are 2 or 3 letter names. In one of my former ITPs (sp) there is a conflict with sp - James Clark's SGML parsing tools. Any comments are welcome. Kind regards Andreas. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512430: ITP: r-cran-spc -- GNU R Statistical Process Control
Package: wnpp Severity: wishlist Owner: Andreas Tille til...@rki.de * Package name: r-cran-spc Version : 0.21 Upstream Author : en Knoth Sven.Knoth at gmx.de * URL : http://cran.r-project.org/web/packages/spc/ * License : GPL Programming Lang: R Description : GNU R Statistical Process Control Evaluation of control charts by means of the zero-state, steady-state ARL (Average Run Length). Setting up control charts for given in-control ARL and plotting of the related figures. The control charts under consideration are one- and two-sided EWMA and CUSUM charts for monitoring the mean of normally distributed independent data. Now, the ARL calculation of EWMA-S^2 control charts is added. Other charts and parameters are in preparation. Further SPC areas will be covered as well (sampling plans, capability indices ...). As my other ITPs I plan to put this under Debian Science team maitenance. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512433: ITP: r-cran-vcd -- GNU R Visualizing Categorical Data
On Tue, 20 Jan 2009, Dirk Eddelbuettel wrote: The Policy Draft you reference is somewhat outdated and in need of a refresher. I've thought this because it is quite old from the tome stamp but I failwd to found something more recent. As for the names: On a few of my more recent ITPs for R / CRAN packages, folks suggested to not use the 'short' names. Hence I would suggest r-cran-msm r-cran-sp r-cran-spc r-cran-vcd for binary _and source_ packages and you may as well stick with r-cran-colorspace Fine, I will regard this for these packages. WHat would you suggest for the recently uploaded package plotrix which is currently in new? should I immediately ask ftpmaster to drop this upload and rename the source package as well? as colorspace is so generic. I completely agree. I just added the explicite hint to my ITPs (if I did not forgot it) to ask for comments on the naming scheme because I was not really convinced that it is the best idea these days (at the time of writing it was probably reasonable). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512490: zope2.10: Problems with zope-formulator with this version of zope (fwd)
Hi Martijn, I would like to report a problem with the latest version of zope-formulator. I can confirm that I also have a similar problem with export / import of zope-formulator objects so there really seems to be a problem. I have the impression that zope formulator is not very actively maintained any more (other people just droped the package form the Debian distribution until I just grabbed it up again). It would be nice if you would keep us informed about the development status. The last message I see on the developer list from you is https://lists.infrae.com/pipermail/formulator-dev/2006-February/000142.html which is quite some time ago. Is there any solution for the problem which is reported below in SVN? Do you see a chance to fix this problem? Kind regards and thanks for your work on Zope Formulator Andreas. -- http://fam-tille.de -- Forwarded message -- Date: Wed, 21 Jan 2009 08:10:23 + From: Filippo Paglia scontu...@infinito.it To: Debian Bug Tracking System sub...@bugs.debian.org Subject: Bug#512490: zope2.10: Problems with zope-formulator with this version of zope Resent-Date: Wed, 21 Jan 2009 08:18:02 + Resent-Date: Wed, 21 Jan 2009 08:18:04 + Resent-From: Filippo Paglia scontu...@infinito.it Resent-To: debian-bugs-dist@lists.debian.org Resent-cc: Debian/Ubuntu Zope Team pkg-zope-develop...@lists.alioth.debian.org Package: zope2.10 Version: 2.10.6-1 Severity: normal I have installed the product Formulator (1.11.3) After the creation of a Formulator Form in a folder and only after the creation of a new field in this form (ex. StringField), I can't copy/move this form in any parts of zope; also I can't use the function of import of .zexp files that contain this type of object. When I try to copy the formulator form, Zope answers with this message: Error Type: AttributeError Error Value: field_added Traceback (innermost last): - Module ZPublisher.Publish,line 119,in publish - Module ZPublisher.mapply,line 88,in mapply - Module ZPublisher.Publish,line 42,in call_object - Module OFS.CopySupport,line 224,in manage_pasteObjects - Module OFS.ObjectManager,line 347,in _setObject - Module zope.event.line 23,in notify - Module zope.component.event,line 26,in dispatch - Module zope.component._api,line 130,in subscribers - Module zope.component.registry,line 290,in subscribers - Module zope.interface.adapter,line 535,in subscribers - Module zope,component.event,line 33,in objectEventNotify - Module zope.component._api,line 130,in subscribers - Module zope.component.registry,line 290,in subscribers - Module zope.interface.adapter,line 535,in subscribers - Module OFS.subscribers,line 119,in dispatchObjectMovedEvent - Module zope.app.container.contained,line 182,in dispatchToSublocations - Module zope.component._api.line 130,in subscribers - Module zope.component.registry,line 290,in subscribers - Module zope.interface.adapter,line 535,in subscribers - Module Products.Formulator.Field,line 579,in field_added Note I've modified the file zope.conf with this values: - datetime-format international - default-zpublisher-encoding utf-8 I hope to have insert the bug in the right place (I thing that this is a problem of zope and not of formulator) Thanks -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-xen-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zope2.10 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6 2.7-18 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii python-tz 2008c-2Python version of the Olson timezo ii python2.4 2.4.6-1An interactive high-level object-o ii zope-common 0.5.45 common settings and scripts for Zo zope2.10 recommends no packages. Versions of packages zope2.10 suggests: pn python-unit none (no description available) pn zope-book none (no description available) pn zope-devguide none (no description available) -- no debconf information ___ pkg-zope-developers mailing list pkg-zope-develop...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-zope-developers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510251: postgresql-8.3-plr: does not build against R 2.8
On Tue, 30 Dec 2008, Faheem Mitha wrote: I have never used plr, but tried building it against 2.8 (CRAN version 2.8.1-1~etchcran.0) right now in an etch vserver, and it failed. Should I report it to the plr mailing list? No. I can reproduce this problem which is caused by the fact that the r-base-core package is lacking /usr/share/R/includes/Rdevices.h . I will reassign the bug report to this package. Thanks for getting this back into Debian - at first I thought I would have to build it myself... You can work around this problem for your local installation by just copying src/include/Rdevices.h into the plr source directory. The you can build the package for the moment. make[1]: Entering directory /usr/local/src/plr/plr-8.3.0.6' sed 's,MODULE_PATHNAME,$libdir/plr,g' plr.sql.in plr.sql cc -g -Wall -O2 -fpic -I. -I/usr/lib/R/include -I/usr/share/R/include -I. -I/usr/include/postgresql/8.3/server -I/usr/include/postgresql/internal -DPKGLIBDIR=\/usr/lib/postgresql/8.3/lib\ -DDLSUFFIX=\.so\ -DR_HOME_DEFAULT=\/usr/lib/R\ -c -o plr.o plr.c In file included from plr.c:33: plr.h:61:22: error: Rdevices.h: No such file or directory -- here you can see the problem. BTW, if you detect a bug which prevents to build a package from source it is definitely higher than wishlist. In most cases it is an RC critical bug. If you are unsure you can set it at least to normal. If I reassign the package to r-base-core it is not RC for this package but at least important because of the problem it causes for plr. Kind regards and thanks for your bug report Andreas. PS: Sorry for the late reply - normally I'm a bit faster ... -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510251: r-base-core is lacking /usr/share/R/includes/Rdevices.h
On Fri, 23 Jan 2009, Andreas Tille wrote: You can work around this problem for your local installation by just copying src/include/Rdevices.h into the plr source directory. The you can build the package for the moment. I have to revert this. I learned that Rgraphics.h is lacking as well and once you include these both in the plr source tree and try to build against R 2.8 you get something like: cc -g -O2 -g -Wall -O2 -fpic -I. -I/usr/share/R/include -I/usr/share/R/include -I. -I/usr/include/post gresql/8.3/server -I/usr/include/postgresql/internal -DPKGLIBDIR=\/usr/lib/postgresql/8.3/lib\ -DDLSUFF IX=\.so\ -DR_HOME_DEFAULT=\/usr/lib/R\ -c -o plr.o plr.c In file included from Rdevices.h:36, from plr.h:61, from plr.c:33: ./Rgraphics.h:124: warning: parameter names (without types) in function declaration ./Rgraphics.h:126: warning: parameter names (without types) in function declaration ./Rgraphics.h:128: warning: parameter names (without types) in function declaration ./Rgraphics.h:140: warning: parameter names (without types) in function declaration ./Rgraphics.h:143: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:163: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:166: warning: parameter names (without types) in function declaration ./Rgraphics.h:169: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:171: warning: parameter names (without types) in function declaration ./Rgraphics.h:173: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:175: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:178: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:181: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:183: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:185: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:187: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:189: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:191: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:195: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:198: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:199: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:213: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:216: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:222: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:224: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:227: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:228: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:243: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:244: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:245: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:247: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:248: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:255: warning: parameter names (without types) in function declaration ./Rgraphics.h:258: warning: parameter names (without types) in function declaration ./Rgraphics.h:261: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Rf_GNewPlot' ./Rgraphics.h:263: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:265: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:267: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:270: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:271: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:272: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:273: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:274: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:275: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:276: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:277: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:278: error: expected declaration specifiers or '...' before 'pGEDevDesc' ./Rgraphics.h:279: error: expected declaration specifiers or '...' before 'pGEDevDesc' make[1
Bug#510251: r-base-core is lacking /usr/share/R/includes/Rdevices.h
On Fri, 23 Jan 2009, Dirk Eddelbuettel wrote: First off, thanks for maintaining pl-r. I wasn't aware that it has landed in your lap. I was aware that the Pg maintainers didn't really want it (for lack of R expertise) but I had no spare capacity to take it on myself. Well, I used this package on a machine running testing and I noticed by chance that it was dropped. I tried to convince RM to reinclude it into Lenny (even bothered them in person at DebConf) but I was not lucky with this attempt. So we will not be able to provide a straight upgrade path from Etch to Lenny - especially if our package in unstable might relay on new R 2.8 features and might get problems with backporting to 2.7. I have no idea whether this might be one consequence of the issue we are discussing here - but at least this might be possible. | You can work around this problem for your local installation by just | copying src/include/Rdevices.h into the plr source directory. The | you can build the package for the moment. | | I have to revert this. Yes, that was plain wrong. R (upstream) changed their interface and tightened this. It also affected things I maintain such as the RPy package. So the error is plainly with the client package. It is not an R issue inasmuch as that these interface were never public (yet pl/R is a well-known example even used in the 'R Extensions' manual about embedding). OK, thanks for the clarification. | I learned that Rgraphics.h is lacking as well | and once you include these both in the plr source tree and try to | build against R 2.8 you get something like: Did you talk Joe Conway about this? Joe as upstream author has always been very responsive clueful when I contacted him about pl/R (which I had played with over the years). I've ssen that Joe is in CC and no, I did not yet talked to him because I just made wrong assumptions (about missing include files). Since you now clarified this issue I guess Joe will find a reasonable response. Now the final question for Faheem: Pl/R has existed in Debian for years. Why did you think you needed to rebuild it for etch? Were you lacking a particular combination of versions of R and/or Pg on etch ? We might perhaps a package which works with Lenny Build-Depends. I'm sure we can sort all this out. If Joe helps us I'm really optimistic. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510251: r-base-core is lacking /usr/share/R/includes/Rdevices.h
On Fri, 23 Jan 2009, Joe Conway wrote: I won't have time to digest this until the weekend, but I'll try to get back to you by Monday. That's perfectly all right. Have a nice weekend Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512891: plr - FTBFS: error: Rdevices.h: No such file or directory
On Sat, 24 Jan 2009, Bastian Blank wrote: Package: plr Version: 1:8.3.0.6-2 Severity: serious There was an error while trying to autobuild your package: Automatic build of plr_1:8.3.0.6-2 on lxdebian.bfinv.de by sbuild/s390 98 ... This is a known problem (#510251) which was discussed yesterday and reported upstream. Thanks for autobuilding the archive anyway Andreas. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512930: ITP: jmol -- java molecular graphics system
On Sun, 25 Jan 2009, Vincent Fourmond wrote: Package: wnpp Severity: wishlist Owner: Vincent Fourmond fourm...@debian.org * Package name: jmol Version : 11.6 Upstream Author : Jmol team * URL : http://jmol.sourceforge.net/ * License : LGPL Programming Lang: Java, Javascript Description : java molecular graphics system Jmol is a molecular graphics system like Pymol written entirely in Java. It can be easily embedded into other applications, such as jalview. This is packaged so it can be used from within jalview. Thanks for your ITP. If you say: This *is* packaged could you please send any URL? There is a former attempt to package Jmol in our SVN: http://svn.debian.org/wsvn/pkg-escience/jmol/trunk/debian/?rev=0sc=0 but this concerns a previous version. Do you have your work anywere publicly available? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515943: debian-science: Broken Vcs-* URLs in debian/control
On Wed, 18 Feb 2009, Rafael Laboissiere wrote: Subject says all. Both URLs below are broken: Vcs-Browser: http://svn.debian.org/wsvn/cdd/projects/science/trunk/debian-science/?rev=0sc=0 Vcs-Svn: svn://svn.debian.org/cdd/projects/science/trunk/debian-science/ It is just fixed in the upload to experimental. The debian-science has a number of extra metapackages which delays processing and also depends from blends-dev which is also only in experimental to enable fixing things in cdd-dev in unstable while Lenny was not yet released. So things will be fixed in the near future automatically (once ftpmaster has edited override). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515947: science-mathematics-dev: Depends on non -dev library packages
On Wed, 18 Feb 2009, Rafael Laboissiere wrote: Making this package depend on other libraries is both non-sensical and useless. I suggest to change the following dependencies: libglpk0 - libglpk-dev libsuperlu3 - libsuperlu3-dev libslepc2.3.2 - libslepc2.3.2-dev libmesh0.6.1 - libmesh0.6.2-dev Note that libmesh0.6.1 does not even exist in Debian. Good catch. I changed this in SVN. I might add that my long term plan is to enable to detect blends-dev package to detect the version number automatically. But this is a _long_ _term_ plan. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370822: xteddy: Please switch to newer version of imlib
On Wed, 18 Feb 2009, Moritz Muehlenhoff wrote: imlib11 is scheduled for removal and since the eventual replacement through cteddy isn't related, please request removal from the archive. Do you mean *now* is there any reason to keep it in unstable for a while? The rationale is that xteddy is not only a cute toy but can be used in some presentation to pop up some transparent images which is sometimes really helpful. If it only would be a toy I would immediately do so, but keeping it in unstable as long as there is no replacement seems to be fair. As an exchange I'll ask for removal of libgtkimreg0 and paul which have the same imlib problem. Is this a fair deal? ;-) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515943: debian-science: Broken Vcs-* URLs in debian/control
On Wed, 18 Feb 2009, Rafael Laboissiere wrote: Subject says all. Both URLs below are broken: Vcs-Browser: http://svn.debian.org/wsvn/cdd/projects/science/trunk/debian-science/?rev=0sc=0 Vcs-Svn: svn://svn.debian.org/cdd/projects/science/trunk/debian-science/ It is just fixed in the upload to experimental. Okay, I have not noticed that 0.4 was in the NEW queue. Could you please tell me the current SVN URL? Well cdd was renamed to blends. Perhaps you might like to check out http://svn.debian.org/wsvn/blends/projects/ Kind regards and thanks for your interest Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516011: RM: libgtkimreg -- ROM; It is using imlib1 which will be removed from the archive soon.
Package: ftp.debian.org Severity: normal libgtkimreg0 is using imlib1 which should be removed from the archive. The library is used by paul which also is subject of removal (#456131). Kind regards and thanks for maintaining ftp.debian.org Andreas. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370822: xteddy: Please switch to newer version of imlib
On Wed, 18 Feb 2009, Barry deFreese wrote: Haven't we already patched xteddy to use Imlib2? The bug log says: -- From: Barry deFreese bdefre...@debian.org To: 370...@bugs.debian.org Subject: Start of patch for imlib2 Date: Wed, 10 Dec 2008 13:08:26 -0500 Hi, Here is a patch I started. It does build but segfaults and I'm probably a bit over my head. Hope this helps at least a little. -- If it segfaults the problem is not really solved and I understood your remark a bit over my head as a I have to give up on this. Sorry if I missinterpreted this. I was also working on a patch for libgtkimreg but it may or may not be broken (As well as not being completed)... I would really welcome if you would succeed with this tasks but even as the upstream author I would say that there are probably other more frequently used packages which deserve an imlib1 to imlib2 upgrade more than libgtkimreg. If there is any hope that you will be successful I might redraw my request for removal (or reintroduce it later again). Many thanks for your effort to upgrade this old code! Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516037: gnumed-client: hard-codes the location to python modules
On Thu, 19 Feb 2009, Josselin Mouette wrote:
the gnumed-client package uses a hard-coded path to the python modules:
GNUMEDDIR=/var/lib/python-support/python${PYVER}/Gnumed/wxpython
However, because of numerous requests from developers, the installation
path for these modules is going to change, so this will make
gnumed-client fail.
If you really want to keep hard-coding this path, it is possible to
handle this with a synchronized upload and a Breaks:, but I’d like to
avoid it if possible.
I would like to follow your advise to not hardcode tha path.
Instead, I’d like to suggest alternate solutions
that are independent from the packaging layers:
* Detect the modules location dynamically from the script. You can
see an example in the pychecker package.
* Make /usr/bin/gnumed a python script, rewriting the environment
manipulations in python; this makes the import trivial.
What means trivial. Is there an alternative example like pychecker
for the first option?
* Move part or all of the files to a private modules directory.
If you ask me this sounds like the most reasonable suggestion. But
how does it work together with python-support? Any docs how the behaviour
of python-support will change? (I haven't followed the debian-python
discussion very closely.)
Kind regards
Andreas.
--
http://fam-tille.de
Bug#516037: gnumed-client: hard-codes the location to python modules
On Thu, 19 Feb 2009, Karsten Hilbert wrote: * Move part or all of the files to a private modules directory. Hopefully we can find another way. IMHO this is the less invasive option and might keep the modules at the place where you put them upstream - at least if I understood the suggestion right. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370822: xteddy: Please switch to newer version of imlib
On Wed, 18 Feb 2009, Barry deFreese wrote: Sorry, Peter DeWachter fixed up my patch and it should be working. Probably needs some more testing? His patch is posted on this bug as well. Ahh, great - I'll test it soon. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516037: gnumed-client: hard-codes the location to python modules
On Thu, 19 Feb 2009, Karsten Hilbert wrote: The trivial seems to come about by the misbelief that our module imports somehow use GNUMEDDIR which they do not. That's only used to access gnumed.py, nothing else. gnumed(.sh) is there exactly to *be* a shell wrapper around gnumed.py to allow the user to run additional shell scripts before launching GNUmed. It doesn't make any sense to convert it to Python. So the fix for the bug is really simple: Install the Python modules at *any* place which the Pathon policy suggests and adapt the shell script to this place, right? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516037: [Debian-med-packaging] Bug#516037: gnumed-client: hard-codes the location to python module
On Thu, 19 Feb 2009, Josselin Mouette wrote: Looking more closely, there is an even simpler way than that of pychecker. Something like this should directly work: python -m Gnumed.wxpython.gnumed I'll think about this. I don’t have one handy, but the idea is to consider it a regular script. Looking more closely at gnumed.py, it occurs to me that it is not even meant to be in a modules directory: if __name__ != __main__: print GNUmed startup: This is not intended to be imported as a module Actually yes, this is true. It was just amongst the other python files and I wanted to write a wrapper script for different configurations inside Debian anyway. So I left it where it was and thought it might not harm to have it compiled into byte code. This way, instead of a wrapper script, you could directly put this script in /usr/bin, adding to it the necessary logic to read the configuration. As I said - it can be started (ar at least there were times when we started it with differend wrappers which used different configurations). The reasons for doing so might have become void these days - I'll keep on thinking about this. This is very simple, just ship the modules to /usr/share/gnumed-client, and modify your script to do something like: import sys sys.path.append(/usr/share/gnumed-client) import Gnumed.whatyouwant … Python-support will handle this automatically; you just have to pass the installation directory to the dh_pysupport call if it is non-standard. Ahh, that sounds good! Thanks for your quick answer, Same to you. ;-) Kind regards Andreas. -- http://fam-tille.de
Bug#514690: Regarding RFS: Artha
On Thu, 19 Feb 2009, Sundaram wrote: I was wondering if you have uploaded the package to the Debian repository. I apologize if I sound demanding or pestering here :) No pestering me is the right way to go. My plan is to do this either at the weekend or at least next monday. Just try perstering again to remind me in case this task might silently go down on my todo list without notice. I am just curious, how will I know if the upload of the package is done or if the check-in of the control files into the Debian Science SVN is done? My plan is to check in first to enable putting the right Vcs fields into the control file. I assume you are OK with the cdbs usage? Thanks for the remainder - it is perfectly welcome on my side Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514690: Regarding RFS: Artha
On Thu, 19 Feb 2009, Sundaram wrote: Wow! Never knew you would recommend pestering :0 SUre - but I have only the right to advise this for one single person (=me). I would not recommend to try this to others. ;-) I am perfectly fine by the usage of cdbs, as you told earlier that its convenient for you to keep track. Well I will remind (pester) you again tomorrow night, as a precursor to the weekend's :) Before you pester again: http://svn.debian.org/wsvn/debian-science/packages/artha/trunk/debian/?rev=0sc=0 ;-) I also try to do the upload tomorrow ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514690: Regarding RFS: Artha
On Fri, 20 Feb 2009, Sundaram wrote: I would not recommend to try this to others. ;-) Point taken. Gee! That (checking in) was fast for a single dosage of pestering ;) That's why I recommended pestering - because it is normally helpful (in my case). ;-) Thanks for checking in the control files. I have received a mail telling that the ITP bug is now tagged 'pending'. Also a mail on artha_0.8.0-1_i386 which says (new) artha_0.8.0-1.diff.gz optional utils (new) artha_0.8.0-1.dsc optional utils (new) artha_0.8.0-1_i386.deb optional utils and in the end Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. So what does these mean? This means I did not only commited to SVN but also uploaded the package: http://ftp-master.debian.org/new/artha_0.8.0-1.html It's just waiting for ftpmaster aproval (as several other packages which enter the Debian pool the first time). What file is it talking about? Also, if I had received one for i386, why didn't I receive one for amd64? The other architectures will be autobuilded later once the package is accepted by ftpmaster. That's perfectly normal. You get the mail only once for the architecture the package was builded. If I would have done it on mips or powerpc or whatever you whould have got this in the notification. I am confused :-| There is no need to be confused. Everything is perfectly normal (as far as I can tell). I wanted to understand the underlying process. If something remains unclear just RTFM. ;-)) Kind regards and thanks for providing this nice WordNet interface Andreas. -- http://fam-tille.de
Bug#516037: gnumed-client: hard-codes the location to python module
On Fri, 20 Feb 2009, Karsten Hilbert wrote:
The attached script would be my suggestion. If that looks OK
I will commit it to the upstream CVS.
Looks perfectly reasonable to me. Do you want me to fix this
problem now by uploading just another 0.3.10 based Debian package
or do you think it makes sense to wait for the upcoming 0.4.
IMHO there is no need to hurry because there is no problem with
the *currently* existing packages in unstable.
Kind regards
Andreas.
--
http://fam-tille.de#!/bin/bash
#==
# This shell script is intended to be placed in
# /usr/bin/ and should be run to start a GNUmed
# client.
#
# $Source: /sources/gnumed/gnumed/gnumed/dists/Linux/gnumed,v $
# $Id: gnumed,v 1.21 2009/02/20 10:45:44 ncq Exp $
# license: GPL
# Karsten Hilbert, Sebastian Hilbert, Andreas Tille
#--
# for debugging this script
# set -x
OPTIONS=$@
# The system-wide configuration file for backend profiles.
SYSCONF=/etc/gnumed/gnumed-client.conf
if [ ! -e ${SYSCONF} ] ; then
echo Global config file ${SYSCONF} missing.
exit 1
fi
# source systemwide startup extension shell script if it exists
if [ -r /etc/gnumed/gnumed-startup-local.sh ] ; then
. /etc/gnumed/gnumed-startup-local.sh
fi
# source local startup extension shell script if it exists
if [ -r ${HOME}/.gnumed/scripts/gnumed-startup-local.sh ] ; then
. ${HOME}/.gnumed/scripts/gnumed-startup-local.sh
fi
# now run the client
python -m Gnumed.wxpython.gnumed ${OPTIONS}
# sync the discs just in case
sync
Bug#516545: ITP: eprover -- The Equational Theorem Prover E
Hi, this seems like a nce target for Debian Science Mathematics section. Petr, do you consider putting the package under Debian Science team maintenance? Kind regards Andreas. On Sun, 22 Feb 2009, Petr Pudlak wrote: Package: wnpp Severity: wishlist Owner: Petr Pudlak d...@pudlak.name * Package name: eprover Version : 1.0.004 Upstream Author : Stephan Schulz sch...@eprover.org * URL : http://www.eprover.org/ * License : GPL-2 Programming Lang: C Description : The Equational Theorem Prover E E is an automated equational theorem prover. That means it is a program that you can stuff a mathematical specification (in first-order logic with equality) and a hypothesis into, and which will then run forever, using up all of your machines resources. Very occasionally it will find a proof for the hypothesis and tell you so ;-). Release 1.0 is the culmination of a long development phase. Important changes vs. version 0.999 include the fixing of some bugs in definitional clausification for large problems and general cleanup. (Copied from the original documentation.) -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516545: ITP: eprover -- The Equational Theorem Prover E
On Sun, 22 Feb 2009, Petr Pudlak (Debian) wrote: yes, I thought that it would be a good idea, but I couldn't find exact guidelines how to do it. (Maybe it's just because I'm a bit tired after spending the whole weekend reading Debian documentation.) I can package eprover according to http://debian-science.alioth.debian.org/debian-science-policy.html This describes basically the recommendations inside the team. BTW, if you have some comments about this policy you are invited to pronounce these openly on the debian-science mailing list. It is always good to get some response whether these guidlines are useful or not. this is no problem, but I'm not sure what to do next. Just look for a sponsor at http://wiki.debian.org/DebianScience/Sponsoring? Or request membership in Debian Science at Alioth? Yes. This is needed to commit your packaging stuff into the Debian Science Vcs (either SVN or Git at your choice). I would also recommend to subscribe the debian-science mailing list. Asking there for sponsoring increases your chances to find a sponsor. (This is a personal remark and might be wrong: *I* personally do not watch the Wiki page - so I can not comment on the success you might have to use the Wiki.) Thanks for your help. You are welcome Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516627: ITP: fudgit -- A double-precision multi-purpose fitting program
Hi Jan, this might be an interesting add on for Debian Science Viewing task. Would you consider group maintenance in the Debian Science team? Kind regards Andreas. On Sun, 22 Feb 2009, Jan Hendrik den Besten wrote: Package: wnpp Severity: wishlist Owner: Jan Hendrik den Besten bes...@janhendrik.eu * Package name: fudgit Version : 2.43-gudjon Upstream Author : Jan Hendrik den Besten bes...@janhendrik.eu * URL : http://www.bbphotonics.eu/fudgit * License : GPL Programming Lang: C Description : A double-precision multi-purpose fitting program FUDGIT is a double-precision multi-purpose fitting program. It can manipulate complete columns of numbers in the form of vector arithmetic. FUDGIT is also an expression language interpreter understanding most of C grammar except pointers. Morever, FUDGIT is a front end for any plotting program supporting commands from stdin. It is a nice mathematical complement to GNUPLOT, for example. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516627: ITP: fudgit -- A double-precision multi-purpose fitting program
On Sun, 22 Feb 2009, Jan Hendrik den Besten wrote: Fudgit would be my first package to maintain. I feel I must gain some experience in that first - before I take up other tasks. Well, nobody is forcing you to join a team - you are perfectly free to do so. But I feel some inconsitency in your reasoning: You do not want the help of a team because you are not experienced? Especially in this case I would recommend reading http://debian-science.alioth.debian.org/debian-science-policy.html because it gives some reasonable framework and if it comes to seeking a sponsor you are welcome to ask on debian-scie...@lists.debian.org. Joining the Debian Science team means getting help in packaging scientific software not adding another task to your shoulders. ;-) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516704: devscripts: uscan should parse not only directory with highes version number
Package: devscripts Version: 2.10.35lenny2 Severity: wishlist Hi, DEHS is reporting new versions of GNUmed with the current watch file which says: http://www.gnumed.de/downloads/client/([\d\.]+)/GNUmed-client\.(.*)\.tgz These new versions are only release candidates (0.4-rc\d) which should not be packaged (as I agreed with upstream). So I might live with these false alarms for the next couple of weeks but I would like to fix the watch file properly. So I tried: http://www.gnumed.de/downloads/client/([\d\.]+)/GNUmed-client\.([\d\.]+)\.tgz but this does not even detects the recent version (0.3.10). My guess is that uscan is at first seeking for the directory with the highest version ( http://www.gnumed.de/downloads/client/0.4 ) and then parses for the tarball which matches GNUmed-client\.([\d\.]+)\.tgz - but there is no such file (these are only in ( http://www.gnumed.de/downloads/client/0.3 ). As you can read in the thread starting at http://lists.debian.org/debian-qa/2009/02/msg00105.html I discussed this problem on debian-qa and Paul Wise actually found a workyround for this problem but we agreed that it would be a nice feature of uscan to parse lower verisoned directories of the scan of the latest might have failed. Kind regards and thanks for maintaining uscan Andreas. -- Package-specific info: --- /etc/devscripts.conf --- DEBUILD_LINDA=no DEBUILD_LINTIAN_OPTS=--info --display-info DEBUILD_LINDA_OPTS=-info --- ~/.devscripts --- Not present -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages devscripts depends on: ii dpkg-dev 1.14.25Debian package development tools ii libc6 2.7-18 GNU C Library: Shared libraries ii perl 5.10.0-19 Larry Wall's Practical Extraction Versions of packages devscripts recommends: ii at 3.1.10.2 Delayed job execution and batch pr ii bsd-mailx [mailx] 8.1.2-0.20071201cvs-3 A simple mail user agent ii curl 7.18.2-8 Get a file from an HTTP, HTTPS or ii cvs1:1.12.13-12 Concurrent Versions System ii dctrl-tools2.13.1Command-line tools to process Debi ii debian-keyring 2009.01.18GnuPG (and obsolete PGP) keys of D ii debian-maintainers 1.52 GPG keys of Debian maintainers ii dput 0.9.2.32 Debian package upload tool ii elinks [www-browse 0.11.4-3 advanced text-mode WWW browser ii epiphany-gecko [ww 2.22.3-9 Intuitive GNOME web browser - Geck ii equivs 2.0.7-0.1 Circumvent Debian package dependen ii fakeroot 1.11 Gives a fake root environment ii galeon [www-browse 2.0.6-2.1 GNOME web browser for advanced use ii git-core 1:1.5.6.5-2 fast, scalable, distributed revisi ii gnupg 1.4.9-3 GNU privacy guard - a free PGP rep ii iceape-browser [ww 1.1.14-1 Iceape Navigator (Internet browser ii iceweasel [www-bro 3.0.6-1 lightweight web browser based on M ii konqueror [www-bro 4:3.5.9.dfsg.1-6 KDE's advanced file manager, web b ii libauthen-sasl-per 2.12-1Authen::SASL - SASL Authentication ii libcrypt-ssleay-pe 0.57-1+b1 Support for https protocol in LWP ii libparse-debcontro 2.005-2 Easy OO parsing of Debian control- ii libsoap-lite-perl 0.710.08-1Client and server side SOAP implem ii libterm-size-perl 0.2-4+b1 Perl extension for retrieving term ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii liburi-perl1.35.dfsg.1-1 Manipulates and accesses URI strin ii libwww-perl5.813-1 WWW client/server library for Perl ii libyaml-syck-perl 1.05-1Fast, lightweight YAML loader and ii links [www-browser 2.1pre37-1.1 Web browser running in text mode ii lintian1.24.2.1 Debian package checker ii lsb-release3.2-20Linux Standard Base version report ii lynx-cur [www-brow 2.8.7dev9-2.1 Text-mode WWW Browser with NLS sup ii mailx 1:20071201-3 Transitional package for mailx ren ii man-db 2.5.2-4 on-line manual pager ii openssh-client [ss 1:5.1p1-5 secure shell client, an rlogin/rsh ii patch 2.5.9-5 Apply a diff file to an original ii patchutils 0.2.31-4 Utilities to work with patches ii strace 4.5.17+cvs080723-2A system call
Bug#516704: devscripts: uscan should parse not only directory with highes version number
On Mon, 23 Feb 2009, Adam D. Barratt wrote: I believe this boils down to basically the same request as #375138, which has been marked wontfix for a couple of years. I admit this seems to be the same problem - sorry fo not verifying BTS properly. I haven't merged them yet as I'm undecided as to whether I agree with the original wontfix - opinions welcome, particularly from other devscripts maintainers. Well, once I brought this topic up again I would like to trigger a new discussion - IMHO the feature to go down the directory tree until a matching file is found makes sense to me. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516545: ITP: eprover -- The Equational Theorem Prover E
On Mon, 23 Feb 2009, Petr Pudlak (Debian) wrote: as I was suggested, I'm looking for a sponsor for the eprover package, who would help me with publishing the package. If you are seeking for a sponsor it is a clever idea to post the URL to your *.dsc file to enable others to evaluate your work. ;-) I believe that Debian Science would be a proper place for it. Did you asked for an alioth account which might be added to debian-science team. Once this is done you are able to commit to SVN or Git - posting this location would be an alternative to the URL of the *.dsc file. Kind regards and thanks for your work on eprover Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516875: ITP: libxfce4menu -- freedesktop.org compliant menu implementation for Xfce
On Tue, 24 Feb 2009, Yves-Alexis Perez wrote: * Package name: libxfce4menu Version : 4.6.0 Upstream Author : Jannis Pohlmann jan...@xfce.org * URL : http://www.xfce.org.org/ * License : GPL-2+ Programming Lang: C Description : freedesktop.org compliant menu implementation for Xfce libxfce4menu is an XDG-compliant menu implementation for Xfce Desktop Environment. Could you please be a little bit more verbose. I had the (maybe wrong) assumption that xfce4 would be XDG-compliant without any additional packages. Or is it just that xfce4 4.6.0 is more modulized? If this is the case I would mention this in the long description to avoid confusion. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517010: [Debian-med-packaging] Bug#517010: Bug#517010: [njplot] Please mention that njplot is a phylogenetic tree drawing program in the short description
On Wed, 25 Feb 2009, Charles Plessy wrote: tag 517010 pending thanks Thanks. ;-) thanks for the suggestion. I corrected the description in our Subversion repository, and the change will be part of the next upload (maybe not so soon…). Any specific reason to wait with an upload. IMHO it makes sense to fix description issues in a shorter time frame. This would influence our tasks pages and gives description translators more time. Kind regards Andreas. -- http://fam-tille.de
Bug#517010: [Debian-med-packaging] Bug#517010: Bug#517010: Bug#517010: [njplot] Please mention that njplot is a phylogenetic tree drawing program in the short description
On Wed, 25 Feb 2009, Charles Plessy wrote: Yes, the end of the coffee break :) ;-) Do not hesitate to upload if you are currently examining njplot. I can do it later, but I already shifted my attention to other packages. OK. I'm probably busy + offline until sunday evening. If nothing happened until then I'll take action. You sounded in your response like the upload would be delayed for weeks or so ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516545: ITP: eprover -- The Equational Theorem Prover E
On Wed, 25 Feb 2009, Petr Pudlak (Debian) wrote: dget -u http://petr.pudlak.name/deb/eprover_1.0.004-1.dsc I had a short look onto your work and would like to give some comments. At first you obviousely did a good job to create a lintian clean package of a complex software! Considering that you even provided man pages for binaries in /usr/bin shows that you made some effort. Especially if it is your first package that's very good. Some (nitpicking!!) idea: Have you considered to move the examples into a separate package. These are not really of a size which should be separated I just want to know whether you know about the option to separate architeture independant files into a separate package exspecially of the package might work without these files. If you confirm that you know this option but decided against it intentionally because the examples are a very impornat part of the package it is perfectly fine for me. Regarding team maintenance: I've seen that you have patched several files and did not used a patch system (like quilt or dpatch). Doing so seems to make Git the better choice for a Version Control System because we have the policy to not commit the upstream source to SVN and use patches instead. The Git workflow (which I'm not very comfortable with) seems to relay on commiting the whole source and patch the files accordingly. So the question is: Have you made up your mind about commiting eprover to the Debian Science reporitory? While this is not required to find a sponsor I would like to recommend this once more. In this case you should add Vcs-Git fields to debian/control. Just take a look at other packages in the Vcs and also see how Maintainer and Uploaders are handled there. I would love if someone else - preferably with better knowledge of this program would be check the package and perhaps do the actual sponsoring. If nobody will step up I can upload the package (but not before Monday next week). Kind regards and thanks for your work Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492842: [Debian-med-packaging] Bug#492842: aeskulap: LP bug 229681: Aeskulap images not seen
On Tue, 29 Jul 2008, Charles Plessy wrote: Package: aeskulap Version: 0.2.2b1-2 Severity: grave Justification: renders package unusable Hi all, I was browsing aeskulap's PTS page and found the Ubuntu bug 229681: https://bugs.launchpad.net/ubuntu/+source/aeskulap/+bug/229681 Basically, the user complains that aeskulap does not display images anymore. I tried to use aeskulap with the following DICOM files: - http://www.barre.nom.fr/medical/samples/files/MR-MONO2-8-16x-heart.gz - http://www.barre.nom.fr/medical/samples/files/MR-MONO2-16-knee.gz While I can display them with xmedcon (anther DICOM viewer we package), with aeskulap I see only plain black. I have not used aeskulap before, so I do not know how it should work, but I think that we have to take the Ubuntu bug very seriously (indeed gravely, severitywise). On the Ubuntu bug [1] page you wrote: Charles Plessy wrote on 2008-09-10: Hello, we tested aeskulap in Debian and realised that the problem of version 0.2.2b1-2 is that the version of the libraries on which it depends are not correctly specified. It works on freshly installed Debian Lenny systems, so it may probably work with Ubuntu Intrepid. If I understand you correctly this bug can be closed in Debian. Is this interpretation true? Kind regards Andreas. [1] https://bugs.launchpad.net/ubuntu/+source/aeskulap/+bug/229681 -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521819: debian-science: New proj dependencies
On Mon, 30 Mar 2009, fran...@debian.org wrote: You should change your build-dep from 'proj' to 'libproj-dev' and eventually also depend on 'proj-bin' if debian-science requires proj command-line tools to work, i.e.: /usr/bin/geod /usr/bin/proj /usr/bin/cs2cs /usr/bin/nad2bin /usr/bin/nad2nad /usr/bin/invgeod /usr/bin/invproj Yes, debian-science just depends on the command line tools or rather it wants to provide users who deal with geographical tasks some tools to deal with these tasks. So I did: $ svn diff Index: debian/changelog === --- debian/changelog(Revision 1481) +++ debian/changelog(Arbeitskopie) @@ -12,6 +12,8 @@ * Bumped policy to 3.8.1 and make use of the new feature that debian/control allows comment lines starting with # with no preceding whitespace. [Policy paragraph 5.2] + * tasks/geography: Depend from proj-bin instead of proj +Closes: #521819 [ Michael Hanke ] * Added preliminary task for cognitive neuroscience. Index: tasks/geography === --- tasks/geography (Revision 1481) +++ tasks/geography (Arbeitskopie) @@ -35,6 +35,8 @@ Depends: qgis-plugin-grass +Depends: proj-bin + Depends: mapserver-bin, \ gmt, \ gpsbabel, \ @@ -47,7 +49,6 @@ openscenegraph, \ thuban, \ drawmap, \ - proj, \ postgis, \ grace6, \ gpstrans, \ Francesco, BTW I really think you should try to understand the idea behind Debian Pure Blends its metapackage systems and the other advantages you might gain. Petter has just started out with some stuff but has not really continued this. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521975: libgtkdatabox: FTBFS: d-shlibs errors
On Mon, 30 Mar 2009, Daniel Schepler wrote: Package: libgtkdatabox Version: 1:0.9.0.1-1 Severity: serious X-Debbugs-CC: Junichi Uekawa dan...@debian.org, d-shl...@packages.debian.org From my pbuilder build log: ... dh_link -plibgtkdatabox-0.9.0-1 dh_installmime -plibgtkdatabox-0.9.0-1 # Call d-shlibmove to comply with library packaging guide d-devlibdeps debian/libgtkdatabox-0.9.0-1-dev.substvars \ debian/tmp/usr/lib/libgtkdatabox.so -- libatk1.0-dev package exists. -- libc6-dev package exists. -- libcairo2-dev package exists. -- libfontconfig1-dev package exists. -- libfreetype6-dev package exists. devlibs error: There is no package matching [libgio-2.0-0-dev] and noone provides it, please report bug to d-shlibs maintainer -- libglib2.0-dev package exists. -- libgtk2.0-dev package exists. -- libpango1.0-dev package exists. devlibs error: There is no package matching [libpangoft2-1.0-0-dev] and noone provides it, please report bug to d-shlibs maintainer I'd like to reassign this bug to d-shlibs but want to clarify with Junichi before whether this was the intention of this message. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522021: [Help] Bug#522021: arb_0.0.20071207.1-7(mips/experimental): FTBFS: missing -fPIC
Hi, I would like to ask for help of the mips porter team whether they might have a clue why this build fails. It seems to me that some graphics / Motif issues might be involved in the problem. Any help is welcome Andreas. On Tue, 31 Mar 2009, Frank Lichtenheld wrote: Package: arb Version: 0.0.20071207.1-7 Severity: important Hi, your package failed to build from source. | Automatic build of arb_0.0.20071207.1-7 on signy by sbuild/mips 98-farm | Build started at 20090331-0122 | ** | Checking available source versions... | Fetching source files... | Reading package lists... | Building dependency tree... | Reading state information... | Need to get 9984kB of source archives. | Get:1 http://ftp.de.debian.org sid/non-free arb 0.0.20071207.1-7 (dsc) [1603B] | Get:2 http://ftp.de.debian.org sid/non-free arb 0.0.20071207.1-7 (tar) [9950kB] | Get:3 http://ftp.de.debian.org sid/non-free arb 0.0.20071207.1-7 (diff) [33.1kB] | Fetched 9984kB in 3min38s (45.6kB/s) | Download complete and in download only mode | ** Using build dependencies supplied by package: | Build-Depends: debhelper (= 7), quilt, libmotif-dev, xviewg-dev, libxml2-utils, lynx, sablotron, libtiff4-dev, libxaw7-dev, kaffe | free-java-sdk, freeglut3-dev | libglu-dev, libglew1.5-dev, libpng12-dev, x11proto-print-dev, libxpm-dev, libxp-dev, libglw1-mesa-dev, perl-doc, chrpath | Checking for already installed source dependencies... [...] | gcc -W -Wall -DLINUX -pipe -DNO_REGEXPR -DGNU -O4 -DNDEBUG -DARB_OPENGL -DFAKE_VTAB_PTR=char -D_ARB_WINDOW -c GLwMDrawA.c -I. -I/build/buildd/arb-0.0.20071207.1/INCLUDE -I/usr/X11R6/include | In file included from GLwMDrawA.c:41: | GLwDrawA.c:344: warning: missing initializer | GLwDrawA.c:344: warning: (near initialization for 'glwMDrawingAreaClassRec.glwDrawingArea_class') | GLwDrawA.c: In function 'createColormap': | GLwDrawA.c:430: warning: unused parameter 'offset' | GLwDrawA.c: In function 'Redraw': | GLwDrawA.c:578: warning: unused parameter 'region' | GLwDrawA.c: In function 'glwInput': | GLwDrawA.c:651: warning: unused parameter 'params' | GLwDrawA.c:651: warning: unused parameter 'numParams' | gcc -W -Wall -DLINUX -pipe -DNO_REGEXPR -DGNU -O4 -DNDEBUG -DARB_OPENGL -DFAKE_VTAB_PTR=char -D_ARB_WINDOW -c GLwDrawA.c -I. -I/build/buildd/arb-0.0.20071207.1/INCLUDE -I/usr/X11R6/include | GLwDrawA.c:344: warning: missing initializer | GLwDrawA.c:344: warning: (near initialization for 'glwDrawingAreaClassRec.glwDrawingArea_class') | GLwDrawA.c: In function 'createColormap': | GLwDrawA.c:430: warning: unused parameter 'offset' | GLwDrawA.c: In function 'Redraw': | GLwDrawA.c:578: warning: unused parameter 'region' | GLwDrawA.c: In function 'glwInput': | GLwDrawA.c:651: warning: unused parameter 'params' | GLwDrawA.c:651: warning: unused parameter 'numParams' | g++ -fmessage-length=0 -Wall -shared -DNO_REGEXPR -DGNU -o libAW.so AW_position.o AW_Xm.o AW_at.o AW_button.o AW_click.o AW_device.o AW_font_group.o AW_global_awars.o AW_nawar.o AW_preset.o AW_print.o AW_question.o AW_size.o AW_status.o AW_window.o AW_xfig.o AW_xfigfont.o AW_xfont.o AW_xkey.o GLwMDrawA.o GLwDrawA.o | /usr/bin/ld: GLwMDrawA.o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC | GLwMDrawA.o: could not read symbols: Bad value | collect2: ld returned 1 exit status | make[2]: *** [libAW.a] Error 1 | make[2]: Leaving directory `/build/buildd/arb-0.0.20071207.1/WINDOW' | make[1]: *** [WINDOW/libAW.dummy] Error 2 | make[1]: Leaving directory `/build/buildd/arb-0.0.20071207.1' | make: *** [build-stamp] Error 2 | dpkg-buildpackage: failure: debian/rules build gave error exit status 2 | ** | Build finished at 20090331-0342 | FAILED [dpkg-buildpackage died] Full build log(s): http://experimental.ftbfs.de/build.php?ver=0.0.20071207.1-7pkg=arbarch=mips Gruesse, -- Frank Lichtenheld dj...@debian.org www: http://www.djpig.de/ ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-med-packaging -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498261: Bug seems to be fixed for a long time but no upload
Hi, when checking out the rasmol git repository[1] I noticed that the changelog says: rasmol (2.7.4.2-4) unstable; urgency=low * rules: Allow building GTK and X11 versions separately for testing * Merge patches/gtk-shortcuts: Add various keyboard shortcuts to the GTK interface * Merge patches/fileopen: Add support for opening more than one file from the command line. Simplify file opening code, remove globs and allow to open files with spaces and other 'special' characters. Fix reading files from stdin with '-' arg. (closes: #498261) -- Teemu Ikonen tpiko...@gmail.com Mon, 08 Sep 2008 17:03:55 +0200 Infortunately the package was not yet uploaded and I wonder what the reasons might be to not fix an iportant bug neither leave any notice in the BTS that it is fixed. Kind regards Andreas. [1] http://git.debian.org/git/debian-science/packages/rasmol.git -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522021: [Debian-med-packaging] [Help] Bug#522021: arb_0.0.20071207.1-7(mips/experimental): FTBFS: missing -fPIC
On Tue, 31 Mar 2009, Frank Lichtenheld wrote: On Tue, Mar 31, 2009 at 09:49:01AM +0200, Andreas Tille wrote: Hi, I would like to ask for help of the mips porter team whether they might have a clue why this build fails. It seems to me that some graphics / Motif issues might be involved in the problem. Any help is welcome [...] | gcc -W -Wall -DLINUX -pipe -DNO_REGEXPR -DGNU -O4 -DNDEBUG -DARB_OPENGL -DFAKE_VTAB_PTR=char -D_ARB_WINDOW -c GLwMDrawA.c -I. -I/build/buildd/arb-0.0.20071207.1/INCLUDE -I/usr/X11R6/include You might want to start by adding a -fPIC here, like the linker requested. But I can't test whether it really works - so any help of porters would be apreciated. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521975: libgtkdatabox: FTBFS: d-shlibs errors
On Wed, 1 Apr 2009, Junichi Uekawa wrote: Actually, I realize you have a local copy in debian/, which is still broken. While I used this in former times to circumvent some problems this is not true for libdatabox. Where did you got this impression from? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503367: Again: Bug#503367: plink: file conflict with putty-tools
Hi, in October last year there was a longish discussion about name space pollution regarding plink. If you like to spend some time you should read the complete log of #503367 [1]. I decided to put an end now on this issue to make sure it will not remain as is for ever and renamed the entry in /usr/bin. This is explained in README.Debian of this package (see svn[2]). Two questions are left on my side: 1. On the one hand plink upstream claimed on their website[3] that Debian *has* renamed plink to snplink (which is not really true because the discussion ended without any real action). But Gentoo went the same road to follow Debian. So there is one established way which is accepted upstream to handle this problem. On the other hand there is this other biological project which has a snplink as well.[4] While chances are not really high that this software will also be packaged - you can not know. So what is better: Just seeking for another name which hopefully is singular and asking upstream as well as Gentoo to change as well or live with the small risk to run the same circle of name space pollution in case the other snplink will be packaged? 2. Is the information that plink was renamed to snplink visible enough or should I rather use a debconf note to make users really aware what they have to do? Kind regards Andreas. [1] http://bugs.debian.org/503367 [2] http://svn.debian.org/wsvn/debian-med/trunk/packages/plink/trunk/debian/README.Debian?op=filerev=0sc=0 [3] http://pngu.mgh.harvard.edu/~purcell/plink/download.shtml [4] http://www.icr.ac.uk/research/research_sections/cancer_genetics/cancer_genetics_teams/molecular_and_population_genetics/software_and_databases/index.shtml -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503367: Again: Bug#503367: plink: file conflict with putty-tools
On Thu, 2 Apr 2009, Daniel Leidert wrote: Two questions are left on my side: 1. On the one hand plink upstream claimed on their website[3] that Debian *has* renamed plink to snplink (which is not really true because the discussion ended without any real action). But Gentoo went the same road to follow Debian. So there is one established way which is accepted upstream to handle this problem. On the other hand there is this other biological project which has a snplink as well.[4] While chances are not really high that this software will also be packaged - you can not know. What about using /usr/bin/PLINK? I can't find a requirement in the policy to use lowercase characters for a binary/script. Maybe I missed it? A Plink was discussed and refused [1] and finally *any* rename has the same problem - it breaks existing scripts. I personally would not have a problem to use any case variation. Well, a NEWS entry is mandatory in this situation. I would further suggest to put this information into the package description too and of course leave an entry in README.Debian. I'll do so. Thanks Andreas. [1] http://lists.debian.org/debian-devel/2008/10/msg00642.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503367: Again: Bug#503367: plink: file conflict with putty-tools
On Fri, 3 Apr 2009, Steffen Moeller wrote: we should ask the technical committee to rule over it. And maybe this needs some voting in the end. Who is this *we*? Do you volunteer? IMHO plink should be renamed because it is way less popular than the putty tool. So we will loose this voting anyway and there is much effort for an foreseable outcome. IMHO the solution I described in README.Debian is reasonable for plink users even with existing scripts. I personally think that we should not rename it. And putty's plink should not be renamed either. The two are in a technical conflict, though with little practical consequences. To me, this situation is preferable over the renaning of the binary of either. This is a worse solution than a rename. Please keep in mind that we don't need to package everything. (sn)plink can just be removed from the archive. Or could it move to non-free since it does not adhere to Debian's principles? I need to reread the policy here. Moving to non-free will not solve the problem and is just wrong (because it is actually not non-free). Trying to solve a problem by pretending wrong facts is a no go. I'd strongly recommend to settle (together with upstream) for a reasonable alternative name (I don't care whether it is snplink, Plink, PLINK or something else) but we should find a reasonable decision in a short time frame (to not spend to power into an issue which does not bring anybody foreward). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522772: ITP: CDO -- Climate Data Operators
Hi, a Debian Science task meteorology comes to mind ... Kind regards Andreas. On Mon, 6 Apr 2009, Alastair McKinstry wrote: Package: wnpp Severity: wishlist Owner: Alastair McKinstry mckins...@debian.org * Package name: CDO Version : 1.3.0 Upstream Author : Uwe Schulzweida uwe.schulzwe...@zmaw.de * URL : http://www.mpimet.mpg.de/fileadmin/software/cdo/ * License : GPL2 Programming Lang: C Description : Climate Data Operators - tools for climate data manipulation CDO is a collection of command line Operators to manipulate and analyse Climate model Data. Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG. There are more than 400 operators available. The following table provides a brief overview of the main categories. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522916: must use invoke-rc.d (policy 9.3.3.2)
On Tue, 7 Apr 2009, Holger Levsen wrote:
during a test with piuparts I noticed your package left processes running on
the system after installation and removal. This is due to directly
calling /etc/rc.d/ scripts in your packages maintainer scripts, which is a
violation of policy 9.3.3.2 and must be replaced by using policy-rc.d - see
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
Thanks for your investigation. Before I go for an upload I would like
you to revise my proposed patch:
Index: dict-wn.postinst
===
--- dict-wn.postinst(Revision 35616)
+++ dict-wn.postinst(Arbeitskopie)
@@ -6,14 +6,18 @@
case $1 in
configure)
- if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi
+ if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi
- if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi
+ # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi
+ if which invoke-rc.d /dev/null 21; then
+ invoke-rc.d dictd restart
+ else
+ /etc/init.d/dictd restart
+ fi
- exit 0
- ;;
+ exit 0
+;;
-
failed-upgrade/abort-upgrade|abort-remove|abort-deconfigure|in-favour|removing)
exit 0;
;;
Index: changelog
===
--- changelog (Revision 35616)
+++ changelog (Arbeitskopie)
@@ -1,3 +1,10 @@
+wordnet (1:3.0-15) unstable; urgency=low
+
+ * Fix usage of init scripts debian/dict-wn.{postinst,prerm}
+Closes: #522916
+
+ -- Andreas Tille ti...@debian.org Tue, 07 Apr 2009 22:58:07 +0200
+
wordnet (1:3.0-14) unstable; urgency=low
* Removed redundant part from description
Index: dict-wn.postrm
===
--- dict-wn.postrm (Revision 35616)
+++ dict-wn.postrm (Arbeitskopie)
@@ -4,13 +4,17 @@
case $1 in
remove|purge)
- if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi
- if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi
+ if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi
- exit 0
- ;;
+ # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi
+if which invoke-rc.d /dev/null 21; then
+ invoke-rc.d dictd restart
+ else
+ /etc/init.d/dictd restart
+ fi
+ exit 0
+;;
-
upgrade|abort-upgrade|abort-remove|abort-deconfigure|in-favour|removing)
exit 0;
;;
I hope that's it and fits policy properly.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523077: science-physics: suggests a package with a broken name
On Wed, 8 Apr 2009, Eugene V. Lyubimkin wrote: Package: science-physics Version: 0.5 Severity: serious Justification: Policy 5.6.7 Suggests contains 'ESPResSo++, PWscf', but upper-case letters are not allowed in package names. Fixed in SVN. I might consider to lowercase any package names when creating the control file for a Blend which will prevent such bugs for the future. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522916: must use invoke-rc.d (policy 9.3.3.2)
On Wed, 8 Apr 2009, Holger Levsen wrote: - if you ask others for review, you shouldn't have whitespace changes in the diff. Yes - sorry. I somehow expected this hint after I sended the mail. - you shouldn't _restart_ the daemon in postrm :-) (and probably not call dictconfig neither) Well, the dictd daemon is *not* part of the dict-wn package. So it might / will exist after removing dict-wn. The package dict-wn just provides one possible data file for dict and if it is removed the dictd daemon needs to know this (via a restart). Do you think it is OK considering this? BTW, the current invoking of dictd was inspired to work around a problem (#357020) which becomes void now because the serpento package is finally removed. So thanks for the catch with piuparts. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514023: Archive not taken over
On Sat, 21 Mar 2009, David Moreno wrote: That's correct, the mailing list has been renamed and /most/ of its services have been migrated. As you say, yes, the web archives still need to be moved. I hadn't spoken about this since the main reason for not finishing it was lacking time on my side. Hopefully, during this weekend, I'll find some time and finish the archive migration. This is also why I hadn't closed the request bug or sent any notification. Thanks for the clarification and your work on this. Just take the time you need Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520747: BioCocoa.app and SequenceConverter.app (Was: Bug#520747: Watch file)
On Sun, 22 Mar 2009, Daniel Leidert wrote: Please find attached a watch file for biococoa.app. There are two possible solutions to catch the version. The first one catches all releases based on the web-SVN service at bioinformatics.org (and also allows to download a tarball). The second one at least works for the new releases 2.x. Many thanks for the patch - it's applied in SVN. You seem to prefer the SVN version in this file. Any reason that you regard it higher than the download version - any reasons for this? In general I wonder what the current status of Biococoa.app might be. Scott Christley has split up a separate application sequenceconverter.app but neither a new biococoa.app nor sequenceconverter.app was finally uploaded. Scott could you please elaborate on your plans for an upload? Any blockers we should know about? I just polished the biococoa.app control file a bit in SVN and wonder whether you regard it fit for upload and whether somebody with GNUstep knowledge might be able to test whether eveything works like expected. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521002: r-cran-sp: long description no sentence
On Tue, 24 Mar 2009, Gerfried Fuchs wrote: It would be nice if the long description of your package could consist of full sentences[1], the first part is not really one. :) Before we do another round of this non sentence bug reports just have a look at This R package provides functions returning, displaying or writing to disk the LaTeX or HTML code associated with the supplied object of class xtable. The package also provides functions converting an R object to an xtable object, which can then be printed as a LaTeX or HTML table. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521002: r-cran-sp: long description no sentence
On Tue, 24 Mar 2009, Gerfried Fuchs wrote:
Package: r-cran-xtable
Ahh, I've found the reassign, but I wonder whether you like my change to xtable
--- control (Revision 35604)
+++ control (Arbeitskopie)
@@ -14,7 +14,7 @@
Architecture: all
Depends: ${shlibs:Depends}, r-base-core
Description: GNU R coerce data to LaTeX and HTML tables
- This R package provides functions returning and displaying or writing
- to disk the LaTeX or HTML code associated with the supplied object of
+ This R package provides functions returning, displaying or writing to
+ disk the LaTeX or HTML code associated with the supplied object of
class xtable. The package also provides functions converting an R object
to an xtable object, which can then be printed as a LaTeX or HTML table.
anyway. (Private mail is fine.)
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520747: [Debian-med-packaging] Bug#520747: BioCocoa.app and SequenceConverter.app (Was: Bug#520747: Watch file)
On Tue, 24 Mar 2009, Scott Christley wrote: There was some copyright/license issues that needed to be resolved. Those should all be resolved now, I'd be very happy if somebody might have a look at biococoa. I have polished packaging regarding inclusion of documentation and examples, updating Standards-Version, polishing changelog etc. The package builds fine and lintian clean in a pbuilder environment - however I have no idea about GNUstep and thus can not really test whether everything works as expected. I thought that there was a new release but maybe that didn't happen, I will take a look. Thanks to Daniel Leidert the watchfile of biococoa is fixed and there is no need to look. Packaging SVN is up to date and you can obtain the latest version via uscan --verbose --force-download Otherwise, I don't think there is anything blocking an upload. I'm pretty hectic this week with an upcoming weekend trip, but hopefully I can resolve this in the coming week. I would very much like to see BioCocoa updated. Both packages biococoa and sequenceconverter.app build fine and sequenceconverter starts at least. If somebody might like to do some testing (or Scott finds time next week) we might upload both. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520747: [Debian-med-packaging] Bug#520747: BioCocoa.app and SequenceConverter.app (Was: Bug#520747: Watch file)
On Wed, 25 Mar 2009, Yavor Doganov wrote: GNUstep frameworks are packaged like classic shared libraries (that's what they are, in fact), i.e. the biococoa source package should build the binary packages libbiococoa2 and libbiococoa-dev. Fine. You don't need the Replaces/Conflicts/Provides: biococoa.app -- sequenceconverter.app I had the impression that sequenceconverter.app builds and runs fine without biococoa - strange, but worked on my machine. would just build-depend on libbiococoa-dev and end up depending on libbiococoa2. If you strongly care about upgrades, sequenceconverter.app could build also a dummy transitional package biococoa.app that depends on sequenceconverter.app (to be dropped after Squeeze). I'm not sure about this. If you don't mind, I can provide a patch for that plus some other fixes that make the package compliant to the (still unwritten) Debian GNUstep policy. I would really appreciate any help here - I could even give you SVN commit permission (if you tell me your alioth login) Note that there is a GNUstep transition pending (we are currently waiting for the ffmpeg and poppler transitions), so it would be great if you upload only when it finishes. It's fine for me to wait. Also, one upstream fix is needed: the top-level GNUmakefile should contain the following line: LIBRARIES_DEPEND_UPON += $(OBJC_LIBS) $(FND_LIBS) to actually link against libobjc and libgnustep-base. If you want to know the harm this causes for GNUstep transitions, see this subthread: http://lists.debian.org/debian-release/2009/03/msg00109.html If you can push this upstream and a new release is pending, that would be great. Otherwise, please tell me what patch system do you prefer. We are using quilt. You can find the packaging at Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/biococoa/trunk/ and Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/sequenceconverter/trunk/ BTW, when doing the actual packaging I was wondering whether a cdbs module for GNUmake might make sense. If you are undergoing some renewal of GNUstep issues this might be an interesting thing to do to simplify packaging and pushing changes through all packages quickly in case something might change in the future. Kind regards and I woudl be happy about any help Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520747: [Debian-med-packaging] Bug#520747: BioCocoa.app and SequenceConverter.app (Was: Bug#520747: Watch file)
On Wed, 25 Mar 2009, Yavor Doganov wrote: On Wed, Mar 25, 2009 at 04:12:11PM +0100, Andreas Tille wrote: I had the impression that sequenceconverter.app builds and runs fine without biococoa - strange, but worked on my machine. Right, I wrongly assumed that it links against BioCocoa. So most probably we might simply release sequenceconverter.app completely independant from BioCocoa? - I could even give you SVN commit permission (if you tell me your alioth login) I'm yavor-guest, but maybe it is a good idea to see my patches first :-) Well, several people read the commit mails and reverting something should be no problem at all. So there is no need to hesitate. BTW, when doing the actual packaging I was wondering whether a cdbs module for GNUmake might make sense. There is: /usr/share/cdbs/1/rules/gnustep.mk. I'll convert biococoa to use CDBS then, right? Ahh, that's great - I just not realsied this. Conversion to CDBS would be perfectly OK. If you are undergoing some renewal of GNUstep issues this might be an interesting thing to do Yes, although I'm not a fan of CDBS, personally. Well, I would not call myself a fan - but it works quite good for team maintainance because you can have a good overview quite quickly. But only if it fits - there are more complex packages which just create headaches if you try to turn them to CDBS. Just decide what you would regard reasonable for the specific case - it's fine if you keep the current packaging. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520747: [Debian-med-packaging] Bug#520747: BioCocoa.app and SequenceConverter.app (Was: Bug#520747: Watch file)
On Wed, 25 Mar 2009, Yavor Doganov wrote: Here it is. I added some comments in debian/rules for things that might not be entirely obvious to you -- feel free to strip them. No, comments are perfectly OK - in contrary, they should be there. I committed your changes and thank you very much for cleaning things up. The only thing I wonder about is the following: Should we file an ITP for either biococoa (2) or sequenceconverter.app? While sequenceconverter.app is the real successor of the former biococoa.app (source and binary package) it might sound like a new for ftpmaster but in fact biococoa is the new package regarding content and I also wonder if we even should conserve the old changelog of biococoa.app - it's just something else. Any opinions? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520747: [Debian-med-packaging] Bug#520747: BioCocoa.app and SequenceConverter.app (Was: Bug#520747: Watch file)
On Thu, 26 Mar 2009, Yavor Doganov wrote: All right. I like comments, but some maintainers consider them redundant. I always consider them helpful. Thanks! I see that you added me to the project -- does that mean that I can commit without pre-approval Yep! That was the idea as I said in one of my previous mails. (only to GNUstep packages, of course)? Why of course. If you see a problem feel free to fix it. But well, sticking to the GNUstep packages is fine for sure. If that's too pushy, I'll perfectly understand that and will submit the diff to the list first. No, that's far from pushy. As I said: Several people read the commit logs and reverting a change is no big deal. IMHO ITPs are primarily to prevent duplicate work and are redundant in this case. The only possible benefit is eventually someone to suggest improvements to the descriptions. AFAIK ftpmasters do not have requirements NEW packages to have ITP bugs filed. This in principle fits my preference. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#278650: feh: wrong remote display with different archs.
On Fri, 27 Mar 2009, Laurent Fousse wrote: I can't reproduce the problem, running feh 1.3.4.dfsg.1-1 on an i386 remotely from a ppc. So you would agree if I would close this bug? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514023: Status of this bug?
Hi listmasters, is there any number of promoters which might convince you that this list is needed? I have some announcements to make, some work to do which should be organised over this list. I would love to see this list created in the next seven days if possible. If you are not yet convinced I will do the announcements without the list and will rather mention this bug number to let more people respond here but I would prefer to announce the existence of the new list. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517945: ITP: libxray-absorption-perl -- x-ray absorption data for the elements
On Mon, 2 Mar 2009, Carlo Segre wrote: Package: wnpp Severity: wishlist Owner: Carlo Segre se...@debian.org * Package name: libxray-absorption-perl Version : 2.0.1 Upstream Author : Bruce Ravel bra...@bnl.gov * URL : http://cars9.uchicago.edu/svn/libperlxray * License : Artistic Programming Lang: Perl Description : x-ray absorption data for the elements This module supports access to X-ray absorption data. It is designed to be a transparent interface to absorption data from a variety of sources. Currently, the only sources of data are the 1969 McMaster tables, the 1999 Elam tables, the 1993 Henke tables, and the 1995 Chantler tables. The Brennan-Cowen implementation of the Cromer-Liberman tables is available as a drop-on-top addition to this package. More resources can be added easily. Hi Carlo, can you imagine applications where this variety of sources includes x-ray data from medical care? I'm wondering whether this package might be an interesting target for the Debian Med physics task. Or are the ITPed packages rather targeting at particle physics and do not really targeting at medical care? IMHO it would not harm if you would add the answer to this question as a separate paragraph to the description. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516545: ITP: eprover -- The Equational Theorem Prover E
On Tue, 3 Mar 2009, Petr Pudlak (Debian) wrote: Hi Andreas, everybody, I moved the package into the git repository: Vcs-Git: git://git.debian.org/git/debian-science/packages/eprover.git Vcs-Browser: http://git.debian.org/?p=debian-science/packages/eprover.git and adapted the package for GIT. It's lintian clean, except for a pedantic warning that it doesn't use a patch system, which I hope is OK, since I've converted my dpatches into git revisions. That's fine. I'd be happy If somebody could upload the package, or perhaps point out that there is something that should be corrected before uploading. I'm currently busy but if nobody would step up until Friday - just come back to me ... Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471410: Installing accessibility packages by default?
On Thu, 5 Mar 2009, Samuel Thibault wrote: It has been suggested a few times (471410, 511329, 516723) to add an accessibility item to tasksel, which would e.g. install gnome-accessibility. The task would be automatically selected when accessibility features was used during d-i itself. I wonder whether this effort might profit from maintaining metapackages for accessibility as it is done in the blends effort. The blends-dev has tasksel support as well - so it is easily possible to include accessibility related packages into tasksel. The extra profit would be that you can provide an easy overview about accesibility related programs in Debian - the only way I know is $ apt-cache search accessibility which is quite weak. Thinks of alternatives like http://blends.alioth.debian.org/science/tasks/ (which might even work for non native English speakers) and you also have a developer related overview about bugs http://blends.alioth.debian.org/science/bugs/ There is no extra effort to create these web pages once you defined the tasks. `While it is a possible approach to have the installer explicitly select packages for the users who are going to use the machine, it is also obvious that an administrator might not know in advance that a person with special needs is going to use this machine. If we think this through, we realize that what would be most desireable is to have accessibility infrastructure installed by default on a default desktop, so that a person with special needs can just activate it at login time if they need to.' I admit that my suggestion above does not really help in this aspect. On the other hand there were some ideas raised in the past to enable a user to install certain tasks quickly inside the Blends framework. Perhaps we should raise this topic again. `What if, for example, you walk up to a friend/coworker and talk about some issue. You end up wanting to show them something, so you'd actually like to login on tehir Linux machine with accessibility enabled so that you can work together on the project. However, since nobody thought their machine would ever be used by a disabled person, the necessary software would not be installed.' The problem is that the typical admin does not have the specific knowledge what actually is needed. The idea to iron out this knowledge inside the tasks files to enable admins who have not enough specific knowledge about the needs of their users is one means to help in this issue. `That is why I think ultimately, accessibility infrastructure needs to be part of the default desktop installation. There are a few other scenarios as well, like public workstations (for instance in universities) running Linux. Currently, for them to be accessible, the admin staff needs to know all the ins and outs of accessibility, or they at least have to make a conscious decission about providing it to users. If accessibility would work by default, the chance of success for disabled people trying to find an accessible computer would be much higher.' I perfectly see the point here. On the other hand I assume there are most probably urgently needed packages who should be installed per default and others which are just Recommended and Suggested. So IMHO it makes sense to have a accessibility-gnome / accessibility-kde (perhaps accessibility-desktop) metapackages which are part of a default installation. But most probably there are other packages which should be handled with different priority and you can perfectly handle these by using metapackages. The advantage of using accessibility-gnome / accessibility-kde metapackages is that you can perfectly handle the dependencies inside the accessibility project because there will be no need to change d-i or the Gnome / KDE tasks. They need only depend from one single package and you can change the dependencies on your own in case some additional packages will show up or some names will be changed for whatever reason. So, I'm asking: would it seem reasonable to ask tasksel to install accessibility packages along desktop packages? IMHO yes - but in the way I suggested above and not by using explicite package names. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517945: ITP: libxray-absorption-perl -- x-ray absorption data for the elements
On Thu, 5 Mar 2009, Carlo Segre wrote: This module supports access to X-ray absorption data. It is designed to be a transparent interface to absorption data from a variety of sources. Currently, the only sources of data are the 1969 McMaster tables, the 1999 Elam tables, the 1993 Henke tables, and the 1995 Chantler tables. The Brennan-Cowen implementation of the Cromer-Liberman tables is available as a drop-on-top addition to this package. More resources can be added easily. Hi Carlo, can you imagine applications where this variety of sources includes x-ray data from medical care? I'm wondering whether this package might be an interesting target for the Debian Med physics task. Or are the ITPed packages rather targeting at particle physics and do not really targeting at medical care? IMHO it would not harm if you would add the answer to this question as a separate paragraph to the description. Hmm, the answer is that these modules allow the calculation of how matter absorbs xrays of different energies. The McMaster tables are the basic reference and have been extended by the Elam and Henke tables to provide additional quantities (fluorescence and total cross-section). The calculations can beused byt many different kinds of researchers, basically anyone who is interested in the interaction of x-rays with matter. I am sure that this includes medical physicists but I do not know if there are other tabulations of data specifically made for medical physics. Well, I just propagate this information to Debian Med list. If nobody raises explicit interest we will leave it out. IMHO a suggests in med-physics will not really harm if anybody might see some use for it. Thanks for the clarification anyway. The calculations are probably not terribly useful to particle physicists though, more to condensed matter and materials physicists and chemists. These modules are necessary components for the horae suite of programs for analysis of x-ray absorption spectroscopy and they used to be hidden in the horae package but have been split out now. So this might make sense in science-physics and science-chemistry as well. i will certainly consider improving the long description in future releases. For now, i prefer to leave them in the incoming queue as they are. That's fine for sure. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516545: ITP: eprover -- The Equational Theorem Prover E
On Tue, 3 Mar 2009, Petr Pudlak (Debian) wrote: I moved the package into the git repository: Vcs-Git: git://git.debian.org/git/debian-science/packages/eprover.git Vcs-Browser: http://git.debian.org/?p=debian-science/packages/eprover.git and adapted the package for GIT. I commited some changes (basically changed the Debian version of the package to -1 and moved the doc/examples to /usr/share/doc/eprover instead of the doc directories of these packages. You might consider adding symlinks for cosistency reasons - but users will look for the docs in /usr/share/doc/eprover and if I'm not completely missleaded this is usual style of packaging (I did not consulted the docs). If you are happy with these changes I might upload in the next couple of days Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471410: Installing accessibility packages by default?
On Thu, 5 Mar 2009, Samuel Thibault wrote: $ apt-cache search accessibility which is quite weak. Tags FTW. Look for Accessibility tags and you'll find a lot of packages. Sure. But do all our package handling tool support DebTags? Are our users aware of DebTags. (Well I admit they might fail to find metapackages as well.) So I'd regard DebTags as a very important technique and joining DebTags information with Blends techniques is quite high on my todo list. Thinks of alternatives like http://blends.alioth.debian.org/science/tasks/ http://blends.alioth.debian.org/science/bugs/ Let me point out something which I think is important (even if I think that's not what you meant): accessibility is not a task. It's like i18n, it's orthogonal to tasks: for all the tasks above you actually need accessibility support. I perfectly got this information out of your last mail. But IMHO this is rather a question of terminology. I'd try to find out what might be helpful for users and IMHO the Blends technique is quite useful. Feel free to suggest a better terminus than task which fits all needs. I do not mean that the tool itself shouldn't be used of course. Fine. ;-) The admin, no, but you (the disabled person) do know and just ask your friend/coworker to run e.g. orca (already installed by default). With USB braille devices, it would even be possible to automatically start it, no even need to sudo. That's fine for this specific case. But my idea is that it is easier to ask for not by default installed packages on the phone line to your local admin if you have to ask for a single metapackage rather than a list of packages. While I share your point that a default machine should have all needed accessibility features there might be a list of suggested packages or even new packages. In the later case would an apt-get update be sufficient to include new software if the metapackage was properly adjusted and net even a phone call would be needed. The idea to iron out this knowledge inside the tasks files to enable admins who have not enough specific knowledge about the needs of their users is one means to help in this issue. Yes, we definitely need to have some sort of database that allows people to know the name of the tools they can try to use to help them anyway. Fine. That's what I'm talking about. So IMHO it makes sense to have a accessibility-gnome / accessibility-kde (perhaps accessibility-desktop) metapackages which are part of a default installation. Which can Depend/Recommend/Suggest depending on the criticity of the help provided by various packages: - can't use the computer without it (e.g. screen reader for blind people). - hard for me to use the computer without it (e.g. color scheme). - makes me more efficient (e.g. dasher). Yes, that's the idea. The advantage of using accessibility-gnome / accessibility-kde metapackages is that you can perfectly handle the dependencies inside the accessibility project because there will be no need to change d-i or the Gnome / KDE tasks. Yes, I also think that'd be better. IMHO yes - but in the way I suggested above and not by using explicite package names. Sure. We don't want to have to bother d-i each time new accessibility packages get added :) Fine. If you want to follow this idea I'd suggest the following things: 0. Try to convince listmaster to fix bug #514023 and subscribe the resulting mailing list debian-blends. I see a big need to have at least one member of the accessibility team lurking on the Blends list to make sure that we do not trap into the pitfalls of choosing narrow minded names (like tasks) or just do other things which are contra productive for your goal. 1. I used your nice classification page [1] to create the stuff you need to create tasks and bugs pages which are linked here: http://blends.alioth.debian.org/accessibility/ You can adjust the informatio in the related SVN svn://svn.debian.org/wsvn/blends/projects/accessibility/trunk/debian-accessibility/tasks Please read my comments and fix the info there! I can add you to the blends team or you can send me a patch. BTW, thanks to your fine software categorisation page the creation of the tasks files took me about 15 minutes. IMHO the result of the tasks and bugs pages is worth this effort. 2. Try to investigate whether something is wrong with your packages. a) http://blends.alioth.debian.org/accessibility/tasks/console.html says that these packages do not have a homepage. This is possibly not true but the control file of the package is lacking the Homepage field. If you fix the package control information the tasks page will be fixed after the next cron job run (twice a day). b) Consider group maintenance in a common repository - it has turned out a good means to fix things like missing Homepage
Bug#370822: About xteddy bug #370822
On Fri, 6 Mar 2009, Kumar Appaiah wrote: I just wanted to ask you whether you have seen my patch for #370822 already, and whether you need something else to be done there as well. I usually don't nag people, but I took the liberty of asking you since you are usually quick with mail (unless you are busy, of course), and hoped you wouldn't mind. Your nagging is perfectly OK. I applied your patch and builded a new upstream version from it (as I did with previous versions of XTeddy because upstream does not work any more on XTeddy but volunteers to put new versions on his official homepage. This sounds reasonable to me to let other distribs profit from it. Once this new version is online (or after a couple of further days of waiting) I'll upload. Kind regards and thanks for your patch (as well as sorry for the unusual long delay) Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471410: Installing accessibility packages by default?
On Sat, 7 Mar 2009, Samuel Thibault wrote: I'll send you a patch to expand it to a somewhat bigger list. Great. It is applied and shows up at the tasks pages now. I'm sthibaul-guest on alioth. You are now able to commit the changes yourself. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370822: About xteddy bug #370822
On Sat, 7 Mar 2009, Kumar Appaiah wrote: Wonderful to hear that upstream will support your release. It would be nice to synchronize the upload with the release on the official homepage. This exactly is my plan Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518880: #518880 ITP: dots -- braille translation user interface
On Mon, 9 Mar 2009, Samuel Thibault wrote: * Package name: dots Version : 0.0.20090222 Upstream Author : Eitan Isaacson ei...@ascender.com * URL : https://github.com/eeejay/dots/tree * License : GPLv3 Description : braille translation user interface Dots is a user interface for liblouisxml, a braille translation engine that can translate XML and MS Word documents into transcribed braille. I just want to mention that it is perfectly possible to include dots at this state inti the tasks files. I usually do this to make sure I'll not forget it later. The metapackage building tools are clever enough to turn dependencies of not (yet) existing packages into Suggests - so the metapackage will be valid from the beginning. The web page building tools will ignore it (there is a warning issued at command line - see alioth:/var/lib/gforge/chroot/home/groups/blends/webtools/logs/ ) and you might even add some additional information (including the number of the WNPP bug) to get it listed as prospective package - see the examples in Debian Med tasks files or read the blends doc[1]. I'd leave it to your decision how long you estimate the delay between issuing the WNPP bug and the final upload. BTW, it is planed to even parse the new queue to obtain the needed information for the tasks page (but this needs some preparation). Kind regards Andreas. [1] http://blends.alioth.debian.org/blends/ch-sentinel.en.html#s-packageslist -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585457: IGV dependencies
Hi Shaun, On Thu, Jun 10, 2010 at 11:55:54AM -0700, Shaun Jackman wrote: IGV has a lot of dependencies, and the list follows. Many of these dependencies are already in Debian; many others are not. Where the dependency is satisfied, I've given the Debian package name. Where it's not satisfied, I've given the upstream URL. thanks for your ITP which is quite interesting for Debian Med. Will you consider also packaging the dependencies? I woud suggest coordination with debian-j...@lists.debian.org. Perhaps there is some work ongoing or some help can be given. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586066: libcomplearn: Typo in watch file leads to reporting new upstream version
Package: libcomplearn Severity: minor Tags: patch Hi, I was alarmed by the new version available message I've got but then I noticed that there is just a missing '.' in the debian/watch file. Please use this as watch file content: version=3 http://complearn.org/download.html \ downloads/libcomplearn-([\d\.]*)\.tar\.gz BTW, I wonder whether you might be interested in putting the package under team maintenance of the Debian Science team. This would mean using the mailing list as maintainer and putting yourself as uploader. It is suggested to either use the Debian Science Git or SVN repository to enable other team members to cooperate. Kind regards and thanks for maintaining libcomplearn Andreas. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-xenU (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586291: wesnoth-1.8: Please rename to wesnoth and remove older versions
Package: wesnoth-1.8 Severity: normal Hi, I would regard it as highly confusing if the new version of a program is hidden behind a version number and I stick to the old version after an upgrade. It took me some time to realise that we actually have wesnoth 1.8 in Debian (I admit I was not particularly interested). Morover I really fail to see any reason why Debian should provide different versions of random games. So I would strongly suggest to replace the wesnoth packages of version 1.6 by the packages which are now named wesnoth-1.8. Kind regards Andreas. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-xenU (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586291: wesnoth-1.8: Please rename to wesnoth and remove older versions
On Fri, Jun 18, 2010 at 09:58:00AM +0200, Gerfried Fuchs wrote: There will be a meta package, as outlined in my blog post: http://rhonda.deb.at/blog/debian/2010/06/09 I'm lacking an explanation what might make Wesnoth so special compared to other games that Debian (aka Release team and Security team) need to support two different versions. IMHO this is unneeded work and over-engineering. Having a metapackage which picks the recent stable upstream version might be OK. I do not think that we should actually release two different versions in stable Debian. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586291: wesnoth-1.8: Please rename to wesnoth and remove older versions
On Fri, Jun 18, 2010 at 11:19:19AM +0200, Gerfried Fuchs wrote: I'm lacking the information that you are part of either team or are needed to specifically be made aware of the communication with those teams. I can give you precise information about this: I'm not a part of either team - I just was trying to apply common sense and was deducing from former similar cases (for instance Zope, where RC team was fighting hard about reducing the number of versions inside Debian). Let me cite again from the blog entry, maybe you missed that paragraph: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch. I can confirm that I have read this. Do you want me to quote numerous requests of scientists who need some specific versions of certain programs? IMHO Debian will fail in consistently support all those requests and I fail to see why Wesnoth (BTW, I like it as well) should make here an exception. IMHO this is unneeded work and over-engineering. IMNSHO you are not the package maintainer and neither involved in the upstream development or the bug management of the package, might it be in the wesnoth forums, the Debian BTS or Ubuntu lanuchpad. Also you aren't the one doing the work so I'm not sure what makes you competent to judge the benefits in respect to the needed work for it. I reported a bug as a user of Debian and specifically wesnoth and the problem I detected was that I was failing in realising that Debian has packages for never versions but no smooth upgrade path. This information belongs to the BTS and the fact that you have a promise for your solution does not solve this bug report. Up to now I was not aware of the fact that a user needs to have some specific features as you are requesting above to be able to report a problem. I have drawn the line further by proposing a solution for the problem - I did not called it patch and considering your answer this would not have been accepted. BTW, I see no need to question the qualification for certain opinions of fellow DDs. Having a metapackage which picks the recent stable upstream version might be OK. I do not think that we should actually release two different versions in stable Debian. I do not think that I anywhere mentioned that it is actually planed to release two different versions in stable Debian. We didn't and we don't plan to. So why are you making so much fuzz about my bug report instead of just answering this way? Kind regards Andreas. PS: For me the issue is OK and needs no further discussion and so I will probably stay silent about this. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586618: Finding wrong packages in depencency list (Was: education-desktop-lxde: Mistake in its suggested packages)
Hi, when reading this bug report I would like to *repeat* my hint which I have given since about 1.5 years in different forms that anybody with a login on Alioth can see this kind of problems by doing a less /var/lib/gforge/chroot/home/users/tille/blends/webtools/logs/debian-edu.err For your comfort I'm attaching a (little bit stripped) version from today in the end of this mail. I would strongly advise to browse your tasks files for the packages below and check for the reasons why the packages mentioned in the log are not in the Debian package pool. The reasons might be various. One might be misspellings as in this bug report and there might be more of them which needs fixing. Other reasons might be that a package was removed from Debian - it makes no sense to keep them in the tasks files any more. A further reason might be that you wanted to add the package as a prospective package but forgot the Pkg-Description field in the tasks file. If you want to prevent bugs like this just work down this list. BTW, I fixed this actual bug in SVN. Kind regards Andreas. Missing description for package gstar. This package will be ignored completely. Missing description for package xephem. This package will be ignored completely. Warning: Dependency with unknown status: lum (Task chemistry) Missing description for package xpovchem. This package will be ignored completely. Missing description for package mek. This package will be ignored completely. Missing description for package xem. This package will be ignored completely. Missing description for package lum. This package will be ignored completely. -- nullidentd is mentioned explicitely in dependency list Do not keep a record of virtual package ident-server which has explicite package dependencies Missing description for package dpt-raidutil. This package will be ignored completely. Missing description for package smartsuite. This package will be ignored completely. Missing description for package gnome2-user-guide. This package will be ignored completely. Missing description for package language-support-en. This package will be ignored completely. Missing description for package sessreg. This package will be ignored completely. Missing description for package xdriinfo. This package will be ignored completely. Missing description for package xkeyboard-config. This package will be ignored completely. Missing description for package xmessage. This package will be ignored completely. Missing description for package nbsmtp. This package will be ignored completely. Missing description for package ipmasqadm. This package will be ignored completely. Missing description for package libsasl2-modules-mysql. This package will be ignored completely. Missing description for package libgnutls12. This package will be ignored completely. Missing description for package libconfigfile-perl. This package will be ignored completely. Missing description for package update. This package will be ignored completely. Missing description for package nvidia-kernel-legacy-2.6.18-4-486. This package will be ignored completely. Missing description for package nvidia-kernel-legacy-2.6.18-4-686. This package will be ignored completely. Missing description for package nvidia-kernel-legacy-2.6.18-4-k7. This package will be ignored completely. Missing description for package fvwm95. This package will be ignored completely. Missing description for package sysv-rc-bootsplash. This package will be ignored completely. Warning: Dependency with unknown status: linux-headers-2.6.24-1-686 (Task common) Missing description for package linux-image-2.6.24-1-686. This package will be ignored completely. Missing description for package linux-headers-2.6.24-1-686. This package will be ignored completely. Missing description for package cupsomatic-ppd. This package will be ignored completely. Missing description for package gnome-mag (= 1:0.14.10). This package will be ignored completely. Missing description for package x-window-manager. This package will be ignored completely. Missing description for package kpaint. This package will be ignored completely. Missing description for package kmidi. This package will be ignored completely. Missing description for package kpm. This package will be ignored completely. Missing description for package koffice-i18n-se. This package will be ignored completely. Warning: Dependency with unknown status: kschoolmenu (Task desktop-kde) Missing description for package kschoolmenu. This package will be ignored completely. Missing description for package potoxx. This package will be ignored completely. Missing description for package mtpint. This package will be ignored completely. Missing description for package xfonts-base-transcoded. This package will be ignored completely. Missing description for package openoffice.org-hyphenation. This package will be ignored completely.
Bug#588445: Bug#588445: imagej: fails to start
On Thu, Jul 08, 2010 at 03:25:42PM +0200, François Boulogne wrote: I installed openjdk-6-jre, and it works like a charm here. :) So I'll upload a package which just drops the alternative java2-runtime as Dependency. Greetings from Bordeaux (LSM) Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588632: ITP: freediams -- Pharmaceutical drugs prescriptor
Package: wnpp Severity: wishlist Owner: Andreas Tille andr...@an3as.eu * Package name: freediams Version : 0.4.2 Upstream Author : Eric Maeker eric.mae...@free.fr * URL : http://www.freemedforms.com/ * License : BSD Programming Lang: C++ Description : Pharmaceutical drugs prescriptor FreeDiams prescriber is the result of FreeMedForms prescriber plugins built into a standalone application. FreeDiams is a multi-platform (MacOS, Linux, FreeBSD, Windows), free and open source released under the new BSD license application. It is developed by medical doctors and is intended for use by these same professionals. It can be used alone to prescribe and / or test drug interactions within a prescription. It can be linked to any application thanks to its command line parameters. FreeDiams can use several drugs database. Are currently under development: Drugs database for the Canada and the USA. The french drugs database is available and allows the calculation of drug interactions through data AFSSAPS. The packaging is done in the Debian Med team and available at svn://svn.debian.org/svn/debian-med/trunk/packages/freediams/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588812: lists.debian.org: Please create Debian GIS mailing list
Package: lists.debian.org Severity: wishlist Hi listmasters, after some discussion on the pkg-grass mailing lists[1] which are currently used to do general discussions and not only issues about packaging GRASS we came up with the conclusion that it is better to have a dedicated mailing list for Debian GIS. The fact that metapackages of a Debian GIS Blend were just accepted by ftpmaster lets us think there now is a good moment to do so. Here is some description of the scope: The goal of the Debian GIS project is improving Debian to make it the best distribution for professional Geographical Information Systems, support of GPS devices and providing various OpenStreetMap tools to make Debian the distribution of choice for mappers. Home: http://wiki.debian.org/DebianGis Kind regards and thanks for maintaining lists.debian.org Andreas. [1] http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2010-July/007756.html -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-xenU (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588812: [DebianGIS] Bug#588812: lists.debian.org: Please create Debian GIS mailing list
On Mon, Jul 12, 2010 at 08:15:10AM -0700, Hamish wrote: Yo!! more than 29 minutes between publicly posting a request- for-comments (in a CC) and declaring a motion passed and acting on it, please! Not cool. Sorry, if I stepped on anybodys shoes (and yes, it is actually not so cool here (32°C in my office :-(). I had some private mail exchange with David at the weekend which leaded me to a probably quicker action than needed. Francesco may have more to say re. the associated -dev notification list. I suggest to wait for his input. Yes. KInd regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588812: [DebianGIS-dev] Debian GIS metapackages available [Was: debian-gis_0.0.1_i386.changes ACCEPTED]
Hi Francesco, On Tue, Jul 13, 2010 at 03:40:53PM +0200, Francesco P. Lovergine wrote: I have not specific preferences about lists, I simply would note that pkg-grass-general/devel were born at the time to manage a low traffic packaging oriented list and listmasters had the opinion that alioth lists were appropriate for that. I hope that listmasters will agree that this is not the case any more. That said, I would also note that current -general list is closed to subscribers, while debian-gis would be open to the world (as generally done for all listmasters lists), with obvious consequence for subscribers about spamming... The pros and cons are heavily discussed in the past and I do not think it makes sense to repeat this discussion. I personally get about one or two mails per month from each mailinlist @l.d.o thanks to the spamfilters the listmasters applied (thanks to the effort of listmasters!) and local SPAM filters. That's IMHO acceptable. I take your mail as somethink like it is fine for me to create the list if you care for it and thus I hope the mailing list can be created soon. Question to listmasters: Is it possible to take over the content of the list archive of pkg-grass-general to debian-gis archive? I guess the different listservers might make this hard and I do not really want to put this on you. But if there would be a reasonable way to do this it would be probably a good idea. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589042: ITP: debichem -- Set of Blends metapackages for DebiChem
Package: wnpp Severity: wishlist Owner: Andreas Tille ti...@debian.org * Package name: debichem Version : 0.0.1 Upstream Author : Michael Banck mba...@debian.org, Andreas Tille ti...@debian.org * URL : Native package * License : GPL Description : Set of Blends metapackages for DebiChem The source package will create a set of metapackages for the different tasks defined by the DebiChem project to support people working with in the field of chemistry finding their stuff easily in the pool of Debian packages. The metapackages should help the DebiChem project to support their users better by simpler installation as well better documentation because the work of the project will be easily displayed by the Blends tools at http://blends.alioth.debian.org/debichem/tasks/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589928: games-thumbnails: Please use screenshots.debian.net service to obtain screenshots
Package: games-thumbnails Severity: wishlist Hi, I would like to suggest that you obtain the screenshots directly from screenshots.debian.net to build the source of this package instead of asking users to send screenshots via mail. I'm really sure that you will be able to find a way to set up a query to the database which is running screenshots.debian.net which also has a simple json interface. The screenshots might be reduced to the needed size afterwards. The advantage of this procedure would be to make the way you provide screenshots for Debian packages uniform and attractive for users. Also please make sure all screenshots gathered by the GoPlay e-mail interface will be propagated to screenshots.debian.net. If you think this wishlist bug makes sense but you might need some help for realisation I'd volunteer to do so. Kind regards Andreas. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-xenU (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584194: tclcl-dev and libctapimkt0-dev: error when trying to install together
Hi Claudia, the naming conflicts with ctapimkt become worse as you see. Both header files /usr/include/config.h in this bug report and /usr/include/ctapi.h in #557495 have naming conflicts. Putting a header file with such a generic name like config.h into a default directory is bad and should be changed. So my advise to solve both issues by creating a subdirectory /usr/include/ctapimkt and move both files to this location. This is one suggestion I made previousely according to #557495 and the reason to follow this suggestion now, after Simon Richter who tried to provide a general ctapi.h has resigned from most of his Debian work, becomes much stronger. So please fix this in your upstream code. Otherwise the library will not make it into the next Debian release and I will ask ftpmaster for removal of this package because it causes other packages to fail. Remark: IMHO also tclcl-dev should not provide a file /usr/include/config.h and I would consider this also as very bad style. Kind regards Andreas. On Wed, Jun 02, 2010 at 08:27:32AM +0200, Ralf Treinen wrote: Package: libctapimkt0-dev,tclcl-dev Version: libctapimkt0-dev/1.0.1-1 Version: tclcl-dev/1.20~RC2-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2010-06-02 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: WARNING: The following packages cannot be authenticated! libc-dev-bin linux-libc-dev libc6-dev libctapimkt0 libctapimkt0-dev tclcl-dev Authentication warning overridden. Can not write log, openpty() failed (/dev/pts not mounted?) Selecting previously deselected package libc-dev-bin. (Reading database ... 12205 files and directories currently installed.) Unpacking libc-dev-bin (from .../libc-dev-bin_2.11.1-2_amd64.deb) ... Selecting previously deselected package linux-libc-dev. Unpacking linux-libc-dev (from .../linux-libc-dev_2.6.32-15_amd64.deb) ... Selecting previously deselected package libc6-dev. Unpacking libc6-dev (from .../libc6-dev_2.11.1-2_amd64.deb) ... Selecting previously deselected package libctapimkt0. Unpacking libctapimkt0 (from .../libctapimkt0_1.0.1-1_amd64.deb) ... Selecting previously deselected package libctapimkt0-dev. Unpacking libctapimkt0-dev (from .../libctapimkt0-dev_1.0.1-1_amd64.deb) ... Selecting previously deselected package tclcl-dev. Unpacking tclcl-dev (from .../tclcl-dev_1.20~RC2-1_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/tclcl-dev_1.20~RC2-1_amd64.deb (--unpack): trying to overwrite '/usr/include/config.h', which is also in package libctapimkt0-dev 0:1.0.1-1 dpkg-deb: subprocess paste killed by signal (Broken pipe) Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/tclcl-dev_1.20~RC2-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/include/config.h This bug is assigned to both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. -Ralf. PS: for more information about the detection of file overwrite errors of this kind see http://edos.debian.net/file-overwrites/. ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-med-packaging -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592725: release.debian.org: Non-free Packages hit by non-functional non-free autobuilders
On Sun, Aug 15, 2010 at 07:13:36PM +0200, Philipp Kern wrote: Most of the non-free Debian Science / Med packages suffer from this in some way. Yes. :-( I've made some efforts to get non-free reactivated and at least for powerpc it should be fixed now. Great. We will try to add more builders on other architectures to the set of non-free building machines, if no unexpected events happen again (like there were the last time we tried). Thanks you for this service! Do you think it makes sense just to wait until phylip/armel and others might be builded? This would enable me doing some other work. Thank you very much for your work on non-free autobuilders Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592306: debian-i18n: Upstream source translation information seems to lack Java support
Hi again, as an additional note there is another form of translations missing from the data you are providing. The Qt way to do the translations which ends up in files progname_lang.qm as the can for instance be found in texmaker /usr/share/texmaker/texmaker_lang.qm are also not covered by the data files you are providing at http://i18n.debian.net/material/data/ I'm a bit curious why I did not got any response from Nicolas who was formerly wuite quick in responding? Any information (preferably in private) about reasons would be great to let me estimate a time frame for tackling the reported problem. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592244: libvcl.so existing in both packages
On Sun, Aug 22, 2010 at 09:44:29PM +0200, Stig Sandbeck Mathisen wrote: I suggest we add Conflicts: headers for varnish-dev and libvxl1-dev against each other, as I do not like the idea of renaming any of the libraries. There was recently a discussion on debian-de...@l.d.o[1] concerning a similar case (bug #592242): Simply using conflicts is nont policy conform and should be avoided. Please see the reasoning there. Kind regards Andreas. [1] http://lists.debian.org/debian-devel/2010/08/msg00314.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586243: education-desktop-sugar: please remove this package, it's outdated and confuses users
On Sat, Jun 26, 2010 at 01:06:15PM +, Sascha Silbe wrote: Excerpts from Omar Alejandro Silva's message of Thu Jun 17 17:42:26 + 2010: Accessing Sugar from desktop terminals or thinstations is important, please don`t forget it while removing packages. education-desktop-sugar is a pure meta package, so removing it shouldn't affect usage of Sugar with thin clients. What is the problem in having pure metapackages? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586243: education-desktop-sugar: please remove this package, it's outdated and confuses users
On Mon, Jun 28, 2010 at 01:35:56PM +0200, Sascha Silbe wrote: If someone cares about this package enough to maintain it, changing the description (to point out that it's LTSP + Sugar, not Sugar on a desktop) and updating the dependencies should be enough. But without an active maintainer removing the package is the best option and should be done ASAP. Makes sense - thanks for the clarification Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587856: ITP: debian-gis -- Set of Blends metapackages for Debian GIS
Package: wnpp Severity: wishlist Owner: Andreas Tille andr...@an3as.eu * Package name: debian-gis Version : 0.0.1 Upstream Author : Petter Reinholdtsen p...@debian.org, Andreas Tille ti...@debian.org * URL : native package * License : GPL Description : Set of Blends metapackages for Debian GIS The source package will create a set of metapackages for the different tasks defined by the Debian GIS project to support people working with Geographical Information Systems finding their stuff easily in the pool of Debian packages. The metapackages should help the Debian GIS project to support their users better by simpler installation as well better documentation because the work of the project will be easily displayed by the Blends tools at http://blends.alioth.debian.org/gis/tasks/ The packaging of debian-gis is just prepared in the Blends SVN at svn://svn.debian.org/blends/projects/gis/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590471: josm: missing images
Package: josm Version: 0.0.svn3376-1 Severity: minor Hi, when starting Josm and quiting it immediately I get the following error messages on console: $ josm Using /usr/lib/jvm/java-6-openjdk/bin/java to execute josm. Debian-Release: 0.0.svn3376-1 Build-Date: 2010-07-18 15:51:31 Revision: 3376 Is-Local-Build: true Fatal: failed to locate image 'service/fire_hydrant.png'. This is a serious configuration problem. JOSM will stop working. Mappaint style standard icon service/fire_hydrant.png not found. Fatal: failed to locate image 'fixme.png'. This is a serious configuration problem. JOSM will stop working. Mappaint style standard icon fixme.png not found. Fatal: failed to locate image 'fixme.png'. This is a serious configuration problem. JOSM will stop working. Mappaint style standard icon fixme.png not found. Kind regards and thanks for maintaining Josm Andreas. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-xenU (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590785: maxima: Please enable alternative pdf-viewer / postscript-viewer
Package: maxima Severity: minor Hi, maxima recommends gv explicitely as pdf-viewer or postscript-viewer. Please use pdf-viewer | gvor postscript-viewer | gv depending of what type of documents will be really viewed. The rationale is that people who install maxima will currently be forced to install gv even if they do not want to. For instance if you install the education-mathematics package of Debian Edu which in principle prefers okular you can not avoid installing gv without extra effort and users become confused by more pdf-viewers / postscript-viewers than needed. Kind regards Andreas. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-xenU (SMP w/1 CPU core) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
