Re: desktop and/or menu files localization (was: Re: adding desktop files to misc packages)

[Neil Williams]

On Sat, 14 Jul 2007 07:54:58 +0200
Christian Perrier <[EMAIL PROTECTED]> wrote:

> (crossposted to -i18n)
> Speaking about desktop files l10n, the current way to
> translate them does not seem to scale very well to me.
> 
> From what I see in the dozens of .desktop files I have on my own
> system, I see "Field[code]" fields for translations of "Field". 
> 
> This is similar to what we had, in the past, for debconf templates and
> we all known this doesn't scale and doesn't handle changes to English
> strings very well.

The strings used to generate translated .desktop entries can (should)
come from the upstream po/ directory via gettext - it can be handled
directly using gettext and make. All my upstream projects include all
translatable strings for the .desktop file in the .gmo (and therefore
the installed .mo) yet these also exist in the .desktop file that is
eventually installed. If an upstream package uses autofoo and does not
create a translated .desktop file for the .orig.tar.gz, that is (IMHO)
an upstream bug.

The thing is, that happens with debian/templates as well. Using
deb-gview, I can view any package that uses debconf with translations
in debian/po and the templates file in the .deb itself (part of
the control.tar.gz of the .deb) increases in size every time a new
translation is added to debian/po and contains long, long lists of
repeated translated strings. From an embedded perspective, I'd love to
lose this duplication:

debconf template (from emdebian-tools 0.3.0 .deb)
Description: Use apt-get to install toolchains?
 emsetup can install toolchain packages for you using apt-get.
 Alternatively, unset this option to use aptitude.
Description-cs.UTF-8: Použít pro instalaci nástrojů apt-get?
 emsetup může automaticky nainstalovat balíky s nástroji pomocí
apt-get. Chcete-li použít aptitude, tuto možnost odmítněte.
Description-de.UTF-8: Soll apt-get zur Installation der Werkzeugkette
verwendet werden? Emsetup kann die Pakete der Werkzeugketten für Sie
mittels apt-get installieren. Alternativ lehnen Sie diese Option ab, um
Aptitude zu verwenden.

desktop file (from gpe-expenses .deb)
Comment=Simple Expenses records for GPE
Comment[cs]=Jednoduché záznamy o výdajích pro GPE
Comment[de]=Einfache Spesenaufzeichnung für GPE
Comment[pt]=Registos simples de Despesas para GPE

I'd agree that BOTH of these should be able to read the .mo just like
the application itself. I don't know if that is achievable. gettext
does support non-compiled implementations like Perl or PHP so there
should be some method of retrieving the strings directly from the .mo
so that both the debconf templates AND the .desktop file contain ONLY
the original "marked up" translatable strings and not the actual
translations. i.e. deal with .desktop and debconf in the same way as
the executable. gettext can do it - it works for PHP and Perl.

debconf template (from emdebian-tools 0.3.0 .deb)
_Description: Use apt-get to install toolchains?
 emsetup can install toolchain packages for you using apt-get.
 Alternatively, unset this option to use aptitude.

desktop file (from gpe-expenses .deb)
_Comment=Simple Expenses records for GPE

Or similar syntax to "markup" the strings:
debconf template (from emdebian-tools 0.3.0 .deb)
Description: _("Use apt-get to install toolchains?")
 _("emsetup can install toolchain packages for you using apt-get.
 Alternatively, unset this option to use aptitude.")

desktop file (from gpe-expenses .deb)
Comment=_("Simple Expenses records for GPE")

So I don't follow the logic above - AFAICT we still have the
debconf system that you describe as "in the past" - we just changed the
syntax. It is an improvement over Field[code] but it seems to me to be
an incomplete transition.

> So whatever choice is Good or Bad, there's an interesting problem to
> work on: develop a gettext-based system to translate .desktop or .menu
> files.

AFAICT what we need is the ability to retrieve the translated strings
from /usr/share/locale/$lang/LC_MESSAGES/$app.mo rather than copying
them en masse into /usr/share/applications/foo as well (and then doing
the same again in /usr/share/menu if we translate menu files too).

> Indeed, it would be good to have something allowing such strings to go
> in a debian/po directory, much similarly to what's currently done with
> debconf templates. Then the translated .desktop or menu files would be
> built at package build time from the original file and the set of
> gettext translations in debian/po

This is what I don't follow, Christian - I already do this upstream.
desktop/app.desktop.in.in can be preprocessed in packages using
autotools to handle gettext. The translated .desktop file is built at
package build time from the original file and the set of gettext
translations in the upstream po/ directory.

-- 

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


pgp3YoZNRS5OT.pgp
Description: PGP signature

Re: desktop and/or menu files localization

[Ming Hua]

On Sat, Jul 14, 2007 at 07:54:58AM +0200, Christian Perrier wrote:
> 
> Quoting Josselin Mouette ([EMAIL PROTECTED]):
> > Le vendredi 13 juillet 2007 à 17:30 -0400, Joey Hess a écrit :
> > > There are probably enhancements that would let it create _better_
> > > .desktop files. For example, ones with translations..
> > 
> > Ah, right. I forgot translations. Another good reason to drop the Debian
> > menu system.
> 
> Speaking about desktop files l10n, the current way to
> translate them does not seem to scale very well to me.
> 
> From what I see in the dozens of .desktop files I have on my own
> system, I see "Field[code]" fields for translations of "Field". 

IIUC, these fields are (can be) automatically filled by intltool, using
the translations in PO files.  So for translators the whole process is
transparent, they only need to deal with PO files.

> I suppose that big projects like KDE and GNOME have setup their own
> l10n infrastructure to localize these, but allowing the same to happen
> with other .desktop files would be an interesting enhancement.

The tool is there, it's just up to the individual software writer if
he/she wants to set up the infrastructure for translating desktop file.

[I am not subscribed to debian-devel, please cc: me if debian-i18n is
not crossposted.]

Ming
2007.07.14


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

Re: desktop and/or menu files localization (was: Re: adding desktop files to misc packages)

[Christian Perrier]

> This is what I don't follow, Christian - I already do this upstream.
> desktop/app.desktop.in.in can be preprocessed in packages using
> autotools to handle gettext. The translated .desktop file is built at
> package build time from the original file and the set of gettext
> translations in the upstream po/ directory.


Hmm, this is indeed something I just wasn't aware of..:-)




signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Bernhard R. Link]

* Josselin Mouette <[EMAIL PROTECTED]> [070713 23:44]:
> IMO the Debian menu should be entirely deprecated unless something
> serious is done about it. Currently:
>   * It is utterly and absolutely ugly. 32x32 XPM icons are not
> matching the graphic quality we have on the rest of the desktop.

Then just add larger or any other icons (in appropiate additional fields).
One of my packages already has a 64x64 icon. Currently no window manager
user it, but if I would use any window manager showing icons and not
scaling them down to 16x16 it would be almost no efford to make them use
them.

>   * Its structure is impractical. Most important things are in
> Applications/, which adds a menu level with no use, and several
> submenus are useless.

That's a question of policy, not of the system. And actually arguing
about policy is in my eyes a point for menu files, as people are
supposed to read Debian policy to create it, and not blindly copying
other people's work, that are following (or even not following) some
other set of policy or another interpretation of policy.

>   * Most importantly, it is absolutely full of useless stuff.
> A menu entry for each window manager? WTF? We can select them from the
> display manager now.

But if the display manager is only worth 2 cents, it's Debian default
configuration should get it from the place where all window managers
give proper notice of their existance, which is the Debian menu.
Also just because many of the new shiny desktop environment systems want
to reinvent everything, there are still many window managers which
are able to properly change window managers on the fly, to any other
window manager. Please do not drop this feature just because your pet
toy does not support it (or supports it but you never used it).

> An entry for each python/TCL/guile interpreter on the system? Can't
> developers use terminals?
> An entry for each of the bsdgames? For nano? For so many terminal
> applications that you want to run, well, in a terminal?

This is the primary reason why I hope the Debian menu will stay, because
it is centered as user-friendlyness and not about some obscure ideology.
Users need programs to do their tasks, no matter if they are terminal or
what guikit they use. If you have a different feeling or think you have
users fitting better into the ideology, the Debian menu system provides
all means to do a simple global change (like not showing terminal apps,
or moving everything you do not like to a other place) for a single or
all users on your systems, while the default can still be what it most
helpfull for people: Have everything that is available and usefull to
start without parameters as an easy to find menu item.

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

[Mike Hommey]

On Sat, Jul 14, 2007 at 10:55:00AM +0200, Bernhard R. Link <[EMAIL PROTECTED]> 
wrote:
> But if the display manager is only worth 2 cents, it's Debian default
> configuration should get it from the place where all window managers
> give proper notice of their existance, which is the Debian menu.
> Also just because many of the new shiny desktop environment systems want
> to reinvent everything, there are still many window managers which
> are able to properly change window managers on the fly, to any other
> window manager. Please do not drop this feature just because your pet
> toy does not support it (or supports it but you never used it).

The fact is very very very very few users actually use these items. So
why bother the more than vast majority that doesn't need them ?

> > An entry for each python/TCL/guile interpreter on the system? Can't
> > developers use terminals?
> > An entry for each of the bsdgames? For nano? For so many terminal
> > applications that you want to run, well, in a terminal?
> 
> This is the primary reason why I hope the Debian menu will stay, because
> it is centered as user-friendlyness and not about some obscure ideology.
> Users need programs to do their tasks, no matter if they are terminal or
> what guikit they use. If you have a different feeling or think you have
> users fitting better into the ideology, the Debian menu system provides
> all means to do a simple global change (like not showing terminal apps,
> or moving everything you do not like to a other place) for a single or
> all users on your systems, while the default can still be what it most
> helpfull for people: Have everything that is available and usefull to
> start without parameters as an easy to find menu item.

Do you really think having the python interpreter in a menu item is at
all useful ? Take the debian user base, the number of people using
python as a development tool is already quite low. Now, in these people
developping python scripts or applications, how many do run the python
interpreter without it running the script or application ? I bet very
few. Of these few, how many run the python interpreter outside the IDE
they must be using ? Even fewer, I'd say. Of these very very few, how
many would run it frequent enough that they'd need a menu item for it ?

Now do you think it's fair to clutter everyone's menu with something
that hardly anybody uses ?

If a filtering of the items is at all possible, these should be
filtered-out *by default*, like some programs pretty much useless to
have in a menu are by default in gnome, such as evince or file roller
or, guess what, the python interpreter. Yep, python2.4 provides a
.desktop that is hidden by default.

Mike


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

Re: adding desktop files to misc packages

[Charles Plessy]

Le Fri, Jul 13, 2007 at 04:54:07PM -0400, Joey Hess a écrit :
> I've gotten some bug reports lately asking for desktop files to be added
> to packages like xgalaga and kobodeluxe, and saw some others in the BTS.
> All of these packages, of course, already include Debian menu files. But I 
> don't understand what the rationalle is behind adding a desktop file to a
> package that includes a Debian menu file and is not a Gnome/KDE component.

Dear Joey,

Having a .desktop file is a requrement in Ubuntu, so it is not
surprising that people submit patches in wishlist bugs : they are
encouraged to do so. Looking from the email adress of the bug senders
from xgalaga and kobodeluxe, they obiously come from there.

The FreeDesktop menu system has a mechanism to make entries invisible
with given desktop managers. What we miss in Debian is a policy, or just
statemenst from relevant teams, which guides maintainers when they have
to deal with .desktop files.

In the absence of any policy from the GNOME, KDE or XFCE teams, my
personal standpoint is that entries are welcome, so I do add .desktop
files. Acutally, I even create them when I prepare a new package which
lacks them. I also support the idea to chose a format from which .menu
and .desktop files would be generated. It is definitely not fun to
maintian two similar files in parallel.

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team
Wako, Saitama, Japan


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

Re: desktop and/or menu files localization (was: Re: adding desktop files to misc packages)

[Josselin Mouette]

Le samedi 14 juillet 2007 à 08:28 +0100, Neil Williams a écrit :
> > From what I see in the dozens of .desktop files I have on my own
> > system, I see "Field[code]" fields for translations of "Field". 
> > 
> > This is similar to what we had, in the past, for debconf templates and
> > we all known this doesn't scale and doesn't handle changes to English
> > strings very well.
> 
> The strings used to generate translated .desktop entries can (should)
> come from the upstream po/ directory via gettext - it can be handled
> directly using gettext and make. 

Actually they are using intltool, just like we do for debconf templates.

> All my upstream projects include all
> translatable strings for the .desktop file in the .gmo (and therefore
> the installed .mo) yet these also exist in the .desktop file that is
> eventually installed.

Side note: you don't need to install such .mo files, unless they also
contain translations accessed from the code.

-- 
 .''`.
: :' :  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

Gardul viu - minune!!!

[Gard viu]

GARDUL VIU-MINUNE!!!
Creste rapid (1.20-1.80 m/an)!!!
E incredibil de nepretentios!!! (atât în privinta solului cât si a îngrijirii)
E incredibil de ieftin!!!
Capacitate de umbrire excelenta!
Capacitate antipraf de un grad înalt!
Este o planta foioasa, de culoare verde viu, cu frunze mici lucioase, formând 
un gard viu de mare densitate.
De la 0.9 RON/rasad, peste 1000 de bucati!
Pentru detalii, vizitati site-ul www.gardviu.ro
Tel: 0744313265
Echipa, NET GREEN AGENT
Homa srl
 
Acest mesaj contine datele noastre de identificare si instructiuni de 
dezabonare. V-a fost oferit din urmatoarele motive: sunteti in baza noastra de 
date ca urmare a unor corespondente anterioare,
adresa Dvs. a fost selectata dintr-o baza de date la care ati subscris, adresa 
Dvs. a fost facuta publica prin afisari cu caracter publicitar. Ne cerem scuze 
daca mesajul ajunge la Dvs. dintr-o eroare
sau daca acest e-mail nu va aduce informatii utile.
- Daca nu mai doriti sa primiti ofertele noastre dati clic la dezabonare in 
mailul prezent si veti fi exclus din baza noastra de date". Conform legislatiei 
( http://www.legi-internet.ro/lg365.htm )
din Romania pentru trimiterea de oferte comerciale prin posta electronica 
trebuie obtinut acordul destinatarului. Va multumim pentru intelegere si speram 
intr-o colaborare benefica ambelor parti!
 


Clic aici pt. optiuni de abonare! ( 
http://roman.viaszfestes.hu/index.php?option=com_acajoom&act=change&subscriber=8732&cle=c4b71992bd71327e8969323a5058372a&listid=2
 )
Clic aici pentru dezabonare. ( 
http://roman.viaszfestes.hu/index.php?option=com_acajoom&act=unsubscribe&subscriber=8732&cle=c4b71992bd71327e8969323a5058372a&listid=2
 )

Powered by Acajoom Mailing System ( http://www.acajoom.com ) 



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

Re: adding desktop files to misc packages

[Bernhard R. Link]

* Mike Hommey <[EMAIL PROTECTED]> [070714 11:30]:
> On Sat, Jul 14, 2007 at 10:55:00AM +0200, Bernhard R. Link <[EMAIL 
> PROTECTED]> wrote:
> > But if the display manager is only worth 2 cents, it's Debian default
> > configuration should get it from the place where all window managers
> > give proper notice of their existance, which is the Debian menu.
> > Also just because many of the new shiny desktop environment systems want
> > to reinvent everything, there are still many window managers which
> > are able to properly change window managers on the fly, to any other
> > window manager. Please do not drop this feature just because your pet
> > toy does not support it (or supports it but you never used it).
>
> The fact is very very very very few users actually use these items. So
> why bother the more than vast majority that doesn't need them ?

Because our priority are our users, and not only those users that some
people think are the important ones?

And how is it bothering other people if there are options? Should we
remove all features just because you and some majority you claim to have
does not use them?

> > This is the primary reason why I hope the Debian menu will stay, because
> > it is centered as user-friendlyness and not about some obscure ideology.
> > Users need programs to do their tasks, no matter if they are terminal or
> > what guikit they use. If you have a different feeling or think you have
> > users fitting better into the ideology, the Debian menu system provides
> > all means to do a simple global change (like not showing terminal apps,
> > or moving everything you do not like to a other place) for a single or
> > all users on your systems, while the default can still be what it most
> > helpfull for people: Have everything that is available and usefull to
> > start without parameters as an easy to find menu item.
>
> Do you really think having the python interpreter in a menu item is at
> all useful ? Take the debian user base, the number of people using
> python as a development tool is already quite low. Now, in these people
> developping python scripts or applications, how many do run the python
> interpreter without it running the script or application ? I bet very
> few. Of these few, how many run the python interpreter outside the IDE
> they must be using ? Even fewer, I'd say. Of these very very few, how
> many would run it frequent enough that they'd need a menu item for it ?

I'd guess that the majority of people needing a menu item are those not
using the application often. Even if not using them for normal work,
it is an easy way to see what is installed and to try some little things.
Why do you insist on everyone not doing things like you is not important
and should not be worth being supported.

> Now do you think it's fair to clutter everyone's menu with something
> that hardly anybody uses ?

Sorry, I do not understand you. All definitions of clutter I could find
include "confusion" or "disorder". Having everything available that is
installed and useable in hierachy is a clear and easy to understand
concept. Hiding stuff by random and/or unpredictable criteria (and
both "person xyz thinks it is not important" or "not enough people use
it" belong to the most random I can think of).

> If a filtering of the items is at all possible, these should be
> filtered-out *by default*, like some programs pretty much useless to
> have in a menu are by default in gnome, such as evince or file roller
> or, guess what, the python interpreter.

I'm extremly against filtering out anything by default. Though I really
do not care what Gnome's default menu-method does. As far as I remember it
never had even the option to show the proper menu...

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

[Alexander Schmehl]

Hi!

* Joey Hess <[EMAIL PROTECTED]> [070713 22:54]:

> This division, while not IMHO technically very nice, helps the
> consistency and usability of the desktop environments, since the most
> accessible menu items are those from the desktop files for that
> particular desktop environment. To find some strange program that is not
> a Gnome (or KDE) program, the user has to go spelunking in the depths of
> the Debian menu structure.

I heard from quite many users, that they where confused about the
doubled menu structure, and always asked why some applications are there
and some others aren't.

Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Wouter Verhelst]

On Sat, Jul 14, 2007 at 01:53:03PM +0200, Alexander Schmehl wrote:
> I heard from quite many users, that they where confused about the
> doubled menu structure, and always asked why some applications are there
> and some others aren't.

That's a good reason to improve the menu system, but not really a good
reason to just go ahead and ship two versions of basically the same
information, IMO.

-- 
 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]

Searching .desktop files and other advantages of Fd.o menus

[Loïc Minier]

On Fri, Jul 13, 2007, Joey Hess wrote:
> In the long run, big menus of all the possible programs all obsolete
> anyway. A better interface is a tool that helps you search for programs,
> and then remembers programs that you've used so you can quickly
> re-access them. The command line has been doing this for decades;
> desktops are only just starting to catch on to the idea. (And of course
> Enrico is several leaps beyond it with some debtags stuff.)

 Actually desktops support this since some years too via deskbar-applet
 and beagle.  These programs are now very usable, but as file contents
 are also indexed for some of them, I am not sure we should install such
 a program by default.

 I just tried deskbar-applet, and it searches through the information of
 .desktop files just fine.

 Another benefit of FreeDesktop menu systems is in the availability of
 menu editors, such as alacarte, which permit reorganizing your menu,
 adding / removing / changing entries etc.

 Translations were also pointed out as a major advantage.

 You can also benefit from launchers in panels or on your desktop which
 will keep all the attributes of the original .desktop files.


 I already complained of flaws of the Debian menu system in the past,
 and I agree with all the complaints I've seen here (icon formats,
 useless entries, Debian specificity).
   Debian specificity is the worst thing here as it prevents us from
 sending improvements upstream and doesn't permit application authors to
 contribute new applications or features: it's less likely that someone
 spends time creating a Debian menu editor than a Freedesktop one.  It
 puts the burden on Debian folks to reinvent everything (translations,
 categories, user overrides) and doesn't permit contributing the efforst
 on the menu entries upstream.
   Maintainers also lose time writing Debian menu entries, or
 downscaling icons in size and colors.

-- 
Loïc Minier


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

Re: adding desktop files to misc packages

[Eduard Bloch]

#include 
* Bernhard R. Link [Sat, Jul 14 2007, 01:10:50PM]:
> * Mike Hommey <[EMAIL PROTECTED]> [070714 11:30]:
> > On Sat, Jul 14, 2007 at 10:55:00AM +0200, Bernhard R. Link <[EMAIL 
> > PROTECTED]> wrote:

> > The fact is very very very very few users actually use these items. So
> > why bother the more than vast majority that doesn't need them ?
> 
> Because our priority are our users, and not only those users that some
> people think are the important ones?

You confuse importance and interests of vast majority.

> And how is it bothering other people if there are options? Should we
> remove all features just because you and some majority you claim to have
> does not use them?

Not remove. Restructure, make the more important submenues appear
earlier and move the unimportant stuff (shells, emulators, hamradio,
...) out of sight.

In fact, I would suggest changing our menu structure a little bit, or
just convert it to the fd.o specs compliant structure (see [1]).

I also suggest moving away from the Debian menu files to .desktop files
because of more flexible format. Therefore, if the menu using packages
support the new style, they would read the menu data from those .desktop
files.

Since we cannot change every package delivering a menu file, this could
be done by a helper package in the transition phase...  this helper
package would put auto-generated .desktop file into a replacement
directory so the new-style-menu-generators can use those files unless
real versions are provided by the correspondig package.

[1] 
http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry

Regards,
Eduard.
-- 
Wie man sein Kind nicht nennen sollte: 
  Gerold Steiner 


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

Re: adding desktop files to misc packages

[Eduard Bloch]

#include 
* Josselin Mouette [Sat, Jul 14 2007, 02:26:55AM]:
> 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.

Changing another WM on-the-fly when letting somebody use your PC,
without restarting the whole X session? Testing other WMs? The fact you
are not imagining any use cases does not mean that such ones do not exist.

> I can imagine someone dealing with such a case (although I'd personally
> start a new session to better match the user's environment) but I don't
> think this justifies adding these entries to all users' menus.

If you don't like seeing them, move them to the Settings submenu.

Eduard.

-- 
 Weasel: schreib mal da hinein, daß ich im IRC immer
so schroff bin und nur auf die Türen zeige, öffnen
und durchgehen müssen die Leute schon selbst.  Und
wenn sie nicht tun, was ich ihnen sage, endet mein
Support an der Stelle.


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

Re: adding desktop files to misc packages

[Mike Hommey]

On Sat, Jul 14, 2007 at 02:26:05PM +0200, Eduard Bloch <[EMAIL PROTECTED]> 
wrote:
> #include 
> * Josselin Mouette [Sat, Jul 14 2007, 02:26:55AM]:
> > 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.
> 
> Changing another WM on-the-fly when letting somebody use your PC,
> without restarting the whole X session? Testing other WMs? The fact you
> are not imagining any use cases does not mean that such ones do not exist.

The fact there are use cases does not mean it *must* have a menu entry.
You can pretty much find use cases for very rare and useful for a
only a couple people things, and yet not have to include a menu entry for
that for everyone.

Mike


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

Re: adding desktop files to misc packages

[Magnus Holmgren]

On Friday 13 July 2007 23:30, Darren Salt wrote:
> I demand that Bastian Venthur may or may not have written...
>
> [snip]
>
> > The most annoying part of our Debian menu is, that it is too complicated.
> > The first level with the entries: Apps, Screen, Help, Games and X-Shells
> > is pretty useless, and adds unnecessary depth to the menu tree. It would
> > be a major improvement if we would move the Apps section to the root of
> > the tree and sort the remaining sections (Screen, Help, Games and
> > X-Sheels) *into* this section. That would reduce the depth of the menu
> > tree by one, and would be a huge improvement of usability.
>
> All five already are at the top level in my customised Xfce menu; for me,
> your proposal would increase the depth by one level for all but Apps.

If so, the contents of Apps could presumably be moved to the top level, 
decreasing the depth by one for Apps even there, and leave the level of the 
relatively few other entries the same, or maybe in some cases increased by 
one.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpjZhQH0G5DU.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Bernhard R. Link]

* Eduard Bloch <[EMAIL PROTECTED]> [070714 14:44]:
> #include 
> I also suggest moving away from the Debian menu files to .desktop files
> because of more flexible format. Therefore, if the menu using packages
> support the new style, they would read the menu data from those .desktop
> files.

What do you mean with "format" and what with "more flexible"?
There can hardly be anything more flexible than free-style key-string
pairs. I'm still waiting from the last discussion about the most basic
documentation about the free desktop mess:
How do I as user override a menu item? How as admin?
(At least to this question there is said to be an answer, something
involving creating an undocumented directory and putting things in
there).
Not to speak about all the more complicated stuff. And inventing all
kind of new .desktop things for those things not part of it
(window manager specific modules, window managers, ...) does not sound
that much easier...

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

[Darren Salt]

I demand that Magnus Holmgren may or may not have written...

> On Friday 13 July 2007 23:30, Darren Salt wrote:
>> I demand that Bastian Venthur may or may not have written...
[snip]
>>> It would be a major improvement if we would move the Apps section to the
>>> root of the tree and sort the remaining sections (Screen, Help, Games and
>>> X-Sheels) *into* this section. That would reduce the depth of the menu
>>> tree by one, and would be a huge improvement of usability.
>> All five already are at the top level in my customised Xfce menu; for me,
>> your proposal would increase the depth by one level for all but Apps.

> If so, the contents of Apps could presumably be moved to the top level,
> decreasing the depth by one for Apps even there,

Maybe, but that would double the height of the top level... no, I prefer it
as it is.

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less.  BE MORE ENERGY EFFICIENT.

"Bother", said Pooh, as the read/write heads flew across the room.


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

Re: adding desktop files to misc packages

[Bernhard R. Link]

* Mike Hommey <[EMAIL PROTECTED]> [070714 15:41]:
> The fact there are use cases does not mean it *must* have a menu entry.
> You can pretty much find use cases for very rare and useful for a
> only a couple people things, and yet not have to include a menu entry for
> that for everyone.

Switching the window manager on the fly is in my eyes one of the most
important features of all. Most window managers hardly support it per
command line, and mistyping while entering it can terminate your
session, which is not nice at all.
So the feature is almost only useable when it is in the default menu.

It's useful (and regulary used) for:
- debugging and testing programs (how does this resize work
  with this wm, how with this, are the style hints understood
  by all,...)
- using a computer by a group. (multiple people thinking about
  an article, one after the other having the task of writing,
  then it is very nice to have the wm changed with a few clicks
  or key presses).
- explaining stuff. If people come to ask for help, having the
  same window manager active like them makes it much easier to
  understand you (most peoples are not that good at abstracting
  the wm away, especially tilded vs overlapping) when you can
  just fastly change the wm to explain/show and change back once
  they are gone.
- buggy programs failing with some WMs.


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.


Bernhard R. Link


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

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Frans Pop]

On Saturday 14 July 2007 17:16, Steinar H. Gunderson wrote:
> On Sat, Jul 14, 2007 at 04:53:54PM +0200, Frans Pop wrote:
> > Since the upgrade from 1:1.1.0-6, my system no longer mounts an NFS
> > volume listed in my /etc/fstab during system boot (I did no other
> > relevant upgrades that day). It mounts without any problems if I just
> > give the mount command manually after the boot has completed.
>
> Duplicate of #432511 and #432750, merging. FWIW, the issue is that the
> new mount requires statd to be running, and initscripts doesn't do that
> yet.

Shouldn't the relevant change be delayed until initscripts _does_ support 
this then? And after that nfs-common should be given a proper versioned 
dependency before activating the change?

Please revert this breakage! just Passing it off to initscripts does not 
seem like the right solution here.


pgpA8caXdBL3a.pgp
Description: PGP signature

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Steinar H. Gunderson]

On Sat, Jul 14, 2007 at 05:37:49PM +0200, Frans Pop wrote:
> Shouldn't the relevant change be delayed until initscripts _does_ support 
> this then? And after that nfs-common should be given a proper versioned 
> dependency before activating the change?

It was not discovered before after-the-fact, unfortunately.

> Please revert this breakage! just Passing it off to initscripts does not 
> seem like the right solution here.

I don't really understand you here. Mounting NFS volumes without rpc.statd
has been semi-broken for ages (ie. works by accident), util-linux is removing 
NFS mount support, and something has to take over. Is then the right fix to

  a) Add a line or two to initscripts to start rpc.statd in addition to
 portmap, or
  b) Remove mount.nfs, against upstream's explicit intentions, and let _all_
 NFS mounts break when the new util-linux hits unstable?

Given how easy a) is, and how hard b) will break at some later stage, I'm
quite sure I'd prefer a). Actually, you can simply remove the current check
for $gss_or_idmap, and do "/etc/init.d/nfs-common start" as soon as you see
an NFS mount (currently signaled by signaled by signaled by signaled by 
"portmap=yes").

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


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

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Frans Pop]

On Saturday 14 July 2007 17:46, Steinar H. Gunderson wrote:
> On Sat, Jul 14, 2007 at 05:37:49PM +0200, Frans Pop wrote:
> > Please revert this breakage! just Passing it off to initscripts does
> > not seem like the right solution here.
>
> I don't really understand you here. Mounting NFS volumes without
> rpc.statd has been semi-broken for ages (ie. works by accident),
> util-linux is removing NFS mount support, and something has to take
> over. Is then the right fix to
>
>   a) Add a line or two to initscripts to start rpc.statd in addition to
>  portmap, or
>   b) Remove mount.nfs, against upstream's explicit intentions, and let
>  _all_ NFS mounts break when the new util-linux hits unstable?

I'm not all that interested in what the right long-term fix is, I'm 
concerned about a change in nfs-common breaking something semi essential 
that has worked for ages, accidentally or not.

If something like that is reported, IMHO the only correct course of action 
is first to make sure that the breakage is fixed, and then to start 
talking with maintainers of other involved packages about the correct 
structural fix and migration path, and only implementing your own change 
again _after_ other packages have made the necessary modifications.

Do I understand correctly that the new util-linux is sitting in 
experimental? In that case it is pretty clear to me that it should *not* 
hit unstable until this has been sorted out.

> Given how easy a) is, and how hard b) will break at some later stage,
> I'm quite sure I'd prefer a). Actually, you can simply remove the
> current check for $gss_or_idmap, and do "/etc/init.d/nfs-common start"
> as soon as you see an NFS mount (currently signaled by signaled by
> signaled by signaled by "portmap=yes").

It has nothing to do with easy or hard. A change in nfs-common is causing 
systems to break. This should be fixed ASAP, and with #432511 only at 
priority important, it does not look like I want to wait for any action 
there...

Cheers,
FJP


pgpsJEJSv31AH.pgp
Description: PGP signature

Re: desktop and/or menu files localization (was: Re: adding desktop files to misc packages)

[Neil Williams]

On Sat, 14 Jul 2007 12:53:03 +0200
Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le samedi 14 juillet 2007 à 08:28 +0100, Neil Williams a écrit :
> > > From what I see in the dozens of .desktop files I have on my own
> > > system, I see "Field[code]" fields for translations of "Field". 
> > > 
> > > This is similar to what we had, in the past, for debconf
> > > templates and we all known this doesn't scale and doesn't handle
> > > changes to English strings very well.
> > 
> > The strings used to generate translated .desktop entries can
> > (should) come from the upstream po/ directory via gettext - it can
> > be handled directly using gettext and make. 
> 
> Actually they are using intltool, just like we do for debconf
> templates.

Yes, just ignore my initial post - I broke my own rule about sending in
haste.
 
> > All my upstream projects include all
> > translatable strings for the .desktop file in the .gmo (and
> > therefore the installed .mo) yet these also exist in the .desktop
> > file that is eventually installed.
> 
> Side note: you don't need to install such .mo files, unless they also
> contain translations accessed from the code.

Yes, they do. The .desktop strings are included to that there is only
one POT file to send to translators.

-- 

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


pgpvPkMKMZ22w.pgp
Description: PGP signature

Re: desktop and/or menu files localization (was: Re: adding desktop files to misc packages)

[Joey Hess]

Neil Williams wrote:
> I'd agree that BOTH of these should be able to read the .mo just like
> the application itself.

.mo files do not exist when debconf preconfigures packages. Unless you
want to stick them in control.tar.gz and deal with them in
/var/lib/dpkg/info/. When debconf l10n was being developed, this was
thought to be a bad idea.

A better way to save space would be to remove debconf's templates
database, and have it use the .templates files directly as its database.
This would save in the neighborhood of 8-10 mb, or more generally,
2x the total size of all the .templates files. 

(To save just 1x, you can just turn off retention of the backup copy of
the database, This needs no code changes at all, just set Backup: false
in debconf.conf.)

Compressing the templates files would also save several mb,
more space than would be saved converting them to .mo files.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Joey Hess]

Charles Plessy wrote:
> Having a .desktop file is a requrement in Ubuntu, so it is not
> surprising that people submit patches in wishlist bugs : they are
> encouraged to do so. Looking from the email adress of the bug senders
> from xgalaga and kobodeluxe, they obiously come from there.

Yes, but I'm talking about Debian, and what Debian should do.

> The FreeDesktop menu system has a mechanism to make entries invisible
> with given desktop managers. What we miss in Debian is a policy, or just
> statemenst from relevant teams, which guides maintainers when they have
> to deal with .desktop files.

Yes, that's why I started this thread.

Until there is one, I don't see any reason why I should accept patches
adding menu files to my packages.

> In the absence of any policy from the GNOME, KDE or XFCE teams, my
> personal standpoint is that entries are welcome, so I do add .desktop
> files. Acutally, I even create them when I prepare a new package which
> lacks them. I also support the idea to chose a format from which .menu
> and .desktop files would be generated. It is definitely not fun to
> maintian two similar files in parallel.

Generating both menu and .desktop files from a third format would be
pointless. Either format can be generated from the other format. menu
already generates .desktop files from menu files, and I don't believe it
would be too hard to make menu _read_ .desktop files directly and use it
as a source for the other files it generates.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Steinar H. Gunderson]

On Sat, Jul 14, 2007 at 06:17:13PM +0200, Frans Pop wrote:
> I'm not all that interested in what the right long-term fix is, I'm 
> concerned about a change in nfs-common breaking something semi essential 
> that has worked for ages, accidentally or not.

I'm a bit unsure why this suddenly started going to debian-devel; I'm Cc-ing
the bug again, at least.

> If something like that is reported, IMHO the only correct course of action 
> is first to make sure that the breakage is fixed, and then to start 
> talking with maintainers of other involved packages about the correct 
> structural fix and migration path, and only implementing your own change 
> again _after_ other packages have made the necessary modifications.

The question here is: When initscripts is broken, and a new version of
nfs-common exposes that breakage, what is the right course of action? I'd say
it is to fix initscripts. Note that this is not a simple code change in
nfs-utils; it is a major move of functionality from one code base
(util-linux) to a different one (nfs-utils).

Try this patch:

diff -u sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs 
sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs
--- sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs
+++ sysvinit-2.86.ds1/debian/initscripts/etc/network/if-up.d/mountnfs
@@ -27,10 +27,9 @@
 
exec 9<&0 /dev/null 2>&1
-   then
-   if [ -x /etc/init.d/portmap ] 
-   then
-   /etc/init.d/portmap start
-   else
-   start-stop-daemon --start --quiet --oknodo 
--exec /sbin/portmap
-   sleep 1  # FIXME: Actually synchronize with the 
process?
-   fi
-   fi
-   fi
-
-   #
-   # Initialize nfs-common (which starts rpc.gssd and/or
-   # rpc.idmapd, and loads the right kernel modules if
+   # Initialize nfs-common (which starts rpc.statd, rpc.gssd
+   # and/or rpc.idmapd, and loads the right kernel modules if
# applicable) if we use Kerberos and/or NFSv4 mounts.
#
-   if [ "$gss_or_idmap" = yes ] && [ -x /etc/init.d/nfs-common ]
+   if [ "$start_nfs" = yes ] && [ -x /etc/init.d/nfs-common ]
then
/etc/init.d/nfs-common start
fi

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


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

The Debian 500000th bug contest

[Christian Perrier]

(reply set to -curiosa to avoid cluttering up other lists. I did not
found this very appropriate for d-d-a)

Please remember that the Debian 50th bug contest is still
opened. As I completely forgot about reminding the enthusiast crowd
about this very important event, I extend the bet period by one week.

For those who missed the original annoucement (I even can't find it
myself, I really suck at announcing things), the contest is very
simple:

There are good chances that the Debian BTS will turn the #50 mark
at some moment during the etch->lenny release cycle.

In order to make this more fun, a small contest has been set up. The
principle is very simple: please place a bet (one per person) about
the day this bug will be reported. The place for bets is the
http://wiki.debian.org/50thBugContest wiki page.

The winner(s) will be the person(s) placing her|his|their bet as close
as possible of the real moment bug #50 is reported.

Bets are opened until July 22nd 2007 00:00UTC (hoping that I'll
remember about closing the page).

In case you care:
Bug #10 was reported June 7th 2001
Bug #20 was reported July 4th 2003
Bug #30 was reported March 17th 2005
Bug #40 was reported Nov 23rd 2006

-- 





signature.asc
Description: Digital signature

Re: desktop and/or menu files localization (was: Re: adding desktop files to misc packages)

[Neil Williams]

On Sat, 14 Jul 2007 12:31:33 -0400
Joey Hess <[EMAIL PROTECTED]> wrote:

> Neil Williams wrote:
> > I'd agree that BOTH of these should be able to read the .mo just
> > like the application itself.
> 
> .mo files do not exist when debconf preconfigures packages. Unless you
> want to stick them in control.tar.gz and deal with them in
> /var/lib/dpkg/info/. When debconf l10n was being developed, this was
> thought to be a bad idea.

Yes, I agree - the original was sent in haste, I realised later why this
wasn't such a good idea.

> A better way to save space would be to remove debconf's templates
> database, and have it use the .templates files directly as its
> database. This would save in the neighborhood of 8-10 mb, or more
> generally, 2x the total size of all the .templates files. 

That's a very good idea, thanks!

In most cases, Emdebian will use cdebconf instead of debconf because
we're removing Perl from essential and doing without perl in the rootfs
(and probably most installations). (Also dropping python etc. and
using busybox/dash instead of bash, we aren't just picking on perl.)

> (To save just 1x, you can just turn off retention of the backup copy
> of the database, This needs no code changes at all, just set Backup:
> false in debconf.conf.)

I'll make a note to test that with cdebconf.

> Compressing the templates files would also save several mb,
> more space than would be saved converting them to .mo files.

Thanks.

-- 

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


pgpKrUOxR5oIf.pgp
Description: PGP signature

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Frans Pop]

On Saturday 14 July 2007 18:46, Steinar H. Gunderson wrote:
> I'm a bit unsure why this suddenly started going to debian-devel; I'm
> Cc-ing the bug again, at least.

Because I CCed it there, but you only replied to d-devel :-)

> The question here is: When initscripts is broken, and a new version of
> nfs-common exposes that breakage, what is the right course of action?
> I'd say it is to fix initscripts. Note that this is not a simple code
> change in nfs-utils; it is a major move of functionality from one code
> base (util-linux) to a different one (nfs-utils).

The right cause of action should at least include preventing the breakage 
from migrating to testing! After all, testing is supposed to be a usable 
distribution. Suddenly losing all you NFS mounts on reboots after a 
routine package upgrade is IMO a serious regression.

Which means that ATM an RC bug against nfs-common should be present as 
nothing else will prevent its migration. (Possibly blocked by the bugs 
against initscripts.)

> Try this patch:

The patch works for me. Thanks.


pgpmpSkSRlipH.pgp
Description: PGP signature

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Steinar H. Gunderson]

tags 433119 + patch
thanks

On Sat, Jul 14, 2007 at 07:40:13PM +0200, Frans Pop wrote:
>> I'm a bit unsure why this suddenly started going to debian-devel; I'm
>> Cc-ing the bug again, at least.
> Because I CCed it there, but you only replied to d-devel :-)

OK, my bad.

>> Try this patch:
> The patch works for me. Thanks.

Good. initscript maintainers: I intend to NMU with this patch (and this patch
alone, except for changelog changes), as per the standard NMU policy with a
week's delay. Please let me know if you have any objections.

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


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

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Frans Pop]

clone 433119 -1
reassign -1 nfs-common 1:1.1.0-8
block -1 with 433119
tags -1 - patch
severity -1 grave
thanks

On Saturday 14 July 2007 20:09, Steinar H. Gunderson wrote:
> Good. initscript maintainers: I intend to NMU with this patch (and this
> patch alone, except for changelog changes), as per the standard NMU
> policy with a week's delay. Please let me know if you have any
> objections.

In that case we still need to block nfs-common from migrating. From these 
comments on #d-devel below it would seem that RM agrees that this is an 
RC issue:
 vorlon: Any opinion on #433119? As it is now, this would affect 
testing too as soon as nfs-utils is old enough.
 fjp: get the release team to block the package until sysvinit is 
fixed?

This cloned bug is also a reminder to set an appropriate versioned 
dependency on initscripts in nfs-common.

Thanks for the quick responses,
FJP


pgpz193wQjvbE.pgp
Description: PGP signature

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Wouter Verhelst]

On Sat, Jul 14, 2007 at 06:17:13PM +0200, Frans Pop wrote:
> If something like that is reported, IMHO the only correct course of action 
> is first to make sure that the breakage is fixed,

No matter what? I disagree. The correct fix should be implemented,
rather than an ugly hackish fix. If you do the ugly hackish
quick-and-dirty fix first, and make an error in that one afterwards, you
end up having to deal with that as well. It's better to keep the
situation as is, take your time to figure out what the best solution is,
and implement that.

Of course, that doesn't mean this can take ages, but that isn't
happening AFAICS.

If it's really a problem for you, you can always download the previous
version of the package and keep it on hold until the bug is fixed.

This is unstable, after all.

-- 
 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]

Re: adding desktop files to misc packages

[Holger Levsen]

Hi,

On Saturday 14 July 2007 13:10, Bernhard R. Link wrote:
> Because our priority are our users, and not only those users that some
> people think are the important ones?
>
> And how is it bothering other people if there are options? Should we
> remove all features just because you and some majority you claim to have
> does not use them?
[...]
> Sorry, I do not understand you. All definitions of clutter I could find
> include "confusion" or "disorder". Having everything available that is
> installed and useable in hierachy is a clear and easy to understand
> concept.

(In general: too much) choice is bad. Please read 
http://www.joelonsoftware.com/items/2006/11/21.html

Exceptions confirm this rule ;-)


I have also been (more) confused by the debian menu than it helped me and I 
know of several others who experienced the same. Maybe renaming "Debian" 
to "all applications" would be helpful enough, that way users could start all 
applications they have installed easily and also copy the launchers to the 
panels, which is what I use(d) the debian menu most often for

I also think a policy and/or release goal is a appropriate way of solving this 
for all packages.


regards,
Holger


pgpW2hmDtlWwl.pgp
Description: PGP signature

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Frans Pop]

On Saturday 14 July 2007 20:45, you wrote:
> If it's really a problem for you, you can always download the previous
> version of the package and keep it on hold until the bug is fixed.
>
> This is unstable, after all.

Of course. I know that.

The whole point of the conversation (and my taking it to d-devel) was that 
by reassigning the issue to another package as was done by Steinar, 
nothing would prevent the breakage from migrating to testing too!

IMO if an upload of a package is the direct cause of serious breakage, 
then, even if the actual bug is in another package, the maintainer needs 
to take responsibility for getting that breakage fixed _before_ allowing 
his package to migrate to testing.
And that was not being done in this case, but all is well now.


pgpzp5IePnNUB.pgp
Description: PGP signature

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Wouter Verhelst]

On Sat, Jul 14, 2007 at 09:54:43PM +0200, Frans Pop wrote:
> IMO if an upload of a package is the direct cause of serious breakage, 
> then, even if the actual bug is in another package, the maintainer needs 
> to take responsibility for getting that breakage fixed _before_ allowing 
> his package to migrate to testing.

Oh, OK. Yes, we agree there, but I didn't understand that from your
original message.

-- 
 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]

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Steve Langasek]

On Sat, Jul 14, 2007 at 08:30:31PM +0200, Frans Pop wrote:

> On Saturday 14 July 2007 20:09, Steinar H. Gunderson wrote:
> > Good. initscript maintainers: I intend to NMU with this patch (and this
> > patch alone, except for changelog changes), as per the standard NMU
> > policy with a week's delay. Please let me know if you have any
> > objections.

> In that case we still need to block nfs-common from migrating. From these 
> comments on #d-devel below it would seem that RM agrees that this is an 
> RC issue:
>  vorlon: Any opinion on #433119? As it is now, this would affect 
> testing too as soon as nfs-utils is old enough.
>  fjp: get the release team to block the package until sysvinit is 
> fixed?

Ahem, "RW".  If you must resort to invoking me in an appeal to authority,
please use accurate citations. :)  (I.e., I neither added such a block, nor
declared this to be an RC bug on nfs-utils; I have no more authority over
lenny than you or any other developer.)

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


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

Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Jelmer Vernooij]

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


* Package name: bzr-rebase
  Version : 0.1
  Upstream Author : Jelmer Vernooij <[EMAIL PROTECTED]>
* URL : http://bazaar-vcs.org/Rebase
* License : GPL
  Programming Lang: Python
  Description : Rebase plugin for Bazaar

The Bazaar rebase plugin adds support for rebasing branches to Bazaar.
It adds the command 'rebase' to Bazaar. When conflicts occur when replaying 
patches, the user can resolve the conflict and continue the rebase using the 
'rebase-continue' command or abort using the 'rebase-abort' command.

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

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


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

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Frans Pop]

On Saturday 14 July 2007 22:57, Steve Langasek wrote:
> >  vorlon: Any opinion on #433119? As it is now, this would affect 
> > testing too as soon as nfs-utils is old enough.
> >  fjp: get the release team to block the package until
> > sysvinit is fixed?
>
> Ahem, "RW".  If you must resort to invoking me in an appeal to
> authority, please use accurate citations. :)  (I.e., I neither added
> such a block, nor declared this to be an RC bug on nfs-utils; I have no
> more authority over lenny than you or any other developer.)

Sorry, I don't understand. AFAIK the quotation is 100% accurate, unless 
you were replying to a different comment from me.

The only thing that may be wrong is my interpretation of your comment. I 
took it to mean that you agreed the issue was serious enough to be 
considered RC and that the release team [1] would consider a request to 
block this new version of nfs-utils from migrating if it were made.
I don't think I ever implied that you actually set such a block.

[1] I do hope that the RW sill is a member of the release team and also
RM also stands for "Release Management" or "Release Managers", especially 
when used without article...


pgpiBtpIZKeHz.pgp
Description: PGP signature

Mass bug filing: Versioned Build-Depends on linux-kernel-headers

[Daniel Schepler]

I intend to do a mass bug filing soon on packages that FTBFS because they have 
a versioned Build-Depends on linux-kernel-headers, which has been removed 
from sid.  (Unversioned Build-Depends are fine for now, since linux-libc-dev 
Provides it.)  According to a quick search through the index files, no binary 
packages are affected, at least on i386, and the source packages affected 
are:

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   gem

Paul Bame <[EMAIL PROTECTED]>
   palo

Ben Collins <[EMAIL PROTECTED]>
   silo

Paul Cupis <[EMAIL PROTECTED]>
   eagle-usb

Debian multimedia packages maintainers 
<[EMAIL PROTECTED]>
   libdvb
   vls

Rene Engelhard <[EMAIL PROTECTED]>
   wavemon

Eric Evans <[EMAIL PROTECTED]>
   xsupplicant

Matthew Garrett <[EMAIL PROTECTED]>
   hotkey-setup

Debian QA Group <[EMAIL PROTECTED]>
   toshset

Daniel Jacobowitz <[EMAIL PROTECTED]>
   bogl

Peter Makholm <[EMAIL PROTECTED]>
   inotify-tools

Noah Meyerhans <[EMAIL PROTECTED]>
   iputils

Josselin Mouette <[EMAIL PROTECTED]>
   gnome-vfs2
-- 
Daniel Schepler


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

> 
> Like it or not, your software fits very much into the role played
> by XMMS, such that someone who likes XMMS is more likely to choose
> Audacious than, say, Rythymbox. That's why it's being discussed as a
> "replacement". If we remove XMMS from the distribution, we have some
> obligation to point users at similar tools. 
> 
> Since you obviously modeled Audacious on XMMS (via BMP), I'm not sure
> why you find such comparisons offensive.
> 
> Steve

Because every time distros try to do an xmms->audacious migration on us,
it causes additional load on our development effort because people file
bug reports and demand that we behave exactly like XMMS. 

I don't find the comparison offensive, I find the result of the comparison
offensive, which is people dictating to us how our project will work. I cannot
work efficiently under those conditions, and I don't suspect anyone else
could either. So, it becomes a PR nightmare for us.

That's why I take offense and ask for very strong clarification that we are
not cloning XMMS to the letter. That's what "XMMS clone" means to these people.

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]

Jon Dowland  alcopop.org> writes:

> Unless I've got my timeframes wrong, there were a few
> successful attempts too. What's objectionable about people
> trying to find security flaws in your software, apart from
> their motivation for doing so?
> 

There is nothing wrong with trying to find security flaws. However,
there have been no security flaws found in audacious itself, but instead
in the third party code we carry on. We have infact used these flaws to
motivate distributions to keep the latest audacious always available to their
userbase, e.g. "hey 1.2.2 has a ton of flaws, you might want to upgrade it
in your next release if you weren't doing so already."

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.

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]

Joseph Neal  speakeasy.net> writes:

> It's my impression that audicious is not scriptable so it can't be
> as easily integrated into existing applications or controlled from emacs
> or irssi.  

[EMAIL PROTECTED] ~ $ audtool current-song
New Order - The Rest Of - Age of Consent
[EMAIL PROTECTED] ~ $ audtool current-song-filename
file:///home/nenolod/03%20Age%20of%20Consent.mp3
[EMAIL PROTECTED] ~ $ audtool current-song-length
5:13

(demonstrations of the other commands not done because there's a lot of them)

Seems pretty scriptable to me.

William


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

Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot

[Steve Langasek]

On Sat, Jul 14, 2007 at 11:31:58PM +0200, Frans Pop wrote:
> On Saturday 14 July 2007 22:57, Steve Langasek wrote:
> > >  vorlon: Any opinion on #433119? As it is now, this would affect 
> > > testing too as soon as nfs-utils is old enough.
> > >  fjp: get the release team to block the package until
> > > sysvinit is fixed?

> > Ahem, "RW".  If you must resort to invoking me in an appeal to
> > authority, please use accurate citations. :)  (I.e., I neither added
> > such a block, nor declared this to be an RC bug on nfs-utils; I have no
> > more authority over lenny than you or any other developer.)

> Sorry, I don't understand. AFAIK the quotation is 100% accurate, unless 
> you were replying to a different comment from me.

You prefaced that quote with

> it would seem that RM agrees that this is an RC issue:

and I'm not an RM.

> The only thing that may be wrong is my interpretation of your comment. I 
> took it to mean that you agreed the issue was serious enough to be 
> considered RC and that the release team [1] would consider a request to 
> block this new version of nfs-utils from migrating if it were made.
> I don't think I ever implied that you actually set such a block.

> [1] I do hope that the RW sill is a member of the release team and also
> RM also stands for "Release Management" or "Release Managers", especially 
> when used without article...

Uh, to my knowledge RM has never stood for "Release Management" in a Debian
context.  So if that's what you meant, ok, but I don't think that was clear
to the audience (and it wasn't clear to me).

Sure, a request to block nfs-utils from migrating would be considered; and
yes, I'm still part of the release team, and my opinions tend to align with
those of the RMs; but I don't speak for them.

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


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

Josselin Mouette  debian.org> writes:

> 
> Whether you like it or not, audacious is a playlist-based audio player
> with support for many audio formats and funny plugins. This description
> sounds much like XMMS, which is why it can be considered a good
> replacement. As a user, I don't care about the architecture being
> different (apart from the bugs gone away).
> 

The only thing I ask for is that you don't assert that Audacious is
a 100% identical "XMMS clone". Saying that Audacious is a suitable
replacement is fine, saying that we are an "XMMS clone" in any
official documentation will likely result in users harassing us.

Which we don't want. After all, would you if you were in our position?

Gentoo did this initially and we got hit with an onslaught of unhappy
migrants. My position is to make sure that does not happen again.

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]

Joseph Neal  speakeasy.net> writes:

> 
> There are a number of plugins available from the rarewares repository[1] and 
> perhaps other third party repositories which provide the only convient way 
> I'm aware of to access a number of media formats (bonk, wavepack, lossless 
> audio, shorten, various DVD audio formats).  While I do not expect debian to 
> support these packages, I do ask that the wider ecosystem be taken into 
> consideration.
> 

Audacious supports wavpack out of the box. I have an unofficial port of
bonk and shorten on my computer which I can package on request; and
there was at one time a port of xmms-ac3dec to Audacious, but it doesn't
work with the new plugin API.

At any rate, the ecosystem for Audacious is pretty much the same as it is
for XMMS.

William




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

Re: Mass bug filing: Versioned Build-Depends on linux-kernel-headers

[Loïc Minier]

On Sat, Jul 14, 2007, Daniel Schepler wrote:
>gnome-vfs2

 Fixed in SVN; please don't file this one; thanks!

-- 
Loïc Minier


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

Re: Considerations for 'xmms' removal from Debian

[Don Armstrong]

On Sat, 14 Jul 2007, William Pitcock wrote:
> Because every time distros try to do an xmms->audacious migration on
> us, it causes additional load on our development effort because
> people file bug reports and demand that we behave exactly like XMMS.

Like it or not, bug reports are a part of software development that we
all have to deal with. Suggesting announcements or text for such a
transition may help, but at the end of the day distributions are going
to switch as projects mature or decay. Complaining about the
transition occuring isn't going to resolve your concern.

> I don't find the comparison offensive, I find the result of the
> comparison offensive, which is people dictating to us how our
> project will work.

Users shouldn't be able to dictate to you how the project works; they
don't do the development. In Debian's case, refer these users to our
bug tracking system (as all of our documentation refers users.)


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 poeple
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]

Lionel Elie Mamane  mamane.lu> writes:

> 
> Would a mention of the "different direction of audacious" in the
> release notes of lenny, the next Debian release, fulfil your "PR
> handling" request? Something like

Simply not asserting that Audacious is a fullstop "XMMS clone" will fulfill my
request.

> 
>  4.5 XMMS removal
> 
>  Due to concerns over its high number of bugs, unmaintained status
>  (and hence bugs will not get fixed), usage of old, unmaintained
>  libraries (gtk+ 1.2) and no UTF-8 support, xmms has been removed from
>  Debian. We suggest users of xmms try 'bmpx' and/or 'audacious' for
>  media players that may feel familiar to them. You may also want to
>  give xmms2 a shot: it is by the same upstream than xmms, albeit feels
>  very different.
>

The developers of bmpx no longer have a player that is anything like
Audacious or XMMS. It uses GStreamer and looks more like Amarok than
XMMS. You should look at their Screenshots[1] before recommending it
as an XMMS replacement.

I'm not qualified to comment on XMMS2.

Sure, audacious is similar to XMMS, and claiming that is fine. Claiming
that we are an XMMS *clone* sends the wrong message to your user base
and causes problems in upstream with bugreports like:

 (a)  Feature X is broken in Audacious because it's not like XMMS.
 (b)  You don't _. That's a regression from XMMS.
 (c)  Why doesn't Audacious have _? XMMS does.

As long as we don't hear about 'regressions from XMMS' as a result of
a migration path provided by Debian, then you have fulfilled my request.

This is where Gentoo initially failed to succeed in their migration.

William

[1] http://beep-media-player.org/site/Screenshots


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

> Like it or not, bug reports are a part of software development that we
> all have to deal with. Suggesting announcements or text for such a
> transition may help, but at the end of the day distributions are going
> to switch as projects mature or decay. Complaining about the
> transition occuring isn't going to resolve your concern.

If you think I am complaining about debian transitioning from xmms to
audacious, I am not. I like bug reports /that have merit/. Simple
comparisons to XMMS do not provide such merit.

I am complaining about developer time being wasted by xmms zealots
which will likely harass us on our tracker.

> Users shouldn't be able to dictate to you how the project works; they
> don't do the development. In Debian's case, refer these users to our
> bug tracking system (as all of our documentation refers users.)

Then debian will resolve their complaints locally using patches, which
means we will likely have to adopt the position of not providing any
upstream support to debian. I would like to avoid that, but if debian
patches audacious to make it work like XMMS, then we would have no
choice but to reject bugs reported to us using the debian patched
binaries.

As an example, what Debian ships as 'xmms' is quite different than what
you normally get in the CVS of XMMS. I would like to see that not happen
to audacious.

William


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

Re: Bug#431482: Considerations for 'xmms' removal from Debian

[William Pitcock]

Steve Langasek  debian.org> writes:

> 
> I wonder why audacious and audacious-plugins should be separate packages at
> all instead of building them into a single binary package, given that this
> circular dependency relationship exists (even if not on paper currently).
> 

Because we (audacious) release the player and the plugins seperately. This 
allows
for faster QA procedures to happen during the development workflow, as we don't
have to freeze development of both the player and the plugins, we can just
concentrate on one or the other. For instance, the latest audacious player is
1.3.2, and the latest plugins pack is 1.3.5.

William


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

Re: Considerations for 'xmms' removal from Debian

[Don Armstrong]

On Sat, 14 Jul 2007, William Pitcock wrote:
> I am complaining about developer time being wasted by xmms zealots
> which will likely harass us on our tracker.

There's little that can be done to educate or placate zealots; but
considering that everyone is talking about transitioning to audacious,
not advertising (heh; amusing that someone thinks we have PR) adacious
as an xmms clone.

> Then debian will resolve their complaints locally using patches,
> which means we will likely have to adopt the position of not
> providing any upstream support to debian. I would like to avoid
> that, but if debian patches audacious to make it work like XMMS,
> then we would have no choice but to reject bugs reported to us using
> the debian patched binaries.

The point isn't that the maintainers would blindly follow the user's
bug reports. The point is that the maintainers will filter out inane
and irrelevant bug reports before forwarding them upstream, reducing
the load on upstream developers due to whatever package descriptions
and transition plans that Debian implements.

In general, bug reports should be filed against the Debian package.
The Debian maintainer is more than capable of discerning whether the
bug is due to a custom modification present in Debian only, or whether
it exists upstream, and forwarding the bug appropriately.

> As an example, what Debian ships as 'xmms' is quite different than
> what you normally get in the CVS of XMMS. I would like to see that
> not happen to audacious.

That's really a matter of maintainers working closely with upstream
developers. Rather than this mailing list the person you should be
coordinating with and talking to is Adam Cécile. [Hopefully you were
already aware that he is the audacious maintainer.]


Don Armstrong

-- 
Our days are precious, but we gladly see them going
If in their place we find a thing more precious growing
A rare, exotic plant, our gardener's heart delighting
A child whom we are teaching, a booklet we are writing
 -- Frederick Rükert _Wisdom of the Brahmans_ 
 [Hermann Hesse _Glass Bead Game_]

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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

Eduard Bloch  gmx.de> writes:

> 
> I see this in strace output with default configuration. Switching the
> setting between on-display and on-load makes it even worse, then it
> opens every file THREE times. Sorry, wtf?
> 

This is a result of codec detection, and has been improved upon in
Audacious 1.3 (presently available in unstable?). XMMS does not perform
codec detection, but instead guesses on how to proceed. That behaviour
is broken in more than a few ways.

> Further, it has broken SIGTERM handling. Unless I am able to find such
> visible problems within minutes, this program is no replacement for the
> good old XMMS.
>

It handles SIGTERM gracefully. That's not broken. SIGTERM is not
supposed to immediately kill the app, it's supposed to allow the
app to shutdown gracefully, e.g. save the playlist, settings, et-cetera.
 
> I don't want to have it entirely deactivated, I want it to work then and
> only then when I need this information.
> 

Hitting F5 on your keyboard will cause metadata to be loaded manually
if you have disabled automatic metadata loading.



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

> 
> There's little that can be done to educate or placate zealots; but
> considering that everyone is talking about transitioning to audacious,
> not advertising (heh; amusing that someone thinks we have PR) adacious
> as an xmms clone.
>

I don't think debian has PR, however I think debian can choose how
to handle a migration in a way where it's not harmful to audacious as
upstream from debian.

> In general, bug reports should be filed against the Debian package.
> The Debian maintainer is more than capable of discerning whether the
> bug is due to a custom modification present in Debian only, or whether
> it exists upstream, and forwarding the bug appropriately.
>

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.
 
> That's really a matter of maintainers working closely with upstream
> developers. Rather than this mailing list the person you should be
> coordinating with and talking to is Adam Cécile. [Hopefully you were
> already aware that he is the audacious maintainer.]
> 

Adam has commit access to our repository. I do indeed trust his
judgement, but if he decides to orphan the package, then we have a
problem. If he is put in a position where there are 11000 xmms users
left without a package taking their angst out on him, he may not feel
like maintaining the package anymore. That's human nature, you know.

William


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

Re: Considerations for 'xmms' removal from Debian

[Don Armstrong]

On Sun, 15 Jul 2007, William Pitcock wrote:
> I don't think debian has PR, however I think debian can choose how
> to handle a migration in a way where it's not harmful to audacious
> as upstream from debian.

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

> 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 do indeed trust his judgement, but if he decides to orphan the
> package, then we have a problem. If he is put in a position where
> there are 11000 xmms users left without a package taking their angst
> out on him, he may not feel like maintaining the package anymore.

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.


Don Armstrong

-- 
Debian's not really about the users or the software at all. It's a
large flame-generating engine that the cabal uses to heat their coffee
 -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500)

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


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

Re: adding desktop files to misc packages

[Charles Plessy]

Hi Joey,

It seems that unfortunately we managed to reach a misunderstanding rate
close to 100 % :(

Le Sat, Jul 14, 2007 at 12:44:16PM -0400, Joey Hess a écrit :
> Charles Plessy wrote:
> > Having a .desktop file is a requrement in Ubuntu, so it is not
> > surprising that people submit patches in wishlist bugs : they are
> > encouraged to do so. Looking from the email adress of the bug senders
> > from xgalaga and kobodeluxe, they obiously come from there.
> 
> Yes, but I'm talking about Debian, and what Debian should do.

I read from your mail that you were asking for the rationale of those
bug reports. Also it seems that you feel like it is users who want you
to do something. I thing it is not. It is just that enough persons have
said that it is nice to send a patch to the Debian package when there is
a modification in Ubuntu which is perceived as an improvement. You are
of course free to decide that it is unsuitable to your package.

I have been encouraging subscribers of the ubuntu-science mailing list
to send their .desktop files and icons to the Debian developpers (this
obviously does not include xgalaga and kobodeluxe). If this was a bad
idea, I welcome maintainers of scientific packages to contact me in
private and let me correct that mistake.


> > In the absence of any policy from the GNOME, KDE or XFCE teams, my
> > personal standpoint is that entries are welcome, so I do add .desktop
> > files. Acutally, I even create them when I prepare a new package which
> > lacks them. I also support the idea to chose a format from which .menu
> > and .desktop files would be generated. It is definitely not fun to
> > maintian two similar files in parallel.
> 
> Generating both menu and .desktop files from a third format would be
> pointless. Either format can be generated from the other format. menu
> already generates .desktop files from menu files, and I don't believe it
> would be too hard to make menu _read_ .desktop files directly and use it
> as a source for the other files it generates.

I have never said that the original format should not be Debian Menu or
FreeDesktop. Indeed, I have already proposed this last year, and got
flamed for this.

I also have volunteered last year to give some time to a transition if
it would happen.

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


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

Bug#433168: ITP: hfsprogs -- mkfs and fsck for HFS and HFS+ file systems

[Rogério Brito]

Package: wnpp
Severity: wishlist
Owner: Rogério Brito <[EMAIL PROTECTED]>


* Package name: hfsprogs
  Version : 332
  Upstream Author : Apple Computer Inc.
* URL : http://www.opensource.apple.com/darwinsource/10.4/
* License : APSL 2.0
  Programming Lang: C
  Description : mkfs and fsck for HFS and HFS+ file systems

This is taken from closed bug report at .
It seems that the package never actually materialized itself
unfortunately.  :-(

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The HFS+ file system used by Apple Computer for their Mac OS is now
supported by the Linux kernel.  I've had ample experience with the
mkfs and fsck utilities for this file system in Linux, both from
personal use and from reports of the users of my Debian package
hfsplus.  Right now, mkfs and fsck from this package are best
described as nonexistent and totally unsuable, respectively.  The
upstream author has declared he is not going to develop these tools
any further.  So there goes another nice piece of free software.

Of course, Apple provides mkfs and fsck for HFS+ with the Unix core of
their operating system, Darwin.  Experimental ports to Linux and
FreeBSD exist, so I will start with the original Darwin source and
these ports.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

For those needing the executables, the best option up to now has been
following ,
but a proper Debian package would be, of course, the preferred solution.

There are more reasons for having this package in the archive, namely:

As I see it, HFS+ seems to be a good compromise to carry files between
MacOS X and Linux Machines (and Linux has already gotten hfsplus support
in the kernel for a long time).

HFS+ doesn't suffer the problems of FAT32 like:

* huge space waste (in slack space as devices grow faster);
* ability to create files that are more than 4GB in size (especially
  good for those working with multimedia and that need to carry large
  ISO files);
* ability to use case sensitivity (but I don't know if this is already
  supported by the Linux Kernel);
* ability to be a journaled filesystem (idem);
* ability to use uid's ang gid's on the filesystem.

Among others that I don't know.

I plan on getting the newest changes/patches that I can, especially from
other distributions, especially from gentoo (which already seems to have
such HFS+ utilities available to their users).

I think that Debian users in general (since Macs have gone ix86-64 and
have also been available under PowerPC for ages) would benefit greatly
from a filesystem that is not as limited as FAT32 as pointed out above.

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

Kernel: Linux 2.6.21.5-1 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=C, LC_CTYPE=pt_BR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

-- 
Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org


signature.asc
Description: Digital signature