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 n
* 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: Di
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, o
* 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 d
* 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
* 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 the
* 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 certifica
* 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/dic
* 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 /
* 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
* 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
* 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 s
* 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
* 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 wa
* 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 a
* 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
* 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*
* 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
* 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 follo
* 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 REPLACE
* 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 linke
* 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 lo
* 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
* 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 opini
* 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 sus
* 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
* 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 *n
* 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 operati
* 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
> > 'no
* 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.
* 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.
* 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 pa
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote:
> Having sent you e-mails with my last answers to the Tasks&Skills
> 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 2005
* 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.
* 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
* 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
>
* 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 b
* 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, n
* 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
* 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 r
* 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 u
* 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
* 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
* 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 hop
* 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&#x
* 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
>
* 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
* 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 trac
* 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 t
* 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
> ve
* 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 p
* 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
* 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 s
* 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
> > reasona
* 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
* 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
* 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 w
* 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
* 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 upl
* 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
* 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, de
* 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
* 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 r
* 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 any
es where it's required (because
the headers of one #include's headers from the other) but that
definitely doesn't 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
&
* 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.
* 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
* 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
* 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
* 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
* 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 tryin
* 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 program
* 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
* 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 h
* 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.
* 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
> > li
* 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 yea
* 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 mechani
* [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
* [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 rea
* 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... Eith
* 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
* 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 wonder
* 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 Debi
* Luke Kenneth Casson Leighton ([EMAIL PROTECTED]) wrote:
> last time i spoke to him [name forgotten] the maintainer
> of coreutils would not accept the coreutils patches -
> already completed and demonstrated as working and sitting on
> http://selinux.lemuria.org/newselinux - because libselinu
* Robert Lemmen ([EMAIL PROTECTED]) wrote:
> On Tue, Jun 07, 2005 at 02:12:04AM -0700, Steve Langasek wrote:
> > - sparc: one buildd which is not consistently able to keep up with the
> > volume of incoming packages; no backup buildd, no additional porter
> > machine.
>
> how powerfull would a
* 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
* 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 r
* Luke Kenneth Casson Leighton ([EMAIL PROTECTED]) wrote:
> any progress on making libselinux1 a "Required" package?
>
> the possibility of having debian/selinux is totally dependent
> on this one thing happening.
>
> no libselinux1="Required", no debian/selinux [all dependent packages
> e.g. cor
* Colin Watson ([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 r
* 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 the
Whoah, whoah, whoah, is this actually an option? Last I checked that
answer was 'no'. Hell, that's most of the
* Simon Richter ([EMAIL PROTECTED]) wrote:
> Stephen Frost schrieb:
> > Completely breaks dlopen()'ings of libldap2. Don't know if there are
> > any in sarge but don't see any reason to break them if there are.
>
> dlopen() should handle dependency libs ju
* Torsten Landschoff ([EMAIL PROTECTED]) wrote:
> At first sight this looked (for me) like making sense and having no
> negative implications. Of course reality was different - ldconfig had
> problems setting the right symbolic links.
setting the right symbolic links? It's not being used to set
* Nigel Jones ([EMAIL PROTECTED]) wrote:
> Unless there is a related RC bug there, I don't think it's gonna
> matter when the change is to get it in sarge (i personally have not
> seen any RC bugs though...)
There's RC bugs all over this.
Stephen
signature.asc
Description: Digital signa
* Simon Richter ([EMAIL PROTECTED]) wrote:
> Torsten Landschoff schrieb:
>
> > Suggestions how to fix that for real before getting sarge out of the
> > door with this risk that I don't feel I can estimate?
>
> Build a dumy libldap.so.2 with the same SONAME that consists of a NEEDED
> entry for li
* Tim Goodaire ([EMAIL PROTECTED]) wrote:
> I haven't been able to find an ITP for this. I've found an RFP for it
> though (278810). Is this what you're referring to?
Yes.
> Also, my ITP bug (305287) has already been closed on me. Apparently I
Yes, I closed it since it was a duplicate WNPP bug.
* Brian Nelson ([EMAIL PROTECTED]) wrote:
> Qt in Debian must build against libiodbc2-dev because otherwise it would
> have a circular build-dependency with unixodbc.
Circular build-deps aren't necessairly a real problem. There's a fair
amount of other stuff which have them and in general I think
* Anthony Towns (aj@azure.humbug.org.au) wrote:
> >Apparently the feeling wrt distcc is somewhat different and is likely to
> >be a more generally accepted solution to the slow-at-compiling issue.
>
> I like distcc -- heck I went to high school with the author -- and I
> think it's cool. I don't
1 - 100 of 198 matches
Mail list logo
