Bug#502959: general: raff.debian.org uses non-free software
On Tue, 2008-10-21 at 12:45 +0200, Luca Niccoli wrote: > On Tue, Oct 21, 2008 at 11:41 AM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > > > raff.debian.org uses a Compaq Smart 5i RAID card. A flash memory is used > > to store the firmware. While the firmware is freely downloadable (as in > > beer) on HP website [1], we don't have the corresponding source code. This is just getting ludicrous. Can we just keep to the sensible dividing line that code executing on the computer's main CPU, _under_ the operating system (not BIOS / SMI) should be "free" to whatever divined standard. Peripheral hardware isn't designed for you to run arbitrary code on its CPU, and the fact it requires a firmware blob uploading is merely an implementation detail. (GPUs are borderline of course.) Having no source-code for firmware is hardly that different to having a completely open-source driver which does un-told magic by poking un-documented registers in a complex chip. Think Intel graphics before they released documentation for (some of) their chips. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
electronics-menu REJECTED (discussion)
PCB and gerbv, all of which need an Electronics menu pcjc2: We need collaboration with hamradiomenus and any others which would be covered under this (EDIT.. we are talking about two so far, not 1 trillion) pcjc2: Are you going to delete hamradiomenus from the dist, and tell them to fix theirs too? (If not.. I don't see how there is any incentive for them to help with this) Ganneff: im not deleting it, but strongly encourage to move it into the generics menu package, as soon as that starts to live Summary (and my thoughts): Use case... user "apt-get install geda", and finds their electronics applications under "Electronics". Joerg is advocating creating a package "xdg-extra-menus" to gather any possible extra menus which could be installed by the user. I'm concerned about category clashes (duplication of apps), and (IMO) the best way to resolve this is to apt-get remove electronics-menu or engineering-menu (hypothetical) which each deal with one category each, and are suggested by other packages as appropriate. Joerg's suggestion is to install all categories from a single package then provide an application to copy them into /etc/xdg/menus from an admin program (or ~/.config/menus/) for the user-specific configuration case. "pusling" on IRC suggested looking at the a2enmod scripts for examples of how to do this). I am however quite concerned about how applications will by default install where they can be found in menus. No new user will know to run whatever script is required to enable a particular menu, meaning at the they should probably be shipped enabled (they only show if an application has this category anyway). In this case, where applications fall into multiple categories, they will appear multiple times. Will all apps desiring a category specified in "xdg-extra-menus" have to depend on it being installed, or will it be installed by default with the desktop? Should we call it "xdg-..." this isn't from the xdg people.. does that break name-spacing, or mislead about its origins? As an upstream developer for gEDA Electronics CAD software, I don't think that I can create or maintain this... I just know that our users complain about not being able to find our software, and was hoping to provide a solution. Comments? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Generic "extra menus" package (was: Re: electronics-menu REJECTED (discussion))
On Sat, 2008-01-12 at 19:34 +, Peter Clifton wrote: > Joerg is advocating creating a package "xdg-extra-menus" to gather any > possible extra menus which could be installed by the user. I've spent a fair amount of time hacking on this, and have a result.. a package I'm calling "extra-menus" for now (I don't want to namespace starting with xdg-, as it isn't from XDG). This installs what was in my electronics-menu package (that got rejected), and what is currently in the hamradiomenus package. It also ships two scripts, based on a2moden and a2moddis, which I've named: exmenen and exmendis. These allow you to link / unlink the provided extra menus into either a system wide or per-user config. The menus ship on by default, as this appears to be the only sane way for applications to be able to install and "just work" as the user expects. If no apps list a particular category that the menu provides, it doesn't show up.. so little harm is done this way. http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0-1.dsc http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0-1.diff.gz http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0.orig.tar.gz I'd appreciate it if those who were advocating this approach on IRC could check over the package, and see what they think. Do I need an ITP bug to proceed? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generic "extra menus" package (was: Re: electronics-menu REJECTED (discussion))
On Mon, 2008-01-14 at 10:53 +0100, Andreas Tille wrote: > On Sun, 13 Jan 2008, Peter Clifton wrote: > > > http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0-1.dsc > > http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0-1.diff.gz > > http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0.orig.tar.gz > > > > > > I'd appreciate it if those who were advocating this approach on IRC > > could check over the package, and see what they think. > > > > Do I need an ITP bug to proceed? > > Well, I would strongly suggest to verify desktop-profiles before > proceeding in this direction. I don't think that it is productive > to invent something new if there is something that might be serve > perfectly for the purpose. I don't think it serves the purpose, as anything configured by the desktop-profiles would only be done at session startup time. This completely breaks the use-case where: apt-get install Will place the app in the user's expected menu, right away. Referring to your previous email, where you state the "currently used user menu solution is suboptimal because it does not scale", could you clarify what exactly you're meaning there, and just how much scalability you think we might need? If we assume that more than one application group needs to install a menu, using desktop-profiles will introduce an entire extra hierarchy of XDG or KDE structure which must be searched through at run time. (Rather than just one extra .menu file per menu). >From the desktop-profiles manpage: "If two profiles contain the same config file, the one from the profile with the highest precedence is used." You STILL have to use the XDG menu merging mechanism, otherwise the desktop-profile will over-write any "master" applications menu file. The XDG menu spec (although it has _badly_ thought out categories), does has the capability to allow these menus to be installed directly. Requiring a new desktop-profile just to have a schematic editor or other CAD program appear in a sensible place does not seem the way forward. "Ham radio" already uses the XDG "merged" mechanism, and I propose to do the same with "Electronics". Wine uses it too (although has the luxury of being able to "own" its own menu directly - rather than needing a category registered on its behalf). If we also bear in mind that any menus added won't appear unless there are applications installed which list these categories, there is no harm in just installing them (if their numbers are low enough). The original argument from ftp-master was simply that he didn't want to allow lots of small packages to install categories individually, and that they should all be lumped together in one "extra-menus" type package. (+ some option of configuring the installed menus on/off)/ IMO this kind of breaks the point of packaging different things in different packages, especially if we have to provide infrastructure for "sub-package" management locally, ie.. for the user to turn parts of it on / off. My opinion is that we are only discussing how the /etc/xdg/menus/appliactions-merged/*.menus get installed: Is it with one debian package per category / menu someone might want to install, like "hamradiomenus" and my "electronics-menu" package? Is it in one master package such as the "extra-menus" package I have presented, which will aim to collect all such menus across Debian and install them in one hit? (And may provide run-time scripts for the user to add/remove the symlinks as desired). At the moment, we are talking about two packages, with the possibility of some scientific interest groups benefiting from extra categories too. It is not as if we're designing some GNOME API which will be set in stone forever.. we can always change things if it becomes necessary. If some tens of interest groups find their applications don't fit in the normal XDG categories, THEN is the time to worry. Specifically, if the problem DOES scale to such a size, then it is a concern which might need to be addressed with an update to the XDG menu spec. What IS clear, is that sensible defaults must be provided with no more complexity than "apt-get install " . The user mustn't be made to work for their menus. Best wishes -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electronics-menu REJECTED (discussion)
On Mon, 2008-01-14 at 09:43 +0900, Charles Plessy wrote: > Le Sat, Jan 12, 2008 at 07:34:21PM +0000, Peter Clifton a écrit : > > > > In gEDA, the .desktop files list "Electronics" and "Engineering" (both > > of which are sub-categories), and without an additional XML file > > describing a new menu, these applications will appear under "Others" > > under gnome, or lost+found under KDE. > > Dear Peter, > > Do you know how many .desktop files in Debian use the categories > Electronics or Engineering? If there are not enough to nicely populate a > menu, it may be better to patch them to relocate them somewhere else. I currently have six installed, but there are more out there. (There are also more packages which _should_ use this category, but don't.. on account of it not being in the menu hierarchy. Since there are no other categories in the XDG spec which fit, this is really why the problem occurs: "Every conforming desktop environment MUST support" (XDG menu-spec) AudioVideo : NO Audio : NO Video : NO Development (really meaning "programming") : NO Education : NO Game: NO Graphics: NO Network : NO Office : NO Settings: NO System : NO Utility (Small utility application, "Accessories") : NO Clearly the people who wrote the XDG menu spec didn't consider any technical applications: Hydrology GIS (Geographic Information system) Mathematics, e.g. Matlab / Octave (if it had a GUI) / others Mechanical CAD packages Structural analysis Electrical CAD, IC Design etc.. Circuit simulation Also: Hamradio, Knitting, Cave surveying, Physics, Chemistry, Medical imaging, Radar, It is not so likely any one given user will have applications installed which fit into all extra categories, they might have one or two. Noting the above main categories are listed as "MUST support" seems to imply the intention that additional categories (e.g. from the additonal categories list) could be supported by distributions / desktops. Suggesting that any of these should be shoe-horned into the nearest XDG main category or risk not appearing in any menu is only going to cause the XDG system to be further inefficient in meeting users needs. For gEDA, we violate the menu spec and do not list a "main" category, as getting lost under "Other" seems preferable to any of the above categories. > If there are enough, there is a third way of having an optional menu: > the Custom Debian Distribution. In the Debian-Med CDD, we have an extra > "Med" menu, and which user gets it is configured through debconf. I don't think it is advisable to require installing a customised distribution just for a particular task. I happen to use (ok, GNU/)Linux for everyday computing, and believe the way forward is using special-interest meta-packages which could pull in a suite of useful tools for a particular topic. We do produce and give students use a customised Knoppix Live CD with Engineering applications on at University, but for every day Linux users, this is actually a step backwards. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!)
Re: electronics-menu REJECTED (discussion)
On Tue, 2008-01-15 at 08:22 +0900, Charles Plessy wrote: > > Shall I open a wiki page to start the coordination of this ? That sounds like a good idea.. I will contact the SuSE and Fedora people I know packaging Electronics applications. I'd still very much like to get something like "extra-menus" uploaded in Debian though.. as I get the feeling that it will take a reasonable amount of time to get through the XDG (if anything comes of it). If a new XDG spec comes out, and this is implemented by the various Gnome, KDE etc.. packages, then new releases of the "extra" package could be made to cut out implemented portions (with appropriate dependencies on the newer versions of the appropriate spec. implementing packages). > Have a nice day, Likewise, Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
