Re: RFS: 0ad
Hi Vincent, (CCing you since I'm not sure which lists you are on if any, sorry for any duplicate mail) Looks like you are taking over the ITPs owned by Bertrand Marc, with his permission. Bertrand was maintaining the packaging in the games team's SVN repository, but you don't seem to have updated the SVN repository with your changes. In addition your package doesn't have the games team in the Maintainer field. Do you intend to join the games team or should we delete Bertrand's packaging from our SVN repository? If you are interested in joining the games team, please check our wiki pages, jump on IRC, say hi and we will give you a quick run-down on our team practices. The team is having a meeting soon, please check these pages: http://lists.debian.org/4d8b6722.5060...@debian.org http://wiki.debian.org/Games/Meetings/2011-04 http://www.doodle.com/q9aguzv2vx9qdrwn -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=plfc9mzu3xy7nhi31chcpjry...@mail.gmail.com
Re: RFS: blockade upgrade
I would suggest joining the Debian games team, committing the package to our SVN repository and maintaining it there. If you are willing to join the team, please check out our wiki pages, jump on our IRC channel, introduce yourself and we will give you a run-down of how the team works: http://wiki.debian.org/Games/Team Once you have joined the team, check out our PET instance for other packages you might want to work on: http://pkg-games.alioth.debian.org/cgi-bin/PET/qareport.cgi And add your package to our sponsors queue: http://wiki.debian.org/Games/Sponsors/Queue In addition we are having another meeting soon, please check out these links: http://lists.debian.org/4d8b6722.5060...@debian.org http://wiki.debian.org/Games/Meetings/2011-04 http://www.doodle.com/q9aguzv2vx9qdrwn -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimj_f_25f7xf4kmwrb3vh9hn2b...@mail.gmail.com
Re: RFS: 0ad
On Sat, Apr 2, 2011 at 11:02 PM, Paul Wise p...@debian.org wrote: Hi Vincent, (CCing you since I'm not sure which lists you are on if any, sorry for any duplicate mail) Looks like you are taking over the ITPs owned by Bertrand Marc, with his permission. Bertrand was maintaining the packaging in the games team's SVN repository, but you don't seem to have updated the SVN repository with your changes. In addition your package doesn't have the games team in the Maintainer field. Do you intend to join the games team or should we delete Bertrand's packaging from our SVN repository? If you are interested in joining the games team, please check our wiki pages, jump on IRC, say hi and we will give you a quick run-down on our team practices. The team is having a meeting soon, please check these pages: http://lists.debian.org/4d8b6722.5060...@debian.org http://wiki.debian.org/Games/Meetings/2011-04 http://www.doodle.com/q9aguzv2vx9qdrwn -- bye, pabs http://wiki.debian.org/PaulWise I would be glad to join the Debian Games team and help maintain various games in Debian (I also have a few other games I want to package); I simply wasn't all too sure how to approach the Games team. I'll take a look at the links you've provided today/tomorrow, and get up to speed with the rest of the team. To be honest, I don't know how to upload files to a SVN repository, which is why I haven't uploaded my 0ad packaging yet. But I'm definitely ready and willing to learn. :) - Vincent
Re: RFS: 0ad
On Sat, Apr 2, 2011 at 11:08 PM, Karl Goetz k...@kgoetz.id.au wrote: On Sat, 2 Apr 2011 21:59:59 -0700 Vincent Cheng vincentc1...@gmail.com wrote: Dear mentors, Not sure if all the CCs are required, so preserving them. I am looking for a sponsor for my package 0ad. * Package name: 0ad Version : 0~r09049~alpha4-1 Upstream Author : Wildfire Games * URL : http://wildfiregames.com/0ad/ * License : GPL, LGPL, MIT Programming Lang: C++ Description : 3D real-time strategy (RTS) game of ancient warfare Section : games Is there code distributed under the terms of license_dbghelp.txt in this package? It would appear to be non-dfsg compliant, so may cause you problems. thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK5FOSS) Debian contributor / gNewSense Maintainer http://www.kgoetz.id.au No, I won't join your social networking group To be honest, I don't know. The files that are licensed under the terms of license_dbghelp.txt are in source/lib/external_libraries/dbghelp.cpp, dbghelp.h, dbghelp_funcs.h, but I'm not sure if they're used during the build. Hmmm...I'll try re-building 0ad with those files removed from the source tarball and see if the build still works. - Vincent
Re: RFS: 0ad
On Sat, 2 Apr 2011 21:59:59 -0700 Vincent Cheng vincentc1...@gmail.com wrote: Hi vincent, I've left all the CCs in; should they all be maintained, or can some be dropped? Dear mentors, I am looking for a sponsor for my package 0ad. Description : 3D real-time strategy (RTS) game of ancient warfare Section Could you double check the following things? Not sure how many of them are real problems, but would be good to have checked. (I'm not sure if my check is correct). ./binaries/data/tests/collada/sphere.pmd - its a data file, and i can't see a free software tool to open this. ./libraries/spidermonkey-tip/src/js.mdp - its a data file, and i can't see a free software tool to open this. ./binaries/data/tools/fontbuilder/fonts/* - this doesn't appear in d/copyright; because they're not installed from here? - i note that there is a comment in there to this effect The Converted... fonts were produced by opening the originals in FontForge 20090923, changing the names, and exporting as TrueType.. problem for debian? ./binaries/data/mods/public/public.zip - is this meant to be sitting around as a zip, or extracted by something at unpack? Could this be related to the lack of files in binaries/data/mods/ ? The copyright file says there is an art/ and an audio/ dir in there. ./libraries/fcollada/src/FCollada/FColladaTest/Samples/Copyright.txt ./libraries/fcollada/src/FCollada/FColladaTest/Samples/Eagle.DAE - according to the Copyright file, Eagle.DAE is non-free. Appears to be a different licence to stated in d/copyright: ./libraries/spidermonkey-tip/src/dtoa.c ./libraries/spidermonkey-tip/src/jsgcchunk.cpp ./libraries/spidermonkey-tip/src/config/mkdepend/* ./libraries/spidermonkey-tip/src/config/mkdepend/Makefile.in ./libraries/spidermonkey-tip/src/assembler/* ./libraries/spidermonkey-tip/src/yarr/pcre/ ./libraries/spidermonkey-tip/ being MPL-1.1 and GPL-2.0 and LGPL-2.1 - the (L)GPL mentioned in the headers is 'or later' I didn't dig into source/. thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK5FOSS) Debian contributor / gNewSense Maintainer http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: RFS: 0ad
On Sun, Apr 3, 2011 at 10:15 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sat, Apr 2, 2011 at 11:08 PM, Karl Goetz k...@kgoetz.id.au wrote: Not sure if all the CCs are required, so preserving them. [...] Is there code distributed under the terms of license_dbghelp.txt in this package? It would appear to be non-dfsg compliant, so may cause you problems. To be honest, I don't know. The files that are licensed under the terms of license_dbghelp.txt are in source/lib/external_libraries/dbghelp.cpp, dbghelp.h, dbghelp_funcs.h, but I'm not sure if they're used during the build. Hmmm...I'll try re-building 0ad with those files removed from the source tarball and see if the build still works. - Vincent dbghelp is only used for Windows. I believe the only subdirectories of libraries/ that are needed for building on Linux are: * cxxtest * fcollada * valgrind * spidermonkey-tip * nvtt (unless building with ./update-workspaces.sh --with-system-nvtt, which requires http://code.google.com/p/nvidia-texture-tools/ version 2.0.9+ (not released)) If you're using the -build tarballs from http://releases.wildfiregames.com/ then all the other stuff under libraries/ in SVN should have been removed already. (source/tools/dist/build.sh does the relevant work.) -- Philip Taylor exc...@gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimmzrnnv9ntw+2er2sv1e9r0rrkxqufhzl0w...@mail.gmail.com
Re: RFS: 0ad
On Sun, Apr 3, 2011 at 11:00 AM, Karl Goetz k...@kgoetz.id.au wrote: On Sat, 2 Apr 2011 21:59:59 -0700 I've left all the CCs in; should they all be maintained, or can some be dropped? [...] ./binaries/data/tests/collada/sphere.pmd - its a data file, and i can't see a free software tool to open this. It's the game's custom format for mesh data (http://trac.wildfiregames.com/wiki/PMD_File_Format). (Old models only exist in .pmd format. New models exist in editable Collada (.dae) format in SVN, and the game automatically converts and caches as .pmd for more efficient loading. That particular tests/collada/sphere.pmd file is just used for tests of the cache loading code - the other .pmd files are inside public.zip.) ./libraries/spidermonkey-tip/src/js.mdp - its a data file, and i can't see a free software tool to open this. It'd be best for the game to not bundle a copy of SpiderMonkey (so this becomes somebody else's problem). I think that should be possible now, since https://bugzilla.mozilla.org/show_bug.cgi?id=628723 gives a relatively stable modern version - just need to do a bit of work to port the game to the latest version of the API. I can probably get that done for the next alpha release of the game. ./binaries/data/tools/fontbuilder/fonts/* - this doesn't appear in d/copyright; because they're not installed from here? - i note that there is a comment in there to this effect The Converted... fonts were produced by opening the originals in FontForge 20090923, changing the names, and exporting as TrueType.. problem for debian? Those files aren't used in the build or installation at all, they're just used by an offline tool that converts them to PNGs (so it was convenient to keep the original font files in SVN and they're not explicitly excluded from the release tarballs). ./binaries/data/mods/public/public.zip - is this meant to be sitting around as a zip, or extracted by something at unpack? Could this be related to the lack of files in binaries/data/mods/ ? The copyright file says there is an art/ and an audio/ dir in there. It's meant to be installed as a zip (kind of like Quake's PK3 files). The game's LICENSE.txt file refers to paths in SVN (where they're not in a zip). The release-building process finds all the files in binaries/data/mods/public/, does some format conversions (PNG - DDS etc), then saves everything into public.zip. Any suggestions on how to state the copyright status more clearly? ./libraries/fcollada/src/FCollada/FColladaTest/Samples/Copyright.txt ./libraries/fcollada/src/FCollada/FColladaTest/Samples/Eagle.DAE - according to the Copyright file, Eagle.DAE is non-free. It'd be best for the game to not bundle a copy of FCollada. See http://trac.wildfiregames.com/ticket/562 - I don't know how long it's likely to be before that's integrated and working, though. In the meantime, it's safe to delete those files from a release (since the FCollada tests don't get run automatically; they're only useful when people are developing FCollada itself). -- Philip Taylor exc...@gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimpRZoMu6=hqihayw6hty6hwnqovt2qb2rfq...@mail.gmail.com
Re: docs are generated on all build machines
On 04/02/2011 04:12 PM, The Fungi wrote: On Sat, Apr 02, 2011 at 10:02:19AM -0400, Scott Howard wrote: I think his package is already Arch:all. [...] Ahh, yes, I had missed the package name/source. I agree your analysis sounds a far more likely scenario given the problem description. Perfect, thanks for the pointers. I think I see the picture now. Michael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d986227.7070...@gmail.com
Re: RFS: 0ad
On Sat, 2 Apr 2011 21:59:59 -0700, Vincent Cheng wrote: Dear mentors, I am looking for a sponsor for my package 0ad. * Package name: 0ad [..] My motivation for maintaining this package is: Even though 0 A.D. is still in Alpha, it is still playable (and also very fun if you like RTS games). I would like to package and maintain 0 A.D. so that fellow Debian users can also enjoy this game as well. I haven't checked the package, but given I'd like to play it, I tried to build it, and it FTBFS because of libenet. It seems like it wants libenet0 (1.2.*), but in Debian we have libenet1a (1.3*). The parallel jobs make it a bit difficult to find the error, since it's buried by tons of other successful compilations, but here it is: g++ -g -O2 -MMD -D LIB_STATIC_LINK -D INSTALLED_BINDIR=/usr/games -D INSTALLED_DATADIR=/usr/share/games/0ad -D INSTALLED_LIBDIR=/usr/lib/games/0ad -D NDEBUG -D CONFIG_FINAL=1 -D USING_PCH -I /usr/X11R6/include/X11 -I /usr/X11R6/include -I /usr/include/X11 -I ../../../source/pch/simulation2 -I ../../../source/ -I ../../../libraries/spidermonkey-tip/include-unix/release -g -O3 -Wall -Wno-switch -Wno-reorder -Wno-invalid-offsetof -Wextra -Wno-missing-field-initializers -Wunused-parameter -Wredundant-decls -Wnon-virtual-dtor -Wundef -fstack-protector-all -D_FORTIFY_SOURCE=2 -fstrict-aliasing -fpch-preprocess -msse -fno-omit-frame-pointer -march=i686 -fvisibility=hidden -MF obj/simulation2_Release/Simulation2.d -MT obj/simulation2_Release/Simulation2.o -o obj/simulation2_Release/Simulation2.o -c -include obj/simulation2_Release/precompiled.h ../../../source/simulation2/Simulation2.cpp In file included from ../../../source/network/NetServer.cpp:29:0: ../../../source/lib/external_libraries/enet.h:33:2: error: #error The game currently requires ENet 1.2.x. You are using a newer version, which has an incompatible API and network protocol. Please switch to an older version. ../../../source/network/NetServer.cpp: In member function 'bool CNetServerWorker::SetupConnection()': ../../../source/network/NetServer.cpp:118:52: error: too few arguments to function 'ENetHost* enet_host_create(const ENetAddress*, size_t, size_t, enet_uint32, enet_uint32)' /usr/include/enet/enet.h:498:21: note: declared here make[3]: *** [obj/network_Release/NetServer.o] Error 1 make[2]: *** [network] Error 2 make[2]: *** Waiting for unfinished jobs I could suggest either maintain a separate libenet0, or try to port 0ad to the newer libenet (preferred, I'd say). Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: 0ad
On Sun, Apr 3, 2011 at 8:10 AM, David Paleino da...@debian.org wrote: On Sat, 2 Apr 2011 21:59:59 -0700, Vincent Cheng wrote: Dear mentors, I am looking for a sponsor for my package 0ad. * Package name : 0ad [..] haven't checked the package, but given I'd like to play it, I tried to build it, and it FTBFS because of libenet. It seems like it wants libenet0 (1.2.*), but in Debian we have libenet1a (1.3*). I started looking at 0AD recently, just wanted to summarize some things I saw. -libenet was just updated in debian less than a month ago. I don't think upstream is planning on updating it soon, but someone form either playdeb or Wildfire will have to do that since playdeb's package and wildfire's compilation instructions for debian/ubuntu say to grab libenet-dev to compile. - As for inclusion in Debian: 0AD has some bundled library issues (e.g. fcollada). The fcollada issue has been mentioned on this list [1-2]. Basically fcollada was a library created by a company 10 years ago with a GPL license. Since then the company stopped maintaining it and removed it from their website. Many projects grabbed the latest release and forked it for their own needs. There are at least 4 major forks out there which are all hacked for individual projects (there are many other patched versions, but it's hard to keep track). I tried to merge all of the major changes together in a way that each project can use, but each fcollada library is pretty much an independent project now where significant work will be needed to get a single library that everyone can use. Debian requires one canonical library, and right now the only practical solution would be to have packages for each of the major forks (which over the past 10 years have grown incompatible with each other), but I don't think that is allowed. Also, Wildfire/0AD needs an fcollada library which is compilable with MSVC building DLLs for windows (which I am not interested in nor capable of doing well.) The last time 0AD was discussed on this list [1], objections were raised about the inclusion of the fcollada library. If wildfire produces the most recent and well-maintained fcollada library available, does that one become the canonical fcollada library (and should it be packaged as is from wildfire/0AD as the libfcollada in debian?) With the amount of work maintaining 0AD may need, you might want to form a sub-team of debian-games to take care of it. Cheers, Scott [1] http://lists.debian.org/debian-devel-games/2010/09/msg5.html [2] sorry can't find the l.d.o link: http://groups.google.com/group/linux.debian.devel.mentors/browse_thread/thread/198b3d604613b17a -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi==nqthg+kstogndyi747jfaxr...@mail.gmail.com
subprocess installed pre-removal script returned error exit status 1
Dear all, I am working on the dcmtk package. I get a bizarre behavior when trying to uninstall it: $ sudo apt-get remove dcmtk Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: apache2-utils apache2-mpm-itk libaprutil1-dbd-sqlite3 apache2.2-bin libapr1 libaprutil1-ldap apache2.2-common libdcmtk1 libdcmtk2 libaprutil1 Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: dcmtk 0 upgraded, 0 newly installed, 1 to remove and 2 not upgraded. After this operation, 4,039 kB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 97834 files and directories currently installed.) Removing dcmtk ... Stopping DCMTK Central Test Node: dcmqrscpdpkg: error processing dcmtk (--remove): subprocess installed pre-removal script returned error exit status 1 configured to not write apport reports Starting DCMTK Central Test Node: dcmqrscp. Errors were encountered while processing: dcmtk E: Sub-process /usr/bin/dpkg returned an error code (1) Now as soon as I change set -e into set -x in /etc/init.d/dcmqrscp, I can uninstall it properly: $ sudo apt-get remove dcmtk Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: apache2-utils apache2-mpm-itk libaprutil1-dbd-sqlite3 apache2.2-bin libapr1 libaprutil1-ldap apache2.2-common libdcmtk1 libdcmtk2 libaprutil1 Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: dcmtk 0 upgraded, 0 newly installed, 1 to remove and 2 not upgraded. After this operation, 4,039 kB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 97834 files and directories currently installed.) Removing dcmtk ... + PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin + DESC=DCMTK Central Test Node + NAME=dcmqrscp + DAEMON=/usr/bin/dcmqrscp + PIDFILE=/var/run/dcmqrscp.pid + SCRIPTNAME=/etc/init.d/dcmqrscp + DCMQRSCP_CFG=/etc/dcmtk/dcmqrscp.cfg + test -x /usr/bin/dcmqrscp + [ -r /etc/default/dcmqrscp ] + . /etc/default/dcmqrscp + DCMQRSCP_ENABLE=Yes + echo -n Stopping DCMTK Central Test Node: dcmqrscp Stopping DCMTK Central Test Node: dcmqrscp+ d_stop + start-stop-daemon --stop --quiet --pidfile /var/run/dcmqrscp.pid --name dcmqrscp + echo . . + exit 0 + PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin + DESC=DCMTK Central Test Node + NAME=dcmqrscp + DAEMON=/usr/bin/dcmqrscp + PIDFILE=/var/run/dcmqrscp.pid + SCRIPTNAME=/etc/init.d/dcmqrscp + DCMQRSCP_CFG=/etc/dcmtk/dcmqrscp.cfg + test -x /usr/bin/dcmqrscp + [ -r /etc/default/dcmqrscp ] + . /etc/default/dcmqrscp + DCMQRSCP_ENABLE=Yes + echo -n Stopping DCMTK Central Test Node: dcmqrscp Stopping DCMTK Central Test Node: dcmqrscp+ d_stop + start-stop-daemon --stop --quiet --pidfile /var/run/dcmqrscp.pid --name dcmqrscp + echo . . + exit 0 Processing triggers for man-db ... Thanks for suggestions, -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=r6weh2yk+d5e6cn-q3-ryxfn...@mail.gmail.com
Re: subprocess installed pre-removal script returned error exit status 1
On Sun, 3 Apr 2011 18:28:29 +0200, Mathieu Malaterre wrote: Dear all, I am working on the dcmtk package. I get a bizarre behavior when trying to uninstall it: [..] Stopping DCMTK Central Test Node: dcmqrscpdpkg: error processing dcmtk (--remove): subprocess installed pre-removal script returned error exit status 1 configured to not write apport reports Starting DCMTK Central Test Node: dcmqrscp. Errors were encountered while processing: dcmtk E: Sub-process /usr/bin/dpkg returned an error code (1) What do you have in your debian/*prerm ? Now as soon as I change set -e into set -x in /etc/init.d/dcmqrscp, I can uninstall it properly: [..] That's because of the behaviour of set -e (from help set): -e Exit immediately if a command exits with a non-zero status. i.e. something in your prerm is returning non-zero, and isn't properly handled. By not setting -e (i.e. changing it into -x, or deleting it, or...), you simply disable this behaviour, which is discouraged. Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: subprocess installed pre-removal script returned error exit status 1
David, On Sun, Apr 3, 2011 at 6:41 PM, David Paleino da...@debian.org wrote: On Sun, 3 Apr 2011 18:28:29 +0200, Mathieu Malaterre wrote: Dear all, I am working on the dcmtk package. I get a bizarre behavior when trying to uninstall it: [..] Stopping DCMTK Central Test Node: dcmqrscpdpkg: error processing dcmtk (--remove): subprocess installed pre-removal script returned error exit status 1 configured to not write apport reports Starting DCMTK Central Test Node: dcmqrscp. Errors were encountered while processing: dcmtk E: Sub-process /usr/bin/dpkg returned an error code (1) What do you have in your debian/*prerm ? Here it is: #!/bin/sh set -e set -x # This is in case we upgrade from dcmtk version 3.5.4 if [ -x /etc/init.d/imagectn ]; then if [ -x /usr/sbin/invoke-rc.d ]; then invoke-rc.d --quiet imagectn stop else /etc/init.d/imagectn stop fi fi if [ -x /etc/init.d/dcmqrscp ]; then if [ -x /usr/sbin/invoke-rc.d ]; then invoke-rc.d --quiet dcmqrscp stop else /etc/init.d/dcmqrscp stop fi fi # Automatically added by dh_installinit if [ -x /etc/init.d/dcmqrscp ]; then invoke-rc.d dcmqrscp stop || exit $? fi # End automatically added section exit 0 And here is the log: Removing dcmtk ... + [ -x /etc/init.d/imagectn ] + [ -x /etc/init.d/dcmqrscp ] + [ -x /usr/sbin/invoke-rc.d ] + invoke-rc.d --quiet dcmqrscp stop + PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin + DESC=DCMTK Central Test Node + NAME=dcmqrscp + DAEMON=/usr/bin/dcmqrscp + PIDFILE=/var/run/dcmqrscp.pid + SCRIPTNAME=/etc/init.d/dcmqrscp + DCMQRSCP_CFG=/etc/dcmtk/dcmqrscp.cfg + test -x /usr/bin/dcmqrscp + [ -r /etc/default/dcmqrscp ] + . /etc/default/dcmqrscp + DCMQRSCP_ENABLE=Yes + echo -n Stopping DCMTK Central Test Node: dcmqrscp Stopping DCMTK Central Test Node: dcmqrscp+ d_stop + start-stop-daemon --stop --pidfile /var/run/dcmqrscp.pid --name dcmqrscp + echo . . + exit 0 + [ -x /etc/init.d/dcmqrscp ] + invoke-rc.d dcmqrscp stop + PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin + DESC=DCMTK Central Test Node + NAME=dcmqrscp + DAEMON=/usr/bin/dcmqrscp + PIDFILE=/var/run/dcmqrscp.pid + SCRIPTNAME=/etc/init.d/dcmqrscp + DCMQRSCP_CFG=/etc/dcmtk/dcmqrscp.cfg + test -x /usr/bin/dcmqrscp + [ -r /etc/default/dcmqrscp ] + . /etc/default/dcmqrscp + DCMQRSCP_ENABLE=Yes + echo -n Stopping DCMTK Central Test Node: dcmqrscp Stopping DCMTK Central Test Node: dcmqrscp+ d_stop + start-stop-daemon --stop --pidfile /var/run/dcmqrscp.pid --name dcmqrscp No dcmqrscp found running; none killed. invoke-rc.d: initscript dcmqrscp, action stop failed. + exit 1 dpkg: error processing dcmtk (--remove): subprocess installed pre-removal script returned error exit status 1 configured to not write apport reports + PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin + DESC=DCMTK Central Test Node + NAME=dcmqrscp + DAEMON=/usr/bin/dcmqrscp + PIDFILE=/var/run/dcmqrscp.pid + SCRIPTNAME=/etc/init.d/dcmqrscp + DCMQRSCP_CFG=/etc/dcmtk/dcmqrscp.cfg + test -x /usr/bin/dcmqrscp + [ -r /etc/default/dcmqrscp ] + . /etc/default/dcmqrscp + DCMQRSCP_ENABLE=Yes + echo -n Starting DCMTK Central Test Node: dcmqrscp Starting DCMTK Central Test Node: dcmqrscp+ d_start + start-stop-daemon --start --quiet --background --make-pidfile --pidfile /var/run/dcmqrscp.pid --exec /usr/bin/dcmqrscp -- +ac -c /etc/dcmtk/dcmqrscp.cfg + echo . . + exit 0 Errors were encountered while processing: dcmtk E: Sub-process /usr/bin/dpkg returned an error code (1) -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTik7PGx-P7KYfNOgcHFUT3DTac=+z...@mail.gmail.com
Re: subprocess installed pre-removal script returned error exit status 1
Hello Mathieu, On Sun, 3 Apr 2011 19:03:30 +0200, Mathieu Malaterre wrote: if [ -x /etc/init.d/dcmqrscp ]; then if [ -x /usr/sbin/invoke-rc.d ]; then invoke-rc.d --quiet dcmqrscp stop else /etc/init.d/dcmqrscp stop fi fi # Automatically added by dh_installinit if [ -x /etc/init.d/dcmqrscp ]; then invoke-rc.d dcmqrscp stop || exit $? fi # End automatically added section This is duplicate code. I suppose you wrote the first manually -- I suggest you to remove it, since dh_installinit is taking care of it already. Also, the error seem to be caused by this code. To find out, please add a set -x to the top of /etc/init.d/dcmqrscp, to find where it breaks. Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: subprocess installed pre-removal script returned error exit status 1
On Sun, Apr 3, 2011 at 7:15 PM, David Paleino da...@debian.org wrote: Hello Mathieu, On Sun, 3 Apr 2011 19:03:30 +0200, Mathieu Malaterre wrote: if [ -x /etc/init.d/dcmqrscp ]; then if [ -x /usr/sbin/invoke-rc.d ]; then invoke-rc.d --quiet dcmqrscp stop else /etc/init.d/dcmqrscp stop fi fi # Automatically added by dh_installinit if [ -x /etc/init.d/dcmqrscp ]; then invoke-rc.d dcmqrscp stop || exit $? fi # End automatically added section This is duplicate code. I suppose you wrote the first manually -- I suggest you to remove it, since dh_installinit is taking care of it already. Also, the error seem to be caused by this code. To find out, please add a set -x to the top of /etc/init.d/dcmqrscp, to find where it breaks. Thanks David ! -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinzat9jcwgq8i7bvqrvdfemuc_...@mail.gmail.com
Re: RFS: polygraph
Hi Dmitry, Sorry for the huge wait for a first reply to your post. Dear mentors, I am looking for a sponsor for my package polygraph. * Package name: polygraph Version : 4.0.11-1 Upstream Author : The Measurement Factory, Inc. i...@measurement-factory.com * URL : http://www.web-polygraph.org * License : Apache-2.0 Section : net [...] I have now started to review this package and found at least two fundamental problems: - The Apache license also gives a fairly precise description how it is to be applied to your work, as can be seen at the very end of http://www.apache.org/licenses/LICENSE-2.0.html The codebase of polygraph does not seem to follow this requirement, which (1) makes checking for proper licensing extremely hard and (2) may even be in violation with the license requirements. - Your package fails to build: Ssl.cc: In constructor ‘SslCtx::SslCtx(SslCtx::SslProtocol, const String)’: Ssl.cc:33:27: error: ‘::SSLv2_method’ has not been declared Other than that the package looks fine to me, but given this FTBFS this review remains very incomplete. Best regards, Michael pgpONMwiPpQIj.pgp Description: PGP signature
Re: RFS: qmagneto
Hi, [...] I finally got around to take a look at your package. One basic problem must be solved at first: several files lack license and copyright information: src/changethumbimpl.h src/application.cpp src/changethumbimpl.cpp src/channeliconitem.h src/application.h src/releaseversion.h src/expandedpixmap.cpp src/expandedpixmap.h src/channeliconitem.cpp Furthermore, the following issues should be addressed: - debian/copyright: Nothing is said about the license of Debian packaging; likely it takes the same license as upstream code, but that should be stated explicitly. Furthermore please consider conversion to DEP5 format. Furthermore it's not even said where this software can be downloaded from. - debian/docs is empty (should probably be removed). - debian/watch does nothing. - Your build rules are semi-broken it seems: the entire build is performed twice. - Building the package yields a large number of warnings; as you are upstream, please address these. - Please make sure your package is lintian-clean. Best regards, Michael pgpgQrvqFuoNG.pgp Description: PGP signature
Re: RFS: mpd-sima (autoqueue MPD client, find similar artists to queue)
Hi, Dear mentors, I am looking for a sponsor for my package mpd-sima (new version of previously named sima package). * Package name: mpd-sima Version : 0.7.0-1 Upstream Author : Kaliko Jack ef...@azylum.org * URL : http://codingteam.net/project/sima * License : GPVv3 Section : sound [...] Built uploaded (but will have to wait in NEW, though). As you renamed the package to mpd-sima, could you please manually remove the sima package from mentors.debian.net? I'd like to point you to [1] - if you'd have some time, it would be great if you could also help others to get their packages reviewed and sponsored. Obviously meanwhile there have been several new RFS sent to the list (looking at my list it must be around 200) and it would be nice if you could take a look at some of these. Thanks a lot for your contribution, Michael [1] http://lists.debian.org/debian-mentors/2010/10/msg00478.html pgpSsvqe7foZy.pgp Description: PGP signature
Re: RFS: polygraph
Hi Michael. On Sun, 3 Apr 2011 19:19:47 +0100, Michael Tautschnig m...@debian.org wrote: Hi Dmitry, Sorry for the huge wait for a first reply to your post. Dear mentors, I am looking for a sponsor for my package polygraph. * Package name: polygraph Version : 4.0.11-1 Upstream Author : The Measurement Factory, Inc. i...@measurement-factory.com * URL : http://www.web-polygraph.org * License : Apache-2.0 Section : net [...] I have now started to review this package and found at least two fundamental problems: Thanks for review. Note that the package has been already uploaded by Tollef Fog Heen. - The Apache license also gives a fairly precise description how it is to be applied to your work, as can be seen at the very end of http://www.apache.org/licenses/LICENSE-2.0.html The codebase of polygraph does not seem to follow this requirement, which (1) makes checking for proper licensing extremely hard and (2) may even be in violation with the license requirements. I see how the non-standard preamble can make licensing checking harder (though, I do not consider it extremly hard). Do you use some tool for license checking? Can you please explain how non-standard preamble violates the license terms? I do not see any requirements on the preamble format in the Apache license text. Note that the appendix which describes it goes after the END OF TERMS AND CONDITIONS line. Do you argue that non-standard preamble renders the package not apropriate for Debian? - Your package fails to build: Ssl.cc: In constructor ‘SslCtx::SslCtx(SslCtx::SslProtocol, const String)’: Ssl.cc:33:27: error: ‘::SSLv2_method’ has not been declared Other than that the package looks fine to me, but given this FTBFS this review remains very incomplete. Yep, I am aware of the issue. It was broken by OpenSSL 1.0 upload to unstable. SSLv2 is disabled now, hence the build failure. See Debian bug #589706 [1]. The package was building fine in unstable just few days ago. I will prepare a new package soon. Regards, Dmitry [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706 Best regards, Michael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zko7xjap@gmail.com
Re: RFS: mediadownloader (retry)
Hi, I am looking for a sponsor for my package mediadownloader. * Package name: mediadownloader Version : 1.5.0-1 Upstream Author : Marco Bavagnoli lil.dei...@gmail.com * URL : http://mediadownloader.cz.cc * License : gpl3 Section : graphics It builds these binary packages: mediadownloader - Search, preview, download with Google Image and YouTube The package appears to be lintian clean. [...] That may well be true, but it doesn't even build: g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DPHONON_LIB -DQT_OPENGL_SUPPORT -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_PHONON_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtXml -I/usr/include/phonon -I/usr/include/qt4/QtWebKit -I/usr/include/qt4 -Imain -I/usr/include/qt4/phonon_compat -I/usr/X11R6/include -I.build -I.build -o .build/browse.o main/browse.cpp main/browse.cpp:20:20: fatal error: QWebView: No such file or directory Apart from this major problem, please consider the following changes, some of which I already suggested in an earlier review: - You might want to acknowledge several previous reviewers in your changelog. - debian/copyright: It would be nice if it were converted to DEP-5 format. - debian/rules: A debian/install (and maybe debian/dirs) should help to simplify your rules, and moving to the simplified debhelper-7 version would be even better. Best regards, Michael pgpegDbK7VdLQ.pgp Description: PGP signature
Re: RFS: bluecove, bluecove-gpl
Hi Chris, Sorry for the huge wait. [...] If these files completely lack copyright information, it might not even be legal to distribute them. The proper approach would definitely be to track down where they come from and fix the copyrightlicense information. Maybe they are part of some larger source package which has its license stated in a separate file!? Best regards, Michael I have contacted the developer but am quite confused with his response. You can see the thread here http://groups.google.com/group/bluecove-developers/browse_thread/thread/f28c13ae5a3e9d46 . If they created the files, they should also take their copyright. This would at least clarify who created them. Licensing might be free of choice as well; and with a copyright it would at least be clear with whom this is to be discussed, if debate is necessary. If you could get that fixed I'd offer to do another round of reviews. Thanks a lot, Michael pgplRvEiSZcvE.pgp Description: PGP signature
Re: RFS: sic (updated package/adoption)
On Thursday 31 March 2011 13:39:16 Jeroen Schot wrote: Dear mentors, Hi, sic- simple irc client (sic) The upload would fix this bug: 606083 (ITA) http://mentors.debian.net/debian/pool/main/s/sic/sic_1.1-4.dsc Looks good. Uploaded. Thanks for taking care of orphaned packages. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: polygraph
Hi Dmitry, Thanks a lot for the very quick reply. [...] Thanks for review. Note that the package has been already uploaded by Tollef Fog Heen. Oh, I must have missed that message, sorry. [...] I see how the non-standard preamble can make licensing checking harder (though, I do not consider it extremly hard). Do you use some tool for license checking? Indeed, it's the licensecheck tool. And indeed you'd be putting quite a lot less work on reviewers if some auto-checkable header were used. Can you please explain how non-standard preamble violates the license terms? I do not see any requirements on the preamble format in the Apache license text. Note that the appendix which describes it goes after the END OF TERMS AND CONDITIONS line. Do you argue that non-standard preamble renders the package not apropriate for Debian? I'm not sure. ftp-master will tell you, but you are probably right that this appendix is not part of the license and hence can safely be ignored. ftp-masters will let you know :-) - Your package fails to build: Ssl.cc: In constructor ‘SslCtx::SslCtx(SslCtx::SslProtocol, const String)’: Ssl.cc:33:27: error: ‘::SSLv2_method’ has not been declared Other than that the package looks fine to me, but given this FTBFS this review remains very incomplete. Yep, I am aware of the issue. It was broken by OpenSSL 1.0 upload to unstable. SSLv2 is disabled now, hence the build failure. See Debian bug #589706 [1]. The package was building fine in unstable just few days ago. I will prepare a new package soon. [...] Ok, as it has been uploaded already and you are aware of that problem that's ok then. Thanks a lot for your work, Michael pgpFp1qCwFAfI.pgp Description: PGP signature
Re: RFS: LeechCraft (second try)
Hi, Dear mentors, I am looking for a sponsor for my package leechcraft. * Package name: leechcraft Version : 0.4.55+88-1 Upstream Author : Georg Rudoy 0xd34df...@gmail.com * URL : http://leechcraft.org * License : GPLv3 Section : net [...] I've finally gotten around to start reviewing this package; its size make it pretty hard to review and I'd suggest that at least some of it is moved to a separate leechcraft-plugins package (after all, that should be the idea of plug-ins), not only for reviewing but primarily for re-uploads: if only some plug-in changes, why rebuild the entire framework? At least one major issue has to be fixed: src/plugins/eiskaltdcpp/eiskaltdcpp/ (and also a small number of files in other directories) has a lot of files without license and copyright information. Looking at the debian/ directory I see: - debian/copyright is incomplete (no short version of license text) and should be DEP-5 formatted. - debian/changelog: It's a bit odd to close the ITP with new upstream version (rather in this case this is the initial upload). Best regards, Michael pgp6gmroewVL5.pgp Description: PGP signature
Re: RFS: blankon (updated package)
Hi, Dear mentors, I am looking for a sponsor for the new version 2.0-1 of my package blankon. It builds these binary packages: gnome-icon-theme-blankon - BlankOn Ombilin icon theme for GTK+ 2.x [...] I'd generally be fine uploading this package, but I fail to understand why this theme *package* is called blankon whereas all the files it contains plus the theme name when installed are monde it seems!? Best regards, Michael pgp6Fz19b9qyF.pgp Description: PGP signature
Re: RFS: polygraph
On Sun, 3 Apr 2011 19:19:47 +0100, Michael Tautschnig wrote: * Package name: polygraph Version : 4.0.11-1 Upstream Author : The Measurement Factory, Inc. i...@measurement-factory.com * URL : http://www.web-polygraph.org * License : Apache-2.0 Section : net I have now started to review this package and found at least two fundamental problems: I wish all our fundamental problems were that easy :-) - The Apache license also gives a fairly precise description how it is to be applied to your work, as can be seen at the very end of http://www.apache.org/licenses/LICENSE-2.0.html The codebase of polygraph does not seem to follow this requirement, which (1) makes checking for proper licensing extremely hard and (2) may even be in violation with the license requirements. FWIW, Apache itself does not follow what you consider a license application requirement. For example, the very web page you linked to above, has no preamble and just says Copyright 2011 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 at the bottom. Moreover, Apache httpd sources use a different preamble as well (e.g., httpd-2.2.17/srclib/apr/mmap/unix/mmap.c -- the first file I checked). As for being extremely hard to check, it seems like an exaggeration. Would the following preamble really leave a lot of question with regard to the distribution license? /* Web Polygraph http://www.web-polygraph.org/ * (C) 2003-2006 The Measurement Factory * Licensed under the Apache License, Version 2.0 */ As you can see, Polygraph preamble uses the exact same text used by Apache site. That text is a part of what is recommended by Apache License; it just does not repeat what is already said in Apache License itself. IMO, we are not doing anything wrong here, but we should be pragmatic about this issue: Humans should have no problems, but if the problem is with automated tools used by Debian, we should try to accommodate them. There is probably some flexibility here because they apparently work fine with other packages using custom preambles, such as Apache httpd. For example, perhaps including the URL of the Apache license would be sufficient to pass those automated checks? Thank you, Alex. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d98e070.8030...@measurement-factory.com
Re: RFS: polygraph
Hi, [...] FWIW, Apache itself does not follow what you consider a license application requirement. For example, the very web page you linked to above, has no preamble and just says Copyright 2011 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 at the bottom. Moreover, Apache httpd sources use a different preamble as well (e.g., httpd-2.2.17/srclib/apr/mmap/unix/mmap.c -- the first file I checked). Indeed it does not use the suggested text, but it still uses a lot more text than polygraph does. As for being extremely hard to check, it seems like an exaggeration. Would the following preamble really leave a lot of question with regard to the distribution license? /* Web Polygraph http://www.web-polygraph.org/ * (C) 2003-2006 The Measurement Factory * Licensed under the Apache License, Version 2.0 */ The good thing is: polygraph seems to consistently use this text. Hence indeed it can be pretty easily checked by testing for this particular pattern. Yes, my statement might have been over-exaggerated, but at bit more of standardization whenever such proposals exist would help us all a lot. As you can see, Polygraph preamble uses the exact same text used by Apache site. That text is a part of what is recommended by Apache License; it just does not repeat what is already said in Apache License itself. I pretty much fail to see in what way it uses exact the same text - is it the words Licensed under ... you are referring to? Then at least you missing the first two lines of the Apache-proposed text, which is the copyright information. Here you are in fact certainly lacking sufficient information, because (C) is not generally equivalent to Copyright under all copyright laws. IMO, we are not doing anything wrong here, but we should be pragmatic about this issue: Humans should have no problems, but if the problem is with automated tools used by Debian, we should try to accommodate them. There is probably some flexibility here because they apparently work fine with other packages using custom preambles, such as Apache httpd. For example, perhaps including the URL of the Apache license would be sufficient to pass those automated checks? I'd suggest the following procedure: if this copyright/license statement gets ack'ed by ftp-master, i.e., polygraph is accepted into the archive, then this license header must be sufficient (not only for polygraph, but also for other packages). It's then time to file a bug against the devscripts package to acknowledge this fact. Thanks a lot, Michael pgpoh1FWmtDwS.pgp Description: PGP signature
Re: RFS: polygraph
On Sun, 3 Apr 2011 22:36:25 +0100, Michael Tautschnig m...@debian.org wrote: Hi, [...] FWIW, Apache itself does not follow what you consider a license application requirement. For example, the very web page you linked to above, has no preamble and just says Copyright 2011 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 at the bottom. Moreover, Apache httpd sources use a different preamble as well (e.g., httpd-2.2.17/srclib/apr/mmap/unix/mmap.c -- the first file I checked). Indeed it does not use the suggested text, but it still uses a lot more text than polygraph does. As for being extremely hard to check, it seems like an exaggeration. Would the following preamble really leave a lot of question with regard to the distribution license? /* Web Polygraph http://www.web-polygraph.org/ * (C) 2003-2006 The Measurement Factory * Licensed under the Apache License, Version 2.0 */ The good thing is: polygraph seems to consistently use this text. Hence indeed it can be pretty easily checked by testing for this particular pattern. Yes, my statement might have been over-exaggerated, but at bit more of standardization whenever such proposals exist would help us all a lot. As you can see, Polygraph preamble uses the exact same text used by Apache site. That text is a part of what is recommended by Apache License; it just does not repeat what is already said in Apache License itself. I pretty much fail to see in what way it uses exact the same text - is it the words Licensed under ... you are referring to? Then at least you missing the first two lines of the Apache-proposed text, which is the copyright information. Here you are in fact certainly lacking sufficient information, because (C) is not generally equivalent to Copyright under all copyright laws. IMO, we are not doing anything wrong here, but we should be pragmatic about this issue: Humans should have no problems, but if the problem is with automated tools used by Debian, we should try to accommodate them. There is probably some flexibility here because they apparently work fine with other packages using custom preambles, such as Apache httpd. For example, perhaps including the URL of the Apache license would be sufficient to pass those automated checks? I'd suggest the following procedure: if this copyright/license statement gets ack'ed by ftp-master, i.e., polygraph is accepted into the archive, then this license header must be sufficient (not only for polygraph, but also for other packages). It's then time to file a bug against the devscripts package to acknowledge this fact. I have looked at licensecheck. It matches the following regexp: /under the Apache License, Version ([^ ]+) \(the License\)/ Changing Licensed under the Apache License, Version 2.0 line to Licensed under the Apache License, Version 2.0 (the License) makes licensecheck detect both license and copyright correctly. IMO the licensecheck regexp should be improved. Regards, Dmitry Thanks a lot, Michael Non-text part: application/pgp-signature -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjtzxarv@gmail.com
Re: RFS: pms (updated package)
Hi Benoît, I am looking for a sponsor for the new version 0.42-0.1 of my package pms. It builds these binary packages: pms- Practical Music Search, an MPD client The package appears to be lintian clean. The upload would fix these bugs: 551619, 612192, 615003 This version was released in May 2010, and the current version in debian (0.41) is more than 18 months old. I opened a bug (#612192) back in February about the new upstream version, but the maintainer (cc'ed) didn't react. [...] May I ask you to follow MIA procedures as described in Section 7.4 of the Developer's Reference? I think you have already reached the point that you can safely contact m...@qa.debian.org with the effect that the package should get orphaned. You can then change this into an intend-to-adopt and upload a new version that also closes this ITA bug report. I'd then happily review your package (feel free to ping me in a separate mail) and subsequently upload it; but I won't do a straight away hijack :-) Best, Michael pgprhF9yBWel7.pgp Description: PGP signature
RFS: xmem: fixes FTBFS
Dear Mentors, I am looking for a sponsor for my package xmem. This upload fixes Bug #556712 (FTBFS / --no-add-needed) URL: http://devel.debian.tamay-dogan.net/debian/pool/main/x/xmem dget http://devel.debian.tamay-dogan.net/debian/pool/main/x/xmem/xmem_1.20-28+b1.dsc I would be glad if someone uploaded this package for me. Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsystems@tdnet France EURL itsystems@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
Re: RFS: 0ad
Scott Howard showard...@gmail.com writes: - As for inclusion in Debian: 0AD has some bundled library issues (e.g. fcollada). The fcollada issue has been mentioned on this list [1-2]. Basically fcollada was a library created by a company 10 years ago with a GPL license. Since then the company stopped maintaining it and removed it from their website. Many projects grabbed the latest release and forked it for their own needs. There are at least 4 major forks out there which are all hacked for individual projects (there are many other patched versions, but it's hard to keep track). I tried to merge all of the major changes together in a way that each project can use, but each fcollada library is pretty much an independent project now where significant work will be needed to get a single library that everyone can use. Debian requires one canonical library, and right now the only practical solution would be to have packages for each of the major forks (which over the past 10 years have grown incompatible with each other), but I don't think that is allowed. Debian doesn't *require* a single canonical library. It's just strongly preferred for security support. In this case, it sounds like what was originally one library has forked thoroughly enough to be four separate libraries. It's not an ideal situation, but I don't think this should block adding the software to Debian. That said, it would still be nice to fix the embedding of yet another gzip library. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o6ergxd@windlord.stanford.edu
What naming scheme should be used for the Swiss Ephemeris?
I am trying to package the Swiss Ephemeris in a way that will allow it to be included in all the various distros. Actually I hope to package all the free software astrology programs for the various distros. They all depend on the Swiss Ephemeris, so it must be first. It is unfortunate that the first package must be a library as I understand that libraries are the most difficult. The Swiss Ephemeris has been extensively used mostly in a WINDOWS environment and the upstream source is mostly concerned about that environment. Source tarballs are non-standard from a packaging standpoint. I plan to use the upstream's .h and .c files. I plan to replace the make system with autotools infrastructure and add packaging information for both debian and rpm based distros. I plan to get everything building on OBS, and then after some testing, get some people to help me get into the various distros. I do not want to modify the source, that is the .c and .h unless absolutely necessary to make things work. I am not an astrology programmer. Existing Linux programs, that link to the Swiss Ephemeris copy the source create a static library libswe.a and link to that. Existing source tarballs are named like this. swe_unix_src_1.67.00.tar.gz swe_unix_src_1.75.00.tar.gz swe_unix_src_1.76.00.tar.gz swe_unix_src_1.77.00.tar.gz The library has an entry point, swe_version that returns strings like this: 1.77.00 I have a note from the author saying No API is changed, i.e. old applications work find against newer libraries. I don't know if this has ever been tested in a Linux or UNIX environment as everyone has been linking staticly. I have read the section in Debian Library Packaging guide on package naming and what files go in what package. I have also read the GNU libtool manual on package versioning. But I am not sure I have understood it all. My questions are: 1) How should my source packages be named? Is swe_unix_src_1.77.00 OK? 2) How should by library package be named? I am sure it should start with libswe, but then I am not so sure. 3)How should my library -dev package be named? 4)what should my SONAME be? I am not sure how the versioning system used for packaging and libtools should interact with my upstream's versioning system which he has a lot invested in. 5)Should the library and its include files be in a subdirectory? I do not think people want include files from the Swiss Ephemeris in /usr/include Thank you for helping me. Many people currently spend a lot of money on proprietary astrology programs runing under proprietary OS. I feel that long term, free software astrology has great potential, because of its superior development model. sharing is better than hoarding. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: What naming scheme should be used for the Swiss Ephemeris?
On Mon, Apr 4, 2011 at 10:09 AM, Paul Elliott pelli...@blackpatchpanel.com wrote: 1) How should my source packages be named? Is swe_unix_src_1.77.00 OK? The source package name should be swe and the version number 1.77.00. 2) How should by library package be named? I am sure it should start with libswe, but then I am not so sure. Depends on the SONAME, see libpkg-guide for a regex that will give you the package name for a specific SONAME. 3)How should my library -dev package be named? libswe-dev unless the library has API versioning. 4)what should my SONAME be? The same as upstream. If upstream doesn't build a shared library or doesn't set the SONAME correctly then you should discuss that with upstream and ask them to maintain the SONAME properly. If they don't want to do that then use a Debian-specific SONAME. I am not sure how the versioning system used for packaging and libtools should interact with my upstream's versioning system which he has a lot invested in. Best talk to upstream to clarify that. 5)Should the library and its include files be in a subdirectory? I do not think people want include files from the Swiss Ephemeris in /usr/include That depends on the software. If there is just one public header then putting it in /usr/include directly would be fine. If there is more than one header I would suggest a subdir of /usr/include. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=a+xlq46sjp9rataskc9omz_t...@mail.gmail.com
Re: What naming scheme should be used for the Swiss Ephemeris?
On Sunday, April 03, 2011 09:25:18 pm Paul Wise wrote: On Mon, Apr 4, 2011 at 10:09 AM, Paul Elliott pelli...@blackpatchpanel.com wrote: 1) How should my source packages be named? Is swe_unix_src_1.77.00 OK? The source package name should be swe and the version number 1.77.00. If I change the name how will people know the original name of the pristine tarball? Or be able to verify that it has not been changed? 2) How should by library package be named? I am sure it should start with libswe, but then I am not so sure. Depends on the SONAME, see libpkg-guide for a regex that will give you the package name for a specific SONAME. 3)How should my library -dev package be named? libswe-dev unless the library has API versioning. 4)what should my SONAME be? The same as upstream. If upstream doesn't build a shared library or doesn't set the SONAME correctly then you should discuss that with upstream and ask them to maintain the SONAME properly. If they don't want to do that then use a Debian-specific SONAME. I am not sure how the versioning system used for packaging and libtools should interact with my upstream's versioning system which he has a lot invested in. Best talk to upstream to clarify that. I am not sure the upstream knows that sonames exist or wants to know. If I am creating the libtools infrastructure, am I not responsible for this? I don't think anyone ever used libtools on this software before. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: What naming scheme should be used for the Swiss Ephemeris?
On Mon, Apr 4, 2011 at 11:54 AM, Paul Elliott pelli...@blackpatchpanel.com wrote: If I change the name how will people know the original name of the pristine tarball? Or be able to verify that it has not been changed? If you are using the upstream tarball without repacking it then by looking at the watch file. Otherwise by looking at the get-orig-source target in debian/rules. I am not sure the upstream knows that sonames exist or wants to know. This is a good opportunity to teach them about libraries, if they reply saying they aren't interested then that is fine too, just make sure to use a Debian-specific SONAME. If I am creating the libtools infrastructure, am I not responsible for this? I don't think anyone ever used libtools on this software before. If you are maintaining a library in Debian you're responsible for ensuring proper ABI versioning and compatibility whether or not upstream has a SONAME or cares about libraries. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikdiaopyx5n1ev3ra9ry-6pxy1...@mail.gmail.com
