Bug#759716: Drop unused php-db dependency
On Sun, August 31, 2014 14:43, Olivier Berger wrote: Hi. On Fri, Aug 29, 2014 at 07:55:10PM +0200, Thijs Kinkhorst wrote: Hi Olivier, Please drop the dependency on php-db of php-cas, because as far as I can see it is not needed at all. I've marked this as important because php-cas has been removed from jessie because of this dependency, it may happen again because php-db is not really maintained. I've noticed the removal from jessie for a while, but thanks for the heads up. AFAIR, php-cas may need a DB for so called PGT storage, but I'm not really clear on whether anyone really used this with the Debian package actually :-/ The source does not seem to include DB.php anywhere, so I think that kind of settles whether it is used. The upstream docs also mention it nowhere as a requirement. I'm not sure it's used in most cases, so I'm a bit puzzled on how to solve this, besides my lack of interest for CAS these days (see my RFA : #757231). Any suggestion welcome. At the very least you could downgrade the Depends to a Recommends. But I think you can just drop it. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760046: apt-file: rapt-file exits with error
Hi, On Sun, August 31, 2014 11:54, Morten Bo Johansen wrote: Trying to use rapt-file to search for a file produces the following error message: urllib2.URLError: urlopen error [Errno -2] Name or service not known It seems dde.debian.net no longer exists. Enrico, do you know what happened to it? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759716: Drop unused php-db dependency
Package: php-cas Severity: important Hi Olivier, Please drop the dependency on php-db of php-cas, because as far as I can see it is not needed at all. I've marked this as important because php-cas has been removed from jessie because of this dependency, it may happen again because php-db is not really maintained. thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759718: php-cas needs to urlencode all tickets (CVE-2014-4172)
Package: php-cas Severity: serious Tags: fixed-upstream Hi Olivier, php-cas 1.3.3 fixes security issue CVE-2014-4172: urlencode all tickets. Can you please upgrade php-cas in Debian to this version? thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759486: creates invalid browse link when no vcs-browser field defined
Package: tracker.debian.org Severity: minor Hi, When a package has a Vcs-something field but not a Vcs-Browser field, the tracker does display a browse link but with an empty href: a href=https://svn.non-gnu.uvt.nl/uvt-dev/trunk/package/modmellon/;Subversion/a (a href=Browse/a) This can at the time of writing be seen here: https://tracker.debian.org/pkg/libapache2-mod-auth-mellon (but I'm migrating this package to another place soon so it may not last). Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730057: Remove FreeSCI from Debian
severity 730057 serious retitle 730057 This package shoudl be removed thanks Hoi Bas, freesci is more or less dead upstream and has already attracted two NMUs. The freesci code was the basis for the SCI support in ScummVM (and there were fixes on top of it). So I suggest we remove freesci in favour of ScummVM? I think this accurately describes the situation; FreeSCI is not developed separately anymore but has been merged into ScummVM, so it makes sense to me to not ship FreeSCI anymore starting with jessie. Agreed? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#725411: gnupg: gpg blindly imports keys from keyserver responses
Hi Paul, tags 725411 + security This bug has been fixed in GnuPG 1.4.17. Although it's a good robustness and anti-keyring-polution measure, I don't think it's an acute security issue in stable that needs to be fixed in a DSA, because the threat model is unclear to me. I think it's well understood that keyservers are not trustworthy per se and that the web of trust is to be used to verify which keys are to be trusted. If you need to rely on a keyserver not being rogue you've already lost. Any key injected in such a download would still not pass web of trust validation. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754693: RFH action claims that package is not in unstable
Package: tracker.debian.org Severity: normal Hi, https://tracker.debian.org/pkg/gnupg lists an action item called RFH. Clicking the ? behind it gives the text: Severity: normal Created: 2014-07-02 Last Updated: 2014-07-02 The WNPP database contains an RFH (Request For Help) entry for this package. This is probably an error, as it is neither part of unstable nor experimental. Please see bug number #660685 for more information. The package clearly is in unstable and the tracker knows about this fact, as seen from the columns on the left. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754694: A new upstream version is available not up to date
Package: tracker.debian.org Severity: normal Hi, https://tracker.debian.org/pkg/gnupg reports an action item A new upstream version is available: 1.4.18. Severity: high Created: 2014-07-13 Last Updated: 2014-07-13 A new upstream version 1.4.18 is available, you should consider packaging it. It claims to be last updated on 13 July, but the new upstream has been in sid since 2 July, and the tracker obviously knows this since it lists that info the boxes left and below to this info. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733134: [Pkg-mailman-hackers] Bug#733134: mailman wrapper script runs as group daemon instead of Debian-exim
Op donderdag 26 december 2013 08:25:02 schreef Bernhard Kuemel: I still have the bug in 1:2.1.15-1 (wheezy (stable) and 1:2.1.16-1 (sid backport to wheezy). This is a duplicate of the archived bug #228935 from 22 Jan 2004. The proposed solution was: Read README.Exim and follow the instructions there. This file does not exist any more. I tried the instructions in /usr/share/doc/mailman/README.Exim4.Debian.gz , but the problem is still there. It still uses the aliases in /etc/aliases. Mailman does not work. Why is this bug still there when it was known in 2004? From the bug report, I'm unsure about the exact nature of the problem. There have not been many complaints since 2004 about Mailman with Exim so I guess it works - I do not use Exim myself. If there's an Exim problem, I suggest that an Exim user (you?) debugs it and lets me know how I need to change the documentation. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#732932: [Pkg-mailman-hackers] Bug#732932: Info received (Bug#732932: Acknowledgement (mailman: Mailman upgrade squeeze-wheezy fails because /var/lock/mailman dir does not exist))
Op maandag 23 december 2013 12:06:58 schreef Chris Stephenson: * What exactly did you do (or not do) that was effective (or ineffective)? The install failed with a Python stack dump and a report that /var/lib/mailman/lock did not exist. This was a symbolic link to /var/lock/mailman. * What was the outcome of this action? I created the /var/lock/mailman directory and reran the install of mailman. The stack dump error went away. There was another error that I have reported separately Why would that directory not exist? It is created by the init script, so if Mailman was running on your Squeeze host, it should be there. I've also not seen this on my upgrades. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#751418: irssiproxy does not work with bindv6only = 1
On Tue, July 8, 2014 14:50, Gerfried Fuchs wrote: * Thijs Kinkhorst th...@debian.org [2014-06-12 13:31:13 CEST]: When using irssiproxy with kernel setting bindv6only = 1 (which is the default in Debain), irssi only binds to IPv6 and no longer accepts IPv4 connections to the proxy. The only reason I found to fix this is to disable bindv6only system-wide which is obviously undesirable. Do I misunderstand something here? The kernel says that things should bind to v6 only, but you want it to ignore that and bind to v4, too? Or do I misinterpret that kernel setting? Can you be more specific? Either one wants stuff to bindv6only or one doesn't, I am uncertain why an application should ignore the kernel preference here? The short summary of the bug is: On a default Debian installation, irssiproxy is only reachable on IPv6, not IPv4., so it's not something I explicitly chose to change. The reason is that Debian (as do other OS'es BTW) sets the kernel option bindv6only to true. All the background can be read in this post by Marco: https://lists.debian.org/debian-devel/2009/10/msg00541.html but it boils down that if you would bind an AF_INET6 listening socket to in your application, you used to get IPv4 for free. With the setting changed, the kernel behaves differently and the application needs to explicitly create the AF_INET socket for IPv4 traffic. Nearly all applications do this, it seems irssiproxy still needs to be changed to account for this. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753310: opu: ia32-libs/20140630 ia32-libs-gtk/20140630
Op dinsdag 8 juli 2014 20:52:08 schreef Adam D. Barratt: Unfortunately, something appears to have gone wrong with the ia32-libs-gtk upload and I've flagged that one for rejection. Specifically, the entire debdiff is: Right, what went wrong is that there are 0 updates for ia32-libs-gtk since the last release and in my workflow I didn't expect that and created a borked update. Sorry for that - with the ia32-libs upload accepted we're done. Thijs signature.asc Description: This is a digitally signed message part.
Bug#753985: [Pkg-gnupg-maint] Bug#753985: gpgv-udeb: fails to validate Release files (missing sha256 support)
Op maandag 7 juli 2014 11:36:49 schreef Didier 'OdyX' Raboud: b) Thankfully we don't need to consider the backup plan mentioned in a) since all we need is enabling sha256 support. Currently, Release files include MD5+SHA1+SHA256. You'll find a tested patch attached. (This means a whole installation using a netboot-gtk image.) I can confirm that Cyril's patch fixes gpgv.exe usage within win32- loader. Merci beaucoup a vous deux pour votre aide excellente dans ce cas! J'ai a l'heure téĺéchargé un nouveau version du gnupg. Cordialement, Thijs signature.asc Description: This is a digitally signed message part.
Bug#753310: opu: ia32-libs/20140630 ia32-libs-gtk/20140630
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: opu Hi RT, In preparation of the upcoming Squeeze point release I've prepared updated versions of ia32-libs and ia32-libs-gtk, as usual. The changelogs are below. Is it ok to upload? Cheers, Thijs ia32-libs (20140630) squeeze-proposed-updates; urgency=low * Packages updated [ cups (1.4.4-7+squeeze4) oldstable-security; urgency=high ] * Backport security fix from cups-filters 1.0.47: pdftoopvp: SECURITY FIX for CVE-2013-6474, CVE-2013-6475, and CVE-2013-6476: Introduction of gmallocn and gmallocn3 to protect against arbitrary code execution with the privileges of the lp user via malicious PDF files. Also restrict the directory from where OPVP drivers can get loaded (#741333) [ curl (7.21.0-2.1+squeeze8) squeeze-security; urgency=medium ] * Fix multiple security issues (#742728): - Fix connection re-use when using different log-in credentials as per CVE-2014-0138 http://curl.haxx.se/docs/adv_20140326A.html - Reject IP address wildcard matches as per CVE-2014-0139 http://curl.haxx.se/docs/adv_20140326B.html * Set urgency=high accordingly [ gnutls26 (2.8.6-1+squeeze3) oldstable-security; urgency=high ] * 22_gnutls-2.8.5-cve-2014-0092.patch by Nikos Mavrogiannopoulos: Fix certificate validation issue. CVE-2014-0092 -- Thijs Kinkhorst th...@debian.org Mon, 30 Jun 2014 13:45:39 +0200 ia32-libs-gtk (20140630) squeeze-proposed-updates; urgency=low * Packages updated [ pixman (0.16.4-1+deb6u1) squeeze-security; urgency=high ] * pixman_trapezoid_valid(): Fix underflow when bottom is close to MIN_INT Addresses CVE-2013-6425 -- Thijs Kinkhorst th...@debian.org Fri, 31 Jan 2014 11:18:31 +0100 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745408: [Pkg-gnupg-maint] Bug#745408: [gnupg] Source package contains non-free IETF RFC/I-D
severity 745408 important tags 745408 moreinfo thanks Op maandag 21 april 2014 16:20:45 schreef bastien ROUCARIES: This source package contains the following files from the IETF under non-free license terms: doc/OpenPGP This file only referances an IETF RFC, so I do not believe it is non-free. Can you elaborate on why you think this is the case? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#752086: [php-maint] Bug#752086: [php5] Please do not request users to read UPGRADING in NEWS.Debian
On Thu, June 19, 2014 16:10, Filipus Klutiero wrote: Package: php5 Version: 5.6.0~beta4+dfsg-4 Severity: wishlist The 5.6.0~beta4+dfsg-2 changelog entry reads: We shouldn't request users to read the full upgrade notes for 2 reasons: 1. We have nothing to gain from users reading that. We should simply inform them for their own good. So we have nothing to gain from users reading upgrade notes but we should simply inform them? This is an internal contradiction: we shouldn't have users read upgrade nodes but they should know about upgrade issues. Right. 2. Even users usually don't need to read the full upgrade notes. Only a minority of developers want to read the full upgrade notes. Even the backwards-incompatible changes don't need to be read on many systems which only use packaged PHP scripts. I'm fairly certain from experience that the vast majority of users are running non-packaged PHP on their systems, which is a completely normal use case. They should be informed of the changes in PHP versions. I see no issue here. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751877: exclude itself from scanned processes
Package: needrestart Version: 0.9-1 Severity: wishlist Hi, On my system needrestart seems to spend the majority of its time on scanning /usr/bin/perl. This may be justifyable, except that there is no regular proces on this machine that uses perl. Inspection turns out that this /usr/bin/perl is actually the perl used by needrestart itself. It would be nice if needrestart could exclude its own processes from the list to scan, since scanning them is inherently useless. Cheers, Thijs -- Package-specific info: needrestart output: Scanning processes No services required to be restarted. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13.7 (SMP w/2 CPU cores) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 Shell: /bin/sh linked to /bin/bash Versions of packages needrestart depends on: ii libmodule-find-perl0.12-1 ii libmodule-scandeps-perl1.13-1 ii libproc-processtable-perl 0.50-1 ii libsort-naturally-perl 1.03-1 ii perl 5.18.2-4 needrestart recommends no packages. needrestart suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733564: pu: apache2 with ECDHE support
On Mon, June 16, 2014 00:06, Adam D. Barratt wrote: Control: tags -1 + pending On Sun, 2014-05-25 at 17:55 +0200, Stefan Fritsch wrote: I have just uploaded apache2_2.2.22-13+deb7u2: Flagged for acceptance; sorry for the delay. apache2 (2.2.22-13+deb7u2) wheezy; urgency=medium * Backport support for SSL ECC keys and ECDH ciphers. For anyone following the bug log, testing of the above change before the point release would be much appreciated. Running this version successfully on two machines, but maybe more interesting: we've been running a build of the same upstream patch on top of deb7u1 on about a hundred machines since a few months. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749795: apt: no authentication checks for source packages
Hi, apt: no authentication checks for source packages The Debian security team has assigned CVE-2014-0478 to this issue. APT developers: we should fix this in wheezy. Are you able to provide an update for wheezy for this issue? As for squeeze, if it's not too much extra work it would be great if an update for squeeze was also possible. Perhaps it could also even include the fix for https://security-tracker.debian.org/tracker/CVE-2011-3634? Let us know. Thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749795: apt: no authentication checks for source packages
Hi Michael, On Thu, June 12, 2014 13:52, Michael Vogt wrote: On Thu, Jun 12, 2014 at 11:44:20AM +0200, Thijs Kinkhorst wrote: apt: no authentication checks for source packages The Debian security team has assigned CVE-2014-0478 to this issue. APT developers: we should fix this in wheezy. Are you able to provide an update for wheezy for this issue? [..] Attached is the fix for wheezy with a regression test, a additional test run is very welcome (works in my wheezy container both the testcase and a manual test when removing /var/lib/apt/lists/*Release*). Thanks! I've built it and verified that it works for me aswell (and solves the issue). For the changelog: you need to target wheezy-security, and may want to add closes: #749795 and urgency=high. With these changes you can upload to security-master.debian.org. Make sure to build with full source (-sa) as wheezy-security doesn't yet have the orig tarball. The patch seems to apply rather cleanly to squeeze, so an update for that would be nice if possible. Fixing CVE-2011-3634 aswell would be nice if simple to do but not essential. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751418: irssiproxy does not work with bindv6only = 1
Package: irssi Version: 0.8.15-5+b1 Severity: normal Tags: ipv6 Hi, When using irssiproxy with kernel setting bindv6only = 1 (which is the default in Debain), irssi only binds to IPv6 and no longer accepts IPv4 connections to the proxy. The only reason I found to fix this is to disable bindv6only system-wide which is obviously undesirable. Cheers, Thijs -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13.7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages irssi depends on: ii libc6 2.19-1 ii libglib2.0-02.40.0-3 ii libncurses5 5.9+20140118-1 ii libperl5.18 5.18.2-4 ii libssl1.0.0 1.0.1h-2 ii libtinfo5 5.9+20140118-1 ii perl5.18.2-4 ii perl-base [perlapi-5.18.1] 5.18.2-4 irssi recommends no packages. Versions of packages irssi suggests: ii irssi-scripts 20131030 -- 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#750682: [php-maint] Bug#750682: [php5] Experimental warning in NEWS.Debian
severity 750682 normal tags 750682 pending thanks On Thu, June 5, 2014 18:36, Filipus Klutiero wrote: Package: php5 Version: 5.6.0~beta3+dfsg-2 Severity: serious NEWS.Debian contains the following entry: php5 (5.6.0~alpha1+dfsg-1) experimental; urgency=medium * THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION! * PHP 5.6.0alpha1 comes with new features such as (incomplete list) : + constant scalar expressions, + variadic functions, + argument unpacking, + support for large(2GiB) file uploads, + SSL/TLS improvements, + a new command line debugger called phpdbg. -- OndÅej Surý ond...@debian.org Tue, 28 Jan 2014 11:02:20 +0100 I'm not sure from what angle this should be taken. On one hand, although the version which reached testing is no longer alpha, it's still very early. The current release's announcement had a similar disclaimer: http://php.net/archive/2014.php#id2014-05-15-1 On the other hand, we have a history of aggressive PHP packaging. Even the last major version was packaged at RC stage. As far as I know/remember, that went rather well, so we might be as lucky. Alpha versions have been packaged since January. Thanks. This message was already removed in git so it won't display on jessie upgrades after the next upload. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750682: [php-maint] Bug#750682: Bug#750682: Bug#750682: [php5] Experimental warning in NEWS.Debian
I am curious where the bug is here... The message is very much still true and will be/should be removed when upstream reach RC phase. This should not be used in production (and that also holds for Debian testing - it should not be used for production). Yes, testing should in princple not be used for production, but it would get tiresome very fast if every package in testing produced warnings about this fact. I believe that our users are more than able to judge what a version number with beta in it means and whether they think it's suitable for their use case, be it production or not. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747697: [LCFC] templates://debian-security-support/{debian-security-support.templates}
On Wed, May 28, 2014 06:39, Christian PERRIER wrote: This is the last call for comments for the review of debconf templates for debian-security-support. From debian/control: for which support has had to be limited The form 'has had to be' seems contructed to me and also general writing advice advises against using the passive form. Can we reword that to something simpler and active, like for which Debian had to limit security support? The two Debconf templates miss a bit of what now? information, in my opinion. Especially the /limited one: as an admin, I get the message that one of my packages is now in 'limited' support, where can I find out what that means? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748758: debconf progress indicator may be overkill
Package: needrestart Version: 0.9-1 Severity: wishlist Hi, Needrestart sports a progress indicator in debconf while it tries to find services that need a restart. However, this scanning for services is most of the time very fast and the full repainting of the screen actually costs more time than the scanning does. When an upgrade has no impact on running services, it results in needless 'flashing' of the screen. I would recommend to only output Scanning processes... on stdout and load and invoke the whole debconf infrastructure only when there's actual prompting to be done. Cheers, Thijs -- Package-specific info: needrestart output: Scanning processes No services required to be restarted. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13.7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages needrestart depends on: ii libmodule-find-perl0.12-1 ii libmodule-scandeps-perl1.13-1 ii libproc-processtable-perl 0.50-1 ii libsort-naturally-perl 1.02-1 ii perl 5.18.2-4 needrestart recommends no packages. needrestart 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#747376: Requesting debian-lts-{changes,announce} mailing lists
Hi, For the Squeeze LTS project, we would like two Debian mailing lists setup to help communicate changes out to the wider LTS userbase. Name: debian-lts-changes Name: debian-lts-announce I support creation of these lists for the LTS effort. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#747084: must not be in jessie without proper long term support
Package: moodle Version: 2.6.2-1 Severity: serious At the time of writing this, I am the single active maintainer on the Moodle package in unstable/testing. The time I spend on the package I can spend at work because we're using the package in its current form as it is in unstable. It's however unlikely that I can commit to supporting Moodle in a stable release in worktime. In discussion with the Security Team it was concluded that a large package like Moodle needs some kind of concrete prospect of being maintained in stable if we want to include it in the release. While there are no other maintainers, that is not the case. Therefore, Moodle should not migrate to Jessie until that is solved. This bug can be closed when there's an active maintainer or team who is willing to keep track of the frequent security issues and wants to prepare updates for the Jessie lifetime. Ideally, this would be based on the upstream 2.7 release which I understand is planned as an LTS. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746715: Shocking read ...
On Sun, May 4, 2014 10:33, Andreas Barth wrote: * Kurt Roeckx (k...@roeckx.be) [140504 01:03]: On Sat, May 03, 2014 at 06:53:29PM +0100, Ian Jackson wrote: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. Did the TC previously agree that we should support multiple init systems? As far as I know only a default was selected, and I'm not sure if something like that this was ever voted on or not. We agreed but didn't put that into the resolution, based on this is too obvious. Seems it wasn't. Don't you think that both Steve and yourself are generalizing a bit hastily, since there has just been a single incident to date? Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746993: description could indicate it also includes Maintainers keyring
Package: debian-keyring Version: 2013.04.21 Severity: minor Hi, The current package description is: GnuPG keys of Debian Developers The Debian project wants developers to digitally sign the announcements of their packages with GnuPG, to protect against forgeries. This package contains keyrings of GnuPG and keys of developers. It could be augmented to mention that it also contains the DM keyring. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746594: [moodle-packaging] Bug#746594: Bug#746594: Embedded OLE is not DFSG-compliant (PHP-2.02)
Hi Dan, On Fri, May 2, 2014 04:02, Dan Poltawski wrote: On 2 May 2014 02:46, David Prévot taf...@debian.org wrote: The embedded PHPExcel copy (#718585) embeds OLE (#487558) which is not DFSG compliant (PHP-2.02)[1,2]. We have removed this library in upstream in version 2.6: https://tracker.moodle.org/browse/MDL-42381 http://git.moodle.org/gw?p=moodle.git;a=commit;h=383d414478f1f3129f243e4d047d4fa06b9a3b8f It wasn't used and can be safely deleted. Is there another instance of this library or is it a packaging problem? It's indeeed a second copy, it's under lib/phpexcel/PHPExcel/Shared/ Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745633: enables GeoIP lookups by default for all requests serverwide
Package: libapache2-mod-geoip Version: 1.2.7-1 Severity: normal Tags: patch Hi, The module installs a file geoip.conf in mods-available, which by default enables GeoIP lookups serverwide; that is, for every request to this server a GeoIP database lookup will be done. This is not recommended by MaxMind and also not logical: a server may have many vhosts and only a small subset of hosts or paths may actually need the GeoIP information in the request. Therefore, it's much better to enable it selectively for those vhosts/locations/directories where it will actually be used. Here's a pull request to fix this issue: https://github.com/prachpub/libapache2-mod-geoip/pull/1 Cheers, Thijs -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736494: About #736494
On Fri, April 18, 2014 17:46, Adam D. Barratt wrote: On 2014-04-16 16:18, William Dauchy wrote: On Apr16 11:06, Adam D. Barratt wrote: On a related note, it would be appreciated if comments such as cleanup series were more verbose in future, as it appears to have involved removing enabled patches (which ones hopes have been replaced by newer patches) as well as those which were already disabled. I will be more versbose on those; it was commented patches in series, so not used; this modification has also been made in unstable. Thanks. Just a gentle reminder, the window for getting an upload in to the 7.5 point release closes over the weekend. Thanks for the reminder. It should have been uploaded less than an hour ago. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736494: About #736494
Hi Adam, On Sun, April 13, 2014 14:39, Adam D. Barratt wrote: On Sun, 2014-04-13 at 13:58 +0200, William Dauchy wrote: Is there someone available to validate this package? Lots of present fixes are more than needed to have an usable version of php in production. Such comments really aren't that helpful. It's entirely possible to have an usable version of php in production using the current package in wheezy, or it wouldn't have made it in to wheezy in the first place and no-one would have been using it on stable systems for the past year. (That's not to say that some people aren't adversely affected by issues in the current package, but that's far from your claim that it's generally unusable.) I realise you've put a lot of effort in to the patch, and that's obviously appreciated, but a diff for stable of the size 46 files changed, 4303 insertions(+), 372 deletions(-) where most of the diff appears to be actual changes (as opposed to translations, or autogenerated files) is non-trivial to review, particularly when people are already short on time. :( I fully understand the lack of manpower. But also, obviously the update fixes significant bugs and has seen lots of real world testing, probably more than many of the other packages proposed for a stable update. Is there a model or approach you can suggest that would work for the SRMs? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744923: notify user about services to be restarted (checkrestart-like)
Package: apt Severity: wishlist Hi, When library packages are upgraded, services using those libraries need to be restarted for the change to take effect. A default Debian installation does nothing to inform the user about that. Some packages have implemented their own service restarting check in postinst, all done differently and as in the case of OpenSSL based on an ever incomplete list. The recent security issue in the latter has again proven the importance of such functionality. checkrestart exists to handle this case, but it's not installed by default, nor is it run automatically when it is. It makes sense to me that such a task is handled by a high level package manager. Having such functionality in the package manager would definitely improve the security of a Debian system. Is this something you'd consider? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744018: Wordpress 3.8.2 fixes two vulnerabilities [CVE-2014-0165 CVE-2014-0166]
Package: wordpress Severity: serious Tags: security fixed-upstream patch Hi, Wordpress 3.8.2 was released which fixes two security issues and several more bugs. http://wordpress.org/news/2014/04/wordpress-3-8-2/ CVE-2014-0165 Wordpress privilege escalation: prevent contributors from publishing posts CVE-2014-0166 Wordpress potential authentication cookie forgery Can you see to it that this is fixed in unstable? I'm not sure if these vulnerabilities warrant an update to stable on their own, can you advise? Thanks, Thijs signature.asc Description: This is a digitally signed message part.
Bug#744027: Please remove StartCom Certification Authority root certificate
Op woensdag 9 april 2014 15:07:08 schreef Klemens Baum: Package: ca-certificates Following the OpenSSL CVE-2014-0160 Heartbleed vulnerability [1,2], any certificate that was used with an vulnerable version of OpenSSL (I read somewhere 1/3 of the web) should be handled as it is compromised. Compromised certificates have to be replaced with new ones (new keys) and the old ones should be revoked. StartCom provides cheap and even free SSL certificates via the StartSSL brand. However, certificates revoking cerificates requires a US$ 24.90 fee [3]. Whatever you and I think of this pricing structure, people free to chose any provider of certificates that matches their pricing interest and that people are knowingly or should be knowlingly buying a product that has a certain price structure when they get the certificates in the first place. Revoking a certificate is generally primarily in the interest of the owner of said certificate so there is incentive to actually pay this fee. I do not believe it is Debian's place to pass judgement on which pricing scheme people should prefer, even if you and I personally rather pay up front and have no costs on revocation. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#742522: liblasso-perl: Not a CODE reference when using perl binding for Lasso
Hi Frederic, So indeed, it was just a compilation option bug... Do you think you can include this patch in next 2.4.0 ? Sure, I'll have it in the next upload and I'll see to get it included upstream. Can you please upload it over the coming days? I got an email that my package libapache2-mod-auth-mellon was scheduled for removal from jessie because of this RC bug. I can alternatively also make an NMU if desired. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743889: libssl1.0.0: libssl update does not cause applications that use it to restart
severity 743889 normal thanks Hi, We have code that checks some of the applications that need to be restarted, but it has a static list of packages to check and it's outdated. We're working on improving that list and providing an other update that will restart those services. I do not believe this is a grave bug in openssl. Debian has never claimed that 100% automatic upgrades are fully supported. Tools like checkrestart and needrestart exist for this reason; and the advisories from both Debian and CERT-CC explicitly mention the need to restart services. That some packages have lists of services to restart is an extra bonus, but since not all libraries have such functionality and there may be first or third party applications on the system, such a service is never a guarantee and the list can never be complete. Therefore, manual action and/or use of tools like checkrestart is always necessary. I'm leaving it at normal, not wishlist, because indeed if the package the package contains such functonality, it should aim to indeed have at least the most important ones in there. In the long term however, I have more faith in a solution where a high level package manager would check such things by default, instead of each individual package. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743842: [php-maint] Bug#743842: php5: uninstallable due to dependency loops
On Mon, April 7, 2014 11:49, Thorsten Glaser wrote: Please remove the Depends: php5-json from php itself. PHP should not depend on any of its extensions; people can rather do that themselves. (Actually, this is an issue in every version that had this Depends.) The dependency exists for transitional reasons: the functionality in the extension used to be in core, so the dependency guarantees that upgrades will not regress in functionality and applications will suddenly break. It can be weakened after one release cycle. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687693: Bug#741561: CAcert Licensing and Inclusion in Debian main
On Wed, April 2, 2014 05:01, Paul Tagliamonte wrote: These certs were removed from Debian a month ago. Perhaps you'd be interested in the recent thread on devel: https://lists.debian.org/debian-devel/2014/03/msg00375.html Thank you, but I think the maintainer knows very well that he removed the cert from his own package. That thread on d-devel, as we're used from that list, is not very productive and has wandered off into generic talk about encryption. There is currently discussion on whether these certificates could not be provided in another way for those that want them, without including them in the default set that every Debian system gets. A precondition to such a solution to be possible is that the licensing question is answered. As I've said in the bug log, I'm fully in agreement with Steve's argument that there is no copyright possible on any root certificate. However, I do have some sympathy to Michael's argument that if CAcert went to the trouble to explicitly make a license statement that forbids distributions to carry the root CA, maybe we should respect their wish, even if not legally obliged to do so. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741561: Should we open a bug to define wether #741561 is critical or wishlist?
On Tue, April 1, 2014 08:57, Klaus Ethgen wrote: Hmmm, for some reason someone changed the certificte of bugs.debian.org to a unknown certificate issuer so bts show does not work anymore. Who the hell is GANDI CA? You're kidding right, maybe because of the date? The Gandi CA is signed by the UTN Userfirst root CA which is in ca-certificates. Your whole argument revolves around the fact that a certificate must be in ca-certificates for you to be able to use/trust it. However, if the BTS uses a CA that is actually included in ca-certificates, you throw up your arms in the air? I'm really at a loss here. No, it's a wget problem that you can only specify to not check any certificate or check any (--no-check-certificate). There is no way to only skip this particular certificate from one side. There is. How to add certificates to the trusted store is documented in ca-certificates and has also been explained in this bug. I just gave the examples I use on a daily base. For normal users there are similar programs. However, I saw also mutt users that just gave a fuck about the fingerprint they are provided with and just accepted it. I agree that these users exist. However, if they accept anything, then they are by definition not influenced by what is in ca-certificates or not. Any attacker will already be able to control their connection. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741561: Proposal for resolution of this issue
Hi all, Please provide an additional binary package, e.g. ca-certificates-cacert that installs the cacert certificates without any further involvement of the user. I think this is the way we should go forward that will satisfy the users of CAcert and also satisfy the desire to keep that certificate no longer in the ca-certificates core package. We can just have ca-certificates build and extra binary package with only this certificate in it. ca-certificates would not depend or recommend this new package. As I've argued before, I'm fully in agreement with the fact that CAcert should no longer be in ca-certificates proper. I see that adding a separate binary package will not hurt that decision. I still acknowledge that CAcert is somewhat 'special', being the only community CA, so I think it's defendable that we create a separate binary package for it. And that we will not do the same for any next random root CA that comes by, so it will only be this one. Do the maintainers agree? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743175: zendframework: two security issues
Hi, CVE names have been assigned for these issues. The assignment is rather complicated. If you fix both issues in one upload it's ok to just mention that it addresses the 5 CVE's named below. http://framework.zend.com/security/advisory/ZF2014-01 CVE-2014-2681 - This CVE is for the lack of protection against XML External Entity injection attacks in some functions, because of the incomplete fix in CVE-2012-5657. It appears that this only affects Zend Framework 1.x, although that isn't critical to determining the number of CVE IDs. CVE-2014-2682 - This CVE is for the failure to consider that the libxml_disable_entity_loader setting is shared among threads in the PHP-FPM case. Again, the existence of this CVE means that the CVE-2012-5657 fix was incomplete. It appears that this affects more than just Zend Framework 1.x, although that isn't critical to determining the number of CVE IDs. CVE-2014-2683 - This CVE is for the lack of protection against XML Entity Expansion attacks in some functions, because of the incomplete fix in CVE-2012-6532. It appears that this also affects more than just Zend Framework 1.x, although that isn't critical to determining the number of CVE IDs. http://framework.zend.com/security/advisory/ZF2014-02 CVE-2014-2684 - This CVE is for the error in the consumer's verify method that leads to acceptance of wrongly sourced tokens. The same CVE is used for Zend Framework 1.x and ZendOpenId 2.x, even though the code is not identical. CVE-2014-2685 - This CVE is for the specification violation in which signing of a single parameter is incorrectly considered sufficient. Again, this CVE is for both Zend Framework 1.x and ZendOpenId 2.x. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741561: Proposal for resolution of this issue
On Tue, April 1, 2014 17:50, Bas van den Dikkenberg wrote: Please specify in witch part of distrobution license it states its non free, and what has to change in de license to make distrubtibol with ca-certificates There is an explanation here of why it's non free: https://fedoraproject.org/wiki/Licensing/CACert_Root_Distribution_License I would agree with it, barring that it does not explain why a certificate would be something copyrightable. For something to be copyrightable, creativity needs to be in the work. A certificate is essentially random numbers fed to an existing algorithm, yielding no creative effort. Still, it's unclear to me why CAcert thinks it can and should claim this copyright. They do not explain that in a place I could find. My concerns with CAcert are not so much about the licensing. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743158: systemd: sends private information without confirmation
Hi Norbert, On Mon, March 31, 2014 03:33, Norbert Preining wrote: Sending /etc/fstab without asking the user is not acceptable, as there might be passwords saved in there. It would help the security team and anyone else not intimately involved with this package if you could indicate more precisely to which functionality you refer here. Thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741561: Processed: severity of 741561 is critical
Klaus,
On Mon, March 31, 2014 09:03, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
severity 741561 critical
Bug #741561 {Done: Michael Shuler mich...@pbandjelly.org}
[ca-certificates] Please Include CAcert Root Certificates
Severity set to 'critical' from 'wishlist'
The severity of this bug has been set by the maintainer and you've already
against explicit instruction changed it back. Moreover you call the
maintainer 'stupid'. Please refrain from this behaviour. Any next
occurrence of this behaviour will result in a request to the BTS operators
to block your access.
Thijs
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743175: zendframework: two security issues
Package: zendframework Severity: serious Tags: security fixed-upstream patch Hi, Two new security advisories were published for the Zend Framework. * ZF2014-01: Potential XXE/XEE attacks using PHP functions: simplexml_load_*, DOMDocument::loadXML, and xml_parse http://framework.zend.com/security/advisory/ZF2014-01 * ZF2014-02: Potential security issue in login mechanism of ZendOpenId and Zend_OpenId consumer http://framework.zend.com/security/advisory/ZF2014-02 Can you please see to it that these are addressed in Debian? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743158: [Pkg-systemd-maintainers] Bug#743158: systemd: sends private information without confirmation
On Mon, March 31, 2014 15:29, Norbert Preining wrote: Hi Michael, On Mon, 31 Mar 2014, Michael Biebl wrote: can you try the attached bug script, you need to copy it to it works for me. I chose to use Y as default, since /etc/fstab should not usually contain password information. I think this is fine. Yes, fine. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742859: XSS vulnerability in open-flash-chart.swf (CVE-2013-1636)
Package: biomaj-watcher Severity: important Tags: security Hi, the following vulnerability was published for biomaj-watcher. CVE-2013-1636[0]: | Cross-site scripting (XSS) vulnerability in open-flash-chart.swf in | Open Flash Chart (aka Open-Flash Chart), as used in the Pretty Link | Lite plugin before 1.6.3 for WordPress, JNews (com_jnews) component | 8.0.1 for Joomla!, and CiviCRM 3.1.0 through 4.2.9 and 4.3.0 through | 4.3.3, allows remote attackers to inject arbitrary web script or HTML | via the get-data parameter. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1636 https://security-tracker.debian.org/tracker/CVE-2013-1636 Please adjust the affected versions in the BTS as needed. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#742795: when selecting no webservers to configure, asks whether to restart
Package: dokuwiki Version: 0.0.20131208-1 Severity: minor Hi, If you unselect all webservers in the debconf question on which one to configure, after that still a question appears about whether the webserver should be restarted. This could of course be omitted in that case. Cheers, Thijs -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages dokuwiki depends on: ii debconf [debconf-2.0] 1.5.52 ii javascript-common 11 ii libjs-jquery 1.7.2+dfsg-3 ii libjs-jquery-cookie9-1 ii libjs-jquery-ui1.10.1+dfsg-1 ii libphp-simplepie 1.2.1-3 ii php-geshi 1.0.8.11-2 ii php-seclib 0.3.6-1 ii php5 5.5.9+dfsg-1 ii ucf3.0027+nmu1 Versions of packages dokuwiki recommends: ii php5-cli5.5.9+dfsg-1 ii php5-gd 5.5.9+dfsg-1 ii php5-ldap 5.5.9+dfsg-1 ii php5-mysql 5.5.9+dfsg-1 Versions of packages dokuwiki suggests: pn libapache2-mod-xsendfile none -- debconf information: * dokuwiki/wiki/acl: true dokuwiki/system/localnet: 10.0.0.0/24 * dokuwiki/system/accessible: localhost only * dokuwiki/wiki/superuser: admin * dokuwiki/system/documentroot: /dokuwiki * dokuwiki/system/configure-webserver: * dokuwiki/system/writeconf: false * dokuwiki/system/writeplugins: false dokuwiki/wiki/failpass: * dokuwiki/wiki/license: cc-by-sa * dokuwiki/system/restart-webserver: false * dokuwiki/wiki/policy: public * dokuwiki/system/purgepages: false * dokuwiki/wiki/title: Debian DokuWiki * dokuwiki/wiki/email: webmaster@localhost * dokuwiki/wiki/fullname: DokuWiki Administrator -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742329: use softer colours for architecture qualification page
Package: release.debian.org
Severity: minor
Tags: patch
Attached patch uses softer colours which are easier on the eye for
the architecture qualification page.
From 3932bb06d69557a5d05efbf50459d9b7b9b5cccf Mon Sep 17 00:00:00 2001
From: Thijs Kinkhorst th...@debian.org
Date: Sat, 22 Mar 2014 14:39:18 +0100
Subject: [PATCH] Use less hard colours to reduce eyebleedage.
---
www/jessie/arch_qualify.py |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/www/jessie/arch_qualify.py b/www/jessie/arch_qualify.py
index 0e56ead..9ffa0ee 100644
--- a/www/jessie/arch_qualify.py
+++ b/www/jessie/arch_qualify.py
@@ -18,9 +18,9 @@ from collections import OrderedDict
### formatting helpers
-def FAIL(value): return (red,value)
-def WARN(value): return (yellow,value)
-def PASS(value): return (lime,value)
+def FAIL(value): return (#e87272,value)
+def WARN(value): return (#ccff66,value)
+def PASS(value): return (#60e760,value)
def c_truth(value):
if value == True or value == yes:
@@ -152,7 +152,7 @@ def dump_table(info,waivers):
w = waivers.get(arch,{}).get(c,None)
if w:
-col=cyan
+col=#00
contents += ' a href=%s(w)/a' % (w)
if col==red:
--
1.7.10.4
Bug#742329: use softer colours for architecture qualification page
On Sat, March 22, 2014 16:28, Julien Cristau wrote:
looks like that if col==red is now broken?
Indeed, see fixed patch attached.
Thijs
From 8f84a1be4a9c49782ea8f736ef315508591e1608 Mon Sep 17 00:00:00 2001
From: Thijs Kinkhorst th...@debian.org
Date: Sat, 22 Mar 2014 16:47:16 +0100
Subject: [PATCH] Use less hard colours to reduce eyebleedage.
---
www/jessie/arch_qualify.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/www/jessie/arch_qualify.py b/www/jessie/arch_qualify.py
index 0e56ead..f872f3c 100644
--- a/www/jessie/arch_qualify.py
+++ b/www/jessie/arch_qualify.py
@@ -18,9 +18,9 @@ from collections import OrderedDict
### formatting helpers
-def FAIL(value): return (red,value)
-def WARN(value): return (yellow,value)
-def PASS(value): return (lime,value)
+def FAIL(value): return (#e87272,value)
+def WARN(value): return (#ccff66,value)
+def PASS(value): return (#60e760,value)
def c_truth(value):
if value == True or value == yes:
@@ -152,10 +152,10 @@ def dump_table(info,waivers):
w = waivers.get(arch,{}).get(c,None)
if w:
-col=cyan
+col=#00
contents += ' a href=%s(w)/a' % (w)
-if col==red:
+if col==#e87272:
candidacy_at_risk[arch]=True
print 'td style=background-color:%s%s/td' % (col,contents)
--
1.7.10.4
Bug#718434: fixed in ca-certificates 20140223
On Mon, March 17, 2014 03:06, Bas Wijnen wrote: The other option is to get a certificate, which costs money. Except with CAcert. This is not true. There are several CA services recognised by the major browsers and thus the ca-certifcates package which offer free as in money SSL certificates; and there are several more that offer them at very low prices. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639268: [php-maint] Bug#639268: [PATCH] Handle .phar (and .bz2|.gz|.zip) with PHP
Hi, Thanks, but this does not really answer my question? Thijs On Mon, March 17, 2014 17:48, Christian Weiske wrote: Configure apache to handle .phar, .phar.bz2, phar.gz and .phar.zip files with the PHP module. Resolves: #639268 --- INSTALL| 6 +++--- debian/php5-cgi.conf | 4 ++-- debian/php5.conf | 4 ++-- debian/php5filter.conf | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git INSTALL INSTALL index 141e4f8..2d2abb7 100644 --- INSTALL +++ INSTALL @@ -462,9 +462,9 @@ LoadModule php5_module modules/libphp5.so SetHandler application/x-httpd-php /FilesMatch Or, if we wanted to allow .php, .php2, .php3, .php4, .php5, .php6, - and .phtml files to be executed as PHP, but nothing else, we'd use - this: -FilesMatch \.ph(p[2-6]?|tml)$ + .phtml, .phar, .phar.bz2, phar.gz and .phar.zip files to be + executed as PHP, but nothing else, we'd use this: +FilesMatch \.ph(ar(|\.bz2|\.gz|\.zip)|p[2-6]?|tml)$ SetHandler application/x-httpd-php /FilesMatch And to allow .phps files to be handled by the php source filter, diff --git debian/php5-cgi.conf debian/php5-cgi.conf index 2a18b14..32d3bfa 100644 --- debian/php5-cgi.conf +++ debian/php5-cgi.conf @@ -5,7 +5,7 @@ # application/x-httpd-php3 php3 # application/x-httpd-php4 php4 # application/x-httpd-php5 php -FilesMatch .+\.ph(p[345]?|t|tml)$ +FilesMatch .+\.ph(ar(|\.bz2|\.gz|\.zip)|p[345]?|t|tml)$ SetHandler application/x-httpd-php /FilesMatch # application/x-httpd-php-source phps @@ -18,7 +18,7 @@ Deny from all /FilesMatch # Deny access to files without filename (e.g. '.php') -FilesMatch ^\.ph(p[345]?|t|tml|ps)$ +FilesMatch ^\.ph(ar(|\.bz2|\.gz|\.zip)|p[345]?|t|tml|ps)$ Order Deny,Allow Deny from all /FilesMatch diff --git debian/php5.conf debian/php5.conf index 2e9772f..c70347f 100644 --- debian/php5.conf +++ debian/php5.conf @@ -1,4 +1,4 @@ -FilesMatch .+\.ph(p[345]?|t|tml)$ +FilesMatch .+\.ph(ar(|\.bz2|\.gz|\.zip)|p[345]?|t|tml)$ SetHandler application/x-httpd-php /FilesMatch FilesMatch .+\.phps$ @@ -10,7 +10,7 @@ Deny from all /FilesMatch # Deny access to files without filename (e.g. '.php') -FilesMatch ^\.ph(p[345]?|t|tml|ps)$ +FilesMatch ^\.ph(ar(|\.bz2|\.gz|\.zip)|p[345]?|t|tml|ps)$ Order Deny,Allow Deny from all /FilesMatch diff --git debian/php5filter.conf debian/php5filter.conf index 50c88b4..ce3f163 100644 --- debian/php5filter.conf +++ debian/php5filter.conf @@ -1,9 +1,9 @@ -FilesMatch .+\.ph(p3?|tml)$ +FilesMatch .+\.ph(ar(|\.bz2|\.gz|\.zip)|p3?|tml)$ SetInputFilter PHP SetOutputFilter PHP /FilesMatch # Deny access to files without filename (e.g. '.php') -FilesMatch ^\.ph(p[345]?|t|tml|ps)$ +FilesMatch ^\.ph(ar(|\.bz2|\.gz|\.zip)|p[345]?|t|tml|ps)$ Order Deny,Allow Deny from all /FilesMatch -- 1.8.3.2 ___ pkg-php-maint mailing list pkg-php-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737963: [php-maint] Bug#737963: php5: directives upload_max_filesize and post_max_size are ignored in /etc/php5/apache2/php.ini
tags 737963 moreinfo unreproducible thanks Hi, On Fri, February 7, 2014 11:03, Francesco De Francesco wrote: Directives upload_max_filesize and post_max_size are not read unless you move them at the top of the file. After weeks of headache I tried to change the php.ini this way after reading bug #685156, worked instantly. Before, only default values were read in phpinfo(). Oddly enough, memory_limit directive was normally read. I tried just now and the changed value is correctly reflected after an Apache reload. I suspect that there may be something else going on; maybe a duplicate occurrence of this directive in your php.ini or in any of the included php.ini snippets? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639268: [php-maint] Bug#639268: Problem from Suhosin
On Sat, September 15, 2012 13:08, Christian Weiske wrote: The bug is from Suhosin which doesn't allow execution of phar:// URLs No, this is not the issue. The issue is that apache does not even let PHP handle the .phar file at all. I'm missing why we would want Apache to handle the phar file directly. If it's an archive, don't you want to download it instead of execute it in the web server context? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577523: Processed: Re: Bug#577523: subversion: no TERENA SSL CA certificate for https://scm.gforge.inria.fr:443
On Thu, March 6, 2014 22:44, Vincent Lefevre wrote: On 2014-03-06 13:46:13 +0100, Thijs Kinkhorst wrote: A simple test with openssl s_client reveals that www.inria.fr has not configured the correct certificate chain for the TCS certificates. This needs to be taken up with the administrators of that website. I confirm for www.inria.fr and www.cnrs.fr (I've reported the problem to the sysadmins), but for other ones with a correct certificate chain, it doesn't work with lynx. Adding the TERENA SSL CA certificate to ca-certificates.crt solves the problem. Now, since this problem is specific to lynx, I suppose that this is more a bug with lynx itself. I've reported another bug: Adding intermediate certificates to ca-certificates.crt works around a problem in said applications. The root CA's as used by TCS are already in ca-certificates.crt and the chains are published by the web server, so all information is there. Any client that fails validation then is buggy. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740961 So this is indeed the best way forward. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736494: Please consider to prioritize this update
Hi Clement, On Tue, February 25, 2014 07:32, Clement Wong wrote: Our web servers has been using a self patched version for a long time because of the sybase regression from deb7u3, and this is a big problem for us in terms of security, we dont have the manpower to keep our php up to date. You can really help this process by taking the packages as included in this bug log and verify that they (a) indeed solve the problem for you and (b) do not cause other regressions, and report that back to the bug. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739815: RFA: signing-party -- Various OpenPGP related tools
Hi, Thank you both for your interest. As you're both not DD's at the moment, you cannot upload the package yourself. I propose to give you commit access to the package's repository and you make your changes there. If you have a complete upload there's people involved in the packaging that can do the actual uploading. If you give me your alioth username I will arrange the commit access. Some more information on adopting a package and packaging in general can be found here: https://wiki.debian.org/DebianMentorsFaq#How_do_I_adopt_an_existing_package.3F https://www.debian.org/devel/ Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#735363: [Pkg-gnupg-maint] Bug#735363: [PATCH] init trustdb before trying to clear it
Op dinsdag 18 februari 2014 20:30:28 schreef Werner Koch: On Tue, 18 Feb 2014 09:47, th...@debian.org said: I do not object against this upload but would like to know if Werner would approve of the patch. Werner? The patch is quite obvious. IIRC, it has also been posted to the BTS or the ML. Yes, indeed. Just checking to be sure, as I'd rather only carry patches in Debian's GnuPG that will at some point be applied upstream. Thanks, Thijs signature.asc Description: This is a digitally signed message part.
Bug#739815: RFA: signing-party -- Various OpenPGP related tools
Package: wnpp Severity: normal We request an adopter for the signing-party package. There's currently a number of co-maintainers but the majority of them have indicated to have no time to contribute a lot to the package. The package is an interesting collection of tools and in the BTS there's a number of useful patches and reports that need to be evaluated and where relevant, applied to the package. Since the team is also upstream there's a lot of flexibility and freedom to make changes that you see fit. The packaging is currently in svn but a move to another vcs if so preferred is perfectly fine. The package description is: signing-party is a collection for all kinds of PGP/GnuPG related things, including tools for signing keys, keyring analysis, and party preparation. . * caff: CA - Fire and Forget signs and mails a key * pgp-clean: removes all non-self signatures from key * pgp-fixkey: removes broken packets from keys * gpg-mailkeys: simply mail out a signed key to its owner * gpg-key2ps: generate PostScript file with fingerprint paper strips * gpgdir: recursive directory encryption tool * gpglist: show who signed which of your UIDs * gpgsigs: annotates list of GnuPG keys with already done signatures * gpgparticipants: create list of party participants for the organiser * gpgwrap: a passphrase wrapper * keyanalyze: minimum signing distance (MSD) analysis on keyrings * keylookup: ncurses wrapper around gpg --search * sig2dot: converts a list of GnuPG signatures to a .dot file * springgraph: creates a graph from a .dot file Let me know if there are any questions. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739816: O: mailping
Package: wnpp Severity: normal I'm orphaning the package 'mailping' which can measure email round trip times in a munin setup. I have only done a single upload to fix a number of issues, and no urgent problems have been reported since. However, it packaging can probably use some modernisation and I'm orphaning it because I don't use it myself anymore. The package description: mailping - monitor email service availability and functioning Monitor email service availability and functioning. Tests the whole route from SMTP submission to local delivery, not just whether an SMTP server accepts TCP connections. Multiple email servers can be tested by creating a remote alias that points back to a local address, and sending test emails to it. The results of this monitoring are available as graphs via Munin plugins, and can be connected to Nagios to send alerts when the test emails no longer get delivered, or if the delivery takes too long. I'm Ccing the munin maintainers since there may be an interesting party among them for adopting the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737630: Document how to cleanly uninstall too
Hi Dan, Op dinsdag 4 februari 2014 13:53:18 schreef Dan Jacobson: Package: ttf-mscorefonts-installer It is nowhere documented how to reverse the effects of installing this package. Does one need a second package, ttf-mscorefonts-uninstaller, that will clean up the effects? Purging ttf-mscorefonts-installer leaves a lot of stuff behind. Please tell me how to clean it up back to the state it was before I installed the package. And also document the method. I'm unsure what you're requesting. I think this package removes everything it installed when the package is removed, as per Debian policy. What is left behind after you uninstall the package? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#739521: Please lower php-tcpdf to to Suggests or Recommends
On Wed, February 19, 2014 20:03, Michal ÄihaÅ wrote: As phpMyAdmin code does not check for it's presence (there is no need for that as it's distributed in upstream tarball), I don't think it good idea to do this. It would be nice if phpMyAdmin could add such a check, it seems to me not very expensive and it would help distributors such as us a lot. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735363: [Pkg-gnupg-maint] Bug#735363: [PATCH] init trustdb before trying to clear it
On Mon, February 17, 2014 19:43, Daniel Kahn Gillmor wrote: On 02/15/2014 01:07 PM, Dominic Hargreaves wrote: Control: severity -1 critical Justification: makes unrelated software on the system break [...] On reflection, I'm upgrading the severity of this bug, since it's blocking RC (FTBFS) bugs on multiple other packages. I think this is the right thing to do for #735363. thanks for doing it, Dominic. Could someone familiar with gnupg's internals check Daniel's patch, please (or Daniel do you feel confident to upload this without further review?) I've been running with this patch since January 20th, and it works fine for me. I'm attaching the debdiff here. I'm uploading it to DELAYED/2 now, in case the package maintainers want to try to resolve this some other way. I do not object against this upload but would like to know if Werner would approve of the patch. Werner? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737201: pu: package ia32-libs/20140131, ia32-libs-gtk/20140131
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Hi, As customary I'd like to update ia32-libs and ia32-libs-gtk for the upcoming Squeeze point update. Attached are what the diffs look like. cheers, Thijs diff -Nru ia32-libs-20131011/debian/changelog ia32-libs-20140131/debian/changelog --- ia32-libs-20131011/debian/changelog 2013-10-11 09:50:18.0 +0200 +++ ia32-libs-20140131/debian/changelog 2014-01-31 10:54:27.0 +0100 @@ -1,3 +1,46 @@ +ia32-libs (20140131) squeeze-proposed-updates; urgency=low + + * Packages updated + + [ curl (7.21.0-2.1+squeeze7) squeeze-security; urgency=high ] + + * Fix re-use of wrong HTTP NTLM connection as per CVE-2014-0015 +http://curl.haxx.se/docs/adv_20140129.html + * Set urgency=high accordingly + + [ curl (7.21.0-2.1+squeeze6) oldstable-security; urgency=low ] + + * Disable host verification too when using the --insecure option +(#729965) + + [ curl (7.21.0-2.1+squeeze5) oldstable-security; urgency=high ] + + * Fix OpenSSL checking of a certificate CN or SAN name field when the +digital signature verification is turned off as per CVE-2013-4545 +http://curl.haxx.se/docs/adv_20131115.html + * Set urgency=high accordingly + + [ libxml2 (2.7.8.dfsg-2+squeeze8) oldstable-security; urgency=high ] + + * Non-maintainer upload by the Security Team. + * Fix cve-2013-2877: out-of-bounds read when handling documents that end +abruptly. + + [ nspr (4.8.6-1+squeeze1) squeeze-security; urgency=high ] + + * Non-maintainer upload by the Security Team. + * Fix CVE-2013-5607: integer overflow on 64 bit systems + + [ nss (3.12.8-1+squeeze7) squeeze-security; urgency=high ] + + * Non-maintainer upload by the Security Team. + * Add CVE-2013-5605.patch. +CVE-2013-5605: Null_Cipher() does not respect maxOutputLen; allowing +remote attackers to cause a denial of service or possibly have +unspecified other impact via invalid handshake packets. + + -- Thijs Kinkhorst th...@debian.org Fri, 31 Jan 2014 09:19:46 +0100 + ia32-libs (20131011) squeeze-proposed-updates; urgency=low * Packages updated diff -Nru ia32-libs-20131011/debian/copyright ia32-libs-20140131/debian/copyright --- ia32-libs-20131011/debian/copyright 2013-10-11 09:43:20.0 +0200 +++ ia32-libs-20140131/debian/copyright 2014-01-31 09:23:51.0 +0100 @@ -843,7 +843,7 @@ --- -Copyright for ./curl_7.21.0-2.1+squeeze4.dsc +Copyright for ./curl_7.21.0-2.1+squeeze7.dsc This package was debianized by Domenico Andreoli ca...@debian.org on Fri, 17 Nov 2000 16:10:37 +0100 @@ -8666,7 +8666,7 @@ dealings in this Software without prior written authorization from Digital Equipment Corporation. --- -Copyright for ./libxml2_2.7.8.dfsg-2+squeeze7.dsc +Copyright for ./libxml2_2.7.8.dfsg-2+squeeze8.dsc This package was debianized by Vincent Renardias vinc...@waw.com on Sat, 26 Sep 1998 16:50:54 +0200 @@ -9685,7 +9685,7 @@ Translation: You can do whatever you want with this software! --- -Copyright for ./nspr_4.8.6-1.dsc +Copyright for ./nspr_4.8.6-1+squeeze1.dsc This package was debianized by Mike Hommey gland...@debian.org on Sun, 25 Mar 2007 12:17:27 +0200. @@ -10276,7 +10276,7 @@ may use your version of this file under either the NPL or the [___] License. --- -Copyright for ./nss_3.12.8-1+squeeze6.dsc +Copyright for ./nss_3.12.8-1+squeeze7.dsc This package was debianized by Mike Hommey gland...@debian.org on Sun, 25 Mar 2007 19:36:42 +0200. Binary files /tmp/4k5hzuEsof/ia32-libs-20131011/pkgs/libcurl3_7.21.0-2.1+squeeze4_i386.deb and /tmp/_8Usvk17_P/ia32-libs-20140131/pkgs/libcurl3_7.21.0-2.1+squeeze4_i386.deb differ Binary files /tmp/4k5hzuEsof/ia32-libs-20131011/pkgs/libcurl3_7.21.0-2.1+squeeze7_i386.deb and /tmp/_8Usvk17_P/ia32-libs-20140131/pkgs/libcurl3_7.21.0-2.1+squeeze7_i386.deb differ Binary files /tmp/4k5hzuEsof/ia32-libs-20131011/pkgs/libnspr4-0d_4.8.6-1+squeeze1_i386.deb and /tmp/_8Usvk17_P/ia32-libs-20140131/pkgs/libnspr4-0d_4.8.6-1+squeeze1_i386.deb differ Binary files /tmp/4k5hzuEsof/ia32-libs-20131011/pkgs/libnspr4-0d_4.8.6-1_i386.deb and /tmp/_8Usvk17_P/ia32-libs-20140131/pkgs/libnspr4-0d_4.8.6-1_i386.deb differ Binary files /tmp/4k5hzuEsof/ia32-libs-20131011/pkgs/libnss3-1d_3.12.8-1+squeeze6_i386.deb and /tmp/_8Usvk17_P/ia32-libs-20140131/pkgs/libnss3-1d_3.12.8-1+squeeze6_i386.deb differ Binary files /tmp/4k5hzuEsof/ia32-libs-20131011/pkgs/libnss3-1d_3.12.8-1+squeeze7_i386.deb and /tmp/_8Usvk17_P/ia32-libs-20140131/pkgs/libnss3-1d_3.12.8-1+squeeze7_i386.deb differ Binary files /tmp/4k5hzuEsof/ia32-libs-20131011/pkgs/libxml2-dev_2.7.8.dfsg-2+squeeze7_i386.deb and /tmp/_8Usvk17_P/ia32-libs-20140131/pkgs
Bug#737128: gpg exits with a fatal error about missing trustdb despite successfully having imported a key
Package: gnupg Version: 1.4.16-1 Tags: patch Original Message Subject: Re: [FOSDEM] Keysigning: list of participants now available From:Philip Paeps phi...@fosdem.org Date:Thu, January 30, 2014 12:21 To: gregor herrmann gregor+fos...@comodo.priv.at Cc: fos...@lists.fosdem.org visitors fos...@lists.fosdem.org -- On 29 Jan 2014, at 22:19, gregor herrmann gregor+fos...@comodo.priv.at wrote: On Tue, 28 Jan 2014 08:53:17 -0600, Tom Marble wrote: Please use caff(1) from the package signing-party (after the KSP) to sign the keys at home. But BEWARE the default caff configuration is NOT the same as for GPG. Please make sure you are using the configuration settings you intend (esp. strong signature strength). For more information please see: https://github.com/tmarble/kspsig Please be aware of http://bugs.debian.org/735536 when using caff. This patch against gnupg-1.4.16 fixes it. When importing keys with --trust-model=always and no existing trustdb, gpg would exit with a fatal error about the missing trustdb despite successfully having imported the key. We should not exit with a fatal error when an operation completes successfully! Signed-off-by: Philip Paeps phi...@paeps.cx --- g10/trustdb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/g10/trustdb.c b/g10/trustdb.c index 0bf92e4..f0c0ab8 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -927,6 +927,7 @@ clear_ownertrusts (PKT_public_key *pk) TRUSTREC rec; int rc; + init_trustdb(); if (trustdb_args.no_trustdb opt.trust_model == TM_ALWAYS) return 0; -- 1.8.3.4 (Apple Git-47) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information ___ FOSDEM mailing list fos...@lists.fosdem.org https://lists.fosdem.org/listinfo/fosdem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737072: ITP: KeySigningPartyTools -- create a better formatted list in PDF format by reading a FOSDEM key list
On Thu, January 30, 2014 15:17, alberto fuentes wrote: On Thu, Jan 30, 2014 at 1:11 PM, Alexander Wirt formo...@debian.org wrote: On Wed, 29 Jan 2014, Alberto Fuentes wrote: Package: wnpp Severity: wishlist Owner: Alberto Fuentes paj...@gmail.com * Package name: KeySigningPartyTools Version : n/a Upstream Author : Vadim Trochinsky m...@vadim.ws * URL : https://github.com/vatral/KeySigningPartyTools * License : AGPL v3 Programming Lang: Perl Description : create a better formatted list in PDF format by reading a FOSDEM key list Key signing is really in need of a program that eases interchange of keys. KeySigningPartyTools generates a pdf with qr codes and visual hints for the fingerprints that allows faster processing and avoid manual errors. It process the qr codes afterwards with the help of a webcam as well. It also automatically checks that the keys scanned match the keys downloaded before you sign them. There already is a signing-party package, would you mind to integrate KeySigningPartyTools into it? Thanks Alex I can sure look into it if its ok to Thijs... I don't see any objection, but in fact. I prefer to actually relinquish my maintainership of signing-party. Any suggestion on how to proceed since the package will have two sources? It's possible to work with multiple source tarballs... Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736236: please package newer upstream git snapshot
Package: freerdp Severity: wishlist Hi, Experimental currently contains a git snapshot from June 2013. It would be great if that could be upgraded to a more recent snapshot, since important features have been added since, including support for gateways which is becoming a more common requirement. thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735312: moodle: deletes files from packages libjs-yui-*
On Tue, January 14, 2014 16:40, Robert Bihlmeyer wrote: Package: moodle Version: 2.5.3-3 Severity: serious Having libjs-yui-common and libjs-yui-common installed, an upgrade of moodle from 2.5.3-2 to -3 results in loss of a large number of files from these two packages. What I think happens here is that dpkg first sets the symlink of /usr/share/moodle/lib/yuilib/3.9.1/build to /usr/share/javascript/yui3, and then goes on to remove all the files from /u/s/m/lib/yuilib/3.9.1/build/ that are no longer contained in the new version of moodle. It *will* follow the symlink and this results in removal of these files from /usr/share/javascript/yui3 instead. This is perfectly reproducable for me: install -2, then upgrade to -3. dpkg -L libjs-yui3-common | while read f; do [ -e $f ] || echo $f; done will list a lot of missing files afterwards. Apart from being a policy violation this bug also cripples the functionality of moodle itself. My suggestion would be: 1. elide the dir removal from preinst 2. don't include the symlink in the package contents 3. remove the dir and create the symlink in the postinst When transplanting the dir removal code, remember that [ -d ... ] will return true for a symlink to a directory. Thanks. I'll investigate early next week. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733195: [Pkg-gnupg-maint] Bug#733195: gnupg: quoted printable character in armor
tags 733195 moreinfo thanks Hi Kingsley, On Thu, December 26, 2013 23:51, Kingsley G. Morse Jr. wrote: Someone I know uses an Apple computer to send me encrypted emails. Content-Transfer-Encoding: quoted-printable I found that my email client, version 1.5.21-6.4 of mutt, can work around the problem by actually changing pgp's message, without prompting me for my gpg pass phrase. The upshot is that mutt deleted three 3Ds at the end of PGP's message to change =3D=3D =3D to == = Your friend sends you messages which are encoded in quoted-printable format, as rightly declared by the message header. Mutt first undoes the quoted-printable encoding, as is exactly what any mail client should do before further processing the message. If you undo the quoted-printable encoding, you will get the original text as it was encrypted by your friend. So this is the thing that GnuPG is able to decrypt. This all seems to work as designed. What is the bug? Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711744: [Pkg-gnupg-maint] Bug#711744: [gnupg] Please check signature files when getting new orig.tar.gz
On Sun, December 15, 2013 19:44, Daniel Kahn Gillmor wrote: On 12/13/2013 03:33 AM, Thijs Kinkhorst wrote: Well, the idea of making it invalid was to see if the download would actually fail on that. uscan should fail (return non-zero) if pgpsigmangleurl is present and anything prevents full validation of the upstream source. OK, I gave it another try. Firstly, it seems like the watch file in this bug accidentally drops the required pasv option. When I re-add that, the downloading of the orig.tar.gz works again, but the downloading of the signature fails. Does that code not use the pasv option? $ uscan --verbose -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: opts=pasv,pgpsigurlmangle=s/$/.sig/ http://gnupg.org/download/ .*/gnupg-(1\..*)\.tar\.gz -- Found the following matching hrefs: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.16.tar.gz (1.4.16) Newest version on remote site is 1.4.16, local version is 1.4.15 = Newer version available from ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.16.tar.gz -- Downloading updated package gnupg-1.4.16.tar.gz -- Downloading OpenPGP signature for package as gnupg-1.4.16.tar.gz.pgp uscan warning: In directory ., downloading OpenPGP signature ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.16.tar.gz failed: 400 FTP return code 150 Also, if the upstream-signing-key.pgp is missing, uscan will happily download the tarball without any verification and with return code 0, I think that's not expected? $ uscan --verbose -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: opts=pasv,pgpsigurlmangle=s/$/.sig/ http://gnupg.org/download/ .*/gnupg-(1\..*)\.tar\.gz uscan warning: pgpsigurlmangle option exists, but debian/upstream-signing-key.pgp does not exist, ignoring in debian/watch: http://gnupg.org/download/ .*/gnupg-(1\..*)\.tar\.gz -- Found the following matching hrefs: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.16.tar.gz (1.4.16) Newest version on remote site is 1.4.16, local version is 1.4.15 = Newer version available from ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.16.tar.gz -- Downloading updated package gnupg-1.4.16.tar.gz -- Successfully downloaded updated package gnupg-1.4.16.tar.gz and symlinked gnupg_1.4.16.orig.tar.gz to it -- Scan finished $ echo $? 0 Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734362: phpmyadmin: Vcs-Svn / Vcs-Browser currently not accessible
On Mon, January 6, 2014 12:16, Thomas Hochstein wrote: Package: phpmyadmin Version: 4:3.4.11.1-2 Severity: minor Dear Maintainer, the VCS namend in Vcs-Browser and Vcs-Svn is not accessible currently: thh@thangorodrim:~$ svn checkout https://svn.kinkhorst.nl/svn/debian/phpmyadmin/trunk svn: Could not open the requested SVN filesystem Yes, this just keeps on failling over. Because I do not host anything else there anymore, perhaps best to just move it to collab-maint. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734045: closed by Thijs Kinkhorst th...@debian.org (Re: [Pkg-ia32-libs-maintainers] Bug#734045: ia32-libs-gtk: not installable, missing dependencies)
On Fri, January 3, 2014 12:41, Leonardo Boselli wrote: Can you reopen it changing to minor and suggesting to change the error message ? No, because it's an error message from apt, not from this package. It is documented in the release notes on two different places, and in the package description. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719056: nagios3 leaks info about install to upstream
Hi, The file html/rss-newsfeed.php in nagios3 (installed into nagios3-cgi) use /tmp insecurely by fixed cache dir name: Actually, besides the tempfile usage, this PHP script exists to query the Nagios upstream website on any load of the front page of the installation, which leaks information about machines having Nagios installed. Perhaps it's better to just remove this functionality. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730104: fixed in moodle 2.5.3-3
Hoi Ivo, On Fri, January 3, 2014 13:48, Ivo De Decker wrote: control: reopen 730104 control: close 733963 2.5.3-3 Hi Thijs, On Fri, Jan 03, 2014 at 12:19:41PM +, Thijs Kinkhorst wrote: Changes: moodle (2.5.3-3) unstable; urgency=medium . * Drop unused libjs-yui dependency (closes: #730104). * Replace bundled yui3 with dependency on packaged libjs-yui3-min. Looks like you closedd the bug in yui, not the one in moodle. Fixing. Sorry and thanks. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732895: Add MariaDB as an alternative dependency
Hello, 2013/12/23 Thijs Kinkhorst th...@debian.org: I'm not against this, but have you considerd to have mariadb-server Provides: mysql-server? Then no packages need to be changed and it will work instantly.. There is Provides: virtual-mysql-client|-server, but we don't have Provides: mysql-server|-client anymore due to circular dependencies issues. Also I think having an explicit virtual package would be a cleaner solution, though this name has not yet been standardized in Debian. Right. I'd love to test it, but it seems no amd64 packages are available yet. I guess you know about this, will they be available soon? Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732895: Add MariaDB as an alternative dependency
Hi Otto, MariaDB is an drop in replacement for MySQL. As MariaDB has just landed in Debian unstable it would be a good time to include it in the dependencies as an alternative to MySQL. Please change in the debian/control any occurences of mysql-server and mysql-client to mariadb-server | mysql-server and mariadb-client | mysql-client. I'm not against this, but have you considerd to have mariadb-server Provides: mysql-server? Then no packages need to be changed and it will work instantly.. Cheers Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732210: Some serious incompatibilities with wheezy php 5.4
On Tue, December 17, 2013 02:15, Dmitry Katsubo wrote: In case somebody will try to install SquirrelMail 1.5.1, there are two issues with it: 1) PHP Fatal error: Call to undefined function session_unregister() in /usr/share/squirrelmail/functions/global.php on line 111 2) PHP Fatal error: Cannot redeclare hex2bin() in /usr/share/squirrelmail/plugins/mail_fetch/functions.php on line 309 Attached patches solve these problems. Also after installation one need to pickup sqspell_config.php from latest stable (e.g. 1.4.23) to make aspell dictionaries working. I personally need 1.5.1 to be able to STARTTLS for IMAP/SMTP server. Otherwise PLAIN authentication is forbidden. If you want to use 1.5 branch, you shoud take a snapshot from squirrelmail.org, as the 1.5.1 release is very dated and indeed suffers from the problems above. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501123: ca-certificates should be maintained as a security relevant package
Hi Christoph, On Mon, December 16, 2013 23:37, Christoph Lechleitner wrote: Why is the ca-certificates package not in the list of security relevant packages? What is this list you refer to? Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711744: [Pkg-gnupg-maint] Bug#711744: [gnupg] Please check signature files when getting new orig.tar.gz
On Thu, December 12, 2013 21:35, Franz Schrober wrote: Thanks, However, this doesn't work for me. If I put random data in the .pgp file it will download the orig.tar.gz blindly. Is this expected? (I'm using sid.) What *.pgp? The watch file was configured to scan for *sig files. And yes, the debian/upstream-signing-key.pgp has to be a valid keyring (which the debian package maintainer provides) and is the one which is used to check against. I don't think the author intended that it can be invalid but it should still download it and tell you that it is an invalid packet and warn you about it. Well, the idea of making it invalid was to see if the download would actually fail on that. I've Cc'ed the author of this feature to discuss it with you. But I just checked it with following scenario: 1. write a correct watchfile + debian/upstream-signing-key.pgp 2. test it (should download both signature and file) 3. change the debian/watch to a wrong ending 4. delete previous downloaded files 5. use uscan again 6. look weird around because the file still exists even when the signature could not be checked because of this 404. It also doesn't generate a failure returncode Thanks. In any case, given the seemingly endless supply of security bugs being discovered in uscan I'm going to hold off on this for a while now. cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730271: [Pkg-gnupg-maint] Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
Hi Stephen, On Sat, November 23, 2013 15:36, Stephen Kitt wrote: I'm getting ready to upload a new version of gcc-mingw-w64 using gcc 4.8 and enabling libgomp. This causes the gpgv-win32 build to attempt to build mpicalc.exe, which fails because the assembly code in libmpi doesn't use underscores as it should when targeting Windows. The attached patch fixes this; I'll be forwarding it upstream too. Thanks. Did this forwarding happen? I couldn't find it. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711744: [Pkg-gnupg-maint] Bug#711744: [gnupg] Please check signature files when getting new orig.tar.gz
On Sun, June 9, 2013 10:01, Schrober wrote: Source: gnupg Severity: wishlist uscan will receive support [1] for checking downloaded tarballs+signatures against a predefined set of keys. gnupg is an (or the most) important part of the verification procedures in debian. Therefore, I would like ask you directly instead of waiting that you noticed this feature. I've attached an example watch file and an upstream-signing-key.pgp (please throw this one away and recreate it because I have absolutely no idea what keys should be included. I've just imported the one from the gnupg homepage [2]). Thanks, However, this doesn't work for me. If I put random data in the .pgp file it will download the orig.tar.gz blindly. Is this expected? (I'm using sid.) Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731436: Update CVE regexp for extended CVE format
Package: libparse-debianchangelog-perl
Version: 1.2.0-1
Severity: normal
Tags: patch
Hi,
CVE syntax will be extended per 2014-01-01, see:
https://cve.mitre.org/cve/identifiers/syntaxchange.html
Attached patch updates the regexp in this package to also detect the
longer forms.
Cheers,
Thijs
diff -Nur libparse-debianchangelog-perl-1.2.0.orig/lib/Parse/DebianChangelog/ChangesFilters.pm libparse-debianchangelog-perl-1.2.0/lib/Parse/DebianChangelog/ChangesFilters.pm
--- libparse-debianchangelog-perl-1.2.0.orig/lib/Parse/DebianChangelog/ChangesFilters.pm 2011-04-04 18:41:06.0 +0200
+++ libparse-debianchangelog-perl-1.2.0/lib/Parse/DebianChangelog/ChangesFilters.pm 2013-12-05 14:09:47.643913682 +0100
@@ -105,7 +105,7 @@
sub cve_to_mitre {
my ($text, $cgi) = @_;
-$text =~ s!\b((?:CVE|CAN)-\d{4}-\d{4})\b
+$text =~ s!\b((?:CVE|CAN)-\d{4}-\d{4,})\b
!$cgi-a({ -href=http://cve.mitre.org/cgi-bin/cvename.cgi?name=$1; }, $1)
!xego;
return $text;
Bug#731438: Update CVE regexp for extended CVE format
Package: aptdaemon
Severity: normal
Tags: patch
Hi,
CVE syntax will be extended per 2014-01-01, see:
https://cve.mitre.org/cve/identifiers/syntaxchange.html
Attached patch updates the regexp in this package to also detect the
longer forms.
Cheers,
Thijs
diff -Nur aptdaemon-1.1.1.old/aptdaemon/pkcompat.py aptdaemon-1.1.1/aptdaemon/pkcompat.py
--- aptdaemon-1.1.1.old/aptdaemon/pkcompat.py 2013-08-11 21:07:59.0 +0200
+++ aptdaemon-1.1.1/aptdaemon/pkcompat.py 2013-12-05 14:16:03.190690491 +0100
@@ -92,7 +92,7 @@
HREF_BUG_UBUNTU = https://bugs.launchpad.net/bugs/%s;
# Regular expression to find cve references
-MATCH_CVE = CVE-\d{4}-\d{4}
+MATCH_CVE = CVE-\d{4}-\d{4,}
HREF_CVE = http://web.nvd.nist.gov/view/vuln/detail?vulnId=%s;
# Map Debian sections to the PackageKit group name space
Bug#731440: Update CVE parsing for extended CVE format
Package: rpm2html Severity: normal Hi, html.c contains code for parsing CVE id's. Per 2014-01-01, CVE id's can have more than 4 digits, see: https://cve.mitre.org/cve/identifiers/syntaxchange.html The parsing code in rpm2html will need to be extended to be able to deal with those CVE's. cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713237: fixed in cpqarrayd 2.3-2
Version: 2.3-2 Hi, This has been fixed in cpqarrayd 2.3-2 but I neglected to mention that in the changelog. Thijs signature.asc Description: This is a digitally signed message part.
Bug#731319: RM: cpqarrayd [powerpc] -- ROM; FTBFS; package not relevant for arch
Package: ftp.debian.org Severity: normal Hi, cpqarrayd provides support for Compaq/HP Smart Array RAID controllers. The package fails to build on powerpc. However, no powerpc hardware exits that sports such controllers. So please remove the old powerpc build from unstable. thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730178: Updates prepared in Git repository
On Fri, November 29, 2013 10:01, Raphael Hertzog wrote: Dear security team, please find attached the diff compared to the respective versions in stable(-security). Is it OK to upload them ? Yes, this is OK (ruby1.8 needs to be built with -sa, ruby1.9.1 without). Thank you for your work on this. PS: I didn't took care of oldstable. Someone should handle that. Obviously we prefer to release updates for all suites at the same time. Are the versions in squeeze so much different that it would be a lot of work to also apply the patches there? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730544: static IV used in Percona XtraBackup
Package: percona-xtrabackup Severity: serious Tags: security fixed-upstream Hi, Upstream discovered and fixed use of a static IV in encrypting backups: A fixed initialization vector (constant string) was used while encrypting the data. This opened the encrypted stream/data to plaintext attacks among others. Bug fixed #1185343. http://www.percona.com/doc/percona-xtrabackup/2.1/release-notes/2.1/2.1.6.html https://bugs.launchpad.net/percona-xtrabackup/+bug/1185343 Fixed in upstream 2.1.6. Can you please ensure that this gets into Debian? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705618: rcu_bh detected stall on CPU
Hi, We're seeing on different VM's running Wheezy 7.2 with linux 3.2.51-1 the same message: INFO: rcu_bh detected stall on CPU 1 (t=0 jiffies) According to http://lwn.net/Articles/520158/ there are two likely commits that fixed this; a10d206e wheezy already has, but c96ea7cf has not yet been backported. Would it make sense to do that? -- Thijs Kinkhorst th...@uvt.nl – LIS Unix Universiteit van Tilburg – Library and IT Services • Postbus 90153, 5000 LE Bezoekadres Warandelaan 2 • Tel. 013 466 3035 • G 236 • http://www.uvt.nl signature.asc Description: This is a digitally signed message part.
Bug#718434: ca-certificates: should CAcert.org be included?
On Wed, November 13, 2013 19:48, Geoffrey Thomas wrote: I'm curious what the status of this bug is -- is there a plan to remove CAcert in the next upload? Thanks for your interest. A final decision still has to be made. However, I think enough information and arguments have been gathered by now. A friend of mine once complained to me that this means that webmasters who use Debian (or a Debian derivative) as their personal OS will often fall into the trap of setting up a website using CAcert, test it on their own machine, and then be surprised when users not on Debian get untrusted certificate errors. This seems like an unlikely scenario, as CAcert is not enabled by default in Debian's most used browsers, Iceweasel (Firefox) and Chromium. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, November 6, 2013 09:10, Russ Allbery wrote: Thijs Kinkhorst th...@debian.org writes: On Wed, November 6, 2013 01:16, Russ Allbery wrote: We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. Do you? In the past Debian has not shied away from making the choice that it considers technically (or philosophically) the most sound, not the one that implies the least amount of work. The choice will probably be made on just a few high-level factors, such as the chosen approach (dependency vs event based), best user experience and/or licensing. Well, my choice won't be made on just those few high-level factors, for whatever that matters. And I seem to have one. :) Technically the most sound and implying the least amount of work are not two unrelated factors. Apply reductio ad absurdum: vaporware is not technicallly sound, regardless of what lofty design principles underlie it. We need to be realistic here about what we, as a project, can accomplish. The ideal init system for Debian is, almost by definition, the one we write ourselves from scratch to do exactly what we want it to do. There's a good reason why no one has proposed that. We have certain realistic limitations about what we can and can't do as a project, which in this space, among other things, require us to adopt an existing project rather than writing our ideal implementation from scratch. I doubt that Debian writing something from scratch would not be realistic: Debian actually has chosen to go the self-implementing route in key infrastructures the past, for example for the installer or package managers. Nonetheless, that's not relevant here. There are several likely candidates in existence, so the choice will not be to use something existing versus implementing from scratch; the choice will be between existing projects, and given that, the amount of work per system may differ but the difference will not likely be that great that it's unsurmountable, as they exist, they have active upstreams and they have successfully been used in other distributions. That metric is trying to get at something that we do care about, namely is a particular upstream project going to be excessively buggy (poorly documented code implies harder to understand code implies people make mistakes when they change it) and can we understand it well enough to make whatever integration changes we need to make to it. I do agree that it's nice to have the very best code quality available, but in the long run, having underdocumented code is annoying and may lead to bugs, but bugs can be fixed and documentation improved; changing the basic architecture of the system is unlikely to be fixed. I really believe we are going to regret it if Debian chooses the architecture it likes less for the reason that it has more documentation. Which system has better code documentation is not relevant. The relevant question is whether a system has adequate documentation, regardless of the documentation of other systems. I think I would like it better if the choice process was split in two. First, for each candidate system assess the supportability in Debian. Code quality can be a factor here. Can we reasonably run this? (Given that the two major choices have been used by several other distributions probably qualifies them, but Debian can make its own assessment here.) Then, from the shortlist of candidates, choose the 'best' one based on high-level but fundamental criteria, like architecture, licensing etc. Currently, it seems these two steps (is it supportable vs what should be the default) are conflated and a big matrix of facts of the different systems is built. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, November 6, 2013 01:16, Russ Allbery wrote: We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. Do you? In the past Debian has not shied away from making the choice that it considers technically (or philosophically) the most sound, not the one that implies the least amount of work. The choice will probably be made on just a few high-level factors, such as the chosen approach (dependency vs event based), best user experience and/or licensing. Facts are being gathered about the percentage of code comments, but I it seems unlikely that Debian would reject a solution that it thinks is architecturally superior because of it having fewer code comments. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728555: RM: ia32-libs, ia32-libs-gtk -- ROM; obsolete
Package: ftp.debian.org Severity: normal Hi, Please remove ia32-libs and ia32-libs-gtk from unstable. The transition to multi-arch was completed with wheezy which contained these packages in transitional form. There's no use to keep the transitional packages for any longer and they block ongoing transitions. thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717647: [Pkg-ia32-libs-maintainers] Bug#717647: [ia32-libs] please transition from lesstif2 to motif
On Sat, November 2, 2013 19:53, Paul Gevers wrote: Hi, On 23-07-13 12:52, Graham Inggs wrote: The lesstif2 package on which your package depends or build-depends is destined to be removed from the archive before the release of Jessie. We are nearly there [1, 2]. Could you please remove or replace lesstif2 in the dependency list of ia32-libs? We could just remove the depenceny but, since we don't want to ship ia32-libs-* with Jessie, I've rather just requested removal altogether: #728555. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728364: [Pkg-cas-maintainers] Bug#728364: should conflict with apache2-mpm-worker
On Thu, October 31, 2013 10:42, Mathieu Parent wrote: Package: libapache2-mod-auth-cas Version: 1.0.9.1-4 Hi, mod_cas is waiting indefinitely for a lock with apache worker. I suggest to make it conflict with apache2-mpm-worker. Ref: http://comments.gmane.org/gmane.comp.java.jasig.cas.user/24169 I'm not eager to do that because obviously it would mean sites cannot use the much better performing -mpm-worker with mod_cas. We are not reproducing the issue here on several sites with mpm-worker. Cited ref seems more like a workaround. Is it possible to get a hold on what would be causing this locking problem? Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728199: fails to upgrade: ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': File exists
Package: dokuwiki Version: 0.0.20130510a-2 Severity: serious Hi, dokuwiki fails to upgrade, and exits the upgrade with an error. Turning set -x on in postinst, this is what happens: + [ -e /etc/apache2/conf.d/dokuwiki.conf ] + [ -d /etc/apache2/conf-available -a ! -e /etc/apache2/conf-available/dokuwiki.conf ] + ln -s /etc/dokuwiki/apache.conf /etc/apache2/conf-available/dokuwiki.conf ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': File exists dpkg: error processing dokuwiki (--configure): subprocess installed post-installation script returned error exit status 1 The code fails because /etc/apache2/conf.d/dokuwiki.conf, the link target, does not exist (it is removed in the same script) and therefore the -e on the link itself fails. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages dokuwiki depends on: ii debconf [debconf-2.0] 1.5.51 ii javascript-common 11 ii libjs-jquery 1.7.2+dfsg-3 ii libjs-jquery-cookie8-2 ii libjs-jquery-ui1.10.1+dfsg-1 ii libphp-simplepie 1.2.1-3 ii php-geshi 1.0.8.11-2 ii php5 5.5.5+dfsg-1 ii ucf3.0027+nmu1 Versions of packages dokuwiki recommends: ii php5-cli5.5.5+dfsg-1 ii php5-gd 5.5.5+dfsg-1 ii php5-ldap 5.5.5+dfsg-1 ii php5-mysql 5.5.5+dfsg-1 Versions of packages dokuwiki suggests: pn libapache2-mod-xsendfile none -- Configuration Files: /etc/dokuwiki/dokuwiki.php changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697940: Closing
reopen 697940 forwarded 697940 http://trac.nginx.org/nginx/ticket/13 tags 697940 = security upstream thanks Hi, This issue is not yet fixed in the package so it seems premature to close it. You're probably right that upstream needs to do this and there's no need for Debian to do it locally. But that is expressed with the 'upstream' and 'forwarded' tags; no need to close it for that reason. It can be closed when a new upstream is uploaded to Debian that fixes the issue. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
