Re: Desktop task(sel) in Etch? (Bug #389092)

[Jon Dowland]

At 1159290174 past the epoch, Jim Crilly wrote:
> The difference here is that removing exim4 and replacing
> it with postfix is a lot less work than it is Gnome->KDE
> since you can't just remove the 'gnome' metapackage and
> have all of Gnome be gone. If there was an easy way to do
> that I doubt anyone would care what the default choice
> was.

Hm. If you installed the gnome metapackage with aptitude,
then the dependencies would be marked 'auto' and removed
once you'd removed the manual package at the top of the
tree.

Perhaps aptitude could be modified so that on installation
it would look at the tasksel choices and interpret that as
if you had installed it yourself via aptitude (that is, mark
any dependencies as automatically installed).

-- 
Jon Dowland
http://alcopop.org/


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

Re: A plan to get rid of unnecessary package dependencies

[Michael Meskes]

On Tue, Sep 26, 2006 at 06:29:25PM -0700, Russ Allbery wrote:
> > But folding it into shlibdeps at least would remove all those warnings
> > that were created by shlibdeps. 
> 
> What warnings were created by shlibdeps?  I'm not sure what you're
> referring to here.

Sorry. I had a short look at some packages and all redundant
dependencies were created by shlibdeps. It doesn't seem to make sense to
have a list by maintainer when the dependencies weren't added by
him/her. Or did I misunderstand what this discussion is about?

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: A plan to get rid of unnecessary package dependencies

[Ganesan Rajagopal]

On Mon, Sep 25, 2006 at 09:49:57PM +0200, Christian Aichinger wrote:
> As a start, I've written a script that searches for unnecessary
> dependencies and reports them. Results are available here:
> http://rerun.lefant.net/checklib

Excellent work :-). I didn't see a link to the checklib script itself.
Do you intend to release it some time? Thanks.

Ganesan

-- 
Ganesan Rajagopal


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

Re: A plan to get rid of unnecessary package dependencies

[Steve Langasek]

On Wed, Sep 27, 2006 at 11:09:37AM +0200, Michael Meskes wrote:
> On Tue, Sep 26, 2006 at 06:29:25PM -0700, Russ Allbery wrote:
> > > But folding it into shlibdeps at least would remove all those warnings
> > > that were created by shlibdeps. 

> > What warnings were created by shlibdeps?  I'm not sure what you're
> > referring to here.

> Sorry. I had a short look at some packages and all redundant
> dependencies were created by shlibdeps. It doesn't seem to make sense to
> have a list by maintainer when the dependencies weren't added by
> him/her. Or did I misunderstand what this discussion is about?

Yes, I'm afraid you did.  The behavior of dpkg-shlibdeps is correct: it
documents the packages that must be present on the system in order for the
binaries to work.  The bug we're discussing happens at the ELF linker level
-- you can't have dpkg-shlibdeps decide to ignore some of these libs,
because the *binary* still embeds references to them and if they're missing,
the binary will not work.

So the fix is to get our binaries to stop embedding references to libraries
they don't need, then dpkg-shlibdeps will do the right thing automatically.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Bug#389710: ITP: git-buildpackage -- Suite to help with Debian packages in git archives

[Guido Guenther]

Package: wnpp
Severity: wishlist
Owner: Guido Guenther <[EMAIL PROTECTED]>

* Package name: git-buildpackage
  Version : 0.2
  Upstream Author : Guido Guenther <[EMAIL PROTECTED]>
* URL : git clone http://honk.sigxcpu.org/git/git-buildpackage/.git
* License : GPLv2
  Programming Lang: Python
  Description : Suite to help with Debian packages in git repositories

This package contains the following tools:
  * git-import-dsc: import an existing Debian source package into a git
repository
  * git-import-orig: import a new upstream version into the git repository
  * git-buildpackage: build a package out of a git repository, check for
local modifications and tag appropriately

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-rc6-g05ff0e29-dirty
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


signature.asc
Description: Digital signature

Re: A plan to get rid of unnecessary package dependencies

[Christian Aichinger]

On Wed, Sep 27, 2006 at 02:05:29PM +0530, Ganesan Rajagopal wrote:
> Excellent work :-).

Thanks :)

> I didn't see a link to the checklib script itself.
> Do you intend to release it some time? Thanks.

It's linked at the bottom of all the pages, the link points to
http://greek0.net/div/checklib.tar.gz>

Cheers,
Christian Aichinger


signature.asc
Description: Digital signature

Re: A plan to get rid of unnecessary package dependencies

[Michael Meskes]

> > Sorry. I had a short look at some packages and all redundant
> > dependencies were created by shlibdeps. It doesn't seem to make sense to
> > have a list by maintainer when the dependencies weren't added by
> > him/her. Or did I misunderstand what this discussion is about?
> 
> Yes, I'm afraid you did.  The behavior of dpkg-shlibdeps is correct: it
> documents the packages that must be present on the system in order for the
> binaries to work.  The bug we're discussing happens at the ELF linker level
> ...

Ah, silly me, I thought the problem was a Depends: entry not a real
dependancy. Sorry for the confusion.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: A plan to get rid of unnecessary package dependencies

[Mark Brown]

On Tue, Sep 26, 2006 at 06:28:50PM -0700, Russ Allbery wrote:
> Christian Aichinger <[EMAIL PROTECTED]> writes:

> > Maintaining such information somewhere within the library package would
> > be possible, but that sounds like a more complex plan, and I doubt that
> > many library maintainers know if their lib uses such tricks or not.

> does still apply.

As a first approximation perhaps libraries with constructors or
destructors could be assumed to always be required?  That would be more
conservative than required but perhaps so conservative as to be useless.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: A plan to get rid of unnecessary package dependencies

[Christian Aichinger]

On Wed, Sep 27, 2006 at 12:50:07PM +0100, Mark Brown wrote:
> As a first approximation perhaps libraries with constructors or
> destructors could be assumed to always be required?  That would be more
> conservative than required but perhaps so conservative as to be useless.

The problematic sections seem to be .init and .fini. There are
sections called .ctors and .dtors, but they aren't marked as
executable.

However both .init and .fini seem to be always present, and include
code too.

To see the sections in the ELF file: readelf -S 
To see the code in .init and .fini:  objdump -D  | sed -n -e 
'/\.init\|\.fini/,/^Dis/p'


What I could imagine was some sort of opt-in system, where library
maintainers could put a special marker into their -dev packages
indicating "yes, please remove me if I'm not needed, it's save".

I'm not sure where to put it inside the -dev package though, perhaps
in an /usr/share/debhelper/stripdeps/ file?

Cheers,
Christian Aichinger


signature.asc
Description: Digital signature

Re: A plan to get rid of unnecessary package dependencies

[Mike Hommey]

On Wed, Sep 27, 2006 at 02:57:16AM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Wed, Sep 27, 2006 at 11:09:37AM +0200, Michael Meskes wrote:
> > On Tue, Sep 26, 2006 at 06:29:25PM -0700, Russ Allbery wrote:
> > > > But folding it into shlibdeps at least would remove all those warnings
> > > > that were created by shlibdeps. 
> 
> > > What warnings were created by shlibdeps?  I'm not sure what you're
> > > referring to here.
> 
> > Sorry. I had a short look at some packages and all redundant
> > dependencies were created by shlibdeps. It doesn't seem to make sense to
> > have a list by maintainer when the dependencies weren't added by
> > him/her. Or did I misunderstand what this discussion is about?
> 
> Yes, I'm afraid you did.  The behavior of dpkg-shlibdeps is correct: it
> documents the packages that must be present on the system in order for the
> binaries to work.  The bug we're discussing happens at the ELF linker level
> -- you can't have dpkg-shlibdeps decide to ignore some of these libs,
> because the *binary* still embeds references to them and if they're missing,
> the binary will not work.
> 
> So the fix is to get our binaries to stop embedding references to libraries
> they don't need, then dpkg-shlibdeps will do the right thing automatically.

A first step in that direction would be to fix .la, .pc and -config
files so that they only give the needed libraries.

Mike


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

Re: Free flash player for your browser

[Jonas Meurer]

On 26/09/2006 Petter Reinholdtsen wrote:
> [Jonas Meurer]
> > unfortunately mozilla-plugin-gnash crashes for most flash pages.
> 
> OK.  If you got time, please add these test pages to the wiki.  I have
> not been able to get the latest plugin to crash, so I am interested in
> these pages.

i must admit that i cannot reproduce any browser crash with flash
animations, but ...

> > www.sonnenvakuum.ch even killed my Xserver once.
> 
> That would be a bug in your X server.  X servers should not crash no
> matter the client.  :)

... my X server crashed a second time, this time at an artist at
myspace.com, which automaticly starts a flash music player.

...
 jonas


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

Re: A plan to get rid of unnecessary package dependencies

[Gabor Gombas]

On Wed, Sep 27, 2006 at 02:44:10PM +0200, Christian Aichinger wrote:

> The problematic sections seem to be .init and .fini. There are
> sections called .ctors and .dtors, but they aren't marked as
> executable.

.ctors and .dtors contain function pointers that are called by code in
the .init/.fini sections (crtbegin.o, crtend.o).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Re: Intent to "hijack" the dhelp package

[José Luis Tallón]

Esteban Manchado Velázquez wrote:
> Hi all,
>
> As Javier noted just after releasing Sarge [1], we need better
> documentation integration tools in Debian. Yes, we have dhelp [2], but it
> lacks loads of features, and it's not what I would call "in shape" [3]. I have
> tried to fix this situation, mostly by organizing and merging bug reports, and
> writing a couple of patches for them.
>   
Thank you (not that I have anything to do with this package, but all
work is welcome)

> I have even rewritten dhelp_parse, one of the main utilities, in Ruby [4]
> (mostly because it's a huge PITA finding and fixing bugs in a largely text
> processing program... written in C). It maintains compatibility with the
> documentation database, so it's a drop-in replacement. At least it should :-)
>   
Ruby is not among the "standard" installation. May I suggest PERL instead?
(Not that I prefer PERL to Ruby -- this is just for dependencies' sake)



J.L.


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

Re: Desktop task(sel) in Etch? (Bug #389092)

[Christoph Berg]

Re: Andreas Tille 2006-09-27 <[EMAIL PROTECTED]>
> The hint to non US keyboard is *very* important.  I would love if
> *every* string a user (not a hacker) has to type at the boot prompt
> would work on *any* keybord according to its marking, which means only
> letters (no =_/ etc.) are allowed.

Given that French keyboards have virtually no key at the "proper"
place, that's quite hard to accomplish...

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#389773: ITP: cnf -- library for C and Fortran mixed programming

[Enrico Zini]

Package: wnpp
Severity: wishlist
Owner: Enrico Zini <[EMAIL PROTECTED]>

* Package name: cnf
  Version : 4.0
  Upstream Author : Various from Council for the Central Laboratory of
the Research Councils ("CCLRC") and stated at the
beginning of every source file.
* URL : http://www.starlink.ac.uk/cgi-store/ftpform1?cnf
* License : GPL version 2
(see http://www.starlink.rl.ac.uk/store/conditions.html)
  Programming Lang: C
  Description : library for C and Fortran mixed programming

The CNF package comprises two sets of software which ease the task of
writing portable programs in a mixture of FORTRAN and C. F77 is a set of
C macros for handling the FORTRAN/C subroutine linkage in a portable
way, and CNF is a set of functions to handle the difference between
FORTRAN and C character strings, logical values and pointers to
dynamically allocated memory.


The original distribution features an own packaging system, which was
good when it was made, but now it's a bit tricky to work with.  To make
it easy package CNF for Debian and Fedora, I skipped part of the
original packaging and created a new makefile which wraps the old one
providing a more usual behaviour.


The package can be inspected at http://people.debian.org/~enrico/2006-09/cnf/
and I intend to proceed with the upload during the week-end.


Ciao,

Enrico


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)


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

Bug#389776: ITP: dballe -- Database for punctual meteorological data

[Enrico Zini]

Package: wnpp
Severity: wishlist
Owner: Enrico Zini <[EMAIL PROTECTED]>

* Package name: dballe
  Version : 2.5
  Upstream Author : Enrico Zini <[EMAIL PROTECTED]> for ARPA SIM
* URL : http://www.smr.arpa.emr.it/software/DBalle.html
* License : GPL
  Programming Lang: C
  Description : Database for punctual meteorological data

DB-All.e is a fast on-disk database where meteorological observed and
forecast data can be stored, searched, retrieved and updated.

This framework allows to manage large amounts of data using its simple
Application Program Interface, and provides tools to visualise, import
and export in the standard formats BUFR, AOF and CREX.

These are the main characteristics of DB-ALL.e:

 * Fortran, C, C++ and Python APIs are provided.
 * To make computation easier, data is stored as physical quantities,
   that is, as measures of a variable in a specific point of space and
   time, rather than as a sequence of report.
 * Internal representation is similar to BUFR and CREX WMO standard
   (table code driven) and utility for import and export are included
   (generic and ECMWF template).
 * Representation is in 7 dimensions: latitude and longitude geographic
   coordinates, table driven vertical coordinate, reference time,
   table driven observation and forecast specification, table driven
   data type.
 * It allows to store extra information linked to the data, such as
   confidence intervals for quality control.
 * It allows to store extra information linked to the stations.
 * Variables can be represented as real, integer and characters, with
   appropriate precision for the type of measured value.
 * It is based on physical principles, that is, the data it contains are
   defined in terms of homogeneous and consistent physical data. For
   example, it is impossible for two incompatible values to exist in the
   same point in space and time.
 * It can manage fixed stations and moving stations such as airplanes or
   ships.
 * It can manage both observational and forecast data.
 * It can manage data along all three dimensions in space, such as data
   from soundings and airplanes.
 * Report information is preserved. It can work based on physical
   parameters or on report types.


Ciao,

Enrico

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)


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

Re: Desktop task(sel) in Etch? (Bug #389092)

[Mike Hommey]

On Wed, Sep 27, 2006 at 08:32:24AM +0200, Andreas Tille <[EMAIL PROTECTED]> 
wrote:
> On Wed, 27 Sep 2006, Christian Perrier wrote:
> 
> >"tasks=kde-desktop" is a bit rude to type (try it on a non US
> >keyboard...).
> 
> The hint to non US keyboard is *very* important.  I would love if
> *every* string a user (not a hacker) has to type at the boot prompt
> would work on *any* keybord according to its marking, which means only
> letters (no =_/ etc.) are allowed.  A "-" might work on the numeric
> keyboard but it is often even hard enough to find the '=' which
> disqualifies for users who have no idea that there is something else
> than their own keyboard in front of them.

Isn't it possible to have the keyboard selection done by the boot loader ?

Mike


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

Bug#389777: ITP: cruisecontrol -- CruiseControl is a java-based framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and various source co

[Rodrigo Lemos]

Package: wnpp
Severity: wishlist
Owner: Rodrigo Lemos <[EMAIL PROTECTED]>


* Package name: cruisecontrol
  Version : 2.5
  Upstream Author : ThoughtWorks, Inc
* URL : http://cruisecontrol.sourceforge.net
* License : BSD-style
  Programming Lang: Java
  Description : CruiseControl is a java-based framework for a continuous
  build process. It includes, but is not limited to, plugins for email
  notification, Ant, and various source control tools. A web interface is
  provided to view the details of the current and previous builds.

Continuous Integration is a software development practice where members of a
team integrate their work frequently, usually each person integrates at least
daily - leading to multiple integrations per day. Each integration is verified
by an automated build (including test) to detect integration errors as quickly
as possible. Many teams find that this approach leads to significantly reduced
integration problems and allows a team to develop cohesive software more
rapidly.

CruiseControl provides a build loop daemon, which checks out source code
from any supported revision tracking system, runs it's build scripts and
publishes the results of each build cycle. Those results can be
published in a variety of ways, such as an HTTP server or an e-mail 
message with HTML report attached.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686-smp
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)


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

Entering parameters at the boot prompt

[Christian Perrier]

(from a discussion in -devel)

> The hint to non US keyboard is *very* important.  I would love if
> *every* string a user (not a hacker) has to type at the boot prompt
> would work on *any* keybord according to its marking, which means only
> letters (no =_/ etc.) are allowed.  A "-" might work on the numeric


and no "a" "z" "y" "q" "w" "m" which are, IIRC the most commonly
relocated keys for ASCII characters on the weird localized
keyboards...

This is currently one of the minor drawbacks of the choice of
"install", "installgui"

/me wonders, thinking out loud, whether we could establish "instqll"
and "instqllgui" as "allowed" alternatives.

CC'ing -boot




signature.asc
Description: Digital signature

Re: Entering parameters at the boot prompt

[Mike Hommey]

On Wed, Sep 27, 2006 at 06:15:39PM +0200, Christian Perrier <[EMAIL PROTECTED]> 
wrote:
> (from a discussion in -devel)
> 
> > The hint to non US keyboard is *very* important.  I would love if
> > *every* string a user (not a hacker) has to type at the boot prompt
> > would work on *any* keybord according to its marking, which means only
> > letters (no =_/ etc.) are allowed.  A "-" might work on the numeric
> 
> 
> and no "a" "z" "y" "q" "w" "m" which are, IIRC the most commonly
> relocated keys for ASCII characters on the weird localized
> keyboards...
> 
> This is currently one of the minor drawbacks of the choice of
> "install", "installgui"
> 
> /me wonders, thinking out loud, whether we could establish "instqll"
> and "instqllgui" as "allowed" alternatives.

Well, users seeing q when typing a wouldn't continue typing anyway...

Or make it display an "a" if a "q" is pressed after "inst".

And "special" characters could be triggered on any key that could hold
the character if it makes sense for the preceding characters to be
followed by the character.

Which reminds me [OT] that when I tried a d-i beta i've been deceived
not to see the magic keyboard wizard i saw on the first ubuntu ; the one
that asks to press some keys and guess the keyboard type based on that
set of keys you typed.

Mike


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

Re: Entering parameters at the boot prompt

[Christian Perrier]

> Which reminds me [OT] that when I tried a d-i beta i've been deceived
> not to see the magic keyboard wizard i saw on the first ubuntu ; the one
> that asks to press some keys and guess the keyboard type based on that
> set of keys you typed.


Will probably be in the TODO list for post-etch but requires using
console-setup, IIRCand Colin Watson himself mentioned, IIRC, that
this is a ugly hack..:-)




signature.asc
Description: Digital signature

Re: A plan to get rid of unnecessary package dependencies

[Russ Allbery]

Christian Aichinger <[EMAIL PROTECTED]> writes:

> What I could imagine was some sort of opt-in system, where library
> maintainers could put a special marker into their -dev packages
> indicating "yes, please remove me if I'm not needed, it's save".

> I'm not sure where to put it inside the -dev package though, perhaps
> in an /usr/share/debhelper/stripdeps/ file?

Well, if we're talking about an external tool to strip unnecessary NEEDED
entries from the library, you could call it dh_striplibs, include it in
debhelper, and have the opt-in system be whether the maintainer chooses to
run it or not.  That doesn't help the folks who aren't using debhelper as
much, though.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#389777: ITP: cruisecontrol -- CruiseControl is a java-based framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and various sourc

[Sandro Tosi]

  Description : CruiseControl is a java-based framework for a continuous
  build process. It includes, but is not limited to, plugins for email
  notification, Ant, and various source control tools. A web interface is
  provided to view the details of the current and previous builds.


referring to [1] and [2] I'd compress maybe in "java-based framework
for a continuous build process" or some other description.

Regards,
Sandro

[1] http://www.debian.org/doc/debian-policy/ch-binary.html#s-synopsis
[2] 
http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis


--
Sandro Tosi (aka Morpheus, matrixhasu)
My (little) site: http://matrixhasu.altervista.org/


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

ITP: freehdl -- Free VHDL simulator

[L. Redrejo]

Package: wnpp
Severity: wishlist
Owner: José L. Redrejo Rodríguez <[EMAIL PROTECTED]>

* Package name: freehdl
  Version : 0.2.3
  Upstream Authors: Marius Vollmer <[EMAIL PROTECTED]> (parser)
Edwin Naroska <[EMAIL PROTECTED]> (code generator/simulator)
Said Mchaalia <[EMAIL PROTECTED]> (VCD dumper)
David Colson <[EMAIL PROTECTED]> (testing)
Philippe <[EMAIL PROTECTED]> (FHDLgui)
* URL : http://www.freehdl.seul.org/
* License : GPL
  Description : This is a  free, open source, GPL'ed VHDL simulator

These are main freehdl features:
  * Has a graphical waveform viewer.
  * Has a source level debugger.
  * Is VHDL-93 compliant.



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: A plan to get rid of unnecessary package dependencies

[Christian Aichinger]

On Wed, Sep 27, 2006 at 10:54:34AM -0700, Russ Allbery wrote:
> > I'm not sure where to put it inside the -dev package though, perhaps
> > in an /usr/share/debhelper/stripdeps/ file?
> 
> Well, if we're talking about an external tool to strip unnecessary NEEDED
> entries from the library, you could call it dh_striplibs, include it in
> debhelper, and have the opt-in system be whether the maintainer chooses to
> run it or not.

That's what I was thinking of.

> That doesn't help the folks who aren't using debhelper as
> much, though.

We could also put the flags in another location then under
/usr/share/debhelper (or into the control tarball, though that
sounds cumbersome), so other build systems could use it too.

Ideas where to put such a thing?

Cheers,
Christian Aichinger


signature.asc
Description: Digital signature

Bug#389798: ITP: hapm -- high availability port monitor

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho <[EMAIL PROTECTED]>


* Package name: hapm
  Version : 0.1
  Upstream Author : Alexandre Antonio Antunes de Almeida <[EMAIL PROTECTED]>
Joao Eriberto Mota Filho <[EMAIL PROTECTED]>
Rosemeri Dantas de Oliveira <[EMAIL PROTECTED]>
* URL : http://hapm.sourceforge.net
* License : GPL
  Description : high availability port monitor

High Availability Port Monitor (HAPM) is a local port status check. It is a 
simple, light and fast daemon to check TCP/UDP ports. If one or more monitored
ports (per IP) downs then the Heartbeat will be killed by HAPM. This is a
Brazilian project.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-xen-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: A plan to get rid of unnecessary package dependencies

[Kevin B. McCarty]

 to
> run it or not.  That doesn't help the folks who aren't using debhelper =
as
> much, though.

But isn't the decision of the maintainer to use dh_striplibs orthogonal
to the need for a library not to be stripped?  That is, some set of
libraries presumably shouldn't be stripped out of NEEDED entries
(because they provide constructors/destructors), but that is not likely
to correspond to the set of maintainers who decide to strip
apparently-superfluous NEEDED entries from their own program or library.


I think what's needed is two-fold.  First, a library packager should be
able to say "I'm sure my library doesn't use constructors/destructors or
anything else that would make checklib give a false negative for it".
Second, any maintainer should be able to take advantage of that fact and
make that library's NEEDED entry be stripped from his/her own package if
(a) it appears unneeded and (b) the library packager has "promised" it
would be OK.


The first item could be implemented with a new debhelper tool, for the
sake of argument call it "dh_setstrippable".  This would just register
the fact in some file of the library package, say
/var/lib/dpkg/info/libfoo.strippable, similar to the shlibs file.  This
could just contain a list of sonames that the library maintainer knows
actually could be stripped away if checklib thinks they appear unneeded.
 For instance, the file /var/lib/dpkg/info/libgtk2.0-0.strippable might
have these contents:

libgdk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0
libgdk_pixbuf_xlib-2.0.so.0
libgtk-x11-2.0.so.0

caused by the GTK maintainer putting this command in debian/rules:

dh_setstrippable -plibgtk2.0-0 libgdk-x11-2.0.so.0 \
libgdk_pixbuf-2.0.so.0 [...]


The second item could be a new feature of dh_strip; it would check for
apparently unneeded NEEDED entries [*] using the same logic as checklib,
and, for each soname that is registered in a "strippable" file, it would
nuke the NEEDED entry.  (Whether this is possible, or how this is done,
I unfortunately have no idea.)  One could of course imagine dh_strip
having a new flag that would turn this behavior off if for some reason
the maintainer found it unwanted.

[*] unneeded NEEDED entries: there's a great oxymoron!


Since dh_strip is run in the build of just about every package
containing a binary or library, the only effort required for this to
work would be the opt-in on the part of library maintainers (who, one
hopes, tend to be among the most active and knowledgeable maintainers).
 As more library maintainers determined it was safe to opt in [**], and
new versions of packages were recompiled and uploaded, the problem of
unnecessary library dependencies would slowly be reduced.  No annoying
relibtoolization, no potentially dangerous use of ld's --as-needed flag,
and no editing of pkg-config or .la files required!

[**] I hope someone out there knows how a library maintainer can
reliably determine this!

best regards,

--=20
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544



signature.asc
Description: OpenPGP digital signature

Re: A plan to get rid of unnecessary package dependencies

[Kevin B. McCarty]

ugh, somehow one of Thunderbird, Enigmail or my SMTP server mangled the
quoted part of my last email at Message-id:
<[EMAIL PROTECTED]>, maybe also the GPG sig.  Sorry about
that!  Everything I wanted to say went through OK though.

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544



signature.asc
Description: OpenPGP digital signature

Re: Desktop task(sel) in Etch? (Bug #389092)

[Joey Hess]

Jon Dowland wrote:
> Hm. If you installed the gnome metapackage with aptitude,
> then the dependencies would be marked 'auto' and removed
> once you'd removed the manual package at the top of the
> tree.

Or you can just tasksel remove gnome-desktop; tasksel install kde-desktop

> Perhaps aptitude could be modified so that on installation
> it would look at the tasksel choices and interpret that as
> if you had installed it yourself via aptitude (that is, mark
> any dependencies as automatically installed).

tasksel uses aptitude for the actual installation, so this already
happens.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Tim Dijkstra]

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


* Package name: pm-utils
  Version : 0.0.1
  Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones
<[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes
<[EMAIL PROTECTED]>
* URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/
* License : GPL
  Programming Lang: C, Shell
  Description : utilities and scripts usefull for power management

Provides simple shell command line tools to suspend and hibernate
computer that can be used to run vendor or distro supplied scripts
on suspend and resume.



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

Re: Bug#388569: general: always printed in letter format

[Martin Wuertele]

* gerhard oettl <[EMAIL PROTECTED]> [2006-09-22 06:59]:

> Since updating to etch some weeks ago i was not able to print
> from firefox, because always letter format is requested on the
> printer panel. This happens independend of the input in the
> printer property fields in the printing dialog if firefox (where
> i entered "A4") and independend of the printer settings in cups
> (where i also use "A4") - see bug 383.255.
 
(...)

Do you have xprint installed? If yes, try purging it and see if it
works. I had multiple problems with firefox and thunderbird when it was
installed and as I don't see a need for it I keep it purged on all of my
systems.

HTH Martin
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operating System
Tuvok schrieb:
> wo genau soll es im böhmischen Prater einen Maulbeerbaum geben?
Die Wurzeln sind im Boden drin und der Rest hängt in der Luft herum.
-- Alexander Marquardt, oesterreich.tuvok

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Steinar H. Gunderson]

On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote:
> Provides simple shell command line tools to suspend and hibernate
> computer that can be used to run vendor or distro supplied scripts
> on suspend and resume.

This is something like the fifth package in Debian that attempts to do this.
What sets is apart from the ones already in Debian? Do we really need another
one?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Tim Dijkstra]

Op Wed, 27 Sep 2006 23:41:01 +0200
schreef "Steinar H. Gunderson" <[EMAIL PROTECTED]>:

> On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote:
> > Provides simple shell command line tools to suspend and hibernate
> > computer that can be used to run vendor or distro supplied scripts
> > on suspend and resume.
> 
> This is something like the fifth package in Debian that attempts to
> do this. What sets is apart from the ones already in Debian? Do we
> really need another one?

This will make all others obsolete;)

More seriously, this will be a dependency of HAL and with that of the
whole gnome power management stack. So I think we can't go around it in
the future. I wanted to package it to make sure it plays nice with
uswsusp (another package I maintain).

grts Tim


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

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Stephen Gran]

This one time, at band camp, Tim Dijkstra said:
> Op Wed, 27 Sep 2006 23:41:01 +0200
> schreef "Steinar H. Gunderson" <[EMAIL PROTECTED]>:
> 
> > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote:
> > > Provides simple shell command line tools to suspend and hibernate
> > > computer that can be used to run vendor or distro supplied scripts
> > > on suspend and resume.
> > 
> > This is something like the fifth package in Debian that attempts to
> > do this. What sets is apart from the ones already in Debian? Do we
> > really need another one?
> 
> This will make all others obsolete;)
> 
> More seriously, this will be a dependency of HAL and with that of the
> whole gnome power management stack. So I think we can't go around it in
> the future. I wanted to package it to make sure it plays nice with
> uswsusp (another package I maintain).

Not that I actually object to the package, but why can't HAL let acpid
manage acpi events?  I am continually confused by the profusion of
packages that offer to work around acpid in order to provide the
functionality it could and should be providing.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Michael Banck]

On Wed, Sep 27, 2006 at 11:41:01PM +0200, Steinar H. Gunderson wrote:
> On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote:
> > Provides simple shell command line tools to suspend and hibernate
> > computer that can be used to run vendor or distro supplied scripts
> > on suspend and resume.
> 
> This is something like the fifth package in Debian that attempts to do this.
> What sets is apart from the ones already in Debian? Do we really need another
> one?

* Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones
<[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes
<[EMAIL PROTECTED]>
* URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/

I think this is the one to rule them all.


Michael


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

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Tim Dijkstra]

Op Thu, 28 Sep 2006 00:00:28 +0100
schreef Stephen Gran <[EMAIL PROTECTED]>:

> Not that I actually object to the package, but why can't HAL let acpid
> manage acpi events?  I am continually confused by the profusion of
> packages that offer to work around acpid in order to provide the
> functionality it could and should be providing.

Note that this package is not really related to acpid, but I'll try to
answer anyway. Acpid is just another deamon listening
to /proc/acpi/event. It doesn't have a good way of communicating with
a user. 
HAL is also able to listen to acpi events (by listening
to /proc/acpi/event or acpid). The advantage HAL has over acpid, is
that it is very well integrated in to the users (kde or gnome) session.
That way it is able to notify the user (he, your battery is low!) get
user feedback (should I suspend to ram, to disk?) and act on user
configuration (suspend to ram when closing the lid, but only when on AC,
else suspend to disk).

Now acpid has technically nothing to do with bringing the machine in a
sleep state. For that to work you have basically three options: 
1) Patch your kernel with suspend2
2) Use swsusp build in kernel
3) Use uswsusp which is partly in kernel, partly user space.
I think that with the profusion of packages you talk about are the
packages (like pm-utils) the try to work around bugs in drivers and
offer functionality before and after the actual sleep. Things like
syncing the clock, stopping services, networks, fixing the state of
the graphics card.

I hope this clears it up a bit

grts Tim 


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

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Tim Dijkstra]

Op Thu, 28 Sep 2006 01:04:40 +0200
schreef Michael Banck <[EMAIL PROTECTED]>:

> On Wed, Sep 27, 2006 at 11:41:01PM +0200, Steinar H. Gunderson wrote:
> > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote:
> > > Provides simple shell command line tools to suspend and hibernate
> > > computer that can be used to run vendor or distro supplied scripts
> > > on suspend and resume.
> > 
> > This is something like the fifth package in Debian that attempts to
> > do this. What sets is apart from the ones already in Debian? Do we
> > really need another one?
> 
> * Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones
> <[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes
> <[EMAIL PROTECTED]>
> * URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/
> 
> I think this is the one to rule them all.

Are you being cynical or serious?

grts Tim


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

Re: Free flash player for your browser

[Ben Finney]

Jonas Meurer <[EMAIL PROTECTED]> writes:

> On 26/09/2006 Petter Reinholdtsen wrote:
> > That would be a bug in your X server.  X servers should not crash
> > no matter the client.  :)
>
> ... my X server crashed a second time, this time at an artist at
> myspace.com, which automaticly starts a flash music player.

Excellent. You're getting more of an understanding of how to reproduce
this bug in your X server. I hope that soon you can submit a bug
report against the X server with a test case.

-- 
 \ "Remember men, we're fighting for this woman's honour; which is |
  `\probably more than she ever did."  -- Groucho Marx |
_o__)  |
Ben Finney


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

Re: Entering parameters at the boot prompt

[Ben Finney]

Mike Hommey <[EMAIL PROTECTED]> writes:

> Well, users seeing q when typing a wouldn't continue typing anyway...

Unless they're one of the great many users who look at the keyboard,
rather than the monitor, while they type.

-- 
 \ "I am an optimist. It does not seem too much use being anything |
  `\  else."  -- Winston Churchill |
_o__)  |
Ben Finney


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

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

[Stephen Gran]

This one time, at band camp, Tim Dijkstra said:
> Op Thu, 28 Sep 2006 00:00:28 +0100
> schreef Stephen Gran <[EMAIL PROTECTED]>:
> 
> > Not that I actually object to the package, but why can't HAL let acpid
> > manage acpi events?  I am continually confused by the profusion of
> > packages that offer to work around acpid in order to provide the
> > functionality it could and should be providing.
> 
> Note that this package is not really related to acpid, but I'll try to
> answer anyway. Acpid is just another deamon listening
> to /proc/acpi/event. It doesn't have a good way of communicating with
> a user. 
> HAL is also able to listen to acpi events (by listening
> to /proc/acpi/event or acpid). The advantage HAL has over acpid, is
> that it is very well integrated in to the users (kde or gnome) session.
> That way it is able to notify the user (he, your battery is low!) get
> user feedback (should I suspend to ram, to disk?) and act on user
> configuration (suspend to ram when closing the lid, but only when on AC,
> else suspend to disk).
> 
> Now acpid has technically nothing to do with bringing the machine in a
> sleep state. For that to work you have basically three options: 
> 1) Patch your kernel with suspend2
> 2) Use swsusp build in kernel
> 3) Use uswsusp which is partly in kernel, partly user space.
> I think that with the profusion of packages you talk about are the
> packages (like pm-utils) the try to work around bugs in drivers and
> offer functionality before and after the actual sleep. Things like
> syncing the clock, stopping services, networks, fixing the state of
> the graphics card.
> 
> I hope this clears it up a bit

Only a little.  Perhaps I am just of the old skool 'do one job and do
it well' mind set, but all of those events appear to be acpi events
which acpid handles rather well, even in the brave new world of single
user linux on laptops that Ubuntu and others have brought us.  You do
know that acpid can run arbitrary scripts on acpi events, like say,
lid close, right?  I understand that this package is no different than
a dozen others, in that it tries to provide policy layers and cute
gui things on top of acpid, but it just seems like too many layers of
abstraction and replicated code bases to me.

But, as I say, whatever, one more won't hurt.  I just feel a little
perturbed when I see some new project that needs HAL, dbus, and a half
dozen other things to handle something that can already be handled with
shell scripts and a very small daemon.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Free flash player for your browser

[Jonas Meurer]

On 28/09/2006 Ben Finney wrote:
> Jonas Meurer <[EMAIL PROTECTED]> writes:
> 
> > On 26/09/2006 Petter Reinholdtsen wrote:
> > > That would be a bug in your X server.  X servers should not crash
> > > no matter the client.  :)
> >
> > ... my X server crashed a second time, this time at an artist at
> > myspace.com, which automaticly starts a flash music player.
> 
> Excellent. You're getting more of an understanding of how to reproduce
> this bug in your X server. I hope that soon you can submit a bug
> report against the X server with a test case.

i'm not able  to reproduce the bug at the moment. even if i put my
system under heavy load, the X server does not crash again.

...
 jonas


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

Re: Free flash player for your browser

[Ben Finney]

Jonas Meurer <[EMAIL PROTECTED]> writes:

> On 28/09/2006 Ben Finney wrote:
> > Excellent. You're getting more of an understanding of how to
> > reproduce this bug in your X server. I hope that soon you can
> > submit a bug report against the X server with a test case.
>
> i'm not able  to reproduce the bug at the moment.

When you do, the 'reportbug' tool (which you can install via aptitude
if you don't already have it) will make it easy to report a bug to the
Debian bug tracking system.

-- 
 \  "Any sufficiently advanced bug is indistinguishable from a |
  `\   feature."  -- Rich Kulawiec |
_o__)  |
Ben Finney


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

Re: Free flash player for your browser

[Miriam Ruiz]

 --- Ben Finney <[EMAIL PROTECTED]> escribió:

> When you do, the 'reportbug' tool (which you can install via aptitude
> if you don't already have it) will make it easy to report a bug to the
> Debian bug tracking system.

Jonas has already filed some bugs against gnash. To be honest, I don't know
the reason for your words, and if there's some kind of irony behind them.

Thanks Jonas.

Greetings,
Miry






__ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com


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

Problems with g++ (Was: Re: A plan to get rid of unnecessary package dependencies)

[Kapil Hari Paranjape]

Hello,

On Mon, 25 Sep 2006, Christian Aichinger wrote:
> As Steve Langasek detailed in his d-d-a mail[1], unnecessary
> dependencies cause lots of problems, as they make transitions
> bigger then they need to be.

Sorry for the noise. I wrote earlier to Christian Aichinger
(and submitted a report #389555 against g++) and got no response.

On Tue, 26 Sep 2006, I wrote:
>I have filed an ITA for "swish++" so the problems with that package land
>in my lap! 
>
>When looking through the makefiles and the libraries that are linked
>there is no mention of the two offending libraries "libm" or
>"libgcc". On the other hand I noticed (by giving CC="g++ -v") that it
>was "g++" which was putting these libraries in its call to collect2.
> 
>If instead of this I link with "gcc" and add a "-lstdc++" in order to
>get it to link correctly then the extra "NEEDED"'s disappear.
> 
>I suppose I could fix the problem this way, but is this not a bug with
>"g++"?
 
On Tue, 26 Sep 2006, I wrote:
>Actually, I found the following thread:
>
>   http://gcc.gnu.org/ml/gcc/2005-01/msg00229.html
>
>This seems to indicate that g++ always links in libm and
>libgcc_*.
>
>This will mean that programs that use g++ to link will always create
>a problem.

Perhaps this should be solved by *not* using g++ to link.

I have now created a version of the "swish++" package that does not
use "g++" to link and uses "gcc" instead.

My question is whether this is "The Way". If so it could be
documented as a solution to at least some of the "problem" cases.

Regards,

Kapil.

P.S. Please CC me I do not subscribe to this list.
--



signature.asc
Description: Digital signature

Re: Desktop task(sel) in Etch? (Bug #389092)

[Christian Perrier]

> Given that French keyboards have virtually no key at the "proper"
> place, that's quite hard to accomplish...


Evil Troll...:-)...let me jump into it.

The "only" keys in the ASCII set that are at different places in the
French keyboard are "a" "z" "q" "w" and "m". I added "y" to the list
because of the Evil German|Swiss|others QWERTZ keyboards

That still leaves 20 ASCII characters which are supposedly at the same
place on all keyboards (to be checked, though).




signature.asc
Description: Digital signature

Re: Desktop task(sel) in Etch? (Bug #389092)

[Andreas Tille]

On Thu, 28 Sep 2006, Christian Perrier wrote:


That still leaves 20 ASCII characters which are supposedly at the same
place on all keyboards (to be checked, though).


I guess that there are other language keyboards around that leave us
only 5 or 6 characters to choose from.  So what about giving a link
to a web page displaying the keyboard layout of a US keyboard?  People
who downloaded the ISOs should be able to download this layout as
well and just put it next to the keyboard they are using?

Just an idea

  Andreas.
--
http://fam-tille.de


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