some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
Some suggestions for a Debian .desktop policy[1]: 1) syntax according to freedesktop's Desktop Entry Specification [TODO: always the latest, fix some version and increase that at fixed points?] 2) Name must be a name properly name the program and be unique enough to be useable if multiple programs doing the same are in the menu. 3) Comment, if it exists, must be <...>[2] 4) Categories must be according to freedesktop's Desktop Menu Specification, appendix A [TODO: what version? Always latest?]. 5) Categories must contain applicable KDE,GNOME,GTK,Qt,Motif,Java[3] so that a menu manager cat filter out things not matching the UI look&feel if wanted. 6) A .desktop file is allowed to break above rules if is has a OnlyShownIn limiting it to some environment(s) it belongs to. 7) In case of 6) there must be a .desktop file with the same command and adhering to this policy, unless that command cannot be run (or cannot work) outside this environment[3]. 8) An alternative .desktop as in 7) might have a NotShownIn, otherwise it must not have one. What do you think? Bernhard R. Link [1] As some people always complain about the need to create menu files, let's try to look how .desktop files can get in shape that they might replace menu files in some future. [2] I'm still looking for some definition of what that should look like. I remember many bugs files about those in the past, but no definition but "something like this 3 examples and I recognize it if it is wrong". For example is it imperative? or an infitive clause? or something else? What exactly does "should not be redundant with the values of Name and GenericName" from D-E-S mean? [3] What does Xaw programs use? And what SDL programs? [4] I suggest a lintian warning for this for everything that has not "Applet" or "Settings" in Categories. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420071252.gb20...@pcpool00.mathematik.uni-freiburg.de
Re: [pkg-fso-maint] [Debian] enlightenment
2011/4/14 Sebastian Reichel : > Elementary and e17 are currently not installable in sid. I suggest > to upload the elementary release from experimental to sid and > update the e17 package to a newer snapshot. > > Apart from that it would be nice to get e17 and its dependencies > into testing now that the libs are supposed to be stable. I'm missing updated E17 python bindings as well, to get new Zhone in so that sid is again installable on FreeRunner including phone functionality. That said, Albin has been all too alone in the pkg-e team lately from what I've seen :( Would there be any volunteers to join the pkg-e [1][2]? [1] http://wiki.debian.org/PkgE [2] http://lists.alioth.debian.org/mailman/listinfo/pkg-e-devel In addition to current packages, there is interesting Samsung funded EFL/Webkit [3] available, which is needed to build the promising touch usable Eve browser [4]. These are definitely on my interest list if I suddenly get gifted all free time I need, but I wanted to share these findings in case someone would be interested in advancing the touch usable software in Debian. [3] http://trac.webkit.org/wiki/EFLWebKit [4] http://trac.enlightenment.org/e/wiki/Eve > @pkg-fso: I will upload a new version of intone when the elementary > in unstable is fixed. And likewise for zhone, possibly I could also consider the neon image viewer which is currently only in pkg-fso repository. I think it's still the best touch usable image viewer available for Debian phones. -Timo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinDFhmWVF1oUpNy==zdrue+fr+...@mail.gmail.com
Re: [pkg-fso-maint] [Debian] enlightenment
On 11-04-20 at 10:25am, Timo Jyrinki wrote: > In addition to current packages, there is interesting Samsung funded > EFL/Webkit [3] available, which is needed to build the promising touch > usable Eve browser [4]. These are definitely on my interest list if I > suddenly get gifted all free time I need, but I wanted to share these > findings in case someone would be interested in advancing the touch > usable software in Debian. > > [3] http://trac.webkit.org/wiki/EFLWebKit > [4] http://trac.enlightenment.org/e/wiki/Eve Please file an RFP bugreport for that, and refer to that when requesting packaging help. Regards, - Jonas ...who has followed the FSO list for quite some time but not yet found time to get involved. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
Le mercredi 20 avril 2011 à 09:12 +0200, Bernhard R. Link a écrit : > Some suggestions for a Debian .desktop policy[1]: > > 1) syntax according to freedesktop's Desktop Entry Specification > [TODO: always the latest, fix some version and increase that at > fixed points?] > > 2) Name must be a name properly name the program and be unique enough >to be useable if multiple programs doing the same are in the menu. > > 3) Comment, if it exists, must be <...>[2] > > 4) Categories must be according to freedesktop's Desktop Menu >Specification, appendix A [TODO: what version? Always latest?]. > > 5) Categories must contain applicable KDE,GNOME,GTK,Qt,Motif,Java[3] >so that a menu manager cat filter out things not matching >the UI look&feel if wanted. > > 6) A .desktop file is allowed to break above rules if is has a >OnlyShownIn limiting it to some environment(s) it belongs to. > > 7) In case of 6) there must be a .desktop file with the same >command and adhering to this policy, unless that command cannot >be run (or cannot work) outside this environment[4]. I disagree with this rule. Menus are editable, so if a program is meant for an environment it should not be displayed by default in others. For example, Thunar works perfectly fine outside Xfce, but you don’t want to show it in KDE or GNOME. > 8) An alternative .desktop as in 7) might have a NotShownIn, >otherwise it must not have one. Same here. > What do you think? I would add at least two other rules: If the entry has Terminal=true, it must also have NoDisplay=true. If the program is not useful in the general case and might have been installed as a dependency for something mostly unrelated, it must have NoDisplay=true. The second case is to handle things like sun-java* crap and similar ones. They get installed just because you installed a Java program, but you don’t want them in your menus, you just want the program to work. With NoDisplay=true these entries can be enabled in a menu editor, so that should be enough. > [4] I suggest a lintian warning for this for everything that has not > "Applet" or "Settings" in Categories. Sounds just as useful as the “su-wrapper-not-su-to-root” check - meaning people adding bugs in their uploads just because lintian asked them to. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303287182.4084.56.camel@pi0307572
Re: (Vcs-Upstream-)Git support for uscan?
On 04/19/2011 09:03 AM, Timo Juhani Lindfors wrote: > Evgeni Golov writes: >> We (lindi, liw and me) had just a short discussion in #-devel, that it >> would be nice to have some sort of Vcs-Upstream-* in debian/control > > How many packages are there that are not using a watch file because > upstream does not provide usable tarballs (either no tarballs or they > are behind some changing dynamic web site layout)? > > Would it be a completely silly idea to extend uscan to support git in > addition to HTTP and FTP that it currently supports? And SVN, bzr, hg, CVS, Darcs, did I miss someone? :) This is imho the task of the get-orig-source rule in debian/rules (which needs a generic helper so not everyone has to invent the wheel again, but thats a different topic). Regards Evgeni -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dae97e9.9040...@debian.org
Re: [pkg-fso-maint] [Debian] enlightenment
2011/4/20 Jonas Smedegaard : >> [3] http://trac.webkit.org/wiki/EFLWebKit >> [4] http://trac.enlightenment.org/e/wiki/Eve > > Please file an RFP bugreport for that, and refer to that when requesting > packaging help. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623437 for Eve. Also, it seems EFLWebKit has been merged to webkit.org upstream SVN, so I also filed a wishlist bug about getting that packaged via webkit sources. Thanks, -Timo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTim3TcA531ZKU=wos9as_dhvuct...@mail.gmail.com
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
* Josselin Mouette [110420 10:14]: > > 5) Categories must contain applicable KDE,GNOME,GTK,Qt,Motif,Java[3] > >so that a menu manager cat filter out things not matching > >the UI look&feel if wanted. > > > > 6) A .desktop file is allowed to break above rules if is has a > >OnlyShownIn limiting it to some environment(s) it belongs to. > > > > 7) In case of 6) there must be a .desktop file with the same > >command and adhering to this policy, unless that command cannot > >be run (or cannot work) outside this environment[4]. > > I disagree with this rule. Menus are editable, so if a program is meant > for an environment it should not be displayed by default in others. For > example, Thunar works perfectly fine outside Xfce, but you don’t want to > show it in KDE or GNOME. The point of that rule is that some classic Window Manager[1] should have all the installed programs available with sensible names. Such users prefer to use whatever program is best suited for the task and not the one looking in a specific way, so one wants to have all available. If one menu provider does want to limit that, it should offer some option to hide things without the right KDE/GNOME/GTK/Qt/Motif/Java Categories. > If the entry has Terminal=true, it must also have > NoDisplay=true. Again, that should be an option in the menu provider. If the point is of hiding programs with an user-interface you do not like, that is the job of the environment not wanting those. (Especially as other providers cannot know when NoDisplay means "only for mime type handling" and when it is "deemed to ugly by someone"). Bernhard R. Link [1] I mean something like "legacy X Session" in newspeak. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420083742.ga20...@pcpool00.mathematik.uni-freiburg.de
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Wed, 20 Apr 2011 09:12:52 +0200 "Bernhard R. Link" wrote: > Some suggestions for a Debian .desktop policy[1]: Do we actually need one? lintian makes a fairly decent job of this currently and I have yet to see any specific examples of where desktop files are a "joke" or not "in shape". (As long as the judgement is made without undue pedantry.) > 1) syntax according to freedesktop's Desktop Entry Specification .. as validated by the desktop-file-validate utility, as used by lintian. > 2) Name must be a name properly name the program and be unique enough >to be usable if multiple programs doing the same are in the menu. 2) Name can be the program name or a short alternative which describes the function of the program, perhaps to make it easier to see why the program name is what it is. 3) Comments should be used to describe the function of the program so that users who are unfamiliar with the program name will be able to understand how the program can help them achieve tasks or partake in an activity. Comments should aim to distinguish the program from similar programs which may appear in the same menu category. Either the Name or the Comment can match parts of the apt-cache description, if the package only contains a single desktop file. e.g. ddd is useless as a Name. Data Display Debugger is OK as a Name, particularly as the comment is "Graphical debugger frontend". There is absolutely no point in Policy mandating that this has to be: Name: ddd Comment: The Data Display Debugger, a graphical debugger frontend (strings taken from the apt-cache Description (short)) It isn't worth arguing that the Name must be a program name (e.g. on the basis that this would make it easier to manage packages) because there is no direct link between the executable name and the binary package name, especially when one package provides multiple executables. It's probably easier to recommend that either the desktop Name or the Comment should be similar to the apt-cache short description, or for packages with multiple .desktop files, similar to parts of the long description. lintian can check this, possibly with a lower certainty than the other tests but that is fully appropriate IMHO. > 4) Categories must be according to freedesktop's Desktop Menu >Specification, appendix A [TODO: what version? Always latest?]. Good practice to have a version but AFAICT it hasn't changed substantially since I started referencing it. We have tools to do the rest. > [1] As some people always complain about the need to create menu files, > let's try to look how .desktop files can get in shape that they might > replace menu files in some future. Have you examples of desktop files which are not "in shape" currently? I complain about creating a menu file because a desktop file is just so much more helpful and useful. I've never had a bug report or comment about the content of a menu file - I have had helpful suggestions on improving desktop files as well as interest from translators (to translate the entirety of the program) simply because the desktop file contents caught their eye. I'm going to start dropping debian/menu files from my packages henceforth. > [2] I'm still looking for some definition of what that should look like. > I remember many bugs files about those in the past, but no > definition but "something like this 3 examples and I recognize it if > it is wrong". For example is it imperative? or an infitive clause? > or something else? What exactly does "should not be redundant with > the values of Name and GenericName" from D-E-S mean? Do we need to specify imperative or just leave it as descriptive? It's a comment, it's meant to be helpful and relevant to users and the kinds of tasks and activities which users would be expected to want to achieve. "should not be redundant" expresses that the comment should provide additional descriptive content beyond just the program name. So if the Name is "Contacts", the Comment can be "Address book" but it shouldn't just be "Manage contacts". Policy doesn't need to stipulate that the comment needs to be "Add, update, delete and export entries from your address book which is also accessible via Evolution" but it might be improved to "Manage your address book" or similar - that should be a wishlist bug, not a stipulation of Policy. Just because it's Policy does not mean that every last minutiae has to be precisely and uniquely referenced. There is absolutely no need for Policy to stipulate whether a verb is necessary and other such nonsense. We have enough problems with that level of pedantry with the apt cache Descriptions. Let it breathe. > [3] What does Xaw programs use? And what SDL programs? > > [4] I suggest a lintian warning for this for everything that has not > "Applet" or "Settings" in Categories. If we're going to bother with this at all, then most of the above must have *must* downgraded to *should*. At no point must men
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Wed, Apr 20, 2011 at 4:47 PM, Neil Williams wrote: > .. as validated by the desktop-file-validate utility, as used by > lintian. desktop-file-validate is not used by lintian, perhaps there should be a test similar to the man-db test though. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinurpscjzkzqareqlswcqs25zg...@mail.gmail.com
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On 2011-04-20, Neil Williams wrote: > e.g. ddd is useless as a Name. Data Display Debugger is OK as a Name, > particularly as the comment is "Graphical debugger frontend".=20 what is the name of that app? is it 'ddd' or 'Data Display Debugger'? Graphical debugger frontend should be in GenericName, not in Comment. GenericName is the ... Joe Average friendly name for the application. Name=LibreOffice Writer GenericName=Word Processor or something like that. Name should of course not be the executable name, but the actual name of the application. > I'd prefer to simply delete the Debian Menu Policy and let lintian > and the BTS manage the desktop files. > > One less Policy document would be a net win for Debian. Sounds like a good idea. I think we should actually try to investigate how different 'menus' is using the desktop entries. KDE Plasma Desktop, default kickoff menu: prefers to show GenericName, falls back to Name. When hovered, a gray version of Name is showed, if this is different from what's showed already KDE Plasma Desktop, classic menu: Shows Name (GenericName), or just Name, if they are the same KDE Plasma Netbook: Shows Name. I haven't (as a user) found any where where the Comment is shown in the above menus. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniqt9hu.p7v.nos...@sshway.ssh.pusling.com
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Wed, 20 Apr 2011 at 09:24:14 +, Sune Vuorela wrote: > I think we should actually try to investigate how different 'menus' is > using the desktop entries. GNOME Shell: displays only Name in the applications menu; displays only Name when you hover over "favourite" apps in the dock; type-ahead search appears to look in the Name and the Comment but not the GenericName. For those interested in investigating different desktops' menus, Ekiga in unstable makes a good test-case (although probably not a great example of doing menu entries right), because all its strings are different: .desktop: Name=Ekiga Softphone GenericName=IP Telephony, VoIP and Video Conferencing Comment=Talk to people over the Internet .menu: title="Ekiga" \ longtitle="Ekiga: Free Your Speech" \ description="The Ekiga Voice and Video Over IP Suite" \ Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420094552.ga18...@reptile.pseudorandom.co.uk
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
* Neil Williams [110420 10:47]: > Have you examples of desktop files which are not "in shape" currently? Well, for example currently in squeeze there is /usr/share/menu/evince: ?package(evince):needs="X11" section="Applications/Viewers"\ title="Evince" command="/usr/bin/evince"\ hints="Documents,GNOME" icon="/usr/share/pixmaps/evince.xpm" but the only .desktop for it has Name=Document Viewer GenericName=Document Viewer Comment=View multi-page documents and even NoDisplay=true So switching from menu to .desktop would remove classic WM users a way to start it. There is nautilus.menu ?package(nautilus):needs="X11" section="Applications/File Management" \ title="Nautilus" command="/usr/bin/nautilus" icon="/usr/share/pixmaps/nautilus.xpm" but all .desktop files with nautilus in it have OnlyShowIn=GNOME; so this would not longer be startable. > > 2) Name must be a name properly name the program and be unique enough > >to be usable if multiple programs doing the same are in the menu. > > 2) Name can be the program name or a short alternative which describes > the function of the program, perhaps to make it easier to see why the > program name is what it is. That sounds better. > 3) Comments should be used to describe the function of the program so > that users who are unfamiliar with the program name will be able to > understand how the program can help them achieve tasks or partake in an > activity. Comments should aim to distinguish the program from similar > programs which may appear in the same menu category. Anything about the way this is expressed? I've had gotten (and sent upstream) bug reports to change Comment=A tetris like game with many levels to Comment=Play a tetris like game with many levels So perhaps it might make sense to include anything about that to avoid any rewriting later. > There is absolutely no point in Policy mandating that this has to be: > > Name: ddd > Comment: The Data Display Debugger, a graphical debugger frontend > It isn't worth arguing that the Name must be a program name (e.g. on the > basis that this would make it easier to manage packages) because there > is no direct link between the executable name and the binary package > name, especially when one package provides multiple executables. I'd have considered "Data Display Debugger" still the program name. I do not suggest (and did not want to imply) to force the binary's name. > I complain about creating a menu file because a desktop file is just so > much more helpful and useful. I've never had a bug report or comment > about the content of a menu file - I have had helpful suggestions on > improving desktop files as well as interest from translators (to > translate the entirety of the program) simply because the desktop file > contents caught their eye. Well, I'd say most Debian menu users are happy if there is a menu item with the name of the program that starts it and do not want much more, while the desktop file has much more fields that can be changed or translated. > I'm going to start dropping debian/menu files from my packages > henceforth. Is there any reason for this other that you want to piss of users if they do not have the same choice about the window manager as you? Sorry to be a bit harsh about that, but seriously??? > > [2] I'm still looking for some definition of what that should look like. > > I remember many bugs files about those in the past, but no > > definition but "something like this 3 examples and I recognize it if > > it is wrong". For example is it imperative? or an infitive clause? > > or something else? What exactly does "should not be redundant with > > the values of Name and GenericName" from D-E-S mean? > > Do we need to specify imperative or just leave it as descriptive? It's > a comment, it's meant to be helpful and relevant to users and the kinds > of tasks and activities which users would be expected to want to > achieve. > "should not be redundant" expresses that the comment should > provide additional descriptive content beyond just the program name. So > if the Name is "Contacts", the Comment can be "Address book" but it > shouldn't just be "Manage contacts". Policy doesn't need to stipulate > that the comment needs to be "Add, update, delete and export entries > from your address book which is also accessible via Evolution" but it > might be improved to "Manage your address book" or similar - that > should be a wishlist bug, not a stipulation of Policy. I think that point can also be more suggestions than strict policy, but please remember that most upstreams (though not the most prominent upstreams) usually also have not heared much about any conventions for such files, and are often not native speakers. (And more than enough free software developers and DDs (including myself) fail miserably at writing understandable things). > Just because it's Policy does not mean that every last minutiae has to > be precisely and uniquely refer
Re: /run in experimental
On Apr 17, Roger Leigh wrote: > udev 167-2: > - works with /run absent > - broken with /run present and with a tmpfs mounted > (no networking, others have other non-working hardware) Unsurprisingly, it turned out that udev works fine in both cases. But ifupdown breaks if /etc/network/run/ is a symlink to /dev/shm/ (and possibly in other situations yet to be understood), I will open a bug later if nobody beats me to it. > For as yet unstated reasons, the udev maintainer has chosen not to use > a versioned dependency on initscripts, which guarantees /run to be > present and functional, and hence allows it to be used reliably and > unconditionally. For the records, the reason is that so far a dependency has not been proven to be needed. As usual, udev is more complex than people think it is (mostly because we need to support upgrades in many different situations and people want it to support annoying corner cases, let's make it required and it will become much easier to deal with). -- ciao, Marco signature.asc Description: Digital signature
Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
On 04/18/2011 08:47 PM, Steve Langasek wrote: > On Tue, Apr 19, 2011 at 02:14:27AM +0800, Thomas Goirand wrote: >> On 04/18/2011 03:03 PM, Soren Hansen wrote: >>> Making the package lintian [clean] is a great goal! > >> It's not a goal, it's a requirement for any DD before uploading to the >> archive. > > No, it's not. With some exceptions you are able to find here: http://ftp-master.debian.org/static/lintian.tags -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4daeb9b7.4070...@bzed.de
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Wed, 20 Apr 2011 11:46:31 +0200 "Bernhard R. Link" wrote: > * Neil Williams [110420 10:47]: > > Have you examples of desktop files which are not "in shape" currently? > > Well, for example currently in squeeze there is > > /usr/share/menu/evince: > ?package(evince):needs="X11" section="Applications/Viewers"\ > title="Evince" command="/usr/bin/evince"\ > hints="Documents,GNOME" icon="/usr/share/pixmaps/evince.xpm" > > but the only .desktop for it has > > Name=Document Viewer > GenericName=Document Viewer > Comment=View multi-page documents > and even > NoDisplay=true > > So switching from menu to .desktop would remove classic WM users a way > to start it. It generally starts when the user wants to open a file it can support. It's not shown by default in GNOME either but that's the way that upstream and the Debian maintainers want it to run. I've got no problem with that. > There is nautilus.menu > ?package(nautilus):needs="X11" section="Applications/File Management" \ > title="Nautilus" command="/usr/bin/nautilus" > icon="/usr/share/pixmaps/nautilus.xpm" > but all .desktop files with nautilus in it have > OnlyShowIn=GNOME; > > so this would not longer be startable. Would it be any use? Thunar is often a better bet for a non-GNOME environment. Again, within GNOME, nautilus isn't usually started just by running nautilus, users select somewhere to look at in nautilus using the Places menu. Other environments have ways of selecting a Place, like / or ~ if nothing else. These are special cases which are easily explained by their intended use cases and do not need to be hit with the Policy stick. > > 3) Comments should be used to describe the function of the program so > > that users who are unfamiliar with the program name will be able to > > understand how the program can help them achieve tasks or partake in an > > activity. Comments should aim to distinguish the program from similar > > programs which may appear in the same menu category. > > Anything about the way this is expressed? No. Firmly, NO. > I've had gotten (and sent upstream) bug reports to change > Comment=A tetris like game with many levels > to > Comment=Play a tetris like game with many levels I would have probably closed such bug reports. It is useless pedantry to assert that one must be used in favour of the other. There is no substantive difference between the two. What will a user gain from the change? The addition of a verb for some pedantic grammatical rule when the verb itself is implied by the description of the thing as something which is normally played, i.e. a game. Three extra characters, another push upstream, another round of 30 translation updates, 30 bugs in the BTS and a new upstream release. WTF? Or you could just patch it in Debian and lose all the translations for the original string and force the pedantry onto all users who previously had a perfectly serviceable string in their own language. Tell me, is that REALLY a result which Debian aspires to achieve?? I don't know about you but I'm 100% sure I've got a long long list of things to do which are way more important than that kind of change. > So perhaps it might make sense to include anything about that to avoid > any rewriting later. Disagree. It should be much more free form. > > I'm going to start dropping debian/menu files from my packages > > henceforth. > > Is there any reason for this other that you want to piss of users > if they do not have the same choice about the window manager as you? > > Sorry to be a bit harsh about that, but seriously??? Most of the applications concerned are intended for specific environments. I also think you are over-estimating how quickly I get around to uploads for each of my packages - by a factor of about 50. There is no need to delay the implementation of desktop files if we don't waste time creating a special Policy. Abolish the current Menu Policy, let things go through the normal process of improvements driven by lintian - which could include removing debian/menu as a ReleaseGoal for Wheezy. > I think that point can also be more suggestions than strict policy, but > please remember that most upstreams (though not the most prominent upstreams) > usually also have not heared much about any conventions for such files, > and are often not native speakers. (And more than enough free software > developers and DDs (including myself) fail miserably at writing understandable > things). There are mechanisms (inside and outside Debian) for people to ask native English speakers to create the original strings which are then sent to translators before the package is released. Generally, programmers of most kinds shouldn't write the English strings which go out for translation - whether native English speakers or not. It can also be useful if programmers don't spend time creating translations of strings into their own language. Translators who are not programmers generally make a better translation. If t
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
Le mercredi 20 avril 2011 à 10:37 +0200, Bernhard R. Link a écrit : > > > 7) In case of 6) there must be a .desktop file with the same > > >command and adhering to this policy, unless that command cannot > > >be run (or cannot work) outside this environment[4]. > > > > I disagree with this rule. Menus are editable, so if a program is meant > > for an environment it should not be displayed by default in others. For > > example, Thunar works perfectly fine outside Xfce, but you don’t want to > > show it in KDE or GNOME. > > The point of that rule is that some classic Window Manager[1] should > have all the installed programs available with sensible names. > Such users prefer to use whatever program is best suited for the task > and not the one looking in a specific way, so one wants to have all > available. If one menu provider does want to limit that, it should offer > some option to hide things without the right KDE/GNOME/GTK/Qt/Motif/Java > Categories. Are you serious? What kind of filtering rules could be used here? > > If the entry has Terminal=true, it must also have > > NoDisplay=true. > > Again, that should be an option in the menu provider. If the point is of > hiding programs with an user-interface you do not like, that is the job > of the environment not wanting those. (Especially as other providers > cannot know when NoDisplay means "only for mime type handling" and when > it is "deemed to ugly by someone"). It’s not only a problem of ugliness. The #1 usability problem with the Debian menu is the huge amount of entries. If you repeat this mistake with the freedesktop menus, a menu system that has been nice so far (nice, not great) would become almost as crappy as the previous situation. Said otherwise: you’re entitled to improve the situation for crapwm if you want, but if you break GNOME in the process, I don’t see this as a win. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303300707.4084.264.camel@pi0307572
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Wed, April 20, 2011 09:57, Paul Wise wrote: > On Wed, Apr 20, 2011 at 4:47 PM, Neil Williams > wrote: > >> .. as validated by the desktop-file-validate utility, as used by >> lintian. > > desktop-file-validate is not used by lintian, perhaps there should be > a test similar to the man-db test though. fwiw, it has been requested that lintian use d-f-v (#455740) but at least at the time it apparently didn't fit the task properly and no one had enough free time to properly investigate its suitability. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12562632d971f6e48f6623b0c33976d4.squir...@adsl.funky-badger.org
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
Le mercredi 20 avril 2011 à 11:46 +0200, Bernhard R. Link a écrit : > > I'm going to start dropping debian/menu files from my packages > > henceforth. > Sorry to be a bit harsh about that, but seriously??? Yes, seriously. There’s a better use of our time than maintaining menu files and, similarly, mailcap entries. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303301158.4084.275.camel@pi0307572
Bug#623452: ITP: partclone -- Utility to clone and restore a partition
Package: wnpp Severity: wishlist Owner: Georges Khaznadar * Package name: partclone Version : 0.2.22 Upstream Author : Steven Shiau , Jazz Wang , Thomas Tsai * URL : http://partclone.org/ * License : GPL-2+ Programming Lang: C Description : Utility to clone and restore a partition Partclone is a project like the well-known backup utility "Partition Image" a.k.a. partimage. . Partclone provides utilities to back up used blocks and design for highest compatibility with file system using supported libraries like e2fslibs. . check the project website for more details http://partclone.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420121733.2950.97116.report...@photos.khaznadar.fr
Bug#623453: ITP: xdmf -- eXtensible Data Model and Format
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: xdmf Version : 2.1 Upstream Author : Name http://www.xdmf.org/ * License : BSD Programming Lang: C++, Python, Fortran Description : eXtensible Data Model and Format library The need for a standardized method to exchange scientific data between High Performance Computing codes and tools lead to the development of the eXtensible Data Model and Format (XDMF) . Uses for XDMF range from a standard format used by HPC codes to take advantage of widely used visualization programs like ParaView, to a mechanism for performing coupled calculations using multiple, previously stand alone codes. Data format refers to the raw data to be manipulated. Information like number type ( float, integer, etc.), precision, location, rank, and dimensions completely describe the any dataset regardless of its size. The description of the data is also separate from the values themselves. We refer to the description of the data as Light data and the values themselves as Heavy data. Light data is small and can be passed between modules easily. Heavy data may be potentially enormous; movement needs to be kept to a minimum. Due to the different nature of heavy and light data, they are stored using separate mechanisms. Light data is stored using XML, Heavy data is typically stored using HDF5. While we could have chosen to store the light data using HDF5 attributes using XML does not require every tool to have access to the compiled HDF5 libraries in order to perform simple operations. Data model refers to the intended use of the data. For example, a three dimensional array of floating point vales may be the X,Y,Z geometry for a grid or calculated vector values. Without a data model, it is impossible to tell the difference. Since the data model only describes the data, it is purely light data and thus stored using XML. It is targeted at scientific simulation data concentrating on scalars, vectors, and tensors defined on some type of computational grid. Structured and Unstructured grids are described via their topology and geometry. Calculated, time varying data values are described as attributes of the grid. The actual values for the grid geometry, connectivity, and attribute values are contained in the data format. This separation of data format and model allows HPC codes to efficiently produce and store vales in a convenient manner without being encumbered by our data model which may be different from their internal arrangement. XDMF uses XML to store Light data and to describe the data Model. HDF5 is used to store Heavy data. The data Format is stored redundantly in both XML and HDF5. This allows tools to parse XML to determine the resources that will be required to access the Heavy data. XDMF is used in the visualization tools Paraview (already in Debian) and VisIt (which I am packaging). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420122606.2798.85343.report...@ailm.sceal.ie
Re: Bug#623452: ITP: partclone -- Utility to clone and restore a partition
On Wed, Apr 20, 2011 at 14:17:33 (CEST), Georges Khaznadar wrote: > Package: wnpp > Severity: wishlist > Owner: Georges Khaznadar > > > * Package name: partclone > Version : 0.2.22 > Upstream Author : Steven Shiau , > Jazz Wang , > Thomas Tsai > * URL : http://partclone.org/ > * License : GPL-2+ > Programming Lang: C > Description : Utility to clone and restore a partition > > Partclone is a project like the well-known backup utility > "Partition Image" a.k.a. partimage. > . > Partclone provides utilities to back up used blocks and > design for highest compatibility with file system using > supported libraries like e2fslibs. > . > check the project website for more details > http://partclone.org It would be great if the description would include a list of supported filesystems. I immediately wondered if NTFS was supported (it seems it is). -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc41cbyb@faui44a.informatik.uni-erlangen.de
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
* Josselin Mouette [110420 13:59]: > It’s not only a problem of ugliness. The #1 usability problem with the > Debian menu is the huge amount of entries. If you repeat this mistake > with the freedesktop menus, a menu system that has been nice so far > (nice, not great) would become almost as crappy as the previous > situation. I can agree that people can have different opinions and I do not care about what gnome shows by default. But for me having everything in the menu is its most important feature. I do not want to tell every single user "oh, hey there is also this and this and this and this package installed you might need for your job, its just hidden because some thought users in other places most likely do not need to see it by default". (And I am very grateful that I can copy /etc/xdg/menus/debian-menu.menu to /etc/xdg/menus/gnome-menu.menu to also get that menu for users of gnome). > Said otherwise: you’re entitled to improve the situation for crapwm if > you want, but if you break GNOME in the process, I don’t see this as a > win. As long as there are menu files and mailcap files, I'll happy use and let use my users them in all the different "crapWMs". But the discussion is about taking them away. And if those "crapWM"s should use .desktop files then I'll complain and do what I can to get .desktop files useable for that. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420153030.ga22...@pcpool00.mathematik.uni-freiburg.de
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
Le mercredi 20 avril 2011 à 17:30 +0200, Bernhard R. Link a écrit : > But for me having everything in the menu is its most important feature. It’s not a feature. It is a design mistake. If you keep on implementing whatever seems best for *your* use, without any care for usability, you’re going straight into a wall, and all the efforts that have been put into making Debian more usable will be thrown away. There is a place where you can access everything that’s installed on your system: it’s call a shell. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303314156.4084.308.camel@pi0307572
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On 2011-04-20, Josselin Mouette wrote: > Le mercredi 20 avril 2011 à 17:30 +0200, Bernhard R. Link a écrit : >> But for me having everything in the menu is its most important feature. [...] > There is a place where you can access everything that’s installed on > your system: it’s call a shell. The one called "gnome-shell"? SCNR Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniqu310.59r.tr...@kelgar.0x539.de
Re: Bug#623452: ITP: partclone -- Utility to clone and restore a partition
Hi Reinhard, Reinhard Tartler a écrit : > > Partclone is a project like the well-known backup utility > > "Partition Image" a.k.a. partimage. > > It would be great if the description would include a list of supported > filesystems. I immediately wondered if NTFS was supported (it seems it is). The list of supported filesystems includes NTFS. I had to remove support for a series of filesystems, which were supported in the version of partclone published two years ago (and distributed with static embedded libraries), because the relevant development libraries are not part of Debian. Here is the list of filesystems which are *not* supported now: xfs, reiserfs, reiser4, ufs, vmfs, jfs. Supported filesystems are: extfs, hfsp, fat, ntfs, btrfs. Any suggestion to find usable libraries for filesystems which I had to drop is welcome. Best regards, Georges. signature.asc Description: Digital signature
Re: network-manager as default? No!
On Sat, Apr 16, 2011 at 07:40:33PM +0200, Stephan Seitz wrote: > On Fri, Apr 15, 2011 at 03:23:32PM +0200, Josselin Mouette wrote: >>> NM may be good for laptops, so put it in the laptop task and leave the >>> rest alone in the default installation. >> And keep the installer unable to do things as widespread as WPA? >> And keep it unable to generate a proper configuration for laptops? > > How many systems are needing WLAN for installation? > Servers don’t have WLAN, I never have seen a Desktop with WLAN (neither > in companies nor private PCs). I've used a wifi USB NIC in a desktop for years. My circa-2006 desktop machine had it built-in. I've also fallen back to it on machines where I normally use wired, when we've had network switch problems (and our wifi is routed via different switches). Granted, where I have the chance, I will use wired for a static machine. However I've only just renovated my study and ran some Ethernet: for the 18 months before that I relied on wifi. One or two fresh installations in that time required moving the machine, or running temporary cabling. All Mac desktops currently on sale (iMac, Mac Mini, Mac Pro) feature built-in wifi adaptors and we've had to rely on it for one or two of the machines we look after at work when we moved things around and lacked enough cabling for them all. Some friends of mine use it exclusively rather than run cable around their houses. There are other classes of device where it can be essential (some SOHO NAS devices, internet tablets and F/OSS capable mobile phones), although many of those require a custom installation method anyway. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420210752.ga11...@deckard.alcopop.org
Bug#623528: ITP: webdis -- a simple web server providing an HTTP interface to Redis server
Package: wnpp Severity: wishlist Owner: Andriy Senkovych * Package name: webdis Version : 0.1.0 Upstream Author : Nicolas Favre-Felix * URL : https://github.com/nicolasff/webdis * License : BSD Programming Lang: C Description : a simple web server providing an HTTP interface to Redis server A very simple web server providing an HTTP interface to Redis. It uses hiredis, jansson, libevent, and http-parser. Features: * GET and POST are supported, as well as PUT for file uploads. * JSON output by default, optional JSONP parameter (?jsonp=myFunction or ?callback=myFunction). * Raw Redis 2.0 protocol output with .raw suffix * BSON support for compact responses and MongoDB compatibility. * HTTP 1.1 pipelining (70,000 http requests per second on a desktop Linux machine.) * Multi-threaded server, configurable number of worker threads. * WebSocket support (Currently using the “hixie-76” specification). * Connects to Redis using a TCP or UNIX socket. * Restricted commands by IP range (CIDR subnet + mask) or HTTP Basic Auth, returning 403 errors. * Possible Redis authentication in the config file. * Pub/Sub using Transfer-Encoding: chunked, works with JSONP as well. Webdis can be used as a Comet server. * Drop privileges on startup. * Custom Content-Type using a pre-defined file extension, or with ?type=some/thing. * URL-encoded parameters for binary data or slashes. For instance, %2f is decoded as / but not used as a command separator. * Logs, with a configurable verbosity. * Cross-origin requests, usable with XMLHttpRequest2 (Cross-Origin Resource Sharing - CORS). * File upload with PUT. * With the JSON output, the return value of INFO is parsed and transformed into an object. * Optional daemonize. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420225520.18017.60124.reportbug@gamma.trdata.local
Bug#623530: ITP: libouch-perl -- exception handling module
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libouch-perl
Version : 0.0300
Upstream Author : JT Smith
* URL : http://search.cpan.org/dist/Ouch/
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : exception handling module
The Ouch module ("exceptions that don't hurt") provides a class for exception
handling that doesn't require a lot of boilerplate, nor any up front
definition. It is fast, easy to use, requires few typing, and has no prereqs,
but still provides much of that same functionality as e.g. Exception::Class.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110420230027.ga5...@belanna.comodo.priv.at
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Wed, Apr 20, 2011 at 09:47:25AM +0100, Neil Williams wrote: > 3) Comments should be used to describe the function of the program so > that users who are unfamiliar with the program name will be able to > understand how the program can help them achieve tasks or partake in an > activity. Comments should aim to distinguish the program from similar > programs which may appear in the same menu category. > > Either the Name or the Comment can match parts of the apt-cache > description, if the package only contains a single desktop file. > > e.g. ddd is useless as a Name. Data Display Debugger is OK as a Name, > particularly as the comment is "Graphical debugger frontend". > > There is absolutely no point in Policy mandating that this has to be: > > Name: ddd > Comment: The Data Display Debugger, a graphical debugger frontend I know I want to use ddd, and when looking in the menu and shows just "Data Display Debugger" I will miss in the first time and go and look for it at some other place, since I have have no idea that that is what I'm looking for. If I do "apt-get install ddd", I epxect to find "ddd" somewhere in the menu. I will find it very annoying when it says "music player" in the menu without telling me *which* one it is. But for people looking for a music player, they don't care (yet) how it's called, so there probably is also a need have a way to display more than just the name of the application. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420231433.ga20...@roeckx.be
Re: network-manager as default? No!
Hello, On Fri, 15 Apr 2011 15:47:18 +0200 Stig Sandbeck Mathisen wrote: > My major gripe with ifupdown is the lack of CIDR in "address", but I > can live with that. :) ifupdown 0.7 does support CIDR. -- WBR, Andrew signature.asc Description: PGP signature
Re: /run in experimental
Hello, On Wed, 20 Apr 2011 12:37:44 +0200 m...@linux.it (Marco d'Itri) wrote: > > udev 167-2: > > - works with /run absent > > - broken with /run present and with a tmpfs mounted > > (no networking, others have other non-working hardware) > Unsurprisingly, it turned out that udev works fine in both cases. > But ifupdown breaks if /etc/network/run/ is a symlink to /dev/shm/ > (and possibly in other situations yet to be understood), I will open > a bug later if nobody beats me to it. I will :) Well, actually, no. I've ported ifupdown to use /run/network instead of bunch of other variants already, so it's just a matter of time and sponsorship. -- WBR, Andrew signature.asc Description: PGP signature
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
Le jeudi 21 avril 2011 à 01:14 +0200, Kurt Roeckx a écrit : > I will find it very annoying when it says "music player" in the > menu without telling me *which* one it is. > > But for people looking for a music player, they don't care (yet) > how it's called, so there probably is also a need have a way > to display more than just the name of the application. This is the purpose of the GenericName field. Ideally (and I don’t think any menu implementation does it correctly), the menu should show the GenericName if it is unique, and the Name if there are several of the same kind. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
