[pnt]
> I tried apt-cache show on sarge & hoary box, cannot find "Tag" entry.
> So you're using unofficial package?
Current sid has this stuff.
signature.asc
Description: Digital signature
[skaller]
> That isn't really possible: the file contains main(), and there could
> be more than one such file which do different things (in fact there
> are, but only one is 'standard' at the moment).
Sounds like a situation similar to 'liby', a helper library for yacc.
It contains a main functi
[skaller]
> Ouch.. main in a library .. well, actually that's an interesting idea
> you describe .. but .. (lol):
Right, there's no inherent reason main can't go in a library, same as
any other global function or variable.
> I don't want to do that because it makes sense only if there is
> reall
[Justin Pryzby]
> If each runtime package Conflicts+Provides+Replaces the virual
> package libgdal, then you will be able to ensure that only a single
> such package is installed.
And that is *far* from optimal. Few things are so annoying as wanting
to install two packages which conflict for rea
[Daniel Leidert]
> Am Sonntag, den 12.02.2006, 20:01 +0100 schrieb Marc Haber:
> > It has now shown to be necessary to apply patches to the upstream
> > docs. I would like to use dpatch for that.
>
> Could you also write a bug-report for dpatch? This is a feature I also
> miss and I would of cour
[Kai Hendry]
> My package webpy has been in the NEW queue for a couple of weeks
...
> Is that for a particular reason, or does it usually take that long?
You're spoiled - it used to be common for packages to sit in NEW for a
month or more. These days the ftpmasters are quite a bit faster.
Still
[Alexander Schmehl]
> - debian/compat: should be set to 5
I'm still using 4 so as not to gratuitously make life harder on anyone
wishing to build my packages on sarge. The changes from 4 to 5 don't
appear to provide much, if any, benefit to my packages. After etch, I
suppose I'll switch to 5.
[Richard Laager]
> If I follow those steps, I'm making a bunch of changes in the source
> directory of the package, which creates a big diff [1]. Is that
> really the best way? Should I instead run those commands as part of
> the package build process?
I do this stuff at build time.[1]
Many peop
[Neil Williams]
> When a package (foo-1.2.3-1) is in the NEW queue and one finds a rather
> annoying typo that really ought to be fixed ... :-)
>
> after fixing the typo, preparing a package and testing, do I need to
> build using -sa ?
Pretty sure you do not need -sa, but you should consider -v
[Andy Hawkins]
> I think I'd prefer libmb5.so, as it maintains consistency with the
> libmb3 packages.
>
> It's also clearer to the person installing it exactly what they're getting.
> Otherwise, the libmb3 packages would have been called libmusicbrainz-6,
> which doesn't obviously tell them
[Muammar El Khatib]
> In most recent upstream version, when you compile it you will get this
> instead:
>
> libCEGUIBase-0.7.0.so
> libCEGUIBase.la
> libCEGUIBase.so
That looks fine. If you look closely you will probably see that
libCEGUIBase.so is a symlink to libCEGUIBase-0.7.0.so.
> So I c
[Luis R. Rodriguez]
> BTW -- while we're on the topic of 2.6.32 and the next Debian
> release, and 802.11, do you guys ship iw by default yet?
It's available (version 0.9.14), but not shipped by default.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "uns
cates that this sort of flexibility is possible.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100327182129.gv18...@p12n.org
e. If library 'bar'
is not reentrant and has shared state, this shared state will affect
functionality used by both your base program and library 'foo'.
This is all within a single process. Multiple processes don't affect
each other unless, as others have noted, you ex
[Carlos Borroto]
> g++ -Wall -Wno-strict-aliasing -march=i686 -O3 -g -O2 -DNDEBUG
> -I/usr/include/seqan -Wall -Wno-strict-aliasing -march=i686 -O3 -g -O2
> -DNDEBUG -Wl,-Bsymbolic-functions -L/usr/lib -o gtf_to_fasta
> GTFToFasta.o FastaTools.o ../src/libtophat.a libgc.a -lbam -lz -lz
> GTFToFa
[Peter Samuelson]
> What appears to be happening is that "config.h" wants to define some
> stuff that affects how the off_t data type is interpreted, but this
> fails to happen if you include certain system headers before you define
> the LFS symbols (I'm talking
[Nico Golde]
> i don't understand why you can't use gpg for these things.
> regards nico
Likely because gpg wraps data in OpenPGP packets, which is not much
good when you want to just produce a raw encrypted stream, like for a
loopback partition.
It does seem as though "openssl enc -aes-128-cbc"
[Max Vozeler]
> Yes, that's pretty close for general encryption purposes. aespipe
> also understands the combination of hashing algorithms that loop-AES
> uses for different key sizes and supports its multi-key IV
> initialisation mode. These settings are difficult if not impossible
> to get right
[Bob Proulx]
> There appear to be three cases.
>
> 1. The developer wrote the Makefiles by hand and did not supply any
>support for DESTDIR natively.
Actually there is also:
1a. The developer wrote Makefiles by hand, but also happens to have a
clue, so at some point added DESTDIR su
[Sebastian Kuzminsky]
> Before 0.10, the upstream installed both the binaries (actually shell
> scripts) and the shell libraries in /usr/bin. Starting with 0.10,
> the shell libraries are moved to /usr/lib/cogito.
Correct, except that it should be /usr/share/cogito/.
Thanks for packaging this.
[Nico Golde]
> i don't understand why you can't use gpg for these things.
> regards nico
Likely because gpg wraps data in OpenPGP packets, which is not much
good when you want to just produce a raw encrypted stream, like for a
loopback partition.
It does seem as though "openssl enc -aes-128-cbc"
[Max Vozeler]
> Yes, that's pretty close for general encryption purposes. aespipe
> also understands the combination of hashing algorithms that loop-AES
> uses for different key sizes and supports its multi-key IV
> initialisation mode. These settings are difficult if not impossible
> to get right
[Bob Proulx]
> There appear to be three cases.
>
> 1. The developer wrote the Makefiles by hand and did not supply any
>support for DESTDIR natively.
Actually there is also:
1a. The developer wrote Makefiles by hand, but also happens to have a
clue, so at some point added DESTDIR su
23 matches
Mail list logo
