Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Josselin Mouette]

Guillem Jover  wrote: 
You seem to be framing this as a XDG vs menu formats. I see it in great
part as applications showing up on WM/DE or not. The collateral damage
from the TC decision are applications, WM/DE and its users from either
format.

Only if WMs keep on using the Debian menu instead of the XDG menu.

Err, no, the TC has explicitly made it "impossible" for the two systems
to coexist, breaking existing support, and forcing maintainers to choose
one or other ecosystems, w/o any working solution in sight for WM/DE not
supporting the XDG system. Which has made the situation even worse than
before, in a very anti social way.

You might want to package https://wiki.archlinux.org/index.php/Xdg-menu
which answers exactly the questions you have been asking.

-- 
Joss

Re: Bug#741573: #741573: Menu Policy and Consensus

[Josselin Mouette]

Sam Hartman hartm...@debian.org wrote: 
That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

Given the state menu is in, reading this is… flabbergasting, to say the
least. I would answer tons of things, but fortunately they have already
been put together concisely: http://islinuxaboutchoice.com/ 

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.

The consensus proposal was, in order to preserve some bits of Bill’s
ego, to let menu die slowly by stopping to require mandatory entries for
a useless menu system that only a handful of obscure window managers are
still able to display. Now that Bill has made very clear, by completely
giving in to ridicule, that his ego should not be a problem, Charles is
merely proposing to accelerate that process and avoid pain for everyone.

-- 
Joss


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1437747652.13194.42.ca...@dsp0698014.postes.calibre.edf.fr

Re: Bug#741573: #741573: Menu Policy and Consensus

[Josselin Mouette]

Le lundi 20 juillet 2015 à 22:42 +0200, Bill Allombert a écrit :
 This kind of language while customary of Sune and Josselin is inappropriate 
 and
 rude to any people that have investigated significant time in maintaining 
 menu.

Before complaining about the rudeness of other people’s language, maybe
you should reflect on your own behavior, which is way more offensive
than any kind of swearing.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1437460002.3386.33.ca...@debian.org

Re: Bug#741573: #741573: Menu Policy and Consensus

[Josselin Mouette]

Sam Hartman hartm...@debian.org wrote: 
Bill, in his role of policy editor said that he believed there was not a
consensus.  He cited a specific set of messages that he believes were
not properly addressed.

From the beginning, I have been puzzled by your approach to this issue.
With this paragraph, I think I’m beginning to understand how you want to
treat the issue. And I can’t say I think it is constructive.

Bill used his position as a policy editor to reject a change, not
because it was against consensus or against the policy process, but
because it was against his own opinion. Not as policy editor, but as
menu maintainer. 

This is the root of the problem. By asking whether the policy process
has been respected, you are reversing the responsibility. It was Bill’s
responsibility from day one to recuse himself from policy decisions on
the menu.
It was also Bill’s responsibility, from day one, to raise his own
concerns to the policy change being discussed, not to rely on other
people’s nitpicks *after* the new policy had been approved and
committed.

Maybe, after all, this issue should not have been sent to the TC but to
the DPL, to ask for the revocation of the abused delegation. 

-- 
Joss


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1437405243.6245.129.ca...@dsp0698014.postes.calibre.edf.fr

Bug#707851: Proposed changes on menu systems

[Josselin Mouette]

Hi Russ,

Le jeudi 27 mars 2014 à 18:47 -0700, Russ Allbery a écrit : 
  I note that some important aspect of the XDG specification are not
  included.  While it is not necessarily a requirement for policy
  inclusion, it could be helpful to document the .menu files used by
  desktop environment and how the Categories relates to the menu layout
  the users will see.
 
 My impression is that this part of the specification hasn't gotten the
 same level of attention as the desktop file specification, but that's a
 very vague impression.  

I think everything exists in the specification, but someone not familiar
with it will never know where to start. Add to that the fact that in
Debian, we have one menu per desktop environment, which is something
that has been standardized only very recently (and maybe not entirely).

 I'd be curious to hear the opinion of the desktop
 environment maintainers on what we should tell maintainers of packages
 like fvwm who want to integrate with desktop entries.

I think we should ask the parties interested in cheap XDG menu support
to package that:
https://wiki.archlinux.org/index.php/Xdg-menu

and get rid of the Debian menu this way.

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1395998740.5311.64.camel@dsp0698014

Bug#707851: Please resume discussion on #707851 or defer decision to the TC.

[Josselin Mouette]

Le jeudi 13 mars 2014 à 22:42 +0100, Bill Allombert a écrit : 
 Secondly, if policy is going to mention the XDG menu system, someone should
 volunteer to maintain the XDG menu system in Debian as a whole, to keep
 some coherence. .desktop files from upstream software that are not part
 of larger desktop project like GNOME and kDE tend to be of lower quality.

Thank you for your interest, but this discussion already happened years
ago, and I don’t remind seeing you contributing to it.

The consensus among desktop environment maintainers is that each desktop
environment has its own view of what the main menu should look like,
what should be shown, and in what hierarchies. As a result, we have
patched XDG menus implementations to allow for entirely different menu
hierarchies depending on the environment. Which is why you have a
kde-applications.menu, a gnome-applications.menu, and so on. The desktop
files themselves, of course, remain shared between environments.

As for the desktop files themselves, of course there is some room for
improvement, but I do think their overall quality is much higher than
that of Debian menu files. The proposal addresses the most important
part: that menu implementations maintainers have their say in what
maintainers put in NoDisplay/OnlyShowIn/NotShowIn fields. This avoids
cluttering the menu with unwanted stuff such as Java’s useless control
panel.

 Thirdly, developpers that have stated publicly they were ignoring what policy
 says about the menu system and would not apply patches to improve it, should
 not involve themself in a discussion the outcome of which they are willing to
 ignore. This is not conductive of good faith discussion.

Sure. Let’s keep some developers out of the process. You’ll have more
weight telling them they don’t follow the process with that reasoning.

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1395339379.21499.1819.camel@dsp0698014

Bug#707851: debian-policy: soften the wording recommending menu files

[Josselin Mouette]

Le dimanche 12 mai 2013 à 16:06 -0700, Russ Allbery a écrit : 
 Josselin Mouette j...@debian.org writes:
  How about simply “not useful as a standalone application”?
 
 That sounds great to me.

Here is a new proposed wording with all your suggestions.

9.6 Menus

Packages shipping applications that belong in the menu of a
desktop environment should provide desktop files for integrating
with the menus, following the Desktop Menu Specification
available at
http://standards.freedesktop.org/desktop-entry-spec/latest/

However, the maintainer should remind that the menu is often the
primary interface for the user, and as such it should be filled
with what is most useful to her. Therefore : 
  * If the menu entry is not useful in the general case as a
standalone application, the desktop entry should include
the NoDisplay=true stanza, so that it can be configured
to be displayed only by those who need it. 
  * Unless hidden by default, the desktop entry MUST point
to a PNG or SVG icon with a transparent background,
providing at least the 22×22 size, and preferably up to
64×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 “hicolor” icon theme
directories, or to use an existing icon from the default
theme. 
  * The maintainer should use the “debian-desktop” mailing
list too coordinate with maintainers of menu
implementations, in order to avoid bad interactions with
other icons or wrong categories. Especially for packages
which are part of installation tasks, the contents of
the NotShowIn/OnlyShowIn stanzas should be validated by
the maintainers of the relevant environments. 

Packages can, to be compatible with Debian additions to some
legacy window managers, also provide a menu file. Such menu
entries should follow the Debian menu policy, which can be found
in the menu-policy files in the debian-policy package. It is
also available from the Debian web mirrors
at /doc/packaging-manuals/menu-policy/.

9.7 Multimedia handlers

MIME (Multipurpose Internet Mail 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/x-mp3).

Registration of MIME type handlers allows programs like mail
user agents, file managers and web browsers to invoke these
handlers to view, edit or display MIME types they don't support
directly.

Packages shipping applications able to view, edit or point to
files of a given MIME type, and/or open links with a given URI
scheme, should provide desktop files as described in §9.6, and
using the MimeType stanza. For URI schemes, the relevant MIME
types are x-scheme-handler/* (e.g. x-scheme-handler/https).

The list of supported MIME types, as well as the corresponding
file magic and filename extensions, is provided by the
“shared-mime-info” package. If an application needs to support a
new MIME type, the maintainer should request its addition to
shared-mime-info first, to the Debian or upstream freedesktop
maintainers.

Until its addition to “shared-mime-info”, the package can ship a
MIME file in XML format as described in the Shared MIME-info
specification:
http://standards.freedesktop.org/shared-mime-info-spec/latest/

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1368432170.13176.41.camel@tomoyo

Bug#707851: debian-policy: soften the wording recommending menu files

[Josselin Mouette]

Hi,

Le dimanche 12 mai 2013 à 10:08 +0900, Charles Plessy a écrit : 
 If we were to recommend FreeDesktop menu entries instead of Debian menu
 entires, and if this recommendation were followed carefully, this would
 increase the number of entries in the Gnome and KDE menus on some sytems where
 the user has installed extra packages.  In particular, some entries will
 be redundant with the default applications, and provide only an XPM icon or
 no icon at all.
 
 One way to avoid this is to use HideIn keys, but this requires coordination
 between the maintainers of the package providing menu entries, and the teams
 maintaining Desktop environments.  If there is already an unwritten norm about
 this, then it would be the good time to add it to the Policy: regardless in
 which package the menu entry file is, who has the final word on which menu
 actually displays the entry.

Currently, the final word on the menus layout is in the hands of the
menu implementations’ maintainers. However, some maintainers being
uncooperative about menu categories or OnlyShowIn/NotShowIn lead us to
implement a blacklist mechanism in gnome-menus.

Maybe the wording should encourage maintainers to be careful before
providing menu entries that don’t serve any purpose at all. There is
nothing wrong per se with menu entries for text programs, for example,
but if practically speaking, users won’t use them outside already
launched terminals, it doesn’t make any sense to ship them.

 It looks to me that the scope of the Debian menu system is broader than
 the FreeDesktop system, so in line with the previous discussions about
 the overlap between both, I think that the best way forward would be to
 recommend to declare an entry in one system, but not both.

I don’t think the basic purpose is different. It’s just that so far, the
Debian menu maintainers have put menu completeness before usability. We
should use the opportunity of a policy change to take care of that.

You are also right about MIME handling; now that you have updated
mime-support in unstable (thanks!). As such, let me propose an alternate
wording.


9.6 Menus

Packages shipping applications that belong in the menu of a
desktop environment should provide desktop files for integrating
with the menus, following the Desktop Menu Specification
available at
http://standards.freedesktop.org/desktop-entry-spec/latest/

However, the maintainer should remind that the menu is often the
primary interface for the user, and as such it should be filled
with what is most useful to her. Therefore :
  * If the application will only be used directly in rare
cases – mostly called from a terminal, or used solely as
handler for a given MIME type, for example – the desktop
entry should include the NoDisplay=true stanza, so that
it can be configured to be displayed only by those who
need it. 
  * Unless hidden by default, the desktop entry MUST point
to a PNG or SVG icon with a transparent background,
providing at least the 22×22 size, and preferably up to
64×64. The icon should be neutral enough to ingrate well
with the default icon themes. 
  * The maintainer should coordinate with the maintainers of
the menu implementations, in order to avoid bad
interactions with other wrong categories or icon
duplication. Especially for packages installed by
default, the contents of the NotShowIn/OnlyShowIn
stanzas should be validated by the maintainers of the
relevant environments. 

Packages can, to be compatible with Debian additions to some
legacy window managers, also provide a menu file.

9.7 Multimedia handlers

Packages shipping applications able to view, edit or point to
files of a given MIME type (e.g. audio/x-mp3 or text/plain),
and/or open links with a given URI scheme, should provide
desktop files as described in §9.6, and using the MimeType
stanza. For URI schemes, the relevant MIME types are
x-scheme-handler/* (e.g. x-scheme-handler/https).

The list of supported MIME types, as well as the corresponding
file magic and filename extensions, is provided by the
“shared-mime-info” package. If an application needs to support a
new MIME type, the maintainer should request its addition to
shared-mime-info first, to the Debian or upstream freedesktop
maintainers.

Until its addition to “shared-mime-info”, the package can ship a
MIME file as described in the Shared MIME-info specification:
http://standards.freedesktop.org/shared-mime-info-spec/latest/

Cheers,
-- 
 .''`.  Josselin Mouette

Bug#707851: Please do not remove menu before .desktop is fixed (if it ever will be)

[Josselin Mouette]

Le dimanche 12 mai 2013 à 12:36 +0200, Bernhard R. Link a écrit : 
 Some points for a having menu files:
 
 - it is supposed to include all programs, and does
   not do choices like you don't want that program

In my opinion, this is an anti-feature. A menu is not some random place
to shove all your programs. It is a key part of the user interface, and
needs to be thought as such.

 - it is properly documented (like how do I as administrator
   override and change a menu setting globally).
 - it is properly documented for maintainers

The XDG menu system is properly documented as well.

 - there is still no policy for .desktop entries (a standard
   describing the format is no policy)

That, indeed, is lacking. This is what I have started to draft in my
previous proposal.

 - it can express features modern DEs lack (like switching
   between different environment without closing programs).

This is the perfect example of an anti-feature. Who needs that? What is
the use case? Selection should be done once from the login manager, in
the real world no one needs to dynamically switch WMs.

All in all I don’t see why we couldn’t just drop menu altogether or
replace it by a XDG menu implementation. In all cases, it doesn’t have a
place in the policy anymore.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1368356140.13176.5.camel@tomoyo

Bug#707851: debian-policy: soften the wording recommending menu files

[Josselin Mouette]

Le dimanche 12 mai 2013 à 08:03 -0700, Russ Allbery a écrit : 
* If the application will only be used directly in rare
  cases – mostly called from a terminal, or used solely as
  handler for a given MIME type, for example – the desktop
  entry should include the NoDisplay=true stanza, so that
  it can be configured to be displayed only by those who
  need it. 
 
 This looks mostly right to me.  I always found the inclusion of some
 things (dc, for example, or every shell on the system) in the Debian menu
 to be rather dubious, and likely to eat up a lot of menu real estate on a
 system with a full set of user packages installed.
 
 I'm not sure that mostly called from the terminal is quite the right way
 of phrasing the point, but I'm not sure what the right way of handling it
 is.  My feeling is that things that make sense as applications (irssi,
 top) should be included in the menu, but things that are really just
 command-line utilities (other shells, telnet these days) probably
 shouldn't.  I'm not sure where ncftp, for example, falls in that list, but
 I think both units and bc would ideally appear in the menu.

How about simply “not useful as a standalone application”?

* Unless hidden by default, the desktop entry MUST point
  to a PNG or SVG icon with a transparent background,
  providing at least the 22×22 size, and preferably up to
  64×64. The icon should be neutral enough to ingrate well
  with the default icon themes.
 
 This is a relatively high bar if the icon has to be custom for that
 application, since most maintainers aren't going to have the skills to
 make icons.  Is it okay to just pick some reasonable icon from, say, the
 highcolor set?

We should even encourage using them. Using an icon from an icon theme
ensures several sizes can be available, for example. And it ensures it
can be overriden by another theme.

* The maintainer should coordinate with the maintainers of
  the menu implementations, in order to avoid bad
  interactions with other wrong categories or icon
  duplication.
 
 If we're going to make this a should, I think we need to provide some sort
 of means for the maintainer to do that.  I personally have no idea how I
 would go about doing that coordination.

We could use the debian-desktop mailing list. I think there is at least
one person from each of the interested teams who reads it.

  9.7 Multimedia handlers

 This looks great as an addition to that section.  I think we should keep
 the current background information (the definition of MIME and the
 discussion of what it's used for), though, and at least for right now we
 should probably also keep the mailcap instructions, since I'm fairly sure
 they're still used by very widely used programs like mutt and the Emacs
 mail clients.

The latest mime-support in unstable makes use of desktop files. So while
for menu it still makes sense to ship legacy menu files, for MIME it is
not necessary anymore.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1368395072.13176.11.camel@tomoyo

What is the use case for Policy §7.6.2 ?

[Josselin Mouette]

Hi,

the Debian policy makes a special case of the
Provides/Conflicts/Replaces combination, allowing to replace a package
by another.

The document mentions the case of a virtual package, for which this is
nice and all, but it is still allowed for other packages.

However, any versioned dependency is broken when you handle upgrades
this way. Even worse, APT does not handle such situations very well. Bug
#691160 is a good example of what happens in a bad case (the old package
not being installable anymore). Arguably this is a bug in APT, but we
are more prone to such bugs by allowing arcane relationships between
packages.

It looks to me that we should strictly favor the transitional package
approach instead. Shouldn’t we entirely forbid the
Provides/Conflicts/Replaces combination way of handling upgrades, except
for virtual packages?

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1352454210.3618.794.camel@pi0307572

Re: Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Le vendredi 05 mars 2010 à 09:30 +0100, Vincent Lefevre a écrit :
  Because the users have not yet decided if they want to start the application
  and they look to the manpage for guidance.
 
 Yes, and for various reasons, it may happen that the application
 doesn't start (e.g. due to incorrect environment), and the user
 cannot look at the help from the menu to see what's wrong.

Sometimes when I read such nonsense, I wonder if we are really using the
same distribution.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267781034.20020.0.ca...@meh

Re: Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Le jeudi 04 mars 2010 à 01:22 +0100, Luca Niccoli a écrit :
 Manuals are not only for documenting command line switches, they
 should actually explain how to use a program.
 I found the lack of good man pages one of the most annoying and
 widespread problems of OSS.
 Unfortunately, this gets more and more common with GUIs, as if a
 graphical program could always be self-explanatory.

No. It’s just that they ship with HTML documentation, which is much more
suitable for documenting a GUI. A manual page cannot contain things as
trivial as screenshots, which are mandatory.

 I completely agree that a debian maintainer can't take the burden to
 write every man page upstream has not written, but that doesn't change
 the fact that a missing, outdated or incomplete manual is a bug - to
 be forwarded upstream if possible.

So far, such bugs have been mostly ignored by upstreams. And when they
have not, that’s where things get worse; some upstreams integrated the
manual pages and didn’t maintain them when they changed the command line
switches.

 As has already been noted, the policy says there SHOULD be a manual
 page, so a missing one doesn't make a package RC buggy.

No, but it fills the BTS with pointless bugs. I think we have better
things to do with our developer time and project resources.

 On a side note, I find the habit of replacing the manual with on-line
 html documentation terrible - we don't live in an always on-line world
 yet.

HTML documentation doesn’t have to be online. Packages that do that can
just copy the HTML tree in /usr/share/doc/$package.

  Manual pages, OTOH, are not maintained properly by upstream developers.
 
 Sadly you are right.
 Please try to educate upstream whenever possible.
 Writing good documentation has never been fun, but it dramatically
 improves the usefulness of a program.

Upstreams often write good documentation. It just happens not to be in
the manual page format, which is not suitable for GUIS, but in --help
output and in HTML format.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267694766.15754.13.ca...@meh

Re: Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Le jeudi 04 mars 2010 à 15:20 +0100, Bill Allombert a écrit :
 On Thu, Mar 04, 2010 at 10:26:06AM +0100, Josselin Mouette wrote:
  No. It’s just that they ship with HTML documentation, which is much more
  suitable for documenting a GUI. A manual page cannot contain things as
  trivial as screenshots, which are mandatory.
 
 But a manual page can at least provide a link to the HTML documentation.
 
 This is far better than letting the user guess how to access the
 documentation.

Because, of course, the user is too stupid to click the “Help” menu
inside the application.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267716765.15754.23.ca...@meh

Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Hi,

currently policy §12.1 mandates that “each program, utility, and
function should have an associated manual page”. However, the more I
stomp on bug reports about manual pages, the less I am convinced of
their usefulness for GUI programs.

GUI applications usually take only a few simple command-line options,
and more importantly, when you use a modern development framework, these
options will always be documented correctly with the --help switch.
Manual pages, OTOH, are not maintained properly by upstream developers.

I think it is a waste of time to write manual pages that won’t be
maintained upstream, and that won’t contain more useful information than
--help. The purpose of a manual page is to document precisely the
behavior of a program, and for GUI applications there is usually an
associated GUI documentation instead.

Therefore I propose that we drop the requirement of a manual page if
these conditions are met: 
  * the program requires graphical interaction with the user, and is
not meant to be used from a script; 
  * the command-line switches are properly documented with a --help
option.

For extra points, we could agree on a way to generate manual pages
automatically, either at installation time or on the fly, using
help2man.

Any comments before I submit a bug against the policy?

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: initial packages with multiarch paths

[Josselin Mouette]

Le samedi 13 février 2010 à 14:08 -0800, Steve Langasek a écrit :
  Files only in first set of .debs, found in package libgfshare-dbg
  -
  -rw-r--r--  root/root   /usr/lib/debug/usr/lib/libgfshare.so.1.0.3
 
 Has anyone checked that gdb will succeed in finding debug symbols via the
 multiarch paths?  (I guess gdb handles these generically by prepending
 /usr/lib/debug to the real object path, but probably should be
 double-checked anyway)

If the development symlink is in the same directory as the runtime
library, I don’t think there’s any case where it wouldn’t work.

Still, we’d be better with switching to build ID based locations now, so
that there’s not even a need to ask that question.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1266222393.17961.5.ca...@meh

Re: What’s the use for Standards-Version?

[Josselin Mouette]

Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit :
  AIUI, this header is here to indicate which version of the policy the
  package is supposed to conform to. This way, we have a way to enforce
  which policy versions are supported, e.g. in a stable release, by
  forbidding the too old versions.
 
 No, that is wrong. The reason we put in the Standards version is
  to let the next developer know what to look for in the upgrading
  checklist in policy in order to bring the package up to date with policy

This assumes that the previous developer has correctly updated the
package according to the stated Standards version. Which is, in the
general case, wrong.

This also assumes that the upgrading checklist contains all relevant
information, which is also wrong for real cases.

If you want to bring a random package up-to-date with the policy, it is
generally more useful to look at its RC bugs, and also at its other
bugs.

Said otherwise, with the current state of our practice, the workflow you
describe is flawed. Which makes the standards version declaration
useless.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: What’s the use for Standards-Version?

[Josselin Mouette]

Le mercredi 12 août 2009 à 11:06 -0400, Neil Roeth a écrit : 
 I've had some packages for years during which policy was changed and required
 corresponding changes in my packages. In that case, the previous developer
 was me, so I'm pretty confident that the previous developer did at least as
 good a job as the current developer. :-)
 
 Your statement is a broad indictment of your fellow DDs as incompetent
 developers who cannot perform the simple task of reading a few lines of policy
 changes and determine if they imply any required changes for their packages.
 Oh, well, it's your life, make all the enemies you want.

When you only work on 6 packages for which you do a pretty good job, you
tend to assume that other packages in the archive are maintained the
same way. Well here’s a scoop, a lot of packages in the archive belong
to maintainers with hundreds of them in their hands, whether alone or in
teams. Not all packages can receive the level of attention you are
expecting.

Try going through large parts of the archive when you need to test a
change, for example. You may be surprised with the overall quality
you’ll meet. After that, you may change your mind about expecting a
declarative field to be conformant with the rest of the packaging.

Heck, I wouldn’t even trust *myself* to do that correctly. Bumping the
standards version is a boring task I have to do so much that I never
bother to have a look at the upgrading checklist, except for the most
complex packages.

  This also assumes that the upgrading checklist contains all relevant
   information, which is also wrong for real cases.
 
 Even if it contains most of the relevant information, it is useful.  If there
 is something missing, that's when someone filing a bug can be a backup.
 No need to throw out the baby with the bath water.
 
 BTW, I just glanced at the debian-policy bug page and see none related to the
 upgrading checklist.  Can you provide some bug numbers of those real cases
 of missing information so I can check my packages?  No hurry, if you've just
 neglected to file them, do that first, then let me know.  Thanks.

I’m not implying the upgrading checklist itself is incomplete. But there
are other things in Debian than following the policy, you know? Most of
the changes needed in packages are not here because of changes in the
policy itself, but because of changes in other packages: packaging
helpers, toolchain, menu system, various pieces of low-level plumbing
that upstream redesigns every other month… these are the things that
require attention. Not looking at whether the package is using the
Speedo fonts.

 If there are current bugs, sure, you should attack those first. But you're
 making a stronger argument that because the workflow is not bulletproof, that
 invalidates the whole process and it should be discarded.  I disagree, I find
 it very useful and hope we keep it.

It may be useful for you, but it is being an annoyance for others. The
suitable thing to do in such cases would be to make the field optional.
Would that be OK?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: What’s the use for Standards-Version?

[Josselin Mouette]

Le mercredi 12 août 2009 à 14:17 -0400, Neil Roeth a écrit :
 If people don't have time to handle all their packages properly, they should
 reduce the number of packages they maintain.

I’ve seen this kind of arguments again and again, and every time it
looks more stupid to me. If you don’t have anything more interesting to
say, maybe you could consider shutting up.

It’s easy to try teaching lessons, but how about a reality check? Most
Debian developers are interested only in maintaining their pet package,
not in belonging to core teams. If what you suggest is that core teams
should abandon their packages, you can immediately start looking for a
new operating system.

 I suspect you are right, the general quality might not be up to my standards.
 However, as Manoj said, we did all sign up to maintain packages that conform
 to policy, and I think the problem you are describing is with some DDs not
 living up to their commitment rather than with the current process.

I signed up to produce the best operating system possible. And
unfortunately it doesn’t seem possible to do it with a 100 packages
archive.

 Removing
 this just makes it easier for people to be sloppy, shift work onto someone
 else, and pretend they are living up to that commitment.

Or maybe that makes it easier for people to shift work onto something
more useful.

 Why would you bump the standards version without actually checking to see if
 the package meets that standard?  That's worse than leaving it as it was.  I
 trust myself to make a conscientious effort to do it correctly if I choose to
 do it at all, but I no longer trust you.

I’m glad to learn that I can trust you to correctly put numbers in your
control files.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
 Hmm. I see very little benefit here. Firstly, to use build id,
  you have to intercept the upstream build system and add --build-id
  (and perhaps the --build-id-style) option to ld, instead of the current
  method of letting the upstream build happen and working on the produced
  objects -- this is more intrusive.  And what do we gain?

Without build IDs, GDB has no sure way to map the binary to the correct
detached symbols. Therefore it will read the whole file to compute its
CRC32 (!) and compare it to the one stored in the gnu_debuglink section
of the binary.

This sole issue is responsible for gdb taking up to several minutes to
produce a backtrace for binaries using big libraries like xulrunner. And
don’t even think of using the debugging symbols over the network in this
case.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
 Except you have not indicated how you (or debhelper) is going to
  intercept ld to add the requisite arguments.

http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 10:39 -0500, Manoj Srivastava a écrit :
 However, if you do not use the build-id mechanism, and use what
  we currently use in dh_strip and friends, objcopy --add-gnu-debuglink
  adds information that gdb looks at to figure out where the debug
  symbols live -- and no CRC check sum is ever performed. 

As I explained, the CRC checksum is performed unconditionally when the
gnu_debuglink mechanism is used.

 Given the difficulty in intercepting ld commands in upstream
  build systems, I would  be inclined to just standardize the debug link
  method, given that it produces human readable file names (so I can
  determine manually if I have debugging symbols for some library or
  not) as an added bonus. 

Providing a script looking at the build-id and telling whether the
debugging symbols are installed is a matter of a few lines of shell
code.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
 * These packages are normal Debian packages with normal package metadata,
   but will generally have a symlink in /usr/share/doc/package pointing
   to the package for which they provide debugging information.

Actually I don’t see the point in this symlink. It only makes things
more complicated, especially if there is no one-to-one mapping between
ddebs and debs.

 Open questions:
 
 * Can we limit this package namespace to *only* detached debugging
   symbols, not all the other sorts of debugging packages that people
   create with special compiler options or optional code features?

I think we should. The purpose of the proposal is to automate as much as
possible, not to open a new section where anyone can dump anything.

 * What about contrib and non-free packages?  Do they just lose here?

How about yes?

 * Can we require a one-to-one correspondance between binary package names
   and debug package names that provide symbols for that binary package?  I
   think we should; I think it would make the system more straightforward.

If we use build IDs (and this has quite some advantages, like being able
to do more than just dump the ddebs on a repository), this can lead to
having the same detached debugging symbols in two binary packages, since
sometimes a binary is built twice the same exact way and put in two
different binary packages. Using a single ddeb for the source package
avoids such issues. Alternatives imply to generate automatically lots of
Replaces and Conflicts fields, and this is just too fragile.

The consensus on #debian-dak when we discussed this specific issue was
to use one ddeb for each source package by default, and to let the door
open to the maintainer overriding this default with several ddebs in a
source, using a new header in the control file. This way we can keep
things as simple as possible, without losing the possibility to handle
corner cases that will arise.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit :
  Actually I don’t see the point in this symlink. It only makes things
  more complicated, especially if there is no one-to-one mapping between
  ddebs and debs.
 
 Without the symlink, they're not valid Debian packages.  It seems like a
 small price to pay for keeping them consistent with the rest of Policy.

The policy is just a document. The question is more about what this
symlink would bring.

BTW, udebs don’t have a /usr/share/doc directory, so that makes a
precedent.

  If we use build IDs (and this has quite some advantages, like being able
  to do more than just dump the ddebs on a repository), this can lead to
  having the same detached debugging symbols in two binary packages, since
  sometimes a binary is built twice the same exact way and put in two
  different binary packages.
 
 Hm, really?  The toolchains that I'm familiar with basically never produce
 the same binary twice; something is always slightly different from
 timestamp information.  Could you give an example of such a case in the
 archive right now where identical binaries are in multiple packages so
 that I can better understand how this happens?

ISTR seeing this with evince/evince-gtk before the plugins were put in a
single package for both versions. Anyway I’ll let Emilio answer since he
did some testing about that specific issue.

  The consensus on #debian-dak when we discussed this specific issue was
  to use one ddeb for each source package by default, and to let the door
  open to the maintainer overriding this default with several ddebs in a
  source, using a new header in the control file. This way we can keep
  things as simple as possible, without losing the possibility to handle
  corner cases that will arise.
 
 In this case, I believe that, in order to comply with some of our
 DFSG-free licenses, we will have to ship a copyright file in the debug
 package.

I’m not sure of what is necessary here. How do we deal with that
specific issue in udebs?

 Also, some source packages are *huge*, and I don't want to have to install
 50GB of debugging information for, say, all of KDE just because I want the
 debugging symbols for a single library.  I suppose that's why you have the
 escape clause of letting maintainers do it differently if they desire, but
 there I really would like to see us treat the entire archive identically
 if at all possible.

The main purpose of setting up an archive of debugging symbols is to be
able to use them transparently without installation, so that doesn’t
change much.

That said, it’s clearly a good reason to allow splitting ddebs manually
at the maintainer’s discretion for some of the largest packages.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 17:26 -0700, Russ Allbery a écrit :
  The main purpose of setting up an archive of debugging symbols is to be
  able to use them transparently without installation, so that doesn’t
  change much.
 
 I don't understand how what you say is related to what I said.  How does
 having them in a separate archive affect whether or not I have to download
 a 50GB package to get debugging symbols for KDE?  Whether that download
 happens automatically or not, it's still a serious issue for some network
 bandwidth profiles.

By transparently, I mean without having to download the whole packages.
Most of our users wouldn’t have the bandwidth to debug KDE or GNOME
packages otherwise.

  That said, it’s clearly a good reason to allow splitting ddebs manually
  at the maintainer’s discretion for some of the largest packages.
 
 Or using one debugging package per binary package by default, which
 provides a level of granularity that makes this just not an issue.

And creates other issues.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: dash as default /bin/sh and bashisms-free archive RGs

[Josselin Mouette]

Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
 So, no, policy does not just document current practice. Policy
  tries to document what is right.

I think it should be both. When we do things right, they should be
specified in the Policy, and there’s no point specifying what is right
if nothing implements it.

-- 
 .''`.  Debian 5.0 “Lenny” has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he’d melt your brain.


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

Bug#484656: gnome, kde, xfce use non-policy main menu

[Josselin Mouette]

Le lundi 07 juillet 2008 à 02:48 -0400, Daniel Dickinson a écrit : 
 And depends on the package maintainer being cooperative.  Because there
 is no debian policy on this if a package maintainer disagrees they
 don't have to hide their menu entry.

Yes, that’s probably the most important issue with the current
situation; nothing prevents the Java maintainer from adding a useless
Java policy tool icon in the Preferences menu, even though it has
nothing to do with the preferences and no one except a small number of
professional Java developers will have anything to do with it.

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


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

Re: gnome, kde, xfce use non-policy main menu

[Josselin Mouette]

Le samedi 05 juillet 2008 à 02:42 -0400, Daniel Dickinson a écrit :
 Gnome, KDE, and XFCE are the the top three desktops used in debian and
 cover most users of desktops in debian.
 
 They all use xdg .desktop-based menus as their main menu.

The last time this discussion was raised up, the clear consensus was
that, at least for the GNOME menu, the primary goals of the xdg-based
menu system and those of the Debian menu are fundamentally different.
The GNOME menu is aimed towards usability, and the Debian menu is aimed
towards completeness. Given the capabilities of the GNOME panel (for
which adding submenus is neither easy nor efficient in terms of
usability), the limitations of the XDG system (for which it is not
possible to define “views” including or excluding some categories) and
the restrictions of the Debian menu system (no i18n support, 32x32 XPM
icons, strict hierarchy), these goals are simply not compatible.

Therefore, I still feel that, despite it being a big mess, the current
situation is the best:
  * the default menu contains only what is needed, and we are still
hunting down entries that are useless to make them not show up
by default;
  * users wanting the Debian menu and its gazillions of entries
including window managers, terminal emulators and shell
interpreters can enable it easily in the menu editor;
  * those really wanting only the Debian menu can replace
gnome-applications.menu by debian-menu.menu.

If you want this to change, you need to seriously think about evolutions
to both XDG and Debian menu systems, to convince fd.o and the Debian
menu maintainer to implement them, and to find a good way to present
them in a nice way in the main menu and in a menu editor. None of these
tasks are simple.

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


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

Re: First draft of review of policy must usage

[Josselin Mouette]

Le mercredi 25 octobre 2006 à 01:03 -0500, Manoj Srivastava a écrit :
 Here is a first draft of changes to the policy that I think
  are required to bring ot closer in line with extant practice. I
  removed portions from the policy that linked policy violations to bug
  severities, since this has been deemed controversial and a bug in
  policy.  Next, I removed the DFSG text and replaced it by a pointer
  to the DFSG document itself, this prevents duplication, and I am not
  sure I would have remembered to edit it here if we ever changed the
  DFSG.

FWIW, I strongly disagree with these changes. The solution is to bring
the release policy in line with the real policy, not the opposite.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom