Bug#655031: To fix
In 7.53+dfsg-1 The best thing you can do to fix this bug is remove the symbolic link ~/.config/alien-arena and create a directory with this name. $ mkdir ~/config/alien-arena than link data1 inside. This bug present in the file /usr/games/alien-arena edit this lines: # Ready to rumble! export COR_GAME=$HOME/.config/alien-arena ln -s /usr/share/games/alien-arena/data1 $COR_GAME change to: if [ ! -f $HOME/.config/alien-arena ] then mkdir $HOME/.config/alien-arena fi ln -s /usr/share/games/alien-arena/data1 $COR_GAME/data1
Bug#663748: ITP: pesco -- Cognitive stimulation tool for elderly or cognitively impaired
Hi Luis, Thanks for the ITP -- I would appreciate if you keep debian-med (it is of relevance for rehabilitation task page and NeuroDebian project) informed on the progress and do not hesitate to ask if you have questions. Cheers On Tue, 13 Mar 2012, Luis Rivas Vañó wrote: Package: wnpp Severity: wishlist Owner: Luis Rivas Vañó lui...@gmail.com * Package name: pesco Version : 1.2 Upstream Author : GEDES Universidad de Granada mjfor...@ugr.es * URL : http://forja.rediris.es/projects/ec-ng/ * License : EUPL Programming Lang: C# Description : Cognitive stimulation tool for elderly or cognitively impaired Pesco is a free software (EUPL) tool whose main goal is to provide cognitive stimulation for the elderly people and cognitive impaired. Its main goal is to evaluate and cognitively stimulate people to prevent the cognitive impairment, delaying the dependence from early stages. It provides test and exercises for the neurological and functional rehabilitation of memory, concentration, reasoning and organization. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
On Thu, Jan 5, 2012 at 12:25 PM, Russ Allbery wrote: This is the bug concerning the wording in current Policy 2.2.1: In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package), There are two separate issues here. One is the question of what to do about non-default alternatives (like Depends: unrar-free | unrar). The other is that this is not a complete list of relevant fields. The second problem is, so far as I can tell, informative and completely non-controversial, so rather than have it blocked by the first problem, I've gone ahead and committed the following patch: diff --git a/policy.sgml b/policy.sgml index 79281e9..c1ff4b4 100644 --- a/policy.sgml +++ b/policy.sgml @@ -489,9 +489,9 @@ item must not require or recommend a package outside of emmain/em for compilation or execution (thus, the - package must not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + package must not declare a Pre-Depends, Depends, + Recommends, Build-Depends, or Build-Depends-Indep + relationship on a non-emmain/em package), /item item must not be so buggy that we refuse to support them, This is a bit off-topic for the bug report, but while you're thinking about rewording this section, it may be prescient to consider non-explicit dependencies. For example, the getweb script in foo2jzs fetches non-free firmware files, yet seems to be currently permissible in main given the current policy wording since there is no Depends or Recommends: external firmware files anywhere in the control file. Anyway, something worth considering. Perhaps this topic itself would be better to start as a new bug report? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659650: [libarchive-dev] please include examples
Hi - Andreas, On 2012-03-13 08:27, Andreas Henriksson wrote: Hi! On Mon, Mar 12, 2012 at 10:43:36PM -0400, Filipus Klutiero wrote: Thanks Andreas, You mean Andres, but you're welcome anyway. ;) Hum, possible confusion indeed, sorry :-S On 2012-03-12 18:36, Andres Mejia wrote: I would rather not bloat any of the existing packages with examples, nor create another package solely for installation of examples. I usually put coding examples in the -dev package. Doesn't matter if it grows a bit because it's not supposed to be installed by the general public, only developers I think it would be a good idea to do so here as well. It would be nice to have some guidelines on this, but as I'm not aware of any, I tend to consider -dev packages as targetted to developers and those who compile. The developers will want examples and documentation in general. Those who compile will not. But since there must be few non-developers who compile and since examples are small, I think including them in the -dev package is fine. If it gets too big, splitting a -doc package from -dev could be a solution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
Michael Gilbert michael.s.gilb...@gmail.com writes: This is a bit off-topic for the bug report, but while you're thinking about rewording this section, it may be prescient to consider non-explicit dependencies. For example, the getweb script in foo2jzs fetches non-free firmware files, yet seems to be currently permissible in main given the current policy wording since there is no Depends or Recommends: external firmware files anywhere in the control file. This concern is addressed by the paragraph three higher, at the start of the section. The main archive area comprises the Debian distribution. Only the packages in this area are considered part of the distribution. None of the packages in the main archive area require software outside of that area to function. The non-free firmware fetched from elsewhere is clearly software outside of that area. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663488: wx2.8-i18n: Translation de
On Sun, Mar 11, 2012 at 05:28:19PM +0100, Mechtilde wrote: I do some completition to the German translation. I wanted to complete the translation for the startup of taskcoach. Please give me a hint how I can provide the new file. Just attach the updated .po file to an email and send it to this bug. However: Package: wx2.8-i18n Version: 2.6.3.2.2-5 That version number suggests you may be looking at wx2.6 rather than wx2.8 - wxwidgets2.6 was removed from testing and unstable last year, and hasn't been supported by upstream for years. Updates to translations on 2.6 would just be a waste of your time. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
On Tue, Mar 13, 2012 at 10:53 PM, Russ Allbery r...@debian.org wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: This is a bit off-topic for the bug report, but while you're thinking about rewording this section, it may be prescient to consider non-explicit dependencies. For example, the getweb script in foo2jzs fetches non-free firmware files, yet seems to be currently permissible in main given the current policy wording since there is no Depends or Recommends: external firmware files anywhere in the control file. This concern is addressed by the paragraph three higher, at the start of the section. The main archive area comprises the Debian distribution. Only the packages in this area are considered part of the distribution. None of the packages in the main archive area require software outside of that area to function. The non-free firmware fetched from elsewhere is clearly software outside of that area. I understand this section very well, and even with that lead-in wording, I contend that sufficient ambiguity remains that additional clarity is needed. Otherwise, it wouldn't have been so difficult to deal with bug #449497, which essentially turned into a wontfix. The problem is that even though the lead-in uses the term software, the actual must requirements use the term package. Thus, a liberal reading of policy leads to the conclusion that if there isn't an explicit dependency on a package, then it's ok to have a script or plugin in main that makes use of non-free. I think that interpretation violates the spirit of the policy. Clearer wording could fix this. I would propose --- a/text +++ b/text2 @@ -1,4 +1,5 @@ -must not require or recommend a package outside of main for compilation or +must not require or recommend software (including packages, plugins, firmware, etc.) +outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a -non-main package), +non-main package and must not include utilities that fetch non-main files), Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662726: use of ancestor-path
On Sun, 11 Mar 2012 19:02:42 -0300, David Bremner brem...@debian.org wrote: Here is a revised version. Let's pretend there were all kinds of useful discussions in some other medium that led to this. Rebasing the single patch and sending it to the BTS started to be a bit boring, so I have made a public branch at http://pivot.cs.unb.ca/git/?p=gitpkg.git;a=summary I have improved the docs, and made few minor improvements. It occurred to me that the field names (export, forwarded, etc...) should probably be restricted to some list in order to avoid typos. This could be overridden either with a config option or a command line option. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
Michael Gilbert michael.s.gilb...@gmail.com writes: I understand this section very well, and even with that lead-in wording, I contend that sufficient ambiguity remains that additional clarity is needed. Otherwise, it wouldn't have been so difficult to deal with bug #449497, which essentially turned into a wontfix. No, that bug is a different argument (the one about what it means to require software). I don't have anything new to say about that bug that I didn't say at the time. I continue to believe that the current bug state is correct, and that your position on that bug is not correct, although I understand where your position comes from and I don't think it's unreasonable. The problem is that even though the lead-in uses the term software, the actual must requirements use the term package. Thus, a liberal reading of policy leads to the conclusion that if there isn't an explicit dependency on a package, then it's ok to have a script or plugin in main that makes use of non-free. Here is the complete text: The main archive area comprises the Debian distribution. Only the packages in this area are considered part of the distribution. None of the packages in the main archive area require software outside of that area to function. Anyone may use, share, modify and redistribute the packages in this archive area freely[4]. Every package in main must comply with the DFSG (Debian Free Software Guidelines). In addition, the packages in main * must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non-main package), * must not be so buggy that we refuse to support them, and * must meet all policy requirements presented in this manual. The words in addition have a specific meaning in English. The bullet points do not replace all the text that comes before them. I suppose we could add a must to the None of the packages in the main archive area require software outside of that area to function sentence with some rephrasing, if it would result in having fewer arguments about this, but I really don't believe the meaning is unclear. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584987: RM: mysql-gui-tools -- RoQA; RC-buggy, EOL upstream, obsoleted by mysql-workbench
reassign 584987 ftp.debian.org retitle 584987 RM: mysql-gui-tools -- RoQA; RC-buggy, EOL upstream, obsoleted by mysql-workbench severity 584987 normal affects 584987 + mysql-gui-tools On Tue, 2010-06-08 at 13:32 +0800, Paul Wise wrote: mysql-gui-tools is EOL upstream: http://dev.mysql.com/support/eol-notice.html Please replace mysql-gui-tools with mysql-workbench and have mysql-gui-tools removed from Debian squeeze. Now that mysql-workbench has entered Debian[1], it is finally time to remove mysql-gui-tools from Debian. It is RC-buggy, EOL upstream since before squeeze was released and is obsoleted by mysql-workbench, which was recently accepted to unstable. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#661283: cmor: FTBFS on kfreebsd-amd64
reopen 661283 done On 03/03/12 14:11, Julien Cristau wrote: I gave it back and it built, so closing. Hi, Doesn't this want fixing more permanently? It got queued for a rebuild for some reason and has been failing again since: https://buildd.debian.org/status/logs.php?pkg=cmorarch=kfreebsd-amd64 The test suite with ~700MiB process images are presumably asking a bit too much of the kfreebsd-amd64 buildds (and way too much for kfreebsd-i386, #598745). That's odd though if they have 6GiB RAM in total. I suspect a limit is be being hit, something similar to kern.maxdsiz although that one is per-process so wouldn't explain why this happens only sometimes. I'm curious anyway what are the kern.maxdsiz and kern.dfldsiz on the buildds (I'm guessing 1GiB on amd64) and is it permissible for them to be raised (to maybe 2GiB) if some package like this one required it? (I'm also wondering about the openjdk-7 failures here.) Or, should/could the cmor test suite be slimmed down to suit? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611418: Modifications of dh_installxmlcatalogs for /etc/xml handling
The attached patch modifies dh_installxmlcatalogs to make /etc/xml solely owned by xml-core, and cleanly removes the directory on purge. This passes piuparts cleanly for the worst dependency blockers, docbook-xsl and sgml-data. Similar changes are needed for /etc/sgml handling by dh_installcatalogs, in debhelper. xml-dir-handling.patch Description: Binary data
Bug#663393: sshfs: User error; please close bug
Package: sshfs Followup-For: Bug #663393 Apparently I'm blind and had typos in the names of the hosts. Sorry for the noise. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'stable-updates'), (1, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sshfs depends on: ii fuse2.8.6-4 ii libc6 2.13-27 ii libfuse22.8.6-4 ii libglib2.0-02.30.2-6 ii openssh-client 1:5.9p1-3 sshfs recommends no packages. sshfs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
On Tue, Mar 13, 2012 at 11:27 PM, Russ Allbery wrote: Michael Gilbert writes: I understand this section very well, and even with that lead-in wording, I contend that sufficient ambiguity remains that additional clarity is needed. Otherwise, it wouldn't have been so difficult to deal with bug #449497, which essentially turned into a wontfix. No, that bug is a different argument (the one about what it means to require software). It's more nuanced than that. Think about it this way. Say the remote firmware files that getweb currently fetches were instead put in a package called foo2zjs-nonfree. That package would (of course) have to be located in non-free, and any packages depending on that would need to be located in at least contrib, right? Now the majority of foo2zjs doesn't depend on those files, but it can make use of them if/when they're available. Now that there is no need to fetch external files, getweb is dropped from the package. Based on those two facts, its obvious that this new version of the package appropriately belongs in main. For the sake of argument, lets assume that the upstream build system doesn't put the foo2zjs-nonfree files into the right place as expected by foo2zjs. In the usual Debian world, the foo2zjs-nonfree maintainer would write some fix-up scripts that would be a part of the that package and it would be a non-issue since all of it would be in non-free. Again, for the sake of argument, let's assume that the foo2zjs-nonfree maintainer is opposed to including those fix-ups directly into the package for whatever reason (as an aside this sort of mimicks the current upstream author's rejection of distro packaging of his software). So someone comes along and writes a foo2zjs-getmove package, which moves the nonfree files into the right place that the foo2zjs package needs. Now, where does foo2zjs-getmove belong? It only serves to support a non-free component. More importantly, what are the Depends and Recommends of that package? I would content that it would be a Depends: foo2zjs-nonfree, since the package itself can't do anything without that. Admittedly, this is a convoluted situation for normal Debian packages, but it accurately mimicks the current situation if it were done with packages rather than fetching scripts, and thus is valid as a gedankenexperiment. I don't have anything new to say about that bug that I didn't say at the time. I don't think you had commented at the time. I continue to believe that the current bug state is correct, and that your position on that bug is not correct, although I understand where your position comes from and I don't think it's unreasonable. Opinions are malleable (wrong and right are all a matter of perspective). This is something sufficiently nuanced that I think its worth sufficient pondering to really get it right. If you haven't spent much time pondering those nuances, it's easy to assume perspective of the status quo. The problem is that even though the lead-in uses the term software, the actual must requirements use the term package. Thus, a liberal reading of policy leads to the conclusion that if there isn't an explicit dependency on a package, then it's ok to have a script or plugin in main that makes use of non-free. Here is the complete text: The main archive area comprises the Debian distribution. Only the packages in this area are considered part of the distribution. None of the packages in the main archive area require software outside of that area to function. Anyone may use, share, modify and redistribute the packages in this archive area freely[4]. Every package in main must comply with the DFSG (Debian Free Software Guidelines). In addition, the packages in main * must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non-main package), * must not be so buggy that we refuse to support them, and * must meet all policy requirements presented in this manual. The words in addition have a specific meaning in English. The bullet points do not replace all the text that comes before them. Right, I wasn't trying to say that. My point was more that the lead-in paragraph as it is now is only descriptive, but given the wording doesn't actually lay out any of particular requirements (more so it lays out the ideals of main). The requirements themselves actually start with, Every package in main must comply then continues with In addition to and then the bullets. Those actually binding sections never use the term software, so the obvious interpretation is that policy only places requirements on packages, and even more importantly seemingly only their control fields, not their actual components (giving things like getweb a pass). I suppose we could add a
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
Michael Gilbert michael.s.gilb...@gmail.com writes: Opinions are malleable (wrong and right are all a matter of perspective). This is something sufficiently nuanced that I think its worth sufficient pondering to really get it right. If you haven't spent much time pondering those nuances, it's easy to assume perspective of the status quo. But I have spent much time pondering these nuances and have decided that while your opinion makes sense and comes from a set of reasonable assumptions, I don't agree with it. When I said I wasn't interested in reopening this discussion, I really meant it. My perception is that the project made a decision on this case (one that I happen to think is right) and there's no great clamour to reopen the topic. You don't agree with that decision, which is perfectly reasonable. I think you're in the rough of rough consensus. If such a clamour arises, then of course that's a different situation. Anyway, I think this is irrelevant to the wording debate, since the core of that argument is over what it means to depend on or recommend or to require other software, and that's not something we're going to resolve by tweaking the wording. Right, I wasn't trying to say that. My point was more that the lead-in paragraph as it is now is only descriptive, but given the wording doesn't actually lay out any of particular requirements (more so it lays out the ideals of main). The requirements themselves actually start with, Every package in main must comply then continues with In addition to and then the bullets. Yes, this is the point where we don't agree. You feel that because there isn't a must in the first paragraph, it's not a requirement. I think the first paragraph is clearly a requirement, whether it includes the word must or not. It's typical in standards that statements of fact like nothing in main requires software outside of main to function constitute a requirement placed on software going in main, regardless of whether it uses a specific standards word. In other words, you aren't allowed to do something that makes factual statements in the policy document false. (This comes up frequently in descriptions of syntax. It's usually both tedious and pointless to add must words everywhere to say that people aren't allowed to violate the syntax.) If it would result in less argument, I can support rephrasing the first paragraph to include the magic word must around does not require software outside of main to function. It's not unclear per se, but there remain ambiguities in terminology making it possible to interpret it in various slightly incompatible fashions: the choice of the term package vs. software makes it appear ok to have non-main software depends/recommends but not ok to have package depends/recommends. The reason why I'm somewhat unenthused about tweaking the wording here is that there are *always* going to be ways to interpret human language other ways, particularly in an area like this that's rife with acknowledged grey areas (like emulators that are mostly used to play non-free ROMs but can also play the -- often nearly nonexistent -- free ROMs). In other words, I'm skeptical whether changing the language here is going to result in fewer discussions like this, and whether it's going to actually resolve confusion, as opposed to being a debating stick. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
