Michael Pobega [EMAIL PROTECTED] wrote:
it's GREATLY increasing the noise:signal
ratio for people who don't know about ignore thread or other such things.
It doesn't bother me personally (like I said I've found some of the messages
in this thread quite interesting... and if I don't feel
Steve Lamb [EMAIL PROTECTED] wrote:
Who gives a shit about politics, and what the hell has it it got to do with
the debian mailing list???
It's the Debian *USER* list, not the *DEBIAN* User list. As has been
discussed several times every time a long thread comes up the list is for the
Steve Lamb [EMAIL PROTECTED] wrote:
I use mutt in non-threaded mode so I have no idea. :-)
So the list should adjust itself to how you read mail?
A list that the debian organization reccomends for new debian users to go
to seek help should be as accomodating to that goal as possible,
Brandon Barnes [EMAIL PROTECTED] wrote:
Are we allowed to disable compiler warnings? What is the preferred
method, if the code is fine, and would require a huge overhaul to fix?
IANADD
However, my feeling is, the less change to a package you have to do to get
it working, the better. If the
Francesco Pedrini [EMAIL PROTECTED] wrote:
After the inspection of the new code and the discover of the new library
I have a problem with the design of the new package structure, because
if I follow the splitting scheme written above I'll have:
kmobiletools - the real application;
Francesco Pedrini [EMAIL PROTECTED] wrote:
Ok, then I will have:
kmobiletools
libkmobiletools
libkmobiletools-dev
and kmobiletools-plugin-kontact.
It seems fine, I can always split the phone engines in a separated
package when the GAMMU engine (and maybe others) will be added, I'm
Martin Zobel-Helas [EMAIL PROTECTED] wrote:
apt-get install hercules.
and then:
http://kitenet.net/~joey/blog/entry/giving_s_390_a_try.html
It worked! I was able to not only build mod_bt under a virtual
s/390, but actually get it up and running and test a few .torrents on it.
:-)
Please see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378375
I would like to test this bug fix on a s390 box before uploading it. Except
I don't have access to an s390 box. :-/ I asked Bastian if he would be
willing to test this before I get my sponsor to upload, but he hasn't
Bart Martens [EMAIL PROTECTED] wrote:
What's the Debian way of handling this? I know that if I upload the new
package to unstable, it will at least be no worse than the previous version,
but it also seems like a waste of time to upload it if it just has more
problems under the s390 arch.
Adeodato Simó [EMAIL PROTECTED] wrote:
http://buildd.debian.org/build.php?pkg=mod-bt
You'll see that it failed in five more architectures (mips powerpc sparc
hppa m68k). In this case in particular, seems like all the big endian
ones. :-)
Aaahh very useful page, thanks :)
My
Martin Zobel-Helas [EMAIL PROTECTED] wrote:
but it also seems like a waste of time to upload it if it just has more
problems under the s390 arch. Should I continue attempting to find an s390
box, is there something somebody out there can do to help, or should I just
have my new packages
Bastian Blank [EMAIL PROTECTED] wrote:
Package: mod-bt
Version: 0.0.18+p4.1178-1
Severity: serious
There was an error while trying to autobuild your package:
Automatic build of mod-bt_0.0.18+p4.1178-1 on lxdebian.bfinv.de by
sbuild/s390 85
[...]
** Using build dependencies supplied
Bastian Blank [EMAIL PROTECTED] wrote:
On Sun, Jul 09, 2006 at 10:10:37AM -0700, Tyler MacDonald wrote:
apache2-prefork-dev depends on libapr0-dev which conflicts with
libapr1-dev.
But that should be fine, since I depend on libapr1-dev *or*
libapr0-dev, shouldn't it? pbuilder
Asheesh Laroia [EMAIL PROTECTED] wrote:
But if I have to remove the apr1 | apr0 sutff, then a new version of
mod-bt (and every other apache2 module) will be neccessary when the switch
to 2.2 happens.
In theory you could just switch the order of apr1 | apr0. But I agree
that this is less
Kurt Roeckx [EMAIL PROTECTED] wrote:
Yes, name it libapr-dev. If something really can use either one
of the 2, I don't see why you should make a transition so hard
and go and name it libapr0-dev.
So I suggest you rename libapr0-dev to libapr-dev and make it
provide libapr0-dev for now.
Michael Stevens [EMAIL PROTECTED] wrote:
How do I setup pbuilder to manage this? when I try to just do
'pbuilder create', it gives the error:
E: Couldn't download slang1a-utf8
pbuilder: debootstrap failed
I've got it working using '--distribution sarge', which is nice for
checking the
Steve Langasek [EMAIL PROTECTED] wrote:
I have found that it is easier to have machines running each distro
you want to build against, but it shouldn't be neccessary. Try a
--distribution etch though; something that builds under etch should still
run under sid.
And no, you should
I just created a /usr/local/include/hi_there.h , #include'd it from a header
file, and built a -dev debian package containing that header file without
any sort of warnings or errors.
So it's really easy to package a -dev package with a header file, that
#include's a header file in a package that
tony mancill [EMAIL PROTECTED] wrote:
packaging of the policy, that URL's have passed by now. But what I guess
you mean is the changes between policy versions, i.e. what you need to
change to upgrade a package's standards-version. That information is
in
Tyler MacDonald [EMAIL PROTECTED] wrote:
They really should state that if it is their intention. A lot of
those builder type programs do it, such as auto* bison and dh-make
(I changed it after someone pointed out the problem with not having
the specific exception).
Fair enough
Craig Small [EMAIL PROTECTED] wrote:
reluctant to do this. Too much information kills information.
I don't for any of my autoconfed packages. The output files have
do whatever type of license, as does most output files of this type.
This makes me wonder about ppport.h in perl-XS
Craig Small [EMAIL PROTECTED] wrote:
However, if you run perl ppport.h --strip, all documentation *and*
licensing information was removed. My feeling is that if the authors of
Devel::PPPort allow the license to be removed (while still leaving other
comments intact in the header file),
mod_bt is now bundling Nik Clayton's libtap, an excellent little unit
testing module. This module is only used by mod_bt during a make check,
and is not installed (and not even used by the debian build process).
The conditions for redistributing libtap are,
* Redistribution and use in source
I have just finished getting Nik Clayton's libtap module debianized. It's a
*really* simple unit testing module (lib+dev package = 13k) with no
dependancies except libc, and I'm pretty sure I've got the debian/ directory
right. The built .deb's are here:
http://www.yi.org/~faraway/libtap/
ugh... I just realized I put the wrong bug # in both my previous email and
in the actual debian package I uploaded. The actual ITP 375014, and I've
uploaded new .deb's to the site below. Sorry for the confusion. :-/
- Tyler
Tyler MacDonald [EMAIL PROTECTED] wrote:
I have just finished
Laszlo Boszormenyi [EMAIL PROTECTED] wrote:
Agree. Also, binary ones sounds better for me; or if someone would like
to reinvent the wheel, then please do it in Python instead of Perl.
I certainly hope this is just your opinion and isn't official debian
advice...
-
Redefined Horizons [EMAIL PROTECTED] wrote:
I want to install a Debian package named Package A.
Package A lists as a dependency another Debian package named Library A.
However, if Package A requires version 2.0 of Library A, while another
Debian package I have installed on my system, named
Redefined Horizons [EMAIL PROTECTED] wrote:
Tyler,
What is the proper procedure for notifying the maintainer of a package about
the dependency problem?
A good way is to use the reportbug utility that comes with debian;
reportbug offending package's name.
Cheers,
I can't find a consistent rule for what should go into man1 vs. man8. For
instance, apt-get can be used as an unprivileged user to download source
tarballs, but it's in man8, whereas defoma-reconfigure, which can only be
run as root, is located in man1.
Under debian, bt_xml2db and bt_db2xml will
Thijs Kinkhorst [EMAIL PROTECTED] wrote:
This isn't 100% clear for every case. Of course, when a package is
solely useful to the system administrator to do system administrative
tasks, it should belong in 8, and if it's neither of those it's in 1.
But there's a lot in between like the examples
Benjamin Mesing [EMAIL PROTECTED] wrote:
find release/$(deb_dir_name) -type d -name CVS | xargs rm -rf
You know about cvs export? This would spare you to having to delete
the CVS directories.
But using cvs export also means I'd have to check-in every change I
want to test,
I'd like to build my debian packages out of my repository, so I've added the
following in my debian/rules... Is there a better, standardized way to do
this? (I've already looked at cvs-buildpackage, but I want to move away from
CVS sometime in the near future...)
Thanks,
gregor herrmann [EMAIL PROTECTED] wrote:
There are helpers for other version control systems, too:
$ apt-cache search --names-only .*-buildpackage
arch-buildpackage - tools for maintaining Debian packages using arch
cvs-buildpackage - A set of Debian package scripts for CVS source trees.
Tyler MacDonald [EMAIL PROTECTED] wrote:
$ /usr/bin/apxs2 -q LIBEXECDIR
/usr/lib/apache2/modules
Yet on my work system, lintian complains with that. On my home system, both
with pbuilder and just plain debuild, the warning does not appear.
This is confusing me. On my home system, I've
Russ Allbery [EMAIL PROTECTED] wrote:
The separate debian/ directory is sort of a psychological
separation of hats that keeps it clearer that I may not always and forever
wear both hats.
The idea of a --with-debian-policy configure script argument
occured to me today; having that
Russ Allbery [EMAIL PROTECTED] wrote:
Tyler MacDonald [EMAIL PROTECTED] writes:
Anyways, I've successfully moved to a non-native package and removed
all lintian warnings, except one that shows up on my work machine, but not
on my home machine:
W: libapache2-mod-bt: binary-or-shlib
Russ Allbery [EMAIL PROTECTED] wrote:
However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's
probably a problem. In general, the string /usr/local should not appear
anywhere in your build for Debian packages.
It doesn't, and apxs2's reply is the same on both systems:
$
I'm working on creating .deb packages for one of my projects, with the
eventual goal of having it included in the debian distribution.
I've browsed through the policy manual, new maintainers guide, etc, and I've
successfully created a debian/ directory in my project that allows debuild
to
Thijs Kinkhorst [EMAIL PROTECTED] wrote:
Just include no manpage at all. Don't silence Lintian for it, because man
pages need to be made eventually. However, will the binaries really change
that much that it creating man pages would be wasted effort? Just some
general documentation is already
Justin Pryzby [EMAIL PROTECTED] wrote:
4. W: libbtt: non-dev-pkg-with-shlib-symlink usr/lib/libbtt.so.0.0.0
usr/lib/libbtt.so
Should I care?
Is it a public shared library? (Do other packages link to it?) If
not, you can/should try to move it out of /usr/lib.
It's
Russ Allbery [EMAIL PROTECTED] wrote:
The general rule of thumb is that if there is any intention whatsoever
that the package be used on a platform other than Debian, the Debian
packaging and the upstream source should be separate.
Okay, so what do you guys do about upstream sources
Maxim Vexler [EMAIL PROTECTED] wrote:
If so where can I learn more about stripping I've tried to search the
Debian developers reference guide and the gcc online documentations, as
well as google but no useful information has turned up.
Check out the strip manpage. :-)
When an
Hello,
I'm working on debianizing my apache2 module
(http://www.crackerjack.net/mod_bt/). My hope is to eventually become a
debian package maintainer and supply debian with this apache2 extension.
I've gotten the core shared libs and apache2 handler done, and now it's time
for me to do
Matthew Palmer [EMAIL PROTECTED] wrote:
- change --with-php-config in my configure script to
--with-php4-config and --with-php5-config, which would do the exact same
thing, only twice. :-)
- build that part of the source tree twice with two
different sets of
44 matches
Mail list logo
