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
At Wed, 25 Mar 2009 23:28:30 +0900,
Hideki Yamane wrote:
On Mon, 23 Mar 2009 22:48:47 +0900
Junichi Uekawa dan...@netfort.gr.jp 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
At Mon, 23 Mar 2009 15:06:16 +0900,
Hideki Yamane wrote:
On Mon, 23 Mar 2009 08:28:46 +0900
Junichi Uekawa dan...@netfort.gr.jp 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
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:
Hi,
At Sun, 22 Mar 2009 07:33:09 +0900,
Hideki Yamane wrote:
On Sun, 22 Mar 2009 00:25:42 +0900
Hideki Yamane henr...@debian.or.jp 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
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 dan...@netfort.gr.jp wrote:
It can replace non-free dict package, so please, someone who want
to make Debian more free OS, upload
At Mon, 29 Dec 2008 14:30:04 + (UTC),
Sune Vuorela wrote:
On 2008-12-29, Junichi Uekawa dan...@netfort.gr.jp 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
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
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
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
At Sun, 28 Dec 2008 12:25:24 + (UTC),
Sune Vuorela wrote:
On 2008-12-28, Hiroyuki Yamamoto yama1...@gmail.com 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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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).
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
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
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
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
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
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]
#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]
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]
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
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
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
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
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
--
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]
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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
package.dirs or package.links)?
usr/include/$(SHELLVARIABLE)/foo.h
Why bother using debhelper at all ?
You can use variables in debian/rules all
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
package.dirs or package.links)?
usr/include/$(SHELLVARIABLE)/foo.h
Why bother using debhelper at all ?
You can use variables in debian/rules all
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
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
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
().
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
=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/
().
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
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
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
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
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
On Fri, 20 Sep 2002 00:08:16 +0100
Will Newton [EMAIL PROTECTED] wrote:
The average user shouldn't be running configure with a prefix of /
or /usr, and so the default is what they want. /etc and /usr are
owned by dpkg, so nothing should be installed manually there.
Running ./configure
On Fri, 20 Sep 2002 00:08:16 +0100
Will Newton [EMAIL PROTECTED] wrote:
The average user shouldn't be running configure with a prefix of /
or /usr, and so the default is what they want. /etc and /usr are
owned by dpkg, so nothing should be installed manually there.
Running ./configure
On Sat, 7 Sep 2002 00:04:16 -0300
Carlos Laviola [EMAIL PROTECTED] wrote:
Hi,
A package that I maintain -- mp3blaster -- doesn't include libsidplay1
as a dependency, even though it links against it. I hadn't noticed that
because I thought everything was working fine, as I hadn't tried to
On Sat, 7 Sep 2002 00:04:16 -0300
Carlos Laviola [EMAIL PROTECTED] wrote:
Hi,
A package that I maintain -- mp3blaster -- doesn't include libsidplay1
as a dependency, even though it links against it. I hadn't noticed that
because I thought everything was working fine, as I hadn't tried to
1 - 100 of 232 matches
Mail list logo
