Bug#778374: php5 5.6.5 fully breaks Horde packages in Debian jessie
Package: php5-common Version: 5.6.5+dfsg-1 Severity: grave Tags: upstream Dear PHP5 maintainers, the latest migration of php5 to Debian jessie unfortunately broke the complete Horde5 software that is in Debian jessie. The latest php5 upstream branches (5.5 and 5.6) introduced a severe regression as discussed at [1]. I am currently test-building a PHP 5.6.5+dfsg-1.1 with that patch reverted. I will get back to you soon, if that fixes the observed issue. Breaking Horde5 means: no communication via IMAP with an MDA (IMAP server) is possible anymore. light+love, Mike [1] https://bugs.php.net/bug.php?id=68948 -- Package-specific info: Additional PHP 5 information PHP 5 SAPI (php5query -S): cli apache2 PHP 5 Extensions (php5query -M -v): imap (Enabled for cli by maintainer script) imap (Enabled for apache2 by maintainer script) pdo (Enabled for cli by maintainer script) pdo (Enabled for apache2 by maintainer script) opcache (Enabled for cli by maintainer script) opcache (Enabled for apache2 by maintainer script) mysql (Enabled for cli by maintainer script) mysql (Enabled for apache2 by maintainer script) curl (Enabled for cli by maintainer script) curl (Enabled for apache2 by maintainer script) mysqli (Enabled for cli by maintainer script) mysqli (Enabled for apache2 by maintainer script) pdo_sqlite (Enabled for cli by maintainer script) pdo_sqlite (Enabled for apache2 by maintainer script) ldap (Enabled for cli by maintainer script) ldap (Enabled for apache2 by maintainer script) pdo_mysql (Enabled for cli by maintainer script) pdo_mysql (Enabled for apache2 by maintainer script) imagick (Enabled for cli by maintainer script) imagick (Enabled for apache2 by maintainer script) intl (Enabled for cli by maintainer script) intl (Enabled for apache2 by maintainer script) json (Enabled for cli by maintainer script) json (Enabled for apache2 by maintainer script) gd (Enabled for cli by maintainer script) gd (Enabled for apache2 by maintainer script) mcrypt (Enabled for cli by maintainer script) mcrypt (Enabled for apache2 by maintainer script) readline (Enabled for cli by maintainer script) readline (Enabled for apache2 by maintainer script) sqlite3 (Enabled for cli by maintainer script) sqlite3 (Enabled for apache2 by maintainer script) Configuration files: /etc/php5/mods-available/pdo.ini extension=pdo.so /etc/php5/mods-available/opcache.ini zend_extension=opcache.so -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages php5 depends on: ii libapache2-mod-php5 5.6.5+dfsg-1 ii php5-common 5.6.5+dfsg-1 php5 recommends no packages. php5 suggests no packages. Versions of packages php5-common depends on: ii libc6 2.19-13 ii lsof4.86+dfsg-1 ii psmisc 22.21-2 ii sed 4.2.2-4+b1 ii ucf 3.0030 Versions of packages php5-common suggests: pn php5-user-cache -- no debconf information -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150214084519.19323.86932.report...@minobo.das-netzwerkteam.de
Should .a library contains non-reallocatable code?
Dear Debian Developers, I wonder what is the current state-of-art concerning the code in .a library (archive for static linking). Should it contain PIC code? Situation: Dynamic (.so) library needs to be linked against such (.a) library. Thank you for any advises and your opinion in advance. On 23/01/2015 17:44, Antonio Diaz Diaz wrote: > Hello Alexander and Dmitry, > > Alexander Alemayhu wrote: >> forwarding a thread I had with Dmitry regarding [#]774164. >> What do you think? > > Libocrad is available only in static form because it is just a very > immature hack. Basically I add functions as users ask for them. It meets > about all the requirements in section 8.3 "Static libraries" of > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > Ocrad itself is very immature. I can't guarantee any stability. > > Moreover, AFAIK, compiling the sources twice (once without PIC for > CLI and another time with PIC for .a) is not trivial. Different names > are needed for the two versions of the object files. > > BTW, libocrad.a is *not* used to create ocrad CLI. libocrad.a is just > ocrad with an incomplete programming interface instead of a CLI. > > > Best regards, > Antonio. > > -- Forwarded message -- > From: Dmitry Katsubo > Date: 2015-01-10 15:39 GMT+01:00 > Subject: Re: Bug#774164: libocrad-dev: libocrad.a contains non-reallocatable > code > To: Alexander Alemayhu > > On 06/01/2015 22:54, Alexander Alemayhu wrote: >> It might take me some time to make a change, because of work. >> Please also note I have not made Debian libraries before, so it >> might take me some time to do it properly. If you can't wait and >> would like to be the change, please send a patch or pull request >> :) >> >> I had a little chat with my neighbour and he had some useful links >> to share which should give more information on Debian best >> practices. >> >> Thanks. >> >> See below: >> >> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html >> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-libraries > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html > > Thanks for the links! > > In particular this one: > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#staticonlylibs > > says > > "providing -fPIC versions of static libraries for linking with > shared libraries is a bad sign, because the "unstable interface" is > now exported through another library's stable library interface", > which is true, but without -fPIC the resulting shared library is unusable. > > Ideally of course would be that OCRAD is split into light-weight > command-line and dynamic library library, but I am sure that adds more > organizational work -- would it be worth? Try to ask the OCRAD > community if they would be happy to have OCRAD also as dynamic library > (which can also be wrapped into Perl/Java/etc bridges). > > -- > With best regards, > Dmitry -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54df4008.20...@mail.ru
Bug#778407: ITP: golang-glog -- Leveled execution logs for Go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-glog Version : 0.1~git20150214.44145f0 Upstream Author : Google Inc. * URL : https://github.com/golang/glog * License : Apache-2.0 Programming Lang: Go Description : Leveled execution logs for Go This is an efficient pure Go implementation of leveled logs in the manner of the open source C++ package http://code.google.com/p/google-glog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150214150927.32729.76240.report...@aine.tincho.org
Re: packages for adoption: icu, tiff, xerces-c, psutils
On Wed, Feb 11, 2015 at 12:02 PM, Richard Winters wrote: > > I'm not a 'debian' maintainer or developer...total newbie to alioth -> but > I'm a c++ developer with over 10 years experience. I'm experienced with > linux and more specifically debian development (just not officially). > > That said I'd love to get involved with Debian development -> I love debian > and live by it. Anyone willing to lemme help out would be great. I check on > alioth often...projects never seem to be posted for help...as a newbie I'm > confused how to get started -> I've read documentation yet most of these > emails looking for helping or specifying a package to be orphaned require a > dev or maintainersome of the packages I've looked into helping out with > either dont have a buglist or are severely old and have dozens of helpers > already. > > I offer my help here because I tend to need the ICU packages for building > various things...if its gonna be orphaned I'd rather help out... > Take a look at the how-can-i-help package to identify potential areas where you can contribute. For example, % how-can-i-help --show newcomer,RFH % how-can-i-help --old | less More details can be found in "man how-can-i-help". You can install this by "apt-get install how-can-i-help". raju -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpbYaeBavGAkiY1HzO_a3majhfZgQU2m3Z=0wbth3w56ya...@mail.gmail.com
Re: Should .a library contains non-reallocatable code?
Hi, On 14.02.2015 13:31, Dmitry Katsubo wrote: > I wonder what is the current state-of-art concerning the code in .a > library (archive for static linking). Should it contain PIC code? Normally, no. > Situation: Dynamic (.so) library needs to be linked against such (.a) > library. That is generally frowned upon. I do the same thing with vxi and librevisa -- I build the static library with PIC code and statically link into librevisa, and I justify that by the vxi code being generated RPC stubs that really don't need an extra shared library package. However, your case is different: a quick hack package without a stable ABI is the exact opposite. From a distribution point of view, it is difficult to track what version of a static library was linked, which is why we use shared libraries as often as we can. The slightly suboptimal solution for a library without a stable ABI is to use a version number in the SONAME, leave out the version from the package name and build a shlibs file that uses a dependency with a fixed version. This means that all packages using this library can only be upgraded together, but at least it doesn't introduce lots of NEW packages with every upload. Simon signature.asc Description: OpenPGP digital signature
Re: packages for adoption: icu, tiff, xerces-c, psutils
Hello Kamaraju, Thank you for that information I am checking it out at this time! Best, *Richard B. Winters* On Sat, Feb 14, 2015 at 10:51 AM, kamaraju kusumanchi < raju.mailingli...@gmail.com> wrote: > On Wed, Feb 11, 2015 at 12:02 PM, Richard Winters wrote: > > > > I'm not a 'debian' maintainer or developer...total newbie to alioth -> > but > > I'm a c++ developer with over 10 years experience. I'm experienced with > > linux and more specifically debian development (just not officially). > > > > That said I'd love to get involved with Debian development -> I love > debian > > and live by it. Anyone willing to lemme help out would be great. I check > on > > alioth often...projects never seem to be posted for help...as a newbie > I'm > > confused how to get started -> I've read documentation yet most of these > > emails looking for helping or specifying a package to be orphaned > require a > > dev or maintainersome of the packages I've looked into helping out > with > > either dont have a buglist or are severely old and have dozens of helpers > > already. > > > > I offer my help here because I tend to need the ICU packages for building > > various things...if its gonna be orphaned I'd rather help out... > > > > Take a look at the how-can-i-help package to identify potential areas > where you can contribute. For example, > > % how-can-i-help --show newcomer,RFH > % how-can-i-help --old | less > > More details can be found in "man how-can-i-help". You can install > this by "apt-get install how-can-i-help". > > raju > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/CABpbYaeBavGAkiY1HzO_a3majhfZgQU2m3Z=0wbth3w56ya...@mail.gmail.com > >
Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library
Package: wnpp Severity: wishlist Owner: Ross Gammon * Package name: netcdf-python Version : 1.1.3 Upstream Author : University Corporation for Atmospheric Research/Unidata * URL : http://unidata.github.io/netcdf4-python/ * License : ISC, Expat Programming Lang: Python Description : python interface to the netCDF4 (network Common Data Form) library NetCDF version 4 has many features not found in earlier versions of the library and is implemented on top of HDF5. This module can read and write files in both the new netCDF 4 and the old netCDF 3 format, and can create files that are readable by HDF5 clients. The API is modelled after Scientific.IO.NetCDF, and should be familiar to users of that module. Most new features of netCDF 4 are implemented, such as multiple unlimited dimensions, groups and zlib data compression. All the new numeric data types (such as 64 bit and unsigned integer types) are implemented. Compound and variable length (vlen) data types are supported, but the enum and opaque data types are not. Mixtures of compound and vlen data types (compound types containing vlens, and vlens containing compound types) are not supported. The University Corporation for Atmospheric Research (Unidata) also provide C++ and Fortran interfaces to the NetCDF C library. This is their python interface. There is already python-netcdf packaged for Debian as part of the Scientific Python source. However, netcdf-python implements different parts of the interface and is supported by the organisation that controls the NetCDF library. The package will be maintained within the Debian GIS Team (as well as the NetCDF C, C++, and Fortran libraries). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150214185529.20773.45062.reportbug@localhost
Re: Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library
On Sat, 2015-02-14 at 19:55 +0100, Ross Gammon wrote: > * Package name: netcdf-python > Version : 1.1.3 > Upstream Author : University Corporation for Atmospheric Research/Unidata > * URL : http://unidata.github.io/netcdf4-python/ How does this differ from the existing python-netcdf package? Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1423940719.23892.5.ca...@adam-barratt.org.uk
Bug#778420: ITP: golang-leveldb -- Implementation of the LevelDB key/value database in Go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-leveldb Version : 0+git20150214.e9e2c8f Upstream Author : Suryandaru Triandana * URL : https://github.com/syndtr/goleveldb * License : BSD-2-clause Programming Lang: go Description : Implementation of the LevelDB key/value database in Go This is an implementation of the LevelDB key/value database (https://github.com/google/leveldb) in the Go programming language. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150214195029.22107.49697.report...@aine.tincho.org
Re: Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library
On 02/14/2015 08:05 PM, Adam D. Barratt wrote: > On Sat, 2015-02-14 at 19:55 +0100, Ross Gammon wrote: >> * Package name: netcdf-python >> Version : 1.1.3 >> Upstream Author : University Corporation for Atmospheric Research/Unidata >> * URL : http://unidata.github.io/netcdf4-python/ > > How does this differ from the existing python-netcdf package? That is not an easy question to answer (at least with my limited knowledge). The Unidata website (http://www.unidata.ucar.edu/software/netcdf/software.html#Python) lists 8 different python interfaces to NetCDF. Some are faster, and some offer writing in reading & writing in other data formats as well as NetCDF. The netcdf4-python package is the only one described as having implemented most of the newest features of NetCDF-4. It was actually modelled on the Scientific.IO.NetCDF module API. The information about the ScientificPython source package which bundles python-netcdf (along with many other modules useful for scientific work), does not contain much easy to digest information about the implemented interface. I did see in the changelog however, that it is at least aware of NetCDF-4 data. Basically, our intention was to package all of the netcdf-* packages under the Unidata banner on github (https://github.com/Unidata). Regards, Ross signature.asc Description: OpenPGP digital signature
