Bug#741573: Proposed draft of ballot to resolve menu/desktop question
On Friday 28 August 2015 19:58:02 Matthew Vernon wrote: That's not much comfort to folk like me who use the trad menu (I'm an FVWM user) - you're proposing getting rid of something that currently works, and leaving nothing to replace it with. https://wiki.archlinux.org/index.php/Xdg-menu There. something to replace it with. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
On Thursday 27 August 2015 18:11:56 Ian Jackson wrote: So the real dispute is: should the existing application metadata database (currently represented by the Debian trad menu files in existing packages): (a) continue to be maintained in its existing file format (b) be translated to a new and more modern file format (perhaps only for some packages) (c) be destroyed. Given that there are people who want to maintain it, I think (c) is unacceptable.[1] Unfortunately, the people who wants to maintain it are not the same people who has to carry the maintenance work (shipping, checking, fixing and managing the menu files across the packages of the distribution, which is why a) is unacceptable. I haven't seen anyone interested in working on tooling[1] to accomplish b) which leaves just c) as a possibility. Personally, I'd rather throw away work made by people in the past, than having people in the current and in the future keep wasting time. /Sune [1] Except the desktop2menu tool that I wrote eons ago that creates a good starting point for creating a menu file, but needs quite some work to be used on a automatic archive wide scale. I'd also suggest people to start off from Arch's xdg-menu that has been linked multiple times as a starting ground to build a menu for the window managers targetting advanced users. -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
On Wednesday 19 August 2015 10:57:43 Sam Hartman wrote: Don == Don Armstrong d...@debian.org writes: While we're not overturning anything in the sense of an override here, I think we owe an explanation for our actions, and I feel really strongly about that. Don Ideally the patch and its rationale should stand alone without Don the need for a separate text. But that said, if you disagree Don that the rationale is not sufficient once it exists, I'll Don either try to modify it or draft a separate text. No, a rationale that explains why option D is better than A/B is all I'm asking for. From my technical POV I think Option D is better than A/B because it is a more clear technical solution, and saying there is one menu to care about The current A/B thing ended up as a standard compromise that tries to leave everyone equally unhappy, and ending everyone having to decide for them selves which menus to cater for. I don't think A/B is a particular good solution but is immensely better than doing nothing. Option D is what I was hoping for we would end up with in some years after letting the debian menu bitrot for another couple of years. In option D4, I'd though like if Debian Desktop or similar was involved, as it is likely the debian desktop maintainers (XFCE, Plasma, Gnome, LX(DE|Qt), ..) who are closest to the users in this regard. From my social POV I'd love to see B win because I really think that there was a good enough consensus to be able to move on with issues like that. If we hadn't had the double-role of menu maintainer and policy editor, I'm pretty sure we wouldn't have gotten here in the first place. But as Debian is a technical project consisting of social individuals, I would hope to see DBAZC as the final result. /Sune - the one who initiated this mess
Bug#741573: #741573: Menu Policy and Consensus
On Monday 20 July 2015 17:14:03 Josselin Mouette wrote: 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. Seconded. The debian menu is de facto dead; it is time to put it out of its misery. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16337487.0xHqSnfGRR@dabney
Bug#741573: Two menu systems
On Monday 30 June 2014 23:23:53 Russ Allbery wrote: Isn't this the tool that Sune wrote and mentioned earlier in this bug as being incomplete and primarily useful for generating a template that requires subsequent work? Correct. The primary issue is that there isn't a 1:1 mapping between all categories. I don't exactly remember the exact categories, but an example could be that the debian menu format generally have a 'game' category, whereas the desktop file based spec has a hierarchy of game categories, where the top level should be empty. by looking in the desktop2menu script in the giant mapping table for !WARN should show where the mapping can't be done, or there are no good actual match. There is also, iirc, a couple of other oddities here and there that says I wouldn't want to use it in a automatic fashion. I do think that arch's XdgMenu package is a much better approach for getting a xdg-based menu into various window managers, but it should really be maintained by someone in debian who has a use for it. (that will likely exclude Plasma users like me and Gnome users like Joss) /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1794155.5SJxHvWaiY@dabney
Bug#741573: Two menu systems
On Thursday 10 April 2014 14:06:11 Ian Jackson wrote:
Has anyone described any actual difficulties with supporting the
traditional menu ?
I am in the uploaders field of packages that probably requires 300 menu files
to
be available and of one consumer of menus.
if it takes 5 minutes to write a menu file and 5 minutes to switch to one of
those 'old style' window managers and test that it shows up as it should, it
is 3000 minutes. Or 1 hour per week in a year. And I guess that on some
uploads, it should be tested again that it still shows up as it should. if
that happens once pr year pr package, it is 30 minutes pr week pr year.
Isn't that time better spent elsewhere?
From the 'consumer' point of view. I have been of the opinion that as long as
the Debian menu is *the* thing documented in the policy, consumers should
display the Debian menu. I even at one point put my time where my mouth was
and wrote the desktop2menu tool available in devscripts to help the Debian
menu.
But for various reasons[0], I don't think the Debian Menu is the thing to show
to most users. And we should get policy fixed to allow this, which is why I
filed the initial bug+patch that later actually got consensus thru the normal
policy process, and was heading into the policy until Bill Allombert short
circuited the policy process in order to defend his kingdom.
And if one shouldn't 'consume' the menu, why should one provide data for it?
[2]
No. It is not difficult. It is just work. And give a bad experience to users.
And once again, I'll link to the tool by Arch that builds menus based upon the
.desktop files that fits in many 'old style' window managers.
https://wiki.archlinux.org/index.php/Xdg-menu
/Sune
[0]
- it is ugly (see the icon format subthread, for example)
- it duplicates the entries already provided by the desktop files
- the menu-xdg package generates categories that icon themes doesn't have
icons for and the menu-xdg maintainer refuses to fix it
- it contains useless entries for many things that helps hiding what you look
for [1]
- having two similar menu structures is confusing.
[1] Shells and interactive interpreters and such.
[2] afaik, the gnome maintainers have added code to the gnome menu building
thing that does foreach desktopfile in desktopfiles {
if(!desktopfile.path.contains(menu-xdg)) addtomenu(desktopfile); }
I am planning something similar for the kdelibs menu building code.
--
I didn’t stop pretending when I became an adult, it’s just that when I was a
kid I was pretending that I fit into the rules and structures of this world.
And now that I’m an adult, I pretend that those rules and structures exist.
- zefrank
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1641684.ANP4CvevnD@dabney
Bug#741573: Two menu systems
Hi I think there is a couple of facts that aren't fully accurate. I'll try to mention them here. I'll try to keep opinions out of this mail. On Tuesday 08 April 2014 18:30:26 Ian Jackson wrote: Consumers: The trad menu is already consumable by a very wide range of window managers etc.; the desktop menu is consumed primarily by desktop environments. Note that a very wide range of window managers neither supports the trad. menu nor the desktop menu, but has a series of scripts to modify one or the other into their native format. In Debian, most of these window managers only has the scripts for the trad. menu, while the rest of the internet have the scripts that uses the desktop menu. Both menu systems have sufficient supporters and users that they are independently viable projects. Some people will say that the trad menu is dead and no-one uses it, but that's clearly not true. Consider the package http://qa.debian.org/popcon.php?package=menu-xdg which provides a view of the trad menu in desktop system which supports the desktop (XDG) menus. Note that the KDE Desktop task until earlier this year did install menu-xdg, and still does it, and the Gnome and XFCE desktops tasks also installed it at one point, so these numbers aren't fully usable. But if a maintainer wants (for example) to generate a trad menu file from an desktop file, then that's fine. BUT this is ONLY PROVIDED that the generated trad menu file is properly confirming to the trad menu specification and has the descriptive text, categorisation, etc., preferred by the trad menu maintainers. As the author of desktop2menu, I can tell that in some cases it is possible to generate it, but in the general case it is not possible to use autogeneration. It is - like the help2man script - good to create a template. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1526750.DoECLEscW5@dabney
Bug#727708: init system other points, and conclusion
On Thursday 02 January 2014 14:27:14 Steve Langasek wrote: For several years the GNOME Team ignored section 9.7 of Policy, concerning integration with the MIME handling system. They did this in favor of implementing the related freedesktop.org on the grounds that the fd.o standard is technically superior (and less work, since it was already implemented upstream). Normally my interactions with the GNOME Team is friendly mockery. But sometimes one has to stand up next to them. I've ignored the mime handling system as a part of the KDE Team. I've ignored the menu system as a part of the KDE Team. And I have a plan to even more aggressively ignore it (as in, hide it from the menu). Both things are ancient relics that should have been dealt with by removal. I tried bring the latter thru the policy process, but given one of the few people who cares strongly about the debian menu is also a policy delegate, it is just a uphill battle and much easier to just move on. But if the members of the TC do *not* think this is true - if, indeed, our collective preference is for upstart rather than for systemd - then I don't think we should be swayed by assertions that GNOME upstream is tethering itself to a specific init system It is not only GNOME upstream that is heading towards systemd as the way to do things. It is also where stuff is heading in KDE land. /Sune -- Genius, I'm not able to cancel the mousepad of a SIMM, how does it work? The point is that you neither can ever explore the analogic program, nor have to ping a printer for saving the SCSI gadget on a proxy over a parallel button. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739372.uNbplAbK6r@dabney
Bug#727708: systemd (security) bugs (was: init system question)
On Thursday 28 November 2013 13:43:27 Ian Jackson wrote: CVE summary Debian BTS Redhat 2012-0871 systemd-logind insecure file creation ? 795853 Furthermore, I think it is fair to look at bugs in non-pid-1 parts of the systemd codebase when assessing the likely code quality of the pid 1 parts. Note that the non-pid1-parts of systemd, like logind for example, are pieces we need no matter what init system we choose. The question is more if we can use them as provided by upstream or we need to adapt them in Debian. /Sune -- How to close the space bar? First from the control drawer inside Office 8.7.5 you should ping the site of the controller for logging on a BIOS. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2842538.jK1El20Jv4@dabney
Bug#727708: systemd (security) bugs (was: init system question)
On Sunday 01 December 2013 21:50:49 Ian Jackson wrote: This leads me to a question which I find myself asking, after reading the systemd debate page: If we were to adopt systemd as pid 1, which sections of the systemd source code would we probably want to adopt as well ? Or to put it another way, which other existing programs would be obsoleted ? logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or not a user is sitting on the physical console or logged in. libpam-xdg ensures that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures that a user session actually can be terminated when she logs out. Logind is the most important one, and within a year or two all desktop environments that wants to be slightly more advanced than TWM is going to need it. Even Ubuntu is using logind and is iirc maintained there by Steve Langasek. Consolekit was written by the same people as involved in systemd and is now hopefully getting it right. Consolekit is abandoned upstream a couple of years ago. Libpam-xdg was written by Steve Langasek for Ubuntu and has since been abandoned in in Ubuntu favour of the systemd bits . Beside that, there are among others: the timezoned is ensuring a common way that applications can get notified when the hosts timezone changes. KDE does have something for that that would be obsoleted. I think most other systems requires restart of applications or manual magic in each app. hostnamed is for notifying when hostname changes. KDE does have something for that. I don't know who else. There are more parts, but that's where my research has ended so far. /Sune -- How to cancel a mailer to the proxy from Flash and from the folder inside DOS 97? You must log on a driver to debug a monitor. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2815230.1zOzeelhbH@dabney
Bug#557948: Severity of 557948 and plans for this bug
On Monday 01 March 2010 23:21:37 Don Armstrong wrote: Is there still a request for the ctte to override the maintainer on the severity of this bug? FWICT, Anibal agrees that this is a bug, and currently the only issue is how to best fix both it and #500454. Hi As I consider this issue much more severe than #500454 and it looks like *nothing* has happened. Even a revert would have been better. And at the same time maintainer has a track record of ignoring non-rc bugs. Please override the maintainer. /Sune -- How can I do for unmounting the wordprocessor on the 53X hardware? You must click a kernel in order to insert a hard disk on the SIMM. signature.asc Description: This is a digitally signed message part.
Re: ssmtp severity 557948 normal
(resending to correct address) reassign 557948 ssmtp,tech-ctte thanks On Monday 11 January 2010 22:39:19 Aníbal Monsalve Salazar wrote: package ssmtp severity 557948 normal stop Dear tech-ctte, A while ago, ssmtp started requiring users to be in group:mail to be able to send emails. As mail traditionally is the group (and user) for mail transporting in general, as this is how /var/mail/* is governed. Several users seemed this bug should be at RC severity, but now the maintainer disagrees. I ask you, tech-ctte, please override the maintainer in the following two cases: 1) the severity of bug 557948 should be at a release critical level and 2) ssmtp must not require users to be member of group:mail Thanks in advance /Sune -- How to reset a command prompt? First you neither must reset the pin on the PCI periferic, nor can ever overclock a directory to delete from the terminale to a 6X TCP/IP folder to the monitor. signature.asc Description: This is a digitally signed message part.
