Bug#707851: Let's remove the Debian menu from the Debian Policy ?
) format (RFC 1524) in the directory `/usr/lib/mime/packages/'. The file name should be the binary package's name. The `mime-support' package provides the `update-mime' program, which integrates these registrations in the `/etc/mailcap' file, using dpkg triggers[1]. Packages installing desktop entries should not install mailcap entries for the same program, because the `mime-support' package already reads desktop entries. Packages using these facilities _should not_ depend on, recommend, or suggest `mime-support'. [1] Creating, modifying or removing a file in `/usr/lib/mime/packages/' using maintainer scripts will not activate the trigger. In that case, it can be done by calling `dpkg-trigger --no-await /usr/lib/mime/packages' from the maintainer script after creating, modifying, or removing the file. 9.7.3. Providing media types to files - The media type of a file is discovered by inspecting the file's extension or its magic(5) pattern, and interrogating a database associating them with media types. To support new associations between media types and files, their characteristic file extensions and magic patterns should be registered to the IANA (Internet Assigned Numbers Authority). See http://www.iana.org/assignments/media-types and RFC 6838 for details. This information will then propagate to the systems discovering file media types in Debian, provided by the `shared-mime-info', `mime-support' and `file' packages. If registration and propagation can not be waited for, support can be asked to the maintainers of the packages mentioned above. For files that are produced and read by a single application, it is also possible to declare this association to the _Shared MIME Info_ system by installing in the directory `/usr/share/mime/packages' a file in the XML format specified at http://standards.freedesktop.org/shared-mime-info-spec/latest/. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140111024610.ga4...@falafel.plessy.net
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Le Thu, Jan 09, 2014 at 01:15:16PM -0800, Jonathan Nieder a écrit : Alas, now that completeness is eroding and I don't see much reason to recommend in policy to continue to add entries, unless we have clear advice about when packagers should include an entry in it and when they should add to the fdo menu instead. As far as I can tell, the de facto policy is just to add to the fdo menu when appropriate. The documented policy is failing to describe that actual practice. Is there some subtlety I'm missing? Hi Jonathan and everybody, please, I would like to decouple two issues. - Issue 1: the Debian menu is superseded in major destkotop environments, and the Policy should recognise that the Debian menu is not the lead mechanism for managing menus in Debian anymore. Unfortutately we have two parallel systems at the moment. - Issue 2: deciding whether the Debian menu is actually obsolete and should be removed from the Policy. I have not yet read complains from users of the Debian menu system that it not comprehensive enough anymore. And while I am not using it, I see in “/usr/share/menu” computer the entries for evince, rythmbox, gedit, and even nautilus, showing that programs that are not strictly specific to GNOME are still there. What I have read is complains from non-users that they would prefer that somebody else does the work of keeping the Debian menu viable, which I think is a totally reasonable request (and to be clear, is also my position as a maintainer of packages having menu entries). If we tie Issue 1 to Issue 2, my gut feeling (not my wish) is that there is currently no way to conclude without going in front of the TC or having a GR, and prehaps demotivate some DDs in the meantime. Please let's not do that, and work so that the the Debian menu is not on the way of the major desktop systems on one hand, and (importantly) vice-versa. Let's avoid that activities in Debian become mutually destructive. So, in order to move forward, I would appreciate if people having stakes in the issue, or having expressed objections earlier, would say whether the patch I proposed is acceptable in principle after correction, and if not, what they are asking for exactly regarding: - Softening the recommendation to use the Debian menu, - documenting the FreeDesktop entry system (menu plus media types), - and since it seems to be a popular request, removing the documentation of the Debian menu from the Policy. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140109232104.ga4...@falafel.plessy.net
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
No comment from the GNOME and KDE teams ? What do you think of the corrections that I proposed below, and of the patch in general ? Cheers, -- Charles Le Mon, Jan 06, 2014 at 08:40:33AM +0900, Charles Plessy a écrit : Hi Steve, Jonathan, and Josselin, thanks to the two first of you for your comments. Josselin, there is a question for you below. About the lack of guidance, I think that it is a weakness of my wording, where for instance I used applications in one case and programs in the other case, but did not underline what difference is meant. For the media types, section 9.7.2 basically says that mailcap should be used if desktop entries are not used, but indeed this information could come earlier. I am proposing corrections below. Le Sun, Jan 05, 2014 at 02:33:20PM -0800, Steve Langasek a écrit : On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote: 9.6. Menus -- Two menu systems are used in Debian: the _FreeDesktop menu_ and the 1 _Debian menu system_. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. It doesn't tell maintainers how to determine which menu system their package belongs to, and it doesn't tell maintainers of packages that want to consume a menu which one they should use. How about: Two independant menu systems are used in Debian. The FreeDesktop menu covers graphical applications that comply with minimal requirements of integration described below. The Debian menu system covers all graphical applications and interactive text-based programs. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. I think that now this clearly shows that everything that is covered by the FreeDesktop menu system is also covered by the Debian menu system. Furthermore, I think the idea of an application belonging to one system or the other is misplaced. I welcome suggestions if belonging can be better replaced by something like relevant to, in the scope of, etc. * In doubt, the package maintainer should coordinate with the maintainers of menu implementations through the _debian-desktop_ mailing list in order to avoid problems with categories or bad interactions with other icons. Especially for packages which are part of installation tasks, the contents of the `NotShowIn'/`OnlyShowIn' keys should be validated by the maintainers of the relevant environments. As a first cut this seems ok, but I would prefer to see more concrete guidance recorded in policy about what values of NotShowIn/OnlyShowIn should be used and when. Josselin, it would be tremendous to have your input here since you wrote that paragraph. Others are of course welcome to make suggestions. 9.7. Multimedia handlers Media types (formerly known as MIME types, Multipurpose Internet Mail 3 Extensions, RFCs 2045-2049) is a mechanism for encoding files and data streams and providing meta-information about them, in particular their type and format (e.g. `image/png', `text/html', `audio/ogg'). # Registration of media type handlers allows programs like mail user # agents and web browsers to invoke these handlers to view, edit or # display media types they don't support directly. Packages which provide programs to view/show/play, compose, edit or print media types should register them using either the _FreeDesktop_ system or the _mailcap_ system. Again, I do not believe an either/or recommendation is appropriate here. How about, in replacement of the previous paragraph: There are two overlaping systems to associate media types to programs which can handle them. The mailcap system is found on a large number of Unix systems. The FreeDesktop system is aimed at Desktop environments. In Debian, FreeDesktop entries are automatically translated in mailcap entries, therefore packages should only use one system at a time. I expect that maintainers of packages with a FreeDesktop menu entry will spontaneously declare media types through it and that it is not necessary to explicitely tell them which one to chose. I welcome suggestions of wording if you think it can be improved. Le Sun, Jan 05, 2014 at 02:39:41PM -0800, Jonathan Nieder a écrit : Do we have clear advice about (1) how to write a menu entry for my console app (or niche graphical app) without cluttering the menus used by the standard desktops (2) when, roughly, it is appropriate to use that facility to hide my menu entries Hi Jonathan, I think that it is not recommended
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Le Tue, Jan 07, 2014 at 11:09:55PM -0300, Lisandro Damián Nicanor Pérez Meyer a écrit : On Wednesday 08 January 2014 08:33:31 Charles Plessy wrote: No comment from the GNOME and KDE teams ? What do you think of the corrections that I proposed below, and of the patch in general ? Not to be taken as KDE team reply, but here's my opinion. On Sunday 05 January 2014 14:53:12 Charles Plessy wrote: First of all, about the core of Sune's request to “soften the the wording recommending menu files”, in the current policy, it is already a should. To make this one softer would be to turn it completely optional at the maintainer's discretion, which does not make sense for a menu that aims at being comprehensive. That's right. So in my opinion we should simply kill the Debian menu system and let other environments implement the FreeDesktop one. The Debian menu system did serve it's purpose, now there is a much wider standard, so let's avoid wasting our time patching the holes on those who did not yet implemented it. Hi Lisandro, thanks for your answer. Input from all the parties is critical. in my point of view, the Policy has been used to bully the maintainers of FreeDesktop-compliant applications and desktop environments, and the patch that I propose, which calls the Debian Menu superseded in these situations, should stop that problem. On the other hand, it is the spirit of Debian to accept low-maintenance patches (in that case, menu entries) when it can help other projects even if one does not care for it. In that sense, if the Debian Menu has an active user base, it would be counter-productive to kill it with a top-down decision. Note that if generalised, top-down termination of people's projects can make Debian very, very small. Regardless of what you think of the Debian Menu, what do you think about my patch ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140108023106.gc28...@falafel.plessy.net
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Hi Steve, Jonathan, and Josselin, thanks to the two first of you for your comments. Josselin, there is a question for you below. About the lack of guidance, I think that it is a weakness of my wording, where for instance I used applications in one case and programs in the other case, but did not underline what difference is meant. For the media types, section 9.7.2 basically says that mailcap should be used if desktop entries are not used, but indeed this information could come earlier. I am proposing corrections below. Le Sun, Jan 05, 2014 at 02:33:20PM -0800, Steve Langasek a écrit : On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote: 9.6. Menus -- Two menu systems are used in Debian: the _FreeDesktop menu_ and the 1 _Debian menu system_. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. It doesn't tell maintainers how to determine which menu system their package belongs to, and it doesn't tell maintainers of packages that want to consume a menu which one they should use. How about: Two independant menu systems are used in Debian. The FreeDesktop menu covers graphical applications that comply with minimal requirements of integration described below. The Debian menu system covers all graphical applications and interactive text-based programs. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. I think that now this clearly shows that everything that is covered by the FreeDesktop menu system is also covered by the Debian menu system. Furthermore, I think the idea of an application belonging to one system or the other is misplaced. I welcome suggestions if belonging can be better replaced by something like relevant to, in the scope of, etc. * In doubt, the package maintainer should coordinate with the maintainers of menu implementations through the _debian-desktop_ mailing list in order to avoid problems with categories or bad interactions with other icons. Especially for packages which are part of installation tasks, the contents of the `NotShowIn'/`OnlyShowIn' keys should be validated by the maintainers of the relevant environments. As a first cut this seems ok, but I would prefer to see more concrete guidance recorded in policy about what values of NotShowIn/OnlyShowIn should be used and when. Josselin, it would be tremendous to have your input here since you wrote that paragraph. Others are of course welcome to make suggestions. 9.7. Multimedia handlers Media types (formerly known as MIME types, Multipurpose Internet Mail 3 Extensions, RFCs 2045-2049) is a mechanism for encoding files and data streams and providing meta-information about them, in particular their type and format (e.g. `image/png', `text/html', `audio/ogg'). # Registration of media type handlers allows programs like mail user # agents and web browsers to invoke these handlers to view, edit or # display media types they don't support directly. Packages which provide programs to view/show/play, compose, edit or print media types should register them using either the _FreeDesktop_ system or the _mailcap_ system. Again, I do not believe an either/or recommendation is appropriate here. How about, in replacement of the previous paragraph: There are two overlaping systems to associate media types to programs which can handle them. The mailcap system is found on a large number of Unix systems. The FreeDesktop system is aimed at Desktop environments. In Debian, FreeDesktop entries are automatically translated in mailcap entries, therefore packages should only use one system at a time. I expect that maintainers of packages with a FreeDesktop menu entry will spontaneously declare media types through it and that it is not necessary to explicitely tell them which one to chose. I welcome suggestions of wording if you think it can be improved. Le Sun, Jan 05, 2014 at 02:39:41PM -0800, Jonathan Nieder a écrit : Do we have clear advice about (1) how to write a menu entry for my console app (or niche graphical app) without cluttering the menus used by the standard desktops (2) when, roughly, it is appropriate to use that facility to hide my menu entries Hi Jonathan, I think that it is not recommended to declare FreeDesktop menu entries for non-graphical programs and that it is more obvious now with the clarifications that I proposed. For hiding entries, let's iron it out (see above), but the final way to determine when it is appropriate is to contact the debian-desktop mailing list. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
(formerly known as MIME types, Multipurpose Internet Mail 3 Extensions, RFCs 2045-2049) is a mechanism for encoding files and data streams and providing meta-information about them, in particular their type and format (e.g. `image/png', `text/html', `audio/ogg'). # Registration of media type handlers allows programs like mail user # agents and web browsers to invoke these handlers to view, edit or # display media types they don't support directly. Packages which provide programs to view/show/play, compose, edit or print media types should register them using either the _FreeDesktop_ system or the _mailcap_ system. 9.7.1. Registration of media type handlers with desktop entries --- Packages shipping an application able to view, edit or point to files of a given media type, or open links with a given URI scheme, should list it in the `MimeType' key of the application's desktop entry. For URI schemes, the relevant MIME types are `x-scheme-handler/*' (e.g. `x-scheme-handler/https'). 9.7.2. Registration of media type handlers with mailcap entries --- Packages that are not using desktop entries for registration should install a file in mailcap(5) format (RFC 1524) in the directory `/usr/lib/mime/packages/'. The file name should be the binary package's name. # The `mime-support' package provides the `update-mime' program, which # integrates these registrations in the `/etc/mailcap' file, using dpkg # triggers. # Footnote: Creating, modifying or removing a file in `/usr/lib/mime/packages/' # using maintainer scripts will not activate the trigger. In that case, # it can be done by calling `dpkg-trigger --no-await # /usr/lib/mime/packages' from the maintainer script after creating, # modifying, or removing the file. Packages installing desktop entries should not install mailcap entries for the same program, because the `mime-support' package already reads desktop entries. # Packages using these facilities _should not_ depend on, recommend, or # suggest `mime-support'. 9.7.3. Providing media types to files - The media type of a file is discovered by inspecting the file's extension or its magic(5) pattern, and interrogating a database associating them with media types. To support new associations between media types and files, their characteristic file extensions and magic patterns should be registered 4 to the IANA (Internet Assigned Numbers Authority). See http://www.iana.org/assignments/media-types and RFC 6838 for details. This information will then propagate to the systems discovering file media types in Debian, provided by the `shared-mime-info', `mime-support' and `file' packages. If registration and propagation can not be waited for, support can be asked to the maintainers of the packages mentioned above. For files that are produced and read by a single application, it is also possible to declare this association to the _Shared MIME Info_ system by installing in the directory `/usr/share/mime/packages' a file in the XML format specified at http://standards.freedesktop.org/shared-mime-info-spec/latest/. Here are my comments: 1: I think that it is fair to ask to support entries in both menu systems as long as there is a real demand (that is: no political bullying), and ideally contribution via patches. Also, if I understand well, the KDE team has a converter that can be used at package build time. 2: One may wonder if this belongs to the Policy, but I would argue that it is a minor bug to keep the burden of maintaining a file that will be better maintained upstream. 3: I replaced “MIME” by “media types” since it is the current terminology. I also made the minor change to replace the mp3 example with ogg. 4: The IANA's procedures and website have positively evolved last year, and now there are even machine-readable lists of media types available for download. I think that we should encourage registration instead of sending requests downstream (for instance to FreeDesktop's shared-mime-info database). First of all, thank you for reading so far. I would welcome constructive comments on the patch attached. By constructive I mean focused (please quote the parts you comment), backed by explanations and, in case of strong objections, some background about what are the stakes of the commenter in the maintenance or use of menu systems and media types. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org
Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
Le Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy a écrit : patch attached. Oops, here it is attached for real. Sorry for the noise ! -- Charles diff --git a/policy.sgml b/policy.sgml index dad8d23..1f0a006 100644 --- a/policy.sgml +++ b/policy.sgml @@ -8054,81 +8054,224 @@ Reloading vardescription/var configuration...done. headingMenus/heading p - The Debian ttmenu/tt package provides a standard - interface between packages providing applications and - emmenu programs/em (either X window managers or - text-based menu programs such as prgnpdmenu/prgn). + Two menu systems are used in Debian: the emFreeDesktop menu/em + and the emDebian menu system/em. Packages shipping applications + that belong to one or both menu systems should provide the necessary + entry files to integrate with them. /p - p - All packages that provide applications that need not be - passed any special command line arguments for normal - operation should register a menu entry for those - applications, so that users of the ttmenu/tt package - will automatically get menu entries in their window - managers, as well in shells like ttpdmenu/tt. - /p + sect1 id=freedesktop-menu + headingThe FreeDesktop menu/heading - p - Menu entries should follow the current menu policy. - /p + p + The FreeDesktop menu is a cross-distribution standard menu that + is available in a large number of desktop environment including + emGNOME/em, emKDE/em or emXfce/em. Applications are + registered through text files called emdesktop entries/em. + Their format is described in the emDesktop Entry Specification/em + at url id=http://standards.freedesktop.org/desktop-entry-spec/latest/; + and complementary information can be found in the + emDesktop Menu Specification/em at + url id=http://standards.freedesktop.org/menu-spec/latest/;. + /p - p - The menu policy can be found in the ttmenu-policy/tt - files in the ttdebian-policy/tt package. - It is also available from the Debian web mirrors at - tturl name=/doc/packaging-manuals/menu-policy/ - id=http://www.debian.org/doc/packaging-manuals/menu-policy/;/tt. - /p + p + The desktop entry files are installed by the packages in the + directory file/usr/share/applications/file and the FreeDesktop + menus are refreshed using emdpkg triggers/em. It is therefore + not necessary to depend on packages providing FreeDesktop menu + systems. + /p - p - Please also refer to the emDebian Menu System/em - documentation that comes with the packagemenu/package - package for information about how to register your - applications. - /p + p + Entries displayed in the FreeDesktop menu should conform to the + following minima for relevance and visual integration. + + list + item + Unless hidden by default, the desktop entry must point to a PNG + or SVG icon with a transparent background, providing at least + the 22times;22 size, and preferably up to 64times;64. The icon + should be neutral enough to ingrate well with the default icon + themes. It is encouraged to ship the icon in the default + emhicolor/em icon theme directories, or to use an existing + icon from the emhicolor/em theme. + /item + + item + If the menu entry is not useful in the general case as a + standalone application, the desktop entry should set the + ttNoDisplay/tt key to vartrue/var, so that it can be + configured to be displayed only by those who need it. + /item + + item + In doubt, the package maintainer should coordinate with the + maintainers of menu implementations through the + emdebian-desktop/em mailing list in order to avoid problems + with categories or bad interactions with other icons. Especially + for packages which are part of installation tasks, the contents + of the ttNotShowIn/tt/ttOnlyShowIn/tt keys should be + validated by the maintainers of the relevant environments. + /item + /list + /p + + p + Since the FreeDesktop menu is a cross-distribution standard, the + desktop entries written for Debian should be forwarded upstream, + where they will benefit to other users and are more likely to + receive extra contributions such as translations. + /p + /sect1 + + sect1 id=debian-menu + headingThe Debian menu system/heading + + p + The Debian menu unifies the menu systems of window managers. In + some desktop environments such as emGNOME/em and emKDE/em, + it has been superseded by the FreeDesktop menu and is hidden by + default. + /p + + p + The Debian ttmenu/tt package provides a standard interface + between packages providing applications and emmenu programs/em + (either X window managers or text-based menu programs such as + prgnpdmenu/prgn). + /p + + p + All packages that provide applications that need not be passed any + special command line
Bug#394417: kgpg: Does not seem to understand unicode.
Package: kgpg Version: 4:3.5.1-2 Severity: normal Dear maintainers, When importing a key, I got a popup saying: gpg: clé BAFEC7F2: « Charles Plessy [EMAIL PROTECTED] » une nouvelle signature [GNUPG:] IMPORT_OK 4 FECC64F84F833C7DB93E213D75897592BAFEC7F2 gpg: Quantité totale traitée: 1 gpg: nouvelles signatures: 1 [GNUPG:] IMPORT_RES 1 0 0 0 0 0 0 1 0 0 0 0 0 0 gpg: 3 marginale(s) nécessaires, 1 complète(s) nécessaires, modèle This kind of behaviour usually indicates that the program tries to print unicode-encoded characters as if they were ISO 8859-1(5). Depending on the cause, this bug may be a duplicate of #385778. Have a nice day, -- Charles Plessy -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages kgpg depends on: ii gnupg 1.4.2-2GNU privacy guard - a free PGP rep ii kdelibs4c2a 4:3.5.4-3 core libraries and binaries for al ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libc6 2.3.6-7GNU C Library: Shared libraries ii libgcc1 1:4.1.1-15 GCC support library ii libqt3-mt 3:3.3.6-4 Qt GUI Library (Threaded runtime v ii libstdc++64.1.1-15 The GNU Standard C++ Library v3 kgpg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
