Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Nathanael Nerode]

On Mon, Nov 17, 2003 at 06:33:52PM -0500, Nathanael Nerode wrote:

> I'm curious, for instance, as to why emacs20 hasn't managed to be removed
> yet.

Matt Zimmerman wrote:
>Perhaps the maintainer hasn't requested its removal?  I don't see a bug
>report open against ftp.debian.org.

I seem to remember him requesting it.  Further, you'll see on the RC bugs list 
that it's listed as REMOVE (and has been for a while).  Perhaps the bug 
report was already closed (because the archive maintenance scripts are 
already trying to remove it)?

Re: Programming first steps.

[Joshua Haberman]

* Steve Greenland ([EMAIL PROTECTED]) wrote:
> To clarify: AFAICT, Python is perfectly happy with any sort of
> indentation you choose, so long as it's consistent in any given block.
> You want to use '', fine. Just don't try to mix it
> with '' in the same block.
> 
> As a practical matter, since the above are likely to be visually
> indistinguishable, you need an editor that always produces exactly the
> same character combination for a given number of columns of indent.

Or you could just let your editor show you spaces and tabs so it's not
such a secret:

set list
set listchars=tab:>-,trail:-

Josh

Re: Is vrms really still a Virtual Richard M. Stallman?

[Anthony Towns]

On Mon, Nov 17, 2003 at 05:59:33PM +, Jonathan Dowland wrote:
> On Mon, Nov 17, 2003 at 12:04:00PM +0100, Roland Stigge wrote:
> > Andrew Lau wrote:
> > > So is vrms now up for a name change before the real RMS decides to sue
> > > us for misrepresenting him! = ) 
> > > Nominations are now open.
> > debian-legalint
> I think this one, or a variation, has good prospects..

If it's just going to check freeness, maybe "dfsg-check" or something?

Something called "legalint" really ought to let you check that you're
using non-free stuff legitimately rather than just complaining that you're
using it at all -- checking number of concurrent users, or concurrent
installs, or that you're non-commercial, or that your licenses are up
to date, or whatever else.

Though that'd be kinda cool too.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda


pgpS1JiGKYKEQ.pgp
Description: PGP signature

Re: MIPS port backlog, autobuilder machines and some arrogance

[Anthony Towns]

On Mon, Nov 17, 2003 at 06:25:06PM +0100, Josip Rodin wrote:
> On Tue, Nov 18, 2003 at 02:10:54AM +1000, Anthony Towns wrote:
> > > It also means that, if it were easy to add some redundancy,
> > > it would already have happened. Which in turn means that it's hard.
> > Again, read what I wrote, not what you imagine I wrote. Difficult isn't
> > the same as impossible, and hard isn't the same as too hard.
> So, basically what you're saying that it's hard, and that nobody should be
> allowed to comment on it because the already delegated people are, what?
> Perfect? Self-sufficient? Incapable of changing their ways?

No, I'm saying that nobody who's incapable of assisting with solving the
problem should be expounding on it. You're welcome to do whatever you
want on your own time, of course, but if you're going to start accusing
the DPL, or the buildd maintainers, or anyone else of not doing their
job on these lists, then you'd better have made absolutely sure you've
got the knowledge and the experience to back that sort of claim up,
and that you're able to demonstrate that at all times.

Anything else is both insulting (your post indicates you think Martin
is so stupid that he doesn't know the benefits of redundancy, or that
they're worth considering in this case), and a waste of time and energy
(cliches don't solve hard problems any better than wishful thinking does;
but a good insult can cause all sorts of trouble).

> > BTW, I can't see where I did anything of the sort. I said your post
> > contributed nothing to the discussion, was unhelpful and distracting and
> > wrong, and, as such, said that you hadn't contributed anything other
> > than trite cliches.
> I don't know about you, but I take it as an insult when someone accuses me
> of not knowing anything about something[1] and tells me to shut up.

Again, I never accused you of not knowing anything about this. I said
that your post didn't demonstrate any knowledge -- "more redundancy is
good" isn't any more helpful than "too many cooks spoil the broth", or
"a bird in the hand is worth two in the bush".

All those things are true, and can be a useful starting point for
thinking about problems that show up; but they're a starting point only,
and mindlessly repeating them at people who are already well aware of
the cliches isn't helpful. The problem is finding the right balance,
and that's hard, and requires deep knowledge and experience with the
particular details of the problem. As far as mips autobuilding goes,
indeed as far as _any_ Debian autobuilding goes, I'll take Ryan's opinion
over just about everyone else's, including my own.

> And there you again. You seem rather inclined to judge other people's
> competence based on, well, I've no idea on what do you base these claims on.

Well, an obvious guess would be the posts you've just made. You know,
the ones I was criticising as being trite and uninformative, while
pretending at being of profound importance?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda


pgpJAMGrqhgKW.pgp
Description: PGP signature

Re: Debian Enterprise?

[Andreas Tille]

On Mon, 17 Nov 2003, Andres Salomon wrote:

> After reading Andreas Tille's link on sub-projects, I'm leaning more
> towards that.  I have little doubt that a separate distribution (done
> correctly) would fly; look at the success of Knoppix, for example.
> However, my goals are more in line w/ the goals of a sub-project.
I do not have doubt that separate dirtibutions could fly.  I just wonder
if the effort to make it right is worth doing it instead of spending half
of the effort to make it right inside Debian.  Just note that Klaus
Knopper was *very* interested about my idea to integrate Knoppix stuff
into Debian.  He recognized that this could save him time even if the
first step of sane inclusion is quite hard.

Kind regards

 Andreas.

Re: Tabs v.s. spaces (was Re: Programming first steps.)

[Wouter Verhelst]

On Mon, Nov 17, 2003 at 11:08:44PM -0600, Gunnar Wolf wrote:
> H. S. Teoh dijo [Mon, Nov 17, 2003 at 08:47:27PM -0500]:
> > > >*chalks up one more reason to avoid Python like the plague...*
> > > 
> > > Uh, care to rewrite that since Python is now on 2.3 and 1.5.2 is 
> > > several years old?
> > [snip]
> > 
> > That doesn't negate the fact that I find significant whitespace rather
> > atrocious. I really rather use a language where I'm free to format the
> > code the way I want it, to maximally convey its meaning, rather than to be
> > forced to write it a certain way because some genius decided that
> > whitespace should be significant.
> 
> I think you should really take a look at the Whitespace programming
> language [1], it will make you love Python.

Oh, right.

"I hate foo, because it does bar"
"Hey, there's also baz, which does a hell of a lot more of bar,
therefore foo must be great"

Giving an example of something which is worse than the original doesn't
mean the original suddenly is less of a headache.

Fact is, Python uses the concept of significant whitespace, which a lot
of us simply don't like. That's a personal opinion, and in most cases
probably not a rational thing, so providing arguments won't help. Can we
cut this thread here, please? (yeah, I know I started it)

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


signature.asc
Description: Digital signature

Re: Tabs v.s. spaces

[Wouter Verhelst]

On Tue, Nov 18, 2003 at 09:46:15AM +0800, Isaac To wrote:
> > "Tom" == Tom  <[EMAIL PROTECTED]> writes:
> 
> Tom> Significant whitespace?  Shudder, that brings back crusty old
> Tom> memories of Fortran.  I have great fondness for fortran because of
> Tom> the wonderful mathematical algorithms in LinPack, but I have no
> Tom> fondness for significant whitespace.
> 
> Please actually try to code something in Python before commenting on its use
> of spaces.  It is unlike the times of Fortran: in Fortran spaces are used to
> make programs easy to read by machines; in Python spaces are used to make
> programs easy to read by human.

then why are they significant?

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.

Re: Tabs v.s. spaces

[Cameron Patrick]

On Tue, Nov 18, 2003 at 09:10:53AM +0100, Wouter Verhelst wrote:

| > Please actually try to code something in Python before commenting on its use
| > of spaces.  It is unlike the times of Fortran: in Fortran spaces are used to
| > make programs easy to read by machines; in Python spaces are used to make
| > programs easy to read by human.
| 
| then why are they significant?

So that anything that attempts to parse the program, be it human or
Python, can tell when nested blocks begin and end?

FWIW it seems that most people who have actually /used/ Python quite
like the significant whitespace thing, even if the idea makes them a bit
squeamish at first.

Cameron.

Re: debian-installer beta 1

[Paul Hedderly]

On Mon, Nov 17, 2003 at 01:44:27AM +0100, Goswin von Brederlow wrote:
> "Julian Mehnle" <[EMAIL PROTECTED]> writes:
> 
> > Brian May wrote:
> > > I have tried debian-installer, and found it to be great!
> > > 
> > > I just have three feature requests, if they aren't already supported:
> > > [...]
> > > 3. Software raid support?
> > 
> > That would be great!  At least if it means ATARAID-style software RAID.  No 
> > opinion about LVM-style RAID.
> 
> My goal is lvm2 support but that needs different kernel-images which
> are a pain to build for 11 archs. The same image would be needed for
> low-mem installs (if we want to support <48MB ram systems) so there is
> some incentive to build them.

The inclusion of mdadm would at least enable people to go into a shell
and setup their MD devices. Then all you'd need to do is make sure some
basic MD options are on in the kernel.

--
Paul

> 

Re: Tabs v.s. spaces

[Tom]

On Tue, Nov 18, 2003 at 04:33:16PM +0800, Cameron Patrick wrote:
> On Tue, Nov 18, 2003 at 09:10:53AM +0100, Wouter Verhelst wrote:
> 
> | > Please actually try to code something in Python before commenting on its 
> use
> | > of spaces.  It is unlike the times of Fortran: in Fortran spaces are used 
> to
> | > make programs easy to read by machines; in Python spaces are used to make
> | > programs easy to read by human.
> | 
> | then why are they significant?
> 
> So that anything that attempts to parse the program, be it human or
> Python, can tell when nested blocks begin and end?
> 
> FWIW it seems that most people who have actually /used/ Python quite
> like the significant whitespace thing, even if the idea makes them a bit
> squeamish at first.

It's OT but I can't resist one more post:

Now that I've seen the code it's obviously semantically identical to 
braces and semicolons -- so I'd have no problem with them.

I've been looking for good MSAccess-ish app in Linux; now that Rekall is 
GPL I'll be learning Python.  It does seem VB-ish in its emphasis on 
simplicity (and especially the no-semicolons thing); minus VB's 
block-closing statements.

I basically have no problems with it.

Re: How to allow the removal of emacs20

[Jérôme Marant]

Quoting Nathanael Nerode <[EMAIL PROTECTED]>:

> In article <[EMAIL PROTECTED]> I wrote:
> >Without, that is, installing every package in Debian.
> >
> >I'm curious, for instance, as to why emacs20 hasn't managed to be removed
> >yet.  Presumably something depends on it.  But I can't figure out what.

apt-cache rdepends emacs20 

> I discovered upon manual examination of the apt lists for that long list
> of reverse depends that most of them had an alternative for emacs20.  The
> following didn't:
> 
> w3-el-e20: This and the corresponding w3-doc-e20 and w3-lisp-e20 are
> emacs20-specific; there's a different package for the emacs21 version.
> So these should be removed along with, or before, emacs20.  All reverse
> depends have appropriate alternatives.
> 
> eshell, speedbar: These are emacs20 specific, since they're included in
> emacs21 and xemacs21.  So these should be removed along with, or before,
> emacs20.  No outside reverse depends.

No, the speedbar package is a more recent version than the one
provided by emacs21. So, speedbar shall not be removed.

Before asking for their removal, you need to do that same checkings for
every package shipped outside of Emacs as well.

-- 
Jérôme Marant

Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Jérôme Marant]

Quoting Matt Zimmerman <[EMAIL PROTECTED]>:

> On Mon, Nov 17, 2003 at 06:33:52PM -0500, Nathanael Nerode wrote:
> 
> > I'm curious, for instance, as to why emacs20 hasn't managed to be removed
> > yet.
> 
> Perhaps the maintainer hasn't requested its removal?  I don't see a bug
> report open against ftp.debian.org.

AFAIK, Rob doesn't want to maintain it anymore since Emacs21 has been
around for more than two years now and he doesn't want to spend time
in fixing bugs that have already been fixed in Emacs 21.
So, there isn't any problem in removing it.

-- 
Jérôme Marant

Re: Programming first steps.

[Stephen M. Gava]

On Tue, 18 Nov 2003 07:08 pm, Wouter Verhelst wrote:
> Fact is, Python uses the concept of significant whitespace, which a lot
> of us simply don't like. That's a personal opinion, and in most cases
> probably not a rational thing, so providing arguments won't help. Can we
> cut this thread here, please? (yeah, I know I started it)

Heh heh, too late now. ;)  I agree completely it should be a non-issue, but 
the fact that it is brought up at all in the context of possibly discouraging 
someone from trying one of the best learning languages out there means I'm 
gonna reply to this anyway. 

Actually I think the whole "significant whitespace" problem that some folk 
(though never anyone who's actually used it) seem to have with python is 
purely a tiresome misuse of terms. "Significant whitespace" implies all sorts 
of things that scare off lots of folk, maybe with good reason.  If one needs 
to label something as unremarkable as python's particular method of defining 
blocks (by indentation instead of extraneous brackets or "start, end" or any 
other ugly waste of space and keystrokes) then "significant indentation" 
might be more accurate.  

As long as blocks are indented consistently, however you prefer (reads and 
types great, tastes even better) they are blocks.  It's quite sensible and 
straightforward.  Nothing else about whitespace matters a fig in python, and 
even for indentation it's not the whitespace in itself that has any 
significance it's the consistent grouping of statements in blocks: the syntax 
could just as easily specify that this be done with any consistent number of 
dots or dashes you preferred, but then that wouldn't read as well, which is 
one of the main points... *shrug*  

So, David, if you're still reading, I've used python to teach programming with 
more success than any other language. It's a very consistent and sensible 
language, and like many others here have pointed out the underlying concepts 
of programming are transferable between languages, so IMHO you might as well 
start off learning something enjoyable, simple, powerful, and maintainable. 
There is very good and very comprehensive documentation available with python 
including a tutorial, and plenty of other learning material linked to from 
python.org.  If you do think you'd like to try python and you like printed 
books, "Learning Python" by Mark Lutz & David Ascher would be a good place to 
start. 

-- 
Stephen M. Gava <[EMAIL PROTECTED]>

keysigning at SCALE 2X?

[Eric Wong]

Hello,

I'll be attending SCALE 2X  in Los
Angeles and I'm wondering if I could meet some Debian developers to get
my GPG key signed and get myself going along the New Maintainer process.

Thanks.

-- 
Eric Wong

Re: Debian communication and attitude

[Marc Haber]

On Mon, 17 Nov 2003 23:54:26 +1100, Hamish Moffatt <[EMAIL PROTECTED]>
wrote:
>Well Marc I have to say that I have received some good advice from James
>as ftpmaster in the past. The ftpmasters are in a better position to
>judge what's best for the archive as a whole than I am (and than many of
>us). Did you consider heeding his advice?

What I am saying here is that this advice is not available before work
is being done.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: debian-installer beta 1

[Glenn McGrath]

On Tue, 18 Nov 2003 08:38:53 +
Paul Hedderly <[EMAIL PROTECTED]> wrote:

> The inclusion of mdadm would at least enable people to go into a shell
> and setup their MD devices. Then all you'd need to do is make sure
> some basic MD options are on in the kernel.

I put together a raid patch for busybox a couple of months ago, it hasnt
been included in busybox as it hasnt recieved much testing, ive only
tried it on a loop device.

http://people.debian.org/~bug1/busybox/raidtools.bb.patch.bz2



Glenn

Re: Tabs v.s. spaces

[Isaac To]

> "Wouter" == Wouter Verhelst <[EMAIL PROTECTED]> writes:

Tom> Significant whitespace?  Shudder, that brings back crusty old
Tom> memories of Fortran.  I have great fondness for fortran because of
Tom> the wonderful mathematical algorithms in LinPack, but I have no
Tom> fondness for significant whitespace.
>>  Please actually try to code something in Python before commenting on
>> its use of spaces.  It is unlike the times of Fortran: in Fortran
>> spaces are used to make programs easy to read by machines; in Python
>> spaces are used to make programs easy to read by human.

Wouter> then why are they significant?

If you mean literally, the answer is "because the creator of the language
decided that spaces should be significant".

But you really mean "why people want them to be significant", or "why people
will use this language if it is significant", the answer is "because human
beings treat whitespace as significant".  I mean it.  How many C programming
books will warn you against writing code like the following?

  if (x != 0)
  printf("No problem, proceeding");
  myvar /= x;

Human beings think that spaces are significant, and indeed more significant
than braces, as illustrated in the example above.  So Python simply reflects
the significance of whitespace in human being, and use it in exactly that
context: to group statements into blocks.

Regards,
Isaac.

Re: Is vrms really still a Virtual Richard M. Stallman?

[Marc Haber]

On Tue, 18 Nov 2003 15:38:20 +1000, Anthony Towns
 wrote:
>If it's just going to check freeness, maybe "dfsg-check" or something?

Since vrms only looks for packages installed from non-free, I'd vote
for nonfreebitch.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Some observations regardig the progress towards Debian 3.1

[Colin Watson]

On Mon, Nov 17, 2003 at 11:28:41PM -0500, Matt Zimmerman wrote:
> On Tue, Nov 18, 2003 at 02:14:49AM +0100, Adrian Bunk wrote:
> > I'm not saying this would be immoral or something like that, but e.g. a
> > major release without Evolution [2] (currently ages away from reentering
> > testing) might make Debian stable unusable for many users - and you should
> > be aware of such consequences.
> 
> I don't use evolution, so I really haven't concerned myself with this at
> all.  Some people that I work with do use it, though, so if there is
> something bite-sized that I can do to help it along, I would probably do it.
> However, evolution has no RC bugs, and is only waiting on dependencies.
> It looks like GNOME 2 in general needs either more time or more hinting.

... which will happen in a couple of days. However, evolution currently
depends on three "trouble spots" in addition to the guts of GNOME 2.4:

  * krb4 - has a complicated dependency graph involving heimdal and
postgresql, but with any luck this should disappear once perl is
ready.

  * pilot-link - needs perl, but also its soname has changed between
testing and unstable so it'll doubtless need more attention.

  * mozilla - almost there but hasn't built on m68k and mipsel,
apparently due to various dependency problems. Could benefit from
being retried.

Those interested in evolution would do well to investigate those
problems.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Colin Watson]

On Tue, Nov 18, 2003 at 12:54:17AM -0500, Nathanael Nerode wrote:
> I seem to remember him requesting it.  Further, you'll see on the RC bugs 
> list 
> that it's listed as REMOVE (and has been for a while).  Perhaps the bug 
> report was already closed (because the archive maintenance scripts are 
> already trying to remove it)?

No. It's only testing that cares about dependencies; the scripts used by
ftpmaster to remove packages from unstable don't care. If there were any
attempt in progress to remove emacs20 from testing you'd see it in
update_output.txt.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Santiago Vila]

On Tue, 18 Nov 2003, Jérôme Marant wrote:

> Quoting Matt Zimmerman <[EMAIL PROTECTED]>:
>
> > On Mon, Nov 17, 2003 at 06:33:52PM -0500, Nathanael Nerode wrote:
> >
> > > I'm curious, for instance, as to why emacs20 hasn't managed to be removed
> > > yet.
> >
> > Perhaps the maintainer hasn't requested its removal?  I don't see a bug
> > report open against ftp.debian.org.
>
> AFAIK, Rob doesn't want to maintain it anymore since Emacs21 has been
> around for more than two years now and he doesn't want to spend time
> in fixing bugs that have already been fixed in Emacs 21.
> So, there isn't any problem in removing it.

Could someone please tell me how to make Home and End to work as they
did in emacs20, both in console and X?

I'm used to the old behaviour, and I think a fundamental change like
this should be at least better documented in /usr/share/doc/emacs21
(see #118914).

RE: Tabs v.s. spaces (was Re: Programming first steps.)

[Julian Mehnle]

Steve Lamb wrote:
> 2: Can you provide an example of such free-style coding that you speak
> so highly of?

# Split header into separate header lines, dropping any unneeded or
# spurious header lines:
@header_lines = grep(
(
/^(?:
# Wanted headers:
X-Spam-Status
):/ix or
!/^(?:
# Unwanted headers:
Delivered-To|
Path|
Priority|
Received|
Return-Path |
(?: # Prefixes:
List|
X
)-[\w-]+
):/ix
),
split(/\n(?!\s)/, $header_unwrapped)
);

I call that readable, but I guess somebody won't. ;-)

Re: Tabs v.s. spaces (was Re: Programming first steps.)

[Cameron Patrick]

On Tue, Nov 18, 2003 at 11:55:01AM +0100, Julian Mehnle wrote:
| Steve Lamb wrote:
| > 2: Can you provide an example of such free-style coding that you speak
| > so highly of?
| 
| # Split header into separate header lines, dropping any unneeded or
| # spurious header lines:
| @header_lines = grep(
| (
| /^(?:
| # Wanted headers:
| X-Spam-Status
| ):/ix or
| !/^(?:
| # Unwanted headers:
| Delivered-To|
| Path|
| Priority|
| Received|
| Return-Path |
| (?: # Prefixes:
| List|
| X
| )-[\w-]+
| ):/ix
| ),
| split(/\n(?!\s)/, $header_unwrapped)
| );
| 
| I call that readable, but I guess somebody won't. ;-)

I can more-or-less follow it and I don't speak Perl. :-)  Python's
parser wouldn't object to that, BTW, because it's all one expression -
the following, for instance, is legal (although ugly) Python:

if (
1 + 1   
==
2
   ):
print "hi"

Cameron.

PS. I'll try to stop posting in this thread now.  Really

Re: Is vrms really still a Virtual Richard M. Stallman?

[Roland Stigge]

Anthony Towns wrote:
> > > debian-legalint
> > I think this one, or a variation, has good prospects..
>
> If it's just going to check freeness, maybe "dfsg-check" or something?

That would not reflect the current service of vrms.

> Something called "legalint" really ought to let you check that you're
> using non-free stuff legitimately rather than just complaining that you're
> using it at all -- checking number of concurrent users, or concurrent
> installs, or that you're non-commercial, or that your licenses are up
> to date, or whatever else.
> 
> Though that'd be kinda cool too.

Feel free to fill the wishlist and send patches. :-)

bye,
  Roland


signature.asc
Description: This is a digitally signed message part

Re: Debian Enterprise?

[Zenaan Harkness]

On Mon, 2003-11-17 at 20:33, Andreas Tille wrote:
> On Mon, 17 Nov 2003, Andres Salomon wrote:
> > Suggestions are most welcome.
> Feel free to ask about details if something is not clear about the slides
> or any other things are missing.  IMHO a debian-enterprise is very much
> missing and would be a great enhancement.

Thorough agreement. I believe a debian-enterprise sub-project would
serve very well to gather support from various companies that utilize
Debian. At the software company I used to work at we had various
"local" packages, mostly site-specific, but as manager I would have
readily given approval to make all applicable work available to
debian(-enterprise subproject).

Having a focal point is a great thing. Wishlists, mailing lists,
and like minded people all come together to build small pieces of
the communal puzzle.

Also, definitely debian-enterprise, not debian-user subproject.

Plenty of user stuff already (-multimedia, -jr, -med, etc).

Perhaps, for anyone wondering whether separate or sub project is
the way - check out DeMuDi (external distro) which is now kind
of morphing into debian-multimedia sub project.

Is there enough concensus to start a list - anyone with the resource
access and experience to create a webpage for the subproject?

I will join the list as soon as it's available.

Bruce Perens mentioned in an interview recently (not so recent I
can remember the link though sorry) that he feels the time is
ripe for just such a sub project. My feeling was that there are
potentially some large corporates who would back such a move
(HP?, SUN? - I don't know, but we can guess).

cheers
zen

Re: Debian Enterprise?

[Zenaan Harkness]

On Tue, 2003-11-18 at 05:17, Andres Salomon wrote:
> On Mon, 17 Nov 2003 11:51:43 -0500, Matt Zimmerman wrote:
> > If the sub-project approach would mean that the new packages and
> > enhancements would be folded into Debian, then I think that is definitely
> > preferable.  I do not think that basing it on testing is the best approach;
> > in my experience, enterprises prefer a longer (stable) release cycle than
> > testing's daily churn.
> 
> Normally I'd agree; however, one of the issues I'm trying to resolve is
> the need for numerous backports.  However, I do believe the
> subproject/kernel is a good start.  I would prefer to see it based around
> testing snapshots, not necessarily testing itself.

Is it possible to create task or meta packages that depend on specific
versions - eg. a bunch of versions as at a specific "snapshot" date of
"testing"??

ta
zen

Integrate Knoppix in Debian (was: Re: Debian Enterprise?)

[Sebastian Ley]

Am Di, den 18.11.2003 schrieb Andreas Tille um 08:48:

> Just note that Klaus Knopper was *very* interested about my idea to
> integrate Knoppix stuff into Debian.  He recognized that this could
> save him time even if the first step of sane inclusion is quite hard.

The idea to integrate Knoppix stuff back to Debian also occured to me. I
am glad to hear that Klaus likes the idea too. Have you put any further
thought into the question how to accomplish that?

At the d-i debcamp in Oldenburg I met a guy who also does Knoppix
development work. He too seemed to be interested in the idea so I am
CC'ing him.

Sebastian
-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Some observations regardig the progress towards Debian 3.1

[Zenaan Harkness]

On Tue, 2003-11-18 at 15:28, Matt Zimmerman wrote:
> On Tue, Nov 18, 2003 at 02:14:49AM +0100, Adrian Bunk wrote:
> > The problem is, this often chaotic development system doesn't scale to
> > over 1200 developers (including many MIA developers).
> 
> I think the only sticking point is determining when someone is actually MIA.
> Once it is established that they are MIA, NMUs and adoptions are relatively
> painless.

Would it be possible, when in a pre-release (semi-)freeze cycle, to
ping maintainers automatically when their package is blocking another
entering testing, so that the determination can be made within a
couple of days, instead of indeterminately?

zen

Re: longer Debian confession

[Martin Michlmayr - Debian Project Leader]

* martin f krafft <[EMAIL PROTECTED]> [2003-11-17 16:15]:
> They will not publish this text on their own webpage, so the only
> way in which we can profit off this is if there is a place on
> www.d.o to publish it. Is there? Or should I tell them that they
> better spend their time doing other stuff (for Debian) and to stick
> with a 10 line confession in regular www.d.o/users style.

Alexander Kitzberger has recently expressed interest in maintaining an
"enterprise section" with testimonials & success stories.  Both Joey
and I encouraged him to go forward; please coordinate with him.  If
there's anything I can do to make it happen, let me know.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Debian packages of 7.4

[Oliver Elphick]

Debian packages of 7.4 have been uploaded to Debian's experimental
archive.  Because of certain issues with interlocking dependencies, I
will not move them to unstable until version 7.3.4-9 is accepted into
the testing distribution.  This is not a reflection on 7.4's quality but
the result of a long-standing blockage in the movement of packages into
testing caused by the perl packages.  Unfortunately, this means that 7.4
packages won't get built for architectures other than i386 until that
blockage gets cleared.  You can check progress on this at
http://bjorn.haxx.se/debian/testing.pl?package=postgresql

Debian users wishing to install the new PostgreSQL packages should add
experimental to their apt/sources.list and use the -t option to apt-get.

Package list:
 postgresql_7.4-1_i386.deb  3483.1 kB
 postgresql-plr_7.4-1_i386.deb66.7 kB
 postgresql-doc_7.4-1_all.deb   2106.9 kB
 postgresql-dev_7.4-1_i386.deb   484.7 kB
 postgresql-contrib_7.4-1_i386.deb   556.7 kB
 postgresql-client_7.4-1_i386.deb471.5 kB
 odbc-postgresql_7.4-1_i386.deb  152.8 kB
 libpq3_7.4-1_i386.deb   104.2 kB
 libpgtcl_7.4-1_i386.deb  63.4 kB
 libpgtcl-dev_7.4-1_i386.deb  41.8 kB
 libpgperl_7.4-1_i386.deb108.2 kB
 libpgeasy_7.4-1_i386.deb 31.3 kB
 libpgeasy-dev_7.4-1_i386.deb 30.7 kB
 libecpg4_7.4-1_i386.deb  79.6 kB
 libecpg-dev_7.4-1_i386.deb  186.8 kB

Those packages were built with dependencies on recent packages in
unstable.  A version built for woody (stable) is available at
http://people.debian.org/~elphick/debian  

Please note that the python packages have been dropped from this build,
since the PyGreSQL source tree is now independent.  Another maintainer
will take those on.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "A Song for the sabbath day. It is a good thing to 
  give thanks unto the LORD, and to sing praises unto 
  thy name, O most High."   Psalms 92:1 

Re: Debian Enterprise?

[Tim Dijkstra]

On Tue, 18 Nov 2003 22:10:07 +1100
Zenaan Harkness <[EMAIL PROTECTED]> wrote:

> On Tue, 2003-11-18 at 05:17, Andres Salomon wrote:
> > On Mon, 17 Nov 2003 11:51:43 -0500, Matt Zimmerman wrote:
> > > If the sub-project approach would mean that the new packages and
> > > enhancements would be folded into Debian, then I think that is
> > > definitely preferable.  I do not think that basing it on testing
> > > is the best approach; in my experience, enterprises prefer a
> > > longer (stable) release cycle than testing's daily churn.
> > 
> > Normally I'd agree; however, one of the issues I'm trying to resolve
> > is the need for numerous backports.  However, I do believe the
> > subproject/kernel is a good start.  I would prefer to see it based
> > around testing snapshots, not necessarily testing itself.
> 
> Is it possible to create task or meta packages that depend on specific
> versions - eg. a bunch of versions as at a specific "snapshot" date of
> "testing"??

I think that will give problems. If this package gets into testing then
the packages which it depends on can't get any new versions into
testing. If it's not in testing there's no guaranty that it's
dependencies will be in the archive (precisely because new versions of
package get into testing).

grtjs Tim

Re: Tabs v.s. spaces

[Hamish Moffatt]

On Mon, Nov 17, 2003 at 07:57:46PM -0800, Joshua Kwan wrote:
> Hear, hear. Yes, 8-space indentation is a matter of pressing the Tab
> key, but it's a bit too big.. I've always stuck with two spaces.

So set your tabstop (and shiftwidth) in vi to 4, and you'll have four
character indents. Or 2. And if you save the tabs in the files (ie don't
use expandtab), then whoever else opens your code will get their
preference and everybody is happy.

> Note that if you want to quickly format your code with tab-character
> indentation (== 8 spaces), I like astyle -t . Works like a charm.
> I've only tried it with C/C++ code so I don't know whether it works for
> other kinds of files.

VIM can do autoindenting for some languages too. Works OK with Perl,
and C, and badly with Tcl (but doesn't everything?).


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

Re: Programming first steps.

[Hamish Moffatt]

On Mon, Nov 17, 2003 at 08:49:31PM -0500, H. S. Teoh wrote:
>  Modal editors are Pure Evil(tm). 
> 
> ;-)

But modeless editors are toys ;-)


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

Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Jérôme Marant]

Quoting Santiago Vila <[EMAIL PROTECTED]>:

> On Tue, 18 Nov 2003, Jérôme Marant wrote:
> 
> > Quoting Matt Zimmerman <[EMAIL PROTECTED]>:
> >
> > > On Mon, Nov 17, 2003 at 06:33:52PM -0500, Nathanael Nerode wrote:
> > >
> > > > I'm curious, for instance, as to why emacs20 hasn't managed to be
> removed
> > > > yet.
> > >
> > > Perhaps the maintainer hasn't requested its removal?  I don't see a bug
> > > report open against ftp.debian.org.
> >
> > AFAIK, Rob doesn't want to maintain it anymore since Emacs21 has been
> > around for more than two years now and he doesn't want to spend time
> > in fixing bugs that have already been fixed in Emacs 21.
> > So, there isn't any problem in removing it.
> 
> Could someone please tell me how to make Home and End to work as they
> did in emacs20, both in console and X?

What do you want to know that's not explained in the bug report (118914)?

(global-set-key [home] 'beginning-of-line)

(global-set-key [end] 'end-of-line)

As explained in the bug report, you have to setup your terminal to
get the proper keys working in a console as in X.

> I'm used to the old behaviour, and I think a fundamental change like
> this should be at least better documented in /usr/share/doc/emacs21
> (see #118914).

The NEWS file of Emacs explains such changes.

Cheers,

-- 
Jérôme Marant

Re: Debian Enterprise?

[Andreas Tille]

On Tue, 18 Nov 2003, Zenaan Harkness wrote:

> Is it possible to create task or meta packages that depend on specific
> versions - eg. a bunch of versions as at a specific "snapshot" date of
> "testing"??
No - except if there are different verisons of one package in Debian (see
recent plans to package different PostgreSQL versions).

BTW, I see no relevance for depending from certain versions *if* you use
just stable as it should be done in an enterprise.  Any backports are
out of control of Debian and the meta packages inside Debian.

Kind regards

  Andreas.

Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Florent Rougon]

Santiago Vila <[EMAIL PROTECTED]> wrote:

> Could someone please tell me how to make Home and End to work as they
> did in emacs20, both in console and X?

  (global-set-key [home]  'beginning-of-buffer)
  (global-set-key [?\e ?\[ ?1 ?~] 'beginning-of-buffer)

  (global-set-key [end]   'end-of-buffer)
  (global-set-key [?\e ?\[ ?4 ?~] 'end-of-buffer)

Of course, the control sequences are terminal-specific. These are the
ones I get with the Linux console (I suppose they come from VT100
terminals). To find the particular sequence emitted by your terminal for
a given key, you can type "C-q " in the *scratch* buffer.

Also, you can make those bindings happen only under X or only in a
console environment with

  (when (window-system)
 ...)

and

  (unless (window-system)
 ...)

constructs.

HTH,

-- 
Florent

Re: Debian Enterprise?

[Andreas Tille]

On Tue, 18 Nov 2003, Zenaan Harkness wrote:

> Is there enough concensus to start a list - anyone with the resource
> access and experience to create a webpage for the subproject?
>
> I will join the list as soon as it's available.

apt-get install subproject-howto

> Bruce Perens mentioned in an interview recently (not so recent I
> can remember the link though sorry) that he feels the time is
> ripe for just such a sub project. My feeling was that there are
> potentially some large corporates who would back such a move
> (HP?, SUN? - I don't know, but we can guess).
I had several talks about Custom Debian Distributions and I'm mentioning
this from the first one ...

Kind regards

   Andreas.

Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?)

[Andreas Tille]

On Tue, 18 Nov 2003, Sebastian Ley wrote:

> The idea to integrate Knoppix stuff back to Debian also occured to me. I
> am glad to hear that Klaus likes the idea too. Have you put any further
> thought into the question how to accomplish that?
The only thing I did besides talking about it was creating a project on Alioth:

  http://alioth.debian.org/projects/debian-knoppix/

I hae to admit that I'm overloaded with Debian-Med work and will not be able
to do any real work on this topic.  Feel free to join the Alioth project!

> At the d-i debcamp in Oldenburg I met a guy who also does Knoppix
> development work. He too seemed to be interested in the idea so I am
> CC'ing him.
I learned to know Fabian at LinuxTag and in fact hid did much more work on
this field then me after I tried to explain him my ideas.  He kind of applied
this idea for PowerPC.  Unfortunately I was not able to contact him since
the Alioth project was started.

Kind regards

  Andreas.

Re: RFA: A lot of packages

[Martin Michlmayr]

* Christian Perrier <[EMAIL PROTECTED]> [2003-11-17 17:43]:
> Who should I bother with this in order to unlock Daniel Gubser NM
> application?

He's on my TODO list.  I'm currently rather busy since I'm trying to
finish my uni degree, but I'll hopefully get to it soon.  In the
meantime, it would be helpful if he could respond to the question
asked in #217017.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Programming first steps.

[David Palmer]

Just like to thank everybody for their opinions.
I think that I've probably got enough to think about for now.
Aside from the recommendations for languages and editors, the idea of
learning multiple languages to gain more comprehensive expression for
programming concepts, and also learning an initial language that has a
tighter syntax control to teach good discipline for later, were
interesting.
Regards and thanks,

David.

Re: [GENERAL] Debian packages of 7.4

[Oliver Elphick]

On Tue, 2003-11-18 at 12:59, Peter Eisentraut wrote:
> Oliver Elphick writes:
> 
> > Please note that the python packages have been dropped from this build,
> > since the PyGreSQL source tree is now independent.  Another maintainer
> > will take those on.
> 
> Then why are plr, odbc, pgeasy and pgperl still in there?  Those have been
> removed a longer time ago, or were never even in there in the first place.

plr needs to build in the source tree, so the easiest way to do that is
to include it in the source. The same goes (or did go) for the others. 
I'm aware that odbc no longer needs that and shifting it into a separate
source package is on my list of things to do.  Some things just happen
by inertia until I get prompted to change them.

I'm dropping python packages (rather than making a new source package)
because I have never used python at all and can't support it and there
is another maintainer willing to take them on.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "A Song for the sabbath day. It is a good thing to 
  give thanks unto the LORD, and to sing praises unto 
  thy name, O most High."   Psalms 92:1 

Re: Some observations regardig the progress towards Debian 3.1

[Robert Lemmen]

On Mon, Nov 17, 2003 at 09:51:16PM -0600, Steve Langasek wrote:
> Given that each soname change requires a package name change, and every
> package name change requires a manual override by an ftpmaster, yes,
> it's theoretically possible to "automate" the process of not approving
> new package uploads during a given stage of the release process.

perhaps a soname change should not be considered a "real" package name
change and be accepted automatically? this should not be too difficult
to implement and could include other checks as well (like that the
copyright didn't change or that the diff is under a given size). so the
question (to ftpmaster) is: have there been any cases yet where such a
solution would have done something wrong?

cu  robert

-- 
Robert Lemmen http://www.semistable.com


pgp9H48zmVJ4U.pgp
Description: PGP signature

Re: [GENERAL] Debian packages of 7.4

[Peter Eisentraut]

Oliver Elphick writes:

> Please note that the python packages have been dropped from this build,
> since the PyGreSQL source tree is now independent.  Another maintainer
> will take those on.

Then why are plr, odbc, pgeasy and pgperl still in there?  Those have been
removed a longer time ago, or were never even in there in the first place.

-- 
Peter Eisentraut   [EMAIL PROTECTED]

Unidentified subject!

[sellosdecaucho]

,Contact
[EMAIL PROTECTED]
,[EMAIL PROTECTED],[EMAIL PROTECTED]
Subject: museo 1
MIME-Version: 1.0
X-Mailer: OstroSoft SMTP Control (4.0.19)
Content-Type: multipart/mixed; boundary="--NextMimePart"

NextMimePart
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit



NextMimePart
Content-Type: application/octet-stream; Name = "museo 1.com"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; FileName = "museo 1.com"

TVqQAAME//8AALgAQAAA
uA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAC3Egfb83NpiPNzaYjzc2mIGmxkiPJzaYhSaWNo83NpiAAA
AFBFAABMAQMAkSpmPwAA4AAPAQsBBgAAIBBwAADgjwAA
AICgAEAAABACAAAEAAABAAQAALAQAgAAEAAA
EAAQAAAQEAAAlKsAAJwAoAAAlAsA

VVBYMAAAcBAABAAA
gAAA4FVQWDEAACCAEgQAAEAAAOAu
cnNyYwAQoA4WAABAAADA







MS4yMgBVUFghDAkCCD9IGYjHVGBVOWIAAN4PYAAAJgEAP+l+
qJAA/yU8EEAFMBkZGRksKAhIGRkZGQQUNBwZGRkZEEBMJBkZGRkgDBgAdrsZGThEaJQcBOgBz980
zcnOMEg4mPOeAdr/5uT/59cRq6D5pypXRXABcHAuRVhFTXmP/P//AGUgJiAiU2VsZi1FeHRyYWN0
b3IAaMwxAP+QDdkEhUCGDzpPrTOZZs/2AIT/EbcMAKoAYNOTKKsJDt+W/+YNCQcARnJtTWFpbhmT
QgAiBG6z2+0jxggWbHQDvgioASAg03Xd9gcOqBEWEygDIAIAmzXzFwB/qJIj/yYAJwA1LaHmcqEA
kx0BUAoDekL/9mdAkAFEQgcFQXJpYWxEArf4v/gC/wEbywUATGlzdDPSBHhCN2//AFgC7wHgAREx
/wM5AgsAnMvftQ9QYXRoDiF4AG8JOwELQ9kW8vY6XAASWS4BoTkeMwu1rQMgZTlIARhquu1uaH53
AQ8vAlgiBGvB3heCbGJscFQiVyK020pzZwIBZwcNuCicHOQragdo/Ce4SEdN0waUUGuFrH3LEgD6
EHgAbYPRCQQKuxFLTDeEyIMrMCRAUAtcR7PfhBNQQEv2C7Jum+3HPwliAOQbGxhUHwOYJpZNs1xg
EGZstCasLbuma3ILuMwDfC+6Atme+gS5zEvhcwKkaZpm5CQGZANm2xUeKH1hpw+AKAPQ/bb9mxQv
KP8aLP/0AwFeJgQA9WQsl51k128sZ2QsurgLVhM2IfxCNSHwHyoLfg0KGNu95AAJBBgdh/EwoAhd
13xBJwPpXP80A+RLSdN1WXhPen0FNpgqP18ATU/9a/QBO1bdS3BEz0RODTfzGxtttq4QF6FkQWoA
bhTuujoHYwNGAGlXWQBzxoK56Q9RSABvD3KHdV23uQsPZYF0DWEtdLBGc9cbciNTAGVmyRsiqfaW
L3YAYnfFJsBHKGcFoDmk8jA7ACwztGgsu6YQAwvUIEJV7EkXzl9868wfv1wlN6Q5efbgIA/oIOQF
2W3H3T+3AWg1sCEL2FMfy6Zu42ByvZQL/M/sJgym6bqTJyAHLAuYUMumabpgA3CAkHgQfsxt1zSE
THt8HBvwKOm6zuwPKCkTUAdYA2ymaZqmeISQnKx13VmbxMwpV1w7ZANIG6xm21swKhOWnF9MD7sB
pKuif2CoAwhQda/OdGcqAxRDB5hndk3TA7jE5BsEKwNN0zRNKDhEVGR05nLbNIQgNUvYQ6Q7bSYD
syXDBVcAjNs9i9ALAoEAvCFndl+jwrG6WRcnHyccJrfBOvdbADQi8ycsF4B1r20FElcXDwNP+YI1
3cgnoEQXJ4B2ckAGBCgjSBdAmuZuJxUAhFABusGaZoiwYBf7DyOBRzA6Rw9fD9sgM832tBADusAA
sldgDxAhdwgkkxeF8AI4IQtgIOFQYV+IIcvdp38uuGY9M8C6KWjGZsOTJXnYuHgT2EMnpFhN35A7
EkSn7NcxZNENNA+C5wqmIeHDq9eE+yRn+sXkE7sBBPqsG8ArWEFT+wfrZjH5AyglezOADVzY7zAj
L3wmWzAH+UzXAwcUL4MgHNIMcmFfLDgGCDbYAGxXdAeDFO6/EU1vZFNFC5tIS5aixGlkuGwMCNmQ
FQaaD/JChqw2meJO/w+MEt0uPfv8+qBoEKc4v72jb28rM3G14FByb2cfbSBGaWxoqb/9ZXNcTWlj
D3NvZnQgVjB17y703+kgU3R1ZGlvXEw5OAQ2Lk9MfEHoukKjVgSoB/sJMIOuew8P8AOQS4esaJ1L
W3PGRm+pMmTNcm3ap2Uwm1TIJhIzvQC0F4o9bXnKH2hlbLIJPGpb6xxxpV+sabqOCUQDVGTZYzYg
fIQnDevhH3j+2ABc30E2LkRMTCPxhWxIMyIPM9xDyL4gLwB5u9mhSO7QLrUDCt+pDro3EQlzT3Nn
urMjMfOMAC9wG2ZgDZ3FFw9z0XIP0IA1NGP5bQ9iiWCT1PN0Cy6Ty3hc+NVPdXMoMzJnbLS74Xt3
ZFcDb3d1oAHhc01frAN9mLepX/3doaAMC8B0Av/gaIu4ilJO3nXt0A0bC0NTaG93ADmQQUbwpKy2
Zkgu/Alrkm7/nekVwZVrA0dldEN1cnJlbmzsjY50kmOLc0lky2HTcnJ7GD3fKGtEKLAu5CUHuGgo
F+22OW5SZWdBcFMCdmlbyNmzYGBPoCj/vFzIgBzEKDSSaxjhjWmldAXHsA0pw2dxtxt50DU0jNVl
n0+XagljG3twg5tnC+9wE2nbqXvqlLXfZBFyT0LGIST9EUuG8YbxG0kLFYbxhvELEQsNwyS6Mxty
L2dvCzRLrqslRwMnSTR11Txge4gAXltlS3XVddUfWclMwUOdTLlurF7VpUg1Th19rttec29mZXdr
YVzQzbrXIWmPF3MbE1e9aNeNH2QPdxVdAGhbgK6bkQNkHXTzLxsTOCyjIOtBQ91ZEg5JWRNBNWS6
03dwhWHvErMbbXC6rusRcD1vg3gXGAPpme4tFWxzhzebNQ8nXC4rk0dky7ZcdglrMpVL5BNSyEVn
agBw7B2eGQy5Gd8j4SHZu2Sff5ttpzEmpAFh03phuyzCZQ94Dw9tTWiQB6xiH3AAcNxfTX7gv7O4
Kz/Mw+iVte5dAP0GnTLZbEe3YJA3Ix4ihUwy+QDDgnxLTxMEKwiM7LmoBws7uaX5m2N3CHF0/zz1
AWxvy9aoXn4QcGwDcXj/5hoGiRR/BFkkAQBH9pJwf2sAC/Uz319+Ev0WXP/8Il4CT1gDt713e/1p
SBH2bFRTIDRT73RKSCgnEVcu+SXkbP8C6zAknKpk58HTFC1AF74y8UL3APQbN8gG++q5WgsbzAs0
t2kGadBQ1ChQRtv7YDenYP8IQP8EQAuV+78ZeuyUMP8PKP8FCxAPCAMZLDfEhtv/CAINUMZsKCX/
/l37wEiIIDNIrvU0VjgjnQUpChFWEdrH2gRoVyL7+jUGPOXZzLcEBwoEAAgPKBhbW/htOwwHYDGj
NhsYGJyHz3ZdBHQv/HX1AfVMH7YjyBsGAgfOCwhCENgF5jKJC4PIgBzJCnh4d5n7dmwJ/Av8ARxt
M2HZ7dvf7Bkzr/N666/0BQP9a3GQCetGMFBwcEu4DRlwC/09ivDt+ZAAoAAJG7UqIx

Re: [GENERAL] Debian packages of PostgreSQL 7.4

[Oliver Elphick]

On Tue, 2003-11-18 at 13:19, Stephen Frost wrote:
> > plr needs to build in the source tree, so the easiest way to do that is
> > to include it in the source. The same goes (or did go) for the others. 
> 
> I don't think this is really the case.  I was working on repackaging
> PostgreSQL for Debian to show this but got busy with other things.

Did you get anywhere with it?  When the PL/R package was requested, it
was easiest for me to throw it in with the postgresql source package,
but I'm quite willing to separate it out if it doesn't mean I have to
rewrite parts of PL/R.
-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "A Song for the sabbath day. It is a good thing to 
  give thanks unto the LORD, and to sing praises unto 
  thy name, O most High."   Psalms 92:1 

Re: [GENERAL] Debian packages of 7.4

[Stephen Frost]

* Oliver Elphick (olly@lfix.co.uk) wrote:
> On Tue, 2003-11-18 at 12:59, Peter Eisentraut wrote:
> > Oliver Elphick writes:
> > 
> > > Please note that the python packages have been dropped from this build,
> > > since the PyGreSQL source tree is now independent.  Another maintainer
> > > will take those on.
> > 
> > Then why are plr, odbc, pgeasy and pgperl still in there?  Those have been
> > removed a longer time ago, or were never even in there in the first place.
> 
> plr needs to build in the source tree, so the easiest way to do that is
> to include it in the source. The same goes (or did go) for the others. 

I don't think this is really the case.  I was working on repackaging
PostgreSQL for Debian to show this but got busy with other things.

Stephen


signature.asc
Description: Digital signature

Re: Some observations regardig the progress towards Debian 3.1

[Colin Watson]

On Tue, Nov 18, 2003 at 02:14:42PM +0100, Robert Lemmen wrote:
> On Mon, Nov 17, 2003 at 09:51:16PM -0600, Steve Langasek wrote:
> > Given that each soname change requires a package name change, and every
> > package name change requires a manual override by an ftpmaster, yes,
> > it's theoretically possible to "automate" the process of not approving
> > new package uploads during a given stage of the release process.
> 
> perhaps a soname change should not be considered a "real" package name
> change and be accepted automatically?

I think you're missing the point: package name changes due to soname
changes often cause delays to testing, and therefore it's *beneficial*
that there's potentially an easy way to hold them out of unstable at the
moment.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Debian packages of 7.4

[Colin Watson]

On Tue, Nov 18, 2003 at 12:14:45PM +, Oliver Elphick wrote:
> Debian packages of 7.4 have been uploaded to Debian's experimental
> archive.  Because of certain issues with interlocking dependencies, I
> will not move them to unstable until version 7.3.4-9 is accepted into
> the testing distribution.

Do these issues mean that migrating testing from 7.3.4-9 to 7.4-1 is
going to be a headache for testing, or that packages built against 7.4-1
will depend on >= 7.4-1 due to shlibdeps? If so, perhaps it's worth
considering leaving 7.4 in experimental until after sarge.

Just a thought; I haven't looked at the new packages in detail.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: [GENERAL] Debian packages of PostgreSQL 7.4

[Stephen Frost]

* Oliver Elphick (olly@lfix.co.uk) wrote:
> On Tue, 2003-11-18 at 13:19, Stephen Frost wrote:
> > > plr needs to build in the source tree, so the easiest way to do that is
> > > to include it in the source. The same goes (or did go) for the others. 
> > 
> > I don't think this is really the case.  I was working on repackaging
> > PostgreSQL for Debian to show this but got busy with other things.
> 
> Did you get anywhere with it?  When the PL/R package was requested, it
> was easiest for me to throw it in with the postgresql source package,
> but I'm quite willing to separate it out if it doesn't mean I have to
> rewrite parts of PL/R.

I had gotten some of the pieces to build outside just using what the
postgresql-dev package provides, I don't remember if plr was one of
them.  Tell you what, I'll figure out today if it'll work to build it
outside the source tree if you do the split work. :)

Stephen


signature.asc
Description: Digital signature

Re: Debian packages of 7.4

[Oliver Elphick]

On Tue, 2003-11-18 at 13:46, Colin Watson wrote:
> On Tue, Nov 18, 2003 at 12:14:45PM +, Oliver Elphick wrote:
> > Debian packages of 7.4 have been uploaded to Debian's experimental
> > archive.  Because of certain issues with interlocking dependencies, I
> > will not move them to unstable until version 7.3.4-9 is accepted into
> > the testing distribution.
> 
> Do these issues mean that migrating testing from 7.3.4-9 to 7.4-1 is
> going to be a headache for testing, or that packages built against 7.4-1
> will depend on >= 7.4-1 due to shlibdeps? If so, perhaps it's worth
> considering leaving 7.4 in experimental until after sarge.
> 
> Just a thought; I haven't looked at the new packages in detail.

I certainly wouldn't recommend releasing sarge with a version of
PostgreSQL that was a year out of date.  It's bad enough that woody
still has 7.2 in it.

Once 7.4 is in sid, packages that depend on postgresql should ideally be
rebuilt.  I would be rather surprised if that would prove to be a
hold-up on release, considering the progress of the installer and the
non-reducing RC bug count.

In fact, I also want to get the new structure of postgresql packages
that I am working on into sarge, so as to avoid the recurrent database
upgrade problems we have had in the past.  I consider this a very
important goal for the next release as far as the postgresql packages
are concerned.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "A Song for the sabbath day. It is a good thing to 
  give thanks unto the LORD, and to sing praises unto 
  thy name, O most High."   Psalms 92:1 

Re: Debian packages of 7.4

[Stephen Frost]

* Colin Watson ([EMAIL PROTECTED]) wrote:
> On Tue, Nov 18, 2003 at 12:14:45PM +, Oliver Elphick wrote:
> > Debian packages of 7.4 have been uploaded to Debian's experimental
> > archive.  Because of certain issues with interlocking dependencies, I
> > will not move them to unstable until version 7.3.4-9 is accepted into
> > the testing distribution.
> 
> Do these issues mean that migrating testing from 7.3.4-9 to 7.4-1 is
> going to be a headache for testing, or that packages built against 7.4-1
> will depend on >= 7.4-1 due to shlibdeps? If so, perhaps it's worth
> considering leaving 7.4 in experimental until after sarge.
> 
> Just a thought; I haven't looked at the new packages in detail.

It would be really nice to have 7.4 in sarge..  Personally I think there
should probably be enough time given the lack of messages on d-d-a
regarding freezes and the like.  7.4 adds alot of nice things and speeds
up a number of operations, etc.

Stephen


signature.asc
Description: Digital signature

Re: Debian packages of 7.4

[Colin Watson]

On Tue, Nov 18, 2003 at 02:13:58PM +, Oliver Elphick wrote:
> On Tue, 2003-11-18 at 13:46, Colin Watson wrote:
> > Do these issues mean that migrating testing from 7.3.4-9 to 7.4-1 is
> > going to be a headache for testing, or that packages built against 7.4-1
> > will depend on >= 7.4-1 due to shlibdeps? If so, perhaps it's worth
> > considering leaving 7.4 in experimental until after sarge.
> > 
> > Just a thought; I haven't looked at the new packages in detail.
> 
> I certainly wouldn't recommend releasing sarge with a version of
> PostgreSQL that was a year out of date.  It's bad enough that woody
> still has 7.2 in it.
> 
> Once 7.4 is in sid, packages that depend on postgresql should ideally be
> rebuilt.

So that *will* be a headache. Oh well, at least we know about it.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Some observations regardig the progress towards Debian 3.1

[Steve Langasek]

On Tue, Nov 18, 2003 at 09:57:41AM +, Colin Watson wrote:

> ... which will happen in a couple of days. However, evolution currently
> depends on three "trouble spots" in addition to the guts of GNOME 2.4:

>   * krb4 - has a complicated dependency graph involving heimdal and
> postgresql, but with any luck this should disappear once perl is
> ready.

It will, with a little nudge.  I don't know about the other two below,
though, so if someone wants to look into these, it wouldn't hurt.

>   * pilot-link - needs perl, but also its soname has changed between
> testing and unstable so it'll doubtless need more attention.

>   * mozilla - almost there but hasn't built on m68k and mipsel,
> apparently due to various dependency problems. Could benefit from
> being retried.

> Those interested in evolution would do well to investigate those
> problems.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Tabs v.s. spaces (was Re: Programming first steps.)

[Chad Walstrom]

On Mon, Nov 17, 2003 at 06:02:40PM -0800, Tom wrote:
> If whitespace mistakes are always caught at compile-time, then I
> probably wouldn't care about them either.  So I'm not bashing python;
> having never used it: I'm bashing languages where syntatic mistakes
> are not caught at compile-time.  I have no idea if Python is in that
> category or not.

Python does catch inconsistent indenting at compile time.  If you want
to catch mixed tabs/spaces for block indenting, run python with -tt.  As
Stephen clarified earlier, Python uses significant indentation, not
significant whitespace.  Variables and objects are not defined by
whitespace, the nested scope of logical blocks are.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpEOupM14RAx.pgp
Description: PGP signature

Re: Example of really nasty DD behavior

[Duck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> I think you are placing too much emphasis on the ITP and the WNPP
> system. I think it has a useful place in avoiding (some) duplicate work,
> searching for new owners for packagers etc, but don't expect every
> transaction to go through that system.

I really think this is a good tool and i still feel that having gathered all
important imformation about packages was a wise idea, even if you discuss and
coordinate using a mailing-list. Looking for problems in a package takes few
minutes using BTS/PTS/... , whether in mailing-lists it can take hours or days.

> Similarly I just gave away a couple of my packages to someone else. No O
> or RFA bugs needed. I suppose if there were other people keen for those
> packages they missed out :-| but they'd never contacted me.

In this case, the package still continues to be maintained, so there is no 
problem,
so no bug to fill in. Giving an equal chance to possible new maintainers is 
another
suject, out of scope.

> Sometimes it is necessary to work with upstream on the build system,
> bugs etc. Sometimes everything just works though and you can build the
> whole package without any discussion at all. There's no hard and fast
> rules.

Indeed it is not compulsory. I just wanted to highlight it is really important, 
even
if not needed because packaging is trivial. Moreover, it s not only a problem a 
needs,
bugs, build issues, ... it is, from my point of view, also a question of 
respect and
courtesy.
Sorry for being so idealist...

Duck



P.S. :
Notice i am still signing as "Duck" and not "Marc DequÃnes", because it the 
way most
people know me and call me in real life. Many probably do not remember my real 
name, so
using my nickname is in fact far less anonymous.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/ujV5sczZcpAmcIYRApjTAJ0YkHZZCQK3pPcg2OJv+FFAd4NhBwCdGI9T
kr7bl6cIzXxfusQt3PY9N6I=
=zqjo
-END PGP SIGNATURE-

招考千里马公告 bbs.51cy.net发送

[无忧财源]

本站出售★庄家★的内部资料，请来财源超市选购。
http://cs.51cy.net



招考千里马公告

　　经动物委组织部、动物物事厅同意和最高相马院批准，动物速跑队为了与世界惯例接轨，终于西边的太
阳出来了，强忍悲痛一改以往数十年一贯制地由上级任命蜗牛和乌龟做队长和副队长的状况，决定公开招考
录用高素质的带队千里马。现将有关招考千里马的各事项公告如下：
　　一、招考对象

　　动物界科级以上工作动物；
　　动物界从事过赛跑或竞走的中级以上职称的工作动物；
　　动物界在运输业执业十年以上的工作动物。
　　以上动物必须是具有四足且姓马的身份。

　　特别说明：

　　（1）所有师范类和卫生类的动物不准报考。原因可能是上级领导讨厌这类动物，也可能这是国家的高度
机密。反正不要问，问了也不会有高级动物答你这SB动物。

　　（2）所有植物，所有的虎、豹、狮以及万里驴、万里骡，还有十二级狂风和耕田种地的农民均不具备马
的身份，均不属于招考的对象！如有誓死要报名者，请到阴曹地府司咨询，由牛头马面负责给予下辈子的答
复。

　　二、招考录用名额和条件

　　拟招考录用千里马2匹。其中从事队长工作的1匹（须在马类专业本科毕业后取得赛马学或床上跑马学硕
士以上学位；或者马类专业本科毕业并被市级以上相马院评为先进种马的，公性）；从事副队长工作的1匹（
须在四足类专业营养饲料学本科毕业从事饮食工作1年以上，并取得过动物跑走级营养饲料调研成果或撰写有
国家级性交易学论文的；或者在四足类专业表演艺术学本科毕业从事狂欢表演色情艺术工作3年以上，并姿色
超群的，母性，未婚处女马）。

　　年龄上,奉行“越年轻越好”的真理。实行“上要封顶，下不封底”的政策。公性35周岁以下，母性28周
岁以下。

　　三、报名时间、地点及要求

　　报名时间：猴年马月猪日黑夜里
　　报名地点：所有领导的家中或别墅中
　　报名要求：报考马须在规定时间内由本马或委托其它长得漂亮的动物MM报名，不得以电传、信函报名。

　　四、考试科目、时间和地点

　　爷年爸月子日孙时考《动物界内界际时事政治》。
　　奶年妈月儿日孙时考《老虎为何要反恐论》和张二江之《下级学》。
　　地点在动物园狐假虎威山顶。

　　五、录用

　　经笔试、面试、组织考核以及体检合格马，择优拟定录用名单，在内部单位阴暗偏僻的角落公示30天，
然后报动物委组织部暗箱操作审批，并依照有关物事程序正式任命千里马。

　　咨询电话：８４６５２７（打死也无人接）
　　联系动物：马屁娟　吴志识　贾伯乐

　动物速跑队政治部
　　Ｘ年Ｘ月Ｘ日




本站出售★庄家★的内部资料，请来财源超市选购。
http://cs.51cy.net

Re: Tabs v.s. spaces

[Scott James Remnant]

On Tue, 2003-11-18 at 01:46, Isaac To wrote:

> > "Tom" == Tom  <[EMAIL PROTECTED]> writes:
> 
> Tom> Significant whitespace?  Shudder, that brings back crusty old
> Tom> memories of Fortran.  I have great fondness for fortran because of
> Tom> the wonderful mathematical algorithms in LinPack, but I have no
> Tom> fondness for significant whitespace.
> 
> Please actually try to code something in Python before commenting on its use
> of spaces.  It is unlike the times of Fortran: in Fortran spaces are used to
> make programs easy to read by machines; in Python spaces are used to make
> programs easy to read by human.
> 
You've never had to combine 'patch' and Python programs have you?  After
receiving a few created by people with different indent bigotries you
quickly realise why significant whitespace is a fundamentally bad idea.

I've had to go and ask someone where his new block was supposed to be
indent-wise before because he used X-space tabs and only provided a
single tab at the start.  (And no, it wasn't in the obvious place.)

(And this is ignoring the person who sent a patch made with -l that
changed the indent level of a number of blocks.)

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



signature.asc
Description: This is a digitally signed message part

Re: Some observations regardig the progress towards Debian 3.1

[Robert Lemmen]

On Tue, Nov 18, 2003 at 01:43:08PM +, Colin Watson wrote:
> I think you're missing the point: package name changes due to soname
> changes often cause delays to testing, and therefore it's *beneficial*
> that there's potentially an easy way to hold them out of unstable at the
> moment.

right, i confused it with the no-imminent-release situation where the
manual ftp-master accept causes delays which in the case of soname
changes don't look very necessary to me. sorry for the confusion.

anyway, during non-freeze times it might be a good idea to accept
libraries with changed sonames automatically.

cu  robert

-- 
Robert Lemmen http://www.semistable.com


pgpCfXD1mGBJS.pgp
Description: PGP signature

Re: Tabs v.s. spaces

[H. S. Teoh]

On Tue, Nov 18, 2003 at 11:45:52AM +0800, Cameron Patrick wrote:
> On Mon, Nov 17, 2003 at 08:56:49PM -0500, H. S. Teoh wrote:
> 
> | Nevertheless, I find 8-space indentation too wasteful, 4-space
> | indentation too cumbersome to type, and 1-space indentation
> | unreadable.
> 
> Your editor should do that for you! :-)

If I can only find an editor that suits my taste... vi is Very Irritating,
and emacs is an Extremely Massive And Cumbersome System.

> e.g. set softtabstop=4 in vim will allow you to have 4-character
> indentation by pressing the tab key and outdentation by pressing
> backspace, but the file will contain spaces instead of tabs.  I would
> be surprised if other editors did not have a similar feature. 

Keep in mind that I can't stand vi and hate emacs, so I'm still using a
very old (non-free!) editor. It's not exactly the greatest, but it
irritates me the least.

> Personally I prefer 8-space indentation, though.
[snip]

I find that it is too restrictive, given that I insist on a 79-column
limit on code lines. With 8-space indentation, you run out of nesting
levels really fast, much faster than is possible to do non-trivial coding
in.


T

-- 
The right half of the brain controls the left half of the body. This means
that only left-handed people are in their right mind. -- Manoj Srivastava

Re: Tabs v.s. spaces

[H. S. Teoh]

On Tue, Nov 18, 2003 at 11:34:14PM +1100, Hamish Moffatt wrote:
> On Mon, Nov 17, 2003 at 07:57:46PM -0800, Joshua Kwan wrote:
> > Hear, hear. Yes, 8-space indentation is a matter of pressing the Tab
> > key, but it's a bit too big.. I've always stuck with two spaces.
> 
> So set your tabstop (and shiftwidth) in vi to 4, and you'll have four
> character indents. Or 2.

If I can convince myself vi is usable beyond editing simple config files.
;-)

> And if you save the tabs in the files (ie don't use expandtab), then
> whoever else opens your code will get their preference and everybody is
> happy. 

I wouldn't be so quick to say that... for one, I line up my comments with
tabs (8-space tabs), they would be misaligned with a different tab stop,
and would look rather atrocious.

> > Note that if you want to quickly format your code with tab-character
> > indentation (== 8 spaces), I like astyle -t . Works like a charm.
> > I've only tried it with C/C++ code so I don't know whether it works for
> > other kinds of files.
> 
> VIM can do autoindenting for some languages too. Works OK with Perl,
> and C, and badly with Tcl (but doesn't everything?).
[snip]

Generally, I am skeptical of autoindenting tools. I usually do it by hand.
(I don't buy the write-first-indent-later coding philosophy.) Also, my
indenting style is complex enough to elude tools like 'indent'. I firmly
believe in doing something right, right from the start. If something isn't
properly indented when first written, it's broken and must be rewritten.


T

-- 
You've gotten under my skin. That you got there speaks ill of me. That you
like it there speaks ill of you. -- Speek, K5

Re: Some observations regardig the progress towards Debian 3.1

[Thomas -Balu- Walter]

On Mon, Nov 17, 2003 at 11:19:24AM +0100, Norbert Tretkowski wrote:
> Unfortunately Adrian didn't wrote why he thinks backports aren't
> usable for production systems. The only real problem with backports I
> see is that there are no guaranted security updates.
> 
> This could be a reason for someone to not using backports. For me it's
> not, I'm using my own backports.

I'd like to use my own backports, but I don't really think I have the
time to get into all the packages I'd like to have backported.

A big question here is - why are the so many backports? Is this a
sign how "outdated" stable is? I'm having Woody on my servers and I'm
loving the stableness and security of it. However. I'd also like to have
an up to date system on my desktop. For this I'd have to use unstable
which breaks now and then (and does not get security support) or search
for backports of all software I'd like to enjoy - a modern gui, better
hardware support (desktops are often more up to date in this point).

For now I have to fiddle around, creating bootdisks with newer kernels,
search backports, ...  and since I don't have the time to do so I've
just installed SuSE once again.[1]

Balu
[1] on this machine, but might switch to knoppix though ;)

Re: Tabs v.s. spaces

[Glenn Maynard]

On Tue, Nov 18, 2003 at 11:00:18AM -0500, H. S. Teoh wrote:
> > VIM can do autoindenting for some languages too. Works OK with Perl,
> > and C, and badly with Tcl (but doesn't everything?).
> [snip]
> 
> Generally, I am skeptical of autoindenting tools. I usually do it by hand.
> (I don't buy the write-first-indent-later coding philosophy.) Also, my
> indenting style is complex enough to elude tools like 'indent'. I firmly
> believe in doing something right, right from the start. If something isn't
> properly indented when first written, it's broken and must be rewritten.

Huh?  Autoindenting happens while you're coding, not later.  That's the
whole point.

(Of course, Vim can do it after, too, but that makes it a mini-indent(1),
not autoindent.)

-- 
Glenn Maynard

Re: Some observations regardig the progress towards Debian 3.1

[John Goerzen]

On Sat, Nov 15, 2003 at 05:35:19PM +, Andrew Suffield wrote:
> On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> > - Debian 3.0 doesn't support much of the hardware curently available -
> >   the old 2.4.18 kernel on the boot floppies doesn't even boot on many
> >   new computers (some Promise IDE chipsets require a more recent 2.4 
>^^^
> >   kernel), and much hardware from nearly all currently abailable 
> ^^
> 
> This is false. All the promise IDE chipsets are adequetely supported
> by 2.4.18, albeit not in anything above ata-33 mode. The only problem
> is that autodetection fails for some of the newer ones, and you have
> to manually specify the controller ports.

That's false.  They're not even adequately supported in 2.4.22, but they're
better.

I still can't use my Promise drive in DMA mode (must use -d 0 with hdparm)
because heavy write activity causes the kernel to hang.

Re: Tabs v.s. spaces

[H. S. Teoh]

On Tue, Nov 18, 2003 at 11:13:46AM -0500, Glenn Maynard wrote:
> On Tue, Nov 18, 2003 at 11:00:18AM -0500, H. S. Teoh wrote:
> > > VIM can do autoindenting for some languages too. Works OK with Perl,
> > > and C, and badly with Tcl (but doesn't everything?).
> > [snip]
> > 
> > Generally, I am skeptical of autoindenting tools. I usually do it by hand.
> > (I don't buy the write-first-indent-later coding philosophy.) Also, my
> > indenting style is complex enough to elude tools like 'indent'. I firmly
> > believe in doing something right, right from the start. If something isn't
> > properly indented when first written, it's broken and must be rewritten.
> 
> Huh?  Autoindenting happens while you're coding, not later.  That's the
> whole point.
[snip]

Oh, you meant autoindenting as you type... I thought you were referring to
indenting tools. As long as it's unintrusive, I'm OK with that.
Unintrusive as in, not anywhere near the atrociousness of MS Word, for
example.


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater
learning.

Re: keysigning at SCALE 2X?

[Matt Zimmerman]

On Tue, Nov 18, 2003 at 01:14:26AM -0800, Eric Wong wrote:

> I'll be attending SCALE 2X  in Los
> Angeles and I'm wondering if I could meet some Debian developers to get
> my GPG key signed and get myself going along the New Maintainer process.

Southern California Debian <[EMAIL PROTECTED]>

-- 
 - mdz

Re: keysigning at SCALE 2X?

[Richard A. Hecker]

Eric Wong wrote:

> Hello,
>
> I'll be attending SCALE 2X  in Los
> Angeles and I'm wondering if I could meet some Debian developers to get
> my GPG key signed and get myself going along the New Maintainer process.
>

We will have a booth there.  There should be plenty of opportunity to exchange
key
information.

Richard

Re: Tabs v.s. spaces

[Isaac To]

> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:

Scott> You've never had to combine 'patch' and Python programs have you?
Scott> After receiving a few created by people with different indent
Scott> bigotries you quickly realise why significant whitespace is a
Scott> fundamentally bad idea.

If somebody send you Python code patch that does not use *your* indentation
style that somebody has some serious problem.  It's just like sending you a
patch with all the variable names changed to ones that he prefers.  I don't
see why this should be a show stopper.  But yes, there are other problems
introduced by whitespace as block structure.  E.g., it is more difficult to
cut some code in one function and paste it into another.  So for best
results one really have to use an editor (and perhaps other tools) that
knows about such significant whitespaces.

Regards,
Isaac.

Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Anthony Towns]

On Tue, Nov 18, 2003 at 12:54:17AM -0500, Nathanael Nerode wrote:
> Matt Zimmerman wrote:
> >Perhaps the maintainer hasn't requested its removal?  I don't see a bug
> >report open against ftp.debian.org.
> I seem to remember him requesting it.  Further, you'll see on the RC bugs
> list that it's listed as REMOVE (and has been for a while).  Perhaps the bug 
> report was already closed (because the archive maintenance scripts are 
> already trying to remove it)?

The RC bug list REMOVE tags mean "remove from testing (not unstable)".

If a bug's filed against ftp.d.o, there's no "trying" -- it'll be removed,
and any packages that depend on it will be left broken.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda


pgpeE6iXVrLqT.pgp
Description: PGP signature

Re: Some observations regardig the progress towards Debian 3.1

[Jamin W. Collins]

On Tue, Nov 18, 2003 at 05:08:40PM +0100, Thomas -Balu- Walter wrote:
> 
> For now I have to fiddle around, creating bootdisks with newer kernels,

Maybe I've just been very lucky, but I've yet to need to create a custom
boot disk to install any of my various systems.  I wouldn't consider
most of them to be extremely old, some of them were bought within the
last 6 months.  In all cases using the 2.4 kernel on the first woody cd
has worked fine for installation.

-- 
Jamin W. Collins

This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar

Re: Tabs v.s. spaces

[Colin Watson]

I swore that I wasn't going to get into the latest style war, but ...

On Tue, Nov 18, 2003 at 10:55:38AM -0500, H. S. Teoh wrote:
> On Tue, Nov 18, 2003 at 11:45:52AM +0800, Cameron Patrick wrote:
> > Personally I prefer 8-space indentation, though.
> 
> I find that it is too restrictive, given that I insist on a 79-column
> limit on code lines. With 8-space indentation, you run out of nesting
> levels really fast, much faster than is possible to do non-trivial
> coding in.

Does that make the kernel trivial? Just wondering. :)

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Tabs v.s. spaces (was Re: Programming first steps.)

[Steve Lamb]

Julian Mehnle wrote:
I call that readable, but I guess somebody won't. ;-)
Actually it is quite readable and sensible in that it breaks down the 
regex into parts that a human can read.  Oh, and the equivolant would be legal 
in Python.  Which was kind of my point on asking H.S. the two questions I did 
in the order I did.  I doubt he's touched Python so is unqualified to discuss 
what is and is not possible with its use of whitespace and was hoping to get 
an example from him and show that it is perfectly legal in Python.

--
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpcN9opEtXIL.pgp
Description: PGP signature

Re: emacs20 obsolete? (Re: How to find all reverse depends of a package?)

[Jérôme Marant]

Quoting Anthony Towns :


> The RC bug list REMOVE tags mean "remove from testing (not unstable)".
> 
> If a bug's filed against ftp.d.o, there's no "trying" -- it'll be removed,
> and any packages that depend on it will be left broken.

BTW, in any case, If we want to stop supporting emacs20, do we need
to change dependencies of every package alternatively depending on emacs20
(like emacs20 | emacs21 etc)?


-- 
Jérôme Marant

Re: Tabs v.s. spaces

[Florent Rougon]

"H. S. Teoh" <[EMAIL PROTECTED]> wrote:

> Oh, you meant autoindenting as you type... I thought you were referring to
> indenting tools. As long as it's unintrusive, I'm OK with that.
> Unintrusive as in, not anywhere near the atrociousness of MS Word, for
> example.

Um, wasn't this thread about programming? A programmer should use a
programmer's editor. A programmer's editor should be able to indent the
code for the language used while it is being typed.

If you are not able to use a programmer's editor, I fail to see how you
can even try to argue about the usefulness of Python's whitespace
handling.

-- 
Florent

Re: Tabs v.s. spaces

[Florent Rougon]

Scott James Remnant <[EMAIL PROTECTED]> wrote:

> You've never had to combine 'patch' and Python programs have you?  After
> receiving a few created by people with different indent bigotries you
> quickly realise why significant whitespace is a fundamentally bad idea.
>
> I've had to go and ask someone where his new block was supposed to be
> indent-wise before because he used X-space tabs and only provided a
> single tab at the start.  (And no, it wasn't in the obvious place.)

That is one reason why it is wise to stay at least 100 meters away from
tabs whenever it is possible.

-- 
Florent

Re: MIPS port backlog, autobuilder machines and some arrogance

[Josip Rodin]

On Tue, Nov 18, 2003 at 03:32:20PM +1000, Anthony Towns wrote:
> > > > It also means that, if it were easy to add some redundancy,
> > > > it would already have happened. Which in turn means that it's hard.
> > > Again, read what I wrote, not what you imagine I wrote. Difficult isn't
> > > the same as impossible, and hard isn't the same as too hard.
> > So, basically what you're saying that it's hard, and that nobody should be
> > allowed to comment on it because the already delegated people are, what?
> > Perfect? Self-sufficient? Incapable of changing their ways?
> 
> No, I'm saying that nobody who's incapable of assisting with solving the
> problem should be expounding on it. You're welcome to do whatever you
> want on your own time, of course, but if you're going to start accusing
> the DPL, or the buildd maintainers, or anyone else of not doing their
> job on these lists, then you'd better have made absolutely sure you've
> got the knowledge and the experience to back that sort of claim up,
> and that you're able to demonstrate that at all times.

Note that I'm not talking about the buildd issue, but only about the
[EMAIL PROTECTED] thing. I believed that my quoting in the original
indicated that; if not, I'm sorry.

And to answer, yes, I believe I can back up what I said on the topic.
Perhaps there are some intricate details in the system of how donations
are processed, but I rather doubt that it isn't something that a developer
like myself could handle, provided one is diligent enough. (Please don't
interpret this as disrespecting the HD post or Mako -- I certainly don't
indend that.)

> > > BTW, I can't see where I did anything of the sort. I said your post
> > > contributed nothing to the discussion, was unhelpful and distracting and
> > > wrong, and, as such, said that you hadn't contributed anything other
> > > than trite cliches.
> > I don't know about you, but I take it as an insult when someone accuses me
> > of not knowing anything about something[1] and tells me to shut up.
> 
> Again, I never accused you of not knowing anything about this. I said
> that your post didn't demonstrate any knowledge -- "more redundancy is
> good" isn't any more helpful than "too many cooks spoil the broth", or
> "a bird in the hand is worth two in the bush".
> 
> All those things are true, and can be a useful starting point for
> thinking about problems that show up; but they're a starting point only,
> and mindlessly repeating them at people who are already well aware of
> the cliches isn't helpful.

I'm not mindlessly repeating it, nor am I convinced that the people are
already well aware of them (most probably aware of the principle, but
obviously not in the specific case). I don't remember but one instance when
someone said that the hardware donations delegate was unavailable, and the
issue wasn't discussed further or in the proper forum -- and even that
memory is vague so it might have been even less noticeable. To repeat what
I said before, I think that the best, and probably the most logical,
explanation is that the DPL and the delegate simply haven't remembered or
had the chance to consider expanding the hardware donations team -- my
"expounding" on the "cliche" was supposed to be a simple, clear reminder.

> > And there you again. You seem rather inclined to judge other people's
> > competence based on, well, I've no idea on what do you base these claims on.
> 
> Well, an obvious guess would be the posts you've just made. You know,
> the ones I was criticising as being trite and uninformative, while
> pretending at being of profound importance?

Stop accusing me of reading too much into what you wrote when you seem to
have found a pretension at being of profound importance in a comment that
I explicitely marked as obvious and unassuming.

-- 
 2. That which causes joy or happiness.

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Mon, Nov 17, 2003 at 11:28:41PM -0500, Matt Zimmerman wrote:
> > > So instead, we have a system where people take individual (or small
> > > group) responsibility for a particular piece of software, to take care
> > > of it and fix its bugs.  This way, we distribute the effort over a large
> > > number of people.
> > 
> > The problem is, this often chaotic development system doesn't scale to
> > over 1200 developers (including many MIA developers).
> 
> I think the only sticking point is determining when someone is actually MIA.
> Once it is established that they are MIA, NMUs and adoptions are relatively
> painless.

Agreed.

> > > If Red Hat ships more of the software the user needs, maybe it is a better
> > > choice.  Choice is one of the great advantages of free software, after 
> > > all.
> > 
> > The question is perhaps a different one:
> >   What is the goal of Debian?
> 
> It meets my OS and application needs, and that is all that I ask of it.
> 
> > This is not about "free software" or such goals, it's about what
> > audiences and niches does Debian target at.
> 
> My "target audience" is myself and those around me (employers, co-workers,
> family, friends, etc.), and, by way of reciprocity, other Debian developers
> and their users.

This gives you over thousand different goals.

E.g. some developers package the latest and best (and buggiest) software
while others work one year until they consider a new upstream release to
be ready for unstable. None of these two is bad in itself, but there's
currently a strange mixture of slightly outdated super-stable and more
buggy latest&greatest packages in unstable. It would IMHO be more
productive, if far from the next freeze the latest software of all
packages is in unstable, and a few months before the next freeze no big
changes happen to all packages.

> > I'm not saying this would be immoral or something like that, but e.g. a
> > major release without Evolution [2] (currently ages away from reentering
> > testing) might make Debian stable unusable for many users - and you should
> > be aware of such consequences.
> 
> I don't use evolution, so I really haven't concerned myself with this at
> all.  Some people that I work with do use it, though, so if there is
> something bite-sized that I can do to help it along, I would probably do it.
> However, evolution has no RC bugs, and is only waiting on dependencies.
>...

Evolution is one example, not the only ne and perhaps not the best one, 
but there are many other packages that are important for this or that   
user.

> > > I think this is more or less what was proposed in the last release 
> > > timeline,
> > > where major changes in certain packages were frozen at various dates.
> > 
> > There are some problems with the release timeline:
> > 
> > Debian stable is too outdated, it doesn't even reasonable support most
> > available new hardware. At least one release [3] every year would be
> > required.
> 
> You keep saying this, but in my experience it simply isn't true.  I
> regularly install woody on brand-new Intel systems.  Most of the time, the
> woody kernels suffice, and when I need some obscure bug fix from a later
> kernel, I simply upgrade the kernel rather than dismissing the entire
> release as "too outdated".

This might work on pure servers, but how do you manage to run XFree86
4.1.0 on brand-new graphics cards (e.g. integrated graphics of
brand-new Intel systems) in non-Vesa resolutions?

>...
> I'm typing this from a woody laptop, because it's the only Debian system I
> have available at the time.  It has a usable graphical environment, with
> decent web browsers, development tools and networking facilities.  It gets
> the job done.  I simply don't need the latest GNOME or KDE goodies in order
> to be productive.

Most likely this laptop is two or three years old?

Debian 3.0 was mostly current at the time when it was released, but much 
support for current hardware is missing in Debian 3.0 .

> > What are the unexpected delays in the dvelopment of debian-installer?
> 
> I don't think that I implied that there was any particular reason for the
> delays; the d-i folks would certainly know better.  My impression was that
> it simply isn't finished yet.

Why did debian-installer miss the dates in the latest release timeline 
by so many months?

>  - mdz

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Tabs v.s. spaces

[Glenn Maynard]

On Tue, Nov 18, 2003 at 06:04:54PM +0100, Florent Rougon wrote:
> If you are not able to use a programmer's editor, I fail to see how you
> can even try to argue about the usefulness of Python's whitespace
> handling.

Yay!  A whitespace flamewar!

-- 
Glenn Maynard

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Tue, Nov 18, 2003 at 09:57:41AM +, Colin Watson wrote:
> On Mon, Nov 17, 2003 at 11:28:41PM -0500, Matt Zimmerman wrote:
> > On Tue, Nov 18, 2003 at 02:14:49AM +0100, Adrian Bunk wrote:
> > > I'm not saying this would be immoral or something like that, but e.g. a
> > > major release without Evolution [2] (currently ages away from reentering
> > > testing) might make Debian stable unusable for many users - and you should
> > > be aware of such consequences.
> > 
> > I don't use evolution, so I really haven't concerned myself with this at
> > all.  Some people that I work with do use it, though, so if there is
> > something bite-sized that I can do to help it along, I would probably do it.
> > However, evolution has no RC bugs, and is only waiting on dependencies.
> > It looks like GNOME 2 in general needs either more time or more hinting.
> 
> ... which will happen in a couple of days. However, evolution currently
> depends on three "trouble spots" in addition to the guts of GNOME 2.4:
> 
>   * krb4 - has a complicated dependency graph involving heimdal and
> postgresql, but with any luck this should disappear once perl is
> ready.
> 
>   * pilot-link - needs perl, but also its soname has changed between
> testing and unstable so it'll doubtless need more attention.

I'm counting 8 other source packages that need to be ready at the same
time to be hinted together with pilot-link.

>   * mozilla - almost there but hasn't built on m68k and mipsel,
> apparently due to various dependency problems. Could benefit from
> being retried.
>...

Besides this, Mozilla with at about two dozen other packages depending 
on a specific version of Mozilla will never enter testing without a 
massive hinting (thats one of the reasons why testing still contains 
Mozilla 1.0.0).


additionally:

  * RC bug in gtkhtml3.0

  * RC bug in gnome-pilot


> Cheers,
> Colin Watson  [EMAIL PROTECTED]

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: keysigning at SCALE 2X?

[Don Armstrong]

On Tue, 18 Nov 2003, Matt Zimmerman wrote:
> On Tue, Nov 18, 2003 at 01:14:26AM -0800, Eric Wong wrote:
>> I'll be attending SCALE 2X  in Los
>> Angeles and I'm wondering if I could meet some Debian developers to
>> get my GPG key signed and get myself going along the New Maintainer
>> process.
> 
> Southern California Debian <[EMAIL PROTECTED]>

Blars Blarson (DD), Matt Kraai (DD), and myself (NM queue) will be
there (in the Debian booth.) I know I will have fingerprints and stuff
with me, I assume Blars and Matt will as well.


Don Armstrong

-- 
If you wish to strive for peace of soul, then believe; if you wish to
be a devotee of truth, then inquire.
 -- Friedrich Nietzsche

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


signature.asc
Description: Digital signature

Re: SANE compiling with patch for HP 4470c

[Julien BLACHE]

Thomas Luft <[EMAIL PROTECTED]> wrote:

Hi,

[sane-backends failing to build, SANE maintainer hat on.]

> make[2]: *** [v4l.lo] Fehler 1
> make[2]: Leaving directory `/home/cpblu01/src/sane-backends-1.0.12/backend'
> make[1]: *** [all-recursive] Fehler 1
> make[1]: Leaving directory `/home/cpblu01/src/sane-backends-1.0.12'
> make: *** [build-stamp] Fehler 2
> debuild: fatal error at line 554:
> dpkg-buildpackage failed!
>
> I tried to compile the sources without the patch from Johannes but the
> error is still the same.

The v4l backend is broken due to the new linux-kernel-headers package
shipping 2.6 kernel headers.

I discovered the problem 2 days ago, and fixed it upstream.

SANE 1.0.13 will be released this week-end, so I won't fix the 1.0.12
packages currently in unstable. Expect 1.0.13 to hit unstable this
week-end or early next week.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 

Bug#221489: general: mouse not working properly after yesterday testing upgrade

[Paolo Benvenuto]

Package: general
Severity: normal

After yesterday (Nov 17 2003) upgrade of my box, running a testing/unstable
debian, my mouse A4Tech 3d MiniMouse, model MSW-5, doesn't work properly:

- in gnome, the left button pops up contestual menus
- in console mode, gpm has problems: making a selection doesnt' define
  the limits of the selection correctly
  
A glibc problem?

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux misiongenovesa 2.4.21 #2 mer giu 25 17:52:37 AST 2003 i686
Locale: LANG=it_IT, LC_CTYPE=it_IT

Re: Tabs v.s. spaces

[H. S. Teoh]

On Tue, Nov 18, 2003 at 12:26:37PM -0500, Glenn Maynard wrote:
> On Tue, Nov 18, 2003 at 06:04:54PM +0100, Florent Rougon wrote:
> > If you are not able to use a programmer's editor, I fail to see how you
> > can even try to argue about the usefulness of Python's whitespace
> > handling.
> 
> Yay!  A whitespace flamewar!
[snip]

Yeah, 'whitespace' about sums up the value of it. Except to Python
programmers, of course. :-P :-P


T

-- 
Unix was not designed to stop people from doing stupid things, because that
would also stop them from doing clever things. -- Doug Gwyn

Re: Tabs v.s. spaces

[H. S. Teoh]

On Tue, Nov 18, 2003 at 04:41:34PM +, Colin Watson wrote:
> I swore that I wasn't going to get into the latest style war, but ...
> 
> On Tue, Nov 18, 2003 at 10:55:38AM -0500, H. S. Teoh wrote:
> > On Tue, Nov 18, 2003 at 11:45:52AM +0800, Cameron Patrick wrote:
> > > Personally I prefer 8-space indentation, though.
> > 
> > I find that it is too restrictive, given that I insist on a 79-column
> > limit on code lines. With 8-space indentation, you run out of nesting
> > levels really fast, much faster than is possible to do non-trivial
> > coding in.
> 
> Does that make the kernel trivial? Just wondering. :)
[snip]

 Yes. 

;-)


T

-- 
It is the quality rather than the quantity that matters. -- Lucius Annaeus
Seneca

Re: Some observations regardig the progress towards Debian 3.1

[Colin Watson]

On Tue, Nov 18, 2003 at 06:15:41PM +0100, Adrian Bunk wrote:
> On Tue, Nov 18, 2003 at 09:57:41AM +, Colin Watson wrote:
> >   * mozilla - almost there but hasn't built on m68k and mipsel,
> > apparently due to various dependency problems. Could benefit from
> > being retried.
> 
> Besides this, Mozilla with at about two dozen other packages depending 
> on a specific version of Mozilla will never enter testing without a 
> massive hinting (thats one of the reasons why testing still contains 
> Mozilla 1.0.0).

One small reason, but most of the reason is that it's had RC bugs and
been out of date on random architectures for ages.

Anyway, I cannot see a serious tenable argument that we're better off
keeping mozilla 1.0.0 just because a couple of mozilla-locale-foo
packages aren't ready for 1.5 yet [1], so we'll just remove from testing
any of those that aren't ready when mozilla finally makes it in its own
right. They'll have a chance to make it back in. Fortunately, half of
them appear to be OK at the moment.

[1] As I make it, the following packages in testing depend on a specific
version of mozilla in such a way as to cause problems when upgrading
mozilla. If you can back up your "about two dozen" with an expanded
list, please do so.

  mozilla-locale-auto
  mozilla-locale-ca
  mozilla-locale-de-at
  mozilla-locale-fr
  mozilla-locale-gl-es
  mozilla-locale-ja
  mozilla-locale-zh-cn
  mozilla-locale-zh-tw

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Bug#221492: ITP: smile -- [Biology] Find statistically significant patterns in sequences

[Steffen Moeller]

Package: wnpp
Severity: wishlist


* Package name: smile
  Version : 1.46
  Upstream Author : Laurent Marsan <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : none
  Description : [Biology] Find statistically significant patterns in 
sequences

 SMILE inferences structured motifs from multiple DNA or protein
 sequences.  The extraction is made according to multiple
 criteria given by the user. Since version 1.4, SMILE accepts extractions
 on any kind of sequences written on any alphabet, searching for motifs
 on any alphabet that may even be degenerated.

Re: Tabs v.s. spaces

[Steve Lamb]

Isaac To wrote:
E.g., it is more difficult to
cut some code in one function and paste it into another.  So for best
results one really have to use an editor (and perhaps other tools) that
knows about such significant whitespaces.
Not really if one is wanting to maintain proper indention in both cases 
all one needs is an editor which is able to add or subtract indention levels. 
 I certainly have had no problems in my Python coding on moving code around 
that are at different levels.  Mark the block, move it, reindent it a level or 
two and be done with it.  *shrug*

--
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpPjq3sDEowe.pgp
Description: PGP signature

Re: Some observations regardig the progress towards Debian 3.1

[Matt Zimmerman]

On Tue, Nov 18, 2003 at 06:06:08PM +0100, Adrian Bunk wrote:

> This might work on pure servers, but how do you manage to run XFree86
> 4.1.0 on brand-new graphics cards (e.g. integrated graphics of brand-new
> Intel systems) in non-Vesa resolutions?

I don't, because I don't buy motherboards with on-board video.

> Most likely this laptop is two or three years old?

Even older, I'd think.  I've installed woody on newer systems, laptop or no.
To claim that it doesn't support "most" available new hardware just isn't
accurate.

> > I don't think that I implied that there was any particular reason for the
> > delays; the d-i folks would certainly know better.  My impression was that
> > it simply isn't finished yet.
> 
> Why did debian-installer miss the dates in the latest release timeline 
> by so many months?

Because those dates were made up out of thin air?

-- 
 - mdz

Re: Tabs v.s. spaces (was Re: Programming first steps.)

[Darren Salt]

I demand that Steve Lamb may or may not have written...

[snip]
> if foo
>  bar
> else
>  baz

  fi



-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   Let's keep the pound sterling

Experience is what you get when you don't get what you want.

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Tue, Nov 18, 2003 at 05:47:44PM +0100, Yann Dirson wrote:
> Joey wrote:
> >Packages in unstable have dependencies in unstable which may not be
> >met in testing, hence they cannot simply be included in testing.
> >Unfortunately we need to take care of this.
> 
> I've come up at least once with a suggestion on how we could avoid this
> problem and increase the throughput of unstable->testing.  However I got 
> virtually no feedback on this.
> 
> The original description is at
> http://lists.debian.org/debian-project/2003/debian-project-200305/msg00082.html
> 
> Today, I'd rather describe it as adding a "pre-testing" stage, where
> packages migration from unstable would not take generated binary deps
> into account, and candidates for migration out of unstable would be
> rebuilt against pre-testing for migration.
> 
> That would allow many packages to migrate much more quickly out of
> unstable, while still filtering out a good number of early-detected RC
> bugs.  Then the current method for migration into testing can be
> applied to pre-testing instead of unstable, and since there should be
> less RC bugs there, as well as less blocker packages (like a recent
> gcc, glibc, kde, gnome, python, ), packages
> could eventually migrate more quickly into testing.

There are some good suggestions in your proposal, e.g. you suggest to 
check whether the build dependencies are fulfilled. The lack of checking 
for build dependencies in the current testing scripts often leads to 
packages in testing you can't build inside testing.

But you have to be aware that your proposal only works for the cases 
where the programs actually compile and work with older versions of 
libraries, the big tasks like getting KDE 3, GNOME 2 or a more recent 
Mozilla into testing aren't affected by your suggestion.

There might be new problems e.g. with inter-library dpendencies for 
libraries without versioned symbols if your proposal would be 
implemented.

> There _are_ many things to think about, but it may be worth to
> investigate it, and see how we could handle the potential problems we
> can think of.
>...

There's also a different discussion that should take place:

Is testing actually worth the effort?

Testing has it's benefits, e.g. it catches build errors and dependency 
problems.

After three years of testing, it seems that some of the promises like 
having testing always in a releasable state were never fulfilled, in 
fact testing was sometimes in a worse state than unstable.

testing with its lack of security fixes, aprox. 500 RC bugs and daily 
changing packages is not usable for production systems.


> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Tabs v.s. spaces

[Steve Lamb]

H. S. Teoh wrote:
Yeah, 'whitespace' about sums up the value of it. Except to Python
programmers, of course. :-P :-P
Quite the contrary.  First off generally flames are from the uninformed. 
 Since in most cases the evils of whitespace are spouted off by those who 
have never once touched Python it is generally they who are flaming and not 
those who have actually used it.

Secondly clearly they are deriving some worth from it.  I mean you did 
post 12 messages to this thread.  More than me, in fact.

Finally I am still waiting for an answer to my two questions posed to you.
1: Have you ever used Python?
2: Provide an example of such free-style coding that you speak highly of.
--
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpZ44SgipXaq.pgp
Description: PGP signature

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Tue, Nov 18, 2003 at 06:14:29PM +, Colin Watson wrote:
>...
> [1] As I make it, the following packages in testing depend on a specific
> version of mozilla in such a way as to cause problems when upgrading
> mozilla. If you can back up your "about two dozen" with an expanded
> list, please do so.
> 
>   mozilla-locale-auto
>   mozilla-locale-ca
>   mozilla-locale-de-at
>   mozilla-locale-fr
>   mozilla-locale-gl-es
>   mozilla-locale-ja
>   mozilla-locale-zh-cn
>   mozilla-locale-zh-tw

The "about two dozen" doesn't apply to testing with it's ancient Mozilla 
and at least one package depending on a specific Mozilla version already 
removed from testing.

There are 20 packages in unstable depending on a specific version of
Mozilla:

epiphany-browser
galeon
mozilla-locale-auto
mozilla-locale-ca 
mozilla-locale-da
mozilla-locale-de-at
mozilla-locale-es-es  
mozilla-locale-eu
mozilla-locale-fr
mozilla-locale-gl-es  
mozilla-locale-it
mozilla-locale-ja
mozilla-locale-ko  
mozilla-locale-no-nb
mozilla-locale-pl
mozilla-locale-ptbr  
mozilla-locale-sl
mozilla-locale-zh-cn
mozilla-locale-zh-hk  
mozilla-locale-zh-tw

> Cheers,
> Colin Watson  [EMAIL PROTECTED]

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#221492: ITP: smile -- [Biology] Find statistically significant patterns in sequences

[Aaron M. Ucko]

Steffen Moeller <[EMAIL PROTECTED]> writes:

> * URL : http://www.example.org/
> * License : none

*cough*

>   Description : [Biology] Find statistically significant patterns in 
> sequences

This should be an uncapitalized noun phrase: perhaps something like
"tool to infer structured motifs in biological sequences"

>  SMILE inferences structured motifs from multiple DNA or protein
>  sequences.  The extraction is made according to multiple
>  criteria given by the user. Since version 1.4, SMILE accepts extractions
>  on any kind of sequences written on any alphabet, searching for motifs
>  on any alphabet that may even be degenerated.

This could also use some rephrasing: how about

SMILE infers structured motifs from multiple DNA or protein sequences
according to a user-specified set of criteria.  It handles arbitrary
sequence alphabets, which may even be degenerate.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Re: Tabs v.s. spaces

[Tom]

On Tue, Nov 18, 2003 at 11:04:48AM -0800, Steve Lamb wrote:
> H. S. Teoh wrote:
> >Yeah, 'whitespace' about sums up the value of it. Except to Python
> >programmers, of course. :-P :-P
> 
> Quite the contrary.  First off generally flames are from the 
> uninformed. Since in most cases the evils of whitespace are spouted off 
> by 
>  those who have never once touched Python it is generally they who are 
> flaming and not those who have actually used it.
> 
> Secondly clearly they are deriving some worth from it.  I mean you did 
> post 12 messages to this thread.  More than me, in fact.
> 
> Finally I am still waiting for an answer to my two questions posed to 
> you.
> 
> 1: Have you ever used Python?
> 
> 2: Provide an example of such free-style coding that you speak highly of.

I have two serious examples and one light-hearted one:

Serious #1:

*It looks like multi-line method invocations require parenthesis to be 
indented at the paren level.  Sometimes that's useful, but often I like 
to pack arguments tighter than that and indent only once on subsequent 
lines:
myreallylongmethodname(bar, bar, bar, bar, bar,
  baz, baz, baz);
myreallylongmethodname(bar, bar, bar, bar, bar,
   baz, baz, baz);

Serious #2:

Multiple statements per line in diagnostic code and error flow control.

The operant value in both these cases is some code is relatively 
unimportant to the main flow of the program and doesn't warrant gobs of 
space.  "Real" code should be indented like Python, but if everything is 
"proper", "important" code gets lost in a bunch of scaffolding.
Obiviously high equality code should be simple, but sometimes other 
values weigh slightly higher than writing perfect code, and flexibility 
is useful.


Light-hearted:

Sometimes I just feel like writing crappy multi-line, write-only code 
because it's not intended to change the world, and I want to see it all 
on the screen at once.  Many real-world tasks are like this.

No need to respond to these points, I can kind of predict the answers...


> 
> -- 
>  Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
>PGP Key: 8B6E99C5   | main connection to the switchboard of 
>souls.
> ---+-

Re: Some observations regardig the progress towards Debian 3.1

[Andreas Barth]

* Matt Zimmerman ([EMAIL PROTECTED]) [031118 19:55]:
> On Tue, Nov 18, 2003 at 06:06:08PM +0100, Adrian Bunk wrote:
> > Why did debian-installer miss the dates in the latest release timeline 
> > by so many months?

> Because those dates were made up out of thin air?

Then the obvious question is: Why are official timelines made up out
of thin air, and why are no updates of such timelines published on
d-d-a?


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

Re: Howto reconfigure alsa-modules-2.4.22-1-k6

[Otto Wyss]

> Otto Wyss dijo:
> >   dpkg-reconfigure alsa-modules-2.4.22-1-k6
> > 
> > but this doesn't show the driver list again! Okay getting dselect out,
> > purge the package and install it again. But now the list isn't shown
> > either. How do I get the driver list from this package?
> > 
> dpkg-reconfigure alsa-base
> 
>   Anyway, this message would have fitted better in debian-user
> 
First it was an oversight, sorry. But now I think the alsa packages are
more broken. After successfully using dpkg-reconfigure alsa-base I got
the following error messages:

depmod: *** Unresolved symbols in
/lib/modules/2.4.22-1-k6/alsa/snd-pdaudiocf.o
depmod: *** Unresolved symbols in
/lib/modules/2.4.22-1-k6/alsa/snd-vx-cs.o
depmod: *** Unresolved symbols in
/lib/modules/2.4.22-1-k6/alsa/snd-vxp440.o
depmod: *** Unresolved symbols in
/lib/modules/2.4.22-1-k6/alsa/snd-vxpocket.o

I get the same messages when using update-modules. My alsa configuration
looks good:

### DEBCONF MAGIC
# This file was automatically generated by alsa-base's debconf stuff

alias char-major-116 snd
alias char-major-14 soundcore

options snd major=116 cards_limit=4

alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

alias snd-card-0 snd-ice1724

alias snd-slot-0 snd-card-0
alias sound-slot-0 snd-slot-0

and lspci shows

00:0b.0 Multimedia audio controller: IC Ensemble Inc ICE1724 [Envy24HT]
(rev 01)

So what's wrong now?

O. Wyss

-- 
See "http://wxguide.sourceforge.net/"; for ideas how to design your app.

Re: Tabs v.s. spaces

[Steve Lamb]

Tom wrote:
On Tue, Nov 18, 2003 at 11:04:48AM -0800, Steve Lamb wrote:
*It looks like multi-line method invocations require parenthesis to be 
indented at the paren level.  Sometimes that's useful, but often I like 
to pack arguments tighter than that and indent only once on subsequent 
lines:
myreallylongmethodname(bar, bar, bar, bar, bar,
  baz, baz, baz);
myreallylongmethodname(bar, bar, bar, bar, bar,
   baz, baz, baz);
Nope.  That was just my stylistic choice.  The rule is that lines are 
continued within an opening brace and whitespace is ignored.  So both the 
above are legit.

Serious #2:

Multiple statements per line in diagnostic code and error flow control.

The operant value in both these cases is some code is relatively 
unimportant to the main flow of the program and doesn't warrant gobs of 
space.
Actually, this I can see.  Although I certianly don't miss it.  Of course 
if you really want it...

[EMAIL PROTECTED]:~} python
Python 2.3+ (#2, Aug 10 2003, 11:33:47)
[GCC 3.3.1 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "foo" ; print "bar"
foo
bar
...you can have it.
--
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpHjJNeIjBUG.pgp
Description: PGP signature

Re: Tabs v.s. spaces

[H. S. Teoh]

On Tue, Nov 18, 2003 at 11:04:48AM -0800, Steve Lamb wrote:
> H. S. Teoh wrote:
> >Yeah, 'whitespace' about sums up the value of it. Except to Python
> >programmers, of course. :-P :-P
> 
> Quite the contrary.  First off generally flames are from the 
> uninformed. Since in most cases the evils of whitespace are spouted off 
> by 
>  those who have never once touched Python it is generally they who are 
> flaming and not those who have actually used it.

First off, note the smileys.

> Secondly clearly they are deriving some worth from it.  I mean you did 
> post 12 messages to this thread.  More than me, in fact.

Secondly, note that I was merely expressing my personal preferences.

> Finally I am still waiting for an answer to my two questions posed to 
> you.
> 
> 1: Have you ever used Python?

Not for any non-trivial task, although I did try to learn it some time
ago. Recently, I had the chance to take another look at it; however, I
found Ruby, which seemed to have the best of both Perl and Python plus
true object-orientation. So when I move on from Perl (which I love, but
which admittedly has its flaws too), it will be to Ruby, not Python.

> 2: Provide an example of such free-style coding that you speak highly of.
[snip]

Example (Perl):
PARSE: {
  m/\G (void|int|float) /gcx && do { $type = $1 };
  [EMAIL PROTECTED] /\*([^*]+|\*[^/])*\*\/@gcx && next PARSE;
  m/\G \s+ /gcx && next PARSE;
  m/\G \{ /gcx && do {
my @statements =  parse_block;
push @block, @statements;
  };
}

OK, this example is a bit contrived (it doesn't really do anything
useful), but it illustrates one situation where you'd like to be able to
stick a block on a single line in one case (e.g., the first match) but
keep it as an indented block in another case (e.g. the last match).

More examples (C++):

try {
  obj_handle handle = get_handle();
  handle.write(data);
  if (handle.error()) throw exception(obj_handle::write_error);

  handle.verify(data);
  if (handle.error()) throw exception(obj_handle::verify_error);

  handle.commit();
  if (handle.error()) {
commit_errors++;
if (retry_needed) {
  retry_request();
}
  }
}

Another contrived example, but shows the same principle: in most cases the
throw can remain on the same line to avoid code clutter, but when
something more involved is needed, you break it up into an indented block.

More Perl examples:
open FILE, $file1 or die "Unable to open $file1: $!\n";
while () {
  ...
}
close FILE or die "Error while reading $file1: $! ($?)\n";
open FILE, $file2 or do {
  ... # do something else
};
...

Again, the flexibility to use or not use indented blocks help greatly in
readability here.

Next example (C):
for (i=0; i

Re: Tabs v.s. spaces

[Chad Walstrom]

On Tue, Nov 18, 2003 at 11:32:36AM -0800, Tom wrote:
> Serious #1:
> 
> *It looks like multi-line method invocations require parenthesis to be
> indented at the paren level.  Sometimes that's useful, but often I
> like to pack arguments tighter than that and indent only once on
> subsequent lines:
> myreallylongmethodname(bar, bar, bar, bar, bar,
>   baz, baz, baz);
> myreallylongmethodname(bar, bar, bar, bar, bar,
>baz, baz, baz);

No, this is not true.  You are describing implicit line joining, which
is described in the Library Reference[1] Section 2.1.3[2].

"Expressions in parentheses, square brackets or curly braces can
be split over more than one physical line without using
backslashes...  The indentation of the continuation lines is not
important.  Blank continuation lines are allowed."

Besides, you don't NEED ';' in Python to end a single statement.

> Serious #2:
> 
> Multiple statements per line in diagnostic code and error flow control.
> 
> The operant value in both these cases is some code is relatively 
> unimportant to the main flow of the program and doesn't warrant gobs of 
> space.  "Real" code should be indented like Python, but if everything is 
> "proper", "important" code gets lost in a bunch of scaffolding.
> Obiviously high equality code should be simple, but sometimes other 
> values weigh slightly higher than writing perfect code, and flexibility 
> is useful.

You can combine statements (Compound Statements[3]) on a single line
with the ';' character...

print 'ERROR: You are mistaken'; sys.exit(1)

Or control flow constructs...

if test: if test2: print x

Which could just as easily be written

if test:
if test2:
print x
> Light-hearted:
> 
> Sometimes I just feel like writing crappy multi-line, write-only code
> because it's not intended to change the world, and I want to see it
> all on the screen at once.  Many real-world tasks are like this.

yay.

REFERENCES
1. http://www.python.org/doc/current/ref/
2. http://www.python.org/doc/current/ref/implicit-joining.html
3. http://www.python.org/doc/current/ref/compound.html

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpSfe8N5dbhn.pgp
Description: PGP signature

Re: Tabs v.s. spaces

[Steve Lamb]

H. S. Teoh wrote:
Not for any non-trivial task, although I did try to learn it some time
ago. Recently, I had the chance to take another look at it; however, I
found Ruby, which seemed to have the best of both Perl and Python plus
true object-orientation. So when I move on from Perl (which I love, but
which admittedly has its flaws too), it will be to Ruby, not Python.
Perl has good points?  *shudder*  I looked at Ruby and saw that it was 
taking many of the bad points of Perl.

PARSE: {
  m/\G (void|int|float) /gcx && do { $type = $1 };
  [EMAIL PROTECTED] /\*([^*]+|\*[^/])*\*\/@gcx && next PARSE;
  m/\G \s+ /gcx && next PARSE;
  m/\G \{ /gcx && do {
my @statements =  parse_block;
push @block, @statements;
  };
}
Possible.
try {
  obj_handle handle = get_handle();
  handle.write(data);
  if (handle.error()) throw exception(obj_handle::write_error);
  handle.verify(data);
  if (handle.error()) throw exception(obj_handle::verify_error);
  handle.commit();
  if (handle.error()) {
commit_errors++;
if (retry_needed) {
  retry_request();
}
  }
}
Possible.

More Perl examples:
open FILE, $file1 or die "Unable to open $file1: $!\n";
while () {
  ...
}
close FILE or die "Error while reading $file1: $! ($?)\n";
open FILE, $file2 or do {
  ... # do something else
};
...
Possible.

Next example (C):
for (i=0; iPossible.
Output example (C/C++):
if (debug==1)
printf(gettext("Debug dump:\n"
   "Current registers: %s\n"
   "Watch values: %s\n"),
   get_register_dump(),
   get_watch_values());
Possible.
Finally, constructors example (C++):
classA::classA(int x, int y) : xcoor(x), ycoor(y) {}
classB::classB(void (*)(int x, int y),
   void classA::*callback(int i)) :
xcoor(x), ycoor(y), cb(callback) {
  if (callback==NULL) throw exception();
}
Possible.
Note how the flexibility to indent makes it possible to write simple
constructors on one line (classA), and layout complex constructors such as
in classB such that separate elements are clearly separated.
So exactly where's your problem with the white space again?  If you 
really wanted to do each of those you could easily enough.  Oddly enough in 
each case you'll mostly be removing braces.  I hope this concludes the topic 
for those who haven't touched Python badmouthing the whitespace issue since, 
thus far, I've yet to see a single example which isn't possible in pretty much 
the exact same visual style.

--
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpLPaEZO7rLq.pgp
Description: PGP signature

Re: Howto reconfigure alsa-modules-2.4.22-1-k6

[Greg Folkert]

On Tue, 2003-11-18 at 14:17, Otto Wyss wrote:
> > Otto Wyss dijo:
> > >   dpkg-reconfigure alsa-modules-2.4.22-1-k6
> > > 
> > > but this doesn't show the driver list again! Okay getting dselect out,
> > > purge the package and install it again. But now the list isn't shown
> > > either. How do I get the driver list from this package?
> > > 
> > dpkg-reconfigure alsa-base
> > 
> >   Anyway, this message would have fitted better in debian-user
> > 
> First it was an oversight, sorry. But now I think the alsa packages are
> more broken. After successfully using dpkg-reconfigure alsa-base I got
> the following error messages:
> 
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.22-1-k6/alsa/snd-pdaudiocf.o
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.22-1-k6/alsa/snd-vx-cs.o
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.22-1-k6/alsa/snd-vxp440.o
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.22-1-k6/alsa/snd-vxpocket.o

At this point I would just remove those files. They are not needed by
your machine. Unless those are the devices you are running. But
seriously just remove them and re-run update-modules. There are some
funky things I have always (nearly always) seen with those modules. Even
in the OSS setup they are difficult to get properly compiled.

> I get the same messages when using update-modules. My alsa configuration
> looks good:
> 
> ### DEBCONF MAGIC
> # This file was automatically generated by alsa-base's debconf stuff
> 
> alias char-major-116 snd
> alias char-major-14 soundcore
> 
> options snd major=116 cards_limit=4
> 
> alias sound-service-0-0 snd-mixer-oss
> alias sound-service-0-1 snd-seq-oss
> alias sound-service-0-3 snd-pcm-oss
> alias sound-service-0-8 snd-seq-oss
> alias sound-service-0-12 snd-pcm-oss
> 
> alias snd-card-0 snd-ice1724
> 
> alias snd-slot-0 snd-card-0
> alias sound-slot-0 snd-slot-0
> 
> and lspci shows
> 
> 00:0b.0 Multimedia audio controller: IC Ensemble Inc ICE1724 [Envy24HT]
> (rev 01)
> 
> So what's wrong now?

Nothing. And from you Conf, it shows your card does not use those
modules anyway. File a bug report for the alsa maintainer and see what
comes of it.

-- 
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Your unexpected explosion entangles us in a web of premature umbrellas
and precocious timepieces.


signature.asc
Description: This is a digitally signed message part