Bug#1073938: ITP: libgeo-libproj-ffi-perl -- Foreign function interface to PROJ coordinate transformation software
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: libgeo-libproj-ffi-perl Version : 1.00 Upstream Contact: Arne Johannessen * URL : * License : Perl or Artistic 2.0 Programming Lang: Perl Description : Foreign function interface to PROJ coordinate transformation software Geo::LibProj::FFI is a foreign function interface to the PROJ coordinate transformation / projection library. Please see the PROJ library's C function reference for further documentation. . Geo::LibProj::FFI offers a large portion of the most commonly used PROJ functions, but more could be added later. . This module was originally written for PROJ version 8. It works with PROJ versions as old as 6.2.0, and up to and including the most recent version. It obsoletes the now deprecated Geo::Proj4 XS module which cannot be used with any recent version of the PROJ library.
Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libmozilla-ca-perl Version : 20230821-1 Upstream Contact: Gisle Aas * URL : https://github.com/libwww-perl/Mozilla-CA * License : MPL-2.0 Programming Lang: Perl Description : Mozilla's CA cert bundle in PEM format Mozilla::CA provides a copy of Mozilla's bundle of Certificate Authority certificates in a form that can be consumed by modules and libraries based on OpenSSL. The module provide a single function: SSL_ca_file() Returns the absolute path to the Mozilla's CA cert bundle PEM file.
Bug#732531: ITP: pktools -- A collection of programs to process geo raster images
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine * Package name: pktools Version : 2.4.3 Upstream Author : Pieter Kempeneers * URL : http://www.nongnu.org/pktools/html/index.html * License : GPL3 Programming Lang: C++ Description : A collection of programs to process geo raster images pktools is a collection of programs written in C++ to perform operations, mostly on raster images. It heavily relies on the Geospatial Data Abstraction Library GDAL and OGR. The programs are similar to the gdal tools (gdalinfo, gdal_translate, gdal_merge,...) and some of the functionalities provided in pktools already exist in the gdal tools. The reason for implementing pktools is a combination of personal preference and additional functionality. All utilities in pktools use command line options and have a built in help. A list of tools available: pkascii2img program to create raster image based on ascii file pkascii2ogr program to create vector points or polygons from text file pkclassify_nn classify raster image using Artificial Neural Network pkclassify_svm classify raster image using Support Vector Machine pkcreatect program to create and import colour table to GTiff image pkcrop perform raster data operations on image such as crop, extract and stack bands pkdiff program to compare two raster image files pkdsm2shadow program to calculate sun shadow based on digital surface model and sun angles pkdumpimg program to dump image content to ascii or std out pkdumpogr dump ogr file to text file or standard output pkeditogr program to edit (rename fields) ogr fil pkegcs Utility for raster files in European Grid Coordinate System pkenhance program to enhance raster images pkextract extract pixel values from raster image from a (vector or raster) sample pkfillnodata program to fill holes in raster image pkfilterascii program to filter data in ASCII file (spectral respons function, dwt) pkfilter program to filter raster images pkfs_nn feature selection for nn classifier pkfs_svm feature selection for svm classifier pkgetmask program to create mask image based on values in input raster image pkinfo program to retrieve information from raster images pklas2img program to create (e.g., DEM) raster image from las files pkmosaic program to create mosaic geo-referenced images pkndvi program to calculate vegetation index image pkopt_svm program to optimize parameters for SVM classification pkpolygonize program to make vector file from raster image pkreclass program to replace pixel values in raster image pkregression_nn regression with artificial neural network (multi-layer perceptron) pksetmask program to apply mask image (set invalid values) to raster image pksieve program to sieve filter raster image pkstatascii pkstatogr program to calculate basic statistics from vector file -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218135314.18625.2476.report...@blegrez.ba.issia.cnr.it
Bug#551631: ITP: ossim -- The OSSIM library
Package: wnpp Severity: wishlist Owner: Debian GIS Project * Package name: ossim Version : 1.7.21 Upstream Author : Garrett Potts et al. * URL : http://www.ossim.org/OSSIM/OSSIM_Home.html * License : LGPL Programming Lang: C++ Description : The OSSIM library Open Source Software Image Map (OSSIM) is a high performance engine for remote sensing, image processing, geographical information systems and photogrammetry. It has been actively developed since 1996. . Designed as a series of high performance software libraries, it is written in C++ employing the latest techniques in object-oriented software design. . The library provides advanced remote sensing, image processing, and geo-spatial functionality. A quick summary of OSSIM functionality includes ortho-rectification, precision terrain correction, rigorous sensor models, very large mosaics, and cross sensor fusions, a wide range of map projections anddatums, and a large range of commercial and government data formats. The architecture of the library supports parallel processing with mpi, a dynamic plugin architecture, and dynamically connectable objects allowing rapid prototyping of custom image processing chains. This package include the core OSSIM library and the basic command-line tools. Other related package (such as Ossim Planet or Imagelinker) will come as successive packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550218: ITP: python-liblas -- A Python module to use the ASPRS LiDAR data translation library
Package: wnpp Severity: wishlist Owner: Debian GIS Project * Package name: python-liblas Version : 1.2.1 Upstream Author : Howard Butler * URL : http://pypi.python.org/pypi/libLAS * License : BSD Programming Lang: Python Description : A Python module to use the ASPRS LiDAR data translation library This is the python binding for the libLAS library. LibLAS is a C/C++ library for reading and writing ASPRS LAS versions 1.0, 1.1 and 1.2 data. The LAS format is a sequential binary format used to store data from sensors and as intermediate processing storage by some LiDAR-related applications. LiDAR (Light Detection and Ranging) is an optical remote sensing technology that measures properties of scattered light to find range and/or other information of a distant target. The prevalent method to determine distance to an object or surface is to use laser pulses. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548720: ITP: libkml -- The C++ library for supporting OGC KML 2.2 standard
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine * Package name: libkml Version : 1.0.1 Upstream Author : Google Inc. * URL : http://code.google.com/p/libkml/ * License : BSD Programming Lang: C++, Python and Java Description : The C++ library for supporting OGC KML 2.2 standard This is a Google's library for use with applications that want to parse, generate and operate on KML. It is an implementation of the OGC KML 2.2 standard. It is written in C++ and bindings are available via SWIG to Java and Python. The library depends on boost 1.34. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#536882: ITP: ncview -- A X11 visual browser for NetCDF format files
Package: wnpp Severity: wishlist Owner: Debian GIS Project * Package name: ncview Version : 1.93g Upstream Author : David W. Pierce * URL : http://meteora.ucsd.edu/~pierce/ncview_home_page.html * License : GPL Programming Lang: C Description : A X11 visual browser for NetCDF format files You would use ncview to get a quick and easy, push-button look at your NetCDF files. You can view simple movies of the data, view along various dimensions, take a look at the actual data values, change color maps, invert the data and other simple visual operations. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532415: ITP: liblas -- ASPRS LiDAR data translation toolset
Package: wnpp Severity: wishlist Owner: Debian GIS Project * Package name: liblas Version : 1.2.1 Upstream Author : Howard Butler et al * URL : http://liblas.org/ * License : BSD Programming Lang: C++ Description : ASPRS LiDAR data translation toolset libLAS is a C/C++ library and toolset for reading and writing ASPRS LAS versions 1.0, 1.1 and 1.2 data. The LAS format is a sequential binary format used to store data from sensors and as intermediate processing storage by some LiDAR-related applications. libLAS has C, C++, .NET, and Python APIs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530845: ITP: spatialindex -- A general framework to manage spatial indexes
Package: wnpp Severity: wishlist Owner: Debian GIS Project * Package name: spatialindex Version : 1.3.2 Upstream Author : Marios Hadjieleftheriou * URL : http://trac.gispython.org/spatialindex * License : LGPL 2.1+ Programming Lang: C++ Description : A general framework to manage spatial indexes Spatialindex is a C++ library that provides a framework for developing spatial indices. Currently it defines generic interfaces, provides simple main memory and disk based storage managers and a robust implementation of an R*-tree, an MVR-tree and a TPR-tree. The purpose of this library is to provide: 1. An extensible framework that will support robust spatial indexing methods. 2. Support for sophisticated spatial queries. Range, point location, nearest neighbor and k-nearest neighbor as well as parametric queries (defined by spatial constraints) should be easy to deploy and run. 3. Easy to use interfaces for inserting, deleting and updating information. 4. Wide variety of customization capabilities. Basic index and storage characteristics like the page size, node capacity, minimum fan-out, splitting algorithm, etc. should be easy to customize. 5. Index persistence. Internal memory and external memory structures should be supported. Clustered and non-clustered indices should be easy to be persisted. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521182: ITP: dans-gdal-scripts -- GINA contributed GDAL tools
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine * Package name: dans-gdal-scripts Version : 0.14 Upstream Author : Dan Stahlke * URL : http://www.gina.alaska.edu/projects/gina-tools * License : BSD Programming Lang: C++ Description : GINA contributed GDAL tools Dan Stahlke's GDAL contributed tools are a collection of useful tools to perform common geo raster operations. The included tools are: gdal_contrast_stretch, gdal_dem2rgb, gdal_get_projected_bounds, gdal_landsat_pansharpi, gdal_list_corners, gdal_merge_simple, gdal_merge_vrt gdal_raw2geotiff, gdal_trace_outline, gdal_wkt_to_mask. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#456659: ITP: tk-tile -- A themed widget set provider library for Tk
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine <[EMAIL PROTECTED]> * Package name: tk-tile Version : 0.7.8 Upstream Author : Joe English and other parties. * URL : http://tktable.sourceforge.net/ * License : BSD Programming Lang: C, Tcl Description : A themed widget set provider library for Tk The Tile widget set is an experimental reimplementation of some of the standard Tk widgets. The main features are: * "Revitalized" look and feel under X11 * Appearance controlled by a theme engine, providing greater flexibility for custom widgets * New widgets, including notebook, progressbar, combobox, separator, and sizegrip. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418184: ITP: geotiff -- the GeoTIFF library
Package: wnpp Severity: wishlist Owner: Debian GIS Project * Package name: geotiff Version : 1.2.3 Upstream Author : Frank Warmerdam et al. <[EMAIL PROTECTED]> * URL : http://geotiff.maptools.org/ * License : MIT/X like Programming Lang: C Description : the GeoTIFF library This C library supports TIFF 6.0 based interchange format for georeferenced raster imagery. The GeoTIFF standard has been developed for reading, and writing geographic meta-information tags on top of TIFF raster. Copyright notes: All the source code in this toolkit are either in the public domain, or under an X style license. In any event it is all considered to be free to use for any purpose (including commercial software). No credit is required though some of the code requires that the specific source code modules retain their existing copyright statements. The CSV files, and other tables derived from the EPSG coordinate system database are also free to use. In particular, no part of this code is "copyleft", nor does it imply any requirement for users to disclose this or their own source code. All components not carrying their own copyright message, but distributed with libgeotiff should be considered to be under the same license as Niles' code. - Code by Frank Warmerdam has this copyright notice (directly copied from X Consortium licence): * Copyright (c) 1999, Frank Warmerdam * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the "Software"), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included * in all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER * DEALINGS IN THE SOFTWARE. --- Code by Niles Ritter is under this licence: *Written By: Niles D. Ritter. * * copyright (c) 1995 Niles D. Ritter * * Permission granted to use this software, so long as this copyright * notice accompanies any products derived therefrom. --- The EPSG Tables (from which the CSV files, and .inc files are derived) carried this statement on use of the data (from the EPSG web site at url http://www.epsg.org/): Use of the Data 1. All data pertinent to a specific coordinate reference system must be copied without modification and all related pages/records must be included; 2. All components of this data set pertinent to any given coordinate reference system must be distributed together (complete distribution of all components of the data set is preferred, but the OGP recognises the need for a more limited distribution); 3. The data may not be distributed for profit by any third party; and 4. The original source [OGP] must be acknowledged. The user assumes the entire risk as to the accuracy and the use of this data. The data may be copied and distributed subject to the following conditions: INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. With regard to (3) above, the data may be included within proprietary applications distributed on a commercial basis when the commerciality is based on application functionality and not on a value ascribed to the freely-distributed EPSG dataset. These conditions are currently under review. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413842: ITP: ogdi -- A library which implements an API for OGDI, a network-enabled protocol to access raster and vector GIS data respositories
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine <[EMAIL PROTECTED]> * Package name: ogdi Version : 3.1.5 Upstream Author : Frank Warmerdam et al * URL : http://ogdi.sourceforge.net/ * License : BSD-like Programming Lang: C Description : A library which implements an API for OGDI, a network-enabled protocol to access raster and vector GIS data respositories OGDI is the Open Geographic Datastore Interface. OGDI is an application programming interface (API) that uses a standardized access methods to work in conjunction with GIS software packages (the application) and various geospatial data products. OGDI uses a client/server architecture to facilitate the dissemination of geospatial data products over any TCP/IP network, and a driver-oriented approach to facilitate access to several geospatial data products/formats. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] list of valid documents for KSPs
On Thu, Jun 01, 2006 at 08:17:28AM -0400, Theodore Tso wrote: > If absolute trust is the only thing you will accept, then you might as > well withdraw from Debian project, and go hide in a hole with some > paranoiod survivalists in Montana. We can't have absolute trust; it > is impossible. And you seem to be the one demanding it, and if you > can't have it, it's "off with their signatures", or "off with their > key on the keyring"! > Absolutely agree. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
On Sat, Mar 11, 2006 at 04:52:04AM -1200, Gürkan Sengün wrote: > no manpages are not going to be renamed. but should be split of > from manpages if they are linux specific to a package called linux-manpages. > > check the package that's in new queue now how it's done: > http://io.debian.net/~tar/debian/freebsd-manpages/ Wouldn't manpages-freebsd more homogeneous with other manpages-* packages? Also, should we suppose that a netbsd or openbsd section exist too? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
On Sat, Mar 11, 2006 at 04:52:04AM -1200, Gürkan Sengün wrote:
> >Wouldn't this package conflict with the 'manpages' package (which provides
> >them for GNU/Linux) and with the manpages provided by other (core)
> >packages?
> >Or are all manpages going to be renamed so that there is no filename
> >conflict
> >under /usr/share/man/man{2,4}?
>
> no manpages are not going to be renamed. but should be split of
> from manpages if they are linux specific to a package called linux-manpages.
>
> check the package that's in new queue now how it's done:
> http://io.debian.net/~tar/debian/freebsd-manpages/
>
I would simply add a specific man section for those kind of pages.
See for instance manpages-posix, which add a 'p' suffix to the section
number. A 'b' section would be probably suitable. User could easily
select their own section of interest.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348508: ITP: autodir -- Creates home, group directories for LDAP/NIS/SQL/local Unix accounts transparently
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine <[EMAIL PROTECTED]> * Package name: autodir Version : 0.99.0 Upstream Author : Venkata Ramana Enaganti <[EMAIL PROTECTED]> * URL : http://www.intraperson.com/autodir/ * License : Creative Commons Attribution License 2.0 Description : Creates home, group directories for LDAP/NIS/SQL/local Unix accounts transparently For license: http://creativecommons.org/licenses/by/2.0/legalcode (non-free) A modular and threaded tool to create and/or mounting and managing automagically and transparently user/group home directories, on demand. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Co-maintainers sought
On Sat, Dec 10, 2005 at 09:09:48AM +, Andrew M.A. Cater wrote: > On Sat, Dec 10, 2005 at 10:01:03AM +0100, Francesco Paolo Lovergine wrote: > > On Sat, Dec 10, 2005 at 01:42:25AM +0100, Thomas Hood wrote: > > > I seek co-maintainers for: > > > > > > mwavem > > > thinkpad, tpctl > > > resolvconf > > > > > > > I got a couple of thinkpads, so i could be a good candidate for > > thinkpad related things if you agree. > > > Will help as well if feasible. [Running unstable on an R50e :) ] > X31 and T43p, and some friends with X40 and A series :-P -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Co-maintainers sought
On Sat, Dec 10, 2005 at 01:42:25AM +0100, Thomas Hood wrote: > I seek co-maintainers for: > > mwavem > thinkpad, tpctl > resolvconf > I got a couple of thinkpads, so i could be a good candidate for thinkpad related things if you agree. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get wants to remove hotplug?
On Mon, Oct 10, 2005 at 11:54:11AM -0700, Daniel Burrows wrote: > Hm, doesn't just manually loading mousedev (and putting it in > /etc/modules) get things working again? > Mousedev, evdev and usbmouse here, to have a working setup for X with a synaptics touchpad and an usb mouse. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330174: ITP: netgo -- KDE tool to interactively manage network settings using different custom profiles
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine <[EMAIL PROTECTED]> * Package name: netgo Version : 0.5 Upstream Author : Per Johansson * URL : http://netgo.hjolug.org/ * License : GPL Description : KDE tool to interactively manage network settings using different custom profiles netGo is a distribution-independent networking tool (written in Qt) for changing network settings quickly and easily. It is intended for laptop owners, who often need to change network settings when relocating. It allows you to create profiles that contain the network settings such as the IP, netmask, gateway, name servers and wireless options. After creating a profile it can be executed with a single click. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#319849: Security fix in just released 1.3.0rc2?
On Thu, Aug 18, 2005 at 08:57:27AM +0200, Vincent Bernat wrote: > OoO En cette matinée pluvieuse du lundi 25 juillet 2005, vers 10:42, > "Francesco P. Lovergine" <[EMAIL PROTECTED]> disait: > > > I pointed both bugs at the very start of july (or end of june?) > > to both stable and testing secteams and sent at least 3 mails about the > > topic > > with patches and analysis for sarge, sid and woody. > > When secteam will judge it useful, they'll do that. > > Last time, I did wait months for that, for yardradius package. > > If you know something useful to accellerate the process, i'd like to > > know... > > Shouldn't this bug be tagged security ? Moreover, since it is marked > as closed in the BTS, will it be tracked correctly in the future ? Being now enabled versioning in BTS, yes. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 12:08:00PM +0200, Francesco P. Lovergine wrote: > On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote: > > my congratulation to the team too. However I was not as fortunate as the > > Sean. > > > > Me too, at least on this machine I had to explicitly install > xserver-xorg to complete the move. BTW, I see the rendering of some ttf > fonts looks not so good. For instance I used happily this resource: > > XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15 > > and the visual quality of that font is now less good. > Ok I can confirm that apt-get dist-upgrade does not remove xserver-xfree86 and install xserver-xorg. I know that aptitude is the way to go, but currently its ask for removing a good deal of more packages. If interested I could replicate on a third box and follup a verbose report on BTS. I'm not completely pesuaded it is not a transient issue, anyway... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Drop the minor release number
On Fri, Jul 08, 2005 at 05:05:09PM +0200, Eduard Bloch wrote: > > Then we would have > > Debian 4.0 for etch, 4.1 for etch stable release 1, 4.2 for etch stable > release 2, 4.2a for etch stable release 2 with a minor CD mastering fix > (for example), etc.pp. > > Does the release team agree with this change or do we need another > consensus (or even a GR)? > That seems reasonable to me too. Anyway I yet think deciding names and version numbers is a RMs' privilege. Let leave them this nice little gift for the efforts they put in their task. We can suggest possible schema, but please avoid GR proposals for that. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The story of speex/vorbis-tools, or how not to be disservicing to our users
On Sun, Jun 05, 2005 at 03:08:48PM -0400, Roberto C. Sanchez wrote: > Since not everyone subscribes to d-d, is there a n easy way to do this? > Would a change in a library that is officially depended on by more than > X packages qualify to be sent out via d-d-a? Or does there is exist > some alias that a library maintainer could a mail to? For example, if I > maintain a library with a source package name of foo and I could send a > message to [EMAIL PROTECTED] and the system could figure > out, based on the maintainer info kept for each package, a list of email > addresses, that would be very nice. That way, by sending one message, > the maintainers of all dependent packages ar notified. This would be > especially good for packages which have many dependents. > You can easily find rdepends for your packages. Sending mass mails to communicate with their maintainers is easy as well. I did that sometimes for libraries I maintain, whenever needed. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Leadership, collaboration and canoncial
On Sun, Jun 05, 2005 at 10:03:35PM +0300, Sami Haahtinen wrote: > Personally i feel that Debian Developers should put their jealousy > aside, burry the hatchet and start collaborating with the other > developers out there, not just ubuntu. Besides, you have given your work > out to the public for anyone to use, anyone to modify, anyone to create > derivates from. Why not try and benefit from that symbiosis. Agree, and also possibly work more and flame less. I found a good deal of traffic on this list in the last years^Wperiod not too far from trolling, for contents and usefulness. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [frankie@debian.org: Status of kernel-patches in sarge]
On Mon, May 30, 2005 at 12:19:11PM +0200, Adrian Bunk wrote: > > I'd expect maintainers drop patches which are orphaned by the upstream > > or whose maintainance would be a problem... > > The number of patches that do not apply shown in the initial message of > this thread shows that your expectation is wrong. > ... well, of course after pointing the issue for them :-) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [frankie@debian.org: Status of kernel-patches in sarge]
On Sun, May 22, 2005 at 12:35:59AM +0200, Adrian Bunk wrote: > On Sat, May 21, 2005 at 10:04:02AM +0200, Francesco Paolo Lovergine wrote: > > > The check shown below is almost complete (but for a couple of 2.2 patches > > and per-arch patches). > > I'm asking if mass bug report filing is opportune at this stage. > > IMHO patches which cannot be applied to debian kernel-sources are almost > > unuseful and should be removed from sarge... > >... > > I'd even ask whether all these patches are _really_ required for sarge. > Eh eh, maybe that could be ask for quite a lot of packages around in sarge :-) > Each of the patches might be broken by a security update for the > kernel and each of them requires security support. > I'd expect maintainers drop patches which are orphaned by the upstream or whose maintainance would be a problem... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [frankie@debian.org: Status of kernel-patches in sarge]
On Sun, May 22, 2005 at 12:40:26AM -0700, Steve Langasek wrote:
> On Sat, May 21, 2005 at 10:04:02AM +0200, Francesco Paolo Lovergine wrote:
> > The check shown below is almost complete (but for a couple of 2.2 patches
> > and per-arch patches).
> > I'm asking if mass bug report filing is opportune at this stage.
> > IMHO patches which cannot be applied to debian kernel-sources are almost
> > unuseful and should be removed from sarge...
>
> I think this is a reasonable thing to do, and the sooner, the better. I
> would suggest filing the bugs as grave ("package is unusable or mostly so").
> If a maintainer disagrees and believes the patch is still useful in sarge,
> he can downgrade (hopefully with an explanation, so we know how to tell in
> the future that the package is still fulfilling its purpose). Any of these
> patches whose maintainers don't speak up for them can then be pulled before
> we release.
>
Yes, this appears reasonable to me.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[frankie@debian.org: Status of kernel-patches in sarge]
The check shown below is almost complete (but for a couple of 2.2 patches and per-arch patches). I'm asking if mass bug report filing is opportune at this stage. IMHO patches which cannot be applied to debian kernel-sources are almost unuseful and should be removed from sarge... - Forwarded message from Francesco Paolo Lovergine <[EMAIL PROTECTED]> - Old-Return-Path: <[EMAIL PROTECTED]> From: Francesco Paolo Lovergine <[EMAIL PROTECTED]> To: debian-kernel@lists.debian.org Subject: Status of kernel-patches in sarge Mail-Followup-To: debian-kernel@lists.debian.org I'm performing an ongoing activity to check the applicability of current kernel-patches against sarge kernel-sources for 2.4.27 and 2.6.8. An almost complete summary is available at http://people.debian.org/~frankie/kernel-patches-checks.txt As you can see, there are a few patches which cannot be used with neither 2.4.27 nor 2.6.8. Marked patches should be simply RC bugged and hinted for remove if not aligned properly. I would also point that too often patch names differes from their kernel-patch names, without justification. I'm working on a little script to do this kind of light check automatically, too. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#308533: ITP: gstat -- A program for multivariable geostatistical modelling, prediction and simulation
On Tue, May 10, 2005 at 08:55:28PM +, Dirk Eddelbuettel wrote: > > Howdy, > > Francesco Paolo Lovergine debian.org> writes: > > Package: wnpp > > Severity: wishlist > > Owner: "Francesco P. Lovergine" debian.org> > > > > * Package name: gstat > > Version : 2.4.4 > > Upstream Author : Edzer J. Pebesma geog.uu.nl> et al. > > * URL : http://www.gstat.org/ > > * License : GPL > > Description : A program for multivariable geostatistical modelling, > prediction and simulation > > > > Gstat is an open source (GPL) computer code for multivariable > > geostatistical modelling, prediction and simulation, and has been around > > from 1997. In the original form, gstat is a stand-alone executable, > > interfaced to various GIS (including GRASS 6). > > As of 2003, the gstat functionaly is also available as an S extension, > > either as R package or S-Plus library. > > Do you intend to package this as r-cran-gstat, in-line with the numerous other > R packages based on CRAN sources? > Ah, nice point. Yes the package set is not yet ready now, I'd like packaging all needed bindings, so thank you for your suggestion... > I'm just asking as gstat is also part of CRAN, e.g. can be found on > http://cran.r-project.org/src/contrib/ and its mirrros. We have a > never-quite-finalized Debian R Policy draft that several of us adhere > to, and that we plan to expand -- i.e. we're working on getting all of > CRAN auto-built (and apt-get'able, though not necessarily inside Debian > as adding 500+ packages may be madness). > > Feel free to follow-up off-line if you have questions. > -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308533: ITP: gstat -- A program for multivariable geostatistical modelling, prediction and simulation
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" <[EMAIL PROTECTED]> * Package name: gstat Version : 2.4.4 Upstream Author : Edzer J. Pebesma <[EMAIL PROTECTED]> et al. * URL : http://www.gstat.org/ * License : GPL Description : A program for multivariable geostatistical modelling, prediction and simulation Gstat is an open source (GPL) computer code for multivariable geostatistical modelling, prediction and simulation, and has been around from 1997. In the original form, gstat is a stand-alone executable, interfaced to various GIS (including GRASS 6). As of 2003, the gstat functionaly is also available as an S extension, either as R package or S-Plus library. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PHP/WebApp policy/mailing list
On Sun, May 01, 2005 at 11:24:53PM +1000, Pascal Hakim wrote: > > I think a suitable section in debian policy would be appropriate. And > > mere technical discussions about the policy contents are also > > appropriate in d-policy. All other technical discussions should go > > in an alioth list. My suggestion of an alioth list is due to > > Do the policy discussion on the new list, and make a new debian web apps > sub policy, in the same way we have perl and emacs policies. Leave the > main debian policy out of it, until we have something that works, and is > used by most web apps. This is how the system is meant to work. > That's what I said in an involute manner :-) > > current discouraging (and long delays) for a new proper list on > > lists.debian.org. If interested people would think a l.d.o list > > is better, that could also be nice. > > Once you've got me convinced the list is a good idea, it usually doesn't > take too long to create it. > I think the list would be useful in the initial period. Once a decent policy would be ready, the true job will move on common tools development, while general policy discussions would be naturally hosted in d-policy, eventually. So, I'm not sure such kind of list will be useful for a long period. Of course, we could discuss about the meaning of 'long' in Debian metrics... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PHP/WebApp policy/mailing list
On Sun, May 01, 2005 at 11:56:47AM +0200, Alexis Sukrieh wrote: > Pascal Hakim wrote: > >Speaking as a listmaster, I believe that a list that would be used to > >provide people with a place to discuss the packaging of web-apps, as > >well as standard things associated with it is a great idea. It's better > >than debian-apache (after all, there's other web servers out there), and > >it's better than creating a debian-php list. We want this to be used by > >all web-apps, whether they be in php, python, perl or whatever the > >flavour of the week is. > > Ok. > It seems that everyone here agrees on the fact that such a list would be > helpful and could enhance the way webapp packages are made. > > I find Frankie's suggestion interesting and would vote for an Alioth > account for hosting the mailinglist. Moreover, if we want to start > writing a "Debian Webapp Policy Manual", alioth is a good idea too, I > suppose. > > First of all we have to find a correct name for such a project. I was > thinking at something generic like "webapp-policy" but other ideas are > welcome. > I think a suitable section in debian policy would be appropriate. And mere technical discussions about the policy contents are also appropriate in d-policy. All other technical discussions should go in an alioth list. My suggestion of an alioth list is due to current discouraging (and long delays) for a new proper list on lists.debian.org. If interested people would think a l.d.o list is better, that could also be nice. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PHP/WebApp policy/mailing list
On Sun, May 01, 2005 at 07:28:48PM +1200, Martin Langhoff wrote: > I've lurked for a while in [EMAIL PROTECTED] hoping that that would > be the right place for such discussions, and, when they happen, the > subscribers are usually pretty clued-in and interested. Perhaps it is > the natural place to discuss web-apps? At least until traffic is > sufficient that the Debian Apache team kicks us out. It ensures we are > 'in touch' with the httpd maintainers, instead of being in an echo > chamber. > I would create an alioth list (and project) and point interested people there, also communicating that on -devel-announce as appropriate... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Mon, Apr 25, 2005 at 04:10:21PM -0700, Steve Langasek wrote: > Ideally, we would have agreement to update all of the following packages to > libmysqlclient12 at the same time: > > courier > cyrus-sasl2 > exim4 > linesrv > pam-mysql > postfix > proftpd ^^^ yet done, and it does not use pam-mysql for auth... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to install ROX applications?
On Sat, Apr 02, 2005 at 06:17:33PM +0100, Tony Houghton wrote: > I was thinking of something like /usr/share/rox-desktop/Apps (I would > probably make a meta-package called rox-desktop anyway, to conveniently > install a nice bundle of applications), but that would mean having to > move the binaries into /usr/bin and modifying the AppRun scripts because > /usr/share is arch-independent. Several ROX developers seem to be rather > against that and it would make packaging a little harder. > > A location within /opt would satisfy both the FHS and the ROX community, > but not Debian I think, because I've never known any other package to > use it. > I removed an Apps dir in the old package for rox-filer which was located in /usr/lib exactly for that reason. An arch-indep dir like /usr/share/rox it's the perfect location for that kind of contents. BTW, you are welcome on the rox ML on alioth for this kind of issues. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Mon, Feb 14, 2005 at 10:47:24PM -0600, John Hasler wrote: > Justin Pryzby writes: > > It occurs to me that help output to stderr is arguably appropriate if an > > invalid option is given > > But '--help' is not an invalid option. > It depends on programs, sometimes the same usage function is used for either --help or invalid options. Not always GNU rules are followed appropriately. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 03:01:26PM +, Mark Brown wrote: > On Sun, Feb 13, 2005 at 01:25:15PM +0100, Steinar H. Gunderson wrote: > > > However, now we've suddenly discovered that _other_ programs get confused by > > this! In particular, if you use an NFSv4-patched mount, it does a > > gethostname() and resolves that, which returns 127.0.0.1, which in turn > > makes > > it happily use that as a client identifier to the remote server. (This > > breaks > > when two or more such clients connect, obviously.) > > This also causes problems for NIS servers, for the same reason - NIS > needs to hand out the IP address of the machine in some circumstances > and 127.0.0.1 is inappropriate. > > Resolving the hostname is a standard method for obtaining an IP address > for the machine and it would be helpful if it could be reverted since I > imagine other programs are also going to run into the same issue. Changing that could also confuse some inner features (e.g.filtering hosts by name) for programs like proftpd. Unfortunately also order is important, I received at leat one report about that, due to changes in /etc/hosts... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291945: eleventh-hour transition for mysql-using packages related to apache
On Sun, Feb 13, 2005 at 12:07:06PM +1100, Paul Hampson wrote: > > So what if we had two editions of libmysqlclient, one of them > > ssl-enabled and the other - as currently - not? That would allow > > using ssl whenever possible. I think that could be done, without > > breaking things. > > That's funny. Didn't we spend all that time since Woody merging > lib-*-ssl back into lib-*? > That was perfecly reasonable at the time of libmysqlclient10, when it was LGPL. Unfortunately the change in the license was not among the possibility considered for the near future... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291945: eleventh-hour transition for mysql-using packages related to apache
On Sat, Feb 12, 2005 at 09:17:44AM -0800, Steve Langasek wrote: > On Sat, Feb 12, 2005 at 09:53:34AM +0100, Francesco Paolo Lovergine wrote: > > > > Nice, so we should check that any linked GPL library directly > > > > (obviuolsy) or > > > > indirectly (with N=1,2,3... levels of indirection) linked against > > > > openssl adds the exception. > > > > No, we should simply not be linking libmysqlclient against OpenSSL. The > > > exemption was needed because there exists software that uses both > > > libmysqlclient and libssl, but making libmysqlclient itself use libssl > > > just > > > because we now have the exemption will cause licensing problems for > > > applications which currently do *not* depend on libssl. > > > That's clear, I meant simply that if program A links libB which links libC > > which links libssl, than both A, libB and libC should add the exception, > > isn't it? That's independently from having A using libssl functions > > directly or not. > > That's true; I'm merely pointing out the importance of not turning > libmysqlclient into libC here. > So what if we had two editions of libmysqlclient, one of them ssl-enabled and the other - as currently - not? That would allow using ssl whenever possible. I think that could be done, without breaking things. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291945: eleventh-hour transition for mysql-using packages related to apache
On Sat, Feb 12, 2005 at 12:39:58AM -0800, Steve Langasek wrote: > > > Nice, so we should check that any linked GPL library directly (obviuolsy) or > > indirectly (with N=1,2,3... levels of indirection) linked against > > openssl adds the exception. > > No, we should simply not be linking libmysqlclient against OpenSSL. The > exemption was needed because there exists software that uses both > libmysqlclient and libssl, but making libmysqlclient itself use libssl just > because we now have the exemption will cause licensing problems for > applications which currently do *not* depend on libssl. > That's clear, I meant simply that if program A links libB which links libC which links libssl, than both A, libB and libC should add the exception, isn't it? That's independently from having A using libssl functions directly or not. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291945: eleventh-hour transition for mysql-using packages related to apache
On Fri, Feb 11, 2005 at 03:30:59PM -0800, Steve Langasek wrote: > On Fri, Feb 11, 2005 at 03:31:44PM +0100, Christian Hammers wrote: > > On 2005-02-11 sean finney wrote: > > > On Fri, Feb 11, 2005 at 10:15:55AM +0100, Francesco P. Lovergine wrote: > > > > FYI: new mysql FLOSS includes OpenSSL license, so many packages could > > > > migrate to current libmysqlclient starting from no starting from now.. > > > > that's great to hear! i'm cc'ing the relevant wishlist bug i have open > > > against mysql-server. christian: any chance of getting an openssl enabled > > > version of the mysql-client and mysql-server packages? > > > Yes, I will re-enable openssl in the next upload. > > Please make sure this does not introduce an openssl dependency to > libmysqlclient itself; just because MySQL AB have granted a license > exception for OpenSSL does not mean everyone who links to libmysqlclient > has done so. > > I know of at least one GPL-without-exception package that is now using > libmysqlclient12 in Debian. Nice, so we should check that any linked GPL library directly (obviuolsy) or indirectly (with N=1,2,3... levels of indirection) linked against openssl adds the exception. This is a great reason to move asap all possible programs to gnutls, indeed. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: eleventh-hour transition for mysql-using packages related to apache
On Wed, Feb 02, 2005 at 09:49:31PM +0100, Andreas Metzler wrote: > > > For what concern proftpd, it does not use libpam-mysql at all, > > so I see no problem for that. > > Hello, > Ehh. As maintainer of a PAM-using application you usually have no > control which PAM modules are used. You just ship the application with > a /etc/pam.d/foo using > > @include common- > > and the *end-user* can (and probably will, if he installs stuff like > libpam-mysql) change these defaults to use modules of his choice. >cu andreas That's clear. I did mean proftpd-mysql does not use PAM to authenticate against mysql, it uses mysql API directly... Of course a PAM module can be used by user, but that's not of interest for licensing compatibility. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who could be able to help SW vendors to support Debian?
On Tue, Feb 01, 2005 at 11:35:41AM -0800, Marc Singer wrote: > I've been under the impression that the only machine-level > incompatibilities are really kernel and driver issues and not issues > with Debian per se. > > Can you be a little more specific? > Currently for instance Matlab 6.5+ cannot be installed without a little hack in the installer, that's due to a known bug (or feature ?) in our sarge libc: it is not executable, like RH ones. Supporting a release involves also those aspects. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: eleventh-hour transition for mysql-using packages related to apache
On Sat, Jan 29, 2005 at 02:34:07PM +0100, Andreas Metzler wrote: > Hello, > These four packages also link against both libpam and libmysqlclient10 > and might experience segfaults when accessing MYSQL over PAM with > libpam-mysql if libpam-mysql switched to libmysqlclient12: > > linesrv-mysql, pure-ftpd-mysql, proftpd-mysql and courier-authmysql > > I am saying /might/ as it is entirely possible that one or more of > these link against libpam without using it. > > (The two mentioned ftp daemons probably cannot switch to -12, as they > link against libssl.) For what concern proftpd, it does not use libpam-mysql at all, so I see no problem for that. I can confirm for proftpd-mysql/libssl issue. Me was one that asked MySQL people to consider libssl for the new FLOSS, without results. At least they included explicitly links to opensource.org and FSF for licenses, else that FLOSS would be also more bad now. Currently, I cannot move to libmysqlclient12. I would see if gnutls can be used instead of libssl, but some modules are not supported upstream in that way (e.g. mod_ldap). G. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#283994: ITP: glastree -- builds live backup trees, with branches for each day
On Fri, Dec 03, 2004 at 03:27:26PM +0100, Enrico Zini wrote: > There were quite many backup programs without the admin::backup tag. > Now admin::backup counts 61 packages: good! > > If someone wants to take care of keeping the admin::backup tag up to > date, please send me a note. hdup? -- Francesco P. Lovergine
Re: Drop testing
On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote: > Gergely Nagy <[EMAIL PROTECTED]> writes: > > >> It may sound a bit radical, but core points have been mentioned in the > >> thread already. I suggest to do it in a more radical way: > >> > >> - unstable lockdown in the freeze > >> - drop Testing and concentrate on work instead of wasting time on > >>synching stuff. This eliminates the need for testing-security. See > >>the last part of the paper for details. > > > > Doing this would result in many users who currently run testing fall > > back to stable + backports or switch to another distro (ubuntu being a > > likely candidate), which in turn, would result in less bugreports and a > > less stable distribution. > > Very few bug reports from testing users are of any value at all. They > usually either report some transient dependency problem that the > maintainer can't fix anyway, or report something that has already been > fixed in the unstable package. The true solution is a multi-release BTS, not dropping testing. And being maintainer/uploader of quite a good number of packages, I can say those cases of testing-only problems is a minority. We have also reports which are (yet now) stable-only, for what I can see. A proper BTS implementation for that could help in tracking things appropriately. -- Francesco P. Lovergine
Re: Drop testing
On Sat, Oct 23, 2004 at 10:44:58PM +0200, Gergely Nagy wrote: > > It may sound a bit radical, but core points have been mentioned in the > > thread already. I suggest to do it in a more radical way: > > > > - unstable lockdown in the freeze > > - drop Testing and concentrate on work instead of wasting time on > >synching stuff. This eliminates the need for testing-security. See > >the last part of the paper for details. > > Doing this would result in many users who currently run testing fall > back to stable + backports or switch to another distro (ubuntu being a > likely candidate), which in turn, would result in less bugreports and a > less stable distribution. I, for one, wouldn't run unstable on my > parents' box, whereas testing proved to be quite reliable there. > Absolutely agree. DON'T drop testig. I'm using testing since ages here on a good deal of boxes with different configurations and used by naive users without big gotchas. It helps me to check problems in -sarge- without using sid on any computers, but for my personal ones. It helps a lot in debugging and testing upgrades from woody. It helps in creating custom distros starting from an archive in a reasonable state. And, about the general 'shape' of testing: are you conscious that testing is _now_ in very better general shape than other 'released' distros? Are you consciuous that _our_ requirements about level of quality is higher than that of many blasonated (also $$$) distros? > Freezing unstable will get you nothing compared to what we have now. > Those who don't care about a release, will not care that way either, > just their complaints will get louder and more frequent. Those who are > willing to do the work neccessary for the release are already trying to. > I agree too. I add also that dropping testing would not help in having up-to-date versions in stable. Simply, we would have a lng freeze in sid, due to the current size of archive (i.e. package per developer) and number of RCs. Versions would be obsolete in any way. > Remember, Debian is a volunteer project, you cannot force people to do > something they do not want to. > > > - about the "filtering updates for frozen" - yes, some additional > >manpower is required but that work must be done. The problems with > >Testing synchronisation are not of pure technical nature, they are > >social problem, and so they should be solved by people and not > >scripts. > > Yes, testing synchronisation is not a purely technical matter. Nor is it > purely social, so the testing scripts, which automatically keep stuff in > sync, are a real help. On top of that, package maintainers coordinating > with each other (the social part) is welcomed too, and should be > encouraged. (And those who break a transition should be kicked in the > ass, so they won't try it again :P) > > I firmly believe that fixing the problems with testing (mainly > testing-security at this point in time) would be MUCH better than > dropping testing and freezing unstable before the next release. > You are my hero :-P -- Francesco P. Lovergine
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 11:54:05AM +0200, Jérôme Marant wrote: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > >> Okay, that's what t-p-u is roughly for, but the fact is that it's > >> quite painful. > > > > Could you elaborate on that? Why is it so painful? > > Probably because you need maintain packages for both unstable and > testing at the same time. Uh? We have pbulder and sbuild for that. What's so painful? -- Francesco P. Lovergine
Proftpd 1.2.10 available in experimental
Subject says all. Interested people can have a look on it and return feedback on BTS. I have no intention to release 1.2.10 in sarge at this time, anyway. -- Francesco P. Lovergine
Re: possible mass bug filing: spamassassin 3
On Sun, Oct 10, 2004 at 10:43:14AM +0900, Clemens Schwaighofer wrote: > > Furthermore, we should all know that Anti-Spam, Anti-Virus is a CPU & > memory hog. It needs tons of memory and fastest cpu ... always. > I'm using now bogofilter and razor, without CPU and memory problems at all. So your always should probably be parsed sometimes. -- Francesco P. Lovergine
Re: Updating scanners and filters in Debian stable (3.1)
On Sun, Oct 10, 2004 at 02:53:58PM +0200, Marc Haber wrote: > On Sun, 3 Oct 2004 12:36:48 +0200, Francesco Paolo Lovergine > <[EMAIL PROTECTED]> wrote: > >Not always. In the past many backports have been built including perfectly > >avoidable new dependencies. The volatile archive should have policy and > >deb tools frozen. So no new debconf, no new ucf and so on. > > In many cases, backporting other tools and libs makes backporting much > easier since a lot of packages use debhelper's latest features. Right, indeed volatile should not do things easy for maintainers, but do the right thing. Too easy backporting the whole dependency set to have something up with minimal work. > And > debhelper has a history of using perl features that are not present in > stable's perl. And no, I won't do a perl backport for new debhelper. > Yep, that's a good reason to not backporting infinity and behind. -- Francesco P. Lovergine
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 03:04:10PM +0200, alphac wrote: > I think hal + dbus-1 + fstab-sync works very well on debian, but the > real missing feature is the possibility for users to mount remote file > systems like cifs and smbfs without having root privileges or having to > suidroot smbmnt, this solution doesn't work very well and it would be > useful to create mount points on demand in the user home directory. > Some environments more err... user-friendly already have this kind of features, like smb4k for KDE. Anywy, I totally dislike tools which hack fstab or other configuration files around, they have the bad habit to (mis)configure things in a way I hate deeply. They are not solutions, but fast and dirty hacks, pure and plain, nothing which could not be done with some ugly scripts and sudo equivalently, as in the old *nix days on non-Solaris systems. A daemon based approach is a more clean solution. -- Francesco P. Lovergine
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 01:23:42PM +0200, Francesco Paolo Lovergine wrote: > On Sat, Oct 09, 2004 at 12:57:46PM +0200, Michael Banck wrote: > > On Sat, Oct 09, 2004 at 02:46:05PM +0200, Bluefuture wrote: > > > Il giorno sab, 09-10-2004 alle 12:23 +0200, Michael Banck ha scritto: > > > > > > > What is updtfstab? > > > I use this on sarge/sid and works very fine: > > > http://ccomb.free.fr/wiki/wakka.php?wiki=UsbMassStorageEnglish > > > > It seems this one just uses udev, not HAL. I hope that we get full > > project-utopia integration for sarge+1 (we've already come a long way). > > > > updtfstab still looks like a good interim solution though. > > In the remote hypothesis I understood the terms of the question :) > I'd prefer a daemon-based approach a la vold, without touching > configuration files around not of competence. > See vold.sf.net, it is the Linux version of a well known tools in > Solaris. > I add also that I like *very much* the possibility of stopping the daemon at any time and mounting by hand devices like true men do, without breaking other things around; or not installing it at all, too. -- Francesco P. Lovergine
Re: pmount vs updfstab
On Sat, Oct 09, 2004 at 12:57:46PM +0200, Michael Banck wrote: > On Sat, Oct 09, 2004 at 02:46:05PM +0200, Bluefuture wrote: > > Il giorno sab, 09-10-2004 alle 12:23 +0200, Michael Banck ha scritto: > > > > > What is updtfstab? > > I use this on sarge/sid and works very fine: > > http://ccomb.free.fr/wiki/wakka.php?wiki=UsbMassStorageEnglish > > It seems this one just uses udev, not HAL. I hope that we get full > project-utopia integration for sarge+1 (we've already come a long way). > > updtfstab still looks like a good interim solution though. In the remote hypothesis I understood the terms of the question :) I'd prefer a daemon-based approach a la vold, without touching configuration files around not of competence. See vold.sf.net, it is the Linux version of a well known tools in Solaris. -- Francesco P. Lovergine
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > Packages like virus checkers seem to be > composed of 2 parts: the app program and the data where the data in > this case are virus sigs and the app is say clamav. And the 'volitile' > part is the virus sigs whereas the app (once it hits stable) shouldnt > change unless it warrents a 'security' update. So, volitile should be > for the data/virus sigs that need updating when new bugs hit the 'net. > No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. -- Francesco P. Lovergine
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 02:28:10AM +0200, Jesus Climent wrote: > On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: > > > > I generally have to resort to backports or unstable when installing > > Debian > > on recent hardware, because we don't update hardware drivers in stable. > > Would the kernel and X be candidates for volatile? > > I dont see any reason why not, if they can be marked as NotAutomatic. > Due to versioned dependencies, that could be impractical for X, which has a long list of reverse depends. I'd like to see in volatile just as much as possible 'autoconsistent' pieces of software (to minimize possibility of subtle breakage). Other things have already their home in backports.org, at admin's risk. If you check d-kernel you we'll also see that any new release of kernel would potentially cause problems to a good deal of users. It's not a thing we could seriously think to support IMHO. Also, little is nice: thinking of having a looong list of (complicated and interdependet) volatile packages would imply looong release cycles. That's exactly the opposite we would gain with v.d.o|n. -- Francesco P. Lovergine
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: > On Friday 08 October 2004 11:51 am, Andreas Barth wrote: > > - volatile is not "just another place" for backports, but should only > > contain changes to stable programs that are necessary to keep them > > functional; > > I generally have to resort to backports or unstable when installing Debian > on recent hardware, because we don't update hardware drivers in stable. > Would the kernel and X be candidates for volatile? > Uhm, if I'm remembering right at potato time we had kernel upgrades, at least 2.2.17 -> 2.2.19. Unfortunately new kernels imply new big security concerns in many cases. Anyway, kernel and X are not typical targets for volatile: we are not proposing new stable releases, but only very localized changes for a few programs which are inerently subject to fast obsolescence (i.e. short-life applications). For those kind of things backports.org is the right answer. -- Francesco P. Lovergine
Re: about volatile.d.o/n
I'll add a few my consideration already discussed in IRC with Andi and others. Feel free to fill the gaps :) On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > Hi all, > > we had some discussion about volatile, and I'm more and more considering to > pick this task up. I think some issues are quite obvious: > > - packages should only go in in cooperation with the maintainers; > > - volatile is not "just another place" for backports, but should only > contain changes to stable programs that are necessary to keep them > functional; > So no new styles of packaging: no dpatch introduction from scratch, for instance. > - Good candidates are clamav (including spin-offs), spamassassin, > chkrootkit; > I'd add IDS like snort. > - It should allow any administrator to "just use" volatile, as they "just > use" security.d.o, and they should be confident that nothing is broken by > that; > In some context volatile would be not useful, so separating the two things is definitively The Good Thing To Do. > - for bugs, the normal debian bug tracking system should be used. > ... adding a volatile tag probably as for experimental? But if nothing would be broken by volatile pkgs, probably BTS is superfluous ;-) > > Some things are not so obvious: > > - security support: There should be security support for volatile. However, > security.d.o is probably not the right place for that, and adding another > task to the security-team is IMHO also not the way to go. So, this needs > to be placed on the burden of the volatile team. > Unfortunately I think so too. > - "releases" of volatile: One could consider to seperate volatile into a > release and a staging area. An advantage would be that system > administrators would only need to update on some times. However, if we > restrict volatile, only upload required changes and don't have more than > 10 packages in it, we don't need that. > > - adding volatile packages to point releases: Though it may be seen as good > idea to add volatile packages at the next point release, this is > currently a no-go. I can see the good reasons for that, and I accept > them. > Indeed, I think we could have a few time post sarge release to buildup the thing. -- Francesco P. Lovergine
Re: Bug#274923: ITP: wnpp -- C++ library for robust numerical and geometric computation
On Tue, Oct 05, 2004 at 06:58:07PM +0200, Joachim Reichel wrote: > > If the names above are still too generic, I think I will use libcore++ as > prefix. Or has anyone else another suggestion? > Why not libexact? > I'm a bit uncertain about potential consequences if the Debian package name > differs too much from the upstream package name. > Programs which would use the library will have to customize. That should be done anyway easy in any decent program. -- Francesco P. Lovergine
Re: Bug#155583: radiusd-freeradius history and future
On Sat, Nov 15, 2003 at 10:36:53AM +, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > Sam Hartman <[EMAIL PROTECTED]> wrote: > >I think dpkg-statoverride is not too bad in this case. I'll talk to > >the nis package maintainer and see if that's acceptable. If not, nis > >could install some flag file. The unix_chkpwd could start with root > >privs, chuck for this flag file with a hard coded path and drop to > >shadow if the flag file does not exist. > > The NIS package is in limbo right now. I'm the maintainer, but > I haven't had time to maintain it. I did send an ITO to this > list, but it appears noone wants to take it. Uh? When? What? Who? I'm surely interested. We use intensively NIS here... -- Francesco P. Lovergine
Re: Mcrypt maintainer.
On Fri, Sep 05, 2003 at 03:53:58PM -0500, Andrés Roldán wrote: > Is the mcrypt maintainer MIA? > > The last mcrypt package was released the last year (November) and > there are newer mcrypt and libmcrypt upstream releases. > Ask [EMAIL PROTECTED] -- Francesco P. Lovergine
Bug#207640: ITP: xoops -- XOOPS is a dynamic oject-oriented web portal system written in PHP
Package: wnpp Version: unavailable; reported 2003-08-28 Severity: wishlist * Package name: xoops Version : 2.0.3 Upstream Author : Kazumi Ono, Goghs Cheng, et al, See [EMAIL PROTECTED] * URL : http://www.xoops.org/ * License : GPL Description : XOOPS is a dynamic oject-oriented web portal system written in PHP XOOPS is a dynamic OO (Object Oriented) based open source portal script written in PHP. XOOPS is the ideal tool for developing small to large dynamic community websites, intra company portals, corporate portals, weblogs and much more. The goals with XOOPS team is to create a Content Management System (CMS) for users and developers that installs out of the box offering unparalleled ease of use, support and management. The XOOPS CMS will be extendable by the use of modules installable through a unified admin interface. The ultimate goal of the XOOPS team is to take the best features of current CMS's and roll them into an Open Source CMS that's easy to use, extendable and unparalleled in the Free/Open Source Community. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux klecker 2.4.21-3-686 #1 Sun Jul 20 16:11:09 EST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Packaging some Redhat admin tools
On Thu, Aug 07, 2003 at 11:15:35AM +0200, Josselin Mouette wrote: > > > > So, I wonder if someone has already built a package from a SRPM package > > ? > > You can easily extract the .tar.gz using alien. > rpm -Uvh estracts in /usr/src/rpm/SOURCES -- Francesco P. Lovergine
Re: About NM and Next Release
On Thu, Aug 07, 2003 at 12:33:08PM +0200, Eduard Bloch wrote: > > What we need is a database with simple mailing list function (similar to > PTS) where willing sponsors for a certain package can subscribe and > sponsorees with much motivation can send diffs for the next version > upgrade. Easy to review and check, easy to build and upload. And easy to > comment and communicate with other sponsors or co-maintainers. > Yep, sponsoring system is currently a bit caothic due to lack of adequate tools. That's one of the few reasonable ideas in this damn long flamewar^Wthread... -- Francesco P. Lovergine
Re: About NM and Next Release
On Thu, Aug 07, 2003 at 09:50:03AM +0200, Goswin von Brederlow wrote: > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > Then he should spend the 10 minutes it takes to implement a "reject" > button on the webpage he can just press to reject someone. > After that rejecting would be a matter of seconds. > The AM has to write down a (reasonable and reasonate) report for rejection, not only press a button on a web page. That is 'more work'... -- Francesco P. Lovergine
Re: About NM and Next Release
On Thu, Aug 07, 2003 at 09:30:35AM +0200, Goswin von Brederlow wrote: > > > > Someone should point NMs to difficulty of entering the development > > mainstream of FreeBSD or becoming maintainer for the kernel... > > IMO it's generally too easy entering in Debian. > > You can get access to the gcc cvs simply by showing your ability to > work on gcc within a few month. The time it takes to get access > depends on the amount and quality of your work (and paying 1 Euro for > some stickers while signing over your copyright to the FSF). Right. The same for me to enter debian. And u can have access to some debian cvs repositories without being a DD at all. The key is 'the amount and quality of your work'. This is relative to the point of view of people who grant accesses. Someone has that low, some other higher. Who is right? None can say. When someone will find a quantitive and universal method to measure that, we should solve all problems. All the rest is gossip and flaming. -- Francesco P. Lovergine
Re: About NM and Next Release
On Wed, Aug 06, 2003 at 05:10:24PM +0200, Eduard Bloch wrote: > Interessting analysis. Many things that hold up the release can only be > solved by active and experienced maintainers since the packages are often > essential. New developers can help maintaining them in cooperation with > main developer and get the experience after some time and reading of the > policy, developers reference, lib packaging guide, etc, but having a > sponsor between them and the upload queue is still better. > Someone should point NMs to difficulty of entering the development mainstream of FreeBSD or becoming maintainer for the kernel... IMO it's generally too easy entering in Debian. -- Francesco P. Lovergine
Experimental: proftpd pre-1.2.9, for brave hearts
Hi guys this is to announce a preview (off sid) for current (cvs) version of proftpd. Testing and comments are welcome. An (incomplete) IPv6 patch is also available. http://people.debian.org/~frankie/debian/sid/experimental/proftpd/ The package will not be uploaded in sid, until a complete IPv6 patch will be available or 1.2.9 will be released. PS: it's intentionally a native pkg. -- Francesco P. Lovergine
Re: Accepted directory-administrator 1.3.5-1 (i386 source)
On Wed, May 21, 2003 at 12:31:14PM -0700, Brian Nelson wrote: > > >* Acknowledge NMU (closes: #174301, #172803, #179036, #177616) Ugh, also this one. Do not use changelog for closing fixed bugs. Do it using BTS directly. -- Francesco P. Lovergine
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 09:40:07PM +0300, Jarno Elonen wrote: > > Additionally, it might be a good idea to provide a shoreter list of authors > in > addition to the detailed one for easier copying to 'standard copyright files' > like 'copying' in Debian. > GNU folks generally use a Credits file for those kind of things. -- Francesco P. Lovergine
Re: Pick a name, any name...
I like maintaining the idea of forge, so my proposal is VULCAN (from Roman mithology). He was the God of volcanic fire and of metal work. He was the son of Hera (and maybe Zeus).(Some say that Hera gave birth to Hephaestus alone because she was angry with Zeus, because Athena was born out of Zeus' head) without the participation of Hera. Vulcan (Hephaestos), the celestial artist, The olympians considered almost everything to be made of natural materials or metal. He made a golden breastplate to Heracles, Achilles' new armour, Agamemnon's Scepter. The brazen-footed bulls, which puffed fire from their mouths. Oenopion's underground house, the Necklace of Harmonia, and the list goes on. -- Francesco P. Lovergine
Re: orbit/evolution/linux2.5 bug #168188
On Tue, Nov 26, 2002 at 07:29:36PM -0500, Stephen Gran wrote: > > > > Jeff > When I do this sort of thing on my local mirror, I usually pretend it's > an NMU - so your package would be 0.5.17-4.1 or something. This > prevents apt from preferring the Debian distributed pakage over yours. > Either that or you can use pinning to give your local repository a > higher preference. > Better something like 0.5.17-4my1 This prevents problems with other official NMUs and updates. -- Francesco P. Lovergine
