Re: RFS: python-sclapp and pytagsfs (new packages) - trying again
Trying again for a sponsor. I've got comments and updated both the packages: - sclapp for a complete debian/copyright file, thanks Bernd Zeimetz (who gave me some useful comments but indicated he is busy right now to discuss the changes) - pytagsfs for a new upstream release. pytagsfs provides very cool functionality :) Both the packages are fairly simple (sclapp is a pure python module and pytagsfs needs it). http://mentors.debian.net/debian/pool/main/s/sclapp/ http://mentors.debian.net/debian/pool/main/p/pytagsfs/ Original RFS: http://lists.debian.org/debian-mentors/2008/03/msg00358.html Cheers, Giridhar PS: I am not subscribed to debian-mentors, please Cc: me on responses. On 08/04/01 02:17 +0530, Y Giridhar Appaji Nag said ... > Thanks to Bernd Zeimetz for comments, updated packages are available at > mentors.debian.net (the site is back up). > > http://mentors.workaround.org/debian/pool/main/s/sclapp/ > http://mentors.workaround.org/debian/pool/main/p/pytagsfs/ > > Giridhar > > On 08/03/31 23:16 +0530, Y Giridhar Appaji Nag said ... > > The packages are available at http://www.appaji.net/foss/debian/ (since > > mentors.debian.net is down, I am using my personal web space). -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
RFC: kgb -- Archiver for .kgb files (doesn't work on non-32bits archs, changes made to address that issue)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, This package is already in the archive, and I have DM upload rights for it. A few days ago I noticed this package doesn't work on non 32bits architectures so I've done a few changes to the package. The relevant part of changelog of the next upload is: * debian/test.sh: add a simple test suite to be run at the build target * debian/control: Build-Depend on gcc-multilib + Not building 64bits bins as the code is designed for 32bits archs The changes I made, as suggested by Goswin von Brederlow, until I get it to work on non 32bits archs were: adding a Build-Depends: gcc-multilib [amd64 kfreebsd-amd64 ppc64] calling gcc with -m32 So before I upload the package I'd like some feedback on the subject. Note: I added the simple test suite just to make sure the compiled binaries are ok, and prevent any similar problem (not knowing it doesn't work under non-32) in the future. 2nd note: the package is still Arch: any, as suggested by Goswin. The .dsc file can be found at: http://mentors.debian.net/debian/pool/main/k/kgb/kgb_1.0b4-6.dsc TIA. Kind regards, - -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH+DM1Yy49rUbZzloRAo0gAJ4lXN1cn0yWNSouA0ViuC1u+72MbwCggLhZ LiyvA6Rp58pMk32UaRn9nXU= =3ToV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unused libSM and libICE (was: Re: RFS: xiterm+thai)
On Tue, Apr 1, 2008 at 3:04 PM, Theppitak Karoonboonyanan
<[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 17, 2008 at 4:16 PM, Paul Wise <[EMAIL PROTECTED]> wrote:
>
> > dpkg-shlibdeps: warning: debian/xiterm+thai/usr/bin/xiterm+thai
> > shouldn't be linked with libSM.so.6 (it uses none of its symbols).
> > dpkg-shlibdeps: warning: debian/xiterm+thai/usr/bin/xiterm+thai
> > shouldn't be linked with libICE.so.6 (it uses none of its symbols).
>
> 'ldd -u -r /usr/bin/x*' shows that xiterm+thai is not the only
> one. Many other X apps have this problem as well.
Update: I've run this simple script to check all executables
and shared libraries installed in my machine which are linked
to libSM or libICE without using them:
---8<---
$ cat check-sm-ice
#!/bin/sh
check_sm_ice()
{
f=$1
unused=`ldd -u -r $f 2>/dev/null`
if echo $unused | grep libSM.so >/dev/null 2>&1 ||
echo $unused | grep libICE.so >/dev/null 2>&1
then
pkg=`dpkg -S $f | cut -d: -f1`
echo "$pkg:$f"
fi
}
for f in `find /usr/lib/ -name '*.so.*' -type f -print`; do
check_sm_ice $f
done
for f in `find /usr/bin/ -type f -print`; do
check_sm_ice $f
done
$ ./check-sm-ice | sort > unused-sm-ice
$ cat unused-sm-ice
abiword-gnome:/usr/bin/AbiWord-2.4
brasero:/usr/bin/brasero
dasher:/usr/bin/dasher
dia-gnome:/usr/bin/dia-gnome
ekiga:/usr/bin/ekiga
epiphany-gecko:/usr/bin/epiphany-gecko
epiphany-webkit:/usr/bin/epiphany-webkit
evince:/usr/bin/evince
evolution:/usr/bin/evolution
evolution:/usr/lib/evolution/2.12/libeabutil.so.0.0.0
evolution:/usr/lib/evolution/2.12/libeconduit.so.0.0.0
evolution:/usr/lib/evolution/2.12/libecontacteditor.so.0.0.0
evolution:/usr/lib/evolution/2.12/libecontactlisteditor.so.0.0.0
evolution:/usr/lib/evolution/2.12/libefilterbar.so.0.0.0
evolution:/usr/lib/evolution/2.12/libemiscwidgets.so.0.0.0
evolution:/usr/lib/evolution/2.12/libeshell.so.0.0.0
evolution:/usr/lib/evolution/2.12/libetable.so.0.0.0
evolution:/usr/lib/evolution/2.12/libetext.so.0.0.0
evolution:/usr/lib/evolution/2.12/libetimezonedialog.so.0.0.0
evolution:/usr/lib/evolution/2.12/libeutil.so.0.0.0
evolution:/usr/lib/evolution/2.12/libevolution-a11y.so.0.0.0
evolution:/usr/lib/evolution/2.12/libevolution-addressbook-a11y.so.0.0.0
evolution:/usr/lib/evolution/2.12/libevolution-addressbook-importers.so.0.0.0
evolution:/usr/lib/evolution/2.12/libevolution-calendar-a11y.so.0.0.0
evolution:/usr/lib/evolution/2.12/libevolution-calendar-importers.so.0.0.0
evolution:/usr/lib/evolution/2.12/libevolution-mail-importers.so.0.0.0
evolution:/usr/lib/evolution/2.12/libevolution-widgets-a11y.so.0.0.0
evolution:/usr/lib/evolution/2.12/libfilter.so.0.0.0
evolution:/usr/lib/evolution/2.12/libmenus.so.0.0.0
fontforge:/usr/bin/fontforge
fontforge:/usr/bin/mensis
fontforge:/usr/lib/fontforge/libgdraw.so.3.0.1
fontforge:/usr/lib/fontforge/libgutils.so.1.0.0
gnomebaker:/usr/bin/gnomebaker
gnome-cups-manager:/usr/bin/gnome-cups-add
gnome-cups-manager:/usr/bin/gnome-cups-icon
gnome-cups-manager:/usr/bin/gnome-cups-manager
gnome-mag:/usr/bin/magnifier
gnome-pilot:/usr/bin/gnome-pilot-make-password
gnome-pilot:/usr/bin/gpilot-applet
gnome-pilot:/usr/bin/gpilotd
gnome-pilot:/usr/bin/gpilotd-control-applet
gnome-pilot:/usr/bin/gpilotd-session-wrapper
gnome-pilot:/usr/bin/gpilot-install-file
gnome-power-manager:/usr/bin/gnome-power-manager
gnome-power-manager:/usr/bin/gnome-power-preferences
gnome-power-manager:/usr/bin/gnome-power-statistics
gnome-screensaver:/usr/bin/gnome-screensaver
gnome-utils:/usr/bin/baobab
gnome-utils:/usr/bin/gfloppy
gnome-utils:/usr/bin/gnome-dictionary
gnome-utils:/usr/bin/gnome-screenshot
gnome-utils:/usr/bin/gnome-search-tool
gnome-utils:/usr/bin/gnome-system-log
gnome-volume-manager:/usr/bin/gnome-volume-properties
groff:/usr/bin/gxditview
gthumb:/usr/bin/gthumb
gtranslator:/usr/bin/gtranslator
imagemagick:/usr/bin/animate
imagemagick:/usr/bin/compare
imagemagick:/usr/bin/composite
imagemagick:/usr/bin/conjure
imagemagick:/usr/bin/convert
imagemagick:/usr/bin/display
imagemagick:/usr/bin/identify
imagemagick:/usr/bin/import
imagemagick:/usr/bin/mogrify
imagemagick:/usr/bin/montage
imagemagick:/usr/bin/stream
libatspi1.0-0:/usr/lib/libcspi.so.0.10.11
libatspi1.0-0:/usr/lib/libloginhelper.so.0.0.0
libatspi1.0-0:/usr/lib/libspi.so.0.10.11
libbonoboui2-0:/usr/lib/libbonoboui-2.so.0.0.0
libbonoboui2-dev:/usr/bin/bonobo-browser
libbonoboui2-dev:/usr/bin/test-moniker
libgnomecupsui1.0-1c2a:/usr/lib/libgnomecupsui-1.0.so.1.0.0
libgnome-media0:/usr/lib/libcddb-slave2.so.0.0.0
libgnome-media0:/usr/lib/libgnome-media-profiles.so.0.0.0
libgnomesu0:/usr/bin/gnomesu
libgnome-window-settings1:/usr/lib/libgnome-window-settings.so.1.0.0
libgtkglext1:/usr/lib/libgdkglext-x11-1.0.so.0.0.0
libgtkglext1:/usr/lib/libgtkglext-x11-1.0.so.0.0.0
libgtkhtml3.14-19:/usr/lib/libgtkhtml-3.14.so.19.1.0
libmagick10:/usr/lib/libMagick.so.10.0.9
libmagick++10:/usr/lib/libMagick++.so.10.0.9
libmagick10:/usr/lib/libWand.so.10.0.9
libplot2c2:/usr/lib/libplot.so.2.2.2
li
Re: cowbuilder and --distribution experimental
Hi, > > > > > > experimental is not a complete distribution. You cannot just use > > > --distribution experimental. I think that you should use an unstable > > > chroot > > > and add to apt experimental sources. You will also have to provide a > > > correct /etc/apt/preferences (otherwise, experimental repository will not > > > be used). > > > > Actually, '--distribution experimental' is special-cased in pbuilder > > such that it should just work. '--distribution experimental' sets up > > internal flags such that it is interpreted as '--distribution sid' and > > special handling for experimental. > > Obviously, it doesn't. Because with properly set pinning, you wouldn't > have a problem with e2fsprogs/libuuid1 (which happens when trying to > install perl from experimental). Heh, I guess we have a different definition of 'properly'. pbuilder experimental usage assumes we can install everything from experimental and get done with it, but I assume there are some packages which don't go along with each other well. But that shouldn't make pbuilder work and cowbuilder not work. I'm confused. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: compiz-switch
On Fri, Apr 4, 2008 at 9:25 AM, Alessio Gaeta <[EMAIL PROTECTED]> wrote: > Description: Compiz-Switch provides a simple yet effective way to switch > between Compiz and the window manager of the desktop environment in use > on a single click. > > The package (not the software inside it! :) ) is quite trivial, but I > think it is very useful (and if you have an ATI with Compiz and fglrx, > is mandatory, to watch your videos easily...) I'm not a DD or DM, but i think the description c/should be improved ie: not using emoticons or parenthesis I've been told not to do stuff like that, so i recommend you to take my advice ;) -- JID: [EMAIL PROTECTED] BEGIN GEEK CODE BLOCK Version: 3.12 GCM/O d->dpu$ s-:- a-->a+++$ C+++ LU P+ L++ E W+++ N !o K w O !M !V PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e h!>h-- r>r+++ y+ END GEEK CODE BLOCK
Re: RFS: compiz-switch
> * Package name: compiz-switch 1) Your diff.gz modifies files out side debian/. Many sponsors will consider this a bad practise, so I suggest using a patch system like dpatch or quilt in order to reach more potential sponsors. 2) There is a debian/menu file. However dh_installmenu is not called. Why? 3) Your diff.gz looks like it is not properly cleaned as it ships a manpage in two formats. Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITR: xmlrpc-epi - copyright issues
Neil Williams wrote: > Copyright issues: > 1. The machine-interpretable copyright format is meant to be > hierarchical - Files: * should not appear before any other more specific > matches. i.e. exclude all the awkward files explicitly in turn, then the > last stanza is "everything else". That's not quite incorrect. Quoting the page: | Matches should be exclusive (a file can only match one rule). The final rule | that should be considered is the most specific one (the one that matches the | fewer files), or if this is ambiguous, the last one in the file. | | Thus, in this case of getopt.c, it is the second rule that has to be taken | into account: | | Files: * | Copyright: [the main work’s author] | License: [the main work’s license] | Files: getopt.* | Copyright: © 2000 the NetBSD Foundation, Inc. | License: other-BSD | [text of the NetBSD license] -- see shy jo signature.asc Description: Digital signature
Re: cowbuilder and --distribution experimental
On Sat, Apr 05, 2008 at 01:57:24PM +0900, Junichi Uekawa wrote: > Hi, > > > > Hi again mentors !!! > > > I've now a strange problem creating an experimental COW image. > > > > > > I use "cowbuilder --create --distribution experimental" but I obtain an > > > unmet error with e2fsprogs (PreDepends: libuuid1 (>= 1.34-1)). > > > libuuid1 package is correctly downloaded and configured on chroot > > > environment :( > > > > > > Same error overriding EXTRAPACKAGES with =libuuid1. > > > > experimental is not a complete distribution. You cannot just use > > --distribution experimental. I think that you should use an unstable chroot > > and add to apt experimental sources. You will also have to provide a > > correct /etc/apt/preferences (otherwise, experimental repository will not > > be used). > > Actually, '--distribution experimental' is special-cased in pbuilder > such that it should just work. '--distribution experimental' sets up > internal flags such that it is interpreted as '--distribution sid' and > special handling for experimental. Obviously, it doesn't. Because with properly set pinning, you wouldn't have a problem with e2fsprogs/libuuid1 (which happens when trying to install perl from experimental). Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mailscanner (updated package)
Hello Simon, On Do, 2008-04-03 at 22:57 +0200, Simon Walter wrote: > I am looking for a sponsor for the new version 4.68.8-1 > of my package "mailscanner". > > It builds these binary packages: > mailscanner - email gateway for virus scanning, spam and phishing detection > > The package appears to be lintian clean. > > The upload would fix these bugs: 469916, 472067, 472489, 472676 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/m/mailscanner > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/m/mailscanner/mailscanner_4.68.8-1.dsc > > I would be glad if someone uploaded this package for me. uploaded. -- Noèl Köthe Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: ITR: xmlrpc-epi - copyright issues
On Sat, 2008-04-05 at 10:47 +0100, Robin Cornelius wrote: > 1) It probably would be a very good idea to remove the expat source code > from upstream completely and ensure the code builds with the latest > expat from expat's upstream instead of carrying a specific copy. Agreed. > > Files: src/expat_compat.h src/compat.c > > Copyright: (C) 1997-2007 The PHP Group > > Licence: PHP-3.01 > > (src/compat.c is part of the packaged library as it is listed in > > src/Makefile.am under libxmlrpc_epi_la_SOURCES. src/expat_compat.h is > > not packaged in the -dev) > > Proposal - drop these files upstream and only use expat as the xmlparser > for now. That would make things a lot easier. > > Files: expat/* > > Copyright: (C) 1998, 1999 James Clark > > Licence: Mozilla Public License Version 1.1 or GNU General Public > > License > > (files not packaged, code not compiled) > > Proposal - drop these files upstream, and if necessary package them in a > separate tarball/zip for distros that don't necessary have expat available. Agreed. > > Files: scripts/cvs2cl.pl > > Copyright: (C) 1999 Karl Fogel <[EMAIL PROTECTED]> > > Licence: GPL-2+ > > (build tool? Robin? seems to be an upstream thing - again worth asking > > upstream not to package it in the released tarball). > > This should be (will be now) dropped from the source tarball and only be > in upstream > CVS as its a CVS changelog tool. OK. > Ok i think we can overcome the major problems fairly easily here to get > the package into an acceptable state. Long term the package needs to be > able to nativly use the libxml2 parser *without* that php compatibility > library. Agreed. > Short term i would like to remove all the php licensed code and the > ability to use libxml2. I will do this upstream then repackage for > debian. This will leave us with an xmlrpc-epi that can only be used by > GPL compatible code, which is probably the better state to be in rather > that a library that cannot be used by GPL code. > > Longer term use libxml2 and remove libexpat so that php5 can use the > library if they so wish. > > How does this sound? (and add that -dbg package, fix the changelog --closes entry and implement the autotools recommendation for debian/rules from the other email). That sounds perfect. Let me know when the new upstream needs a sponsor. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: ITR: xmlrpc-epi - copyright issues
Neil Williams wrote:
> On Thu, 2008-04-03 at 12:12 +0100, Robin Cornelius wrote:
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "xmlrpc-epi".
Hi Neil, thanks for your time on this.
>
> 2. expat - debian/copyright quotes this as being dual-licenced MPL or
> GPL but does not note that the expat code itself is neither compiled nor
> distributed in the Debian package, only in the upstream source. (It may
> be an idea to see if upstream would consider splitting it into a
> separate source tarball.) The problem is that GPL-2+ code cannot be
> compiled into (or linked against) a shared library that also includes
> code under the PHP licence and although the build does not do that, it
> also does not state that the expat code is not actually packaged. (The
> MPL is also incompatible with the GPL but that isn't a problem in your
> case. I must admit, I'm not sure if the MPL is compatible with the PHP
> licence.)
> http://www.gnu.org/licenses/license-list.html
1) It probably would be a very good idea to remove the expat source code
from upstream completely and ensure the code builds with the latest
expat from expat's upstream instead of carrying a specific copy.
2) the php licensed code is only required to use libxml2 and in fact
just provides API compatibility so that expat calls get translated into
libxml2 calls. This code could be entirely removed, thus removing all
php licences but would mean that libxml2 could not currently be used as
the xml parser. This is not necessarily an issue itself.
Its a case of either expat is used in which case no php licensed code is
required or its libxml2 which requires the php licensed compatibility file.
>
> 3. PHP-licenced code in a shared library. In effect, your package cannot
> be used by (i.e. linked against) any GPL code because it contains code
> under a licence that is not compatible with the GPL. That is a
> potential minefield for other packages wanting to use your library and
> needs to be spelt out in debian/copyright.
I think its better to remove this minefield completely upstream.
>
> All content relevant to these issues must be in debian/copyright -
> content anywhere else in the package will be ignored as far as
> acceptance by the ftp-masters is concerned. IMHO, that includes some
> statement that expat/* is not compiled or packaged for Debian and that
> there would be problems combining the expat/* code with the src/* code
> (which is why I find it strange that the two are packaged together).
>
> Files: src/expat_compat.h src/compat.c
> Copyright: (C) 1997-2007 The PHP Group
> Licence: PHP-3.01
> (src/compat.c is part of the packaged library as it is listed in
> src/Makefile.am under libxmlrpc_epi_la_SOURCES. src/expat_compat.h is
> not packaged in the -dev)
Proposal - drop these files upstream and only use expat as the xmlparser
for now.
>
> Files: expat/*
> Copyright: (C) 1998, 1999 James Clark
> Licence: Mozilla Public License Version 1.1 or GNU General Public
> License
> (files not packaged, code not compiled)
Proposal - drop these files upstream, and if necessary package them in a
separate tarball/zip for distros that don't necessary have expat available.
>
> Files: scripts/cvs2cl.pl
> Copyright: (C) 1999 Karl Fogel <[EMAIL PROTECTED]>
> Licence: GPL-2+
> (build tool? Robin? seems to be an upstream thing - again worth asking
> upstream not to package it in the released tarball).
This should be (will be now) dropped from the source tarball and only be
in upstream
CVS as its a CVS changelog tool.
>
> Quite a collection.
>
Ok i think we can overcome the major problems fairly easily here to get
the package into an acceptable state. Long term the package needs to be
able to nativly use the libxml2 parser *without* that php compatibility
library.
The main reason for this is php5 is a potential user of the library so
it looks like the incompatibilities between expats licence and php
licence are the reason php5 created the compatibility layer in the first
place and a reason why they use libxml2.
The ideal situation in this case IMHO is to have a xmlrpc-epi that
either php or GPL licensed code can linkto but this is going to take a
little work upstream so :-
This is my planned work flow :-
Short term i would like to remove all the php licensed code and the
ability to use libxml2. I will do this upstream then repackage for
debian. This will leave us with an xmlrpc-epi that can only be used by
GPL compatible code, which is probably the better state to be in rather
that a library that cannot be used by GPL code.
Longer term use libxml2 and remove libexpat so that php5 can use the
library if they so wish.
How does this sound?
> (On a better note, I've just got my laptop back from repair {new
> motherboard} and it's working fine - thanks for all your help with
> that!) :-)
>
Woot! thats great
Thanks once again.
Robin
signature.asc
Description: OpenPGP digital signature
