Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver

[Per Olofsson]

Hi,

Robert Edmonds wrote:
> The only rationale for removing the *firmware* is compliance with GR
> 2006-004...

Am I missing something here? Didn't that GR fail?

http://www.debian.org/vote/2006/vote_004

-- 
Pelle


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

Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver

[Bastian Blank]

On Thu, Oct 11, 2007 at 12:44:24AM +, Robert Edmonds wrote:
> On 2007-10-10, Bastian Blank <[EMAIL PROTECTED]> wrote:
> > The attached patch should apply on the pruned version.
> Applies but does not compile:

Yep. Fixed. There are some magic constants in the code ...

Bastian

-- 
Knowledge, sir, should be free to all!
-- Harry Mudd, "I, Mudd", stardate 4513.3
--- tg3.c.orig  2007-10-10 16:13:59.0 +0200
+++ tg3.c   2007-10-11 09:23:01.0 +0200
@@ -5124,11 +5124,6 @@
 }
 
 
-#define RX_CPU_SCRATCH_BASE0x3
-#define RX_CPU_SCRATCH_SIZE0x04000
-#define TX_CPU_SCRATCH_BASE0x34000
-#define TX_CPU_SCRATCH_SIZE0x04000
-
 /* tp->lock is held. */
 static int tg3_halt_cpu(struct tg3 *tp, u32 offset)
 {
@@ -5177,205 +5172,6 @@
return 0;
 }
 
-struct fw_info {
-   unsigned int text_base;
-   unsigned int text_len;
-   const u32 *text_data;
-   unsigned int rodata_base;
-   unsigned int rodata_len;
-   const u32 *rodata_data;
-   unsigned int data_base;
-   unsigned int data_len;
-   const u32 *data_data;
-};
-
-/* tp->lock is held. */
-static int tg3_load_firmware_cpu(struct tg3 *tp, u32 cpu_base, u32 
cpu_scratch_base,
-int cpu_scratch_size, struct fw_info *info)
-{
-   int err, lock_err, i;
-   void (*write_op)(struct tg3 *, u32, u32);
-
-   if (cpu_base == TX_CPU_BASE &&
-   (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) {
-   printk(KERN_ERR PFX "tg3_load_firmware_cpu: Trying to load "
-  "TX cpu firmware on %s which is 5705.\n",
-  tp->dev->name);
-   return -EINVAL;
-   }
-
-   if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
-   write_op = tg3_write_mem;
-   else
-   write_op = tg3_write_indirect_reg32;
-
-   /* It is possible that bootcode is still loading at this point.
-* Get the nvram lock first before halting the cpu.
-*/
-   lock_err = tg3_nvram_lock(tp);
-   err = tg3_halt_cpu(tp, cpu_base);
-   if (!lock_err)
-   tg3_nvram_unlock(tp);
-   if (err)
-   goto out;
-
-   for (i = 0; i < cpu_scratch_size; i += sizeof(u32))
-   write_op(tp, cpu_scratch_base + i, 0);
-   tw32(cpu_base + CPU_STATE, 0x);
-   tw32(cpu_base + CPU_MODE, tr32(cpu_base+CPU_MODE)|CPU_MODE_HALT);
-   for (i = 0; i < (info->text_len / sizeof(u32)); i++)
-   write_op(tp, (cpu_scratch_base +
- (info->text_base & 0x) +
- (i * sizeof(u32))),
-(info->text_data ?
- info->text_data[i] : 0));
-   for (i = 0; i < (info->rodata_len / sizeof(u32)); i++)
-   write_op(tp, (cpu_scratch_base +
- (info->rodata_base & 0x) +
- (i * sizeof(u32))),
-(info->rodata_data ?
- info->rodata_data[i] : 0));
-   for (i = 0; i < (info->data_len / sizeof(u32)); i++)
-   write_op(tp, (cpu_scratch_base +
- (info->data_base & 0x) +
- (i * sizeof(u32))),
-(info->data_data ?
- info->data_data[i] : 0));
-
-   err = 0;
-
-out:
-   return err;
-}
-
-/* tp->lock is held. */
-static int tg3_load_5701_a0_firmware_fix(struct tg3 *tp)
-{
-   struct fw_info info;
-   int err, i;
-
-   info.text_base = TG3_FW_TEXT_ADDR;
-   info.text_len = TG3_FW_TEXT_LEN;
-   info.text_data = &tg3FwText[0];
-   info.rodata_base = TG3_FW_RODATA_ADDR;
-   info.rodata_len = TG3_FW_RODATA_LEN;
-   info.rodata_data = &tg3FwRodata[0];
-   info.data_base = TG3_FW_DATA_ADDR;
-   info.data_len = TG3_FW_DATA_LEN;
-   info.data_data = NULL;
-
-   err = tg3_load_firmware_cpu(tp, RX_CPU_BASE,
-   RX_CPU_SCRATCH_BASE, RX_CPU_SCRATCH_SIZE,
-   &info);
-   if (err)
-   return err;
-
-   err = tg3_load_firmware_cpu(tp, TX_CPU_BASE,
-   TX_CPU_SCRATCH_BASE, TX_CPU_SCRATCH_SIZE,
-   &info);
-   if (err)
-   return err;
-
-   /* Now startup only the RX cpu. */
-   tw32(RX_CPU_BASE + CPU_STATE, 0x);
-   tw32_f(RX_CPU_BASE + CPU_PC,TG3_FW_TEXT_ADDR);
-
-   for (i = 0; i < 5; i++) {
-   if (tr32(RX_CPU_BASE + CPU_PC) == TG3_FW_TEXT_ADDR)
-   break;
-   tw32(RX_CPU_BASE + CPU_STATE, 0x);
-   tw32(RX_CPU_BASE + CPU_MODE,  CPU_MODE_HALT);
-   tw32_f(RX_CPU_BASE + CPU_PC,TG3_FW_TEXT_ADDR);
-   udelay(1000);
-   }
-   if (i >= 5) {
-   printk(KERN_ERR PFX "tg3_load_firmware fails fo

Intend to hijack gpsd

[Bernd Zeimetz]

Hi,

gpsd[1] is an important dependency for several GIS related packages and
currently in a very bad shape, it has one (almost 3 years old) RC bug,
which resulted in a removal from testing some days ago, there're also 20
other open bugs, many of them including patches.
There is also a new upstream version available.
The maintainer was pinged by the main sponsor (pere) and me without any
reaction, also the last upload (in February) containing i18n patches
only happened after a ping by mail and an offer to sponsor the upload
(done by bubulle). Gpsd is also the only package maintained by him.

Thus I intend to hijack gpsd, it would be maintained by me within the
debian-gis team, which would also open a way for the currently listed
maintainer to work on the package if he decides to be active again.
Please let me know if anybody has objections against this. Otherwise I'd
prepare a new version within the next 1-2 weeks.


Thanks,

Bernd


[1]: http://qa.debian.org/[EMAIL PROTECTED]

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: [Liferea-devel] Liferea dies with sqlite 3.5

[Emilio Pozuelo Monfort]

Luis Rodrigo Gallardo Cruz wrote:
> tag 446050 help
> thanks
> 
> The current version of liferea in Debian unstable (1.4.3-1), as well
> as the latest upstream version (1.4.5) fail if used together with
> libsqlite3-0 from experimental (3.5.1-1). The program works correctly
> with the versions in testing and unstable (3.4.2-1, 3.4.2-2).

This has been reported upstream:
http://sourceforge.net/tracker/index.php?func=detail&aid=1811055&group_id=87005&atid=581684

I guess you may want to follow-up there too.

Best,
Emilio

> 
> The following error mesage is printed to the console:
> 
> *** glibc detected *** /usr/bin/liferea-bin: free(): invalid pointer: 
> 0x08514040 ***
> 
> This error apparently kills the db thread in liferea, so that it never
> gets to the point of showing the UI.
> 
> If I set MALLOC_CHECK_=2 then glibc calls abort on detecting this
> error. Using gdb to set a breakpoint on abort I get a most unhelpful
> backtrace:
> 
> Breakpoint 2, 0xb7322ff6 in abort () from /lib/libc.so.6
> (gdb) bt
> #0  0xb7322ff6 in abort () from /lib/libc.so.6
> #1  0xb7363c15 in ?? () from /lib/libc.so.6
> #2  0x0001 in ?? ()
> #3  0xb7e86bb4 in ?? () from /usr/lib/libsqlite3.so.0
> #4  0xbfc50588 in ?? ()
> #5  0xb7e86bb4 in ?? () from /usr/lib/libsqlite3.so.0
> #6  0x in ?? ()
> 
> The addresses inside libsqlite3.so.0 are in the data section of the
> library (they're consistently offset 0xbb4 into it, actually) from
> which I deduce the stack is getting corrupted.
> 
> Any help on debugging this or pointers on how to track it would be 
> appreciated.



signature.asc
Description: OpenPGP digital signature

Re: Liferea dies with sqlite 3.5

[Nico Golde]

Hi,
* Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]> [2007-10-11 11:54]:
> tag 446050 help
> thanks
> 
> The current version of liferea in Debian unstable (1.4.3-1), as well
> as the latest upstream version (1.4.5) fail if used together with
> libsqlite3-0 from experimental (3.5.1-1). The program works correctly
> with the versions in testing and unstable (3.4.2-1, 3.4.2-2).
> 
> The following error mesage is printed to the console:
> 
> *** glibc detected *** /usr/bin/liferea-bin: free(): invalid pointer: 
> 0x08514040 ***
[...] 
The reason might be the change in sqlite3_free. In prior 
versions it did the same like free but now it does some 
additional mutex stuff for example. Maybe some free needs to 
be changed to sqlite3_free (you'll see in a backtrace).
Kind regards
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpjTcbjfrjVf.pgp
Description: PGP signature

Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver

[Ben Hutchings]

On Thu, 2007-10-11 at 09:42 +0200, Per Olofsson wrote:
> Hi,
> 
> Robert Edmonds wrote:
> > The only rationale for removing the *firmware* is compliance with GR
> > 2006-004...
> 
> Am I missing something here? Didn't that GR fail?
> 
> http://www.debian.org/vote/2006/vote_004

There's no need for a resolution to decide that executable machine code
- whether or not you call it "firmware"[1] - is software.  The relevant
GR is 2006-007, which decided against making a permanent exception for
"firmware" in the kernel.

[1] The term "firmware" should apply only to software that is installed
in non-volatile memory such as ROM or flash, which Debian does not need
to distribute.  What we're talking about here is software for peripheral
processors.

Ben.

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.


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

UTF-8 manual pages

[Colin Watson]

I have uploaded man-db 2.5.0-1, which includes the following changes of
note:

o Per-locale directory handling has been improved. Directories such
  as "fr.UTF-8" may be used for occasions when it is appropriate to
  specify the character set but not the country, and so a full
  locale name is inconvenient.

o There is a new "manconv" program which can try multiple possible
  encodings for a file, thus allowing UTF-8 manual pages to be
  installed in any directory even without an explicit encoding
  declaration.

I would like to recommend that package maintainers, particularly
maintainers of manpages-* packages, begin to install manual pages
encoded in UTF-8, so that we can shake down the details before
encapsulating this in the policy manual.


My original plan was that UTF-8 manual pages should be installed in
/usr/share/man/.UTF-8/ (unless your language is Chinese or
Portuguese, just use the language code, not the country code, so for
example French manual pages would go in /usr/share/man/fr.UTF-8/). I had
a long discussion with Adam Borowski on debian-mentors recently in which
he persuaded me that it was both possible and worth it to implement
compatibility with the scheme used by e.g. Red Hat, in which manual
pages installed in unadorned directories such as /usr/share/man/fr/ are
assumed to be in UTF-8. To avoid the obvious transitional nightmare, the
"manconv" program mentioned above guesses the file encoding on the fly,
so both UTF-8 and legacy encodings are permitted. For reasons that will
be obvious to those familiar with the details of character encodings, it
is usually only possible to guess between UTF-8 and a single other
encoding this way, but that's good enough for us.

This means that we now have a choice of putting UTF-8 manual pages in
/usr/share/man// or /usr/share/man/.UTF-8/. Although
Adam made a valiant effort to persuade me otherwise, I still favour the
.UTF-8 suffix; it's explicit, and it means that if your man program
doesn't support UTF-8 (xman and yelp probably don't, for instance) then
you will get the English manual page rather than a pile of misencoded
garbage. Whether you think this is desirable probably depends on your
language; a misencoded French page would be mostly readable anyway,
while a misencoded Japanese page is entirely unusable.

However, I'm posting to debian-devel and debian-i18n about this to give
people the opportunity to advocate the other position. At this point,
neither choice will present major technical difficulties as far as
man-db is concerned. I would like to ask that people consider the
practicalities of other man implementations as well as pure aesthetic
concerns.


groff does not yet support UTF-8 input, so at the moment this is
implemented by recoding in man. For the time being, the implementation
requires that the page be convertible to the legacy encoding for the
language using iconv (it uses //TRANSLIT so that it will make an attempt
at characters that aren't directly convertible, but that isn't perfect);
so a German manual page should avoid using UTF-8 characters without an
equivalent in ISO-8859-1. I do not expect this to be particularly
onerous for the time being, though there are a few cases (particularly
proper names) where it may be a problem. I ask for your patience in
those cases. If you need to use a character not in the corresponding
legacy encoding, then I recommend using named character escapes as
documented in groff_char(7).


Once we have a consensus on install locations, dh_installman should IMO
be changed to do the recoding automatically; to do this, it needs to be
told the source encoding. Joey, what do you think is the best way to do
this? Options that come to mind are:

  * --language=.ISO-8859-1
  * --source-encoding=ISO-8859-1
  * manpage:ISO-8859-1 on the command line or in debian/package.manpages

It's worth noting that packages may well have manual pages in a number
of languages with a variety of encodings, so I'm not sure how well a
global --source-encoding option would work.

Of course the other option would be for dh_installman to DWIM and guess
the encoding in the same way man does. :-) The transition to UTF-8 would
happen much faster if maintainers didn't have to specify the encoding by
hand. If you'd like to take this approach I can add code to man-db as
necessary to help out.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Bug#446050: Liferea dies with sqlite 3.5

[Lars Lindner]

On 10/11/07, Nico Golde <[EMAIL PROTECTED]> wrote:
> Hi,
> * Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]> [2007-10-11 11:54]:
> > tag 446050 help
> > thanks
> >
> > The current version of liferea in Debian unstable (1.4.3-1), as well
> > as the latest upstream version (1.4.5) fail if used together with
> > libsqlite3-0 from experimental (3.5.1-1). The program works correctly
> > with the versions in testing and unstable (3.4.2-1, 3.4.2-2).
> >
> > The following error mesage is printed to the console:
> >
> > *** glibc detected *** /usr/bin/liferea-bin: free(): invalid pointer: 
> > 0x08514040 ***
> [...]
> The reason might be the change in sqlite3_free. In prior
> versions it did the same like free but now it does some
> additional mutex stuff for example. Maybe some free needs to
> be changed to sqlite3_free (you'll see in a backtrace).

This was the critical hint. Thanks again!

Fixed upstream with Liferea release 1.4.5b.
Patch against 1.4.5 is attached.

Best Regards,
Lars
Index: src/db.c
===
--- src/db.c	(Revision 3481)
+++ src/db.c	(Arbeitskopie)
@@ -1304,7 +1304,7 @@
 	if (SQLITE_OK != res) 
 		debug2 (DEBUG_DB, "Create view failed (%s) SQL: %s", err, sql);
 			   
-	g_free (select);
+	sqlite3_free (select);
 	sqlite3_free (sql);
 	sqlite3_free (err);
 }

Re: using testing/stable/unstable names with cdebootstrap

[Goswin von Brederlow]

Vincent Danjean <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> Ritesh Raj Sarraf <[EMAIL PROTECTED]> writes:
>> 
>>> Hi,
>>>
>>> Is there a reason to not use stable/testing/unstable as the names in 
>>> config/suites file ?
>>>
>>> Currently it only has code names like etch/lenny/sid.
>>>
>>> Ritesh
>> 
>> Does it matter anywhere? You can use testing as suite name on
>> invocation and it will see that testing currently is lenny and use
>> that.
>
> How will it know the corresponding between the 'hard' code name (ie etch)
> and the logical code name (ie stable) ? Do not forget that this is the
> *same* package that will be in unstable, then testing, stable and oldstable.
> So this cannot be hardcoded in the program.
>   Perhaps cdebootstrap can look at somewhere on the net (I do not use
> cdebootstrap myself, so I do not know). But this feature (allowing testing, 
> ...)
> cannot be solved just by adding aliases directly in the package itself.
>
>   Best regards,
> Vincent

That is really simple. You parse dists/testing/Release and got the
codename. Cdebootstrap already does this just fine afaik. At least you
can bootstrap a testing and it will use lenny and so on.

MfG
Goswin


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

Bug#446255: ITP: svn-pusher -- Propagate changesets between two different svn repositories

[Piotr Roszatycki]

X-Debbugs-CC: debian-devel@lists.debian.org
Package: wnpp
Owner: Piotr Roszatycki <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: svn-pusher
  Version : 0.04
  Upstream Author : Shlomi Fish <[EMAIL PROTECTED]>
* URL : http://web-cpan.berlios.de/modules/SVN-Pusher/
* License : Perl (Artistic or GPL)
  Programming Lang: Perl
  Description : Propagate changesets between two different svn repositories

svn-pusher is a command line utility that allows one to propagate ("push")
changesets between two repositories even if the destination is not at
local filesystem.

svn-pusher allows to propagate just a part of the whole repository:
single directory or the part of repository history. This tool also can
be used for creating the exact copy of existing repository.

-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-



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

Re: Bug#445866: ITP: perforce -- closed source revision control system

[Jon Dowland]

On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. Sánchez wrote:
> Given the great abundance of revision control systems already packaged
> for Debian, what is the point of adding another?  Especially when it is
> non-free.

Firstly, as it is non-free, it isn't really going "into Debian".
Secondly, if someone wants to package it, and other people use it, why
shouldn't it?

It seems every other semi-controversial ITP gets an obligatory "why
package this when we have X,Y,Z instead?" reply, although seemingly
never from an ftp-master or mirror maintainer or anyone else who is
actually impacted by archive sizes :-(

-- 
Jon Dowland


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

keep Packages.IndexDiff for two weeks please

[jidanni]

Can somebody up the time the Packages.IndexDiff and associated files
are kept on the mirrors from one week to two please? These very few
more bytes would save low bandwidth users hours in case they don't
return home within the seven days currently allotted.


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

Re: Bug#445866: ITP: perforce -- closed source revision control system

[Josselin Mouette]

Le jeudi 11 octobre 2007 à 15:01 +0100, Jon Dowland a écrit :
> It seems every other semi-controversial ITP gets an obligatory "why
> package this when we have X,Y,Z instead?" reply, although seemingly
> never from an ftp-master or mirror maintainer or anyone else who is
> actually impacted by archive sizes :-(

Archive size not so much a concern as archive *quality*. There is
trouble maintaining the quality level reasonable for each packages when
there are so many packages.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: UTF-8 manual pages

[Joey Hess]

Colin Watson wrote:
> Once we have a consensus on install locations, dh_installman should IMO
> be changed to do the recoding automatically; to do this, it needs to be
> told the source encoding. Joey, what do you think is the best way to do
> this? Options that come to mind are:
> 
>   * --language=.ISO-8859-1
>   * --source-encoding=ISO-8859-1
>   * manpage:ISO-8859-1 on the command line or in debian/package.manpages
> 
> It's worth noting that packages may well have manual pages in a number
> of languages with a variety of encodings, so I'm not sure how well a
> global --source-encoding option would work.
> 
> Of course the other option would be for dh_installman to DWIM and guess
> the encoding in the same way man does. :-) The transition to UTF-8 would
> happen much faster if maintainers didn't have to specify the encoding by
> hand. If you'd like to take this approach I can add code to man-db as
> necessary to help out.

Bear in mind that my skills at messing about with encodings are such
that I left #441812 open rather than try to figure out how to recode
those man pages from utf-8 to something old man could support -- because
I failed miserably for an hour trying to do the recoding. :-)

I don't much like any of the switch ideas, since they would probably
not be able to express all possible collections of man pages (given
debhelper's current command line parser). The manpage:encoding idea
could work, but might have ambiguity issues with man pages with colons
in their name (perl ones have two colons, but I'll bet there are some
with one). I'd be ok with DWIM here if it worked the same way man does,
perhaps by using manconv directly?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Intend to hijack gpsd

[Fathi Boudra]

Hi,

> The maintainer was pinged by the main sponsor (pere) and me without any
> reaction, also the last upload (in February) containing i18n patches
> only happened after a ping by mail and an offer to sponsor the upload
> (done by bubulle).

I pinged current maintainer around june too, without any reply.
so far, I use my own local package using gpsd 2.34.

cheers,

Fathi


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

Bug#446292: ITP: libtext-bidi-perl -- Unicode bidi algorithm using libfribidi

[Lior Kaplan]

Package: wnpp
Severity: wishlist
Owner: Lior Kaplan <[EMAIL PROTECTED]>


* Package name: libtext-bidi-perl
  Version : 0.03
  Upstream Author : Moshe Kamensky <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~kamensky/Text-Bidi-0.03/
* License : Artistic
  Programming Lang: Perl
  Description : Unicode bidirectional (BiDi) algorithm using libfribidi

This module provides basic support for the Unicode bidirectional text (Bidi) 
algorithm, for displaying text consisting of both left-to-right and 
right-to-left written languages (like Hebrew and Arabic.) It does so using a 
swig interface file to the libfribidi library.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-k7 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Mad promo!

[Rob Pool]

Our X X X Network for FREE today!
www madpromo dot cn

elaborates tridepside
Epstein comanagers


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

Re: Bug#445866: ITP: perforce -- closed source revision control system

[Russ Allbery]

Jon Dowland <[EMAIL PROTECTED]> writes:

> It seems every other semi-controversial ITP gets an obligatory "why
> package this when we have X,Y,Z instead?" reply, although seemingly
> never from an ftp-master or mirror maintainer or anyone else who is
> actually impacted by archive sizes :-(

Consider it an expression of increasing resistance designed to make people
think twice.  I think it's useful even when not enforced.  If one is
convinced that the package is needed, one can always go ahead anyway, but
the resistance provides useful feedback and sometimes identifies packages
that are really unnecessary for reasons that the prospective packager
didn't realize.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: UTF-8 manual pages

[Junichi Uekawa]

Hi,

> o Per-locale directory handling has been improved. Directories such
>   as "fr.UTF-8" may be used for occasions when it is appropriate to
>   specify the character set but not the country, and so a full
>   locale name is inconvenient.
> 
> o There is a new "manconv" program which can try multiple possible
>   encodings for a file, thus allowing UTF-8 manual pages to be
>   installed in any directory even without an explicit encoding
>   declaration.

This is cool.

A great workaround for that compatibility mess RedHat has created for US.

I assume UTF-8 / local-encoding detection can fail sometimes; which
encoding has precedence?



regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Bug#446316: ITP: ptop -- ptop is a utility that displays current state of PostgreSQL processes

[Adam Majer]

Package: wnpp
Severity: wishlist
Owner: Adam Majer <[EMAIL PROTECTED]>

* Package name: ptop
  Version : 3.6.1~b1
  Upstream Author : Mark Wong <[EMAIL PROTECTED]>
* URL : http://pgfoundry.org/projects/ptop/
* License : BSD License
  Programming Lang: C
  Description : ptop is a utility that displays current state of PostgreSQL 
processes

ptop is a utility that provides a display of top PostgreSQL processes
and other database statistics such as:
 - Current queries,
 - Query plans,
 - Locks,
 - User table statistics, and
 - User index statistics


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (5, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-k7 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

migration and installation 50 THOUSAND machines

[andremachado]

Hello,
As PART of a study about using Debian GNU / Linux for a massive deployment from 
5 thousand
up to 50 thousand machines (desktops AND servers) geographically distributed 
across a country,
I searched for some installation, configuration and config management tools for 
this task size [0], [1], [2].
Please, verify if a relevant tool is missing or if there are errors and or 
omissions.
I found the Alexander Zangerl texts [3] as a good starting point for a broader 
text.
They are the most aligned with the study objectives that I was able to find.
Do you have some ideas?
Some information about why Debian is suitable for this task?
What tools are suitable for some of the remaining tasks: managing systems, user
accounts, monitoring such big deployment?
Do you have some url more suitable for reading?
The similar sized and profile Debian deployment I can remember is Munich [4], 
[5].
Regards.
Andre Felipe Machado

[0]
http://www.techforce.com.br/index.php/news/linux_blog/massive_installation_management_tools_p_1
[1]
http://www.techforce.com.br/index.php/news/linux_blog/massive_installation_management_tools_p_2
[2]
http://www.techforce.com.br/index.php/news/linux_blog/massive_installation_management_tools_p_3
[3] http://people.debian.org/%7Eaz/
[4] http://wiki.debian.org/PressCoverage2006
[5] http://wiki.debian.org/PressCoverage2007




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

Bug#446321: ITP: docbook-xsl-xalan -- Java extensions for use with DocBook XML stylesheets (Xalan)

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: docbook-xsl-xalan
  Version : 1.00
  Upstream Author : Norman Walsh and members of the DocBook project.
* URL : http://wiki.docbook.org/topic/DocBookXsltExtensions
* License : MIT/X
  Programming Lang: Java
  Description : Java extensions for use with DocBook XML stylesheets (Xalan)

These are Java extensions for use with the DocBook XML stylesheets
and the Xalan XSLT engine. You need these extensions to enable e.g.
the callouts and linenumbering extensions of the docbook-xsl suite.
.
In the past these extensions were shipped with the docbook-xsl
tarball


I already began packaging at
http://svn.debian.org/wsvn/debian-xml-sgml/packages/docbook-xsl-xalan/trunk/?rev=0&sc=0.

Regards, Daniel


- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.21.5 (PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHDsUsm0bx+wiPa4wRAkZqAJ9jTJFyGoHxrFCM7/pH+5RaNvs0dACfXSLu
o45frqVgA1a5PrakXjkOa5s=
=B2LB
-END PGP SIGNATURE-



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

Re: migration and installation 50 THOUSAND machines

[Martin Langhoff]

Hi Andre,

I would suggest using most of the ideas outlined in
http://infrastructures.org/ - though the text on the website is a bit
dated, you can manage a large infrastructure of 50K systems combining
the conceptual framework laid out by Steve Traugott, with Debian tools
and modern configuration tools (cfengine, puppet). Having said that, I
am still deeply impressed by the simple approach of using makefiles
that drives the originall version of IsConf.

An intriguing project that might be "the missing piece" is IsiSetup -
http://www.isisetup.ch/ - but haven't had the time to review it or use
it. If it does what it promises - integration with apt/dpkg to store
config files of debian packages in a git repo to allow management of
machine configuration as an extension of the apt/dpkg infrastrucuture,
it could be a killer app.

good luck!


m


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

Work-needing packages report for Oct 12, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 314 (new: 1)
Total number of packages offered up for adoption: 77 (new: 4)
Total number of packages requested help for: 35 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   motion (#445750), orphaned 3 days ago
 Description: V4L capture program supporting motion detection
 Installations reported by Popcon: 737

313 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   kbd (#446030), offered 2 days ago
 Description: Linux console font and keytable utilities
 Reverse Depends: console-common console-cyrillic console-log
   console-setup-udeb console-terminus fonty hibernate ltsp-client-core
   svgatextmode
 Installations reported by Popcon: 496

   libtut (#446162), offered yesterday
 Installations reported by Popcon: 39

   poppass-cgi (#446141), offered yesterday
 Installations reported by Popcon: 17

   xar (#446003), offered 2 days ago
 Description: eXtensible ARchiver
 Reverse Depends: libxar1-dev xar
 Installations reported by Popcon: 56

73 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 840 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core
 Installations reported by Popcon: 119

   apt-build (#365427), requested 530 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 859

   apt-show-versions (#382026), requested 429 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 3052

   athcool (#278442), requested 1080 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 290

   cvs (#354176), requested 595 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (15
   more omitted)
 Installations reported by Popcon: 21173

   dpkg (#282283), requested 1055 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb clamsmtp crosshurd (88 more
   omitted)
 Installations reported by Popcon: 66817

   elvis (#432298), requested 94 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 312

   gentoo (#422498), requested 158 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 283

   grub (#248397), requested 1249 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild replicator
 Installations reported by Popcon: 61374

   ispell-et (#391105), requested 372 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 52

   kradio (#429873), requested 113 days ago
 Description: Comfortable Radio Application for KDE
 Installations reported by Popcon: 294

   loop-aes-utils (#385614), requested 406 days ago
 Description: Tools for mounting and manipulating filesystems
 Reverse Depends: loop-aes-modules-2.6.22-2-486
   loop-aes-modules-2.6.22-2-4kc-malta loop-aes-modules-2.6.22-2-686
   loop-aes-modules-2.6.22-2-686-bigmem
   loop-aes-modules-2.6.22-2-alpha-generic
   loop-aes-modules-2.6.22-2-alpha-legacy
   loop-aes-modules-2.6.22-2-alpha-smp loop-aes-modules-2.6.22-2-amd64
   loop-aes-modules-2.6.22-2-footbridge
   loop-aes-modules-2.6.22-2-iop32x (33 more omitted)
 Installations reported by Popcon: 737

   mc (#380999), requested 436 days ago
 Description: midnight commander - a powerful file manager
 Reverse Depends: junior-system
 Installations reported by Popcon: 15657

   mol (#436450), requested 65 days ago
 Description: The Mac-on-Linux emulator
 Reverse Depends: mol-drivers-linux mol-drivers-macos
   mol-drivers-macosx mol-modules-source
 Installations reported by Popcon: 70

   mwavem (#313369), requested 850 days ago (non

Re: migration and installation 50 THOUSAND machines

[Henning Glawe]

On Thu, Oct 11, 2007 at 05:58:16PM -0700, andremachado wrote:
> Please, verify if a relevant tool is missing or if there are errors and or 
> omissions.

well, as one of the FAI developers I must say that it is _very_ well suited for
system management (using the "softupdate" feature and a SCM like cvs or svn
to store the configuration...). I am using it in a team to administrate
something like 300 machines (ok, not as big as your intended setup...), and
this since early 2002 in a very heterogenous environment (servers, desktops,
hpc cluster nodes are reading the same configuration space, distinguished by
different sets of classes). Softupdates are mass-deployed in our case using a
perl/curses frontend I hacked together called fai-updater [1].
In my experience, a FAI setup like this scales quite well (although the
updating frontend FAI-updater would need some improvements to scale better).

[1] http://faiwiki.informatik.uni-koeln.de/index.php/Fai-updater


-- 
c u
henning


signature.asc
Description: Digital signature

Re: migration and installation 50 THOUSAND machines

[Bernd Zeimetz]

Hi,


> As PART of a study about using Debian GNU / Linux for a massive deployment 
> from 5 thousand
> up to 50 thousand machines (desktops AND servers) geographically distributed 
> across a country,

[...]

> Do you have some url more suitable for reading?
> The similar sized and profile Debian deployment I can remember is Munich [4], 
> [5].

Exactly, that's why I'd also recommend the tools they're using there:
- FAI: http://www.informatik.uni-koeln.de/fai/
- GOsa: http://www.gosa-project.org/ (which not only provides a user
management but also ways to configure and deploy machines using FAI)
Please not that I didn't test them on such a large system personally,
but I'm pretty sure thy can handle it.

For monitoring there're several tools available, like nagios, cacti,
zenoss (will be soon in Debian, but you need to enterprise version to
handle 5 computers in _one_ frontend) and several other opensource
and commercial systems - but I'm not sure which one is capable to handle
so many hosts.

Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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