Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file
clone 1006917 -1 reassign -1 libfile-keepass-perl retitle -1 libfile-keepass-perl: crashes "not well-formed (invalid token)" when finding escape characters severity -1 important thanks Hey, Am 18.03.22 um 12:02 schrieb Rhonda D'Vine: * Arno Töll [2022-03-17 14:07:02 CET]: Hi Rhonda, Am 08.03.22 um 16:31 schrieb Rhonda D'Vine: Upstream is at 3.6 in the meantime, I'm willing to update it now that I digged a bit further into it. If I don't hear back in the next few days I propose an NMU for it, as thanks for having it around in the first place. :) please feel free to do, and go ahead. Feel free to add yourself as a maintainer/uploader if you wish. ;-) Do you have a copy of the git repository you used still around? It never seems to have been moved to salsa, and I for obvious reasons would work based on what's there already. :) Alioth's archive of the repository is at https://alioth-archive.debian.org/git/collab-maint/kpcli.git.tar.xz. That allows for bare import, including git history into salsa. Unfortunately I don't have a lot of time for Debian these days, sorry about that. The issue has been properly reassigned in the meantime. Thanks for that Lester. It actually hasn't been reassigned but closed I noticed, and I'm also not so convinced to call it only a minor issue, because as I explained, I managed to fix it because I know my way around the code, but that's not something to expect from regular users. I will be looking into filing this with the upstream tracker though. How about duplicating the issue and reassigning one to libfile-keepass-perl? I'm not sure about the priority, but something below RC might do for that. I did so as per this mail. -- Arno Töll
Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file
Hi Rhonda, Am 08.03.22 um 16:31 schrieb Rhonda D'Vine: Upstream is at 3.6 in the meantime, I'm willing to update it now that I digged a bit further into it. If I don't hear back in the next few days I propose an NMU for it, as thanks for having it around in the first place. :) please feel free to do, and go ahead. Feel free to add yourself as a maintainer/uploader if you wish. ;-) The issue has been properly reassigned in the meantime. Thanks for that Lester. -- Arno Töll
Bug#857976: ifupdown: Failure to create VLAN interface on an Infiniband-capable port running in Ethernet mode
Hi Alex, > I found that the VLAN interfaces specified in /etc/network/interfaces had > not been created. This is the output when attempting to bring up a vlan > interface manually: > > $ ifup eth0.220 > /bin/sh: 1: cannot create /sys/class/net/eth0/create_child: Permission > denied > ifup: ignoring unknown interface eth0.220=eth0.220 > > The server has a Mellanox ConnectX-3 Pro card, which has two interfaces that > are configurable to run in either Infiniband or Ethernet mode. I am running > both ports in Ethernet mode, but ifupdown is treating the interfaces as > Infiniband and trying to add an Infiniband partition to the interface > instead of an Ethernet VLAN. This fails, and the expected VLAN interfaces > are never created. > > I have attached a patch which resolves the issue by only attempting to > create Infiniband partitions when an interface has type ARPHRD_INFINIBAND, > i.e. that is its current opera you are right that these cards can run in either mode and that the pure presence of /sys/class/net//device/infiniband might not suffice to qualify as port in IB mode. I cannot currently test with a card running in Ethernet mode, but I will ask Benjamin who eventually contributed this patch, to test your patch in our IB environment. From a first glance it looks good and your check for ARPHRD_INFINIBAND sounds plausible. The question remains if the card port configuration is reliably available at early boot. Arno Töll
Bug#834340: O: xnbd -- Network Block Device client with support for live migration
Package: wnpp Severity: normal I intend to orphan the xnbd package. I no longer use it with my current employer, and do also not have any use for it privately. Hence I intend to orphan it. Anybody is welcome to take it over. The package description is: xNBD is a NBD (Network Block Device) server program, which is fully compatible with the NBD client driver of Linux kernel. It adds extended features to the traditional NBD server: . * Better performance * Support for distributed copy-on-write disks * Live storage migration for virtual machines. * IPv6 support. . This is the client side of the program
Bug#834339: O: xnbd -- Network Block Device client with support for live migration
Package: wnpp Severity: normal I intend to orphan the xnbd package. I no longer use it with my current employer, and do also not have any use for it privately. Hence I intend to orphan it. Anybody is welcome to take it over. The package description is: xNBD is a NBD (Network Block Device) server program, which is fully compatible with the NBD client driver of Linux kernel. It adds extended features to the traditional NBD server: . * Better performance * Support for distributed copy-on-write disks * Live storage migration for virtual machines. * IPv6 support. . This is the client side of the program
Bug#834337: O: xnbd -- Network Block Device client with support for live migration
Package: wnpp Severity: normal I intend to orphan the xnbd package. I no longer use it with my current employer, and do also not have any use for it privately. Hence I intend to orphan it. Anybody is welcome to take it over. The package description is: xNBD is a NBD (Network Block Device) server program, which is fully compatible with the NBD client driver of Linux kernel. It adds extended features to the traditional NBD server: . * Better performance * Support for distributed copy-on-write disks * Live storage migration for virtual machines. * IPv6 support. . This is the client side of the program
Bug#832935: Bad patch
Hi, On Saturday 30 July 2016 15:47:20 Lester Hightower wrote: > Earlier today, kpcli v3.1 was released and it allows > for Math::Random::ISAAC to be optionally used in place of the built-in > rand() function. An objective evaluation of the ways that rand() is used in > kpcli would likely lead one to believe this is an unnecessary change, but I > made it none the less. I will update kpcli in Debian to 3.1. As pointed out in your discussion upstream, I cannot currently enable it for Debian as Math::Random::ISAAC is not currently packaged. Having that said, I will talk to the Perl team, an if they package it, I will recommend the package in kpcli. This allows people to use it transparently, as you seem to use the module at runtime when available, and recommends are installed. Is that okay with all of you? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: This is a digitally signed message part.
Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2
Hi, we agreed that we should change Lintian to accommodate these changes. The fix would be, to raise this Lintian error only if a package depends on apache2-bin but not on apache2-api-MMNN. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: This is a digitally signed message part.
Bug#778895: (pre-approval) unblock: trafficserver/5.0.1-1+deb8u1
Hi, On Tuesday 10 March 2015 17:27:04 Arnaud Fontaine wrote: Ok, before uploading and filing a proper unblock request, I will wait for the maintainer ACK until Friday if that's ok with you. I'm fine with your NMU, but please note it's only part of the problem. We never bothered for the (easy) fix for #778895 because of other security problems we cannot easily fix in particular CVE-2014-3624 and #749846 - both fixed in Sid. However, the Release Team was uncomfortable to unblock that package (cf. #769689). I'm afraid, that we better ask for removal of that package in Testing rather than bothering with it, as we - as maintainers - cannot guarantee for the security of it already, even less so over the lifespan of a Debian Release, and upstream is moving faster than us. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: This is a digitally signed message part.
Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade
On 19.11.2014 16:49, Andreas Beckmann wrote: PS: do you need the apache2.2-common transitional package? would upgrades work if that would not exist? Please see https://lists.debian.org/debian-devel/2014/07/msg00450.html for all the gory details. We added it very late in the process to work around people's laziness :/ -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade
Hi, On 10.11.2014 00:11, Andreas Beckmann wrote: that process would have to be distributed to two packages ... We do right that already, the best we can. cf.: http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.preinst http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.postinst We can't use dpkg-maintscript helper for the reason you named, as we renamed the package owning it. However, I believe, we cleanly remove/take-over the conffiles in the best way dpkg allows us. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#767287: trafficserver: ftbfs on kfreebsd
Hi, On 30.10.2014 00:10, Steven Chamberlain wrote: I guess the .install file may have some kind syntax to mark that file [linux-any]? Sadly not. However, we may find another way to get it build on kfreebsd. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#765347: Disable SSLv3 in default config
For the records, we evaluated the market share of IE6. Several sources indicate it's in the 0.1% range so that it sounds like a safe default to disable SSLv3. - http://www.w3schools.com/browsers/browsers_explorer.asp says - https://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#762584: apache2: silently changes user configuration /etc/logrotate.d/apache2
On 23.09.2014 15:01, Vincent Lefevre wrote: On 2014-09-23 14:43:49 +0200, Arno Töll wrote: We install this file through dh_installlogrotate and it is listed as a conffile in the binary package of apache2. That means, it will be handled like any other configuration file in Debian with special care and it won't overwrite changes YOU made. OK, but then, is there any reason not to announce it in the NEWS file? This is a significant configuration change! This is a change like the ones which happen every day in Debian during an update. It's not newsworthy I think. Unfortunately it doesn't seem to be possible to hint dpkg: according to the dpkg(1) man page, all the conffile related options are in the case If a conffile is missing or If a conffile has been modified (while here it exists, but was not modified because the default was OK). You're looking for --force-confold. See http://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/ for all details. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Hi Jonathan, On 14.07.2014 23:12, Jonathan Nieder wrote: https://wiki.debian.org/Apache/PackagingFor24 is helpful (thanks!), but I'm still stuck --- I really just don't know how to package gitweb in the new setup. See also http://bugs.debian.org/669292#28: * It's not clear when to run apache2_invoke enconf gitweb for a package like gitweb that does not have a Depends against apache 2.4. If I run it conditionally based on the Apache version, then gitweb will still be broken when the user upgrades apache, unless gitweb happens to be upgraded later in the same upgrade run. web applications aren't supposed to depend on Apache anyway. We suggest packagers of web applications to recommend on Apache so that other web servers can be used, too if people wish. On that matter I do not think gitweb would be different to other packages, or is it? Therefore, we recommend that you check if Apache 2.4 is installed at time you execute the maintainer scripts. There is not much you or we could do, if it isn't. We do both agree that gitweb should rather not depend on Apache, therefore we need conditionals in maintainer scripts. For Apache 2.4 this works like this: if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper apache2_invoke enconf gitweb.conf || exit $? fi This ensures that your configuration is enabled when Apache is installed, and it will not fail if it is not. You do not need to worry in what context to execute this, as our apache2-maintscript-helper takes care to figure out the right thing in the right context (e.g. postinst configure). * It's not clear when to run apache2_invoke disconf gitweb. At remove and purge time doesn't seem to be enough. Likewise as for the enable part. Just call if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper apache2_invoke disconf gitweb.conf || exit $? fi ... and apache2-maintscript-helper tries to figure out when to do what. In particular we disable the module in postrm purge, postrm remove and prerm remove. When else do you think it would be necessary? For the archives: apache2-maintscript-helper is reading the maintainer script state out of $@ supplied to your script. If you wish to call it from a function, you must ensure the context is preserved. If you wish, you can set APACHE2_MAINTSCRIPT_DEBUG (e.g. in /etc/apache2/envvars) and get debug output of the apache2-maintscript-helper at runtime to see what it does in various use cases. And https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=update-apache-packaging.patch;att=1;bug=669292: - prerm deconfigure does not clean up as much as it should - needs triggers to reconfigure when apache is updated? Not sure what you ask me about here? Basically, I am stuck on understanding the state machine: (1) What is the intended update order between webapps, apache-common, and apache itself? What Depends, Pre-Depends, or triggers should be used to make sure everything works okay regardless of the update order? Please read http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;h=0bbb06c48d628cd7c3b6037a0118574a722f2184;hb=HEAD#l157. Does this answer your questions? It does not talk about triggers, because there are none (though we planned to do at some stage) ;-) In particular, the conditional enconf and disconf invocations seem to make it easy to get into a non-working state and never get out of it. Well, we need to deal with that. This is not different than before. If Apache2 wasn't installed, you putting a conf to conf.d is not going to work out either. If you meant to address situations when you install your conf to conf-available and install Apache at a later stage, it is our business (i.e. Apache maintainer's) to ensure those get enabled then. That's a good point actually, and I need to think if we can and should do something in that case. (2) What is the intended uninstallation procedure? https://wiki.debian.org/Apache/PackagingFor24 tells me I should enconf in postinst and disconf in postrm. That's confusing because: * Usually in packaging, postinst is a mirror image of prerm so when the package is in a given dpkg state, the state of configuration matches that. Why here is postinst's mirror image in postrm instead? * Dependencies are not guaranteed to be present during postrm, so the disconf is not guaranteed to happen. It is actually preferred that disconf is called in prerm. This is also what dh-apache2 would do if you let it. Or in both scripts. I am not sure why this is isn't written more explicit in the wiki but I will fix that in a minute. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc
Bug#752922: apache2 upgrade wheezy-jessie breaks certain apache2 modules
merge 752922 711925 thanks Hi, This is a duplicate of #711925. I will merge the isse you reported. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: Solutions for the Apache upgrade hell
Hello, we've got a problem with Apache that causes problems during upgrades (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4 changed ABIs, so that we need to ensure that dpkg properly removes packages linking against the obsolete ABIs at upgrade time. This is the first time this happened since Debian Etch, so this brings a problem to the spotlight, that hasn't been one for a long time. To summarize the bug reports: The problem is, that Apache package maintainers at that time decided, that third party modules shall depend on apache2.2-common, by guaranteeing ABIs remain stable as long as the package name does not change. This is, so far policy compliant. However, by now ABIs did change and we were forced to rename the package (we did so, by providing a virtual API package third parties must depend on. At time of writing this is apache2-api-20120211). Unfortunately, apache2.2-common also contains conffiles and configuration file handling in postinst/postrm ... I spent a lot of time to properly transition to a new state with conffiles/configuration separated from ABI handling, and this works well enough for regular updates by now. Unfortunately it turns out, that /a lot/ of people use aptitude --purge-unused safe-upgrade, or the apt equivalent apt-get dist-upgrade --purge which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. Those people end up with effects as described in the bugs outlined above, for example with incomplete installations because our maintainer scripts had no chance to properly detect the state of the /etc/apache2 directory before the upgrade. This gives us three possibilities which all have unwanted side effects (unless you come up with an idea that all of us makes happy). I'm writing to this list in hope that someone has a very smart idea to make everyone happy, or express your support for either alternative to give us some insights what people think would be the best alternative. * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? * Add a apache2.2-commmon transitional package. This gives us a chance to inspect /etc/apache2 in spite of --purge-unused and properly transition to Apache 2.4. HOWEVER, this has the nasty side effect that modules ABIs are considered compatible as far as dpkg is concerned. Therefore, old module packages aren't forced to be removed and this breaks at runtime when people try to start their upgraded web server with incompatible modules. As a workaround we could add a versioned Breaks for all modules in Wheezy (~ 75) in the apache2.2-common transitional package, and in addition for packages that existed in Squeeze or Etch only (no, really). That said, this still won't help for third party modules outside Debian which people might use (and to my best knowledge, they do a lot) and it's generally problematic in view of the policy with respect to library packaging (even though we're not a library strictly speaking) * Treat the upgrade as new install in our maintainer scripts when --purge-unused was used (side question: Any idea how to reliably and properly detect that case, as the binary package name changed and it's well possible that in Wheezy apache2.2-common is installed, but not apache2 because of weird(tm) packaging)? This would not preserve user's choices in regard of enabled/disabled modules and thus be a borderline policy violation, too. What would you do in our situation? Side note 2: We kinda expected this situation and added a trapdoor in Wheezy [1], but it turned out, that even that is not good enough to prevent havoc with --purge-unused. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.2-common.postrm;h=bbe9f740b81cf8af64412f7ba6aace119dd159ad;hb=refs/heads/wheezy#l5 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#491547: web server policy requires /var/www, not in FHS
Hi Bill, On 01.05.2014 22:52, Bill Allombert wrote: [[ I think it is possible to use subdirectories of /srv as long as we prompt the user for the directory structure to use, but that seems totally unpractical for tthe purpose of the Document Root. ]] ... and not good enough. For some use cases, e.g. Apache, we need to know the Document Root at build time. Apache does statically compile the path in for apache2-suexec for example. Other web servers might do something similar (or not). I have made a first minimal draft. Please comment. diff --git a/policy.sgml b/policy.sgml index bf959f1..5661f4b 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7043,6 +7043,11 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) /p /item item +p + The file/var/www/file directory is additionally allowed. +/p + /item + item p On GNU/Hurd systems, the following additional directories are allowed in the root @@ -9752,7 +9757,7 @@ http://localhost/cgi-bin/.../varcgi-bin-name/var packagedoc-base/package package. If access to the web document root is unavoidable then use example compact=compact -/var/www +/var/www/html /example as the Document Root. This might be just a symbolic link to the location where the system administrator Fine with me, thanks. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711755: don't attempt to reload apache2 if it wasn't running before we started the upgrade
reassign 711755 debhelper affects 711755 src:apache2 thanks Hi, On 09.06.2013 14:33, jida...@jidanni.org wrote: I'm telling you guys, not everybody runs apache2 24/7/365 days a year, so please double check if it was running first (before the upgrade started) before causing these error messages during upgrades! technically, we do not but debhelper does. We call dh_installinit as: override_dh_installinit: dh_installinit --restart-after-upgrade --error-handler=true -- defaults 91 09 which is expanded to: # Automatically added by dh_installinit if [ -x /etc/init.d/apache2 ]; then update-rc.d apache2 defaults 91 09 /dev/null if [ -n $2 ]; then _dh_action=restart else _dh_action=start fi invoke-rc.d apache2 $_dh_action || true fi # End automatically added section in postinst. I think, debhelper should check through invoke-rc.d status - when available - before (re-)starting a daemon unconditionally. This is arguably a behavior which should be addressed on a higher level for all packages that handle init scripts through dh_installinit. If debhelper maintainers disagree, please assign back and we may workaround that particular behavior for our package only, even though that sounds wrong to me. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.
reassign mpm-itk thanks Steinar, On 05.04.2014 17:01, Steinar H. Gunderson wrote: This is almost certainly a configuration issue. It sounds like he is hitting suexec or suphp. I'm handing this over to you now that itk is its own package. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#736809: apache2-bin needs proper Breaks: for Apache 2.4 transition
On 26.01.2014 22:30, Adrian Bunk wrote: Package: apache2-bin Version: 2.4.6-3 Severity: serious First, I was surprised to see the many open and non-RC bugs in [1], shouldn't packages that e.g. use /etc/apache2/conf.d/ have an RC bug since they'll definitely have to get fixed for jessie? Yes. However, the problem is, that a lot of web apps are not all technically release critical broken. We need to look at all of them on a case by case basis and decide what exactly they do (or don't do). This is on my to do, but if someone beats me on it, I won't complain. :-) Second, for supporting all possible upgrade and partial upgrade scenarios (not only between wheezy and jessie, Debian-derived distributions like Ubuntu might have different collections of packages), apache2-bin needs to have a versioned Breaks: against the broken versions of all of the packages in [1] and [2]. Why? Packages in [2] aren't supposed to depend on apache2.2-bin (with some few exceptions, against which ones we /do/ have Breaks in place). Module packages depend on apache2.2-common, where we do force removal upon upgrade, so that in turn, obsolete dependencies without proper replacement are removed, too. For web apps, it's merely a definition of Breaks, a lot of web apps continue to work just fine, just the automated integration into Apache does not work anymore, or the example configuration needs a few fixes, whereas the package itself just works fine. Not that they would depend on apache2.2-bin. (Are there more such usertags?) No, there are not. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#745605: apache2: ignores AddDefaultCharset
Hi,
On 16.06.2014 22:59, Arnaud de Prelle wrote:
It seems Apache 2.4.9-2 misuses the AddDefaultCharset statement.
By default it should be Off but the current 2.4.9-2 simply overrides the
value of the parameters and sets it to UTF-8.
are you sure, this isn't overridden by PHP as in Carlos' case? Apache
defaults to
#define DEFAULT_ADD_DEFAULT_CHARSET_NAME iso-8859-1
else if (!strcasecmp(arg, On)) {
d-add_default_charset = ADD_DEFAULT_CHARSET_ON;
d-add_default_charset_name = DEFAULT_ADD_DEFAULT_CHARSET_NAME;
when set to on, and this code hasn't changed a long time.
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
Bug#754135: trafficserver: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4
Hi Breno, thanks for your patch, but unfortunately you submitted it after I uploaded ATS 5.0 already. That being said, by pure coincidence, I enabled autoreconf for that upload already. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#754527: dput-ng: Please update for Ubuntu upload changes (for derived distros)
Hi Scott, On 12.07.2014 07:45, Scott Kitterman wrote: Please see the attached patch. It would be nice to get this into Debian for people that work on Ubuntu from Debian systems. when we started dput-ng, we said we're hosted on collab-maint and we mean it: Therefore, feel free to push that patch yourself to our git head. I'm sure, you have commit access there. Just one question: Is this the only method allowed anymore on Launchpad? I mean, do we need to keep legacy compatibility? If we do not, your patch is very fine. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#754134: trafficserver: add support for ppc64el
Hi Breno, On 07.07.2014 22:50, Breno Leitao wrote: I would like to have this patch included in order to add support for ppc64el in the trafficserver package. Currently it fails with this build log. http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/trafficserver_5.0.0-1_ppc64el.build as mentioned in the other bug you filed: You submitted your patch after I uploaded ATS 5.0 already. Could you please test your patch for the current version? I'm not really sure how I would test ppc64el builds. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#754134: trafficserver: add support for ppc64el
One more thing I forgot: The build log you linked is for 5.0, the patch for 4.1.2 and so seems your bug report. Could you please enlighten me? Did you patch and test 4.1.2 or 5.0? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#753851: apache2: [core:notice] [pid 22446] AH00052: child pid 22554 exit signal Segmentation fault (11)
reassign 753851 libapache2-mod-php5 thanks Hi Rainer, yes - this is indeed an issue in PHP. gc_remove_zval_from_buffer sounds like PHP tries to access a freed value. I'm reassigning to PHP, maybe they can tell you more about. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#749846: trafficserver: Insecure command execution and use of temporary filenames.
Hi Steve, On 30.05.2014 09:59, Steve Kemp wrote: Please do request/assign CVE identifiers. Thanks for your report, I will coordinate this with Apache folks to get a CVE upstream as this is not Debian specific. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#749846: trafficserver: Insecure command execution and use of temporary filenames.
On 02.06.2014 11:29, Steve Kemp wrote: [ Hoping this whole file isn't needed, and can simply go away :) ] Actually, it is. The shadow part is most likely a left-over from dead code before ATS was open-sourced. Either way, the entire command line utility (traffic-shell) is being dropped upstream altogether. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#745707: xpra: raising a window with H.264 encoding causes xpra to crash and remain stale
On 25.04.2014 04:06, Dmitry Smirnov wrote: On Thu, 24 Apr 2014 10:46:23 Arno Töll wrote: Versions of packages xpra depends on: ii libavutil52 10:2.1.3-dmo1 ii libswscale2 10:2.1.3-dmo1 I'm pretty sure the above libraries are responsible for troubles. *le sigh* -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#745707: xpra: raising a window with H.264 encoding causes xpra to crash and remain stale
On 25.04.2014 09:46, Arno Töll wrote: On 25.04.2014 04:06, Dmitry Smirnov wrote: On Thu, 24 Apr 2014 10:46:23 Arno Töll wrote: Versions of packages xpra depends on: ii libavutil52 10:2.1.3-dmo1 ii libswscale2 10:2.1.3-dmo1 I'm pretty sure the above libraries are responsible for troubles. *le sigh* Err, wait: Yes, I'm using DMO on the client side. However, what's crashing is the server if the client wishes H.264 encoding? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#745707: xpra: raising a window with H.264 encoding causes xpra to crash and remain stale
Package: xpra
Version: 0.12.3+dfsg-1
Severity: important
The current version of xpra looks rather broken to me. Trying to raise a window
yields to an unrecoverable error. Symptoms are that the first window is
displayed,
causing xpra to crash, and further windows remain black when they exist already,
or aren't displayed anymore at all, when they do not exist yet. The server
remains
stale, accepts connections but no windows are shown.
To reproduce, do on the server side (connect a client after the start):
$ xpra start :1
$ DISPLAY=:1 xmessage 'foo' // works, but causes the crash
Warning: Cannot convert string vlines2 to type Pixmap
$ DISPLAY=:1 xmessage 'foo' // never shown
from the log:
2014-04-24 10:36:11,636 Handshake complete; enabling connection
2014-04-24 10:36:11,641 Python/Gtk2 Linux client version 0.12.3 connected from
'snowball' as 'arno' ('arno')
2014-04-24 10:36:11,642 client supplied an mmap_file: /tmp/xpra.16EDpx.mmap but
we cannot find it
2014-04-24 10:36:11,643 using h264 as primary encoding, also available: vp8,
rgb24, rgb32
2014-04-24 10:36:11,643 client root window size is 1600x900 with 1 displays:
2014-04-24 10:36:11,643 ':0.0' (423x238 mm) workarea: 1600x850
2014-04-24 10:36:11,643 LVDS1 (310x174 mm)
2014-04-24 10:36:11,645 server virtual display now set to 1600x900
2014-04-24 10:36:11,646 setting key repeat rate from client: 300ms delay / 20ms
interval
2014-04-24 10:36:11,647 setting keymap: rules=evdev, model=thinkpad60,
layout=de,us
The XKEYBOARD keymap compiler (xkbcomp) reports:
Warning: Type ONE_LEVEL has 1 levels, but RALT has 2 symbols
Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
2014-04-24 10:36:11,669 setting full keymap definition from client via xkbcomp
[swscaler @ 0x7f141c005380] 0x54 - 0x54 is invalid scaling dimension
2014-04-24 10:36:16,431 setup_pipeline failed for (44, codec_spec(swscale),
'RGB', codec_spec(x264))
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/xpra/server/window_video_source.py,
line 1051, in setup_pipeline
enc_width, enc_height, enc_in_format, csc_speed)
File colorspace_converter.pyx, line 316, in
xpra.codecs.csc_swscale.colorspace_converter.ColorspaceConverter.init_context
(xpra/codecs/csc_swscale/colorspace_converter.c:4321)
AssertionError: sws_getContext returned NULL
The problem seems to be specific to the H.264 codec (which is the default).
Starting the client with
$ xpra attach --encoding=vp8 ...
seems to workaround the problem, however. That being said using VP8 fills the
log
with:
2014-04-24 10:42:51,594 error processing damage data: BUG: no encoder not found
for rgb
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/xpra/server/source.py, line 1578, in
data_to_packet
encode_and_queue()
File /usr/lib/python2.7/dist-packages/xpra/server/window_source.py, line
890, in make_data_packet_cb
packet = self.make_data_packet(*data)
File /usr/lib/python2.7/dist-packages/xpra/server/window_source.py, line
1109, in make_data_packet
raise Exception(BUG: no encoder not found for %s % coding)
Exception: BUG: no encoder not found for rgb
... though that seems harmless.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xpra depends on:
ii libavcodec54 6:9.11-3+b2
ii libavutil52 10:2.1.3-dmo1
ii libc6 2.18-4
ii libgtk2.0-0 2.24.23-1
ii libswscale2 10:2.1.3-dmo1
ii libvpx1 1.3.0-2
ii libx11-6 2:1.6.2-1
ii libx264-142 2:0.142.2389+git956c8d8-4
ii libxcomposite11:0.4.4-1
ii libxdamage1 1:1.1.4-1
ii libxext6 2:1.3.2-1
ii libxfixes31:5.0.1-1
ii libxrandr22:1.4.2-1
ii libxtst6 2:1.2.2-1
ii python2.7.5-5
ii python-gtk2 2.24.0-3+b1
ii x11-xserver-utils 7.7+2
ii xserver-xorg-input-void 1:1.4.0-1+b3
ii xserver-xorg-video-dummy 1:0.3.7-1+b2
Versions of packages xpra recommends:
ii openssh-client1:6.6p1-3
ii python-avahi 0.6.31-4
ii python-gtkglext1 1.1.0-9.1
ii python-imaging2.3.0-2
ii python-netifaces 0.8-3+b1
ii python-webm 0.2.2-3
ii ssh-askpass 1:1.2.4.1-9
Versions of packages xpra suggests:
ii gstreamer0.10-plugins-bad 0.10.23-7.2
ii gstreamer0.10-plugins-good 0.10.31-3+nmu2
ii openssh-server 1:6.6p1-3
pn pulseaudio none
pn pulseaudio-utilsnone
ii python-dbus 1.2.0-2+b2
pn python-gst0.10 none
pn python-pyopencl none
-- no
Bug#743977: drbd8: Xen resource script fails when using the xl stack
Source: drbd8 Severity: important The DRBD resource script for Xen (/etc/xen/scripts/block-drbd) does not work when using the xl toolstack anymore, which is exclusively available in xen 4.2 and later (i.e. the current Testing). First of all, it needs the patch mentioned in [1] for basic support. However, when using it in conjunction with pygrub, it fails to find its boot device, whereas this worked fine earlier. Consider this configuration domu.cfg: bootloader = '/usr/lib/xen-4.3/bin/pygrub' disk= [ 'drbd:web1,xvda1,w', ] it fails with: xl create -c /etc/xen/auto/matrix-web1.cfg Parsing config from /etc/xen/auto/matrix-web1.cfg libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.22.log libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [20386] exited with error status 1 libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain type for domid=22 Unable to attach console libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 1 # cat /var/log/xen/bootloader.22.log Traceback (most recent call last): File /usr/lib/xen-4.3/bin/pygrub, line 799, in module part_offs = get_partition_offsets(file) File /usr/lib/xen-4.3/bin/pygrub, line 106, in get_partition_offsets image_type = identify_disk_image(file) File /usr/lib/xen-4.3/bin/pygrub, line 48, in identify_disk_image fd = os.open(file, os.O_RDONLY) OSError: [Errno 2] No such file or directory: 'web1' However, with the configuration: kernel = /boot/vmlinuz-3.2.0-4-amd64 ramdisk = /boot/initrd.img-3.2.0-4-amd64 disk= [ 'drbd:web1,xvda1,w', ] it works fine. I guess the resource script needs a few more tweaks to work with pygrub. [1] http://lists.linbit.com/pipermail/drbd-user/2014-April/thread.html -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.
Steinar, could you please comment on that? I have no experience with itk whatsoever. Therefore, I do not how if this is a problem in itk or a configuration issue. Moreover, please reasign this bug to the itk source package, if this is a still persisting problem. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731074: [pkg-lighttpd] Bug#731074: Bug#731074: lighttpd: indeterminate test on kfreebsd buildds
Hi, On 02.04.2014 02:13, Michael Gilbert wrote: Didn't get a message that I was accepted ;) Will do. That's a feature of FusionForge. While you're at it, please do also include the security NMUs you did in Stable. Thanks! -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743584: trafficserver 4.1.2-1.1 FTBFS on kfreebsd-*
On 05.04.2014 04:06, Aníbal Monsalve Salazar wrote: Please let trafficserver 4.1.2-1.2 migrate to testing. It's the result of the efforts of Petr, Dejan, myself and some other people who looked into the bugs fixed by the NMUs. Sure thing. The MIPS patch is supposed to be included in ATS 5.0, but the kfreebsd patch is probably a Debian specific issue. That being said, I can also commit it upstream if you'd like. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743338: [pkg-lighttpd] Bug#743338: lighttpd: Broken migration to /var/www/html
Hi, On 01.04.2014 23:24, Nelson A. de Oliveira wrote: I see two problems here: it broke my server without any message (there isn't a message in NEWS, for example) and the placeholder page gives a wrong path too: Good idea. I'll add a NEWS file warning users about this and fix the documentation bug. I am also thinking if it should automatically change/update my /etc/lighttpd/lighttpd.conf file to include the new path (like happened) or if it should only use /var/www/html on new installs. As you should be aware as a DD, I am not allowed to touch conffiles. It will be updated accordingly if you did not modify the default configuration but apart there is not much I can do. I am not sure how the upgrade broke anything for you though. Apparently you had modified the lighttpd.conf so that it wasn't upgraded. Thus, it further continues to use whatever doc root you configured, and our default doc root contains nothing but the sample index.html file you're supposed to replace if you really want to use the default. Would you mind telling me more about your setup? Please note, that the default document root is not really meant to be used by end users anyway. It's rather supposed to be the host of last resort when no other (virtual) host matches. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743635: openvswitch: OVS should probably start before networking
Source: openvswitch
Severity: important
OVS is a software switch, and as such providing primarily L2 features. Therefore
it's unfortunate that it starts after networking (i.e. ifupdown) that may be
used
to configure bridge ports provided by OVS.
Consider this configuration:
ovs-vsctl add-br br0
ovs-vsctl add-bond br0 bond0 eth0 eth1 lacp=active
/etc/network/interfaces
auto br0
iface br0 inet static
address 10.10.100.84
netmask 255.255.255.128
network 10.10.100.0
broadcast 10.10.100.127
gateway 10.10.100.1
auto eth0
auto eth0 inet manual
auto eth1
auto eth1 inet manual
In such a setup there is no way where you ever could end up with a networking
setup that ends in remote reachable machine and is thus locking you out. This is
because ifupdown starts before openvswitch-{switch, controller}. Thus, ifupdown
does not find that interface as it isn't provided at this stage during the boot.
A possible fix would be to let openvswitch-{switch, controller} start before the
network. For example these LSB headers would do the job:
# X-Start-Before:networking
# Required-Start:$local_fs
# Required-Stop:
# Default-Start: S
# Default-Stop: 0 6
Arguably this is a cyclic dependency as - depending on the configuration - OVS
may
indeed rely on a working network to connect to a remote controller. In such
setups
it is probably advised to keep things as is, although OVS may still come up and
fail to connect to the controller which isn't that bad as it keeps reconnecting
I
guess. That being said I believe that my use case is more common for OVS and
should thus be fixed.
Alternatively OVS should provide a way to configure it's own L3 stuff itself so
that
such cyclic dependencies could be avoided. For example, the whole problem could
be
avoided if the IP configuration was stored in the OVS database.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743584: trafficserver 4.1.2-1.1 FTBFS on kfreebsd-*
Hi On 04.04.2014 00:05, Aníbal Monsalve Salazar wrote: As you could guess we don't have a Debian kfreebsd machine to test patches. Dejan and I are following up the NMU of trafficserver 4.1.2-1.1 to fix bugs on mips/mipsel and we noticed it FTBFS on kfreebsd-*. while I do not mind if you go ahead, I did not look into these build issues as trafficserver 4.2 is to be released any day ahead and I wanted to work on the package with the new upstream base. That being said it's probably too late to merge your porting patches upstream for 4.2 anyway, so it may not make a difference anyway. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org
Hi, On 01.04.2014 12:38, Mike Gabriel wrote: When using debian testing, it is not trivial to get the previous version of a package after it is upgraded. [..] debsnap (in devscripts) is your friend. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731074: [pkg-lighttpd] Bug#731074: lighttpd: indeterminate test on kfreebsd buildds
Hi Michael, On 30.03.2014 23:42, Michael Gilbert wrote: I've uploaded this fix to delayed/10 since the build failure is blocking lighttpd from testing. Please see attached patch. since you joined the lighttpd packaging team: Please commit your changes to the VCS and stop doing NMUs, and just do regular maintainer uploads ;) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743225: RM: trafficserver [armel] -- NVIU; ARM out of date; FTBS for newer versions
Package: ftp.debian.org Severity: normal Testing currently has an older version of trafficserver in Testing that blocks migration of the trafficserver package. The package fails to build from source on armel for pretty obsucre reasons so I'd prefer if it was removed for now. Thanks! Note: this was a request for a partial removal from testing, converted in one for unstable -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491547: web server policy requires /var/www, not in FHS
Hi, On 22.03.2014 18:50, Bill Allombert wrote: Are the other HTTP engines going to also change the default document root to /var/www/html ? Yes. I tried to seek consensus with maintainers of other web servers in Debian, and I filed a mass bug to track the state of the adoption [1]. But practically what are you sugesting ? Add a FHS exception for /var/www/html and change the document root in policy ? Yes - either this (where the name html is an implementation detail. With the reasoning being, that any sub directory of /var/www is needed and html is what other distros, e.g. Red Hat use), or allow us to use/assume a directory structure in /srv which may have a larger impact on the FHS than /var/www. [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-doc-root;users=debian-apa...@lists.debian.org;archive=both -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731074: lighttpd: indeterminate test on kfreebsd buildds
severity 731074 important thanks I will downgrade this bug to important for now, as long at is uncertain if this is a bug in lighttpd or kfreebsd's libc. Either way we need to have a newer lighttpd in Testing. If you feel like, feel free to upgrade the severity again, once 1.4.35 hits Testing. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#741904: dma uses debconf as a registry
tags 741904 +pending thanks Hi Stuart, On 17.03.2014 06:10, Stuart Prescott wrote: but really, the .config file should be reading this value from dma.conf prior to asking the user for the new value. The value in the config file must override whatever happens to be in the debconf db when the user runs dpkg-reconfigure dma; the use of db_input without a db_set to read in the current setting beforehand is incorrect. I've commited 8f12e2a36a989f0985c4b1769433f91e3cc1896d to HEAD which should basically be doing what you suggest. Feel free to test the changes in git. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2
Original Message From: marco.ri...@gmail.com Fri Feb 21 09:50:06 2014 Return-Path: marco.ri...@gmail.com X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id 5362C16419A; Fri, 21 Feb 2014 09:50:06 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smart.knallkopp.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 X-policyd-weight: using cached result; rate: -5.5 Received: from muffat.debian.org (muffat.debian.org [206.12.19.146]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id B18AD164178 for deb...@toell.net; Fri, 21 Feb 2014 09:50:00 +0100 (CET) Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]) by muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from marco.ri...@gmail.com) id 1WGlny-0002UE-Jp for deb...@toell.net; Fri, 21 Feb 2014 08:49:59 + Received: by mail-ee0-f42.google.com with SMTP id b15so1451736eek.1 for a...@debian.org; Fri, 21 Feb 2014 00:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MnCfXMdLIR8yfrFpVOsC73jng1WPi2xW1MQ0+AGzT2Y=; b=FlCUSqX90YmXIVCaTpes6szFuydunoaEmZTyIBe0w06rBj/p7fqTiFz+f6+pdtFyGs asQeTAIph/zaIR5F/aFZM222ZWkWJvPotko/1KECj9cvzCLZmi76dIxwZOWBOVKFML2Z +OzdQ6GnV+Yepph4qALDfwhnJzMapwbnHu+TLKKBU9bw6Y57kRK8falB0QI7eRr8VAms SFFomsT1rM0BHI+NztKIoQReas4eyEu7Zb6ORDTG5uCK3OS5ZaRftDcz1WH0xUFcx0EW zdCH0cyZGn3nxKW6QdXLwH05DL+bZJ1pF1zJf9wKUpjxlpDnu3k7mcg+svOWQZrr2kvt IFMw== X-Received: by 10.14.175.2 with SMTP id y2mr6817847eel.75.1392972590781; Fri, 21 Feb 2014 00:49:50 -0800 (PST) Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it. [146.48.81.142])by mx.google.com with ESMTPSA id 46sm24014582ees.4.2014.02.21.00.49.50for a...@debian.org (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Fri, 21 Feb 2014 00:49:50 -0800 (PST) Message-ID: 5307132d.8030...@gmail.com Date: Fri, 21 Feb 2014 09:49:49 +0100 From: Marco Righi marco.ri...@gmail.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Arno Töll a...@debian.org Subject: Re: Bug#739614: [apache2] unable to execute apache2 References: 53060663.7050...@gmail.com 5306157d.6020...@debian.org In-Reply-To: 5306157d.6020...@debian.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit apachectl start Command 593 of 97 #apachectl start sh: 0: getcwd() failed: No such file or directory AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 2a00:1620:c0:50:f66d:4ff:fe74:f12c. Set the 'ServerName' directive globally to suppress this message (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80 (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down AH00015: Unable to open logs Action 'start' failed. The Apache error log may have more information. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737770: Duplicate
forcemerge 714296 737770 severity 714296 serious thanks #737770 is a duplicate of #714296. Moreover, I think this is a serious problem in dia that heavily impacts is usability, next to making it useless (how useful is a diagram drawing tool where you can't use labels whatsoever?). Thus, I'm raising the severity. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#739614: [apache2] unable to execute apache2
Hi Marco, On 20.02.2014 14:42, Marco Righi wrote: Please ask to me if you need more informaitons. Of course we do need more information. You didn't tell us anything we could work with. At very least you should tell us why you think Apache won't start, how you tried, and what happens if you execute apachectl start. You know, anything. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2
Original Message From: marco.ri...@gmail.com Thu Feb 20 16:18:52 2014 Return-Path: marco.ri...@gmail.com X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id 9C42516419A; Thu, 20 Feb 2014 16:18:52 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smart.knallkopp.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 X-policyd-weight: using cached result; rate: -5.5 Received: from muffat.debian.org (muffat.debian.org [206.12.19.146]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id AF2D9164178 for deb...@toell.net; Thu, 20 Feb 2014 16:18:46 +0100 (CET) Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]) by muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from marco.ri...@gmail.com) id 1WGVOe-F6-Qc for deb...@toell.net; Thu, 20 Feb 2014 15:18:45 + Received: by mail-ea0-f177.google.com with SMTP id h14so965338eaj.36 for a...@debian.org; Thu, 20 Feb 2014 07:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KCVsdwZl/eWZiXqUrvvp1mY+bJdhHi4DUGiCgkttRX4=; b=a5lP10JdD+rr+mInYKC4E2uh6alFfk0YOLszGp7ykzrQN191K9Ho81hATU9vjd3Kvz ia2jeBmW4YJ9O8pqswIepGLi2L1FvzDu30cFf8YWSNQFT1Tp1xfu7jSJVzlII1WCcDnf R+hhu6RmZj/P0Hxph2mHNB3QAnMSlcEPC5Ui9hL/T+Vzm5Yb6UMLENR5IiALigbfwAZA fUD8lVIYpwME5mxdMWYx3K4GqKHUB+OZywCBghilXRP6Y5ryS5i+kCnMhOdfyqbCxEfI 5rj+DC3SFHJNKEmLRCEDLdOd7lE78FvKZtuY/9vOgxMetlqWHpccDKW00YT71lWo2Ra5 AeRw== X-Received: by 10.15.42.72 with SMTP id t48mr2439607eev.45.1392909517030;Thu, 20 Feb 2014 07:18:37 -0800 (PST) Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it. [146.48.81.142])by mx.google.com with ESMTPSA id v6sm14914396eef.2.2014.02.20.07.18.36for a...@debian.org (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Thu, 20 Feb 2014 07:18:36 -0800 (PST) Message-ID: 53061ccb.4020...@gmail.com Date: Thu, 20 Feb 2014 16:18:35 +0100 From: Marco Righi marco.ri...@gmail.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Arno Töll a...@debian.org Subject: Re: Bug#739614: [apache2] unable to execute apache2 References: 53060663.7050...@gmail.com 5306157d.6020...@debian.org In-Reply-To: 5306157d.6020...@debian.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit I have try to use /etc/inid.d/apache2 restart The command shell is quick to execute the STOP command. It is very slow during the start session. I have not error messages. I am sure that apache does not run because when I try to connect to localhost with firefox I got a timeout. Moreover, it is strange that the log files are empty! I have try to uninstall completely apache2 using synaptic. After the unistallation I deleted the /etc/apache2 directory. I have installed again apache2 (without delete the apt cache) and I have encountered again the previous problem! do you think that it is important try to execute directly apachectl start? Marco Il 20/02/2014 15:47, Arno Töll ha scritto: Hi Marco, On 20.02.2014 14:42, Marco Righi wrote: Please ask to me if you need more informaitons. Of course we do need more information. You didn't tell us anything we could work with. At very least you should tell us why you think Apache won't start, how you tried, and what happens if you execute apachectl start. You know, anything. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728245: icinga-cgi: fails to install: subprocess installed post-installation script returned error exit status 1
Hi, + APACHE2_NEED_ACTION=1 + a2enmod -m -q cgi + return 1 dpkg: error processing package icinga-cgi (--configure): this is the actual problem. The maintscript-helper could not enable the CGI module and thus fails out. So far that's correct behavior. Now, the underlying question ist _why_ it fails. I cannot reproduce this in a default installation of Apache 2.4 and a clean chroot either. However, note that a2enmod selects cgid over cgi when a threaded MPM was found. Thus, a2enmod cgi will actually enable cgid when the event/worker MPM is used. Either way this is handled correctly I think: (work-amd64)root@build:/build/apache# a2enmod cgi ; echo $? Your MPM seems to be threaded. Selecting cgid instead of cgi. Enabling module cgid. To activate the new configuration, you need to run: service apache2 restart 0 (work-amd64)root@build:/build/apache# (work-amd64)root@build:/build/apache# a2query -m cgi No module matches cgi (work-amd64)root@build:/build/apache# a2query -m cgid cgid (enabled by site administrator) (work-amd64)root@build:/build/apache# a2dismod cgid Module cgid disabled. To activate the new configuration, you need to run: service apache2 restart (work-amd64)root@build:/build/apache# a2enmod -m -q cgi ; echo $? Your MPM seems to be threaded. Selecting cgid instead of cgi. Enabling module cgid. 0 What's special in your environment Andreas making this fail? -- mit freundlichen Grüßen, Arno Töll GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731074: [pkg-lighttpd] Bug#731074: lighttpd: indeterminate test on kfreebsd buildds
Hi Steven. On 27.01.2014 21:22, Steven Chamberlain wrote: I could reproduce it 8 times out of 100 here on kfreebsd-amd64. The race happens after getting Connection Refused trying to contact the fcgi-responder which has just exit (intentionally). The parent does a wait4() syscall, and if this returns the pid of the process that just exit, a new listen is set up on 1/tcp and lighttpd forks a new fcgi-responder. The parent waits with select() for it to be ready, then sends the FCGI request which is successful: is this a libc portability issue then? All in all this does not really sound like a problem in the lighttpd code base, does it? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#734865: libapache2-mpm-itk: fails to install: subprocess installed post-installation script returned error exit status 1
Hi Steinar, On 16.01.2014 21:22, Steinar H. Gunderson wrote: I think this is a separate issue; it was discussed when we split out mpm-itk as a separate package, and the general sentiment was that it will work for wheezy - jessie, but not necessarily sid - sid (the latter is not strictly supported). however, we support an upgrade sid-sid - unless there is a (unrelated) bug - in such, that the update won't error out. Sid users will be warned, but the related postinst code is not supposed to fail in that case. Please check if your maintainer scripts work as expected, as the issue seems to be, that you enable the itk module, before disabling the current (default) mpm. See [1] for properly switchting MPMs in maintainer scripts. On a side note, Andreas would it be possible to do piuparts checks related to Apache and its modules with APACHE2_MAINTSCRIPT_DEBUG=true defined in the environment? That would make the logs more useful. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;h=0bbb06c48d628cd7c3b6037a0118574a722f2184;hb=HEAD#l317 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#714296: dia: pdf export broken for text elements, example attached
forwarded 714296 https://bugzilla.gnome.org/show_bug.cgi?id=573261 thanks As a follow-up, here are some related upstream bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=696128 https://bugzilla.gnome.org/show_bug.cgi?id=705164 https://bugzilla.gnome.org/show_bug.cgi?id=573261 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#714296: dia: pdf export broken for text elements, example attached
Hello, I can confirm this serious problem in dia. See the files attached which contain a simple dia input file and the corresponding PNG/PDF exports. Both are unreadable. This makes dia pretty useless. The problem applies to all versions in Testing/Unstable, (Old-)Stable however is not affected. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D fonts.dia Description: application/dia-diagram fonts.pdf Description: Adobe PDF document attachment: fonts.png signature.asc Description: OpenPGP digital signature
Bug#733377: trafficserver: FTBFS: TsConfigGrammar.hpp:3:3: error: expected identifier before '{' token
tags 733377 pending thanks Hi, the issue is fixed upstream. I'm in the preparation of a new upstream version upload fixing this issue by driving by. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#491547: web server policy requires /var/www, not in FHS
Hi, even more so a discussion on debian-devel [1] came to the conclusion that /var/www as a document root is security-wise a bad default for web servers. Therefore, we, Apache maintainers, decided to change the default document root to /var/www/html (#730372). This might be seen as a policy violation as of §11.5, but we do not violate the FHS as this directory does not exist there. I'm not sure about the state of the FHS when this bug was filed, but to date /srv exists per FHS as a place to put organization-local files, e.g. document roots which is a replacement to /var/www _to users_. We, as a maintainer cannot use /srv straight though to avoid information leaks. Moreover, we must neither assume any organization-local directory structure below /srv. Please clarify this ambiguity in the policy. [1] https://lists.debian.org/debian-devel/2012/04/msg00301.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#732450: please sign new apache releases only with strong keys -- trimming the KEYS file
Hi, On 27.12.2013 00:18, Nick Kew wrote: What is Debian's view on the relative importance of key size vs breadth and depth of the WoT surrounding a key? I would tend to find an ancient 1024-bit key with 100 strong-set sigs much more reassuring than a shiny new 4096-bit with just 1 (let alone any number of non-strong-set keys)! Debian /requires/ new developers to obtain a key being 2048R at least and urges existing developers migrate to stronger keys, while aiming to keep a solid WoT. Formal and informal keysigning parties on DebConfs and resigning requests are a used practice to transition to stronger keys. Full details are covered in [1][2]. Debian's best practices for a key migration are documented in [3] [1] http://lists.debian.org/debian-devel-announce/2010/09/msg3.html [2] http://keyring.debian.org/creating-key.html [3] http://keyring.debian.org/replacing_keys.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#732450: debian/watch: help uscan verify PGP signature automatically
Hi, On 23.12.2013 17:48, Daniel Kahn Gillmor wrote: But if apache is issuing cryptographic signatures from any of the weak keys in KEYS, we should encourage them to stop doing so. Apache's source code is a high-value target, and we should not leave the software distribution mechanism open to fiddling based on weak keys for cryptographic certifications. [..] I recommend filtering KEYS by removing every key whose primary key (or any signing-capable subkey) is less than 3072 bits (assuming RSA or DSA keys here) before storing it in debian/upstream-signing-key,pgp. I'm absolutely with you on that. I strongly agree that Apache people should use stronger keys. However, we're a distribution - it's not our job to define key requirements for upstreams. We can, and maybe should talk to them on that matter but technically it's not only Jim to be allowed to release new versions of the Apache web server. That being said, it's them to accept/define valid and legit keys used within their project. Therefore, I thought a more complete patch would be a keyring which includes all signatures of people allowed to sign and release code on behalf of the httpd project. I do not mind removing weak keys again, but then I wonder if there is an actual benefit if Jim for once doesn't sign a release. Either way, we should move this discussion to upstream I guess. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731074: lighttpd: indeterminate test on kfreebsd buildds
tags 731074 help thanks Hi, On 01.12.2013 18:03, Michael Gilbert wrote: The mod-fastcgi.t test sometimes fails and sometimes succeeds on the kfreebsd build daemons. Please see latest build logs: https://buildd.debian.org/status/logs.php?pkg=lighttpdarch=kfreebsd-i386 https://buildd.debian.org/status/logs.php?pkg=lighttpdarch=kfreebsd-amd64 I did some testing with a real kfreebsd machine, and this test always passes (I uploaded those binaries), so it seems the problem is specific to the buildds. could anyone with sufficient buildd-fu please provide some insight here? In my local sbuild installation lighttpd builds fine on kfreebsd, as it seems to do for Michael's. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#713860: [PATCH] work around bug #712727 (systemd-tmpfiles --create uses non-absolute path)
Hi Michael, On 23.06.2013 12:31, Michael Stapelberg wrote: Package: lighttpd Version: 1.4.31-3 Severity: normal Tags: patch Quote from the commit message: work around bug #712727 (systemd-tmpfiles --create uses non-absolute path) These lines can be reverted once a new debhelper version is uploaded. Note that the Build-Dependency needs to be bumped to make sure that debhelper version is used. This problem results in lighttpd not starting up properly until you either run systemd-tmpfiles --create or reboot your machine. All machines running systemd-44 (currently in Debian stable and sid) are affected. sorry for the dealy. For some reason I missed your patch. It looks #712727 is fixed now, so that we can close this bug without any further action. Do you agree? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731074: lighttpd: indeterminate test on kfreebsd buildds
Hi Christoph, On 24.12.2013 14:15, Christoph Egger wrote: Are you both running stable kernels for the build? are you using chroots or not? I use sbuild and unstable on my dev environment. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#713860: [pkg-lighttpd] Bug#713860: [PATCH] work around bug #712727 (systemd-tmpfiles --create uses non-absolute path)
tag 713860 pending thanks On 24.12.2013 16:12, Michael Stapelberg wrote: Feel free to proceed as you wish :). I obey you blindly, my great master. http://anonscm.debian.org/gitweb/?p=pkg-lighttpd/lighttpd.git;a=commitdiff;h=276708d2dca9f1ffae520a731c918e1ff3e01195 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#732450: debian/watch: help uscan verify PGP signature automatically
tag 732450 +pending thanks Hi Daniel, On 18.12.2013 08:53, Daniel Kahn Gillmor wrote: It looks like Jim Jagielski is signing apache2 releases (at least those from 2.2 onward, which are all that we care about) with his key with fingerprint A93D 62EC C3C8 EA12 DB22 0EC9 34EA 76E6 7914 85A8. So to get uscan to verify this automatically, you'd do: FINGERPRINT='A93D 62EC C3C8 EA12 DB22 0EC9 34EA 76E6 7914 85A8' gpg --keyserver keys.gnupg.org --recv $FINGERPRINT cd src/apache2 gpg --export $FINGERPRINT debian/upstream-signing-key.pgp thanks for that suggestion. I added your patch for the upcoming package upload. I did, however, add the full keyring of Apache developers that /could/ sign a release as listed in http://www.apache.org/dist/httpd/KEYS -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731531: apache2ctl doesn't create /var/run/apache2/
Hi Harald, On 06.12.2013 11:47, Harald Dunkel wrote: Package: apache2 Version: 2.2.22-13 I have to start apache using a dedicated account and sudo /usr/sbin/apache2ctl -f /my/apache2.conf -k graceful instead of root and /etc/init.d/apache2 start. Problem: apache2 fails to start with Cannot create SSLMutex with file `/var/run/apache2/ssl_mutex' /var/run/apache2/ doesn't exist. This is not graceful. Indeed. However, you seem to use your own configuration by bypassing the apache2 init.d scripts. In this case, I claim, It's legit to assume that you take care of creating the directories you need in your (private) configuration yourself. I'd think that it is Debian's job to provide an environment which can be started off the default configuration, but you seem to use a private setup instead. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#718789: apache2: upgrade wheezy - testing (2.4.6-2) wiped out all of my log files
Hi, On 26.11.2013 15:39, Marc Dequènes (Duck) wrote: thus httpd.conf is probably the most problematic lost file. note that we do not ship httpd.conf in Wheezy. If you still have it, it will remain as it is not owned by apache2.2-common anymore. See also: http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.2-common.postinst;h=a730b9eff5f06d34301c2cb23804553f2ac4c21b;hb=refs/heads/wheezy#l80 I guess this is all dead for unstable but a stable upload may introduce some mechanism without recreating an apache2.2-common package. Now that the transition is over, we could reintroduce a -common transitional package, but again, we will carefully evaluate this before, as this causes lots of side-effects. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#690097: Bug #690097 - dynamips: Please enable buildd support
Hi, On 22.11.2013 12:48, Danel Lintott wrote: Is there anything else we need to do to get dynamips enabled for autobuilding? First of all you need to set XS-Autobuild: yes in your debian/control source file. Once you made an upload containing that flag, buildd support should reappear again without any further interaction from your side. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#644227: Please add support for /etc/mime.types.d or alternatives.
Hi Charles, On 23.11.2013 05:34, Charles Plessy wrote: I read the bug discussion and I am not sure to understand the problem that is to solve. Isn't it enough to modify /etc/mimes.types ? If there were a /etc/mime.types.d directory, which package would currently add some files there ? By policy files in /etc are to be modified by the user as you highlight. That being said, it's also guaranteed that changes are preserved across updates. Thus, if a user modifies that file, any future update would not be effective to that user, just because he had to add a custom mime type. That's not ideal, as we face a problem, where a file should be updated, but contain customizable additions aside. You already support this by reading .mime.types, but that's not a solution for daemons which (hopefully) do not rely on environment settings but are keen to start in a predictable configuration. Apache does it, Lighttpd does it and I assume many other daemons dealing with file types do as well. Usually they just read /etc/mime.types, and that's all they know about MIME types. On the other hand, how often did you actually change /etc/mime.type in the last years? Maybe it's a hypothetic problem anyway. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#728937: apache2: broken in system upgrade due to mailgraph Recommends leading to tntnet installation
severity 728937 wishlist tags 728937 pending thanks On 07.11.2013 03:08, Vincent Lefevre wrote: Severity: grave Justification: renders package unusable Your issue renders the package no way unusable, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. In fact, it's not even a bug since you installed a leaf package directly which is not meant to be used standalone. I had the following problem when upgrading Ubuntu from 13.04 to 13.10, and since Debian has more or less the same packages (stable sid), I think it can be affected too. Yet this is Debian, and not Ubuntu. I do not doubt your issue is in Debian, too but still it would be helpful if you verified your problem in Debian when reporting to a Debian bug tracker. Installing tntnet as Recommends of mailgraph Installing libcxxtools9 as Depends of tntnet Installing libtntnet11 as Depends of tntnet Installing tntnet-runtime as Recommends of libtntnet11 The mailgraph Recommends has in particular: httpd | apache2. which is perfectly acceptable, since that's precisely what the recommends line tells. If you believe this is a problem and apache should be pulled instead, report a bug against mailgraph. As the apache2 package wasn't installed on my machine (it is just a metapackage with Apache 2.2, such as in Ubuntu 13.04 and the current Debian stable, so that one can already have an Apache server without this package), this can lead to the installation of another web server such as tntnet via httpd. You can. But it's not supported. That use case is meant for people embedding Apache as embedded server into their binaries, such as gnome-user-share. Everyone else is supposed to install apache2. Note: on this machine, I had apache2-mpm-itk installed, which had Provides: ..., httpd, ... in the 2.2 version, but this line is no longer present in the 2.4 version (the new apache2-bin package has one and is eventually installed due to dependencies, but it seems that apt can't figure this out early enough). Which means, this problem is one existing in apt/aptitude. I don't know the best solution. Add a Provides: line to the transitional packages (such as apache2-mpm-itk), which corresponds to what apache2-bin now provides? At least that seems not to cause problems, so I may add it for the next upload unless I find another unwanted side-effect. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#728937: apache2: broken in system upgrade due to mailgraph Recommends leading to tntnet installation
On 07.11.2013 16:06, Vincent Lefevre wrote: In fact, it's not even a bug since you installed a leaf package directly which is not meant to be used standalone. You're wrong. Users are not forced to install metapackages. I probably did apt-get install apache2-mpm-itk to make sure that this version of the server was installed (something that apt-get install apache2 doesn't). It you think that apache2 must have been installed too, then a Depends: apache2 must have been added (and Provides: apache2 should probably have been removed), or at least a Recommends: apache2. Note that apache2-mpm-itk provided httpd, so that there were no reasons at all to install apache2 *explicitly*. I did not say, that users are forced to install meta packages, but that -mpm-* packages existed _only_ to let reverse dependencies depend on them at Apache 2.2 time, as some modules require a particular MPM to run. They are not meant to be installed standalone by users, and are now fortunately going to disappear. In fact, all they do is to change the link pointing to the MPM you are going to use. However, we cannot just depend on the apache2 package as you suggest, because some packages use the binaries only, without wanting the full stack (configuration files, handling, init scripts etc.) - e.g. look at gnome-user-share which pulls apache2.2-bin. If you look into the 2.2 packages you will notice, that neither of the MPM packages _actually_ includes that MPM. They are all, always installed by apache2.2-bin. No! Apache was already installed (with httpd provided by apache2-mpm-itk, so that this Recommends was satisfied). The problem is that apt pulled tntnet *in addition* to Apache. Yes. But that's a problem of apt[itude], not of the packaging of Apache as I said previously. We ensure that people having apache2-mpm-itk installed get the appropriate package with the appropriate MPM providing httpd in Apache 2.4 again. If that makes apt think that there is no httpd installed for a transient moment in time, well, there is not much we could do against other than working around that limitation (or bug, if you may want to put it that way) which we will do in future as you suggested. A Recommends on httpd | apache2 | apache2-mpm-worker | apache2-mpm-prefork | apache2-mpm-event | apache2-mpm-itk might have solved the problem, but I don't think it is up to mailgraph to know the internals of Apache packages. It is the job of Apache packages to make sure that the transition is OK. Again, we do, unless you use packages in a way they are not meant to be used. Everyone else is supposed to... without a Depends or Recommends? That's insane! Well. I gave you the reason why this is problematic. I suppose Gnome users wouldn't like it if it would pull a web server listening on port 80 by default - don't you think? I agree that this is a borderline case to insanity (and not even my decision back then). but that's the way it is for Apache 2.2. Luckily we do not need to worry anymore as in 2.4 MPMs are regular modules and do not need a special treatment anymore. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717693: Bug#720591: apache2_invoke: configuration phpbb3 not supported in postinst
tags 717693 +patch +pending +moreinfo thanks Hi, On 28.09.2013 23:47, David Prévot wrote: Seems like I’m able to reproduce this issue on upgrade too. If I’m not mistaken, it seems related to #717693 ([im]possible to use apache2_invoke disconf in postinst). That looks like a new behaviour. apache2 maintainers, can you please confirm the issue? Should I look into a workaround (any guidance is welcome)? Could either of you please test the patch I wrote [1]. I was not able to find a maintainer script triggering the issue easily, so that I fixed it without testing. Could you let me know if this fixes the issue for you? [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=commit;h=7bbd9734dcb2403505805301c94a6300d225f386 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi, apart of the arguments raised by others, I'd like to point out three more things: - If we'd be inclined to switch the init system to something different to sysvinit, let's start rather soon than later. Starting with today we have one year until we expect to freeze which sounds like a lot, but it's not if you take in mind that (up to) 1200 packages [1] need to be adapted to this change, some in a non-trivial way. I guess any alternative being discussed here is able to provide some fall-back mechanism in case it's really needed, but if we rely on that, I don't see a reason to switch in the first place. Thus, I'd appreciate if the TC decides on that case rather soon than later since I'm one of these persons who maintains several not-trivial init scripts. - Please bear in mind that supporting more than one init script type is not feasible or doable. Especially for non-trivial scripts [2][3] maintaining an init script is a substantial piece of work, and I claim, that we could spend our time in better ways than maintaining three pieces of code (or, as for me, meta-language description files) which all need to be tested, fixed and updated every once in a while. I guess, I could deal with that burden once for Jessie, but please don't get us into that as a long term solution. - Whatever you decide, please do also turn your attention to the outside world apart of Debian. This discussion was raised (well, this time), because Gnome started to depend transitionally on systemd. Whether we like it or not, but we're not the center of the universe. There are distributions, and very important pieces of software outside the control Debian and the TC that have (biased) points of view conflicting with Debian's on this matter. Thus, I suspect that we are not going to succeed with an isolated island solution, which does not care about the ways other distributions move - especially since the init system choice seems to be heavily tied to the choice of the desktop these days. Whether it's systemd or upstart, both have major players standing behind its respective technologies, each with substantial financial resources to drive development of these platforms in a direction where Debian with an isolated solution cannot compete with, due to its community driven organizational structure. [1] $ apt-file search /etc/init.d | wc -l 1194 [2] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.init;h=f5977abd302115e1517110fc2e00ca0cd2054afd;hb=HEAD [3] http://anonscm.debian.org/gitweb/?p=users/wouter/nbd.git;a=blob;f=debian/nbd-client.init.d;h=23994dd93b315533ee43bbb961b21aa40ff25c00;hb=HEAD -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#727182: apache2: config variables not defined on second reload
tags 727182 +moreinfo
thanks
Richard,
could you please tell us more about your environment? I cannot reproduce
your issue in a clean chroot. I suspect you have some (outdated)
configuration files in your installation, which have not been updated.
Could you also tell us what your output of
dpkg-query -f '${Conffiles}\n' -W apache2
is?
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
Bug#716880: apache2 upgrade failed
On 07.08.2013 21:39, Julian Gilbey wrote: On Sun, Jul 14, 2013 at 02:39:41PM +0200, Arno Töll wrote: * The only way to ship a package named apache2.2-common is to add a Breaks header listing every single reverse dependency with correct version information. That would be 100+ Breaks. I do not think that is feasible but that may need a wider discussion. How did you reach that conclusion? I looked at the current testing distribution, and the only direct dependency on apache2.2-common is libapache2-svn, which may go away when subversion is able to transition to testing. It's one now. :) It was the state as of Squeeze at the time I wrote this as we were in the middle of the transition. Now we can seriously consider doing the transition package approach. Also, it is important to realise that without a dependency from apache2.4 on apache2.2-common, apache2.2-common could be purged by apt(itude) before the first apache2.4 package is even unpacked: looking at my dpkg log, this is exactly what happened. So the mechanism in apache2.2-common.postrm of checking for /etc/apache2/upgrade-to-2.4-in-progress doesn't provide any benefit in this case :-( Right. That's also why we do not use this trapdoor in maintainer scripts. So it seems like having a dependency on a dummy apache2.2-common would be the sensible (if annoying) thing to do. Thanks for this list. I'm short of time for the next 2-4 weeks, and unless sf beats me with it I will address all the outstanding Apache packaging issues then (or try to find a feasible solution at least). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#718789: apache2: upgrade wheezy - testing (2.4.6-2) wiped out all of my log files
On 05.08.2013 16:26, Arno Töll wrote: It's your responsibility if you use this option or apt's equivalent. This is the same problem as #717476. Refer there too, why an apache2.2-common package is problematic. err. #711925 I mean. #717476 is a duplicate of the same issue, too. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#718789: apache2: upgrade wheezy - testing (2.4.6-2) wiped out all of my log files
severity 718789 important thanks On 05.08.2013 15:33, Julian Gilbey wrote: Severity: serious Justification: causes data loss Yes it does, and that's expected. Read the manpage from aptitude (for example): --purge-unused [..] THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING! It's your responsibility if you use this option or apt's equivalent. This is the same problem as #717476. Refer there too, why an apache2.2-common package is problematic. That being said we may just provide it to make these discussions finally (but possibly open a new can'o'worms). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
Hi, On 25.07.2013 11:52, Vincent Lefevre wrote: thus depends on the alias module being there, but the dependency is not enforced anywhere. What if for some reason the alias module gets disabled in the future? Shouldn't a IfModule directive be used in order to avoid the full Apache server being down just because of apache2-doc? There is a certain trade-off to take. We consider some modules crucial for a functioning web-server which shall be enabled on any site. The alias module is one of them. These modules are documented in our PACKAGING policy. This is the same principle as Debian as a whole applies to essential packages, such as dpkg and others. There is no need to express such dependencies explicitly because it is assumed the condition is met on any functioning system. And some way to warn the admin when the alias module is disabled (but when the problem occurs, looking at the apache2-doc config gives the answer). Yes. See #709461. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:02, Vincent Lefevre wrote: Then wouldn't it be possible during an upgrade of some packages (e.g. apache2, apache2-doc) to make sure that these modules are enabled, and re-enable them if they aren't? As said, unless due to a bug, these modules are always enabled. However, some people might still prefer to disable them by free choice and that's something we have to respect in compliance with the policy and in hope these people know what they are doing. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:16, Ondřej Surý wrote: could you please rethink the idea of re-adding apache2.2-common with version Breaks: on all reverse depends (with versions from wheezy, the jessie can be handled by filling RC bugs case-by-case). Yes, we did not definitely decide on that. It is, however, not going to solve this bug in particular as the conffiles would have to move regardless from apache2.2-common to apache2 which is the root cause with --purge-unsued. It may solve other problems you have though, e.g. your pre-depdency in PHP and so on. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:25, Ondřej Surý wrote: Wouldn't Package: apache2 Replaces: apache2.2-common ( 2.4.0) Breaks: apache2.2-common ( 2.4.0) Solve the problem? That's what we do already (minus breaks). That allows us to overwrite and take-over conffiles from apache2.2-common. This works nicely and does what it is supposed to do - except in cases where people use --purge-unused because they think that's fun. In that case apt[itude] decides to purge all of /etc/apache2 entirely _before_ we have a deterministic chance to do look at the state, because apache2.2-common is going to be removed by upgrading to 2.4. I am not sure if an empty 2.2-common package in addition to that would solve that problem, as it would ship none of the conffiles either, so consequently they would still be purged. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 25.07.2013 13:39, Vincent Lefevre wrote: If users are allowed to disable these modules in compliance with the policy, then you need to make sure that Apache still works in such a case (e.g. for a personal website that doesn't need these modules). The use of IfModule could be a solution. Try apt-get remove bash or apt-get remove dpkg and agree with the scary warning and see what works thereafter (no, don't do it for real). You will notice, you just broke your system badly without any safety net. The definition of an essential package is do not remove it. If you still do, it's your business to deal with the situation. Same for these modules - however, I agree that we need to communicate this more prominently (again, see #709461). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
-prefork 2.2.22-13 (using .../apache2-mpm-prefork_2.4.6-2_amd64.deb) ... [ ok ] Stopping web server: apache2. Unpacking replacement apache2-mpm-prefork ... Preparing to replace libxml2:amd64 2.8.0+dfsg1-7+nmu1 (using .../libxml2_2.9.1+dfsg1-2_amd64.deb) ... Unpacking replacement libxml2:amd64 ... Selecting previously unselected package libbsd0:amd64. Unpacking libbsd0:amd64 (from .../libbsd0_0.6.0-1_amd64.deb) ... Selecting previously unselected package libedit2:amd64. Unpacking libedit2:amd64 (from .../libedit2_2.11-20080614-6_amd64.deb) ... Preparing to replace php5-cli 5.4.4-14+deb7u2 (using .../php5-cli_5.5.1+dfsg-1_amd64.deb) ... Unpacking replacement php5-cli ... Selecting previously unselected package lsof. Unpacking lsof (from .../lsof_4.86+dfsg-1_amd64.deb) ... Preparing to replace php5-common 5.4.4-14+deb7u2 (using .../php5-common_5.5.1+dfsg-1_amd64.deb) ... Unpacking replacement php5-common ... dpkg: warning: unable to delete old directory '/etc/php5/conf.d': Directory not empty Processing triggers for man-db ... fopen: Permission denied Can not write log, openpty() failed (/dev/pts not mounted?) Setting up apache2.2-bin (2.4.6-2) ... Setting up libxml2:amd64 (2.9.1+dfsg1-2) ... Setting up lsof (4.86+dfsg-1) ... Setting up php5-common (5.5.1+dfsg-1) ... Installing new version of config file /etc/cron.d/php5 ... php5_invoke: Enable module pdo for cli SAPI php5_invoke: Enable module pdo for apache2 SAPI Creating config file /etc/php5/mods-available/opcache.ini with new version php5_invoke: Enable module opcache for cli SAPI php5_invoke: Enable module opcache for apache2 SAPI Setting up libapache2-mod-php5 (5.5.1+dfsg-1) ... Replacing config file /etc/php5/apache2/php.ini with new version php5_invoke pdo: already enabled for apache2 SAPI php5_invoke opcache: already enabled for apache2 SAPI apache2_invoke php5: already enabled [Ok] Restarting web server: apache2 Setting up apache2-mpm-prefork (2.4.6-2) ... Setting up libbsd0:amd64 (0.6.0-1) ... Setting up libedit2:amd64 (2.11-20080614-6) ... Setting up php5-cli (5.5.1+dfsg-1) ... Replacing config file /etc/php5/cli/php.ini with new version php5_invoke pdo: already enabled for cli SAPI php5_invoke opcache: already enabled for cli SAPI root@build:/# root@build:/# a2query -m env (enabled by unknown) authz_host (enabled by unknown) mpm_prefork (enabled by site administrator) alias (enabled by unknown) authz_core (enabled by maintainer script) authz_user (enabled by unknown) negotiation (enabled by unknown) dir (enabled by unknown) reqtimeout (enabled by unknown) mime (enabled by unknown) autoindex (enabled by unknown) auth_basic (enabled by unknown) authn_file (enabled by unknown) setenvif (enabled by unknown) authn_core (enabled by maintainer script) php5 (enabled by unknown) access_compat (enabled by maintainer script) cgi (enabled by unknown) deflate (enabled by unknown) authz_groupfile (enabled by unknown) status (enabled by unknown) filter (enabled by maintainer script) unique_id (enabled by unknown) root@build:/# apt-get install apache2-doc Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: apache2-mpm-prefork apache2.2-bin libcurl3-gnutls librtmp0 libssh2-1 Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: apache2-doc 0 upgraded, 1 newly installed, 0 to remove and 123 not upgraded. Need to get 2.650 kB of archives. After this operation, 19,7 MB of additional disk space will be used. Get:1 http://ftp.de.debian.org/debian/ sid/main apache2-doc all 2.4.6-2 [2.650 kB] Fetched 2.650 kB in 1s (1.566 kB/s) Can not write log, openpty() failed (/dev/pts not mounted?) Selecting previously unselected package apache2-doc. (Reading database ... 14326 files and directories currently installed.) Unpacking apache2-doc (from .../apache2-doc_2.4.6-2_all.deb) ... Can not write log, openpty() failed (/dev/pts not mounted?) Setting up apache2-doc (2.4.6-2) ... apache2_invoke: Enable configuration apache2-doc [Ok] Reloading web server: apache2 failed! root@build:/# a2query -m env (enabled by unknown) authz_host (enabled by unknown) mpm_prefork (enabled by site administrator) alias (enabled by unknown) authz_core (enabled by maintainer script) authz_user (enabled by unknown) negotiation (enabled by unknown) dir (enabled by unknown) reqtimeout (enabled by unknown) mime (enabled by unknown) autoindex (enabled by unknown) auth_basic (enabled by unknown) authn_file (enabled by unknown) setenvif (enabled by unknown) authn_core (enabled by maintainer script) php5 (enabled by unknown) access_compat (enabled by maintainer script) cgi (enabled by unknown) deflate (enabled by unknown) authz_groupfile (enabled by unknown) status (enabled by unknown) filter (enabled by maintainer script) unique_id (enabled by unknown) root@build:/# apachectl configtest Syntax OK -- with kind regards, Arno Töll IRC: daemonkeeper
Bug#711925: apache2-doc's config file breaks apache itself
On 24.07.2013 13:54, Norbert Preining wrote: Removal does not work easily, since gnome depends on apache2. Gnome depends on apache2-bin which works fine without apache2 and any configuration file as they are all in apache2. So how should I know what modules etc should be active and what not? How should I (and other people) go tback to a working configuration? How did you upgrade? Did you use --purge-unused or whatever the equivalent for apt is? As I say, in a regular upgrade in a unmodified build chroot your issue does not appear. I would already be happy if you could send a list of modules/conf that should be linked. for module in authz_host auth_basic access_compat authn_file authz_user \ alias dir autoindex \ env mime negotiation setenvif \ filter deflate \ status ; do a2enmod -m -q $module done -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#711925: apache2-doc's config file breaks apache itself
On 24.07.2013 22:47, Stefan Fritsch wrote: The bug in apache2 is that we still treat this situation as an upgrade in the postinst even if there is nothing left of the old install. If we can detect it, we should probably treat it as a new install instead. I do not think we could in a deterministic way. We might be able to guess based on certain heuristics, like no conffiles whatsoever but the apache packages being installed. However, I am sure this will bite others who deliberately rm'ed all of /etc/apache2 because they think our configuration sucks anyway. We could also add a check to apache2.2-common's prerm to detect the purging during an upgrade and abort, and get that change into wheezy in a point release. However, only people who have upgraded to the latest version will benefit from that change. And I am not sure that this is a good approach in any case. Not sure about the goodness of that approach either, but that's certainly possible. I am not sure how you would like to detect this situation though? Alternatively we could enforce the modules being installed regardless of it being an upgrade or not (though this might be a debatable choice in view of policy correctness) or get apt[itude] maintainers to display a warning when using --purge-unused during a dist-upgrade. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717610: a second run of aptitude safe-upgrade clears it
On 23.07.2013 12:02, Ondřej Surý wrote: And I would say it's a regression from apache2 2.4.4-6 to 2.4.6-1. If it is related, you are right. However, I did not change these things fundamentally. Ondřej can you provide me an output of the bad behavior with APACHE2_MAINTSCRIPT_DEBUG set in your environment? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717610: [php-maint] Bug#717610: a second run of aptitude safe-upgrade clears it
On 23.07.2013 12:29, Ondřej Surý wrote: Control: reassign -1 apache2 Control: retitle -1 apache2-maintscript-helper doesn't support dpkg triggers Yep, thanks. That is it. Did you recently enable triggers for your maintainer script so that the 2.4.6-1 upload is just coincidence? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717448: apache2: Invalid command 'AuthType'
clone 717448 -1 reassign -1 apache2 retitle -1 apache2: Please enable authn_core by default thanks On 21.07.2013 15:59, Thijs Kinkhorst wrote: Does it make sense to allow to use mod_authn_file unconditionally in config files, but not allow authn_core unconditionally? authn_core provides directives that are common to all authentication providers. We can of course discuss this. I'm making a separate issue out of it, as its not directly related to the problem in phpmyadmin. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80
Hi, On 21.07.2013 17:32, Edward Welbourne wrote: Even though I actually have a NameVirtualHost in my enabled sites-available file, matching exactly the same file's VirtualHost parameter, my configuration was broken by a NameVirtualHost *:80 elsewhere, that I knew nothing about. ... Given that the VirtualHost directive lives in a user-configurable file and *must* exactly match the NameVirtualHost directive, it strikes me that the old way, having the later also in the user-configurable file, was a better approach than the present, where the user must - in fact - edit a file that's not in sub-directory in which user-configuration normally takes place. If there's genuinely a compelling reason to put the NameVirtualHost somewhere other than *right next to* the VirtualHost directive (as I'm fairly sure it used to be), where it'll be obvious that they need to stay in sync, please add a comment to default, immediately before the VirtualHost directive, saying be sure to keep ports.conf's NameVirtualHost in sync; the host:port must match exactly. First, let me point out that also ports.conf is a user-configurable file. You can safely edit and adapt it to your needs. That what it is meant for. Having NameVirtualHost in 000-default though is dangerous, at is a directive being _shared_ across virtual hosts. It is used by all sites, including but not limited to the default site. Assuming you deactivate the default site, this causes undefined and broken behavior if you have other name based virtual hosts. This is a major problem lots of Debian users stumbled upon over the years. Thus, we're more than glad and very happy NameVirtualHost is no more in 000-default.conf and we are definitely not going back that road. That being said please note, that NameVirtualHost itself is deprecated and not used anymore in Apache2 2.4. There is no chance to fix this in Debian Stable anyway due to our freezing policy, and the next Debian release will have Apache2 2.4 only, not using NameVirtualHost at all anymore. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#717448: apache2: Invalid command 'AuthType'
reassign 717448 phpmyadin thanks On 21.07.2013 03:59, Jean-Michel Vourgère wrote: Try $ a2enmod authn_core It fixes the same problem here. AuthType is provided by authn_core in httpd 2.4 and no longer provided by the core module. As such, it is not available unconditionally in a apache2 2.4 installation. Packags must not use such directives without protecting them with IfModule. Please see our packaging guidelines at [1]. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=master#l194 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#707024: apache2.4 transition
On 20.07.2013 13:53, Lior Kaplan wrote: Are we still waiting for some dependent packages or we can close this issue We are. Please see [1]. Colin NMUed most of the outstanding packages, and we will discuss together with the Release Team when to migrate to Testing once the NMUs are beyond their 10 day waiting period. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=apache24transition;users=debian-apa...@lists.debian.org;archive=both -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#666802: libapreq2: sourceful transition towards Apache 2.4
Hi, On 15.07.2013 21:05, Steinar H. Gunderson wrote: I've uploaded 2.13-2, which goes through (I hope) all necessary motions to build against Apache 2.4. However, it also fixes a bunch of other things, and one of them is a package rename from libapreq2 to libapreq2-3, which means that the package must go through NEW processing. I bribed my favorite ftpmaster [assistant] so that it went through NEW already. That means you guys at debian-perl@ could possibly work on the remaining level 2 dependencies for the modules requiring a transitioned libapreq2. Thanks for considering working on it :) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: apache2 upgrade failed
Hi, On 14.07.2013 09:47, Helmut Grohne wrote: As far as I can tell the only way to fix this issue is to introduce a transitional apache2.2-common package containing no files. apache2 would need to depend on apache2.2-common for one release (skipping a release is not supported). we cannot do this as long as the transition is ongoing. Sadly lots of packages reverse-depends on on apache2.2-common. Satisfying this dependency would create (even more) havoc on such systems as apt would not force a removal of packages depending ob not provided ABIs. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716880: apache2 upgrade failed
On 14.07.2013 12:08, Helmut Grohne wrote: I do not see how the transition is affecting this option. If it breaks during the transition, it can also break a partial upgrade. Introducing apache2.2-common later can cause a broken wheezy-jessie upgrade when a user fails to upgrade the corresponding apache module. Is this correct or am I missing something? Pretending we provided apache2.2-common, modules depending on the 2.2 version of the server had their depdencies satisfied. Thus, they would be co-installable with Apache 2.4, they would migrate to Testing and so on. However, if you try to enable such a module, it breaks the whole server which fails to start as there will be symbol lookup errors at runtime. We could possibly discuss your suggestion as soon as nothing in Debian depends on apache2.2-common anymore, but for now that just adds more havoc. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#716880: apache2 upgrade failed
On 14.07.2013 12:38, Helmut Grohne wrote: My point was that if modules had their dependencies satisfied in such a way, then dependencies are wrong even for a wheezy - jessie upgrade, because as you later point out it would break the whole server. They are wrong and this can get really nasty. I don't know who introduced them this way back then but they hurt us now. * The only way to prevent apache2 configuration from being purged during upgrade is to keep shipping a package named apache2.2-common and to have apache2 depend on it. I am not sure this is the only way. Possibly it could be the other way around and transition from apache2.2-common to apache2 through a transitional package. * The only way to ship a package named apache2.2-common is to add a Breaks header listing every single reverse dependency with correct version information. That would be 100+ Breaks. I do not think that is feasible but that may need a wider discussion. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#715439: glpi: unowned files after purge (policy 6.8, 10.8): /etc/apache2/conf-available/glpi.conf - /etc/glpi/apache.conf
Hi Andreas, On 09.07.2013 07:42, Andreas Beckmann wrote: Cc:ed the apache2 maintainers, as this might be a bug in their packaging helpers or instructions, too. we don't do either: Neither we suggest to use a link for conf-available files, nor do we document this use case in our policy. In fact, we even transitioned from conf.d to conf-available so that maintainers can unconditionally install files to conf-available without fearing to activate it automatically which might not be what the site owner desires. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#715485: (no subject)
Source: uwsgi
Severity: serious
Hi,
similar to #715472 reported by Julien, you should really think twice whether you
want to depend on a hardcoded API version. Unlike PHP our version is much less
often to change, but this still complicates future transitions.
That being said, the real problem is the dependency line:
676 Depends: ${shlibs:Depends}, ${misc:Depends}, apache2, apache2-api-20120211
You must NOT depend on apache2. as this pulls the entire web-server and makes it
impossible for future transitions to properly transition to a newer version
without breaking your package explicitly. From our packaging policy (found in
/usr/share/doc/apache2-dev):
72 The resulting binary package should be called libapache2-mod-modulename and
73 MUST NOT depend on apache2 or apache2-bin. Instead a module package must
depend
74 on our virtual package providing the module magic number which denotes the
ABI
75 compatibility version number. The virtual package is called
apache2-api-MMDD
76 and is guaranteed to be stable through all binary updates of 2.4.x. The
77 dh_apache2 helper assists in getting the dependencies right.
If you meant to depend on Apache2 to satisfy your dependency against mod_proxy,
please look at our depends line enforcing module dependencies against each
other,
documented in the same policy.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666794: subversion: diff for NMU version 1.7.9-1+nmu3
Hi, thanks for having subversion on the radar. On 09.07.2013 23:10, Julien Cristau wrote: as subversion is on the critical path for the update to apache 2.4, I've prepared an NMU for subversion (versioned as 1.7.9-1+nmu3) and am going to upload it to DELAYED/2. That should (assuming it builds everywhere) get it off the crit path and give more time for a proper fix. I'm not saying you should not go ahead, but I'd highly appreciate if people feeling competent enough could have a look at the patches created by Barry at [1] and [2] which do port Subversion to Apache 2.4. I'm really not in the position to judge about their impact apart of things specific to Apache, so maybe Peter could ack them in time before Julien uploads the proposed NMU? That would be much better than dropping the Apache modules altogether. [1] http://people.debian.org/~bdefreese/serf/ [2] http://people.debian.org/~bdefreese/subversion/ -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#709468: closed by Janos Guljas ja...@debian.org (Bug#709468: fixed in uwsgi 1.2.3+dfsg-6)
On 08.07.2013 03:46, Colin Watson wrote: I'm afraid this doesn't seem to truly fix this bug. uwsgi still Build-Depends on apache2-threaded-dev, which is no longer available with Apache 2.4, so this currently fails to build on Ubuntu and will eventually either fail to build in unstable or block the removal of the old MPM binary packages from unstable. It is neither available in Debian unless you consider virtual provides. Either way the package is already broken and will not work in Unstable for the state being. I hope this is just a matter of dropping the build-dependency ... No, it's not. See #666793. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#666842: libapache2-mod-encoding: sourceful transition towards Apache 2.4
Hi Colin,
On 08.07.2013 16:26, Colin Watson wrote:
I think that this patch should do the job, but it's the first module
I've worked on for the 2.4 transition. Could a Debian Apache expert
have a look? If it looks OK, I'm willing to NMU for this, since the
last maintainer upload was nearly six years ago.
sure. Your patch looks fine and does the packaging side of the module
exactly the way it's meant.
-Build-Depends: debhelper (= 4.0.0), libiconv-hook-dev, apache2-threaded-dev
(= 2.0.50-9) | apache2-dev (= 2.0.50-9)
+Build-Depends: debhelper (= 4.0.0), libiconv-hook-dev, dh-apache2,
apache2-dev (= 2.0.50-9)
This is all fine, though (= 2.0.50-9) is trivially satisfied for eons
in Debian. You may keep it as is, but any version of Apache provided in
Debian since Sarge (I think) satisfies this dependency.
-Depends: apache2.2-common, ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Perfect. That's the most important part of the whole transition. That
said, I never tested dh-apache2 at such low compat levels. Please ensure
it works correctly and adds apache2-api-20120211 to ${misc:Depends}.
Everything else looks correct, too. Please note, I did not compile the
module with your patch. Please pay attention whether the upstream
codebase still compiles against the 2.4 APIs. In particular the build
system is often not triggering a fatal build failure for obsolete
symbols due to the nature of a plugin. However, may test rebuild last
year [1] indicated it would still work indeed.
Apart, please go ahead an NMU the module as soon as you see it fits to you.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666842#10
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
Bug#709465: libapache2-mod-ruid2: Apache 2.4 moves to Unstable
severity 709465 serious thanks Looks like your package from Experimental implementing the apache 2.4 transition was removed (#696733). Thus, this bug is serious again. Please fix your package in unstable as soon as possible. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#666808: apparmor: sourceful transition towards Apache 2.4
Hi, If needed, I might be able to help for the upload at the right time part, but I don't plan to learn how to use/test the AppArmor changehat Apache module any time soon, so this really should be done by someone else. any chance to move on with an upload anytime soon? AppArmor has reverse dependencies in Testing so that we cannot easily move on with the Apache transition as long as this module is not fixed or removed. If possible, please NMU this package as soon as possible. Alternatively I may NMU it by disabling the module as I have _no_ clue about AppArmor or how to test the module. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
