RE: font policy changes
> Original Message
> Subject: Re: font policy changes
> From: Julien Cristau <[EMAIL PROTECTED]>
> Date: Wed, July 16, 2008 8:47 am
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], debian-mentors@lists.debian.org
>
> On Wed, Jul 16, 2008 at 08:37:12 -0700, [EMAIL PROTECTED] wrote:
>
> > Thank you. I can write a proposed addition to the Policy Manual for
> > TrueType fonts after I'm done with the current package unless someone
> > else wants to do it. The "update-fonts-dir" utility currently only
> > handles fonts in the X11 tree (not TrueType), and even then the new X11
> > font directory options to look under /usr/share/fonts/X11/ ("-7" and
> > "--x11r7-layout") don't work on my stable release (Etch 4.0r3).
> >
> These options are no-ops. What do you mean by "don't work"?
> Also please stop breaking the thread.
>
> Cheers,
> Julien
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What I meant by "don't work" is that, as you mention, these two options
are no-ops.
According to the update-fonts-dir(1) man page, these options should not
be no-ops:
===
update-fonts-dir creates a fonts.dir file in an X font directory by
invoking mkfontdir(1x) with the appropriate argumentsFor each
directory, which is simply the last component of its path (such as
'75dpi' or 'misc'), update-fonts-dir will generate either
/usr/lib/X11/fonts/directory/fonts.dir or
/usr/share/fonts/X11/directory/fonts.dir from the fonts.scale and font
files found within it.
-7, --x11r7-layout switches the font layout to the one introduced in
X11R7: fonts in /usr/share/fonts/X11/directory (default is: fonts in
/usr/lib/X11/fonts/directory)
===
Here are examples of what happens in practice on Etch (4.0r3, i386 DVD
install), showing where the man page says the program should look versus
what actually happens.
Invocation: update-fonts-dir misc
Documented Path: /usr/lib/X11/fonts/misc
Actual Path: /usr/lib/X11/fonts/misc
Status: works as advertised (and complains that
/usr/lib/X11/fonts/misc doesn't exist)
Invocation: update-fonts-dir -7 misc
Documented Path: /usr/share/fonts/X11/misc
Actual Path: /usr/lib/X11/fonts/misc
Status: looks in wrong directory; "-7" has no effect
Invocation: update-fonts-dir --x11r7-layout misc
Documented Path: /usr/share/fonts/X11/misc
Actual Path: /usr/lib/X11/fonts/misc
Status: looks in wrong directory; "--x11r7-layout" has no
effect
Invocation: update-fonts-dir /usr/share/fonts/X11/misc
Documented Path: /usr/share/fonts/X11/misc
Actual Path: /usr/share/fonts/X11/misc
Status: "warning: absolute path /usr/share/fonts/X11/misc was
provided"
===
With the current stable release, use of /usr/lib/X11/fonts is
deprecated. This gives a few options:
a) Leave "-7" and "--x11r7-layout" as no-ops, but change the default
font top directory from "/usr/lib/X11/fonts" to "/usr/share/fonts/X11"
in the source code (so it never looks in "/usr/lib/X11/fonts" anymore).
b) Change "-7" and "--x11r7-layout" to work the way the man page says
they should work.
c) Change update-fonts-dir to accept an absolute font path without
complaint.
d) Change update-fonts-dir to look by default in both the old top-level
directory and the new one.
e) Phase out update-fonts-dir in favor of something else that also looks
in the truetype/ and other font directories outside the customary X11
font directories (for example, defoma or fc-cache). Remove the mandated
use of update-fonts-dir from the Policy Manual (it doesn't handle
truetype fonts anyways).
f) Other suggestions?
Paul Hardy
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: font policy changes
On Thu, Jul 17, 2008 at 00:19:39 -0700, [EMAIL PROTECTED] wrote: > What I meant by "don't work" is that, as you mention, these two options > are no-ops. > > According to the update-fonts-dir(1) man page, these options should not > be no-ops: > === > update-fonts-dir creates a fonts.dir file in an X font directory by > invoking mkfontdir(1x) with the appropriate argumentsFor each > directory, which is simply the last component of its path (such as > '75dpi' or 'misc'), update-fonts-dir will generate either > /usr/lib/X11/fonts/directory/fonts.dir or > /usr/share/fonts/X11/directory/fonts.dir from the fonts.scale and font > files found within it. > > -7, --x11r7-layout switches the font layout to the one introduced in > X11R7: fonts in /usr/share/fonts/X11/directory (default is: fonts in > /usr/lib/X11/fonts/directory) > === > The manpage is outdated. > Here are examples of what happens in practice on Etch (4.0r3, i386 DVD > install), showing where the man page says the program should look versus > what actually happens. > > Invocation: update-fonts-dir misc > Documented Path: /usr/lib/X11/fonts/misc > Actual Path: /usr/lib/X11/fonts/misc > Status: works as advertised (and complains that > /usr/lib/X11/fonts/misc doesn't exist) > No. It looks in both the old and the new paths. Did you actually look at the script? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to not break dependant packages
First, I'm a user, not a maintainer. I'm in a debate with a package maintainer that could be endless and so I'd like a your expertise to help end it. The maintainer is breaking his own dependant packages with every version change, and he says that's the only way to do it. His reason for this is in the README.Debian file below. From what I can gather, he uploads claws-mail, and then waits for it come back to him via apt-get, then he tries to build claws-mail-extra-plugins. My suggestion to him was to install claws-mail via dpkg -i and then build claws-mail-extra-plugins and then upload all the packages at once. This way, he'd know everything would build before he uploaded. His answer to this was: "I'm sorry but I never upload packages built in dirty environments. And even doing what you suggest it only solves the issue for the architecture being uploaded (which, btw, is not the one you're using), for the rest the extra-plugins would fail to build until claws-mail is built. Have a look on how the autobuilders work. Anyway, like I've already said in other bug [0], this is handled better in next version." His reasoning doesn't seem valid to me, but I'm not a maintainer. I don't want to debate with the guy. Could someone tell me if there is a way he can upload all his claws-mail-* packages at once without breaking his dependant packages for days (6 so far). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490304 Here's the README.Debian file mentioned in the bug report as == /usr/share/doc/claws-mail-extra-plugins/README.Debian == claws-mail-extra-plugins for Debian --- This is a collection of external plugins for Claws Mail. Plugins are dynamic libraries and as such they must share a common ABI with the host application to work properly. As the ABI is currently in development, the plugin code must check the Claws Mail version at load time so it matches the version the plugin was compiled with. Not doing so will result in unpredictable behaviour because of the ABI changes. This represents no problem for internal plugins because they are recompiled at the same time Claws Mail is, so version always matches. OTOH, external plugins doesn't know when Claws Mail version has changed, so packages for external plugins have to be rebuilt with each new *upstream* version (Debian version changes shouldn't modify ABI). On current packaging there is no way to express the dependency on upstream version only, so the implemented solution is to relax the dependency to greater or equal than the current upstream version and introducing a conflict with the next upstream version, so the plugin can effectively live with any of the possible Debian revisions without needing to be rebuilt. This solution has at least one problem: it depends on a future value of the version string. If upstream versioning scheme changes the version range expressed by the current Depends/Conflicts pair may be wider than expected and include the newer upstream version. In practice that means the old plugin package won't be uninstalled when the new Claws Mail version gets installed. This has already happened with releases 0.9.12a and 0.9.12b. To summarize, when loading a plugin if you see the popup message: "Your Claws Mail version is newer than the version the plugin was built with" then you have to wait until a new plugin package enters the archive. Alternatively you may put claws-mail package on hold until all external plugins you use are uploaded and then upgrade both claws and the plugins at the same time. -- Ricardo Mones <[EMAIL PROTECTED]> Mon, 26 Jun 2006 07:24:14 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
Le 17 juil. 08 à 15:15, Sean McE a écrit : First, I'm a user, not a maintainer. I'm in a debate with a package maintainer that could be endless and so I'd like a your expertise to help end it. The maintainer is breaking his own dependant packages with every version change, and he says that's the only way to do it. His reason for this is in the README.Debian file below. From what I can gather, he uploads claws-mail, and then waits for it come back to him via apt-get, then he tries to build claws-mail-extra-plugins. My suggestion to him was to install claws-mail via dpkg -i and then build claws-mail-extra-plugins and then upload all the packages at once. This way, he'd know everything would build before he uploaded. Hi, He can _prepare_ the other packages before he uploads claws-mail, but indeed testing the dependent packages a last time and uploading them after the build-dependency claws-mail is in the archive looks like a good idea to me. That should make a delay of only ~ one day for you if he plans ahead. I guess you are running unstable: you have to expect those glitches. It should not happen in testing or stable. It should not happen in unstable very often either: apparently it's only for new upstream versions of claws-mail. Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
Hi, On Thursday 17 July 2008 15:15:25 Sean McE wrote: > > On current packaging there is no way to express the dependency on > upstream version only, [..] actually, there is: Depends: foo (>= 1.2.1), foo (<< 1.2.1+) > [..] > by the current Depends/Conflicts pair may be wider than [..] This sounds like there are conflicts, where these shouldn't be. (Are there really conflicts on file level involved?). Cheers, Stefan. signature.asc Description: This is a digitally signed message part.
Re: How to not break dependant packages
On Thu, 17 Jul 2008 15:30:08 +0200 Thibaut Paumard <[EMAIL PROTECTED]> wrote: > I guess you are running unstable: you have to expect those glitches. > It should not happen in testing or stable. It should not happen in > unstable very often either: apparently it's only for new upstream > versions of claws-mail. I'm running testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thibaut Paumard ha scritto: > I guess you are running unstable: you have to expect those > glitches. It should not happen in testing or stable. Please forgive my ignorance: why shouldn't it happen in testing? (I mean: by what control mechanism?) Pietro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIf0tUcZVtR82bmAYRAgeMAJ9iv/FJFMcLL+O9aEtYjEBCV58UigCgi+EL FKdIa16MtFuuJ7kZGEmhtzo= =Dc1M -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 IANADD Sean McE wrote: > On Thu, 17 Jul 2008 15:30:08 +0200 > Thibaut Paumard <[EMAIL PROTECTED]> wrote: > >> I guess you are running unstable: you have to expect those glitches. >> It should not happen in testing or stable. It should not happen in >> unstable very often either: apparently it's only for new upstream >> versions of claws-mail. > > > I'm running testing. IMHO, In this case maintainer is quite wrong, because it is not allowed in testing to break any packages in testing. My suggestion is to put 'Conflicts: claws-mail-plugins-extra (<< "upstream-version")' to 'claws-mail' package. Am I wrong? - -- Eugene V. Lyubimkin aka JackYF -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh/U8QACgkQchorMMFUmYzNvQCfcO565D2q8gEVQA1kHIoLah/h f18AnAykc1qm/sawmIFfME1CuANfoksw =ShEr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
Le 17 juil. 08 à 15:58, Sean McE a écrit : On Thu, 17 Jul 2008 15:30:08 +0200 Thibaut Paumard <[EMAIL PROTECTED]> wrote: I guess you are running unstable: you have to expect those glitches. It should not happen in testing or stable. It should not happen in unstable very often either: apparently it's only for new upstream versions of claws-mail. I'm running testing. Then I believe the maintainer could do something with the dependencies, but I'm not sure what. Setting Conflicts in claws-mail on the previous version of the plug-ins would ensure that you don't keep installed plug-in that don't work, so that you can decide to not upgrade until those packages are upgradable. (This is true in unstable as well). Actually, I thought that there would be a way of preventing claws- mail from migrating to testing until all the plug-ins can migrate as well, but I'm afraid that would mean _depending_ on all the plug-ins. Not sure whether _recommending_ would work for that purpose. Regards, T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
Le 17 juil. 08 à 15:38, Pietro Battiston a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thibaut Paumard ha scritto: I guess you are running unstable: you have to expect those glitches. It should not happen in testing or stable. Please forgive my ignorance: why shouldn't it happen in testing? (I mean: by what control mechanism?) A package won't migrate until all its dependencies can migrate as well. However here we are talking about reverse dependencies, so I'm not so sure anymore. Regards, T. PGP.sig Description: Ceci est une signature électronique PGP
RFS: dante - fix RC bugs, adopt, update
Hi, I am looking for a sponsor for the new version 1.1.19.dfsg-1 of the "dante" package - I'm adopting it, fixing three RC bugs (dante does not currently have a version in testing), updating it to the new upstream release, and updating the Debian packaging a lot. It builds these binary packages: dante-client - SOCKS wrapper for users behind a firewall dante-server - SOCKS (v4 and v5) proxy daemon (danted) libdsocksd0 - SOCKS library for internal use by the dante client libsocksd0 - SOCKS library for packages built using libsocksd-dev libsocksd0-dev - Development files for compiling programs with SOCKS support The package has been tested by lintian on testing and unstable. The upload would fix these bugs: 232574, 368322 (grave), 466082 (grave), and 486756 (ITA). The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/d/dante/dante_1.1.19.dfsg-1.dsc I would be glad if someone uploaded this package for me, so that dante has a chance of making it into Lenny now that the RC bugs are fixed. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. pgpwMxwunDdMg.pgp Description: PGP signature
Re: How to not break dependant packages
Le 17 juil. 08 à 16:19, Thibaut Paumard a écrit : Le 17 juil. 08 à 15:38, Pietro Battiston a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thibaut Paumard ha scritto: I guess you are running unstable: you have to expect those glitches. It should not happen in testing or stable. Please forgive my ignorance: why shouldn't it happen in testing? (I mean: by what control mechanism?) A package won't migrate until all its dependencies can migrate as well. However here we are talking about reverse dependencies, so I'm not so sure anymore. Actually I see a mechanism that should work (not sure whether it's a good idea though): the claws-mail source package could provide a claws-mail-all binary package, which would depend on the right version of all the plug-ins. This way, the entire set of packages would be held out of testing as long as everything cannot come in. Regards, T. PGP.sig Description: Ceci est une signature électronique PGP
RFS: bzr-search
Dear mentors, I am looking for a sponsor for my package "bzr-search". * Package name: bzr-search Version : 1.6.0~bzr49-1 Upstream Author : Robert Collins <[EMAIL PROTECTED]> * URL : https://launchpad.net/bzr-search * License : GPL Section : devel It builds these binary packages: bzr-search - Search plugin for Bazaar The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bzr-search - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bzr-search/bzr-search_1.6.0~bzr49-1.dsc I would be glad if someone uploaded this package for me. Kind regards Jelmer Vernooij signature.asc Description: Digital signature
Re: How to not break dependant packages
Hi, On Thursday 17 July 2008 16:17:09 Thibaut Paumard wrote: [..] > > Then I believe the maintainer could do something with the > dependencies, but I'm not sure what. Setting Conflicts in claws-mail > on the previous version of the plug-ins would ensure that you don't > keep installed plug-in that don't work, so that you can decide to not > upgrade until those packages are upgradable. (This is true in > unstable as well). Did I write yet that conflicts are not to be used to annotate that one package breaks another? > > Actually, I thought that there would be a way of preventing claws- > mail from migrating to testing until all the plug-ins can migrate as > well, but I'm afraid that would mean _depending_ on all the plug-ins. > Not sure whether _recommending_ would work for that purpose. erm, with a package and plugins, it's the other way round: The package itself must never depend on a plugin alone (otherwise there's no reason why it should be a plugin in the first place). However a plugin is not usable at all w.o. the application itself*, so the plugin must depend on it. Hence the solution seems to be: some-claws-mail-plugin Depends: claws-mail (>= up.stream.version), claws-mail (<< up.stream.version+) Now I'm not sure how britney works too much, but I guess that it would keep the new claws-mail from migrating before the plugins are available as well, because the old plugins would otherwise be unmet. At least on a users system, this will have the effect, that claws-mail will be held back, until new plugins are available. *: corner cases like plugins working with two different applications aside. HTH, Stefan. signature.asc Description: This is a digitally signed message part.
RFS: bzr-stats
Dear mentors, I am looking for a sponsor for my package "bzr-stats". * Package name: bzr-stats Version : 0.0.1~bzr23-1 Upstream Author : John Arbash Meinel Jelmer Vernooij * URL : http://launchpad.net/bzr-stats * License : GPL Section : devel It builds these binary packages: bzr-stats - Statistics plugin for Bazaar The package appears to be lintian clean. The upload would fix these bugs: 491103 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bzr-stats - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bzr-stats/bzr-stats_0.0.1~bzr23-1.dsc I would be glad if someone uploaded this package for me. Kind regards Jelmer Vernooij signature.asc Description: Digital signature
RFS: bzr-upload
Dear mentors, I am looking for a sponsor for my package "bzr-upload". * Package name: bzr-upload Version : 0.1.0~bzr44-1 Upstream Author : Vincent Ladeuil Martin Albisetti * URL : http://launchpad.net/bzr-upload * License : GPL Section : devel It builds these binary packages: bzr-upload - Bazaar plugin for uploading to web servers The package appears to be lintian clean. The upload would fix these bugs: 487106 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bzr-upload - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bzr-upload/bzr-upload_0.1.0~bzr44-1.dsc I would be glad if someone uploaded this package for me. Kind regards Jelmer Vernooij signature.asc Description: Digital signature
RFS: bzr-avahi
Dear mentors, I am looking for a sponsor for my package "bzr-avahi". * Package name: bzr-avahi Version : 0.1~bzr17-1 Upstream Author : James Henstridge * URL : http://launchpad.net/bzr-avahi * License : GPL Section : devel It builds these binary packages: bzr-avahi - mDNS plugin for Bazaar The package appears to be lintian clean. The upload would fix these bugs: 491190 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bzr-avahi - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bzr-avahi/bzr-avahi_0.1~bzr17-1.dsc I would be glad if someone uploaded this package for me. Kind regards Jelmer Vernooij signature.asc Description: Digital signature
Re: RFS: dante - fix RC bugs, adopt, update
On Thu, Jul 17, 2008 at 05:19:37PM +0300, Peter Pentchev wrote: > Hi, > > I am looking for a sponsor for the new version 1.1.19.dfsg-1 > of the "dante" package - I'm adopting it, fixing three RC bugs > (dante does not currently have a version in testing), updating it > to the new upstream release, and updating the Debian packaging > a lot. > > It builds these binary packages: > dante-client - SOCKS wrapper for users behind a firewall > dante-server - SOCKS (v4 and v5) proxy daemon (danted) > libdsocksd0 - SOCKS library for internal use by the dante client > libsocksd0 - SOCKS library for packages built using libsocksd-dev > libsocksd0-dev - Development files for compiling programs with SOCKS support > > The package has been tested by lintian on testing and unstable. > > The upload would fix these bugs: 232574, 368322 (grave), 466082 (grave), > and 486756 (ITA). > > The package can be found on mentors.debian.net: > http://mentors.debian.net/debian/pool/main/d/dante/dante_1.1.19.dfsg-1.dsc > > I would be glad if someone uploaded this package for me, so that dante > has a chance of making it into Lenny now that the RC bugs are fixed. I forgot this in the RFS, but here's the brief part of the changelog (the 1.1.19.dfsg-1 changelog entry itself also has a file-by-file breakdown of the changes): * New maintainer. Closes: #486756 * Do not start danted if the config file contains nothing but the default settings. Closes: #232574, #368322, #466082. * Use quilt to manage the patches, converting all existing ones. * Fix some lintian warnings * Add a watch file and README.source * Honor DEB_BUILD_OPTIONS * Separate the dante client library into a package of its own * Minimize the rules file by using debhelper 7 * Add the Vcs-Svn and Vcs-Browser source control fields * Add symbols files for the libraries * Convert the copyright file the machine-parseable format * Fix some C compiler warnings, mainly related to printf format strings * Enable build hardening unless DEB_BUILD_OPTIONS contains "nohardening" * New upstream version - remove the sockd/serverconfig.c upstream patch - doc/README.msproxy was removed * Install all sample configuration files [file-by-file changes snipped] G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. pgp1ytwR9Z1N6.pgp Description: PGP signature
Changing of behavior: How to tell the user?
Dear Mentors,
I'm the maintainer of the CVSNT package. This is a better replacement
for CVS and just like CVS it can work as server or client.
One of the enhancements (on the server side) was replacing the old
directory based file locks with a so-called lock server, which handled
all the locking on a per file basis. What I did until now was to start
this cvslockd daemon in an init script regardless whether the user used
CVSNT as client or server.
In the next few weeks should now come out a new version upstream and I
updated my package, fixed the bugs and I also want to prevent that
cvslockd is started every time. So I created a configuration file
/etc/defaults/cvsnt where an environment variable defines whether or not
the daemon gets started. I figured that there are probably more client
users than server users and set the default to no longer start cvslockd.
My questions:
1) Is this change of behavior desirable/do-able?
2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all?
3) How shall I inform the server users that they know that they have to
configure the file to get the lock daemon started again?
TIA and best regards
Andreas
--
("`-''-/").___..--''"`-._
`o_ o ) `-. ( ).`-.__.`)
(_Y_.)' ._ ) `._ `. ``-..-'
_..`--'_..-_/ /--'_.' .'
(il).-'' (li).' ((!.-'
Andreas Tscharner [EMAIL PROTECTED] ICQ-No. 14356454
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changing of behavior: How to tell the user?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Tscharner wrote: > Dear Mentors, > > I'm the maintainer of the CVSNT package. This is a better replacement > for CVS and just like CVS it can work as server or client. > > One of the enhancements (on the server side) was replacing the old > directory based file locks with a so-called lock server, which handled > all the locking on a per file basis. What I did until now was to start > this cvslockd daemon in an init script regardless whether the user used > CVSNT as client or server. > > In the next few weeks should now come out a new version upstream and I > updated my package, fixed the bugs and I also want to prevent that > cvslockd is started every time. So I created a configuration file > /etc/defaults/cvsnt where an environment variable defines whether or not > the daemon gets started. I figured that there are probably more client > users than server users and set the default to no longer start cvslockd. > > My questions: > 1) Is this change of behavior desirable/do-able? > 2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all? > 3) How shall I inform the server users that they know that they have to > configure the file to get the lock daemon started again? > > TIA and best regards > Andreas for 3) - may be, Debian.NEWS and/or debconf message in postinst? - -- Eugene V. Lyubimkin aka JackYF -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh/YesACgkQchorMMFUmYw3egCeKr2kyaAt5JMohn2W5bCiySzs ph0AnRpiZsqDU2cTMm40J/oJ38zPWtCz =5Ufe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: font policy changes
> Original Message > Subject: Re: font policy changes > From: Julien Cristau <[EMAIL PROTECTED]> > Date: Thu, July 17, 2008 1:38 am > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], debian-mentors@lists.debian.org > > On Thu, Jul 17, 2008 at 00:19:39 -0700, [EMAIL PROTECTED] wrote: > > > What I meant by "don't work" is that, as you mention, these two options > > are no-ops. > > > > According to the update-fonts-dir(1) man page, these options should not > > be no-ops: > > === > > update-fonts-dir creates a fonts.dir file in an X font directory by > > invoking mkfontdir(1x) with the appropriate argumentsFor each > > directory, which is simply the last component of its path (such as > > '75dpi' or 'misc'), update-fonts-dir will generate either > > /usr/lib/X11/fonts/directory/fonts.dir or > > /usr/share/fonts/X11/directory/fonts.dir from the fonts.scale and font > > files found within it. > > > > -7, --x11r7-layout switches the font layout to the one introduced in > > X11R7: fonts in /usr/share/fonts/X11/directory (default is: fonts in > > /usr/lib/X11/fonts/directory) > > === > > > The manpage is outdated. Okay, then as far as that problem goes, it is just that the man page needs to be updated. > > > Here are examples of what happens in practice on Etch (4.0r3, i386 DVD > > install), showing where the man page says the program should look versus > > what actually happens. > > > > Invocation: update-fonts-dir misc > > Documented Path: /usr/lib/X11/fonts/misc > > Actual Path: /usr/lib/X11/fonts/misc > > Status: works as advertised (and complains that > > /usr/lib/X11/fonts/misc doesn't exist) > > > No. It looks in both the old and the new paths. Did you actually look > at the script? I only looked at the script quickly, and saw that all it did was invoke mkfontdir, and knew that wasn't enough to start using a font immediately under X11. That's why I posted my earlier messages about whether it was okay to just call mkfontdir directly (given that update-fonts-dir wasn't behaving the way the man page said it should), and also if installation shouldn't then refresh the X11 font list with xset or fc-cache. The consensus seems to be that it's okay to use fc-cache or defoma in a postinst or postrm script, but that it's not okay to use xset, because xset will fail if X11 isn't running. It would be nice to add mention of that in some way to the Policy Manual. update-fonts-dir should probably no longer complain about /usr/lib/X11/fonts not being found every time it is run, seeing as how that directory no longer exists on Debian systems. > > Cheers, > Julien Paul Hardy [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: libnanoxml2-java
Hello! I am looking for a sponsor for my package "libnanoxml2-java", a small XML parser for Java. * Package name: libnanoxml2-java Version : 2.2.3.dfsg-4 Upstream Author : Marc De Scheemaecker * URL : http://nanoxml.cyberelf.be/ * License : zlib Section : libs It builds these binary packages: libnanoxml2-java - small XML parser for Java libnanoxml2-java-doc - documentation for libnanoxml2-java The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libnanoxml2-java - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libnanoxml2-java/libnanoxml2-java_2.2.3.dfsg-4.dsc I also have some questions: - I read that it was preferred to bump the changelog before each upload to mentors. Will it be possible to shorten it and get it back to 0 before the upload? - This is my first from scratch Debian package. Anything I could improve? I would be glad if someone uploaded this package for me if it is good enough. Kind regards Sveinung Kvilhaugsvik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changing of behavior: How to tell the user?
On Thu, Jul 17, 2008 at 06:14:51PM +0300, Eugene V. Lyubimkin wrote:
> Andreas Tscharner wrote:
> > Dear Mentors,
> > cvslockd is started every time. So I created a configuration file
> > /etc/defaults/cvsnt where an environment variable defines whether or not
> > the daemon gets started. I figured that there are probably more client
> > users than server users and set the default to no longer start cvslockd.
> >
> > My questions:
> > 1) Is this change of behavior desirable/do-able?
I like that change, as I typically install cvsnt and then
rm -fv /etc/rc?.d/S??cvsnt.
> > 2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all?
I think so.
> > 3) How shall I inform the server users that they know that they have to
> > configure the file to get the lock daemon started again?
> for 3) - may be, Debian.NEWS and/or debconf message in postinst?
Another option is to create (only if it doesn't exist, and after doing
a version number comparison with dpkg --compare-versions to see if
this is a version where it should be created) /etc/defaults/cvsnt as a
non-conffile configuration file, with the value CVSNTD determined by:
. if it's an initial installation, "no";
. otherwise, detect if cvslockd is running with s-s-d:
postinst:
f=/etc/defaults/cvsnt
v=2.5.03.2382-3.3
[ ! -e "$f" ] && dpkg --compare-versions "$2" le "$v" && {
CVSNTD=no
[ -n "$2" ] && start-stop-daemon --quiet --stop --test -n cvslockd -x
/usr/bin/cvslockd && CVSNTD=yes
echo "Creating /etc/defaults/cvsnt with CVSNTD=$CVSNTD" >&2
echo "CVSNTD=$CVSNTD" >"$f"
}
Perhaps you could do something a bit more sophisticated, instead of
doing [ ! -e "$f" ] you could do:
grep '^[[:space:]]*CVSNTD' "$f" >/dev/null || {
dpkg --compare=-versions "$2" le "$v" && {
CVSNTD=no
[ -n "$2" ] && start-stop-daemon --quiet --stop --test -n
cvslockd -x /usr/bin/cvslockd && CVSNTD=yes
echo "Initializing /etc/defaults/cvsnt with CVSNTD=$CVSNTD" >&2
echo "CVSNTD=$CVSNTD" >>"$f"
}
}
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dante - fix RC bugs, adopt, update
On Thursday 17 July 2008 17:47:51 Peter Pentchev wrote: > On Thu, Jul 17, 2008 at 05:19:37PM +0300, Peter Pentchev wrote: > > Hi, > > > > I am looking for a sponsor for the new version 1.1.19.dfsg-1 > > of the "dante" package - I'm adopting it, fixing three RC bugs > > (dante does not currently have a version in testing), updating it > > to the new upstream release, and updating the Debian packaging > > a lot. > > > > It builds these binary packages: > > dante-client - SOCKS wrapper for users behind a firewall > > dante-server - SOCKS (v4 and v5) proxy daemon (danted) > > libdsocksd0 - SOCKS library for internal use by the dante client > > libsocksd0 - SOCKS library for packages built using libsocksd-dev > > libsocksd0-dev - Development files for compiling programs with SOCKS > > support > > > > The package has been tested by lintian on testing and unstable. > > > > The upload would fix these bugs: 232574, 368322 (grave), 466082 (grave), > > and 486756 (ITA). > > > > The package can be found on mentors.debian.net: > > http://mentors.debian.net/debian/pool/main/d/dante/dante_1.1.19.dfsg-1.ds > >c > > > > I would be glad if someone uploaded this package for me, so that dante > > has a chance of making it into Lenny now that the RC bugs are fixed. > > I forgot this in the RFS, but here's the brief part of the changelog > (the 1.1.19.dfsg-1 changelog entry itself also has a file-by-file > breakdown of the changes): > >* New maintainer. Closes: #486756 >* Do not start danted if the config file contains nothing but > the default settings. Closes: #232574, #368322, #466082. >* Use quilt to manage the patches, converting all existing ones. >* Fix some lintian warnings >* Add a watch file and README.source >* Honor DEB_BUILD_OPTIONS >* Separate the dante client library into a package of its own >* Minimize the rules file by using debhelper 7 >* Add the Vcs-Svn and Vcs-Browser source control fields >* Add symbols files for the libraries >* Convert the copyright file the machine-parseable format >* Fix some C compiler warnings, mainly related to printf format strings >* Enable build hardening unless DEB_BUILD_OPTIONS contains "nohardening" >* New upstream version > - remove the sockd/serverconfig.c upstream patch > - doc/README.msproxy was removed >* Install all sample configuration files > >[file-by-file changes snipped] Peter, I just uploaded that package, since it brings notable improvements over the last one found in sid -- thanks for taking care of that! I have one question, though: did you feed upstream with the patches applied to the upstream code, AFAICS they will be interested in all of them, but `rename' ones ? -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: Changing of behavior: How to tell the user?
On 2008-07-17 17:56 +0200, Justin Pryzby wrote: > Another option is to create (only if it doesn't exist, and after doing > a version number comparison with dpkg --compare-versions to see if > this is a version where it should be created) /etc/defaults/cvsnt as a > non-conffile configuration file, with the value CVSNTD determined by: > > . if it's an initial installation, "no"; > . otherwise, detect if cvslockd is running with s-s-d: AFAICS, this last option won't quite work in the postinst, because dh_installinit's snippet stops the daemon in the prerm script, see #471060. But maybe it can be used in the preinst instead. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
Stefan Potyra wrote: > Hi, > On Thursday 17 July 2008 15:15:25 Sean McE wrote: >> > On current packaging there is no way to express the dependency on > upstream version only, [...] > actually, there is: > Depends: foo (>= 1.2.1), foo (<< 1.2.1+) This wouldn't work for binNMU'ed packages (in which case, foo might have version number like 1.2.1+b1). Maybe "foo (<< 1.2.1++)" might work. -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hubert Chathi wrote: > Stefan Potyra wrote: > >> Hi, >> On Thursday 17 July 2008 15:15:25 Sean McE wrote: >> On current packaging there is no way to express the dependency on >> upstream version only, > [...] > >> actually, there is: >> Depends: foo (>= 1.2.1), foo (<< 1.2.1+) > > This wouldn't work for binNMU'ed packages (in which case, foo might have > version number like 1.2.1+b1). Maybe "foo (<< 1.2.1++)" might work. > Why not "foo (<< 1.2.2)" then? - -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIf5ZNchorMMFUmYwRAhXAAJ9nEZKHKymmQr04B8bWuV8vwSR8zwCfer6O vlb+e7R4LCizLp9CCPwIL+U= =4Iwz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
On 2008-07-17 20:59 +0200, Hubert Chathi wrote: > Stefan Potyra wrote: > >> Hi, >> On Thursday 17 July 2008 15:15:25 Sean McE wrote: >>> >> On current packaging there is no way to express the dependency on >> upstream version only, > [...] > >> actually, there is: >> Depends: foo (>= 1.2.1), foo (<< 1.2.1+) > > This wouldn't work for binNMU'ed packages (in which case, foo might have > version number like 1.2.1+b1). Maybe "foo (<< 1.2.1++)" might work. Huh? We're talking about non-native packages here, so the Debian versions are 1.2.1-1, 1.2.1-2, 1.2.1-2+b1, ..., 1.2.1+git20080717-1 or similar. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
Sven Joachim wrote: > On 2008-07-17 20:59 +0200, Hubert Chathi wrote: >> Stefan Potyra wrote: >> >> Hi, >> On Thursday 17 July 2008 15:15:25 Sean McE wrote: >>> >>> On current packaging there is no way to express the dependency on >>> upstream version only, >> [...] >> >>> actually, there is: >>> Depends: foo (>= 1.2.1), foo (<< 1.2.1+) >> >> This wouldn't work for binNMU'ed packages (in which case, foo might have >> version number like 1.2.1+b1). Maybe "foo (<< 1.2.1++)" might work. > Huh? We're talking about non-native packages here, so the Debian > versions are 1.2.1-1, 1.2.1-2, 1.2.1-2+b1, ..., 1.2.1+git20080717-1 or > similar. Yup. I realized that after I posted. :-/ -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging for wine
[EMAIL PROTECTED] schrieb: > hello, > > i'd like to package (separately) some windows applications that run nice > under wine. Hello, first thanks for trying to make Debian better and better. But I've to say that I disagree with the idea to package applications which need wine to run, so on pure Windows applications. Why I disagree? We are here on GNU/Linux, not Window - so on we should concentrate ourself on software which runs nativly on Linux platforms, wine should be only a fallback solution. Maybe some software developers could also think "Why should I port my app to another platform than Windows, wine could also do my job?" - this could damage the availbility of nativly available software for Linux if everyone starts to wrap their applications about wine and we support this with packaging them. Do not feel blamed please, that's just my personal opinion, not more or less and btw. I don't hate wine. :) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: [EMAIL PROTECTED] Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging for wine
[EMAIL PROTECTED] schrieb: > hello, > > i'd like to package (separately) some windows applications that run nice > under wine. Hello, first thanks for trying to make Debian better and better. But I've to say that I disagree with the idea to package applications which need wine to run, so on pure Windows applications. Why I disagree? We are here on GNU/Linux, not Window - so on we should concentrate ourself on software which runs nativly on Linux platforms, wine should be only a fallback solution. Maybe some software developers could also think "Why should I port my app to another platform than Windows, wine could also do my job?" - this could damage the availbility of nativly available software for Linux if everyone starts to wrap their applications about wine and we support this with packaging them. Do not feel blamed please, that's just my personal opinion, not more or less and btw. I don't hate wine. :) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: [EMAIL PROTECTED] Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging for wine
[EMAIL PROTECTED] schrieb: > hello, > > i'd like to package (separately) some windows applications that run nice > under wine. Hello, first thanks for trying to make Debian better and better. But I've to say that I disagree with the idea to package applications which need wine to run, so on pure Windows applications. Why I disagree? We are here on GNU/Linux, not Window - so on we should concentrate ourself on software which runs nativly on Linux platforms, wine should be only a fallback solution. Maybe some software developers could also think "Why should I port my app to another platform than Windows, wine could also do my job?" - this could damage the availbility of nativly available software for Linux if everyone starts to wrap their applications about wine and we support this with packaging them. Do not feel blamed please, that's just my personal opinion, not more or less and btw. I don't hate wine. :) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: [EMAIL PROTECTED] Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libnanoxml2-java
On Thu Jul 17 17:31, Sveinung Kvilhaugsvik wrote: > Hello! Hi! > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/l/libnanoxml2-java > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/l/libnanoxml2-java/libnanoxml2-java_2.2.3.dfsg-4.dsc There seems to be a problem with the source package, I was getting md5sum errors trying to dget that .dsc file. > I also have some questions: > - I read that it was preferred to bump the changelog before each > upload to mentors. Will it be possible to shorten it and get it back > to 0 before the upload? Well, back to 1, which is the first Debian-revision. It's not critical, but I prefer changelog entries to correspond to Debian uploads. > - This is my first from scratch Debian package. Anything I could improve? > > I would be glad if someone uploaded this package for me if it is good enough. > If you can check the md5sum package above I'll happily look it over and sponsor. Matt -- Matthew Johnson signature.asc Description: Digital signature
RFS: xaos (updated package)
Dear mentors/QA team, I am looking for a sponsor for the new version 3.4-1 of package "xaos" (QA upload). It builds these binary packages: xaos - real-time interactive fractal zoomer The package appears to be lintian clean. The upload would fix these bugs: 244490, 478993 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xaos - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xaos/xaos_3.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards Sandro Tosi PS: Joey, I'm CCing you because you used to be his maintainer, so maybe you would sponsor this upload. -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xaos (updated package)
On Fri, Jul 18, 2008 at 01:25, Frank Lichtenheld <[EMAIL PROTECTED]> wrote: > Are you sure this change is safe? > > * debian/menu > - added explicitly the binary program instead of using sh to launch it > > Maybe there was a reason this made sure that the program was called > with HOME as the working directory. It may be, but for my testings, nothing "strange" happened. The only relevant reference to that in debian/changelog is way back in 1997 about setting /tmp (later then changed to HOME) before running the problem to save there the files. I tested it, and it asks for a directory now. In addition, (but I don't know if it's good or bad :) ), the desktop file in Ubuntu calls directly the binary, as the one now shipped in this Debian package. Thanks for the check! Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xaos (updated package)
On Fri, Jul 18, 2008 at 12:51:30AM +0200, Sandro Tosi wrote: > The upload would fix these bugs: 244490, 478993 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/x/xaos > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget http://mentors.debian.net/debian/pool/main/x/xaos/xaos_3.4-1.dsc > > I would be glad if someone uploaded this package for me. Are you sure this change is safe? * debian/menu - added explicitly the binary program instead of using sh to launch it Maybe there was a reason this made sure that the program was called with HOME as the working directory. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging for wine
Am Donnerstag, den 10.07.2008, 08:52 +0200 schrieb [EMAIL PROTECTED]: > i'd like to package (separately) some windows applications that run > nice under wine. > > does anybody know if exists a similar package (to steal ideas from)? > > i don't know where to install files, how to control which users can > access the apps in a multiuser environment, etc. Are there any apps in particular you're thinking of ? I suspect most apps that have their source available and are useful on Linux quickly get ported anyway, so wouldn't need wine. Cheers, Jelmer -- Jelmer Vernooij <[EMAIL PROTECTED]> - http://samba.org/~jelmer/ Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bzr-search
Jelmer Vernooij <[EMAIL PROTECTED]> writes:
> bzr-search - Search plugin for Bazaar
Thanks for packaging so many useful things for Bazaar.
However, please re-work the synopsis for this (and any other packages)
so that it is an appositiv clause, as described in
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis>.
The general test is to see if the synopsis makes sense when it
populates the hypothetical sentence template:
is {the,a,an}
For example this package's synopsis would be better as:
search plugin for Bazaar
--
\ “The truth is the most valuable thing we have. Let us economize |
`\ it.” —Mark Twain, _Following the Equator_ |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libnanoxml2-java
>> The package can be found on mentors.debian.net: >> - URL: http://mentors.debian.net/debian/pool/main/l/libnanoxml2-java >> - Source repository: deb-src http://mentors.debian.net/debian unstable >> main contrib non-free >> - dget >> http://mentors.debian.net/debian/pool/main/l/libnanoxml2-java/libnanoxml2-java_2.2.3.dfsg-4.dsc > > There seems to be a problem with the source package, I was getting > md5sum errors trying to dget that .dsc file. > Hmm... Seems like an old version of the orig (I changed get-orig-source) still was there. Fixed. The new upload can be found by running dget http://mentors.debian.net/debian/pool/main/l/libnanoxml2-java/libnanoxml2-java_2.2.3.dfsg-1.dsc >> I also have some questions: >> - I read that it was preferred to bump the changelog before each >> upload to mentors. Will it be possible to shorten it and get it back >> to 0 before the upload? > > Well, back to 1, which is the first Debian-revision. It's not critical, > but I prefer changelog entries to correspond to Debian uploads. > In the new upload I have gone back to 1. (That and the new orig is the only change) >> - This is my first from scratch Debian package. Anything I could improve? >> >> I would be glad if someone uploaded this package for me if it is good enough. >> > > If you can check the md5sum package above I'll happily look it over and > sponsor. > Thank you very much. Sveinung -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dkms
Hi, On Monday 09 June 2008 01:55:51 David Paleino wrote: > > > DKMS is a framework designed to allow individual kernel modules to be > > > upgraded without changing the whole kernel. It is also very easy to > > > rebuild > > > modules as you upgrade kernels. > > > > please elaborate on the advantages of this compared to the approach > > debian has taken: modules-source packages with m-a and prebuild modules > > through conglomeration packages. > > I'm just starting using dkms, and I've always used m-a, so I cannot really say > which one is better. > One example scenario I might think of is getting newer modules than the ones > present in Debian, at any given time. If a sysadmin needs a certain module he > should currently hack a bit to get m-a build the new source (I've experimented > this a while ago for ndiswrapper -- I needed a version newer than the one in > Debian -- but things might have changed since then). The drawback is that the > module isn't installed in a fancy .deb format. But, well, sysadmins should > know > what they're doing, shouldn't they? Just wanted to add that Ubuntu kernel team member has published a presentation that gives more detailed information about DKMS from a packagers perspective. http://blog.phunnypharm.org/2008/07/dkms-presentation.html Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to not break dependant packages
On Thu, 17 Jul 2008, Stefan Potyra wrote: > On Thursday 17 July 2008 15:15:25 Sean McE wrote: > > On current packaging there is no way to express the dependency on > > upstream version only, > [..] > > actually, there is: > Depends: foo (>= 1.2.1), foo (<< 1.2.1+) You generally want Package: bar Depends: (foo >= 1.2.1), foo (<< 1.2.2~) or similar. An alternative is Package: foo Provides: foo-api-1.2.1 Package: bar Depends: foo, foo-api-1.2.1 or similar. The second is slightly better, because it enables you to avoid having to rebuild bar if the api/abi doesn't change when you move to 1.2.2. [Though frankly, plugins should be using a frozen API with an unchanging, well thought out interface; rapidly changing APIs for plugins is fundamentally broken.] Don Armstrong -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bzr-avahi
On Thu, Jul 17, 2008 at 10:40 PM, Jelmer Vernooij <[EMAIL PROTECTED]> wrote: > Dear mentors, > > I am looking for a sponsor for my package "bzr-avahi". > > * Package name: bzr-avahi > Version : 0.1~bzr17-1 Is there any reason you're packaging such an old version? I put out a 0.2.0 tarball back in February, and never put out a 0.1 release. James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
