Bug#551992: general: stopping squeeze chroot shuts system

[Stephen Stafford]

> In a lenny chroot, on the same system, rc6.d/S90reboot calls 'reboot -d -f
> i' and that works like I'd expect; the chroot is stopped and the system
> keeps on running.
> In the squeeze chroot we have rc6.d/K09reboot and the same 'reboot -d -f -i'.
>
> I will check if the -f does the trick but I still think the behaviour
> should be the same for both lenny and squeeze. I also think that the
> ability to reboot a system by rebooting a chrooted environment shouldn't
> be possible so the bug remains.
>
> According xen or kvm; eventually we will make that change of course, but
> at the moment that's not something we're focussing.
>

Your script only calls all K* scripts (not S* scripts) when stop is
invoked.  Hence in the system where reboot is S90, it won't call it.
Where it's K09, it will be called.  I suspect if you rm K09reboot in
the squeeze chroot, it will fix the behaviour to what you want.

As far as rebooting from inside a chroot rebooting the system I don;t
know whether that's a bug or not.  As far as I'm aware it has been the
way it's behaved for a long while...not sure what you can do to
prevent it even...

-- 
Stephen Stafford



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#415703: /etc/modules has no function/should be deleted

[Stephen Stafford]

On 21/03/07, Olaf Zaplinski <[EMAIL PROTECTED]> wrote:

Package: general

/etc/modules is not owned by any package, and its content is ignored when
building an initrd image. I just checked. By default the module loop is
defined in /etc/modules, but it is not included in my new initrd image.


It's a very handy place to put modules which should be loaded at boot.
Please don't remove it.

Cheers,
Stephen
--
Stephen Stafford


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: software updates file in /usr -- policy bug?

[Stephen Stafford]

Anthony Towns wrote:
On Fri, Oct 29, 2004 at 10:14:08AM +0200, martin f krafft wrote:
Come on! The FHS regulates what normal software can/should do,
partially so that package managers can work reliably. dpkg is the
package manager, thus it is exempt from the FHS.
In fact, I should have been even clearer. The FHS applies to the
filesystem structure are run-time, not at installation time. It
guides the installation, but only such that when the installation
phase is complete, the system can switch to run-time and be
FHS-compliant from the start onwards.

That's not quite true -- dpkg can't stick stuff in /debian-rocks/bin and
claim to be FHS compliant. The key point is the distinction between who
is controlling the file, and what it's for: the vendor (us) puts stuff
in /usr, the admin puts software in /usr/local, and programs put their
data in /var, ~, or /srv, depending on what sort of data it is (internal,
personal work, or shared work).
Having apt-spy dpkg-divert the file in /usr on install, and replace it
with a symlink to a file in /var/lib, and then update the file in /var/lib
when invoked seems the obviously correct way to deal with this, no?
In the end, after my irritation at how the NMU was done abated, I just 
moved the file to /var/lib/apt-spy.  Most people seemed to agree this 
was the correct location.  Nothing else depends on the location of the 
file, so a symlink isn't required.

In a future version of apt-spy we might provide a config file which sets 
(among other things) where to get the file from.  That then allows the 
network admin to set a location for his own version (the main reason it 
was in /usr/share in the first place) and then I think the file would be 
in the right place...for now it will do, although I don't think it's 
ideal.

Steven Holmes is looking to extend apt-spy's functionality to make it do 
a similar job for BSD mirrors and for other Linux distributions.  A 
configuration file to modify behaviour will be part of this extension. 
I'm not going to upload this before etch (assuming it's even ready 
before then - how long is sarge's release likely to be?).  Right now I 
don't want to make too many uploads of new features...I'd like a release 
sometime sooner rather than later after all :)

Cheers,
Stephen

Re: tmda: Challenge-response is fundamentally broken

[Stephen Stafford]

On Wed, Aug 27, 2003 at 01:35:12PM +0200, Tore Anderson wrote:
> [ Please do not send me CC's, as I have not explicitly asked for them. ]

Apologies.

> 
> * Stephen Stafford
> 
>  > Sorry, but I do NOT see how this is a grave bug.  It's wishlist (at best).
>  >
>  > YOU might not agree that C-R systems are good (personally I detest them),
>  > but that does NOT mean that we shouldn't release one.  If the package is in
>  > good shape and functions as advertised, then it IS fit for release.  
> 
>   I do not have anything against C-R systems per se, and I do not care if
>  others use them, or if we distribute them.  What I -do- have a problem
>  with is that the C-R system in question ignores the fact that SMTP
>  headers are trivially (and regulary) forged.  I believe this is deliberate,
>  and that TMDA does not attempt to verify that the recipient of the
>  challenge truly was the sender of the original e-mail.  (If it did, I
>  would have no problem with it at all.)
> 
>   Therefore third-party users, who had nothing to do with the original
>  sending of the mail, will receive unsolicited e-mail, and that even
>  from a program which is designed to stop such junk.
> 
>  > Hey, how about if I decide that emacs is a huge bloaded piece of shit?
>  > Does that mean we shouldn't release it?
>  >
>  > Or if I decide that CUPS is rubbish and lprng is the One True Printer
>  > Daemon?
>  >
>  > Or that Gnome is a steaming pimple on the arse of desktop managers?
> 
>   None of these are comparable - that one user installs Gnome on his
>  system does not hurt you in any way.  You can simply ignore it and
>  go on with your life.  You do not even have to know -- Gnome will not
>  send you unsolicited junk mail, regardless of it being a 'steaming
>  pimple' or no.

The original submitter was NOT compaining that the package was badly
implemented, he was complaining that C-R systems are bad (okay, he has lots
of reasons why he thinks they are bad, but it's all opinion in the end) and
should not be released.  The TMDA package is not broken with respect to what
it is meant to do.  It does exactly what it is meant to do.  The fact that
you don't like it is neitehr here nor there.

My examples of Gnome, emacs and CUPs were just that...examples.  They are
designs which some people like and some people don't.  The variety that says
we can have different designs is a good thing.

Personally I do not like C-R systems.  In general if I get a challenge from
one, I ignore it.

This does not mean that the tmda package is buggy.  All it means is that you
don't like what it does.  That being the case, it is exactly comparable to
someone deciding that because they don't like emacs, or Gnome or whatever
that we should file a RC bug on it to prevent it being released.  The only
thing that isn't comparable WHY you don't like it.  Sorry, but from where I
sit, it's not a good enough reason to remove it from the archive, or to
prevent it being released.

I dislike C-R based anti-spam measures, and I will tell anyone who asks me
WHY I don't like them.  Someone who likes vi and detests emacs will tell
anyone why he dislikes emacs.  I don't see why this should be a good reason
for removal from the archive, or why this is a release critical bug.

Stephen


pgpugmGC7ruZW.pgp
Description: PGP signature

Re: tmda: Challenge-response is fundamentally broken

[Stephen Stafford]

[enormous snippage]

Sorry, but I do NOT see how this is a grave bug.  It's wishlist (at best).

YOU might not agree that C-R systems are good (personally I detest them),
but that does NOT mean that we shouldn't release one.  If the package is in
good shape and functions as advertised, then it IS fit for release.  

Hey, how about if I decide that emacs is a huge bloaded piece of shit?  Does
that mean we shouldn't release it?

Or if I decide that CUPS is rubbish and lprng is the One True Printer Daemon?

Or that Gnome is a steaming pimple on the arse of desktop managers?

As long as SOME users like it, and find it useful and it fits THEIR needs,
then we should not be removing it from Debian (as long as it meets DFSG).
tmda appears to meet those criteria.  It is NOT your place to decide what
software our users can and can't use.

This is NOT a grave bug.  You have given NO reasons why the package does not
work as advertised, or fails to build, or fails to install or causes major
breakage to significant numbers of systems.  All you have is an opinion that
C-R systems are bad.  I share that opinion, but that does NOT make this a
grave bug.

Stephen


pgpngUSCQUk8G.pgp
Description: PGP signature

Re: surfraw ultimatum

[Stephen Stafford]

On Tue, Jul 22, 2003 at 11:12:44PM -0500, Thomas Smith wrote:
> Hi,
> On Tuesday, July 22, 2003, at 07:03 PM, Adam Borowski wrote:
> >
> >Just don't *dare* to let anyone remove /usr/bin/google or I'll kill 
> >you,
> >your dog and your friend's uncle's son's ex-roommate's girlfriend's 
> >aunt's
> >pet hamster.
> >
> OK, how about we change the surfraw "rhyme" to accept similar command 
> line arguments to the rhyme-the-package "rhyme" and register them as 
> alternatives, with rhyme-the-package higher on the list?  Note that I 
> have not yet downloaded rhyme-the-package to see how well this will 
> work...

Hi Thomas,

I have no problem with this (as the maintainer of rhyme (the package).  I
don't even necessarily need rhyme (the package) to have a higher priority.

I'm not 100% convinced that alternatives is the Right Way though (even
though I'll implement that if it's what we agree on in the end). How about
this for a suggestion?

rhyme (the package) keeps the rhyme binary.  surfraw renames the rhyme
binary to (say) surfrhyme or something.  I arrange for rhyme the package to
prominently display some notice to the effect of "This rhyme command
supplants the rhyme command in surfraw.  If you want the surfraw rhyme
command then use the new name of 'surfrhyme'".

Obviously the language needs to be cleaned up and thought about, as does the
command name.  There are problems with this approach as well though,
obviously.

It still doesn't address the namespace pollution though.  There are a lot
more very "generic" commands there.

Still, both are solutions that I'm happy to implement as long as surfraw
starts being maintained actively again.

As regards the alioth project goes.  Well done and thank you for getting
this up and running.  If you post again when it's properly running, I'll
check out the CVS and might submit a few patches.  Be aware that you don't
always get a confirmation mail from alioth to say the project has been
started...sometimes it just appears :)  Have a look to see what projects
your account on alioth are registered as being associated with, it might
already be there :)

> 
> I think that, since they have similar functions, this strategy should 
> work... if there's some other program that wants to use W then that's 
> less likely, but this should work for now.
> 
> >Considering the number of people interested in surfraw, you most likely
> >already received a complete set of patches.
> Heh, you underestimate the laziness of people in general.  go for it, 
> man.

hehe, well, not necessarily laziness.  I did take an hour or so to have a
look at the surfraw package a few days ago and started to fix some trivial
stuff.  I was loath to do much before the question of where the commands
were going was settled though.

As I said earlier, once you have the package in publicly available CVS, I'll
more then likely grab it and submit patches properly.

Cheers,

Stephen


pgponZN0e69lH.pgp
Description: PGP signature

Re: Debian 10th birthday gear

[Stephen Stafford]

On Tue, Jul 08, 2003 at 09:59:07AM -0400, Matt Zimmerman wrote:
> On Tue, Jul 08, 2003 at 01:14:45PM +0200, Ignacio Garc?a Fern?ndez wrote:
> 
> > It would be nice that there was one design in pgn or something
> 
> (...ponders what a T-shirt design in chess notation would look like...)
> 

I used to have one:

Fischer - Panno 1970
1. c4  1-0

Which is legal PGN (apropos the correct header format, which I'm not going
to try to reproduce, sorry) and I believe to be the shortest ever
competitive Grandmaster game.

Cheers,

Stephen

Re: Please remove RFCs from the documentation in Debian packages

[Stephen Stafford]

On Sat, Jul 05, 2003 at 02:10:12PM +0200, Petter Reinholdtsen wrote:
> [Stephen Stafford]
> > We have a commitment that everything in Debian main is Free.  Since
> > the RFC license is NOT Free, it can't be in main.  This does NOT
> > imply anything about the usefulness of RFCs, merely about their
> > Freedom.
> 
> There seem to be two ways of interpreting the social contract.  One is
> that the only thing (100%) included in Debian must be free software.
> The other one is that all software included in Debian must be free
> software, as defined by the DFSG.  Only if you use the first
> interpretation do you statement make sense.  I find it rather strange
> to try to handle everything as software, and believe we need to handle
> non-software with a different set of guidelines.  Until these
> guidelines are in place, I believe it is unwise to try to handle
> non-software as software and force the DFSG on all of these.

Umm...I find it hard to see how you can interpret "Debian will remain 100%
Free software" as meaning that only the software in Debian will always be
100% Free.  You *could* interpret it to mean that the only things in Debian
will be software that is Free if you wanted to...in which case RFCs (not
being software) do NOT belong in Debian.

Personally I prefer the option of treating everything that is in Debian as
being software (whether it is or not) and applying the DFSG to decide on
whether it is Free or not.

Whether we need guidelines for things which are non-software to determine
their Freeness or not is a different question.  However, while we DON'T have
those guidelines, we MUST use the only guidelines we do have, which is the
DFSG.

I had to agree to abide by the DFSG when I did NM as did everyone with an
account (unless they were given accounts before the NM process was created).
I *Still* believe that the DFSG is a useful set of guidelines for everything
in Debian.

To digress a little from the core point of the thread, I think that the fact
that there are some things which aren't Free, but which still serve our
users' needs, is a good reason for keeping non-free around.

I am wholly uncomfortable with the idea of putting non-free stuff in main
(the "because it's not really software, it doesn't really matter" argument).
I think the existence of something in Debian main implies somethign about
its freedom.  This is laid out in the Social Contract and the DFSG.  I wish
we could lose the stigma that non-free has.  There's nothing wrong with
things in non-free...they just are NOT FREE!  Putting something in main
implies that Debian as an entity endorsees it as Free.

I should explain here that I'm not half as rabidly anti non-free software as
many DDs.  I prefer to use Free stuff if it's available and is fit for
purpose.  If there isn't something Free available to do the task, I'll use
something non-free instead.  Just because I will use non-free software, does
NOT mean I think it belongs in Debian main though.  There is a committment
to keep Debian main 100% Free, and that's a committment I like.

/me stops before he goes on a real rant

Cheers,

Stephen


pgp1fail3suJW.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Stephen Stafford]

On Fri, Jul 04, 2003 at 12:47:19PM -0500, Chad Walstrom wrote:

> To require or demand that the IETF changes their copyright policy or
> their publishing practices to cater to someone else's idea of what the
> document should be used for is plain arogance.  Respect the wishes of
> the original authors and the established, reliable publishing policy of
> the IETF, and use the document in the proper manner: reference it in
> your own supplemental documentation.

I don't think anyone is implying that they should do that.  What is being
stated is that the license terms are not Free.  We have a commitment that
everything in Debian main is Free.  Since the RFC license is NOT Free, it
can't be in main.  This does NOT imply anything about the usefulness of
RFCs, merely about their Freedom.

This is one of the stronger arguments for keeping non-free around IMO.
There *are* things which aren't Free, and very likely shouldn't ever be Free
which nevertheless are useful things for our users to have.  I use hwb on a
regular basis, for example, and it is in non-free.  I understand and agree
with why it is in non-free, and I see no real problem with this.  It's STILL
useful enough to have it packaged and available to our users IMO.

> I really don't see what's wrong with the RFC copyright.  It is freely
> distributable reference documentation.  It is not software.  Perhaps it
> shouldn't be distributed in Debian "main" because of a pedantic
> interpretation of the DFSG, (there's that software reference again) and
> Social Contract.  Fine, but it should still be packaged.  It is a
> valuable reference, and having the convenience of package installation
> improves it's distribution amongst developers.

Exactly.  We *must* be able to distribute by the terms of the license.
Modifiability is less important for things like RFCs, certainly.  I still
think it's possible to license RFCs in a way I consider Free but which
preserves their usefulness though.  For example:

You are free to distribute this RFC.  You are free to modify the RFC and
redistribute your modifications provided it is clearly marked as bein a
modified version and NOT endorsed by IETF (perhaps forcing a rename
also).

I think something along those lines is Free and would pass DFSG (needs to be
fleshed out and put into legalspeak, obviously), whilst still providing the
protections that RFCs need from rogue modified standards documents.

Cheers,

Stephen

Bug#199881: ITP: rhyme -- console based rhyming dictionary

[Stephen Stafford]

Package: wnpp
Version: N/A; reported 2003-07-03
Severity: wishlist

  Package name: rhyme
  Version : 0.9
  Upstream Author : Brian (tuffy) Langenberger <[EMAIL PROTECTED]>
  URL : http://sourceforge.net/projects/rhyme
  License : GPL
  Description : console based rhyming dictionary


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux bitech88 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C

Bug#198158: architecture i386 isn't i386 anymore

[Stephen Stafford]

On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote:
> On Fri, 20 Jun 2003, Stephen Stafford wrote:
> > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > > What about perusing the INT 6 idea, and going all the way up to i686?
> > While I support the removal of 386 support, I absolutely and strenuously
> > object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
> > use a nunber of 4/586 machines still (I have one 486 which I use for
> > embedded development and 3 P100 boxen which are used for various things like
> > CVS server, gateway/firewall, testing various things).
> Note that my idea was about patching the kernel that so the newer opcodes 
> would be emulated in software.  Everything would still work even on a 386, 
> just slower -- and the speed decrease can be removed by running apt-build.

I'm still not convinced.  Your argument works just as well in reverse.  If
people running >=686 want to they are perfectly capable of building the
packages to take advantage of it themselves, and FAR more able to afford the
computrons to do so (recompiling most of a system on a 486 will never be my
idea of fun...on (say) a 1GHz machine, it's far easier to do)

I'm also still not convinced of the usefulness of these optinisations per
architecture at non-high loads.  I submit that a 486 is FAR more likely to
be running at high load than a 1GHz machine.  The 486 can far less afford
the performance hit from emulating instructions in software than a 1GHz
machine can by not having the small optimisations built by default.

This basically comes down to "will a significant portion of our userbase
suffer if we do this?"  Personally I think the answer is "yes".  You
obviously have a different viewpoint here :)

Cheers,

Stephen

Bug#198158: architecture i386 isn't i386 anymore

[Stephen Stafford]

On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote:
> 
> Stephen Stafford wrote:
> 
> >While I support the removal of 386 support, I absolutely and strenuously
> >object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
> >use a nunber of 4/586 machines still (I have one 486 which I use for
> >embedded development and 3 P100 boxen which are used for various things 
> >like
> >CVS server, gateway/firewall, testing various things).
> >
> >Judging from my random contacts with users, it's a fairly usual setup to 
> >see
> >a network of higher (500Mhz+) end hardware machines which sit on a LAN in
> >1918space and are masqueraded to the outside internet by a firewall/gateway
> >running Debian on a 486 or low end pentium.  I believe this to be a fairly
> >significant proportion of our userbase and I'd oppose any move to
> >marginalise them like this.
> 
> You will upgrade these router to sarge o newer distributions?
> i think removal of some 486sx will have some advantages (removal of
> software floating point support in kernels/disks..

I fail to see the gain in this.  If you don't need software floating point,
then it isn't used AFAIK.

Although, yes...in principle, I'm happy enough to drop 486sx support if it's
shown to have any real benefits.  I believe we should retain 486dx support
though.

Cheers,

Stephen

Bug#198158: architecture i386 isn't i386 anymore

[Stephen Stafford]

On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote:
> > In any case we need to make clear if we allow 486 optimisation that
> > are not i386 compatible or not.
> What about perusing the INT 6 idea, and going all the way up to i686?
> As i686 is already like ten(?) years old, I would say 99.9% [1] machines 
> that run sarge are 686 and higher -- thus, moving to i686-specific 
> optimizations would be good for the vast majority of users (this comes 
> from someone who set up two servers on P MMX two weeks ago :p)
> 
> If speed on archaic machines is an issue, you can always use the
> wonderful piece of software called apt-build.
>  

While I support the removal of 386 support, I absolutely and strenuously
object to going to 686.  686 isn't all that old at all (1997 IIRC), and I
use a nunber of 4/586 machines still (I have one 486 which I use for
embedded development and 3 P100 boxen which are used for various things like
CVS server, gateway/firewall, testing various things).

Judging from my random contacts with users, it's a fairly usual setup to see
a network of higher (500Mhz+) end hardware machines which sit on a LAN in
1918space and are masqueraded to the outside internet by a firewall/gateway
running Debian on a 486 or low end pentium.  I believe this to be a fairly
significant proportion of our userbase and I'd oppose any move to
marginalise them like this.

I'm not fully convinced that moving up to full 686 optimisation has that
many benefits under all but the highest loads anyway (in userspace at least,
we already have processor specific kernels).  Do you have a link to
a URL with studies/analysis of this?

Cheers,

Stephen

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Stephen Stafford]

On Tue, Apr 09, 2002 at 10:40:41PM +0200, Jeroen Dekkers wrote:
> On Tue, Apr 09, 2002 at 08:16:07PM +0100, Stephen Stafford wrote:
> 

> I just say the consequences of that choice, that is you're having
> problems with an old version and you don't have the freedom to fix
> that.
>  
> > >From reading this thread, it looks to me almost as if you would advocate a
> > system whereby Debian refused to run any non-free software at all.
> 
> s/refused/discouraged/ and I would agree. Isn't the goal of Debian
> providing a free system so users don't have to run any non-free
> software anymore? IMHO the "we support non-free software" clause was
> only temporary, when there are free alternatives for the non-free
> software we could drop the support of non-free software. I feel the
> time has come to drop it.

Then that is where we differ.  That is NOT what I see the goal of Debian as
being.  The goal of Debian (from where I stand at least) is to offer people
the *choice* of running free software if they want to.  If they *choose* to
run non-free software (either instead or as well) then they should have that
*choice*.  This is enshrined in the Social Contract.  If at some point this
changes then I will re-evaluate my position.  I suspect I will not be the
only one.

> 
> > The free alternatives to VMware are not really all that good at all I am
> > afraid.  Development on plex86 has pretty much died since Kevin changed
> > jobs.  bochs was never really an alternative at all, its aims are somewhat
> > different.
> 
> True, but plex86 development is going to continue, subscribe to the
> list if you want to get informed on everything.
> 

I have been a lurker on the plex86 list for roughly 2 years.

> > VMware might be non-free, but it is damn good.  
> 
> I think for the price of a license you can better buy a nice
> second-hand computer. I'm sure that will a damn bit better!! (I
> actually use this method, with an old computer I got for free beer)
> 

That is your *choice*.  I *choose* to run VMware instead.  Please do not
seek to restrict my freedom.

> > When a libc6 change breaks
> > it, then asking why is not *ever* a bad thing.  Expecting changes in libc6
> > to not break things is sensible.  If it does break stuff then we should look
> > at why.
> 
> We looked at it. We saw it wasn't libc's fault.
> 

But you can see why people might be forgiven for thinking it was?  An
unversioned change that breaks lots of stuff?  I think that looking to ask
questions to libc6 is not at all unreasonable.

> > If it turns out that the breakage is unavoidable, or serves a greater good
> > then fine.  I don't really understand this case well enough to know if that
> > is the case or not.  The breakage is/was deemed necessary by the libc6
> > maintainer (presumably) and I tend towards trusting Ben's judgement.
> 
> It's not really breakage, it's fixing a bug. The programs which now
> break were buggy, I don't see why there should be any support for
> that. Instead, the programs should get fixed

Programs which were not broken suddenly break and the reason they break is
because a bug was fixed??  Forgive me for finding this a hard thing to
understand.  I accept that it might be (probably is) true.  But it isn't
even close to obvious, or intuitive.


> > Your "advocacy" looks like so much wind and piss in all honesty.  You do no
> > favours either to yourself or to the free software movement by it.  You look
> > and sound like a rabid, unthinking, kneejerking moron.  That is usually a
> > description reserved for RMS :)
> 
> I already said people compare me with RMS and I take it as a
> compliment. Actually, there are people who can work with me (Yes,
> really!), there are also enough people who can work with
> RMS. Personally I never worked with RMS or discussed with him, but I
> don't think I would have big problems with that. I never see why
> everybody just say that RMS and GNU are bad.

I don't say that GNU and RMS are bad.  I *do* say that rabid and stupid
looking kneejerk reactions are bad, make you look bad, and make free
software look bad.

> 
> > Seriously examine what it is that you are saying.  What it looks like to me
> > (at least, probably others too) is "You run non-free software, so fuck off,
> > we hate you, we hate your mother, we hate your sister's cat.  Go whinge to
> > the people who made the non-free software, because they should have forseen
> > when they wrote their software a couple of years ago that we were going to
> > break it."
> 
> This want not meant so, I already apologized about that. Do I have to
> do more?
> 

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Stephen Stafford]

On Tue, Apr 09, 2002 at 08:25:47PM +0200, Jeroen Dekkers wrote:
> On Mon, Apr 08, 2002 at 11:47:42PM +0200, Jeroen Dekkers wrote:
> > It's your own fault. You choosed to run non-free software, now you get
> > the consequences. Debian doesn't support vmware, so go somewhere else
> > with your vmware problems. (Debian does support plex86 and bochs, BTW)
> 
> As this might be a bit too offensive I apologize if you read it that
> way. Here is an alternative wording which says what I actually meant
> (I never try to write a mail quickly just before I got to bed):
> 
> This problem is very common for non-free software. If you want to
> avoid such problems, you could try one of the free alternatives in
> Debian, plex86 and bochs. Those might have other problems (like being
> slower) but you probably won't have the same problems you're having
> now. We can also help you with problems you are having with plex86 and
> bochs. If you insist on using vmware, we can't help you, you should go
> to the vmware guys when you've got problems.
> 



I think you totally miss the point.  Free software is about choice.  What
you are saying is that it is okay for a library to change in a way that
breaks software which I *choose* to run.  The fact that software is non-free
is irrelevant.  I *choose* to run it.  I made an informed choice.  I looked
at the alternatives, and made a decision.  You look like you are wanting to
remove my ability to make that choice.

>From reading this thread, it looks to me almost as if you would advocate a
system whereby Debian refused to run any non-free software at all.

The free alternatives to VMware are not really all that good at all I am
afraid.  Development on plex86 has pretty much died since Kevin changed
jobs.  bochs was never really an alternative at all, its aims are somewhat
different.

VMware might be non-free, but it is damn good.  When a libc6 change breaks
it, then asking why is not *ever* a bad thing.  Expecting changes in libc6
to not break things is sensible.  If it does break stuff then we should look
at why.

If it turns out that the breakage is unavoidable, or serves a greater good
then fine.  I don't really understand this case well enough to know if that
is the case or not.  The breakage is/was deemed necessary by the libc6
maintainer (presumably) and I tend towards trusting Ben's judgement.

Your "advocacy" looks like so much wind and piss in all honesty.  You do no
favours either to yourself or to the free software movement by it.  You look
and sound like a rabid, unthinking, kneejerking moron.  That is usually a
description reserved for RMS :)

Seriously examine what it is that you are saying.  What it looks like to me
(at least, probably others too) is "You run non-free software, so fuck off,
we hate you, we hate your mother, we hate your sister's cat.  Go whinge to
the people who made the non-free software, because they should have forseen
when they wrote their software a couple of years ago that we were going to
break it."

When I joined Debian I did so with the understanding that "Our priorities
are our users and free software".  Free software is not served at all by
your silly rants, and our users are definitely not served by firstly having
the software they *choose* to run break, and secondly being insulted and
belittled by you for making that choice.  

One way or the other, VMware not working any more is a bug somewhere.
Whether it is a bug in libc6 or a bug in VMware itself.  Since VMware has
been running on this machine essentially without change for over a year, and
a new version of libc6 has just been installed, then surely I can be
forgiven for asking questions of libc6 first?

I know that it is very easy to be infected by the rabidity of "non-free is
bad by definition -- people who use it are either evil or misguided".  All I
can do is assure you that most people grow out of that.  I *choose* to use
non-free software of many kinds.  I am also forced to do so ssometimes.  I
will *not* have someone try to make me feel evil, stupid or misguided
because of it.




Cheers,

Stephen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Stephen Stafford]

On Mon, Apr 08, 2002 at 11:03:11AM -0500, Donald J Bindner wrote:
> On Wed, Mar 27, 2002 at 12:01:00AM +0100, Paul Seelig wrote:
> > [EMAIL PROTECTED] (Mike Phillips) writes:
> > Petr Vandrovec wrote:
> > 
> > > As SUSv2 mandates that new nice return value is correct,
> > > please use [EMAIL PROTECTED] (or @GLIBC_2.2.6 as it is in CVS
> > > only) for new nice() interface, so old applications will not
> > > break.
> > 
> > Let's replace movl %eax,%ebx with xorl %ebx,%ebx ;-) Apply
> > ftp://platan.vc.cvut.cz/pub/vmware/vmware-ws-1455-update12.tar.gz.
> > It fixes issue for VMware 3.0 and for some 3.1 betas. If you
> > are using VMware 2.0 and you suffer from this problem - sorry. 
> > 
> > It also fixes crash when you start vmnet-bridge with eth0
> > interface loaded, but down, and you'll not 'up' interface
> > before eth0 interface disappears (by rmmod -a, for example) by
> > fixing problem and not symptoms (like previous fix did).
> 
> Let me see if I understand this.  I am running VMWare 2.0.4 and
> this morning I discovered that it dies with:
> 
>   VMware Workstation PANIC:
>   AIO:  NOT_IMPLEMENTED F(566):1081
> 
> This is on a relatively current Woody system, and VMWare was
> running fine last week.  Is this the same issue, and does that
> leave me in the "sorry" category?
> 
> (I would like to believe not, since my VMWare sessions are
> suspended, and to upgrade them to 3.x I would need to have them
> running in 2.0 to turn them off properly).
> 

I think it does leave you in the "sorry" category, yes.  I had a similar
problem (running 2.0.x) and have had to downgrade libc6 packages to work
around it.  When I have time I will build a chroot for vmware to run in and
do it that way.  Unfortunately right now I just don't have the cash to
upgrade.

Cheers,

Stephen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A language by any other name

[Stephen Stafford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 19 Sep 2001 8:37 pm, John Hasler wrote:
> Steve Langasek writes:
> > en_UK is English as spoken in the United Kingdom.
>
> While en_GB is english as spoken in Great Britain.  Perhpas one of
> the residents thereof can explain the difference.

en_UK doesn't exist as a locale AFAIK, it is en_GB I believe.

The difference between "United KIngdom" and "Great Britain" is rather 
blurred.  However, it appears to be that "Great Britain" comprises 
England, Scotland and Wales, whereas "United Kindom" adds Northern 
Ireland to that.

stephen:~$ dict -d wn "united kingdom"
1 definition found
 
- From WordNet (r) 1.7 [wn]:
 
  United Kingdom
   n : a monarchy in northwestern Europe occupying most of the
   British Isles;  divided into England and Scotland and
   Wales and Northern Ireland [syn: {United Kingdom}, {UK},
   {Great Britain}, {Britain}, {United Kingdom of Great
   Britain and Northern Ireland}]


stephen:~$ dict -d wn "great britain"
1 definition found
 
- From WordNet (r) 1.7 [wn]:
 
  Great Britain
   n 1: a monarchy in northwestern Europe occupying most of the
British Isles;  divided into England and Scotland and
Wales and Northern Ireland [syn: {United Kingdom}, {UK},
 {Great Britain}, {Britain}, {United Kingdom of Great
Britain and Northern Ireland}]
   2: an island comprising England and Scotland and Wales [syn: 
{Great Britain}]


The line *does* seem rather blurry.  Personally I use the two terms 
interchangeably.  Others like to be more exact about it.

- -- 
Stephen Stafford
finger [EMAIL PROTECTED] to get gpg public key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7qRTtFwmY7Xa4pD0RAgSDAJoC2mV9/DWUwyXLVRSWmZ5Ck6rsowCdGFuf
tffIWgfx+sAZmMroxOuIDHU=
=guL+
-END PGP SIGNATURE-

Re: extra feature for debchange

[Stephen Stafford]

On Monday 10 Sep 2001 1:20 am, Brandon L. Griffith wrote:
> * Jason Thomas ([EMAIL PROTECTED]) wrote:
> > take a look at apt-listchanges
>
> aha I knew it, yet another apt-* or dpkg-* utility I haven't heard
> of. I need to keep more up to date on these things, or these
> utilities need to be more well ducumented. Is there a list, anywhere,
> of all these obscure? utilites that I seem to only find when it's too
> late?

grep-available -Ps Package dpkg
grep-available -Ps Package apt

-- 
Stephen Stafford
finger [EMAIL PROTECTED] to get gpg public key
I subscribe to most debian-* lists I post to, but a CC direct to me 
will ensure your reply gets dealt with faster, therefore please CC me 
on list replies