Re: Build-Depends-Indep and packages with architecture all
Thomas Viehmann <[EMAIL PROTECTED]> wrote: > Frank Küster wrote: >> In the original package's control file, there is a line of >> Build-Depends-Indep, but no Build-Depends. Does this make sense for a >> source package that has no architecture dependent binary packages at >> all? Why not just use Build-Depends here and use Build-Depends-Indep >> only when a source package yields both kinds of binary packages? > > If you hadn't asked here, I'd be inclined to think that you're looking > for something beyond "because that's what policy tells you to do" (in > the section on debian/rules)... Either I don't understand your sentence, or I have a problem reading the policy. In file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-debianrules I can find statements about the targets binary-arch and binary-indep and the respective build-targets. But there's nothing about Dependency-fields in the control file. Also in Chapter 7, "Declaring relationships between packages", I cannot find an explanation (probably because I didn't read thoroughly enough). Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Problems when packaging KTrack for Debian unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Lunes, 28 de Julio de 2003 23:51, Joshua Kwan escribió: > Sounds like some #include is missing for KPushButton. I have found part of the error... KPustButton (at kpushbutton.h), as you said below is in kdelibs4-dev package. The problem is that the file that should have the "#include " is automatically generated during building using "uic" from a .ui (the GUI file) and it is not correctly generated since i updated the debian unstable packages about 10 days ago. Can anybody help me please? > > transponderdefinitionwidget.h:19: error: forward declaration of `struct > >KPushButton' > > transponderdefinitionwidget.cpp:48: error: no matching function for call > > to ` QGridLayout::addWidget(KPushButton*&, int, int)' > > /usr/share/qt3/include/qlayout.h:324: error: candidates are: void > >QGridLayout::addWidget(QWidget*, int, int, int) > > hopefully, KPushButton is : public QWidget, assuming the code makes > sense otherwise. are there any error lines about files that g++ can't > find? > > > What package is missing? > > Can you give me any clue? > > A search of google says that KPushButton should be in kpushbutton.h, > which packages.debian.org says is in kdelibs4-dev. > > Hope this helps! > > -Josh - -- Un saludo, Jaime Robles - http://jaime.robles.nu [EMAIL PROTECTED] Coordinador KDE-es - KDE Spanish Translation Team http://www.kde.org/es - http://es.i18n.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Kh3fER46oL+8yYURAp9CAJ9D7nVF/BWoWmUgBknbCZR96nYoWwCfXbCl tBuPVPCHDpfYWB+6pPE8eo4= =QrZu -END PGP SIGNATURE-
Re: Build-Depends-Indep and packages with architecture all
Joel Baker <[EMAIL PROTECTED]> schrieb:
> On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
>> Hi,
>>
>> for practice and because I want to use it, I am working on a package of
>> the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
>> Emacs-addon written in Lisp, it's of course architecture independent.
>>
>> In debian/rules of the "real" package from unstable, binary requires
>> binary-arch and binary-indep; the first does nothing and the second
>> builds the package.
>>
>> In the original package's control file, there is a line of
>> Build-Depends-Indep, but no Build-Depends. Does this make sense for a
>> source package that has no architecture dependent binary packages at
>> all? Why not just use Build-Depends here and use Build-Depends-Indep
>> only when a source package yields both kinds of binary packages?
>
> Because it is simpler to have two easily expressed rules ("Build-Depends
> must be satisfied for targets", "Build-Depends-Indep must be
> satisfied for targets") than a complex set of exceptions
> ("Build-Depends must be satisfied for on Arch: (!= all), or on
> Arch: all, unless Build-Depends-Indep is also set, in which case")
That sounds sensible. However, I'm puzzled by the following statement in
file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6
,
| Build-Depends, Build-Conflicts
|
| The Build-Depends and Build-Conflicts
| fields must be satisfied when any of the following targets is invoked:
| build, clean, binary, binary-arch, build-arch, build-indep and
| binary-indep.
`
So if I put all the dependencies into Build-Depends for a package that
only generates a single package_version_all.deb, I get the same effect
as if I put only some (like debhelper) there and the rest into
Build-Depends-Indep. Or am I missing something?
> 6 extra characters in the control file is a small price to pay for sanity,
> especially because it allows some of us (namely, porters) to build *simple*
> tools that figure out dependancy trees, and which can prune some parts of
> them based on this information.
What concern do porters have with architecture-all-only-packages?
TIA, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Re: Problems when packaging KTrack for Debian unstable
On Fri, Aug 01, 2003 at 09:59:26AM +0200, Jaime Robles wrote: > I have found part of the error... > KPustButton (at kpushbutton.h), as you said below is in kdelibs4-dev package. > The problem is that the file that should have the "#include " > is automatically generated during building using "uic" from a .ui (the GUI > file) and it is not correctly generated since i updated the debian unstable > packages about 10 days ago. > > Can anybody help me please? I know nothing about Qt development. -Josh -- Using words to describe magic is like using a screwdriver to cut roast beef. -- Tom Robbins pgpEW7pmQDqfP.pgp Description: PGP signature
Re: Build-Depends-Indep and packages with architecture all
Hi. Frank Küster ([EMAIL PROTECTED]) wrote: >Either I don't understand your sentence, or I have a problem reading the >policy. In Or I was wrong. :) >file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-deb >ianrules > >I can find statements about the targets binary-arch and binary-indep and >the respective build-targets. But there's nothing about >Dependency-fields in the control file. Also in Chapter 7, "Declaring >relationships between packages", I cannot find an explanation (probably >because I didn't read thoroughly enough). Basically I thought that the explanation of binary-arch and binary-indep combined with the principle of minimal build-dependencies yields the answer. Especially the footnote in paragraph 7.6 (on package relations) seems to shed light on this (and shead doubt on the effectiveness of build-depends-indep, oh well). Cheers T.
Re: locale files
On Aug 1, Matthias Urlichs ([EMAIL PROTECTED]) wrote: > Hi, Matt Zimmerman wrote: > > > But presumably you _would_ have a problem with: > > - the old library trying to look up a string which isn't there anymore in > > the new library > > - the new library trying to look up a string which isn't there in the old > > library > > Of course the message catalog would contain the union of strings > from both libraries, not its intersection. > > I'd think that'd be obvious... That's the point where it would be much easier to version the message package rather than attempt to keep track of which strings were for the old library, which for the new, etc. -- Neil Roeth
changelog in utf-8 conflicts with maintainer in control
Hi I have a problem with debian policy 3.6.0 One of the news of this version is that changelog _should_ be in utf-8 In my case the changelog should not be in utf-8 :) I have iconv'ed my changelog to be fully utf-8, but my name has a "strange character" that gets converted So when the uploader checks the name of the Maintainer in the control file (not utf-8) with the name in the changelog says that are different, and results in a NMU ¿Are my steps correct or iŽm wrong? ¿Should I open a bug against debian-policy? Best regards -- Celso González pgp5I3NR9vlHE.pgp Description: PGP signature
Re: changelog in utf-8 conflicts with maintainer in control
Celso González (2003-08-01 13:14:33 +0200) : > One of the news of this version is that changelog _should_ be in > utf-8 In my case the changelog should not be in utf-8 :) > > I have iconv'ed my changelog to be fully utf-8, but my name has a > "strange character" that gets converted > > So when the uploader checks the name of the Maintainer in the > control file (not utf-8) with the name in the changelog says that > are different, and results in a NMU > > ¿Are my steps correct or iŽm wrong? I can't see where you could possibly go wrong. I believe your steps are correct. > ¿Should I open a bug against debian-policy? Maybe not a bug, but you should definitely report this behaviour on the debian-policy mailing-list. My opinion would be that the control file should also be switched to UTF-8. If you could try that, and if the uploader stops reporting that as an NMU, then you should suggest policy to be changed to document that fact. Anyway, trust debian-policy, not me, as I don't have any diacritics in *my* name :-) Roland. -- Roland Mas If you spit in the air, it lands in your face. -- Tevye, in Fiddler on the roof
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:33:18PM +0200, Eduard Bloch wrote: > #include > * Celso González [Fri, Aug 01 2003, 01:14:33PM]: > > > So when the uploader checks the name of the Maintainer in the control > > file (not utf-8) with the name in the changelog says that are different, > ^ > > Show me where policy tells you not to use UTF-8 in control files but > some other non-ascii charset with some other encoding instead. Well, I think is not clear enough A reflexion from the guy that suggest the change in policy Extracted from C2.2 "Now, we can't switch to using UTF-8 for package control fields and the like until dpkg has better support, but one thing we can start doing today is requesting that Debian changelogs are UTF-8 encoded" Maintainer is a control field The solution is that both files have the same encoding (both latin1 or both utf-8) but iŽm not sure that utf-8 is correct for debina/control Thanks for your answer -- Celso González pgpgguCsSxJly.pgp Description: PGP signature
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:14:33PM +0200, Celso Gonz?lez wrote: > I have a problem with debian policy 3.6.0 > > One of the news of this version is that changelog _should_ be in utf-8 > In my case the changelog should not be in utf-8 :) > > I have iconv'ed my changelog to be fully utf-8, but my name has a > "strange character" that gets converted > > So when the uploader checks the name of the Maintainer in the control > file (not utf-8) with the name in the changelog says that are different, > and results in a NMU Why not convert your name in the control file as well? -- Colin Watson [EMAIL PROTECTED]
Re: changelog in utf-8 conflicts with maintainer in control
#include * Celso González [Fri, Aug 01 2003, 01:14:33PM]: > So when the uploader checks the name of the Maintainer in the control > file (not utf-8) with the name in the changelog says that are different, ^ Why not? If you are not making a Description translation for DDTP, there is no reason for forcing some special charset/encoding into control files. And if you like to add non-ascii chars, use UTF-8 in control and not your special thing (latin1, I guess). > ¿Are my steps correct or iŽm wrong? > ¿Should I open a bug against debian-policy? Show me where policy tells you not to use UTF-8 in control files but some other non-ascii charset with some other encoding instead. MfG, Eduard. -- "VIM - verbesserter Vi" - Wer hat an meinem LANG gedreht... jjFux: scheis i18n, das müsste vvi sein, nich vim
Re: locale files
On Fri, Aug 01, 2003 at 07:30:20AM +0200, Matthias Urlichs wrote: > > But presumably you _would_ have a problem with: > > - the old library trying to look up a string which isn't there anymore in > > the new library > > - the new library trying to look up a string which isn't there in the old > > library > > Of course the message catalog would contain the union of strings > from both libraries, not its intersection. > > I'd think that'd be obvious... Since these things are usually managed by automated tools which scan the source code looking for translatable strings, it would be nontrivial to ensure that nothing was ever deleted from the file. Also, the new version of the library would require a versioned dependency on the package containing the message catalog. I think it is much more straightforward to version it. -- - mdz
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:47:59PM +0200, Celso Gonz?lez wrote: > On Fri, Aug 01, 2003 at 01:33:18PM +0200, Eduard Bloch wrote: > > #include > > * Celso Gonz?lez [Fri, Aug 01 2003, 01:14:33PM]: > > > > > So when the uploader checks the name of the Maintainer in the control > > > file (not utf-8) with the name in the changelog says that are different, > > ^ > > > > Show me where policy tells you not to use UTF-8 in control files but > > some other non-ascii charset with some other encoding instead. > > Well, I think is not clear enough > A reflexion from the guy that suggest the change in policy > > Extracted from C2.2 > "Now, we can't switch to using UTF-8 for package control fields > and the like until dpkg has better support, but one thing we can > start doing today is requesting that Debian changelogs are UTF-8 > encoded" > > Maintainer is a control field > > The solution is that both files have the same encoding (both latin1 or > both utf-8) but i??m not sure that utf-8 is correct for debina/control Right now, dpkg has no explicit support for anything other than ASCII in debian/control: that is to say, it doesn't attempt to recode maintainer names to the current locale when asked to display control information with 'dpkg -s', etc. However, it doesn't support Latin-1 any better than it supports UTF-8! If you think that this is a problem, then the answer is not to use Latin-1, but to use only ASCII. That said, the problems caused by using an encoding that dpkg doesn't support are not serious; they just mean that some people will see your name wrongly when they type 'dpkg -s', but hey, that would happen anyway (particularly if you don't like the ASCII transliteration of your name). With that knowledge, if you're going to pick a non-ASCII encoding, then UTF-8 is almost certainly the way to go. It seems unlikely to me that we would select anything other than UTF-8 as the 8-bit encoding for control files. As a side note, I'd love to get rid of Latin-1 in maintainer names; it's currently difficult for the BTS to declare any character set in the web pages it generates, since some of the maintainer names it prints are in Latin-1 and some in UTF-8 and it can't easily tell which are which. Switching to UTF-8 throughout would solve that problem. So, to summarize, please either use plain ASCII (if you think that the lack of recoding is a problem) or UTF-8 (if you don't mind); using other legacy encodings is just storing up trouble. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Trying to make my first package...
"Bernhard R. Link" <[EMAIL PROTECTED]> : > dpkg-buildpackage cannot create a orig.tar.gz, as something original > has already to be there. (Try putting the upstream source code renamed > there). In order to dpkg-buildpackage even trying, you need to have a > version number ending with a debian-specific number. (The thing after > -) As you say, I just renamed the folder where I put the original sources with a "-1" version number, and then dpkg-buildpackage produces the orig.tar.gz and the diff.gz files. The new version is here : http://www.nozav.org/debian/ Thanks !
Re: Trying to make my first package...
On Fri, Aug 01, 2003 at 04:22:57PM +0200, Julien Barnier wrote: > "Bernhard R. Link" <[EMAIL PROTECTED]> : > > dpkg-buildpackage cannot create a orig.tar.gz, as something original > > has already to be there. (Try putting the upstream source code renamed > > there). In order to dpkg-buildpackage even trying, you need to have a > > version number ending with a debian-specific number. (The thing after > > -) > > As you say, I just renamed the folder where I put the original sources > with a "-1" version number, The name of that directory doesn't matter (much). It's the presence of the .orig.tar.gz and the version number at the head of debian/changelog that are important. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Build-Depends-Indep and packages with architecture all
On Fri, Aug 01, 2003 at 09:57:10AM +0200, Frank Küster wrote:
> Joel Baker <[EMAIL PROTECTED]> schrieb:
>
> > On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
> >> Hi,
> >>
> >> for practice and because I want to use it, I am working on a package of
> >> the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
> >> Emacs-addon written in Lisp, it's of course architecture independent.
> >>
> >> In debian/rules of the "real" package from unstable, binary requires
> >> binary-arch and binary-indep; the first does nothing and the second
> >> builds the package.
> >>
> >> In the original package's control file, there is a line of
> >> Build-Depends-Indep, but no Build-Depends. Does this make sense for a
> >> source package that has no architecture dependent binary packages at
> >> all? Why not just use Build-Depends here and use Build-Depends-Indep
> >> only when a source package yields both kinds of binary packages?
> >
> > Because it is simpler to have two easily expressed rules ("Build-Depends
> > must be satisfied for targets", "Build-Depends-Indep must be
> > satisfied for targets") than a complex set of exceptions
> > ("Build-Depends must be satisfied for on Arch: (!= all), or on
> > Arch: all, unless Build-Depends-Indep is also set, in which case")
>
> That sounds sensible. However, I'm puzzled by the following statement in
>
> file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6
>
> ,
> | Build-Depends, Build-Conflicts
> |
> | The Build-Depends and Build-Conflicts
> | fields must be satisfied when any of the following targets is invoked:
> | build, clean, binary, binary-arch, build-arch, build-indep and
> | binary-indep.
> `
Hmmm. I'm not sure if that needs to be updated, or if I've just missed
something. Practice may be preceeding policy, however...
> So if I put all the dependencies into Build-Depends for a package that
> only generates a single package_version_all.deb, I get the same effect
> as if I put only some (like debhelper) there and the rest into
> Build-Depends-Indep. Or am I missing something?
It might work, given the above; it's still better style, if nothing
else, to use the BDI field for stuff that is needed when invoking the
build-indep/binary-indep targets (for example, latex2html or somesuch, for
generating docs for a foo-doc*_all.deb package)
> > 6 extra characters in the control file is a small price to pay for sanity,
> > especially because it allows some of us (namely, porters) to build *simple*
> > tools that figure out dependancy trees, and which can prune some parts of
> > them based on this information.
>
> What concern do porters have with architecture-all-only-packages?
With most Arch: all packages, little to none. The concern is actually in
*not* having stuff that is *only* needed for -indep targets (which will
generally never be built by porting machines) in the Binary-Depends field,
so that it doesn't get installed (since it won't be needed). Or, in the
case of bootstrapping ports, so that they don't avoid building the package
thinking it needs emacs ported first, when really emacs is only used to do
some documentation fudging.
Yes, there are things in the archive which BDI on emacs...
--
Joel Baker <[EMAIL PROTECTED]>
pgpaR36EEwcep.pgp
Description: PGP signature
Re: locale files
Hi, Matt Zimmerman wrote:
> But presumably you _would_ have a problem with:
> - the old library trying to look up a string which isn't there anymore in
> the new library
> - the new library trying to look up a string which isn't there in the old
> library
Of course the message catalog would contain the union of strings
from both libraries, not its intersection.
I'd think that'd be obvious...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
This PIZZA symbolizes my COMPLETE EMOTIONAL RECOVERY!!
-- Zippy the Pinhead
Re: Build-Depends-Indep and packages with architecture all
Thomas Viehmann <[EMAIL PROTECTED]> wrote: > Frank Küster wrote: >> In the original package's control file, there is a line of >> Build-Depends-Indep, but no Build-Depends. Does this make sense for a >> source package that has no architecture dependent binary packages at >> all? Why not just use Build-Depends here and use Build-Depends-Indep >> only when a source package yields both kinds of binary packages? > > If you hadn't asked here, I'd be inclined to think that you're looking > for something beyond "because that's what policy tells you to do" (in > the section on debian/rules)... Either I don't understand your sentence, or I have a problem reading the policy. In file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-debianrules I can find statements about the targets binary-arch and binary-indep and the respective build-targets. But there's nothing about Dependency-fields in the control file. Also in Chapter 7, "Declaring relationships between packages", I cannot find an explanation (probably because I didn't read thoroughly enough). Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems when packaging KTrack for Debian unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Lunes, 28 de Julio de 2003 23:51, Joshua Kwan escribió: > Sounds like some #include is missing for KPushButton. I have found part of the error... KPustButton (at kpushbutton.h), as you said below is in kdelibs4-dev package. The problem is that the file that should have the "#include " is automatically generated during building using "uic" from a .ui (the GUI file) and it is not correctly generated since i updated the debian unstable packages about 10 days ago. Can anybody help me please? > > transponderdefinitionwidget.h:19: error: forward declaration of `struct > >KPushButton' > > transponderdefinitionwidget.cpp:48: error: no matching function for call > > to ` QGridLayout::addWidget(KPushButton*&, int, int)' > > /usr/share/qt3/include/qlayout.h:324: error: candidates are: void > >QGridLayout::addWidget(QWidget*, int, int, int) > > hopefully, KPushButton is : public QWidget, assuming the code makes > sense otherwise. are there any error lines about files that g++ can't > find? > > > What package is missing? > > Can you give me any clue? > > A search of google says that KPushButton should be in kpushbutton.h, > which packages.debian.org says is in kdelibs4-dev. > > Hope this helps! > > -Josh - -- Un saludo, Jaime Robles - http://jaime.robles.nu [EMAIL PROTECTED] Coordinador KDE-es - KDE Spanish Translation Team http://www.kde.org/es - http://es.i18n.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Kh3fER46oL+8yYURAp9CAJ9D7nVF/BWoWmUgBknbCZR96nYoWwCfXbCl tBuPVPCHDpfYWB+6pPE8eo4= =QrZu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends-Indep and packages with architecture all
Joel Baker <[EMAIL PROTECTED]> schrieb:
> On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
>> Hi,
>>
>> for practice and because I want to use it, I am working on a package of
>> the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
>> Emacs-addon written in Lisp, it's of course architecture independent.
>>
>> In debian/rules of the "real" package from unstable, binary requires
>> binary-arch and binary-indep; the first does nothing and the second
>> builds the package.
>>
>> In the original package's control file, there is a line of
>> Build-Depends-Indep, but no Build-Depends. Does this make sense for a
>> source package that has no architecture dependent binary packages at
>> all? Why not just use Build-Depends here and use Build-Depends-Indep
>> only when a source package yields both kinds of binary packages?
>
> Because it is simpler to have two easily expressed rules ("Build-Depends
> must be satisfied for targets", "Build-Depends-Indep must be
> satisfied for targets") than a complex set of exceptions
> ("Build-Depends must be satisfied for on Arch: (!= all), or on
> Arch: all, unless Build-Depends-Indep is also set, in which case")
That sounds sensible. However, I'm puzzled by the following statement in
file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6
,
| Build-Depends, Build-Conflicts
|
| The Build-Depends and Build-Conflicts
| fields must be satisfied when any of the following targets is invoked:
| build, clean, binary, binary-arch, build-arch, build-indep and
| binary-indep.
`
So if I put all the dependencies into Build-Depends for a package that
only generates a single package_version_all.deb, I get the same effect
as if I put only some (like debhelper) there and the rest into
Build-Depends-Indep. Or am I missing something?
> 6 extra characters in the control file is a small price to pay for sanity,
> especially because it allows some of us (namely, porters) to build *simple*
> tools that figure out dependancy trees, and which can prune some parts of
> them based on this information.
What concern do porters have with architecture-all-only-packages?
TIA, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems when packaging KTrack for Debian unstable
On Fri, Aug 01, 2003 at 09:59:26AM +0200, Jaime Robles wrote: > I have found part of the error... > KPustButton (at kpushbutton.h), as you said below is in kdelibs4-dev package. > The problem is that the file that should have the "#include " > is automatically generated during building using "uic" from a .ui (the GUI > file) and it is not correctly generated since i updated the debian unstable > packages about 10 days ago. > > Can anybody help me please? I know nothing about Qt development. -Josh -- Using words to describe magic is like using a screwdriver to cut roast beef. -- Tom Robbins pgp0.pgp Description: PGP signature
Re: Build-Depends-Indep and packages with architecture all
Hi. Frank Küster ([EMAIL PROTECTED]) wrote: >Either I don't understand your sentence, or I have a problem reading the >policy. In Or I was wrong. :) >file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-deb >ianrules > >I can find statements about the targets binary-arch and binary-indep and >the respective build-targets. But there's nothing about >Dependency-fields in the control file. Also in Chapter 7, "Declaring >relationships between packages", I cannot find an explanation (probably >because I didn't read thoroughly enough). Basically I thought that the explanation of binary-arch and binary-indep combined with the principle of minimal build-dependencies yields the answer. Especially the footnote in paragraph 7.6 (on package relations) seems to shed light on this (and shead doubt on the effectiveness of build-depends-indep, oh well). Cheers T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: locale files
On Aug 1, Matthias Urlichs ([EMAIL PROTECTED]) wrote: > Hi, Matt Zimmerman wrote: > > > But presumably you _would_ have a problem with: > > - the old library trying to look up a string which isn't there anymore in > > the new library > > - the new library trying to look up a string which isn't there in the old > > library > > Of course the message catalog would contain the union of strings > from both libraries, not its intersection. > > I'd think that'd be obvious... That's the point where it would be much easier to version the message package rather than attempt to keep track of which strings were for the old library, which for the new, etc. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
changelog in utf-8 conflicts with maintainer in control
Hi I have a problem with debian policy 3.6.0 One of the news of this version is that changelog _should_ be in utf-8 In my case the changelog should not be in utf-8 :) I have iconv'ed my changelog to be fully utf-8, but my name has a "strange character" that gets converted So when the uploader checks the name of the Maintainer in the control file (not utf-8) with the name in the changelog says that are different, and results in a NMU ¿Are my steps correct or iŽm wrong? ¿Should I open a bug against debian-policy? Best regards -- Celso González pgp0.pgp Description: PGP signature
Re: changelog in utf-8 conflicts with maintainer in control
Celso Gonz+AOE-lez (2003-08-01 13:14:33 +-0200) : > One of the news of this version is that changelog _should_ be in > utf-8 In my case the changelog should not be in utf-8 :) > > I have iconv'ed my changelog to be fully utf-8, but my name has a > "strange character" that gets converted > > So when the uploader checks the name of the Maintainer in the > control file (not utf-8) with the name in the changelog says that > are different, and results in a NMU > > +AL8-Are my steps correct or i+AX0-m wrong? I can't see where you could possibly go wrong. I believe your steps are correct. > +AL8-Should I open a bug against debian-policy? Maybe not a bug, but you should definitely report this behaviour on the debian-policy mailing-list. My opinion would be that the control file should also be switched to UTF-8. If you could try that, and if the uploader stops reporting that as an NMU, then you should suggest policy to be changed to document that fact. Anyway, trust debian-policy, not me, as I don't have any diacritics in *my* name :-) Roland. -- Roland Mas If you spit in the air, it lands in your face. -- Tevye, in Fiddler on the roof -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:33:18PM +0200, Eduard Bloch wrote: > #include > * Celso González [Fri, Aug 01 2003, 01:14:33PM]: > > > So when the uploader checks the name of the Maintainer in the control > > file (not utf-8) with the name in the changelog says that are different, > ^ > > Show me where policy tells you not to use UTF-8 in control files but > some other non-ascii charset with some other encoding instead. Well, I think is not clear enough A reflexion from the guy that suggest the change in policy Extracted from C2.2 "Now, we can't switch to using UTF-8 for package control fields and the like until dpkg has better support, but one thing we can start doing today is requesting that Debian changelogs are UTF-8 encoded" Maintainer is a control field The solution is that both files have the same encoding (both latin1 or both utf-8) but iŽm not sure that utf-8 is correct for debina/control Thanks for your answer -- Celso González pgp0.pgp Description: PGP signature
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:14:33PM +0200, Celso Gonz?lez wrote: > I have a problem with debian policy 3.6.0 > > One of the news of this version is that changelog _should_ be in utf-8 > In my case the changelog should not be in utf-8 :) > > I have iconv'ed my changelog to be fully utf-8, but my name has a > "strange character" that gets converted > > So when the uploader checks the name of the Maintainer in the control > file (not utf-8) with the name in the changelog says that are different, > and results in a NMU Why not convert your name in the control file as well? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changelog in utf-8 conflicts with maintainer in control
#include * Celso González [Fri, Aug 01 2003, 01:14:33PM]: > So when the uploader checks the name of the Maintainer in the control > file (not utf-8) with the name in the changelog says that are different, ^ Why not? If you are not making a Description translation for DDTP, there is no reason for forcing some special charset/encoding into control files. And if you like to add non-ascii chars, use UTF-8 in control and not your special thing (latin1, I guess). > ¿Are my steps correct or iŽm wrong? > ¿Should I open a bug against debian-policy? Show me where policy tells you not to use UTF-8 in control files but some other non-ascii charset with some other encoding instead. MfG, Eduard. -- "VIM - verbesserter Vi" - Wer hat an meinem LANG gedreht... jjFux: scheis i18n, das müsste vvi sein, nich vim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: locale files
On Fri, Aug 01, 2003 at 07:30:20AM +0200, Matthias Urlichs wrote: > > But presumably you _would_ have a problem with: > > - the old library trying to look up a string which isn't there anymore in > > the new library > > - the new library trying to look up a string which isn't there in the old > > library > > Of course the message catalog would contain the union of strings > from both libraries, not its intersection. > > I'd think that'd be obvious... Since these things are usually managed by automated tools which scan the source code looking for translatable strings, it would be nontrivial to ensure that nothing was ever deleted from the file. Also, the new version of the library would require a versioned dependency on the package containing the message catalog. I think it is much more straightforward to version it. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:47:59PM +0200, Celso González wrote: > On Fri, Aug 01, 2003 at 01:33:18PM +0200, Eduard Bloch wrote: > > #include > > * Celso González [Fri, Aug 01 2003, 01:14:33PM]: > > > > > So when the uploader checks the name of the Maintainer in the control > > > file (not utf-8) with the name in the changelog says that are different, > > ^ > > > > Show me where policy tells you not to use UTF-8 in control files but > > some other non-ascii charset with some other encoding instead. > > Well, I think is not clear enough > A reflexion from the guy that suggest the change in policy > > Extracted from C2.2 > "Now, we can't switch to using UTF-8 for package control fields > and the like until dpkg has better support, but one thing we can > start doing today is requesting that Debian changelogs are UTF-8 > encoded" > > Maintainer is a control field > > The solution is that both files have the same encoding (both latin1 or > both utf-8) but i??m not sure that utf-8 is correct for debina/control Right now, dpkg has no explicit support for anything other than ASCII in debian/control: that is to say, it doesn't attempt to recode maintainer names to the current locale when asked to display control information with 'dpkg -s', etc. However, it doesn't support Latin-1 any better than it supports UTF-8! If you think that this is a problem, then the answer is not to use Latin-1, but to use only ASCII. That said, the problems caused by using an encoding that dpkg doesn't support are not serious; they just mean that some people will see your name wrongly when they type 'dpkg -s', but hey, that would happen anyway (particularly if you don't like the ASCII transliteration of your name). With that knowledge, if you're going to pick a non-ASCII encoding, then UTF-8 is almost certainly the way to go. It seems unlikely to me that we would select anything other than UTF-8 as the 8-bit encoding for control files. As a side note, I'd love to get rid of Latin-1 in maintainer names; it's currently difficult for the BTS to declare any character set in the web pages it generates, since some of the maintainer names it prints are in Latin-1 and some in UTF-8 and it can't easily tell which are which. Switching to UTF-8 throughout would solve that problem. So, to summarize, please either use plain ASCII (if you think that the lack of recoding is a problem) or UTF-8 (if you don't mind); using other legacy encodings is just storing up trouble. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to make my first package...
"Bernhard R. Link" <[EMAIL PROTECTED]> : > dpkg-buildpackage cannot create a orig.tar.gz, as something original > has already to be there. (Try putting the upstream source code renamed > there). In order to dpkg-buildpackage even trying, you need to have a > version number ending with a debian-specific number. (The thing after > -) As you say, I just renamed the folder where I put the original sources with a "-1" version number, and then dpkg-buildpackage produces the orig.tar.gz and the diff.gz files. The new version is here : http://www.nozav.org/debian/ Thanks ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to make my first package...
On Fri, Aug 01, 2003 at 04:22:57PM +0200, Julien Barnier wrote: > "Bernhard R. Link" <[EMAIL PROTECTED]> : > > dpkg-buildpackage cannot create a orig.tar.gz, as something original > > has already to be there. (Try putting the upstream source code renamed > > there). In order to dpkg-buildpackage even trying, you need to have a > > version number ending with a debian-specific number. (The thing after > > -) > > As you say, I just renamed the folder where I put the original sources > with a "-1" version number, The name of that directory doesn't matter (much). It's the presence of the .orig.tar.gz and the version number at the head of debian/changelog that are important. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends-Indep and packages with architecture all
On Fri, Aug 01, 2003 at 09:57:10AM +0200, Frank Küster wrote:
> Joel Baker <[EMAIL PROTECTED]> schrieb:
>
> > On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
> >> Hi,
> >>
> >> for practice and because I want to use it, I am working on a package of
> >> the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
> >> Emacs-addon written in Lisp, it's of course architecture independent.
> >>
> >> In debian/rules of the "real" package from unstable, binary requires
> >> binary-arch and binary-indep; the first does nothing and the second
> >> builds the package.
> >>
> >> In the original package's control file, there is a line of
> >> Build-Depends-Indep, but no Build-Depends. Does this make sense for a
> >> source package that has no architecture dependent binary packages at
> >> all? Why not just use Build-Depends here and use Build-Depends-Indep
> >> only when a source package yields both kinds of binary packages?
> >
> > Because it is simpler to have two easily expressed rules ("Build-Depends
> > must be satisfied for targets", "Build-Depends-Indep must be
> > satisfied for targets") than a complex set of exceptions
> > ("Build-Depends must be satisfied for on Arch: (!= all), or on
> > Arch: all, unless Build-Depends-Indep is also set, in which case")
>
> That sounds sensible. However, I'm puzzled by the following statement in
>
> file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6
>
> ,
> | Build-Depends, Build-Conflicts
> |
> | The Build-Depends and Build-Conflicts
> | fields must be satisfied when any of the following targets is invoked:
> | build, clean, binary, binary-arch, build-arch, build-indep and
> | binary-indep.
> `
Hmmm. I'm not sure if that needs to be updated, or if I've just missed
something. Practice may be preceeding policy, however...
> So if I put all the dependencies into Build-Depends for a package that
> only generates a single package_version_all.deb, I get the same effect
> as if I put only some (like debhelper) there and the rest into
> Build-Depends-Indep. Or am I missing something?
It might work, given the above; it's still better style, if nothing
else, to use the BDI field for stuff that is needed when invoking the
build-indep/binary-indep targets (for example, latex2html or somesuch, for
generating docs for a foo-doc*_all.deb package)
> > 6 extra characters in the control file is a small price to pay for sanity,
> > especially because it allows some of us (namely, porters) to build *simple*
> > tools that figure out dependancy trees, and which can prune some parts of
> > them based on this information.
>
> What concern do porters have with architecture-all-only-packages?
With most Arch: all packages, little to none. The concern is actually in
*not* having stuff that is *only* needed for -indep targets (which will
generally never be built by porting machines) in the Binary-Depends field,
so that it doesn't get installed (since it won't be needed). Or, in the
case of bootstrapping ports, so that they don't avoid building the package
thinking it needs emacs ported first, when really emacs is only used to do
some documentation fudging.
Yes, there are things in the archive which BDI on emacs...
--
Joel Baker <[EMAIL PROTECTED]>
pgp0.pgp
Description: PGP signature
search a sponsor
I am new here. I have debianized a package named "fvwm-themes". I have it made with instrucktion from original developer. Now this package is so i think ready to test and ready to show to an sponsor. The original developer have me say, how he want. * a entry in the original Makefile.am "deb-dist" and "deb-dist3" like rpm. So i have it done. Also i have the "debian/*" uploadet to cvs-server. Now anybody can load the package from cvs and "make deb-dist". Ok i wait for respond. Andrei -- _ _ _ / ___| _ __ ___ (_) (_) ___ \___ \| '_ ` _ \| | | |/ _ \ ___) | | | | | | | | | __/ |/|_| |_| |_|_|_|_|\___| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
