> You can't distribute text with the word "fuck" in it anywhere to minors in
> the
> US?
>
> Truly remarkable. Are there any minors reading this? Where do I hand myself
> in?
Well, you would need to check the penal codes of each individual state
wherein such a minor resides; some states will a
> It's "prurient", not "puritan".
>
> "dict prurient" will explain.
Thank you for misinterpreting the wordplay.
Please take this discussion to another mailing list or end it
completely. These arguments have been rehashed within Debian
since what I believe to be its original inception 7 years ag
> Do you think moria still has a place in Debian? Or do you gather it
> might be better removed?
A better question is whether Mr. Koeneke is willing to relicense his
code under a free software license so that moria and angband and
derivatives can finally be free.
--
To UNSUBSCRIBE, email to [EM
> ii debianutils2.12.0 Miscellaneous utilities specific to Debian
> ii exim 3.36-13An MTA (Mail Transport Agent)
>
> Is there anyone who encountered the same problem or is this
> Alpha specific or even specific to my machine?
This should be fixed in debianutils 2.
> Nevertheless, I don't know if it's a problem of the manpage system or of
> the manpage writers, and how the writers could circumvent/solve the
> problem. And this information would be useful before I start filing
> bugs, or!?
This is a bug in the manpages themselves. The unformatted source s
> Should we notify the maintainers to better go back to 4.2 for sarge?
Don't bother notifying me; I won't be switching anything back to 4.2.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Why? (technical reasons, please). Not that I am assuming there is enough
> evidence to downgrade anything but OpenLDAP just yet, but your reply seems
> to imply that even if there were, you would still not downgrade.
If there were anything besides FUD, I'd consider it on its own merits,
but all
> Only now I would trust BDB 4.2 with any mission critical data... but then, I
> am the one which still builds Cyrus 2.1 against BDB 3.2 for stability (Cyrus
> 2.2 will be built against BDB 4.2).
IIRC, BDB 3.3 addresses very serious problems in 3.2, but we can't have
3.3 in Debian without a painfu
> The buildd maintainer is one of the 'notoriously difficult to reach'
> people in Debian. If you were interested in trying, contacting the
> mailing list for the port is the obvious next step.
What can the people on such a mailing list do about buildd issues?
--
To UNSUBSCRIBE, email to [EMAI
> The job of the buildd admin is to make sure packages are built. Mostly
> that's automated, which is great, which means the buildd admin's job is
> mostly to keep the automation working.
Dan was a really good buildd admin. Maybe he knows what he's talking
about.
--
To UNSUBSCRIBE, email to [E
> developer, and I can use it to access the pkg-perl repository on
> svn.debian.org without any trouble. When I became a Debian developer, I
> got a new Alioth ID rra. It's now also been added to the pkg-perl
> repository. But it doesn't work with svn.debian.org.
Assuming nothing is wrong, you
> True. However, the issue in question is whether or not it would be
> better if they maintained in teams.
I imagine that it would not be better.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I intend to orphan the following packages:
bricolage
dbacl
libcache-mmap-perl
libmasonx-interp-withcallbacks-perl
libparams-callbackrequest-perl
libstring-crc32-perl
scottfree
ttf-kacst
ttf-paktype
If you want one of these, upload it with yourself as Maintainer.
Immediately.
--
To UNSUBSCRIBE
Thanks to those who saved me the time and hassle of filing some wnpp
bugs.
> bricolage
#348948
> dbacl
#348949
> libcache-mmap-perl
#348951
> libmasonx-interp-withcallbacks-perl
#348952
> libparams-callbackrequest-perl
#348953
> libstring-crc32-perl
#348954
> scottfree
#348950
--
T
> Does this make sense to anyone but me?
It seems unnecessary for shared libraries to have priorities if they're
useless without programs which depend upon them.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED]
> I don't see your point, and you seem to have missed mine.
My point is that there's no need for a package with no user-level
functionality of its own, such as a library, to have a priority
of its own.
If an Important package such as 'at' depends on libelf0 for whatever
dubious reason, libelf0 mi
> Those who have no space for documentation on their system should use "rm".
> Our next package system will be able to use a policy file to exclude
> installation from certain directories, like /usr/doc, which will make this
> easier for the user who wants to exclude documentation from a system.
W
> For Deity, I suppose we could make pattern-matching work in the policy file.
I think that would be preferable to simple directory exclusion.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
> Well, you're going to need a script to implement that policy. Probably
> the best way to handle this is to provide a way to tell the package system
> that you have deliberately removed a file, and that this file should not
> be replaced. I wouldn't expect this in version 1.0 .
What exactly is th
> "bare minimum" doesn't extend to a compilation environment.
> or to printing, IMO.
> > * netbase and netstd should both be there, they are standard
> >on Unix
It seems as though the implicit definition of "standard Unix system"
omits a declaration of intended usage.
--
TO UNSUBSCRIBE FR
> I'll do that (they also used 1.7b which means "second release candidate
> for 1.7), but I probably won't be able to rewrite history and make 1.55
> disappear...
I had this problem before and used the equivalent of 1.70.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubsc
> Well, I did not talk about regular snapshots, but about direct exports.
> Some tools in Debian (like "darcs-buildpackage", thank you John for
> this) make it possible to make such SCM builds. However the Autotools
> output is not versioned, so not included in the tarball.
It is possible to run a
> I may do that too, but its architecture support is abysmal compared to
> Debian, so I have no choice in the matter at this point (and lack the
> time to port ubuntu to all my archs).
Perhaps the SCC plan will help make that choice easier for you.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> In every single patch system I've encountered, you can run debian/rules
> patch and get the patched source. It's only one more command and I consider
> it universal for all patch systems deployed in Debian.
In some cases, this will fail if you don't have the build-dependencies
installed.
--
> Here's a proposed patch. What do people think about this approach? I
> know there was an inconclusive Policy discussion a while back about how
> best to deal with this issue. As you can tell from this patch, I favor
> the approach of documenting the specific features that we require and
> assu
> Forgive me if I am wrong, but I was under the impression that posh was
> created for the purpose of providing a shell which supports a minimum
> of functionality required by policy against which scripts could be
Not exactly a minimum. For example, posh implements a POSIX pwd
builtin. If it wer
> Why not ls?
Judging by the lack of wishlist bugs requesting it and my
own feeling of revulsion at the idea, I'd say that it's because
no one wants it.
A builtin ls might be a good idea for disaster recovery shells,
though zsh-static does not have it. posh is not intended to be
such a shell, no
> Okay, here's try number two. I tried to incorporate the feedback from
> various people. Please critique.
Other than wanting the 'echo -n' and -a/-o bits to go away, I think this
looks pretty good.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contac
> I think you're confusing the buildd admin with the porters. I expect
Maybe that's because the buildd admins used to be the porters, and then,
for some reason I do not understand, this mysteriously stopped being
true.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscrib
> ATM kdemultimedia (and therefore kde) is uninstallable on any arch
> except amd64 because libtunepimp2c2a has not been built. I see from
> the changelog of libtunepimp3 that it was renamed, so shouldn't
> libtunepimp3 provide and replace libtunepimp2c2a or the dependencies
> of noatun, juk. amaro
> Which installation method are you using in dselect? In think you have to
> specify the directory "debian/dists/unstable" as base directory and select
> distributions "main", "contrib", and "non-free".
This would be nice, but the Packages files seem to be set up for /debian to
be the base direct
> The primary MTA? does that mean that more than one MTA can be installed on
> Debian at once? I thought they all conflicted with each other.
They do, and that should change.
The apparent solution to something like bug#45344 is to have all
the packages providing an identd to conflict with one another.
While reasonable in most cases, this has the horrible side effect
of not letting the administrator have multiple identds on the
system. What if I have a machine with t
> Okay, then solve the problem of which one should actually work on the
> standard port? You can't use update-alternatives if the software is
Well, I would prefer that things didn't start listening for connections
without asking first, but I can't imagine that that's a popular suggestion.
> laun
> Of course. Now if you built them yourself, dpkg wouldn't touch them.
If I wanted to build them myself, I would use Slackware.
If I repackage them I will need to remove the Conflicts line from
the control files every single time I upgrade.
> People who want such "complex" setups should have eno
> If you want to run two httpd's, popd's or mta's, you'll probably have to
> do more than the usual tweaking to the package setup anyway, so what is
> really the big deal of having to:
>
> 1. `apt-get source foo`
> 2. edit various files, mostly in debian/
> 3. add an epoch to the package versio
> And of course you can always do dpkg --force-conflicts. I believe that's what
> the --force commands are really there for: special situations.
Broken situations. Sure, you can --force dpkg to overwrite files
from another package. But Debian prefers to fix the problem instead.
> a) I would not test a new daemon on a working machine, I would use a separate
So?
> b) if you know what you are doing, compile the packages by hand, fix their
> install scripts, and remove the conflicts. You are trying to circumvent the
> norm.
If I wanted to compile them by hand, why would I
> Because as everyone knows the last 10% takes 90% of the work and often ends up
> hurting the other 90%.
Then it's being done wrong.
> The point is Debian needs to work for as many people as possible. We are
> doing
Yes, that's exactly the point.
> apt-get source qpopper
[...]
> dpkg -i qpop
> Ok, let's bring this back to implementation. How would you propose we handle
> this? Currently daemons install, set themselves up, and begin running.
>
> a) we can prompt.
> b) we leave everything off and let the admin turn it on (not an option for
> obvious reasons)
> c) first come first serv
> the "we-know-better-than-you" attitude is what redhat and caldera (and
> microsoft, for that matter) does. it sucks. debian has always done
> better than that - our way is to encourage people to learn to do it for
> themself by not trying to hide the fact that knowledge and experience is
> requir
> debian's attitude is: if you want something different, DIY. and more
> importantly, it lets you DIY.
Err.. what Unix DOESN'T let you DIY?
> read the rest of my message. the bit that ranted about unix's that
> get in the way of DIY. RH is one. sun's Netra is another...both are
> examples of how NOT to do configuration management on unix.
No. You're talking about doing something your way and then having
it wrecked by the RH/whatever
> There is currently no default -- it varies on a per-package basis.
I note that
### to run vtund as a server on port 5000, uncomment the following line:
#--server-- 5000
isn't uncommented by default.
> Or are you saying something else?
I was merely pointing out the irony of one of Craig's packages
not enabling the daemon by default.
> it isn't useful to run the vtund server until it is configured. there
> is no "standard" configuration which is suitable for shipping as a
> default - it MUST be customised for each site, each tunnel must be setup
> individually.
When did "useful" enter this discussion?
pipsecd starts the daemo
[Craig flaming Doctor What deleted]
> if someone doesn't want a service enabled then they should not install
> the package that provides that service. if they want the service, then
> install the appropriate package. simple. their choice to install or not
> install.
>
> now what is so fucking dif
> No, this is silly. When you install a package, it is for use. If you
> don't intend to use it, why install it?
Perhaps you can explain where this idea comes from.
Of course, if I want to evaluate a daemon, I can --unpack the package
into /usr/local/testfun and manually enable it, evaluate it
> > Package: zsh (debian/main).
> > Maintainer: Clint Adams <[EMAIL PROTECTED]>
> > 58941 core dump with function mycd() {builtin cd "$@" && echo $PWD}
> > [STRATEGY] Fixed in the next .deb. Already fixed upstream. (Mar15MH)
>
> That is a
> No real reason? Only one package can listen in on port 25, and
Only one package can listen on port 25 of one IP. It is possible to
have multiple packages listening on different ports or different IPs.
> Why a new zsh was introduced in potato-proposed-updates ? It's not
> compatible with thw previous version...
What do you mean, it's not compatible?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> The completion control system has changed, along with a few other
> minor details. I am myself a zsh user and have since made the
> adjustment; I'm not sure the attitude others have towards their
> zshrc's. A number of the mechanisms used prior to zsh-3.1.x to
> control the completion behavior ar
> I've opened a bug against zsh for the aforementioned behavior.
Fine. We can move the discussion there then.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> (Please CC: me, I no longer track debian-devel)
Your M-F-T is broken.
> I am contemplating the upload of a version of coreutils that will have
> support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l
How about selinux support?
> texi2html's behavior changed recently: if it is invoked with
> -split=chapter, old versions place the HTML files in the same
> directory as the documentation source, whereas new versions place the
> generated files in a subdirectory.
To get the old behavior, one can use
--output . --split=chap
> So I want to highjack the package.
> Any meanings?
Do it. Pop the trunk.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> FWIW, this is just about the same response I got from upstream when I
> asked them about the issue. The solution is of course to get rid of
> libdb and use tdb or something equivalent.
Maybe you should convince bogofilter upstream to keep supporting tdb.
They're dropping it on the grounds that
On Sun, Jan 20, 2008 at 04:44:34PM +0100, Adeodato Simó wrote:
> In summary, `run-parts` is safe wrt .dpkg-bak, `run-parts --lsbsysinit`
> is not.
Easy enough to fix if need be.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Jan 28, 2008 at 05:37:03PM -0800, Russ Allbery wrote:
> This work flow simply doesn't work with our current source package format
> and a patch management system. Requiring this to work *with the current
> source package format* essentially means outlawing using patch management
> systems
On Mon, Jan 28, 2008 at 06:58:10PM -0800, Russ Allbery wrote:
> If wig&pen provides a defined series, then I don't need more than that. I
> don't know enough about wig&pen to tell you whether all the pieces are
> already there.
It does not. To programmatically convert from quilt to a wig&pen
debi
On Sat, Feb 09, 2008 at 04:39:11PM -0800, Russ Allbery wrote:
> This one is somewhat arguable. Pure POSIX doesn't allow signal numbers,
> but the XSI extension to POSIX does and dash and posh both support them.
> We do not, in general, accept XSI extensions, but it's hard to argue
> strongly for e
On Wed, Mar 05, 2008 at 12:55:00AM -0300, Henrique de Moraes Holschuh wrote:
> Isn't this going way out of proportion? That's the first I hear from any
> *refuses* to merge, as opposed to "the merge not going to be done the way I
> would like it to happen", and "it is taking too long for it to get
On Sun, Mar 09, 2008 at 10:14:14PM +0900, Hideki Yamane wrote:
> Hi list,
>
> Just a question.
>
> In Developer Locations page(*), it seems that Debian Developer is in
> Antarctic Continent... awesome! Is it real??
Not that one; someone made a sign error with his coordinates.
--
To UNSUBS
On Sun, Mar 09, 2008 at 05:13:14PM +0100, Lionel Elie Mamane wrote:
> So he's really in very-northern Finland/Sweden/Norway/Russia?
If I recall correctly, he was somewhere in or around Michigan.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMA
On Mon, Mar 17, 2008 at 04:27:03PM -0700, Russ Allbery wrote:
> Joerg has been moving towards doing more of this, and I applaud him for
> doing so. I hope that anyone else who works on NEW does the same. It's
> one of our best opportunities to raise the general quality of the archive
> up-front,
On Mon, Mar 17, 2008 at 05:18:20PM -0700, Russ Allbery wrote:
> The last part is certainly true, although I don't think that makes the
> check at that point unuseful. The initial upload is the point at which
> it's the most likely that significant misunderstandings or structural
> flaws will show
On Thu, Mar 20, 2008 at 08:50:11AM +1100, Ben Finney wrote:
> William, please follow the Debian mailing list code of conduct
> http://www.debian.org/MailingLists/#codeofconduct>; specifically,
> don't send me individual messages that are also sent to the list,
> since I didn't ask for them.
How ma
On Fri, Mar 21, 2008 at 07:43:22PM +0100, Luca Capello wrote:
> I'd suggest debianutils, since it provides at least sensible-browser,
> but it misses sensible-terminal-emulator.
I'd suggest the packages actually providing x-www-browser and
x-terminal-emulator, since debianutils is not one of those
On Tue, Mar 25, 2008 at 08:35:12PM +0100, Luca Capello wrote:
> Do you mean that every package that installs an alternative for
> x-www-browser or x-terminal-emulator should install a .desktop file?
> Maybe we can have a new alternative x-www-browser.desktop and
> x-terminal-emulator.desktop.
That
[moving to -devel to make Christian happy]
On Sat, Apr 19, 2008 at 09:57:44AM +0200, Andreas Barth wrote:
> And, BTW, most of us (including me) have a paid dayjob, and are of
> course active on that one for the contracted time - for obvious reasons.
> Telling that I would neglect Debian because I'
On Sun, May 18, 2008 at 05:21:52PM +0200, Frans Pop wrote:
> Clint Adams sent a request to d-www to have the CoC changed and I have
> replied with a strong NACK to that suggestion. If the CoC should be
You neglected to Cc me.
> changed, it should be done after a proper discussion (on
On Sun, May 18, 2008 at 06:35:20PM +0200, Frans Pop wrote:
> Wrong. You neglected to request to be CCed.
My M-F-T was clearly a request to be Cc'd.
> That's bullshit. The CoC has been in place and unchanged for years. Please
Yes, and it has been controversial and WRONG for years.
> check the o
On Sun, May 18, 2008 at 07:31:37PM +0200, Frans Pop wrote:
> I agree it has been controversial. However, "wrong" is just your opinion.
> My opinion is that it is "right" for Debian's lists.
My preference for a default is to suggest that everyone always Cc unless
otherwise requested. Note that I d
On Tue, Jul 21, 2009 at 06:14:27AM -0700, Russ Allbery wrote:
> Except that every package in Debian that explicitly uses bash has no
> declared dependency on bash because it's essential. I think attempting to
> go through and add all those dependencies and test would be a huge waste
> of time and
On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote:
> Why?
Because:
On Fri, Jul 24, 2009 at 09:38:01AM +0200, Steve Langasek wrote:
> If the goal is to make *bash* removable, then I can understand why that
> would be helpful to some people since it's the heavier shell by far. None
>
On Fri, Jul 24, 2009 at 03:43:47PM +0200, Steve Langasek wrote:
> Patches will be considered.
The second hunk isn't relevant to bash, but it seems a waste to
call ls and head for no reason.
--- debian/libpam0g.postinst.orig 2009-07-24 08:59:07.0 -0500
+++ debian/libpam0g.postinst
[not replying off-list because that seems counterproductive and arrogant]
On Fri, Jul 24, 2009 at 03:49:15PM +, brian m. carlson wrote:
> Actually, if it's invoked as /bin/sh, it is supposed to be
> Bourne-compatible. That's my experience with the current version:
Not much effort is put into
On Sun, Nov 01, 2009 at 07:29:23PM -0800, Russ Allbery wrote:
> Also, note that the ftp team are at least project delegates, whereas the
> Lintian maintainers are "just" package maintainers. If we have a
> governance problem with the ftp team making this decision, it would be
> even worse if the L
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
> I don't think it's good to waste buildd time on failing to build packages.
> I also don't think anyone is stopped from setting up a service that
> allows source-only uploads as a go-between.
Do you mean set up an unofficial upload queue
On Thu, Dec 03, 2009 at 07:45:30PM +0100, Luk Claes wrote:
> Unfortunately Debian does not seem to be able to also have real
> constructive discussion about complex issues on the lists. So for these
> issues we usually have real discussions on IRC, real life, phone or
> private mail. The final resu
On Tue, Dec 15, 2009 at 05:24:48PM +0530, Ritesh Raj Sarraf wrote:
> The copyright file lists that the copy of GCIDE is archived. I am not very
> sure
> who the current upstream is and if this database is still actively maintained.
It is not. Upstream abandoned GCIDE on the grounds that WordNet
> Is it technically and/or socially possible to send build logs to
> buildd.debian.org?
Yes, the current security model does not prohibit that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> I would think that the same things that attract a technical individual
> could attract a non-technical individual. Desire to learn. Desire to
> contribute. Desire to build skills for resume or future employment.
> And so on. The thing is that the current NM process is heavily biased
> toward
Newly orphaned:
conquest - a real-time, multi-player space warfare game
xmaddressbook - X-based (Motif) address book
zsh30 - zsh 3.0
xmaddressbook also needs someone to take over as upstream.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
> I created one package. When I try to perform the below
> command, come this error:
>
> pc101:# fakeroot debian/rules binary
> fakeroot: FAKEROOTKEY set to 818929733
> fakeroot: nested operation not yet supporte
>
> Any suggestion ?
Are you trying to run fakeroot within fakeroot?
--
To UNSU
> Hi,
>
> The command:
>
> pc01:package/fakeroot debian/rules
> fakeroot: FAKEROOTKEY set to 818929733
> fakeroot: nested operation not yet supported
>
> Att,
>
> Faria
Let's try this another way. Why is FAKEROOTKEY already set?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
> Not sure why on earth you would want to do this, but it seems to work
> OK on etch. Maybe this is only supported with recent versions of
> fakeroot?
No, it's only appearing to work OK. You'll lose state between the
different fakeroot invocations and that's why the error message is
there until w
> I doubt that.
> You can easily run into this problem by using
> make-kpkg --rootcmd fakeroot modules-image
> and the nvidia module will fail with
Does this happen every time?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Wed, May 23, 2007 at 12:07:01AM +0200, Turbo Fredriksson wrote:
> If I knew anything about kernel interior and development, I'd be happy
> to step up, but...
Why don't you step up and learn then?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
On Sun, May 27, 2007 at 12:11:03AM +0200, Frans Pop wrote:
> However, I do feel my comment is justified in the sense that if there is
> one thing in Debian that is the joint responsibility of _all_ DDs, then
> it is the website. So yes, if you've never contributed in any way to the
> website, fe
> The wiki is completely centered on English and therefore fails to serve a
> significant portion of our users. Sure, parts of the wiki are translated,
> but maintenance of that is an orders of magnitude worse problem than it
> is for the website.
>
> As far as I'm concerned the wiki is not a v
On Sun, May 27, 2007 at 08:13:37AM +0200, Christian Perrier wrote:
> How were things working in the debian-glibc CVS? Did accidents or hot
> discussions hapen because of the very opened commit access?
No more so than happens today with the more closed SVN repo.
--
To UNSUBSCRIBE, email to [EMAI
On Tue, May 29, 2007 at 08:30:23PM +0200, Josip Rodin wrote:
> It's not unfair to say that web editing is by and large much a easier thing
> compared to coding the C library. Consequently, the number of people who
> know how to do it, as well as the people who *think* they know how to do it,
> is m
On Wed, May 30, 2007 at 01:02:12AM +0200, Josip Rodin wrote:
> Anyway, before we get lost in all this prediction stuff, I'm yet to hear
> a good reason why we need complete triviality in the access method, as
> opposed to the kind of triviality we have had for years now: all that is
> necessary to
On Thu, Aug 07, 2008 at 12:48:20AM +0200, Lucas Nussbaum wrote:
> Confirmed. And it hasn't been fixed.
That's why I run it in a while loop and find it to be reasonable
functional that way.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PRO
On Wed, Sep 17, 2008 at 01:12:04PM +0200, Daniel Baumann wrote:
> or in other words: soname 6 in debian will therefore be not compatible,
> as it introduces both --enable-ext-mouse and --enable-ext-colors. also,
> the wide builds will dissappear.
What's the transition plan for those of us using wi
On Wed, Sep 17, 2008 at 01:37:29PM +0100, Adeodato Simó wrote:
> libncurses5-dev (and libncursesw5-dev as well if appropriate). With
Can't do that because the pathnames are different.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT
On Mon, Oct 06, 2008 at 11:13:22PM +0200, Luk Claes wrote:
> We do have experimental...
It would be better to have a new place for that so we don't need to
abuse experimental. Preferably one that moves everything to unstable
post-release. Or call it unstable and resurrect 'frozen' for where the
On Wed, Oct 08, 2008 at 02:30:50PM -0500, Manoj Srivastava wrote:
> So I think we need to modify the proposal, not the policy.
We need to stop pretending that patent enforcement is one of our
responsibilities or that we expose ourself to any kind of liability
by distributing code that may
On Wed, Oct 08, 2008 at 04:37:26PM -0500, Manoj Srivastava wrote:
> So don't. Don't put any of the patent encumbered sources in main
> either -- there is nothing that says patent infringement does not
> happen as source code.
>
> That would meet the current policy as well.
>
>
1 - 100 of 241 matches
Mail list logo
