Bug#457741: Bug#460158: zsh-doc would not install
On Thu, 10 Jan 2008, Clint Adams wrote: On Fri, Jan 11, 2008 at 12:35:57AM +0100, arno renevier wrote: zsh-doc upgrade did not work today. I tried to uninstall, and reinstall, and it looks like package is uninstallable. Here is the output I get with aptitude install zsh-doc: This is bug #457741 on dpkg. I haven't investigated at all and I'm in no way an expert concerning info files. But from what I've read, I must say that I'm not yet sure that it's a bug in dpkg... Is there a real standard on what an info file should look like ? Or are we at the mercy of every output change of the info file generator ? I'd gladly fix install-info (until we manage to get rid of it that is :)) if someone could point me to relevant information. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#213907: inglayan
Brandon said that his dick grew 3 more inches in just 4 weeks http://www.ruyestsm.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457741: Bug#460158: zsh-doc would not install
reassign 457741 texinfo thanks On Fri, 2008-01-11 at 08:58:18 +0100, Raphael Hertzog wrote: On Thu, 10 Jan 2008, Clint Adams wrote: On Fri, Jan 11, 2008 at 12:35:57AM +0100, arno renevier wrote: zsh-doc upgrade did not work today. I tried to uninstall, and reinstall, and it looks like package is uninstallable. Here is the output I get with aptitude install zsh-doc: This is bug #457741 on dpkg. I haven't investigated at all and I'm in no way an expert concerning info files. But from what I've read, I must say that I'm not yet sure that it's a bug in dpkg... Is there a real standard on what an info file should look like ? Or are we at the mercy of every output change of the info file generator ? I'd gladly fix install-info (until we manage to get rid of it that is :)) if someone could point me to relevant information. I don't think we should fix this in dpkg. I don't think it's a bug in install-info, otherwise installing any package from testing/unstable on etch will fail, like on a partial upgrade. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#457741: Bug#460158: zsh-doc would not install
Processing commands for [EMAIL PROTECTED]: reassign 457741 texinfo Bug#457741: zsh-doc: Fails to configure Bug#457743: zsh-doc fails to install: No `START-INFO-DIR-ENTRY' and no `This file documents'. Bug reassigned from package `dpkg' to `texinfo'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Fri, 2008-01-11 at 01:24:33 +0100, Frans Pop wrote: On Friday 11 January 2008, you wrote: Joey, I don't think that that the Package-Type field ending up in the binary package can be qualified as bloat given that except the filename and the origin of the file, udeb can't be identified as such. I'm sorry, but I agree with Joey. There is absolutely no reason why we need the package type in the control file for udebs. They are already 100% identifyable by both section and extention. Well then there's also the argument that there's no point in having it in the source control either, it could be inferred from the section. But those seem quite weak and specific ways to do so. Anyway, I don't think that'd be clean, and we might want to use that field for other package types in the future (translation debs, or debugging debs come to mind). The way this was implemented basically just ignores the only current official user of the package type field, I mentioned I'd implement it that way one year ago (or so) on #d-b, and no one seemed to oppose, and I requested comments on the patch implementing this again on #d-b few days before committing. That does not mean that decision could not be changed, but I don't see a good reason to do so, the current implementation seems cleaner anyway. and is thus not policy compliant. The initial udeb support seems to have been implemented and deployed in an ad-hoc way, overriding[0] dpkg, which is perfectly fine, as that's how a lot of things are implemented and deployed in Debian. But I'd not go as far as calling that policy. regards, guillem [0] I'm not sure this strictly expresses the meaning I've in mind, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457741: Bug#460158: zsh-doc would not install
Le vendredi 11 janvier 2008, à 08:58:18 +0100, Raphael a écrit : On Thu, 10 Jan 2008, Clint Adams wrote: On Fri, Jan 11, 2008 at 12:35:57AM +0100, arno renevier wrote: zsh-doc upgrade did not work today. I tried to uninstall, and reinstall, and it looks like package is uninstallable. Here is the output I get with aptitude install zsh-doc: This is bug #457741 on dpkg. I haven't investigated at all and I'm in no way an expert concerning info files. But from what I've read, I must say that I'm not yet sure that it's a bug in dpkg... Is there a real standard on what an info file should look like ? Or are we at the mercy of every output change of the info file generator ? I'd gladly fix install-info (until we manage to get rid of it that is :)) if someone could point me to relevant information. Cheers, I checked texinfo manual, and there seems to be no indication about whether direntry should/could begin with whitespace or not. http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Installing-Dir-Entries.html arno signature.asc Description: Digital signature
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Fri, 2008-01-11 at 12:29:40 -0500, Joey Hess wrote: Your continual closusre of this bug report Sorry, but the closure was not intentional, just what was on the Reply-To, and didn't see Frans reopen until later. Also notice you also replyed with the -done CCed. and refusal to listen to us is becoming very annoying. I don't think I'm refusing to listen, but it seems that to listen implies doing as you guys please. I just wanted a convincing argument. But this is getting non-constructive, and at some point I might just give up and not care at all. :/ regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Guillem Jover wrote: Well then there's also the argument that there's no point in having it in the source control either, it could be inferred from the section. But those seem quite weak and specific ways to do so. Determining a file's type from its extension is weak and specific? Tell that to /var/lib/dpkg/info/*.p*. Tell that to everyone who has run dpkg -i *.deb and managed to not accidentially dpkg -i *.a (both ar files after all). Anyway, I don't think that'd be clean, and we might want to use that field for other package types in the future (translation debs, or debugging debs come to mind). You're designing for use cases that are not yet clear, and ignoring the current use case. I mentioned I'd implement it that way one year ago (or so) on #d-b, Um, all I got from your communication on this subject was that you would make it an official field, not that you would put it *in* the binary package. and no one seemed to oppose, and I requested comments on the patch implementing this again on #d-b few days before committing. That does not mean that decision could not be changed, but I don't see a good reason to do so, the current implementation seems cleaner anyway. If you cared so much about our opinion that you requested comments twice before, why are you continually ignoring our opinion now, and continually re-closing this bug report? -- see shy jo signature.asc Description: Digital signature
Processed: Re: Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Processing commands for [EMAIL PROTECTED]: # Reopening as Joey closed it accidentally by using reply-to-all. reopen 452273 Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item Bug reopened, originator not changed. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Guillem Jover wrote: There's 278 udebs in the current main Packages file. Each Package-Type field takes 19 bytes, so 5282 bytes of bloat. In comparison the Description field takes 49416 bytes. If you are really concerned about bloat, maybe you could trim those down instead. We are constantly trimming udeb descriptions. However, unlike this useless new field, udeb descriptions do have value -- they are displayed to the user. Your continual closusre of this bug report and refusal to listen to us is becoming very annoying. -- see shy jo signature.asc Description: Digital signature
Processed: tagging 460021
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.12 tags 460021 + pending Bug#460021: dpkg-dev: Typo in the French manpage for deb-substvars Tags were: l10n Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#172752: marked as done (dpkg-buildpackage messes up Description: in UTF-8 locale)
Your message dated Fri, 11 Jan 2008 20:39:48 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#172752: dpkg-dev: dpkg-buildpackage messes up Description: inUTF-8 locale has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.10.9 Severity: normal I ahev a package with Description in UTF-8. Until some time ago, all worked well, dpkg-buildpackage placed the Description verbatim into debian package. However, I found out now that if I compile the package in UTF-8 locale, Description is mangled. It seems that the encoding is assumed to be in ISO-8859-1 and is converted into UTF-8. Of course, since it was already in UTF-8, the result is mojibake. In 8-bit locales the Description is copied verbatim and all works well. I guess it has something to do with new perl's UTF-8 capabilities (as many other bugs already reported) -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux atlas15 2.4.17-grsecurity-1.9.2+xfs+unicodedeadkeys+pspa #2 Thu Sep 19 09:14:19 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 Versions of packages dpkg-dev depends on: ii binutils 2.13.90.0.10-2 The GNU assembler, linker and bina ii cpio 2.5-1 GNU cpio -- a program to manage ar ii make 3.80-1 The GNU version of the make util ii patch 2.5.4-11 Apply a diff file to an original ii perl [perl5] 5.8.0-13 Larry Wall's Practical Extraction ii perl-modules 5.8.0-13 Core Perl modules. -- no debconf information ---End Message--- ---BeginMessage--- On Thu, 12 Dec 2002, Radovan Garabik wrote: I ahev a package with Description in UTF-8. Until some time ago, all worked well, dpkg-buildpackage placed the Description verbatim into debian package. However, I found out now that if I compile the package in UTF-8 locale, Description is mangled. It seems that the encoding is assumed to be in ISO-8859-1 and is converted into UTF-8. Of course, since it was already in UTF-8, the result is mojibake. In 8-bit locales the Description is copied verbatim and all works well. I guess it has something to do with new perl's UTF-8 capabilities (as many other bugs already reported) I just read perluniintro(1), perlunicode(1) and PerlIO(3) and the latest perl version can't have such problems since it will always keep strings as 8 bit internally, until an unicode character 0xFF is somehow added to the string (ie there's no conversion of input by default). Furthermore none of the filehandles use UTF8 by default. One need to use -C to explicitely enable that (or PERL_UNICODE). So I'm closing both bugs on the topic. They were rightfully tagged unreproducible already. Though I agree it's good style to call binmode() when we handle known binary data. I have made the changes locally and I'll commit them if all seems to go well. With this, I also fixed dpkg-genchanges, dpkg-gencontrol and dpkg-source to write *.dsc, *.changes and DEBIAN/control files as UTF-8. And here Perl might implicitely do some conversion if the input is not valid UTF-8. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ ---End Message---
Bug#433477: dpkg-gencontrol -v fails to set ${binary:Version}
Here's one scenario where I use -v and binary:Version. I have a
library, libscarlet, that I build for both Sarge and Etch. To be able
to tell the two versions apart, I append +dv3.1 or +dv4.0 to the
version of the binary package. (dv stands for Debian Version.)
I build the following regular, debug, and developer package files:
libscarlet0_1.6.0+dv3.1_i386.deb
libscarlet0-dbg_1.6.0+dv3.1_i386.deb
libscarlet-dev_1.6.0+dv3.1_i386.deb
libscarlet0_1.6.0+dv4.0_i386.deb
libscarlet0-dbg_1.6.0+dv4.0_i386.deb
libscarlet-dev_1.6.0+dv4.0_i386.deb
I build both versions of the packages from the same source.
The binary version is set with a pbuilder hook that edits the
debian/rules file to pass a -v flag to dh_gencontrol (which
passes it to dpkg-gencontrol). Here is my hook script:
#! /bin/sh -e
# A50add-debianversion, by Stephen Gildea.
# pbuilder type A hook, runs before dpkg-buildpackage.
# Purpose: add the version of this Debian release to the binary
# package version.
# (This addition lets us build binaries for
# more than one Debian release from the same sources.)
debian_release=$(cat etc/debian_version)
cd tmp/buildd/*/
source_version=$(dpkg-parsechangelog | sed -n '/^Version: /s/Version: //p')
total_vers=$source_version+dv$debian_release
echo Will build binaries as version $total_vers
sed -i~ /^ dh_gencontrol[^-]*\$/s/dh_gencontrol/ -- -v'$total_vers'/ \
debian/rules
The dpkg support for different source and binary versions is great,
and it accurately records that my binary packages come from the same
source. In particular, my binary package control files correctly have
the following lines:
Version: 1.6.0+dv4.0
Source: libscarlet (1.6.0)
I would like to specify the dependencies of the dbg and dev packages
with the following simple declarations in the control file:
Package: libscarlet0-dbg
Depends: libscarlet0 (= ${binary:Version})
Package: libscarlet-dev
Depends: libscarlet0 (= ${binary:Version})
... and this is the only part of my whole setup that doesn't work.
${binary:Version} is 1.6.0, but it needs to be 1.6.0+dv4.0.
Thank you for your attention to this issue.
Stephen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#161338: marked as done (debconf w/ charset encoding support)
Your message dated Fri, 11 Jan 2008 20:39:48 +0100
with message-id [EMAIL PROTECTED]
and subject line Bug#172752: dpkg-dev: dpkg-buildpackage messes up Description:
inUTF-8 locale
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: dpkg-dev
Version: 1.10.8
Severity: normal
On Wed, Sep 18, 2002 at 03:07:21PM +0200, Radovan Garabik wrote:
P.S. apt-get source hylafax said:
...
Fetched 1335kB in 21s (63.0kB/s)
Malformed UTF-8 character (unexpected end of string) at /usr/bin/dpkg-source
line 604, GZIP line 5804.
the source otherwise unpacked well.
dpkg-source should use binmode() when processing arbitrary binary data.
This is unimportant (unless porting to Win32/Mac) but good style and
harmless with Perl 5.6; it's important with Perl 5.8 because I/O now
uses the :utf8 layer by default when the current locale's encoding is
UTF-8, so binary filehandles need to be identified as such.
Something like this should help:
--- dpkg-source.orig2002-09-18 14:23:07.0 +0100
+++ dpkg-source 2002-09-18 14:22:35.0 +0100
@@ -1050,6 +1050,7 @@
sub forkgzipwrite {
open(GZIPFILE, $_[0]) || syserr(create file $_[0]);
pipe(GZIPREAD,GZIP) || syserr(pipe for gzip);
+binmode(GZIP);
defined($cgz= fork) || syserr(fork for gzip);
if (!$cgz) {
open(STDIN,GZIPREAD) || syserr(reopen gzip pipe);
close(GZIPREAD);
@@ -1064,6 +1065,7 @@
local $SIG{PIPE} = 'DEFAULT';
open(GZIPFILE, $_[0]) || syserr(read file $_[0]);
pipe(GZIP,GZIPWRITE) || syserr(pipe for gunzip);
+binmode(GZIP);
defined($cgz= fork) || syserr(fork for gunzip);
if (!$cgz) {
open(STDOUT,GZIPWRITE) || syserr(reopen gunzip pipe);
close(GZIPWRITE);
--
Colin Watson [EMAIL PROTECTED]
---End Message---
---BeginMessage---
On Thu, 12 Dec 2002, Radovan Garabik wrote:
I ahev a package with Description in UTF-8. Until some time ago,
all worked well, dpkg-buildpackage placed the Description verbatim
into debian package. However, I found out now that if I compile the
package in UTF-8 locale, Description is mangled. It seems that
the encoding is assumed to be in ISO-8859-1 and is converted into
UTF-8. Of course, since it was already in UTF-8, the result is mojibake.
In 8-bit locales the Description is copied verbatim and all works well.
I guess it has something to do with new perl's UTF-8 capabilities
(as many other bugs already reported)
I just read perluniintro(1), perlunicode(1) and PerlIO(3) and the latest
perl version can't have such problems since it will always keep strings as
8 bit internally, until an unicode character 0xFF is somehow added
to the string (ie there's no conversion of input by default).
Furthermore none of the filehandles use UTF8 by default. One need to use
-C to explicitely enable that (or PERL_UNICODE).
So I'm closing both bugs on the topic. They were rightfully tagged
unreproducible already.
Though I agree it's good style to call binmode() when we handle known
binary data. I have made the changes locally and I'll commit them if all
seems to go well.
With this, I also fixed dpkg-genchanges, dpkg-gencontrol and dpkg-source
to write *.dsc, *.changes and DEBIAN/control files as UTF-8. And here Perl
might implicitely do some conversion if the input is not valid UTF-8.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
---End Message---
Bug#168160: marked as done ([UTF-8] [DPKG-SOURCE] dpkg-source and UTF-8)
Your message dated Fri, 11 Jan 2008 20:39:48 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#172752: dpkg-dev: dpkg-buildpackage messes up Description: inUTF-8 locale has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.10.9 When I dowload dosemu source using apt-src dpkg-source complains about malformed UTF-8 chararcter [EMAIL PROTECTED]:/home/petr/_Work/dosemu# apt-src install dosemu Couldn't stat source package list http://shakti.ath.cx ./ Packages (/var/lib/apt/lists/shakti.ath.cx_debian_kde3.1-rc2_._Packages) - stat (2 není souborem ani adresářem) You may want to run apt-get update to correct these problems Reading Package Lists... Done Building Dependency Tree... Done Need to get 1717kB of source archives. Get:1 http://http.us.debian.org stable/contrib dosemu 1.0.2.1-7 (dsc) [788B] Get:2 http://http.us.debian.org stable/contrib dosemu 1.0.2.1-7 (tar) [1693kB] Get:3 http://http.us.debian.org stable/contrib dosemu 1.0.2.1-7 (diff) [23.3kB] Fetched 1717kB in 1s (1113kB/s) Malformed UTF-8 character (unexpected end of string) at /usr/bin/dpkg-source line 604, GZIP line 1429. dpkg-source: extracting dosemu in dosemu-1.0.2.1 W: Couldn't stat source package list http://shakti.ath.cx ./ Packages (/var/lib/apt/lists/shakti.ath.cx_debian_kde3.1-rc2_._Packages) - stat (2 No such file or directory) W: You may want to run apt-get update to correct these problems [EMAIL PROTECTED]:/home/petr/_Work/dosemu# locale LANG=czech LC_CTYPE=cs_CZ.UTF-8 LC_NUMERIC=cs_CZ.UTF-8 LC_TIME=cs_CZ.UTF-8 LC_COLLATE=cs_CZ.UTF-8 LC_MONETARY=cs_CZ.UTF-8 LC_MESSAGES=cs_CZ.UTF-8 LC_PAPER=cs_CZ.UTF-8 LC_NAME=cs_CZ.UTF-8 LC_ADDRESS=cs_CZ.UTF-8 LC_TELEPHONE=cs_CZ.UTF-8 LC_MEASUREMENT=cs_CZ.UTF-8 LC_IDENTIFICATION=cs_CZ.UTF-8 LC_ALL=cs_CZ.UTF-8 -- Petr Baláš (petr at balas dot cz) ---End Message--- ---BeginMessage--- On Thu, 12 Dec 2002, Radovan Garabik wrote: I ahev a package with Description in UTF-8. Until some time ago, all worked well, dpkg-buildpackage placed the Description verbatim into debian package. However, I found out now that if I compile the package in UTF-8 locale, Description is mangled. It seems that the encoding is assumed to be in ISO-8859-1 and is converted into UTF-8. Of course, since it was already in UTF-8, the result is mojibake. In 8-bit locales the Description is copied verbatim and all works well. I guess it has something to do with new perl's UTF-8 capabilities (as many other bugs already reported) I just read perluniintro(1), perlunicode(1) and PerlIO(3) and the latest perl version can't have such problems since it will always keep strings as 8 bit internally, until an unicode character 0xFF is somehow added to the string (ie there's no conversion of input by default). Furthermore none of the filehandles use UTF8 by default. One need to use -C to explicitely enable that (or PERL_UNICODE). So I'm closing both bugs on the topic. They were rightfully tagged unreproducible already. Though I agree it's good style to call binmode() when we handle known binary data. I have made the changes locally and I'll commit them if all seems to go well. With this, I also fixed dpkg-genchanges, dpkg-gencontrol and dpkg-source to write *.dsc, *.changes and DEBIAN/control files as UTF-8. And here Perl might implicitely do some conversion if the input is not valid UTF-8. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ ---End Message---
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Friday 11 January 2008, Joey Hess wrote: Your continual closusre of this bug report [...] That's not correct. I'm afraid you closed it yourself the last time by using reply-to-all and thus including -done. Guillem only replied to your reply and probably also didn't notice -done was still in the address list. Anyway, I've reopened the BR again. Cheers, Frans signature.asc Description: This is a digitally signed message part.
Processed: tagging 433477
Processing commands for [EMAIL PROTECTED]:
# Automatically generated email from bts, devscripts version 2.10.12
tags 433477 + pending
Bug#433477: dpkg-gencontrol -v fails to set ${binary:Version}
Tags were: patch
Tags added: pending
End of message, stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#149961: Viaaaagrrrraaaa is your magic weapon
Good night Customer feel like a major player with our new EDSET http://wecarepower.com Mikkey Fox, New York -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460309: dpkg: debian/control doesn't allow one homepage per binary package
Package: dpkg Version: 1.14.15 Severity: normal Hi! Lot's of the KDE source packages have a different upstream homepage for every binary package, because all the different projects are released together in one tarball. Right now it is not possible to express this in the Control file, because the homepage must be set per source package. Otherwise dpkg-source tells you the following: dpkg-source: warning: unknown information field 'Homepage' in input data in package's section of control info file Please implement the possibility to specify a different homepage per binary packages than specified for the source package. Greetings, Armin with support of the Debian KDE Team ;) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 5.97-5.7 The GNU core utilities ii libc6 2.7-5 GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 453400
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.12 tags 453400 + pending Bug#453400: dpkg-source: please accept DM-Upload-Allowed field in control (and import to dsc) There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 460309
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.12 tags 460309 + pending Bug#460309: Fix warnings when using Homepage on binary package stanzas There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460309: dpkg: debian/control doesn't allow one homepage per binary package
On Sat, 12 Jan 08 01:46, Guillem Jover wrote: This has been supported from the beginning, the only problem is those missleading warnings. Next release fixes the warnings problem, though. Oh this is great! Thanks for fixing and the fast answer. /Armin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
