Re: Bug#668400: /usr/bin/apt-get: Apt-get purge/remove delete file behind symlink
Control: reassign -1 tomcat7 Hi! On Wed, 2012-07-18 at 20:22:12 +0200, Guillem Jover wrote: On Wed, 2012-04-11 at 17:47:15 +0200, Rafal Kaminski wrote: Package: apt Version: 0.8.15.10 Severity: normal File: /usr/bin/apt-get I found some bug or feature apt-get. I've installed tomcat7 and in folder /etc/tomcat7 I put symlink to diff. folder - like to /data/file1. Then in /etc/tomcat7 I had symlink file1. When I made apt-get remove tomcat7 or apt-get remove --purge tomcat7 - apt-get didn't remove symlink from /etc/tomcat7, BUT REMOVE file from /data. After apt-get remove I hadn't file1 in /data/file1. Given the directory removals in tomcat7's postrm script I'm inclined to think this is tomcat7 (and tomcat6) fault, but it would be helpful to know what exactly did you symlink, was it the /etc/tomcat7 directory itself, one of the conffiles inside? Something else? I'm reassigning to the tomcat7 package. Regards, Guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#698899: mathpiper: Non-functional Homepage URL
Package: mathpiper Version: 0.81f+svn4469+dfsg3-1 Severity: minor Hi! The Homepage field points to an URL that no longer works. The correct URL seems to be http://www.mathpiper.org/. Thanks, Guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#696283: jruby: Sets FD_CLOEXEC incorrectly with F_SETFL instead of F_SETFD
Source: jruby Version: 1.5.6-5 Severity: important Tags: patch User: debian-...@lists.debian.org Usertags: fcntl-fd-cloexec Hi! This package contains code that tries to set the FD_CLOEXEC flag for a file descriptor, but it does using F_SETFL instead of F_SETFD. Using that value on F_SETFL is just wrong, and might make the call fail on some systems, as it's requesting to set an undetermined flag. For example on GNU/* FD_CLOEXEC has value 1, which matches with O_WRONLY. This might cause the code to at least leak file descriptors, and at worst to terminate execution. Attached a patch fixing this. (I've filed bug reports for the ruby 1.8 and 1.9.1 parts on their relative packages too.) Thanks, Guillem From e6ba288b93628e231dbb1a067b30f6f928be87d5 Mon Sep 17 00:00:00 2001 From: Guillem Jover guil...@hadrons.org Date: Tue, 18 Dec 2012 18:33:48 +0100 Subject: [PATCH] jruby: Set FD_CLOEXEC correctly using F_SETFD not F_SETFL Using that value on F_SETFL is just wrong, and might make the call fail on some systems, as it's requesting to set an undetermined flag. For example on GNU/* FD_CLOEXEC has value 1, which matches with O_WRONLY. This might cause the code to at least leak file descriptors, and at worst to terminate execution. --- lib/ruby/1.8/drb/unix.rb | 2 +- lib/ruby/1.8/webrick/utils.rb | 2 +- lib/ruby/1.9/drb/unix.rb | 2 +- lib/ruby/1.9/webrick/utils.rb | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/ruby/1.8/drb/unix.rb b/lib/ruby/1.8/drb/unix.rb index 57feed8..90ca292 100644 --- a/lib/ruby/1.8/drb/unix.rb +++ b/lib/ruby/1.8/drb/unix.rb @@ -100,7 +100,7 @@ module DRb end def set_sockopt(soc) - soc.fcntl(Fcntl::F_SETFL, Fcntl::FD_CLOEXEC) if defined? Fcntl::FD_CLOEXEC + soc.fcntl(Fcntl::F_SETFD, Fcntl::FD_CLOEXEC) if defined? Fcntl::FD_CLOEXEC end end diff --git a/lib/ruby/1.8/webrick/utils.rb b/lib/ruby/1.8/webrick/utils.rb index cf9da6f..1c29ef5 100644 --- a/lib/ruby/1.8/webrick/utils.rb +++ b/lib/ruby/1.8/webrick/utils.rb @@ -29,7 +29,7 @@ module WEBrick def set_close_on_exec(io) if defined?(Fcntl::FD_CLOEXEC) -io.fcntl(Fcntl::FD_CLOEXEC, 1) +io.fcntl(Fcntl::F_SETFD, Fcntl::FD_CLOEXEC) end end module_function :set_close_on_exec diff --git a/lib/ruby/1.9/drb/unix.rb b/lib/ruby/1.9/drb/unix.rb index ebecc22..e56008c 100644 --- a/lib/ruby/1.9/drb/unix.rb +++ b/lib/ruby/1.9/drb/unix.rb @@ -100,7 +100,7 @@ module DRb end def set_sockopt(soc) - soc.fcntl(Fcntl::F_SETFL, Fcntl::FD_CLOEXEC) if defined? Fcntl::FD_CLOEXEC + soc.fcntl(Fcntl::F_SETFD, Fcntl::FD_CLOEXEC) if defined? Fcntl::FD_CLOEXEC end end diff --git a/lib/ruby/1.9/webrick/utils.rb b/lib/ruby/1.9/webrick/utils.rb index dee9363..677ecb8 100644 --- a/lib/ruby/1.9/webrick/utils.rb +++ b/lib/ruby/1.9/webrick/utils.rb @@ -29,7 +29,7 @@ module WEBrick def set_close_on_exec(io) if defined?(Fcntl::FD_CLOEXEC) -io.fcntl(Fcntl::FD_CLOEXEC, 1) +io.fcntl(Fcntl::F_SETFD, Fcntl::FD_CLOEXEC) end end module_function :set_close_on_exec -- 1.8.1.rc0 __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#690204: Bug#537051: Add no-await trigger support and Breaks to fix ca-certificates-java breakage
On Thu, 2012-11-29 at 08:48:04 -0800, Don Armstrong wrote: On Thu, 29 Nov 2012, Guillem Jover wrote: On Tue, 2012-11-13 at 13:18:37 -0800, Don Armstrong wrote: diff --git a/debian/ca-certificates.triggers b/debian/ca-certificates.triggers new file mode 100644 index 000..14dec6e --- /dev/null +++ b/debian/ca-certificates.triggers @@ -0,0 +1,4 @@ +interest-noawait update-ca-certificates +interest-noawait update-ca-certificates-fresh As these are not supported by squeeze's dpkg, this can cause upgrade problems (see below). +interest update-ca-certificates +interest update-ca-certificates-fresh (OOC why the duplicates?) They're not duplicated; it can handle both noawait and non-noawait triggers. dpkg does not handle them as different trigger directives if there's synchronous and asynchronous variants, they will just end up stomping over each other. Given the current implementation, the last directive wins, so I'd expect to see only the await variants in the dpkg database. («cat /var/lib/dpkg/triggers/update-ca-certificates».) In any case, regardless of this, semantics-wise I don't think it makes much sense to have both of them present. I'll be fixing the deb-triggers(5) man page to clarify this. diff --git a/debian/control b/debian/control index 5ef776e..8f84573 100644 --- a/debian/control +++ b/debian/control @@ -13,9 +13,11 @@ Vcs-Browser: http://git.debian.org/?p=collab-maint/ca-certificates.git Package: ca-certificates Architecture: all +Pre-Depends: dpkg (= 1.16.1) This only guarantees that this dpkg version will be configured before installing this package, but not that the currently running dpkg will be that one version, so the upgrade from squeeze can still fail due to parser errors for the unknown triggers directive. I've actually tested this, and it hasn't been a problem. I suppose the only way you could get it to be one is if you were manually using dpkg. I was thinking about non-apt frontends, not just using dpkg directly. The main issue here is that the metadata does not guarantee what you want to do, and as such other non-apt frontends are not required to prepare the upgrade transaction in the same way as apt (and I'm not even sure it would be safe to expect that behaviour from apt, even if it's what it's currently doing). It'd probably be a good idea to discuss and try to come up with a way to notify dpkg and/or frontends, that they might need to restart themselves because a package requires one of its new features, so that some of those can be deployed w/o having to wait a full release cycle. I've added this to my TODO list for after wheezy. If that's really the case, then it basically means that no package in wheezy can use the noawait triggers at all. Yes, that's always been the case for lots of dpkg features, that we have to wait for a new release cycle before being able to use them. And that's been the case for the noawait directives up to now, I've just checked the lintian lab, and this is the only package using them. Regards, Guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#690204: Bug#537051: Add no-await trigger support and Breaks to fix ca-certificates-java breakage
On Fri, 2012-11-30 at 11:24:48 -0800, Don Armstrong wrote: On Fri, 30 Nov 2012, Guillem Jover wrote: In any case, regardless of this, semantics-wise I don't think it makes much sense to have both of them present. I'll be fixing the deb-triggers(5) man page to clarify this. I'm not sure I follow you here; allowing for both of them means that the triggering package can define whether the triggered feature is crucial, or not essential to its function. Doing it the other way around means that only the triggered package can define whether the feature is crucial or not essential. This is already supported, and now having rechecked the patch in more detail and having paid attention :), you are already making use of it by calling dpkg-trigger with --no-await, which activates a trigger w/o marking the activating package as needing to await processing. You have to think about the interest* directives as default behaviour, so if the directive is synchronous, you can still activate it asynchronously (with dpkg-trigger --noawait). If the interested package marks it as noawait then it means it's really never needed for triggering packages to await processing; an example of this latter case could be man page cache regeneration. Those default directives are also needed so that implicit triggering, like the ones activated via path changes by dpkg itself during unpack/remove/etc, can behave in a way or another, but there needs to be only one, two directives does not make sense, which one would apply then? So, it really looks like these packages were behaving like if they only had «interest foo» (due to the stomping I mentioned before) and the trigger was asynchronous anyway due to the dpkg-trigger call, so you don't really need to use interest-noawait support nor the dpkg Pre-Depends anyway, and the possible upgrade issues just disappear. It'd probably be a good idea to discuss and try to come up with a way to notify dpkg and/or frontends, that they might need to restart themselves because a package requires one of its new features, so that some of those can be deployed w/o having to wait a full release cycle. I've added this to my TODO list for after wheezy. That should actually be pretty easy for the frontends just to handle. If a package pre-depends on dpkg or some other essential package required for the upgrade, it should do those upgrades first, then do the rest of them. dpkg doesn't really need to do anything. That's one of the solutions that had crossed my mind too, but it might be too restritive in how frontends might need to prepare transactions, so it might be too heavy handed. The only problem here is just dpkg (perhaps the frontends itself too, but nothing else really), as the running process that gets out of sync with its own database, but asking frontends to hardcode a special case for the dpkg package might not be liked, and instead a metadata-based solution might be preferred, that's why I mentioned that this would need discussion. :) Thanks, Guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#690204: Bug#537051: Add no-await trigger support and Breaks to fix ca-certificates-java breakage
On Fri, 2012-11-30 at 14:44:03 -0800, Don Armstrong wrote: On Fri, 30 Nov 2012, Guillem Jover wrote: You have to think about the interest* directives as default behaviour, so if the directive is synchronous, you can still activate it asynchronously (with dpkg-trigger --noawait). Ah, awesome. Ok, this wasn't clear at all to me from reading the documentation. Let me try to rephrase to see if I've understood you correctly: interest triggername just means that by default a dpkg-trigger will be considered to be a synchronous trigger; if dpkg-trigger is called with --noawait, then it does it asynchronously. And interest-noawait triggername mean that the trigger will always be asynchronous no matter how dpkg-trigger is called or the activate trigger is listed. Correct. Assuming I understand this properly now, I think I'll whip up a patch to the git repository which explains this in more detail in the manpage. Cool, that'd be wonderful, I'll happily queue it for 1.17.x. If you are going to mention dpkg-trigger (an explicit trigger) it would be nice to also mention implicit triggers too. And it probably also makes sense to avoid using the “(a)synchronous” language when talking about triggers as that is not used in any other place when talking about them. So, it really looks like these packages were behaving like if they only had «interest foo» (due to the stomping I mentioned before) and the trigger was asynchronous anyway due to the dpkg-trigger call, so you don't really need to use interest-noawait support nor the dpkg Pre-Depends anyway, and the possible upgrade issues just disappear. Ok. Do we still need a dependency for dpkg-trigger --no-await to work? Nope, «dpkg-trigger --no-await» is supported since dpkg 1.14.17, the version that introduced triggers. That's one of the solutions that had crossed my mind too, but it might be too restritive in how frontends might need to prepare transactions, so it might be too heavy handed. The only problem here is just dpkg (perhaps the frontends itself too, but nothing else really), as the running process that gets out of sync with its own database, but asking frontends to hardcode a special case for the dpkg package might not be liked, and instead a metadata-based solution might be preferred, that's why I mentioned that this would need discussion. :) Yeah. Another crazy option would be for dpkg to recognize that it was upgrading itself, and rexec itself after upgrading itself if it has more thins to do. But that's probably even more kinds of crazy. Yes, this also crossed my mind :). In principle it should not require that much code jugling, but I'd have to review the code paths to make sure how much state might need to be preserved (like status-fds) or flushed to disk if it's still not there, etc. It still might be too heavy handed, because a package Pre-Depending on dpkg might need features provided by one of the other tools (like dpkg-query), which would not require the dpkg process to restart, and we might still want to have control over when this happens. Thanks, Guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#690204: Bug#537051: Add no-await trigger support and Breaks to fix ca-certificates-java breakage
Hi! On Tue, 2012-11-13 at 13:18:37 -0800, Don Armstrong wrote: Control: tag -1 patch Please find the attached patches which fix this problem. I've tested them a bit, but please review them. ca-certificates (20121112+nmu1) unstable; urgency=low * Non-maintainer upload * Breaks ca-certificates-java (20121112+nmu1); partially fixing #537051. * Provide update-ca-certificates and update-ca-certificates-fresh triggers. * Call the triggers using no-await so that the configuration files from the newer version of ca-certificates-java are in places before the upgrade. Closes: #537051. diff --git a/debian/ca-certificates.triggers b/debian/ca-certificates.triggers new file mode 100644 index 000..14dec6e --- /dev/null +++ b/debian/ca-certificates.triggers @@ -0,0 +1,4 @@ +interest-noawait update-ca-certificates +interest-noawait update-ca-certificates-fresh As these are not supported by squeeze's dpkg, this can cause upgrade problems (see below). +interest update-ca-certificates +interest update-ca-certificates-fresh (OOC why the duplicates?) diff --git a/debian/control b/debian/control index 5ef776e..8f84573 100644 --- a/debian/control +++ b/debian/control @@ -13,9 +13,11 @@ Vcs-Browser: http://git.debian.org/?p=collab-maint/ca-certificates.git Package: ca-certificates Architecture: all +Pre-Depends: dpkg (= 1.16.1) This only guarantees that this dpkg version will be configured before installing this package, but not that the currently running dpkg will be that one version, so the upgrade from squeeze can still fail due to parser errors for the unknown triggers directive. diff --git a/debian/postinst b/debian/postinst index 198c57e..9964e27 100644 --- a/debian/postinst +++ b/debian/postinst @@ -142,12 +142,29 @@ EOF # fix bogus symlink to ca-certificates.crt on upgrades; see # Debian #643667; drop after wheezy if dpkg --compare-versions $2 lt-nl 20111025; then - update-ca-certificates --fresh + dpkg-trigger --no-await update-ca-certificates-fresh else - update-ca-certificates + dpkg-trigger --no-await update-ca-certificates fi ;; This is of course fine, though. Thanks, Guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#668400: /usr/bin/apt-get: Apt-get purge/remove delete file behind symlink
On Wed, 2012-04-11 at 17:47:15 +0200, Rafal Kaminski wrote: Package: apt Version: 0.8.15.10 Severity: normal File: /usr/bin/apt-get I found some bug or feature apt-get. I've installed tomcat7 and in folder /etc/tomcat7 I put symlink to diff. folder - like to /data/file1. Then in /etc/tomcat7 I had symlink file1. When I made apt-get remove tomcat7 or apt-get remove --purge tomcat7 - apt-get didn't remove symlink from /etc/tomcat7, BUT REMOVE file from /data. After apt-get remove I hadn't file1 in /data/file1. Given the directory removals in tomcat7's postrm script I'm inclined to think this is tomcat7 (and tomcat6) fault, but it would be helpful to know what exactly did you symlink, was it the /etc/tomcat7 directory itself, one of the conffiles inside? Something else? regards, guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#653622: bug 653622
Hi! [ Just saw this mail now, as bug reporters are not automatically subscribed to bugs, if not addressed explicitly they don't see replies. ] On Sat, 2012-01-07 at 11:22:07 +0800, TripleA Developers wrote: Could you guys explain this a little bit better for someone who is not very familiar with OS's and especially not familiar with Linux? Please be detailed and patient, and I will try to address the problem. On Unix systems the user directory is called the “home directory”, there, applications can place configuration files or other directories, but the convention is to use dot files or directories. On Unix any filename which starts with a dot will be automatically hidden from normal directory listing (for example «.hidden-file»), which is very convinient as those are not really generally interesting. But they can be explicitly listed with some options on the command-line or special buttons/switches on graphical applications. So for triplea, the ideal on Unix (this includes GNU/Linux, Mac OS X, etc.) would be to use $HOME/.triplea/ or better yet use the environment variables defined in http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html to see where to place those files and directories. Please give that spec a look, it's not too long. Any further question I'll be happy to clarify. thanks, guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#653622: triplea: Creates non-hidden state directory
Package: triplea Version: 1.3.2.2-2 Severity: normal Hi! This game creates a non-hidden state directory (~/triplea/) on the home directory. It should create it as a dot dir on the home dir (preferably following the XDG base dir spec [0]). [0] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html The culprit seems to be: src/games/strategy/engine/framework/GameRunner.java:getUserRootFolder() regards, guillem __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#545802: libjgrapht0.6-java-link: Unusual name for a default package
Hi! On Wed, 2009-09-09 at 22:02:04 +0200, Torsten Werner wrote: On Wed, Sep 9, 2009 at 11:08 AM, Guillem Joverguil...@debian.org wrote: This package has a non-conventional name for a default package, the -link postfix is a bit confusing. Could you rename it to libjgrapht-java instead? Or is there a problem with using that one? yes, both such packages are just bloat. Why not moving the unversioned symlink and the unversioned Provides field to the versioned libjgrapht0.6-java package? Hmm, ah ok after enabling contrib I see this now more clearly. There's: VersionSource Binary 0.6.0-5libjgrapht-java libjgrapht-java libjgrapht0.6-java 0.6.0-8libjgrapht0.6-java libjgrapht0.6-java-link libjgrapht0.6-java 0.7.3-2libjgrapht-java libjgrapht-java libjgrapht0.7-java Version 0.6.0-8 is the only one in main, the rest are in contrib. Isn't the 0.7 version in contrib supposed to be moved to main also? So, if there's supposed to be different versions of the package (0.6, 0.7, 0.8, etc), I think preserving the unversioned package makes sense, otherwise the versioned ones cannot be co-installed. And probably moving the unversioned binary package from the old source package to the new one, once the default has to be switched (0.6 → 0.7). BTW, who files the removal request against the now obsolete libjgrapht-java source package? But that package contains the latest version 0.7, doesn't it? regards, guillem ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#545802: libjgrapht0.6-java-link: Unusual name for a default package
Package: libjgrapht0.6-java-link Version: 0.6.0-8 Severity: normal Hi! This package has a non-conventional name for a default package, the -link postfix is a bit confusing. Could you rename it to libjgrapht-java instead? Or is there a problem with using that one? regards, guillem ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
