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 possibl
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 f
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 do
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:
> 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
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;
>
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.
:
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 pa
Martin Zobel-Helas <[EMAIL PROTECTED]> wrote:
> apt-get install hercules.
>
> and then:
> http://kitenet.net/~joey/blog/entry/giving_s_390_a_try.html
> http://blog.zobel.ftbfs.de/stuff/installing-debian-sarge-on-s390
Thanks, I'll give it a shot :) (BTW, love your domain name, and the
ir
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 :
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 s39
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
repl
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
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
> checki
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 n
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
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 *
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 depende
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 i
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 /usr/share/doc/debian-polic
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
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 hea
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 per
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 a
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]> wrot
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/
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...
- T
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 ".
Cheers,
Tyler
--
To
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
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 exa
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 wi
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,
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 tree
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,
Ty
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.
>
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:
$ /us
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
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:
> 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 source
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.
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 alr
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 produ
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. :-)
Wh
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
> > d
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 the
45 matches
Mail list logo
