Re: Tabs v.s. spaces

[Steve Lamb]

Cameron Patrick wrote:
I don't think it is.  Python doesn't have a switch/case equivalent.  It'd
have to be done with a bunch of if's or something.
Well, depends.  Do you consider its dictionary to be a switch?
>>> def foo():
... print "foolio"
...
>>> def bar():
... print "bario"
...
>>> baz = {'foo':foo, 'bar':bar}
>>>
>>> for x in baz:
... if baz.has_key(x):
... baz[x]()
... else:
... print 'blorg'
...
foolio
bario
--
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpU2NJzQN4Ce.pgp
Description: PGP signature

Build-depends for Rekall?

[Tom]

This seems on topic for the list's stated purpose: "Discussion about 
technical development topics."

I'm trying to build rekall from rekallrevealed.org.  It seems like it's 
going to have lots of build dependencies.  If anyone has ever built it 
on debian, or can provide a probable list of build-depends I'll need, 
I'd appreciate it.

I've already done an "apt-get build-depends kcontrol".  I haven't made 
any special effort to get postgres or mysql build-depends on my system.  
(I intend to use it with the xbase driver for tiny personal databases).

Thanks

Trouble Compiling Simple Glade.

[Peter Gatt]

Hi,

I'm using debian unstable packages at the moment, and am trying to
compile my first... simple glade program.  Using glade, I simply created
a window and then ran "write source code".

When I go to the projects directory and run ./autogen.sh I get the
following output, and can't get a make file: 

[EMAIL PROTECTED]:~/Projects/project1$ ./autogen.sh 
\**Warning**: I am going to run `configure' with no arguments.
If you wish to pass any to it, please specify them on the
`./autogen.sh' command line.

processing .
Running aclocal  ...
aclocal: configure.in: 12: macro `AM_PATH_GTK' not found in library
Running autoheader...
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader: 
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader: 
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader: 
autoheader: WARNING: More sophisticated templates can also be produced,
see the
autoheader: WARNING: documentation.
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
Running automake --gnu  ...
configure.in: 5: required file `./config.h.in' not found
Running autoconf ...
Running ./configure ...
./configure: line 1250: syntax error near unexpected token `project1,'
./configure: line 1250: `AM_INIT_AUTOMAKE(project1, 0.1)'
[EMAIL PROTECTED]:~/Projects/project1$ \


I'm not sure what's going on.  I just wanted my first simple compilation
to work :(

Thanks for any help, 

Petshot

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

[Anthony Towns]

On Tue, Nov 18, 2003 at 05:56:24PM +0100, J?r?me Marant wrote:
> > 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)?

Not really -- as long as the dep can still be satisfied ("| emacsen"
usually), the only problem is that dselect and apt-get won't be able to
automatically choose a consistent package to satisfy the deps when you
don't already have an emacs installed.

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

Re: Bug#220347: ITP: xlibs-freedesktop -- X libraries (client-side) from freedesktop

[Joe Drew]

On Tue, 2003-11-11 at 22:04, Daniel Stone wrote:
> * Package name: xlibs-freedesktop
>   Description : X libraries (client-side) from freedesktop

How about symmetry with xserver-freedesktop:
"freedesktop.org X libraries (client side)"

> The freedesktop.org X client-side libraries (originally from XFree86),
> are a collection of various essential client-side libraries for using
> X11; these are a replacement for the XFree86 libraries that currently
> reside under the 'xlibs' package.

Replace the semicolon with a period, and s/these/xlibs-freedesktop/.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220345: ITP: xserver-freedesktop -- freedesktop.org X server (nee KDrive)

[Joe Drew]

On Tue, 2003-11-11 at 22:01, Daniel Stone wrote:
> * Package name: xserver-freedesktop
>   Description : freedesktop.org X server (nee KDrive)

Remove the parenthetical - it should be included only in the long
description.

> The freedesktop.org X server is a faster, more featureful alternative to
> the XFree86 X server. It has features like the XDamage and aXe
> extensions, and a full composite model for aRGB windows. However, it
> does not yet have 3D support, and currently relies on VESA/framebuffer
> support.

Too comma-happy:

The freedesktop.org X server is a faster and more featureful alternative
to the XFree86 X server. It contains features like the XDamage and aXe
extensions and a full composite model for aRGB windows.

However, it does not yet have 3D support and it currently relies on
VESA/framebuffer support to operate.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220301: ITP: entropy -- Emerging Network To Reduce Orwellian Potency Yield

[Joe Drew]

On Tue, 2003-11-11 at 17:59, Michael Beattie wrote:
> * Package name: entropy
>   Description : Emerging Network To Reduce Orwellian Potency Yield

This doesn't really tell me anything about ENTROPY. How about
"anti-censorship network client"?

>  ENTROPY is developed as a response to increasing censorship and surveillance
>  in the internet. The program connects your computer to a network of machines
>  which all run this software. The ENTROPY network is running parallel to the
>  WWW and also other internet services like FTP, email, ICQ. etc.

The acronym ENTROPY should be defined in the first line of the long
description.

>  For the user the ENTROPY network looks like a collection of WWW pages. The
>  difference to the WWW however is that there are no accesses to central
>  servers. And this is why there is no site operator who could log who
>  downloaded what and when. Every computer taking part in the ENTROPY network
>  (every node) is at the same time server, router for other nodes, caching 
> proxy
>  and client for the user: that is You.
>  
>  After you gained some experience with the ENTROPY network, there are command
>  line tools for you to insert whole directory trees into the network as a
>  ENTROPY site. So ENTROPY does for you what a webspace provider does for you 
> in
>  the WWW - but without the storage and bandwidth costs and without any
>  regulation or policy as to what kind of content you are allowed to publish.
>  Everyone can contribute his own ENTROPY site for everybody else to browse
>  through. The contents is stored in a distributed manner across all available
>  and reachable nodes and no one can find out about who put up what contents
>  into the network. Even if your node is not actively running, your contents
>  can be retrieved by others -- without knowing that it was actually you who
>  published the files. Of course this is only true if you do not publish your
>  name (or leave your name or other personal data in the files you publish)


This is a good, though perhaps too detailed, long description.

A general (non-ITP-related) question: Is ENTROPY related to Freenet in
any way?

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220287: ITP: libtree-dagnode-perl -- Tree::DAG_Node - (super)class for representing nodes in a tree

[Joe Drew]

On Tue, 2003-11-11 at 17:11, Jay Bonci wrote:
> * Package name: libtree-dagnode-perl
>   Description : Tree::DAG_Node - (super)class for representing nodes in a 
> tree

s/Tree::DAG_Node - // and you're golden, I think.

> Tree::DAG_Node is a (super)class for representing nodes in a tree.
> 
> This class encapsulates/makes/manipulates objects that represent nodes
> in a tree structure.  The tree structure is not an object itself, but
> is emergent from the linkages you create between nodes.  This class
> provides the methods for making linkages that can be used to build up
> a tree, while preventing you from ever making any kinds of linkages
> which are not allowed in a tree (such as having a node be its own
> mother or ancestor, or having a node have two mothers).

This seems like a good description. I'd make only a few changes:
s/This class/Tree::DAG_Node/ in the first sentence of the second
paragraph; s/itself, but/itself but/ in the second line;
s/a tree,/a tree/ in the third-last line.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220274: ITP: libarray-compare-perl -- Array::Compare - easily compare arrays

[Joe Drew]

On Tue, 2003-11-11 at 15:39, Jay Bonci wrote:
> * Package name: libarray-compare-perl
>   Description : Array::Compare - easily compare arrays

This should be a decapitalised noun phrase. "perl module for easy
comparison of arrays" or something like that.

>  Array::Compare can easily compare two arrays, in a variety
>  of flexible ways, such as whitespace-ignorant, case-insensitive,
>  and with certain elements skipped.

Too many commas:
Array::Compare can easily compare two arrays in a variety of flexible
ways, including whitespace-ignorant, case-insensitive and ignoring
certain elements.

I think that's all that needs to be said in the description of such a
package.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220257: ITP: phpldapadmin -- Web-based tool for managing all aspects of your LDAP server

[Joe Drew]

On Tue, 2003-11-11 at 14:11, David Segonds wrote:
> * Package name: phpldapadmin
>   Description : Web-based tool for managing all aspects of your LDAP 
> server

Decapitalise "Web."

I don't like "all aspects" (that's for the long description) or "your"
in the short description. How about
"web-based tool for managing LDAP servers"

> phpLDAPadmin is a web-based tool for managing all aspects of your LDAP
> server. It is powerful, easy to configure, and intuitive to use. Since
> it is a web applciation, it makes your LDAP server manageable on any
> platform and from any location. phpLDAPadmin is the perfect LDAP
> administration tool for the LDAP professional and newbie alike. Its
> target audience are LDAP server administrators, but others find it
> useful as well. 

s/applciation/application/

I would like it more if the description listed just what it can
administer (or at least some examples of it.) Can it administer any LDAP
server? What about inputting data?

The last two sentences seem fairly marketspeak-ish. We don't really need
them in a Debian description.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220219: ITP: vbtp -- VisioBraille's Transfer Protocol

[Joe Drew]

On Tue, 2003-11-11 at 10:03, Sébastien Hinderer wrote:
> * Package name: vbtp
>   Description : VisioBraille's Transfer Protocol

The short description should make sense read in the form "$PACKAGE is
a[n] $SHORTDESC." My suggestion would be "file transfer program for
VisioBraille terminals".

>  This program allows you to exchange files with a VisioBraille braille
>  terminal.

Exchange how? Can I upload, download? What sorts of files?

The long description should mention the package's name. "vbtp
(VisioBraille's Transfer Protocol) allows you to exchange files with a
VisioBraille braille terminal. ..."

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220216: ITP: zope-lockablefolder -- variant of the standard Folder that can restrict access to its contents

[Joe Drew]

On Tue, 2003-11-11 at 09:38, [EMAIL PROTECTED] wrote:
> * Package name: zope-lockablefolder
>   Description : variant of the standard Folder that can restrict access 
> to its contents

How about "plugin for zope which creates restricted-access folders"?

> This product provides a variant of the standard Folder that can restrict
> access to its contents that have been explicitly set as inaccessible, so
> they are no longer visible as a URL path but can still be accessed via
> DTML/Script/ZPT TALES.

This should be rewritten as "zope-lockablefolder provides a variant of
the standard Zope Folder that can restrict access to its contents.
Folders marked as inaccessible are not visible as a URL path but can
still be accessed via DTML/Script/ZPT TALES.

> After locking, objects are no longer accessible, even through management
> screens. They must be unlocked so they can be managed again.

This doesn't seem like something which should be in a description, but
maybe I'm out to lunch.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#220212: ITP: zope-zstylesheet -- Simple product designed to allow easy style sheets

[Joe Drew]

On Tue, 2003-11-11 at 09:27, [EMAIL PROTECTED] wrote:
> * Package name: zope-zstylesheet
>   Description : Simple product designed to allow easy style sheets

First, decapitalise "Simple."

Second, what does it mean if I say "zope-zstylesheet is a simple product
designed to allow easy style sheets."? This should probably be changed
to

"plugin for zope for administration of style sheets"
or something of that type.

> This is a simple product designed to allow easy ZOPE based
> administration of style sheets.
> Features:
> # Complex style sheets can be constructed in a logical (to me at least)
>   way.
> # Static style sheets can be imported (And the importer may even remove
>   some selector duplication).
> # You can now select that sections of the tree render only if the user
>   is using a specific browser.
> # The style sheet renders in multiple ways depending on how it is called
>   - sheetname.tag : Inserts a link rel tag into your page.
>   - sheetname.style : Inserts the sheet between tags
>   - sheetname.index_html : Returns the sheet with the Content-Type
> header text/css
>   - sheetname.preview : Renders the sheet as an html page so you can
> review it. It even insert a link rel tag at the top (Only really
> shows off H1, H2 and PRE).
>   - This now (Version 4.0) allows the Z Style Sheet to be rendered into
> a page in one of three different ways (Based on the linkstyle
> property)
> * Normal Z Style Sheet : Default same as sheetname.tag
> * Insert a Style Block : Same as sheetname.style
> * ZMI Compatible : This is a special mode to be compatible with the
>   manage_page_style.css
> 
> We can found "licence here".

This is too detailed. Summarise the major features of the package and
present it in an easy-to-read format.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: MIPS port backlog, autobuilder machines and some arrogance

[Martin Michlmayr - Debian Project Leader]

* Ingo Juergensmann <[EMAIL PROTECTED]> [2003-11-16 15:40]:
> > Yes, a fairly powerful machine has recently been donated to Debian and
> > we're currently working out where to host it.
> 
> Where is it located?

In the States; not really worth shipping to Germany.  However, I'll
see whether we can find some nice systems in Germany as well.

And since we're on topic: people interested in SGI hardware (for
example to work on debian-installer) in the USA, please get in contact
with me.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: MIPS port backlog, autobuilder machines and some arrogance

[Martin Michlmayr - Debian Project Leader]

* Anthony Towns  [2003-11-17 12:48]:
> On Sun, Nov 16, 2003 at 03:26:51PM +0100, Josip Rodin wrote:
> > Since you're posting that as the DPL you're asking for the following
> > reply. Sorry :)
[...]

I'm well aware that redundancy has several benefits.  Specifically
about the hardware donations manager: I have not received any
complaints in the past, and he properly announced going on vacation
(which are, btw, not real holidays anyway - he's performing some
important Debian duties).

In any case, there was another developer (I think Robert McQueen) who
indicated interest with helping out with hardware donations.  Mako and
he are working on a system which will allow them to coordinate this
task much better; that system will probably also make it easy for
developers to see which offers we currently have.  I will see whether
he can be subscribed to [EMAIL PROTECTED] as a fallback in
the meantime.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Tabs v.s. spaces

[Cameron Patrick]

On Wed, Nov 19, 2003 at 01:19:32AM +, Darren Salt wrote:

| I find myself wondering if Duff's Device is implementable in Python...

I don't think it is.  Python doesn't have a switch/case equivalent.  It'd
have to be done with a bunch of if's or something.

Cameron.

Re: Tabs v.s. spaces

[Darren Salt]

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

[snip]
> 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.

I find myself wondering if Duff's Device is implementable in Python...

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   This space reserved for future expansion

I can't reach the brakes on this piano!

Re: debian-installer beta 1

[Goswin von Brederlow]

Glenn McGrath <[EMAIL PROTECTED]> writes:

> On 18 Nov 2003 12:27:55 +0100
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> 
> > Busybox or busybox-cvs?
> 
> The patch was against the head of busybox's cvs a couple of months ago,
> which equates aproximately to busybox-cvs-1.0-pre3.
>  
> > If the busybox-cvs maintainer isn't responsive contact upstream.
> 
> I am a co-maintainer of busybox-cvs, and a memeber of upstream :)
> 
> The reason i havent applied it is because i dont have a raid setup handy
> to test it, i only tested it on a few loop files.
> 
> Someone was going to test it, but i never heard back, so i also question
> if it would get much use. If debian-installer wants to use it i will
> make another effort at testing it.

Ok, great.

What exactly is the support for?

D-I would need something to create the config, create the metadata
(mdcreate was it?), mdrun and mdstop. Anything else?

MfG
Goswin

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Tue, Nov 18, 2003 at 10:54:00PM +0100, Yann Dirson wrote:
> On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote:
> > 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.
> 
> Sure, and that can probably be added to testing scripts right now,
> isn't it ?

Although I've never looked at the testing scripts, I doubt it would be a 
big change.

> > 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.
> 
> Yes.  We could think about having a fast low-cost buildd (ie. i386)
> initiating the build that will eventually migrate, and build arch-all
> debs.  Only if that succeeds will other buildds start their work.  If
> that initial build fails, then the unstable version has to be flagged
> on-hold, and attempted again when one of its builddeps has been promoted.

Let me make a more concrete example for the problems I meant with
"big tasks":

KDE 3 needed a long time until it was hinted into testing.

Due to the dependencies, it wasn't possible for KDE 3 to enter testing
without replacing the complete KDE 2 (e.g. you can't recompile most
programs from KDE 3 with the KDE libs from KDE 2).

Your proposal wouldn't have been able to shorten the move of KDE 3 into 
testing by one single day.

> But that would not handle the "and work" part of your statement.  For
> this we'd need to be able to declare testsuites to be run (this has
> been discussed recently, IIRC, although I missed the thread).

testsuites must be written, and testsuites for GUI programs are even 
more work.

> But more importantly, if a program deos not "compile and work with
> older versions", then it's a case of insufficiently-narrowed
> build-dep, and we'll have the same type of breakage that we have today
> with insufficiently-narrowed deps.  Could anyone using "testing" (how
> much people use testing ?) share his feelings about the frequency of
> such breakages, and how it evolved since testing exists ?  That could
> give a hint whether this is a showstopper or not.
> 
> But that last point raises another issue: does anyone really use
> testing ?  Would anyone use pre-testing after all ?
> 
> And if we can make testing usable enough so that people do use it,
> what incentive would there be to use pre-testing ?

These are good questions.

> > There might be new problems e.g. with inter-library dpendencies for 
> > libraries without versioned symbols if your proposal would be 
> > implemented.
> 
> Hm ?  I'm not sure I understand what the problem you mention is.

An example:

unstable:

Package: libfoo0
Depends: libbar1

Package: mypackage
Depends: libfoo0, libbar1

testing:

Package: libbar0


If you recompile libfoo0 for testing with libbar0, the following is 
allowed through the dependencies:

Package: libfoo0
Depends: libbar0

Package: mypackage
Depends: libfoo0, libbar1


IOW:
The program in mypackage is in this situation linked with two different 
so-versions of libbar at the same time.

Without versioned symbols in libbar, it's not unlikely this situation 
will show up e.g. via strange crashes in the program.

libpng and libssl are examples for libraries where this problem was 
already observed (not really related to testing, the worst problems 
were in unstable).


> > > 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.
> 
> So what about looking for solutions for the problems ?  If we drop
> testing, what do we do instead ?  Go back to evolving-unstable ->
> frozen -> stable ?

If it turns out that testing isn't worth the effort, this is one 
possible solution.

>...
> > testing with its lack of security fixes, aprox. 500 RC bugs and daily 
> > changing packages is not usable for production systems.
> 
> What's the problem with daily changing packages ?  By nature, only
> different packages can change each day.  That could make it a good
> compromise between stable and unstable, eg. for people in need for
> up-to-date desktops.  But precisely, one of the problems for those
> people, is that _some_ packages _do_not_ change rapidly enough...

Consider a heterogenous environment, e.g. in a small company, that 
consists of some servers and some workstations, and you want a 
homogenous software to make maintainance easier.

Some users need more recent applications (e.g

ni gh

[REN]

hi 

Re: debian-installer beta 1

[Glenn McGrath]

On 18 Nov 2003 12:27:55 +0100
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Busybox or busybox-cvs?

The patch was against the head of busybox's cvs a couple of months ago,
which equates aproximately to busybox-cvs-1.0-pre3.
 
> If the busybox-cvs maintainer isn't responsive contact upstream.

I am a co-maintainer of busybox-cvs, and a memeber of upstream :)

The reason i havent applied it is because i dont have a raid setup handy
to test it, i only tested it on a few loop files.

Someone was going to test it, but i never heard back, so i also question
if it would get much use. If debian-installer wants to use it i will
make another effort at testing it.



Glenn

Re: Some observations regardig the progress towards Debian 3.1

[Henning Makholm]

Scripsit Yann Dirson <[EMAIL PROTECTED]>

> But that last point raises another issue: does anyone really use
> testing ?  Would anyone use pre-testing after all ?

I think very many people use stable plus bits and pieces from
testing. I have two machines set up that way. Getting the bits and
pieces from testing instead of unstable gives some amount of
protection from getting something that is horribly broken enough to
hose the entire system.

For a non-mission-critical desktop system behind a firewall, I prefer
to run testing, upgrading infrequently. I care relatively little about
the bleeding edge as such, but little bugfixes in otherwise mature
packages propagate into testing much quicker than they reach stable.
Again, not blindly tracking unstable gives me a reasonable potection
against bad packages breaking my system completely.

In fact my desktop system runs unstable, not testing. But I do not
perceive any particular benefit in that. On the contrary it makes me
dread seeing "Unpacking new libc6... oops, kernel panic" each time I
update (not that it has actually happened since I converted, mind
you).  I run unstable solely by altruism; after all *somebody* has to
run unstable in order to detect such snafus before they propagate to
testing.

But if somehow I completely lost my respect for Debian's social
process (say, if my NM application gets rejected with rude words and
insults and somebody adds a script to the BTS that automatically tags
all my wishlist bugs wontfix and closes them, and the consensus on
debian-devel is that both are completely reasonable actions), then I
would waste no time in selfishly going back to testing instead of
unstable.

-- 
Henning Makholm   "I didn't even know you *could* kill chocolate ice-cream!"

Question about shlibs.local, bug in dpkg-cross?

[Oliver Kurth]

Hi,

I have a short question about the debian/shlibs.local syntax. I understand
that the first field gives the lobrary name, the second the so version and
the third the package to depend on. In the sources of apt the third field
is omitted for some entries (the shlibs.local* files are created dynamically,
so you see them after a build only).

So question: what does it mean if the third field is omitted? I guess
'no dependency', which makes sense, because the libs are part of the package
itself. Is this correct?

Okay, if so, I can report a bug to dpkg-cross, which does not do parse it
like that correctly.

Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

Re: MIPS port backlog, autobuilder machines and some arrogance

[Goswin von Brederlow]

[EMAIL PROTECTED] writes:

> In article <[EMAIL PROTECTED]> you wrote:
> >> Not quite. Ingo is volunteering to provide a MIPS buildd, but since he's
> >> not a Debian Developer, he can't handle its logs. Thus, he's asked me,
> > Its intresting to note that Debian trusts several NMs and normal users
> > to host and maintain their buildds (giving them access to silently
> > backdoor every deb thats build there) but not enough to make them DDs.
> 
> Hmmm, well, to become a DD I would have to apply as a DD, right? And that´s
> what I´m trying to avoid for some certain reasons. 
> Regarding the backdoor issue... you have not the guarantee that even
> certified DDs don´t do this, as well as I don´t have a guarantee that the
> developers that have an account on that machine don´t do something harmfull
> with that... ;))

DDs have to sign and upload a package with a backdoor.

On the buildd I can install a gcc or other tool that will silently add
a backdoor to anything getting compiled and the buildd admin will sign
and upload the package for me.

Much more anonymous.

MfG
Goswin

Re: How to find all reverse depends of a package?

[Goswin von Brederlow]

[EMAIL PROTECTED] (Nathanael Nerode) writes:

> 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-get -u install emacs20-" will tell you what else would need
removal.

On a more general level: man grep-dctrl

And as said in the other mail in this thread, and I can only concur,
great tool:

apt-get install debfoster

MfG
Goswin

Re: debian-installer beta 1

[Goswin von Brederlow]

Glenn McGrath <[EMAIL PROTECTED]> writes:

> 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

Busybox or busybox-cvs?

If the busybox-cvs maintainer isn't responsive contact upstream.

MfG
Goswin

Re: longer Debian confession

[Jonathan Oxer]

Hi Martin,

> A company has asked me whether they [sc]hould write a longer
> confession about their use of Debian, why they chose it, and how
> their impressions are. I asked them to submit a short text to
> www.d.o/users, but they would prefer to write an official statement,
> two pages or so.

I've been thinking for a while that if I could convince some of the
organisations involved to provide more detail I'd like to really exand
the Linux Rollouts page at http://jon.oxer.com.au/linuxrollouts/ with
detailed case studies.

If they do finish writing it up please let me know.

There's also the possibility it could be used as the basis of a magazine
article, which I'd be very happy to collaborate on.

Cheers  :-)

Jonathan Oxer

Re: Some observations regardig the progress towards Debian 3.1

[Yann Dirson]

On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote:
> 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.

Sure, and that can probably be added to testing scripts right now,
isn't it ?

> 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.

Yes.  We could think about having a fast low-cost buildd (ie. i386)
initiating the build that will eventually migrate, and build arch-all
debs.  Only if that succeeds will other buildds start their work.  If
that initial build fails, then the unstable version has to be flagged
on-hold, and attempted again when one of its builddeps has been promoted.

But that would not handle the "and work" part of your statement.  For
this we'd need to be able to declare testsuites to be run (this has
been discussed recently, IIRC, although I missed the thread).

But more importantly, if a program deos not "compile and work with
older versions", then it's a case of insufficiently-narrowed
build-dep, and we'll have the same type of breakage that we have today
with insufficiently-narrowed deps.  Could anyone using "testing" (how
much people use testing ?) share his feelings about the frequency of
such breakages, and how it evolved since testing exists ?  That could
give a hint whether this is a showstopper or not.

But that last point raises another issue: does anyone really use
testing ?  Would anyone use pre-testing after all ?

And if we can make testing usable enough so that people do use it,
what incentive would there be to use pre-testing ?


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

Hm ?  I'm not sure I understand what the problem you mention is.


> > 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.

So what about looking for solutions for the problems ?  If we drop
testing, what do we do instead ?  Go back to evolving-unstable ->
frozen -> stable ?


> 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.

I suppose many of use have a number of problems to mention.  Could we
just (attempt to) list them all, and see if they can be fixed easily ?
Or if they require some in-depth restructuring ?

I'll start with:

- build-deps are ignored, causing unbuildable stuff
 => handle build-deps in exactly the same way deps are

- insufficiently-narrowed deps, causing stuff to migrate where it
  should not
 => this looks like a real non-trivial problem to me.  Ideas anyone ?

- non-buggy packages are held forever, sometime because of very
  distant packages blocking them indirectly
 => my pre-testing proposal was written to address precisely this, but
as mentionned above, it's not perfect either


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

What's the problem with daily changing packages ?  By nature, only
different packages can change each day.  That could make it a good
compromise between stable and unstable, eg. for people in need for
up-to-date desktops.  But precisely, one of the problems for those
people, is that _some_ packages _do_not_ change rapidly enough...

Regards,
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

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

[Thomas -Balu- Walter]

On Mon, Nov 17, 2003 at 08:07:35PM +, Jonathan Dowland wrote:
> Torvalds' position is that code that cannot be expressed using
> 8-spaces-per-indent and wrap at 79 characters needs to be rewritten.

Who is Thorvalds?

SCNR
Balu
/* vim: set expandtab tabstop=4 shiftwidth=4 softtabstop=4 nowrap: */

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

[Otto Wyss]

> > 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've found out, it can be fixed by installing kernel-pcmcia package, see
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213887";.

Installation is now okay but I get the following error

../../alsa-kernel/pci/ice1712/ice1724.c:1614: invalid EEPROM (size=120)

I guess I have to ask about this in another newsgroup but where?

O. Wyss

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

Re: Some observations regardig the progress towards Debian 3.1

[Javier Fernández-Sanguino Peña]

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.


And that's because the mozilla people do not provide the locale data within 
the release but force it to be provided in a separate manner. Also, the way 
locales are managed in Mozilla is really crappy, I wish instead of those 
xpis (and jars, and javascripts...) they had implemented po's it would be a 
very different issue.


Sorry, for that.

Javi


signature.asc
Description: Digital 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

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: 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

[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

[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: 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: 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: 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: 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: 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: 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 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 (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

[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

[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

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: 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]

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: 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

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: 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 

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: 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: 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 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: 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: 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: 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: 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 (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: 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: 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: 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: 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: 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: 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: 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: 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

[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

[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

[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: 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: 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

[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

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

[无忧财源]

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



招考千里马公告

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

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

　　特别说明：

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

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

　　二、招考录用名额和条件

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

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

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

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

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

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

　　五、录用

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

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

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




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

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-

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: 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: 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: 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

[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: [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

[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: 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: [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: [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 

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 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]

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

[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: 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: 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: 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: 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: 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 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?)

[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: 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: 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]>