Building package creates broken .diff.gz file
Hi, I experienced a strange behaviour when I build a debian package for one of my C libraries. When I run 'dpkg-buildpackage -r fakeroot' the resulting .diff.gz file has entries like the following: --- pxlib-0.4.2.orig/debian/changelog +++ pxlib-0.4.2/debian/changelog @@ -1 +1,187 @@ -/usr/bin/gpg +pxlib (0.4.2-1) unstable; urgency=low + I wonder where the '-/usr/bin/gpg' comes from. Running 'dpkg-soure -b pxlib' results in a propper diff.gz file. Is anybody else experiencing this or can anybody explain this? I'm runnig an up to date unstable distribution. Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Re: Help: Strange behaviour of ldd
On Wed, Jun 01, 2005 at 02:26:10PM +0200, Andreas Tille wrote: > Hi, > > I observed a strange problem when trying to sponsor the mummer package > > http://bioinformatics.pzr.uni-rostock.de/~moeller/debian/mummer > > I reduced the problem to a quite basic one. Just go to > > http://people.debian.org/~tille/tmp/test/ > > and download Makefile *.cc and *.hh (only 5 files) and try make. This > builds > two executables: annotate and gaps. Now try > > $ ldd annotate gaps > annotate: > not a dynamic executable > gaps: > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7f19000) > libm.so.6 => /lib/tls/libm.so.6 (0xb7ef6000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41312000) > libc.so.6 => /lib/tls/libc.so.6 (0xb7dc1000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000) > > I'm no C++ expert but I really fail to see the difference which causes > ldd to fail. Perhaps we should discuss this on debian-devel list. I'm > not sure whether such things might be caused by different libraries and > you need to add a certain build dependency. > At least on my ibook it cannot reproduce it. [EMAIL PROTECTED]:/tmp$ ldd annotate gaps annotate: libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0ff27000) libm.so.6 => /lib/libm.so.6 (0x0fe92000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0fe64000) libc.so.6 => /lib/libc.so.6 (0x0fd05000) /lib/ld.so.1 => /lib/ld.so.1 (0x3000) gaps: libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0ff27000) libm.so.6 => /lib/libm.so.6 (0x0fe92000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0fe64000) libc.so.6 => /lib/libc.so.6 (0x0fd05000) /lib/ld.so.1 => /lib/ld.so.1 (0x3000) [EMAIL PROTECTED]:/tmp$ gcc --version gcc (GCC) 3.3.6 (Debian 1:3.3.6-5.0.1) Copyright © 2003 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE. [EMAIL PROTECTED]:/tmp$ ldd --version ldd (GNU libc) 2.3.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. [EMAIL PROTECTED]:/tmp$ uname -a Linux ibook 2.6.11-rc4 #2 Mon Feb 14 19:36:55 CET 2005 ppc GNU/Linux -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
postrm hangs after restart of apache
Hi, I'm currently trying to write a postrm file for a debian package containing a php4 web application. During postinst I did set up apache und PostgreSQL. When I try to purge or remove the package, the postrm bash script fails quite early after I had removed the included http.conf file of my application and tried to restart apache. Actually it doesn't fail but simply got stuck. I need to Ctrl-C to get out. The following code within postrm remove) # Coments include file on the main config of the webserver if [ -f /usr/share/wwwconfig-common/apache-cominclude_all.sh ]; then for server in $webservers; do . /usr/share/wwwconfig-common/apache-cominclude_all.sh if [ "$status" = "comment" ]; then restart="$restart $server" fi done fi # Restart modified webservers if [ -f /usr/share/wwwconfig-common/restart.sh ]; then servers="apache-ssl apache" . /usr/share/wwwconfig-common/restart.sh # need some sleep, otherwise this skript hangs sleep 5 fi ;; produces ... ++ log=Include of /etc/us-adressdatenbank/apache.conf found in apache config files, commenting.Commenting import for /etc/us-adressdatenbank/apache.conf in /etc/apache/httpd.conf.apache needs to be restarted. ++ '[' -x /etc/init.d/apache ']' ++ /etc/init.d/apache restart + sleep 5 + '[' remove = purge ']' + exit 0 It appears like the 'sleep 5' which I added for debugging has improved the situation. /var/log/apache/error.log contains lines like [Thu Jun 26 12:05:09 2003] [crit] (98)Address already in use: make_sock: could not bind to port 80 which sounds like the restart failed. If that is the problem, could somebody enlighten me on how to fix it. Thanks for the help Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 pgphnL4iS9uFF.pgp Description: PGP signature
Re: x48
On Thu, Sep 25, 2003 at 07:38:28AM -0600, Hans Fugal wrote: > Does anyone remember x48? It's an HP48 CPU emulator. It used to be > packaged for debian, but was orphaned. > > In order to do any emulation it needs a ROM, which you can download from > your HP48 over the serial line. You can also get ROMs from [1]. > "HP graciously began allowing this to be downloaded in mid-2000." [1] > I don't know exactly what this means by way of copyright and/or license, > and I have emailed the webmaster of hpcalc.org to see if he knows any > more details. I imagine ROMs won't be distributable. x48 itself is under > the GPL. > > x48 hasn't been maintained for about 4 years now, and didn't work very > well on modern processors when I picked up the source (timing issues). > But Eddie Dost, the original author, has graciously worked with me to > get those issues resolved and it now works like a charm. > > So my question is, is there a problem with creating a package for a fine > but mostly-unmaintained piece of software that does its job, when I > myself have minimal familiarity with the code (or the HP48 processor > itself)? I would appreciate a package. I did one myself but never made it public. Where can the fixed version be downloaded? Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Changing name of source package
hi, I just want to double check that changing the name of a source package can be done as I anticipate it. I would like to change the name of the source package php4-ps into php-ps. php4-ps creates two binary packages php4-ps and php5-ps. The new source package php-ps will only create php5-ps because php4 will be dropped anyway in the near future. >From what I have read so far, it should be sufficient to upload the new source package which takes over the binary package php5-ps. Is it required to wait for a new upstream version or can I simply push up the debian version from 1.3.5-1 to 1.3.5-2? Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen [EMAIL PROTECTED] Tel: 02331 840446Fax: 02331 843920 signature.asc Description: Digital signature
Problems with double-word alignment on hppa and sparc
Hi, I need some help with #94 since I'm neither an ocaml nor a hppa, sparc specialist. The package orpie ships with its own gsl ocaml bindings and they cannot be compiled on hppa and sparc due to an alignment problem. I contacted upstream of orpie and got the following answer: I've looked into this a bit, and I'm not sure it can be fixed very easily. The OCaml bindings for libgsl avoid some expensive copy operations by making the assumption that the platform can accept double arrays aligned on word boundaries. Apparently hppa and sparc don't provide this capability. Well, is there really no hope for fixing this? This appears to be a more general problem and maybe somebody has solved it already. What puzzles me is the fact, that libocamlgsl-ocaml compiles without errors. The gsl bindings shipped with orpie are the same version as libocamlgsl-ocaml, though not all files are present. Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen [EMAIL PROTECTED] Tel: 02331 840446Fax: 02331 843920 signature.asc Description: Digital signature
Re: Packaging LetoDMS (mydms)
On Sat, Jan 01, 2011 at 10:24:24PM +0100, Francisco M. García Claramonte wrote: > Hello all, Hi Francisco, I'm one of the developers for about 2 month now and made most of the recent changes to the code currently only available in svn. > I am trying to package the new upstream version of mydms [1]. > This Debian package is removed from the archive, and it won't > be present in Squeeze [2]. > > The upstream package is renamed to letodms [3]. Last versions > have a lot of changes (database, code) and improvements. The upcoming version (probably 3.0) will have even more changes and is much more modulized. > I'm not sure if it is better to rename the package, creating a > dummy transitional package (mydms) with the new package letodms. > Or maybe, as the old mydms is removed from archive, just doing as a > new package, and upload it with an ITP. The database changes are still rather minor and can be handled by dbconfig. The next version will have some changes in how admins and guests are treated. Currently there is only one admin and guest allowed. In the future any number of admins and guests are possible. I'm not sure if dbconfig has a solution for it, because all guest must have the 'isguest' field set in the database. > In case of rename the package, maybe it could be needed to keep > some paths (user data in /var/lib/mydms must remain, instead > /var/lib/letodms), and Apache config to be compatible with old instances > of mydms (for example, the old URL http:///mydms must kept, > maybe add the new http:///letomds). > The old mysql database name, named mydms, must be ketp to in new > package to compatibilize with old instances of mydms. > > Maybe, the best way to rename the package is doing it with a new > Debian revision with no database changes (on the same upstream > version), and later package new upstream versions with database > changes (db is managed with dbconfig-common). > But, I am not sure if keep old /var/lib/mydms (for mydms upgrades) > and create /var/lib/letodms (for new installs) is a good idea > (it isn't). > > I would like to know what do you think about these points. > Thank you. I thought about it as well but finally created new debian packages for letodms and droped the upgrade path from mydms, mostly because of all the renaming you mentioned above. If that could be done automatically it would be great, but I doubt it's worth to do so. What if Readme.Debian just describes how to upgrade? The *new* letodms in debian should be split up into various packages. The source of letodms is already prepared for such a split. The source code has a Makefile to create a pear package of the core, a webdav server based on HTTP_WebDAV_Server and the application itself. There is still some fine tuning needed, but that's only a matter of time. Thanks for taking care of the debian package. Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen uwe.steinm...@mmk-hagen.de Tel: 02331 840446Fax: 02331 843920 signature.asc Description: Digital signature
Re: RFC: best practice creating database
On Thu, Oct 07, 2004 at 03:38:59PM +0200, Philipp Matthias Hahn wrote: > Hello! > > What is consideres best practice when a package uses a SQL database > (mysql, postgresql) and needs to create its own catalog and/or tables? > > [ ] Disable the package until someone has manually setup the database? > [ ] Ask a lot of questions via debconf and try to setup in postconf? I'd go for the second option. > I ask because bacula-director-pgsql is currently broken and I'm trying > to help the maintainer fix it. What irks me is > * need to ask for hostname of remote or local DBMS. > * if its remote, the DBA might have to change "pg_hba.conf" by hand. > * need to ask for user/password of DBA, so new catalog can be created > * password is cleared after use for security reason > * will a paranoid DBA tell me his password? > * need to ask for user/password for bacula-user > > If the automation fails (and it does for my setup), bacula-dir-pgsql is > left unconfigured and I have to deeply dig in its postconf script to fix > it my hand. > What I ask myself at this point, is it worth to try to automatically > setup these things at all or wouldn't it be better to just document the > needed steps and let the user do them by hand? I expect from a debian package to be usable once it is installed, unless the configuration is so complex that it can't be determined wit debconf questions. Setting up a database is somewhat errorprune but still something achievable in a postinst script. Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Re: RFC: best practice creating database
On Fri, Oct 08, 2004 at 03:45:26PM +1000, Andrew Pollock wrote: > On Thu, Oct 07, 2004 at 05:19:07PM +0200, Uwe Steinmann wrote: > > On Thu, Oct 07, 2004 at 03:38:59PM +0200, Philipp Matthias Hahn wrote: > > > Hello! > > > > > > What is consideres best practice when a package uses a SQL database > > > (mysql, postgresql) and needs to create its own catalog and/or tables? > > > > > > [ ] Disable the package until someone has manually setup the database? > > > [ ] Ask a lot of questions via debconf and try to setup in postconf? > > I'd go for the second option. > > > [snip] > > > > Setting up a database is somewhat errorprune but still something > > achievable in a postinst script. > > Methinks we need something like wwwconfig-common, but for databases... wwwconfig-common does most of what needs to be done for setting up a database. What are you missing? Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Re: RFC: best practice creating database
On Sat, Oct 09, 2004 at 08:02:22AM +0200, Andreas Tille wrote: > On Fri, 8 Oct 2004, Stefan Hornburg wrote: > > >First of all documentation. > Definitely! I was about to write some, to at least have an overview of what commands are available. Unfortunately, I haven't found the time yet. Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Re: Failed to make a .deb package of PECL uploadprogress on squeeze. Any solution?
On Fri, Oct 28, 2011 at 07:28:09AM +0530, Jaisen wrote: > Hello..., > > Please help.., > I need to make this. > I feel bad that, nobody in this list paying no attention in this.. :( Try the '--only 5' option of dh-make-pecl Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen uwe.steinm...@mmk-hagen.de Tel: 02331 840446Fax: 02331 843920 signature.asc Description: Digital signature
