Re: Sponsor wanted for new newspost package
David wrote: > I have made changes to source package newspost_2.1.1-4, so that a bigger -l > (lines) parameter can be given, and and indroduced a new parameter -2 with > which it calls another program - such as par2create - to make the desired > par2 files. I renamed the dir into newspost-2.1.2.beta. > > *Open question*: Is another person presently working on a new version of > newspost, if yes, how can I contact him/her? For a first try, see if you can contact the original upstream author. The newspost web page, including contact information (which may or may not still be valid) appears to be at http://newspost.unixcab.org/ Maybe he will release a new upstream version that includes your changes. I don't have interest in sponsoring the package, but David, please see below for some advice. For the benefit of anyone who *does* want to sponsor newspost, note that it was orphaned by the Debian packager on 23 June 2004 [1]; the last QA upload was 26 March 2005, so some catch-up work will be needed to update the packaging; and it was removed from unstable by ftp-masters at the request of QA on 23 November 2007 [2]. [1] http://bugs.debian.org/255807 [2] http://ftp-master.debian.org/removals-2007.txt > When trying to upload the package with dput, then come following error > messages: > > [EMAIL PROTECTED]:~/newspost-2.1.2.beta$ dput -P ftp-master > debian/newspost.changes That is not going to work; only official Debian Developers and Debian Maintainers are allowed to upload to ftp-master. Consider uploading your package to mentors.debian.net where people can take a look at it. See http://mentors.debian.net/ and http://mentors.debian.net/cgi-bin/maintainer-intro . > I don't know anything about the file debian/files, so I need help. That particular file is usually generated automatically during a package build. But you'll want to check into the other files in the debian dir. > At present time I want to build a source package only, the binary package I > want to make later. OK, but keep in mind that it must be possible to build the binary package from the source package before the package can enter Debian. Also, you are more likely to find packaging errors if you try to build the binary package yourself. > It follows newpost.changes with signature: [snip] The file you named newpost.changes is not in the proper format for a changes file. Changes files of the type that dput takes as argument are automatically generated during a package build by dpkg-buildpackage. They are *not* the same thing as a changelog. I *highly* recommend that you read some documentation before you proceed further, starting with the mentors.debian.net pages above and these: http://www.debian.org/doc/devel-manuals#maint-guide http://wiki.debian.org/HowToPackageForDebian http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging Otherwise you may become very frustrated. Since newspost is not currently in Debian unstable, you should also file an ITP; see this URL: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-newpackage best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: Test suites
Neil Williams wrote: > On Sun, 2008-04-20 at 14:58 +0200, Martin Fuzzey wrote: >> Hi mentors, >> >> A little question regarding automatic test suites : >> >> When a package provides such a suite should the normal package build process >> : >> >> 1) Always run the test suite (for example to catch bugs that may not >> occur on the developper's architecture) > > Yes. (That is the main point of having a test suite.) I agree with this (of course with the caveat that DEB_BUILD_OPTIONS=nocheck should disable the test suite). But I'll add a minor and maybe obvious exception -- one should disable or rework any parts of the test suite that would need any of the following: * An X server (e.g. for GUI tests) * A working network connection * Write access to the file system outside the build directory (with obvious exceptions like /tmp) * Interactivity None of these are guaranteed to be available on the buildds. (Although minimal interactivity could be scripted with expect or some such.) best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: RFS: gliese (updated package) [Uploaded]
Francisco García wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.1-14 > of my package "gliese". For the benefit of debian-mentors, I'm writing to mention that I have now uploaded this also. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: RFS: yale (updated package) [Uploaded]
Francisco García wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.0-13 > of my package "yale". [snip] Hi debian-mentors, Just for the record, this is now uploaded (I've been in private communication with the maintainer). I also intend to upload gliese as soon as I hear back about one minor thing. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: netcdf with new and improved diffs [Uploaded]
Warren Turkal wrote: > On Thursday 05 April 2007 17:26, Kevin B. McCarty wrote: >> In order to ensure that upgrades run smoothly, the easiest possibility >> (maybe the only possibility) is for you to also add the epoch, changing >> the version number on your packages to 1:3.6.2-1 which is higher than >> 1:3a-2.1 > > Okay. > >> Making this one change in debian/changelog is the only thing that should >> be required. Â(There is no need to renumber the orig.tar.gz or anything >> like that -- the epoch number is just as Debian-specific as the Debian >> revision). ÂPlease re-post a diff.gz including this one change and then >> I really will upload it. > > Done. Uploaded. Thanks for your patience with my perfectionism. You should get a confirmation email from the Debian queue daemon within a couple hours. Then the packages will have to be processed in NEW since there are renamed binary packages. From experience, this will probably take between 1 and 3 weeks, depending on how busy the FTP-masters are. Once they approve the packages, you should get a second confirmation email. After that happens, you can look at the packages' status on the experimental buildd machines at [1], and at the actual buildd logs at [2]. (The official Debian buildd site at buildd.debian.org does not keep track of packages in experimental, as far as I can tell.) [1] http://www.buildd.net/cgi/package_status?experimental_pkg=netcdf&searchtype=all [2] http://experimental.ftbfs.de/build.php?arch=&pkg=netcdf&ver= best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: netcdf with new and improved diffs
Warren Turkal wrote: > On Thursday 05 April 2007 15:12, Kevin B. McCarty wrote: >> Do you plan to post a final 3.6.2-1 version for me to build and upload? >> Or shall I just bump the version number in the 3.6.2-1~pre8 changelog to >> 3.6.2-1, then build and upload that? > > I have now posted 3.6.2-1. There are no changes from pre8 other than the > changelog revision. I'm sorry! I finished building 3.6.2-1 and was preparing to upload it when I noticed (just in time) that the old netcdf-doc package has an epoch in the version number -- it is at version 1:3a-2.1 In order to ensure that upgrades run smoothly, the easiest possibility (maybe the only possibility) is for you to also add the epoch, changing the version number on your packages to 1:3.6.2-1 which is higher than 1:3a-2.1 Making this one change in debian/changelog is the only thing that should be required. (There is no need to renumber the orig.tar.gz or anything like that -- the epoch number is just as Debian-specific as the Debian revision). Please re-post a diff.gz including this one change and then I really will upload it. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: netcdf with new and improved diffs
Warren Turkal wrote: > On Thursday 05 April 2007 12:47, Kevin B. McCarty wrote: >> One minor point is that the orig.tar.gz of a source package that was >> modified for Debian (even just to repack it) should contain a directory >> named >> netcdf-3.6.2.orig >> rather than >> netcdf-3.6.2 > I created README.Debian-source with the following text: > > The orig.tar.gz has changed from the upstream source. To recreate the > orig.tar.gz from the upstream source, follow these steps. [snip] Looks fine. > I will upload a 1~pre8 for you to check out first. In fact, it's already > posted if you wanna look at it. I have also posted the new orig.tar.gz. I've scanned those and they also seem good. Do you plan to post a final 3.6.2-1 version for me to build and upload? Or shall I just bump the version number in the 3.6.2-1~pre8 changelog to 3.6.2-1, then build and upload that? >> During the build, there are a lot of error messages of the form >> "warning: enumeration value ‘NC_NAT’ not handled in switch". Is this >> something that could be a problem? Maybe upstream would best know the >> answer to this... > > First of all, they are warnings. Upstream says the errors were also in 3.6.1 > or before. They don't seem to cause any functional problems. I have > scientists using 3.6.2 compiled and installed into /usr/local as we speak. OK, it sounds safe then. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: netcdf with new and improved diffs
Hi Warren!
Warren Turkal wrote:
> Kevin,
>
> Today is your lucky day. I addressed all of your bullet points along with a
> fun bonus. The new revision (1~pre7) is at [1]. I now think that 1~pre7 is
> ready for experimental after a revision change to 1.
Thanks for addressing all of these points! Unfortunately I've found
some new things to complain about :-) related to the tarball repackaging
and the new binary packages. (This is *not* an objection to either
thing that you've done; both are good ideas.)
> So you know, the orig.tar.gz has changed in this revision. I untarred it,
> ran ./configure && make distclean to get rid of some files, and tarred it
> back up.
OK.
One minor point is that the orig.tar.gz of a source package that was
modified for Debian (even just to repack it) should contain a directory
named
netcdf-3.6.2.orig
rather than
netcdf-3.6.2
although anyone downloading the source package with "apt-get source"
will still obtain a netcdf-3.6.2 directory.
Also, the debian directory (in the diff.gz) should contain a file named
"README.Debian-source" that describes how the repackaged orig.tar.gz
tarball was generated from the original upstream tarball. (In this case
you could basically just copy your second paragraph I quoted above into
that file :-) Note you don't need to install this file in the binary
.debs, just in the source package.
You can find these recommendations in section 6.7.8.2 of the Developers
Reference:
http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz
> I have the netcdf-doc package in this revision. I moved the docs from
> libnetcdf-dev as well as the html docs into this package. Please check it
> out.
--> Close #321337 in debian/changelog then?
I did look into the -doc package and everything looks fine.
You may want to have libnetcdf-dev Suggest or Recommend netcdf-bin
and/or netcdf-doc, but this is optional; only do it if you think it's a
good idea.
Linda gives me three warnings, related to the new -doc and -dbg packages:
> W: netcdf-doc; This package ends in -doc, or -docs, and isn't in Section: doc
> This package is considered to be a documentation package, but is not
> contained in Section: doc. This may cause warnings from dinstall when
> you upload.
--> add "Section: doc" under the netcdf-doc stanza in debian/control
> W: netcdf-dbg; Long descriptions contains short description.
> The long description of this package contains the short description.
> This is a bad idea, as the long description should be long, and not
> just reiterate the short description.
--> This warning I think can be ignored, since you just have the short
description as part of a complete sentence in the long description.
> W: netcdf-dbg; There is no Depends: line in the control file.
> The package has no Depends: line in the control file. This is not
> allowed by Policy if the package in question contains binary objects.
> Perhaps try calling dpkg-shlibdeps or dh_shlibdeps in the package
> rules file.
--> Have netcdf-dbg Depend upon "libnetcdf4 (= ${binary:Version})"
--> Also, please give netcdf-dbg "Priority: extra" in debian/control
I think that overall the packages are in great shape, despite my
nitpicking. Please fix the points mentioned above, change the version
number to 3.6.2-1, and I will be happy to upload to experimental. Thanks
again for taking on this important science-related package; there cannot
be too many maintainers of science packages in Debian!
Finally, a couple ancillary questions:
The change of your maintainer address to the penguintechs dot org
address is intentional, right?
During the build, there are a lot of error messages of the form
"warning: enumeration value ‘NC_NAT’ not handled in switch". Is this
something that could be a problem? Maybe upstream would best know the
answer to this...
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
signature.asc
Description: OpenPGP digital signature
Re: netcdf with new and improved diffs
Warren Turkal wrote: > Kevin and other interested parties, > > New netcdf packages are up at [1]. All issues are fixed other than the > netcdf-doc related issue. > > [1]http://www.penguintechs.org/~wt/debian/netcdf/ Hi Warren, Let me preface this email by saying that all the comments below are "wishlist" items in my opinion, so I would be fine with uploading the 3.6.2-1~pre6 packages to Debian/experimental for you as they are, after of course changing the version number to 3.6.2-1 in the debian/changelog. Would you like me to go ahead and do that, or to wait for a bit longer? The main downside of having me upload now is that if you later add an arch:all package to the docs, netcdf will then have to go through NEW a second time. (Although if the arch:all package is named "netcdf-doc" to replace the old netcdf-doc source/binary package, that may not be the case -- I'm not entirely sure.) The comments are these: 1) I see you've decided to use the pre-built PDF / PS documentation files shipped in upstream's orig.tar.gz, and so commented out the debian/rules clean target. There's nothing wrong with that, as has previously been mentioned on this list, since we know these docs can be rebuilt from the source package. However, because you're doing this, it could be worthwhile to remove the build-dependencies on texinfo and texlive-latex-base | tetex-bin from debian/control. They currently don't do anything except cause an awful lot of packages to be downloaded by pbuilder or sbuild, which increases the build time. 2) I also have just noticed that upstream's build outputs a message recommending to do a "make check" to test the binaries / libraries. Is this something that would be reasonably easy to put into the Debian build? 3) [of course you know this, I'm leaving it here as a placeholder to remind myself]: the possibility to move the docs from libnetcdf-dev into an arch:all binary package. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: packages for netcdf 3.6.2 (released today)
Warren Turkal wrote:
> On Wednesday 07 March 2007 17:47, Kevin B. McCarty wrote:
>> * possibility to build an arch:all documentation package
>
> The maintainer is encouraging the use of the pre-built docs instead of
> building them from the texinfo sources. Would there be an issue with doing
> that?
It looks like there was a general consensus in a thread from 2005 [0]
that as long as the source code for the docs is shipped in the source
package, it is OK to ship the pre-built docs in the binary package(s).
Someone in that thread suggested [1] adding a target in debian/rules
that could build the docs even if that target was never called (except
by hand from time to time, to make sure that the docs are still
autobuildable).
[0] http://lists.debian.org/debian-mentors/2005/02/msg00131.html
[1] http://lists.debian.org/debian-mentors/2005/02/msg00134.html
If you want to do this, most of the clean target I suggested earlier
should be removed, since sbuild and dpkg-buildpackage always run
debian/rules clean first.
>> * whether or not this is the same as the "netcdf-doc" referenced by #321337
>
> It seems to be. However, netcdf-doc hasn't been updated in ages.
Hmm. Do you think that the FTP masters should be asked to remove the
netcdf-doc source package from unstable once the new netcdf is there? If
so, I guess there is no problem with including a netcdf-doc binary
package built from the netcdf source package. The existing netcdf-doc
source package is most unlikely to end up on the autobuilders
(especially now that I realize it is of course arch:all) before netcdf
3.6.2 is in unstable :-)
>From your other email:
> On Wednesday 07 March 2007 17:47, Kevin B. McCarty wrote:
>> 1) I have to tell you that I made an error in the clean target I
>> suggested for debian/rules:
[snip]
>> ... specifically, all of the $ signs above should be changed to $$ in
>> order to escape them from Make. My apologies for that!
>
> Fixed in pre4 @ [1].
>
> [1]http://www.penguintechs.org/~wt/debian/netcdf/
Assuming you'd like me to look at the newer -1~pre5 version there instead?
Looks fine, except there are still a lot of HTML files in the diff.gz.
This rule in the debian/rules clean target:
rm -f man/*.html
doesn't get them all since most are in subdirectories of man. Try this
instead for instance:
find . -name '*.html' -exec rm -f {} \;
# remove now-empty directories
find . -depth -type d -empty -exec rmdir {} \;
It would make sense to delete these in a clean target even if you decide
to use the docs prebuilt by upstream, since these HTML files are *not*
present in the orig.tar.gz and you don't install them to the .debs in
any case.
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages for netcdf 3.6.2 (released today)
Hi Warren, Thanks for making all the suggested changes in -1~pre3. Other than the following 3 points, the packages look good. 1) I have to tell you that I made an error in the clean target I suggested for debian/rules: > for file in netcdf-c netcdf-cxx netcdf-f77 netcdf-f90 \ > netcdf-install netcdf-tutorial netcdf ; do \ > rm -f man/$file.ps man/$file.pdf \ > man/$file.html man/$file.dvi ; \ > done > rm -f ncdump/ctest.c ncdump/ctest64.c ... specifically, all of the $ signs above should be changed to $$ in order to escape them from Make. My apologies for that! 2) There is another new thing that appeared in the -1~pre3 release, which is that now the following appears in the diff.gz: > $ lsdiff -z netcdf_3.6.2-1~pre3.diff.gz | grep -v /debian/ > netcdf-3.6.2/man/netcdf/index.html > netcdf-3.6.2/man/netcdf/Foreword.html > netcdf-3.6.2/man/netcdf/Summary.html [snipped 341 more lines in "man" directory] Where did those come from? Is their addition in the diff intentional? I'm guessing that these may be HTML versions of the documentation that were generated at some point, but not cleaned when you ran dpkg-buildpackage. In this case maybe the above clean target should be extended by adding this: rm -rf man/$$file ; \ within the for loop. Also, do you plan to install these HTML files in the documentation directory as well? 3) And of course please let me know what decision you reach about these points: * possibility to build an arch:all documentation package * whether or not this is the same as the "netcdf-doc" referenced by #321337 If not, and if you do decide to create the arch:all package, I guess it should be named something other than "netcdf-doc" since various packages (sbuild, apt) don't deal well with binary packages of the same name as an unrelated source package [0]. [0] http://lists.debian.org/debian-policy/2007/01/msg00031.html best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: packages for netcdf 3.6.2 (released today)
Warren Turkal wrote:
> The NetCDF 3.6.2 library was just released today. I have created packages at
> [1]. They are lintian clean and apt-gettable. Please review them. Considering
> this is a stable NetCDF release, I am also looking for a sponsor.
>
> [1]http://www.penguintechs.org/~wt/debian/netcdf/
Hi Warren,
as promised earlier, I will be happy to sponsor these packages.
There are some things I think should first be fixed or at least looked at:
debian/README.Debian:
* nothing substantive in here so probably this file should be deleted.
debian/changelog:
* Please close the ITA bug (#321336) in your changelog entry.
* Please merge in the changelog entries from Debian package versions
3.6.1-0.2 and 3.6.1-1. (I'd suggest merging everything from your
earlier unofficial packages into one changelog entry for 3.6.2-1.)
* Also, I'd strongly recommend uploading to experimental for the moment
(i.e. change the target distribution in the first line of the changelog)
so as not to complicate getting any fixes that may be needed for netcdf3
into Etch.
* I'm not sure the BTS is smart enough to close #278739 that appears
with a newline between it and "closes:". (If I'm wrong, someone please
correct me.)
debian/control:
* netcdfg-dev should be in section "oldlibs" since it's an empty
transition package
* libnetcdf-dev should be in section "libdevel" rather than "devel"
* It's generally a good idea to have the lib*-dev package depend on the
exact same version of the lib package, e.g.
Depends: libnetcdf4 (= ${binary:Version})
* The documentation in /usr/share/doc/libnetcdf-dev comes to 3.2 MB,
probably large enough to consider creating a separate netcdf-doc package
for it.
On second look I see you have an ITA for "netcdf-doc" -- is this the
same as the documents now in your packages in
/usr/share/doc/libnetcdf-dev? If so, your changelog should also close
the ITA for #321337. If not, maybe the existing netcdf-doc package
would better be renamed something like netcdf-users-guide, based on its
description.
debian/copyright:
* In the first line of the first ALL-CAPS clause you have "provided by
the Regents and Contributors" - this looks like you may have missed
substituting your own name for "the Regents" ? Also you may want to
give the year(s) of your copyright on the Debian packaging.
* I'm not sure whether you may want to acknowledge the previous
maintainer(s) of netcdf even though you don't use their work. I seem to
recall this was discussed on debian-mentors before but I don't remember
the consensus.
debian/docs:
* This file causes README to be installed into the first .deb package
named in the control file, namely the dummy package netcdfg-dev. Do you
actually want it there? (It also gets installed also to the other three
packages where it makes more sense.)
debian/libnetcdf-dev.docs:
* I think you should omit the info files from here since they also get
installed to a more sensible place by the presence of the
libnetcdf-dev.info file.
debian/rules:
* A number of files in the source tree are autogenerated, for instance
the PS and PDF files. If one runs a build and then runs "debian/rules
clean", these files no longer exist, making the process not idempotent.
To make sure these files get built properly from scratch, I'd recommend
adding the following commands in the clean target of debian/rules:
for file in netcdf-c netcdf-cxx netcdf-f77 netcdf-f90 \
netcdf-install netcdf-tutorial netcdf ; do \
rm -f man/$file.ps man/$file.pdf \
man/$file.html man/$file.dvi ; \
done
rm -f ncdump/ctest.c ncdump/ctest64.c
and also adding "texlive-latex-base | tetex-bin" to Build-Depends in
debian/control.
(note: they would instead be in Build-Depends-Indep if you create an
arch: all netcdf-doc package *and* can work out how to get CDBS to
generate the docs only in the binary-indep target.)
One last thing: please install RELEASE_NOTES as the upstream changelog
("changelog.gz") in all the binary .debs.
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
signature.asc
Description: OpenPGP digital signature
Re: netcdf again
> On Friday 02 February 2007 19:10, Kevin B. McCarty wrote: >> One cautionary note: If you go with 3.6.2~beta6 for an upstream version, >> your build directory will be named netcdf-3.6.2~beta6. ÂI remember that >> some libtool versions don't like directory names that include tildes [0] >> ... might that be a problem? ÂIf this is so, it could be necessary to >> re-libtoolize the source with Debian's libtool [1,2]. > > Even after re-libtoolizing, the version scheme above causes failures in the > build for me. Ugh. Unless any libtool experts have a quick fix to suggest, maybe then the version scheme could be something like this: 3.6.1-1 (existing version in Debian) ... 3.6.1+3.6.2.beta6-1~pre1 (your unofficial releases) 3.6.1+3.6.2.beta6-1~pre2 ... 3.6.1+3.6.2.beta6-1 (official upload to Debian) 3.6.1+3.6.2.beta6-2 ... 3.6.1+3.6.2.beta7-1 (new upstream beta release) ... 3.6.2-1 (final upstream 3.6.2 release) where the orig.tar.gz's are named netcdf_3.6.1+3.6.2.beta6.orig.tar.gz etc. The problem with this scheme is of course that the version numbers are really ugly. But at least they are monotonically increasing and don't require an epoch. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf again
Warren Turkal wrote: > You have convinced me, I will reroll the packages at version > 3.6.2-beta6~pre1-1 so that the original source is uploaded as well. The > current version scheme I used doesn't allow a proper -1 release. Or do you > have a suggestion? I'm not quite sure whether you want the "pre1" to be part of the upstream version or of the Debian revision versioning system. Assuming that the upstream version is 3.6.2-beta6, I'd suggest the following scheme: Packages that you distribute unofficially: 3.6.2~beta6-1~pre1 (then 3.6.2~beta6-1~pre2, etc.) Eventual package for upload to Debian: 3.6.2~beta6-1 Note the use of a ~ in the upstream version (3.6.2~beta6). Otherwise, 3.6.2-beta6 is greater than the eventual release version 3.6.2. Setting the Debian revision to 1~pre1 lets you make the eventual release targeted to Debian experimental (or to unstable, post-Etch release) be version 3.6.2~beta6-1. Alternatively you could just release unofficial 3.6.2~beta6-1 packages now, and have the final version uploaded to Debian be 3.6.2~beta6-4 (or just whatever the Debian revision happens to be by then). All that's necessary is to remind your sponsor to build with the -sa option to dpkg-buildpackage, to ensure that the orig.tar.gz will get uploaded. Some people are a bit insistent about always wanting the first Debian upload of a sponsored package to be -1, but I'm not one of them ;-) One cautionary note: If you go with 3.6.2~beta6 for an upstream version, your build directory will be named netcdf-3.6.2~beta6. I remember that some libtool versions don't like directory names that include tildes [0] ... might that be a problem? If this is so, it could be necessary to re-libtoolize the source with Debian's libtool [1,2]. [0] http://lists.debian.org/debian-devel/2006/09/msg00825.html [1] http://lists.debian.org/debian-devel/2006/09/msg00828.html [2] http://lists.debian.org/debian-devel/2006/09/msg00830.html best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf again
Warren Turkal wrote: > I plan on maintaining these packages outside of Debian until Etch. If you > think it would be useful to upload to experimental, what do I need to change? > I would assume that the changelog needs to say experimental instead of > unstable. Is there anything else? I am pretty certain that the changelog entry is the only thing needed to ensure that uploads go to a specific distribution (unstable, experimental, stable-security, etc.). Uploading to experimental could be useful in two ways: it would help ensure that the packages can be autobuilt (experimental now is autobuilt for several arches), and it would make the packages a canonical part of Debian for any people who are adventurous enough to try a new RC release of netcdf. As an added bonus, it would also get the packages into the NEW queue now, so that by the time you're ready for them to be in unstable, there will hopefully be no wait time :-) best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Few questions
Hi Thomas, Thomas Goirand wrote: > I don't want that it's possible to have them both at the same time. Once > again, my package1 and package2 are the same, only dependencies are not. > So can I write: > > Package: package1 > Conflicts: package2 > Replaces: package2 > [...] > Package: package2 > Conflicts: package1 > Replaces: package1 > Provides: package1 That should work quite well. If any third-party packages want to depend on either of your packages, they would just have to do "Depends: package1" and that should pull in package1 if it isn't already installed. If package2 is already installed, the dependencies would already be satisfied. Presumably you've decided most people would rather have package1 than package2? One word of caution: Note that if a third-party package wanted to declare a *versioned* dependency on package1, it would always pull in package1 (causing package2 to be uninstalled if it was present). This is because virtual packages cannot satisfy versioned dependencies. By the way, therefore if a third-party package explicitly wanted package1 and not package2, it could do "Depends: package1 (>> 0)" to force installation of package1. Finally, if package1 and package2 contain a lot of files that not only are installed at the same path/filename but also are identical, you might want to instead stick those into a third binary package "package1-common" and have both package1 and package2 Depend upon that. That would save disk space on the Debian mirrors, and also save bandwidth for people who install package1 and then later change their minds and want package2 instead (or vice versa). best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf again
Hi Warren, > The new packages are at [1]. > > The newest packages remove the libnetcdf++4 package as I don't think it's > needed. Because of the soversion change, I agree with you that the libnetcdf++4 package (even as a dummy) is unneeded, since nothing at all depends upon it. > Please check out these packages, and help me get them ready for upload to > debian. I'll be happy to take a look at these when I have a moment! I do want to caution that because of the upcoming release, it may be best not to upload them to Debian right now. If they make it into Sid, because of the soversion change it will become impossible for any more netcdf packages (or any packages that are newly rebuilt that depend on netcdf) to propagate into Etch except via testing-proposed-updates. So I'd recommend either targeting experimental with these packages, or else holding off on the upload until the Etch release. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BALLView - a molecular viewer and modeling tool
a very minor correction... On 1/26/07, Andreas Tille <[EMAIL PROTECTED]> wrote: On Fri, 26 Jan 2007, Andreas Moll wrote: > I have uploaded a new version of the package. Well, I checked your work offline and my comments are concerning the version from tomorrow morning. So feel free to ignore issues that might be voided by your new version. > I have changed the control file again, to support the ppc arch. If there is no reason to exclude a certain architecture you should always use "Architecture: all" in your package. I'm pretty sure you meant to say "Architecture: any" here. (For anyone who might need clarification: an Architecture: any package must be built separately on every architecture. Architecture: all is for a package that can be built once and then used on every architecture as is, usually because it contains scripts, data or documentation, but no libraries or binaries. The two words are too similar, everyone gets them mixed up at one point or another :-) By the way, Andreas Moll, the PPC architecture name in Debian is "powerpc" and not "ppc", as in "foo_1.0-3_powerpc.deb", just in case there was some doubt... I hope this didn't come across as nitpicky, just wanted to make sure things were clear for anyone new to Debian packaging who might be reading the lists. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library sonames and unstable libraries
Justin Pryzby wrote: > On Tue, Jan 09, 2007 at 08:46:59AM +0100, Andreas Fester wrote: >> Hi, >> >> Junichi Uekawa wrote: [Andreas] >> >> so I suppose that the format libfoo-1.2.3.so only exists for historical >> >> reasons, right? IMHO new packages have to use the form libfoo.so.1.2.3 ? >> > >> > That's not quite the case. >> >> Yes, Steve already said that; so, if I understand it correctly, none of >> the two formats is preferred over the other one, i.e. if upstream >> uses either of them, both would be valid for Debian, right? > I couldn't find it (or would have mentioned it), but dpkg-shlibdeps (I > believe) used to contain a comment to the effect that the > libfoo-1.2.3.so-style sonames were not to be encouraged. This might > have just been a Debian interpretation resulting from some > (hypothetical) bug report from maintainers of a package using that > style (or something). I'm guessing that people who name libraries like libfoo-1.2.3.so often tend to (lazily) use the software version number as the release number, so they don't need to keep track of (or try to prevent) ABI incompatibilities. Hence the soname changes with every new version. I can see why this behavior would be discouraged :-) (Yes, I know Gnome/GTK+ doesn't have this issue; it was just a general statistical observation.) best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stupid library ABI question
Neil Williams wrote: > On Wed, 10 Jan 2007 09:36:28 -0800 "Kevin B. McCarty" > <[EMAIL PROTECTED]> wrote: >> Upstream of my library (Cernlib maintainers) only ships static >> libraries, and the shared library support is hacked in by me. So I >> have complete control over the soversion, but of course I'd rather >> not bump it if I can get away without doing so. > > ... especially so close to Etch ... I probably should have mentioned that I will not upload anything implementing this change until after Etch. :-/ Sorry if I upset any release managers! best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stupid library ABI question
Thanks everyone who answered so far! Unfortunately some of the answers (Steve Langasek's vs. Neil Williams') seem directly opposed :-) I'd like to try to understand this better since I really know very little technical detail about how the runtime linker works. Neil Williams wrote: > On Mon, 08 Jan 2007 11:19:40 -0800 > "Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: > >> Hello, >> >> I have a dumb library ABI question. Suppose I maintain a library >> libfoo.so that has public functions A(), B() and C(). Now there is a >> new release in which libfoo.so only provides A(), but it is now (newly) >> dynamically linked against libbar.so, which has public functions B() and >> C() with interfaces identical to the old B() and C() in the old version >> of libfoo.so. > > How will applications linked against the original libfoo be able to > locate the symbols B and C? As these are called directly from the > application, the application would have to be linked against libbar. > > You are adding a new dependency to these applications, libbar. Doesn't the linker on Linux search dependencies recursively? Suppose there is some application "do_stuff" that was originally linked against the old libfoo.so (the one that provided B() and C() itself). If "objdump -x do_stuff | grep NEEDED" gives libfoo.so, and "objdump -x libfoo.so | grep NEEDED" gives libbar.so (only on the new libfoo.so) then wouldn't do_stuff, now being indirectly linked against libbar.so[*], still have B() and C() in its list of known symbols? [*] That is, "ldd do_stuff" will now output both libfoo.so and libbar.so > A better solution for libfoo, IMHO, is for libbar to use barB() and barC > () then libfoo can retain B() and C() until such time as all > applications have migrated to barB and barC. Understood, but this isn't really an option for me. The issue is that I maintain a library [*] whose source includes embedded code from old versions of libXbae and libXaw, and I've just been notified of this fact. I would really rather remove that code and link it dynamically against external versions of those libraries (for obvious security and maintainability reasons). Not being upstream of libXbae or libXaw, I really can't change the name of the functions in question in those libraries. [*] libpawlib2-lesstif Debian package, if anyone's interested Upstream of my library (Cernlib maintainers) only ships static libraries, and the shared library support is hacked in by me. So I have complete control over the soversion, but of course I'd rather not bump it if I can get away without doing so. Let me ask another question that will possibly show the amount of my ignorance :-) If a library stops shipping certain symbols (so that the soversion *should* definitely be bumped, but *isn't*), but no applications or other libraries actually use those symbols, then what happens to programs built against the old library but now using the new one? a) They segfault because the new version of the library is missing symbols b) They work properly because they don't use the missing symbols c) Something in between (?) There are no other interface changes in the library (i.e. function APIs and structs that still exist all stay the same). best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Stupid library ABI question
Hello, I have a dumb library ABI question. Suppose I maintain a library libfoo.so that has public functions A(), B() and C(). Now there is a new release in which libfoo.so only provides A(), but it is now (newly) dynamically linked against libbar.so, which has public functions B() and C() with interfaces identical to the old B() and C() in the old version of libfoo.so. Does libfoo.so need to have its soname bumped, since it no longer provides B() and C()? Or can it keep the same soname since it still indirectly provides B() and C() via its new dependency on libbar.so? Thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal wrote: > On Friday 15 December 2006 17:22, Warren Turkal wrote: >> Known issues: >> * haven't bumped soname for C++ yet. I want to see if upstream will do >> that. > > Ed from upstream had a question: > > *** > I'm not too strong yet on how these numbers are used, but last time I > looked into it the conclusion was to release version 3.6.2 of netCDF > with: > > -version-info 0:0:0 > > Any comments would be welcome. Do you think this is correct? > *** I'm not clear exactly how libtool translates -version-info flags to version numbers. (If I read the libtool script right, then -version-info X:Y:Z translates to "libfoo.so.(X-Z).Z.Y" on Linux.) However, it is definitely the case that having -version-info 0:0:0 will create a library with filename "libwhatever.so.0.0.0" and soname "libwhatever.so.0". This will break any binary compatibility with previous netcdf versions, so it would definitely become necessary to rebuild existing programs against the new netcdf. (This is always a risk when a Debian packager hacks in shared library support, and then later upstream decides to support building shared libraries in the official source.) If upstream is sketchy about library versioning, please ask them to read the "Library interface versions" chapter of the libtool Info docs, and hopefully all will become clear :-) Maybe also point them at the C++ ABI FAQ mentioned in a previous email of mine: http://www.trolltech.com/developer/knowledgebase/362/ > Can you please comment on this issue as to what would help us ship a > non-modified upstream soname? If upstream were to ship netcdf 3.6.2 using -version-info 4:0:0, that would put their soversion higher than any that had previously been hacked in by downstream suppliers. So you might ask them if they could do that. (Again this would necessitate rebuild of netcdf-depending programs. But my best guess is that ABI compatibility from netcdf version 3.6.1 has already been broken, based on your description of the situations in which kst-plugins had a segfault. At least having upstream start with libnetcdf.so.4 would guarantee a monotonic progression of soversions in the Debian package history.) Of course, it's up to them whether they are willing to do so. If they don't, Debian will have to support whatever their official decision is. >> * researching cfortran.h issue > > I have asked upstream to prefer the system version of cfortran.h over the one > included in the tarball. I saw your copy of their response, which was basically "we always want to prefer our own version in case the system version is old and buggy". As far as I can tell, though, netcdf changes to cfortran.h 4.3 are pretty minimal, and consist mainly of adding cygwin, Pathscale, and gfortran support. The gfortran support has been patched into Debian's cfortran.h independently, and of course Pathscale compiler and cygwin support are not relevant to the build on Debian. As cfortran maintainer I'd prefer to see you force use of the system cfortran.h during the build, but if you don't want to go against upstream in this way I understand. It is really a pity that the cfortran author is no longer active in maintaining it; forks like this are kind of getting out of control. This comment from upstream, quoted in your other email, I'd like to understand better: > NetCDF includes it's own cfortran.h, which will be used in its build. > > Any cfortran.h on the system will not be used, it will be ignored by > netCDF. The netCDF fortran API looks for, and uses, its own > cfortran.h, not depending on it to be installed, or using it if it is. Does this mean that the libnetcdf-dev package will ship its own copy of cfortran.h somewhere (maybe at /usr/include/netcdf/cfortran.h or something similar)? How does a Fortran compilation using libnetcdff ensure that the compiler picks up that file (which it should do to be consistent) and not /usr/include/cfortran.h ? best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal wrote:
> On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
>> 1) Why did you make the libnetcdf++3 package into a dummy package and
>> move the C++ bindings into the libnetcdf3 package? ÂIf the soname of the
>> C++ package needs to evolve faster than that of the C/FORTRAN bindings,
>> as I speculated above, this would be a really good reason to keep the
>> C++ bindings in a separate package.
>
> The netcdf libs are shipped as one tarball.
Sorry, I meant, keep the C++ bindings in the same source package, but
why not put libnetcdf_c++.so.3.6.2 into a different binary package
(libnetcdf++3) as was done before? If you feel things are better with
all libs in one package, that's OK, I was just curious about the reason.
>> 3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev
>> package, not in the runtime library (libnetcdf3) package. ÂPlease do not
>> ship libtool *.la files at all, as has been requested many times by the
>> release team. ÂSee for instance the discussion at bug #400140.
>
> This advice seems contrary to [1]. #400140 also seems to contradict [1].
> Maybe
> [1] needs to be updated?
Possibly... I don't know enough to get involved in that argument,
though. All I know is that people whose opinion I highly respect seem
to hate .la files ...
>> 4) Your libnetcdf-dev package is missing a Depends line. ÂIt should
>> Depend at least upon the netcdf shared library package(s), upon any
>> *-dev packages that ship files #included by its header files, and upon
>> any *-dev packages that ship static libs depended upon by netcdf static
>> libs. Â(The last is slightly controversial, since there are people who
>> hate static libraries; for that you might be able to use a Recommends
>> instead of Depends.)
>
> Is there a better way than just listing Depends: libnetcdf3 in the control
> file for libnetcdf-dev?
Unfortunately not that I am aware of.
> I don't think that it depends on more than the standard lib.
OK. At least, maybe add a Depends on libc6-dev | libc-dev, and a
Suggests or Recommends (as you think appropriate) on gfortran.
> I have attached the new control file. Can you please check it out?
> Source: netcdf
> Section: science
> Priority: optional
> Maintainer: Warren Turkal <[EMAIL PROTECTED]>
> Build-Depends: cdbs, debhelper (>= 5), autotools-dev, gfortran, texinfo
While I think of it, please add cfortran as a Build-Depends, and in
debian/rules do something to ensure that the build happens using the
copy of cfortran.h in Debian, to ensure consistency. Probably the
easiest way would be just to
cp -pf /usr/include/cfortran.h $(CURDIR)/fortran/
in the configure target to overwrite the existing copy. In debian/rules
clean target, do the following: "rm -f $(CURDIR)/fortran/cfortran.h" in
order to avoid bloating the diff.gz.
[snip]
> Package: libnetcdf3
> Section: libs
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Provides: netcdf, netcdfg, libnetcdf++3
> Conflicts: netcdf3 (<< 3.3.1-1), netcdfg3 (<< 3.6.2), libnetcdf++3 (<< 3.6.2)
> Replaces: netcdf3, netcdfg3
Please also have it replace libnetcdf++3 (<< 3.6.2) if you are going to
have the new libnetcdf++3 be a dummy package.
[snip]
> Package: libnetcdf-dev
> Section: devel
> Architecture: any
> Depends: libnetcdf3, ${shlibs:Depends}, ${misc:Depends}
${shlibs:Depends} isn't useful for a -dev package, since static libs
(*.a files) don't contain any dependency information that dpkg-shlibdeps
can extract. As mentioned above, please also add a dependency on
"libc6-dev | libc-dev" and perhaps a Recommends or Suggests on gfortran.
> Conflicts: netcdf-dev, netcdfg-dev (<< 3.6.2)
again, please add the Replaces for these
Rest looks fine.
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal wrote:
> On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
>> This is weird: if you install your new packages of netcdf, the existing
>> kst-plugins package (from Sid) on your system should automatically pick
>> up the new libnetcdf_c++.so.3 library and function properly, fixing the
>> crash. ÂI can only think of two reasons why this would not work:
>
> This could have something to do with the largefile support.
> The --enable-64bits enables support for netcdf files over 2GB. This probably
> changes some functions to return 64 bit instead of 32 bit numbers. Is the
> appropriate solution to bump the soname in this case?
At first I thought that might be a possibility. But in looking through
the configure.ac script, it seems that on Linux, --enable-64bits doesn't
actually do anything! Check out lines 570 - 621 of configure.ac, there
is no case for Linux. Also, netcdf-install.txt says this option has no
effect on Linux.
Maybe you are thinking of --disable-largefile, which "omits OS support
for large files (i.e. files larger than 2 GB)". But large files are
enabled by default as far as I can tell.
>> *) the soname of libnetcdf_c++.so has changed since the version in Sid
>> (in which case the binary package name must be changed and indeed kst
>> must then be rebuilt against the new library),
>
> I think this is what you are referring to.
>
> Was: libnetcdf.so.3.6.1
> Now: libnetcdf.so.3.6.2
Not that...
> You may also be referring to the links to those files, which are
> libnetcdf.so.3 in both cases.
Close. There should always exist a link with the same name as the
soname, pointing to the actual file, e.g.
libnetcdf.so.3 -> libnetcdf.so.3.6.2
You can find the actual soname built into the shared library file with
the following command:
objdump -x /usr/lib/libnetcdf.so.3 | grep SONAME
and it turns out to be "libnetcdf.so.3" for both your .debs and the ones
already in Sid.
>> *) OR, the soname was not changed even though it should have been.
>> (This is not an uncommon situation since C++ is hard to maintain a
>> stable ABI in.) ÂActually, I seem to remember you saying that shared lib
>> support was hacked into the Debian packages, meaning you will need to
>> care for the soname yourself.
>
> The sonames in the old version were an illusion. Should we diverge from
> upstream on the soname?
It's generally bad to diverge sonames from upstream if at all possible.
If it's necessary, one usually adds something Debian-specific on the
end, like libnetcdf.so.3d ("d" for Debian; I know, it's ugly) and
renames the package to something like libnetcdf3d.
I did a diff between netcdf-3.6.1/src/cxx and netcdf-3.6.2-beta4/cxx and
found some changes in netcdfcpp.h that look possibly problematic. For
instance, in the NcFile class, the add_dim() and add_var() methods have
been made virtual. In NcTypedComponent, a virtual destructor was added;
in NcError, an inline function, a static function, and two static
variables were added. I'm not sure if these changes are sufficient to
break the ABI. Trolltech has an FAQ about maintaining C++ ABI
compatibility if you want to look through it:
http://www.trolltech.com/developer/knowledgebase/362/
Another thing I noticed is that the old .debs have a single file
libnetcdf.so.3.6.1 including both C and FORTRAN code, while your new
.debs have separated it out into two files, libnetcdf.so.3.6.2 and
libnetcdff.so.3.6.2. This is going to break anything that depended on
the FORTRAN bindings in the old package, since those bindings are no
longer in the same file. Again, I don't know whether any of the
reverse-dependencies of libnetcdf3 use FORTRAN bindings, but you may
wish to check that.
For these two reasons, I would add the "d" to the end of the soname and
change the name of the package (only the runtime package, not the -dev
package) in order to be safe. Then, once the new .debs are eventually
uploaded (this will require a wait for the NEW queue due to the new
binary package name), request a rebuild of all depending packages.
Possibly you should ask for comments about this on debian-devel, we are
probably getting a little beyond the scope of debian-mentors. Maybe
also send these comments/questions along upstream...
Incidentally, if you run "ldd /usr/lib/libnetcdff.so.3" on the FORTRAN
bindings, it does not show libgfortran.so.1 nor libnetcdf.so.3, both of
which it uses symbols from. This should be fixed to ensure accurate
library dependencies. (In particular, you want to ensure that the
libnetcdf3 package picks up a Depends: libgfortran1 via
${shlibs:Depends}.) Similarly, libnetcdf_c++.so.3 should ideally also
have a built-in dependency on libnetcdf.so.3.
Will reply to your other email in a minute.
best regards,
--
Kevin B. McCar
Re: changelog entries - ubuntu?
Kevin Coyner wrote: > During a recent upgrade of my Debian Sid box, I noticed the > following changelog entry: > > f-spot (0.2.2-0ubuntu1) feisty; urgency=low > > * Update to 0.2.2 upstream > > Perhaps I've already missed a discussion on this. If so, I'd > appreciate a link/pointer so that I can read up. But if not, then > are their guidelines or policy statements somewhere that explain > how and when Ubuntu releases are incorporated into Debian? > > I maintain a handful of Debian packages and am genuinely curious > about this and am not trying to start a heated debate. Hi Kevin, (another Kevin here) I am pretty sure there is no formal policy describing what to do about version numbers containing the substring "ubuntu" (or that of any other derived distribution). As far as I can see, in practice having "ubuntu" entries in the Debian changelog is tolerated. This commonly happens when the Debian and Ubuntu maintainers are the same persons, or the Debian maintainers pull from the Ubuntu maintainer's work. I imagine that having a version number containing "ubuntu" in the actual package uploaded to Debian is discouraged. I only found one package in Sid at the moment that does this: update-manager, version 0.42.2ubuntu22-7. I think this is because Ubuntu is upstream for this package. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: netcdf packages
Hi Warren, Warren Turkal wrote: > On Wednesday 13 December 2006 10:55, Warren Turkal wrote: >> I think that we should just go for it. W00T! OK, you've convinced me that compiling with gfortran shouldn't be a problem. (But please try to make sure that maintainers of any new packages introduced depending on the FORTRAN bindings of netcdf are aware of the issue.) > KST can actually plot netcdf graphs after the upgrade in library. It just > crashed on all my netcdf files before. This is another reason to upgrade the > library. > > Unfortunately, it lookes like kst will have to be relinked with the new > library to work without crashing. It uses the c++ binding. I suspect anything > using that binding would need to be recompiled as well. Did the netcdf lib > ever go through the C++ ABI change? I think it must have at least been built with the new g++: benjo (sid)[2]:~% apt-cache show libnetcdf++3| grep Depends Depends: [...], libstdc++6 (>= 4.1.0) ^^ According to packages.qa.debian.org, the version of kst in Sid/Etch was built in November '06, long after the current version of netcdf was uploaded (in July '06). So any problems with kst's use of netcdf in Sid/Etch are not likely to be due to the C++ ABI transition. I don't quite understand the exact problem you are facing, though. If I have read your email correctly, you see the following: a) libnetcdf++3 package from Sid, kst-plugins package from Sid ==> Crash b) libnetcdf++3 package from your new .debs, kst-plugins package from Sid ==> Crash c) libnetcdf++3 package from your new .debs, kst-plugins package rebuilt against your new .debs ==> Works OK This is weird: if you install your new packages of netcdf, the existing kst-plugins package (from Sid) on your system should automatically pick up the new libnetcdf_c++.so.3 library and function properly, fixing the crash. I can only think of two reasons why this would not work: *) the soname of libnetcdf_c++.so has changed since the version in Sid (in which case the binary package name must be changed and indeed kst must then be rebuilt against the new library), *) OR, the soname was not changed even though it should have been. (This is not an uncommon situation since C++ is hard to maintain a stable ABI in.) Actually, I seem to remember you saying that shared lib support was hacked into the Debian packages, meaning you will need to care for the soname yourself. Here are some other comments regarding your -beta4-1~pre3 .debs, now that I've taken the time to look at them. (Note, I have only looked at the .debs, not at the source package.) 1) Why did you make the libnetcdf++3 package into a dummy package and move the C++ bindings into the libnetcdf3 package? If the soname of the C++ package needs to evolve faster than that of the C/FORTRAN bindings, as I speculated above, this would be a really good reason to keep the C++ bindings in a separate package. 2) I don't think there should be info files in libnetcdf++3 (regardless of whether it is a dummy package or a shared library package). I see you do ship the info files in libnetcdf-dev as well (where they should be), but they should be in /usr/share/info, not under /usr/share/doc/libnetcdf-dev where info won't look for them. (On second look, you already have noticed this problem.) 3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev package, not in the runtime library (libnetcdf3) package. Please do not ship libtool *.la files at all, as has been requested many times by the release team. See for instance the discussion at bug #400140. 4) Your libnetcdf-dev package is missing a Depends line. It should Depend at least upon the netcdf shared library package(s), upon any *-dev packages that ship files #included by its header files, and upon any *-dev packages that ship static libs depended upon by netcdf static libs. (The last is slightly controversial, since there are people who hate static libraries; for that you might be able to use a Recommends instead of Depends.) 5) Wherever you Conflict against an old package (such as libnetcdf-dev's Conflicts: netcdf-dev, netcdfg-dev (<< 3.6.2)) because of file conflicts, you also need a Replaces line with similar contents. This is because under some circumstances, dpkg will try to unpack a new package before completely removing an old package that is conflicted against. Some of these issues could have been caught by comparing the contents of the netcdf binary packages in Sid and your new packages. I find that debdiff is a really useful tool for such comparisons, though of course YMMV. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: netcdf packages
Warren Turkal wrote: > netcdf (3.6.2-beta4~pre1) unstable; urgency=low > . >* New maintainer: Warren Turkal >* Completely repackaged with cdbs (closes: #378610). >* Enabled Fortran 90 support by compiling with Gfortran. (closes: #219592, > #278739) Hi Warren, Regarding the use of gfortran -- are you aware that g77 and gfortran produce object code with somewhat incompatible ABIs? See my previous emails on this topic here: http://lists.debian.org/debian-science/2005/09/msg00071.html http://lists.debian.org/debian-science/2006/06/msg5.html Unfortunately it seems that no one is yet endeavoring to make sure there is a reasonable transition plan for libraries from g77 to gfortran. (Possibly I will try to do something about this post-etch, if I have time and once gfortran supports all the g77 intrinsics.) For that reason I recommend that all FORTRAN libraries, when possible, be compiled with g77 for the moment. If netcdf does not have any functions returning REAL (single-precision) or COMPLEX, maybe building netcdf with gfortran is OK though. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: Best practice for packages using devhelp for their API documentation
Hi Michael, [CC'ing maintainer of devhelp.] Michael Biebl wrote (on debian-mentors): > the hal-doc package contains the API documentation for hal. In the last > upstream release, upstream decided to use devhelp [1] for the API > documentation. The location of the documentation files changed (to > /usr/share/gtk-doc/html/hal/) which lead to this bug report [2]. > [1] devhelp is a API documentation browser for Gnome > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398803 > While taking a look at this issue I wondered how to deal with this > correctly. It seems that this case is not handled consistently by the > different packages that have devhelp documentation. [Option #1] > Some packages just install the files to > /usr/share/gtk-doc/html/$package. This of course has the disadvantage > that people that don't use devhelp have a hard time finding the files. This is a bug in the package. Debian Policy sections 12.3 and 12.4 are pretty clear that documentation other than man and info pages is supposed to be accessible under /usr/share/doc/, at least with symlinks. (But this is a "should" rather than a "must" so it only warrants a severity-normal bug.) Also, not having docs in the expected place seriously confuses users, as in the bug you referenced. Please report a bug against any other packages you found doing this. [Option #2] > So, some package maintainers decided to move the documentation files to > /usr/share/doc/$package/html and create a link back to > /usr/share/gtk-doc/html/$package. The problem here is, that you mustn't > forget to explicitly exclude the html files from being compressed, > otherwise devhelp will not find them correctly. I think dh_compress excludes html and css files by default, doesn't it? [Option #3] > The third option is, to > leave the files in /usr/share/gtk-doc/$package and create a link to > /usr/share/doc/$package/html. > If I count the packages currently installed on my machine that use > devhelper, 6 use option #1, 16 option #2 and only 1 uses option #3. At first, reading this paragraph of Policy 12.3, I thought option #3 may be the preferred one: "Packages must not require the existence of any files in /usr/share/doc/ in order to function [78]. Any files that are referenced by programs but are also useful as stand alone documentation should be installed under /usr/share/package/ with symbolic links from /usr/share/doc/package." However, this still says that the real docs should live in /usr/share/, not /usr/share/gtk-doc/html/, so this isn't a perfect solution. Also, devhelp is an independent program, not part of the package in question, so it is not the *package* that is requiring files in /usr/share/gtk-doc/html/ in any case. From an aesthetic standpoint, personally I would prefer option #2. One can argue that devhelp is no different in principle from any other viewer that might be used to read docs. > So, there doesn't seem to be a consensus here, that's why I'm seeking > for advice and discussion of the following questions: > > 1.) Should the documentation be accessible from within > /usr/share/doc/$package? Yes, policy requires it with a "should" directive. > 2.) If yes, should the files be moved to /usr/share/doc/$package/html > and a link be created to /usr/share/gtk-doc/html/$package or > 3.) should the files remain in /usr/share/gtk-doc/html/$package and a > link be created to /usr/share/doc/$package/html These seem more-or-less equivalent to me, but as said above I'd prefer #2 aesthetically. > 4.) Should the package declare a Recommends: devhelp IMO at most a Suggests is warranted, as the docs are perfectly readable without it using any HTML viewer. > 5.) If there is a consensus on this matter, should this be documented > somewhere (policy, dev-ref) and bugs be filed against the packages not > complying to this policy? Maybe see what the Debian maintainer of devhelp thinks? Also, what does he think about the possibility of patching devhelp for Debian to look for docs in /usr/share/doc//html as well as in the default /usr/share/gtk-doc/html/ location? If that were done there would be no need for symlinks. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: Question on a package split
Francesco Pedrini wrote: > After the inspection of the new code and the discover of the new library > I have a problem with the design of the new package structure, because > if I follow the splitting scheme written above I'll have: > > kmobiletools - the real application; > libkmobiletools - the foundation library; > libkmobiletools-dev - libkmobiletools development files; > kmobiletools-plugin-kontact - the plugin; > libkmobiletools_at - the engine for AT based phone; I'm afraid this is immaterial to the actual question, but I don't think the underscore "_" is allowed in package names. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Splitting source package; what to do with NEWS files?
Hi all, I am intending to split the source package for "cernlib" into four new source packages (one of which will still be called cernlib) for the purposes of better maintainability, and making life easier on slow buildds. I have questions about what to do with NEWS files though. Let me give a simplified example to describe the questions: Source package foo, version 1-1, generates binary packages foo-bin and bar-bin. It has a file debian/NEWS that describes important changes made to the bar source code between upstream versions 0 and 1. The file looks like this: foo (1-1) unstable; urgency=low Important options of the "bar" program changed between versions 0 and 1; they are not backward-compatible. See upstream's changelog for more info. -- Kevin B. McCarty <[EMAIL PROTECTED]> [date] Later, foo is split up into source packages foo (version 2-1) that generates binary package foo-bin; and bar (version 2-1) that generates binary package bar-bin. What should I do with the NEWS file? Should it stay in the foo source package (even though it is about bar)? Should it instead move into the bar source package (even though the title of the NEWS entry is "foo")? Should I move it into the bar source package and rewrite history by changing "foo" to "bar" in the first line of the NEWS file, even though there was never a bar 1-1 source package? And will apt-listchanges do the Right Thing during upgrades in any of these cases? (In the case of cernlib, the package names in question are actually foo = cernlib, bar = geant321, and the NEWS entry in question is for cernlib version 2005.05.09.dfsg-1. As an added complication, a nearly identical NEWS entry exists for the version 2004.11.04.dfsg-0sarge1 that was pushed into stable/updates to fix a licensing problem, and is now in Sarge.) Thanks in advance for your opinions. -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Including .so symlinks in non-dev package: policy violation?
Hi Fabian,
Fabian Fagerholm wrote:
> Is it forbidden by policy (or otherwise) to include .so symlinks without
> the version number (for example, .so ->
> .so.0.0.0) in a non-dev package?
In general, yes. Let's say your library package is libfoo0 and it
includes the files
libfoo.so.0.0.0
libfoo.so.0 -> libfoo.so.0.0.0
libfoo.so -> libfoo.so.0.0.0
Later the soname is changed, so you ship a new package libfoo1 containing
libfoo.so.1.0.0
libfoo.so.1 -> libfoo.so.1.0.0
libfoo.so -> libfoo.so.1.0.0
The libfoo.so symlink that exists in both packages will prevent you from
having libfoo0 and libfoo1 installed simultaneously, and this is a
Policy violation (runtime libs must be co-installable for ease of upgrades).
> I guess the general answer is that it shouldn't be done, but how about
> this particular case:
>
> synfig, a 2D vector animation package, uses a (libtool) dlopen()-style
> way of loading plugins at runtime. The plugins are shipped as .so's. The
> plugin loader is not sophisticated enough to ask the ltdl routines for a
> versioned library [0]. If we don't ship the unversioned .so symlinks
> together with the actual .so's, the program will not work unless the
> -dev package is installed with the unversioned symlinks (some plugins
> implement essential functionality).
>
> The plugin .so's are not designed to be accessed directly. The purpose
> is to access them through libsynfig, which is properly versioned. In a
> sense, they differ from shared libraries ("libraries that are to be
> shared between applications").
As long as they aren't in /usr/lib or some other place where the linker
can find them -- that is, they are private files of synfig -- you
actually don't need to follow Policy for shared libraries. I'm not
really even clear on why you need library versioning. If synfig and its
plugins are in the same binary Debian package, there is no problem at
all. If they are in different binary packages, say "synfig" and
"synfig-plugins", but generated by the same source package, then you can
always have synfig Depend on synfig-plugins (= ${Source-Version}) so
they are guaranteed to be in sync.
> Is it ok to include the unversioned symlinks for the plugin .so's in the
> non-dev package (libsynfig0)?
If the only things in libsynfig0 are plugins, then I would rename it to
synfig-plugins, put the plugins into /usr/lib/synfig/modules, and
proceed as above.
If there is also an honest-to-goodness shared library that goes in
/usr/lib and itself uses the plugins, things get a bit more complicated.
The important thing is to make sure that libsynfig0 and the eventual
libsynfig1 are co-installable. One solution is to use versioned
directories. In the case of synfig, maybe you could have something like
this in the libsynfig0 package:
/usr/lib/synfig/0/modules/libplugin.so.0.0.0
/usr/lib/synfig/0/modules/libplugin.so -> libplugin.so.0.0.0
/usr/lib/libsynfig.so.0.0.0
/usr/lib/libsynfig.so.0 -> libsynfig.so.0.0.0
and in libsynfig-dev:
/usr/lib/libsynfig.so -> libsynfig.so.0.0.0
/usr/lib/libsynfig.a
/usr/include/whatever.h
This supposes that libsynfig can be configured to look for its plugins
only in the directory "/usr/lib/synfig/0/modules". When you bump the
soname, the lib becomes libsynfig.so.1.0.0 and the plugins go into
"/usr/lib/synfig/1/modules", where the new lib is configured to look.
(For simplicity I'm assuming the main library and the plugins have
soversions that stay in sync. If this is the case, again I see no
reason for the plugins to need soversions.)
Hope this helps,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
signature.asc
Description: OpenPGP digital signature
Re: How to 'su' to root from a script using Xdialog?
Michelle Konzack wrote: > since some times I am coding a debconf util which use Xdialog as > interface. Exactly, on startup it present a list of all packages > which can be configured with debconf and then the $USER select > the desired package and configure it using Xdialog. This doesn't answer your actual question (which I snipped), but are you familiar with the package "configure-debian" ? It sounds like it is very similar to the goal you are trying to achieve, so maybe it can save you some coding... regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depending on both runtime and dev packages?
Martin Meredith wrote:
> Kevin B. McCarty wrote:
>> Davide Puricelli wrote:
>>
>>> Hi, I'm building a package (a Scheme-to-C compiler) and I split it into
>>> three different debs: libfoo0 (runtime libs), libfoo-dev (.a and .la
>>> files and includes) and foo-bin (compiler and other tools).
>>> The depends are a big problem: foo-bin needs to depend on libfoo0
>>> (otherwise the compiler won't run) but without the -dev package you
>>> won't be able to convert a Scheme file into a C one, so a Depends on
>>> libfoo-dev is needed, too: I don't think someone will ever use a program
>>> just to see the -help screen.
>> I think there is no problem. It seems perfectly OK to me for the
>> compiler package to depend upon both the runtime lib and the development
>> package for the language. For instance, the package g77-3.4 (a FORTRAN
>> compiler) depends upon the development version of the FORTRAN library,
>> libg2c0-dev, because that package is necessary to compile FORTRAN
>> programs. (It doesn't depend upon the libg2c0 runtime package, but that
>> is because g77 is not itself written in FORTRAN.)
> Dont most -dev packages auto-depend on the libs they're assosciated with
> anyway?
Yes.
So in Davide's case, foo-bin is going to have a dependency on both the
runtime lib in libfoo0 (from ${shlibs:Depends}) as well as on the
development package libfoo-dev (which the packager includes in the
Depends list manually). You could argue that the dependency on libfoo0
is redundant; but it would be hard to leave it out since it gets added
through the shlibs mechanism.
In the specific case of g77-3.4, g77-3.4 has a dependency on
libg2c0-dev, which in turn depends on libg2c0 as you say. But g77-3.4
doesn't itself use libg2c0 even though it happens to be an indirect
dependency.
I hope I didn't confuse things further with this attempted explanation...
regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules build/build-indep/build-arch
Hi Paul, Paul Wise wrote: > According to my reading of debian-policy 4.8 and 7.6, this should be > correct: > > debian/rules: > > build: build-indep build-arch > build-indep: > build arch-indep stuff (like docs) > build-arch: configure > build some binaries > > However the autobuilders use debian/rules build instead of debian/rules > binary-arch and do not install Build-Depends-Indep. For eg: > > http://buildd.debian.org/fetch.php?&pkg=mapserver&ver=4.8.1-1&arch=ia64&stamp=1140357449&file=log&as=raw > http://buildd.debian.org/build.php?&pkg=mapserver Yes, this is a known issue with the buildd software. It's been discussed many times, most recently in this thread: http://lists.debian.org/debian-policy/2006/01/msg2.html The usual conclusion, as I understand it, has been that it will be difficult to transition safely to a situation where Policy is followed better. If the build software switched to running "debian/rules build-arch", software that only used the build target (which is permitted because build-arch is currently optional) would FTBFS. You may say that the build software could then try "debian/rules build", but it is apparently not always possible to determine that the initial FTBFS results from a missing target rather than some other problem. One proposal that seems promising is for packages who want buildds to use build-arch by default to add a certain flag to their control files. I agree that the current situation is quite annoying. Hopefully some solution will be introduced soon. > So, I'm thinking of switching the build target to something like this: > > # This is the correct, policy-compliant build target > #build: build-indep build-arch > > # This is the incorrect, non-policy compliant build target > # it is necessary because the auto-builders use build, but don't install > Build-Depends-Indep > build: build-arch I just looked into Policy, and 7.6 does not explicitly say anything about the interrelationships required between debian/rules targets. 4.8 does not specifically say that "build" must depend upon "build-indep"; it is only a "should": The build target *should* perform all the configuration and compilation of the package. The build target *should* depend on those of the targets build-arch and build-indep that are provided in the rules file. (emphasis mine) >From Policy 1.1: Non-conformance with guidelines denoted by should (or recommended) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution. ... These classifications are roughly equivalent to the bug severities ... minor, normal or important (for should or recommended directive violations) So you may get a Policy bug filed for ignoring this recommendation of section 4.8, but from my reading you are free to tag it "wontfix". In any case, I've used the solution you suggest in some of my packages. No Policy bugs filed against them yet (not that this means anything). > Is this the correct work-around for this problem? or should I put the > Build-Depends-Indep packages into Build-Depends and let the autobuilders > build the docs, but not make them into packages (seems like this is a > bad thing to do, since it increases build times and seems wasteful)? This is of course the other possible workaround, which is technically more Policy-compliant. I've used it in others of my packages. If your documents' build is CPU-intensive, I think the waste of effort to compile them on every arch outweighs the dubious benefit of technically being more Policy-compliant this way. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depending on both runtime and dev packages?
Davide Puricelli wrote: > Hi, I'm building a package (a Scheme-to-C compiler) and I split it into > three different debs: libfoo0 (runtime libs), libfoo-dev (.a and .la > files and includes) and foo-bin (compiler and other tools). > The depends are a big problem: foo-bin needs to depend on libfoo0 > (otherwise the compiler won't run) but without the -dev package you > won't be able to convert a Scheme file into a C one, so a Depends on > libfoo-dev is needed, too: I don't think someone will ever use a program > just to see the -help screen. I think there is no problem. It seems perfectly OK to me for the compiler package to depend upon both the runtime lib and the development package for the language. For instance, the package g77-3.4 (a FORTRAN compiler) depends upon the development version of the FORTRAN library, libg2c0-dev, because that package is necessary to compile FORTRAN programs. (It doesn't depend upon the libg2c0 runtime package, but that is because g77 is not itself written in FORTRAN.) best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debug packages?
Adeodato Simó wrote:
> * Paul Wise [Mon, 30 Jan 2006 22:18:07 +0800]:
>> I'd like to add a package for debug information, since the app crashes
>> occasionally. Should I add a libfoo0-dbg or foo-dbg package containing
>> debug info for the lib and the app? or should I create separate
>> libfoo0-dbg and foo-dbg packages? I'm inclined to think that creating
>> just libfoo0-dbg with debug info for both the binary and is the right
>> way to go, since there is also a gui in another package, which uses the
>> library, therefore more people will just have the library than normal.
> As long as it's only one -dbg package, I'd say that both names are ok.
> Though now that, thanks to debhelper v5, it's easy to create -dbg
> packages with symbols from multiple binary packages, I'd favour
> ${source}-dbg for those. Remember to make it Prio: extra, Section:
> libdevel.
I'm happy this topic came up because I have a couple questions about
this myself. For multi-binary source packages, should the -dbg binary
package depend on all of the other binary packages, only recommend them,
or not have any dependencies?
Also (and this is quite a dumb question), when the end user wants to use
the debug package, what magical options does s/he give to gdb when
running a program so that gdb knows where to find the debugging
information? Is additional setup needed when the thing to be debugged
is a shared library used by the program that the user directly executes?
Thanks in advance,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch vs. quilt
Adeodato Simó wrote: > * Kevin B. McCarty [Sun, 29 Jan 2006 11:39:17 -0500]: >> Out of curiosity, does quilt have a mechanism similar to dpatch that >> allows you to treat shell scripts as "patches"? My inability to find >> such a feature was the main reason I opted for dpatch over quilt in the >> Cernlib package -- I needed to move a bunch of files around within the >> source, and doing so with a pure patch system will result in huge and >> fragile diff files (two copies of each file to be moved, which breaks if >> upstream changes any of them!). > > No, in quilt patches are patches, not scripts. :) Why don't you move > files around in debian/rules, anyway? I partly answered this elsewhere in the thread (it's nice to logically keep together the file-moving operation with the patching of the Imakefiles to reflect the different file locations, in two files in debian/patches starting with the same number). The other reason is that I'm trying to keep my (fairly substantial) patches to Cernlib [1] accessible to non-Debian distributions. For instance Patrice Dumas is using my set of patches in creating Cernlib RPMs for Fedora Extras. Moving the files around in debian/rules but patching the Imakefiles in separate patches under debian/patches would make his life a lot harder :-P [1] This includes things like creating shared libraries as well as static ones, removing circular library dependencies, fixing things to work on AMD64, etc Unfortunately upstream is almost dead and I don't think they are likely to accept such changes. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch vs. quilt
Frank Küster wrote: > "Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: > >>Out of curiosity, does quilt have a mechanism similar to dpatch that >>allows you to treat shell scripts as "patches"? My inability to find >>such a feature was the main reason I opted for dpatch over quilt in the >>Cernlib package -- I needed to move a bunch of files around within the >>source, and doing so with a pure patch system will result in huge and >>fragile diff files (two copies of each file to be moved, which breaks if >>upstream changes any of them!). But now it sounds like I'm missing out >>on some features by not using quilt. > > I don't think that quilt offers this, at least not in a straightforward > way. > Why can't you separate the moving around of files from the patching? > > patch-stamp: > quilt push -a > debian/movefilearound I guess in principle I could, but it's nice to have the step where the file move takes place be right next to the step where I edit the Imakefiles (sadly, Cernlib uses imake) to suit. E.g., this file is a script to move some files around: debian/patches/702-fix-packlib-mathlib-circular-mess.sh.dpatch and this patch fixes the Imakefiles appropriately: debian/patches/702-patch-Imakefiles-for-packlib-mathlib.dpatch > But looking at its implementation, maybe this could easily be changed, > just add an additional check whether the "patch" has a shebang line at > the start, and execute it instead of calling patch. Hmm, I will look into this when I have time and maybe file a wishlist bug on quilt with a patch. Thanks, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpatch vs. quilt [was: Re: RFS: proxycheck -- link]
Frank Küster wrote: > There are also other alternatives to dpatch; one is Debian-specific and > i keep forgetting its name, and there's quilt. The main advantage of > quilt IMHO is that it doesn't duplicate the whole tree when editing and > updating the patch, which can be time- and disk-consuming in large > projects. Instead it keeps a list of files for the patch one is editing > and only keeps copies of these. Out of curiosity, does quilt have a mechanism similar to dpatch that allows you to treat shell scripts as "patches"? My inability to find such a feature was the main reason I opted for dpatch over quilt in the Cernlib package -- I needed to move a bunch of files around within the source, and doing so with a pure patch system will result in huge and fragile diff files (two copies of each file to be moved, which breaks if upstream changes any of them!). But now it sounds like I'm missing out on some features by not using quilt. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian package installation - setting environment
Hi Ivars,
Ivars Strazdins wrote:
> This seem to be appropriate mailing list, please advice, if not.
Unless you are talking about creating a Debian package, you probably
will get more advice on debian-user. The rest of my reply below assumes
that you are in fact creating a Debian package out of third-party
software. In that case, the first thing to ask yourself is -- do you
eventually want to see the package (a) in the official Debian archive,
(b) otherwise publicly or commercially available, or (c) is it for
personal or internal use only? In case (a), there are a lot of
stringent requirements ("Debian Policy") on the locations of files in
the package. In case (b) or (c), you can do as you want, but I would
recommend that publicly available third-party software built as a Debian
package try to obey Debian Policy as much as possible to reduce user
confusion.
> how do I set/change system wide environment variables when installing
> package?
Unfortunately (or fortunately, depending upon your viewpoint) Debian
doesn't have any method of setting environment variables for all users.
This is partly because it's forbidden by Policy, and partly because
it's a non-trivial problem (you don't know what shells the users are
using, etc.) The only guaranteed way to run a binary with a given set
of environment variables set is to write a wrapper script around the
binary, and export the variables in the wrapper.
> The package should go to /opt/. I've been reading a lot
> of fighting about /opt for packages.
There is no fight -- official Debian packages may not use /opt.
Third-party packages installed in some other way certainly may, but
again I would recommend that unofficial Debian packages conform to
Policy as much as possible so as not to confuse users.
> Anyway, this seem to be the right place for 3rd party packages. Also,
> I cannot change this decision anyway :(
Why -- is it closed-source software? Never mind, I just saw your second
reply:
> It is hard coded into management decision to which I really have no
> access whatsoever.
Someone should tell management that Debian users will be happier to
use the package if it conforms to expected behavior for Debian
packages :-)
> So, I need at least to add /opt//bin to $PATH + maybe
> setting some other environment variables (creating a wrapper script
> in $PATH is another possibility). How do I do this?
If management will not change its mind about the packaged files going
into /opt, it seems to me that putting wrapper scripts into /usr/bin or
/usr/sbin (or /bin or /sbin if you need the software available early in
the boot process) is your only option.
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rpath from `avifile-config --libs`
Simo Kauppi wrote: > While packaging swftools, I noticed that `avifile-config --libs` gives > -Wl,-rpath,/usr/lib -laviplay. lintian/linda obviously are not happy > with rpath. > > I can work around that, but I thought I ask if that should be > considered a bug in the libavifile-0.7-dev package. I think it's considered a bug, although AFAIK Policy doesn't explicitly forbid rpath. Junichi Uekawa writes "To remove -rpath in the upstream level, it is usually non-invasive to request upstream to special-case /usr/lib, to not add -rpath.": http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html If avifile-config is a shell script (I haven't checked), it shouldn't be too hard to submit a patch for that. > And while I'm at it, what would be the best way around if > `something-config --libs` gives rpath? `something-config --libs | sed 's/-Wl,-rpath,[^[:space:]]*//g'` would be the first thing I tried. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: R-F-NMU: saods9: imtool for astronomy -- #344317: kubuntu patch
Kevin B. McCarty wrote: > Justin Pryzby wrote: > >>>This is a request for an NMU, or 1-time sponsorship, whichever you >>>prefer. Aurelien is typically busy; I don't see the need to bug him >>>for a 1 line patch :) >>> >>>Please apply the patch given at #344317: "saods9: fix for FTBFS in >>>kubuntu dapper and breezy". >>> >>> http://bugs.debian.org/344317 > > I can get this for you today if no one else has already volunteered. > I'll start building it as an NMU now -- just let me know ASAP if someone > else has beaten me to the punch. saods9 4.0b7-1.1 just uploaded. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: R-F-NMU: saods9: imtool for astronomy -- #344317: kubuntu patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: > This is a request for an NMU, or 1-time sponsorship, whichever you > prefer. Aurelien is typically busy; I don't see the need to bug him > for a 1 line patch :) > > Please apply the patch given at #344317: "saods9: fix for FTBFS in > kubuntu dapper and breezy". > > http://bugs.debian.org/344317 Hi Justin, I can get this for you today if no one else has already volunteered. I'll start building it as an NMU now -- just let me know ASAP if someone else has beaten me to the punch. best regards, - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDw8qbfYxAIk+Dx1ERAtuEAKDLVxFobxR3GDTAhQ7pQF15MtKdlACcD0ZP dgp5ktGYxDtrmBZwTB0VuSg= =MrLx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changes to upstream sources/HOWTO patch
Bartosz Fenski aka fEnIo wrote: > On Mon, Dec 19, 2005 at 10:56:24AM +0100, Bastian Venthur wrote: >> Can someone explain to me how to apply patches to upstream sources "the >> right way" or point me to an appropriate document? > > `apt-get install dpatch` > > You've got some examples in /usr/share/doc/dpatch/ then. > > You can also take a look at some packages which build depend on dpatch. But not cernlib, your head will explode :-) -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem in Debian Quality Assurance ?
Jose Carlos do Nascimento wrote: > I am mantainer of one package and I created debian/watch file using these > lines: > > version=2 > opts=dversionmangle=s/\./-/ \ > http://www.phpconcept.net/pclzip/ > \.\./download.php.file=pclzip-([\d\-]+)\.tgz.* > > but in Debian Quality Assurance, versions are wrong showed. > > http://qa.debian.org/developer.php?login=debian%40psabs.com.br > http://dehs.alioth.debian.org/maintainer.php?name=libphp-pclzip > > Is this a bug or its normal ? I'd say it's a bug. I have a similar problem with the watch file of mn-fit. (Upstream chose to separate version number components with an underscore instead of a dot. I'm not using dversionmangle; instead I have two groups of parentheses surrounding the two numerical components -- see the URL below for my watch file.) My guess is that DEHS doesn't support unusual watch file features. I sent an email about the bug to debian-devel in October, but received no response of any sort: http://lists.debian.org/debian-devel/2005/10/msg00120.html regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about skim.
Christopher Schütz wrote: > Am Sonntag, den 13.11.2005, 01:18 + schrieb Sune Vuorela: >> A chroot is a nice solution - I use it for many things. >> >> the program 'debootstrap' can help you building a chroot. >> >> just: >> mkdir sid-chroot >> sudo debootstrap sid sid-chroot http://yournearestmirror. >> sudo chroot sidchroot >> >> in here, you can create a user account, install packages and whatever >> you like. >> >> /Sune >> > I got a problem here. Like you suggested I did a > '$ sudo debootstrap sid chroot http://ftp.de.debian.org'. > All goes well until I get 'E: Couldn't download libsigc++-1.2-5c102' > and debootstrap quits. Any suggestions what went wrong? Sid is often hard to get debootstrapped directly due to the ever-changing library packages. Try setting up a sarge or etch chroot, then chroot into it and set up the network interfaces. Then you can update to Sid with APT (of course you have to set up the appropriate /etc/apt/sources.list file in the chroot first, too). Once set up, you may want to look into the "dchroot" package which lets you give normal users the permission to chroot to the other distribution. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about skim.
Bas Wijnen wrote:
> On Sun, Nov 13, 2005 at 01:18:12AM +, Sune Vuorela wrote:
>> A chroot is a nice solution - I use it for many things.
>>
>> the program 'debootstrap' can help you building a chroot.
>>
>> just:
>> mkdir sid-chroot
>> sudo debootstrap sid sid-chroot http://yournearestmirror.
>> sudo chroot sidchroot
>
> I always mount proc (and sometimes /dev, at least when I used devfs). Without
> it, the system is handicapped, although package installs should work.
>
> sudo --bind /proc sid-chroot/proc
It's a good idea to bind-mount /tmp inside the chroot as well if you
want to run any graphical programs from within it. I also put the
bind-mounts at the end of /etc/fstab so they're done automatically:
/proc /sid/proc nonerw,bind 0 0
/tmp/sid/tmpnonerw,bind 0 0
/home /sid/home nonerw,bind 0 0
You may not want to bind-mount /home if you are running programs very
different between their sid and sarge incarnations -- e.g. they could
mess up your sarge dot-files -- but I find it very convenient. Just be
sure to keep the regular users in /etc/{passwd,group,shadow,gshadow} in
sync in the chroot.
regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflict with kernel versions?
David Given wrote: > Unfortunately, the application has its own coroutine library that turns out > to > have a nasty conflict with linuxthreads (due to allocating its own stacks, > which causes linuxthreads to crash). linuxthreads is used as part of glibc on > 2.4 kernels. 2.6 kernels, such as the one I did the development on, are fine. > > Is it possible to specify this as part of the package dependencies, and if so > how, or am I just going to have to document the fact that it'll crash on > startup on a 2.4 system? Is this, in fact, not appropriate for inclusion in > Debian because of this? To answer your first question: you cannot conflict against (or depend upon) specific kernel versions because there is no guarantee that an installed kernel package is the kernel that's running at the moment. A user might very well want to have a 2.4 and 2.6 kernel installed simultaneously, and plan to only run the app when booting into the 2.6 kernel. And a Conflicts wouldn't prevent a user from having a self-installed 2.4 kernel that was installed outside the packaging system (a case which I believe Debian supports, although I can't find a guarantee of such support in the Policy docs off-hand). What you _can_ do is to have a wrapper script around the application that aborts with an appropriate error message if it detects a running 2.4 kernel. It looks like your app is a daemon, so you could even do this in its /etc/init.d script if it's unlikely anyone would run it by hand. To answer the second question, I think it would be fine to have this app in Debian as long as the kernel version requirements were clearly documented in both the package long description (in the debian/control file) and a README.Debian file. But this is just MHO. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first steps (pcfitsio, pyraf and iraf)
Cedric BRINER wrote: > Hi, > > I'm working as a sysadmin at the Geneva Observatory and we do need > some softwares which are not provided by the debian distribution. So > I thought that it will be a good idea to do this job well once and to > give this back to the debian community. > > the software that I'm willing to package are: pcfitsio, pyraf, iraf IIRC, Justin Pryzby (justinpryzby at users.sourceforge.net) has made unofficial packages of at least IRAF. There have been some possible copyright issues with the package. You should probably coordinate work on packaging IRAF with him, especially since he owns the open ITP: http://bugs.debian.org/244711 -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: How to use imake with new X policy ?
Jose Carlos do Nascimento wrote: > Look what lintian reports: > xbanner isnt a X Window System itself. > And xbanner doesnt use autotools or automake. Its use imake. > > I dont know how say to imake put files in /usr/sbin instead /usr/X11R6 Don't know if there is a way to force imake to do that, but you can always move the binary by hand in debian/rules. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unknown default encoding?
Hi guys, I get the following warning when building cernlib on sid: dh_installdebconf -a Warning: Unknown default encoding for vi, get it from debian/po/vi.po: UTF-8 The top of vi.po is as follows: # Vietnamese translation for cernlib. # Copyright © 2005 Free Software Foundation, Inc. # Clytie Siddall <[EMAIL PROTECTED]>, 2005. # msgid "" msgstr "" "Project-Id-Version: cernlib 2004.11.04-3\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2004-02-25 17:23-0500\n" "PO-Revision-Date: 2005-06-13 15:24+0930\n" "Last-Translator: Clytie Siddall <[EMAIL PROTECTED]>\n" "Language-Team: Vietnamese <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0\n" Can someone tell me what I'm doing wrong, if anything? A Google search for this error turned up little besides package build logs, although someone else was wondering about the same thing back in 2003: http://lists.debian.org/debian-apache/2003/08/msg00083.html regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shotgun Debugger: different data packages depending on endianness
Miriam Ruiz wrote: > I've created two different packages, one with the md2 files and another one > with the md2b files. I've tried to make the main program install the > appropriate package depending on it's endianness but I wasn't able to get it > working. Any ideas how to do it? BTW, which debian archs are big endian and > which are small endian? You can Build-Depend on the "type-handling" package. As long as the main package is Arch: any, this has a way to make the main package Depend upon the appropriate data package (sdb-data-little-endian vs. sdb-data-big-endian ?) by playing with the debian/control file at build time. I assume both data packages would be Arch: all, right? Alternatively you could have the data package be Arch: any and build it with the appropriate endianness for each platform. But that would waste an awful lot of disk space. I agree with Justin that it would be most preferable to have only one data file package, and hack the program code to flip the endianness (on the appropriate platforms) in memory at the time of loading the data files. >From what I remember, the following are little-endian: i386 amd64 alpha ia64 mipsel and the following are big-endian: powerpc s390 m68k mips sparc hppa I believe arm and Super-H can be either endianness, but Debian only supports one endianness for arm -- I forget which though. (Super-H is an unofficial port which I think plans to support both cases.) regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml users: see Mathematica for study
John Hendrickson wrote: > A career imperitive here about ocaml langugae for audience of those > unfamiliar with Mathematica, Maple, Matlab. (sorry, I know, not a package > issue. But the packagers themselves are important too ;) John, Since no one else has bothered to say it yet, I'll point it out: Mathematica is off-topic for this list, since it obviously can't be packaged for Debian, and also off-topic for this thread, since Felix has nothing to do with it (as far as I could tell). If you want to see a Mathematica-syntax-compatible front end for Free Software CASes (certainly not a bad idea), you should directly contact the developers working on those projects. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ROOT package
Anibal Monsalve Salazar wrote: > On Thu, Jun 09, 2005 at 07:50:39PM -0400, Ricardo Yanez wrote: > >>Kevin McCarty and I have packaged the software called ROOT, widely used >>in particle and nuclear physics for the numerical analysis of large data >>sets. Currently, ROOT cannot go into Debian or non-free due to various >>license issues. > > > Maybe you could ask the upstream author to relicense ROOT. Hi Anibal and debian-mentors, Upstream has been promising to re-license Root for years. See, for instance, * http://root.cern.ch/root/roottalk/roottalk98/1521.html * http://root.cern.ch/root/r2002_final_discussion.html (search for "license" in that page) * http://lists.debian.org/debian-devel/2005/01/msg01166.html I'm optimistic that it will happen eventually. I do wish they would describe the biggest obstacles to re-licensing -- clearly there must be some. But I don't know if continued pestering will help :-) In the meantime, I believe that Ricardo's intent (please correct me if I'm wrong) is to request that people look over the Debianized Root source package to make sure it is done well. So at least people will have a good unofficial source of Root .debs before the license is changed, and when it is, they can immediately be uploaded to Debian. Finally, I want to note that Ricardo has been very kind in naming me as a co-packager -- he has done by far most of the work; I've just been offering advice and suggestions. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
Sebastian Kuzminsky wrote: > The upstream Cogito people have added a /usr/bin/git executable (over > my objections) which conflicts with GNU Interactive Tools' /usr/bin/git. > > Their argument is that GNU Interactive Tools is obsoleted by mc and > should just go away. For what it's worth, popcon.debian.org says that 97 people (out of 6409 participating) have git installed, while only 63 have cogito installed. So if anyone loses that argument, it's cogito and not git :-) (It also appears that cogito isn't even in Sarge, so bear in mind that someone upgrading from Sarge to Etch may very well have git installed and then try to install cogito.) -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Questions about packaging LaTeX macros
Hi debian-mentors, I ITP'ed xymtex ( http://bugs.debian.org/304714 ), which (assuming I can clear up some licensing issues) will be my first LaTeX macro package. I have a few questions for you while I wait for upstream to reply to my email about licensing clarifications: 1) Some .sty files are in a subdirectory - that is, most get installed to /usr/share/texmf/tex/latex/xymtex/ but a few go into .../xymtex/xymtxps/ - will mktexlsr still find them there? 2) Upstream source includes a bunch of .dtx and .ins files as well as .sty files. It appears that the .sty and .ins files are both autogenerated from .dtx files (in some way involving "docstrip" which I don't yet know). Should they all be installed into the xymtex binary package, or only the .sty's? 3) Since the .sty files are autogenerated, should I be trying to re-generate them before installing them? Upstream source doesn't have a Makefile or anything, so it isn't immediately obvious to me how to do so. 4) On a similar note, upstream includes .tex, .dvi, and .pdf files of XyMTeX documentation. Should I be re-generating the DVIs and PDFs? (I could have sworn there was a recent thread about this very subject on debian-mentors, but I can't find it, nor remember the conclusion.) Thanks in advance for helping to clear up my confusion! -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sources with missing dependencies
Michelle Konzack wrote: > dpkg-buildpackage ... > 8< > > and now it stops, because missing build dependencies. > > Now two quesions: > > 1) What should I do in such situation? > > Write a BUG report against the package ? Yes, please file a bug against the package with severity "grave". If the package can be built on sid, but not on sarge, then also tag the bug "sarge". Which package, by the way? > 2) How does buildd handel such situation? If a package can't be compiled on the buildd then usually the package maintainer will get an FTBFS bug filed by the buildd maintainer. In some corner cases, it's possible that a package will compile on a buildd but not with "apt-get build-dep" etc., because sbuild (the core buildd program) has an implementation of dependencies different from APT's. It's also possible that a package will compile in sid but not in sarge, because the sarge testing scripts don't check build-deps. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Splitting package
Shachar Shemesh wrote:
Benjamin Cutler wrote:
The debian/control file should look something like:
Package: foo-common
Conflicts: foo (<< 7.6.5-2)
Replaces: foo (<< 7.6.5-2)
Why the "Replaces"? I would have expected that would only be necessary if there
> was no longer any "foo" package.
The "Replaces" is necessary to ensure smooth upgrades. When one
upgrades from foo 7.6.5-1 to foo + foo-common 7.6.5-2, APT may install
the new foo-common before upgrading foo, and discover that foo-common
overwrites a file in the old foo package. This would cause an error
without the "Replaces" line. ("Replaces" means that the replacing
package may overwrite files in the replaced package; it doesn't
necessarily mean that one package is a replacement as a whole for the
other.)
(And don't forget to have the new "foo" Depend upon foo-common!)
regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Including object (.o) files in a package - linda errors
On 03/25/2005 10:41 AM, Kevin B. McCarty wrote:
> Justin Pryzby wrote:
>>lin{da,tian} shouldn't complain about an object file which is not
>>linked with anything, since, well, it cannot be.
>
> OK, I will file a bug against linda then. (any objections?)
Filed at http://bugs.debian.org/301392 .
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Including object (.o) files in a package - linda errors
Hi Justin,
Justin Pryzby wrote:
> I was hoping that someone else would respond to this, since I'm just
> fumbling for an answer. Maybe I can provoke one:)
>
> On Fri, Mar 18, 2005 at 12:02:34PM -0500, Kevin B. McCarty wrote:
>> > arcturus[6]:~/Debian/mn-fit% linda -i mn-fit-dev_5.05-1_powerpc.deb
>> > E: mn-fit-dev; Object /usr/lib/mn-fit/obj/programs/mn_main_k.o is not
>> > directly linked against libc.
>> > The binary object shown above is not directly linked against the
>> > required library libc.so.6.
>> > W: mn-fit-dev; Shared binary object
>> > /usr/lib/mn-fit/obj/programs/mn_main_k.o has no dependancy information.
>> > The binary object listed above is a shared object, but does not report
>> > that it depends on any other shared libraries.
> But, rethinking this, what kind of file is that (as given by
> /usr/bin/file)? AFAIK object files (traditionally *.o) cannot be
> linked with anything; indeed, gcc -lfoo -c -o bar.o baz.c yields:
>
> gcc: -lc: linker input file unused because linking not done
Yep, it's just a normal object file, originally compiled with something
like "g77 -c -o mn_main_k.o mn_main_k.f". The intent of the author is
to let people build in their own functionality to the program (mn_fit)
by linking this object file, the mn_fit static libraries, and their own
custom code into a custom executable.
In principle I guess there is no reason I can't include the source code
mn_main_k.f into the mn-fit-dev package, instead of the object file, and
make sure it gets built correctly when the user wants to compile. Maybe
I'll do that in the next upload as the easiest way to get around the
whole issue.
> lin{da,tian} shouldn't complain about an object file which is not
> linked with anything, since, well, it cannot be.
OK, I will file a bug against linda then. (any objections?)
[I snipped the rest of your analysis which maybe isn't relevant to this
specific case, but it looks like helpful advice in general.]
> If it is a shared object, and it actually doesn't use any external
> symbols (including those from libc), then I suppose an override is
> appropriate. (Let me guess; some awkward physics software whose
> authors decided to rewrite everything from the ground up using only
> loops and arithmetic? sigh.)
Almost as bad: it's based on Cernlib so it's likely completely br0ken on
64-bit. I could probably get around the FTBFSes on alpha and ia64, but
the resulting binary probably wouldn't work anyway, so I won't try
before the Sarge release. :-(
regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with package restricted to specific arches
Hi, Richard C Bilson wrote: > I maintan a source package, u++, which builds two packages: u++, which > is arch-specific, and u++-doc, which is arch-indep. The u++ binary > package can only be built on certain Debian architectures. > > The problem is that now I have a bug based on the fact that building > the arch-specific package fails on the other, unsupported, > architectures. I've tried three or four different solutions, and > nothing helps. Currently, I've conditionalized my binary-arch target > so that it does nothing on an unsupported arch, but then genchanges > dies when it finds that nothing was built. In addition to explicitly listing the set of supported architectures in debian/control, you must also get your package listed in the Packages-arch-specific file used by the buildds. Here's a HOWTO I found after a quick Google search: http://www.wolffelaar.nl/~jeroen/P-a-s-HOWTO.txt The P-a-s maintainers mentioned in that file include LaMont Jones <[EMAIL PROTECTED]> and James Troup <[EMAIL PROTECTED]> among others. -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Including object (.o) files in a package - linda errors
Hi list, I am packaging mn_fit (source package is named mn-fit; currently stuck in NEW). Upstream tells me that the capability exists for users to create a customized version of mn_fit by linking their own Fortran source code with mn_fit static libraries and the mn_fit main object file, mn_main_k.o. So I am creating a new mn-fit-dev binary package to contain these libraries, etc. (Thus, users who don't need to customize mn_fit can just install the mn-fit binary package, without the additional 3 Mb of static libs in mn-fit-dev.) The problem is that linda really doesn't like the object file: > arcturus[6]:~/Debian/mn-fit% linda -i mn-fit-dev_5.05-1_powerpc.deb > E: mn-fit-dev; Object /usr/lib/mn-fit/obj/programs/mn_main_k.o is not > directly linked against libc. > The binary object shown above is not directly linked against the > required library libc.so.6. > W: mn-fit-dev; Shared binary object /usr/lib/mn-fit/obj/programs/mn_main_k.o > has no dependancy information. > The binary object listed above is a shared object, but does not report > that it depends on any other shared libraries. What can I do about this? I found that linda gives the same complaints about libcrt1.o (and other object files) in the libc6-dev package. (Lintian doesn't care.) Should I just add linda overrides to ignore the error and warning? thanks in advance, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failure on sparc
Tommaso Moroni wrote: > Looking at the buildd logs[1] I found this: > > [snip] > checking for vsnprintf... yes > checking for snprintf... yes > checking for X... configure: error: Can't find X libraries. Please check your > installation and add the correct paths! > make: *** [config.status] Error 1 > ** > Build finished at 20050309-0500 > FAILED [dpkg-buildpackage died] > [snip] > [1] > http://buildd.debian.org/fetch.php?&pkg=knights&ver=0.6-1&arch=sparc&stamp=1110363729&file=log&as=raw Looking at the configure script in your package, it appears to check for Xos.h (line 20472) and libXt (line 20350) to decide whether the X libs are present. So, add "x-dev | xlibs-dev, libxt-dev | xlibs-dev" to your Build-Depends. Hopefully the indirect dependencies of kdelibs4-dev take care of everything else. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help: debian packaging
Charles Majola wrote: > I need help with this: how do I add configuration files to a debian package. > I want to add files to /etc/package-name/config.d > The package already creates the folder but not configuration files. Hi, Assuming you are using debhelper, you add a call to dh_install somewhere in the appropriate install target of your debian/rules. You also have a file debian/install (or for multiple binary packages created from the same source package, debian/.install) whose contents look like this, for instance: debian/debian.conf debian//etc//config.d src/config/default.conf debian//etc//config.d The first entry on each line gives the file to install, relative to the source directory, and the second entry gives the directory to install it to (obviously, replace with the name of your binary package). If you are using a debhelper compat level of 3 or greater, the files will automatically be marked as conffiles since they are installed to /etc. For more details, see dh_install(1) and debhelper(7). regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Found a sponsor [was: Re: RFS: wmakerconf 2.11-1, wmakerconf-data 0.90.0.0-1]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/2005 02:25 PM, Kevin B. McCarty wrote: > My usual sponsor for wmakerconf and wmakerconf-data, Nicolas Boullis, > has lately had only intermittent connectivity to the Internet. Would > someone therefore be willing to sponsor these two source packages for > me, just this one time? It would be nice to get them into testing ASAP, > since I've finally ported wmakerconf to GTK+ 2, and the new version > fixes a number of incompatibilities with Window Maker 0.91. Anibal Monsalve Salazar has kindly offered to sponsor these two packages. - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJkY7fYxAIk+Dx1ERAvVMAKC1nbmf2MrS5Gp0DEH55KUmm+ryIQCggjF8 oDTaoDhKDzdQQimqJzZm4GY= =Lcoi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: wmakerconf 2.11-1, wmakerconf-data 0.90.0.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear debian-mentors, My usual sponsor for wmakerconf and wmakerconf-data, Nicolas Boullis, has lately had only intermittent connectivity to the Internet. Would someone therefore be willing to sponsor these two source packages for me, just this one time? It would be nice to get them into testing ASAP, since I've finally ported wmakerconf to GTK+ 2, and the new version fixes a number of incompatibilities with Window Maker 0.91. You can get source code for them by adding the following line to /etc/apt/sources.list deb-src http://borex.princeton.edu/~kmccarty/ unstable main and running "apt-get update; apt-get source wmakerconf wmakerconf-data". Regarding the potential questions of a) why there are separate source packages for the program and its data, and b) why wmakerconf-data has such a weird upstream number: it's a long story, but I plan to fix these issues after the sarge release. For completeness, here are the package descriptions. wmakerconf: > Description: GTK+ based configuration tool for Window Maker > Interactive graphical configuration utility for Window Maker. It > permits configuration of Window Maker using a mouse driven point and > click interface, avoiding direct manual editing of its configuration > files. > . > There is not much point in installing this program without > Window Maker on the system, but this package doesn't depend on the > wmaker package so it may be used with, for example, self-compiled > installations of Window Maker. wmakerconf-data: > Description: Data files for wmakerconf, a configuration tool for Window Maker > This contains the necessary information that enables wmakerconf to generate > a configuration file for Window Maker. In normal circumstances, you > only have to change this package in order to be able to configure a new > version of Window Maker. This package is useless without wmakerconf and > an appropriate version of Window Maker. thanks and regards, - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJhMZfYxAIk+Dx1ERApV6AKCfErRNzcOrV63MFPBW5dXd3wkg2gCeLxT0 awp2b4pEhhURkTp9YiNgOBA= =hS9s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for an advocate
Shachar Shemesh wrote: > There is a document on the site, though I couldn't find it the last > five times I looked for it, explaining a step-by-step in creating a > deb. This one should be the first one up there. And if you find it, > do send me a link. I don't think I need it any more (my package is in > sid's main queue), but you never know. If I remember it correctly, it > even explains the sponsors and debian-mentors process. Hi Shachar, I believe you are looking for one or both of the following: - the New Maintainer's Guide, available at http://www.nl.debian.org/doc/devel-manuals#maint-guide or in the Debian package "maint-guide" - the debian-mentors FAQ at http://people.debian.org/~mpalmer/debian-mentors_FAQ.html I hope this helps! regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bookmarkbridge
Hello, Masami Ichikawa wrote: > I edited control file, changelog and rebuild. > > Re-Upload here. > http://moonlinux.sourceforge.jp/debian/ In your debian/rules file, delete all the commented out debhelper commands like "# dh_perl" -- there's no reason to keep these lines. In your man page, you could be more descriptive of what some of the options do -- I can't figure out all of them. Particularly, I don't understand the line for the "-r" flag. In debian/control and in the man page, change this: bookmarkbridge is supports these browser. Internet Explorer [...] Konqueror. to read something like this: BookmarkBridge supports the Internet Explorer, Opera, Mozilla Navigator, Mozilla Firefox, and Konqueror browsers. Be aware that you can email debian-l10n-english@lists.debian.org if you would like any help with English phrasing. As a nit-pick, the hyphen "-" in your man page at the beginning of the OPTIONS section needs to be \escaped. Finally, as suggested by fEnIo, you might want to add a line to debian/control like this: Suggests: mozilla-browser | mozilla-firefox | konqueror This looks like a useful package. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New to the packaging thing... :)
Sven Mueller wrote: > 3) debian/control: Current Standards-Version is 3.6.1.1, you should >state that version in there (and follow it, obviously). A slight nitpick: the fourth number in the Standards-Version basically is a revision for typographical and packaging fixes, so it is fine to specify a Standards-Version of 3.6.1 as Jose did. (cite: debian-policy 5.6.10) regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reporting lintian and linda overrides
Jereme Corrado wrote: > I was thinking about an override, (linda complains) and my sponsor > pointed out that he thought he recalled that overrides should be > reported. I wasn't able to find any mention of this so I was hoping > for some insight from the list. The lintian documentation in section 2.4 covers this, although I don't think it is mentioned in any linda docs. The docs give three cases: lintian (or linda) has a bug; lintian isn't smart enough to figure out that the reported error/warning is a special case allowed by policy; or policy in general allows exceptions to a rule checked by lintian. It looks like you probably fall under case 2. In the first case, file a bug against lintian/linda; in the second/third cases, one "should contact the Lintian maintainers too, including the Lintian error message and a short note, stating why you think this is an exception." For what it's worth, I am a horrible person and haven't reported any of the overrides I've put in my packages to stop lintian from giving spurious warnings. :-) My overrides are trivial enough that I don't think they are worth wasting the lintian maintainers' time. Hmm, on a second look maybe I will report the one for viewglob. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: renaming a library package (advice and sanity check)
Santiago Vila wrote: > On Fri, 14 Jan 2005, Jay Berkenbilt wrote: > >> I've read Section 5.9.3 of the developer's reference and understand it >> clearly. Is that still the best way to go? > > Not always, unfortunately. Very often, the upgrade will be smoother if > you use empty dummy packages wisely. It's a pity that developer's > reference does not mention dummy packages. Actually it does mention them (calling them "transition packages") in section 6.7.7. It's too bad section 5.9.3 doesn't cross-reference it. > For example, you can create a dummy (empty) libvips7.10-doc which > depends on libvips-doc and has section: oldlibs. Then libvips-doc does > not need to conflict with every version of libvips7.10-doc, only with > the non-dummy versions. To Jay: This is good advice and I second it. To assure smooth upgrades, remember to have libvips-doc Replace the non-dummy versions of libvips7.10-doc as well as Conflicting against them. Good luck with having the section changed from doc to oldlibs in the override file; I had great difficulty getting this to happen when converting some binary packages of Cernlib to dummy packages. > This way, "apt-get upgrade" will install libvips-doc without requiring > "apt-get dist-upgrade", and this will be done automatically and > without user intervention, Are you certain of that? My understanding is that apt-get upgrade will neither remove current packages nor install new ones, only upgrade packages that can otherwise be upgraded. So "apt-get upgrade" will just output something like "libvips7.10-doc is being held back" -- it will not upgrade libvips7.10-doc to the dummy package nor will it install the new libvips-doc package. "apt-get dist-upgrade" would still be required for that. Unless "apt-get upgrade" has special handling for dummy packages that I'm not aware of? regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem creating mn-fit watch file (packaging comments also welcome)
Justin Pryzby wrote: > Does this do what you want? See bug #282255: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282255 Yes, thanks, that looks perfect. I second this wishlist bug patch :-) Ideally, it could even be more general, to permit arbitrary transformations of the filename in order to derive a version number before the comparison to the local version. But maybe there wouldn't be much call for that. For people reading emails to bug # 282255: refer here for context: http://lists.debian.org/debian-mentors/2005/01/msg00133.html regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem creating mn-fit watch file (packaging comments also welcome)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've ITP'ed Mn_Fit, an interactive fitting and analysis program (bug # 288959), and I have most of the packaging finished. I could use some help figuring out an appropriate watch file because the tar files on the Mn_Fit web site are named in a kind of strange way. Specifically, for version 5.03, the file is named mn_fit_v5_03.tar.gz -- there is an underscore in the version number that needs to be replaced with a period when comparing versions. So far I have something like: version=2 http://www-zeus.physik.uni-bonn.de/~brock/mn_fit/tar/ \ mn_fit_v([0-9_]*)\.tar\.gz debian uupdate Running uscan --verbose --no-download outputs: > -- Scanning for watchfiles in . > -- Found watchfile in ./debian > -- In ./debian/watch, processing watchfile line: >http://www-zeus.physik.uni-bonn.de/~brock/mn_fit/tar/ > mn_fit_v([0-9_]*)\.tar\.gz debian uupdate > -- Found the following matching hrefs: > mn_fit_v5_03.tar.gz > mn_fit_v5_01.tar.gz > Newest version on remote site is 5_03, local version is 5.03 > => mn_fit_v5_03.tar.gz already in package directory > -- Scan finished If anyone wants to take the further step of looking at my packaging, that would be appreciated too. :-) It can be found at deb-src http://borex.princeton.edu/~kmccarty/ unstable main apt-get source mn-fit Please note that I'm waiting on the upstream author to get back to me about a LaTeX .cls file missing from the source; until that happens, the mn-fit-doc binary package won't be generated correctly. Also I am planning on converting the source package to use dpatch before looking for a sponsor. CC-ing this message to Joerg Jaspert, my AM, in case he wants to make any comments. (Hi Joerg!) - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3/VxfYxAIk+Dx1ERAh9CAJ4jC2ZKFVU52wjpq1GHP8PQN42OUQCfTNpg CgLN73NzdSGuHfCLKxRa3sU= =S4/Y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CERN root
Hi Ricardo, Sorry for the long delay in replying, I was without email access over Christmas break. On 12/20/2004 11:01 PM, Ricardo Yanez wrote: > This is not the first time we read each other. To answer your > question... yes, I started with the scripts you mention to create the > debian directory (archaic if you believe the revision logs). As you say, > they are non-working. To make the story short, the --enable-pthread > option had to be removed because it prevented us from compiling within > root (cint) the data reading and analysis codes. I'm guessing a conflict > between the pthread dev files included in the root source and the one > part of the debian system. Interesting. One other thing I thought of in the meantime is the question of the library ABI backwards compatibility. Are the ROOT authors aware of the importance of preserving library ABI compatibility, and especially the difficulty in doing so when using C++? The shared libraries they create don't have any version numbering, so I'm a little leery here... Does it make more sense to have the ROOT shared libs be in a separate directory /usr/lib/root, or dump them into /usr/lib with everything else? If the libraries have an ABI that constantly changes incompatibly, it would be best to have them separate, but then you have to make special provisions ($LD_LIBRARY_PATH or whatever) for linked binaries. Plus you still have to recompile linked binaries with every new incompatible version of ROOT... I don't know the answer to these questions myself, but they'll be important things to consider in packaging ROOT, even if only for a small private set of users due to the licensing issues. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CERN root
Ricardo Yanez wrote: > I have packaged CERN's root (an object oriented data analysis > framework) for our internal distribution. ROOT is widely used in nuclear > and particle physics labs, groups, etc. Since root is becoming the > standard, substituting PAW which is distributed by Debian, I thought to > seek a sponsor for this software, learn more about packaging, and help > my fellow physicist around the world. Hi Ricardo, I guess it's been mentioned that there are serious licensing issues a package of Root would have to surmount. On a different note, though, I was just wondering if you had checked into the Debian packaging already present in Root. There are scripts in root/build/package/lib that create a debian directory, although I seem to remember them being unsupported or non-working; if you haven't already, you may want to take a look at them. Maybe they could be fixed and sent upstream. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CERN root
Bas Zoetekouw wrote: > You wrote: > >> The license is at http://root.cern.ch/root/License.html. I'm assuming the >> specific cause of concern is: >> >> "Additionally, the authors grant permission to modify this software and its >> documentation for any purpose, provided that such modifications are not >> distributed without the explicit consent of the authors" > > Even worse, it apparently links against Xclass (LGPL) and Cernlib (GPL) > libraries[1], while the above license it clearly GPL- (and possibly(?) LGPL-) > incompatible. Theredore, it cannot even be legally distributed. > > [1] http://www.princeton.edu/~kmccarty/physics-software-rant.html Just a nitpick -- I'm the author of the referenced page, so maybe this is my own fault for being unclear. The situation is even a bit worse than this: Root doesn't just link against Xclass or Cernlib, it actually *includes derived code* from them. And it can't be trivially removed or rewritten -- Xclass-derived code provides the core of the GUI, and Cernlib-derived code (MINUIT) provides the core of the function fitter. -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared libraries
On 12/11/2004 10:21 AM, Justin Pryzby wrote: > Oh, yeah, and upstream creates a libc.a which is in the search path .. > for now I'm just removing it so that gcc doesn't screw up (shared > libraries are renamed, but static onese are not). Oh. My. God. Can you hit them with the clue stick? Is it supposed to replace the standard system libc, or are they just _really_ dumb about selecting library names? > Is there a way to reset the library search path? I would like to > specify gcc -L $IRAFroot (so that I use the just-compiled version of > the libraries, and not something that may be already in /usr/lib) > -lfoo (which XC will resolve to libiraf-foo) ... > --reset-library-search-path? > > If I could do that, then libc.a wouldn't be a problem. I suppose I > could just use gcc -L/usr/lib -L$IRAFroot..but that's pretty bad. Could you rename the libc.a to something else immediately after it's created, and link to it as needed? > By the way, what is /usr/lib/tls/, and why do all of my programs link > to its libc.so? I have no idea. Looking it up in packages.debian.org doesn't seem to produce any results. What does "dpkg -S /usr/lib/tls" say? Is it in your /etc/ld.so.conf? > Well, did you spend more than a week doing it? :-0 > Its worth it though; it cut the size of my architecture-dependent > package by a factor of 2. And I'm now a factor of *5* smaller than > what upstream distributes. Oh yes, quite a bit more than a week. But I agree it was worth the trouble. > It still doesn't completely work yet. Probably something about 30 > year old blobs of fortran.. I expect cernlib is the same? Yep, exactly. Got to love scientific code... ;-) -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared libraries
Justin Pryzby wrote: > How can I modify the path to the libraries? During compilation, the > build system has to see $buildpath/iraf/lib/libfoo.so.0, but once > installed, the executables must see > /usr/lib/iraf/iraf/lib/libfoo.so.0. There are a bunch of executables, > so I don't want to have to use a script to set LD_LIBRARY_PATH or > such. Maybe this isn't the best idea, but really you only need to write one script in /usr/bin, plus make a bunch of symlinks in /usr/bin to the script that have the same name as the real executables. Assuming your real executables go in /usr/lib/iraf/bin, the script would be #!/bin/sh PROGRAM=`basename $0` BASE_PATH=/usr/lib/iraf/bin export LD_LIBRARY_PATH=/usr/lib/iraf/iraf/lib exec $BASE_PATH/$PROGRAM "$@" # if we get here something went wrong echo "Couldn't run $BASE_PATH/$PROGRAM!" > /dev/stderr exit 1 I guess the script could even go in /usr/share/iraf/bin so as not to clutter the /usr/bin namespace. Probably this method is only good for a last resort, as it's kind of hackish. Alternative solutions would be to put the shared libs in /usr/lib, or else to add the IRAF shared lib directory to /etc/ld.so.conf ... By the way, congrats on getting IRAF to build shared libs -- I hope it wasn't as much of a pain in the @$$ as I found it was for cernlib. -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: viewglob (new version 1.0.2-1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm requesting a sponsor to upload version 1.0.2-1 of viewglob. Source packages, including the orig.tar.gz, can be found here using apt: deb-src http://borex.princeton.edu/~kmccarty/ unstable main or here by direct HTTP: http://borex.princeton.edu/~kmccarty/dists/unstable/main/source/ The .dsc is signed with my GPG key (ID is in the .sig below). Package is lintian-clean, and has already been sponsored several times by Michael Schiansky, who is now spending time away from Debian writing a thesis. The package is pretty easy to maintain; package description follows: > Description: A graphical display of directories referenced at the shell prompt > Viewglob complements the Unix shell by presenting a graphical display > showing the contents of directories referenced on the command line, > including the current directory. The display also shows results of file > globs and expansions as they are typed, with selected files and possible > name completions highlighted. > . > Viewglob currently supports bash and zsh. It should work with any > X-based terminal emulator (xterm, gnome-terminal, konsole, etc.). > . > Homepage: http://viewglob.sourceforge.net/index.html Thanks to any takers, - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrMVafYxAIk+Dx1ERAoglAJsG+KanIut0dITaQXnXDzdQ9NIBiwCfZDEZ /3nTWIRmVAcWaQEou9GICXs= =yvsb -END PGP SIGNATURE-
RFS: viewglob (new version 1.0.2-1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm requesting a sponsor to upload version 1.0.2-1 of viewglob. Source packages, including the orig.tar.gz, can be found here using apt: deb-src http://borex.princeton.edu/~kmccarty/ unstable main or here by direct HTTP: http://borex.princeton.edu/~kmccarty/dists/unstable/main/source/ The .dsc is signed with my GPG key (ID is in the .sig below). Package is lintian-clean, and has already been sponsored several times by Michael Schiansky, who is now spending time away from Debian writing a thesis. The package is pretty easy to maintain; package description follows: > Description: A graphical display of directories referenced at the shell prompt > Viewglob complements the Unix shell by presenting a graphical display > showing the contents of directories referenced on the command line, > including the current directory. The display also shows results of file > globs and expansions as they are typed, with selected files and possible > name completions highlighted. > . > Viewglob currently supports bash and zsh. It should work with any > X-based terminal emulator (xterm, gnome-terminal, konsole, etc.). > . > Homepage: http://viewglob.sourceforge.net/index.html Thanks to any takers, - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrMVafYxAIk+Dx1ERAoglAJsG+KanIut0dITaQXnXDzdQ9NIBiwCfZDEZ /3nTWIRmVAcWaQEou9GICXs= =yvsb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob [revised]
I have added the viewglob.desktop file provided by Stefan Fritsch for a konsole session, and fixed all the compiler warnings. The new package is at the same location as before. Any takers for sponsoring viewglob? deb-src http://borex.princeton.edu/~kmccarty/ unstable main apt-get update apt-get source viewglob regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Re: RFS schoolbell - A calenaring server for schools
Matthew Palmer wrote: > I just had another thought -- make a -1 revision with an empty diff. Weird, > but I can't think of any reason why it wouldn't work... Why would the diff be empty? I would think it should contain the debian subdir in any case. It makes no sense to ship a debian directory in generic source code released for RedHat, Windows, etc. (it would just uselessly increase the tarball size) so it might as well go into the Debian-specific diff.gz. Even as both upstream and maintainer, you (Brian Sutherland) might find it useful to keep Debian packaging stuff separate from the main body of code. Then if there is a bug in debian/rules, or Debian Policy is updated to mandate some new control field, you don't have to release an entirely new tarball just to fix a Debian-specific issue. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi Stefan, You wrote: > that's a nice little program. Just one suggestion: > Add a viewglob session type to the KDE konsole by including the > file /usr/share/apps/konsole/viewglob.desktop OK, I'll go ahead and add it. Have you tested it? I don't use KDE so can't do so myself. It will be a little while before I put up a new source package, since I'm waiting to hear back from upstream about a possibly problematic compiler warning. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Re: RFS: viewglob [revised]
I have added the viewglob.desktop file provided by Stefan Fritsch for a konsole session, and fixed all the compiler warnings. The new package is at the same location as before. Any takers for sponsoring viewglob? deb-src http://borex.princeton.edu/~kmccarty/ unstable main apt-get update apt-get source viewglob regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS schoolbell - A calenaring server for schools
Matthew Palmer wrote: > I just had another thought -- make a -1 revision with an empty diff. Weird, > but I can't think of any reason why it wouldn't work... Why would the diff be empty? I would think it should contain the debian subdir in any case. It makes no sense to ship a debian directory in generic source code released for RedHat, Windows, etc. (it would just uselessly increase the tarball size) so it might as well go into the Debian-specific diff.gz. Even as both upstream and maintainer, you (Brian Sutherland) might find it useful to keep Debian packaging stuff separate from the main body of code. Then if there is a bug in debian/rules, or Debian Policy is updated to mandate some new control field, you don't have to release an entirely new tarball just to fix a Debian-specific issue. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi Stefan, You wrote: > that's a nice little program. Just one suggestion: > Add a viewglob session type to the KDE konsole by including the > file /usr/share/apps/konsole/viewglob.desktop OK, I'll go ahead and add it. Have you tested it? I don't use KDE so can't do so myself. It will be a little while before I put up a new source package, since I'm waiting to hear back from upstream about a possibly problematic compiler warning. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi all, I am seeking a sponsor for viewglob. The ITP is at http://bugs.debian.org/269445 and the home page is at http://viewglob.sourceforge.net/ . License is GPL plus a few BSD-licensed files. Description follows: Viewglob complements the Unix shell by presenting a graphical display showing the contents of directories referenced on the command line, including the current directory. The display also shows results of file globs and expansions as they are typed, with selected files and possible name completions highlighted. Viewglob currently only supports the Bourne-Again Shell (bash), although zsh support is planned for the future. It should work with any X-based terminal emulator (xterm, gnome-terminal, konsole, etc.). The package is lintian- and linda-clean except for two false positives. There is a lintian error "shell-script-fails-syntax-check", which is due to the lintian check being made without bash's extglob option turned on; I have added a lintian override for this. The other false positive is a warning that x-terminal-emulator is in the menu file but not contained in the package. Debianized source code can be obtained here: deb-src http://borex.princeton.edu/~kmccarty/ unstable main (apt-get source viewglob) or downloaded directly from: http://borex.princeton.edu/~kmccarty/dists/sid/main/source/viewglob_0.8.4.orig.tar.gz http://borex.princeton.edu/~kmccarty/dists/sid/main/source/viewglob_0.8.4-1.diff.gz http://borex.princeton.edu/~kmccarty/dists/sid/main/source/viewglob_0.8.4-1.dsc regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi all, I am seeking a sponsor for viewglob. The ITP is at http://bugs.debian.org/269445 and the home page is at http://viewglob.sourceforge.net/ . License is GPL plus a few BSD-licensed files. Description follows: Viewglob complements the Unix shell by presenting a graphical display showing the contents of directories referenced on the command line, including the current directory. The display also shows results of file globs and expansions as they are typed, with selected files and possible name completions highlighted. Viewglob currently only supports the Bourne-Again Shell (bash), although zsh support is planned for the future. It should work with any X-based terminal emulator (xterm, gnome-terminal, konsole, etc.). The package is lintian- and linda-clean except for two false positives. There is a lintian error "shell-script-fails-syntax-check", which is due to the lintian check being made without bash's extglob option turned on; I have added a lintian override for this. The other false positive is a warning that x-terminal-emulator is in the menu file but not contained in the package. Debianized source code can be obtained here: deb-src http://borex.princeton.edu/~kmccarty/ unstable main (apt-get source viewglob) or downloaded directly from: http://borex.princeton.edu/~kmccarty/dists/sid/main/source/viewglob_0.8.4.orig.tar.gz http://borex.princeton.edu/~kmccarty/dists/sid/main/source/viewglob_0.8.4-1.diff.gz http://borex.princeton.edu/~kmccarty/dists/sid/main/source/viewglob_0.8.4-1.dsc regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Excluding some architectures
On Wed, 23 Jun 2004, Frank Lichtenheld wrote: > > I think there are two other things to fix: changing some master list used > > by buildds of which packages to compile or not, and removal of existing > > 64-bit cernlib packages from the archive. Who should I contact for each > > of these? > > The list is > http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup > > Further instructions are included there. Thank you, I've followed them. By the way (just out of curiosity), why is such a list necessary when it just duplicates information already in packages' control files? regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
Re: Excluding some architectures
On Wed, 23 Jun 2004, Frank Lichtenheld wrote: > > I think there are two other things to fix: changing some master list used > > by buildds of which packages to compile or not, and removal of existing > > 64-bit cernlib packages from the archive. Who should I contact for each > > of these? > > The list is > http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup > > Further instructions are included there. Thank you, I've followed them. By the way (just out of curiosity), why is such a list necessary when it just duplicates information already in packages' control files? regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Excluding some architectures
Hi all, I'm coming to the conclusion that cernlib can't be ported to 64-bit architectures without a great deal of work, and I am not sure that it will be finished before Sarge is released. I would prefer having no version of Cernlib available on 64-bit arches in Sarge, as opposed to a completely broken version. My understanding is that in debian/control I need to change "Architecture: any" to the specific list of supported arches, something like "Architecture: i386 m68k sparc s390 hppa mips mipsel powerpc arm" correct? I think there are two other things to fix: changing some master list used by buildds of which packages to compile or not, and removal of existing 64-bit cernlib packages from the archive. Who should I contact for each of these? And how to keep 64-bit arches from seeing the "Architecture: all" Cernlib binary packages? Thanks, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
Excluding some architectures
Hi all, I'm coming to the conclusion that cernlib can't be ported to 64-bit architectures without a great deal of work, and I am not sure that it will be finished before Sarge is released. I would prefer having no version of Cernlib available on 64-bit arches in Sarge, as opposed to a completely broken version. My understanding is that in debian/control I need to change "Architecture: any" to the specific list of supported arches, something like "Architecture: i386 m68k sparc s390 hppa mips mipsel powerpc arm" correct? I think there are two other things to fix: changing some master list used by buildds of which packages to compile or not, and removal of existing 64-bit cernlib packages from the archive. Who should I contact for each of these? And how to keep 64-bit arches from seeing the "Architecture: all" Cernlib binary packages? Thanks, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Size of int vs. long vs. void * vs. Fortran INTEGER
On 06/17/2004 08:34 PM, Goswin von Brederlow wrote: > Normaly thats what your configure script is for. > > Or just use and then int32_t, int64_t, intptr_t, Unfortunately Cernlib was largely written in the 1970's and 80's long before configure scripts came about... It uses Imake. Also, most of it is in Fortran, and the authors apparently never considered the possibility that sizeof(void *) might one day be bigger than sizeof(int) on some machines; they do all kinds of horrible conversions between C pointers, C ints, Fortran INTEGERs, REALs, etc. Anyway, the reason I asked was that I want to know what I can change (e.g. int -> long) to fix things on 64-bit without breaking library ABI compatibility on 32-bit machines. (On 64-bit, breaking library compatibility doesn't matter so much since most of the libs just segfault right now.) -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
Re: Size of int vs. long vs. void * vs. Fortran INTEGER
On 06/17/2004 08:34 PM, Goswin von Brederlow wrote: > Normaly thats what your configure script is for. > > Or just use and then int32_t, int64_t, intptr_t, Unfortunately Cernlib was largely written in the 1970's and 80's long before configure scripts came about... It uses Imake. Also, most of it is in Fortran, and the authors apparently never considered the possibility that sizeof(void *) might one day be bigger than sizeof(int) on some machines; they do all kinds of horrible conversions between C pointers, C ints, Fortran INTEGERs, REALs, etc. Anyway, the reason I asked was that I want to know what I can change (e.g. int -> long) to fix things on 64-bit without breaking library ABI compatibility on 32-bit machines. (On 64-bit, breaking library compatibility doesn't matter so much since most of the libs just segfault right now.) -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Size of int vs. long vs. void * vs. Fortran INTEGER
Hi all, I am embarking on the ambitious project of getting Cernlib to work on 64-bit arches, thanks to Mattias Wadenstein graciously giving me an account on his AMD64. I have some questions about type sizes. Please answer only with respect to the GNU/Linux architectures supported by Debian, and the gcc/g77 compilers. (I.e., if Joe's custom-built one-of-a-kind chip design running "joecc" is a counterexample, I don't care.) 1) Is it true that sizeof(long) == sizeof(void *) on all arches? 2) Is it true that sizeof(int) == sizeof(Fortran INTEGER), when the precision or KIND of INTEGER is not specified, on all arches? 3) Is it true that sizeof(int) == sizeof(long), on all *32-bit* arches? 4) Is it true that sizeof(int) < sizeof(long), on all *64-bit* arches? Thanks in advance for responses, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
Size of int vs. long vs. void * vs. Fortran INTEGER
Hi all, I am embarking on the ambitious project of getting Cernlib to work on 64-bit arches, thanks to Mattias Wadenstein graciously giving me an account on his AMD64. I have some questions about type sizes. Please answer only with respect to the GNU/Linux architectures supported by Debian, and the gcc/g77 compilers. (I.e., if Joe's custom-built one-of-a-kind chip design running "joecc" is a counterexample, I don't care.) 1) Is it true that sizeof(long) == sizeof(void *) on all arches? 2) Is it true that sizeof(int) == sizeof(Fortran INTEGER), when the precision or KIND of INTEGER is not specified, on all arches? 3) Is it true that sizeof(int) == sizeof(long), on all *32-bit* arches? 4) Is it true that sizeof(int) < sizeof(long), on all *64-bit* arches? Thanks in advance for responses, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: wmakerconf, wmakerconf-data, comparator
Please disregard these messages, my original sponsor has gotten back in contact with me. -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
Re: RFS: wmakerconf, wmakerconf-data, comparator
Please disregard these messages, my original sponsor has gotten back in contact with me. -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: wmakerconf, wmakerconf-data, comparator
On Tue, 6 Jan 2004, Kevin B. McCarty wrote: > I am looking for a sponsor for the three source packages wmakerconf > [2.9-3], wmakerconf-data [0.80.0-2], and comparator [2.2-1] (each produces > one binary package of the same name). The first two are upgrades (the > first closes a priority Important bug) and the third closes an ITP. FWIW, wmakerconf and wmakerconf-data are ranked #82 and #83 by "Vote" in the x11 section by the popularity-contest results [1] (out of 613 packages, that puts them at the 87th percentile). A lot of people would benefit if someone could sponsor these packages [2], even just for one upload. [1] http://people.debian.org/~apenwarr/popcon/results.x11.html [2] deb-src http://borex.princeton.edu/~kmccarty/ unstable main regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
