Greetings,
* Joseph Herlant (herla...@gmail.com) wrote:
> I'm currently maintaining a few packages and am looking for one or two
> DD around Berkeley/Oakland/San Francisco in California that would be
> willing to meet in order to sign my gpg key so I can go ahead and
> start the DM process.
I'll
* Neil McGovern (ne...@debian.org) wrote:
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
57dd4d7c-3e92-428f-8ab7-10de5172589e
[ 5 ] Choice 1: Packages may not (in general) require a specific init system
[ 3 ] Choice 2: Support for other init systems is recommended, but
* Thorsten Glaser (t...@mirbsd.org) wrote:
(But it was
nice to have a published list of those people who maybe could
accidentally be hit by a tactical small-bus…)
These comments are not necessary nor appropriate, ever.
Thanks,
Stephen
signature.asc
Description:
Olivier,
Because -h is slow hardly seems like a good justification for having
static packages. Last I checked (which wasn't long ago..), BLAST is
typically a long-running process (at least on the stuff we're doing..).
Also, are subsequent calls (even '-h' ones) faster? I'd expect them to
be,
PROTECTED]
Changed-By: Stephen Frost [EMAIL PROTECTED]
Description:
libpostgis-java - geographic objects support for PostgreSQL -- JDBC support
postgis- geographic objects support for PostgreSQL -- common files
postgresql-8.2-postgis - geographic objects support for PostgreSQL 8.2
Closes: 419297
* Shaun Jackman ([EMAIL PROTECTED]) wrote:
64-bit: alpha amd64 ia64
mips/mipsel, sparc, s390 and powerpc can all come in a 64-bit
flavors, iirc.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Tue, Nov 28, 2006 at 02:41:13PM -0700, Shaun Jackman wrote:
64-bit: alpha amd64 ia64
The rest are 32-bit.
Am I missing any?
Nope.
*smirk
Perhaps this is a suitable feature for dpkg-architecture.
You could just as well do a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 22 Oct 2006 19:19:59 -0400
Source: libnss-ldap
Binary: libnss-ldap
Architecture: source amd64
Version: 251-6
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 3 Nov 2006 21:46:02 -0500
Source: libnss-ldap
Binary: libnss-ldap
Architecture: source amd64
Version: 251-7
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
* martin f krafft ([EMAIL PROTECTED]) wrote:
also sprach Stephen Frost [EMAIL PROTECTED] [2006.10.31.2103 +0100]:
How are certificate files not intended to be modified? If they
expire? If they are incomplete?
If they expire then they should be updated by the package.
The problem
* martin f krafft ([EMAIL PROTECTED]) wrote:
Since #350282 is still being discussed, I ended up doing
cat /etc/ssl/certs/cacert-class3.pem /etc/ssl/certs/cacert.pem
on systems that needed access to all of CACert's certificates.
cat /my/favorite/editor /etc/alternatives/vi
cat
* martin f krafft ([EMAIL PROTECTED]) wrote:
also sprach Stephen Frost [EMAIL PROTECTED] [2006.10.31.1948 +0100]:
cat /my/favorite/editor /etc/alternatives/vi
alternatives are surely an exception, don't you think?
cat /the/best/dictionary /etc/dictionaries-common/words
I don't see
* martin f krafft ([EMAIL PROTECTED]) wrote:
also sprach Stephen Frost [EMAIL PROTECTED] [2006.10.31.2016 +0100]:
In all of these cases the files pointed to are not intended to be
modified but what file is used can be configured.
How are certificate files not intended to be modified
* Marco d'Itri ([EMAIL PROTECTED]) wrote:
On Aug 11, Adam Borowski [EMAIL PROTECTED] wrote:
Why, for the love of Cthulhu, does netbase depend on inetd in the first
place? Let's see:
Historical reasons.
Not good enough. Not even close.
It would be good to get rid of inetd from the basic
* John Goerzen ([EMAIL PROTECTED]) wrote:
On Thu, Jul 06, 2006 at 02:39:16PM +0300, Pasi Kärkkäinen wrote:
Not always true. Both paths can be active at the same time.. if supported by
the SAN array. Then you do also load balancing between the paths..
Quite true, though my impression is
@lists.alioth.debian.org
Changed-By: Stephen Frost [EMAIL PROTECTED]
Description:
libpostgis-java - geographic objects support for PostgreSQL -- JDBC support
postgis- geographic objects support for PostgreSQL -- common files
postgresql-8.1-postgis - geographic objects support for PostgreSQL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Jun 2006 14:03:21 -0400
Source: libnss-ldap
Binary: libnss-ldap
Architecture: source amd64
Version: 251-4
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Jun 2006 14:53:29 -0400
Source: libnss-ldap
Binary: libnss-ldap
Architecture: source amd64
Version: 251-5
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 23 Jun 2006 23:11:24 -0400
Source: libnss-ldap
Binary: libnss-ldap
Architecture: source amd64
Version: 251-3
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 22 Jun 2006 10:01:07 -0400
Source: libnss-ldap
Binary: libnss-ldap
Architecture: source amd64
Version: 251-1
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 22 Jun 2006 21:59:20 -0400
Source: libnss-ldap
Binary: libnss-ldap
Architecture: source amd64
Version: 251-2
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
* Manoj Srivastava ([EMAIL PROTECTED]) wrote:
On 25 May 2006, Stephen Frost spake thusly:
I wasn't making any claim as to the general validity of IDs which
are purchased and I'm rather annoyed that you attempted to
extrapolate it out to such. What I said is that he wasn't trying to
fake
* Manoj Srivastava ([EMAIL PROTECTED]) wrote:
Explanation? What we have here is an act of bad faith, in the
guise of demonstrating a weakness. In my experience, one act of bad
faith often leads to others.
pffft. This is taking it to an extreme. He wasn't trying to fake who
he was,
* Manoj Srivastava ([EMAIL PROTECTED]) wrote:
On 25 May 2006, Stephen Frost verbalised:
* Manoj Srivastava ([EMAIL PROTECTED]) wrote:
Explanation? What we have here is an act of bad faith, in the guise
of demonstrating a weakness. In my experience, one act of bad faith
often leads
* Anthony Towns (aj@azure.humbug.org.au) wrote:
On Sun, May 21, 2006 at 06:14:51PM +0200, Michael Meskes wrote:
On Sat, May 20, 2006 at 04:18:44PM -0500, Anthony Towns wrote:
Anyway, the background is that James Troup, Jeroen van Wolffelaar and
myself examined the license before accepting
* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
On Mon, May 22, 2006 at 08:01:34AM +0200, Juergen A. Erhard wrote:
On Sun, May 21, 2006 at 03:55:53PM -0700, Steve Langasek wrote:
[...] They didn't ask you because Debian is not a democracy and random
opinions on this decision *don't* matter.
* Florian Weimer ([EMAIL PROTECTED]) wrote:
* Nathanael Nerode:
(2) Upstream status.
There hasn't been a new upstream for sysklogd since 2001.
All of the others are active upstream.
Have you checked if SuSE's syslog-ng is heavily patched? If it's
mostly alright, it's probably a good
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
But regarding the build system, I REALLY object to any major changes! Fixes
yes,
but not REPLACEMENT!!
Uhh, or, not... Sorry, but the build system was terrible and is
certainly something which should not be encouraged.
I'd encourage you to look
* Aurelien Jarno ([EMAIL PROTECTED]) wrote:
The FHS is actually not very clear, as it says 64-bit libraries should
be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib.
This is a contradiction for a pure 64-bit system.
The FHS is very clear about the path to the 64bit linker,
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
Quoting Stephen Frost [EMAIL PROTECTED]:
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
But regarding the build system, I REALLY object to any major changes!
Fixes yes,
but not REPLACEMENT!!
Uhh, or, not... Sorry, but the build system
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
You keep saying that, without showing the problems. From what I can see,
all you say is it's wrong, it's very wrong and there's major problems
with it.
John pointed out the issues to it earlier in this thread, which you said
you had followed so I
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Thu, May 18, 2006 at 10:09:28AM +0200, Frans Pop wrote:
If you really have urgent reasons to get a package into new, the best
action is probably to send a mail to debian-release and to present these
reasons.
Please don't abuse the release
* Riku Voipio ([EMAIL PROTECTED]) wrote:
On Thu, May 11, 2006 at 03:05:17PM +0300, Riku Voipio wrote:
On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote:
The package has bugs, lots of them, and for that reason has been removed
from testing, well done, unstable it is here
* Roberto Lumbreras ([EMAIL PROTECTED]) wrote:
I don't agree, all those things are not in my opinion enough for the
hijacking.
Thankfully, you're wrong.
The package has bugs, lots of them, and for that reason has been removed
from testing, well done, unstable it is here for that.
It's *not*
* Roberto Lumbreras ([EMAIL PROTECTED]) wrote:
Speaking about your mail, I think it's your opinion, mine is different.
Sure, but you're looking through some very rosy glasses.
Jose Luis doesn't want just his name in some place, he has worked a lot
in bacula in the past, and I don't know why
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote:
Steve Langasek wrote:
Actually, we've heard in this thread that Stephen (his AM) *did* offer to
sponsor bacula uploads, and José Luis did not avail himself of this.
When the offer did come, I wasn't able to prepare the upload anyway.
I suspected
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
If the maintainer still wants to maintain it, help him, do NMUs, whatever,
but I'm still looking for one reason you can take over the package against
the maintainer's opinion.
He wants to have his name on the package w/o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 16 Jan 2006 14:45:33 -0500
Source: libpam-ldap
Binary: libpam-ldap
Architecture: source i386
Version: 180-1
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
* Matt Zimmerman ([EMAIL PROTECTED]) wrote:
On Tue, Jan 17, 2006 at 03:07:25PM -0500, Stephen Frost wrote:
You're already rebuilding the package, which I expect entails possible
Depends: line changes and other things which would pretty clearly
'normally' entail different Debian package
* Matt Zimmerman ([EMAIL PROTECTED]) wrote:
On Wed, Jan 18, 2006 at 12:34:33AM +0100, Florian Weimer wrote:
FWIW, I think your implied assumption that all Debian derivatives should
be treated the same is flawed. Ubuntu is just not like any other
derivative, it's a significant operation on
* Matt Zimmerman ([EMAIL PROTECTED]) wrote:
* for unmodified debs (including ones that have been rebuilt, possibly
with different versions of libraries), keep the Maintainer: field the
same
Joey Hess and others in this thread have said that this is not acceptable to
them. What I
* Matt Zimmerman ([EMAIL PROTECTED]) wrote:
I would very much appreciate if folks would review
http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the
points that I raise there. I put some effort into collating the issues
which came up the last time and presenting them.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 12 Jan 2006 21:40:10 -0500
Source: ksymoops
Binary: ksymoops
Architecture: source i386
Version: 2.4.11-1
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 16 Jan 2006 14:15:43 -0500
Source: libxmms-ruby
Binary: libxmms-ruby
Architecture: source i386
Version: 0.1.2-1
Distribution: unstable
Urgency: low
Maintainer: Stephen Frost [EMAIL PROTECTED]
Changed-By: Stephen Frost [EMAIL
* Simon Huggins ([EMAIL PROTECTED]) wrote:
Does anyone want to adopt/help with the ploticus packages in Debian?
I'm only slightly better than MIA (and some might dispute even that),
but I'd really like to see ploticus in Debian updated/improved. I don't
use it much myself but it's one of the
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote:
Having sent you e-mails with my last answers to the TasksSkills
stage of the NM process on 2005/10/05, and having received receipt
confirmation from you on 2005/10/18, i still have no answer from you.
Moreover, i have ping'd you on
* Brian May ([EMAIL PROTECTED]) wrote:
Are you saying you should bounce SPAM mail???
*I* don't bounce much of anything. Talk to Ian about wanting to
generate bounces, it wasn't my idea. What I want is for him to bounce
it himself if he feels it needs to be bounced, not make master do it.
No, I
* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
I don't want to accept any random crap that a forwarding host might send
me just because I asked it to forward mail for me; my resources (in the
form of bandwidth, processing time, and disk space) are limited, and if
Then don't run a mail server.
* Steinar H. Gunderson ([EMAIL PROTECTED]) wrote:
On Fri, Nov 18, 2005 at 02:11:43PM -0500, Stephen Frost wrote:
I expect you could do it though I havn't tried myself because I'm not a
big fan of smtp-level rejects exactly for these reasons. I just accept
and then discard (at least
* Ian Jackson ([EMAIL PROTECTED]) wrote:
Stephen Frost writes (Re: master's mail backlog and upgrade time):
* Andy Smith ([EMAIL PROTECTED]) wrote:
a) inflict bounce spam scatter on the forged from addresses in the
malware and spam he doesn't want to accept delivery for; or
...
It's
* Ian Jackson ([EMAIL PROTECTED]) wrote:
Steve Langasek writes (Re: master's mail backlog and upgrade time):
So accept it and auto-discard it instead, if you prefer; but don't throw it
back at master after telling master to send it to you.
I'm strange in that I like my mail to be reliable.
* Ian Jackson ([EMAIL PROTECTED]) wrote:
Stephen Frost writes (Re: master's mail backlog and upgrade time):
Then bounce it locally. Duh. No reason to force master to deal with
the bounce messages you feel are 'right' to send.
I don't bounce it. I reject it at SMTP time with a 4xx or 5xx
* Andy Smith ([EMAIL PROTECTED]) wrote:
You would prefer that Ian:
a) inflict bounce spam scatter on the forged from addresses in the
malware and spam he doesn't want to accept delivery for; or
That is what he's said he wants to do. What I want him to do is have
*his* servers do it, not
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
Since we are talking about it, it is not always trivial to special-case an
incoming connection for a local bounce instead of a SMTP-level bounce,
though. At least not with all MTAs.
Using an MTA with the capabilities you need should be
* Frank K?ster ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] wrote:
Have we actually got a specific case of this happening and there being a
real security threat from it?
When I ran a samba server years ago, I changed the default log file names
and, IIRC, location.
Were
* Brian May ([EMAIL PROTECTED]) wrote:
Stephen == Stephen Frost [EMAIL PROTECTED] writes:
Stephen Not to mention that quite a few things do things like DNS
Stephen lookups which could take quite a while for an unconnected
Stephen system (perhaps because something broke, or who
* Marc Haber ([EMAIL PROTECTED]) wrote:
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
Some remove the user
(and fail to check if it was created by the postinst/preinst and not by the
alocal admin),
Removing the user is a general bug, IMO. They
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I disagree with the idea that removing a user is a bug. If the user was
added by the package, and the package is being purged, and there's a
reasonable expectation that it wasn't used outside
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* sean finney ([EMAIL PROTECTED]) [051026 14:20]:
i don't think removing and reusing users is a good idea in practice.
what harm would there be in simply leaving the user account on the
system permenantly, with maybe locking the account and setting
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Humberto Massa [EMAIL PROTECTED] writes:
Problem being, if daemons don't remove their (supposedly exclusive-use)
accounts, you can end in two years with 100 unnecessary accounts in a
workstation.
And what bad results does this produce?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
By knowing what the package uses the user for. This is somewhat akin to
the PostgreSQL package's question do you want your data files to be
purged upon package removal, or the fact that the default
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Same way you know that the system administrator hasn't modified a file
in /usr/bin.
Um, I know that by comparing the contents against a known-true
version. How do I detect whether the system
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
This is just patently false, as has been pointed out elsewhere. What
security hole, exactly, is created by orphaning a file?
Well, if some process (maybe within the package) creates a private
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]:
Additionally, this is *not* a problem with the orphaning of the file,
it's a problem with the reuse of a previously-used uid. I could see
adding a system to track previously-used uids
* sean finney ([EMAIL PROTECTED]) wrote:
On Wed, Oct 26, 2005 at 02:58:15PM -0400, Stephen Frost wrote:
Leaving around unused accounts is plainly wrong too, and also a
iyho.
Duh? I ain't humble tho. :)
potential security risk. If we're going to try to push for a broad
change in how
* Don Armstrong ([EMAIL PROTECTED]) wrote:
On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote:
On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
What about log files with sensitive content?
Non-issue, as I said in the end of my post, those should be removed
on
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Leaving around unused accounts is plainly wrong too, and also a
potential security risk.
Can you outline the risk please?
Sure. Locking accounts isn't necessairly perfect. Checking
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
We aren't talking about log files created by the package, but by the
sysadmin.
What if the sysadmin has taken the sensitive log and squirreled it
away, saving it for future reference? Is that no longer a supported
thing?
One would hope
* Lars Wirzenius ([EMAIL PROTECTED]) wrote:
ke, 2005-10-26 kello 12:39 -0700, Thomas Bushnell BSG kirjoitti:
David Goodenough [EMAIL PROTECTED] writes:
In various discussions recently it has been suggested that it would be
a good idea (TM) to make the init.d scripts run in parallel.
* Marco d'Itri ([EMAIL PROTECTED]) wrote:
On Oct 23, Nathanael Nerode [EMAIL PROTECTED] wrote:
Making one of the portable versions the default ping for Debian seems like
the
right thing to do.
Please explain why.
Consistancy. The alternatives system could be used if someone wants a
* Noah Meyerhans ([EMAIL PROTECTED]) wrote:
On Fri, Oct 21, 2005 at 10:13:30PM +0200, Marco d'Itri wrote:
Is a portable version required to be not working and not up to date?
If the upstream maintainer is not interested in it, yes.
It depends on what you mean by up to date. If we're only
* Peter Samuelson ([EMAIL PROTECTED]) wrote:
I'd argue to go one step further and invent a virtual package like
'no-static-link-support' (well, a shorter name would be better) and
generate each dependency on libfoo-dev | no-static-link-support.
Then I can install one little equivs package to
* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
On Tue, Aug 23, 2005 at 09:32:33AM +0200, Martin Pitt wrote:
It doesn't really hurt us right now, so we didn't start to force
building packages in pbuilder. buildd time is cheap compared to
developer time, so introducing mandatory pbuilding would
* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
On Tue, Aug 23, 2005 at 09:14:28AM -0400, Stephen Frost wrote:
Sure we do, for certain ports (ie: amd64). Really, this just means it'd
be better to implement a system along the lines of:
source upload
fastest/preferred buildd type (i386
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
libtool is broken in this regard and needs to be fixed to survive
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
- Option 4 (requires volunteers): fix libtool
Blankly stating that libtool needs to be 'fixed'
because it is 'broken' is not very helpful.
Would you care to explain what needs to be fixed and why
it is broken? Good working examples would be
* Steve Langasek ([EMAIL PROTECTED]) wrote:
It doesn't exist; I think it's a great idea. Perhaps a tool named
dh_libtool, which populates a substvar named ${libtool:Depends}?
This sounds reasonable to me; I appriciate that it's a libtool-specific
thing and not a blanket policy. :)
FWIW,
deserve a 'should'. In fact, even those cases should
generally be discouraged.
Stephen Frost argued in this thread that -dev packages do not need to
depend on other -dev packages, but due to
things such as header files and libtool,
there are cases which -dev packages depending
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
libtool is broken in this regard and needs to be fixed to survive
missing files.
Then fix it instead of giving people bad advice.
Do you actually have anything beyond libtool breaks
* Goswin von Brederlow ([EMAIL PROTECTED]) wrote:
I guess the savest way is to have a libldap-nossl-dev and
libldap-ssl-dev. The former should have anything ssl derived
removed.
No, that was *worse*. We tried that before. The answer really is
reasonably simple- just modify libldap2 to use
* Torsten Landschoff ([EMAIL PROTECTED]) wrote:
On Mon, Jul 18, 2005 at 09:06:20AM -0400, Stephen Frost wrote:
No, that was *worse*. We tried that before. The answer really is
reasonably simple- just modify libldap2 to use GNUTLS. That was done w/
an older version of things involved
* Torsten Landschoff ([EMAIL PROTECTED]) wrote:
Hi Stephen,
On Mon, Jul 18, 2005 at 10:53:02AM -0400, Stephen Frost wrote:
Working on that. At least theoretically - when I get time, yada, yada.
Steve Langasek had offered to help with this too. I'll poke him about
it on IRC and see
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
If this is actually necessary for libtool-using packages, then write
something which goes through all of the .la files and does this, since
that's what libtool wants to do.
and
Errr, you still havn't said what problem you're trying to solve
* Francesco P. Lovergine ([EMAIL PROTECTED]) wrote:
On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]:
libfoobar-2.1-0 will have
libfoobar-2.1-0-dev.
Please distinguish between API and ABI!
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
Exactly! :) We must have a seperate tracking of API and ABI changes.
To do otherwise is madness.
Hmm... I don't think Debian -dev package and
shared library packages really reflect what we consider to be
ABI/API.
Nothing documented about
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and this just creates unnecessary work.
This allows
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
There may be other showstoppers.
What does doing this solve? What does it even help with?
I would really like this 10-year old non-regulation to
go to a concensus (it is indeed rather embarassing we don't
agree on a good solution after 10
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
There may be other showstoppers.
What does doing this solve? What does it even help with?
Hmmm... we are talking about naming
Debian development shareed library package names based on
Debian runtime shared library package names.
Errr, you
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Uh, no it isn't. SONAME changes are fine, the package has
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
The current recommendation I'm trying to give is:
Package: libXXX-dev
Conflicts: libXXX-dev
Provides: libXXX-dev
Thus, it won't contradict with your requirement to
be able to just build-depend on libXXX-dev.
Uhh, then it doesn't fix your
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote:
It's a single headache for the one library developer/packager, as
opposed to headaches for _every user_ of the library.
Yes indeed, but it's still a headache for one person ;).
If that one person isn't willing to deal with it then that person
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote:
The thing is that the library is written in C++ and makes heavily use of
templates which means that even a small change in the code, that doesn't
change the ABI, might lead to incompatibility.
There's no 'might' about it... Either it
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
That's almost certainly a terrible idea.
I somehow expected that might come up. I didn't fell to comfortable with this
idea, but I think there must be another solution than simply doing it by
hand,
a more elegant way.
You can't really
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Well I did say that : The .h file has to include the .cc one in order for the
compilation to work.
Now if you decide to leave the code that I put into g.cc only the .h file, it
works too...
The template class has to actually be included, and so
* Thijs Kinkhorst ([EMAIL PROTECTED]) wrote:
On Wed, June 22, 2005 11:36, Thomas Bushnell BSG wrote:
I think the point is that we ask for a donation before we spend money
on it.
Sure, but the statement quoted above rules it out entirely. can't pay is
pretty definitive. I'm wondering why
* Thijs Kinkhorst ([EMAIL PROTECTED]) wrote:
On Wed, June 8, 2005 12:50, Petter Reinholdtsen wrote:
In RedHat, using selinux is a run time option. If one don't want to use
it,
all one need to do is update a config file and reboot. I'm sure can get
something similar working in Debian.
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote:
* Steve Langasek ([EMAIL PROTECTED]) wrote:
Clone yourself and make yourself a slave to the buildds for 7 or 8
architectures, so that the release team doesn't have to. Neither
* Blars Blarson ([EMAIL PROTECTED]) wrote:
I've been watching the sparc buildd queues for the past 9 months or
so, filing most of the ftbfs bugs for sparc, and prodding the buildd
maintainer when a package needs a simple build requeue or the sbuild
chroot is broken.
Great! What mechanisms
1 - 100 of 240 matches
Mail list logo
