Re: electronics-menu REJECTED (discussion)

[Josselin Mouette]

Le lundi 14 janvier 2008 à 21:25 +, Peter Clifton a écrit :
> Since there are no other categories in the XDG spec which fit, this is
> really why the problem occurs:
> 
> "Every conforming desktop environment MUST support" (XDG menu-spec)

At least for GNOME, I have nothing against adding new menus. We have
already done that for games, and this could be done for other categories
as well.

> Clearly the people who wrote the XDG menu spec didn't consider any
> technical applications:
> 
>   Hydrology
>   GIS (Geographic Information system)
>   Mathematics, e.g. Matlab / Octave (if it had a GUI) / others
>   Mechanical CAD packages
>   Structural analysis
>   Electrical CAD, IC Design etc..
>   Circuit simulation
> 
> Also:
>   Hamradio, Knitting, Cave surveying, 
>   Physics, Chemistry, 
>   Medical imaging, Radar, 

I think the good solution is a new "technical" menu with optional
submenus appearing when it becomes too large. If you can agree on the
structure of this menu and make it fit as much as possible to existing
XDG categories, it could be easily added.

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


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

Re: Bug#460504: dh_desktop/dh_icons madness

[Josselin Mouette]

Le dimanche 13 janvier 2008 à 22:02 +0100, Loïc Minier a écrit :
> >On a technical level, the best approach would appear to be
> > implementing some sort of global dpkg postinst and postrm hooks.
> 
>  Yes, "triggers"; I think these were not available at the time of the
>  first implementations; I did object to the current implementation for
>  many reasons -- but not to use triggers -- but as I didn't produce any
>  alternative code, the proposed implementation was merged and is now
>  what we rely on.  I'd very much like if someone would provide a simpler
>  implementation, which I imagine could be based on triggers.

As soon as triggers are available, the current implementation of both
update-desktop-database and update-icon-caches (as well as scrollkeeper)
can be trivially made to use them.

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


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

Re: gnome 1.x removal

[Pierre Habouzit]

On Tue, Jan 15, 2008 at 09:34:54AM +, Pierre Habouzit wrote:
> On Tue, Jan 15, 2008 at 01:10:26AM +, Thomas Bushnell BSG wrote:
> > Don't start filing remove requests until other maintainers have a
> > chance.  Take the step of contacting those who maintain packages that
> > depend on the libraries you want to remove, post RFAs instead of remove
> > requests, and only post remove requests after people have had a goodly
> > chance to take over maintenance themselves.

  And please don't disregard the Reply-To I set, debian-release@ isn't a
discussion list. Thanks.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpbAv6TJaB5S.pgp
Description: PGP signature

Re: gnome 1.x removal

[Pierre Habouzit]

On Tue, Jan 15, 2008 at 01:10:26AM +, Thomas Bushnell BSG wrote:
> Don't start filing remove requests until other maintainers have a
> chance.  Take the step of contacting those who maintain packages that
> depend on the libraries you want to remove, post RFAs instead of remove
> requests, and only post remove requests after people have had a goodly
> chance to take over maintenance themselves.

  Please, gnome 1.x is discontinued for years now, and the number of
packages that depends upon gnome-libs is fairly limited now, it's a
bearable task. FWIW the current list of package is:

cheops-ng
coriander
cronosii
directory-administrator
fvwm
gabber
gaby
gbatnav
gbib
gdk-pixbuf
gfontview
gfslicer
glotski
gmanedit
gmoo
gnome-chess
gnome-lokkit
gnome-print
gnomemm
gnomp3
gpgp
gphotocoll
gtkgo
gtkgrepmail
gtoaster
junior-gnome
libglade
libgtk-canvas
libgtk-perl
mathwar
multi-gnome-terminal [ maintainer already agreed upon removal ]
nethack
pimppa
powershell
snac
soundtracker
spacechart
telegnome
terraform
xemacs21
xgsmlib
xwine

  Most of those package either have far better alternatives (gabber,
gtoaster, …), are libs (lib*, gnomemm, …) or will probably easily drop
the dependency (xemacs21, nethack, …). Most of the upstreams of those
applications are dead, and the applications don't budge, and there is
little point in having them in lenny when you can use the version in
etch on your lenny without a problem.

  And btw, I didn't filed a bug for removal of gnome-libs yet, I'll
first wait to see how this list get reduced.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpy7OEtvCtHe.pgp
Description: PGP signature

Lenny (testing): Install hangs

[Dag Andersen]

Hi, tried to install this:
debian-testing-amd64-netinst.iso
from 2008-13-01.
It hangs during download of files. I tried twice, first time stopped after 
approx 600, second after 841 of 923, that's 30-45 mins into a 1 hour 
download.
Only thing I can see is that there is no activity on the network.
The network uses DHCP, so maybe a renewal problem? (Wild guess)
-- 
Mvh
Dag Andersen


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

Re: Intent to help maintaining libxml++s

[Deng Xiyue]

Deng Xiyue <[EMAIL PROTECTED]> writes:

> ...so I can be safely removed when it has 0 rdepends.

And of course, s/I/it/ . Sorry for the stupid typo :P


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

Re: Intent to help maintaining libxml++s

[Deng Xiyue]

Deng Xiyue <[EMAIL PROTECTED]> writes:

> can do to help, so I can be safely removed when it has 0 rdepends.

And of course, s/I/it . Sorry for this stupid typo :P


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

Intent to help maintaining libxml++s

[Deng Xiyue]

As confirmed by QA team that Chris Leishman <[EMAIL PROTECTED]>, the
maintainer of libxml++{,2.6} is kind of MIA, I would like to help
comaintaining these libs.  I've already file a wishlist bug for
libxml++2.6 (#430142[1]), which contains a preliminary version of
.diff.gz and .dsc against latest upstream version, which fixes various
bugs on BTS. 

As for libxml++, currently it has 2 rdepends, which are ofx and
passepartout.  According to #460407[2], libofx might got removed from
Debian in the nearing future, so that only leaves passepartout.
Currently, its upstream hasn't start the transition, so
libxml++1.0 has to stay for some time.  I'll see if there's anything I
can do to help, so I can be safely removed when it has 0 rdepends.

As for myself, I'm currently maintaining several GTK+/GNOME C++
bindings.  My QA page is at [3].  Hope I'm eligible to help :)

[1] http://bugs.debian.org/430142
[2] http://bugs.debian.org/460407
[3] http://qa.debian.org/[EMAIL PROTECTED]


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

Change default directory in a package

[Rodrigo Tavares]

Hello,

When I install a program in Windows, it's need to set
one directory. 


I would like make the same with packages debian.

How I can do it ?


Best regards,

Faria




  Abra sua conta no Yahoo! Mail, o único sem limite de espaço para 
armazenamento!
http://br.mail.yahoo.com/


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

Re: Change default directory in a package

[Norbert Preining]

Hi Faria,

this is a "development" list, not a user support list. You have higher
chances of getting responses when you ask one of the local user groups
or mailing lists.

On Di, 15 Jan 2008, Rodrigo Tavares wrote:
> When I install a program in Windows, it's need to set
> one directory. 
> 
> 
> I would like make the same with packages debian.

I assume you mean the working directory. Changing directory to the place
you want to have as "the directory" should do it.

If you need it automatized, a small script like:
cd /pat/to/dir/you/want
start-the-program-you-want
will do it.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
MUNDERFIELD (n.) A meadow selected, whilst driving past, as being
ideal for a picnic which, from a sitting position, turns out to be
full of stubble, dust and cowpats, and almost impossible to enjoy
yourself in.
--- Douglas Adams, The Meaning of Liff


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

Re: gnome 1.x removal

[Marc 'HE' Brockschmidt]

"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes:
> "As long as there's interest the software will stay alive" is one of the 
> main tenets of Free Software. Consequently, IMHO, as long as there's people 
> willing to maintain it, it shouldn't be removed regardless of how old it 
> is. 

GNOME 1.x is neither maintained in Debian nor upstream. Noone has
stepped forward to keep it alive. The main reason that it's still in
Debian is that we don't clean up often enough.

Marc
-- 
BOFH #24:
network packets travelling uphill (use a carrier pigeon)


pgpjiLeTBCg38.pgp
Description: PGP signature

Re: electronics-menu REJECTED (discussion)

[Hamish Moffatt]

On Tue, Jan 15, 2008 at 11:34:10PM +1100, Hamish Moffatt wrote:
> Can submenus be made to appear automatically? I should study the
> standards.

Err, like you did already for games, as you said. I see in the 
standard GNOME gnome-applications.menu.

It appears that the Technical menu should include at least;
- Science
- Engineering
- Math
- HamRadio
- Electronics

(The Freedesktop.org menu spec doesn't list Engineering as related to
Electronics, which I think is an oversight.)

I'm not sure if it needs to list ALL of the relevant Additional
Categories; the above are the set of related categories which cover
them.

Should we develop a patch for gnome-menus and submit it in a bug report?

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


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

Re: electronics-menu REJECTED (discussion)

[Hamish Moffatt]

On Tue, Jan 15, 2008 at 10:39:03AM +0100, Josselin Mouette wrote:
> Le lundi 14 janvier 2008 à 21:25 +, Peter Clifton a écrit :
> > Since there are no other categories in the XDG spec which fit, this is
> > really why the problem occurs:
> > 
> > "Every conforming desktop environment MUST support" (XDG menu-spec)
> 
> At least for GNOME, I have nothing against adding new menus. We have
> already done that for games, and this could be done for other categories
> as well.
> 
[...]
> I think the good solution is a new "technical" menu with optional
> submenus appearing when it becomes too large. If you can agree on the
> structure of this menu and make it fit as much as possible to existing
> XDG categories, it could be easily added.

Thanks for the suggestion. I agree, with questions:

How many is too many? I understand that having many top-level menus with
a few entries each may be confusing, but grouping electronics, science
and hamradio applications on one menu is also rather odd.

Can submenus be made to appear automatically? I should study the
standards.

I opened #339305 requesting gnome-menus add a ham radio menu more than
two years ago and unfortunately the maintainer has not responded at all.

That still leaves KDE. I guess it has its own implementation of the
standard XDG menus somewhere. Is it better to have a single
implementation of these extra menus that could be recommended by
gnome-menus and (?)kdelibs-data?

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


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

Re: gnome 1.x removal

[cobaco (aka Bart Cornelis)]

On Tuesday 15 January 2008, Pierre Habouzit wrote:
> On Tue, Jan 15, 2008 at 01:10:26AM +, Thomas Bushnell BSG wrote:
> > Don't start filing remove requests until other maintainers have a
> > chance.  Take the step of contacting those who maintain packages that
> > depend on the libraries you want to remove, post RFAs instead of remove
> > requests, and only post remove requests after people have had a goodly
> > chance to take over maintenance themselves.
>
>   Please, gnome 1.x is discontinued for years now, and the number of
> packages that depends upon gnome-libs is fairly limited now, it's a
> bearable task. FWIW the current list of package is:

"As long as there's interest the software will stay alive" is one of the 
main tenets of Free Software. Consequently, IMHO, as long as there's people 
willing to maintain it, it shouldn't be removed regardless of how old it 
is. 

=> If the current maintainer is no longer interested others should get the 
change to step forward and take over, and only if noone steps up it should 
be removed
-- 
Cheers, cobaco (aka Bart Cornelis)


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

Re: electronics-menu REJECTED (discussion)

[Andreas Tille]

On Tue, 15 Jan 2008, Hamish Moffatt wrote:


Err, like you did already for games, as you said. I see in the
standard GNOME gnome-applications.menu.

It appears that the Technical menu should include at least;
- Science
- Engineering
- Math
- HamRadio
- Electronics


And here we have good chances for a flame because I as a user would
not expect Science and Math under a main menu "Technical".  I'd rather
see "Science" as a main menu entry and find "Math" below this.  I
do not say that my point of view is correct but there is no "correct"
location for the sections and it mainly depends from users view where
he might search for certain topics.  That's my arguing for grouping
users according to their views and care for them in sub projects
were you are able to do reasonable guessings where a user would
suspect certain applications.  This was one sense for the Debian-Med
project because every user of this project will definitely enter
the "Med" main menu and can easily proceed from there.  For these
users the "Technical" menu section would be of low use.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Bug#460885: ITP: mcrl2 -- the mCRL2 formal specification language toolset

[Paul van Tilburg]

Package: wnpp
Severity: wishlist
Owner: Paul van Tilburg <[EMAIL PROTECTED]>

* Package name: mcrl2
  Version : 1.0.0
  Upstream Author : Jan Friso Groote <[EMAIL PROTECTED]> and many others
* URL : http://www.mcrl2.org/
* License : Boost Software License (MIT-like),
3rd-party software under BSD/LGPL license
  Programming Lang: C++/C
  Description : the mCRL2 formal specification language toolset

mCRL2 stands for micro Common Representation Language 2.  It is a
specification language that can be used to specify and analyse the
behaviour of distributed systems and protocols and is the successor to
muCRL.  Using its accompanying toolset, systems can be analysed and
verified automatically.

This toolset supports a collection of tools for linearisation, simulation,
state-space exploration and generation and tools to optimise and analyse
specifications.  Moreover, state spaces can be manipulated, visualised and
analysed.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (102, 'experimental')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.18-4-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Change default directory in a package

[Rodrigo Tavares]

Hello,

When I install a program in Windows, it's need to set
one directory. 


I would like make the same with packages debian.

How I can do it ?

Is there any tool for this work ?


Best regards,

Faria



  Abra sua conta no Yahoo! Mail, o único sem limite de espaço para 
armazenamento!
http://br.mail.yahoo.com/


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

launching dpkg-reconfigure from Synaptic

[SZERVÁC Attila]

 When I right-click an installed package in Synaptic, I don't see
 'Configure' option, which runs dpkg-reconfigure .

 Since Synaptic's page tells: 'Debian only: Configure packages through
 the debconf system.': allowing this option & setting Debconf priority
 from Synaptic needs a patch?

 Unfortunately Debian Desktop Users - DDUs(tm) don't really know Debconf
 system...

-- 
 sas ( satie ) - SZERVÁC Attila - zeneszerző - szoftvergazda  \
 elnökhelyettes - Linux-felhasználók Magyarországi Egyesülete - http://lme.hu/
 HU/Budapest - http://321.hu/sas/http://321.hu/Elig


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

Re: gnome 1.x removal

[cobaco (aka Bart Cornelis)]

On Tuesday 15 January 2008, Marc 'HE' Brockschmidt wrote:
> "cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes:
> > "As long as there's interest the software will stay alive" is one of
> > the main tenets of Free Software. Consequently, IMHO, as long as
> > there's people willing to maintain it, it shouldn't be removed
> > regardless of how old it is.
>
> GNOME 1.x is neither maintained in Debian nor upstream. Noone has
> stepped forward to keep it alive. The main reason that it's still in
> Debian is that we don't clean up often enough.

I had the impresion from this thread that people hadn't had the chance to 
step forward to take over maintenance yet, 
seems that impression was wrong, in which case I'm all for removal
-- 
Cheers, cobaco (aka Bart Cornelis)


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

wnpp tags "ita" and "rm"

[Sebastian Pipping]

-- rm
i noticed this bug [1] is the only wnpp bug using
the type "rm" for removal. is this an official
type that scripts talking to BTS should support?
is it documented somewhere? is it a bug in the bug
report?

-- ita
i noticed the "intent to adopt" tag is not mentioned
on [2] though used frequently. is this on purpose?
if not can somebody witha free minute add it?
i don't have write access to that page.



sebastian


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453466
[2] http://www.debian.org/devel/wnpp/#l2


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

Re: electronics-menu REJECTED (discussion)

[L. Redrejo]

El mar, 15-01-2008 a las 14:22 +0100, Andreas Tille escribió:
> On Tue, 15 Jan 2008, Hamish Moffatt wrote:
> 
> > Err, like you did already for games, as you said. I see in the
> > standard GNOME gnome-applications.menu.
> >
> > It appears that the Technical menu should include at least;
> > - Science
> > - Engineering
> > - Math
> > - HamRadio
> > - Electronics
> 
> And here we have good chances for a flame because I as a user would
> not expect Science and Math under a main menu "Technical".  I'd rather
> see "Science" as a main menu entry and find "Math" below this.  I
> do not say that my point of view is correct but there is no "correct"
> location for the sections and it mainly depends from users view where
> he might search for certain topics.  That's my arguing for grouping
> users according to their views and care for them in sub projects
> were you are able to do reasonable guessings where a user would
> suspect certain applications.  This was one sense for the Debian-Med
> project because every user of this project will definitely enter
> the "Med" main menu and can easily proceed from there.  For these
> users the "Technical" menu section would be of low use.


And another flame decission chance comes when you have to decide if an
application should be under , e.g., Education/electronics or
Technical/Electronics. As an example, where do you think qucs[1] should
be placed? It's wonderfull to study at a deep level how solid state
circuits work, but also wonderful for secondary school children to study
and simulate digital and analogic circuits...

On the other hand, I want to point an undesirable behaviour out: if you
take a look at gnome-applications.menu or kde-applications.menu they
place the merged-directories entry at the beggining of the file, that
has a bad secondary effect: if you want to exclude a desktop file to
appear in a menu branch you can not, as it will be include by the rest
of the file. As example: if you create a Education/Electronic branch
using merged-directories you would like to put applications with
categories Education;Electronics there, but as merged-directories is
merged at the beggining, you waste your time if you try to exclude them
from the education branch, so that application will appear twice: at the
Education branch and at the Education/Electronics branch. That kind of
behaviour only can be avoided using dektop-profiles so the user can
choose what kind of profile he belongs to. So if a user is at the
teachers of students menus he can see qucs at Education/Electronics and
if he is in the, let's say, scientists group he can see it at
Technical/Electronics. 

So, if the right profiles are installed in the system, with 
apt-get install  
the user will see the application in a different branch depending of the
system groups he belongs.


Regards.
José L.

[1] http://packages.debian.org/sid/qucs


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

Re: wnpp tags "ita" and "rm"

[Nico Golde]

Hi Sebastian,
* Sebastian Pipping <[EMAIL PROTECTED]> [2008-01-15 15:58]:
> -- rm
> i noticed this bug [1] is the only wnpp bug using
> the type "rm" for removal. is this an official
> type that scripts talking to BTS should support?
> is it documented somewhere? is it a bug in the bug
> report?

In general this is only used to express why the package 
should be removed without forcing people to read the whole 
bug log. I think supporting the possible RM tags would be 
nice. The meanings are explained on:
http://ftp-master.debian.org/removals.html
(top of the page)

> -- ita
> i noticed the "intent to adopt" tag is not mentioned
> on [2] though used frequently. is this on purpose?

I guess yes since this part is about adding a new wnpp bug. 
And adding a bug with ITA as tag does not make much sense.
It is documented on http://www.debian.org/devel/wnpp/#l3.

> if not can somebody witha free minute add it?
> i don't have write access to that page.

It may not hurt to add it with an explanation on the wnpp 
site. Just file a wishlist bug against www.debian.org if you 
want this.

Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpyiJ6ecxOmd.pgp
Description: PGP signature

Re: electronics-menu REJECTED (discussion)

[Andreas Tille]

On Tue, 15 Jan 2008, José L. Redrejo Rodríguez wrote:


And here we have good chances for a flame because I as a user would
not expect Science and Math under a main menu "Technical".  I'd rather
see "Science" as a main menu entry and find "Math" below this.  I
do not say that my point of view is correct but there is no "correct"
location for the sections and it mainly depends from users view where
he might search for certain topics.  That's my arguing for grouping
users according to their views and care for them in sub projects
were you are able to do reasonable guessings where a user would
suspect certain applications.  This was one sense for the Debian-Med
project because every user of this project will definitely enter
the "Med" main menu and can easily proceed from there.  For these
users the "Technical" menu section would be of low use.



And another flame decission chance comes when you have to decide if an
application should be under , e.g., Education/electronics or
Technical/Electronics. As an example, where do you think qucs[1] should
be placed? It's wonderfull to study at a deep level how solid state
circuits work, but also wonderful for secondary school children to study
and simulate digital and analogic circuits...


But your argument exactly supports my position that the place
where a user expects a program depends from the tasks a user has to
do.  So we need user groups first and afterwards we need the
apropriate menus.  It's hard to believe but people (sometimes we
forget that users are people ;-)) are different and there is no
really good way to find a general menu.


So, if the right profiles are installed in the system, with
apt-get install 
the user will see the application in a different branch depending of the
system groups he belongs.


I did not dived very deeply into this but does "system group"
here UNIX group or is this even transparent for LDAP using systems etc.?

Kind regards

Andreas.

--
http://fam-tille.de

Re: electronics-menu REJECTED (discussion)

[L. Redrejo]

El mar, 15-01-2008 a las 16:22 +0100, Andreas Tille escribió:
> On Tue, 15 Jan 2008, José L. Redrejo Rodríguez wrote:
> 
> >> And here we have good chances for a flame because I as a user would
> >> not expect Science and Math under a main menu "Technical".  I'd rather
> >> see "Science" as a main menu entry and find "Math" below this.  I
> >> do not say that my point of view is correct but there is no "correct"
> >> location for the sections and it mainly depends from users view where
> >> he might search for certain topics.  That's my arguing for grouping
> >> users according to their views and care for them in sub projects
> >> were you are able to do reasonable guessings where a user would
> >> suspect certain applications.  This was one sense for the Debian-Med
> >> project because every user of this project will definitely enter
> >> the "Med" main menu and can easily proceed from there.  For these
> >> users the "Technical" menu section would be of low use.
> >
> >
> > And another flame decission chance comes when you have to decide if an
> > application should be under , e.g., Education/electronics or
> > Technical/Electronics. As an example, where do you think qucs[1] should
> > be placed? It's wonderfull to study at a deep level how solid state
> > circuits work, but also wonderful for secondary school children to study
> > and simulate digital and analogic circuits...
> 
> But your argument exactly supports my position that the place
> where a user expects a program depends from the tasks a user has to
> do.  So we need user groups first and afterwards we need the
> apropriate menus.  It's hard to believe but people (sometimes we
> forget that users are people ;-)) are different and there is no
> really good way to find a general menu.

Exactly, my conclusions after working sometime on this issue is the
same: we need user groups, then menu profiles for those groups  , then
desktop-profiles to join both (just
using /etc/xdg/menu/applications-merged doesn't work because of the bad
place of the "" line in current
gnome/kde-applications.menu files) 

> 
> > So, if the right profiles are installed in the system, with
> > apt-get install 
> > the user will see the application in a different branch depending of the
> > system groups he belongs.
> 
> I did not dived very deeply into this but does "system group"
> here UNIX group or is this even transparent for LDAP using systems etc.?
> 

I think so, I don't see any reason for a more complicated solution. I
did my tests for education using students & teachers unix groups (under
LDAP) with desktop-profiles and it works perfectly.

Regards, 
José L.


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

Re: gnome 1.x removal

[Thomas Bushnell BSG]

On Tue, 2008-01-15 at 10:34 +0100, Pierre Habouzit wrote:
> On Tue, Jan 15, 2008 at 01:10:26AM +, Thomas Bushnell BSG wrote:
> > Don't start filing remove requests until other maintainers have a
> > chance.  Take the step of contacting those who maintain packages that
> > depend on the libraries you want to remove, post RFAs instead of remove
> > requests, and only post remove requests after people have had a goodly
> > chance to take over maintenance themselves.
> 
>   Please, gnome 1.x is discontinued for years now, and the number of
> packages that depends upon gnome-libs is fairly limited now, it's a
> bearable task. FWIW the current list of package is:

This is what people said before, and gnucash nearly vanished from Debian
because the gnome team hadn't bothered to alert me or arrange an orderly
transition.

So please, let these maintainers choose, rather than ordering them
about.  It is *they* who are in a position to decide whether maintaining
gnome 1.x is worth it.  Of course, it will also be up to them to do the
maintenance.

>   Most of those package either have far better alternatives (gabber,
> gtoaster, …), are libs (lib*, gnomemm, …) or will probably easily drop
> the dependency (xemacs21, nethack, …). Most of the upstreams of those
> applications are dead, and the applications don't budge, and there is
> little point in having them in lenny when you can use the version in
> etch on your lenny without a problem.

Most?  Really?  Wow, I'm impressed.  Are you sure?  People said this the
last time around, and they forgot gnucash.  How about we let these
maintainers make that determination rather than you making it for them?

Thomas

Re: gnome 1.x removal

[Pierre Habouzit]

On Tue, Jan 15, 2008 at 04:35:54PM +, Thomas Bushnell BSG wrote:
> 
> On Tue, 2008-01-15 at 10:34 +0100, Pierre Habouzit wrote:
> > On Tue, Jan 15, 2008 at 01:10:26AM +, Thomas Bushnell BSG wrote:
> > > Don't start filing remove requests until other maintainers have a
> > > chance.  Take the step of contacting those who maintain packages that
> > > depend on the libraries you want to remove, post RFAs instead of remove
> > > requests, and only post remove requests after people have had a goodly
> > > chance to take over maintenance themselves.
> > 
> >   Please, gnome 1.x is discontinued for years now, and the number of
> > packages that depends upon gnome-libs is fairly limited now, it's a
> > bearable task. FWIW the current list of package is:
> 
> This is what people said before, and gnucash nearly vanished from Debian
> because the gnome team hadn't bothered to alert me or arrange an orderly
> transition.
> 
> So please, let these maintainers choose, rather than ordering them
> about.  It is *they* who are in a position to decide whether maintaining
> gnome 1.x is worth it.  Of course, it will also be up to them to do the
> maintenance.

Now explain me why _you_ who aren't concerned by the transition are from
far the most vocal about it ?

> >   Most of those package either have far better alternatives (gabber,
> > gtoaster, …), are libs (lib*, gnomemm, …) or will probably easily drop
> > the dependency (xemacs21, nethack, …). Most of the upstreams of those
> > applications are dead, and the applications don't budge, and there is
> > little point in having them in lenny when you can use the version in
> > etch on your lenny without a problem.
> 
> Most?  Really?  Wow, I'm impressed.  Are you sure?  People said this the
> last time around, and they forgot gnucash.  How about we let these
> maintainers make that determination rather than you making it for them?

I opened bugs on the packages so that people can discuss it, and I'll
monitor them closely I said it. The fact that you don't seem to trust my
word that it's exactly what I'll do is insulting.

And again please stop Cc-ing debian-release.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpsn8cEXmIof.pgp
Description: PGP signature

Re: gnome 1.x removal

[Neil McGovern]

On Tue, Jan 15, 2008 at 11:35:54AM -0500, Thomas Bushnell BSG wrote:
> So please, let these maintainers choose, rather than ordering them
> about.  It is *they* who are in a position to decide whether maintaining
> gnome 1.x is worth it.  Of course, it will also be up to them to do the
> maintenance.
> 

gnome-libs has now been orphaned for more than a year. I would have
expected it to have been picked up by now.

> Most?  Really?  Wow, I'm impressed.  Are you sure?  People said this the
> last time around, and they forgot gnucash.  How about we let these
> maintainers make that determination rather than you making it for them?
> 

Do you know of any specific examples that would cause a problem?

Neil
-- 
 hm, maybe wearing a black t-shirt while dusting my bedroom for the
first time in years wasn't such a good idea


signature.asc
Description: Digital signature

Re: wnpp tags "ita" and "rm"

[David Moreno Garza]

On Tue, 2008-01-15 at 15:56 +0100, Sebastian Pipping wrote:
> -- rm
> i noticed this bug [1] is the only wnpp bug using
> the type "rm" for removal. is this an official
> type that scripts talking to BTS should support?
> is it documented somewhere? is it a bug in the bug
> report?
> 
> -- ita
> i noticed the "intent to adopt" tag is not mentioned
> on [2] though used frequently. is this on purpose?
> if not can somebody witha free minute add it?
> i don't have write access to that page.

Well, there's really no official thing on the wnpp bug titles. I've been
working on the past on this, you can see some explanation on:
http://people.debian.org/~damog/wnpp/malformed-titles.html

If you think on adding such new title conventions, please talk first to
-wnpp or on -qa.

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 El micrófono es mi metralleta.

Re: wnpp tags "ita" and "rm"

[Steve Langasek]

reassign 453466 ftp.debian.org
thanks

On Tue, Jan 15, 2008 at 03:56:35PM +0100, Sebastian Pipping wrote:
> -- rm
> i noticed this bug [1] is the only wnpp bug using
> the type "rm" for removal. is this an official
> type that scripts talking to BTS should support?
> is it documented somewhere? is it a bug in the bug
> report?

As the bug log shows, this is a result of a misspelled keyword.  Removal
bugs are supposed to be assigned to ftp.debian.org.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: gnome 1.x removal

[Thomas Bushnell BSG]

On Tue, 2008-01-15 at 17:56 +0100, Pierre Habouzit wrote:
> > So please, let these maintainers choose, rather than ordering them
> > about.  It is *they* who are in a position to decide whether maintaining
> > gnome 1.x is worth it.  Of course, it will also be up to them to do the
> > maintenance.
> 
> Now explain me why _you_ who aren't concerned by the transition are from
> far the most vocal about it ?

Because the last time you all did this it got all the way to deleting
the packages and I had to run around and clean that up.  I'm asking you
to give the maintainers a chance.  That's all.  Is it really that hard
to do?

> I opened bugs on the packages so that people can discuss it, and I'll
> monitor them closely I said it. The fact that you don't seem to trust my
> word that it's exactly what I'll do is insulting.

I didn't say I didn't trust your word.




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

Re: gnome 1.x removal

[Thomas Bushnell BSG]

On Tue, 2008-01-15 at 13:39 +0100, Marc 'HE' Brockschmidt wrote:
> "cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes:
> > "As long as there's interest the software will stay alive" is one of the 
> > main tenets of Free Software. Consequently, IMHO, as long as there's people 
> > willing to maintain it, it shouldn't be removed regardless of how old it 
> > is. 
> 
> GNOME 1.x is neither maintained in Debian nor upstream. Noone has
> stepped forward to keep it alive. The main reason that it's still in
> Debian is that we don't clean up often enough.

This is what was said the last time.  But nobody asked the maintainers
of gnome 1.x packages whether they would maintain it; the team just
decreed that nobody would step forward, and started deleting packages.
It caused a major headache.  I'm asking for a more orderly process this
time.  Instead of saying "we're deleting this, you will all have to
adapt", say, "we aren't maintaining this anymore; if you want it, you'll
have to start taking it over."

Thomas



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

Re: gnome 1.x removal

[Thomas Bushnell BSG]

On Tue, 2008-01-15 at 17:02 +, Neil McGovern wrote:
> On Tue, Jan 15, 2008 at 11:35:54AM -0500, Thomas Bushnell BSG wrote:
> > So please, let these maintainers choose, rather than ordering them
> > about.  It is *they* who are in a position to decide whether maintaining
> > gnome 1.x is worth it.  Of course, it will also be up to them to do the
> > maintenance.
> > 
> 
> gnome-libs has now been orphaned for more than a year. I would have
> expected it to have been picked up by now.

I wouldn't.  I don't keep tabs on every package that my packages depend
on.  One of them could be orphaned and I would never know.

> > Most?  Really?  Wow, I'm impressed.  Are you sure?  People said this the
> > last time around, and they forgot gnucash.  How about we let these
> > maintainers make that determination rather than you making it for them?
> > 
> Do you know of any specific examples that would cause a problem?

No; I haven't investigated it.  That's why I am asking to let those
maintainers decide.  Thinking up yet one more way to make the decision
without involving them seems like a poor strategy.  There is no need for
me to figure out whether there is a specific example or not.  Instead,
just tell the maintainers, and give them the option.

Thomas
-


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

Re: wnpp tags "ita" and "rm"

[Sebastian Pipping]

Nico Golde wrote:

i noticed the "intent to adopt" tag is not mentioned
on [2] though used frequently. is this on purpose?


I guess yes since this part is about adding a new wnpp bug. 
And adding a bug with ITA as tag does not make much sense.

It is documented on http://www.debian.org/devel/wnpp/#l3.


makes sense. thank you!




sebastian


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

Re: gnome 1.x removal

[Luk Claes]

Thomas Bushnell BSG wrote:
> On Tue, 2008-01-15 at 13:39 +0100, Marc 'HE' Brockschmidt wrote:
>> "cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes:
>>> "As long as there's interest the software will stay alive" is one of the 
>>> main tenets of Free Software. Consequently, IMHO, as long as there's people 
>>> willing to maintain it, it shouldn't be removed regardless of how old it 
>>> is. 
>> GNOME 1.x is neither maintained in Debian nor upstream. Noone has
>> stepped forward to keep it alive. The main reason that it's still in
>> Debian is that we don't clean up often enough.
> 
> This is what was said the last time.  But nobody asked the maintainers
> of gnome 1.x packages whether they would maintain it; the team just
> decreed that nobody would step forward, and started deleting packages.
> It caused a major headache.  I'm asking for a more orderly process this
> time.  Instead of saying "we're deleting this, you will all have to
> adapt", say, "we aren't maintaining this anymore; if you want it, you'll
> have to start taking it over."

We can surely keep all old cruft in the archive and never release again
(or not with these packages anyway), though I don't think that is
preferred from a quality assurance, security nor release point of view...

Cheers

Luk


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

Bug#460942: ITP: line6usb-source -- Line 6 POD driver source

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: line6usb-source
  Version : 0.7.2
  Upstream Author : Markus Grabner
* URL : http://www.tanzband-scream.at/line6/
* License : GPL
  Programming Lang: C
  Description : Line 6 POD driver source

An experimental driver for the guitar amp, cab, and effects modeller 
PODxt Pro by Line6 (and similar devices), supporting the following features:

 * Reading/writing individual parameters
 * Reading/writing complete channel, effects setup, and amp setup data
 * Channel switching
 * Virtual MIDI interface
 * Tuner access
 * Playback/capture/mixer device for any ALSA-compatible
 * PCM audio application
 * Signal routing (record clean/processed guitar signal, re-amping)

(Include the long description here.)

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

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

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

iQCVAwUBR40Afwy0JeEGD2blAQKoogP/cQBP+9IH4wI+EMJD/dkmE09BNeujNh+8
2CFjD+2qi5qForrzdLbPwfgLy2t1DVgBfSlnyQBVtvuDUt5HY5wpcYkgU10UndpX
SJV5NCIQ/iHsT2hgmA9rcawajLxlxsAzc3ZxZla216We0sfkIqDRCVxo7qLK28jG
rdOx979oeOE=
=FcZz
-END PGP SIGNATURE-



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

Re: gnome 1.x removal

[Russ Allbery]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> I wouldn't.  I don't keep tabs on every package that my packages depend
> on.  One of them could be orphaned and I would never know.

Running wnpp-alert weekly out of cron is a good idea for any DD, IMO.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: gnome 1.x removal

[Ben Finney]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Instead of saying "we're deleting this, you will all have to adapt",
> say, "we aren't maintaining this anymore; if you want it, you'll
> have to start taking it over."

Isn't that exactly what bug #369130 means? I thought it was the
responsibility of the package maintainer to run 'wnpp-alert' to be
aware if the packages they depend on need help.

It was retitled as ITA on 2007-08-19, and not altered since then. That
means it won't show up in 'wnpp-alert', which is unfortunate since
it's been rather a long time.

-- 
 \ "I know when I'm going to die, because my birth certificate has |
  `\an expiration date."  -- Steven Wright |
_o__)  |
Ben Finney


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

Re: electronics-menu REJECTED (discussion)

[Hamish Moffatt]

On Tue, Jan 15, 2008 at 02:22:19PM +0100, Andreas Tille wrote:
> On Tue, 15 Jan 2008, Hamish Moffatt wrote:
>
>> Err, like you did already for games, as you said. I see in the
>> standard GNOME gnome-applications.menu.
>>
>> It appears that the Technical menu should include at least;
>> - Science
>> - Engineering
>> - Math
>> - HamRadio
>> - Electronics
>
> And here we have good chances for a flame because I as a user would
> not expect Science and Math under a main menu "Technical".  I'd rather
> see "Science" as a main menu entry and find "Math" below this.  I

By the way, our main aim in proposing the original electronics-menu
package was simply to get these packages out of Other and into a
relevant menu. I imagine that Science is suffering similarly.

I would be happy to get a simple solution in place before working on the
larger problems of different user views etc.


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


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

Re: gnome 1.x removal

[Thomas Bushnell BSG]

On Tue, 2008-01-15 at 19:56 +0100, Luk Claes wrote:
> We can surely keep all old cruft in the archive and never release again
> (or not with these packages anyway), though I don't think that is
> preferred from a quality assurance, security nor release point of view...

Of course, this isn't what I suggested.

Thomas



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

Re: electronics-menu REJECTED (discussion)

[Hamish Moffatt]

On Tue, Jan 15, 2008 at 02:22:19PM +0100, Andreas Tille wrote:
> On Tue, 15 Jan 2008, Hamish Moffatt wrote:
>
>> Err, like you did already for games, as you said. I see in the
>> standard GNOME gnome-applications.menu.
>>
>> It appears that the Technical menu should include at least;
>> - Science
>> - Engineering
>> - Math
>> - HamRadio
>> - Electronics
>
> And here we have good chances for a flame because I as a user would
> not expect Science and Math under a main menu "Technical".  I'd rather
> see "Science" as a main menu entry and find "Math" below this.  I
> do not say that my point of view is correct but there is no "correct"
> location for the sections and it mainly depends from users view where
> he might search for certain topics.  That's my arguing for grouping

I thought that Science fit under Technical, if the offer was for
one additional main menu. However it's clearly big enough to have its
own main menu (there are lots of Science sub-categories in the
standard).

Math is an interesting case in that it's obviously a science, yet the
tools are also used in engineering and also education. Hence your point
about different user views. (On the other hand, putting everything under
Technical helps too :)).


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


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

Bug#460965: ITP: kpar2 -- a frontend for verifying and repairing PAR and PAR2 recovery sets

[Fathi Boudra]

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

Package name: kpar2
Version: 0.3.1
Upstream Author: Lawrence Lee <[EMAIL PROTECTED]>
URL: http://kde-apps.org/content/show.php/KPar2?content=70101
License: GPL
Description: a frontend for verifying and repairing PAR and PAR2 recovery sets

KPar2 is a simple, easy to use graphical interface for verification and repair
of PAR v1.0 and PAR v2.0 (PAR2) recovery sets.

Parity Volumes may be used to verify that a set of files have not been
corrupted, or to reconstruct damaged files (providing that you have a
sufficient quantity of Parity Volumes to match the missing or damaged files).



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

Re: gnome 1.x removal

[Moritz Muehlenhoff]

Pierre Habouzit wrote:
> As per release goal, gnome 1.x won't be shipped in Lenny. I just started
> a first round of bugs (severity important for now), with user/usertag
> [EMAIL PROTECTED]/gnome-1.x-removal so that people
> interested in that goal can track our progress.

Two thumbs up, thanks for pushing this. 

> Then I'll do some more runs of the same principle on other gnome 1.x
> related libs until we got rid of them al.

If possible, libxml should be removed as well, most of the rev deps
are gnome1-related and the few remaining packages could be fixed to
use libxml2.

Cheers,
Moritz




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

Re: gnome 1.x removal

[Pierre Habouzit]

On Tue, Jan 15, 2008 at 10:53:50PM +, Moritz Muehlenhoff wrote:
> Pierre Habouzit wrote:
> > As per release goal, gnome 1.x won't be shipped in Lenny. I just started
> > a first round of bugs (severity important for now), with user/usertag
> > [EMAIL PROTECTED]/gnome-1.x-removal so that people
> > interested in that goal can track our progress.
> 
> Two thumbs up, thanks for pushing this. 
> 
> > Then I'll do some more runs of the same principle on other gnome 1.x
> > related libs until we got rid of them al.
> 
> If possible, libxml should be removed as well, most of the rev deps
> are gnome1-related and the few remaining packages could be fixed to
> use libxml2.

  Okay, this will go next then, consider it on my todolist.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp8mQGaKASZt.pgp
Description: PGP signature

Re: electronics-menu REJECTED (discussion)

[Charles Plessy]

> On Tue, Jan 15, 2008 at 10:39:03AM +0100, Josselin Mouette wrote:
> > I think the good solution is a new "technical" menu with optional
> > submenus appearing when it becomes too large. If you can agree on the
> > structure of this menu and make it fit as much as possible to existing
> > XDG categories, it could be easily added.

Le Tue, Jan 15, 2008 at 11:34:10PM +1100, Hamish Moffatt a écrit :
> I opened #339305 requesting gnome-menus add a ham radio menu more than
> two years ago and unfortunately the maintainer has not responded at all.

Le Tue, Jan 15, 2008 at 11:48:33PM +1100, Hamish Moffatt a écrit :
> It appears that the Technical menu should include at least;
> - Science
> - Engineering
> - Math
> - HamRadio
> - Electronics

Le Tue, Jan 15, 2008 at 02:22:19PM +0100, Andreas Tille a écrit :
> And here we have good chances for a flame because I as a user would
> not expect Science and Math under a main menu "Technical".  I'd rather
> see "Science" as a main menu entry and find "Math" below this.  I
> do not say that my point of view is correct but there is no "correct"
> location for the sections and it mainly depends from users view where
> he might search for certain topics.  That's my arguing for grouping
> users according to their views and care for them in sub projects
> were you are able to do reasonable guessings where a user would
> suspect certain applications.  This was one sense for the Debian-Med
> project because every user of this project will definitely enter
> the "Med" main menu and can easily proceed from there.  For these
> users the "Technical" menu section would be of low use.

Le Tue, Jan 15, 2008 at 03:32:07PM +0100, José L. Redrejo Rodríguez a écrit :
> And another flame decission chance comes when you have to decide if an
> application should be under , e.g., Education/electronics or
> Technical/Electronics. As an example, where do you think qucs[1] should
> be placed? It's wonderfull to study at a deep level how solid state
> circuits work, but also wonderful for secondary school children to study
> and simulate digital and analogic circuits...

Hi all,

Some people use Debian to learn, and some other to work. I think that
the people who work do not expect their tools in the "Educational" menu,
even if their salary is payed by a university. My understanding of
"Educational" tools is programs whose sole purpose is to learn and
study, otherwise we should move OpenOffice in "Educational" in the
computers used for training people at the use of office software.

Then, the question wether some tools are scientifical or technical is in
my opinion unsolvable. I would favor a Science & Technique menu if this
is not tool long in terms of number of characters. Acutally, is is a bit
frustrating that the software developpers who wrote the standard have
given a menu entry to their own professional tools, "Development", while
other professions have not this facility (except for secretaries and
graphists). Maybe we simply need a "Pro" mode in the menus, that are
obviously very "Home"… but this makes us far from our original goal.

I have updated the wiki page http://wiki.debian.org/ExtraMenus with some
details from the standard and some parts of the current discussion. If
we want to keep things simple, and if mechanisms exist to automatically
create sub-menus using the "Additional" categories (see the wiki) when
there are too many entries, I would propose to keep things as simple as
possible and to promote 'Science & Technics' as a "Main" category.

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team


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