Re: [DebianGIS-dev] maps / coastline files within Debian

[Bernd Zeimetz]

Francesco P. Lovergine wrote:
> On Tue, Jun 16, 2009 at 10:12:02PM +0100, Alastair McKinstry wrote:
>> Does anyone know this code? It appears as though the gmt-coast-low is  
>> not sufficient for zyGrib and magics++,
>> and I'm not familiar with the history of "gmt" beyond the README.  Any  
>> ideas or recommendations as to how to proceed?
>>
> 
> Just for note, the downloading script can be used in non interactive
> way so a debconf based postinst step to download at installation 
> (or any later) time the required files could be considered. I'm too 
> lazy to provide that myself, but a patch for that could be considered for 
> the gmt data package could be useful. 
> 
> That said, the whole arch-indep 
> data set is probably much less a concerning for storage of some years
> ago, but that could be confirmed only by ftp-masters and mirror
> maintainers. There were some discussions in the past about a data
> providing infrastructure, but I missed the whole thread conclusion
> (if any).
> 

We're still waiting for the necessary hardware (mainly: storage) to be 
sponsored...

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


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

Bug#535455: ITP: libstring-rewriteprefix-perl -- rewrite strings based on a set of known prefixe

[eloy]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyżaniak (eloy)" 


* Package name: libstring-rewriteprefix-perl
  Version : 0.004
  Upstream Author : Ricardo SIGNES 
* URL : http://search.cpan.org/dist/String-RewritePrefix/
* License : Perl (Artistic/GPL)
  Programming Lang: Perl
  Description : rewrite strings based on a set of known prefixe

String::RewritePrefix rewrites strings based on a set of known prefixes.

(... and that's it. String::RewritePrefix is demanded by new libcatalyst-perl 
module)



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

Re: Dueling Banjoes

[Andrew Hooper]

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

Bug#535461: ITP: libkal -- library for converting dates between various calendar systems

[أحمد المحمودي]

Package: wnpp
Severity: wishlist
Owner: "أحمد المحمودي" 


* Package name: libkal
  Version : 0.9.0
  Upstream Author : Petr Tomasek 
* URL : http://www.etf.cuni.cz/~tomasek/pub/
* License : LGPL2
  Programming Lang: C
  Description : library for converting dates between various calendar 
systems
 The 'libkal' library provides support for converting dates between various
 calendar systems (currently only julianic, gregorianic, arabic and jewish
 ones) and some more related stuff.
 .
 The basic idea of this library is, that any date in any calendar system can be
 converted to a single number, which express the number of days since some
 fixed date in the past. libkal uses the so-called 'julianic date'(jd), that is
 used in Astronomy (not exactly).



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

Re: Dueling Banjoes

[Andrea Bolognani]

We haven't got multiarch yet, and you ask for multibanjos support already?

That's pretty rude if you ask me.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


pgpa82LhbtB8l.pgp
Description: PGP signature

Re: Dueling Banjoes

[Carlos Laviola]

On Thu, Jul 2, 2009 at 12:03, Andrea Bolognani wrote:
> We haven't got multiarch yet, and you ask for multibanjos support already?
>
> That's pretty rude if you ask me.

Alas, Dueling Banjos are an old unanswered request from various users:
http://www.debian.org/News/project/2003/37/


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

Re: A standard patch rule for our rules

[Andreas Metzler]

Ben Finney  wrote:
[...]

> It seems to me that the whole point of adding ‘patch’ as a (phony)
> target is to allow a dependency on that target, 
[...]

Hello,
Being used as dependencies of non-phony targets is the one thing phony
targets are not useful for. A phony dependency is always out of date
and will cause rerunning of the depending target.

(I am pretty sure you knew that, and I am just misparsing.)

I do not know what is wrong with having patch a phony target, though,
phony target are fine for direct invocation (debian/rules patch) and
that seems to be whole point of the respective entry in policy.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

CDPATH and shell scripts

[Goswin von Brederlow]

Hi,

it seems to me that the current CDPATH behaviour is verry strange and
extremly dangerous for shell scripts.

For those that have never heart of CDPATH it does 2 things:

1) a relative "cd" command with search the CDPATH for the given
   directory. If unset then '.' is used.

2) it outputs the path it used to stdout.

Now say you have the following script:

#! /bin/sh

cd /tmp
mkdir src
cd src
: do something
FOO=$(cd bar && cat blub)
rm -rf *
cd ..
rmdir src

Calling that with CDPATH=~ exported will 'rm -rf ~/src'. That will be
fun. It also suddenly outputs to stdout totally changing the value of
FOO.


So what is the right course of action here?

1) unset CDPATH in every single shell script there is?
2) never use relartive paths for cd in scripts?
3) shoot the user for doing something dumb?
4) disable CDPATH in /bin/sh (or is that POSIX?) or non-interactive
   scripts (would break automake I think)

MfG
Goswin


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

Re: Dueling Banjoes

[Gunnar Wolf]

Andrea Bolognani dijo [Thu, Jul 02, 2009 at 05:03:37PM +0200]:
> We haven't got multiarch yet, and you ask for multibanjos support already?
> 
> That's pretty rude if you ask me.

But bibanjo can perfectly solve the needs at hand, with the hardware
at hand.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Bug#535501: ITP: roxterm -- A multi-tabbed GTK terminal emulator

[Tony Houghton]

Package: wnpp
Severity: wishlist
Owner: Tony Houghton 


* Package name: roxterm
  Version : 1.15.1
  Upstream Author : Tony Houghton 
* URL : http://roxterm.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : A multi-tabbed GTK+2 terminal emulator application

ROXTerm is a terminal emulator intended to provide similar features to
gnome-terminal, based on the same VTE library, but with a smaller footprint
and quicker start-up time. It achieves this by not using the Gnome libraries
and by using a separate applet to provide the configuration GUI. It can be
used as a ROX application, as the name implies, or in any other X environment.



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

Re: Bug#535501: ITP: roxterm -- A multi-tabbed GTK terminal emulator

[Cyril Brulebois]

Tony Houghton  (02/07/2009):
> Package: wnpp
> Severity: wishlist
> Owner: Tony Houghton 
> 
> 
> * Package name: roxterm
>   Version : 1.15.1
>   Upstream Author : Tony Houghton 
> * URL : http://roxterm.sourceforge.net/
> * License : GPL
>   Programming Lang: C
>   Description : A multi-tabbed GTK+2 terminal emulator application
> 
> ROXTerm is a terminal emulator intended to provide similar features to
> gnome-terminal, based on the same VTE library, but with a smaller footprint
> and quicker start-up time. It achieves this by not using the Gnome libraries
> and by using a separate applet to provide the configuration GUI. It can be
> used as a ROX application, as the name implies, or in any other X environment.

$ rmadison roxterm
   roxterm | 1.11.1-1.1 |stable | source, alpha, amd64, arm, armel, 
hppa, i386, ia64, mipsel, powerpc
   roxterm | 1.11.1-1.1+b1 |stable | mips, s390, sparc
   roxterm |   1.12.2-1 |   testing | source, alpha, amd64, armel, hppa, 
i386, ia64, mips, mipsel, powerpc, s390, sparc
   roxterm |   1.12.2-1 |  unstable | source, alpha, amd64, armel, hppa, 
hurd-i386, i386, ia64, mips, mipsel, powerpc, s390, sparc

Closing this bug.

Mraw,
KiBi.


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

Re: Bug#535501: ITP: roxterm -- A multi-tabbed GTK terminal emulator

[Carsten Hey]

On Thu, Jul 02, 2009 at 06:36:37PM +0100, Tony Houghton wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Tony Houghton 

Please rename the existing RFA bug (#535246) instead of filing a new
one, e.g. by using /usr/bin/bts from the package devscripts.

>   Upstream Author : Tony Houghton 

And please _don't_ upload a native package ;)

debian-ment...@lists.debian.org and #debian-mentors on irc.oftc.net are
good places to find sponsors or ask questions.


Carsten


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

multiarch and maintainer scripts

[Goswin von Brederlow]

Hi,

what can be done if the maintainer scripts of a package must behave
differently when unpacking the i386 deb on i386 or the i386 deb on
amd64?

For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on
i386 but /usr/lib32/libGL.so.1.2 on amd64.

Other examples would be packages that scan for plugins in their
postinst to generate a list of them. Pango and gtk used to do
that. Even if they are changed the multiarch library dirs they should
probably continue to scan the old plugin dirs for backward
compatibility.


So would it make sense to allow architecture specific maintainer
scripts? Back to the fglrx-glx example the control.tar.gz could
contain:

preinst-amd64 - use when configuring on amd64
preinst   - use otherwise

I choose '-' so it doesn't collide with debhelpers preinst.amd64
source files.

MfG
Goswin


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

Re: CDPATH and shell scripts

[Michael Tautschnig]

[...]
> So what is the right course of action here?
> 
> 1) unset CDPATH in every single shell script there is?
> 2) never use relartive paths for cd in scripts?
> 3) shoot the user for doing something dumb?
> 4) disable CDPATH in /bin/sh (or is that POSIX?) or non-interactive
>scripts (would break automake I think)
> 

Looking at some autoconf-generated configure script I've found the following:


# The HP-UX ksh and POSIX shell print the target directory to stdout
# if CDPATH is set.
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH


I had once stumbled over this problem and ever since I keep using

cd bla > /dev/null

whenever the output could possibly trouble me. But well, actually, unsetting
CDPATH would be more appropriate.

Best,
Michael



pgpbQZmW16g4o.pgp
Description: PGP signature

Re: multiarch and maintainer scripts

[Russ Allbery]

Goswin von Brederlow  writes:

> what can be done if the maintainer scripts of a package must behave
> differently when unpacking the i386 deb on i386 or the i386 deb on
> amd64?
>
> For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on
> i386 but /usr/lib32/libGL.so.1.2 on amd64.

Surely this is as simple as:

case `dpkg --print-architecture` in
amd64)
# Do some stuff.
;;
i386)
# Do some other stuff.
;;
esac

isn't it?

-- 
Russ Allbery (r...@debian.org)   


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

Re: CDPATH and shell scripts

[Jonathan Yu]

Hi:

There are lots of variables which do nasty things.

In particular (copying this from perldoc of a module I wrote):
PATH

PATH provides a list of paths to search for executables, which
influences which commands are invoked by unqualified calls to system()
and others. This variable is particularly dangerous because even if
you use a fully qualified call to the executable, like "/usr/bin/echo
..." -- there is still a security hole, since echo could be executing
unqualified code itself.

The safest way to handle this, and the strategy used by this module,
is to remove everything except /usr/bin and /usr/local/bin (or
equivalent, depending on your operating system).
CDPATH

CDPATH provides additional paths for cd to search on the system when
it is called. This is dangerous because you could be attempting to
change into a known safe directory, but the CDPATH may divert you to
another directory. The variable is generally of limited usefulness,
and so is removed completely during %ENV scrubbing.
IFS

IFS is the Internal Field Separator, which tells the operating system
what characters should be considered whitespace separating command
line arguments. Combined with controlling PATH, this exposes a very
dangerous vulnerability: if the IFS is set to '/', then
system('/bin/more') is essentially the same as system('bin more'). As
a result, the 'bin' command is executed instead of '/bin/more' as
expected.
ENV and BASH_ENV

ENV and BASH_ENV list files that are executed whenever a new shell is
started, which includes whenever a shell script (.sh) is run.

Okay. So what? These issues have existed for a long time.

How to fix them? Write Perl scripts, and turn on taint checking --
that fixes the four issues above, because it makes the script exit if
any of them look dangerous. Env::Sanctify::Auto is a Perl module that
automatically cleans up the paths.

My advice:
1. Write scripts that might be run as root (or setuid root) using Perl
2. Turn on taint checking
3. Consider using Env::Sanctify::Auto (shameless plug)

Cheers,

Jonathan

On Thu, Jul 2, 2009 at 4:22 PM, Michael Tautschnig wrote:
> [...]
>> So what is the right course of action here?
>>
>> 1) unset CDPATH in every single shell script there is?
>> 2) never use relartive paths for cd in scripts?
>> 3) shoot the user for doing something dumb?
>> 4) disable CDPATH in /bin/sh (or is that POSIX?) or non-interactive
>>    scripts (would break automake I think)
>>
>
> Looking at some autoconf-generated configure script I've found the following:
>
> 
> # The HP-UX ksh and POSIX shell print the target directory to stdout
> # if CDPATH is set.
> (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
> 
>
> I had once stumbled over this problem and ever since I keep using
>
> cd bla > /dev/null
>
> whenever the output could possibly trouble me. But well, actually, unsetting
> CDPATH would be more appropriate.
>
> Best,
> Michael
>
>


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

Re: multiarch and maintainer scripts

[Goswin von Brederlow]

Russ Allbery  writes:

> Goswin von Brederlow  writes:
>
>> what can be done if the maintainer scripts of a package must behave
>> differently when unpacking the i386 deb on i386 or the i386 deb on
>> amd64?
>>
>> For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on
>> i386 but /usr/lib32/libGL.so.1.2 on amd64.
>
> Surely this is as simple as:
>
> case `dpkg --print-architecture` in
> amd64)
> # Do some stuff.
> ;;
> i386)
> # Do some other stuff.
> ;;
> esac
>
> isn't it?

That is another possibility. Is that the solution we (as in Debian)
want?

MfG
Goswin


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

Re: CDPATH and shell scripts

[Russ Allbery]

Jonathan Yu  writes:

> How to fix them? Write Perl scripts, and turn on taint checking --
> that fixes the four issues above, because it makes the script exit if
> any of them look dangerous. Env::Sanctify::Auto is a Perl module that
> automatically cleans up the paths.
>
> My advice:
> 1. Write scripts that might be run as root (or setuid root) using Perl
> 2. Turn on taint checking
> 3. Consider using Env::Sanctify::Auto (shameless plug)

I would really prefer that people not start writing maintainer scripts
in Perl as a matter of course.  Perl is harder to analyze for programs
like lintian than shell scripts (which are already hard enough).

-- 
Russ Allbery (r...@debian.org)   


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

Re: CDPATH and shell scripts

[Jonathan Yu]

On Thu, Jul 2, 2009 at 5:26 PM, Russ Allbery wrote:
> Jonathan Yu  writes:
>
>> How to fix them? Write Perl scripts, and turn on taint checking --
>> that fixes the four issues above, because it makes the script exit if
>> any of them look dangerous. Env::Sanctify::Auto is a Perl module that
>> automatically cleans up the paths.
>>
>> My advice:
>> 1. Write scripts that might be run as root (or setuid root) using Perl
>> 2. Turn on taint checking
>> 3. Consider using Env::Sanctify::Auto (shameless plug)
>
> I would really prefer that people not start writing maintainer scripts
> in Perl as a matter of course.  Perl is harder to analyze for programs
> like lintian than shell scripts (which are already hard enough).

I agree that all too often many build systems are sort of centered
around Perl, and that can be a bad thing, in terms of maintainability.
On the other hand I don't think Perl is always unmaintainable -- it
depends on the programmer.

I suppose though that shell scripts are simpler and thus present less
of a cognitive load for programmers, so that might be why it's
perceived to be more maintainable/easier to analyze.

On the other hand, you're going to run into security issues due to the
aforementioned variables, in any language that doesn't provide a check
(like Perl's taint mode).

Perhaps it could be established in Policy as a best practice to set
those environment variables at the beginning of execution, and carry
them throughout. Or to use a simple Perl or Shell script wrapper which
would clear all those variables before exec'ing to the desired
command.

Security versus convenience is a common debate, and it's no different here.

Another option might be to break from POSIX/etc policy (I'm not sure
where these variables are defined) and patch our command like 'cd' to
simply ignore 'CDPATH' etc. But I suppose this would then require
patches in all the various shells available for Debian to go against
something standardized for so long.

It's a contentious issue. I wish everyone all the best trying to
figure it out, it's scary stuff indeed.

Cheers,

Jonathan


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

Re: CDPATH and shell scripts

[Goswin von Brederlow]

Russ Allbery  writes:

> Jonathan Yu  writes:
>
>> How to fix them? Write Perl scripts, and turn on taint checking --
>> that fixes the four issues above, because it makes the script exit if
>> any of them look dangerous. Env::Sanctify::Auto is a Perl module that
>> automatically cleans up the paths.
>>
>> My advice:
>> 1. Write scripts that might be run as root (or setuid root) using Perl
>> 2. Turn on taint checking
>> 3. Consider using Env::Sanctify::Auto (shameless plug)
>
> I would really prefer that people not start writing maintainer scripts
> in Perl as a matter of course.  Perl is harder to analyze for programs
> like lintian than shell scripts (which are already hard enough).
>
> -- 
> Russ Allbery (r...@debian.org)   

Not to mention humans. :)

MfG
Goswin


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

Re: CDPATH and shell scripts

[Jonathan Yu]

On Thu, Jul 2, 2009 at 5:44 PM, Goswin von Brederlow wrote:
> Russ Allbery  writes:
>
>> Jonathan Yu  writes:
>>
>>> How to fix them? Write Perl scripts, and turn on taint checking --
>>> that fixes the four issues above, because it makes the script exit if
>>> any of them look dangerous. Env::Sanctify::Auto is a Perl module that
>>> automatically cleans up the paths.
>>>
>>> My advice:
>>> 1. Write scripts that might be run as root (or setuid root) using Perl
>>> 2. Turn on taint checking
>>> 3. Consider using Env::Sanctify::Auto (shameless plug)
>>
>> I would really prefer that people not start writing maintainer scripts
>> in Perl as a matter of course.  Perl is harder to analyze for programs
>> like lintian than shell scripts (which are already hard enough).
>>
>> --
>> Russ Allbery (r...@debian.org)               
>
> Not to mention humans. :)
Oh.

I read that incorrectly in my reply. Yeah, analyzing Perl via lintian
is probably more difficult than shell script, and more likely to raise
false positives/etc.

Static code analysis is getting a little better with PPI, but Perl is
a *very* dynamic language, so it's hard to do analyze it without
executing it.

In that case, I'd recommend to establish some sort of best practice
using these variables, and put it in Policy. As in a contract that
programs:
1. Must not set these variables
2. Must not use these variables
3. Must set them to something sane within the scope of the current
execution (not necessarily exporting them)

So I guess really in practice that just requires people to do:
unset CDPATH
unset IFS
set PATH="/some/safe/path'

etc. All of these default/preferred values should be in Policy, and
users should be given a list of acceptable things to go in PATH -- for
example, allowing developers to use:
/usr/bin
/usr/local/bin

Then a developer is welcome to locally set PATH to a subset of those,
like PATH=/usr/bin -- of course we'd need to add something to lintian
to parse paths. There are, however, CPAN modules that can do that I
believe, and on Debian only it's as simple as split(':', $path)


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

Re: CDPATH and shell scripts

[Russ Allbery]

Jonathan Yu  writes:
> On Thu, Jul 2, 2009 at 5:26 PM, Russ Allbery wrote:

>> I would really prefer that people not start writing maintainer
>> scripts in Perl as a matter of course.  Perl is harder to analyze for
>> programs like lintian than shell scripts (which are already hard
>> enough).

> I agree that all too often many build systems are sort of centered
> around Perl, and that can be a bad thing, in terms of maintainability.
> On the other hand I don't think Perl is always unmaintainable -- it
> depends on the programmer.

Just to clarify, it's really not maintainability that I'm concerned
about.  It's automated analysis.  Take a look at checks/scripts,
checks/menus, checks/debconf, and checks/shared-libs in Lintian, among
others.  Currently, we mostly just bail if Perl is used for maintainer
scripts since it's much more difficult to do the sort of checks that
Lintian is doing against Perl scripts.  There are more ways of
expressing conditionals that are widely used, there's additional
punctuation and potential line wrapping in system() calls, and all sorts
of other issues.

Perl is a problem specifically because it's a richer language.  Any
other richer language would also be a problem.  For better or for ill,
Bourne shell is fairly straightforward, and while it has some odd
corners, it doesn't have that many syntactic quirks or that many
different ways of doing the same thing.  It also helps considerably that
the way to run an external program (which is much of what Lintian
checks) is to just run it, without additional syntax or function calls.

Note also that if you use Perl to write maintainer scripts but you're
using debhelper, you have to use somewhat strange workarounds to get the
debhelper fragments to be invoked, and those too are hard to analyze.

I've been quixotically proposing for several years that the ideal
solution would be to write a new interpreter specifically for maintainer
scripts that had a simple syntax and directly supported the 20-30 most
common things that one needs to do in a Debian maintainer script.  One
could start with anything that debhelper adds to maintainer scripts and
then add diversions, alternatives, deleting files and directories, and
maybe two or three other things.  Packages that need something more
complicated could fall back to shell or Perl as they do today, but I
suspect that writing an interpreter that could handle the maintainer
scripts for 90% of the packages in Debian would not be particularly
difficult, and it would also potentially hide a lot of complexity and
would be an opportunity to get the behavior right in all the tricky
error rollback cases.

Of course, I have no time to do the work.  :/

-- 
Russ Allbery (r...@debian.org)   


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

ia32-libs{-tools}, multiarch, squeeze

[Joerg Jaspert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello world,

(Please remember that we can only speak for ourselves and not the
security/release/any other teams, individuals or other sentient beings.)

During the recent discussion about about ia32-libs{,-gtk,-tools} there were
various requests for removal / comments about ftpmaster requirements for the
whole ia32-libs situation.

Having looked at the situation both in lenny and in sid, we tend to agree that
ia32-libs-tools in its current form is unacceptable.  It was mentioned in the
threads that comments had been received from ftpmaster that the lenny form of
ia32-libs (the one where all the source is duplicated in two huge packages -
ia32-libs and ia32-libs-gtk) was disliked.  This remains the case but it is
still preferable (both to us, and it seems to the majority of the rest of the
project) than the ia32-libs-tools approach.

Given that there are definitely use-cases for some form of ia32-libs, we
suggest that a version of ia32-libs{-gtk} is re-uploaded to Debian, replacing
the current ia32-libs-tools.  This needs agreement with the release and
security teams, as this most probably will have to be supported for squeeze in
some form (even if that includes admitting that we have no security support for
the binary ia32-libs packages).

The recent discussions on doing multiarch properly look promising and, even
better, there seems to be broad consensus that this is the right longer-term
direction.  The question is whether the first round could be ready for squeeze
so that we don't have to ship ia32-libs again.  This obviously depends on
people wanting (and having time) to work on it; hopefully more will be known
after the planned BoF at DebConf.  Just to make it clear, there are no
objections at all from ftpmaster to multiarch and we will make sure that any
archive-side changes which may be necessary will be performed so that we don't
block it (although looking at the current proposal from Steve Langasek et al,
we can't really see anything which should need changing).

This should drop the surprising effects users of the ia32-libs-tools packages
experienced in the last few days and also allow us to continue supporting users
of the 32 bit libraries.

This is, as ever, not a statement of the future, but suggestions and thoughts
on the matter.  It has mainly been written due to the fact that we have been
asked by multiple people to remove ia32-libs-tools but don't want to do so
until a consensus has been reached on what we're going to do to replace it.

Thanks,

- -- 
bye, Joerg
 Sesse: I doubt that many people will switch network
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKTTP/NIW6CNDsByMRAriyAKDRsW6oVKKoBNImJ2eTGPYDNq/aRgCcDB4i
H/46CNsPZeMYDMtTPMy5MI4=
=Txza
-END PGP SIGNATURE-


pgpTdiWNtmH0w.pgp
Description: PGP signature

Re: CDPATH and shell scripts

[Goswin von Brederlow]

Jonathan Yu  writes:

> Another option might be to break from POSIX/etc policy (I'm not sure
> where these variables are defined) and patch our command like 'cd' to
> simply ignore 'CDPATH' etc. But I suppose this would then require
> patches in all the various shells available for Debian to go against
> something standardized for so long.
>
> It's a contentious issue. I wish everyone all the best trying to
> figure it out, it's scary stuff indeed.
>
> Cheers,
>
> Jonathan

As a middle ground I wouldn't mind $SHELL to unset CDPATH when it
switches from an interactive shell to a non-interactive shell, when a
script with #! $SHELL is executed. That one is just to damn scary.

Also why does it output to stdout and not stderr?

MfG
Goswin


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

Re: ia32-libs{-tools}, multiarch, squeeze

[Goswin von Brederlow]

Joerg Jaspert  writes:

> Hello world,
>
> (Please remember that we can only speak for ourselves and not the
> security/release/any other teams, individuals or other sentient beings.)
>
> During the recent discussion about about ia32-libs{,-gtk,-tools} there were
> various requests for removal / comments about ftpmaster requirements for the
> whole ia32-libs situation.
>
> Having looked at the situation both in lenny and in sid, we tend to agree that
> ia32-libs-tools in its current form is unacceptable.  It was mentioned in the

Please do files bugs about issues you consider blockers for
ia32-libs-tools and squeeze and please include if that applies even if
there is the old ia32-libs in parallel to it (i.e. when it doesn't get
pulled in on upgrades).

> threads that comments had been received from ftpmaster that the lenny form of
> ia32-libs (the one where all the source is duplicated in two huge packages -
> ia32-libs and ia32-libs-gtk) was disliked.  This remains the case but it is
> still preferable (both to us, and it seems to the majority of the rest of the
> project) than the ia32-libs-tools approach.
>
> Given that there are definitely use-cases for some form of ia32-libs, we
> suggest that a version of ia32-libs{-gtk} is re-uploaded to Debian, replacing
> the current ia32-libs-tools.  This needs agreement with the release and
> security teams, as this most probably will have to be supported for squeeze in
> some form (even if that includes admitting that we have no security support 
> for
> the binary ia32-libs packages).

Also an agreement from Bdale Garbee  and/or Frederik
Schüler  to remain its maintainer or another
volunteer.


> The recent discussions on doing multiarch properly look promising and, even
> better, there seems to be broad consensus that this is the right longer-term
> direction.  The question is whether the first round could be ready for squeeze
> so that we don't have to ship ia32-libs again.  This obviously depends on
> people wanting (and having time) to work on it; hopefully more will be known
> after the planned BoF at DebConf.  Just to make it clear, there are no
> objections at all from ftpmaster to multiarch and we will make sure that any
> archive-side changes which may be necessary will be performed so that we don't
> block it (although looking at the current proposal from Steve Langasek et al,
> we can't really see anything which should need changing).

As per design. :)

There is only one thing that DAK might want to adapt to. For most
multiarch architectures there is a definite main architecture that
most things should be in and then some corner cases where different
architetcure might be prefered or required. Usualy because 32bit mode
has smaller code and is faster than 64bit mode but sometimes the
larger addresss space of 64bit mode is required.

So there might be a need to introduce partial architectures for ppc64,
mips64, mips64el, sparc64 that only carry a small subset of
Debian. The change would be in policy to allow architecture that are
partial and maybe some code to reject unwanted packages from those
architectures.

> This should drop the surprising effects users of the ia32-libs-tools packages
> experienced in the last few days and also allow us to continue supporting 
> users
> of the 32 bit libraries.

I hope most surprises are addresses in the current version, at least
those that aren't as designed. Please do continue to file bugs when
you run into something so it can be addressed in the package and other
people are spared from the surprise in the future.

> This is, as ever, not a statement of the future, but suggestions and thoughts
> on the matter.  It has mainly been written due to the fact that we have been
> asked by multiple people to remove ia32-libs-tools but don't want to do so
> until a consensus has been reached on what we're going to do to replace it.
>
> Thanks,
>
> -- 
> bye, Joerg
>  Sesse: I doubt that many people will switch network

MfG
Goswin


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

Bug#535524: ITP: libparse-exuberantctags-perl -- exuberant ctags parser for Perl

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libparse-exuberantctags-perl
  Version : 1.01
  Upstream Author : Steffen Mueller 
* URL : http://search.cpan.org/dist/Parse-ExuberantCTags/
* License : Artistic | GPL-1+, with included readtags library being PD
  Programming Lang: Perl
  Description : exuberant ctags parser for Perl
 Parse::ExuberantCTags parses ctags files and handles both traditional
 ctags as well as extended ctags files such as produced with Exuberant
 ctags. To the best of my knowledge, it does not handle emacs-style
 "etags" files.
 .
 The module is implemented as a wrapper around the readtags library
 that normally ships with Exuberant ctags. If you do not know what
 that is, you are encouraged to have a look at
 http://ctags.sourceforge.net/ and look at the exuberant-ctags
 package.



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

Re: CDPATH and shell scripts

[brian m. carlson]

On Fri, Jul 03, 2009 at 01:01:41AM +0200, Goswin von Brederlow wrote:
> As a middle ground I wouldn't mind $SHELL to unset CDPATH when it
> switches from an interactive shell to a non-interactive shell, when a
> script with #! $SHELL is executed. That one is just to damn scary.

I don't think that's permitted by SUSv3, and Policy says:

  Scripts may assume that /bin/sh implements the SUSv3 Shell Command
  Language

> Also why does it output to stdout and not stderr?

According to SUSv3 (and SUSv4) for the cd utility:

  If a non-empty directory name from CDPATH is used, or if cd - is used,
  an absolute pathname of the new working directory shall be written to
  the standard output as follows:
  
  "%s\n", 

The rationale states that CDPATH was taken from the SysV shell, and it
probably had that behavior.

If you're going to write a /bin/sh script, you need to be aware of the
environment and how it's going to affect your script.  For example, if
you don't want utilities (such as patch) to have POSIX behavior, you
need to unset POSIXLY_CORRECT and _POSIX2_VERSION.  If you don't want
cd to use CDPATH, you need to unset it.  You can probably do something
like

  unset `set | sed -re 's/^([^=]+)=.*$/\1/g' | grep -E '^[A-Za-z0-9]' | grep 
-vE '^(PS|PATH|TERM)'` 2>/dev/null

to get a "clean" environment.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: multiarch and maintainer scripts

[Guillem Jover]

Hi!

On Thu, 2009-07-02 at 13:58:48 -0700, Russ Allbery wrote:
> Goswin von Brederlow  writes:
> > what can be done if the maintainer scripts of a package must behave
> > differently when unpacking the i386 deb on i386 or the i386 deb on
> > amd64?

We discussed this with Steve some days ago. My initial idea was to
make “dpkg --print-architecture” polymorphic, and change what it
prints depending on what architecture the package being installed is.

That would require less packaging changes, but it seems pretty
fragile and non-obvious behaviour, and we have several packages using
“uname -m”, they'd need to be changed due to this or just to
multiarchify them anyway, so we discarded it.

But yesterday I came up with a simpler and cleaner solution, just
export an env var matching the package arch being installed. Something
like DPKG_MAINTSCRIPT_ARCH or similar.

> > For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on
> > i386 but /usr/lib32/libGL.so.1.2 on amd64.

I don't think this example is relevant. Once libgl has been
multiarchified, then everywhere the i386 file is going to be located
under ‘/usr/lib/i486-linux-gnu/libGL.so.1.2’.

> Surely this is as simple as:
> 
> case `dpkg --print-architecture` in
> amd64)
> # Do some stuff.
> ;;
> i386)
> # Do some other stuff.
> ;;
> esac
> 
> isn't it?

In this case it might have been enough, or not needed at all.

But that would print the arch dpkg was built for (i.e. the native
architecture), not the foreign arch of the package we are installing,
which is what we'd be interested in most cases like grub, eglibc,
module-init-tools or util-linux maint scripts.

regards,
guillem


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

Work-needing packages report for Jul 3, 2009

[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: 393 (new: 3)
Total number of packages offered up for adoption: 125 (new: 5)
Total number of packages requested help for: 51 (new: 1)

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



The following packages have been orphaned:

   gnomoradio (#535045), orphaned 3 days ago
 Reverse Depends: gnomoradio librainbow-dev librainbow0c2
   libroboradio-dev libroboradio0c2
 Installations reported by Popcon: 104

   somaplayer (#535046), orphaned 3 days ago
 Description: player audio for the soma suite
 Reverse Depends: libsds-dev libsomaplayer-dev somaplayer
 Installations reported by Popcon: 124

   supertux (#535147), orphaned 2 days ago
 Description: Classic 2D jump 'n run sidescroller with Tux
 Reverse Depends: supertux
 Installations reported by Popcon: 2109

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

   bzr-loom (#534760), offered 6 days ago
 Description: Focused patch plugin support for Bazaar
 Installations reported by Popcon: 50

   ejabberd (#534910), offered 4 days ago
 Description: Distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Installations reported by Popcon: 555

   jwchat (#534913), offered 4 days ago
 Description: a full featured, web-based Jabber chat client
 Installations reported by Popcon: 67

   kbuild (#534921), offered 4 days ago
 Reverse Depends: virtualbox-ose-guest-source virtualbox-ose-source
 Installations reported by Popcon: 2188

   xpdf (#535261), offered yesterday
 Description: Portable Document Format (PDF) suite
 Reverse Depends: cups dhelp fossology-agents fossology-agents-single
   impressive muttprint-manual page-crunch papaya python-numarray-doc
   texpower-examples (11 more omitted)
 Installations reported by Popcon: 12799

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

[NEW] libcap2 (#534999), requested 4 days ago
 Description: support for getting/setting POSIX.1e capabilities
 Reverse Depends: apache2-mpm-itk asterisk autodir avahi-daemon bind9
   bind9-host bind9utils dnsutils hercules libbind9-50 (61 more
   omitted)
 Installations reported by Popcon: 51980

   apache2 (#470795), requested 476 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (162 more
   omitted)
 Installations reported by Popcon: 44634

   ara (#450876), requested 599 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 116

   asymptote (#517342), requested 125 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 504

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

   boinc (#511243), requested 175 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1643

   cvs (#354176), requested 1225 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsreport (11
   more omitted)
 Installations reported by Popcon: 21176

   dctrl-tools (#448284), requested 614 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage ia32-archive ia32-libs-tools libsbuild-perl mlmmj
   simple-cdd
 Installations reported by Popcon: 11969

   dpkg (#282283), requested 1684 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc biblatex biblatex-dw build-essential bzr-builddeb (224 more
   omitted)
 Installations reported by Popcon: 84783

   elvis (#432298), requested 724 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depen

Re: ia32-libs transition

[Faidon Liambotis]

Goswin von Brederlow wrote:
> ia32-wine is only available when ia32-apt-get is installed.
WTF? Are you listening to yourself?

Do you actually believe that it's okay to mess in such horrendous ways
with the packaging system?

--
Faidon


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

Bug#535528: ITP: libhtml-calendarmonthsimple-perl -- perl module for generating html calendars

[Italo Valcy]

Package: wnpp
Severity: wishlist
Owner: Italo Valcy 


* Package name: libhtml-calendarmonthsimple-perl
  Version : 1.25
  Upstream Author : Matthew P. Sisk 
* URL :
* http://search.cpan.org/~stigmata/HTML-CalendarMonthSimple-1.25/
* License : Unknown
  Programming Lang: Perl
  Description : perl module for generating html calendars

HTML::CalendarMonthSimple is a Perl module for generating, manipulating,
and printing a HTML calendar grid for a specified month. It is intended
as a faster and easier-to-use alternative to HTML::CalendarMonth.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



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

Re: ia32-libs transition

[Goswin von Brederlow]

Faidon Liambotis  writes:

> Goswin von Brederlow wrote:
>> ia32-wine is only available when ia32-apt-get is installed.
> WTF? Are you listening to yourself?
>
> Do you actually believe that it's okay to mess in such horrendous ways
> with the packaging system?

If you don't want it then don't use it. That is your choice.

If you think the old ia32-libs did any less messing around with the
debs then you fail to see that the only difference is one of when.
And the ia32-apt-get way has the advantage of supporting "apt-get
install skype" and similar invocations.

MfG
Goswin


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

Re: multiarch and maintainer scripts

[Goswin von Brederlow]

Guillem Jover  writes:

> Hi!
>
> On Thu, 2009-07-02 at 13:58:48 -0700, Russ Allbery wrote:
>> Goswin von Brederlow  writes:
>> > what can be done if the maintainer scripts of a package must behave
>> > differently when unpacking the i386 deb on i386 or the i386 deb on
>> > amd64?
>
> We discussed this with Steve some days ago. My initial idea was to
> make “dpkg --print-architecture” polymorphic, and change what it
> prints depending on what architecture the package being installed is.

Then how would you detect if your package is unpacked on i386 or
amd64? An i386 deb knows at compile time that it is build for i386. I
see no good reason to have dpkg tell it so as well.

> That would require less packaging changes, but it seems pretty
> fragile and non-obvious behaviour, and we have several packages using
> “uname -m”, they'd need to be changed due to this or just to
> multiarchify them anyway, so we discarded it.

uname -m tells what kernel is in use, not what architecture the
package was build for nor what architecture it gets installed for.
A mostly useless information. I would consider any package that uses
uname -m in its maintainer scrips buggy. You can not depend on it not
chaning at any time (the system is rebootet) and the mainatiner script
will not be rerun when it does.

> But yesterday I came up with a simpler and cleaner solution, just
> export an env var matching the package arch being installed. Something
> like DPKG_MAINTSCRIPT_ARCH or similar.

That would be better, or at least not destroy other needed information.

>> > For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on
>> > i386 but /usr/lib32/libGL.so.1.2 on amd64.
>
> I don't think this example is relevant. Once libgl has been
> multiarchified, then everywhere the i386 file is going to be located
> under ‘/usr/lib/i486-linux-gnu/libGL.so.1.2’.

One can hope it catches on quickly enough. As it is free software it
can be changed easily enough. That might not always be the case,
especially when supporting backward compatible
/usr/lib{,32,64}/package/* plugin scanning though.

>> Surely this is as simple as:
>> 
>> case `dpkg --print-architecture` in
>> amd64)
>> # Do some stuff.
>> ;;
>> i386)
>> # Do some other stuff.
>> ;;
>> esac
>> 
>> isn't it?
>
> In this case it might have been enough, or not needed at all.
>
> But that would print the arch dpkg was built for (i.e. the native
> architecture), not the foreign arch of the package we are installing,
> which is what we'd be interested in most cases like grub, eglibc,
> module-init-tools or util-linux maint scripts.

Which is what was required.

The package always knows the arch it build for at build time. For that
one can use

  PKG_ARCH="@DEB_HOST_ARCH@"

and

  sed 's/@DEB_HOST_ARCH@/$(DEB_HOST_ARCH)/g' < postinst.in > postinst

or have debian/package.postinst.i386 and debian/package.postinst.amd64
and debhelper install the right one and so on.

(which doesn't mean dpkg exporting the arch at configure time wouldn't
be better in some cases)

> regards,
> guillem

MfG
Goswin


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

Re-activating an emeritus account

[John Ferlito]

Hi,

I've been trying to become a Debian Developer again for a while. I am
currently in emeritus status. The correct process for this according
to [1] is to email da-mana...@d.o which I have done twice in the last
year with no response.

Someone on IRC suggested emailing new-maintai...@d.o which I did a
about one month ago, again with no response.

I even tried just going through the New Maintainer process again but
it knows that I'm already in the system.

In the meantime so I can more easily upload packages I ended up
becoming a DM.

I'm not really complaining here I know that everyone responsible for
the above performs these tasks in their spare time. I'm just at a loss
as to what to try next.

1. http://lists.debian.org/debian-devel-announce/2005/02/msg3.html


Cheers,
John

-- 
John
Bloghttp://www.inodes.org/blog
OLPC Friends http://olpcfriends.org


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

Re: piuparts output wishlist?

[Ben Finney]

Lars Wirzenius  writes:

> How would _you_ like to see piuparts report results, and produce other
> output? Go wild, the sky is bright blue.
> 
> The obvious things to fix are:
> 
> - make it really easy to see what the result of each test is

Almost as obvious is to easily identify which test is being run.

This is kind of available now, but only if you know to look in the
‘DEBUG’ messages for command starts and exit status reports. I think
those debug messages are fine (provided the default logging level is
raised so those messages don't appear by default).

I think a good way to show both of these would be to have a different
channel of output, beside the logging output, that shows explicitly a
test identifier at the start, and then the result of that test at the
end, with a visually similar presentation for both. “Test identifier”
can simply be a command line, for example::

N: Running command: ‘dpkg --info 
/var/cache/pbuilder/result/burn_0.4.4-1_all.deb’
…
I: Command OK:  ‘dpkg --info 
/var/cache/pbuilder/result/burn_0.4.4-1_all.deb’
N: Running command: ‘chroot /tmp/tmpQm3zr8 dpkg -i tmp/burn_0.4.4-1_all.deb’
…
E: Command FAILED:  ‘chroot /tmp/tmpQm3zr8 dpkg -i tmp/burn_0.4.4-1_all.deb’

> - indicate severity of test failures (an extra file after purge is not
>   not as severe as leaving a daemon process running)

I like the earlier suggestions of ‘I: ’, ‘N: ’, ‘W: ’, ‘E: ’ prefixes to
indicate these severities. (I would understand these as, in increasing
order of severity: “info”, “notice”, “warning”, “error”.)

> - make logs be rather less voluminous by default

Yes, the default log output level should be something like ‘NOTICE’.

-- 
 \  “The most common way people give up their power is by thinking |
  `\   they don't have any.” —Alice Walker |
_o__)  |
Ben Finney


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

Re: Re-activating an emeritus account

[Paul Wise]

On Fri, Jul 3, 2009 at 12:02 PM, John Ferlito wrote:

> I've been trying to become a Debian Developer again for a while. I am
> currently in emeritus status. The correct process for this according
> to [1] is to email da-mana...@d.o which I have done twice in the last
> year with no response.

Try prodding the DAMs (Ganneff & Myon) or FD (bzed, Yoe, Myon, man-di)
on IRC on #debian-devel or #debian-newmaint. It is possible that the
mails went missing or unnoticed somehow.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: CDPATH and shell scripts

[Mike Hommey]

On Thu, Jul 02, 2009 at 02:26:21PM -0700, Russ Allbery wrote:
> Jonathan Yu  writes:
> 
> > How to fix them? Write Perl scripts, and turn on taint checking --
> > that fixes the four issues above, because it makes the script exit if
> > any of them look dangerous. Env::Sanctify::Auto is a Perl module that
> > automatically cleans up the paths.
> >
> > My advice:
> > 1. Write scripts that might be run as root (or setuid root) using Perl
> > 2. Turn on taint checking
> > 3. Consider using Env::Sanctify::Auto (shameless plug)
> 
> I would really prefer that people not start writing maintainer scripts
> in Perl as a matter of course.  Perl is harder to analyze for programs
> like lintian than shell scripts (which are already hard enough).

I wonder, do dpkg unset these variables when running maintainer scripts?
That could be a good idea if it doesn't already.

Mike


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

Re: ia32-libs{-tools}, multiarch, squeeze

[Steve Langasek]

On Fri, Jul 03, 2009 at 01:18:14AM +0200, Goswin von Brederlow wrote:
> There is only one thing that DAK might want to adapt to. For most
> multiarch architectures there is a definite main architecture that
> most things should be in and then some corner cases where different
> architetcure might be prefered or required. Usualy because 32bit mode
> has smaller code and is faster than 64bit mode but sometimes the
> larger addresss space of 64bit mode is required.

> So there might be a need to introduce partial architectures for ppc64,
> mips64, mips64el, sparc64 that only carry a small subset of
> Debian. The change would be in policy to allow architecture that are
> partial and maybe some code to reject unwanted packages from those
> architectures.

+ s390x

I would encourage people interested in these architectures to work on
developing such a policy, building on top of the current multiarch spec.
This isn't critical-path for delivering an initial multiarch implementation
for squeeze, but I see no reason that it couldn't be worked on in parallel.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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