Re: Arm Elf Toolchain
Hi, On Tue, Sep 21, 2010 at 08:59:14PM +0100, Chris Baines wrote: I am building packages for the arm elf toolchain. Welcome to the club. Your laminated member card should arrive shortly. In the meantime, here[1] are some brochures. Simon :) [1] http://wiki.debian.org/EmdebianToolchain -- 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/20100922111009.ga27...@richter
Re: Type 3.0 (quilt) source packages aditional original tarballs
Hi, On Wed, Sep 01, 2010 at 01:37:37PM +0100, Chris Baines wrote: I think it should say something about the other original tarballs there as well. Is there anything I am missing? Look at my package foundry for an example on how to use multiple tarballs. Simon -- 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/20100901131300.ga21...@richter
Re: Multiple ITP's
Hi, On Mon, Aug 16, 2010 at 05:07:03PM +0100, Chris Baines wrote: ITPs are meant for coordinating work on packages not in the archive, i.e. where there is no Maintainer (capital M) yet. If an updated source package adds new binaries, there is no need for an ITP. By splitting down the base package I mean creating individual source packages for the component parts that build there own binary packages, this is because the component parts have separate version's. If it's the same software, then it is unlikely that someone else will want to package those separately from you (because there is already a version in the archive), hence no need to coordinate. Simon -- 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/20100817114531.gb27...@richter
Re: Multiple ITP's
Hi, On Mon, Aug 16, 2010 at 11:47:20AM +0100, Chris Baines wrote: In my attempt to update the Debian FlightGear packages I have decided it would be best to spilt the FlightGear base package down in to its different components to allow for easier setup. ITPs are meant for coordinating work on packages not in the archive, i.e. where there is no Maintainer (capital M) yet. If an updated source package adds new binaries, there is no need for an ITP. Simon -- 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/20100816113244.ga5...@richter
Re: RFS: icedove-imap-acl
Hi, On Tue, Aug 03, 2010 at 01:19:54PM +0200, Michael Fladischer wrote: http://mentors.debian.net/debian/pool/main/i/icedove-imap-acl/icedove-imap-acl_0.1.1-1.dsc Uploaded. Simon -- 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/20100804091145.gb11...@richter
Re: Source Packages (v3)
Hi, On Wed, Aug 04, 2010 at 12:50:28PM +0100, Chris Baines wrote: binutils_2.18.50.orig-armtc.tar.bz2 additional original archive gcc_4.3.2.orig-armtc.tar.bz2 additional original archive newlib_1.16.0.orig-armtc.tar.gz additional original archive That smells like an embedded code copy. Can you use binutils-source, gcc-4.4-source and newlib-source instead? Simon -- 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/20100804125016.gd13...@richter
Re: RFS: icedove-sieve
Hi, http://mentors.debian.net/debian/pool/main/i/icedove-sieve/icedove-sieve_0.1.10-1.dsc Looks good, uploaded. Simon -- 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/20100803104401.gb6...@richter
Re: Help with autoconf / libtool
Hi, On Wed, Jul 07, 2010 at 07:15:34PM +0200, Sebastian Harl wrote: libctapimkt_la_LDFLAGS = $(AM_LDFLAGS) -version-info @GENERIC_LIBRARY_VERSION@ Like that, except that $(AM_LDFLAGS) is implicit and doesn't need to be specified again here, and @GENERIC_LIBRARY_VERSION@ is not a standard name, but rather something the other projects that use it have defined in their configure.ac (and I'd hardcode it in the Makefile.am). Also, http://www.gnu.org/software/libtool/manual/html_node/Versioning.html is an important read. Simon -- 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/20100708075343.gb2...@richter
Re: Control which packages debhelper builds
Hi, On Tue, Jun 29, 2010 at 05:28:41PM -0400, Evan Kroske wrote: I'm packaging uClibc for in order to build a cross-toolchain. Note that there is an uclibc-source package in Debian already that is supposed to be used from toolchain builds (when building from scratch). Having packages for uClibc in Debian proper does not really make sense because uClibc uses a different ABI, and so their use would be limited to software that uses only functionality from libraries provided there. Instead, there are two families of architectures defined: uclibc-linux-* for systems with an MMU, and uclinux-* for systems lacking one. uClibc packages are going to be built for these architectures, and you can use dpkg-cross afterwards. In order to build the toolchain from source, I must build and install the uClibc development headers, build and install a bootstrap GCC, compile the uClibc core with the bootstrap GCC, build a final version of GCC connected to the uClibc core, and compile various uClibc host and target utilities with the final GCC. Indeed. This cannot be done within the packaging system easily, so the toolchain packages provide binary packages containing the source code. From the uClibc source, I must build three batches of packages: the uClibc dev headers, the uClibc core, and the uClibc utilities. How can I control which packages debhelper builds and how it builds them? Using separate rules for each, and debhelper's -p flag. Note that you will still need a script to go back and forth between packages, and there are other pitfalls there. Simon -- 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/20100629225614.ga26...@honey.hogyros.de
Re: RFS: netstat-nat (updated package, QA upload)
Hi, On Sun, Jun 27, 2010 at 11:44:18AM +0200, Johann Felix Soden wrote: netstat-nat - tool that display NAT connections What is the advantage over conntrack -L? Simon -- 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/20100628092737.ga4...@richter
Re: Asking for DMUA: Yes while seeking first sponsor
Hi, On Tue, Jun 15, 2010 at 10:14:54AM +0800, Paul Wise wrote: This isn't the only misuse of DMUA that exists, some people set it in their package instead of asking the sponsor to set it. Others go further and do not mention that in debian/changelog nor in their RFS mail. That is generally fine with me -- they need to set the flag on their side too, so I don't see the point why they shouldn't build the source package after doing that and thus saving me the (minimal) effort. I don't think it needs to be reflected in the changelog either, as it doesn't really concern the packaging as such, but only upload permissions (also, if I should set it, then I'd have to write the changelog entry, no?). Generally, RFS mails should never happen for DMUA packages. Simon -- 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/20100615110610.gb26...@richter
Re: build place cleanup
Hi, On Mon, Apr 26, 2010 at 08:39:23PM +0200, Christoph Biedl wrote: a while ago I learned at a place I cannot remember that the clean target should restore the build place, more precisely: The state created after an initial unpacking (dpkg-source -x or the like) and fakeroot debian/rules clean should be restored after a build (debuild or the like) and clean (again: fakeroot debian/rules clean) cycle. The state after unpacking is also the state before packing. That is, if you build a package twice, any files from the build left over after an invocation of the clean target will end up in the packaging diff (or stop the source package build). Simon -- 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/20100426224343.ga23...@honey.hogyros.de
Re: RFS: ipsec-tools - IPsec tools for Linux - racoon - IPsec IKE keying daemon
Hi, On Tue, Feb 23, 2010 at 12:10:53PM +0100, Stefan Bauer wrote: Wow, that was a quick upload. I hope i'm not in trouble now as i always got some hints on packaging in the past. Heh. IIRC, debhelper modified the upstream config.guess/config.sub files during build and that was a serious problem for lintian to keep them in diff. I hope that was correct. I don't know if the dh $* invocation updates these files, but individual dh_* programs never do. The rules you commented out update the files if (possibly) newer ones are available, which of course makes them show up in the diff. The best (and only) way to avoid that and still have them updated is to build-depend on autotools-dev, delete the files in the clean target and copy them unconditionally before running the configure script. This will still give warnings from dpkg-source (because it won't generate a diff for deleted files), but that can be safely ignored. Simon -- 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/20100223112037.ga13...@richter
Re: RFS: ipsec-tools - IPsec tools for Linux - racoon - IPsec IKE keying daemon
Hi, On Tue, Feb 23, 2010 at 10:43:36AM +0100, Stefan Bauer wrote: i would love to see someone could have a look at my recently uploaded package to mentors ftp-server and sponsor the upload for me please. The package had plenty of lintian errors and warnings as well as a few typos in source and manpages. Looks good, uploaded. I'd like to know why you commented out the bits that automatically update config.guess/config.sub, though. Simon -- 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/20100223110631.ga13...@richter
Re: RFS: ipsec-tools - IPsec tools for Linux - racoon - IPsec IKE keying daemon
Hi, On Tue, Feb 23, 2010 at 12:06:32PM +0100, Simon Richter wrote: Looks good, uploaded. Note that the archive is somewhat grumpy at the moment, so it will take some time until the package appears. Simon -- 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/20100223113916.ga13...@richter
Re: How to remove the relation between a file and a .deb package
Hi, On Wed, Feb 03, 2010 at 03:44:54PM +0100, M. Frey wrote: I got the Package A with the version 1.0 and 2.0. From version 2.0 on it's not necessary to keep track of the file fileB.txt. But I want to keep fileB.txt on the target system anyway. This means that systems that never had version 1.0 installed will be different from systems that were upgraded. The point of having a package manager is to avoid precisely this situation. What is the actual use case? What does fileB.txt actually do so that this is desired? Is there any key word in the control file? Or is there a special file, which lists dependencies to delete? No, dpkg removes any files that are no longer part inside the tar file embedded in the package (i.e. the absence of the file in the new package is the trigger for its deletion). What happens if the same file is contained in two packages and one of them gets removed? Then those two packages would have had an agreement on who provides that file (i.e. one of them declares a Replaces: relation on the other), otherwise it would not be possible to install both packages at the same time. Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: youtube-dl (updated package, support for 1080p videos)
Hi, On Thu, Nov 19, 2009 at 05:45:44AM -0200, Rogério Brito wrote: |* include a better manpage. Closes: #553919. That appears to be broken. I get E: youtube-dl: empty-manual-page usr/share/man/man1/youtube-dl.1.gz W: youtube-dl: manpage-has-bad-whatis-entry usr/share/man/man1/youtube-dl.1.gz Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: youtube-dl (updated package, support for 1080p videos)
Hi, On Thu, Nov 19, 2009 at 11:39:46AM -0200, Rogério Brito wrote: dget http://mentors.debian.net/debian/pool/main/y/youtube-dl/youtube-dl_2009.09.13-2.dsc | * include the DMUA: yes field. Sneaky. :) Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: youtube-dl (updated package, support for 1080p videos)
Hi, On Thu, Nov 19, 2009 at 12:22:18PM -0200, Rogério Brito wrote: | * include the DMUA: yes field. Sneaky. :) Oh, that was something that I talked about with some other developers. It really seem that the opinions on this are divided... :-/ It's fine with me, otherwise I wouldn't have uploaded the package like this. I just wanted to comment on that DMUA had not been set in the last version of the package I saw. :) Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS (3rd try after 2nd unanswered): wmaker-data (updated package)
Hi, On Wed, Nov 18, 2009 at 09:44:49PM +0100, Noel David Torres Taño wrote: Reject Reasons: wmaker-data_0.9~3-3.dsc refers to wmaker-data_0.9~3.orig.tar.gz, but I can't find it in the queue or in the pool. wmaker-data_0.9~3-3.dsc refers to wmaker-data_0.9~3.orig-iconsPaul.tar.gz, but I can't find it in the queue or in the pool. Yes, your package has a Debian revision of -3, so my initial build did not include the orig source. I've rebuilt and reuploaded with -sa now. Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS (3rd try after 2nd unanswered): wmaker-data (updated package)
Hi, On Tue, Nov 17, 2009 at 05:44:39PM +0100, Noel David Torres Taño wrote: I am looking for a sponsor for the new version 0.9~3-3 of my package wmaker-data. My usual sponsor Mr. Oboukhov seems not to be available. He uploaded the package previously but dak didn't accept it because it is format 3.0 . Since 3.0 seems to be available now, I would like this version to be uploaded to the Archive to allow me to continue improving the package. Uploaded. There is a lintian warning that a build dependency on a recent enough version of debhelper is missing, this should be fixed in the next upload (also, you might want to replace dh_clean -k with dh_prep). Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: xiterm+thai (updated package)
Hi, On Thu, Jul 30, 2009 at 06:50:41PM +0700, Neutron Soutmun wrote: I am looking for a sponsor for the new version 1.09-2 of my package xiterm+thai. Done. Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: scim-input-pad
Hi, * Package name: scim-input-pad Could you also Cc pkg-ime-de...@lists.alioth.debian.org on input method related packaging, so the IME team knows what is going on? Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: scim-tables-indonesian
Hi, * Package name: scim-tables-indonesian Could you also include pkg-ime-de...@lists.alioth.debian.org when asking for sponsors for input method related packages in order to get the IME team on board? Simon -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: VCS-Git branch
Hi, how can I specify the branch in debian/control VCS-Git? The upstream branch is master and the debian branch has the name debian. I want that debcheckout will checkout debian instead of master. Not sure if debcheckout handles this correctly, but git's syntax for cloning a specific branch is to append a hash (#) sign and the branch name (i.e. git://example.com/foo/bar.git#baz) Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: executable scripts in debian/
Hi, I need to run a script as part of debian/rules. I can't rely on it being executable when unpacked, since dpkg-source doesn't preserve the mode. Set the mode from the clean target. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: boolstuff - library for operating on boolean expression binary trees
Hi, Miriam Ruiz wrote: * Package name: boolstuff Version : 0.1.11 Uploaded. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: scim-kmfl-imengine
Hi, Doug Rintoul wrote: * Package name: scim-kmfl-imengine Version : 0.9.6-5 Upstream Author : Doug Rintoul [EMAIL PROTECTED] * URL : kmfl.sourceforge.net * License : GPL Section : utils It might be a good idea to coordinate this with the IME packaging group. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mailscanner (updated package) 3rd try
Hi, Simon Walter wrote: I am looking for a sponsor for the new version 4.64.3-1 of my package mailscanner. What's wrong with this package, why is no-one willing to sponsor it? Willing, yes; however it is a pretty complex package. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: esmtp (updated package)
Hi, José Fonseca wrote: I'd appreciate if a DD could sponsor the upload of esmtp (user configurable relay-only MTA): Done. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP bugs
Hi, Pierre THIERRY schrieb: Among my 5 packages waiting at mentors.d.n, only the two more recents close ITP bugs. Would it be better practice if I issue a new Debian revisions for the 3 others after opening an ITP bug, with a changelog closing the latter? ITP bugs are not required. It is customary to use them as an advisory lock when packaging something, but for example if you are packaging your own software or are otherwise reasonably sure that noone else is working on that package, there's no need to file one. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/control: `Suggests: package [arch]' possible?
Hi, Cyril Brulebois wrote: A solution would be to use control.in, but that's quite overkill for that particular use. The proper solution would be a substvar. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dtc (updated package)
Hi, Thomas Goirand wrote: I am looking for a sponsor for the new version 0.26.4-1 of my package dtc. It's been now a long time that I'm searching for a sponsor, as my old sponsor decided to stop sponsoring completely. Oh yay, I can foresee a lot of fun. dtc is also used for the device tree compiler, a compiler that creates OpenFirmware device trees on systems that do not use OF (passing a device tree is a requirement for current Linux on powerpc). Does your package contain a binary named dtc? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing transition stuff in debhelper scripts after which time?
Hi, Justin Pryzby wrote: You can drop such things in uploads to unstable after they're included in a stable release. Upgrades across releases are not tested and are officially not supported though AFAIK the reasons are largely undocumented. I think it's roughly the same situation as for downgrades: It would nevertheless be a nice thing if people would not deliberately break upgrades just because there is no requirement for upgrades anymore. To be honest, I was pretty annoyed when I had to switch my unstable system to stable when sarge came out in order to get the kernel version that was regarded as the new minimum to install further versions, and there was not even a safeguard in place that made sure that unstable-unstable upgrades crossing the kernel version in stable at this time were correctly rejected. . maintainer scripts may not support things; this is basically so maintainers are allowed to drop support for ancient things and not have unmanagably large and difficult to test, unmaintanble cruft; However you can create sections in the maintainer scripts, with the first section being active only if the last configured version (which you are told) is lower than the stable version, doing an upgrade to whatever the stable version expected, and the next section going from there to the current state. Since both of these are supposed to be idempotent on their own, this is no more difficult to maintain than a version that only supports upgrades from the latest stable. . Package control file; including in particular the dependency fields: Conflicts, Depends, Provides (?), Pre-Depend plus Replaces. Dependencies on versions earlier than [old]stable are often dropped. It's only unfortunate that control files afaik still don't support comments to document why the versions and things were there with which to being. I'd only drop things that are relevant only to stuff older than oldstable; I believe we could make an automated check for that (i.e. leave everything as it is, unless the versioned dependency will always be met even in oldstable). The dependency fields help a lot in telling the package manager that it should not try something that is unsupported. Debian's renowned stability across upgrades doesn't come from nowhere. . The package itself; eg. it might contain logic to upgrade the format of its datafiles but not for every historic version and bugs therein. It might make sense to have a Pre-Conflicts (for lack of a better word) field that could be used to say this package does not support upgrades from versions earlier than x. I'm not entirely confident current conflict resolvers could handle such a situation gracefully though. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autoconfigurable package: how to build two configurations?
Hi, Felipe Sateler wrote: Actually, you could use different build directories: [...] This way you don't need to erase one version to build the other. Yes, that is in fact preferable, as building can happen without root privileges that way. Back when I maintained it, python-imaging used to build like that. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dfu-programmer
Hello, Andrew Straw wrote: * Package name: dfu-programmer Version : 0.4.0-1 Upstream Author : Weston Schmidt [EMAIL PROTECTED] * URL : http://dfu-programmer.sourceforge.net/ * License : GPL Section : devel I am interested in this package, and would like to subscribe to your newsletter. I don't see any major showstoppers besides the sid distribution and the copyright file that Nico already mentioned. The diff is a bit large due to rerunning autoconf, is that really necessary (there is no need to remove the spec file, as long as it is not installed, which seemed like the only change to the build system)? The description should probably read ...an USB... and would ideally have a few paragraph breaks. Not using debhelper is fine with me. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: aiccu (updated package)
Hi, Vincent Bernat wrote: I am looking for a sponsor for the new version 20070115-0.2 of my package aiccu. Has this been uploaded already? No, it hasn't. Have you seen my other message? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: aiccu (updated package)
Hi, Vincent Bernat wrote: I am looking for a sponsor for the new version 20070115-0.2 of my package aiccu. Has this been uploaded already? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Signing the package
Hello, Prasad Ramamurthy Kadambi schrieb: Is it OK if I sign package.deb leaving out .dsc and .changes file ? There is a provision to do that, however that is optional and currently pretty much unsupported (in fact IIRC there is a hook that auto-rejects signed packages these days). Take a small look at the .dsc and .changes files, then it should become clear to you why these (and only these) are signed. The method I normally use is to build with dpkg-buildpackage -rfakeroot -us -uc and then, after all lintian/linda tests have run and I'm happy with the package (for example, one should check that the package is not empty, happens even to the best of us, and lintian does not warn about this because there may be valid reasons to do so), then I invoke debsign on the .changes file (if I want to upload the package), or on the .dsc (if I want to publish it, but not upload to Debian). Note that signing the .changes file includes signing the .dsc, as it only makes sense to upload sources that are also signed. Also Should I sign .orig.tar.gz ? That happens implicitly by signing the .changes which includes a checksum of the .orig.tar.gz. Simon signature.asc Description: OpenPGP digital signature
Re: Question about linux-wlan-ng-firmware in main
Hi, Goswin von Brederlow schrieb: But does it have any use without the non-free firmware? Only then can you close an eye and let it stay in main due to its other functions. Yes: Loading free firmware. Whether such a thing exists is largely irrelevant; for the loader, it is just data, and we do not discriminate on fields of endeavour (i.e. it is fine to copy your non-free data around as you like it, even into your hardware if you so choose). A downloader package is a bit of grey area; much like a typical contrib package, it has some more-or-less hardcoded string that points to non-free data; it does not, however, depend on anything outside of main to function (since main is enough to get a network up and running, and the web service, while not dealing with free software, is not Debian's concern as it is only between the user and the company publishing the data files). The real problem with firmware in my opinion is that it ignites a flamewar between people that don't really care whether they have free software as long as it works, and free software purists that want to be able to change their entire system, including the firmware. The former group usually emphasizes that our priority are our users, the latter our priority is free software. We have yet to find a sane middle ground; largely because it would probably be display a dialog educating the user that they are now leaving the wonderful world of free software where you can expect the development team to consist of actual humans that reply to bug reports, and entering the evil corporate dystopia where emails are answered by 'your opinion is very important to us' -- and this would upset both groups (You zealots should not pester the users with your ideology all the time vs. Yeah, as if somebody read all those messages). Good ideas welcome. Simon signature.asc Description: OpenPGP digital signature
Re: Question about linux-wlan-ng-firmware in main
Hi, As I understand it, the sole purpose of this package is to download non-free firmware. This fits into 'contrib', not 'main', since it depends on non-free software for its ultimate operation. Packages like this are given as an example of packages for contrib. From Policy 2.2.2: Hm, that is close to the case of mISDN's loadfirm utility. The consensus back then was that splitting off a (free) firmware loader from a free package was not worth the effort required (after all, we're not violating licenses here); also IMO it is a bit counterproductive, as people wishing to write free firmware would have to get the firmware loader from contrib then. Simon signature.asc Description: OpenPGP digital signature
Re: A list of common gotchas in Debian packaging
Hello, Florent Rougon schrieb: The threshold where commented lines get unacceptable is IMHO way before they cause terrible difficulties. You *could* read a newspaper article in which every other line is an ad written in red ink, but given the choice between that and a normal article, what would you choose? The point is that in the normal case, I would do what makes the package more maintainable for me, as the maintainer. Some people prefer to have clean as a double-colon rule, scattered across the rules file, because then you have functional blocks that are self-contained. Other people believe that the clean rule is a functional block in itself and should be self-contained. I'm not going to argue in favour of one or the other (in fact I use both, depending on circumstances), and I would prefer if it would remain the way it is now rather than being told to use the One True Way[1]. Simon [1] While we are at it, could we force elmo to use debhelper for binutils? I'm trying to prepare a patch against it and it would be so much easier if the package used debhelper. We can't? Bummer. signature.asc Description: OpenPGP digital signature
Re: debian/rules::dh_* comments as rejection criteria
Hello, Florent Rougon schrieb: I'd say that if you're ready to sacrifice understanding of your package in order to spare 15 seconds, you should probably spend your time on something else than official Debian packages... Exactly. So in order to understand my own packages better I leave the dh_* calls in, commented out so I can grep for them and see that they are disabled. Being a DD, I think I should be able to make that judgement for myself. Simon signature.asc Description: OpenPGP digital signature
Re: A list of common gotchas in Debian packaging
Hello, Panu Kalliokoski schrieb: Some issues seem to come up time and again when somebody inspects RFS'd packages. Some of these are not breaches of policy but simply bad practices, like leaving quoted dh_* commands in debian/rules. I do that all the time. It is much easier to see that a program is not being run if it is explicitly commented out rather than just not there, as Makefiles tend to be executed in interesting nonlinear ways, and it doesn't really hurt either. Even the slowest of our buildds can skip over these lines in less than a second, while if I screw up with these lines I'm wasting a lot more autobuilder time, archive bandwidth etc.[1] Simon [1] I'm half-joking here (I also throw out the commented-out dh_* lines when I get around to it). The point I'm trying to make is that there is such a thing as personal style, and sometimes a solution that appears suboptimal to you might be easier to work with for the actual maintainer, so I wouldn't attempt to micromanage here. It is an entirely different thing for corner cases that may lead to packages misbehaving; for example I consider the -$(MAKE) distclean line in the clean target of a lot of packages a bug because it will not clean up if the toplevel Makefile goes missing. signature.asc Description: OpenPGP digital signature
Re: Adopt new package Wormux
Hi, Bernhard R. Link schrieb: http://jean.parpaillon.free.fr/wormux/wormux_0.7-1.dsc http://jean.parpaillon.free.fr/wormux/wormux_0.7.orig.tar.gz http://jean.parpaillon.free.fr/wormux/wormux_0.7-1.diff.gz The md5sum of the wormux_0.7.orig.tar.gz is different from the md5sum of the wormux-0.7.tar.gz on the upstream website, though the contents seem to be the same. Better use the original one. Huh? The original .tar.gz matched the md5sum in the .dsc for me. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tnef -- Tool to unpack MIME application/ms-tnef attachments
Hi, Paul Wise schrieb: * debian/control: need an extra space before Homepage (see the devref 6.2.4), may as well remove the extra / from the end of the URL. No. The / at the end is usually important, although a number of web servers hand out redirects (i.e. one extra round trip) if you omit it. * debian/control: hmm, not sure if the Section is correct. I think utils or perhaps otherosfs would be more appropriate - compare with orange or unshield / etc. Well, mail would be fine IMO, since this type of file is usually found in emails. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adopt new package Wormux
Hello, artefact schrieb: I need a sponsor. Here is the source package: http://jean.parpaillon.free.fr/wormux/wormux_0.7-1.dsc http://jean.parpaillon.free.fr/wormux/wormux_0.7.orig.tar.gz http://jean.parpaillon.free.fr/wormux/wormux_0.7-1.diff.gz The packaging is quite good, although I get a bit more lintian errors: E: wormux_0.7-1_powerpc.changes: bad-distribution-in-changes-file UNRELEASED W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/wilberteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/konqiteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/snortteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/tuxteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/thunderbirdteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/phpteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/workraveteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/gnuteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/firefoxteam/config.xml W: wormux-data: executable-not-elf-or-script ./usr/share/games/wormux/skin/nupikteam/config.xml W: wormux: binary-without-manpage wormux E: wormux: FSSTND-dir-in-usr usr/man/ W: wormux: package-contains-upstream-install-documentation usr/share/doc/wormux/INSTALL W: wormux: extra-license-file usr/share/doc/wormux/COPYING.gz E: wormux: menu-item-missing-required-tag needs /usr/share/menu/wormux:1 E: wormux: whitespace-after-continuation-character /usr/share/menu/wormux:6 E: wormux: bad-test-in-menu-item /usr/share/menu/wormux:6 E: wormux: changelog-file-not-compressed ChangeLog There are some minor nits as well, for example you delete a file called #CONFIGURE-STAMP# in the clean target, and the build complains about a missing config.rpath. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of GnuWin32 source packages
Hi, Volker Grabsch wrote: However, your idea was my first thought. But it is naive, and leads to bigger problems. Please take a look into the other threads about gnuwin32. Here's a short summary: 1) Debian isn't intended to produce cross compile libraries and/or compilers. Even as separate packages there is a good chance the majority of Debian developers don't want them beeing included into Debian. Indeed, but your proposal does not solve that. What would be a real solution is to treat Win32 as a separate architecture, for which packages are always cross-compiled (at least in the beginning). People wishing to use the packages would use dpkg-cross to generate packages they can install on their development systems, and the packages would only be listed in the package list for the win32 arch, so no overhead for the ordinary user. 2) Convincing each Debian maintainer of these libs to include an extra binary target will be very hard, and the project as a whole may fail if only one of them doesn't like it. Indeed, and this would only be a stopgap solution, but it's better than duplicating source packages. 3) It's much work for a Debian maintainer to keep track with the mingw32 builds. Some packages are prepared to produce lots of binaries compiled with different ./configure options. But most of them aren't, so it'll compilicate their debian/rules. Also, all these libs would need a build-dependency on the mingw32 package. Indeed. I think in the long run a separate architecture would be preferable. 4) Versions: It's much better when the packages use the same version the GnuWin32 project uses. For instance, a Windows user will be able to get the DLLs (and other runtime stuff) from there, and is able to run my cross compiled EXE. True; however especially the libraries you are talking about (libz, libpng, ...) had security issues in the past which required a bugfix release. Having to apply the fix to two different versions doubles the work of the security team. In the long run, a lot of free software projects strive for their own obsolescence. If a porting patch is accepted by the upstream developers, and there are a few test cases in place to catch regressions, all that remains to be done is to protect the project from optimizations from excited Gentoo people. :-) However, if there are differences between GnuWin32 and the Debian cross compiled packages, one may have to ship own DLL files of that library along with the program which is not desirable. On Windows, you already are in DLL hell, so shipping all DLLs you need and installing them in your program directory is a wise thing to do. 5) Remember: You want to cross compile. So the Debian cross compiling should stay as close as possible to the packages one would normally use with MinGW under Windows. True. The long term solution -- new architecture -- does that. 6) It add in general more work to more persons, than to simply use the GnuWin32 source packages as upstream source. The GnuWin32 people *are* already a kind of distribution ... compared to Debian they are organized quite simple, but they already *do* have some kind of package formats and package maintainers. I figured we could just assimilate them. :-) Why should I ask 10 or 20 busy Debian maintainer to duplicate work that is already done by the GnuWin32 project? Because it is, in the long run, duplication of work already, and both projects could benefit from synergy (I feel dirty for saying that word now) effects. If the patches are so intrusive that they break regular builds then they are not fit for production use IMO. This is really the minor problem. But even if there were such patches, what about packages that compile *only* in MinGW? What's about packages which use the win32 API and never *intended* to be portable? Such libraries may be interesting, too. Indeed, and nothing stops you from supplying those, as they are not in Debian already. Simon signature.asc Description: OpenPGP digital signature
Re: Handling of GnuWin32 source packages
Hi, Volker Grabsch wrote: I'm trying to build Debian cross compiled packages of win32 libraries. As upstream sources I use the (already patched) sources from the GnuWin32 project. (http://gnuwin32.sourceforge.net/) IMO what would make more sense is to try to get the patches integrated into the regular libpng package, so that it can build a cross development package as well (like wxwidgets can, for example). That would make it incredibly easier for the security team to handle this as only one source package needs to be updated. If the patches are so intrusive that they break regular builds then they are not fit for production use IMO. Simon signature.asc Description: OpenPGP digital signature
Re: Doing a proper package split (cream)
Hello, Christoph Haas wrote: 'cream' is a package with a lot of documentation. Until version 0.33 I had all the files in a single package. Now in 0.34 I want to split off the documentation so i have cream (main) and cream-doc (documentation). That only makes sense when the documentation is large and the package has arch-specific components. Since both packages are arch:all, at least in the control file you posted, I doubt it is worth it. Conflicts: cream(0.34) Replaces: cream(0.34) If there is no functional conflict, you can omit the Conflicts: here, as you are merely replacing files in the old version. This would, however, allow a situation where the new docs and the old programs are installed. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Hi, Hendrik Sattler wrote: there is still no sponsor for these packages, so this is another post to find sponsors for obexobex. Uploaded now. Had trouble with my smartcard reader. Simon signature.asc Description: OpenPGP digital signature
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Hi, Hendrik Sattler wrote: Really? I thought PUSH was pretty much a different protocol, with a different purpose, on a different channel, just using the same object format. So to replace ussp-push, you can simply use the obexftp options -H -U none And maybe omit the -l option in this case. If the phone still differs, define the proper bluetooth channel. Ah, okay. So ussp-push could be replaced by a shell script wrapper? :-) Simon signature.asc Description: OpenPGP digital signature
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Hello, Hendrik Sattler wrote: Is the API/ABI sufficiently stable? I see that the Debian patch introduces a new parameter to a function. This is inside the apps/ subdirectory which is not part of the lib. The patch was already in the openobex-apps package and I took it over since it still applies. The referring changelog entry from openobex-apps: * Apply patch to enable control of creator ID with irobex_palm3. Thanks to Bruno David Rodrigues. (Closes: #185833) Ah, okay. Like I said, I only glanced at the package. That leaves the question if the previously seperated changelogs should be included? It would help to have it documented somehow, not as if I would ever read a file called README. Intention was to leave package in there current state and address the presently filed bugs after the first upload. I can live with that, but expect a long delay in NEW if the diff is huge and/or complicated. Some people actually read them, I was told. 1. If it's going to end up in a separate package anyway, there is no point in pulling in source code from other projects as a patch. I didn't but upstream did. Previously, upstream seperated the source in three packages but gave up on that with the current release (it is a configure parameter now to build the apps). Yes, but it shows up as added files in the Debian patch, which it shouldn't IMO, especially if it builds upon a library. It is already in the upstream source. See http://sourceforge.net/project/showfiles.php?group_id=8960package_id=9047 and compare versions 1.1 and 1.0 (1.0.1 was not packaged). Okay, so it would be safe to remove the source code from the Debian patch? Other DDs told me that shipping the seperated patches with the package is actually wanted. That leaves only one more copy in the .pc subdir. However, deleting it means that if someone else works on an additional patch, he has to re-do all previous ones (as that is how quilt works). Thus the only fix would be to not use quilt at all. Hrm, would it be possible to try to get the functional patches integrated upstream? I tend to just leave them in the Debian patch and not do any further tracking on them, then silently rejoice when uupdate tells me that hunks have been ignored. Also, there still are a number of lintian warnings. W: openobex-apps: binary-without-manpage irobex_palm3 W: openobex-apps: binary-without-manpage irxfer W: openobex-apps: binary-without-manpage obex_tcp W: openobex-apps: binary-without-manpage obex_test Those are mentioned in the TODO file of that package. It needs some work, sure. If you require that before first upload, then I'll do that. However, I'd rather move that to -2. No problem. If I were to say otherwise, people would point at my packages. duckingrunning What about the linda-warning?: W: libopenobex; Paketversion 1.1-1 ist geringer als 1:1.0.0-rel-3. I was under the assumption that I don't have to take the epoch over to the new package (binary package names are different, source package name is different). However, the linda test may be broken. Yes, the linda test probably goes through the changelog only, which is the only thing it can do, as it cannot check whether the package built different binaries before. Did really all of the binary package names change? I could see a bit of merit in getting this package into unstable sooner than later, to allow the depending packages to adapt and bugs be ironed out before the release. As I don't see any policy violations or regressions from a quick glimpse over the package, I might be persuaded to upload this still (after a more thorough check) and file bugs for the issues remaining. Great. Don't miss the updated version (note: package version did not change!). Okay, but it won't be until later this evening or probably tomorrow as I'm pretty busy during the week. If someone else wants to go ahead in the meantime, please drop me a line. I also plan on packaging other OBEX related packages, e.g. wnpp bug #238314. Are you by chance interested in taking over ussp-push as well? I am not sure as obexftp can do the same thing by now (and qobex, too) when using no uuid. However, I'll take a look at it, maybe there's more to it than the description says. Really? I thought PUSH was pretty much a different protocol, with a different purpose, on a different channel, just using the same object format. Simon signature.asc Description: OpenPGP digital signature
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Hi, Hendrik Sattler wrote: I didn't but upstream did. Previously, upstream seperated the source in three packages but gave up on that with the current release (it is a configure parameter now to build the apps). Yes, but it shows up as added files in the Debian patch, which it shouldn't IMO, especially if it builds upon a library. Ok, I'll remove them the .pc directory Cannot quilt clean up patches that are no longer needed? Yes, the linda test probably goes through the changelog only, which is the only thing it can do, as it cannot check whether the package built different binaries before. Did really all of the binary package names change? For the previous library: yes. The now two additional packages previously had: openobex-apps (1.0.0-rel-6) ircp (0.3-2) Should be ok. Indeed. I think this warning can be ignored, and if it persists in the next version, silenced with an override. Really? I thought PUSH was pretty much a different protocol, with a different purpose, on a different channel, just using the same object format. As I said, I'll have a look at it. The effects on my hardware (several Siemens mobile phones) is the same for both. Ah. For me (using a Nokia) there is quite a difference: Stuff transferred via obexftp shows up in the filesystem, objects received via PUSH show up in Received messages and I'm asked what to do with them. Thus, I have less of an issue allowing anyone to send me stuff like vcards via PUSH, because the system keeps track of what items I have already seen. Simon signature.asc Description: OpenPGP digital signature
Re: first package pcftisio
Hi, Cedric BRINER wrote: after searching for a copyright, I sent him an email about it: There is not copyright on pCFITSIO. No guaranties either :-) so I was wondering, if such kind of 'NO COPYRIGHT' can be included in debian ? Sure. It's public domain. I'd write a small blurb into the copyright file that says that you contacted the author for clarification, quotes the email and states that this has been interpreted that as placing the software in the PD, then sign the entire thing to testify that you have actually done all that stuff. Simon signature.asc Description: OpenPGP digital signature
Re: RFS: libopenobex (also includes openobex-apps and ircp)
Hello, Hendrik Sattler schrieb: The new package can be found at: http://www.stud.uni-karlsruhe.de/~ubq7/debian/ The source package got renamed (libopenobex1.0 - libopenobex) as it was once (in oldstable) and the binary packages got renamed, too (libopenobex-1.0-0 - libopenobex1). The naming is thus consistent with the libpkg-guide. Is the API/ABI sufficiently stable? I see that the Debian patch introduces a new parameter to a function. I also notified the maintainer of ircp but did not get any answer so far. However, I included any patches of the previously seperated packages. The patches are handled by quilt (no build-time patching). There are two issues I have with that: 1. If it's going to end up in a separate package anyway, there is no point in pulling in source code from other projects as a patch. I believe this to be too broad a change for a simple package. If it is a separate project, it is a separate package. If it is not, it should be contained in the upstream source already (on the very extreme side of that, when I packaged spandsp I packaged the library on its own and added the example code, a bunch of asterisk plugins, by creating a tarball from the loose files that were on the author's website). 2. Every file that is added is contained three times in the diff (look at the diffstat output), once for quilt's hidden directory, once for debian/patches and once for the actual file being patched. Also, there still are a number of lintian warnings. I hope that someone can sponsor this new version; getting obexftp-0.19 also uploaded would be a bonus :) I could see a bit of merit in getting this package into unstable sooner than later, to allow the depending packages to adapt and bugs be ironed out before the release. As I don't see any policy violations or regressions from a quick glimpse over the package, I might be persuaded to upload this still (after a more thorough check) and file bugs for the issues remaining. I also plan on packaging other OBEX related packages, e.g. wnpp bug #238314. Are you by chance interested in taking over ussp-push as well? Simon signature.asc Description: OpenPGP digital signature
Re: RFS: softgun -- An ARM system emulator
Hi, Claudio Matsuoka wrote: As I'm working with embedded stuff on NetSilicon hardware ATM I'd be interested in sponsoring this package. Eugeniy reviewed the package and found some issues, I'd be thankful if you could test the emulator and see if there are any additional problems. I'm currently going through my todo list and found this message on it. What is the current status of softgun for Debian? Simon signature.asc Description: OpenPGP digital signature
Re: No official upstream sources archive, only tagged SVN directory
Hi, Ivan Dubrov wrote: First solution is to simply export the tagged directory and archive it and remove binary artifacts during the build process. However, disadvantages are obvious - larger size and odd binaries (these funny dll's are definetly not needed). On the other hand, packaging the exported directory is rather natural way to create upstream source package, I think. Yes, definitely. Bonus points if there is a command that rebuilds the same archive (you may want to use the -n argument to gzip to avoid storing a timestamp then). Simon signature.asc Description: OpenPGP digital signature
Re: RFS: hibernate
Hi, Cameron Patrick wrote: My usual sponsor can no longer upload for me as he has tendonitis. Is anyone else willing to upload a new release of hibernate for me? It's a relatively small package. Done. Simon signature.asc Description: OpenPGP digital signature
Re: sysinfo upstream tarball problems
Hi, Adriaan Peeters wrote: W: sysinfo source: configure-generated-file-in-source config.log How can I resolve this without an override? Not at all. It's an error upstream has made, but unless it affects the build in a harmful way (which I doubt) I would just leave it at that and ignore the warning until upstream releases a fixed package. Furthermore I had to rerun automake because the original Makefile installed extra doc files under /usr/doc/sysinfo. Is this the correct solution or should I remove the files after running upstream make? Both solutions are correct, modifying the Makefile is easier to understand for someone else looking at the package and will also show a conflict if upstream fixes it so you know when to remove the workaround. So IMO that one is preferable. Simon signature.asc Description: OpenPGP digital signature
Re: sysinfo upstream tarball problems
Hi,
Adriaan Peeters wrote:
sysinfodocdir = ${prefix}/doc/sysinfo
sysinfodoc_DATA = \
README\
COPYING\
AUTHORS\
ChangeLog\
INSTALL\
NEWS
EXTRA_DIST = \
$(sysinfodoc_DATA)\
How should I advise upstream to fix this (and remove the files
from /usr/doc/sysinfo)?
Upstream should just be aware that noone has ever heard of $(prefix)/doc
being used for anything, especially not the INSTALL file. :-)
For the package, I think it is best if you just remove the entire block
and install README and NEWS by hand or via dh_installdocs and ChangeLog
via dh_installchangelogs. COPYING, AUTHORS and INSTALL are not
interesting, the former because debian/copyright already summarizes
them, the latter because the package is already installed.
Simon
Simon
signature.asc
Description: OpenPGP digital signature
Re: packages size versus files under dpkg control
Hi, Norbert Preining wrote: 2) Install a compressed definition file and create the pfb files at package installation time, then deleting the definition file. Hrm, doesn't that happen automatically on first use? Simon signature.asc Description: OpenPGP digital signature
Re: RFC/RFS: scim 1.2.3-1 -- an input method platform
Hi, My usual sponsor, Osamu Aoki, has been busy these days and can't do the sponsor work this time, so I am asking for a sponsor here. Also since this package is quite complicated and this upload involves both a new upstream (with SONAME bump) and the C++ transition, any comments on my packaging will be appreciated. The package 1.2.3-1 I've made are at http://www.mems.rice.edu/~minghua/debian/ and there is also an extracted directory for anyone who prefer to browse through. I am going to take a look at this tonight or tomorrow. Simon signature.asc Description: OpenPGP digital signature
Re: RFS: softgun -- An ARM system emulator
Hi, Claudio Matsuoka wrote: * Package name: softgun Version : 0.10 Upstream Author : Jochen Karrer [EMAIL PROTECTED] * URL : http://softgun.sourceforge.net/ * License : GPL Description : ARM system emulator As I'm working with embedded stuff on NetSilicon hardware ATM I'd be interested in sponsoring this package. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gfpoken (Re: Upcoming removal of orphaned packages)
Hi, Bas Wijnen schrieb: I need a sponsor for uploading. Anyone interested? Here. Simon signature.asc Description: OpenPGP digital signature
Re: RFS: esmtp - User configurable relay-only MTA
Hi, My sponsor for this package so far, Matthias Urlichs, has been unreachable for quite some time now. So I'd like for a DD to sponsor this package (temporarily or not). I'm interested. I hope I can look at the package today, but I cannot promise it ATM. Simon signature.asc Description: OpenPGP digital signature
Re: RFS : libflash -- GPL Flash (SWF) Library
Nobuhiro Iwamatsu wrote: I am looking for a sponsor libflash( source package ) . Here. Where can I find your packages? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: x-no-session-manager - restore default X behavior with gnome/kde installed
Hi, 'update-alternatives --config x-session-manager' This could be a wishlist bug for X. IMO, the choice of the session manager should be made by the user that logs in, not by the admin. One less question for the admin, one extra point for the powerusers who know what they are doing. Simon (who is very happy that the number of xclocks being started for him is constant) signature.asc Description: OpenPGP digital signature
Re: RFS: (2nd try) bmon - Command-line bandwidth monitor and rate estimator
Hi, Reto Schuettel schrieb: I've talked with the upstream author and he refuses to maintain the soname during the 0.x developing phase of libnl. So I've come to the conclusion that at the moment it would be better to release bmon without libnl support. Perhaps somebody else is able to package it in a acceptable way someday (or I will be ;)). You could package a static build of libnl and omit the shared library, which is usually the way to go with unstable ABIs. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy concerning files used by postinst but not to be installed
Hi, I would like to use them in the postinst script to upgrade the database automatically. So, I have to carry those files in the .deb. Ship them in /usr/share, ask the admin whether she wants the upgrade performed automatically and if she says no, point to the directory where they were installed. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-ime-devel] -dev package dependency policy
Hi, The -dev package should depend on all -dev packages for libraries that the library package depends upon... But this is actually a very strict requirement (since you are pulling in many -dev packages you don't even know through dependecies). And it generates quite long Depends: list for -dev packages. From what I see, few -dev packages follow this practice. For example, our scim-dev package don't do this. The point behind this requirement is that library header files include library header files from other libraries, and so depend functionally on the presence of these header files, even if this dependency may not be required for the part of the API the application is using. Thus, the application's build-dependencies would be too broad (since it doesn't use the library, why should it depend on it), but nevertheless neccessary since the unneeded parts in the header file would still fail to compile. The only packages that can be omitted here are build-essential packages. In essence, this means that if your library depends on another library and this is reflected in the header files (which it obviously is), your -dev package needs to depend on the other library's -dev package. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-ime-devel] -dev package dependency policy
Hi, The -dev package should depend on all -dev packages for libraries that the library package depends upon... But this is actually a very strict requirement (since you are pulling in many -dev packages you don't even know through dependecies). And it generates quite long Depends: list for -dev packages. From what I see, few -dev packages follow this practice. For example, our scim-dev package don't do this. The point behind this requirement is that library header files include library header files from other libraries, and so depend functionally on the presence of these header files, even if this dependency may not be required for the part of the API the application is using. Thus, the application's build-dependencies would be too broad (since it doesn't use the library, why should it depend on it), but nevertheless neccessary since the unneeded parts in the header file would still fail to compile. The only packages that can be omitted here are build-essential packages. In essence, this means that if your library depends on another library and this is reflected in the header files (which it obviously is), your -dev package needs to depend on the other library's -dev package. Simon
Re: configure/build/install
Hi, my question is whether you can see any problems arising from this? or does it not matter if i have NOOP configure and build targets and do everything in the install target before debianising in binary-*? Only the targets mentioned in the policy are required, i.e. there is no need to even have a configure target. A lot of package maintainers have it for their convenience. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 signature.asc Description: Digital signature
Re: configure/build/install
Hi, my question is whether you can see any problems arising from this? or does it not matter if i have NOOP configure and build targets and do everything in the install target before debianising in binary-*? Only the targets mentioned in the policy are required, i.e. there is no need to even have a configure target. A lot of package maintainers have it for their convenience. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 signature.asc Description: Digital signature
Re: Interaktive questions in postrm purge allowed?
Hi, So is it ok to ask interactive questions in postrm when called with purge? It depends. If you use debconf, you should really ask that question when the package is removed, not when its conffiles are purged, though you may only want to delete the database files on purge. The rationale for this is that there is no mechanism in place to guarantee that a certain other package, in this instance debconf, is installed at purge time (though the assumption may be fairly safe). The least bad solution I can see is to ask at remove time, store the result outside of debconf (/etc/default) and kill the db on purge if requested. As the script is not called with purge in a normal apt-get upgrade run I can see no problems, do you? In an environment where database servers are set up and reconfigured with values from an external database (e.g. an ISP that gives you preconfigured boxes and installs certain packages on the customer's request), I can see a use for an automated script calling your postrm with purge. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 signature.asc Description: Digital signature
Re: Interaktive questions in postrm purge allowed?
Hi, So is it ok to ask interactive questions in postrm when called with purge? It depends. If you use debconf, you should really ask that question when the package is removed, not when its conffiles are purged, though you may only want to delete the database files on purge. The rationale for this is that there is no mechanism in place to guarantee that a certain other package, in this instance debconf, is installed at purge time (though the assumption may be fairly safe). The least bad solution I can see is to ask at remove time, store the result outside of debconf (/etc/default) and kill the db on purge if requested. As the script is not called with purge in a normal apt-get upgrade run I can see no problems, do you? In an environment where database servers are set up and reconfigured with values from an external database (e.g. an ISP that gives you preconfigured boxes and installs certain packages on the customer's request), I can see a use for an automated script calling your postrm with purge. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 signature.asc Description: Digital signature
Re: Howto make one Debian package out of 2 source tar.gz?
Frank, The program is distributed as two tar.gz files, molmol-2k.2.0-src.tar.gz and molmol-2k.2.0-doc.tar.gz. However they have to make one Debian Package (or at least be mixed), since after compilation everything that comes out of the src.tar.gz is the single binary, whereas manpages, internal menu files and so on are in the doc.tar.gz. Hrm, what about leaving the source trees separate and simply creating two packages that depend on each other? I mean, when upstream thinks that a separate -doc package is warranted, it might be a good idea to make the docs a separate arch-indep package and reduce archive size this way. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp0.pgp Description: PGP signature
Re: Howto make one Debian package out of 2 source tar.gz?
Frank, The program is distributed as two tar.gz files, molmol-2k.2.0-src.tar.gz and molmol-2k.2.0-doc.tar.gz. However they have to make one Debian Package (or at least be mixed), since after compilation everything that comes out of the src.tar.gz is the single binary, whereas manpages, internal menu files and so on are in the doc.tar.gz. Hrm, what about leaving the source trees separate and simply creating two packages that depend on each other? I mean, when upstream thinks that a separate -doc package is warranted, it might be a good idea to make the docs a separate arch-indep package and reduce archive size this way. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpsfveiMI4rg.pgp Description: PGP signature
Re: Correct version numbering for pre-Versions?
Frank, Of course I wouldn't want to put such a pre-Version into the Debian archive. If it works at least to some extent, it may be a good idea to put it in the archive, accompanied by an R bug saying that this is not yet suitable for release (which will keep it out of testing). Exposure to a technology-savvy audience (unstable users) is a good thing for stuff in the final bug-fixing phases. So, as long as upstream hasn't agreed to change this (or even stated they never will), what should I do? In the special case where I came across this, it's even worse: The development versions for to-be 1.2 are numbered 1.2-1 to 1.2-4, and I fear the release will be just 1.2. The usual way is using pre1, pre2, ..., rc1, ..., rel. As a matter of fact, this sorts nicely. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpOZjqvqwPSw.pgp Description: PGP signature
Re: Request for a sponsor - lMule (Linux port of eMule)
Hi Igor, I'm looking for someone who is interested in sponsoring the following of my Debian packages: - lMule (1.1.12) which basically is a Linux port of the eMule Client. lMule is a file sharing tool a la KaZaA. It has a GPL license which makes it really attractive ;-) can do, but probably not in the next few days (have to work from 3 PM 'till 5 AM now, and am going to Frankfurt the next day) Your package is Debian native (i.e. you only have a .tar.gz). Would it be possible to have the original archive and a diff on the server? Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp0.pgp Description: PGP signature
Re: Request for a sponsor - lMule (Linux port of eMule)
Hi Igor, I'm looking for someone who is interested in sponsoring the following of my Debian packages: - lMule (1.1.12) which basically is a Linux port of the eMule Client. lMule is a file sharing tool a la KaZaA. It has a GPL license which makes it really attractive ;-) can do, but probably not in the next few days (have to work from 3 PM 'till 5 AM now, and am going to Frankfurt the next day) Your package is Debian native (i.e. you only have a .tar.gz). Would it be possible to have the original archive and a diff on the server? Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp09F9GwkAeG.pgp Description: PGP signature
Re: Closing bugs in unreleased packages?
Bob, I am assuming here that accepted into the Debian archive refers to 'sid' in this case. Therefore all bugs are closed when the package is in 'sid' even though this fix may never reach 'stable'. A user of the released Debian may never see the fix. No. For each bug, you will have to check the stable and unstable versions for this bug, with the Version field of the report being a hint on how to reproduce easily. If the bug appears in multiple dists, clone it, tag the bugs appropriately and prepare multiple patched versions closing the bug in the changelog. The bug against stable will remain open until the package is included in a point release, so users will still see it. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp0.pgp Description: PGP signature
Re: Closing bugs in unreleased packages?
Bob, I am assuming here that accepted into the Debian archive refers to 'sid' in this case. Therefore all bugs are closed when the package is in 'sid' even though this fix may never reach 'stable'. A user of the released Debian may never see the fix. No. For each bug, you will have to check the stable and unstable versions for this bug, with the Version field of the report being a hint on how to reproduce easily. If the bug appears in multiple dists, clone it, tag the bugs appropriately and prepare multiple patched versions closing the bug in the changelog. The bug against stable will remain open until the package is included in a point release, so users will still see it. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp9rkIoDxjwm.pgp Description: PGP signature
Re: How to obtain current package version number?
Marc, Well, I wouldn't have posted without first consulting policy and developer's reference. Section 6.4 doesn't seem to document any maintainer script of the package being installed being called with the new version number as a parameter, so I was actually hoping that dpkg sends that information in the environment or somewhere else. You can pull it in using a substvar, I think. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp0.pgp Description: PGP signature
Re: How to obtain current package version number?
Marc, Well, I wouldn't have posted without first consulting policy and developer's reference. Section 6.4 doesn't seem to document any maintainer script of the package being installed being called with the new version number as a parameter, so I was actually hoping that dpkg sends that information in the environment or somewhere else. You can pull it in using a substvar, I think. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpLhG6HSGz76.pgp Description: PGP signature
Re: How to obtain current package version number?
Marc, You can pull it in using a substvar, I think. That sounds interesting. Can you elaborate? I know that I can use substvars in my control file to get automatic dependencies on the libs I use, but how does that transfer to maintainer scripts? Never mind, I just looked it up. Substvars are only allowed for control, .dsc and .changes files. So probably you will have to go through sed if you really need it. Usually, your postinst should compare the old version to one that a particular change was made in and make that change if necessary. Comparing to the current version is bad, since maintainer scripts are supposed to be idempotent anyway. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgproy4HhS1dE.pgp Description: PGP signature
Re: New Maintainer ou New Developer
Agney, I'm looking for information about debian developer/maintainer. A maintainer is someone who maintains a package, while a developer has an account on the Debian machines and permission to upload. These two are basically distinct (i.e. you can maintain a package without being a developer and you can be a developer but work on the web pages instead of doing packaging). I read in debian page that the only way to became maintainer is developing some nice program, but I have two friends that are only who make the .deb package. Developing software is a different thing, although you probably need some programming experience in order to maintain a package properly. The situation is: I don't have a nice package develped by me, but I would like to maintain some package from someone who don't have interest or time to maintain it on debian. How can I find a package to maintain or how can I submit a package (not mine) ? This is good. Debian actually has a lot of packages that noone cares about. Have a look at http://qa.debian.org/ , it should be a good starting point, and of course you should have read the documentation at http://www.debian.org/devel . If you are interested in a particular orphaned package, just go ahead and file an ITA (Intent To Adopt), exact instructions are on the WNPP pages on qa.debian.org. To upload, you will need a sponsor, just ask again here on debian-mentors. ps: I have my gpg key signed by a debian developer (Gustavo Noronha Silva [EMAIL PROTECTED]) This is good. If you want to become a Debian Developer, you should probably add yourself to the NM queue at http://nm.debian.org/ , but you should wait until you have some package that's ready to be uploaded (you will need a so-called advocate, which is a DD who confirms your application, and you far easier get that confirmation when you've already done something). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp0.pgp Description: PGP signature
Re: New Maintainer ou New Developer
Agney, I'm looking for information about debian developer/maintainer. A maintainer is someone who maintains a package, while a developer has an account on the Debian machines and permission to upload. These two are basically distinct (i.e. you can maintain a package without being a developer and you can be a developer but work on the web pages instead of doing packaging). I read in debian page that the only way to became maintainer is developing some nice program, but I have two friends that are only who make the .deb package. Developing software is a different thing, although you probably need some programming experience in order to maintain a package properly. The situation is: I don't have a nice package develped by me, but I would like to maintain some package from someone who don't have interest or time to maintain it on debian. How can I find a package to maintain or how can I submit a package (not mine) ? This is good. Debian actually has a lot of packages that noone cares about. Have a look at http://qa.debian.org/ , it should be a good starting point, and of course you should have read the documentation at http://www.debian.org/devel . If you are interested in a particular orphaned package, just go ahead and file an ITA (Intent To Adopt), exact instructions are on the WNPP pages on qa.debian.org. To upload, you will need a sponsor, just ask again here on debian-mentors. ps: I have my gpg key signed by a debian developer (Gustavo Noronha Silva [EMAIL PROTECTED]) This is good. If you want to become a Debian Developer, you should probably add yourself to the NM queue at http://nm.debian.org/ , but you should wait until you have some package that's ready to be uploaded (you will need a so-called advocate, which is a DD who confirms your application, and you far easier get that confirmation when you've already done something). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp4Jrvsh0poD.pgp Description: PGP signature
Re: Build-Depends on source of a different package?
Andreas, If you're wondering: The package in question would be exim v4 with the exiscan patch applied. - It cannot simply be built from the exim4 source-package because the patch is released more often than exim itself (current-version is already 4.12-24). Hrm, what does it need the patch for. I can understand that configuration file changes might be needed, but a patch? Would it be possible (in cooperation with upstream) to split the package into stuff that can be applied upstream, does not change often and can be optionally switched on an off (stable API) and stuff that changes often and thus should not be compiled directly into a mission critical piece of software anyway? Since there will probably be multiple exim packages, this would effectively double their number again (exim4-tls-ldap-noexiscan, sigh). So it would be better to have a real virus scanner API and make exiscan plug into that instead of inventing workarounds for broken design. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpf1CGk0OmMN.pgp Description: PGP signature
Re: lintian warning: debconf-is-not-a-registry
Martin,
W: mcbsam: debconf-is-not-a-registry ./usr/sbin/mcbsam-configure
You should not use debconf outside of the config and postinst (and
possibly preinst) scripts. What you really mean to do is to merge the
setup script into the postinst and let the user reconfigure the package
with dpkg-reconfigure. The rationale behind this is that only at the
time the postinst is called from dpkg-{p,}reconfigure you are guaranteed
that the values the config script stored in the debconf db are still
there (dpkg-reconfigure will call the config script again).
Simon
--
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
pgp0.pgp
Description: PGP signature
Re: lintian warning: debconf-is-not-a-registry
Martin,
W: mcbsam: debconf-is-not-a-registry ./usr/sbin/mcbsam-configure
You should not use debconf outside of the config and postinst (and
possibly preinst) scripts. What you really mean to do is to merge the
setup script into the postinst and let the user reconfigure the package
with dpkg-reconfigure. The rationale behind this is that only at the
time the postinst is called from dpkg-{p,}reconfigure you are guaranteed
that the values the config script stored in the debconf db are still
there (dpkg-reconfigure will call the config script again).
Simon
--
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
pgpYiwziN9CiG.pgp
Description: PGP signature
Re: Writing front-ends for programs
Hi, I'm curius to know how to write user-friendly front ends to programs. I'm referring to programs like KPakage, GnoRPM, aptitude and dselect and the various setup utilities for the Apache server that wrap around a console based utility (rpm or dpkg, for example). aptitude sits on top of the apt library, which does all the talking to dpkg; dpkg itself has been designed to be called by other programs, specifically by dselect. dselect, on the other hand, uses the same code dpkg does. How do I design the console based programs? Think of the console app as a class in the frontend's design. I.e. it should have a small, clean interface, hide the implementation details and make sure it is always in a consistent state. If something goes badly wrong, it should indicate the error in an easily understandable way (return a nonzero exit code). It should have concurrency locks in the right places, to avoid multiple simultaneous callers from messing things up. Input and output channels should either transfer structured data, be unstructured or let the structured form define an exit to unstructured mode (and possibly with a transition back). Look at SMTP: The both sides talk structured command-response, but for actual data it switches to an unstructured mode, where a single dot switches back. If you have a structured mode, be sure that you need to enable it explicitly, and possibly that you can talk it over a separate fd (gpg --status-fd and dpkg --set-selections are examples here). Should I implement an extensive command line argument interface for them? Having everything as command line options is good, since sometimes someone may want to call programs from scripts. If your program manages a lot of state or for some other reasons has significant startup cost, give it an interactive mode with a structured interface so that you can start one and then talk to it until you are done. How do I parse the output produce? If it's structured, the usual parsing is good. scanf(), cin , split, etc. If the output is unstructured, don't bother parsing, as output changes with program version and locale. Instead, patch the program to accept some sort of --status-fd switch and make sure the fd gets flushed often enough or is unbuffered. What language is most suitable and easiest for writing the user-friendly interface (for instance, Tcl/Tk? Python?) ? Depends. Python and Perl both have a high startup cost, which is annoying on slower systems (reportbug takes about two minutes for the import statements on my system). On some occasions, I write the backend in C++ and the frontend in Java, so I can make the frontend an applet. In short, it varies. Performance, other than startup time, is seldom an issue, since the amount of data that the user can perceive is significantly lower than the amount of data almost any programming language can handle in a given timeframe. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg08615/pgp0.pgp Description: PGP signature
Re: Writing front-ends for programs
Hi, I'm curius to know how to write user-friendly front ends to programs. I'm referring to programs like KPakage, GnoRPM, aptitude and dselect and the various setup utilities for the Apache server that wrap around a console based utility (rpm or dpkg, for example). aptitude sits on top of the apt library, which does all the talking to dpkg; dpkg itself has been designed to be called by other programs, specifically by dselect. dselect, on the other hand, uses the same code dpkg does. How do I design the console based programs? Think of the console app as a class in the frontend's design. I.e. it should have a small, clean interface, hide the implementation details and make sure it is always in a consistent state. If something goes badly wrong, it should indicate the error in an easily understandable way (return a nonzero exit code). It should have concurrency locks in the right places, to avoid multiple simultaneous callers from messing things up. Input and output channels should either transfer structured data, be unstructured or let the structured form define an exit to unstructured mode (and possibly with a transition back). Look at SMTP: The both sides talk structured command-response, but for actual data it switches to an unstructured mode, where a single dot switches back. If you have a structured mode, be sure that you need to enable it explicitly, and possibly that you can talk it over a separate fd (gpg --status-fd and dpkg --set-selections are examples here). Should I implement an extensive command line argument interface for them? Having everything as command line options is good, since sometimes someone may want to call programs from scripts. If your program manages a lot of state or for some other reasons has significant startup cost, give it an interactive mode with a structured interface so that you can start one and then talk to it until you are done. How do I parse the output produce? If it's structured, the usual parsing is good. scanf(), cin , split, etc. If the output is unstructured, don't bother parsing, as output changes with program version and locale. Instead, patch the program to accept some sort of --status-fd switch and make sure the fd gets flushed often enough or is unbuffered. What language is most suitable and easiest for writing the user-friendly interface (for instance, Tcl/Tk? Python?) ? Depends. Python and Perl both have a high startup cost, which is annoying on slower systems (reportbug takes about two minutes for the import statements on my system). On some occasions, I write the backend in C++ and the frontend in Java, so I can make the frontend an applet. In short, it varies. Performance, other than startup time, is seldom an issue, since the amount of data that the user can perceive is significantly lower than the amount of data almost any programming language can handle in a given timeframe. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp6I3EkxurL8.pgp Description: PGP signature
Re: need help with bug #178837 (automake)
Frank, What do I have to change to be able to add -mieee on alpha, preferably from debian/rules, or configure ? Since this problem is not Debian specific, the best way would be to add it in the configure script if required (i.e. patch configure.in and submit upstream). There may already be some readymade testcase somewhere (- Google) that checks whether a given system needs -mieee or sth. like that (-mieee is like -fno-fast-math, IIRC). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpvbdgFCFZOy.pgp Description: PGP signature
Re: Packagin mozilla plugin
Celso, Option c) Create a mozilla-dev? package and use this one like build dependence Guess what? There is already a mozilla-dev package. :-) Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg08482/pgp0.pgp Description: PGP signature
Re: Packagin mozilla plugin
Celso, Option c) Create a mozilla-dev? package and use this one like build dependence Guess what? There is already a mozilla-dev package. :-) Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpBEej03Ntyk.pgp Description: PGP signature
Re: multiple binary package with different version-numbers?
Antoine, I am packaging OTTER, an automated theorem prover, and MACE, a model finder. The otter-3.2 sources come with mace-2.0 bundled in, so I naturally made a multiple binary package. Is mace available on its own? If so, you could package it separately and make otter use the mace package installed on the system, ignoring the bundled version (so you can update them independently). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg08464/pgp0.pgp Description: PGP signature
Re: multiple binary package with different version-numbers?
Antoine, I am packaging OTTER, an automated theorem prover, and MACE, a model finder. The otter-3.2 sources come with mace-2.0 bundled in, so I naturally made a multiple binary package. Is mace available on its own? If so, you could package it separately and make otter use the mace package installed on the system, ignoring the bundled version (so you can update them independently). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpk5g39sZeQE.pgp Description: PGP signature
Re: [mindas@ziedas.ktu.lt: Bug#177332: libphp-adodb on testing should be applied to the stable]
Hi, $updateSQL = $conn-GetUpdateSQL($rs, $record); gives me UPDATE FOO set bar=1. IMO this one justifies an upload into stable (severe data loss), but the fix should of course be backported. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp5t3cWWjxCf.pgp Description: PGP signature
Re: Best practices of GPG signing
Hi, On Wed, Dec 04, 2002 at 10:59:06AM -0800, Osamu Aoki wrote: 1) Should I gather signature for all active e-mail addresses? (Is signature only for [EMAIL PROTECTED] enough? Is the act of asking signer to sign alternative address considered useless request? Or is it worthy cause?) Of course more signatures are better, as the web of trust is also useful outside of Debian. 2) Should I print these alternative e-mail addresses on my Debian business card for the convenience of signer. (I never see that in my experience but people tends to have multiple uids.) Well, I have separate cards with all my uids and subkeys on them, which I use for signing purposes. Business cards are something different, I have different cards for different personalities of mine -- i.e. one with my private address, one for Debian, one for the uni, one for work, ... But I think this is sort of the German mentality to keep everything apart. 3) Is it a good practice to ask people who signed only old uid to sign new uid? (I do this with GPG signed mail.) I'd say it depends. It makes sense if you're going to make heavy use of the new uid, so people can easily validate it. 4) If someone who used only his ex-work address in GPG key, is it OK to sign his new uid by exchanging mail through different mail address but with properly signed mails? I think yes, because that should still be the same person, and if the key was stolen and someone is trying to get mails diverted, there should be a revocation around soon. 5) How important is the uid field? After all e-mail address can easily be spoofed. (For me, it looks totally secondary. Important thing is possession of the secret key.) Generally that's what the different levels of how you checked the uids mean. If you have seen the ID card, use level 2, if you've checked the mail address, use level 3. Where some years of correspondence replace pinging the account, at least for me. :-) Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg08050/pgp0.pgp Description: PGP signature
