Hi,
The author of one of the packages I was packaging for
my own use has asked me to be the maintainer of the
debian's package. The problem that I found is that in
latest versions he includes his own version of
debian's directory inside the original tar.gz file as
you download it from the web.
Hi,
I'm doing my 1st packaging of a python script. It's a
program called cycle thas uses wxpython libraries and
it's distributed under GNU General Public License.
Cycle is a calendar program for women. Given a cycle
length or statistics for several periods, it can
calculate the days until
--- Charles Majola [EMAIL PROTECTED] wrote:
I request a sponsor for the drip package.
Description: GNOME application for encoding a DivX
from a DVD
Drip is a DVD to DivX conversion application. It's
made up out two
applications: a DVD reader and a DivX encoder. The
reader is a GUI for
--- Alexandre [EMAIL PROTECTED] wrote:
This is for python modules that you want to be
imported from other
modules/application. For standalone application,
the
policy says that
/usr/share/appname or /usr/lib/appname is fine
(depending on the
presence of C coded extension modules)
Thanks!
--- Adeodato Simó [EMAIL PROTECTED] wrote:
Still, is a warning. Miriam, perhaps you should
ask upstream to change
0x950412de to 0x950412deL or similar.
Yes, I'm concerned about it even when it's a warning.
I've sent an email upstream this morning commenting
that problem (and also sending
There are two problems with this: Security and
DFSG-freeness.
I wouldn't put too much weight in the security
thing. If you don't
understand postscript or pdf, you won't detect the
exploit - it doesn't
matter if it is in the ps/pdf file, or in a \special
command in the
LaTeX/Lyx
--- Justin Pryzby
[EMAIL PROTECTED] escribió:
PDF can be trojaned, so you should at least
*provide* a way to
generate them from their sources, even if that
makefile rule is not
called by default, and the additional
build-dependencies are just a
note in debian/rules.
In case only PDF
--- Justin Pryzby
[EMAIL PROTECTED] escribió:
Good you saved a 10k:). Really, though, you saved
yourself a few
files, which is nice.
Yep, thanks for your advice, it was really valuable :)
I'm in contact with upstream author now so he can give
me a clue about the program's internals and
--- Justin Pryzby
[EMAIL PROTECTED] escribió:
On Sun, Feb 06, 2005 at 07:36:42AM +0100, Miriam
Ruiz wrote:
Yep, you were right, I had to link all the
objects.
Thanks for the clue!! :)
Cool; can you give us a comparison of the relative
sizes of the
packages? Compiling statically
--- Justin Pryzby
[EMAIL PROTECTED] escribió:
If I understand correctly, he intends that the
entire library is
included in the executable, but nowhere else. Then,
when the
executable dlopen()s a plugin .so, all the symbols
are already
statically linked into the exe and don't depend on
But if the plugins are only loaded by maserver, you
don't need to link the
plugins against libmaserver *at all*, statically or
dynamically. This was
the point from my earlier message.
If you statically link libmaserver into maserver,
you get a minimal
*reduction* in the total install
Try lintian -i: you'll see this type of thing:
A shared object was identified in a library
directory
(i.e. a directory in the standard linker path)
which
doesn't have a SONAME. This is usually an error.
Thanks, yes it seems that the lintian error means what
you're saying.
Hi,
I'm trying to package a program named maserver (
http://www.babichev.info/en/projects/maserver/index.html
), which is an audio streaming server for LAN and
internet.
The file structure resulting from install (with some
tweaks) is right now:
Configuration files:
etc/maserver/*
Binary:
It's true that you usually should not have shared
libraries in an
application package, but that is not the meaning of
this error. This error
means that the file that you have placed in /usr/lib
is *not a shared
library*. If the file does not declare an SONAME,
it's not a shared library
I've just made a new package: Stellarium Astronomy
Software
Stellarium is a free GPL software which renders
realistic skies in real time with openGL. It is
available for Linux/Unix, Windows and MacOSX. With
Stellarium, you really see what you can see with your
eyes, binoculars or a small
--- Justin Pryzby
[EMAIL PROTECTED] escribió:
On Sat, Jan 01, 2005 at 02:43:31AM +0100, Miriam
Ruiz wrote:
I've just made a new package: Stellarium Astronomy
Software
Hi Miriam,
You might also be interested in SkyChart:
http://handhelds.freshmeat.net/projects/skychart/
Its
, or maybe I should write
to the original maintainer.
Thanks,
Miry
--- Henrique de Moraes Holschuh [EMAIL PROTECTED]
escribió:
On Sat, 01 Jan 2005, Miriam Ruiz wrote:
Thanks, i'll try to find it. I couldn't find it in
http://packages.debian.org/, and the only package
i
found for that program
Hi,
I've just finished a new package: Avida.
It is an artificial life simulation program based on
Tierra. It is a joint project of the Digital Life
Laboratory (headed by Chris Adami) at the California
Institute of Technology and Richard Lenski's
Microbial Evolution laboratory at Michigan State
--- Florian Ernst [EMAIL PROTECTED] escribió:
Hello Miriam, hello list!
Hi!! Lots of thanks for your comments! :)
There is a RFP filed at
http://bugs.debian.org/282153. In order to
prevent duplicated effort in packaging, please
retitle the bugreport
as your packaging seems to be quite
Hi,
This is the 1st time I write to this list, so I guess
I should introduce myself. My name is Miriam, I'm from
Spain, and, even though I've been using Debian for
some time, I've recently started to try to make my own
packages.
One of them is almost finished. It's called
xdesktopwaves, and its
--- Ricardo Mones [EMAIL PROTECTED] escribió:
Mine (Lintian v1.23.5) does twice:
Thanks I've removed the dependencies on gcc and
libc6-dev
Also fails to build at first because debian/rules
is not executable,
but after chmod'ing it builds and runs fine. Nice
toy :)
Corrected that too.
101 - 121 of 121 matches
Mail list logo
