Re: adding desktop files to misc packages

[Sam Hocevar]

On Sun, Jul 15, 2007, Steve Langasek wrote:
> On Sun, Jul 15, 2007 at 09:56:42PM +0200, Josselin Mouette wrote:
> > The way Debian works is that developers have the final word on what
> > happens in their packages.
> 
> No, the way Debian works is that we have this little thing called Policy
> that's intended to ensure consistency between packages in the distribution
> so that the system works as a cohesive whole instead of being fragmented
> as a result of pigheadedness on the part of individual developers who think
> they know better than everybody else, and this other little thing called the
> Technical Committee to enforce Policy.

   Sorry to interrupt, but the way Debian works is that we have this
other thing called the Social Contract that says we do what our users
want. Not directed at you, Steve, but it looks like most of this thread
is slowly losing track of it.

Cheers,
-- 
Sam.


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

Re: Bug#433261: ITP: libpano13 -- panorama tools library

[Bernd Zeimetz]

>  Panorama Tools was originally created by Professor Helmut Dersch of the
>  University of Applied Sciences Furtwangen. Professor Dersch's site no
>  longer has links to download the tools, which is why this panotools
>  sourceforge project exists.

I remember vaguely that there were some copyright/licenseing issues with
at least parts of the software provided on the page of Prof. Dersch -
but I'm not sure.

Also, do you intend to package clens, too? This would be very appreciated.


Best regards,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: adding desktop files to misc packages

[Raphael Hertzog]

On Mon, 16 Jul 2007, Sam Hocevar wrote:
> On Sun, Jul 15, 2007, Steve Langasek wrote:
> > On Sun, Jul 15, 2007 at 09:56:42PM +0200, Josselin Mouette wrote:
> > > The way Debian works is that developers have the final word on what
> > > happens in their packages.
> > 
> > No, the way Debian works is that we have this little thing called Policy
> > that's intended to ensure consistency between packages in the distribution
> > so that the system works as a cohesive whole instead of being fragmented
> > as a result of pigheadedness on the part of individual developers who think
> > they know better than everybody else, and this other little thing called the
> > Technical Committee to enforce Policy.
> 
>Sorry to interrupt, but the way Debian works is that we have this
> other thing called the Social Contract that says we do what our users
> want. Not directed at you, Steve, but it looks like most of this thread
> is slowly losing track of it.

Granted. 

And at least to me it's pretty clear that the proper course of action is
replace "menu" files by "dekstop" files. Modify the menu package to use
desktop file as input and continue to use the menu package for software
which are not able to handle "desktop" file natively.

It looks like the fd.o desktop files have all the features needed to
express the various things that we need:
- indicate if it's a console or graphical application
- etc.

Then the gnome menu can filter out console applications and the menu of window
managers used by advanced users can have the full list.

Yes, it's probably some non-trivial work. And the behaviour of Josselin is
not really constructive in that regard. Because he cares only about
Gnome/KDE/Xfce, he doesn't want to fix the menu package himself. It's his
right, but then he should also acknowledge what is the proper course of
action for the project and encourage people to go in that direction
instead of throwing accusations and telling everybody how horrible the
Debian menu is.

Yes, the Debian menu is problematic in the Gnome environment:
- it confuses people
- it's sometimes regenerated in english when you install new
  packages after the initial installation
- i even saw him with only two sub menus (the apps one having
  disappeared among others)

(No I haven't bothered to check if those bugs are already reported or
not)

I completely understand the will to have that menu disappear in the Gnome
environment.

Bill, you haven't participated in this discussion, what's your opinion?
Would you like to do that work?

Would it be helpful to have the technical committee decide on this
topic?

Cheers,
-- 
Raphaës Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: adding desktop files to misc packages

[Don Armstrong]

So it seems like we should do the following:

1. Make changes to the menu system to use .desktop files in preference
to .menu files when they exist

2. Generate .desktop files from .menu files using the menu system when
.desktop files don't exist.

3. Continue using the menu system for window managers which don't
natively understand .desktop files; drop the Debian menu for those
that do.

The other issue that was brought up was improving the hierarchical
organization of the menus, but how to do that hasn't been made clear
in this thread.



Don Armstrong

-- 
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the people
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
 -- Chad C. Mulligan (John Brunner _Stand On Zanzibar p390)

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

Don Armstrong  debian.org> writes:

> 
> We can certainly attempt to do so; I don't think anyone in this thread
> is contemplanting knowingly causing audacious's upstream harm.
>

I agree, in fact, I don't think Debian would handle such a migration
in the way that Gentoo handled it. I'm just bringing forward advice
that I have observed from previous migrations that have resulted in
problems for us upstream and requesting that people don't move in the
direction that they did.

So far, things seem to be OK.
 
> > So then you are saying we should reject all bugs against audacious
> > as provided by debian which do not refer to a debian bugtracker URL
> > anyway? I'll certainly be happy to implement that.
> 
> It's entirely your decision as to what you do with your bug reports,
> but reporting bugs against the bts is what Debian users are encouraged
> to do, especially when they aren't certain whether the bug is an
> upstream problem or not.

I'll discuss that with Adam and see what he thinks would be a good idea
to do then. Since Debian users are encouraged to use sendbug(1), I have
not received many support cases from Debian users.

In fact, you could say that I have enjoyed the lack of support cases from
Debian users in general. This is probably because Audacious in Debian
does not have a gazillion insane patches on top of it, like some of the
other binary packages do.

> 
> Considering the fact that he would be involved in any transition, he's
> perfectly capable of deciding and/or recommending veribiage with which
> he is satisfied.
> 

Indeed, and I think he can come up with a way to handle such a
migration. I was simply pointing out potential problems and how they
could be avoided.

William


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

Josselin Mouette  debian.org> writes:

> 
> I think what they don't want is
>   [4] Replace XMMS by a metapackage that installs Audacious in place
> 

This is exactly what we want, as that will cause problems for us.

William


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

Bug#433343: ITP: envctrl -- Kernel modules to support the environmental monitoring hardware in Sun's E250 and E450 servers

[David Johnson]

Package: wnpp
Severity: wishlist
Owner: David Johnson <[EMAIL PROTECTED]>


* Package name: envctrl
  Version : SVN snapshot
  Upstream Authors: Eric Brower <[EMAIL PROTECTED]>, David Johnson <[EMAIL 
PROTECTED]>
* URL : http://www.david-web.co.uk/index.php?p=envctrl
* License : GPL
  Programming Lang: C, SPARC ASM
  Description : Kernel modules to support the environmental monitoring 
hardware in Sun's E250 and E450 servers

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

Steve Greenland  moregruel.net> writes:

> 
> On 14-Jul-07, 16:48 (CDT), William Pitcock  sacredspiral.co.uk>
wrote: 
> > My issue is that I find it patently offensive that people attack my work
> > simply because they wish to regain XMMS in their distribution. Maybe
> > I am wrong in thinking that way, but I'm pretty sure I'm not.
> 
> I don't think you're wrong to be offended by jerks. However, based on
> 20 years of Usenet and mailling list experience, I do think you'll be
> happier in the long run by learning to ignore them.
> 
> Steve
> 

I do ignore jerks. However, some jerks become problems for our project,
and flood our bugtrackers and distro bugtrackers with inane bugs which
point out some "flaw" in Audacious and then ask for XMMS to be restored.

Which reflects poorly on our project.

Luckily, I don't think Debian has so many jerks, as it's targeted at a
more mature audience than those distros that I speak of were.

What's funny is that some of these people who were doing this wound up
switching to Debian thinking that it would always keep XMMS for some
reason.

William


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

William Pitcock  sacredspiral.co.uk> writes:

> 
> Josselin Mouette  debian.org> writes:
> 
> > 
> > I think what they don't want is
> >   [4] Replace XMMS by a metapackage that installs Audacious in place
> > 
> 

Err to clarify, not doing [4] is exactly what we want. Sorry if anyone
got confused.


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

Eduard Bloch  gmx.de> writes:

> I disagree. As said, I dislike a simple player touching every file for no
> good reason, and I do not consider "codec detection" a such one. There
> is simply no important information you would gather from that. Validity
> of the file and the length are only interesting at play time.
> 

We've added a "feature" for people who feel this way which allows detection to
be entirely postponed until playtime. However, that is only fully functional in
1.3 and later.

> I fail to see what is so "broken" about the XMMS way. It may be
> inconvinient for you when doing (re)design since you have to deal with
> uncerntainity. But, well, are you going to create a comfortable player or
> yet another piece of stupid multimedia software?
> 

Well, I guess in your opinion we are going to create 'yet another piece of
stupid multimedia software.'

> And this is documented... where? Why not in the documentation balloons?
> Ever heard about ISO 9241? Please get a copy and read parts 13 and 14, I
> would also recommend reading VDI 3850 which is IMO a good tutorial in
> designing human machine interfaces.

It is documented at http://audacious-media-player.org/FAQ#11.4

Oh by the way, debian users can still use XMMS. There's nothing wrong with
stopping them from:

1) Doing ./configure; make; make install, or:

2) Copying the debian source archives from the previous release and using dbuild
to build packages for Lenny.

and odds are:

3) Somebody else will have already done this and made a repo somewhere.
Rarewares comes to mind.

So honestly, if Audacious is not a suitable replacement for you it does not
really matter as there are ways to retain XMMS.

William


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

Re: adding desktop files to misc packages

[Wouter Verhelst]

On Sun, Jul 15, 2007 at 02:11:55PM +0100, Neil Williams wrote:
> On Sun, 15 Jul 2007 14:36:47 +0200
> Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > Le vendredi 13 juillet 2007 à 18:34 -0400, Joey Hess a écrit :
> > > > I can't find anything in the Debian menu which is neither already in the
> > > > GNOME menu at a better place, or simply completely unsuitable for a
> > > > graphical menu.
> > > 
> > > If that's actually true, we could drop menu from the gnome-desktop and
> > > kde-destkop tasks. (What about XFCE?)
> > 
> > I wouldn't speak for KDE, but after this discussion, I'd recommend
> > dropping it from the gnome-desktop task.
> 
> It makes me wonder if there is any point keeping debian/menu at all.
> 
> Why not drop the Debian Menu Policy completely? The only sane argument
> against .desktop is hierarchy support but then the most pertinent
> complaint against menu is that the hierarchy is wasteful.

The debian menu hierarchy has just been revised, and a new menu policy
has been active since a few weeks. Why not wait that out, and see
whether that improves things? Personally, I think it will improve
matters by much.

In any case, I don't think just dropping debian/menu is the best thing
to do. Perhaps make it an option, but IMO one of the main strengths
about Debian as a whole is precisely this unified menu system. If
there's an opinion floating around that the fdo menu hierarchy is much
better, then that may be a good argument to improve the Debian menu
system, but not necessarily one to drop it entirely.

[...]
-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Bug#433358: ITP: gtkrsync -- GUI front-end to display rsync status

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: gtkrsync
  Version : 1.0.0
  Upstream Author : John Goerzen <[EMAIL PROTECTED]>
* URL : http://hg.complete.org/gtkrsync
* License : GPL
  Programming Lang: Haskell
  Description : GUI front-end to display rsync status
 gtkrsync is a simple GUI that displays a running status display
 built from rsync --progress -v.  This status display includes a
 per-file and overall status bar, overall estimated time to completion,
 and an expandable button that shows all rsync status output.
 .
 Unlike other GUI rsync frontends such as grsync, gtkrsync does not have
 any GUI tools for configuring or invoking rsync.  gtkrsync is designed
 to be invoked from the command line or shell scripts, which already
 specify all the needed rsync options.  It is thus ideal for scripted
 rsync runs that need a GUI, or for command-line users that would like a
 GUI to monitor their rsync progress.
 .
 This package provides two binaries.  gtkrsync is a drop-in replacement
 for rsync.  It fires up the GUI and invokes rsync, passing all args to
 it.  When invoked this way, gtkrsync is able to detect if rsync exits
 in error and alerts the user.  gtkrsync can also monitor both stdout
 and stderr from rsync, and displays both.  The cancel button in
 gtkrsync also will kill off the rsync process.
 .
 The other binary is gtkrsyncp.  This program accepts the output of
 rsync --progress -v on standard input and displays it in a GUI.  It
 cannot detect whether rsync exited in error and cannot kill rsync when
 Cancel is pressed.  However, this program may be useful in some cases
 when direct control of rsync is handled elsewhere.

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

Kernel: Linux 2.6.18-4-k7 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash


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

Re: adding desktop files to misc packages

[Andreas Tille]

On Sun, 15 Jul 2007, Josselin Mouette wrote:


I'm opposed to people who drink the GNOME koolaid and call it "usability".


Call it like you want. We call it usability, and it looks incompatible
with what a number of developers expect from the menu system.


I don't think that there is something like "general usability".  There might
be something that is "very usable for a certain group of users".  So claiming
to design a system for maximum usability requires to define the group of
users first.  You obviousely are speeking for thoses users that prefer
Gnome - which is perfectly valid, but a generalisation of this seems not
to be possible.


The way Debian works is that developers have the final word on what
happens in their packages. The GNOME team decides of what's in the GNOME
menu, and the WindowMaker maintainers decide what's in the WindowMaker
menu. If we can agree to put the same things in both menus, that's fine.
If we can't, we'll all go working on something more productive.


Well, I've also tried something productive: In the cdd-dev framework for
custom Debian distributions it is possible to define user roles that will
be presented with an extra menu entry that matches the tasks that are
defined for the CDD.  The rationale behind this is that I here *know*
the users and there preferences and are able to guess what they are interested
in.  Unfortunately this works only for the Debian menu system - which
should be by no means a pro-Debian-menu argument.  In contrary I plan
to implement a fd.o solution as soon as possible.

The idea I want to bring in into this discussion is that even if we really
would .desktop files in all packages it does not make the situation much
better because the menu will be very long again.  What we need is kind of
a task specific menu according to different user roles - this is exactly
what CDD intent to do: Define groups od specific users, support easy 
installation
of packages related to their tasks and prepare their dasktop accordingly.

I personally prefer a menu item for every installed package in this CDD
scope, because for a user who did not installed the machine themselves
anything that is not in the menu is "not available" or at least "hidden".

In another mail
On Sun, 15 Jul 2007, Josselin Mouette wrote:


As a consequence, this will duplicate the work, but I think we should
add .desktop entries to packages, especially games, that don't have one
and deserve it.


What do you mean with "deserve it"?  Could you please give some criteria
to deside which packages deserve a menu entry?  For which group of users
makes a menu entry sense and for which not?

Kind regards

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


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

Re: adding desktop files to misc packages

[Russ Allbery]

Andreas Tille <[EMAIL PROTECTED]> writes:
> On Sun, 15 Jul 2007, Josselin Mouette wrote:

>> As a consequence, this will duplicate the work, but I think we should
>> add .desktop entries to packages, especially games, that don't have one
>> and deserve it.

> What do you mean with "deserve it"?  Could you please give some criteria
> to deside which packages deserve a menu entry?  For which group of users
> makes a menu entry sense and for which not?

Yes, please.  This seems to be one of the fundamental objections to the
current menu system, and we *have* a Menu Policy already where this sort
of thing could be addressed.  And if we're going to replace menu with
.desktop files, we're *still* going to need a policy that addresses this.

It's all very fine and good to say that there's stuff with menu entries
that shouldn't have them, but nothing will change until someone writes a
clear policy on what should be included and what shouldn't that we can all
agree to.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

policy and userfriendlyness (Re: adding desktop files to misc packages)

[Bernhard R. Link]

* Sam Hocevar <[EMAIL PROTECTED]> [070716 12:15]:
> On Sun, Jul 15, 2007, Steve Langasek wrote:
> > On Sun, Jul 15, 2007 at 09:56:42PM +0200, Josselin Mouette wrote:
> > > The way Debian works is that developers have the final word on what
> > > happens in their packages.
> > 
> > No, the way Debian works is that we have this little thing called Policy
> > that's intended to ensure consistency between packages in the distribution
> > so that the system works as a cohesive whole instead of being fragmented
> > as a result of pigheadedness on the part of individual developers who think
> > they know better than everybody else, and this other little thing called the
> > Technical Committee to enforce Policy.
> 
>Sorry to interrupt, but the way Debian works is that we have this
> other thing called the Social Contract that says we do what our users
> want. Not directed at you, Steve, but it looks like most of this thread
> is slowly losing track of it.

But there is no single user. (If there was, we could go and ask him/her
what the users want, and would not need the whole discussion). I don't
think anyone here is not claiming to supporting what the users want.

The problem is that users have different needs and and wishes, even to
the extend of mutually exclusive ones, and different priorities.
Which especially mean that people do not want to think about everything,
so if there are decisions, there should be easier to memorize patterns
than "maintainer X does not like Y" or "gnome people don't think X
is intresting for users they can imagine". That's why having a policy
is one of the biggest advantages of Debian in being useful for users.

Hochachtungsvoll,
Bernhard R. Link


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

Re: adding desktop files to misc packages

[Steve Greenland]

On 13-Jul-07, 19:26 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> Le vendredi 13 juillet 2007 ? 17:16 -0700, Steve Langasek a ?crit :
> > > Oh my. Do you mean that in the 90 window managers shipped in Debian,
> > > none of them is suitable for all your needs and that you have to use
> > > *several* ones depending on the moment?
> > 
> > Unix systems have supported selecting window managers on-the-fly for years
> > before Debian did it.  Why does one extra entry for a submenu offend you so?
> 
> I'm wondering what is the use case for that entry.

So I can try a new window manager without restarting my xsession. 

So J. Random User can easily see what window managers are available.

Not everybody thinks GNOME and KDE are the epitome of desktop management.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: adding desktop files to misc packages

[Steve Greenland]

On 15-Jul-07, 07:17 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> The fact this is the best way to implement this feature doesn't make it
> less frivolous.
> 
> > 
> > How about next suggesting to remove all modules for hardware less than
> > 10% of users have? That would help much to not clobber the kernel
> > image
> > packages.
> > 
> 
> Kernel modules don't clutter the user interface.

But all those KDE packages clutter my usage of aptitude. So do the
windowmaker packages. And all those damn perl packages.

Just because *you* don't use something doesn't make it unimportant. One
of the big values of Debian is a long time tolerance and support of a
variety of users and use patterns, even those that are non-mainstream.
If you find the Debian menu to be clutter, fine. Ignore it, or change
the configuration to skip it.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: adding desktop files to misc packages

[Steve Greenland]

On 15-Jul-07, 14:17 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> Le dimanche 15 juillet 2007 ? 11:24 -0500, Manoj Srivastava a ?crit :
> > This sounds fairly combative; and it also begins to sound
> >  divisive (the GNOME people, keepers of usability, vs all the useless
> >  users who do not use desktop systems). I hope I am misreading the
> >  attitude.
> 
> This is your own interpretation. I understand from the discussion that
> some people are strongly opposed to the changes that are required to
> make the Debian menu more usable.

The problem is your idea of "more usable" is, to me, "remove valuable
functionality". 

Yes, the menu hierarchy could use some work. Yes, it might be better if
not every shell and console text editor had a menu entry, or if they
were buried under the "Obscure Console Apps" sub-head.

But that's got nothing to do with format of the menu entries. You're
going to have to decide policy for that kind of stuff no matter what
format you choose. And *right now*, there is a lot more support for the
Debian menu format that the freedesktop.org format.

And for the record, I'm someone who is generally in favor of the
direction GNOME chose. But I think that rather than trashing the Debian
menu system, it might be the better choice for GNOME (in Debian), to
ignore/disable the Debian menu by default.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: adding desktop files to misc packages

[Steve Greenland]

On 15-Jul-07, 15:18 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> Le dimanche 15 juillet 2007 ? 13:07 -0700, Steve Langasek a ?crit :
> > No, the way Debian works is that we have this little thing called Policy
> > that's intended to ensure consistency between packages in the distribution
> > so that the system works as a cohesive whole instead of being fragmented
> > as a result of pigheadedness on the part of individual developers who think
> > they know better than everybody else, and this other little thing called the
> > Technical Committee to enforce Policy.
> 
> I can't wait to see someone seize the technical committee to ask the
> GNOME menu to be replaced by the Debian menu.

Why do you think that would happen? None of the people here have
suggested that. You, on the other hand, have suggested that the Debian
menu system be trashed in favor the GNOME menu system.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 12:32 -0500, Steve Greenland a écrit :
> > Kernel modules don't clutter the user interface.
> 
> But all those KDE packages clutter my usage of aptitude. So do the
> windowmaker packages. And all those damn perl packages.

Nothing to do with the user interface (which in this case should be
improved to filter out packages you don't want to see), but I would be
glad if we could clean the archive of its unmaintained and/or useless
packages.

> Just because *you* don't use something doesn't make it unimportant. 

Just because you use something doesn't make it necessary.

> One
> of the big values of Debian is a long time tolerance and support of a
> variety of users and use patterns, even those that are non-mainstream.
> If you find the Debian menu to be clutter, fine. Ignore it, or change
> the configuration to skip it.

This is exactly what I am asking for.

-- 
 .''`.
: :' :  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: adding desktop files to misc packages

[Neil Williams]

On Mon, 16 Jul 2007 04:12:02 -0700
Don Armstrong <[EMAIL PROTECTED]> wrote:

> So it seems like we should do the following:
> 
> 1. Make changes to the menu system to use .desktop files in preference
> to .menu files when they exist
> 
> 2. Generate .desktop files from .menu files using the menu system when
> .desktop files don't exist.
> 
> 3. Continue using the menu system for window managers which don't
> natively understand .desktop files; drop the Debian menu for those
> that do.

Sounds good to me.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpWEyM3wLkqs.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 12:25 -0500, Steve Greenland a écrit :
> So I can try a new window manager without restarting my xsession. 

Does your job include daily window manager testing?

> So J. Random User can easily see what window managers are available.

Some of the users we target don't even know what a window manager is,
and they don't want to know it.

-- 
 .''`.
: :' :  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: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 16:08 +0200, Wouter Verhelst a écrit :
> The debian menu hierarchy has just been revised, and a new menu policy
> has been active since a few weeks. 

The new hierarchy doesn't fix any of the issues that were raised.

-- 
 .''`.
: :' :  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: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 12:47 -0500, Steve Greenland a écrit :
> Why do you think that would happen? None of the people here have
> suggested that. You, on the other hand, have suggested that the Debian
> menu system be trashed in favor the GNOME menu system.

No. I have suggested that both systems continue to coexist as long as
their goals are incompatible.

-- 
 .''`.
: :' :  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: adding desktop files to misc packages

[Javier Fernández-Sanguino Peña]

On Fri, Jul 13, 2007 at 10:10:09PM -0400, Joey Hess wrote:
> Josselin Mouette wrote:
> > We can use additional keywords in the desktop entries to get them sorted
> > in sub-menus when appropriate, but many desktop files are not tagged
> > correctly. As you can see in the specification [0], all categories we
> > need should be here, so if we tag desktop files appropriately, the
> > generated menu should be usable.
> 
> Oddly, the specification nearly exactly mirrors the despised
> Debian menu system, as far as the categorisation of games goes:

(...)

Just a few thoughts based on my personal experience. I present you my home
system: sid, GNOME 2.18, but not with the full gnome-desktop-environment
metapackage installed, as it's rather huge, but with gnome-core and an
assorted collection of gnome-specific packages as well as many games.

In my case the Debian menu properly introduces these games in their proper
submenu but the GNOME menu does *not* create submenu for any of the
categories, all games are presented in a flat menu which overflows the
screen. Is this a feature only available when installing a particular
package?

Check this:
$ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \;  | wc -l
54

I get all these 54 items in GNOME's Game menu with no category division. 
And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there. 

Not that I'm completely in favour of submenus (a submenu with a single entry
does not seem useful to me). However, having a list of items that cannot be
seen on screen without browsing through it does not seem very user-friendly
to me. Specially as I don't play all games often (just a few of them)

What I would like to see implement (in the UI side?=
update-menus could also):

a- if # items in a menu are < THRESHOLD then present them in a flat list
b- if # items in a menu are > THRESHOLD then use submenus to categorise
but, if there is a submenu that has < THRESHOLD_B items (say 1) then
do not create a submenu for it.
c- "learn" which items the user uses most and present those hiding others
  (there's people which despise this feature from other OSes, I actually
   find it useful)

This could be implemented in the UI side, but maybe update-menus could
also implement this (specially a and b) to prevent having submenus with just
1 item.

I don't see any of this being mentioned in GNOME's Menu Usability wiki
(http://live.gnome.org/UsabilityTeam/Menu) which seems to imply that a flat
hierarchy is prefered by GNOME (but it is quite useless in Debian, as we do
carry much more applications if you install both GNOME and KDE). But maybe it
is because it works (better) in other (heavier) GNOME environments.

BTW. If I use GNOME's built-in menu editor (the one you get when you
right-clink on the footprint with just gnome-panel installed, not alacarte,
as it is not installed) I'm not able to create submenus and, even, to see the
categories the different desktop files assign to each Game. That isn't too
user-friendly to me.

I know I can install alacarte (pulled in by gnome-desktop-environment) but
IMHO a *proper menu editor should be an essential part of the GNOME desktop.
However, even if I install alacarte I don't get the option to create
submenus automatically based on the Game categories (which, again, are not
shown). Which means I have to automatically sort games byhand into menus when
there is already information in the desktop files to do this!

Just my 2c,

Javier


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 12:45 -0500, Steve Greenland a écrit :
> The problem is your idea of "more usable" is, to me, "remove valuable
> functionality". 

Yes. Improving usability requires removing or reworking functionality
exposure. This is a trade-off between not being able to do something
because there are no features and not being able to do something because
features are hidden into tons of other features.

> And for the record, I'm someone who is generally in favor of the
> direction GNOME chose. But I think that rather than trashing the Debian
> menu system, it might be the better choice for GNOME (in Debian), to
> ignore/disable the Debian menu by default.

I think we can also agree on this.

-- 
 .''`.
: :' :  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: adding desktop files to misc packages

[Neil Williams]

On Sun, 15 Jul 2007 18:16:49 -0600
Bruce Sass <[EMAIL PROTECTED]> wrote:

> > > Why not drop the Debian Menu Policy completely? The only sane
> > > argument against .desktop is hierarchy support but then the most
> > > pertinent complaint against menu is that the hierarchy is wasteful.
> >
> > The Freedesktop menu has hierarchy support, but it's much more clever
> > than the Debian menu's.
> >
> > The most important argument against it is more about window manager
> > coverage. There are a good number of packages with Debian menu
> > support and no Freedesktop menu support.
> 
> Neil,
> 
> If by "drop the Debian Menu Policy completely" you mean adopting 
> Freedesktop's .desktop file format, menu hierarchy rules, and whatever 
> tools they have for working with menus---sure. From an enduser's 
> perspective it doesn't matter what lies beneath the menus we see[1], if 
> you DD's decide the Freedesktop way is the better one for packaging 
> menu entries then so be it.

I like Don's idea - remove the Debian menu from those window managers
etc. that understand .desktop files and make the Debian menu aware
of .desktop files for those other systems.

> 1. Make changes to the menu system to use .desktop files in preference
> to .menu files when they exist
> 
> 2. Generate .desktop files from .menu files using the menu system when
> .desktop files don't exist.
> 
> 3. Continue using the menu system for window managers which don't
> natively understand .desktop files; drop the Debian menu for those
> that do.

> If you are suggesting dropping the Debian menu infrastructure as well, 
> therebye forcing the other window managers to learn how to 
> read .desktop files or convert them into their native format on their 
> own time---that sounds like a bad idea. 

True - that is avoidable so there's no need to go that far.

> I would think that would be enough to place the idea of dropping the 
> menu infrastructure in the non-starter category, but obviously it isn't 
> because "window manager coverage" is an issue. 

If the current Debian Menu Policy is rewritten along the lines set out
in Don Armstrong's email, that is fine with me.

> [2] it has been awhile since I used Gnome but their menus used to be 
> slower than KDE's, KDE's have gotten slower (and take up more HDD 
> space, perhaps a consequence of the Freedesktop related stuff added to 
> the menu subsystem and maybe why there has been a push to swith 
> to .desktop files)... but the menus I get with UWM are always very fast

Depends what else has been happening on the machine - the .desktop
based menus load very quickly if there is sufficient cache. The first
time I view either menu, I get the same delay on this amd64 box, it
appears to be the icons that are the cause of the delay, not the source
of the textual data.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp2hZNWR7KTv.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Javier Fernández-Sanguino Peña]

On Mon, Jul 16, 2007 at 04:12:02AM -0700, Don Armstrong wrote:
> So it seems like we should do the following:
(...)

4. Add i18n support to menu so that it can generate localised menu names,
   entries and tooltips both when converting desktop -> menu (for WM !=
   KDE/GNOME/Xfce) and when converting menu -> desktop (for WM ==
   KDE/GNOME/Xfce). As WM might not have i18n support for their menu, this
   should be based on the system's /etc/default/locale setting when
   converting from desktop -> menu to select a single text string there.

> The other issue that was brought up was improving the hierarchical
> organization of the menus, but how to do that hasn't been made clear
> in this thread.

Maybe some of the people that claim that the hierarchical organization is
broken should open up a wiki page and do a side-to-side comparison of
Debian's menu vs. Freedesktop's menu structure.

Just my 2c,

Javier


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Josselin Mouette]

Le lundi 16 juillet 2007 à 20:01 +0200, Javier Fernández-Sanguino Peña a
écrit :
> Check this:
> $ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \;  | wc -l
> 54
> 
> I get all these 54 items in GNOME's Game menu with no category division. 
> And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there. 

You should probably file bugs against game packages that provide
uncategorized desktop entries. The GNOME menu should sort them out in
submenus if this is done correctly.

-- 
 .''`.
: :' :  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: adding desktop files to misc packages

[Frans Pop]

On Monday 16 July 2007 20:44, Javier Fernández-Sanguino Peña wrote:
> There are some typos there too ('GameAction', 'ActionGame') which I'm
> going to file bugs now.

The use of plurals for both seems to be a bug too, looking at other 
categories.


pgpp3TxdDCLlE.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Javier Fernández-Sanguino Peña]

On Mon, Jul 16, 2007 at 08:09:28PM +0200, Josselin Mouette wrote:
> Le lundi 16 juillet 2007 à 20:01 +0200, Javier Fernández-Sanguino Peña a
> écrit :
> > Check this:
> > $ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \;  | wc -l
> > 54
> > 
> > I get all these 54 items in GNOME's Game menu with no category division. 
> > And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there. 
> 
> You should probably file bugs against game packages that provide
> uncategorized desktop entries. The GNOME menu should sort them out in
> submenus if this is done correctly.

It looks to me like they are properly categorised and its the GNOME menu
which is misbehaving:

$ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \;   |  \
perl -ne 'while ($_ ne "") {if (/([\-\w]+);(.*)/) {print "$1\n"; $_=$2;} \
else { $_= ""; }}' | sort | uniq -c |sort -nr
55 Game
31 Qt
31 KDE
18 GNOME
15 GTK
13 ArcadeGame
11 StrategyGame
11 BoardGame
7 LogicGame
6 Application
5 CardGame
1 X-KDE-KidsGame
1 GamesAction
1 GameAction
1 BlocksGame
1 ActionGames
1 ActionGame


There are some typos there too ('GameAction', 'ActionGame') which I'm going
to file bugs now.

Javier


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Andreas Tille]

On Mon, 16 Jul 2007, Josselin Mouette wrote:


Le lundi 16 juillet 2007 à 12:25 -0500, Steve Greenland a écrit :

So I can try a new window manager without restarting my xsession.


Does your job include daily window manager testing?


Interesting criterion: Daily use of an entry.
H 


So J. Random User can easily see what window managers are available.


Some of the users we target don't even know what a window manager is,
and they don't want to know it.


I'm sorry, but I consider myself as a quite important target user.
If I would not be a target user I probably wouldn't be a Debian
developer.

Kind regards

  Andreas.

--
http://fam-tille.de

Re: adding desktop files to misc packages

[martin f krafft]

also sprach Josselin Mouette <[EMAIL PROTECTED]> [2007.07.16.1957 +0200]:
> > So I can try a new window manager without restarting my xsession. 
> 
> Does your job include daily window manager testing?

Mine is, full-time. Stop being destructive.

> > So J. Random User can easily see what window managers are available.
> 
> Some of the users we target don't even know what a window manager is,
> and they don't want to know it.

I don't think we know our target group to the point to be able to
make such statements.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"it is the mark of an educated mind
 to be able to entertain a thought
 without accepting it."
-- aristoteles


signature.asc
Description: Digital signature (GPG/PGP)

Re: adding desktop files to misc packages

[Frank Küster]

Neil Williams <[EMAIL PROTECTED]> wrote:

> I like Don's idea - remove the Debian menu from those window managers
> etc. that understand .desktop files and make the Debian menu aware
> of .desktop files for those other systems.

Oh, please not.  Everytime I try a "desktop environment", I end up using
its menus nearly only for configuring it, and the Debian menu for doing
real work.  It's the menu I am used to, and it would really reduce my
productivity to miss it.  Not that a desktop environment increases my
productivity, anyway; but should I actually want to get used to one for
longer, it would indeed make my personal transition smoother if I can
start with the familiar Debian menu and switch to the respective desktop
environment menus gradually.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Michael Biebl]

Frank Küster wrote:
> Neil Williams <[EMAIL PROTECTED]> wrote:
> 
>> I like Don's idea - remove the Debian menu from those window managers
>> etc. that understand .desktop files and make the Debian menu aware
>> of .desktop files for those other systems.
> 
> Oh, please not.  Everytime I try a "desktop environment", I end up using
> its menus nearly only for configuring it, and the Debian menu for doing
> real work.  It's the menu I am used to, and it would really reduce my
> productivity to miss it.  Not that a desktop environment increases my
> productivity, anyway; but should I actually want to get used to one for
> longer, it would indeed make my personal transition smoother if I can
> start with the familiar Debian menu and switch to the respective desktop
> environment menus gradually.
> 

I actually do like Don's idea.
The first thing I usually do, after installing KDE or Gnome is to
disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,
for all the reason already given:
- It duplicates entries (so it's potentially confusing for novice users)
- Has no i18n
- ugly (although I agree that's subjective). No png icons for
applications, no icons for subdirectories, which imho makes it harder to
recognize the categories quickly.

So, yeah, I vote for disabling the Debian menu in KDE/Gnome/XFCE.


Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: adding desktop files to misc packages

[Bruce Sass]

On Mon July 16 2007 12:03:17 pm Neil Williams wrote:
> On Sun, 15 Jul 2007 18:16:49 -0600
> Bruce Sass <[EMAIL PROTECTED]> wrote:
> I like Don's idea - remove the Debian menu from those window managers
> etc. that understand .desktop files and make the Debian menu aware
> of .desktop files for those other systems.

Ya, I think Don has come up with a pretty good summary of the most 
reasonable/significant ideas. The only thing missing is an explicit 
acknowledgement of the need for a way to grossly customize the menus 
independently of any tools provided by a specific environment. E.g., I 
would like the KDE K-menu to default to having a Debian submenu 
containing all executables, with all other submenus containing only KDE 
programs; if I fire up Gnome I would like its main menu to do the same; 
etc.---without having to independently configure each environment.


> > [2] it has been awhile since I used Gnome but their menus used to
> > be slower than KDE's, KDE's have gotten slower (and take up more
> > HDD space, perhaps a consequence of the Freedesktop related stuff
> > added to the menu subsystem and maybe why there has been a push to
> > swith to .desktop files)... but the menus I get with UWM are always
> > very fast
>
> Depends what else has been happening on the machine - the .desktop
> based menus load very quickly if there is sufficient cache. The first
> time I view either menu, I get the same delay on this amd64 box, it
> appears to be the icons that are the cause of the delay, not the
> source of the textual data.

I'm not sure what is happening, only that shortly after it became 
annoying I noticed "xdg" related menu-methods and a ~/.local dir which 
hadn't existed before.

It does only happen first time accessing a menu, and seems to be related 
more to the number of entries than whether they have icons or not. 

 Anything I use frequently has a desktop shortcut, panel icon, or 
is in the quick launcher, so it's not a big deal. A combination of KDE 
style menu infrastructure and a less featureful environment would be 
very annoying though.


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

Re: Bug#433261: ITP: libpano13 -- panorama tools library

[Florent Bayle]

Hi,

Le lundi 16 juillet 2007, Bernd Zeimetz a écrit :
> 
> >  Panorama Tools was originally created by Professor Helmut Dersch of the
> >  University of Applied Sciences Furtwangen. Professor Dersch's site no
> >  longer has links to download the tools, which is why this panotools
> >  sourceforge project exists.
> 
> I remember vaguely that there were some copyright/licenseing issues with
> at least parts of the software provided on the page of Prof. Dersch -
> but I'm not sure.

It was a patent problem. It was already discussed when I packaged the
previous version of libpano (libpano12). You can search for old discussions
on debian-legal archives, libpano12 ITP and archived bugs on libpano12.

> 
> Also, do you intend to package clens, too? This would be very appreciated.

I currently don't use it myself, but I will have a look.

-- 
Florent


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

Re: adding desktop files to misc packages

[Steve Greenland]

On 16-Jul-07, 12:57 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> Le lundi 16 juillet 2007 ? 12:25 -0500, Steve Greenland a ?crit :
> > So I can try a new window manager without restarting my xsession. 
> 
> Does your job include daily window manager testing?

No. But anything I use daily gets its own icon on the application bar.
Right now the entries are rxvt, emacs, iceweasel, jpilot, trn, and
sonata. Oh, and a new mail detector hooked up to mutt.

By your argument, I'd say we don't need any menu entries at all.

> > So J. Random User can easily see what window managers are available.
> 
> Some of the users we target don't even know what a window manager is,
> and they don't want to know it.

Some of the users we target don't use any desktop environment, running
headless servers. So let's remove KDE and GNOME.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Lintian test for desktop files (was Re: adding desktop files to misc packages)

[Javier Fernández-Sanguino Peña]

On Mon, Jul 16, 2007 at 08:54:47PM +0200, Frans Pop wrote:
> On Monday 16 July 2007 20:44, Javier Fernández-Sanguino Peña wrote:
> > There are some typos there too ('GameAction', 'ActionGame') which I'm
> > going to file bugs now.
> 
> The use of plurals for both seems to be a bug too, looking at other 
> categories.

True. It looks like there is only one culprit (in my system, at least):
armagetronad. Bug filed (#433372).

I've just coded in a test for Lintian to implement validation of desktop
files. After implementing it (and sending it to the BTS, see #433411), I've
noticed that there was an outstanding bug report (#277441) which has been
open for over 3 years asking for just this feature.

My lintian tests do less than 'desktop-file-validate' (a tool I didn't know
about, until I read #277441) but can be easily extended based on the code of
that tool to avoid adding too many dependencies to lintian if needed.

Might be interesting to add the test I submitted into lintian and see which
packages fail it specially if we want to promote the use of desktop vs.
menu entries.

Regards

Javier


signature.asc
Description: Digital signature

Possibly building OpenAFS 64-bit for sparc

[Russ Allbery]

(I am not subscribed to debian-sparc, but I am subscribed to debian-devel.
If you don't cc debian-devel, please cc me.)

Hello folks,

OpenAFS (a distributed file system client and server with a fairly old
code base) has userspace client programs and servers that use its internal
lightweight threading library.  Upstream is working slowly on converting
this to pthreads for Linux, but we're not quite there yet.  In the
meantime, it needs to either know rather too much about the internals of
glibc data structures (which broke as of glibc 2.3) or it needs to have
getcontext/setcontext functions.

As of the upgrade to glibc 2.3, we've switched the OpenAFS packages for
all platforms over to using getcontext/setcontext.  The problem is that
these functions are not implemented for 32-bit SPARC, which means that the
client no longer works for Debian's sparc architecture.  This is a fairly
long-standing bug against glibc (Bug#295173) and it seems unlikely to me
that anyone wants to implement and maintain this code for 32-bit SPARC.

I've verified that building the OpenAFS userspace programs 64-bit instead
of 32-bit results in working binaries.

So, I'm looking for guidance at this point.  It seems like my alternatives
(other than convincing someone to implement these functions for 32-bit
SPARC) are to either drop the SPARC architecture for OpenAFS or to build
the OpenAFS packages 64-bit on SPARC, which I believe is against the
normal intention of the sparc architecture.  However, with the proposed
dropping of the 32-bit sparc kernel, perhaps building programs with these
sorts of technical requirements for the 64-bit environment is a reasonable
thing to do?

I welcome any advice.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Possibly building OpenAFS 64-bit for sparc

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> In the meantime, it needs to either know rather too much about the
> internals of glibc data structures (which broke as of glibc 2.3) or it
> needs to have getcontext/setcontext functions.

> As of the upgrade to glibc 2.3, we've switched the OpenAFS packages for
> all platforms over to using getcontext/setcontext.

Bleh, sorry.  The breakpoint was glibc 2.4, not 2.3.  That was otherwise
going to be very confusing, given how old glibc 2.3 is.  I misread a > in
the code as >=.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: adding desktop files to misc packages

[Frank Küster]

Michael Biebl <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>> Neil Williams <[EMAIL PROTECTED]> wrote:
>> 
>>> I like Don's idea - remove the Debian menu from those window managers
>>> etc. that understand .desktop files and make the Debian menu aware
>>> of .desktop files for those other systems.
>> 
>> Oh, please not.  
[...]
> I actually do like Don's idea.
> The first thing I usually do, after installing KDE or Gnome is to
> disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,

Okay, as long as it can easily be configured, I see no problem in
disabling it by default.  But there should be either a prominent menu
entry which is easy to find, or a README.Debian in an obvious package.

> for all the reason already given:
> - It duplicates entries (so it's potentially confusing for novice users)

That's a point.

> - Has no i18n

That isn't an argument to remove it, but for adding i18n support to it.

> - ugly (although I agree that's subjective). No png icons for
> applications, no icons for subdirectories, which imho makes it harder to
> recognize the categories quickly.

Having no icons is probably a feature - someone else said in this thread
that the icons are the reason for slow menus.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Co-Maintainer for libdbi-perl wanted

[Christian Hammers]

Hello

I'm looking for a co-maintainer of libdbi-perl. It's a very low-work package
that just sometimes fails to build on some architecture.

bye,

-christian-


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