Bug#532042: ITP: monica -- A monitor calibration tool.
Package: wnpp Severity: wishlist Owner: Octavio Alvarez * Package name: monica Version : 3.7 Upstream Author : As per AUTHORS file: Tilo Riemer (versions to 1.11) Paul Sherman (version 2.0->3.6) Philip Heuer (version 3.6->3.7 patch) * URL : http://www.pcbypaul.com/software/monica.html * License : BSD Programming Lang: C++ Description : A simple monitor calibration tool. Monica is a monitor calibration tool using the FLTK library. It works as frontend to xgamma to alter the gamma correction for XFree86 or Xorg. The black point, gray and color blocks help to find usable settings for a target of 2.2 gamma, the Web and sRGB standard. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Reverting to GNOME for jessie's default desktop
On 09/08/14 04:30, Jonas Smedegaard wrote: > Hi envite, > > Thanks for your input. > > Quoting envite (2014-08-09 10:43:25) >> XFCE (does not mount my USB disks) > > Did you perhaps suppress recommends? Should this really be a Recommends? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53eaa6ce.8020...@alvarezp.ods.org
Re: Reverting to GNOME for jessie's default desktop
On 12/08/14 15:44, Theodore Ts'o wrote: >>> So that's my experience with Xfce and HiDPI displays; at least for >>> this hacker, it was orders of magnitude less painful than dealing with >>> GNOME. :-) >> >> I would appreciate if you went into a little detail on what pain you had >> with GNOME for comparison purposes. > > It's the usual frustrations, that have been aired a million times > before[1]. Struggling with the GNOME equivalent of the Windows Registry, > wanting to use a 2D workspace, struggling as random GNOME extensions > break when GNOME releases a new version, etc., etc., etc. > > [1] http://felipec.wordpress.com/2013/06/12/the-problem-with-gnome-3/ > > Basically, I can be effective and efficient with Xfce. I can't say > the same about GNOME, as a power user. Which is OK, since I'm clearly > not the target audience for the GNOME project. Oh, well I can't agree more, with you and the blog post. I will go further. Xfce does not break a paradigm, it uses less than half the RAM, which allows me to do more things simultaneously and doesn't do unexpected things. Xfce customizability is built in. Under GNOME I have to install a tweaker to make it remotely do what I expect. Over time, GNOME 3 increasingly consumes more RAM. The same happens with X.org. Xfce behavior is definitely not as bad. I've been told this has to do with heap fragmentation but I don't buy it. I don't have numbers but I would think HF to cause 20% of the increasingly-consumed RAM behavior. By default, GNOME 3 hides the notification area from view and only one application button can be seen at a time. One of the most common and important tasks, "application switching", is a two-step process now: 1) open the 'Activities' view to see what windows do I have open. 2) Look for it with the eyes and click. In the traditional desktop, the first step is eliminated. That's possibly desirable in a tablet where screen resources are invaluable, but not in a workstation where user-to-computer "bandwidth" must be maximized and screen are not touch-sensitive. That's why I see GNOME 3 as a tablet environment. I'd love to use a tablet with GNOME 3. But using it in a desktop just reduces the communication between me and my computer. What is Debian? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53eaae86.5070...@alvarezp.ods.org
JavaScript usage (was: Two-minute(!)-survey on motivation and free time contribution of open source developers)
On 08/31/2014 10:03 AM, Bálint Réczey wrote: > Hi, > 2014-08-31 17:42 GMT+02:00 Paul Wise : >> On Sun, Aug 31, 2014 at 6:53 AM, Stefan Kullack wrote: >> >>> It would be fantastic if you could spend two minutes on three simple >>> questions! >>> >>> Here is the link to the survey: https://de.surveymonkey.com/s/MFKXYLP >> >> You might get more feedback if you weren't using a proprietary SaaSS >> (service as a software substitute) that also causes privacy violations >> by asking users' browsers to report to the proprietary privacy >> invading Google Analytics service. > I would happily take this survey if I could do it without enabling > JavaScript on the page. > It this was the first survey question it is a pretty clever setup :-) Why don't you use JavaScript? I also don't like enabling JavaScript in my browsers but other than my personal reasons I have no arguments coming from somebody else. How do you currently cope up with pages with JavaScript? I use Chrome and the "Quick JavaScript Switcher" plugin. Do you have a particular concept regarding JavaScript or scripting in documents, or is it just for a practical purpose? Thanks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54035992.1030...@alvarezp.ods.org
Re: JavaScript usage
On 08/31/2014 10:21 AM, Octavio Alvarez wrote: > Why don't you use JavaScript? I also don't like enabling JavaScript in > my browsers but other than my personal reasons I have no arguments > coming from somebody else. > > How do you currently cope up with pages with JavaScript? I use Chrome > and the "Quick JavaScript Switcher" plugin. > > Do you have a particular concept regarding JavaScript or scripting in > documents, or is it just for a practical purpose? Sorry, that was meant to be a private response. My MUA hid the DD mailing list from view and never checked beyond what appeared on the screen. Please ignore, and sorry for the noise. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54035a1b.2050...@alvarezp.ods.org
Re: veto?
On 11/12/2014 02:04 AM, Daniel Pocock wrote: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? I would prefer a solution with less politics. Not more. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5463aa4d.8040...@alvarezp.ods.org
Re: veto?
On 11/13/2014 05:03 AM, Daniel Pocock wrote: On 13/11/14 13:16, Holger Levsen wrote: Hi, On Donnerstag, 13. November 2014, Matthias Urlichs wrote: I veto this idea. I agree. I don't. I veto the idea that this idea is dead, I think we should discuss it some more. If veto is dead, what would the FTP masters do when somebody decides to upload something before checking it is 100% free? Veto != policy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5464fb3b.7020...@alvarezp.ods.org
Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)
On 22/10/13 09:18, Arturo Borrero Gonzalez wrote: I would suggest: caching-name-server *-dns-server would be better, as it is specific enough to avoid name collision in the future. -- 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/5266c0ef.1050...@alvarezp.ods.org
Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)
On 10/24/2013 12:30 AM, Ondřej Surý wrote: > On Tue, Oct 22, 2013, at 20:16, Octavio Alvarez wrote: >> On 22/10/13 09:18, Arturo Borrero Gonzalez wrote: >>> I would suggest: caching-name-server >> >> *-dns-server would be better, as it is specific enough to avoid name >> collision in the future. > > JFTR that should not be any name collisions as the "name server" is term > defined in RFC1034 and used in all DNS standards out there. Not that it > matters now when the idea was those was rejected (see my other > proposal). RFC1034 and all DNS standards define "name server" within their own scope. Debian has a lot of software that do not belong to the IETF scope. -- 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/526d509a.5050...@alvarezp.ods.org
Bug#647877: ITP: superkb -- Keyboard-based launcher with unobtrusive on-screen graphical hints.
Package: wnpp Severity: wishlist Owner: Octavio Alvarez * Package name: superkb Version : 0.22 Upstream Author : Octavio Alvarez * URL : http://superkb.sourceforge.net/ * License : GPLv2 Programming Lang: C Description : Keyboard-based launcher with unobtrusive on-screen graphical hints. Hi. This is a program I wrote to enable key bindings to work with the Super key. Holding down the Super key for N seconds shows a keyboard on screen with hints about available bound keys. Configuration is stored in a flat text file. You can bind arbitrary scripts to your keys. It has been helpful to me because I can easily replicate my bindings to another PC and, so I have my keyboard full of shortcuts, I can check them when in doubt. The Super key is not fixed, so you can use any "magic" key in laptops that don't have the key (like the T42) without losing it. I am also learning to package for Debian. I am very willing to learn and become a maintainer in the near future, and potentially a developer. -- 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/2007075648.16890.96678.reportbug@localhost.localdomain
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, 17 Jan 2012 13:59:14 -0800, Ansgar Burchardt wrote: We propose to use the BTS to handle sponsoring requests. Both sponsorees and sponsors should already be familiar with its usage and we hope it will improve the sponsoring process for both sides. It will also make it easier to analyse sponsoring (e.g. number of requests without a response). As a non-developer, I really like this idea. Just a note, though: the non-automatic subscription behavior of the BTS could confuse new potential package maintainers, as they might not subscribe to the corresponding bug (this has happened to me). This should be noted in the documentation. In other issue tracking systems, the requester is automatically notified of any response or follow-up in the reported case. Best regards. -- Octavio. -- 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/op.v8j7kpqp4oyyg1@alvarezp-ws
Re: Removing packages from unofficial repositories
On 01/03/2014 03:41 AM, Виталий Филиппов wrote: > AFAIK the apt_preferences method is rather simple: > > Package: * > Pin: release o=Debian > Pin-Priority: 1001 > > With that setting 'apt-get dist-upgrade' downgrades DMO packages to > official ones. At least it did in my case. Does it work if you have Debian, deb-multimedia, another third-party repo, and you just want to remove deb-multimedia? Thanks. -- 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/52c6f111.5020...@alvarezp.ods.org
Re: Proposal: SystemD.pushers/forcers be physically beaten as revenge.
On 02/11/2014 11:46 AM, Maas Verri wrote: > Proposal: SystemD pushers/forcers be physically beaten as revenge. > > The people, such as Adrian, who are pushing systemd as the one > and only init system for debian should be physically harmed. Are you aware that saying "let's physically beat systemd pushers" has the same weight than "excuse me, but I do not agree because of blah", or possibly even less? You're barely doing something useful (if anything *at all*). After comments like that, this is simple: nobody will change their decisions (for whatever init system) after a comment of yours now because you have just shown you are nothing but a troll and can't be taken seriously. Most will just ignore you now. -- 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/52fab17c.4080...@alvarezp.ods.org
Re: Idea for apt-get : getting source code instead getting binaries
On 03/06/2014 07:33 AM, Solal Rastier wrote: > Hello! I've an idea for a new apt-get package style : > > Developer side : > -The developer create a ./install script in the source code. > -The install script executes all commands necessary for install the software. > Also, it getting dependancies, etc. > -The developer create a tarball (.tar.bzip2) and rename the file name. > Instead of software.tar.bzip2 , that's software.deb > -The developer distribute the software.deb > > Apt-get side : > -The apt-get tool download software.deb from the Debian repository. > -The program is installed with dpkg > > Dpkg side : > -dpkg rename the software.deb software.tar.bzip2 > -tar uncompress the software.tar.bzip2 > -cd go into the "software" folder > -./install execute install script Uninstalling would be a pain and would *easily* leave my system (and systems I support) in an inconsistent state and with a lot of leftovers because of packagers that don't care about uninstalling properly. This is something I like about Debian and dislike about Windows, by the way. Bad idea. Despite being a bad idea, I think it could be done by using the postinst script, but nobody does it like this because it is very inconvenient. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5318bd48.4060...@alvarezp.ods.org
Re: cppcheck, does nobody really care about it?
On 12/05/14 11:47, Gianfranco Costamagna wrote: > Hi debian developers, > > cppcheck [1] has been removed from testing [2] because of a sourceless > javascript file [3]. Hi, Gianfranco. Not a DD here, but: There are mixed opinions about cases like this. cppcheck doesn't need jQuery to work (or to do anything at all, even): it's just that a copy of the documentation website is included in the upstream package, and thus, the Debian source package, but nothing from this is actually included in the binary, not even used for compilation. So, just to get back in sync: currently, Debian's cppcheck is (was) upstream's 1.61. There was a 1.64 version available [*] but there was a problem with tinyxml2 versioning (and therefore, packaging). I commented on tinyxml2 issue #31 [1] regarding this and upstream accepted to tag future releases. This helped tinyxml2 packaging [2] to make it easier for cppcheck to Depend: libtinyxml2-2 and 2.0.2-1 is now on testing [3]. I got asked privately to test 1.64 directly, but I've been out of town for almost a month now and unable to contribute. Just today I returned, so I should have some spare time during this week to try a package for 1.64 with Depend: libtinyxml2-2 and most probably without the jQuery file altogether, given that jQuery cases and correct inclusion discussion have still not completely settled down. [*] 2 days ago 1.65 was released [4], so I may try 1.65 instead. [1] https://github.com/leethomason/tinyxml2/issues/31 [2] http://packages.qa.debian.org/t/tinyxml2.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734617 [4] https://github.com/danmar/cppcheck/releases > Because of this I packaged (with patch and thanks from Octavio) a new dfsg > version and uploaded on mentors [4] some time ago. > (I'm uploading it again right now since I forgot to put the bug reference > into the changelog) Personally, I'd rather see 1.61+dfsg uploaded before attempting to package 1.65, but has its own set of implications. For example, the patch uses the Files-Excluded: facility on debian/watch, and this includes repackaging the same version of upstream, which I'm not exactly sure how this would work. So, if 1.65 works now, we should kill two big birds with one shot and hopefully we will all be happy. > I personally consider cppcheck a great package, that helped so far me in > spotting many possible vulnerabilities in packages I comaintain, helping me > in providing more secure packages in debian repositories (as well as sending > security fixes upstream). I use it on a regular basis, and most of my build scripts use it, so I'm interested it having it included. However, not being a DD, I still need sponsorship. My two cents. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53712dc7.2020...@alvarezp.ods.org
Re: MATE 1.8 has now fully arrived in Debian
On 06/03/2014 05:36 AM, Fabian Greffrath wrote: > Again, I don't want to degrade the MATE project or your packaging > effort, not at all. But my questions and concerns are serious. I still > do not get the point of the whole MATE desktop now that it tries to run > behind and catch up with GNOME again. Speaking as an individual, I do appreciate the effort of the MATE team. My experience with GNOME Flashback has ranged from very bad to incredibly frustrating, up to the point that I decided to switch to Xfce and I have, since, been happy again. Just before writing this message, I tested GNOME Flashback once again on my Sid box and it does not unpaint some windows (tried with the menu and GNOME Terminal). This is not only a show stopper, it's an elemental mistake. I couldn't be able to say if it's a packaging problem or a GNOME Flashback problem. I run GNOME Flashback under Ubuntu at work. At that moment, when I installed it I had to diagnose a terrible a memory leak that came from upstream. I know Ubuntu is not Debian, but the memory leak was eventually acknowledged and fixed by upstream. OTOH, GNOME Classic just runs on top of GNOME Shell, suffering from the same drawbacks like resource consumption and the tablet-like UX paradigm (just a bit less sucky). >From my point of view, GNOME Flashback just doesn't have enough love from --pretty much-- anybody; this includes the GNOME team: no news about GNOME Flashback in the 3.10 or 3.12 release notes (it was first released in 3.8). I will, of course, test MATE in the upcoming days. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539027aa.7040...@alvarezp.ods.org
Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]
On 19/11/14 21:32, Steve Langasek wrote: >> 1) the problem with new feature in systemd which considers all >> filesystems in fstab vital for system boot and stops boot if they >> fail. It's been decided that although it is a change in behaviour >> that might render some systems unbootable it's technically correct >> implementation and only enforces that non-vital filesystems are >> marked as such in fstab which should have been the case from the >> start. >> > As regards the two issues you've described: the first is not a bug. > It's a necessary change in how we view the boot in a truly > event-driven system. There is no sane default policy for how to > interpret entries in /etc/fstab on upgrade except to regard them as > all mandatory - *but* it's important that the admin be given the > opportunity to intervene to override this policy. Question: is it safe to say that systemd doesn't yet support the full /etc/fstab specification from util-linux [1]? [1] man 5 fstab Thanks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546e6113.2010...@alvarezp.ods.org
Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]
On 19/01/15 01:14, Paul Wise wrote: > On Mon, Jan 19, 2015 at 5:03 PM, Tomas Pospisek wrote: > >> But isn't subscribing participants "natural"? Posting to a bug >> report means participation and thus you'd get the follow-ups. Why >> would you post to a bug report if you aren't interested in what >> happens with it, how things proceed/evolve? > > It is only natural to people who are used to it happening on other > bug trackers. People often file bugs for issues they discover in > software they don't use or care about, getting followups to those > isn't necessary. >> >> I can understand your point of view and I think also the why but >> isn't that position the exception from the rule? That is shouldn't >> the process be optimized for the "common" case and allow the >> exception? > > The problem is that there is no common case. The only generality I > can think of is that people who have been around for a long time > generally want the status quo and new people who are usually used to > other bug trackers want to be subscribed by default. Hi. It is far better to get the surprise that you got subscribed and having to unsubscribe than to get the surprise that you did not get subscribed and missing real-time conversation. Also, automatic subscription would definitely lower the barrier for potential contributors, as it is expected to be subscribed; it also makes continued contribution require less effort. Experts that want to nitpick each case could have a flag available and their default could be changed by one or another way. Best regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54bd7a61.7040...@alvarezp.ods.org
Re: conflicts between Debian's and upstream's Debian package
On 02/20/2015 06:25 AM, Harald Dunkel wrote: Hi Daniel, On 02/20/15 13:09, Daniel Leidert wrote: Just to understand your problem: there is a package foo. Debian provides it with version 1:A-B and upstream provides some self-compiled packages with the same name under version C-D (and C-D < 1:A-B) and you want to force apt to install the package from the upstream developers site. Not exactly: I want to avoid that such a mess happens again. I think its obvious that a naming conflict should be avoided. Having 2 source or binary packages with identical names in 2 independent repositories is just asking or troubles. I don't understand how policy can help in this case. Debian can only have policy for its own work. Upstream's is not Debian. My take is that it's more a matter of configuration (or some other technical aspect) than policy. I explain: Debian could have package name X based on a software piece from upstream U. Some version problems happen and the maintainer decides to set version to 1:V. and then upstream U decides to also create its own .deb package X without using 1:. [*] [*] Notice that I didn't say 'Debian package', I said '.deb package' All is well fr both *until* the user decides to add the repository for upstream. The Debian repository should have higher priority than upstream's, mostly for security purposes, but I don't know if that's currently the way. Nevertheless it's the *user* that decided to manually add the third-party repo. You and I can create a repo for any existing Debian package with any version number. If the user decides to add our repos there's nothing Debian can do to stop him. Our packages could even be malicious. Then the question is not about policy. It's about how to best help the user handle the situation, and that is being allowed to locally raise or lower the priority of a package or repository for a particular set of packages or repositories. IMHO there should be a policy for the special case, that there is a naming conflict between upstream's source or binary packages, and the packages included in Debian. Ah, naming conflict can only be stated within Debian. Going on this would just be repeating myself. Maybe you want to have a way to define different "namespaces" for particular repos, so you can distinguish them. Let me invent something on the fly: you want to distinguish "debian$package" vs "upstream$package", where 'debian$' and 'upstream$' are repo prefixes so apt-get handles them separately. Possibly 'debian$' is the one by default. This doesn't exist AFAIK. Best regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f1e04a.1090...@alvarezp.ods.org
Re: Bug#782001: general: access granted to /home files of another user
On 04/06/2015 08:20 AM, Adam Borowski wrote: On Mon, Apr 06, 2015 at 12:46:30PM +0200, Björn wrote: * What led up to the situation? Created new user from a non-root account (using root password prompt within non-root account). Started that new user. Tried to read files from /home of first user. Succeeded. This is not an error, works as designed. You can "dpkg-reconfigure adduser" to change this behaviour for newly added users (ie, not the first one), existing users' homes need manual chmodding. What about sane defaults? It could also be dpkg-reconfigured the other way around. Best regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55238608.4060...@alvarezp.ods.org
Re: Half-cycle
On 02/05/15 11:58, Dimitri John Ledkov wrote: > Could we: > > Freeze in 6-8 months > Release in 10-12 months Please don't. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5547c4ab.3040...@alvarezp.org
Re: The Spirit of Free Software, or The Reality
On 07/04/2015 10:40 AM, Jan Gloser wrote: I am not an active member of the debian community, just a listener on this thread, but you got my attention. I also admire free software makers although I think one must always keep in mind the reality of the world and the rules of the game called 'trade'. (snipped the rest of the message) It appears to me that throughout your reply you used the word "free" to refer to zero price. In Lumin's original post he was not referring to price, but to freedom. I personally know people that have businesses based on free(dom) software, and I know people that get paid for implementing and customizing Free Software, for example. That could be the reason behind your analogy with communism, which turns out to be out of bounds. The Free Software community is not against trade or capitalism at all. Maybe some individuals do, but that's another story. In fact, Free Software is legally based on Copyright law. When RMS emphasizes about "freedom, not price" it means precisely that, but the message could not be so obvious. For example, we in Spanish call it "Software Libre" as opposed to "Software Gratis". Many people use it because it has zero price and that's ok too, but when people ask me if a piece of software is "gratis" (for free) I reply that yes, but furthermore, it is also "libre" (liberty). Compare, for example, with the Flash player for Windows, which you can download for free but you don't have a legal freedom to create derivative copies. That's not what we are talking about. Best regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55998521.2070...@alvarezp.org
Re: The Spirit of Free Software, or The Reality
On 07/16/2015 01:00 AM, Ben Finney wrote: Bas Wijnen writes: The "problem" that nobody mentioned it may be caused by the fact that nobody really considers those icons non-free, The copyright holder of those icons does not, AFAIK, grant restricted license for recipients to modify and redistribute the work. That makes those works non-free by my reading of the Social Contract. IANAL but the icons are not part of the work (the browser); they are trademarks for purposes of identification of an integration with a third-party service; they don't have to be DFSG-free, just redistributable by Debian (and possibly not even that because this usage could fall into fair use, as long as there is no claim or appearance that the third-party endorses the work). Best regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a9239b.3060...@alvarezp.org
Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin
On 01/30/2017 02:29 AM, Guus Sliepen wrote: > On Mon, Jan 30, 2017 at 11:19:32AM +0100, Michael Biebl wrote: > >>> Fredrik, the plugin already recommends pavucontrol (which recommends >>> pulseaudio) so it should already have been installed unless you manually >>> asked >>> not. But right, it might be a good idea to have a direct pulseaudio >>> recommends . >> >> A pulseaudio plugin without a pulseaudio "Depends" seems rather pointless > > But xfce4 Depends on xfce4-pulseaudio-plugin. Maybe it is better if that > became a Recommends then? What's the problem with two packages depending on the same package? What am I missing? -- Octavio.
Re: DAK Commands for Bikesheds
On 09/17/2015 05:41 AM, Raphael Hertzog wrote: Hi, On Thu, 17 Sep 2015, Joerg Jaspert wrote: Please check if I forgot something obvious or if there is some big error in it. Patches/git trees to merge from/... are welcome. Please don't call this feature "Bikesheds" and don't hardcode this naming in the suggested API. It was funny during one Debconf talk... but it won't be funny in the long term. I don't want to suggest bikeshedding on the name but stick to something simple like "XXX Package (Repository|Archive)" with a XXX that makes sense to you (Special, Developer, Custom, ...). I'm with you. It's not only confusing because the word already has two meanings, but it also doesn't say anything about the feature at all, while being hard to remove the negative connotation the word carries from the bikeshedding concept. Best regards. -- Octavio.
Bug#813464: ITP: ciscocmd -- Expect script to send a set of commands to a set of Cisco devices
Package: wnpp Severity: wishlist Owner: Octavio Alvarez * Package name: ciscocmd Version : 1.11 Upstream Author : Alain Degreffe * URL : http://cosi-nms.sourceforge.net/alpha-progs.html * License : GPLv2 Programming Lang: Expect/TCL Description : Expect script to send a set of commands to a set of Cisco devices ciscocmd is a Tcl/Expect script. With this tool, you can send a set of command to a large number of ios target hosts and get a separated report for each node. I use this program on a day-to-day basis and I have contributed code to it. Because this program is a single-file Expect script, package maintenance should be simple. I plan to maintain it by myself. I will need a sponsor for this package, though.
