Bug#724282: New release 2.1.5
Hello, It would be great if the new release 2.1.5 could be included in some backports (at least)… It would prevent people to get some personal repository with possible old release… As sphinxsearch provides packages for stable and old-stable, it shouldn't be long to insert them (though I'm pretty sure other arch would also be glad to get the newest release). Cheers, C. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725684: some more information
Hello, I tried the 1.7.2 (Jessie) and 1.7.3 (apt.puppetlabs.com), there's exactly the same problem. Seems the github repository has some huge differences, maybe it would be better to build the package based on this version instead… Any update on this bug would be appreciated, it's a bit a blocker for us :(. Cheers, C. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725684: AWS VPC not supported by facter-1.7.1
Package: facter Version: 1.7.1 severity: important When we run facter in a freshly Amazon VPC instance, it doesn't get the ec2_* facts as it should. Problem seems to be located in Facter::Util::EC2.has_ec2_arp function: it checks the instance MAC address, which is predictable on non-VPC instances (fe:ff:ff:ff:ff:ff), but not on VPC instances, as they do have a real MAC address. My tests seem to show the generated MAC has this root: 12:ea:49:c0 This means we should be able to modify util/ec2.rb like this: --- ec2.rb.ori 2013-10-07 14:06:14.391700848 +0200 +++ ec2.rb 2013-10-07 08:58:28.690642654 +0200 @@ -40,9 +40,9 @@ mac_address_re = case kernel when /Windows/i - /fe-ff-ff-ff-ff-ff/i + /(fe-ff-ff-ff-ff-ff|12-ea-49-c0)/i else - /fe:ff:ff:ff:ff:ff/i + /(fe:ff:ff:ff:ff:ff|12:ea:49:c0)/i end arp_command = case kernel Or, maybe, we can ignore this check… MAC address isn't the best way to test this kind of stuff, the Facter::Util::EC2.can_connect should be sufficient… -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710356: [nagios3-core] No scheduled downtime retention
Control tag -1 +confirmed Hello Didier, hello Nagios maintainers, The provided package works as expected, the status are really kept *and* applied after a reload or restart. Thanks a lot for the quick support :). Cheers, C. On Thu, 30 May 2013 11:44:58 +0200 Didier 'OdyX' Raboud o...@debian.org wrote: Control: tags -1 +patch +upstream Hi Cédric, hi Nagios maintainers, Le jeudi, 30 mai 2013 09.29:54, Cédric Jeanneret a écrit : I just installed the latest nagios3* on a debian Wheezy, and stumbled on a bad bug: the scheduled downtime event aren't kept when a restart or reload occurs. (…) After some researches, I stumbled on this nagios resolved bug: http://tracker.nagios.org/view.php?id=338 It seems there's a patch available since October 2012 on the SVN: Fixed in svn with the supplied patch and will ship with the first version after 3.4.1 - it may be good to have a look at 3.4.2 (or something like that), as a major feature is currently broken. The dpatch'ed backport of the (git-)svn commit from upstream is attached. I have built nagios3-core targetted at stable with the above patch (debdiff attached), the built files are available there: http://alioth.debian.org/~odyx-guest/debian/wheezy/ Cédric; it would be useful if you could test these. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691861: unscd: executable nor configuration name reflect package name (executable: nscd, config: nscd.conf)
On Thu, 1 Nov 2012 18:21:14 -0700 Don Armstrong d...@donarmstrong.com wrote: Control: severity -1 minor Control: tag -1 wontfix On Tue, 30 Oct 2012, Cedric Jeanneret wrote: unscd package should provide an executable named unscd, and its configuration file should be /etc/unscd.conf. Currently, the unscd package provides unscd init-file nscd executable nscd.conf configuration file unscd is a drop in replacement for nscd, so it uses the exact same configuration file and the exact same executable. It's possible to provide a /usr/sbin/unscd and a /usr/sbin/nscd symlink, but it's not particularly necessary. well, it's just in order to get a consistent package naming… Having unscd package with unscd init-script, I'm tempted to say the executable is unscd - oh crap! it isn't! This comment is obviously false: - file doesn't exist, it's /usr/share/doc/unscd/NEWS.Debian.gz - the package nscd tells us to install unscd in order to have stable host caching That again is in order to have unscd be a drop in replacement. Otherwise, the user will be prompted to replace the default nscd configuration file. err, if this allow the user to activate the host caching [by default], this may be good, doesn't it? As nscd tells us hey install unscd, it's better and you can have host caching, I was a bit surprised to see the option deactivated by default… More over, having a wrong documentation link in a config file is just bad. This very point should be corrected I think, don't you? Cheers, C. Don Armstrong -- Cédric Jeanneret | System Administrator 021 619 10 32| Camptocamp SA cedric.jeanne...@camptocamp.com | PSE-A / EPFL www.camptocamp.com | www.github.com/camptocamp signature.asc Description: PGP signature
Bug#691861: unscd: executable nor configuration name reflect package name (executable: nscd, config: nscd.conf)
Package: unscd Version: 0.48-2 Severity: normal unscd package should provide an executable named unscd, and its configuration file should be /etc/unscd.conf. Currently, the unscd package provides unscd init-file nscd executable nscd.conf configuration file More over, the provided nscd.conf file is a simple copy of the one provided by package nscd, containing the following comment: # hosts caching is broken with gethostby* calls, hence is now disabled # per default. See /usr/share/doc/nscd/NEWS.Debian. This comment is obviously false: - file doesn't exist, it's /usr/share/doc/unscd/NEWS.Debian.gz - the package nscd tells us to install unscd in order to have stable host caching The provided nscd.conf file disables the host caching by default, which is wrong. And it should be called unscd.conf. If the naming intends to avoid users getting mad with some hey, nscd command doesn't exist!, it may be a symlink to unscd, but that's bad I think. Thank you for your consideration C. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-308.8.2.el5.028stab101.1 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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#605657: isc-dhcp-server: The DHCP server fails to start when only alias interfaces have an address
Hello,
this bug is still present, and is currently preventing us to upgrade to
Squeeze
here's what we have:
/etc/network/interfaces
#
# ETH3: Interface LAN (wrk/tel/gst)
#
iface eth3 inet dhcp
metric 0
auto eth3:wrk
auto eth3:tel
auto eth3:gst
iface eth3:wrk inet static
address 10.26.10.1
netmask 255.255.255.0
iface eth3:tel inet static
address 10.26.11.1
netmask 255.255.255.0
iface eth3:gst inet static
address 10.26.12.1
netmask 255.255.255.0
Revelant part of dhcpd.conf:
shared-network eth3 {
# File managed by puppet
subnet 10.26.10.0 netmask 255.255.255.0 {
option routers 10.26.10.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.26.10.255;
option domain-name wrk.cby.camptocamp.com;
option domain-name-servers 10.26.10.1;
deny unknown-clients;
filename pxelinux.0;
next-server 10.26.21.8;
}
# File managed by puppet
subnet 10.26.11.0 netmask 255.255.255.0 {
option routers 10.26.11.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.26.11.255;
option domain-name tel.cby.camptocamp.com;
next-server 10.26.21.2;
deny unknown-clients;
option domain-name-servers 10.26.11.1;
}
# File managed by puppet
subnet 10.26.12.0 netmask 255.255.255.0 {
option routers 10.26.12.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.26.12.255;
option domain-name gst.cby.camptocamp.com;
allow unknown-clients;
filename pxelinux.0;
next-server 10.26.21.8;
option domain-name-servers 10.26.12.1;
}
}
Whan trying to start the daemon, it doesn't see the eth3 interface nor its
attached virtual interfaces. Trying to set up INTERFACES='eth3' or eth3:wrk
eth3:tel eth3:gst in /etc/default/isc-dhcp-server doesn't help.
Any advise, hint or resolution would be great.
We also tried package version from weezy, it doesn't work...
Thank you.
Cheers,
C.
--
Cédric Jeanneret | System Administrator
021 619 10 32| Camptocamp SA
cedric.jeanne...@camptocamp.com | PSE-A / EPFL
www.camptocamp.com | www.github.com/camptocamp
signature.asc
Description: PGP signature
Bug#500876: fix for 500876
Hello!
unfortunately, I can't test it anymore... finally we put an alienized kernel
downloaded directly from openvz.org. We couldn't wait, as our servers are
really overprovisionned... And I don't known when we'll be able to buy another
server :/
Maybe someone else vith a bi-quad can test it?
Thanks for your time patching the kernel anyway. If it works, we'll use it on
new servers [when we'll buy them... someday -.-]
Regards,
C.
On Tue, 3 Mar 2009 13:43:56 -0700
dann frazier da...@dannf.org wrote:
On Tue, Mar 03, 2009 at 09:34:26PM +0100, Ola Lundqvist wrote:
Hi Dann
The openvz 686 version is now regression tested. I have also asked the
person that had the problem with this bug to verify the amd64 kernel as
well.
Best regards,
Thanks!
// Ola
On Tue, Mar 03, 2009 at 11:36:17AM -0700, dann frazier wrote:
On Tue, Mar 03, 2009 at 05:54:09PM +0100, Ola Lundqvist wrote:
Hi Dann
Looks very similar to the patch I proposed. Here it is.
I was not aware you could add more files so I appended to the
end of the file.
Ah - yeah, in fact we _must_ have separate files. That gives us the
ability to generate older versions of the source tree from the
latest. Of course, that doesn't work so well for the features
patches, since they sometimes have to be regen'd to apply.
When you have different files like this, which order will it take
them?
That is determined by the series file. At application, the build
system parses the series file (using the changelog to determine
order), and applys all of the normal patches (series files that don't
end in -extra), followed by all of the -extra patches.
I guess the only thing remaining is to verify that this patch works
well and risk of regression is low - do you have a system (or systems)
you can use to test the builds here?
http://people.debian.org/~dannf/bugs/500876/
Best regards,
// Ola
On Tue, Mar 03, 2009 at 09:31:36AM -0700, dann frazier wrote:
On Tue, Mar 03, 2009 at 07:49:05AM +0100, Ola Lundqvist wrote:
Hi Dann
Quoting dann frazier da...@dannf.org:
hey Ola,
Attached is a patch I have queued for lenny.
I've posted builds w/ this fix here:
http://people.debian.org/~dannf/bugs/500876/
Oh, thanks a lot.
Would you be able to review the patch/test the build to confirm
that
its ok for a stable update? Note that it doesn't change the ABI.
Good to know that it does not change the ABI. I was just about to
send you
a mail with my own work regarding this issue. My machine is
currently
building a package with this patch.
Do you have a diff file on what you did? If not I'll send mine
later today.
The patch applied fine and seems to build on 686 arch at least.
Best regards,
// Ola
oops - forgot to attach it
Index: debian/patches/series/14-extra
===
--- debian/patches/series/14-extra(revision 0)
+++ debian/patches/series/14-extra(revision 0)
@@ -0,0 +1 @@
++ features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
featureset=openvz
Index:
debian/patches/features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
===
---
debian/patches/features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
(revision 0)
+++
debian/patches/features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
(revision 0)
@@ -0,0 +1,112 @@
+From: Konstantin Khlebnikov khlebni...@openvz.org
+Date: Tue, 7 Oct 2008 08:57:48 + (+0400)
+Subject: fix wrong size of ub0_percpu.
+X-Git-Tag: sync-2.6.27-15.10.08~5
+X-Git-Url:
http://git.openvz.org/?p=linux-2.6.26-openvz;a=commitdiff_plain;h=777e8164ebf8a03e43511983cdec472f8691a8af
+
+fix wrong size of ub0_percpu.
+
+after commit b3242151 struct percpu_data dynamically allocated
+and have array only for 1 cpu, so static usage of it does not work.
+
+Plus rework macros for static percpu variables declaration and
initialization.
+
+http://bugzilla.openvz.org/show_bug.cgi?id=1039
+
+Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
+Signed-off-by: Pavel Emelyanov xe...@openvz.org
+---
+
+diff --git a/include/linux/percpu.h b/include/linux/percpu.h
+index 5ac97e1..e159f4d 100644
+--- a/include/linux/percpu.h
b/include/linux/percpu.h
+@@ -74,11 +74,20 @@ struct percpu_data {
+ (__typeof__(ptr))__p-ptrs[(cpu)];\
+ })
+
+-#define static_percpu_ptr(sptr, sptrs) ({ \
++struct percpu_data_static {
++void
