Re: packaging guide questions
Hi,
adding debian-mentors, you may get a lot more response there to your question.
At Sat, 30 May 2009 01:39:00 +0100,
Stanisław Pitucha wrote:
>
> Hi,
> I've got two questions I couldn't find answer to... (at least in the
> official guide). Could you answer them / point me at the correct
> mailing list?
>
> If there is a source package which generates: a common library
> everything else is linking against, 2 binaries, many plugins (common
> and specific):
>
> 1.
> Is there a way to make plugins depend on the specific verison of the
> program, but allow for minor corrections? I.e. if everything is in
> version 1.2.3 of the app, but some plugin needs a minor correction
> that doesn't require rebuilding main binary packages / the common
> library, then is there a way to set version dependencies in such way
> that the plugin can be updated separately?
I think you could use, for example, ${Source-Version} dependency here,
but I doubt it will always work (for example, you have to use
different notations for new incompatible compiler changes etc.)
and makes it harder for security fixes etc. to happen.
> 2.
> If it's highly unlikely anyone will ever use the common library
> without installing the binary programs, is there any reason to keep it
> separate? There has to be a -dev package, but creating something like:
> - prog-binary-A, prog-binary-B
> - libprog, prog-dev
> - prog-plugins, prog-plugin-mysql, prog-plugin-pgsql, ...
> seems like an overkill when prog-binary-... are the only packages that
> are going to use it (even if they're separate and independent). Should
> I pull libprog into the more common binary-A and make binary-B depend
> on it, or should it be split properly like described here?
I think you should split them out as per policy, but I need some
context here to understand why you are saying this.
--
dan...@{netfort.gr.jp,debian.org}
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: mecab-naist-jdic
At Wed, 25 Mar 2009 23:28:30 +0900,
Hideki Yamane wrote:
>
> On Mon, 23 Mar 2009 22:48:47 +0900
> Junichi Uekawa wrote:
> > > > It's less easy to maintain patches.
> > > > How do I patch a file inside that tarball?
> > >
> > > Okay, it's not easy to maintain patches. Yes.
> > > But upstream is quite friendly for us, Debian, and patches will be
> > > include at next release time. So we does not maintain so many patches
> > > for this package.
> >
> > You're not answering my question properly.
>
> But it's easy for "clean" target.
> What is the best way to deal with changes "autogen.sh" or "autoreconf -i"
> made? Could you tell me that, please?
You can read a lot of source packages which have that. They clean
files in clean: target.
If you are going to do something nonstandard, please make
README.source with how to use your source package, as documented in
policy.
4.14. Source package handling: `debian/README.source'
-
If running `dpkg-source -x' on a source package doesn't produce the
source of the package, ready for editing, and allow one to make
changes and run `dpkg-buildpackage' to produce a modified package
without taking any additional steps, creating a `debian/README.source'
documentation file is recommended. This file should explain how to do
all of the following:
regards,
junichi
--
dan...@{netfort.gr.jp,debian.org}
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: mecab-naist-jdic
At Mon, 23 Mar 2009 15:06:16 +0900, Hideki Yamane wrote: > > On Mon, 23 Mar 2009 08:28:46 +0900 > Junichi Uekawa wrote: > > It's less easy to maintain patches. > > How do I patch a file inside that tarball? > > Okay, it's not easy to maintain patches. Yes. > But upstream is quite friendly for us, Debian, and patches will be > include at next release time. So we does not maintain so many patches > for this package. You're not answering my question properly. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: mecab-naist-jdic
At Mon, 23 Mar 2009 07:11:24 +0900,
Hideki Yamane wrote:
>
> Hi (CCed to mecab-ipadic maintainer),
>
> On Mon, 23 Mar 2009 00:03:53 +0900
> Junichi Uekawa wrote:
> > > It can replace non-free dict package, so please, someone who want
> > > to make Debian more "free" OS, upload it to repository :)
> >
> > The packaging is weird, why do you have
> > mecab-naist-jdic-0.4.3-20080917.tar.gz inside the .orig.tar.gz ?
>
> I made it as same as mecab-ipadic, it's easy to do when cleaned.
> Is it so weird?
It's less easy to maintain patches.
How do I patch a file inside that tarball?
regards,
junichi
--
dan...@{netfort.gr.jp,debian.org}
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: mecab-naist-jdic
Hi, At Sun, 22 Mar 2009 07:33:09 +0900, Hideki Yamane wrote: > > On Sun, 22 Mar 2009 00:25:42 +0900 > Hideki Yamane wrote: > > I'm looking for a sponsor for mecab-naist-jdic package. > > It can replace non-free dict package, so please, someone who want > to make Debian more "free" OS, upload it to repository :) The packaging is weird, why do you have mecab-naist-jdic-0.4.3-20080917.tar.gz inside the .orig.tar.gz ? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: gnview
Hi,
Is it all GPLv2 ?
For example, this looks fishy:
sub genRandStr {
# http://orfeus.knmi.nl/pub/outgoing/chad/perl/randstr.perl より取得
At Sun, 22 Mar 2009 08:04:43 +0900,
Hideki Yamane wrote:
>
> Hi mentors,
>
> I'm looking for a sponsor gnview package.
>
> * Package name: gnview
> ITP: #471155
> Version: 0.8.13
> Upstream Author: Mitsutoshi Kiuchi
> * URL: http://gnview.sourceforge.jp/
> * License: GNU General Public License v2 (GPLv2)
> Section: net
> Language: Perl
> Description: 2ch browser that uses gikonavi's setting and log data
>gnview is gtk2-perl based 2ch browser. It uses "gikonavi"
> setting
>and logs, famous 2ch browser on Windows.
>.
>If you have gikonavi data, you can use it with gnview.
>
> It is similar to my JD package and kita2, RFSed by Hiroyuki Yamamoto,
> alternative "2ch browser" for people (diversity is good, isn't it? :)
>
> Upstream development is very active, good conditions.
> Now I put packages to upstream web site, sourceforge.jp (such as sf.net),
> but that's better if it is in Debian.
>
> It's lintian clean package, of course.
> You can get it from
> http://mentors.debian.net/debian/pool/main/g/gnview/gnview_0.8.13-1.dsc
>
> Please someone upload it to Official repository.
>
>
> --
> Regards,
>
> Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
> http://wiki.debian.org/HidekiYamane
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
Hi, At Sat, 17 Jan 2009 00:17:28 +0900, Hiroyuki Yamamoto wrote: > > Hi, > > Hiroyuki Yamamoto wrote: > >Junichi Uekawa wrote: > >> > At Wed, 31 Dec 2008 18:07:43 +0900, > >> > Hiroyuki Yamamoto wrote: > >>> >> Junichi Uekawa wrote: > >>>> >>> what's the error message when ja_JP.UTF-8 is not available? > >>> >> Hmm, no error message is available now. > >>> >> Tentatively, I described to README.Debian as follows: > >>> >> > >>> >> * Now Kita2 should be used under UTF-8 locale. > >>> >>Please generate to run "dpkg-reconfigure locales" and select > >>> >>"ja_JP.UTF-8". > >> > > >> > I think this is a bug; can you contact upstream to fix it? > > > >Yeah, I would try to contact him. > > No reply has been received from the upstream yet, > so, in order to warn, I introduced a new rapper as follows: > #!/bin/sh > if [ $(LC_ALL=ja_JP.UTF-8 locale charmap) != 'UTF-8' ]; > then > kdialog --title "Error" --error "Kita2 needs ja_JP.UTF-8 locale." > exit 1 > else > LANG=ja_JP.UTF-8 exec /usr/bin/ruby1.8 -C/usr/share/kita2 > /usr/share/kita2/kita.rb > exit 0 > fi > > > Here is the new package: > http://mentors.debian.net/debian/pool/main/k/kita2/kita2_1.90.4-1.dsc I think there was some concern about kde4 compatibility, did you address that ? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
At Mon, 29 Dec 2008 14:30:04 + (UTC), Sune Vuorela wrote: > > On 2008-12-29, Junichi Uekawa wrote: > >> It needs more work than just change the dependencies to make it work > >> with korundum4 > > > > Are we talking about a package which only exists in experimental > > replacing the version in sid? > > Yes. and the replacement is planned ASAP. > > > Let the version which works today with a sid version, and make it work > > with kde4 version when it's in unstable; does it sound reasonable? > > Well.. I think any work with the version that works with a sid version > today is a waste of time - and if no one is planning to actually port it > to kde4, someone will also have to, very soon, to ask for removal of it. > > So instead of adding a package to be removed soon after it is clear of > NEW, I suggest not adding it at all. So, it's been two weeks, is there a working kde4? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
Hi, At Wed, 31 Dec 2008 18:07:43 +0900, Hiroyuki Yamamoto wrote: > > Junichi Uekawa wrote: > > what's the error message when ja_JP.UTF-8 is not available? > > Hmm, no error message is available now. > Tentatively, I described to README.Debian as follows: > > * Now Kita2 should be used under UTF-8 locale. >Please generate to run "dpkg-reconfigure locales" and select >"ja_JP.UTF-8". > I think this is a bug; can you contact upstream to fix it? > Regards, > -- > Hiroyuki Yamamoto > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
Hi, what's the error message when ja_JP.UTF-8 is not available? At Wed, 31 Dec 2008 11:46:54 +0900, Hiroyuki Yamamoto wrote: > > Hi, > > Junichi Uekawa wrote: > > At Sun, 28 Dec 2008 05:34:46 +0900, > > Hiroyuki Yamamoto wrote: > >> I am looking for a sponsor for my package "kita2". > >> > >> * Package name: kita2 > >> ITP: #488488 > >> Version: 1.90.4-1 > >> Upstream Author: Hideki Ikemoto > >> * URL: http://kita.sourceforge.jp/ > >> * License: The MIT License > >> Section: net > >> Language: Ruby > >> Description: Ruby based 2ch client for KDE > >> Kita2 is useful to view "2ch-style Bulletin Board System" that use > >> "bbs.cgi" and "read.cgi", it is like that we use RSS reader to read > >> blogs. It helps you to read/write articles in such BBS. > >> . > >> 2ch-style BBS include > >> - 2 channel (http://www.2ch.net, largest BBS in Japan) > >> - Pink channel (http://www.bbspink.com/) > >> - Machi-BBS (http://www.machi.to/) > >> - Shitaraba (http://rentalbbs.livedoor.com/jbbs/) and so on. > >> > >> > >> It builds this binary package: > >> kita2 - Ruby based 2ch client for KDE > >> > >> The package appears to be lintian clean. > > > > > > I tested the package, and it doesn't seem to work well on my > > environment GNOME with LC_ALL=ja_JP.EUC-JP. > > Oh, I did not test on LANG=ja_JP.EUC-JP. > Well, here is the new package: > > http://mentors.debian.net/debian/pool/main/k/kita2/kita2_1.90.4-1.dsc > > > Regards, > -- > Hiroyuki Yamamoto > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
At Sun, 28 Dec 2008 12:25:24 + (UTC), Sune Vuorela wrote: > > On 2008-12-28, Hiroyuki Yamamoto wrote: > >>> How about kde4? > >> > >> KDE4 has nice ruby bindings, currently available in experimental. > > > > Oh, thanks. > > When kde4 has entered in sid, kita2 should depend on korundum4 package. > > http://packages.debian.org/experimental/korundum4 > > It needs more work than just change the dependencies to make it work > with korundum4 Are we talking about a package which only exists in experimental replacing the version in sid? Let the version which works today with a sid version, and make it work with kde4 version when it's in unstable; does it sound reasonable? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cowbuilder and --distribution experimental
Hi, > > > > Heh, I guess we have a different definition of 'properly'. > > > > > > > > pbuilder experimental usage assumes we can install everything from > > > > experimental and get done with it, but I assume there are some > > > > packages which don't go along with each other well. > > > > > > > > But that shouldn't make pbuilder work and cowbuilder not work. I'm > > > > confused. > > > > > > I have the same problem with pbuilder... apt prefers packages from > > > experimental over those from sid, while it should be the contrary, and > > > the dummy package for build-dependencies would make sure the build > > > dependencies are downloaded from experimental when needed (that's what > > > versioned dependencies are for, aren't they?). > > > > Have you tried using 'pbuilder-satisfydepends-experimental' ? (man > > pbuilderrc) > > Is pbuilder-satisfydepends-experimental being used when running pbuilder > create and pbuilder update ? There are two different things on this table we are talking about, to spell it out: 1. When you want to have a full experimental experience, where you want everything from experimental. -> use --distributiuon experimental. This can be broken since not everything in experimental goes along well together, although it would be nice if it did. 2. When you want to have a partial experimental experience, where you only have the necessary packages from experimental. -> use --distribution sid, and use pbuilder-satisfydepends-experimental regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cowbuilder and --distribution experimental
Hi, > > > > Heh, I guess we have a different definition of 'properly'. > > > > pbuilder experimental usage assumes we can install everything from > > experimental and get done with it, but I assume there are some > > packages which don't go along with each other well. > > > > But that shouldn't make pbuilder work and cowbuilder not work. I'm > > confused. > > I have the same problem with pbuilder... apt prefers packages from > experimental over those from sid, while it should be the contrary, and > the dummy package for build-dependencies would make sure the build > dependencies are downloaded from experimental when needed (that's what > versioned dependencies are for, aren't they?). Have you tried using 'pbuilder-satisfydepends-experimental' ? (man pbuilderrc) regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cowbuilder and --distribution experimental
Hi, > > > > > > experimental is not a complete distribution. You cannot just use > > > --distribution experimental. I think that you should use an unstable > > > chroot > > > and add to apt experimental sources. You will also have to provide a > > > correct /etc/apt/preferences (otherwise, experimental repository will not > > > be used). > > > > Actually, '--distribution experimental' is special-cased in pbuilder > > such that it should just work. '--distribution experimental' sets up > > internal flags such that it is interpreted as '--distribution sid' and > > special handling for experimental. > > Obviously, it doesn't. Because with properly set pinning, you wouldn't > have a problem with e2fsprogs/libuuid1 (which happens when trying to > install perl from experimental). Heh, I guess we have a different definition of 'properly'. pbuilder experimental usage assumes we can install everything from experimental and get done with it, but I assume there are some packages which don't go along with each other well. But that shouldn't make pbuilder work and cowbuilder not work. I'm confused. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cowbuilder and --distribution experimental
Hi, > > Hi again mentors !!! > > I've now a strange problem creating an experimental COW image. > > > > I use "cowbuilder --create --distribution experimental" but I obtain an > > unmet error with e2fsprogs (PreDepends: libuuid1 (>= 1.34-1)). > > libuuid1 package is correctly downloaded and configured on chroot > > environment :( > > > > Same error overriding EXTRAPACKAGES with =libuuid1. > > experimental is not a complete distribution. You cannot just use > --distribution experimental. I think that you should use an unstable chroot > and add to apt experimental sources. You will also have to provide a > correct /etc/apt/preferences (otherwise, experimental repository will not > be used). Actually, '--distribution experimental' is special-cased in pbuilder such that it should just work. '--distribution experimental' sets up internal flags such that it is interpreted as '--distribution sid' and special handling for experimental. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: speed of COW directory copying: XFS 20x slower than ext3
Hi, > We just discovered, that mounting XFS partition with: > > sudo mount -o nobarrier /dev/sda2 /mnt/p1 > > speeds things up on all machines. The reason is, that the option "-o > barrier" was added by default to all kernels >= 2.6.17, so dakol has > nobarrier, all the others have barrier. By mounting with nobarrier, > the cp and rm times are 5s on the first run and around 1.7s on > subsequent runs. That's much better for XFS. This is very interesting. I have so far only tested cowdancer with ext3. Profiling and optimizing code is done only for ext3. I'm not quite sure how widespread other filesystems are, but it would be interesting to see how they can be optimized better wrt cowdancer usage. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Statically linked libraries...
Hi, > I am preparing a package for the mira software, and encounter the > following lintian error: > > The package installs a statically linked binary or object file. > > I miss the backgound in C programing to know where to start to takcle > this problem. Can sombebody give me a hint? I have uploaded the package > on mentors (this is still a preliminary package). ./configure output says: > > Summary of MIRA configuration > > We are building on ... Linux > Can MIRA be build on this system? yes > CPU supports 64 bit? . ... yes > Do we compile in 64 bit? . yes > Building completely static? .. yes > Compiler . x86_64-linux-gnu-gcc and looking at the build log it says: > x86_64-linux-gnu-g++ -DPUBLICQUIET -DAJ_Linux64 -O2 -L../../../io/ > -L../../../util/ -L../../../errorhandling/ -L../../../mira > -L../../../examine/ -L../../../EdIt/ -L../../../caf/ -L../../../knn_abi373 > -L../../../knn_alf -Wl,-z,defs -static -o tstReadPool tstReadPool.o > -lerrorhandling -lmira -lmsupport -ldptools -lutil -lfio -lexpat So yes, you are building binaries static (you are giving '-static' option to g++ ), and it looks like ./configure has a switch to toggle the option. A properly created ./configure script usually has a usable --help option. > ./configure --help gives: > --enable-static builds static binaries, default is yes Looking at the source (configure.ac) the upstream have customized it such that --enable-static is the default, and adds '-static' to the linking process. I don't quite understand why they want to do that as default, but --disable-static should disable static-linking. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: quilt, cdbs, dpatch, but is there even simpler ?
Hi,
> > >> > > I moved to debian/patches with dpatch. Is this a reasonable
> > >> > > solution?
> > >> >
> > >> > use what you like. I usually find quilt simpler, but really, I care
> > >> > much about you beeing comfortable with it than me. You may want to
> > >> > read[0].
> > >>
> > >> Wow, quilt is much easier to use. The new maintainer guide recommended
> > >> dpatch but it sort of sucked, good thing I asked :)
> > >
> > > For the moment I use dpatch, but is is a slight work overhead since it
> > > is needed to convert patches to dpatches,
> >
> > Are you sure, this is necessary? AFAIK the comments and shell commands
> > are optional.
>
> Comments are optional but the first line is needed now as:
> #! /bin/sh /usr/share/dpatch/dpatch-run
>
> I had the same impression as yours.
>
> I guess changing following 2 lines should fix situation.
>
> line 416: test -x ${patch} || chmod +x ${patch}
> line 434: if eval ${patch} -patch ${wd} ${redir} ${stamp}.new 2>&1; then
>
> I guess drop 416 and run dpatch-run in 434.
>
> Probably, deapply needs fix too.
>
> I do not know this is caused by some design decision or not. (CCing to
> current
> active maintainer)
Yeah, I guess it was a design decision. If I follow your advise, I
will break those tools that do not run dpatch-run. Most of the
original dpatch scriptlets contained shell scripts which
applied/deapplied themselves.
I read the manual, and apparently there is a simple way to create
dpatch scriptlets (man dpatch):
Creating dpatch scriptlets
There are many ways to create dpatch scriptlets. They are
simple, executable files, which follow a standardised calling
convention (documented in dpatch(7)).
You can fire up your $EDITOR, or use dpatch-edit-patch, and you
should be all set.
For most cases, where the dpatch file is only to apply a simple
patch, there is an even easier way:
dpatch patch-template -p "01_some_patch" "A random patch" \
debian/patches/01_some_patch.dpatch
regards,
junichi
--
[EMAIL PROTECTED],netfort.gr.jp} Debian Project
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: echroot
Hi, > > > > >> I am looking for a sponsor for my package "echroot". > > > > echroot extends the basic options that we found in chroot, with > > > echroot we > > can control many more options than executing chroot. Here I show some > > of the options that we can happen to echroot. > > What is the advantage of running a chroot not as root? Personally, I'm touched by this because I'm always forced to use 'su' alongside 'chroot'. Being root inside chrooted environment really is useless. > That doesn't seem (to me) to be a particularly long list of new > features and some can be worked around the existing chroot without too > much difficulty. Have you tried submitting wishlist bugs against chroot > to include the new functionality? Do the two programs use the same > language? It might be worth noting that chroot is a widely available tool with a set of specific expectations and adding features to chroot may or may not be a good idea. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: echroot
Hi, > >> I am looking for a sponsor for my package "echroot". > >[...] > >The description says that this is an alternative to the > >well-known chroot. What makes it different? > >Kind regards > >Nico > > echroot complements and extend chroot, run command with root directory > set to NEW-ROOT. That doesn't really explain anything, what does it really do? regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library sonames and unstable libraries
Hi, > > > Too, there are actually two forms of library soname file naming used: > > libfoo.so.1.2.3 > > and > > libfoo-1.2.3.so > > Only the first one is mentioned in the various packaging guides, hmmm ? excluding this? http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#shldevpackagecontents > 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. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can a package using a cow-shell be cow-builded?
Hi, > I am preparing the package of a software which provides regression tests > in a separate directory, for which there is no "make clean" available. > For the moment, I copy the directory somewhere else, perform the tests > in (it generates many files), and delete the directory in debian/rules > clean. > > I am tempted to use cow-shell for this, and I am wondering if it would > interfere when the whole package is cow-builded? > > I put Junichi in copy of this mail, as he is likely to have an answer... I think it should be okay; depending on what you do, as long as you're not running in root privilege, it shouldn't cause any bad side-effects. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using cow-shell to build a package
Hi, > > >It would be nice if you could describe your setup in more detail (or > > >even provide the hook scripts somewhere). I tried a A00login hookscript > > >that invokes in interactive bash, but for some reason it exits > > >immediately when invoked by pbuilder: > > > > I didn't do anything special than reading the pbuilder-doc and using > > examples from /usr/share/doc/pbuilder > > > > > -> user script /var/cache/pbuilder/build//1695/tmp/hooks/A00login finished > > > su: Authentication service cannot retrieve authentication info. > > > (Ignored) > > > > I don't have access to debian/ubuntu system right now, but I think in > > order to go interactive from a hook I did something like this in a hook > > script > > > > bash /dev/tty >^^^ > > This was the missing piece of information. Thanks! > > > > > I also didn't use the A hook, only the pre-build hook and > > build-failed/build-success hook (sorry, don't remember the hook letters > > anymore) > The A hooks are called after all dependencies are installed on the source > package is unpackaged, so this should be the prebuild hook. > Note that hook example files are available in /usr/share/doc/pbuilder/examples which you could even point to it using cowbuilder --build --hookdir /usr/share/doc/pbuilder/examples XXX.dsc to see the full extent of current available hooks. If you had looked at C10shell hook, it would have been obvious... BTW, I like your idea of using A hooks to do it. I presume you're doing something like pdebuild -- --hookdir --bindmount $(pwd)/.. --pbuilder cowbuilder regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: use of xvfb-run in pbuilder builds
Hi, > >> Are there any suggestions or can anyone point me to a package that > >> successfully uses xvfb under pbuilder? > > > > In theory, it should work, though I have not really tried recently. > > > > Does your chroot have /tmp/.X11-unix ? > > > > That is it, I guess. I have a minimal chroot because I want to be sure > that the buildd network can build the package no matter what. I suppose > that I will have to figure out how to install all the requirements at run > time or just give in and permanently install X on my chroots. Is there > any guarantee that the buildds have this installed already? It should be mostly guaranteed since this file is created as part of boot process, or installation process, as long as invoke-rc.d is handled properly. pbuilder does it properly, but no idea how buildds are maintained wrt this. Since xvfb is one thing that other packages already use in build, it's probably functional. Even if it fails, it's arguably something that should be fixed to work on buildd side. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: use of xvfb-run in pbuilder builds
Hi, > I am trying to use xvfb-run to permit pbuilder to build some packages > which need to connect to X. In both cases, if I do a local build with > dpkg-buildpackages, the connection to the xvfb server works fine, however > it fails in pbuilder. In one case, it is a perl-tk module which tries to > open a window to run tests: > > xvfb-run /usr/bin/make test > ... > "couldn't connect to display \":99\" > > In the second case, it is a python package which successfully connects to > X initially but then there is a failure. I know this because if I don't > try to use xvfb-run, the failure occurs _before_ any compilation happens. > > xvfb-run python2.3 ./setup.py build > ... > lots of compilation ensues > ... > /usr/bin/xvfb-run: line 158: kill: (23268) - No such process > > Are there any suggestions or can anyone point me to a package that > successfully uses xvfb under pbuilder? In theory, it should work, though I have not really tried recently. Does your chroot have /tmp/.X11-unix ? regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-Debian packaging practice
Hi, > The possible exception is in combination with gnulib, but this seems > inconsistent, since most people I've asked, who know "about" autofoo, > don't know what gnulib is. But I'd love to understand more than I do. > > There are now projects that want to use autotools because it is > "right", even if they won't actually *do* anything with the output of > the configure script, they want to be able to show their users/bosses > that "we use autotools, ergo we are portable". One thing is that gnulib is quite new, only few years old. > Correct me if I'm wrong .. but thats now how it works. autoconf seems > to provides a kind of a framework to facilitate portability, and > automake provides a framework for creating makefiles with common and > useful targets. Just stuffing autotools into an existing project just > adds crud, with no benefits. Hmm... no benefits is an overstatement. autoconf provides a standard package configuration framework, which allows for a ./configure script interface that parses known standard variables, such as installation directories and compiler flags. These days, Linux is mostly standard, and maybe you might want to care about MacOSX and that's it, but when you have to work with the plethora of Commercial Unices, and BSDs, it is still quite a valuable tool. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-Debian packaging practice
Hi, > Is there a document describing software packaging good practices for > general use, not specific to Debian, preferably in electronic form? You might be looking for autoconf/automake (although it's a bit rusty, and quite a few people loathe it, it's one working current standard we have). Autoconf and automake manuals will probably tell you a lot about these things. Basically you make Makefile.am and configure.ac files, which will let you do make dist to create your .tar.gz distribution, which is in turn used as upstream source tarball for every distribution. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upstream tar.gz in orig file à la dbs (was Re: dpatch & upstream source)
Hi > > Also, how does this work WRT pristine source requirements? I notice > > that coreutils embedded upstream tarball is pristine, but of course > > the .orig is not. > > That's the kind of question I'm looking answers for. In the developer > manual, > it is clearly said that the .orig.tar.gz should be a "byte-for-byte identical > to a tarball officially distributed by the upstream author." > > ... but, dbs does it. coreutils is just an example. I've seen some other > package doing that. There are probably many of them but I don't download > source package very often. With dpatch maintainer hat on, dpatch-convert-diffgz should work for most problems, although it does have a few bugs. If you can work with filterdiff et al directly, that's fine. erlang leaving things around might be a problem. Most C/C++ codes using autoconf/automake have checks against them. More of an operational point of view, it's difficult to look at source code. Bug #250202 is the one to look at; which seems to have a solution. I stumbled upon this when I tried to write a hook to import Debian sources to gonzui (source-code browser). regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch & upstream source
Hi, > I'm working on some big changes for the new upstream of the erlang packages. > The biggest change is that the package is now fully using dpatch, *but*, > basing myself on some other package I've seen (coreutils for example), I've > put the compressed upstream right in the package. It is extracted using a > dpatch scriptlet. > > Is it okay to do that, for one thing? Out of interest, I would be interested in the advantages of having a tarball like that. DBS used to do that, and dpatch users (in my impression) were those who didn't like that doubly tar-ed orig tarball. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What should I call the source package?
Hi, > > After compiling it, I will get two libraries (runtime and development > > libraries). I named these packages as libfortranposix0, > > libfortranposix0-dev according to their soname. > > It's libfortranposix0 for the runtime library and libfortranposix-dev > for the development package. (If you read by chance debian-devel you > should ignore the discussion about naming there for now.) In case you haven't noticed, read section 8.1, 8.4 of Debian-policy. The naming is at the discretion of the maintainer, with a reason. As for the original question, the orig.tar.gz should be what the upstream has specified as the package name, which probably is "fortranposix" in this case. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how use dpatch for binary files ?
Hi, > Im thinking use uuencode and uudecode to solve this problem, but I > would like to know if have other option to solve it. It is the limitation of dpkg-source. That seems to be the right solution for the time being. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: ecasound: Re: Bug#317194: ecasound update is pending g++ 4.0 transition
Hi, I'm looking for someone who can upload ecasound for me. http://www.netfort.gr.jp/~dancer/tmp/20050713/ It fixes a uninstallable error. regards, junichi At Wed, 13 Jul 2005 02:02:43 +0900, Junichi Uekawa wrote: > > > gcc 4.0 is already in a usable state and is the default compiler in > > unstable. According to the C++ transition plan laid out by Matthias, you > > should be uploading ecasound2.2 ASAP. If there is some other "turmoil" that > > is grounds for delaying the ecasound2.2 upload, please discuss it on > > debian-devel. > > > > Some ecasound-using packages must also wait for qt-x11-free, but that > > should shake out soon now that xorg-x11 has been uploaded to unstable, and > > is still not a reason to delay fixing ecasound2.2. > > ecasound2.2 is available here: > > http://www.netfort.gr.jp/~dancer/tmp/20050713/ > > I don't have my key with me right now, > and even if I had it, it's probably not accepted in Debian keyring. > Looking for a sponsor. > > > regards, > junichi > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -dev library package naming
Hi, > > The library package guide should tell you to use > > > > libspf-1.0-0 > > Note that the question was about the -dev package naming, which is > not really explained in your excellent FAQ. > > PS: also, will you ever incorporate the shell script snippet by > Steve Langasek I sent you, which determines the package name given > the library file? I've already included it; but discovered that it was not in the section under naming shared libraries, so I shuffled it around. It should look (slightly) better now. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#naminglibpkg regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -dev library package naming
Hi, > A package that installs /usr/lib/libspf-1.0.so.0.0.0 should be names > libspf-1.0-0 from all I can tell. The policy does not dictate how > the -dev (and -doc) package should be named. I would prefer not to > call it libspf-dev but rather encode the version. > > The library packaging guide says I should include the SONAME in the > name (libspf0-dev), but this seems wrong to me. Shouldn't the name > rather include the 1.0 used by upstream? The library package guide should tell you to use libspf-1.0-0 If it doesn't, that's an error in the guide; but I would also first check the SONAME of the library. regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
Hi, > 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. > > Should I just make my cogito package Conflict with the GNU Interactive > Tools git package? I don't think we really need /usr/bin/git. It's just a wrapper that runs /usr/bin/git-whatever-script My recommended action is: 1. tell them /usr/bin/git name is already taken, and we're renaming it to piggy alternatives is unintuitive, because we will see the problem of 'git' is this on one system, but is another on another system, and they are completely different things. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tinywm - Ridiculously tiny window manager
Hi,
> >
> > With these points fixed, your package looks good that I could sponsor.
>
> Thank you very much .
I've uploaded it to the archive.
regards,
junichi
--
Junichi Uekawa, Debian Developer
17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
http://www.netfort.gr.jp/~dancer/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tinywm - Ridiculously tiny window manager
Hi, 1. > > 2. > > Is the priority '50' for x-window-manager alternatives > > correct? How did you calculate the value? > > > I did't notice this . > I changed this priority to 10. > The reason for this WM is that it is thought that priority > levels are lower than other WM when the reason examined the > priority of other WM. According to: '11.8.4. Packages providing a window manager' It should be 20 Did I miss something ? 2. I've sent a separate mail about your description. With these points fixed, your package looks good that I could sponsor. regards, junichi -- Junichi Uekawa, Debian Developer 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 http://www.netfort.gr.jp/~dancer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tinywm - Ridiculously tiny window manager
Hi,
My comments against your description:
Description: Ridiculously tiny window manager
TinyWM is a ridiculously tiny window manager implemented
in nearly as few lines of C as possible, without being
obfuscated or entirely useless. It allows you to move,
resize, focus (sloppy), and raise windows -- that's it!
TinyWM's main purpose is to serve as a quick example of some
window manager programming basics.
And this is likely to be able to use it as a window manager of a
embedded system.
1, I would not want to have a relative term like 'ridiculously'
2, the first line is just a repetition
3, the source code is not what the user will directly see.
I suggest the following
Description: Tiny Window Manager
TinyWM is a small and simple window manager with small
memory footprint, useful in embedded systems.
.
Features window move, resize, sloppy focus and raise.
.
Due to the simplicity, the source code in C and python
can be used for reference in Window Manager programming basics.
Could l10n-english folks proofread my description?
BTW, I was really surprised that it was really so small.
$ wc -l tinywm.c
58 tinywm.c
regards,
junichi
--
Junichi Uekawa, Debian Developer
17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
http://www.netfort.gr.jp/~dancer/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tinywm - Ridiculously tiny window manager
Hi,
> Thank you for this comment .
> I put a necessary file.
> Files are availabele at :
> http://www.hemamu.com/hemamu/debian/
1.
I think you've misspelt
debian/manpeges should be debian/manpages
2.
Is the priority '50' for x-window-manager alternatives
correct? How did you calculate the value?
3.
I think there were objections to your Description before;
it only describes it as a tiny/example window manager,
while you have expressed it as a window manager of
choice for embedded systems.
Could you reflect it in the description?
regards,
junichi
--
Junichi Uekawa, Debian Developer
17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
http://www.netfort.gr.jp/~dancer/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tinywm - Ridiculously tiny window manager
Hi, > The package files are available from http://www.hemamu.com/hemamu/debian/ . > I've looked at the directory. I can point out that you have only created a Debian native package, You will need an upstream file as ../tinywm_1.3.orig.tar.gz when building. regards, junichi -- Junichi Uekawa, Debian Developer 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 http://www.netfort.gr.jp/~dancer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: upstream version in debian/rules in a $VARIABLE?
Hi, > Do I have easy access to the upstream version in debian/rules? > > Of course, I can get it, but that'd be silly if it's already there. > > dpkg-parsechangelog | grep ^Version: | cut -f 2 -d \ | cut -f 1 -d - > > (I know, I really should read the sed and awk docs, it's probably easy to > fold grep, cut, cut into one.) I would be interested since I'm doing the following in yc-el package; VERSION=$(shell dpkg-parsechangelog | sed -n 's/^Version: \([^-]*\).*$$/\1/p') regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Iuusues when packaging libraries..
> I am responsible for the package htdig. Htdig is a full-text indexer for > (local) sites, ie. will generate a full-text (searchable) index of that > site. > The thing is written in C++, and comes with loads of libraries. While > the procedure described in the various manuals (the shlibs system) is > great if you have very few libraries that do not interdepend, it is imo > not a solution for cases like mine (over 30 libraries, that interdepend). > > Hence my mail to this list. I am looking for a solution to package those > libs, if possible without getting warnings like: > > >dpkg-shlibdeps: warning: could not find path for (libraryname-version.so) If you're using dh_shlibdeps, they seem to do what you probably want to do: -ldirectory[:directory:directory:..] Before dpkg-shlibdeps is run, LD_LIBRARY_PATH will have added to it the specified directory (or directories -- separate with colons). This is useful for multi-binary packages where a library is built in one package and another package contains binaries linked against said library. Relative paths will be made absolute for the benefit of dpkg-shlibdeps. Note that the directory given should be the complete or relative path to a directory that contains the library. See example below. -Lpackage, --libpackage=package Use the shlibs file automatically generated by dh_makeshlibs for the named package as a kind of automatically generated shlibs.local file. You can use this switch in concert with the -l switch to make dpkg-shlibdeps find a library built as part of the current package, and get the shlibs information. See example below. regards, junichi
Re: Iuusues when packaging libraries..
> I am responsible for the package htdig. Htdig is a full-text indexer for > (local) sites, ie. will generate a full-text (searchable) index of that > site. > The thing is written in C++, and comes with loads of libraries. While > the procedure described in the various manuals (the shlibs system) is > great if you have very few libraries that do not interdepend, it is imo > not a solution for cases like mine (over 30 libraries, that interdepend). > > Hence my mail to this list. I am looking for a solution to package those > libs, if possible without getting warnings like: > > >dpkg-shlibdeps: warning: could not find path for (libraryname-version.so) If you're using dh_shlibdeps, they seem to do what you probably want to do: -ldirectory[:directory:directory:..] Before dpkg-shlibdeps is run, LD_LIBRARY_PATH will have added to it the specified directory (or directories -- separate with colons). This is useful for multi-binary packages where a library is built in one package and another package contains binaries linked against said library. Relative paths will be made absolute for the benefit of dpkg-shlibdeps. Note that the directory given should be the complete or relative path to a directory that contains the library. See example below. -Lpackage, --libpackage=package Use the shlibs file automatically generated by dh_makeshlibs for the named package as a kind of automatically generated shlibs.local file. You can use this switch in concert with the -l switch to make dpkg-shlibdeps find a library built as part of the current package, and get the shlibs information. See example below. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error on dpkg-buildpackage
> > > > AFAIR, you have to change > > CFLAGS=$(CFLAGS) ./configure [...] > > to > > CFLAGS="$(CFLAGS)" ./configure [...] > > in debian/rules. > > Wouldn't > > CFLAGS += .configure [...] > > be a lot easier in most cases? That's a totally different notion :P We're trying to set a shell variable before calling ./configure. regards, junichi
Re: Error on dpkg-buildpackage
> > > > AFAIR, you have to change > > CFLAGS=$(CFLAGS) ./configure [...] > > to > > CFLAGS="$(CFLAGS)" ./configure [...] > > in debian/rules. > > Wouldn't > > CFLAGS += .configure [...] > > be a lot easier in most cases? That's a totally different notion :P We're trying to set a shell variable before calling ./configure. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: jackd/ dpkg-statoverride/ "audio" group question(s)]
> > > > Is there a policy for audio apps in this regard? > > > > No, but there should be, probably. > > Since there are a lot of audio applications starting to > hit sid, eg. jackd, ardour, etc, where would be the place to > discuss "policy" in this regard - eg., having an audio group, > and suid/sgid on these applications? > (seeing as dpkg-statoverride is not the way to do it it seems) I invite you to join debian-multimedia mailing list, where we are trying to coordinate jack related stuff. regards, junichi
Re: [Fwd: Re: jackd/ dpkg-statoverride/ "audio" group question(s)]
> > > > Is there a policy for audio apps in this regard? > > > > No, but there should be, probably. > > Since there are a lot of audio applications starting to > hit sid, eg. jackd, ardour, etc, where would be the place to > discuss "policy" in this regard - eg., having an audio group, > and suid/sgid on these applications? > (seeing as dpkg-statoverride is not the way to do it it seems) I invite you to join debian-multimedia mailing list, where we are trying to coordinate jack related stuff. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
> Lintian, however, can't know that this particular library usually is > preloaded, not linked to. Hence the override. If its use is going to be something like that, please don't put it in /usr/lib. That's what the lintian warning is about. regards, junichi
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
> Lintian, however, can't know that this particular library usually is > preloaded, not linked to. Hence the override. If its use is going to be something like that, please don't put it in /usr/lib. That's what the lintian warning is about. regards, junichi
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
> Lintian, however, can't know that this particular library usually is > preloaded, not linked to. Hence the override. If its use is going to be something like that, please don't put it in /usr/lib. That's what the lintian warning is about. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
> Lintian, however, can't know that this particular library usually is > preloaded, not linked to. Hence the override. If its use is going to be something like that, please don't put it in /usr/lib. That's what the lintian warning is about. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pdsh -- An efficient rsh-like utility, for using hosts in paralell
> Pdsh is a high-performance, parallel remote shell utility. It has > built-in, thread-safe clients for Berkeley and Kerberos V4 rsh, and can > call SSH externally (though with reduced performance). Pdsh uses a > "sliding window" parallel algorithm to conserve socket resources on the > initiating node and to allow progress to continue while timeouts occur > on some connections. I would like an improved description than this; ideally one should be able to compare the description of 'dsh' and 'pdsh' and see how they are different. I'll try and update dsh description. The major difference between the two implementation seems to be (from your description): o pdsh includes rsh itself, while dsh does not o pdsh tries to keep fixed amount of connections at the same time for parallel connection, dsh does not care; dsh uses a fan-out mechanism for large-scale job submission. regards, junichi.
Re: RFS: pdsh -- An efficient rsh-like utility, for using hosts in paralell
> Pdsh is a high-performance, parallel remote shell utility. It has > built-in, thread-safe clients for Berkeley and Kerberos V4 rsh, and can > call SSH externally (though with reduced performance). Pdsh uses a > "sliding window" parallel algorithm to conserve socket resources on the > initiating node and to allow progress to continue while timeouts occur > on some connections. I would like an improved description than this; ideally one should be able to compare the description of 'dsh' and 'pdsh' and see how they are different. I'll try and update dsh description. The major difference between the two implementation seems to be (from your description): o pdsh includes rsh itself, while dsh does not o pdsh tries to keep fixed amount of connections at the same time for parallel connection, dsh does not care; dsh uses a fan-out mechanism for large-scale job submission. regards, junichi. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pdsh
>Commercialization of this product is prohibited without notifying the >Department of Energy (DOE) or Lawrence Livermore National Laboratory >(LLNL)." > > This seems to me to conflict with the GPL, and I'd like confirmation on > that. I guess if it is, then the proper procedure would be to ask > upstream about the conflict. That conflicts with Debian Free Software Guidelines, even if it doesn't conflict with GPL. regards, junichi.
Re: RFS: pdsh
>Commercialization of this product is prohibited without notifying the >Department of Energy (DOE) or Lawrence Livermore National Laboratory >(LLNL)." > > This seems to me to conflict with the GPL, and I'd like confirmation on > that. I guess if it is, then the proper procedure would be to ask > upstream about the conflict. That conflicts with Debian Free Software Guidelines, even if it doesn't conflict with GPL. regards, junichi. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libgtop2 NMU and advice asked.
> > The normal procedure is to rename the binary package to > > libgtop2-1 (it should probably have been libgtop2.0-1, but > > people seem to have their own tastes about this.) > > Ok, thanks for the info, and what is the procedure concerning this and > NMUs ? Also, while this name change mean the package will linger in NEW > for days, and not fix the corresponding RC bug during all this time ? Yes. You can revert to the old package using an epoch so that it goes back to a known good version first, if you are pedantic, but I don't think it's worth it, since you are uploading a new package into unstable. It's unfortunate but that's the price of being non-attentive when packaging libraries. There are tools to address that issue, such as d-shlibs, which gives out errors when things don't look right. > > And then noting each maintainer to recompile against the new package, > > and optionally doing a mass-NMU and uploading to DELAYED queue... > > So, doing it the hard way. Could anyone provide me a script or something > to get all the problematix packages ? Would a apt-cache rdepends be > enough for this : I think that would be enough. It would be obvious after the new package is installed, because they will be uninstallable in unstable. regards, junichi
Re: libgtop2 NMU and advice asked.
> > The normal procedure is to rename the binary package to > > libgtop2-1 (it should probably have been libgtop2.0-1, but > > people seem to have their own tastes about this.) > > Ok, thanks for the info, and what is the procedure concerning this and > NMUs ? Also, while this name change mean the package will linger in NEW > for days, and not fix the corresponding RC bug during all this time ? Yes. You can revert to the old package using an epoch so that it goes back to a known good version first, if you are pedantic, but I don't think it's worth it, since you are uploading a new package into unstable. It's unfortunate but that's the price of being non-attentive when packaging libraries. There are tools to address that issue, such as d-shlibs, which gives out errors when things don't look right. > > And then noting each maintainer to recompile against the new package, > > and optionally doing a mass-NMU and uploading to DELAYED queue... > > So, doing it the hard way. Could anyone provide me a script or something > to get all the problematix packages ? Would a apt-cache rdepends be > enough for this : I think that would be enough. It would be obvious after the new package is installed, because they will be uninstallable in unstable. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libgtop2 NMU and advice asked.
> I am currently preparing a NMU for libgtop2, which is broken and whose > maintainer told me has no time to fix right now. > > Now, the problem was that the libgtop library moved from 0.so.0.0.1 to > 0.so.1.0.1, and the install rules didn't catch this changes. The normal procedure is to rename the binary package to libgtop2-1 (it should probably have been libgtop2.0-1, but people seem to have their own tastes about this.) And then noting each maintainer to recompile against the new package, and optionally doing a mass-NMU and uploading to DELAYED queue... A reference document for library package naming is available here: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html regards, junichi
Re: libgtop2 NMU and advice asked.
> I am currently preparing a NMU for libgtop2, which is broken and whose > maintainer told me has no time to fix right now. > > Now, the problem was that the libgtop library moved from 0.so.0.0.1 to > 0.so.1.0.1, and the install rules didn't catch this changes. The normal procedure is to rename the binary package to libgtop2-1 (it should probably have been libgtop2.0-1, but people seem to have their own tastes about this.) And then noting each maintainer to recompile against the new package, and optionally doing a mass-NMU and uploading to DELAYED queue... A reference document for library package naming is available here: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package does not build everywhere due to midding header -- help sought
> To my knowledge, Netfilter's ULOG target (and thus ipt_ULOG.h) > appeared in kernel version 2.4.18. On neither architecture, kernel > versions greater than 2.4.17 are available, so I guess using > ulog-acctd on those architectures would not make much sense, anyhow. I don't think it is intended that these architectures to stay with 2.4.17 kernel, so I think you just need to wait and ignore these architectures until newer versions are available. Just my opinion. regards, junichi
Re: package does not build everywhere due to midding header -- help sought
> To my knowledge, Netfilter's ULOG target (and thus ipt_ULOG.h) > appeared in kernel version 2.4.18. On neither architecture, kernel > versions greater than 2.4.17 are available, so I guess using > ulog-acctd on those architectures would not make much sense, anyhow. I don't think it is intended that these architectures to stay with 2.4.17 kernel, so I think you just need to wait and ignore these architectures until newer versions are available. Just my opinion. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: age in libraries and debian package names
> Hi. > (A special hello to Junichi who is CCed because of his libpkg-guide.) > > I'm having a package that will probably use the age feature of release > numbering. (I.e. libfoo.a.b.1 to indicate that programs linked against > libfoo.a > and libfoo.(a-1) can use it as documented in the libtool docs.) I've searched > the docs (including libpkg guide) for hints what to do in terms of packaging. > Should I just ignore the binary compatibility or should I add a "Provides: > libfoo(a-1)"? (a-1) being the result of calculating the predecessor of a. > Advice is appreciated, as are examples in the archive. You are going to use the SONAME of the library, which will be different from the numbers you give to the libtool versioning. The package name is going to be derived from the package name, so you don't need to play with the provides and such things. regards, junichi
Re: age in libraries and debian package names
> Hi. > (A special hello to Junichi who is CCed because of his libpkg-guide.) > > I'm having a package that will probably use the age feature of release > numbering. (I.e. libfoo.a.b.1 to indicate that programs linked against libfoo.a > and libfoo.(a-1) can use it as documented in the libtool docs.) I've searched > the docs (including libpkg guide) for hints what to do in terms of packaging. > Should I just ignore the binary compatibility or should I add a "Provides: > libfoo(a-1)"? (a-1) being the result of calculating the predecessor of a. > Advice is appreciated, as are examples in the archive. You are going to use the SONAME of the library, which will be different from the numbers you give to the libtool versioning. The package name is going to be derived from the package name, so you don't need to play with the provides and such things. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder - how to use existing apt cache?
> > Since I'm behind a 64-k ISDN line, I would like pbuilder to use cached > > packages from /var/cache/apt/archives, if available instead of > > unconditionally downloading all the stuff. But unfortunately, > > /var/cache/apt/archives doesn't seem to be accessible from within the > > chroot. > > > > Well, I could run dpkg-scanpackages on /var/cache/apt/archives and make > > the files available through a local web server which then could be added > > to the pbuilderrc as OTHERMIRROR. But wouldn't pbuilder try MIRRORSITE > > first anyway, so that OTHERMIRROR remains completely unused? > > > > Is there a 'canonical' way to achive what I'm asking for? > > I simply use APTCACHE=/var/cache/apt/archives/, it copies the contents > into the chroot first and copies back the newly downloaded debs. > I'll add this into the FAQ section of the documentation. I initially thought it should be obvious, but apparently isn't. regards, junichi
Re: pbuilder - how to use existing apt cache?
> > Since I'm behind a 64-k ISDN line, I would like pbuilder to use cached > > packages from /var/cache/apt/archives, if available instead of > > unconditionally downloading all the stuff. But unfortunately, > > /var/cache/apt/archives doesn't seem to be accessible from within the > > chroot. > > > > Well, I could run dpkg-scanpackages on /var/cache/apt/archives and make > > the files available through a local web server which then could be added > > to the pbuilderrc as OTHERMIRROR. But wouldn't pbuilder try MIRRORSITE > > first anyway, so that OTHERMIRROR remains completely unused? > > > > Is there a 'canonical' way to achive what I'm asking for? > > I simply use APTCACHE=/var/cache/apt/archives/, it copies the contents > into the chroot first and copies back the newly downloaded debs. > I'll add this into the FAQ section of the documentation. I initially thought it should be obvious, but apparently isn't. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build a package from cvs.
> I am (have already) building a new package from the cvs tree, but my question > is: > > Shall I run the autobuild (called bootstrap) on my system and go with the > package using those results or I shall modify my debian/rules to create the > Makefile.in and friends during compilation time? > > It would force some modifications in debian/control to use the right automake > and so on... I'd rather have autoconf/automake run on your system, and use the results as the orig.tar.gz. The rationale being that automake et al take quite a lot of CPU cycle to run (waste of buildd time), and more importantly, they are rather unreliable to be ran noninteractively. regards, junichi
Re: How to build a package from cvs.
> I am (have already) building a new package from the cvs tree, but my question > is: > > Shall I run the autobuild (called bootstrap) on my system and go with the > package using those results or I shall modify my debian/rules to create the > Makefile.in and friends during compilation time? > > It would force some modifications in debian/control to use the right automake > and so on... I'd rather have autoconf/automake run on your system, and use the results as the orig.tar.gz. The rationale being that automake et al take quite a lot of CPU cycle to run (waste of buildd time), and more importantly, they are rather unreliable to be ran noninteractively. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SML-NJ Package Names
> smlnj-lib : misc libs for sml At least, I don't want binary packages to be named -lib. If they are shared libraries, make it libwhateverX and read libpkg-guide. if they are some SML libraries, name them libsml-whatever-whatever regards, junichi
Re: SML-NJ Package Names
> smlnj-lib : misc libs for sml At least, I don't want binary packages to be named -lib. If they are shared libraries, make it libwhateverX and read libpkg-guide. if they are some SML libraries, name them libsml-whatever-whatever regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to change file owner for deb packages properly?
Hi, I have a question. There are packages which probably need to be changed the owner (or suid) in .deb packages. Trying to chown to a user which does not exist will obviously emit an error like this: dh_link dh_strip dh_compress dh_fixperms chown netsaint debian/netsaint-neat/usr/lib/cgi-bin/netsaint/neat.cgi chown: `netsaint': invalid user I have seen several packages which do this and fail, and what is the proper way to fix that ? regards, junichi
How to change file owner for deb packages properly?
Hi, I have a question. There are packages which probably need to be changed the owner (or suid) in .deb packages. Trying to chown to a user which does not exist will obviously emit an error like this: dh_link dh_strip dh_compress dh_fixperms chown netsaint debian/netsaint-neat/usr/lib/cgi-bin/netsaint/neat.cgi chown: `netsaint': invalid user I have seen several packages which do this and fail, and what is the proper way to fix that ? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FHS ambiguity: /usr/lib or /usr/share?
> Putting script libraries into /usr/lib does not break systems mounted in > such manner, it only increases number of files that should be stored > separately for each architecture. Yes, I was quite wondering that too, and people tend to disagree on that point, and some people tend to be walking around filing RC bugs on this regard. I *think* that it is valid for scripts to reside in /usr/lib, especially when they are executables, or those which are libraries. /usr/share should really be restricted to shared data. Scripts may have some architecture dependency etc., right ? /usr/share is sharable among different architectures as well. regards, junichi
Re: FHS ambiguity: /usr/lib or /usr/share?
> Putting script libraries into /usr/lib does not break systems mounted in > such manner, it only increases number of files that should be stored > separately for each architecture. Yes, I was quite wondering that too, and people tend to disagree on that point, and some people tend to be walking around filing RC bugs on this regard. I *think* that it is valid for scripts to reside in /usr/lib, especially when they are executables, or those which are libraries. /usr/share should really be restricted to shared data. Scripts may have some architecture dependency etc., right ? /usr/share is sharable among different architectures as well. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some questions about patching source
> The plan I have come up with is to put all the files it needs into a > debian/patches directory, and alter the Makefile accordingly. This > works just fine, although it makes the resulting .diff about twice the > size of the original source code, and it means it need to be redone > every time there is a new xscreensaver revision. Does anyone have any > experience with this sort of thing, and have suggestions for automating > this process, or dealing with it differently? I usually like to have such piece to be included in the main thing. In this case, probably the lowest load will be to include that screensaver in the main screensaver package.. regards, junichi
Re: Which compiler
> But the plan is to move all architectures to gcc-3.2 for sarge. > I don't know why this hasn't happened already. That at least requires working gcc-3.2 and hence probably working glibc 2.3 for all arches, which has not happened yet. regards, junichi
Re: Some questions about patching source
> The plan I have come up with is to put all the files it needs into a > debian/patches directory, and alter the Makefile accordingly. This > works just fine, although it makes the resulting .diff about twice the > size of the original source code, and it means it need to be redone > every time there is a new xscreensaver revision. Does anyone have any > experience with this sort of thing, and have suggestions for automating > this process, or dealing with it differently? I usually like to have such piece to be included in the main thing. In this case, probably the lowest load will be to include that screensaver in the main screensaver package.. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which compiler
> But the plan is to move all architectures to gcc-3.2 for sarge. > I don't know why this hasn't happened already. That at least requires working gcc-3.2 and hence probably working glibc 2.3 for all arches, which has not happened yet. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failures & compiler versions
> > > Who can I ask to untweak the s390 buildd, and get my package rebuilt? > > > > > That's not the point of the bug report, > > you should fix your package to build with gcc-3.2, so > > that the switchover may happen with less pain. > > I will attempt to build it with 3.2 on i386. I was a bit surprised that a bug > was filed against it for that reason. Is that now automatic with all packages > being uploaded that fail to build with 3.2? I don't think it's automatic, I believe it is done manually. He's been filing few bugs every day, I think. I don't think any bug filing is automatic currently at all. regards, junichi
Re: build failures & compiler versions
> > > Who can I ask to untweak the s390 buildd, and get my package rebuilt? > > > > > That's not the point of the bug report, > > you should fix your package to build with gcc-3.2, so > > that the switchover may happen with less pain. > > I will attempt to build it with 3.2 on i386. I was a bit surprised that a bug > was filed against it for that reason. Is that now automatic with all packages > being uploaded that fail to build with 3.2? I don't think it's automatic, I believe it is done manually. He's been filing few bugs every day, I think. I don't think any bug filing is automatic currently at all. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failures & compiler versions
At Thu, 31 Oct 2002 06:58:00 -0500, Neil L. Roeth <[EMAIL PROTECTED]> wrote: > > So, gcc 2.95 is still supposed to be what s390 uses. Sounds like someone > > has "tweaked" the s390 buildd. > > Who can I ask to untweak the s390 buildd, and get my package rebuilt? > That's not the point of the bug report, you should fix your package to build with gcc-3.2, so that the switchover may happen with less pain. regards, junichi
Re: s390 build
At Wed, 30 Oct 2002 06:45:15 -0500, Neil L. Roeth <[EMAIL PROTECTED]> wrote: > due to a compile error. I logged on to trex and attempted to build it in the > unstable chroot. It built without error. Then I noticed that the error in > the buildd log referred to a file /usr/include/c++/3.2/backward/new.h. The > "3.2" made me think that the 3.2 compiler was being used instead of the > 2.95.4, but I found that the installed version of c++ is in fact 2.95.4 (c++ > --version). What is the build-essential compiler on s390? If it is 3.2, > should I expect it to be installed in the unstable chroot? I have an impression that the bug for failure to build with gcc-3.2 is filed prior to switch to 3.2 compiler. so default compiler is still 2.95. You should be able to try 3.2 out on an i386 box just fine, and it will probably fail. regards, junichi
Re: build failures & compiler versions
At Thu, 31 Oct 2002 06:58:00 -0500, Neil L. Roeth <[EMAIL PROTECTED]> wrote: > > So, gcc 2.95 is still supposed to be what s390 uses. Sounds like someone > > has "tweaked" the s390 buildd. > > Who can I ask to untweak the s390 buildd, and get my package rebuilt? > That's not the point of the bug report, you should fix your package to build with gcc-3.2, so that the switchover may happen with less pain. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 build
At Wed, 30 Oct 2002 06:45:15 -0500, Neil L. Roeth <[EMAIL PROTECTED]> wrote: > due to a compile error. I logged on to trex and attempted to build it in the > unstable chroot. It built without error. Then I noticed that the error in > the buildd log referred to a file /usr/include/c++/3.2/backward/new.h. The > "3.2" made me think that the 3.2 compiler was being used instead of the > 2.95.4, but I found that the installed version of c++ is in fact 2.95.4 (c++ > --version). What is the build-essential compiler on s390? If it is 3.2, > should I expect it to be installed in the unstable chroot? I have an impression that the bug for failure to build with gcc-3.2 is filed prior to switch to 3.2 compiler. so default compiler is still 2.95. You should be able to try 3.2 out on an i386 box just fine, and it will probably fail. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library version equals to project version ?
Eric Van Buggenhaut <[EMAIL PROTECTED]> immo vero scripsit: > On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, > which depends on libavifile0 version 0.7. OTOH, we have aspell version > 0.33.7.1 > which depends on libaspell10 version 0.33.7 The interface number of a shared library should usually be distinct from the version number of the package itself, since interface usually does not correspond to package versions. Interface do change with minor version upgrades, in which case interface number should be updated, and even with major version upgrades, interface compatibility can be kept, which means interface number does not need to change. avifile-player probably ignores that part, or changes the library version number on every release, or whatever. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Re: library version equals to project version ?
Eric Van Buggenhaut <[EMAIL PROTECTED]> immo vero scripsit: > On one hand I have the example of avifile-player version 0.7.12.20020719-1.2, > which depends on libavifile0 version 0.7. OTOH, we have aspell version 0.33.7.1 > which depends on libaspell10 version 0.33.7 The interface number of a shared library should usually be distinct from the version number of the package itself, since interface usually does not correspond to package versions. Interface do change with minor version upgrades, in which case interface number should be updated, and even with major version upgrades, interface compatibility can be kept, which means interface number does not need to change. avifile-player probably ignores that part, or changes the library version number on every release, or whatever. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help creating a c2lib package
[EMAIL PROTECTED] immo vero scripsit: > I'm building a Debian package of my c2lib library, mainly for my > own home use at the moment, but hopefully to become a part of > Debian in the future. My current efforts are here: > > http://annexia.org/tmp/c2lib-1.2.23.tar.gz A brief description of what it is and what it does would be a big plus. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Re: Help creating a c2lib package
[EMAIL PROTECTED] immo vero scripsit: > I'm building a Debian package of my c2lib library, mainly for my > own home use at the moment, but hopefully to become a part of > Debian in the future. My current efforts are here: > > http://annexia.org/tmp/c2lib-1.2.23.tar.gz A brief description of what it is and what it does would be a big plus. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper files w/ meta values
On Fri, 18 Oct 2002 12:29:34 -0600 "Joel Baker" <[EMAIL PROTECTED]> wrote: > > You can use variables in debian/rules all right. > > Er. Because it's helpful? Being able to do dh_installdirs, dh_installlinks, > dh_install (etc) and have the lists in sane files of only that is far > easier to manage than listing them all in debian/rules, or even included > rules files? > > At this point, I've punted and gone with m4, though. It's just easier. Well, I prefer using sed in debian/rules to generate debhelper files, from some template files with ".in" appended to it. But sometimes that makes things a bit muddier, and harder for other people to see. I'm more inclined to write it down in debian/rules and not use debhelper for that specific part, if working around debhelper limitation is needed. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper files w/ meta values
On Fri, 18 Oct 2002 12:29:34 -0600 "Joel Baker" <[EMAIL PROTECTED]> wrote: > > You can use variables in debian/rules all right. > > Er. Because it's helpful? Being able to do dh_installdirs, dh_installlinks, > dh_install (etc) and have the lists in sane files of only that is far > easier to manage than listing them all in debian/rules, or even included > rules files? > > At this point, I've punted and gone with m4, though. It's just easier. Well, I prefer using sed in debian/rules to generate debhelper files, from some template files with ".in" appended to it. But sometimes that makes things a bit muddier, and harder for other people to see. I'm more inclined to write it down in debian/rules and not use debhelper for that specific part, if working around debhelper limitation is needed. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Debhelper files w/ meta values
On Thu, 17 Oct 2002 12:59:20 -0600 "Joel Baker" <[EMAIL PROTECTED]> wrote: > Is there a way to specify the following in a Debhelper file (such as > .dirs or .links)? > > usr/include/$(SHELLVARIABLE)/foo.h Why bother using debhelper at all ? You can use variables in debian/rules all right. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Debhelper files w/ meta values
On Thu, 17 Oct 2002 12:59:20 -0600 "Joel Baker" <[EMAIL PROTECTED]> wrote: > Is there a way to specify the following in a Debhelper file (such as > .dirs or .links)? > > usr/include/$(SHELLVARIABLE)/foo.h Why bother using debhelper at all ? You can use variables in debian/rules all right. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depends/Depends wierdness
Stephen Gran <[EMAIL PROTECTED]> immo vero scripsit:
> No, that was actually quite helpful. I am chasing this around because
> someone who wrote me offlist suggested that it actually depended on more
> libraries than I had listed. I checked with objdump, and it agrees with
> the generated field (as I expected - that's what dpkg-shlibdeps uses,
> right?). I cannot seem to set up an environment without the missing
> libraries, as that would remove tons of other kde stuff, and prevent me
> from running the program (in addition to hosing many of my users'
> desktops), so I'm going to believe objdump over ldd at this point.
You can try pbuilder.
It is designed to do such jobs.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Re: Build-Depends/Depends wierdness
Stephen Gran <[EMAIL PROTECTED]> immo vero scripsit:
> No, that was actually quite helpful. I am chasing this around because
> someone who wrote me offlist suggested that it actually depended on more
> libraries than I had listed. I checked with objdump, and it agrees with
> the generated field (as I expected - that's what dpkg-shlibdeps uses,
> right?). I cannot seem to set up an environment without the missing
> libraries, as that would remove tons of other kde stuff, and prevent me
> from running the program (in addition to hosing many of my users'
> desktops), so I'm going to believe objdump over ldd at this point.
You can try pbuilder.
It is designed to do such jobs.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> immo vero scripsit:
> Ignoring the irksome ld.so issues for a moment, upstram for this package
> is doing exactly the right thing by putting common functionality out in
> shared libs, even if the only executables sharing them are the ones in
> the package itself. There are 11 executables in this package, of about
> 30k each, plus 3 libs of about 75k each; each executable links against
> two of the libs. Linking the private libs statically would roughly
> triple the size of the package.
I wouldn't really worry about 75k each.
If it's something exceeding 1MB, I would start worrying about them.
Did you measure the overhead of shared libraries vs. linking them
statically ? My local source tells me that making shared libs
has some overhead that is significant enough to make my
code 208k when it builds with shared lib (3 shared libs, and 2
binaries) and 170k static.
Considering that being a shared library apparently reduces the
number of available CPU registers on i386 systems, I wonder where the
advantage lies.
> There are plenty of packages using private subdirs of /usr/lib/ to store
> shared libraries, though most seem to access them directly dlopen().
They are different in that they are plugins.
Some just do dlopen for the sake of it, but there are
applications which are dynamically pluggable.
(like LADSPA).
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Re: Handling application private libs
Matt Zimmerman <[EMAIL PROTECTED]> immo vero scripsit: > Sometimes this happens because it makes sense to share the library within > the (to conserve resources), but either: > > - It does not make sense for other programs to use the library (very > specific) But we all know that it is very often untrue :) > - The author is not willing to maintain a stable ABI or version the library > appropriately And we all know that in terms of Debian, they get to keep their ABI for 2 years, at least ... ;P If it is autoconfiscated source, making them not use shared libs is usually only "--enable-shared=no" away... regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> immo vero scripsit:
> Ignoring the irksome ld.so issues for a moment, upstram for this package
> is doing exactly the right thing by putting common functionality out in
> shared libs, even if the only executables sharing them are the ones in
> the package itself. There are 11 executables in this package, of about
> 30k each, plus 3 libs of about 75k each; each executable links against
> two of the libs. Linking the private libs statically would roughly
> triple the size of the package.
I wouldn't really worry about 75k each.
If it's something exceeding 1MB, I would start worrying about them.
Did you measure the overhead of shared libraries vs. linking them
statically ? My local source tells me that making shared libs
has some overhead that is significant enough to make my
code 208k when it builds with shared lib (3 shared libs, and 2
binaries) and 170k static.
Considering that being a shared library apparently reduces the
number of available CPU registers on i386 systems, I wonder where the
advantage lies.
> There are plenty of packages using private subdirs of /usr/lib/ to store
> shared libraries, though most seem to access them directly dlopen().
They are different in that they are plugins.
Some just do dlopen for the sake of it, but there are
applications which are dynamically pluggable.
(like LADSPA).
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling application private libs
Matt Zimmerman <[EMAIL PROTECTED]> immo vero scripsit: > Sometimes this happens because it makes sense to share the library within > the (to conserve resources), but either: > > - It does not make sense for other programs to use the library (very > specific) But we all know that it is very often untrue :) > - The author is not willing to maintain a stable ABI or version the library > appropriately And we all know that in terms of Debian, they get to keep their ABI for 2 years, at least ... ;P If it is autoconfiscated source, making them not use shared libs is usually only "--enable-shared=no" away... regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> immo vero scripsit: > I'm working on a package containing several executables, whose common > functionality lives in a few shared libraries. They're linked in the > usual way at compile time. Policy says they should live in > /usr/lib/packagename/, but I need to make them available for the runtime > linker. What would be the point of restricting the shared libraries to within the software ? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Re: Handling application private libs
Devin Carraway <[EMAIL PROTECTED]> immo vero scripsit: > I'm working on a package containing several executables, whose common > functionality lives in a few shared libraries. They're linked in the > usual way at compile time. Policy says they should live in > /usr/lib/packagename/, but I need to make them available for the runtime > linker. What would be the point of restricting the shared libraries to within the software ? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building packages on unstable for stable
Holger Kubiak <[EMAIL PROTECTED]> immo vero scripsit: > But I have another problem: When I build the package with debuild there is > no problem, when I build with pdebuild, all scripts (one bash, one perl) > in /usr/bin are not executable. diff does not maintain executable bits. So, any file that is in your debian diff will have no executable bit set. It's a common mistake. Set the executable bit in your build, or call them like: /bin/sh some-script. /bin/perl ... -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
