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
> m
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&
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.
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 De
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
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
>
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:
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 ex
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:
>
>
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 looki
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 packa
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.
> > > >
> >
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, exper
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 confi
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 m
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].
> > >>
> > >> Wo
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 th
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.
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
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 sp
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
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 tri
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
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).
Au
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.
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,
> > 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.
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
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
ort.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]
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]
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
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://ww
r 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]
aise.
.
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
atives
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]
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
> 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 syste
> 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 syste
> >
> > 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 se
> >
> > 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 se
>
> > > 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 sui
>
> > > 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 sui
> 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
> 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, emai
> 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, emai
> 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 n
> 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 n
>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
>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
> > 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 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
> 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
> 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
> 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
> 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 doc
> > 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.
> >
> > 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.
> >
> 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?
>
>
> 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?
>
>
> 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
> 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
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/
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/
> 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
> 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 th
> 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 th
> 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
> > > 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
> > > 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
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
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/backwa
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
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/backwa
r 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
ades, 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 Fin
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/
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/li
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 manag
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 manag
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.
reg
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.
reg
> 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 CD3
rs'
> 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 CD3
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.n
hared
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/
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.n
hared
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/
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
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
, 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
1 - 100 of 263 matches
Mail list logo
