sliced bread (was: Debian-Installer rc3 released)

[Frank Küster]

Jesus Climent <[EMAIL PROTECTED]> wrote:

> Kudos to Joey and the D-I team for all the effort, dedication and time spent
> in making D-I one of the best pieces of code ever since the invention of apt
> and sliced bread.

Code?  Where's the code?  According to DFSG clause 2, you must give me
the source code for sliced bread!!!1

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: sliced bread (was: Debian-Installer rc3 released)

[Ben Hill]

On Thu, 2005-03-24 at 09:19 +0100, Frank Küster wrote:
> Code?  Where's the code?  According to DFSG clause 2, you must give me
> the source code for sliced bread!!!1

You just want your cake, and to eat it too.

Or is that something else?? ;-)

-- 
[EMAIL PROTECTED] - www.seigan.org
PGP Key fingerprint = 4309 1C58 5143 AFAC F69E  11CD 76FD 56D4 1223 E387

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

[Paul Hampson]

On Thu, Mar 24, 2005 at 07:39:04AM +0100, Jesus Climent wrote:
> On Thu, Mar 24, 2005 at 02:33:27PM +1100, Paul Hampson wrote:
> > On the other hand, I'm having a problem with the package, it
> > doesn't include muttng_dotlock, and seems to think my mailspool
> > (mbox in /var/mail) is read-only. (vanilla) Mutt can use it
> > fine.

> Same problem here. Reported to Norbert but never got deeper into it. Let's try
> renaming mutt_dotlock to muttng_dotlock ;)

I hard-linked muttng_dotlock to mutt_dotlock but it didn't
help. I might futz with it later, once I get sick of using
vanilla mutt for my Inbox. ^_^

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpS6wCdHg6wB.pgp
Description: PGP signature

Possible compromise on releasing architectures

[Blars Blarson]

The Vancouver meeting concluded that more of the burden of supporting
the various architectures needs to be on the port teams, but did not
supply a workable way for releases to be made on less popular
architectures.

Here's a proposal that will hopefully both meet the main desires of
the release managers and the port teams.

Release architecture:

* All FTBFS and architecture specific bugs are release critical
* packages must be built on all to propagate to testing

Release candidate architecture:

* testing managed by port release manager(s)
* testing consists of packages that built on the candidate and
  are in release architecture testing with the same version
* testing proposed updates may be needed more often due to changes
  in dependencies
* need a way to propagate architecture specific packages (such as 
  boot loaders) to testing
* FTBFS and other architecture specific bugs are release critical 
  if a reasonable[0] patch is in the BTS
* Will release if testing is in good shape at release time, or at 
  point release time
* stable security team may decide not to provide security support

Non-release architecture:

* no testing, unstable only

[0] When there is a difference on what is reasonable, the technical
committee will decide.


-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Re: Vancouver meeting - clarifications

[Anthony Towns]

Pierre THIERRY wrote:
Scribit Anthony Towns dies 23/03/2005 hora 21:52:
Pierre THIERRY wrote:
- Debian: 11 ports, 9157 packages (sarge) [17593 in sid]
Hrm, where are those numbers from?
wc -l (modulo the first lines) of the allpackages.txt file on the
website
Aha, with just a straight wc -l of those, I get:
9163 stable.txt
   16371 testing.txt
   17463 unstable.txt
So looks like "sarge" above should be "woody".
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: If Debian's too radical for you... [was: NEW handling: About rejects, and kernels]

[Matthew Palmer]

On Thu, Mar 24, 2005 at 08:49:39AM +0100, Marc Haber wrote:
> On Thu, 24 Mar 2005 11:13:05 +1100, Matthew Palmer
> >"Some would say that this has already happened".  Not a fork, per se, but
> >Ubuntu's licencing policy (and the general level-headedness of the people I
> >know who are deeply involved in it) suggests that it may be the refuge you
> >seek.
> 
> Is it as easy to participate with Ubuntu as it is with Debian?

I can't say for sure, since I'm not an Ubuntu contributor, but from what
I've read on their website, it doesn't look particularly difficult.  Their
BTS and communications are open, and they have a documented process for
getting upload access, so the basics are there.  There appears to be several
volunteer contributors already, so I think things are running along there.

I guess whether "it's as easy as Debian" is subjective -- some people will
probably find it easier to contribute, and others more difficult, because of
the differing styles of the two projects.  Those who have a religious
objection to our e-mail based BTS, for instance, might find Ubuntu's
bugzilla more appealing.  

- Matt


signature.asc
Description: Digital signature

Re: debian development diagram: major rework!

[Kevin Mark]

On Wed, Mar 23, 2005 at 09:05:28PM +0100, Josselin Mouette wrote:
> Le dimanche 20 mars 2005 à 08:48 -0500, Kevin Mark a écrit :
> > Hi all you folks who have exercised your fingers and eyes because of
> > 'vancouvor',
> > In my quest to see how things work, I have made some major revision to
> > my diagram.
> > http://debian.home.pipeline.com/
> > the new diagram is newdebian2.png
> > any comment appreciated (before the whole shebang is outdated)
> 
> Just a comment: the ACCEPTED mail is sent once the package is accepted;
> your diagram leads to thinking it is sent by the maintainer himself.

ACK.

cheers,
Kev

-- 
counter.li.org #238656 -- goto counter.li.org and be counted!


signature.asc
Description: Digital signature

Re: Possible compromise on releasing architectures

[Blars Blarson]

On Thu, Mar 24, 2005 at 10:12:35AM +0100, Jan Niehusmann wrote:
> On Thu, Mar 24, 2005 at 12:59:19AM -0800, Blars Blarson wrote:
> > Release candidate architecture:
> > 
> > * testing managed by port release manager(s)
> > * testing consists of packages that built on the candidate and
> >   are in release architecture testing with the same version
> 
> Please specify what applies to sources and what to binaries. As I
> understand your proposal, one would need architecture specific source
> repositories (as different architectures may have different versions 
> in testing).

My proposale included "same version".  Testing will have the same
version if any on all architectures.  Testing may be broken by missing
packages on the candidate.

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Andreas Barth]

* Russell Coker ([EMAIL PROTECTED]) [050324 00:35]:
> On Thursday 24 March 2005 03:40, Theodore Ts'o <[EMAIL PROTECTED]> wrote:
> > If the free software fanatics succeed in kicking non-free from being
> > supported by Debian assets, such that the FSF documentation were no
> > longer available, I'd probably end up agreeing with you and probably
> > would do what you are considering to do after sarge ships.
> >
> > If it would help, I'd ask you to reconsider.  If all the reasonable
> > moderates leave, then all that will be left will be the extremists.

> Of course an option is always to fork the project.  Maybe it's time to have a 
> Debian project that focusses on getting software released as opposed to the 
> Debian that wants to be fanatic.

Actually, I believe the Debian project as whole _wants_ to getting
software released. That was at least the decision in all GRs where
people didn't hide the intents ("editorial changes").


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

[David Schmitt]

On Thursday 24 March 2005 00:09, Petri Latvala wrote:
> On Wed, Mar 23, 2005 at 07:35:35PM +0100, Elimar Riesebieter wrote:
> >   Version : x.y.z
> >   Upstream Author : Name <[EMAIL PROTECTED]>
> > * URL : http://www.example.org/
> > * License : (GPL, LGPL, BSD, MIT/X, etc.)
>
> Didn't feel the need to fill those in?

Perhaps a little private reminder had sufficed?

I'm tempted to ask "Didn't feel the need to be polite?", but then I'd probably 
have to read another dragged out discussion about how blind people are and 
how many prospective maintainers have already failed to fill out these 
fields.

Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Bernhard R. Link]

* Raphael Hertzog <[EMAIL PROTECTED]> [050322 22:39]:
> I'm also not satisfied with the non-productiveness of the removal of
> useful documentation. I'm also ashamed that some hardware doesn't work
> out of the box on Debian because we decided that firmware are software
> and thus should meet DFSG.
> 
> However I don't plan to leave Debian because it's just not the right
> thing to do.
> 
> I joined Debian because its goal was to satisfy its users... and sadly
> it turns that some developers forget about that when prefering freeness
> over the service to our users.

I'm sad that you see it this way. But in my eyes freeness is one of our
most beneficial services to our users.

For those aspects of computer life we and our users are locked into
software we (including developers and users) are not allowed to fix, 
not allowed to see what they do and/or maybe not even allowed to give
to others, we (Debian) supply the non-free section in addition to our
distribution. I think this is an important service, though one the one
hand I'm happy it has lost much of its importance for applications as
there are nowadays much more free alternatives, and on the other hand
non-free licenses shift a bit into the direction where we are not even
allowed to ship them in non-free.

But the goal we should aim is still "Debian is a free operating system
(OS) for your computer." We are about free software. And free software
includes the promise for freedom. I'm sick of bloody buggy non-free
drivers I'm not allowed to look close enough to have a chance to fix
them. I'm sick of software telling me I have to download it for each
single computer again instead of once and distributing it. I'm sick
of software I'm not able to redistribute to others as I could have
to pay for some legal fees, I'm sick of documentation I'm not allowed
to merge with the documentation within the code, not allowed to bring
in forms I like, or with preposterous demands like not changing the
title or adding a 20k text into every manpage or digest sheet. 

And I really think we have no right to foist such things on our users.

Put non-free stuff in non-free, that's what it is for. If we are unable
to offer free programs, drivers and documentation, we have no right to
hide the next best thing in main. If we are unable to provide what we
promised (free stuff) we should at least mark the non-free stuff as
non-free stuff, so that our users can make their decision.

> We need to have a big political shift on that side, or we'll loose more
> valuable contributors in favor of other distributions... you may not
> care but I want Debian to stay the central distribution and I don't want
> that other distributions do a better service to users than us.

Has there ever been a time when people did not tell Debian will die
instantly (or perhaps only next month) if we do not do what some people
say our users consider the "better service".

Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.


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

Re: If Debian's too radical for you... [was: NEW handling: About rejects, and kernels]

[Thomas Hood]

On Thu, 24 Mar 2005 08:50:16 +0100, Marc Haber wrote:
> Is it as easy to participate with Ubuntu as it is with Debian?

In some respects it is easier.  For one thing you can become a maintainer
there without going through an NM ordeal.

-- 
Thomas Hood


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

Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

[Guido Guenther]

n Wed, Mar 16, 2005 at 10:44:15AM -0500, Kyle McMartin wrote:
> On Wed, Mar 16, 2005 at 03:06:19PM +, Rob Taylor wrote:
> > Yes, that makes total sense. Would there likely be major objections to
> > this?
> >
> 
> Even less (likely zero) testing of packages by the maintainer before they
> upload? This is definitely a serious problem...
The binary deb that comes with the source only ensures that the package
is buildable on at least one arch. So don't allow for source only
uploads, rebuild on the uploaded arch and discard the uploaded binary. 
 -- Guido

> 
> Famous last words...
> "Oh, I'll just make this one change, rebuild source and upload."
> 
> --Kyle 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


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

Processed: Re: fonts, entiity and konqueror/qt

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> clone 238833 -1
Bug#238833: general: not all fonts contain glyphs for all codepoints
Bug 238833 cloned as bug 301194.

> reassign -1 libqt3c102-mt
Bug#301194: general: not all fonts contain glyphs for all codepoints
Bug reassigned from package `general' to `libqt3c102-mt'.

> tag -1 +upstream
Bug#301194: general: not all fonts contain glyphs for all codepoints
There were no tags set.
Tags added: upstream

> retitle -1 konqueror: Fails to render ∀ ∈ ∧
Bug#301194: general: not all fonts contain glyphs for all codepoints
Changed Bug title.

> quit
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

[Norbert Tretkowski]

* Jesus Climent wrote:
> On Thu, Mar 24, 2005 at 02:33:27PM +1100, Paul Hampson wrote:
> > On the other hand, I'm having a problem with the package, it
> > doesn't include muttng_dotlock, and seems to think my mailspool
> > (mbox in /var/mail) is read-only. (vanilla) Mutt can use it fine.
> 
> Same problem here. Reported to Norbert but never got deeper into it.
> Let's try renaming mutt_dotlock to muttng_dotlock ;)

I did that after your report a while ago, and my last package[0]
includes muttng_dotlock.

[0]: http://people.debian.org/~nobse/debian/unstable/

Norbert


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

Re: Possible compromise on releasing architectures

[Jan Niehusmann]

On Thu, Mar 24, 2005 at 12:59:19AM -0800, Blars Blarson wrote:
> Release candidate architecture:
> 
> * testing managed by port release manager(s)
> * testing consists of packages that built on the candidate and
>   are in release architecture testing with the same version

Please specify what applies to sources and what to binaries. As I
understand your proposal, one would need architecture specific source
repositories (as different architectures may have different versions 
in testing).

Jan


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

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

[Jesus Climent]

On Thu, Mar 24, 2005 at 10:03:02AM +0100, Norbert Tretkowski wrote:
>
> > Same problem here. Reported to Norbert but never got deeper into it.
> > Let's try renaming mutt_dotlock to muttng_dotlock ;)
> 
> I did that after your report a while ago, and my last package[0]
> includes muttng_dotlock.

I was, obviously, the one who never got deeper into the problem.

Thanks, Norbert!

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

I never drink ... wine.
--Dracula (Dracula)


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

Re: Two thougts about testing

[Steve Langasek]

On Tue, Mar 22, 2005 at 10:55:05AM +0100, Erik Schanze wrote:
> Joerg Friedrich <[EMAIL PROTECTED]>:
> > reading larger parts of the recent threads triggered by the
> > 'Vancouver proposal' brought me to write this mail.
> >
> > Over the last two years testing became more and more a second
> > (almost) stable distribution instead of being a preparation area for the
> > next release. Now there is even security support it is not a officially
> > supported release.
> >
> > Nevertheless I believe that testing is a good idea. But it suffers from
> > some problems.

> > 1. The number of packages
> >Debian never stopped growing, and there are packages which are
> >unmaintained but they are still in the archive.
> >Hey, if noone is willing to maintain a package, wait a grace period
> >(30 days) and remove it from unstable and testing. If somone needs
> >it, he could step forward and maintain it.

This doesn't seem like a very good heuristic to me, and it's not something
that's currently a major source of work for the release team.  Currently,
packages in testing are candidates for removal if they've had
release-critical bugs open for more than a week; it doesn't matter if
they're orphaned or not.  Likewise, if a package *doesn't* have
release-critical bugs, it doesn't matter if it's orphaned or not: being
orphaned for a month just isn't a good indicator of the utility, or the
quality, of the package.

Auto-removal of orphaned packages from unstable is also bad if it's an
orphaned library that's still needed (which happens often enough).

> If RC-bugs remain unfixed for a period, I agree with removing, but this is 
> common practice, I think. Perhaps somethimes too slow. ;-)

Hmm, 7 days is too slow?

> Perhaps wnpp websites could be improved to show a ranking list of packages 
> which will be removed soon and why. A Section "Removal Candidates" in DWN 
> could be also helpful.

The thought is to use the new debian-testing-changes mailing list to notify
when (and why) packages have been removed from testing.  Currently, we don't
have any automatic way to notify maintainers of a package's removal from
testing, which is bad.

I don't think DWN is a good choice here, though; weekly reports won't be a
very good starting point for people interested in working on the packages.

> > 2. Unstable to testing migration is one way
> >Packages migrate to testing automaticly, but removal requires manual
> >action.
> >I noticed that some developers work hard to get a package or a
> >specific version into testing, but if a new (rc) bug occurs after the
> >migration, nothing happens.
> >At least optional and extra packages should be removed automaticly if
> >a new rc bug emerges.
> >E.g. if noone claims to fix the bug, an extra package should be
> >removed from testing after one, an optional after two weeks. And also
> >all packages which depend on the buggy one.

Again, I don't think there are any grounds for automating this.  RC-buggy
packages that are clearly expendable do get removed from testing quite
quickly.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Development files for manipulating Debian packages

[Ivan Kirchev]

Hello all,

Does Debian package management suite provide C APIs for
easier program manipulation of .deb files?

I am looking for something like RedHat's rpm-devel  C API but
still in vain...

--
Best Regards,
   Ivan Kirchev

[If everything seems under control, you're just not going fast enough.]




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

Re: Found an http SourceForge archive mirror

[Free Ekanayaka]

|--==> Bartosz Fenski aka fEnIo writes:

  BFaf> [1  ]
  BFaf> On Wed, Mar 23, 2005 at 11:24:21AM +0100, Free Ekanayaka wrote:
  >>For who cares..
  >>
  >>I've noticed that my old sf ftp mirror [0] is down/broken/unmaintained.
  >>
  >>After googling a bit I found a new one:
  >>
  >>http://sf.gds.tuwien.ac.at/
  >>
  >>Thus a debian/watch like:
  >>
  >>version=2
  >>http://sf.gds.tuwien.ac.at/a/al/alsamodular/ams-(.*)\.tar\.bz2 debian 
uupdate
  >>
  >>is working for my ams package.

  BFaf> What about prdownloads.sourceforge.net? 

Cool! So simple, didn't know about that.. thanks.

Would it be the case to add a FAQ to the devscripts documentation?

Cheers,

Free


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

Re: Two thougts about testing

[Thiemo Seufer]

Steve Langasek wrote:
[snip]
> Auto-removal of orphaned packages from unstable is also bad if it's an
> orphaned library that's still needed (which happens often enough).

Auto-removal of orphaned (build-)dependency leaves sounds useful.
This would also remove orphaned libraries after a while if the
library users are also orphaned.


Thiemo


signature.asc
Description: Digital signature

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Hamish Moffatt]

On Thu, Mar 24, 2005 at 10:59:37AM +0100, Bernhard R. Link wrote:
> * Raphael Hertzog <[EMAIL PROTECTED]> [050322 22:39]:
> > I'm also not satisfied with the non-productiveness of the removal of
> > useful documentation. I'm also ashamed that some hardware doesn't work
> > out of the box on Debian because we decided that firmware are software
> > and thus should meet DFSG.
> 
[...]

> I'm sad that you see it this way. But in my eyes freeness is one of our
> most beneficial services to our users.

Please don't rehash old arguments. Nobody has argued that we should put
non-free packages into main, but we don't agree on what is free and what
isn't for all types of packages.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Getting openswan 2.2.0 back into sarge

[Rene Mayrhofer]

Hi all, 

[Please CC me in replies, I am currently not subscribed to this list.]

As some have already noticed, openswan has been removed from testing a while 
ago, most probably because of bug #291274, which did not apply to package 
version 2.2.0-4 (the one that has been removed from testing). As 2.3.0 
upstream is currently not production quality (this is my personal opinion, 
since it basically triggers a DoS on 2.2.0 installations, cf. #292132), I did 
not work on getting it into testing. Of course, I have to admit that I have 
been lazy in not filing a RC bug report to prevent it from entering testing 
and fixing this bug. However, it looked like 2.3.1 might get released soon at 
that time, so I had decided to wait for it and push it into testing as soon 
as the new upstream is there. At the moment, 2.3.1 is nowhere to be seen and 
I would really like to have a working (and not DoS-triggering) openswan in 
testing. My current intention would be to get 2.2.0-4 back into testing, 
which worked well in all of my own tests (I am still using that particular 
version on many production boxes) and does not seem to be broken for other 
users. What is the general opinion on that?

with best regards,
Rene


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

Re: Let's stop feeding the NVidia cuckoo

[Paul Hedderly]

On Mon, Mar 07, 2005 at 07:31:22AM -0600, John Hasler wrote:
> Henning Makholm writes:
> > Yes, but we shouldn't act as if it was a _freedom_ problem.
> 
> If it was deliberately made bloody horribly ugly and painful in order to
> make changing it difficult, it's a freedom problem.

Not really. How NV choose to do stuff is totally up to NV. What we have
is source code (yes code that can be compiled) which is unencumbered, we
can modify,compile, distribute etc... whether it is _harder_ to modify
or not because of choices the _owner/author_ has made or not... is
nothing to do with freedom.

--
Paul 


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

Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d

[Bartosz Fenski aka fEnIo]

On Thu, Mar 24, 2005 at 11:42:48AM +0100, David Schmitt wrote:
> zion:~# apt-cache showpkg libsdl-mixer1.2 libsdl-net1.2 libsdl1.2debian-all | 
> grep '^  ' | sort -u | cut -d ',' -f 1 > /tmp/sdldeps
> zion:~# apt-cache showpkg libwxgtk2.4 | grep '^  ' | sort -u | cut -d ',' -f 
> 1 
> > /tmp/wxdeps 
> zion:~# diff -u /tmp/sdldeps /tmp/wxdeps  | grep '^ '
>scorched3d
> zion:~# 
> 
> It seems that this conflict only affects scorched3d.

Yep since nothing else depends on libwxgtk2.4 and libsdl in the same time.
 
> Is there a possibility to check for these things on a global level?

Thanks David for checking this. 

I made further checks and here's what I got:

[ sid / unstable ]

([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so   
libartsc.so.0 => /usr/lib/libartsc.so.0 (0x40103000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40109000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x4010e000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40113000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x40193000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x4019b000)
libaudio.so.2 => /usr/lib/libaudio.so.2 (0x401bf000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x401d4000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40226000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402ed000)
libvga.so.1 => /usr/lib/libvga.so.1 (0x402fb000)
libaa.so.1 => /usr/lib/libaa.so.1 (0x4036)
libasound.so.2 => /usr/lib/libasound.so.2 (0x4037c000)
libm.so.6 => /lib/libm.so.6 (0x4042f000)
libdl.so.2 => /lib/libdl.so.2 (0x40452000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40455000)
libc.so.6 => /lib/libc.so.6 (0x404a6000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x405d9000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x405e2000)
libncurses.so.5 => /lib/libncurses.so.5 (0x405fa000)
libslang.so.1 => /lib/libslang.so.1 (0x40639000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0x406ac000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
([EMAIL PROTECTED])~$

[ sarge / testing ]

([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so
libm.so.6 => /lib/libm.so.6 (0x400ad000)
libdl.so.2 => /lib/libdl.so.2 (0x400cf000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400d2000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4019a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x401a8000)
libc.so.6 => /lib/libc.so.6 (0x401f9000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
([EMAIL PROTECTED])~$

Any reason for such huge disproportions? That's where we got libglib2.0.
Scorched3D built on sarge works fine and doesn't link against libglib2.0.

I asked some of mine friends using other distros for pasting me output of
`ldd /usr/lib/libSDL.so | wc -l`

Here are some stats [ we've got in sid 23 ]

slackware current - 11
gentoo - 14 (we know this could vary a lot)

Also seems that other distros have wxgtk2.4 linked against libglib2.0 and
libsdl doesn't linked against any libglib.
This way most other distros have scorched3d linked against libglib2.0, but
only because wxgtk2.4 and not libsdl.

I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
glib2.0? Or unlink libsdl from using libglib?

regards
fEnIo
-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d

[David Schmitt]

On Thursday 24 March 2005 14:37, Bartosz Fenski aka fEnIo wrote:
[analysis skipped]
> I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
> glib2.0? Or unlink libsdl from using libglib?

I found the cause:

libSDL.so from libsdl1.2debian-all links against glib2.0 (and much other 
stuff)

libSDL.so from libsdl1.2debian-alsa:

zion:~# ldd /usr/lib/libSDL.so  | sort
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7e7c000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7e6e000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7dba000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7c52000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7d95000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7d98000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7d86000)
zion:~#

scorched3d loads fine for me now, I could start a game (though textures were 
messed up).


Looking at Depends of libsdl1.2debian-*, a Conflicts: libsdl1.2debian-all, 
libsdl1.2debian-arts would probably help.



Regards, David

-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

[Adeodato Simó]

* David Schmitt [Thu, 24 Mar 2005 10:44:31 +0100]:
> how many prospective maintainers have already failed to fill out these 
> fields.

  #293361 - reportbug: add reminder to fill fields to the ITP template

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Don't ask the barber whether you need a haircut.
-- Daniel S. Greenberg


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

Re: Debian-Installer rc3 released

[Otavio Salvador]

|| On Wed, 23 Mar 2005 23:53:25 -0500
|| Joey Hess <[EMAIL PROTECTED]> wrote: 

jh> The Debian Installer team is proud to announce the third release candidate
jh> of the Debian Installer for Debian GNU/Linux Sarge. We love doing this so
jh> much that we couldn't resist updating the installer one more time before
jh> the official release of Debian 3.1.

Please, resend it to debian-devel-announce too

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Packages count (was Re: Vancouver meeting - clarifications)

[Pierre THIERRY]

> So looks like "sarge" above should be "woody".

Oh, yes. I was wondering why I found so few (!) packages, because last
time I installed a fresh sarge, some debconf screen told me I could
install something like 14K packages...

BTW, is there any other distrib that includes officially so many
packages?

Increasingly,
Nowhere man
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d

[Bartosz Fenski aka fEnIo]

On Thu, Mar 24, 2005 at 03:11:32PM +0100, Josselin Mouette wrote:

[...]

> Sarge and sid have the same SDL version. You are basically comparing
> libsdl1.2debian-all and libsdl1.2debian-oss.

Yes you're right. I didn't notice that I'm using -all on my box.
 
> > Any reason for such huge disproportions? That's where we got libglib2.0.
> > Scorched3D built on sarge works fine and doesn't link against libglib2.0.
> 
> That's an indirect dependency (brought by libarts), that you won't see
> if you pass --as-needed to ld. However, this is not enough, as users
> having libsdl1.2debian-{all,arts} installed will still get this
> dependency at runtime, probably leading to segfaults.

So I suppose that Conflicts: libsdl1.2debian-{all,arts} isn't a solution?

ARTS users won't be able to use Scorched3D then :/
 
> > Also seems that other distros have wxgtk2.4 linked against libglib2.0 and
> > libsdl doesn't linked against any libglib.
> > This way most other distros have scorched3d linked against libglib2.0, but
> > only because wxgtk2.4 and not libsdl.
> 
> This may be because they are building a GTK+2.0 version of libwxgtk2.4.
> 
> > I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
> > glib2.0? Or unlink libsdl from using libglib?
> 
> I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
> together with wxgtk2.4, if possible, would be a good option. IIRC, it's
> possible to rebuild WxWidgets 2.4 against GTK+ 2.x, but it requires
> changes in the applications because of the move to UTF8.

Hmm, so I wonder how it's done in other distros where wxwidgets uses
gtk2.x. Or maybe they don't use `apt-cache rdepends libwxgtk2.4`?

regards
fEnIo
-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d

[Josselin Mouette]

Le jeudi 24 mars 2005 à 14:37 +0100, Bartosz Fenski aka fEnIo a écrit :
> [ sid / unstable ]
> 
> ([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so   
> libartsc.so.0 => /usr/lib/libartsc.so.0 (0x40103000)
> libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40109000)
> libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x4010e000)
> libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40113000)
> libesd.so.0 => /usr/lib/libesd.so.0 (0x40193000)
> libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x4019b000)
> libaudio.so.2 => /usr/lib/libaudio.so.2 (0x401bf000)
> libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x401d4000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40226000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402ed000)
> libvga.so.1 => /usr/lib/libvga.so.1 (0x402fb000)
> libaa.so.1 => /usr/lib/libaa.so.1 (0x4036)
> libasound.so.2 => /usr/lib/libasound.so.2 (0x4037c000)
> libm.so.6 => /lib/libm.so.6 (0x4042f000)
> libdl.so.2 => /lib/libdl.so.2 (0x40452000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x40455000)
> libc.so.6 => /lib/libc.so.6 (0x404a6000)
> libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x405d9000)
> libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x405e2000)
> libncurses.so.5 => /lib/libncurses.so.5 (0x405fa000)
> libslang.so.1 => /lib/libslang.so.1 (0x40639000)
> libgpm.so.1 => /usr/lib/libgpm.so.1 (0x406ac000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
> ([EMAIL PROTECTED])~$
> 
> [ sarge / testing ]
> 
> ([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so
> libm.so.6 => /lib/libm.so.6 (0x400ad000)
> libdl.so.2 => /lib/libdl.so.2 (0x400cf000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400d2000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4019a000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x401a8000)
> libc.so.6 => /lib/libc.so.6 (0x401f9000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)
> ([EMAIL PROTECTED])~$

Sarge and sid have the same SDL version. You are basically comparing
libsdl1.2debian-all and libsdl1.2debian-oss.

> Any reason for such huge disproportions? That's where we got libglib2.0.
> Scorched3D built on sarge works fine and doesn't link against libglib2.0.

That's an indirect dependency (brought by libarts), that you won't see
if you pass --as-needed to ld. However, this is not enough, as users
having libsdl1.2debian-{all,arts} installed will still get this
dependency at runtime, probably leading to segfaults.

> Also seems that other distros have wxgtk2.4 linked against libglib2.0 and
> libsdl doesn't linked against any libglib.
> This way most other distros have scorched3d linked against libglib2.0, but
> only because wxgtk2.4 and not libsdl.

This may be because they are building a GTK+2.0 version of libwxgtk2.4.

> I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
> glib2.0? Or unlink libsdl from using libglib?

I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
together with wxgtk2.4, if possible, would be a good option. IIRC, it's
possible to rebuild WxWidgets 2.4 against GTK+ 2.x, but it requires
changes in the applications because of the move to UTF8.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d

[Henrique de Moraes Holschuh]

On Thu, 24 Mar 2005, Josselin Mouette wrote:
> > I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
> > glib2.0? Or unlink libsdl from using libglib?
> 
> I'm afraid there is no miracle solution. Getting wxgtk2.5 to install

Miracle? no.  Technical, sound, and sane? Yes: Version the symbols properly
on all libraries that are going to be used by other libraries.  Gnome and
Kde should have been doing this since day one, since they are the very
definition of library hell.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: HOWTO Help (was: Debian DPL Debate Comments)

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexander Schmehl wrote:

> I think it is quite short and is missing some quite easy tasks that can
> be done by nearly everyone.
> 
> I did the mentioned talk and am about to write the document, because I
> got asked a couple of times what people can do to help us, so I think
> there is need for a more detailed document about that.
> 
> But thanks for the hint anyway; if it is ready, it should be linked
> from there ;)

Please do it.
It would help a lot to people like me who are willing to contribute but are
confused/scared about the legislations listed into some short docs.

Regards,

rrs
- -- 
Ritesh Raj Sarraf
RESEARCHUT -- http://www.researchut.com
Gnupg Key ID: 04F130BC
"Stealing logic from one person is plagiarism, stealing from many is
research".
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCQbOL4Rhi6gTxMLwRArcAAJ9bb+uY1NJxor/3l6fpLj4/7zrUoQCfXwKS
sjdLFV7vCVDLywbPrO7gPGs=
=pee/
-END PGP SIGNATURE-


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

Idea: about package installation under chroot.

[Jorge L. deLyra]

Dear Debian developers,

I would like to consult the developer community on the following issue.

Here is the story: Debian packages including daemons may be a problem for
people installing them via chroot, due to the fact that the packages will
typically try to stop and restart the daemons. In fact, this can interact
destructively with the system of the server, accidentally killing this or
that process. It may also cause the Debian package tools to crash.

Installation via chroot can be very useful for embedded systems, and also
for diskless machines that boot remotely from a server and mount the root
via NFS. If a package is being installed via chroot running in the server
it does not really make any sense to try to stop or start daemons.

Although most packages do in fact survive this process, in the sense that
the installation completes despite some errors when stopping and starting
daemons, some do cause the package tools to exit in error, leaving behind
a broken package. One example that is particularly troublesome is rwhod.

Now, all this can be avoided very simply by a line in the init.d/ script
for the daemon, checking that /proc is mounted. Since it will be mounted
on normal systems but typically not when using a chroot shell, it serves
as a flag to enable the daemon restarting procedure.

I am using successfully the following line to fix the situation in the
case of the troublesome rwhod package, near the top of the file:

test -e /proc/mounts || exit 0

So here are my questions: is there any way in which including a line like
this in the init.d/ scripts can be adopted as a standard procedure in the
future, for all Debian packages containing daemons?

Are there, perhaps, undesirable side effects to this?

Is there some other, better solution to this problem?

Solving this problem would certainly help people using chroot to install
packages and so help to extend the range of applicability and usefulness
of Debian.
Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]



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

Re: Call for votes for the Debian Project Leader Election 2005

[Alberto Gonzalez Iniesta]

On Sun, Mar 20, 2005 at 05:24:15PM -0600, Debian Project Secretary wrote:
> Hi,
> 
>FIRST CALL FOR VOTES FOR THE DEBIAN PROJECT LEADER ELECTION 2005
>=  === = === === == === ==  
> 
>  Votinge period starts 00:00:01 UTC on March 21st, 2005.
>  Votes must be received by 23:59:59 UTC on April 10th, 2005.
> 
> This vote is being conducted as required by the Debian Constitution.
> You may see the constitution at http://www.debian.org/devel/constitution.
> For voting questions contact [EMAIL PROTECTED]
> 
> HOW TO VOTE
> 
> Do not erase anything between the lines below and do not change the
> choice names.
> 
> In the brackets next to your preferred choice, place a 1. Place a 2 in
> the brackets next to your next choice. Continue till you reach your
> last choice. Do not enter a number smaller than 1 or larger than 7.
> You may skip numbers.  You may rank options equally (as long as all
> choices X you make fall in the range 1<= X <= 7).
> 
> To vote "no, no matter what" rank "None Of The Above" as more
> desirable than the unacceptable choices, or You may rank the "None Of
> The Above" choice, and leave choices you consider unacceptable
> blank. Unranked choices are considered equally the least desired
> choices, and ranked below all ranked choices. (Note: if the None Of
> The Above choice is unranked, then it is equal to all other unranked
> choices, if any -- no special consideration is given to the None Of
> The Above choice by the voting software).
> 
> Then mail the ballot to: [EMAIL PROTECTED] 
> Don't worry about spacing of the columns or any quote characters
> (">") that your reply inserts. NOTE: The vote must be GPG signed
> (or PGP signed) with your key that is in the Debian keyring. 
> 
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 46348448-74a5-40ae-a651-49704435ae8c
> [ 3 ] Choice 1: Jonathan Walther 
> [   ] Choice 2: Matthew Garrett 
> [ 2 ] Choice 3: Branden Robinson 
> [   ] Choice 4: Anthony Towns 
> [   ] Choice 5: Angus Lees 
> [ 4 ] Choice 6: Andreas Schuldei
> [ 1 ] Choice 7: None Of The Above
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 
> --
> 
> The responses to a valid vote shall be signed by the vote key created
> for this vote. The public key for the vote, signed by the Project
> secretary, is appended below.



-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.org

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3


signature.asc
Description: Digital signature

Bug#77570: Bug #77570 - corrupted *status* file (tagged unreproducible but shloudn't it be closed ?)

[browaeys . alban]

Could i close this bug ?

This is a followup for bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77570


> Configuring packages ...
> dpkg: parse error, in file `/var/lib/dpkg/status' near line
> 22622:
>  invalid package name (character `<' not allowed - only
>  letters, digits and -+._ allowed)
> E: Sub-process /usr/bin/dpkg returned an error code (2)

there is a backup of status in /var/backups anyway ...

Thanks
Alban




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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Thomas Bushnell BSG]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> Please don't rehash old arguments. Nobody has argued that we should put
> non-free packages into main, but we don't agree on what is free and what
> isn't for all types of packages.

Actually, nobody from the "more lenient" side has given a description
of what they think the right bounds for freeness are for
documentation, and why those bounds should be different than for
programs.

Thomas


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

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

[Elimar Riesebieter]

On Thu, 24 Mar 2005 the mental interface of
Paul Hampson told:

> On Wed, Mar 23, 2005 at 08:53:38PM +0100, Per Olofsson wrote:
> > Elimar Riesebieter:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Elimar Riesebieter <[EMAIL PROTECTED]>
> 
> > > * Package name: mutt-ng
> 
> > Also note that Norbert Tretkowski has already created a mutt-ng
> > package, although he doesn't intend to upload it (yet). It is
> > available at .
> 
> Actually, the site with the test deb files mentions that Norbert
> has passed the baton to Elimar.
> 
> On the other hand, I'm having a problem with the package, it
> doesn't include muttng_dotlock, and seems to think my mailspool
> (mbox in /var/mail) is read-only. (vanilla) Mutt can use it
> fine.

On the machine the i386-build was done, /var/mail was world-readable
(don't flame me), so configure seemed to not build dotlock then.

Will be fixed next upload (maybe tonight).

Elimar

-- 
  Numeric stability is probably not all that 
  important when you're guessing;-)


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

Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d

[Josselin Mouette]

Le jeudi 24 mars 2005 Ã 14:27 -0300, Henrique de Moraes Holschuh a
Ãcrit :
> On Thu, 24 Mar 2005, Josselin Mouette wrote:
> > > I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
> > > glib2.0? Or unlink libsdl from using libglib?
> > 
> > I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
> 
> Miracle? no.  Technical, sound, and sane? Yes: Version the symbols properly
> on all libraries that are going to be used by other libraries.  

Yes, adding symbol versioning to Glib is definitely an option. It also
means rebuilding all of the incriminated libraries.

> Gnome and
> Kde should have been doing this since day one, since they are the very
> definition of library hell.

I don't know for KDE, but the core GNOME libraries now retain full
binary compatibility in all versions.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Idea: about package installation under chroot.

[Josselin Mouette]

Le jeudi 24 mars 2005 Ã 14:54 -0300, Jorge L. deLyra a Ãcrit :
> Now, all this can be avoided very simply by a line in the init.d/ script
> for the daemon, checking that /proc is mounted. Since it will be mounted
> on normal systems but typically not when using a chroot shell, it serves
> as a flag to enable the daemon restarting procedure.
> 
> I am using successfully the following line to fix the situation in the
> case of the troublesome rwhod package, near the top of the file:
> 
> test -e /proc/mounts || exit 0

I definitely like that idea. I don't know whether we have ports
without /proc, but such a check for a chroot would be really nice
anyway.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Idea: about package installation under chroot.

[Florian Ernst]

Hello!

On Thu, Mar 24, 2005 at 02:54:40PM -0300, Jorge L. deLyra wrote:
> Here is the story: Debian packages including daemons may be a problem for
> people installing them via chroot, due to the fact that the packages will
> typically try to stop and restart the daemons. In fact, this can interact
> destructively with the system of the server, accidentally killing this or
> that process. It may also cause the Debian package tools to crash.
> [...]
> Is there some other, better solution to this problem?

echo -e '#!/bin/sh\n\nexit 101' > /chroot/usr/sbin/policy-rc.d \
&& chmod a+x /chroot/usr/sbin/policy-rc.d

as mentioned by Steve Langasek in
.

HTH,
Flo


signature.asc
Description: Digital signature

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Adam Majer]

Andreas Barth wrote:

> Actually, I believe the Debian project as whole _wants_ to getting
>
>software released. That was at least the decision in all GRs where
>people didn't hide the intents ("editorial changes").
>  
>

Indeed. These types of changes are akin to changing a country's
constitution and calling these "editorial changes" bill. But then again
we can always change it back and call the change "editorial changes" as
well.

- Adam



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

OPORTUNIDADE

[Luis Jordão]

O futuro é você quem 
faz...Existem boas escolhas a serem feitas...
E as conseqüências de suas escolhas é 
que determinarão os resultados.
Você está 
satisfeito?
Como estão suas 
perspectivas?
O que você está fazendo para mudar seu 
futuro?Comece 
já seu negócio em casa...
Quais são seus sonhos, objetivos e 
ambições?

Estamos em 
expansão, procurando pessoas de boa visão de negócio e empreendedoras, que 
queiram algo a mais e gostariam de ter um estilo com qualidade de 
vida.
Somos uma 
multinacional americana com 25 anos no mercado e líder em seu segmento. 
Recentemente, dois grandes bancos de investimentos, fizeram um aporte de US$ 
700 milhões em nosso negócio, e estamos, portanto, em fase de grande 
expansão.Procuramos profissionais que sejam empreendedores e 
independentes e que queiram trabalhar, em período parcial ou integral, com 
treinamento, gerenciamento e formação de pessoas, ou com alguma experiência na 
área comercial.Gostaríamos de salientar que não somos uma empresa 
de recolocação.Enfatizamos, também, que não se trata de 
uma vaga de emprego tradicional (com carteira assinada), e sim de um 
trabalho autônomo com o suporte de três grandes empresas. O objetivo do nosso 
contato é convidá-lo para uma reunião de negócios onde serão apresentados a 
empresa, os nossos parceiros, o plano de carreira, as formas de remuneração e as 
atividades que você desempenharia. Caso você visualize a diferença do nosso 
sistema de trabalho daremos continuidade ao processo. 
Caso tenha interesse, retorne com o titulo 
"CONFIRMAÇÃO”  dizendo cidade com telefone para 
contato que agendaremos uma apresentação. 
Aguardamos 
seu retorno.Atenciosamente,Luís Jordão 
“Viva Bem... Sinta se 
Bem... Se você mudar a sua maneira de pensar, talvez possa mudar a sua 
vida.”

Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client

[Henning Makholm]

Scripsit David Moreno Garza <[EMAIL PROTECTED]>

> Revolution is a little Ruby binding to the excellent Evolution email
> client.

Is it so little that it would be better to include it with the
evolution package?

-- 
Henning Makholm "Al lykken er i ét ord: Overvægtig!"

Re: Let's stop feeding the NVidia cuckoo

[Henning Makholm]

Scripsit Paul Hedderly <[EMAIL PROTECTED]>

> What we have is source code (yes code that can be compiled) which is
> unencumbered, we can modify,compile, distribute etc... whether it is
> _harder_ to modify or not because of choices the _owner/author_ has
> made or not... is nothing to do with freedom.

What you are showing here is that "code that can be compiled" is not a
working defintion of "source code".

-- 
Henning Makholm "Logic is a system for talking about
   propositions that can be true or false, or at least enjoy
   properties that are generalized versions of truth and falsehood."


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

Re: NEW handling: About rejects, and kernels

[Henning Makholm]

Scripsit Hamish Moffatt <[EMAIL PROTECTED]>

> Please don't rehash old arguments. Nobody has argued that we should put
> non-free packages into main, but we don't agree on what is free and what
> isn't for all types of packages.

Do you have any arguments for this that do *not* basically reason
backwards from "we want this stuff to be in main, freedoms or not"?

-- 
Henning Makholm "Occam was a medieval old fart. The simplest
 explanation that fits the facts is always, God did it."


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

Re: OPORTUNIDADE

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luis JordÃo escreveu:
:: *O futuro à vocà quem faz...
[...]
Looks like a pt_BR SPAM. :o)
- --
//
// Felipe Augusto van de Wiel (faw) <[EMAIL PROTECTED]>
// GUD-PR / DUG-PR || http://www.debian-pr.org
// GUD-BR / DUG-BR || http://www.debian-br.org
// Debian Project  || http://www.debian.org/
//
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFCQyqqCjAO0JDlykYRAn9dAJ4k1ZZkdIB0IG1hgiNFirYLpCKBpQCgieds
mRBCt1KIniKGdsekmQwxy0A=
=LWXd
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: discrepancies between uploaded and source-built .deb

[Thaddeus H. Black]

Jeroen van Wolffelaar:

> [Karl Chen:]
>
> > I didn't know about debdiff - that would have saved me from
> > basically re-implementing it.
> 
> Common problem unfortunately in the open source/Debian world... not that
> $what_you_want doesn't exist, but that you just don't know it exists nor
> where to find it :(.

The Debian archive is admirably vast.  Out of this free software sea,
you can usually fish the one sarge package you need with debram.  Debram
sorts sarge's 14,000+ packages into broad classes, then divides and
redivides them into 470 finer, more specific branches.

Debram is part of the Debtags project.  Debtags development info here:

  http://debtags.alioth.debian.org/


pgpy31ZYmlSF3.pgp
Description: PGP signature

Re: Idea: about package installation under chroot.

[Henning Makholm]

Scripsit "Jorge L. deLyra" <[EMAIL PROTECTED]>

> Although most packages do in fact survive this process, in the sense that
> the installation completes despite some errors when stopping and starting
> daemons, some do cause the package tools to exit in error, leaving behind
> a broken package. One example that is particularly troublesome is rwhod.
...
> Is there some other, better solution to this problem?

Write a policy-rc.d script for the chroot that denies starting either
the particular demon or all demons in general.

zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz 

-- 
Henning Makholm  "What has it got in its pocketses?"


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

Re: Getting openswan 2.2.0 back into sarge

[Adam M.]

Rene Mayrhofer wrote:

>Hi all, 
>
>[Please CC me in replies, I am currently not subscribed to this list.]
>
>As some have already noticed, openswan has been removed from testing a while 
>ago, most probably because of bug #291274, which did not apply to package 
>version 2.2.0-4 (the one that has been removed from testing). As 2.3.0 
>  
>

You should have tagged the RC bug Sid.

>upstream is currently not production quality (this is my personal opinion, 
>since it basically triggers a DoS on 2.2.0 installations, cf. #292132), I did 
>  
>

Doesn't this mean that 2.2.0 is NOT release quality? It is a security
problem if you can trigger a DoS on a package.

>not work on getting it into testing. Of course, I have to admit that I have 
>been lazy in not filing a RC bug report to prevent it from entering testing 
>and fixing this bug. However, it looked like 2.3.1 might get released soon at 
>that time, so I had decided to wait for it and push it into testing as soon 
>as the new upstream is there. At the moment, 2.3.1 is nowhere to be seen and 
>I would really like to have a working (and not DoS-triggering) openswan in 
>testing. My current intention would be to get 2.2.0-4 back into testing, 
>which worked well in all of my own tests (I am still using that particular 
>version on many production boxes) and does not seem to be broken for other 
>users. What is the general opinion on that?
>  
>
The first step is to remove the current version from testing if it is
not production quality.
The second step is to locate the DoS problem in 2.2.0
The final step is to upload 1:2.2.0 or similar to unstable and wait for
it to get to testing.

- Adam



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

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> Write a policy-rc.d script for the chroot that denies starting either
> the particular demon or all demons in general.
>
> zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz

I was not aware of this structure, but it seems to relate to controlling
the start of damons during boot or changes in runlevel. I do not see how
this will prevent a package that has a

/etc/init.d/ start

in its postinstall script to start that daemon. I was not talking about
booting a system, but about using a chroot shell to install packages in
the filesystem structure of a remotely-booted machine.

In this situation one does not want to prevent the machine from starting
daemons when it boots, just to prevent package installations or upgrades
from stoping or starting daemons, when they are done in the disk server,
by means of a chroot shell.
Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]



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

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

[Florian Weimer]

* Elimar Riesebieter:

>  Differences between mutt and mutt-ng:

You should make clear that this list of features compares the mutt and
mutt-ng packages (I hope it does).  Debian's mutt package contains
some of the mutt-ng patches.


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

Re: Idea: about package installation under chroot.

[Daniel Baumann]

Josselin Mouette wrote:
I don't know whether we have ports without /proc,
the Hurd has no /proc.
Regards,
Daniel
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Idea: about package installation under chroot.

[Don Armstrong]

On Thu, 24 Mar 2005, Jorge L. deLyra wrote:
> > Write a policy-rc.d script for the chroot that denies starting either
> > the particular demon or all demons in general.
> >
> > zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz
> 
> I was not aware of this structure, but it seems to relate to
> controlling the start of damons during boot or changes in
> runlevel. I do not see how this will prevent a package that has a
> 
> /etc/init.d/ start
> 
> in its postinstall script to start that daemon.

It won't, but thankfully there are fewer and fewer packages that don't
follow the recommendation of Policy 9.3.3.2.[1]

If you find such a package, please file a wishlist bug against it
requesting that the follow the recommendation of Policy not to call
the init scripts directly.


Don Armstrong

1: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
-- 
A people living under the perpetual menace of war and invasion is very
easy to govern. It demands no social reforms. It does not haggle over
expenditures on armaments and military equipment. It pays without
discussion, it ruins itself, and that is an excellent thing for the
syndicates of financiers and manufacturers for whom patriotic terrors
are an abundant source of gain.
 -- Anatole France

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client

[David Moreno Garza]

On Thu, 2005-03-24 at 17:31 +, Henning Makholm wrote:
> Scripsit David Moreno Garza <[EMAIL PROTECTED]>
> 
> > Revolution is a little Ruby binding to the excellent Evolution email
> > client.
> 
> Is it so little that it would be better to include it with the
> evolution package?

Not quite sure since:

a) evolution, IMHO, doesn't need to depend on ruby.
b) It is a 3rd-party software, not included officially by Novell.
c) It is a ruby module itself, just as other several hundreds.

But if evolution's maintainer thinks it could be a good idea (I don't),
we can implement it in the near future, yes.

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 The only way to make your PC go faster is to throw it out a window. 
 GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D


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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Hamish Moffatt]

On Thu, Mar 24, 2005 at 10:28:36AM -0800, Thomas Bushnell BSG wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> 
> > Please don't rehash old arguments. Nobody has argued that we should put
> > non-free packages into main, but we don't agree on what is free and what
> > isn't for all types of packages.
> 
> Actually, nobody from the "more lenient" side has given a description
> of what they think the right bounds for freeness are for
> documentation, and why those bounds should be different than for
> programs.

That may be true for documentation but certainly not for firmware, which
has been discussed to death. (Not with a satisfactory outcome, imho.)


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Idea: about package installation under chroot.

[Hamish Moffatt]

On Thu, Mar 24, 2005 at 02:54:40PM -0300, Jorge L. deLyra wrote:
> Installation via chroot can be very useful for embedded systems, and also
> for diskless machines that boot remotely from a server and mount the root
> via NFS. If a package is being installed via chroot running in the server
> it does not really make any sense to try to stop or start daemons.

[...]
> Now, all this can be avoided very simply by a line in the init.d/ script
> for the daemon, checking that /proc is mounted. Since it will be mounted
> on normal systems but typically not when using a chroot shell, it serves
> as a flag to enable the daemon restarting procedure.

FWIW, the Debian-amd64 HOWTO suggests mounting /proc in your i386
chroot too. (Though I don't know what the benefits are.)

See:
https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274246

I think this is a good problem to solve though.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Idea: about package installation under chroot.

[Thomas Bushnell BSG]

"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:

> Now, all this can be avoided very simply by a line in the init.d/ script
> for the daemon, checking that /proc is mounted. Since it will be mounted
> on normal systems but typically not when using a chroot shell, it serves
> as a flag to enable the daemon restarting procedure.

There is nothing wrong with mounting /proc in a chroot; you should not
assume that chroots all lack /proc.


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

Re: Idea: about package installation under chroot.

[Alban Browaeys]

> I was not aware of this structure, but it seems to relate to controlling
> the start of damons during boot or changes in runlevel. I do not see how
> this will prevent a package that has a
> 
> /etc/init.d/ start
Well if they do they won't work on file-rc system , so are already broken ...

Alban


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

Re: [RFC] OpenLDAP automatic upgrade

[Torsten Landschoff]

Hi Quanah, 

On Mon, Mar 21, 2005 at 05:58:01PM -0800, Quanah Gibson-Mount wrote:
 
> You can find the patch for adding "-q" to slapadd on OpenLDAP 2.2 here:
> 
> 

Great, thanks! Applied it to the subversion repository.

> I've been reading back over my notes on the problems OpenLDAP has with BDB
> 4.3, and I believe that this patch will resolve those issues as well (as
> long as it is used to load a DB, rather than without the "-q" flag).
> 
> The main issue is that the way BDB 4.3 creates transaction logs in the
> quickload scenario is to use
> 
> setflags DB_LOG_INMEMORY

Okay. Anyway, I guess I'll revert to bdb 4.2 if you made bad experiences
with 4.3. As long as OpenLDAP does not need any features from 4.3 why
would we want to use it anyway?

> I would note that it would likely be good for Debian to still include a
> DB_CONFIG file in the database directory it creates with its OpenLDAP
> distribution, as the default settings from Sleepycat are entirely too
> small.
> 
> Here are some examples.  All examples use:
> 
> 10k entry LDIF file
> 23 attributes indexed
> BDB 4.2.52
> "database bdb" as the slapd.conf database
> 
> 1) DB_CONFIG file with a 384MB cache, and normal slapadd options.
> 
>ldap-linux0:/db/DBs# time slapadd -l 10k.ldif
>30.760u 1.800s 0:36.89 88.2%0+0k 0+0io 13351pf+0w

Point taken :) I'll submit this as a bug to not forget about it. I think
about using at least 1MB for the cache (stop laughing :-) and at most
10% of the main memory of the system. After all there are still people
running slapd on systems with 16MB of memory (our students' hostel
server is still running such a system...)

Greetings

Torsten


signature.asc
Description: Digital signature

Bug#301260: ITP: achims-guestbook -- php driven guestbook

[Tim Peeler]

Package: wnpp
Severity: wishlist
Owner: Tim Peeler <[EMAIL PROTECTED]>


* Package name: achims-guestbook
  Version : 2.52 
  Upstream Author : Achim Winkler <[EMAIL PROTECTED]>
* URL : http://www.lkcc.org:8500/
* License : GPL
  Description : php driven guestbook

 Achims Guestbook is a php driven guestbook that relies on text files for
 storing entries.  It has support for ip banning, bad word filters,
 smileys, and an easy to use administrative interface.


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> There is nothing wrong with mounting /proc in a chroot; you should not
> assume that chroots all lack /proc.

Yes, I know, and I'm not.  But it would be nice if one could prevent the
packages from starting the daemons by simply choosing not to mount /proc
in the chroot.
Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]



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

Re: Idea: about package installation under chroot.

[Bill Allombert]

On Thu, Mar 24, 2005 at 07:42:01PM +0100, Josselin Mouette wrote:
> Le jeudi 24 mars 2005 ?? 14:54 -0300, Jorge L. deLyra a ??crit :
> > Now, all this can be avoided very simply by a line in the init.d/ script
> > for the daemon, checking that /proc is mounted. Since it will be mounted
> > on normal systems but typically not when using a chroot shell, it serves
> > as a flag to enable the daemon restarting procedure.
> > 
> > I am using successfully the following line to fix the situation in the
> > case of the troublesome rwhod package, near the top of the file:
> > 
> > test -e /proc/mounts || exit 0
> 
> I definitely like that idea. I don't know whether we have ports
> without /proc, but such a check for a chroot would be really nice
> anyway.

Probably I don't understand the assumption /proc is not mounted in
chroot.

All my chroots have /proc. There are just too many programs that depends 
of /proc. I even witnessed a FTBFS of a C++ program that depended of the
chroot not having /proc mounted.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Idea: about package installation under chroot.

[Thomas Bushnell BSG]

"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:

> > There is nothing wrong with mounting /proc in a chroot; you should not
> > assume that chroots all lack /proc.
> 
> Yes, I know, and I'm not.  But it would be nice if one could prevent the
> packages from starting the daemons by simply choosing not to mount /proc
> in the chroot.

But you might need /proc.  If you are going to tell people "to prevent
packages from starting daemons, do this in the filesystem", then why
not just have an /etc/startdaemons file?


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

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> > I was not aware of this structure, but it seems to relate to controlling
> > the start of damons during boot or changes in runlevel. I do not see how
> > this will prevent a package that has a
> >
> > /etc/init.d/ start
> Well if they do they won't work on file-rc system , so are already broken ...

Then there are many such broken packages. I just counted about 40 both in
the sarge system closest at hand and in a woody server. The list includes
many important packages, see lists below.  Looks like this policy has not
been followed very much...
Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]


woody: acct adjtimex anacron and apache at autofs bind console-common cron
dqs gom gpm ircd isapnptools junkbuster kbd libc6 linuxlogo lprng makedev
mrouted netkit-inetd nfs-common nfs-kernel-server nis ntop ntp-simple
ntpdate portmap ppp procps quota rwhod setserial spamassassin ssh sudo
sysstat upsd xfs xpilot-server xtell

sarge: anacron and apache apache-common at autofs binfmt-support
console-common console-tools cron dhcp3-server exim4-base
exim4-daemon-light gom hpoj isapnptools libdevmapper1 lprng makedev
nbd-client nbd-server netkit-inetd nfs-common nfs-kernel-server nis
ntp-server ntpdate nut portmap procps queue quota rsync rwhod setserial
ssh sudo wu-ftpd xprt-common xtell



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

Re: Let's stop feeding the NVidia cuckoo

[Stephen Gran]

This one time, at band camp, Henning Makholm said:
> Scripsit Paul Hedderly <[EMAIL PROTECTED]>
> 
> > What we have is source code (yes code that can be compiled) which is
> > unencumbered, we can modify,compile, distribute etc... whether it is
> > _harder_ to modify or not because of choices the _owner/author_ has
> > made or not... is nothing to do with freedom.
> 
> What you are showing here is that "code that can be compiled" is not a
> working defintion of "source code".

However, code that "we can modify,compile, distribute etc" and is
"unencumbered" is.  Please, folks, "it's ugly" != "it's non-free".
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpTtkazASorU.pgp
Description: PGP signature

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Marco d'Itri]

On Mar 24, Hamish Moffatt <[EMAIL PROTECTED]> wrote:

> That may be true for documentation but certainly not for firmware, which
> has been discussed to death. (Not with a satisfactory outcome, imho.)
And one of the reasons for which licensing for documentation has not
been discussed is that most people were not aware of the scope of the
"editorial" changes, so there was no reason to discuss anything.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> > Is there some other, better solution to this problem?
>
> echo -e '#!/bin/sh\n\nexit 101' > /chroot/usr/sbin/policy-rc.d \
> && chmod a+x /chroot/usr/sbin/policy-rc.d
>
> as mentioned by Steve Langasek in
> .

OK, I got to this point: if all packages used invoke-rc.d then I could
solve my problem with installing packages under chroot by installing a
policy-rc.d script that returned 101 if the runlevel is "unknown". All
I have to do is to mask /var/run, which I already do. Two questions:

1) The command "runlevel" returns "unknown" and exits in error, will this
   error status do something bad to invoke-rc.d?

2) What does invoke-rc.d do if the runlevel is "unknown"? Maybe I would
   not have to do anything after all, if the policy was followed.

Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]



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

Re: Idea: about package installation under chroot.

[Don Armstrong]

On Thu, 24 Mar 2005, Jorge L. deLyra wrote:
> nfs-kernel-server 

This uses invoke-rc.d: 

invoke-rc.d nfs-kernel-server $act

> ntp-server

invoke-rc.d ntp-server start || exit 0

> ntpdate 

as does this: invoke-rc.d ntpdate start || exit 0

Pray tell, how was this list generated? The three examples that I
picked at random all use invoke-rc.d. [Two of which because they use
debhelper to do the invoking.]


Don Armstrong

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on
a California license plate on a VW Beetle: 'FEATURE'..."
 -- Joshua D. Wachs - Natural Intelligence, Inc.

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: Idea: about package installation under chroot.

[Steve Langasek]

On Thu, Mar 24, 2005 at 08:58:22PM -0300, Jorge L. deLyra wrote:
> > > I was not aware of this structure, but it seems to relate to controlling
> > > the start of damons during boot or changes in runlevel. I do not see how
> > > this will prevent a package that has a
> > >
> > > /etc/init.d/ start
> > Well if they do they won't work on file-rc system , so are already broken 
> > ...

> Then there are many such broken packages. I just counted about 40 both in
> the sarge system closest at hand and in a woody server. The list includes
> many important packages, see lists below.  Looks like this policy has not
> been followed very much...

> sarge: anacron and apache apache-common at autofs binfmt-support
> console-common console-tools cron dhcp3-server exim4-base
> exim4-daemon-light gom hpoj isapnptools libdevmapper1 lprng makedev
> nbd-client nbd-server netkit-inetd nfs-common nfs-kernel-server nis
> ntp-server ntpdate nut portmap procps queue quota rsync rwhod setserial
> ssh sudo wu-ftpd xprt-common xtell

At least some of these packages call /etc/init.d/ start *only* if
invoke-rc.d cannot be found.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> But you might need /proc.

Well, I am starting to see that this might not be a good way to solve the
problem but, still, if you need it, just mount it, and be aware that some
daemons may come up and down on the server if you install or upgrade some
package in these circumstances. If you do not need it, don't mount it and
then do not worry about daemons...

> If you are going to tell people "to prevent packages from starting
> daemons, do this in the filesystem", then why not just have an
> /etc/startdaemons file?

Well, I suppose you could create this file briefly while doing the install
or upgrade, and then delete it. You do not want it there permanently since
the remote-boot machine is not to be prevented from starting daemons. Will
using this file really work in this way?
Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]



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

Re: Idea: about package installation under chroot.

[Thomas Bushnell BSG]

"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:

> > But you might need /proc.
> 
> Well, I am starting to see that this might not be a good way to solve the
> problem but, still, if you need it, just mount it, and be aware that some
> daemons may come up and down on the server if you install or upgrade some
> package in these circumstances. If you do not need it, don't mount it and
> then do not worry about daemons...
> 
> > If you are going to tell people "to prevent packages from starting
> > daemons, do this in the filesystem", then why not just have an
> > /etc/startdaemons file?
> 
> Well, I suppose you could create this file briefly while doing the install
> or upgrade, and then delete it. You do not want it there permanently since
> the remote-boot machine is not to be prevented from starting daemons. Will
> using this file really work in this way?

I think you miss my point.

Rather than keying "restart daemons" to /proc (who would ever guess
that?!), I'm saying create something *new*, that means "this is a
chroot, don't restart demons".

Thomas


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

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> Pray tell, how was this list generated? The three examples that I picked
> at random all use invoke-rc.d. [Two of which because they use debhelper
> to do the invoking.]

Oh, I see. Looks like I did a poor job here. I just searched for instances
of /etc/init.d/something being executed. So, I take it all back... |:-)

Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]



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

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> At least some of these packages call /etc/init.d/ start *only* if
> invoke-rc.d cannot be found.

Ah! This is another way how I miscounted them, since I just seached for
instances of /etc/init.d/ being executed...
Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]









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

Re: Idea: about package installation under chroot.

[Jorge L. deLyra]

> I think you miss my point.
>
> Rather than keying "restart daemons" to /proc (who would ever guess
> that?!), I'm saying create something *new*, that means "this is a
> chroot, don't restart demons".

OK, I read you. Your message gave me the impression that something like it
was already in place.  That meaning doesn't have to be "this is a chroot",
but just "don't start daemons", for whatever reasons there may be for that
in any particular case. It would be nice if we could touch a flag file and
prevent packages from starting daemons...
Cheers,


Jorge L. deLyra,  Associate Professor of Physics
The University of Sao Paulo,  IFUSP-DFMA
   For more information: finger [EMAIL PROTECTED]



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

Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client

[Matthias Urlichs]

Hi, Adam M. wrote:

> Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to
> depend on evolution.

What happens if/when ruby is updated in a non-binary-compatible way?
Or if/when somebody decides to remove ruby since, after all, nothing
depends on it?

If that happens, you have a broken libevolution-ruby on your system.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]



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

Re: Idea: about package installation under chroot.

[Henning Makholm]

Scripsit "Jorge L. deLyra" <[EMAIL PROTECTED]>

>> zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz

> I was not aware of this structure, but it seems to relate to controlling
> the start of damons during boot or changes in runlevel. I do not see how
> this will prevent a package that has a

> /etc/init.d/ start

> in its postinstall script to start that daemon.

As far as I'm aware it's a bug if a package has that in its postinst
rather than

   invoke-rc.d  start

even though it is not yet mandatory policy. It is, however, "strongly
recommended" (§9.3.3.2).

-- 
Henning Makholm  "Y'know, I don't want to seem like one of those
 hackneyed Jews that you see in heartwarming movies.
 But at times like this, all I can say is 'Oy, gevalt!'"

Re: Idea: about package installation under chroot.

[Thomas Bushnell BSG]

"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:

> OK, I read you. Your message gave me the impression that something like it
> was already in place.  That meaning doesn't have to be "this is a chroot",
> but just "don't start daemons", for whatever reasons there may be for that
> in any particular case. It would be nice if we could touch a flag file and
> prevent packages from starting daemons...

Yes, that's basically what I'm suggesting.  I'm glad you located this
bug; it's a problem will worth fixing.


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

Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client

[Adeodato Simó]

* Matthias Urlichs [Fri, 25 Mar 2005 01:46:45 +0100]:
> Hi, Adam M. wrote:

> > Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to
> > depend on evolution.

> What happens if/when ruby is updated in a non-binary-compatible way?
> Or if/when somebody decides to remove ruby since, after all, nothing
> depends on it?

> If that happens, you have a broken libevolution-ruby on your system.

  Also, you can't make updates to the bindings without a full evolution
  upload, which has to get built in all arches, heavy compilation, etc.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Mecano - El club de los humildes
 
From the moment I picked your book up until I put it down I was
convulsed with laughter. Some day I intend reading it.
-- Groucho Marx

Re: Idea: about package installation under chroot.

[Adeodato Simó]

* Jorge L. deLyra [Thu, 24 Mar 2005 14:54:40 -0300]:

> test -e /proc/mounts || exit 0

  Others have already pointed out that a policy-rc.d script is the way
  to do what you want.

  Still, I thought I'd share a way of testing if you're inside a chroot
  even if /proc is mounted. IIRC, it was LaMont Jones who mentioned this
  some weeks ago on IRC:

# test -r /proc/1/root || echo "Inside a chroot"

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Mecano - Aire
 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
-- George Bernard Shaw


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

Re: Idea: about package installation under chroot.

[Joey Hess]

Florian Ernst wrote:
> echo -e '#!/bin/sh\n\nexit 101' > /chroot/usr/sbin/policy-rc.d \
> && chmod a+x /chroot/usr/sbin/policy-rc.d
> 
> as mentioned by Steve Langasek in
> .

Would someone like to package this?

(No, I'm not really kidding.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client

[Adam M.]

David Moreno Garza wrote:

>On Thu, 2005-03-24 at 17:31 +, Henning Makholm wrote:
>  
>
>>Scripsit David Moreno Garza <[EMAIL PROTECTED]>
>>
>>
>>
>>>Revolution is a little Ruby binding to the excellent Evolution email
>>>client.
>>>  
>>>
>>Is it so little that it would be better to include it with the
>>evolution package?
>>
>>
>
>Not quite sure since:
>
>a) evolution, IMHO, doesn't need to depend on ruby.
>b) It is a 3rd-party software, not included officially by Novell.
>c) It is a ruby module itself, just as other several hundreds.
>
>But if evolution's maintainer thinks it could be a good idea (I don't),
>we can implement it in the near future, yes.
>  
>

With regards to a), I don't think you need to depend on ruby at all. The
reason is that the ruby bindings are only available for programs running
in a ruby interpreter (AFAIK). Thus, if you want to *use* the ruby
bindings, you then install ruby. If you do not install ruby, you do not
need or use the ruby bindings.

For example, if you package a libfoo package that is a C library, and
libfoo-dev contains the static part of the C library, then there is no
need to have libfoo-dev depend on the C compiler. Anyone that *uses* the
libfoo-dev library will need to install a C compiler regardless.

Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to
depend on evolution.

- Adam

PS. It may need build depend on ruby, rake, etc.. , but that is different.


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

Re: Vancouver meeting - clarifications

[Noah Meyerhans]

On Wed, Mar 23, 2005 at 01:07:07PM +0100, Wouter Verhelst wrote:
> On Wed, Mar 23, 2005 at 01:46:17AM +0100, Pierre THIERRY wrote:
> > - Debian: 11 ports, 9157 packages (sarge) [17593 in sid]
> > - NetBSD: 55 ports, 5300 packages
> 
> It should be noted that the definition of 'port' isn't necessarily the
> same if you compare NetBSD against Debian; for instance, NetBSD/mac68k
> and NetBSD/amiga count as two ports, whereas in Debian, they count as
> one (albeit the 'subarchitecture' is different)

Additionally, they do not provide binaries for all their packages.  In
fact, the pkgsrc collection does not even follow the normal release
cycle.  When NetBSD is ready to release, they simply take a snapshot of
pkgsrc.  It's not even a requirement that the packages in pkgsrc are
even buildable on all supported platforms.

NetBSD is able to support as many platforms as they do because they have
very different requirements for "support" than we do.  It's not a good
idea to compare us to them.

noah



pgpsqrooX3nPQ.pgp
Description: PGP signature

Re: Idea: about package installation under chroot.

[Brian May]

> "Jorge" == Jorge L deLyra <[EMAIL PROTECTED]> writes:

Jorge> /etc/init.d/ start

Jorge> in its postinstall script to start that daemon. I was not
Jorge> talking about booting a system, but about using a chroot
Jorge> shell to install packages in the filesystem structure of a
Jorge> remotely-booted machine.

If a package directly uses /etc/init.d/ in its scripts, file a
bug report.

It should use invoke-rc.d instead. man invoke-rc.d

It should work for chroots, and does work for pbuilder.
-- 
Brian May <[EMAIL PROTECTED]>


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

update-menus runs in the background?

[Justin Pryzby]

It seems that /usr/bin/update-menus now runs in the background.  I ran
sudo apt-et install glade, and after it finished, I ran ps -ef |tail
-5, and the last commands running were update-menus.real, and
install-menu.

Is it supposed to be a background job, and, if so, why?

Thanks, please Cc: me,
Justin


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

7 Hours of Photoshop Video Training

[Photoshop Training]

7 Hours of Photoshop Video Training - $29.95

Download a DEMO Here

http://photoshop-teacher.com/DEMO.htm


Adobe Photoshop CS 

Adobe Photoshop CS is a professional tool for editing digital images. With
Photoshop Tutorials on Video, you'll get to peek over the shoulder of a
professional graphic designer and learn at your own pace. With access to
more than 7 hours of Photoshop instruction, you'll discover the secrets of
editing digital photos like a pro, how-to create cool objects for web
sites,
and learn a myriad of other useful tricks - all in one comprehensive
step-by-step course. 


7 hours of Video Training

All Photoshop tutorials are presented in crystal-clear 1024x768 video
quality, and are available to you as a downloadable file. No streaming, no
activation, no copyright protection - simply download a file and watch it
as
many times as you like. A picture may be worth a thousand words, but a
video
explains things far more clearly and concisely. Try our demo and discover
how easy working in Adobe Photoshop can be. 


Editing Digital Photos

Digital photography is one of the fastest-growing tech markets, but
learning how image editing software works hasn't been easy. With this set
of
clearly-worded Photoshop tutorials, you can enter the digital photography
world at your own pace and discover ways to improve your imagery with Adobe
Photoshop. We'll show you how-to remove distracting objects, assemble
panoramas, restore damaged photos, remove red-eye, adjust color, and
address
a myriad of other digital photo issues and projects. 


Step By Step Course

"I wish I had known about this video before. I've bought four books, but
this set of Photoshop tutorials gave me much more." "Books are great as a
quick reference, but if you really want to learn how-to edit digital
photos,
Photoshop Tutorials on Video is the way to go. It's so much easier to
follow! Thanks for your great service!" - Don Bryant, Woodland Hills, CA 

No future mailings

http://photoshop-teacher.com/r.htm










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

Re: A new arch support proposal, hopefully consensual (?)

[foo_bar_baz_boo-deb]

Believe what you like about what I said. I could not care less.

What was apparently blatantly obvious to you about the nature of the
post was not to me, and I wanted to step forward to be sure that Sven's
points (which are near to my heart as a SPARC user) were not discarded
over a triviality.

Is it not ironic that I, a "nameless top-poster" (as you said), was a
lot more polite about expressing my opinion than you were about
expressing yours? After all, I voiced my objections specifically
instead of categorizing the parent post as "stupid".

Well, I think the dead horse has been beaten, so let's make amends and
move on to another more pressing issue.

--- Glenn Maynard <[EMAIL PROTECTED]> wrote:

> On Mon, Mar 21, 2005 at 12:26:13AM -0800,
> [EMAIL PROTECTED] wrote:
> This is stupid.  The very phrasing was lightly humerous, not an
> attack.



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

Re: A new arch support proposal, hopefully consensual (?)

[Glenn Maynard]

On Thu, Mar 24, 2005 at 06:56:31PM -0800, [EMAIL PROTECTED] wrote:
> Believe what you like about what I said. I could not care less.
> 
> What was apparently blatantly obvious to you about the nature of the
> post was not to me, and I wanted to step forward to be sure that Sven's
> points (which are near to my heart as a SPARC user) were not discarded
> over a triviality.
> 
> Is it not ironic that I, a "nameless top-poster" (as you said), was a
> lot more polite about expressing my opinion than you were about
> expressing yours? After all, I voiced my objections specifically
> instead of categorizing the parent post as "stupid".

Not really.  I considered accusing someone of "perpetrating a straw man
attack" who used the phrase "you ignoramus, you" silly enough that most
people wouldn't need it explained.  *shrug*

You're a nameless top-poster; this is objective, not a flame.  Your From:
header has no name.  If you scan other posts, you'll find it difficult to
find anyone else who isn't posting with something at least resembling a
real name.  (It's hard to take an anonymous entity named "foo bar baz boo
deb" seriously.)  You quote upside-down; I'm sure you know what that means
already and how bad form it is on most technical lists.  Oh, and you break
threads every time you reply, which is also extraordinarily bad practice:
your In-Reply-To header is bogus and there's no References: header, which
makes threads much harder to follow, and will probably get you ignored by
many people since your posts won't appear in the normal flow of the thread.

(I actually do point them out in the hope that you'll fix them.  If you
don't care enough about the quality of your posts to do so, it's not my
loss.  :)

-- 
Glenn Maynard


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

Re: HOWTO Help (was: Debian DPL Debate Comments)

[Rudy Godoy]

El día 23/03/2005 a 05:32 Alexander Schmehl escribio ...

> * Frans Pop <[EMAIL PROTECTED]> [050322 22:25]:
> 
> > > AFAIK we don't have a good "What you can do to help us" documentation
> > > (please correct me, if I am wrong).
> > How about http://www.debian.org/devel/join/ ?
> > Which is linked from the main debian.org page (bottom left: "Help Debian")
> 
> I think it is quite short and is missing some quite easy tasks that can
> be done by nearly everyone.
>

It's a very good start...
 
> I did the mentioned talk and am about to write the document, because I
> got asked a couple of times what people can do to help us, so I think
> there is need for a more detailed document about that.
> 

Sure, there's always people asking for such things and such a
documment would be really helpful for them and the end for Debian.
I've heard damog did similar thing recently. I've tried to do a
start working on similar documment after my talk at DC4, not made
real progress though, but I'd be more than likely to work on this once
I manage to "get things on the road" again. Probably putting a draft
of what you've summarized on debian-doc can be a good starting point.

regards,
-Rudy

-- 
Rudy Godoy | 0x3433BD21 | http://stone-head.org   ,''`.
http://www.apesol.org  -  http://www.debian.org  : :' :
GPG FP: 0D12 8537 607E 2DF5 4EFB  35A7 550F 1A00 3433 BD21   `. `'
   `-


signature.asc
Description: Digital signature