Bug#959013: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
FWIW, this looks good to me. This is a new upstream release, but it's a bug-fix only (adding a translation update at the same time seems fine). Is there a particular reason this should NOT be uploaded? -- Richard signature.asc Description: OpenPGP digital signature
Bug#659047: RFS: rpg - Readable Password Generator
What advantages does this program have over pwgen (which has been around for a long time and is already package)? -- Richard signature.asc Description: This is a digitally signed message part
Re: Bug#658959: RFS: phpvirtualbox-4.1
On Tue, 2012-02-07 at 01:12 +0200, Alexey Eromenko wrote: > To minimize confusion, I think it might be better to keep only one > version in Debian "main" -- the one that matches VirtualBox. It might be worthwhile to have a phpvirtualbox "meta" package which Depends: phpvirtualbox-4.1, Recommends: virtualbox-ose (>= 4.1). I'm not a DD and you should double-check Debian Policy first. If you're in touch with upstream, I'd like to see them version the URLs for their include files (Javascript, etc.). This could maybe be as simple as putting them all in a directory named (e.g.) 4.1.1. Otherwise, when you upgrade phpvirtualbox, your browser can have the old Javascript cached and things break. -- Richard signature.asc Description: This is a digitally signed message part
Re: RFS: rudeconfig
On Sun, 2012-02-05 at 20:59 +0530, Medhamsh wrote: > I have submitted an ITP for rudecgi parser lib for C++ and uploaded > the package to mentors(#658347). After that found all the components > of http://rudeserver.com to be interesting. Are you actually using these components in an application? If you're packaging them "just for fun", that's probably not the best use of your time or Debian's archive space, buildds, etc. -- Richard signature.asc Description: This is a digitally signed message part
Re: Moving cron job from daily to weekly
Perhaps you should use a cron.d file instead, as the admin could edit that. Richard -- 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/1322845599.23885.17.ca...@watermelon.coderich.net
Re: (future unblock) RFS: mobile-broadband-provider-info (updated package)
On Tue, 2011-01-04 at 10:52 +0530, Bhavani Shankar R wrote: > as the README > says its safe to update the package at any stage. Isn't this basically the same as saying, "We don't introduce bugs in our software."? If they put the wrong information into this package, wouldn't that break your mobile broadband connection just as if there was a kernel bug for your USB 3G modem? Richard signature.asc Description: This is a digitally signed message part
Re: package maintainer question
On Thu, 2010-09-09 at 02:50 +0200, Harald Jenny wrote: > I'm facing the problem that a package I maintain depends on a library whose > maintainer is either to busy or not interested providing a deb for the new > upstream version which would (hopefully) fix a serious bug in the library. IANADD, but... Have you filed a bug report with the appropriate priority for this issue? It sounds like this might be a release-critical issue. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: libaosd (updated package)
On Wed, 2010-07-28 at 02:36 +0300, Eugene Paskevich wrote: > On Tue, 27 Jul 2010 20:11:47 +0300, Paul Wise wrote: > > Why did you drop this line from debian/rules? > > > > rm -f config.sub config.guess > > I'm not sure why they are there to begin with. > These files are in orig tarball and are replaced with debian ones. > Why do they have to be removed on clean? They should be removed on clean so they don't show up in the package diff. Richard signature.asc Description: This is a digitally signed message part
Re: The use of epoch in version
On Thu, 2010-01-28 at 23:04 +0100, Mats Erik Andersson wrote: > Abondoning the tarball-in-tarball form of the > orig.tar-file would change the upstream tarball that comes with the > repackaged debian source, without changes to the upstream version IANADD (and I don't know what you're packaging), but I've always thought that epochs were supposed to be avoided unless absolutely necessary. Could you just get this change ready and wait to upload until the next upstream release? Richard signature.asc Description: This is a digitally signed message part
Re: RFS: pidgin-mikroblog
On Mon, 2009-12-14 at 21:18 +0100, Karolina Kalic wrote: > It is a plugin for any libpurple based client and I wrote that in long > description of the package. But, there is no plugin which name starts > with "purple-", so it may be difficult to find it. Also, there are > other packages in Debian repository which names starts with "pidgin-", > and they have in their description mentioned that they can be used > with other libpurple based clients (pidgin-awayonlock, > pidgin-facebookchat, pidgin-skype). I didn't realize these were all broken. My opinion is that they should be renamed to purple-*, but you'll have to see what your sponsor wants, as IANADD. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: pidgin-skype
On Wed, 2009-11-04 at 01:15 +, Sune Vuorela wrote: > Yes and no. Some icon artists create it in svg and then export to png > and does pixelmanipulations of each size. > > What's the source here ? Theoretical discussions aside, in this case, I'd distribute both. If the SVG no longer exists, I'd obviously distribute just the PNGs. Richard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: pidgin-skype
On Tue, 2009-11-03 at 18:27 +0100, Julian Andres Klode wrote: > * You should probably not depend on pidgin, I guess the plugin >is also useable from finch (the console version). You would want to depend on libpurple0, but that should be happening automatically. (I haven't tried building this package.) The plugin requires libpurple >= 2.1.0, as per its PurplePluginInfo struct in libskype.c. So you need to drop the pidgin dependency and change the libpurple build-dep to be something like this: Build-Dep: libpurple-dev (< 3), libpurple-dev (>= 2.1) Also, why does the diff include a huge delta for the README? You have README.txt listed twice in debian/docs. Why does this only suggest the skype package? It doesn't work without it. Shouldn't that be a Depends? Why mention Adium in the Debian package description? Adium only runs on Mac OS X? That whole description feels to me like it needs some work. Here's a quick suggestion (not meant as a finished product necessarily): This protocol plugin allows libpurple to communicate with Skype. Applications using libpurple (Pidgin, Finch, Instantbird, etc.) can thus show your Skype contacts alongside those from other protocols, and you can communicate with them using that application instead of the Skype user interface. . This plugin communicates with the Skype application in the background to perform its work, so it's necessary to have Skype installed and running. Richard P.S. Eion, skype_buddy_free() doesn't need all the "if (foo)" bits before the g_free()s. g_free() is documented to always check for NULL. signature.asc Description: This is a digitally signed message part
Re: Bug#505633: RFS: gnome-keyring-query
On Wed, 2008-11-19 at 22:15 +0100, Michal Čihař wrote: > Dne Wed, 19 Nov 2008 14:46:30 -0600 > Richard Laager <[EMAIL PROTECTED]> napsal(a): > > > Do you think I should file a bug report on the gnome-keyring package in > > Debian to see if the maintainer would include this as a patch? > > I think it is better way to go than introducing new package for this. Done: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506255 Richard signature.asc Description: This is a digitally signed message part
RFS: gnome-keyring-query
I am looking for a sponsor for my package "gnome-keyring-query". * Package name: gnome-keyring-query Version : 0.0.0.20070709-3 Upstream Author : "Koster" * URL : http://www.gentoo-wiki.info/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases * License : Public Domain Section : gnome It builds these binary packages: gnome-keyring-query - Command-line utility for querying GNOME Keyring The package appears to be lintian clean. The upload would fix its ITP bug: 505633 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnome-keyring-query - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gnome-keyring-query/gnome-keyring-query_0.0.0.20070709-3.dsc I would be glad if someone uploaded this package for me. Thanks, Richard signature.asc Description: This is a digitally signed message part
Re: Different suggests/recomends according to architecture
On Fri, 2008-10-31 at 18:35 +0100, Julien Valroff wrote: > Le vendredi 31 octobre 2008 à 18:24 +0100, Siegfried-Angel a écrit : > > If I remember correctly, you can use the following syntax: > > "python-psyco [i386]". > > This is only for build-depends. I think that can also be used for > arch:any packages, but as arch:all packages are built only once, the > dependencies would be set for the built architecture. Consequently, you can just convert it to an arch:any package to have this work. I've done this for some private packages I maintain for myself. I'm not sure if it's appropriate in this case or not, but it does work (on arch:any). Richard signature.asc Description: This is a digitally signed message part
Re: dbconfig-common
On Thu, 2008-09-18 at 02:40 +0800, Thomas Goirand wrote: > Why do you think no app would need it? I never claimed this. > How about something that does mysql backups, or manages MySQL accounts? > I have made 2 packages that needs that, one of them being > automysqlbackup, and I had to do hackish stuff like this: Wouldn't you just use this: mysqldump --defaults-file=/etc/mysql/debian.cnf ...ARGS... When you're talking about system-level access, the idea of per-application database users loses most of its utility. Richard signature.asc Description: This is a digitally signed message part
Re: dbconfig-common
On Thu, 2008-09-18 at 01:00 +0800, Thomas Goirand wrote: > Patrick Schoenfeld wrote: > > dbconfig-common is documented fairly well. > > I do not agree with this statement. There are dark areas in the doc, > particularly nowhere, it's telling how to get a root user on MySQL, and > some packages might need it. Why would you need a root user? Richard signature.asc Description: This is a digitally signed message part
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
On Mon, 2008-07-07 at 22:51 +0900, Charles Plessy wrote: > How can this conflict of interest be solved? I would start with the assumption that people installing your package actually want it. Then I'd look at the most common use case in such a scenario and make that the default answer in debconf. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: pidgin-privacy-please
On Thu, 2008-06-26 at 09:52 +0800, Paul Wise wrote: > On Thu, Jun 26, 2008 at 8:22 AM, Stefan Ott <[EMAIL PROTECTED]> wrote: > > > I am looking for a sponsor for my package "pidgin-privacy-please". > > The upstream website says this requires pidgin itself to be patched, > has the Debian pidgin package integrated that patch? Last I checked, no. Here's the comment from the p-p-p upstream README [0]: Since version 2.3.0, pidgin includes the auth-signals patch, thus you'll only need to apply the patch for blocked-signals. If you choose not to apply that patch, pidgin-privacy-please won't be able to send auto-replies when a message has been blocked. While I'm not against the idea of those signals, sending an auto-reply when a message is blocked seems pretty counter-intuitive to me. Richard [0] http://code.google.com/p/pidgin-privacy-please/wiki/ReadMe signature.asc Description: This is a digitally signed message part
Re: Some license issues (Was Re: RFS: unionfs-fuse)
On Wed, 2008-06-25 at 14:02 +0530, Kapil Hari Paranjape wrote: > I have enclosed a sample "debian/copyright" file for your package. > You might wish to edit it before including it. This looks like it's supposed to be the machine-readable format, but it doesn't seem to comply with that spec. The "License" option is referring to arbitrary names of things given later in the file. I think you want "License: Other" with the license text below that section. See here: http://wiki.debian.org/Proposals/CopyrightFormat#head-133d3ff18d9a3119d48e96f0c8aca4a37391769f If I'm off-base here, please let me know, as I'm trying to do a machine-readable copyright file for my package right now and I'd like to do it correctly. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: fpm2 - a password manager
On Thu, 2008-05-08 at 20:19 +0800, Wen-Yen Chuang wrote: > Aleš Koval (author of fpm2) wrote: > > FPM2 data file is 100% compatible with his old version. I port FPM2 as > > drop-in replacement old FPM in mind. In this case, why is it necessary to create an fpm2 package at all? Why not just do a new fpm package (version 2.x.y) and avoid all the transitioning? To me, an fpm2 package makes sense only if you intend to support both versions in the archive at the same time. Richard P.S. IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iolanguage packaging
I'm not a Debian developer, so take this all with a large grain of salt. On Sat, 2008-01-05 at 15:03 +0100, Jonas Eschenburg wrote: >1. Some addons' shared libraries have dependencies to other addons. Do you have an example here? It seems like this is violating the addon abstraction, though I know nothing about this programming language. For example, I don't think I've ever seen a Perl or Python module that required a shared library from another module; they would just require the module itself and work with the Perl/Python API. If these addons are all built from the same source package, you're probably fine. If they don't, then I'm guessing you'll need to make that into a versioned shared library. >2. Flux, an OpenGL-based GUI addon, contains a lot of image and font > resources. Those, of course, end up in /usr/lib and produce > lintian warnings such as "image-file-in-usr-lib". What am I > supposed to do about it? The design of putting code and data into > the same addon directory is not 'broken', it just differs from FHS > philosophy. If the images take up significant size, you should split them into an architecture independent package. You could install these into /usr/share and then either patch the addon to use them from there or make symlinks. >3. The same addon contains .ttf files from various free fonts like > Vera. Those files are duplicates of the files in the corresponding > Debian packages, but they're renamed and put into a special folder > structure. Is it a) necessary to replace those files by symlinks > and b) can that be done automatically? If they're exact duplicates, I'd say you should use the existing packages. You could see about patching the addon to use .ttf files from the system location. This would be ideal, I think, as then it could use other installed fonts that the upstream addon package didn't ship, right? Richard signature.asc Description: This is a digitally signed message part
Re: RFS: libccc
On Sun, 2007-12-02 at 00:21 +, Pedro Fragoso wrote: > I am looking for a sponsor for my package "libccc". > > * Package name: libccc > Version : 0.0.5 > Upstream Author : [fill in name and email of upstream] > * URL : [fill in URL of upstreams web site] > > * License : [fill in] You should have filled in the missing data before you sent this e-mail. Richard signature.asc Description: This is a digitally signed message part
Re: Ubuntu-to-Debian packaging
On Fri, 2007-11-23 at 22:47 +, James Westby wrote: > On Fri, 2007-11-23 at 18:23 -0400, Jose Luis Rivas Contreras wrote: > > You need a new changelog for Debian starting from scratch and you could > > adapt the copyright (if the license allow it) or just make one new. > > I'm not so sure. Likewise, I don't see why you would want to start over. You'd lose potentially useful changelog information. For example, if you're wondering why something was done a certain way in the package, it might be listed in the changelog. Plus, packages that started in Ubuntu obviously have some interest there. As they're downstream of Debian, changes will be copied in at least one direction, but quite probably both. Retaining history can be very useful in these efforts. Finally, I think it's generally distaseful to remove the record of someone else's work for no good reason. Richard signature.asc Description: This is a digitally signed message part
Re: Advice on packaging SAGE
On Tue, 2007-05-29 at 13:48 -0500, Jordi Gutierrez Hermoso wrote: > On 29/05/07, Paul Wise <[EMAIL PROTECTED]> wrote: > > Find out if the SAGE developers changes to octave/etc are useful to > > people who use octave/etc without using SAGE, if so, go the first > > route. > > According to William Stein (SAGE's lead developer), a lot of those > changes will probably be rejected upstream. Without knowing anything about the specifics... then the changes need to be modified into something suitable. Richard signature.asc Description: This is a digitally signed message part
Fwd: Re: gbonds_2.0.2-7_i386.changes REJECTED
I sent the following message to my sponsor, but haven't heard back yet. I welcome any assistance anyone can provide. Thanks, Richard > On Sun, 2007-03-11 at 12:06 +, Joerg Jaspert wrote: > > rejected, you missed to mention the difference of the license in help/* > > Also you need to find out if its ok to go in main with that license, see > > the vote > > on GFDL. > > As you can see, gbonds was rejected. I did a Google search and found the > vote on the GFDL, and it seems to be mostly about invariant sections. > > I added a note about the license to the copyright file. The file now > looks like this: > > - > This package was debianized by Richard Laager <[EMAIL PROTECTED]> on > Mon, 10 Apr 2006 23:34:33 -0500. > > It was downloaded from http://gbonds.sourceforge.net/download/ > > Copyright Holder: Jim Evins <[EMAIL PROTECTED]> > > License: > >This package is free software; you can redistribute it and/or modify >it under the terms of the GNU General Public License as published by >the Free Software Foundation; either version 2 of the License, or >(at your option) any later version. > >This package is distributed in the hope that it will be useful, >but WITHOUT ANY WARRANTY; without even the implied warranty of >MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >GNU General Public License for more details. > >You should have received a copy of the GNU General Public License >along with this package; if not, write to the Free Software >Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > > On Debian systems, the complete text of the GNU General > Public License can be found in `/usr/share/common-licenses/GPL'. > > The documentation in the help directory is licensed as follows: > > Permission is granted to copy, distribute and/or modify this > document under the terms of the GNU Free Documentation License, > Version 1.1 or any later version published by the Free Software > Foundation with no Invariant Sections, no Front-Cover Texts, and no > Back-Cover Texts. A copy of the license can be found in the file > COPYING-DOCS which shipped as part of this package. > - > > Is that the right way to deal with it? > > Now, is that license acceptable for Debian? If not, what can I do? Do I > make a gbonds-doc binary package and ship it in non-free? Do I need to > pull the help directory even from the source package? > > Thanks, > Richard > signature.asc Description: This is a digitally signed message part
Re: Bug#414477: dtc config ask for mysql login/pass, and it's useless on debian
On Mon, 2007-03-12 at 18:24 +0800, Thomas Goirand wrote: > P.S: dbconfig-common is too much Debian specific and it wont be an > available package on other Unix systems like FreeBSD or OSX, so we can't > really use it. dbconfig-common solves all of this stuff for you. It is the right solution. Whether or not it exists on other operating systems is irrelevant. The Debian package is for Debian, not for FreeBSD or OS X. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: debian-sec
On Wed, 2007-02-21 at 01:41 +, Tim Brown wrote: > I am looking for a sponsor for my package "debian-sec". Debian-Sec is a > collection of existing and new (arp-scan and sucrack - submitted separately) > packages identified as useful in assessing hosts, networks, applications and > protocols. First off, the obligatory "I'm not a DD", so factor that into your consideration of my thoughts here. The name of this package makes me think there's a debian-sec group that is related. If there's a debian-security or something, that might be confusing... Also, why debian-sec and then a bunch of security-* packages. The naming seems confusing to me. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Tue, 2007-02-13 at 21:34 +0100, Thijs Kinkhorst wrote: > As for the binary package, that depends on the installed size. For both > phpBB and SquirrelMail we did not split the translation up, because each > translation is quite small sized. How much space would it cost to > install all translations? If that's the way it's done in Debian for existing packages, then I suppose roundcube should do the same. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Tue, 2007-02-13 at 13:22 +0100, Vincent Bernat wrote: > On Tue, 13 Feb 2007 00:42:22 -0800, Richard Laager <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-02-12 at 21:19 +0100, Vincent Bernat wrote: > >> OoO En cette matinée pluvieuse du lundi 12 février 2007, vers 10:11, > >> sean finney <[EMAIL PROTECTED]> disait: > >> > >> > MAX_TMPFILE_LIFETIME=15 > > > > Do these files really need to stick around for 15 days? > > I don't think. But it is a safe value. Sure, but can we get something smaller that's still safe? On a busy server, 15 days might be too long. I realize it's customizable, but I think we should be able to find a reasonable default. > >> RoundCube can be localized. However, the localization files are in > >> separate tarballs. Should I package them as separate packages or > >> should I include the translation into the main package ? > > > > Are those tarballs released separately from Roundcube? > > Yes. I was really asking if they were released at different times (mainly more or less frequently) or with different version numbers. It seems they're not. Feedback from a DD would be helpful here. There are 24 language packs, by my count. I'm inclined to say that they should be separate binary packages, at least, since people won't necessarily want every single language installed. (When I install RoundCube for my employer, we probably won't want all the languages, for example.) From there, the question is if you want to make them separate source packages as well. That seems klunky to me, but so does repacking the .orig tarball. Personally, I think repacking the tarball would be the lesser of two evils. I'd unpack all the language tarballs into some subdirectory, creating something like this (using two random language tarballs that I looked at as examples): localization/ arabic/ README ar/ ... ... dutch/ README nl_NL/ ... ... Then in your debian/rules, you could do something like this: for language in localization/* ; do cp -R $language/*/ debian/roundcube-`basename $language`/path/to/install/localization/ done This is really rough code and completely untested, but it should give you the idea. In debian/control, you'd have multiple binary packages listed, of the form roundcube-LANGUAGE. In this way, adding a new language is as simple as unpacking a new tarball and copying/pasting/modifying the appropriate new snippet in debian/control. Again, I'm not a DD, so if someone who is wants to chime in, take their advice over mine. ;) Richard signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Mon, 2007-02-12 at 21:19 +0100, Vincent Bernat wrote: > OoO En cette matinée pluvieuse du lundi 12 février 2007, vers 10:11, > sean finney <[EMAIL PROTECTED]> disait: > > > MAX_TMPFILE_LIFETIME=15 Do these files really need to stick around for 15 days? > OK, I have included your snippet of code. I don't provide > /etc/default/roundcube since it would be a commented file only and the > cron job seems already documented. /etc/default/roundcube seems like a standardized place for this sort of thing. It seems like you should include that file so people will know they can customize MAX_TMPFILE_LIFETIME. > RoundCube can be localized. However, the localization files are in > separate tarballs. Should I package them as separate packages or > should I include the translation into the main package ? Are those tarballs released separately from Roundcube? Richard signature.asc Description: This is a digitally signed message part
Re: RFS: roundcube
On Sat, 2007-02-10 at 23:21 +0100, Vincent Bernat wrote: First off, I'm not a Debian developer. My advice could be wrong, so be cautious about following it. I do have a strong interest in seeing Roundcube packaged for Debian. > This is still a beta quality software but I use it happily every > day. The package uses dbconfig-common to configure database. It > supports sqlite, MySQL and PostgreSQL backend. To avoid to pull too > much packages, it does not depend on any of those backends. Any > comment on this is welcome. I have put a note in README.Debian. Here's your note: "To avoid to pull too much packages, it does not depend on any of those backends." If you're going to stick with this plan, I'd recommend something like this: "To avoid pulling in too many packages, it does not depend on any of these backends." The wording flows a little better, I think. Your diff includes po/templates.pot which is autogenerated, right? You should see if you can avoid creating that file, or you should delete it to avoid having it show up in the diff. Your dependencies list PHP 4 first. I think you should list PHP 5 first, since it's newer. Also, you list sqlite as the first backend, when I'd imagine MySQL is going to be more popular. I'd list them like: Depends: ..., libapache2-mod-php5 | ..., php5-mysql | ..., ... I'm not sure how I feel about configuring and restarting a web server by default. How do other packages handle this? There's a log folder configured... Do you need to configure log rotation then? > The other question is that roundcube requires a temp directory. I have > modified the config file to create /var/tmp/roundcube. I don't know > what should be the best way. If the directory already exists, it can > be a security risk (the user owning the directory could delete files > or put symlinks in it). Maybe should I put this temporary directory in > /var/lib/roundcube instead ? /var/tmp is for temporary files that need to survive a reboot, right? Is that the case here? I'm not sure what to suggest about a temp file location. Richard signature.asc Description: This is a digitally signed message part
Re: Required package in build-deps?
On Mon, 2007-01-29 at 19:17 +0100, Laurent Bigonville wrote: > On Mon, 29 Jan 2007 11:39:28 -0600 > Richard Laager <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-01-29 at 18:18 +0100, Laurent Bigonville wrote: > > > My package (pam-keyring) FTBFS on some buildd[1] because 'kill' is > > > missing. /bin/kill is part of the procps package which has a > > > required priority. I thought that packages with such priority > > > should not be added to build-deps... > > > > Why does it need /bin/kill during the build process? That seems a > > little odd... > > The configure script need to know the path of kill, because it's > hardcoded later at build time. Thinking out loud, I'd say you could either: 1) Fix the code so it uses PATH, which may or may not be appropriate, 2) Replace the configure detection with a hardcoded /bin/kill (which is probably more trouble than it's worth), or 3) Add procps as a build-dep. Out of curiosity, any idea why it hardcodes the path to kill instead of looking at the PATH? Richard signature.asc Description: This is a digitally signed message part
Re: BALLView - a molecular viewer and modeling tool
On Sun, 2007-01-28 at 09:45 +0100, Andreas Tille wrote: I'm replying to the reply, since I can't find a copy of the original message in my MUA. Sorry for the sub-optimal threading. > On Sun, 28 Jan 2007, Andreas wrote: > > >>4. debian/compat > >> The current debhelper version is 5.x. So if you have no > >> certain reason (like backporting to Sarge for instance), > >> I would recommend to use debhelper 5 here. > > I used the version 4 because otherwise I could not build the package on > > the Edgy Ubuntu. The package works fine with the older version of debhelper. Are you sure that's what it was? I'm able to build packages with debhelper version 5 on Edgy. Edgy ships debhelper version 5.0.37.3ubuntu4. Richard signature.asc Description: This is a digitally signed message part
Re: Re: RFS: ballview : new package version
On Thu, 2007-01-25 at 14:17 +0100, Andreas Moll wrote: > > If the scripts are intended to be used on other platforms, how about > > moving them out of the debian directory, in the upstream sources? > Well these scripts are in the upstream sources (see debian-upstream dir) > and when I want to create a source package, they are copied to the > debian directory. With this procedure future downstream autors can > modify them to their liking. There's no need to do this. If they're in the upstream source tarball and a packager modifies them, then the changes will show up in the .diff.gz. Richard signature.asc Description: This is a digitally signed message part
Re: RFS: pam-keyring -- PAM module that unlock gnome-keyring at login (new package)
On Sat, 2006-12-23 at 02:29 +0100, Laurent Bigonville wrote: > It's a PAM module that unlock the gnome-keyring at login. Useful with > network-manager for example. > > I'm not sure where pam-keyring-tool must go (/bin or /usr/bin) since it > is needed by the pam library. > > Full informations on the BTS: http://bugs.debian.org/402500 Are you sure this is the latest version of pam-keyring? (Or, did you patch it? I didn't check.) I looked at packaging it before, but the latest version required pam >= 0.99, so I filed an RFE for that with Ubuntu. Here's the relevant Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360460 Richard signature.asc Description: This is a digitally signed message part
Re: Using the user nobody in my package
On Sat, 2006-11-18 at 12:59 +0800, Thomas Goirand wrote: > Also, I wanted to have your opinion. Is it ok to use dtc:nogroup, or > should I also generate a group name and use it? I think the same arguments apply for the group. Richard signature.asc Description: This is a digitally signed message part
Re: Bug#398486: RFC: teamspeak-server -- VoIP chat for online gaming (server)
> I hereby >grant both the Debian and Ubuntu teams, and their associated mirrors, >permission to distribute the TeamSpeak Version 2.x, and ONLY Version 2.x, >software package FREE of charge, and without any fee requirements, > for the >sole purpose of facilitating the installation process of TeamSpeak > Version >2.x software in these Linux related distributions or operating > systems. This violates the DFSG, in that the license can't be Debian-specific, right? Unless this is going into non-free... I haven't followed this thread. Richard signature.asc Description: This is a digitally signed message part
Re: Using the user nobody in my package
On Thu, 2006-11-16 at 06:40 +0800, Thomas Goirand wrote: > Please post your thoughts here, so we can have a valuable chat on what > to do. There is a way to get static UID assignments. I'm not sure if that's the best solution here, or how easily they're granted, but I do know it's covered in the policy. I wrote a web configuration system for web hosting at my employer. I use named groups. How often do you really move sites? In that case, you could just do the move with something that'll preserve ownership by name rather than UID/GID. Also, for us, we end up creating our servers the same way, so the UIDs end up matching anyway. It seems to me like you should use whatever account is most appropriate for each task, rather than trying to pick one UID/GID for everything. For your daemon, that might be a particular user, such as dtc. For apache, leave its default alone. I don't think it's good form to be changing Apache's users. (I'd imagine that'd require modifying apache's conffiles anyway, which would be against policy.) For other daemons, do whatever is necessary... I'm not sure how much this helps. I'd be glad to discuss the users that we use in our package, if that helps. Richard signature.asc Description: This is a digitally signed message part
Re: debianizing directories?
On Tue, 2006-11-07 at 16:35 -0500, Kit Peters wrote: > The boxen out in the field run apt-get update ; apt-get dist-upgrade > once a night. I don't know much about anything, but I do know this is dangerous. dist-upgrade removes packages as necessary. Sometimes, due to the archive being partially updated, packages can be removed when that's not what you wanted. Now, if you only use a local repository and you ensure this isn't going to be the case, you're fine. Personally, I have my machines run apt-get update && apt-get dist-upgrade in test mode. That'll show me all the changes that are necessary. I then SSH to the machine in the morning and apply the updates myself. Richard signature.asc Description: This is a digitally signed message part
Re: Linking with --as-needed in Debian Packages (Was: Re: RFS: flamerobin (updated package))
On Mon, 2006-10-30 at 19:30 +0100, Michael Biebl wrote: > http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html > > In short: > - First try the relibtoolize approach. I'll start by admitting I don't know much about the autotools. I took a look at this URL: http://people.debian.org/~keybuk/libtool-updating.html If I follow those steps, I'm making a bunch of changes in the source directory of the package, which creates a big diff [1]. Is that really the best way? Should I instead run those commands as part of the package build process? Richard [1] The diff statistics on *just this change*: aclocal.m4 | 9095 +-- config.guess | 699 +- config.sub | 234 configure|17299 +-- ltmain.sh| 3759 +--- 5 files changed, 24189 insertions(+), 6897 deletions(-) signature.asc Description: This is a digitally signed message part
Linking with --as-needed in Debian Packages (Was: Re: RFS: flamerobin (updated package))
On Mon, 2006-10-30 at 14:31 +0200, Damyan Ivanov wrote: >* Added --as-needed to LDFLAGS to avoid unnecessary NEEDED entries. > Thanks to Christian 'Greek0' Aichinger. Is the use of --as-needed encouraged/discouraged in Debian? Is there a reason this isn't used system-wide? (I'm aware some packages have issues, but those can and should be addressed individually.) Richard signature.asc Description: This is a digitally signed message part
Re: RFS: zeroinstall-injector
On Fri, 2006-10-27 at 11:10 +, Thomas Leonard wrote: ... Thanks for your explanation. ... > http://0install.net/matrix.html The one thing I found particularly interesting is: "Conflict-free" "If program A requires an old version of a library, and program B requires a new version, A and B can both be installed and used at the same time. The system will never refuse to install one program because some other program is installed." You gave an example of user-mode-linux and GnuPG. Isn't this just an example of why properly using sonames is important? There's no harm in having both libfoo1 and libfoo2 installed, and if you need to upgrade libfoo1 from 1.0 to 1.1 to support an application, everything else that needs libfoo 1.0 will continue to work with libfoo 1.1, right? Richard signature.asc Description: This is a digitally signed message part
Re: RFS: zeroinstall-injector
On Thu, 2006-10-26 at 14:39 +, Thomas Leonard wrote: > It builds these binary packages: > zeroinstall-injector - run programs by URL This probably isn't related to getting your package in Debian, so if this gets to be a larger discussion, we might need to take it off list, but... This looks interesting. How is this different than autopackage? Is there/ could there be some collaboration between your projects? Richard signature.asc Description: This is a digitally signed message part
RFS: scrdec -- Windows Script Decoder
Dear mentors, I am looking for a sponsor for my package "scrdec". * Package name: scrdec Version : 1.8-5 Upstream Author : Mr Brownstone <[EMAIL PROTECTED]> * URL : http://www.virtualconspiracy.com/index.php?page=scrdec/download * License : BSD Section : utils It builds these binary packages: scrdec - Windows Script Decoder The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scrdec - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scrdec/scrdec_1.8-3.dsc I would be glad if someone uploaded this package for me. The ITP bug number is 382722, which is not yet noted in the changelog. This is my second package. gbonds was just uploaded (thanks tony mancill!). I've had this packaged locally for some time, and I think it's ready to be uploaded. Thanks, Richard signature.asc Description: This is a digitally signed message part
Re: [RFS]: jsMath:TeX equations in HTML documents
On Tue, 2006-10-24 at 14:08 -0400, Yaroslav Halchenko wrote: > 2. only iff conf.d is not included (may be older config files were > preserved during upgrades or explicitely removed by sysadmin), then it > adds that explicit rule. I haven't really been following this, so I'm not sure if you're targeting Apache 1 or Apache 2, but if you're targetting Apache 2, is it possible that this code has always been there? If that's the case, the only reason it wouldn't be there is if the sysadmin removed it, in which case it seems wrong for you to blindly assume that you can add code to their conffile. In any case, I thought it violated Debian Policy to modify a conffile from another package, so you shouldn't do this either way, right? I'm not a DD. I'm a new packager, so please don't rely on what I've just said. However, I'd love to have clarification on this, to improve my own understanding. Richard signature.asc Description: This is a digitally signed message part
Re: How can I contribute??
On Tue, 2006-10-24 at 13:08 -0200, eduardo.oliva barruzi wrote: > Hi mentor, I joined this list to make some needed work to the project. > If any of you knows something that I can help, please let me know, > cause I really want to join. I'm not sure what to suggest for Debian specifically, but for open source development in general: Find something you're interested in working on. Look at bug reports and fix a bug or write a new feature (making sure to collaborate with the developers on the design) or write documentation, etc. Working on something *you* are interested in is much better for everyone in the long run: You'll produce higher quality results because you care about what you're doing, you'll enjoy it more, and you'll be more likely to stick around. Richard signature.asc Description: This is a digitally signed message part
RFS: gbonds
Dear mentors, I am looking for a sponsor for my package "gbonds". * Package name: gbonds Version : 2.0.2-6 Upstream Author : Jim Evins <[EMAIL PROTECTED]> * URL : http://gbonds.sourceforge.net/download/ * License : GPL Section : gnome It builds these binary packages: gbonds - U.S. savings bond inventory program for GNOME The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gbonds - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gbonds/gbonds_2.0.2-6.dsc I would be glad for any help or guidance you can provide. I'm hoping to get this package uploaded at some point. Thanks, Richard signature.asc Description: This is a digitally signed message part
