ry and put some
trace of work in the BTS.
It is pretty difficult to see if the person is doing anything useful.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
tems.
> struct.h says:
> | #ifndef MAXPATHLEN
> | # define MAXPATHLEN 1024
> | #endif
[everything else dropped]
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
hing more than -O2 has problems on some
architectures, and it is not advisable to use anything more than
-O2 unless you know what you are doing.
> > o are you sending the mods to the upstream ? / have you
> > contacted the upstream ?
> Not yet.
Please do.
Reducing the -Wall warning
in debian/rules.
I think all it does is set DEB_BUILD_OPTIONS="...", unset,
and then run debuild.
But that is talking about shell.
Try testing this snippet:
muha.sh:
#!/bin/sh
echo $MUHA
and on the command-line run:
$ MUHA="fuu" muha.sh
fuu
$ MUHA="fuu" && muha.sh
regards.
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
.
>
> And perhaps a doc package but it would be really small.
I might be missing something, but what is the soname for
libgphoto2 ?
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
/usr/lib/libgphoto.so.2.0.0 or something similar
libgphoto2-dev Package would probably contain
/usr/lib/libgphoto.so which is a symlink to
/usr/lib/libgphoto.so.2, and etc. etc. etc.
The soname is the number "2" in this case
(but I have not looked at libgphoto2 to check)
regards,
BLE to the script ?
I've accompanied myself with a testing script to
check that behavior as well, have you tried running it?
> Can you please explain me what I'm missing ?
That's what I want to know too.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
ified otherwise in the command-line.
Maybe he was just talking about shell constructs.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
e my package ok both for the former
> and the newer version of the ocaml package.
If that is the case, it should be enough to specify ocaml (>= version)
with high-enough version number (which includes the previous camlp4).
At least from the information given from your mail.
regards,
build, and /etc/sbuild should have been
somewhere like /usr/share/sbuild/sbuild.default.conf.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
owitz-config in diff.gz?
Binary package names are incorrect, name them
"lib"mowitz0 and "lib"mowitz-dev
The source package name is fine.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
;s the case, I also have doubts whether it should be
called libmowitz"0"
Are you sure of the soname version number?
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
1 root root 296592 13 mar 18.42
> /usr/lib/libMowitz.so.0.2.0
>
> And the version number of the package is 0.2.0 as well.
That sounds like a bad news, a potential sign of
upstream changing binary interface between 0.1.0 and 0.2.0
regards,
junichi
--
[EMAIL PROTECTED] : Jun
incompatible change to the library, and call it
0.3.0 (well, it's only natural).
However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Finge
ign of a changed interface are:
o random segfault
o irrational behavior
regards,
junihi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
however, be changes in the source
which does affect.
I don't know if there could be a systematic way to do it.
Warning might be possible, but not strict and real checking.
Lintian won't be able to do this, because lintian only has access
to one version of source at the tim
Junichi Uekawa <[EMAIL PROTECTED]> cum veritate scripsit:
Well, now I updated the doc a little bit, I'll post it here.
I've received exactly one response so far, and I'm feeling a bit
naive about the contents of this document.
Please comment:
Library packaging Guide (very m
On Wed, 3 Apr 2002 00:07:47 +
"David H. Askew" <[EMAIL PROTECTED]> wrote:
>
> Ok.. so i'm working on packages for jedit .. and I'm contemplating
> splitting the documentation into its own sepperate package.
That I would object.
Splitting the docs when it doessn't have to happen, it not us
On Fri, 5 Apr 2002 15:04:41 +0200
Russell Coker <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Apr 2002 14:42, Stefan Schwandter wrote:
> > I know that policy recommends not to use uppercase letters in package
> > names, but I'd like to package jack (jackit.sourceforge.net).
> > Unfortunately, there alrea
n't really need to care about python-version compatibility,
do they ? Their primary aim is to write code that works for them, not
write code that works on both.
maybe I am wrong, I don't code in python (yet).
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://
Maintainer [EMAIL PROTECTED] -sPackage| awk '{sum+=
length($2); i ++} END{print sum / i }'
12.3125
grep-available -FMaintainer [EMAIL PROTECTED] -sPackage| awk '{sum+=
length($2); i ++} END{print sum / i }'
10.3571
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Ue
rkings of tcl/tk, but they are
provided as shared libraries. I've got an impression
that it will cause problems.
For example, try compiling against tck/tk 8.3, and remove
8.3 and install 8.0, and then run the program.
The program should fail to start.
regards,
junichi
--
[E
a script to do that.
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
Should "package" depend on exactly the
> same version of "package-data"?
Why do you have to make it a symlink at all ?
By doing that you are distributing a .deb file
which does not contain copyright information, etc.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi U
do with providing a symlink to usr/share/doc/package
that's a maintainer decision.
> > Don't just split without good reason.
>
> Just making sure one of the good reasons was seen in the discussion.
Trying,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://
having -x version when there is -sdl version ?
(is both of them maintained in a good shape or is only one of them?)
Note: Splitting packages up causes more work, and maintenance
cost.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerp
that will
(seeing that it is unmaintained) probably decay to unusability.
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
erent file when it was compressed
at a different time.
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 Mon, 10 Jun 2002 08:24:39 +0200
Eric Gentilini <[EMAIL PROTECTED]> wrote:
Hi,
> Considering a given library libfoo, which of another version supporting
> multithreading is available, called libfoo-mt.
> libfoo-mt offers all the functionnalities offered by libfoo and programs
> compiling with l
ION@ -version-info 0:0:0
to Makefile.am should create something reasonable for an unstable shared
library, suggest using this for the upstream (if they do versioning at all).
But I suggest reading libtool/autoconf/automake manual a bit.
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa
> I have had a similar problem and solved it by exporting a LIBRARY_PATH
> variable during the install step :
>
> replacing
>$(MAKE) install ...
> by
>export LIBRARY_PATH=`pwd`/debian/tmp/usr/lib; $(MAKE) install ...
>
> NOTE : LIBRARY_PATH not LD_LIBRARY_PATH.
>
Hmm... this hack se
rong Makefile.am
Add it somewhere with libiiwusynth_la_SOURCES are defined.
--
[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 UNSU
gelse.c other.c
libtarget.whatever.so: ${sources:.c=.lo}
libtarget.a: ${sources:.c=.o}
%.lo: %.c
gcc -fPIC ..
%.o: %.c
gcc
regards,
junichi
--
[EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 C
you have not already
read it, is in my sig.
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 UNSUBSCRI
ss arguments to
> dpkg-genchanges.
Try something like:
DEBBUILDOPTS=-sa
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 Wed, 21 Aug 2002 14:53:54 -0700
Matt Kraai <[EMAIL PROTECTED]> wrote:
> Here are the solutions I've considered:
>
> * merge them into one source package. This would diverge from
>upstreams distribution model.
There are many examples of putting multiple source packages
in one Debian sou
On Mon, 19 Aug 2002 21:40:16 -0400
David Z Maze <[EMAIL PROTECTED]> wrote:
> >> I think you need root privileges to actually enter the chroot jail.
> >> Other than that, it does seem like it should be possible to build the
> >> chroot image entirely in a fakeroot world, but I remember having tried
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 trie
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
, 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
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
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
> 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
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 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
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/
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
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
> > > 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
> 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
> 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
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/
> 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
> 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?
>
>
> > 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.
> >
> 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
> 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
> 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 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
>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
201 - 263 of 263 matches
Mail list logo
