Changing source package name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to change the name of a source package; is there anything non-package-specific thing to do apart from simply using the new name in debian/changelog? I mean adding new header fields, etc. Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiHjsgACgkQGJRwVVqzMkMgigCeJCyL0fk+a2RPf8y8BQ4c5KFG W3AAn2rvpsfFhqAGFCva1BWmfHsx6YNc =fL+D -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libvrb (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Amaya, Amaya wrote: Sorry for my really long silence. I see this version is still not in Debian. Should I upload? Yes, please. Thanks! - -- cc Székelyi Szabolcs wrote: Dear mentors, I am looking for a sponsor for the new version 0.5.1-5 of my package libvrb. Amaya sponsored the initial upload, I would prefer her for the update, too. It builds these binary packages: libvrb0- Virtual Ring Buffer library libvrb0-dev - Virtual Ring Buffer library - development files vbuf - Virtual Ring Buffer library - shell interface The package appears to be lintian clean. The upload would fix these bugs: 437455 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libvrb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libvrb/libvrb_0.5.1-5.dsc I would be glad if someone uploaded this package for me. Kind regards Székelyi Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH/87yGJRwVVqzMkMRAtlVAJ9Gx2yL6PuMqNL5lBX1IZbU2+7aDgCfYUrU q6w3Wc6mawb/LSKLAET2l5Y= =jK5Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: vamp-plugin-sdk -- audio analysis and feature extraction plugins (3rd try)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors / Multimedia Team / Sam, I am (still) looking for a sponsor for my package vamp-plugin-sdk. This is needed to build Sonic Visualiser, which is a very interesting piece of software for music analysis. It's far more than a usual audio analyzer. You can put layers on top of the waveform itself, so you san see beat onsets, spectrum, prominent frequency, power, notes, chords, etc on the same screen. Data displayed on these layers are provided by Vamp plugins, based on the original audio data. See [1] for details and examples. * Package name: vamp-plugin-sdk Version : 1.1b-1 Upstream Author : Chris Cannam [EMAIL PROTECTED] * URL : http://www.vamp-plugins.org/ * License : BSD Section : sound Vamp is an audio processing plugin system for plugins that extract descriptive information from audio data - typically referred to as audio analysis plugins or audio feature extraction plugins. Just like an audio effects plugin (such as a VST), a Vamp plugin is a binary module that can be loaded up by a host application and fed audio data. However, unlike an effects plugin, a Vamp plugin outputs not processed audio but some sort of symbolic information. Typical things that a Vamp plugin might calculate include the locations of moments such as note onset times, visual representations of the audio such as histograms, or curve data such as power or fundamental frequency. Hosts using Vamp plugins include Audacity and Sonic Visualiser. Although this package is not very useful by itself, I have a packaged Sonic Visualiser ready for upload, which Build-Depends on vamp-plugin-sdk, so Vamp has to make it through before I can send RFS for it. It builds these binary packages: libvamp-hostsdk2 - helper library for Vamp hosts written in C++ libvamp-sdk1 - helper library for Vamp plugins written in C++ vamp-examples - example Vamp plugins and host vamp-plugin-sdk - audio analysis and feature extraction plugins (SDK) The package appears to be lintian and pbuilder clean. The upload would fix these bugs: 463754 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk/vamp-plugin-sdk_1.1b-1.dsc I would be glad if someone uploaded this package for me. Kind regards, - -- cc [1] http://www.sonicvisualiser.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH+9bdGJRwVVqzMkMRAjtYAJ4ru+mr2EIyAA/QfKf0EE0rzwWeogCfbzaC 0TnGLLf5QoyNb8v2nAs3w6U= =cpbv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: vamp-plugin-sdk -- audio analysis and feature extraction plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors / Multimedia Team / Sam, I am looking for a sponsor for my package vamp-plugin-sdk. This is needed to build Sonic Visualiser, which is a very interesting piece of software for music analysis. It's far more than a usual audio analyzer. You can put layers on top of the waveform itself, so you san see beat onsets, spectrum, prominent frequency, power, notes, chords, etc on the same screen. Data displayed on these layers are provided by Vamp plugins, based on the original audio data. See [1] for details and examples. * Package name: vamp-plugin-sdk Version : 1.1b-1 Upstream Author : Chris Cannam [EMAIL PROTECTED] * URL : http://www.vamp-plugins.org/ * License : BSD Section : sound Vamp is an audio processing plugin system for plugins that extract descriptive information from audio data - typically referred to as audio analysis plugins or audio feature extraction plugins. Just like an audio effects plugin (such as a VST), a Vamp plugin is a binary module that can be loaded up by a host application and fed audio data. However, unlike an effects plugin, a Vamp plugin outputs not processed audio but some sort of symbolic information. Typical things that a Vamp plugin might calculate include the locations of moments such as note onset times, visual representations of the audio such as histograms, or curve data such as power or fundamental frequency. Hosts using Vamp plugins include Audacity and Sonic Visualiser. Although this package is not very useful by itself, I have a packaged Sonic Visualiser ready for upload, which Build-Depends on vamp-plugin-sdk, so Vamp has to make it through before I can send RFS for it. It builds these binary packages: libvamp-hostsdk2 - helper library for Vamp hosts written in C++ libvamp-sdk1 - helper library for Vamp plugins written in C++ vamp-examples - example Vamp plugins and host vamp-plugin-sdk - audio analysis and feature extraction plugins (SDK) The package appears to be lintian and pbuilder clean. The upload would fix these bugs: 463754 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk/vamp-plugin-sdk_1.1b-1.dsc I would be glad if someone uploaded this package for me. Kind regards, - -- cc [1] http://www.sonic-visualiser.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwA05GJRwVVqzMkMRAvrMAJ9fR5tzHZp4nrcdbbfQWQIC0bnxLACgocX/ vCpPhiq+2WacrOGBwJaNNGE= =GJMH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vamp-plugin-sdk -- audio analysis and feature extraction plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, the correct web address for Sonic Visualiser is: http://www.sonicvisualiser.org/ - -- cc SZÉKELYI Szabolcs wrote: Dear mentors / Multimedia Team / Sam, I am looking for a sponsor for my package vamp-plugin-sdk. This is needed to build Sonic Visualiser, which is a very interesting piece of software for music analysis. It's far more than a usual audio analyzer. You can put layers on top of the waveform itself, so you san see beat onsets, spectrum, prominent frequency, power, notes, chords, etc on the same screen. Data displayed on these layers are provided by Vamp plugins, based on the original audio data. See [1] for details and examples. * Package name: vamp-plugin-sdk Version : 1.1b-1 Upstream Author : Chris Cannam [EMAIL PROTECTED] * URL : http://www.vamp-plugins.org/ * License : BSD Section : sound Vamp is an audio processing plugin system for plugins that extract descriptive information from audio data - typically referred to as audio analysis plugins or audio feature extraction plugins. Just like an audio effects plugin (such as a VST), a Vamp plugin is a binary module that can be loaded up by a host application and fed audio data. However, unlike an effects plugin, a Vamp plugin outputs not processed audio but some sort of symbolic information. Typical things that a Vamp plugin might calculate include the locations of moments such as note onset times, visual representations of the audio such as histograms, or curve data such as power or fundamental frequency. Hosts using Vamp plugins include Audacity and Sonic Visualiser. Although this package is not very useful by itself, I have a packaged Sonic Visualiser ready for upload, which Build-Depends on vamp-plugin-sdk, so Vamp has to make it through before I can send RFS for it. It builds these binary packages: libvamp-hostsdk2 - helper library for Vamp hosts written in C++ libvamp-sdk1 - helper library for Vamp plugins written in C++ vamp-examples - example Vamp plugins and host vamp-plugin-sdk - audio analysis and feature extraction plugins (SDK) The package appears to be lintian and pbuilder clean. The upload would fix these bugs: 463754 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk/vamp-plugin-sdk_1.1b-1.dsc I would be glad if someone uploaded this package for me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwCdNGJRwVVqzMkMRAkp4AJ9VkXVTunRsgDkpnebpr1MisvkdGgCfYFE4 LcnFRL1TU9J2ximcHJZ0XPw= =UNAZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help with watch file -- pre-release upstream versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leo costela Antunes wrote: Székelyi Szabolcs wrote: What's the usual way of handling preX upstream version numbers in watch files? I'm having trouble because uscan considers 1.0pre3 newer than 1.0. Perhaps mangling the upstream version to use the tilde (~) as a separator? But I don't really know if uscan even recognizes it... Thanks to all, it works this way. - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHsL0XGJRwVVqzMkMRAq/jAJ9FhO+irUtptNuuepW4AxBrgeAD2gCdEOxq zS0+5kZ1owexjkXz6qqAG/Q= =QW7T -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: vamp-plugin-sdk -- audio analysis and feature extraction plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package vamp-plugin-sdk. * Package name: vamp-plugin-sdk Version : 1.1b-1 Upstream Author : Chris Cannam [EMAIL PROTECTED] * URL : http://www.vamp-plugins.org/ * License : BSD Section : sound Vamp is an audio processing plugin system for plugins that extract descriptive information from audio data - typically referred to as audio analysis plugins or audio feature extraction plugins. Just like an audio effects plugin (such as a VST), a Vamp plugin is a binary module that can be loaded up by a host application and fed audio data. However, unlike an effects plugin, a Vamp plugin outputs not processed audio but some sort of symbolic information. Typical things that a Vamp plugin might calculate include the locations of moments such as note onset times, visual representations of the audio such as histograms, or curve data such as power or fundamental frequency. Hosts using Vamp plugins include Audacity and Sonic Visualiser. Although this package is not very useful by itself, I have a packaged Sonic Visualiser ready for upload, which Build-Depends on vamp-plugin-sdk, so Vamp has to make it through before I can send RFS for it. It builds these binary packages: libvamp-hostsdk2 - helper library for Vamp hosts written in C++ libvamp-sdk1 - helper library for Vamp plugins written in C++ vamp-examples - example Vamp plugins and host vamp-plugin-sdk - audio analysis and feature extraction plugins (SDK) The package appears to be lintian and pbuilder clean. The upload would fix these bugs: 463754 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk/vamp-plugin-sdk_1.1b-1.dsc I would be glad if someone uploaded this package for me. Kind regards, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHsOEsGJRwVVqzMkMRAkxyAJ4kawwdx549dQkQGVKdJxaTUjgVDACfbyy5 9KhGTwbYfM08vWmOB/laSq0= =BQzp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Help with watch file -- pre-release upstream versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi mentors, What's the usual way of handling preX upstream version numbers in watch files? I'm having trouble because uscan considers 1.0pre3 newer than 1.0. Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHr6OsGJRwVVqzMkMRAkGJAJ9vz5f/dhC35Himh3yVF//w4PLXdQCdGSbo mZRhO3+yq2PIqkwxA4iNWvQ= =3dvl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Change of address in GPL 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giovanni Mascellani wrote: Should I copy in debian/copyright the old address or the new one? Or maybe should I change also the address contained in the license statement in the source code files? debian/copyright is the license for the packaging itself, it's up to you what you put in it (unless it complies with Policy, of course). And said so, you should use the new address. I think this doesn't worth changing upstream code, even if it's only the license text. You should leave the copyright for the upstream code untouched and file a bug in the upstream BTS. Cheers, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHIRRgGJRwVVqzMkMRApGtAJ9dWBshZIjvPJa1fxdpI4ROiHVLqACfV1Ai hgtBJolk+7nSD1lCSFXBex0= =OU5e -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libvrb (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 0.5.1-5 of my package libvrb. Amaya sponsored the initial upload, I would prefer her for the update, too. It builds these binary packages: libvrb0- Virtual Ring Buffer library libvrb0-dev - Virtual Ring Buffer library - development files vbuf - Virtual Ring Buffer library - shell interface The package appears to be lintian clean. The upload would fix these bugs: 437455 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/l/libvrb - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/l/libvrb/libvrb_0.5.1-5.dsc I would be glad if someone uploaded this package for me. Kind regards Székelyi Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG/ZozGJRwVVqzMkMRAjh3AJ4hT2CUhjOnUz/zAXnEJBmAKk6EgQCglRuY dmFf7SYcbCy6G2kWr1xpgsU= =2eog -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Kemp wrote: On Fri, Apr 13, 2007 at 05:33:29PM -0400, Kamaraju S Kusumanchi wrote: I want to run software only from Stable (ie Etch) when I am doing non-debian related work. However, when I am doing debian related work (ex :- fixing some bugs in the BTS) I want to work in unstable (ex :- compile packages for sid). Is this kind of think possible? You have several choices here: * Use pbuilder to setup a build environment. heavyweight but simple. * Use chroots for building. simple and well understood. These two choices suffer in that you can't get a graphical environment within them. So if you build a package for sid which used Xorg you couldn't test it. You can. Just run an sshd inside the chroot and enable X forwarding on the ssh server sitting inside and the ssh client connecting from outside (from an xterm, of course). Reards, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGIALAGJRwVVqzMkMRAmGRAJ4kFtj6jtRmMjAgPo2QpTAP00WG8ACfdUlx ZrXcDGqPwDg43cPl2hJJHrQ= =b7MW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make or $(MAKE) ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Plessy wrote: As one of the program I package was recently automakified, I had to change debian/rules to deal with this. While comparing with other packages, I realised that often $(MAKE) is used instead of make in debian/rules. In case of trivial packages which do not seem to expect something fancy from the enviroment, are both commands equivalent ? To stay on the safe side, you should use $(MAKE); see http://www.gnu.org/software/make/manual/make.html#MAKE-Variable Bye, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGF4gYGJRwVVqzMkMRAhJhAJ9LVlCqh4KY624skCGXmyBs2a7/PACeMV70 BuAZZmez8+KCG46Rtw5YrAM= =84BX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broken packages?
Hi, On 1/24/07, Székelyi Szabolcs [EMAIL PROTECTED] wrote: I have a package called morg-mailcommands that depends on Postfix. Trying to install it with aptitude gives (...) You are missing some important pieces of information: 1) How you tried to install the package I tried `apt-get install morg-mailcommands` and the same with aptitude. 2) Where is this package (so we can look at it) Sorry, I cannot give you the source, but I can provide any packaging information. Here are the main control fields: == Package: morg-mailcommands Source: morg Version: 0.1.1 Priority: optional Section: non-free/admin Maintainer: Székelyi Szabolcs [EMAIL PROTECTED] Pre-Depends: morg-base Depends: adduser, morg-keyring, procmail, gnupg, sudo, postfix Architecture: all == The question is why doesn't exim4 get removed when installing morg-mailcommands (`apt-get install morg-mailcommands`) (which pulls in postfix which conflicts with exim4)? Thanks, -- Szabolcs
APT crazyness
Hi, I have a package which depends on linux-image-2.6.16-2-686 (from backports.org). I can't install it with apt-get because: The following packages have unmet dependencies: morg: Depends: linux-image-2.6.16-2-686 but it is not going to be installed However, I can install linux-image-2.6.16-2-686 (and its dependencies) without any problem. I can't understand why linux-image-2.6.16-2-686 is not installed automatically. Here is my apt.conf: == APT::Default-Release sarge; == and my preferences file: == Package: lsb-base Pin: release a=sarge-backports Pin-priority: 999 Package: linux-image-2.6.16-2-686 Pin: release a=sarge-backports Pin-Priority: 999 Package: initramfs-tools Pin: release a=sarge-backports Pin-Priority: 999 Package: udev Pin: release a=sarge-backports Pin-Priority: 999 Package: module-init-tools Pin: release a=sarge-backports Pin-Priority: 999 == It can be seen that linux-image-2.6.16-2-686 has a higher priority than the default. Another interesting thing is `apt-get -t sarge-backports install morg` works fine (it silently installs linux-image-2.6.16-2-686). Could someone explain what's happening and how can I fix this (so the same happens as with the -t sarge-backports switch)? Thanks, -- Szabolcs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
broken packages?
Hi, I have a package called morg-mailcommands that depends on Postfix. Trying to install it with aptitude gives E: Unable to correct problems, you have held broken packages. E: Unable to correct dependencies, some packages cannot be installed E: Unable to resolve some dependencies! Some packages had unmet dependencies. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following packages have unmet dependencies: morg-mailcommands: Depends: postfix but it is not installable Removing all exim4 packages fixes the problem, however I would like to ask: * aptitudes says I have held broken packages. `dpkg --get-selections` says I have no held packages at all. Is this a (small) bug in aptitude? * Why is my package considered broken? All dependencies are correct. Should it explicitly conflict with exim4? (I think this is pointless since postfix already does.) * How can I make aptitude to remove exim4 when installing morg-mailcommands? Even the -f flag to aptitude doesn't help. Thanks, -- Szabolcs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Bedogni wrote: Hi mentors made my first libpackage and the program is the following. When i launch pbuilder on another package that uses my library-package i got that he can't use the include. I use the package from a local repository. You should add a Build-Depends line to the control file of the other package. You get errors because the development package containing the header files is missing from the jail used to build the package. For example, if your package is called libfoo (thus you build libfoo-dev, too), you should add: Build-Depends: libfoo-dev to the debian/control file of the package which fails to build. This requires that the package libfoo-dev to be available (ie. installable) inside the pbuilder jail. You can use the local repository for that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFZiPwGJRwVVqzMkMRAmnyAJ9415o1AJAD9bPGxlAz1u/tKdL/kACgnXDi nqF/h586cLMIhVqg40L6wLA= =2KHA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Gerrit Pape wrote: On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote: can anyone tell why ftpds do conflict with each other and why httpds do not? Actually the httpds should conflict too as they install listeners on 0.0.0.0:80. E.g.: With no httpd installed, install the apache package, apache will listen on 0.0.0.0:80; now install the thttpd package, it'll work fine, but no thttpd daemon will run afterwards, because it fails to bind to 0.0.0.0:80, see syslog; reboot the machine, and you'll be surprised to see the thttpd daemon run, and not apache, because thttpd gets started first. There was a saying a few years ago, that comes into my mind regarding this problem. It read something like this: Linux *is* user-friendly... not fool-friendly or looser-friendly. Now consider the two choices: a) keep Conflicts - Novice user not knowing what's happening exactly, tries to install two servers providing the same functionality. Installation will fail. User doesn't know why. - Experienced system administrator tries to install the two servers. He exactly knows what he wants. He won't be able to do so. Experienced system administrator gets mad. Someone mentioned earlier, he could rebuild at least one of the servers after removing the Conflicts field. Experienced system administrator gets madder. This problem typically arises in enterprise IT infrastructures, where recompiling the package every time it gets updated is *not* an option. Experienced system administrator gets absolutely mad. b) drop Conflicts - Novice user installs the packages in question. *If* he notices that there is some problem, looks at logs (as I remember, apache tells about the problem on the console, too), searches on Google, gets tons of results. After reading three of them, he knows what the problem is, he can fix it, he will *understand* what he's doing. User is happy. - Experienced system administrator installs the packages, reconfigures them to use different ports/interfaces/addresses. Experienced system administrator is happy. (*) IMHO, two servers binding to the same socket by default, is not enough reason for them to conflict with each other. Let me remind you that the case of MTAs is another story. Bye, - -- Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFUPFhGJRwVVqzMkMRAnJwAJsFMFC1fofF/FpxjQDhPHXyU1Ze2wCfWayB muzY+HC+iCUMAX782xZDfT4= =Lp4Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libvrb uploaded (was: Re: No response to RFS -- what to do now?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Amaya wrote: Székelyi Szabolcs wrote: I've posted an [0]RFS about 2 weeks ago, but the package has received no attention from official developers. I'll upload it. Sorry I missed your RFS. Thanks. A package using this lib will follow soon, I hope. First I need to bring it into usable state. Thanks again, - -- Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFT7JdGJRwVVqzMkMRAkv8AJ9TjERYEr3rS4s4/71ZKQw0FOhBwwCeLahi sBG0JmoZJW8Q42EK3CTAA54= =bC79 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, can anyone tell why ftpds do conflict with each other and why httpds do not? In case of MTAs, the conflict is reasonable due to the possibility of accessing a mailbox at the same time, but I can't see the point in the case of ftpds. Thanks, - -- Szabolcs Jean-Sebastien Pilon wrote: I agree with you, this is un-necessary conflicts. -Original Message- From: Gerrit Pape [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 11:02 AM To: debian-mentors@lists.debian.org Subject: Re: 2 ftpds packages conflicts On Mon, Nov 06, 2006 at 10:23:19AM -0500, Jean-Sebastien Pilon wrote: It might not be the best place to aask this, but I have been seeking for help elsewhere and found no satisfactory resolution to my problem and it is package related ;) I run a system with 2 ftpds (pure-ftpd and vsftpd) and they are both debian stock packages Whenever I try to do anything with apt, I get the following message. If I try to install something, it wants to remove one of the ftpds packages... I tried putting both packages on hold, no success, it still wants to remove it. Any idea how i can fix this ? This is a general problem with packages providing services and declaring conflicts for this reason. I suggested, and personally implement, a solution to this, but others seem not to like it that much http://lists.debian.org/debian-devel/2005/08/msg01314.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFT7hmGJRwVVqzMkMRAqztAKCP1izhRDuanEiZ8io2OzsFTxXiqgCglkFy Fb/OhnAPCr9f9b0NT202sOE= =SmGF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
No response to RFS -- what to do now?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've posted an [0]RFS about 2 weeks ago, but the package has received no attention from official developers. What is the usual procedure in this case? Wait longer, re-post the RFS or try to accept that the package will never be a part of Debian? Thanks, - -- Szabolcs [0] http://lists.debian.org/debian-mentors/2006/10/msg00207.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFTmw6GJRwVVqzMkMRAkYsAKCYCSmrzGy7ZuBWPuOaeVNrUZoQpACfRQrd TnaqmzdTZsw0NHP+8t03I7U= =dUrv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Adopting a package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Mentors, when adopting a package, sould I first contact the original maintainer and the the retitle the 'O:' bug to 'ITA:' or retitle it first and contact the maintainer afterwards? As I remember, a non-dd is allowed to adopt a package, am I right? Thanks, - -- Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFTNNjGJRwVVqzMkMRAm0hAJ9FZll0OsYzlG4GOf3Ak6OGTg+oggCgm1n8 ABiUtqaRlV+Go8uJTCROsr4= =2j9Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libvrb -- Virtual Ring Buffer library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package libvrb. Fixes minor issues proposed by James Westby (http://lists.debian.org/debian-mentors/2006/09/msg00769.html). * Package name: libvrb Version : 0.5.1-3 Upstream Author : Philip Howard [EMAIL PROTECTED] * URL : http://vrb.slashusr.org/ * License : LGPL Section : libs It builds these binary packages: libvrb0- Virtual Ring Buffer library libvrb0-dev - Virtual Ring Buffer library - development files vbuf - Virtual Ring Buffer library - shell interface The package is lintian, linda and pbuilder clean, apart from a few hyphen-used-as-minus-sign which should be fixed upstream. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/l/libvrb - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/l/libvrb/libvrb_0.5.1-3.dsc I would be glad if someone uploaded this package for me. Kind regards - -- Székelyi Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFMMg5GJRwVVqzMkMRAqhzAJ9zJMDR68CUA/19galE8UKdvJoKMACffwUT Eh3XrbvT/kj4d5midxOn9RE= =5k+3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: naming and relationships of development packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Rougon wrote: Székelyi Szabolcs [EMAIL PROTECTED] wrote: That's right. But why is Replaces needed in the case of an MTA? If a package Providing mail-transport-agent is installed, and the user is about to explicitly install another package which also Provides and Conflicts with mail-transport-agent, then the currently installed package will be removed anyway before the new one is installed. I do not see the need for Replaces. I didn't say it's needed. I even posted an experiment showing that with the tools from unstable, it makes no difference in: apt-get -s install virtual package But that's not right. With this, what you've tested is installing the virtual package installs the real package instead. That's the way it should be. It shows that, even when not using Replaces, things do work in this situation. You are absolutely right, but that's not what the thread was about. But the question is: is Replaces needed to get the previous version removed upon installation of the new package? What previous version are you talking about? Which new package? Installing libfoo1-dev when libfoo0-dev is already installed. The original thread was about the need for Replaces: libfoo-dev among the control fields of libfoo0-dev and libfoo1-dev. In this case the new package is libfoo1-dev. I think you misunderstood the topic of the thread. We are talking about two different things. Sorry if this is because of my poor composition. What if the user forces the installation of the new package by overriding the conflict (dpkg --force-conflicts)? Then Replaces can be used to take over the files contained in both packages, so dpkg won't complain about overwriting files which are contained in another package, resulting in a somewhat more consistent installation. So, it's right because dpkg doesn't complain when the user it shooting itself in the foot? If the user uses --force-conflicts, he is on its own. Agreed. I would add that if we can, we should minimize the impact of a power user. That's what I'm trying to do. It's not about dpkg not complaining, it's about dpkg not failing because of trying to overwrite foo.h which is also in package libfoo0-dev (or something similar). I disagree. Provides is used for that. It has nothing to do with Replaces. Fine. I tried to explain how the use of Replaces in the MTA example could be justified with the information given in Policy. If that is not enough for you, go argue with the Policy maintainers. I won't. I understand the role of Replaces now. If a package contains files those are contained in another package also, then Replaces must be used. That's the simple rule. And if foo.h is contained in libfoo0-dev and libfoo1-dev, then they should replace each other. An easy and extensible way of doing this is make them Provide the libfoo-dev virtual package and make them Conflict with libfoo-dev also, meaning all other versions. Thus only one version will be installed. Thanks for your comments anyway. - -- Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLrVUGJRwVVqzMkMRAqBjAKCIC3qH5Azl7A/fV9Il8sQ0DCS6/gCfSmH5 YRr2TUtNWNbG7mNVH76xzZg= =bwZw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: naming and relationships of development packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ming Hua wrote: On Sun, Oct 08, 2006 at 11:14:51PM +0200, Székelyi Szabolcs wrote: Hi, Ming Hua wrote: On Fri, Oct 06, 2006 at 01:10:32AM +0200, Székelyi Szabolcs wrote: James Westby wrote: * Do you need Replaces: libvrb-dev as well? I have seen similar (ie. development) packages with and others without this. Do I? If you want to support upgrading for users who use you previous unofficial package, and libvrb0-dev ships the same files as libvrb-dev, then yes, you need Replaces: (and probably also Conflicts:) libvrb-dev. There is no libvrb-dev package. It is a virtual package to ensure that only one development version is installed at a time (Provides + Conflicts). I see. Didn't notice libvrb0-dev Provides libvrb-dev before, sorry. I know the naming of -dev packages is a very controversial topic, so I want to hear your (and other people's) opinion. The soversion is usually added to the -dev package name to be able to support multiple versions of a library off-line, which means all versions can be found in the archive, but only one can be installed on the user's machine. I think what I really wanted to ask is what would be a good reason to have multiple versions of a library avaiable in the archive. The package I maintain, scim, changes its SONAME once in a while, but keeps API compatible all the way, What if it doesn't? All dependent packages will suddenly FTBFS. You can say that it's the responsibility of upstream to maintain interface compatibility, or rename the headers if they can't. But from our point of view, it's better to be on the safe side. It's a bit similar to the well-known saying among engineers, Be liberal in what you accept, be conservative in what you send.. Supporting multiple versions in the archive makes us liberal in what we accept, allowing upstream to make the mistake of not renaming header files. so I only keep one -dev package, without the SONAME. My impression is that if you make both libfoo0-dev and libfoo1-dev provide and conflict libfoo-dev, you are implying that porting a package building against libfoo0 to building against libfoo1 should be zero or minimal effort. I'm implying just the opposite. libfoo-dev is just a tool to ensure that only one libfooX-dev is installed. This way there is no need to enumerate all libfooX-dev packages in the Conflicts field of all of them. Look at libcupsys2-dev: Conflicts: libcupsys1-dev, libcupsys-dev, cupsys ( 1.1.22-3) If libcupsys1-dev Provided libcupsys-dev, then libcupsys1-dev could have been left out of this list. The problem with this is that it doesn't scale with the maturity of the package. libfoo53-dev should list libfoo0-dev, libfoo1-dev, libfoo2-dev, ..., libfoo52-dev in its Conflicts field. But if all of them Provides libfoo-dev, then it is enough for libfoo53-dev to Conflict with the single virtual package libfoo-dev (among possible other conflicts, of course). Keeping more versions of the development package enables building all other packages using different (so)versions of the library, while keeping just one may work for building some packages, but may break others if the two versions are not API compatible. If that's the case, isn't keeping only one -dev package a better choice, if just to encourage other packages to migrate to the newer version of the library? We can't force upstream to switch to the new interface version. If they decide to use the previous version of the library for some time, their software may FTBFS. I don't want to (even temporarily) kick other packages from the archive just because they don't/can't use the newest API. The question is, which mechanism should be used to accomplish this? Do we need Replaces:? I think Provides and Conflicts is enough. The Debian Library Packaging Guide (written by Junichi Uekawa, mentioned by a lot of DDs, but AFAIK is still an unofficial guide) seems to agree with you: But I don't agree with myself. ;) If libfoo0-dev and libfoo1-dev both contain foo.h, then at least one of them must Replace the other(s). Again, it's the same with Conflicts, it's easier to accomplish this using virtual packages. Thanks for your remarks, - -- Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLrdVGJRwVVqzMkMRAmo+AKCGrkGMck2FbwdfBIrODXsZ95+q+QCcDFsB NVN0+k2FEeevb33Xruqa1IA= =0F3h -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: naming and relationships of development packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Rougon wrote: Székelyi Szabolcs [EMAIL PROTECTED] wrote: The soversion is usually added to the -dev package name to be able to support multiple versions of a library off-line, which means all versions can be found in the archive, but only one can be installed on the user's machine. The question is, which mechanism should be used to accomplish this? Do we need Replaces:? I think Provides and Conflicts is enough. I think it's an analogous case to that of the MTA in Policy, and therefore, that Replaces should be used. That's right. But why is Replaces needed in the case of an MTA? If a package Providing mail-transport-agent is installed, and the user is about to explicitly install another package which also Provides and Conflicts with mail-transport-agent, then the currently installed package will be removed anyway before the new one is installed. I do not see the need for Replaces. However, I'm not sure whether any of our current tools (apt, dpkg, etc.) makes any difference if it is used or not, in this context. Actually, I tested one case with the apt from unstable: apt-get -s install virtual package Having the Replaces in addition to the Provides and Conflicts made no difference: foo 1.0-4 ~ Provides: foo-pkg Conflicts: foo-pkg # apt-get -s install foo-pkg Reading package lists... Done Building dependency tree... Done Note, selecting foo instead of foo-pkg The following NEW packages will be installed: foo 0 upgraded, 1 newly installed, 0 to remove and 240 not upgraded. Inst foo (1.0-4 Florent Rougon's packages for experiments:unstable) Conf foo (1.0-4 Florent Rougon's packages for experiments:unstable) foo 1.0-5 ~ Provides: foo-pkg Conflicts: foo-pkg Replaces: foo-pkg # apt-get -s install foo-pkg Reading package lists... Done Building dependency tree... Done Note, selecting foo instead of foo-pkg The following NEW packages will be installed: foo 0 upgraded, 1 newly installed, 0 to remove and 240 not upgraded. Inst foo (1.0-5 Florent Rougon's packages for experiments:unstable) Conf foo (1.0-5 Florent Rougon's packages for experiments:unstable) But that's not right. With this, what you've tested is installing the virtual package installs the real package instead. That's the way it should be. But the question is: is Replaces needed to get the previous version removed upon installation of the new package? After an hour of experimentation, it turned out that * dpkg *will not* automatically remove the old package regardless of the presence of the Replaces field * apt *will* remove the old package regardless of the presence of the Replaces field which means that there is no need for Replaces to accomplish the above. But... What if the user forces the installation of the new package by overriding the conflict (dpkg --force-conflicts)? Then Replaces can be used to take over the files contained in both packages, so dpkg won't complain about overwriting files which are contained in another package, resulting in a somewhat more consistent installation. According to this, I will add Replaces: libvrb-dev to libvrb0-dev. You can check how this situation is handled in the archive with the following command: grep-available -F Provides -s Package,Provides,Replaces,Conflicts \ -e .*-dev | less You'll see that many packages use the Replaces, and many don't. I smell mass bug filing... ;) Some even Replace and Conflict with the various -dev packages, but I don't think it's a good idea (Replacing and Conflicting with the virtual package should be enough): Package: libcupsys2-dev Provides: libcupsys-dev Replaces: libcupsys1-dev, libcupsys-dev, cupsys ( 1.1.22-3) Conflicts: libcupsys1-dev, libcupsys-dev, cupsys ( 1.1.22-3) This is for historical reasons, I guess. I'm not sure I understand the example about MTAs in Policy 7.5.2. Why is Replaces needed at all in this particular case? Is this also valid in the case of development packages? Why aren't Conflicts + Provides enough? Quoting § 7.5.2: Secondly, Replaces allows the packaging system to resolve which package should be removed when there is a conflict Based on that, I'd argue that the meaning of the Replaces in the MTA example is: Any real package providing mail-transport-agent should be favored upon the virtual package mail-transport-agent. i.e., if something pulls in mail-transport-agent for whatever reason (e.g., a dependency or 'apt-get install virtual package'), then in no case should the virtual package mail-transport-agent be installed; all other packages Replacing it are preferred to resolve the situation (which is fortunate, since of course, you cannot install a virtual package). I disagree. Provides is used for that. It has nothing to do with Replaces. Bye, - -- Szabolcs -BEGIN PGP
naming and relationships of development packages (was: Re: RFS: libvrb -- Virtual Ring Buffer library)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Ming Hua wrote: On Fri, Oct 06, 2006 at 01:10:32AM +0200, Székelyi Szabolcs wrote: James Westby wrote: * Do you need Replaces: libvrb-dev as well? I have seen similar (ie. development) packages with and others without this. Do I? If you want to support upgrading for users who use you previous unofficial package, and libvrb0-dev ships the same files as libvrb-dev, then yes, you need Replaces: (and probably also Conflicts:) libvrb-dev. There is no libvrb-dev package. It is a virtual package to ensure that only one development version is installed at a time (Provides + Conflicts). I am also curious why did you change the name of the development library package in the first place. See Policy 8.4. I know the naming of -dev packages is a very controversial topic, so I want to hear your (and other people's) opinion. The soversion is usually added to the -dev package name to be able to support multiple versions of a library off-line, which means all versions can be found in the archive, but only one can be installed on the user's machine. The question is, which mechanism should be used to accomplish this? Do we need Replaces:? I think Provides and Conflicts is enough. I'm not sure I understand the example about MTAs in Policy 7.5.2. Why is Replaces needed at all in this particular case? Is this also valid in the case of development packages? Why aren't Conflicts + Provides enough? Thanks, - -- Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKWpLGJRwVVqzMkMRAm1SAJ9BUjLaao38BS9v0TEn7uvrtDx7+wCfVhHg DlgkSEzanAlo7yYtxM7b798= =h6ES -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libvrb -- Virtual Ring Buffer library
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Westby wrote:
On (26/09/06 22:09), Székelyi Szabolcs wrote:
I am looking for a sponsor for my package libvrb. This is an update to
the (so far unsponsored) previous version 0.5.1-1.
Hi, I cannot sponsor, but I have a few comments for you.
First of all, thanks for your time to investigate the package.
* The dev-ref recommends indenting the Homepage: pseudo-field by two
spaces.
Because of word-wrapping... Thanks. Done.
* Do you need Replaces: libvrb-dev as well?
I have seen similar (ie. development) packages with and others without
this. Do I?
* Please move away from using ${Source-Version} in debian/control
http://lists.debian.org/debian-mentors/2006/09/msg00228.html
Understood. Done.
* Drop the blank line from libvrb0-dev.install
Done.
* You don't need a - in front of rm -rf as it wont fail if the dir is
not present.
Although it did no harm, the source package is one byte smaller now. ;)
Done.
* Why are you not using the configure target? Your current setup makes
cross-compiling harder, and making a debug version of the package
difficult as well.
Policy does not mention the configure target, which means to me that the
autobuilders don't use it. Instead,
The build target should perform all the configuration and compilation
of the package.
Could you explain (or point to RTFM) how a configure target would be useful?
* Please add a watch file.
Done.
* Lintian gives a few
I: vbuf: hyphen-used-as-minus-sign usr/share/man/man1/vbuf.1.gz:66
that you might like to fix.
Actually there was an error in the man page. Thanks for spotting. Done.
Thanks again for your helpful comments. I will upload a new version if
questions left open in this mail are discussed.
Have a nice day,
- --
Szabolcs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFJZDoGJRwVVqzMkMRAsdUAJ0YICEVReSu5HqQ67JLOesYpOS86QCfeJ7O
b1OLQH0r4Xaq7u1YR2ooHzs=
=S9Vp
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libvrb -- Virtual Ring Buffer library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package libvrb. This is an update to the (so far unsponsored) previous version 0.5.1-1. * Package name: libvrb Version : 0.5.1-2 Upstream Author : Philip Howard [EMAIL PROTECTED] * URL : http://vrb.slashusr.org/ * License : LGPL Section : libs It builds these binary packages: libvrb0- Virtual Ring Buffer library libvrb0-dev - Virtual Ring Buffer library - development files vbuf - Virtual Ring Buffer library - shell interface The package is lintian, linda and pbuilder clean. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/l/libvrb - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/l/libvrb/libvrb_0.5.1-2.dsc I would be glad if someone uploaded this package for me. Kind regards Székelyi Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFGYjgGJRwVVqzMkMRArOFAJkBAHgjgvMcD8a1QCywyzxLC4JH7ACcCIt4 feI8bNqPoWgzxWajSJzPDnk= =VpSy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libvrb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package libvrb. * Package name: libvrb Version : 0.5.1-1 Upstream Author : Philip Howard [EMAIL PROTECTED] * URL : http://vrb.slashusr.org/ * License : LGPL Section : libs It builds these binary packages: libvrb0 - Virtual Ring Buffer library libvrb0-dev - Virtual Ring Buffer library - development files The package is lintian, linda and pbuilder clean. The upload would fix these bugs: 377551 (Upstream released 0.5.1 while packaging was in progress. That's why the ITP reports 0.5.0 but the package is actually 0.5.1.) The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/l/libvrb - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/l/libvrb/libvrb_0.5.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Székelyi Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE3oC5GJRwVVqzMkMRAnL+AJ9dKEJY+HTzICwTCggHjBBSj1aB5ACgkcCu VwKJhGUQPzbcTPAAbUjhC88= =Op/G -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
changelog.Debian.gz as a symbolic link
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm packaging a simple library building a shared lib and a development package as usual. The -dev package depends on the one containing the shared library. Policy says that it is permitted in this situation to symlink documentation coming with the -dev package to the files installed by the shared library package. Is this true in the case of changelog.Debian.gz? lintian emits a warning (syntax-error-in-debian-changelog line 0 found eof where expected first heading) while linda treats this an error (The package contains no changelog.Debian.) Anyway, does changelog.Debian.gz belong to the binary or the source package? In the latter case it would be reasonable to symlink changelog.Debian.gz. Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEwgvvGJRwVVqzMkMRAj/ZAJ0frqWvsSaHZhxnNlS/ZivNKB4oWwCeLDNq XYPRqWBQWGbBTc5g4ynKIbA= =zx97 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog.Debian.gz as a symbolic link
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eddy Petrisor wrote: Székelyi Szabolcs wrote: I'm packaging a simple library building a shared lib and a development package as usual. The -dev package depends on the one containing the shared library. Policy says that it is permitted in this situation to symlink documentation coming with the -dev package to the files installed by the shared library package. Is this true in the case of changelog.Debian.gz? If both packages come from the same source (as they should), you should symlink the /usr/share/doc/libpac-dev to the /usr/share/doc/libpac. Thank you for the advice. It's correct in this situation, but if the - -dev package installs API documentation (which is not the case in this particular package), this is obviously not the way to go. So the question is still on, is it allowed to symlink changelog.Debian.gz? -- cc ^^ is this a request for CC ? (done anyway) Thanks, but this is the signature (as the -- denotes). I read the list. Bye, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEwj3EGJRwVVqzMkMRAoiKAJ9v1V8MQBMkwvYVUfdUwblnTGHI4wCdE2TN 376mW3PlVAVtpL3DcOh66ZQ= =QMBH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: being_processed has a too-low limit again?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: On Mon, Jun 05, 2006 at 05:18:47PM +0200, Sz?kelyi Szabolcs wrote: I've sent an ITP on libvrb last night (at about 23:19 CET), but I cannot see it on d-d and in the BTS. However, I got the copy to my personal inbox. Do you have the bug number? No. It hasn't been assigned yet, I guess. I saw ITPs on d-d and in the BTS posted this afternoon. I can't find it. I mean more recent ITPs for _other_ packages, not mine. I remember in the past the being_processed page had a too-low limit: http://lists.debian.org/debian-www/2005/01/msg00186.html We have right now 969 ITP bugs, and recently crossed the 370,000 bug mark; I wonder.. Now should I try resending the ITP bug? However, the copy is in my inbox, I can copy the body from there. Or should I try reportbug again? Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEjJ3tGJRwVVqzMkMRAsh+AKCLN6NWpZW9iOCG+ed2l7XqUgiSfQCfZA0o kQBJNctW8b5FQ/mX/SlMnkQ= =kUjF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lost ITP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've sent an ITP on libvrb last night (at about 23:19 CET), but I cannot see it on d-d and in the BTS. However, I got the copy to my personal inbox. I saw ITPs on d-d and in the BTS posted this afternoon. Is it possible that the ITPs are not processed in FIFO-style? Or should I forward the ITP from my inbox to somewhere? Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEhEtWGJRwVVqzMkMRAjQiAJ43mqbrDNLZoA66QNOXy1CM7v4/9wCgkyxS 5pCmb/syttclWskhalNypv8= =zJDI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
