Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Russ Allbery  writes:

> Ferenc Wagner  writes:
>
>> Thanks.  Regarding xmltooling, We could as well do a regular upload
>> replacing the liblog4cpp5-dev dependency of libxmltooling-dev with
>> liblog4shib-dev.  I only noticed this yesterday when building opensaml
>> pulled in log4cpp, sorry.
>
> I think I was just confused and everything is fine, since the transition
> already happened after the previous NMU.  There's still a transition for
> opensaml2 and shibboleth-sp2, I think, but that's tiny and not a big deal.

Do you mean the library name transition (+v5), of which this bug is
about?

> It's probably fine to upload opensaml2 right away, but I'll wait until
> log4shib propagates everywhere just in case.

Looks like it won't, the builds fail everywhere.  At first sight the
problem seems to be that on amd64:

checking if gcc static flag -static works... no

which leads to liblog4shib.la being created, while on other arches:

checking if gcc static flag -static works... yes

and liblog4shib.la is not created, leading to an error when debian/rules
tries to remove it.  While this would be easy to work around, I really
wonder what's going on.  Looking at my older build logs, the -static
flag occasionally worked on amd64, but most of the it does not work
(according to configure).  Why does this happen?
-- 
Thanks,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Russ Allbery  writes:

> Ferenc Wagner  writes:
>
>> That's great!  Let's start with log4shib, another immediate BD of
>> OpenSAML2, which also has a not-yet-packaged upstream release.  I
>> applied the DEP-14 transformation (branch renaming) to the Alioth repo,
>> and did some streamlining, similarly to xmltooling.  The result is
>> available at https://mentors.debian.net/package/log4shib.  Please review
>> and upload if suitable.  I'm doing OpenSAML itself tomorrow.
>
> Uploaded log4shib.  We're going to need to ask for a binNMU for xmltooling
> as well to pick up the new dependency.  I forgot about that until just
> after I uploaded it.
>
> I'll open a bug against release.debian.org for the mini-transition.

Thanks.  Regarding xmltooling, We could as well do a regular upload
replacing the liblog4cpp5-dev dependency of libxmltooling-dev with
liblog4shib-dev.  I only noticed this yesterday when building opensaml
pulled in log4cpp, sorry.
-- 
Regards,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Ferenc Wagner  writes:

> I'm doing OpenSAML itself tomorrow.

I converted the Alioth repository to DEP-14 and pushed all my changes.
Please review and upload if it's suitable.  Preferably after
log4shib_1.0.9-1 is in, I guess, so that it builds against that version.
-- 
Thanks,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Russ Allbery  writes:

> Ferenc Wagner  writes:
>
>> Please wait a little, I'm packaging the new upstream anyway and will
>> introduce this change soon (I'll need a sponsor, though).
>
> I should be able to help with sponsorship.

That's great!  Let's start with log4shib, another immediate BD of
OpenSAML2, which also has a not-yet-packaged upstream release.  I
applied the DEP-14 transformation (branch renaming) to the Alioth repo,
and did some streamlining, similarly to xmltooling.  The result is
available at https://mentors.debian.net/package/log4shib.  Please review
and upload if suitable.  I'm doing OpenSAML itself tomorrow.
-- 
Thanks,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Luca BRUNO  writes:

>> On Tue, 01 Sep 2015 10:48:28 +0200 Ferenc Wagner  wrote:
>>
>>> I'll package new upstream versions of the whole Shibboleth stack to
>>> fix the outstanding OpenSAML security bug in unstable.
>>> This will change the SO version of xml-security-c and
>>> probably all other library packages in the stack.  Does this change the
>>> big picture somehow?  I don't understand the interdependencies of this
>>> transition.
>
> I had a quick look at this, and I think that libsaml is not getting any
> soname bump in latest upstream version: 
> https://git.shibboleth.net/view/?p=cpp-opensaml.git;a=commitdiff;h=390147dc17687e900bf6a50f3577ccc611a0a7cd;hp=ec145bf31d59d23bbf63cdc39ffeb172ed29d67d
>
> As such, I think we can just proceed with a NMU introducing libsaml8v5.
> This will also remove the last blocker for libshibsp.

Please wait a little, I'm packaging the new upstream anyway and will
introduce this change soon (I'll need a sponsor, though).
-- 
Thanks,
Feri.

Bug#809966: [Debian-ha-maintainers] Bug#809966: libcrmcommon-dev: arch-dependent file in "Multi-Arch: same" package

[Ferenc Wagner]

Jakub Wilk  writes:

> libcrmcommon-dev is marked as "Multi-Arch: same", but the following
> file is architecture-dependent:
>
> /usr/include/pacemaker/crm_config.h

Is there anything to do besides setting the package to Multi-Arch: no?
Has the multiarch specification been extended to include files yet?
-- 
Thanks,
Feri.

Bug#809764: [Debian-ha-maintainers] Bug#809764: Bug#809764: libqb6-dev and libqb-dev: error when trying to install together

[Ferenc Wagner]

Herbert Fortes (hpfn)  writes:

> "In case several development versions of a library exist, you may need
> to use dpkg's Conflicts mechanism"

I think the Policy means this between versions of the same library
(eg. your libqb6-dev and a later libqb7-dev).

But anyway, this is a more broader problem: there are now two libraries
named libqb in Debian.  Currently we provide libqb0 and libqb-dev
packages, you provide libqb6 and libqb6-dev and we have a guarranteed
file name conflict in the dev packages.  It's already confusing, but
there's no telling when the package names themselves will clash.  The
absolutely best solution would be persuading an upstream to change the
library name.  Webcamoid seems to be the newer project, therefore its Qb
library might have seen less use, so I don't find it unreasonable to
approach its maintainer with this problem.
-- 
Regards,
Feri.

Bug#804590: [Debian-ha-maintainers] Bug#804590: redhat-cluster: build-depends on libcorosync-dev which is no longer built

[Ferenc Wagner]

Jonathan Wiltshire  writes:

> On Mon, Dec 14, 2015 at 02:22:54AM +0100, Ferenc Wagner wrote:
>
>> The redhat-cluster package will be removed from the archive, we don't
>> intend to fix it.
>
> Here's the hit list then:

[gfs2-utils, lvm2, ocfs2-tools]

That's fine, once pacemaker passes NEW, we can upload the new DLM
package and adjust the above to use it instead of redhat-cluster.
-- 
Thanks,
Feri.

Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Emilio Pozuelo Monfort  writes:

> This is the last blocker for the perl transition. Packages should be
> installable now in unstable. Please let us know if you make progress
> with this or if you hit any blockers.

Short progress report: no blockers.

I encountered unexpected problems, but they are mostly solved by now.
While waiting for the review of my sponsor, I'm doing QA tests.
-- 
Regards,
Feri.

Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Ferenc Wagner  writes:

> Emilio Pozuelo Monfort  writes:
>
>> On 16/12/15 00:12, Ferenc Wagner wrote:
>>
>>> Niko Tyni  writes:
>>> 
>>>> So the proper way out seems to be a separate libdlm source package, as
>>>> discussed in [1]. Ferenc, do I understand right that a new pacemaker
>>>> package is a blocker for this? Is that because the current pacemaker
>>>> would be broken by the libdlm update?
>>> 
>>> No: the new DLM package depends on the new Pacemaker package.  I'm
>>> already testing them, there's only some cleanup remaining before they
>>> can be uploaded.  Both will go through NEW though, so it will take some
>>> time.
>>
>> I can speed things up if they block a transition... Got an eta for this?
>
> That sounds useful!  I expect to get pacemaker_1.1.13-1 ready for upload
> today, taking some shortcuts.

Now the Perl transition is rolling and I can't build Pacemaker anymore,
because some of its build dependencies are broken.  Is there still a
reason to hurry the uploads?
-- 
Regards,
Feri.

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Emilio Pozuelo Monfort  writes:

> On 16/12/15 00:12, Ferenc Wagner wrote:
>
>> Niko Tyni  writes:
>> 
>>> So the proper way out seems to be a separate libdlm source package, as
>>> discussed in [1]. Ferenc, do I understand right that a new pacemaker
>>> package is a blocker for this? Is that because the current pacemaker
>>> would be broken by the libdlm update?
>> 
>> No: the new DLM package depends on the new Pacemaker package.  I'm
>> already testing them, there's only some cleanup remaining before they
>> can be uploaded.  Both will go through NEW though, so it will take some
>> time.
>
> I can speed things up if they block a transition... Got an eta for this?

That sounds useful!  I expect to get pacemaker_1.1.13-1 ready for upload
today, taking some shortcuts.  I'll try to contact my usual sponsor, but
other interested parties can also step in. :)  If no serious issue
surfaces during this process, we can quickly repeat for DLM.

>> Then LVM will have to be rebuilt against the new DLM, and you
>> will be free to kick redhat-cluster out of the archive (I hope nothing
>> else depends on it).
>
> Checking reverse dependencies...
> # Broken Depends:
> gfs2-utils: gfs2-cluster [amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x]
> gfs2-utils [amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x]
> lvm2: clvm [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el 
> s390x]
>
> # Broken Build-Depends:
> gfs2-utils: libccs-dev (>= 3.1.0)
> libcman-dev (>= 3.1.0)
> libdlm-dev (>= 3.1.0)
> libdlmcontrol-dev (>= 3.1.0)
> libfence-dev (>= 3.1.0)
> liblogthread-dev (>= 3.1.0)
> lvm2: libcman-dev (> 2)
>   libdlm-dev (> 2)
> ocfs2-tools: libdlm-dev
>  libdlmcontrol-dev

Thanks.  We will take care of gfs2-utils and ocfs2-tools soon, those are
also maintained by the HA team.
-- 
Regards,
Feri.

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Niko Tyni  writes:

> So the proper way out seems to be a separate libdlm source package, as
> discussed in [1]. Ferenc, do I understand right that a new pacemaker
> package is a blocker for this? Is that because the current pacemaker
> would be broken by the libdlm update?

No: the new DLM package depends on the new Pacemaker package.  I'm
already testing them, there's only some cleanup remaining before they
can be uploaded.  Both will go through NEW though, so it will take some
time.  Then LVM will have to be rebuilt against the new DLM, and you
will be free to kick redhat-cluster out of the archive (I hope nothing
else depends on it).

Actually, it would be possible to temporarily omit Pacemaker support
from DLM, but I'd like to avoid that if possible.
-- 
Regards,
Feri.

Bug#804590: [Debian-ha-maintainers] Bug#804590: redhat-cluster: build-depends on libcorosync-dev which is no longer built

[Ferenc Wagner]

gregor herrmann  writes:

> On Mon, 09 Nov 2015 20:39:32 +0100, Emilio Pozuelo Monfort wrote:
>
>> Your package build-depends on libcorosync-dev which is no longer
>> built by corosync. Please switch to the appropriate packages to
>> build against the new version.
>
> Afer replacing libcorosync-dev with libcorosync-common-dev and
> libconfdb-dev, the build ends with:
> [...]
> /build/redhat-cluster-3.1.8/config/plugins/xml/config.c:6:35: fatal error: 
> corosync/lcr/lcr_comp.h: No such file or directory
> compilation terminated.
>
> and corosync/lcr/lcr_comp.h seems to be gone from the archive.
>
> Looks like this need more work than just changing build dependencies.

The redhat-cluster package will be removed from the archive, we don't
intend to fix it.
-- 
Regards,
Feri.

Bug#796345: [Debian-ha-maintainers] redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Dominic Hargreaves  writes:

> From [2] it appears that work is underway to fix all this, by including
> libdlm as a separate package. Presumably at this point lvm2 would not
> depend on redhat-cluster and it could be removed from testing?

Yes, that's the plan.

> As a more immediate fix - can the HA team comment on whether libccs-perl
> has any value?

Being built from the redhat-cluster source package, it will go when we
remove redhat-cluster from the archive.  Has it got any rdeps?

> If not then perhaps that should just be dropped from the
> redhat-cluster package ASAP [...] -- of course, since redhat-cluster
> FTBFS, this would have to be done by the release team manually
> removing (just) libccs-perl from testing. Is this feasible?

I don't know if it's possible, but if yes: no objection from the HA
team.
-- 
Regards,
Feri.

Bug#802410: [Debian-ha-maintainers] Bug#802410: openais: FTBFS: error: corosync/coroipc_types.h: No such file or directory

[Ferenc Wagner]

Fernando Seiti Furusato  writes:

> It also fails on ppc64el and other architectures

Hi Fernando,

We're planning to drop the openais package altogether, replacing it by
Corosync 2.  The new HA stack builds DLM, cLVM and GFS directly on
Corosync.
-- 
Regards,
Feri.

Bug#793855: DoS, Shibboleth SP software crashes on well-formed but invalid XML (CVE-2015-0851)

[Ferenc Wagner]

Salvatore Bonaccorso  writes:

> On Thu, Sep 24, 2015 at 08:54:08AM +0200, Ferenc Wagner wrote:
>
>> Salvatore Bonaccorso  writes:
>> 
>>> Any news for the fix to unstable for CVE-2015-0851?
>> 
>> Sorry, I got bogged down in another department.  It isn't forgotten,
>> though, I expect to tend to it in a couple of days.
>
> *ping*? ;-)

I clearly failed to live up to my promise.  Sorry for that.  Things are
shaping up, though, I really expect to start packaging the newest stack
next week latest.  (That will take care of the C++ transition, too.)
-- 
Regards,
Feri.

Bug#752512: corosync: Corosync doesn't start at reboot

[Ferenc Wagner]

Hi,

Does syslog contain anything corosync-related after bootup, but before
you start it manually?  Isn't it the DRBD timeout mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752512#10 ?
-- 
Thanks,
Feri.

Bug#746980: Conflicting declarations of function pload_initialize

[Ferenc Wagner]

Hi,

Do you get such reports with the current corosync versions?  Much has
changed in this area, I can't identify pload_initialize anymore.
-- 
Thanks,
Feri.

Bug#711043: corosync: /etc/init.d/corosync stop freeze

[Ferenc Wagner]

Hi,

Does this also happen with the current packages?  Pacemaker isn't a
plugin anymore, thus it shouldn't be able to freeze Corosync shutdown.
On the other hand, the systemd unit files order Pacemaker shutdown
strictly before Corosync shutdown, because killing Corosync under
running Pacemaker usually leads to the node being fenced.
-- 
Thanks,
Feri.

Bug#801870: [Debian-ha-maintainers] Bug#801870: redhat-cluster: dead upstream?

[Ferenc Wagner]

tag 801870 +pending
thanks

Arturo Borrero Gonzalez  writes:

> I think this is dead project :-( because:
>  * latest upstream release was almost 3 years ago (early 2013)
>  * no movements in mailing lists
>  * lots of dead links in redhat/fedorahosted websites
>  * no news / articles talking about it in recent times
>
> If this is true, I would recommend removing redhat-cluster from the
> Debian archive.

Absolutely, that's the plan.  DLM has a separate upstream, which is
already packaged but not uploaded yet.  redhat-cluster will be removed
soon.
-- 
Regards,
Feri.

Bug#753289: almost fixed it

[Ferenc Wagner]

reopen 753289
thanks

The autogenerated GitHub archive, which we used as orig tarball for 2.3.4,
did not contain the m4 directory.  This broke the default dh_autoreconf
action (that is, autoreconf -f -i), and we chose the easy way out: invoking
the supplied autogen.sh.  Unfortunately, that invokes autoreconf without the
-f option, thus stopped updating config.sub and config.guess when used on
proper distribution tarballs (like that of 2.3.5).

We're dropping the override in the next upload.
-- 
Regards,
Feri.

Bug#800521: systemd: sys-kernel-config.mount not functional

[Ferenc Wagner]

Michael Biebl  writes:

> Or, the dlm packages ships a modules-load.d snippet in
> /usr/lib/modules-load.d where it loads the configfs mdoule, since it's
> the dlm package which apparently needs configfs, not systemd itself.

Well, this is the point where we obviously differ: in my opinion, the
sys-kernel-config.mount unit provided by systemd needs configfs.  Not in
the technical sense because of the ConditionPathExists=/sys/kernel/config
directive, which I find historical baggage hiding the problem and tripping
the outsiders.  If that wasn't there, the issue would be much more clear
cut.  But I think in the practical sense it still is, and systemd should
ensure that pulling in sys-kernel-config.mount results in configfs being
available under its standard mount point.  (I think the kernel could as
well expose the /sys/kernel/config mount point unconditionally, even if
configfs is a not yet loaded module or even disabled, but I digress.)

Basically, it all boils down to the meaning of sys-kernel-config.mount.  I
don't know what else requires or will require a mounted configfs, but it
should not need to care about configfs being modules or built in, or the
path of its standard mount point.  Putting Require=sys-kernel-config.mount
(and After=) should take care of that, concentrating all the system-
specific knowledge into the system manager.  After all, stuff should
preferably work even under a user-compiled monolithic kernel.  I'm not
sure how to best handle that, but certainly in the central module loader,
not in the individual packages providing stuff.

Please forgive me pushing this so stubbornly; maybe I'd just need to sleep
on it.
-- 
Regards,
Feri.

Bug#800521: systemd: sys-kernel-config.mount not functional

[Ferenc Wagner]

Michael Biebl  writes:

> Have you asked dlm upstream, why they do it this way? Maybe they
> simply don't know about modules-load.d? I would in any case try to get
> this change upstream.

Looking at #ExecStopPost=/sbin/modprobe -r dlm, I think they didn't use
modules-load.d because they wanted to remove the dlm module on unit
deactivation.  They may have given up, though, and I don't see the point
either.  I'll try to contact them.

But this would make the sys-kernel-config.mount unit functional only
when dlm-controld is installed, which sounds somewhat unsatisfactory.
-- 
Thanks,
Feri.

Bug#800521: systemd: sys-kernel-config.mount not functional

[Ferenc Wagner]

Michael Biebl  writes:

> Am 30.09.2015 um 16:04 schrieb Ferenc Wagner:
>
>> Michael Biebl  writes:
>> 
>>> Why are your using a .service file to load the dlm module?
>> 
>> Sorry for being confusing by eliding too much.  The dlm service starts
>> the DLM control daemon, and also loads the dlm kernel module beforehand.
>> It's dlm_controld which needs a mounted configfs (and the dlm module):
>> 
>> $ systemctl cat dlm
>> # /lib/systemd/system/dlm.service
>> [Unit]
>> Description=dlm control daemon
>> Requires=corosync.service sys-kernel-config.mount
>> After=corosync.service sys-kernel-config.mount
>> 
>> [Service]
>> OOMScoreAdjust=-1000
>> Type=notify
>> NotifyAccess=main
>> EnvironmentFile=/etc/default/dlm
>> ExecStartPre=/sbin/modprobe dlm 
>> ExecStart=/usr/sbin/dlm_controld --foreground $DLM_CONTROLD_OPTS
>> #ExecStopPost=/sbin/modprobe -r dlm
>> 
>> # If dlm_controld doesn't stop, there are active lockspaces.
>> # Killing it will just get the node fenced.
>> SendSIGKILL=no
>> 
>> [Install]
>> WantedBy=multi-user.target
>> 
>>> Why does the dlm.service require the sys-kernel-config fs?
>> 
>> Because dlm_controld uses files under /sys/kernel/config/dlm.
>> 
>>> Can't you just ship a snippet in /usr/lib/modules-load.d/ and then also
>>> include configfs in there?
>> 
>> No, loading the dlm kernel module is only part of the task.
>
> Sure, but why don't you load the dlm + configfs module not via a
> module-load.d snippet, knowing that the Debian kernel doesn't have it
> builtin?

Do you mean I should remove the ExecStartPre directive and load dlm
(which would pull in the configfs kernel module, too) from a
module-load.d snippet?  That would work, but that would also mean
deviating from the logic used by the upstream service file.  And systemd
is supposed to make distributions converge, not diverge, AFAIK.

>>> Fwiw, I don't think there is anything to fix on the systemd side.
>> 
>> Do you mean that sys-kernel-config.mount somehow manages to work for you
>> under jessie?  Then my initial analysis must be incorrect somewhere.
>
> See the upstream bug report you referenced:
> Either the module should be compiled in, or software requiring it should
> make sure to load the module itself, ideally by shipping a
> modules-load.d snippet.

Exactly.  Now, sys-kernel-config.mount is shipped by systemd, so I'd
expect systemd to make sure it actually works.  In the upstream
bugreport they got configfs compiled in the kernel, for example.  Or am
I mistaken about the purpose of the sys-kernel-config.mount unit?  Is
that unit supposed to make configfs mounted only under certain
circumstances?  The DLM upstream does not seem to think so, and the
cited RedHat bug report doesn't handle the issue like that, either.
-- 
Regards,
Feri.

Bug#800521: systemd: sys-kernel-config.mount not functional

[Ferenc Wagner]

Michael Biebl  writes:

> Why are your using a .service file to load the dlm module?

Sorry for being confusing by eliding too much.  The dlm service starts
the DLM control daemon, and also loads the dlm kernel module beforehand.
It's dlm_controld which needs a mounted configfs (and the dlm module):

$ systemctl cat dlm
# /lib/systemd/system/dlm.service
[Unit]
Description=dlm control daemon
Requires=corosync.service sys-kernel-config.mount
After=corosync.service sys-kernel-config.mount

[Service]
OOMScoreAdjust=-1000
Type=notify
NotifyAccess=main
EnvironmentFile=/etc/default/dlm
ExecStartPre=/sbin/modprobe dlm 
ExecStart=/usr/sbin/dlm_controld --foreground $DLM_CONTROLD_OPTS
#ExecStopPost=/sbin/modprobe -r dlm

# If dlm_controld doesn't stop, there are active lockspaces.
# Killing it will just get the node fenced.
SendSIGKILL=no

[Install]
WantedBy=multi-user.target

> Why does the dlm.service require the sys-kernel-config fs?

Because dlm_controld uses files under /sys/kernel/config/dlm.

> Can't you just ship a snippet in /usr/lib/modules-load.d/ and then also
> include configfs in there?

No, loading the dlm kernel module is only part of the task.

> Fwiw, I don't think there is anything to fix on the systemd side.

Do you mean that sys-kernel-config.mount somehow manages to work for you
under jessie?  Then my initial analysis must be incorrect somewhere.
-- 
Thanks,
Feri.

Bug#800521: forgot the extension

[Ferenc Wagner]

I mean:

# echo configfs >/etc/modules-load.d/configfs.conf

Bug#793855: DoS, Shibboleth SP software crashes on well-formed but invalid XML (CVE-2015-0851)

[Ferenc Wagner]

Salvatore Bonaccorso  writes:

> Any news for the fix to unstable for CVE-2015-0851?

Sorry, I got bogged down in another department.  It isn't forgotten,
though, I expect to tend to it in a couple of days.
-- 
Regards,
Feri.

Bug#499014: dbus - Fails to install: chown: invalid group: `messagebus:messagebus'

[Ferenc Wagner]

reassign 499014 schroot
thanks

Thanks, it was useful.  This happens after reusing an schroot after
installing dbus inside it, if the host does not have the messagebus
user/group.  Because schroot by default overrides the NSS databases of
the chroot by those of the host, see /etc/schroot/*/nssdatabases.

Which makes this more an schroot bug than a dbus one.  Merging the
databases would be preferable.
-- 
Regards,
Feri.

Bug#765365: corosync build-depends

[Ferenc Wagner]

tags 765365 - pending
thanks

"Adrian.Vondendriesch"  writes:

> IIRC I've set the tag because leberus was working on it. But there were
> problems building the Build-Debs on hurd.
>
> At the end there wasn't any outcome. So, removing the pending tag seams
> reasonable.

Thanks for the info.  So, we'll probably look into this eventually, but
not working on it right now.
-- 
Feri.

Bug#797623: Bug#797625: xmltooling: transition needed for g++-5 ABIs

[Ferenc Wagner]

Hi,

Thanks for the detailed report.  Right now I'm doing urgent work on HA
packages, but once that's done, I'll package new upstream versions of
the whole Shibboleth stack to fix the outstanding OpenSAML security bug
in unstable.  This will change the SO version of xml-security-c and
probably all other library packages in the stack.  Does this change the
big picture somehow?  I don't understand the interdependencies of this
transition.  Anyway, feel free to NMU these packages if that helps
unblocking other stuff, just don't be too concerned about the fate of
the current versions in unstable, expect new upstream versions after a
couple of weeks.
-- 
Regards,
Feri.

Bug#788496: Not a regression, but would be nice to have

[Ferenc Wagner]

tags 788496 -moreinfo
severity 788496 wishlist
thanks

The version numbers in the original report reflect a change in
python-apt (longer commit messages appeared there), not in gbp.
While the --customizations option provides a workaround, I think line
wrapping should be enabled by default in gbp-dch, because commit IDs and
Closes tags can inflate changelog line lengths.
-- 
Regards,
Feri.

Bug#796329: dependencies are also needed

[Ferenc Wagner]

Actually, what I suggested above is not enough, these
/lib/multipath/*.so files occasionally require other shared libraries,
like libaio.so.1 in the case of /lib/multipath/libcheckdirectio.so.  I'm
not sure what's the best way to chase down these, but it's already done
for executables, so support is already there somewhere.

Bug#793855: DoS, Shibboleth SP software crashes on well-formed but invalid XML (CVE-2015-0851)

[Ferenc Wagner]

We're already working on this with the Security Team.  I wonder if I
should prepare new packages (for {wheezy,jessie}-security) with the
changelogs closing this bug.  Or should it be closed by the unstable
upload of 1.5.5?  The proposed security uploads can be found at
http://apt.niif.hu/CVE-2015-0851/.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#570232: about later changes

[Ferenc Wagner]

Unfortunately, the above recipe stopped working under wheezy.
It was broken and later fixed upstream, see:
http://www.redhat.com/archives/lvm-devel/2012-March/msg00162.html

Lock conversion to exclusive is also problematic, as this patch isn't
included yet:
https://www.redhat.com/archives/lvm-devel/2013-December/msg00095.html

On the other hand, adding cmirrord to the LVM2 packages seems feasible.
I added it to the clvmd package locally, and after fixing some stack
smashing bugs we're starting to get encouraging test results.  Let's see
what upstream has to say on this...
-- 
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#788824: RFS: sblim-wbemcli/1.6.3-1 (new upstream patchlevel release + minor touch-ups)

[Ferenc Wagner]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sblim-wbemcli"

 * Package name: sblim-wbemcli
   Version : 1.6.3-1
   Upstream Author : Tyrel Datwyler 
 * URL : 
http://sourceforge.net/apps/mediawiki/sblim/index.php?title=Wbemcli
 * License : Eclipse Public License -v 1.0
   Section : admin

It builds those binary packages:

  sblim-wbemcli - WBEM Command Line Interface for CIMOM access
  sblim-wbemcli-dbg - debugging symbols for sblim-wbemcli

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/sblim-wbemcli

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/s/sblim-wbemcli/sblim-wbemcli_1.6.3-1.dsc

Changes since the last upload:

 * New upstream release.
 * Drop gcc4.7-fixes.patch (fixed upstream).
 * Enable hardening=+all.
 * Remove dh_builddeb override, xz compression is the default.
   Drop the corresponding Pre-Depends: dpkg (>= 1.15.6~) as well.
 * Add uupdate to watch file.
 * Update copyright years of aclocal.m4, INSTALL, configure and Makefile.in,
   because upstream upgraded to Autoconf 2.68.
 * Include upstream NEWS and README.

Regards,
Ferenc Wágner


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745778: openssh-server/permit-root-login should be honored for new installs too

[Ferenc Wagner]

Christoph Anton Mitterer  writes:

> On Thu, 2015-04-30 at 23:00 +0200, Ferenc Wagner wrote: 
>
>> By "usual means" do you mean preseeding late_command with a sed
>> script editing sshd_config?
>
> No I rather meant by using the installation system or configuration
> system you use (FAI, puppet, etc.)

Actually, we only need the initial root login so that our configuration
system can bootstrap the login policy of the organization (which means
LDAP user DB, SSH key authorization and no root login at all).  We could
work around this issue in various ways, but we'd rather continue on the
known path if possible.  And the documentation says it is...
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745778: openssh-server/permit-root-login should be honored for new installs too

[Ferenc Wagner]

By "usual means" do you mean preseeding late_command with a sed script
editing sshd_config?
https://www.debian.org/releases/jessie/i386/apbs05.html.en#preseed-hooks
That's certainly possible, but preseeding a boolean (as documented) is
significantly simpler.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745778: openssh-server/permit-root-login should be honored for new installs too

[Ferenc Wagner]

The preseed possibility is actually documented in the jessie release
notes, see
https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#openssh
I tried to use it in vain, then found this bug.
Please raise its urgency. :)
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781633: [Pkg-freeipmi-devel] Bug#781633: /usr/sbin/ipmiconsole: repeated text in man page

[Ferenc Wagner]

forwarded 781633 http://savannah.gnu.org/bugs/?44698
thanks

ja...@crackle.treshna.com writes:

> the section "KNOWN ISSUES" in the ipmiconsole man page partially occurs twice.
> (search for the string "KNOWN ISSUES" )

I reported this upstream, they'll probably fix this eventually.
http://savannah.gnu.org/bugs/?44698
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781632: [Pkg-freeipmi-devel] Bug#781632: /usr/sbin/ipmiconsole: path wrong?

[Ferenc Wagner]

ja...@crackle.treshna.com writes:

> ipmiconsole installis in /usr/sbin but it does not require root
> permissions to use (possible work-arounds for this are obvious) but this
> seems sub-optiomal

I'm not sure it's worth deviating from the upstream installation
practice (and manpage section), given that a symlink in /usr/local/bin
looks like a sufficient workaround.  Maybe open an issue upstream?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768922: [Debian-ha-maintainers] pacemaker in jessie

[Ferenc Wagner]

franz schaefer  writes:

>> As many of us, see
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768922.
>
> thanks for the link. so from the discussion there the only reason that 
> libqb0 is not newer is that it did not work on kfreebsd which is no longer
> important as this is droped from beeing fully suported anyway. 
>
> so the only thing left is to compile libqb0 version 0.17.0-2 which is in sid
> now for jessie and then the pacemaker 1.1.10+git20130802-4.1 version that
> was in jessie until recently will work just fine
>
> the libqb0 version 0.17.0-2 compiled on jessie out of the box. 
>
> so that should be quick and easy. who is going to do it?

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768922#35 Jonathan
Wiltshire (member of the release team) stated that migrating libqb isn't
an option.  And the pacemaker reversion did not happen either.  Lacking
direction, other people couldn't do anything about this either.  Though
in retrospect, I feel like we would have had enough time for migrating
libqb after all.  It's really sad we got nowhere instead.  I'm turning
towards getting a fresh cluster stack backported into jessie instead.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775930: [lvs-users] [PATCH] ipvsadm: add SCTP support

[Ferenc Wagner]

Alexander Wirt  writes:

> On Wed, 11 Feb 2015, Ferenc Wagner wrote:
>
>> supp...@remsnet.de writes:
>> 
>>> From: "Ferenc Wagner" 
>>>
>>>> supp...@remsnet.de writes:
>>>> 
>>>>> I can´t understand why Debian , Suse , FC / Redhat  and it´s clones
>>>>> Distrubtions still publish the buggy ipvsadm 1.26 .
>>>> 
>>>> The change of distribution location may play a role in this.  The latest
>>>> tarballs at http://www.linux-vs.org/software/kernel-2.6/ are of version 
>>>> 1.26.
>>>> See for example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775930.
>>>
>>> Thanks Ferry ,
>>> to explain why Debian are 5 years behind the Mainsteam at IPVS - and
>>> clones as well.
>>>
>>> and yes see the Anouncment  of the ipvsadm 1.27 at the "lvs-user" list,
>>>
>>> The ipvsadm Tarball Distribution had been changed  at 2013 , an GIT
>>> repro exist since then from
>>>
>>> http://www.linux-vs.org/software/kernel-2.6/ to
>>> https://kernel.org/pub/linux/utils/kernel/ipvsadm
>>>
>>> Julian, Me and others HAD written Notices to distrib mainta8iners -
>>> but that seems been ignored.
>> 
>> Not arguing here.  I tried to provide some explanation, not an excuse.
>> The Debian watch file certainly points to the old location.
>
> googling for ipvsadm also doesn't help. It doesn't give you any hint of the
> new location.

First of all, thanks for the quick upload of 1.28!  While at it, would
you mind also fixing the watch file and adding VCS control fields, if
your packaging repo is public?
-- 
Regards,
Feri.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775930: [lvs-users] [PATCH] ipvsadm: add SCTP support

[Ferenc Wagner]

supp...@remsnet.de writes:

> From: "Ferenc Wagner" 
>
>> supp...@remsnet.de writes:
>> 
>>> I can´t understand why Debian , Suse , FC / Redhat  and it´s clones
>>> Distrubtions still publish the buggy ipvsadm 1.26 .
>> 
>> The change of distribution location may play a role in this.  The latest
>> tarballs at http://www.linux-vs.org/software/kernel-2.6/ are of version 1.26.
>> See for example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775930.
>
> Thanks Ferry ,
> to explain why Debian are 5 years behind the Mainsteam at IPVS - and
> clones as well.
>
> and yes see the Anouncment  of the ipvsadm 1.27 at the "lvs-user" list,
>
> The ipvsadm Tarball Distribution had been changed  at 2013 , an GIT
> repro exist since then from
>
> http://www.linux-vs.org/software/kernel-2.6/ to
> https://kernel.org/pub/linux/utils/kernel/ipvsadm
>
> Julian, Me and others HAD written Notices to distrib mainta8iners -
> but that seems been ignored.

Not arguing here.  I tried to provide some explanation, not an excuse.
The Debian watch file certainly points to the old location.
-- 
Regards,
Feri.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#270368: even jessie will ship with this bug

[Ferenc Wagner]

I'd like to add that gethostbyname.3 also refers to the order line in
/etc/host.conf, thus is should be corrected as well.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#270368: even jessie will ship with this bug

[Ferenc Wagner]

Please,

Is there any controversy about this bug?  Now it cost me quite some
time, and I guess I'm not alone with that.  The solution seems simple
enough and is undisputed, so why not just fix it?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768618: [Debian-ha-maintainers] Bug#768922: Bug#768618: pacemaker: FTBFS in jessie: build-dependency not installable: libqb-dev (>= 0.16.0.real)

[Ferenc Wagner]

Simon Horman  writes:

> On Mon, Jan 19, 2015 at 09:26:36AM +0900, Christian Balzer wrote:
> 
>> Meanwhile, here in what it what we tenuously call reality one can observe
>> the following things:
>> 
>> 1. Pacemaker broken in Jessie for more than 2 months now.
>> 2. Silence on this bug for more than one month.
>> 3. Pacemaker was recently removed from Jessie.
>> 4. The February 5th deadline is rapidly approaching, cue the laughingstock.
>> 
>> Between systemd and this gem Jessie is shaping up to be the best Debian
>> release ever...
>
> I wonder if there are any active members of the Debian linux-ha team.
> Speaking for and pointing the finger at myself for one who
> has been inactive for several years.
>
> I for one would be happy to see an NMU here.

There were a couple offers of help on the list (in October and November)
but the situation was rather hopeless already then, and nobody came up
with any plan to keep Pacemaker in testing.  Actually, I don't think
version 1.10 is really worth much effort.  I'm planning to use the
current versions of Corosync and Pacemaker on jessie, and will try to
create local packages for that.  If there is a way to use that work in
Debian, I'm most interested to hear about it.  But I don't think there's
still a way to have a modern Pacemaker in jessie.  Please prove me wrong.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#614569: [Pkg-openldap-devel] Bug#614569: RFS: Bug#614569: slapd fails to dump/reload partial replica -- NMU sponsor needed

[Ferenc Wagner]

Luca Bruno  writes:

> On Wednesday 03 December 2014 18:21:08 Ryan Tandy wrote:
>
>> On Wed, Dec 03, 2014 at 11:40:24PM +0100, Ferenc Wagner wrote:
>>
>>> I got pre-approval on #771962: the upload will be unblocked, provided
>>> it's in unstable by Monday the 8th of December.  People with upload
>>> rights, if you can spare a minute please review the above change and
>>> consider sponsoring the upload!  Actually, review is welcome from
>>> anybody. :)
>> 
>> Thanks very much for working on this, and the debdiff looks fine (but I
>> haven't actually built or tested it). I hope you can find a sponsor in
>> time. Luca, are you reading?
>
> I was following the discussion, and I have to say that I am not too 
> comfortable in uploading this NMU at this point of the release cycle.
> So NACK on my side.
>
> My main concerns are:
>  * I am not sure that I grok all the implications of that. I suspect that
>most of our (overly) complex pre/postinst scripts makes some assumption on
>schema/db consistency, at least implicitly.

I went through all the maintainer scripts in the package, and did not
find any dependency on DB consistency, apart from the config DB itself,
which we touch on the filesystem (which is unsupported).  And of course
apart from the current issue, which is assuming that slapadd will work
on the result of slapcat.  This is false without the -s option.

>  * We are changing the default behavior to fix a single-case situation, by
>removing a safety check. Mmmh...

As you point out below, debconf does not offer switching off schema
checking.  Just like it does not offer configuring replication.  Thus if
a database is not schema-correct, that must be the result of manual
configuration, not some default behavior.  From this point of view, we
do not change the default behavior, we extend it to other cases.  If the
database was schema-correct, it will stay so.  If the admin uses a
config where it wasn't, then it will stay so as well.

>  * This bug has been open since some time, never marked as RC, put on
>low-priority by the maintainer

I don't understand why.  This bug breaks upgrades, and the only
workaround I know of is manually editing the postinst script.

>  and upstream discouraged dropping the "-s".

(I guess you mean "using").  Yes, but I think their reasoning about
importing invalid databases does not apply in our case, see above and
below.

>  * This is not even the proper solution, just a quick-hack patch.

The "proper" solution would require separate dump/restore decisions for
each database, and we haven't yet got the infrastructure for that.  And
it would only achieve not using the -s flag when it wouldn't have any
effect anyway (maybe apart from slowing down the import).  After all,
we're loading dumps we ourselves made a couple of moments earlier, not
some synthetic data.

> Moreover, I don't consider myself an LDAP expert, but I have some comments on 
> the issue:
>  * I would say that requiring/checking schema integrity across upgrade is a
>good general measure, and we should NOT work around that. Fail early, fail
>loudly.

My point here is that schema-correctness has nothing to do with the
upgrade, as the schema is just a part of the local configuration, which
is not changed by the upgrade.

>  * IIRC disabling schemachecking is heavily discouraged. We don't offer that
>option in debconf. I assume the admin are really aware of the setup, and
>know its quirk.

As far as I know, it's not only discouraged, but is actually impossible
for some time now.  The only way to switch off schema checking is using
replication, making your database a read-only shadow.

>  * Workarounds for the specific corner case exists, but maybe are a bit
>undocumented.

I don't consider editing the postinst script a viable workaround.  Maybe
I miss something here?  Disabling dumping does not cut it, see #770827
and #771823.

> So my alternative suggestion is: let's make it explicit that we value schema 
> integrity, and we rely on it across upgrades

OpenLDAP also values schema-correctness (see above), and that's why
artifically relying on it does not really help, only needlessly breaks
upgrades on partial replicas.

> let's put a point in the release notes to document how to workaround
> this partial replica scenario; let's try to address this better in the
> next point release.

I honestly don't think there's much to gain in that direction.  Unless
there really is a good workaround (not involving hand-editing maintainer
scripts during the upgrade), I find it an unneeded burden on the user.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770827: slapd: can't reconfigure dumping

[Ferenc Wagner]

Ryan Tandy  writes:

>> Trying to upgrade with DEBIAN_PRIORITY=medium does not work either
>> due to another problem: I can switch off dumping then, and dumping is
>> skipped all right, but the reload is attempted regardless and fails
>> not finding the dump.
>
> That's a bug, for sure. dump_databases() exits early if dumping is
> disabled, but the symmetric check in load_databases() is missing. That
> doesn't make a lot of sense. :)

I built a package with this change:

* Do not try to restore the databases if we did not dump them.
  Do not even move the old ones away: our current format change
  logic works with BDB and HDB only, slapd will continue to work
  with the other formats across upgrades.  (Closes: #771823)

--- a/debian/slapd.postinst
+++ b/debian/slapd.postinst
@@ -30,11 +30,11 @@ postinst_upgrade_configuration() {  
# {{{
echo -n "  Backing up $SLAPD_CONF in `database_dumping_destdir`... " >&2
backup_config_once
echo done. >&2
 
# Check if the database format has changed.
-   if database_format_changed; then
+   if database_format_changed && database_dumping_enabled; then
 
# During upgrading we have to load the old data
move_incompatible_databases_away
load_databases
fi

During a wheezy -> jessie upgrade test with slapd/dump_database: never,
it correctly skipped loading of my (MDB) database.  But slapd did not
start:

mdb_db_open: database "...": DN index needs upgrade, run "slapindex entryDN"

http://brylov.info/2013/03/zimbra-8-0-2-8-0-3-update-failure led me to
http://www.openldap.org/lists/openldap-announce/201303/msg0.html,
which explains the issue (DN index format change) and the solution.

So MDB also needs some care during dist-upgrade.  The above simple fix
seems to achieve its aim, but is no substitute for fixing #614569.
However, running slapindex may be much more feasible than a full
dump/restore on a big database, so it still has some value.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#614569: RFS: Bug#614569: slapd fails to dump/reload partial replica -- NMU sponsor needed

[Ferenc Wagner]

Ferenc Wagner  writes:

> I pushed my proposed change at a separate branch:
> http://anonscm.debian.org/cgit/users/wferi-guest/openldap.git/log/?h=bug/614569
> Reproducing it here:
>
> commit 8a769204be90c1eaf7d5070c4e8a2d1eb18a82dc
> Author: Ferenc Wágner 
> Date:   Wed Dec 3 15:51:58 2014 +0100
>
> Disable schema checking for reloading the dumped data during upgrades
> 
> This avoids interrupting the upgrade procedure of partial replicas 
> (#614569).
>
> diff --git a/debian/changelog b/debian/changelog
> index 1fcc7f3..012df5d 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +openldap (2.4.40-3.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Disable schema checking for reloading the dumped data during upgrades,
> +to avoid interrupting the upgrade procedure of partial replicas.
> +(Closes: #614569).
> +
> + -- Ferenc Wágner   Wed, 03 Dec 2014 15:35:44 +0100
> +
>  openldap (2.4.40-3) unstable; urgency=medium
>  
>* Remove trailing spaces from slapd.templates.
> diff --git a/debian/slapd.scripts-common b/debian/slapd.scripts-common
> index f56b3b1..8cf7f7b 100644
> --- a/debian/slapd.scripts-common
> +++ b/debian/slapd.scripts-common
> @@ -220,8 +220,11 @@ load_databases() {   
>   # {{{
> else
> slapadd_opts="-g -F ${SLAPD_CONF}"
> fi
> +   # Disable schema checking for the reload of the dumped data.
> +   # Otherwise, reloading partial replicas fails, breaking the
> +   # upgrade process.
> capture_diagnostics slapadd ${slapadd_opts} \
> -   -q -b "$suffix" -l "$file" || failed=1
> +   -q -b "$suffix" -l "$file" -s || failed=1
> if [ "$failed" ]; then
> rm -f "$dbdir"/*
> echo "failed." >&2
>
> Would anybody please sponsor an NMU with the above change added to
> 2.4.40-3, if I happen to get the change pre-approved by the release
> team?

I got pre-approval on #771962: the upload will be unblocked, provided
it's in unstable by Monday the 8th of December.  People with upload
rights, if you can spare a minute please review the above change and
consider sponsoring the upload!  Actually, review is welcome from
anybody. :)

The package is available at
http://mentors.debian.net/package/openldap

The dsc file can be downloaded from
http://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.40-3.1.dsc

Ryan, please note that my upload somehow ended up under your name on
mentors.debian.net.  Thus I can't flip the "Needs a sponsor" flag.

Also, QA information says "Bug #614569 does not belong to this package",
and I only wonder why...
-- 
Thanks,
Feri.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#614569: slapd fails to dump/reload partial replica

[Ferenc Wagner]

Ryan Tandy  writes:

> On Tue, Dec 02, 2014 at 07:45:26PM +0100, Ferenc Wagner wrote:
>
>> I'm inclined to simply add that -s option.  If the database was schema-
>> correct, it will stay so, and it it wasn't, then upgrade isn't the best
>> time to point that out.  There isn't much to test on such a change.
>
> I don't like interrupting upgrades either, but if we don't check
> correctness during reloads, I don't know what other opportunity we
> have. I suppose you could argue it's the admin's concern and not ours.

Yes, that's my point.  The upgrade does not change schema validity, and
should not crash in either case.

>> Also, do you think some pre-agreement from the release team would be
>> needed before the upload?
>
> Yes, you'd definitely want a pre-approval (via an unblock request:
> reportbug release.debian.org, attach a source debdiff) before
> uploading (but after securing a sponsor).

I pushed my proposed change at a separate branch:
http://anonscm.debian.org/cgit/users/wferi-guest/openldap.git/log/?h=bug/614569
Reproducing it here:

commit 8a769204be90c1eaf7d5070c4e8a2d1eb18a82dc
Author: Ferenc Wágner 
Date:   Wed Dec 3 15:51:58 2014 +0100

Disable schema checking for reloading the dumped data during upgrades

This avoids interrupting the upgrade procedure of partial replicas 
(#614569).

diff --git a/debian/changelog b/debian/changelog
index 1fcc7f3..012df5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+openldap (2.4.40-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable schema checking for reloading the dumped data during upgrades,
+to avoid interrupting the upgrade procedure of partial replicas.
+(Closes: #614569).
+
+ -- Ferenc Wágner   Wed, 03 Dec 2014 15:35:44 +0100
+
 openldap (2.4.40-3) unstable; urgency=medium
 
   * Remove trailing spaces from slapd.templates.
diff --git a/debian/slapd.scripts-common b/debian/slapd.scripts-common
index f56b3b1..8cf7f7b 100644
--- a/debian/slapd.scripts-common
+++ b/debian/slapd.scripts-common
@@ -220,8 +220,11 @@ load_databases() { 
# {{{
else
slapadd_opts="-g -F ${SLAPD_CONF}"
fi
+   # Disable schema checking for the reload of the dumped data.
+   # Otherwise, reloading partial replicas fails, breaking the
+   # upgrade process.
capture_diagnostics slapadd ${slapadd_opts} \
-   -q -b "$suffix" -l "$file" || failed=1
+   -q -b "$suffix" -l "$file" -s || failed=1
if [ "$failed" ]; then
rm -f "$dbdir"/*
echo "failed." >&2

It behaved as expected in my tests.  Now I'm doing a full clean sbuild
with tests (which take LONG), but let me first try to get some review
here:

Would anybody please sponsor an NMU with the above change added to
2.4.40-3, if I happen to get the change pre-approved by the release
team?
-- 
Thanks,
Feri.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#614569: Bug#770827: slapd: can't reconfigure dumping

[Ferenc Wagner]

Ryan Tandy  writes:

> On Tue, Dec 02, 2014 at 11:27:47AM +0100, Ferenc Wagner wrote:
>
>> Now, do you plan to do anything about these for jessie?  As I understand
>> it, anybody running a partial replica will necessarily hit this during
>> the wheezy -> jessie upgrade.  But we've still got a couple of days to
>> get an unblock for these fixes...
>
> Just to be clear, we're talking about (at least) three separate bugs:
>
> #614569 - fails to reload a partial replica
> #770827 - dpkg-reconfigure doesn't ask the dumping question
> #771823 - attempts database reload even with dumping set to 'never'

Precisely.  Thanks for setting this up!

> #770827 I think is clearly not RC.

Well, you can work around it by debconf-set-selections I guess...  If
#771823 didn't spoil it, this could be the recommended workaround for
upgrades of partial MDB replicas.

> #614569 would have been good to fix for jessie, but I personally have
> basically no time available at the moment. I can't provide a
> well-tested fix before the 5th, sorry.

I'm inclined to simply add that -s option.  If the database was schema-
correct, it will stay so, and it it wasn't, then upgrade isn't the best
time to point that out.  There isn't much to test on such a change.  To
do any better, you'd need separate dumping decisions on each configured
database, which would be nice (ATM only BDB and HDB need this, after
all) but that may be too much for a last-minute change.  I'm willing to
work on this if we can agree on the direction.  I'll have to upgrade my
servers somehow, doing it offically can't hurt...

> Other facts about #614569 are that it has been around for two upgrade
> cycles already, and that it can be worked around by editing the
> postinst to add -s to the slapadd invocation and running 'dpkg
> --configure -a' to retry the upgrade.

That's what I did.  Not exactly the expected Debian upgrade
experience. :(

> Unless someone else wants to prepare and upload a fix in the next
> couple of days, I'll fix it in unstable later and then propose it for
> a point release of jessie. I'm also monitoring some lmdb issues being
> worked on upstream, in case some of the patches turn out to be
> suitable for a point release.

That's good to hear.

> I doubt this was the answer you hoped for; sorry for that.

Sure it was, really!  Unfortunately, I can't upload, so a sponsor would
be needed to conclude this.  Also, do you think some pre-agreement from
the release team would be needed before the upload?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770827: slapd: can't reconfigure dumping

[Ferenc Wagner]

Ryan Tandy  writes:

> IMO, the dumping questions could be asked outside of that guard, even
> on initial installation (and certainly on reconfiguration), with a low
> priority.

Agreed.

> That's a bug, for sure. dump_databases() exits early if dumping is
> disabled, but the symmetric check in load_databases() is missing. That
> doesn't make a lot of sense. :)

Also agreed.

Now, do you plan to do anything about these for jessie?  As I understand
it, anybody running a partial replica will necessarily hit this during
the wheezy -> jessie upgrade.  But we've still got a couple of days to
get an unblock for these fixes...
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768203: sblim-wbemcli: fails to upgrade from 'wheezy' - trying to overwrite /usr/bin/wbemcli

[Ferenc Wagner]

Thanks much.  Unblock request filed as #768610.
-- 
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768203: sblim-wbemcli: fails to upgrade from 'wheezy' - trying to overwrite /usr/bin/wbemcli

[Ferenc Wagner]

Andreas Beckmann  and Bernd Zeimetz  writes:

> Breaks: python-pywbem (<< 0.8.0~dev650-1~)
> Replaces: python-pywbem (<< 0.8.0~dev650-1~)

OK.  Footnote 53 brought up an example with a file being moved between
related packages, which made me read more into Breaks+Replaces than
there is.  Thanks for patiently explaining the obvious.  I added these
lines and uploaded to mentors:

https://mentors.debian.net/package/sblim-wbemcli

(Too bad I missed the new upstream release just before the freeze.)
Would one of you please sponsor it into unstable?  I'll ask for a freeze
exception once it landed.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768203: sblim-wbemcli: fails to upgrade from 'wheezy' - trying to overwrite /usr/bin/wbemcli

[Ferenc Wagner]

Andreas Beckmann  writes:

> Since no upgrade ordering is not guaranteed by the package manager, I'm
> looking for all possibly problematic (partial) upgrade paths from wheezy
> to jessie,

I'm afraid I don't understand.  You're talking about upgrades, but you
couldn't possibly have python-pywbem and sblim-wbemcli installed
together, unless python-pywbem was at 0.8.0~dev650-1, its latest
version.  And then there's no problem with any version of sblim-wbemcli.
No version of sblim-wbemcli is included in wheezy, though.

> that includes files being moved from one package to another (that may
> not have existed in wheezy.) And I try to really excercise all paths
> not forbidden by Breaks/Conflicts :-)

Maybe you install python-pywbem in wheezy, then switch sources to jessie
and install sblim-wbemcli without dist-upgrading first?  That's the only
scenario I can think of which exhibits this problem.

> On 2014-11-06 11:00, Ferenc Wagner wrote:
>
>> Of course the above problem could be declared in the metadata of
>> sblim-wbemcli, though 7.6 does not seem to apply here.  7.4 (Conflicts)
>> seems more appropriate to me, if something really is needed.  I
>> initially thought it was not, but you surely know better, please advise
>> me.
>
> If a package was in wheezy and is completely gone in jessie, unversioned
> Replaces+Conflicts in the successor are OK.

No, this is not the case, both packages are in jessie, but python-pywbem
has its former /usr/bin/wbemcli binary renamed to avoid conflict with
sblim-wbemcli.  Replaces does not play either, the packages have
different (tough in part similar) purposes, as well as the clashing
binaries.

> If the package still exists (even as an empty transitional package),
> use versioned Breaks+Replaces (<<
> the-first-version-no-longer-shipping-the-files~) The trailing ~ is
> recommended for backports-compatibility.  Breaks are much easier to
> handle for the package manager than Conflicts.

But Breaks does not forbid unpacking both packages together, which is
really impossible, as both contain the same file.  All this suggests

Conflicts: python-pywbem (<< 0.8.0~dev650-1~)

should be added to sblim-wbemcli to avoid this error on any setup.
Do you agree?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768203: sblim-wbemcli: fails to upgrade from 'wheezy' - trying to overwrite /usr/bin/wbemcli

[Ferenc Wagner]

Andreas Beckmann  writes:

> during a test with piuparts I noticed your package fails to upgrade from
> 'wheezy'.

Hi,

Something is strange here, as sblim-wbemcli was never part of wheezy,
thus it is not supposed to be upgraded from there.

> It installed fine in 'wheezy', then the upgrade to 'jessie' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.

The sblim-wbemcli package indeed had a file conflict with python-pywbem
0.7.0-4 (see #679607).  However, the conflicting file was renamed in the
jessie version of python-pywbem.

>>From the attached log (scroll to the bottom...):
>
>   Selecting previously unselected package sblim-wbemcli.

This sounds more like a new install of sblim-wbemcli, not an upgrade.

>   Unpacking sblim-wbemcli (from .../sblim-wbemcli_1.6.2-8_amd64.deb) ...
>   dpkg: error processing 
> /var/cache/apt/archives/sblim-wbemcli_1.6.2-8_amd64.deb (--unpack):
>trying to overwrite '/usr/bin/wbemcli', which is also in package 
> python-pywbem 0.7.0-4
>   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
>   Errors were encountered while processing:
>/var/cache/apt/archives/sblim-wbemcli_1.6.2-8_amd64.deb

Which is expected to fail with python-pywbem 0.7.0-4 present.  However,
I wonder how you managed to get into this situation.  A wheezy -> jessie
upgrade should have upgraded python-pywbem to 0.8.0~dev650-1, and you
shouldn't experience problems trying to install sblim-wbemcli next to
that version.

> See policy 7.6 at
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

Of course the above problem could be declared in the metadata of
sblim-wbemcli, though 7.6 does not seem to apply here.  7.4 (Conflicts)
seems more appropriate to me, if something really is needed.  I
initially thought it was not, but you surely know better, please advise
me.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765747: RFS: openldap/2.4.40-1 [RC]

[Ferenc Wagner]

Ryan Tandy  writes:

> On 18/10/14 02:26 AM, Ferenc Wagner wrote:
>
>> Ryan Tandy  writes:
>> 
>>>* debian/slapd.init.ldif:
>> 
>> Btw: why do you give rigths to the RootDN explicitly?  Doesn't it skip
>> all ACL processing anyway?
>
> Good point, again; I hadn't noticed that. In debian/slapd.conf the
> rootdn line is commented and we just have the explicit ACLs. I think I
> would do the same with slapd.init.ldif, and drop olcRoot{DN,PW}.

I'd go the other way, as a RootDN is good to have anyway (replication
needs it), while the explicit rules clutter up the ACLs.  Or do you want
to differentiate between the write and manage access levels this way?

>> Maybe the Logging section could mention rsyslog [...]
>
> Would you be willing to provide a patch against the README for that?

Probably yes, but not tonight. :)

>> I backported your package to wheezy and upgraded a machine carrying a
>> partial replica.  The upgrade failed, so I added the -s option to the
>> slapadd call in the postinst.  Please consider using it.
>
> See #614569. I would like to fix it for jessie, but it might be in a
> later upload. I only want to add -s in cases where it's strictly needed,
> not in general.

That would certainly be more correct; I'm just not sure if it's worth
the trouble.  Bringing up problems during upgrade isn't too useful.

>> Btw. is the dump/restore necessary with MDB?
>
> It's not (details in #750022). I filed #759597 about that.

Cool.  I added a note about the example DB_CONFIG being unnecessary
copied in.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#759597: MDB does not need DB_CONFIG

[Ferenc Wagner]

Beyond the unnecessary (and failing:) dump/reload, I also got a gratis
DB_CONFIG file during upgrade from wheezy to 2.4.40-1.  So not only the
conditions differ, but also the methods, since MDB does not need this.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765747: RFS: openldap/2.4.40-1 [RC]

[Ferenc Wagner]

I backported your package to wheezy and upgraded a machine carrying a
partial replica.  The upgrade failed, so I added the -s option to the
slapadd call in the postinst.  Please consider using it.

Btw. is the dump/restore necessary with MDB?  I found no information
about the format incompatibilities between the various versions.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765747: RFS: openldap/2.4.40-1 [RC]

[Ferenc Wagner]

Ryan Tandy  writes:

>  - Invoke find, chmod, and chown with -H in case /var/lib/ldap is a
>symlink. (Closes: #742862)

You mean chgrp, not chmod.

>* debian/slapd.README.Debian: Add a note about database format
>  upgrades and the consequences of missing one. (Closes: #594711)

"HDB is the recommended database backend."  Is this still so?  Not MDB?

Maybe the Logging section could mention rsyslog, which is the current
default system log daemon.  I personally use /etc/rsyslog.d/50-slapd.conf:

  # Globally turn off rate limiting on the unix socket (mostly slapd logs)
  $SystemLogRateLimitInterval 0

  local4.* -/var/log/slapd.log
  & ~

with a corresponding logrotate snippet, although it could be done
another way as well (http://wiki.rsyslog.com/index.php/DailyLogRotation).

>* debian/slapd.init.ldif:

Btw: why do you give rigths to the RootDN explicitly?  Doesn't it skip
all ACL processing anyway?

I much hope to see OpenLDAP 2.4.40 in jessie!
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765648: RFS: fbxkb/0.6-1.2 [NMU]

[Ferenc Wagner]

"Dmitry Borisyuk"  writes:

> The package fbxkb has long-standing bugs (#412254, #436824 and others),
> and seems unmaintained (the maintainer does not respond for years).
> As I happen to install this package, I patched it for my local use,
> and now upload it to mentors; it would be nice if someone helped
> installing the corrected version to Debian archive.
> [...]
>   * Fix parsing of keyboard info, to show proper "us" flag. (Closes: #412254)

Yeah, the fix is not bulletproof, but certainly better than the
original.  I can't comment on the other changes, nor sponsor the
package, but I vote for it.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#763136: [Pkg-freeipmi-devel] Bug#763136: Bug#763136: [freeipmi-bmc-watchdog] Duplicate logrotate.d entries

[Ferenc Wagner]

Yaroslav Halchenko  writes:

> but shouldn't we keep bmc-watchdog.log not freeipmi-bmc-watchdog.log to
> somewhat match default/init.d file naming?

I supposed this recent rename has been agreed upon.  Anyway, what about
the bug/763136b branch then?
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#763136: [Pkg-freeipmi-devel] Bug#763136: [freeipmi-bmc-watchdog] Duplicate logrotate.d entries

[Ferenc Wagner]

tags 763136 patch
thanks

I pushed a new branch bug/763136 to Alioth, please review, merge (fast
forward), delete and upload as convenient.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#763758: RFS: sblim-wbemcli/1.6.2-8

[Ferenc Wagner]

Hi Russ,

In the past you sponsored the initial upload of my sblim-wbemcli package
into Debian.  I prepared a new revision of it with very few changes,
could you please sponsor it again?

https://mentors.debian.net/package/sblim-wbemcli
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#763758: RFS: sblim-wbemcli/1.6.2-8

[Ferenc Wagner]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sblim-wbemcli"

 * Package name: sblim-wbemcli
   Version : 1.6.2-8
   Upstream Author : Tyrel Datwyler 
 * URL : 
http://sourceforge.net/apps/mediawiki/sblim/index.php?title=Wbemcli
 * License : Eclipse Public License -v 1.0
   Section : admin

  It builds those binary packages:

sblim-wbemcli - WBEM Command Line Interface for CIMOM access
sblim-wbemcli-dbg - debugging symbols for sblim-wbemcli

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/sblim-wbemcli


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/s/sblim-wbemcli/sblim-wbemcli_1.6.2-8.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

   * Report failure in the exit code.
   * Use dh-autoreconf. (Closes: #727960, #744506)
   * Bump to Standards-Version 3.9.6 (no changes).

  Regards,
   Ferenc Wágner


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#763136: [freeipmi-bmc-watchdog] Duplicate logrotate.d entries

[Ferenc Wagner]

This seems to be caused by the rename of the logrotate config file
stemming from commit 4d4f988a (Move logrotate.d snippet to its own file;
dropped upstream).  I think it could be fixed in 1.4.4-2~ by adding

dpkg-maintscript-helper mv_conffile \
  /etc/logrotate.d/bmc-watchdog /etc/logrotate.d/freeipmi-bmc-watchdog \
  1.4.4-2~ freeipmi-bmc-watchdog -- "$@"

to debian/freeipmi-bmc-watchdog.{preinst,postinst,postrm}.  Funny thing:
its inverse is already present since commit d6622127 (freeipmi- prefix
stripped upstream from bmc-watchdog daemon/scripts).  Maybe we should
just use dh_installlogrotate --name, as the already overridden
dh_installinit invocations do...  Opinions?
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679607: python-pywbem and sblim-wbemcli: error when trying to install together

[Ferenc Wagner]

Ferenc Wagner  writes:

> Ferenc Wagner  writes:
>
>> Ferenc Wagner  writes:
>>
>>> Bernd Zeimetz  writes:
>>>
>>>>> I'm preparing a new upload of sblim-wbemcli.  Shall I rename the
>>>>> contained wbemcli binary, or do you still plan letting me use that
>>>>> name?
>>>>
>>>> given the low popcon and pywebem not being devleoped by upstream
>>>> anymore, I think it would be okay for you to take the name, if we find
>>>> a proper way to let people know about it. I guess pywbem could ship
>>>> wbemcli.py instead, then it would be obvious.
>>>
>>> I agree.
>>>
>>>> What would you think about a debconf notice which is displayed only to
>>>> those who have python-wbem installed? or something like that?
>>>> Do you have better ideas?
>>>
>>> I could most certainly add a notice like that.  However, this is
>>> actually a change in pywbem, thus I feel like it should be documented
>>> there.  I also think a NEWS entry would be more than enough, as the
>>> current wbemcli binary in pywbem looks more like an example than a
>>> readily usable utility, so I don't expect a wide affected user base.
>>
>> If the above plan does not work for you, please let me know.  I'm still
>> holding back a new upload with some bugfixes.
>
> Could you please provide some feedback on this issue, so that we can
> make progress with this bug?  You seemed to kindly agree to rename the
> binary in python-pywbem.  If you still do, please reassing this bug to
> python-pywbem.  If not, please state it, and I'll take care of it in
> sblim-wbemcli.

Hi Bernd,

Please, pretty please express your current opinion on this bug.  Freeze
is approaching quickly, it would be a shame to miss it again.  Will you
rename the wbemcli binary in python-pywbem?  If yes, or if you don't
want to ship python-pywbem in jessie, please reassign this bug to it.
Otherwise please drop me a note and I'll reassign this bug to
sblim-wbemcli and fix it there.
-- 
Looking forward to hearing from you soon,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#617235: statoverride under /var/run?

[Ferenc Wagner]

Hi,

On my wheezy system:

$ dpkg-statoverride --list /var/run/hplip
hplip root 755 /var/run/hplip
$ getent passwd hplip
hplip:x:113:7:HPLIP system user,,,:/var/run/hplip:/bin/false

so the user is present, thus this override does not cause any problem.
The hplip package is installed, however,

$ ls -ld /var/run/hplip
ls: cannot access /var/run/hplip: No such file or directory

Also, it's a standard setup, so /var/run is a symlink to /run, which is
a tmpfs.  In this setting, this override does not seem to be useful
anymore.  It's managed in hplip.post{inst,rm}, but that stuff should
probably be removed, especially since /etc/init.d/hplip does not exist
anymore.  So after some cleanup this report could be closed, I think.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712134: my setup

[Ferenc Wagner]

Hi,

Yesterday I upgraded from squeeze to wheezy a moderate Munin setup (117
hosts).  After much struggling and installing version 2.0.21-2~bpo70+3,
I managed to reach acceptable response (in the realm of seconds) via
Apache2 mod-fcgid.  There might be some log/cache file permission
changes left from the squeeze setup (which I hacked seriously to keep
going in CGI mode), but basically my modifications are:

/etc/munin/munin.conf: localhost removed

/etc/munin/munin-conf.d/settings.conf:
graph_strategy cgi
html_strategy cgi

/etc/munin/munin-conf.d/hosts.conf: lots of node definitions

/etc/apache2/sites-enabled/000-default:
[...]
Alias /munin/static/ /etc/munin/static/
Alias /munin-cgi/munin-cgi-graph/ /usr/lib/munin/cgi/munin-cgi-graph/
Alias /munin/ /usr/lib/munin/cgi/munin-cgi-html/

Options ExecCGI
SetHandler fcgid-script

[...]

I think something like this would be useful to include in the
documentation, the linked stuff was both overly complex and lacking.
Also, I'm not really sure what made the difference in the end (my first
tries resulted in the OOM-killer trimming some Apache children), but
this may still be a useful data point.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679607: python-pywbem and sblim-wbemcli: error when trying to install together

[Ferenc Wagner]

Ferenc Wagner  writes:

> Ferenc Wagner  writes:
>
>> Bernd Zeimetz  writes:
>>
>>>> I'm preparing a new upload of sblim-wbemcli.  Shall I rename the
>>>> contained wbemcli binary, or do you still plan letting me use that
>>>> name?
>>>
>>> given the low popcon and pywebem not being devleoped by upstream
>>> anymore, I think it would be okay for you to take the name, if we find
>>> a proper way to let people know about it. I guess pywbem could ship
>>> wbemcli.py instead, then it would be obvious.
>>
>> I agree.
>>
>>> What would you think about a debconf notice which is displayed only to
>>> those who have python-wbem installed? or something like that?
>>> Do you have better ideas?
>>
>> I could most certainly add a notice like that.  However, this is
>> actually a change in pywbem, thus I feel like it should be documented
>> there.  I also think a NEWS entry would be more than enough, as the
>> current wbemcli binary in pywbem looks more like an example than a
>> readily usable utility, so I don't expect a wide affected user base.
>
> If the above plan does not work for you, please let me know.  I'm still
> holding back a new upload with some bugfixes.

Hi Bernd,

Could you please provide some feedback on this issue, so that we can
make progress with this bug?  You seemed to kindly agree to rename the
binary in python-pywbem.  If you still do, please reassing this bug to
python-pywbem.  If not, please state it, and I'll take care of it in
sblim-wbemcli.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735162: xml-security-c: FTBFS on hurd-i386

[Ferenc Wagner]

Svante Signell  writes:

> The attached patch fixes this problem by adding a check in
> configure.ac for a working path = getcwd(NULL, 0) allocating the
> string length required dynamically, and freed later on.  Similarly the
> string baseURI is malloced and freed.

I can see the freeing of baseURI, but not that of path.
I'd say it's leaked.  Or do I miss something here?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#726420: multipath-tools: Fails to upgrade in root-on-multipath setups

[Ferenc Wagner]

Salvatore Bonaccorso  writes:

> On Tue, Oct 15, 2013 at 05:34:09PM +0200, Ferenc Wágner wrote:
>
>> The Debian 7.1 -> 7.2 upgrade includes a multipath-tools upgrade,
>> which fails on a multipath-rooted system:
>> 
>> Preparing to replace multipath-tools 0.4.9+git0.4dfdaf2b-6 (using 
>> .../multipath-tools_0.4.9+git0.4dfdaf2b-7~deb7u1_amd64.deb) ...
>> [] Root is on a multipathed device, multipathd can not be 
>> stopped:invoke-rc.d: initscript multipath-tools, action "stop" failed.
>> dpkg: warning: subprocess old pre-removal script returned error exit status 1
>> dpkg: trying script from the new package instead ...
>> [] Root is on a multipathed device, multipathd can not be 
>> stopped:invoke-rc.d: initscript multipath-tools, action "stop" failed.
>> dpkg: error processing 
>> /var/cache/apt/archives/multipath-tools_0.4.9+git0.4dfdaf2b-7~deb7u1_amd64.deb
>>  (--unpack):
>>  subprocess new pre-removal script returned error exit status 1
>> 
>> Ignoring the stop failure in the prerm script fixes the problem.
>
> Only a follow-up on this bugreport: This looks similar to #704073.

Absolutely.  I did not read through that report before reporting this,
because its title described another bug.  Sorry.

So, the current version behaves sanely, because the init script won't
error out anymore, but the upgrades are still broken, because that could
only be fixed by ignoring the error of the old init script in the new
prerm script.

By the way, that teardown_slaves() function in the init script still has
its problems.  Apart from its name being rather misleading, the
recursive call changes the current directory under the for loop, so it
emits error messages if a devices has multiple slaves:

Preparing to replace multipath-tools 0.4.9+git0.4dfdaf2b-7~deb7u1 (using 
.../multipath-tools_0.4.9+git0.4dfdaf2b-7~deb7u2_amd64.deb) ...
[] Root is on a multipathed device, multipathd can not be 
stopped:/etc/init.d/multipath-tools: 30: cd: can't cd to 
/sys/devices/platform/host7/session1/target7:0:0/7:0:0:2/block/sdc/slaves/sdj
/etc/init.d/multipath-tools: 35: /etc/init.d/multipath-tools: cannot open 
/sys/devices/platform/host7/session1/target7:0:0/7:0:0:2/block/sdc/slaves/sdj/dev:
 No such file
[] Root is on a multipathed device, multipathd can not be 
stopped:/etc/init.d/multipath-tools: 30: cd: can't cd to 
/sys/devices/platform/host7/session1/target7:0:0/7:0:0:2/block/sdc/slaves/sdq
/etc/init.d/multipath-tools: 35: /etc/init.d/multipath-tools: cannot open 
/sys/devices/platform/host7/session1/target7:0:0/7:0:0:2/block/sdc/slaves/sdq/dev:
 No such file
[] Root is on a multipathed device, multipathd can not be 
stopped:/etc/init.d/multipath-tools: 30: cd: can't cd to 
/sys/devices/platform/host7/session1/target7:0:0/7:0:0:2/block/sdc/slaves/sdx
/etc/init.d/multipath-tools: 35: /etc/init.d/multipath-tools: cannot open 
/sys/devices/platform/host7/session1/target7:0:0/7:0:0:2/block/sdc/slaves/sdx/dev:
 No such file
[] Root is on a multipathed device, multipathd can not be stopped:Unpacking 
replacement multipath-tools ...

Here's how I would do it instead.  Also much shorter:

is_mpath () {
read name 2>/dev/null <"$1"/dm/name && [ "$(dmsetup table --target 
multipath "$name")" ] && return 0
for slave in "$1"/slaves/*; do
[ -L "$slave" ] && is_mpath "$slave" && return 0
done
return 1
}

rdev=$(stat --format %d /)
is_mpath /sys/dev/block/$((rdev/256)):$((rdev%256)) && echo "multipath root"

> @Ferenc, anyway please wait to update multipath-tools, there were
> detected a regression #726296 and #726311 which should be available
> via wheezy-updates tonight.

Thanks for the notice, much appreciated.
-- 
Feri.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679607: python-pywbem and sblim-wbemcli: error when trying to install together

[Ferenc Wagner]

Ferenc Wagner  writes:

> Bernd Zeimetz  writes:
>
>>> I'm preparing a new upload of sblim-wbemcli.  Shall I rename the
>>> contained wbemcli binary, or do you still plan letting me use that
>>> name?
>>
>> given the low popcon and pywebem not being devleoped by upstream
>> anymore, I think it would be okay for you to take the name, if we find
>> a proper way to let people know about it. I guess pywbem could ship
>> wbemcli.py instead, then it would be obvious.
>
> I agree.
>
>> What would you think about a debconf notice which is displayed only to
>> those who have python-wbem installed? or something like that?
>> Do you have better ideas?
>
> I could most certainly add a notice like that.  However, this is
> actually a change in pywbem, thus I feel like it should be documented
> there.  I also think a NEWS entry would be more than enough, as the
> current wbemcli binary in pywbem looks more like an example than a
> readily usable utility, so I don't expect a wide affected user base.

Hi Bernd,

If the above plan does not work for you, please let me know.  I'm still
holding back a new upload with some bugfixes.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#610630: Why not get over with this?

[Ferenc Wagner]

Hi,

This unfortunate code in the postinst script led to serveral (like
#482041, #589040, #606784 and #610630) bugs.  Now that there have been
stable releases with the upgrade code adding the snmp group, the
existing user and group could be let alone, simply by letting adduser
fail gracefully, without any conditional logic.  What do you think?
(I'm currently suffering this doing the latest squeeze point upgrade.)
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#589040: Isn't this something like #622230?

[Ferenc Wagner]

Exit status 20 sounds like debconf confused by unintended input.
Running the postinst script with set -x as in #622230 would reveal this.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#622230: unscd: breaks snmpd upgrades

[Ferenc Wagner]

severity 622230 critical
thanks

Jérôme Warnier  writes:

> Actually, it breaks stuff.
> Example: installing snmpd fails with the following message:
> [...]
> As you can see, there is a problem with debconf.
>
> Probably a good reason to raise the severity of this bug.

Absolutely.  What "makes unrelated software on the system break", is by
definition critical.  This bug actively breaks squeeze upgrades to the
latest point release.  Please fix it.
-- 
Thanks,
Feri.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679607: python-pywbem and sblim-wbemcli: error when trying to install together

[Ferenc Wagner]

Bernd Zeimetz  writes:

>> I'm preparing a new upload of sblim-wbemcli.  Shall I rename the
>> contained wbemcli binary, or do you still plan letting me use that
>> name?
>
> given the low popcon and pywebem not being devleoped by upstream
> anymore, I think it would be okay for you to take the name, if we find
> a proper way to let people know about it. I guess pywbem could ship
> wbemcli.py instead, then it would be obvious.

I agree.

> What would you think about a debconf notice which is displayed only to
> those who have python-wbem installed? or something like that?
> Do you have better ideas?

I could most certainly add a notice like that.  However, this is
actually a change in pywbem, thus I feel like it should be documented
there.  I also think a NEWS entry would be more than enough, as the
current wbemcli binary in pywbem looks more like an example than a
readily usable utility, so I don't expect a wide affected user base.
-- 
Cheers,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679607: python-pywbem and sblim-wbemcli: error when trying to install together

[Ferenc Wagner]

Hi Bernd,

I'm preparing a new upload of sblim-wbemcli.  Shall I rename the
contained wbemcli binary, or do you still plan letting me use that name?
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#710517: libvirt-bin: Segfault when virsh destroy is called while virsh console is connected

[Ferenc Wagner]

found 710517 0.9.12-11
fixed 710517 0.10.0
tags 710517 + patch
thanks

"Carpenter, Christopher"  writes:

> This bug seems to happen every time I try to virsh destroy (or use
> appropriate libvirt API call) while already having an open console via
> virsh console.

I also hit this issue.  It's not 100% reproducible for me, but almost.
In a production cluster hosting virtual machines it leads to cluster
fencing, ie. hard reboot of the affected host machine, as its VMs become
unmanageable when libvirtd dies.  So I consider this a serious bug, but
also an easy to fix one: upstream already fixed it as noted in the
upstream tracker (altough an unrelated commit is mentioned there by
mistake; I included the fixed line based on that info, not on testing).

I wonder why the original report indicated version 0.9.12-11.1, did that
version officially exist?  On the other hand, it's actually the version
given to my locally modified package (with the attached patch added to
fix this bug).  Anybody interested can get it from:
deb(-src) http://apt.niif.hu/debian wheezy main

As this bug affects wheezy, I hereby plea for including the fix in a
stable update.
-- 
Thanks,
Feri.

Description: Fix libvirtd crash when destroying a domain with attached console
Author: Peter Krempa 
Origin: upstream
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=969497
Applied-Upstream: ba226d334acbc49f6751b430e0c4e00f69eef6bf and 45edefc7a7bcbec988f54331ff37fc32e4bc2718
Last-Update: 2013-06-07
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/

This is two upstream commits squashed:

commit ba226d334acbc49f6751b430e0c4e00f69eef6bf
Author: Peter Krempa 
Date:   Fri Jul 27 14:50:54 2012 +0200

conf: Remove callback from stream when freeing entries in console hash

When a domain has a active console connection and is destroyed the
callback is called on private data that no longer exist causing a
segfault.

commit 45edefc7a7bcbec988f54331ff37fc32e4bc2718
Author: Peter Krempa 
Date:   Fri Aug 3 11:20:29 2012 +0200

conf: Remove console stream callback only when freeing console helper

Commit ba226d334acbc49f6751b430e0c4e00f69eef6bf tried to fix crash of
the daemon when a domain with an open console was destroyed. The fix was
wrong as it tried to remove the callback also when the stream was
aborted, where at that point the fd stream driver was already freed and
removed.

This patch clears the callbacks with a helper right before the hash is
freed, so that it doesn't interfere with other codepaths where the
stream object is freed.
Index: libvirt-0.9.12/src/conf/virconsole.c
===
--- libvirt-0.9.12.orig/src/conf/virconsole.c	2012-02-28 07:39:38.0 +0100
+++ libvirt-0.9.12/src/conf/virconsole.c	2013-06-07 10:50:09.564085862 +0200
@@ -290,6 +290,18 @@
 }
 
 /**
+ * Helper to clear stream callbacks when freeing the hash
+ */
+static void virConsoleFreeClearCallbacks(void *payload,
+ const void *name ATTRIBUTE_UNUSED,
+ void *data ATTRIBUTE_UNUSED)
+{
+virStreamPtr st = payload;
+
+virFDStreamSetInternalCloseCb(st, NULL, NULL, NULL);
+}
+
+/**
  * Free structures for handling open console streams.
  *
  * @cons Pointer to the private structure.
@@ -300,6 +312,7 @@
 return;
 
 virMutexLock(&cons->lock);
+virHashForEach(cons->hash, virConsoleFreeClearCallbacks, NULL);
 virHashFree(cons->hash);
 virMutexUnlock(&cons->lock);
 virMutexDestroy(&cons->lock);

Bug#696910: initscripts: cannot shut down when / on network - iscsi

[Ferenc Wagner]

Hi,

I was also bitten by this issue; Dear Maintainer, please consider fixing
it!  I applied to following patches to the reboot and halt scripts,
based on similar checks in the networking and open-iscsi init scripts:

--- /etc/init.d/reboot.orig 2012-11-20 12:03:28.737794685 +0100
+++ /etc/init.d/reboot  2012-11-20 12:07:20.209804174 +0100
@@ -17,7 +17,11 @@
# Message should end with a newline since kFreeBSD may
# print more stuff (see #323749)
log_action_msg "Will now restart"
-   reboot -d -f -i
+   netdown="-i"
+   if [ -e /etc/iscsi/iscsi.initramfs ]; then
+   netdown=""
+   fi
+   reboot -d -f $netdown
 }
 
 case "$1" in
--- /etc/init.d/halt.orig   2012-11-20 12:03:25.237794541 +0100
+++ /etc/init.d/halt2012-11-20 12:05:23.209799378 +0100
@@ -53,9 +53,9 @@
fi
 
# Make it possible to not shut down network interfaces,
-   # needed to use wake-on-lan
+   # needed to use wake-on-lan or to synchronize the iSCSI cache
netdown="-i"
-   if [ "$NETDOWN" = "no" ]; then
+   if [ "$NETDOWN" = "no" ] || [ -e /etc/iscsi/iscsi.initramfs ]; then
netdown=""
fi
 
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697676: lvm2: cLVM binary package is missing

[Ferenc Wagner]

Julien Cristau  writes:

> Somebody would have to properly maintain its dependencies in debian
> (redhat-cluster, and by extension gfs2-utils, corosync, ...).  They're
> the reason the clvm package had to go.

Hi Julien,

We're running clvm over Corosync in wheezy (were using redhat-cluster
earlier).  Installation wasn't exactly straightforward because of
#614238, but manageable anyway.  I can accept there are problems with
the corosync package in wheezy, but which one is serious enough to
warrant removing clvm support from wheezy altogether?  And what could be
done to fix this?  I'm willing to help out if at all possible.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697676: lvm2: cLVM binary package is missing

[Ferenc Wagner]

Hi Bastian,

Please comment on this bug, because we're hitting a dead end here,
especially now that 2.02.95-6 has migrated into wheezy but upgrading
requires removing clvm, which we use.  Can you see any alternatives
people using clvm could switch to?  Or can we somehow help you to keep
clvm in wheezy after all?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697676: lvm2: cLVM binary package is missing

[Ferenc Wagner]

I'm much surprised that a disruptive change like dropping cluster
support from the lvm2 package was put forward this late in the wheezy
freeze cycle.  What's the real reason for it?  Some people use it to
their satisfaction and don't have a quick replacement on hand, and those
who don't like it aren't affected by the compiled-in support, or are
they?

Please consider keeping clvm around until a viable alternative emerges.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697357: bridging broken over bond interfaces

[Ferenc Wagner]

Bastian Blank  writes:

> On Fri, Jan 04, 2013 at 12:17:12PM +0100, Peter Palfrader wrote:
>> I tried to set up a new KVM host in the usual way:
>>   - have a bond0 interface over all physcial eth* interfaces
>>   - create a br0 over that bond0 and any vnet* interfaces for the
>> guests.
>
> You want to use Open vSwitch for such setups.

Hi Bastian,

Somewhat offtopic, but I left in the Cc-s to get it documented: why
should we prefer Open vSwitch over standard Linux bonding, bridge and
vlan interfaces in such setups?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697357: bridging broken over bond interfaces

[Ferenc Wagner]

Ben Hutchings  writes:

> Forwarding this to netdev since the bug is still present in Linux 3.7.1.
> For those joining us, this thread is archive at
> .

Please forgive me for eliding the previous discussion; I think I hit the
same or a very similar problem in the same setup, but without the KVM or
guest parts (but I could reproduce this in a pretty bare KVM guest with
a virtio network device).  My interface configuration (hopefully
comprehensible without familiarity with Debian):

# this is a bare bond interface named after the native VLAN (no .1q!)
auto vlan894
iface vlan894 inet manual
bond_mode   active-backup
bond_slaves eth0
bond_miimon 100
bond_updelay4000

# this bridge has a static IPv4 address and contains the above bond
auto br894
iface br894 inet static
bridge_portsvlan894
bridge_stp  off
bridge_fd   0
address x.y.z.w
netmask 255.255.255.0
gateway x.y.z.g

Actually, I want ARP monitoring for the bond, but if I leave out either
the miimon *or* the updelay configuration, the machine stops responding
to solicited-node multicast packages (neighbor solicitations) thus
becoming unreachable via its autoconfigured global IPv6 address.  That
is, until I put eth0 into promiscuous mode!  And really, with the above
(working) config dmesg says:

bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: vlan894 is being created...
bonding: vlan894: Setting MII monitoring interval to 100.
bonding: vlan894: Setting up delay to 4000.
bonding: vlan894: setting mode to active-backup (1).
bonding: vlan894: Adding slave eth0.
bonding: vlan894: enslaving eth0 as a backup interface with an up link.
Bridge firewalling registered
device vlan894 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): vlan894: link is not ready
bonding: vlan894: link status definitely up for interface eth0, 4294967295 Mbps 
full duplex.
bonding: vlan894: making interface eth0 the new active one.
device eth0 entered promiscuous mode
bonding: vlan894: first active interface up!
IPv6: ADDRCONF(NETDEV_CHANGE): vlan894: link becomes ready
br894: port 1(vlan894) entered forwarding state
br894: port 1(vlan894) entered forwarding state

(although ip link does not list any promiscuous interfaces).  On the
other hand, if I don't configure eg. bond_updelay:

bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: vlan894 is being created...
bonding: vlan894: Setting MII monitoring interval to 100.
bonding: vlan894: setting mode to active-backup (1).
bonding: vlan894: Adding slave eth0.
bonding: vlan894: making interface eth0 the new active one.
bonding: vlan894: first active interface up!
bonding: vlan894: enslaving eth0 as an active interface with an up link.
Bridge firewalling registered
device vlan894 entered promiscuous mode
br894: port 1(vlan894) entered forwarding state
br894: port 1(vlan894) entered forwarding state

ie. promiscuous mode isn't propageted to eth0 and the global IPv6
address of the machine does not respond to ping6 until tcpdump -i eth0
or ip link set eth0 promisc on.  Meanwhile in all cases:

# ip maddr show dev br894
5:  br894
link  33:33:00:00:00:01
link  01:00:5e:00:00:01
link  33:33:ff:02:00:07
inet  224.0.0.1
inet6 ff02::1:ff02:7 users 2
inet6 ff02::1

This happens with the current 3.7.3-1~experimental.1 amd64 kernel under
Debian wheezy (besides the current 3.2 wheezy kernel).
-- 
Thanks for your time,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697907: munin-plugins-core: slapd_ plugin does not autoconfigure

[Ferenc Wagner]

Steve Schnepp  writes:

> It just got fixed upstream in c5cf4ad4b54983265a38554290414ab9af828bf5.

Outstanding, thanks a lot!
-- 
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697907: munin-plugins-core: slapd_ plugin does not autoconfigure

[Ferenc Wagner]

Package: munin-plugins-core
Version: 2.0.6-1
Severity: normal

Dear Maintainer,

After installing munin-node on a wheezy system:

# ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_connections
# vim /etc/munin/plugin-conf.d/slapd
# munin-run slapd_connections autoconf
no (Can't use string ("cn") as an ARRAY ref while "strict refs" in use at 
/usr/share/perl5/Convert/ASN1/_encode.pm line 269,  line 558.
)

This seems to be caused by an API change in Net::LDAP, and possible to fix
by explicitly using an array reference instead of a string as:

--- /usr/share/munin/plugins/slapd_ 2012-09-03 14:58:08.0 +0200
+++ slapd_connections   2013-01-11 10:36:49.913237002 +0100
@@ -233,7 +233,7 @@
base   => $basedn,
scope  => 'one',
filter => '(objectClass=monitorServer)',
-   attrs  => 'cn',
+   attrs  => ['cn'],
);
 if ($mesg->code) {
   print "no (" . $mesg->error . ")\n";

Please consider upstreaming and patching this bug.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697679: libghc-text-icu-dev: depends on on libicu-dev

[Ferenc Wagner]

Package: libghc-text-icu-dev
Version: 0.6.3.4-2+b2
Severity: normal

Hi,

After installing libghc-text-icu-dev, my first test failed:

$ ghci
GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Text.ICU.Convert
Prelude Data.Text.ICU.Convert> converterNames
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package text-0.11.2.0 ... linking ... done.
Loading package text-icu-0.6.3.4 ... can't load .so/.DLL for: libicui18n.so 
(libicui18n.so: cannot open shared object file: No such file or directory)

Installing libicu-dev resolved this problem.
Please consider extending the control file.

Thanks,
Feri.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.6-trunk-amd64 (SMP w/2 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 libghc-text-icu-dev depends on:
ii  ghc [libghc-bytestring-dev-0.9.2.1-18f26] 7.4.1-4
ii  libc6 2.13-37
ii  libffi5   3.0.10-3
pn  libghc-base-dev-4.5.0.0-40b99 
ii  libghc-text-dev [libghc-text-dev-0.11.2.0-cbc26]  0.11.2.0-1
ii  libgmp10  2:5.0.5+dfsg-2
ii  libicu48  4.8.1.1-10

libghc-text-icu-dev recommends no packages.

Versions of packages libghc-text-icu-dev suggests:
pn  libghc-text-icu-doc   
pn  libghc-text-icu-prof  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697276: ebtables: please do not recommend module-init-tools

[Ferenc Wagner]

Package: ebtables
Version: 2.0.10.4-1
Severity: normal

Hi,

ebtables currently recommends the module-init-tools package,
which since March 2012 has become a transitional package.
Please remember to update this package to recommend kmod in
time for the release of wheezy.

(Text adapted from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683987)
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697275: ebtables: gives warning on installation

[Ferenc Wagner]

Package: ebtables
Version: 2.0.10.4-1
Severity: normal

Hi,

Installing ebtables gives the following warning:

  Setting up ebtables (2.0.10.4-1) ...
  update-rc.d: warning: default start runlevel arguments (2 3 4 5) do not match 
ebtables Default-Start values (S)

which supposedly comes from the postinst script invoking:

  update-rc.d ebtables defaults

Please synchronize the arguments with the LSB header.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#691625: nslcd: stops before ssh sessions are closed during shutdown

[Ferenc Wagner]

Package: nslcd
Version: 0.8.10-2
Severity: normal

Dear Maintainer,

During shutdown, I got a good bunch of log lines like:

sshd[21799]: pam_env(sshd:setcred): No such user!?
sshd[21799]: fatal: login_init_entry: Cannot find user "dummy"

I suspect it's because nslcd was stopped before these ssh sessions
were terminated (by sendsigs, presumably).  I'm not quite sure how
serious this problem is, but it would be nice to see it fixed.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#691439: [Pkg-freeipmi-devel] Bug#691439: Acknowledgement (libfreeipmi12: copyright file missing after upgrade (policy 12.5))

[Ferenc Wagner]

Andreas Beckmann  writes:

> That happens during the sid -> experimental upgrade, not squeeze->wheezy.
> Same problem with libipmidetect0.

As downloaded from packages.debian.org, libfreeipmi12_1.1.5-4_amd64.deb
and libipmidetect0_1.1.5-4_amd64.deb contain symlinks, not directories
under usr/share/doc/, pointing to freeipmi-common.  However, I can
reproduce the issue:

# dpkg -i freeipmi-common_1.1.5-3_all.deb libipmidetect0_1.1.5-3_amd64.deb
# dpkg -i freeipmi-common_1.1.5-4_all.deb libipmidetect0_1.1.5-4_amd64.deb
# ls -ld /usr/share/doc/libipmidetect0
drwxr-xr-x 2 root root 6 Oct 26 09:31 /usr/share/doc/libipmidetect0

which is certainly wrong.  But at the same time:

# dpkg --purge freeipmi-common libipmidetect0
# dpkg -i freeipmi-common_1.1.5-4_all.deb libipmidetect0_1.1.5-4_amd64.deb
# ls -ld /usr/share/doc/libipmidetect0
lrwxrwxrwx 1 root root 15 Jul 11 19:56 /usr/share/doc/libipmidetect0 -> 
freeipmi-common

which is the intended behaviour.  I'm investigating.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#691439: [Pkg-freeipmi-devel] Bug#691439: Acknowledgement (libfreeipmi12: copyright file missing after upgrade (policy 12.5))

[Ferenc Wagner]

Ferenc Wagner  writes:

> Andreas Beckmann  writes:
>
>> That happens during the sid -> experimental upgrade, not squeeze->wheezy.
>> Same problem with libipmidetect0.
>
> As downloaded from packages.debian.org, libfreeipmi12_1.1.5-4_amd64.deb
> and libipmidetect0_1.1.5-4_amd64.deb contain symlinks, not directories
> under usr/share/doc/, pointing to freeipmi-common.  However, I can
> reproduce the issue:
>
> # dpkg -i freeipmi-common_1.1.5-3_all.deb libipmidetect0_1.1.5-3_amd64.deb
> # dpkg -i freeipmi-common_1.1.5-4_all.deb libipmidetect0_1.1.5-4_amd64.deb
> # ls -ld /usr/share/doc/libipmidetect0
> drwxr-xr-x 2 root root 6 Oct 26 09:31 /usr/share/doc/libipmidetect0
>
> which is certainly wrong.  But at the same time:
>
> # dpkg --purge freeipmi-common libipmidetect0
> # dpkg -i freeipmi-common_1.1.5-4_all.deb libipmidetect0_1.1.5-4_amd64.deb
> # ls -ld /usr/share/doc/libipmidetect0
> lrwxrwxrwx 1 root root 15 Jul 11 19:56 /usr/share/doc/libipmidetect0 -> 
> freeipmi-common
>
> which is the intended behaviour.  I'm investigating.

I was tripped up by dpkg feature #404850.  Will fix this.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#648686: [Packaging] Bug#648686: Bug in bonding_err_ plugin

[Ferenc Wagner]

Holger Levsen  writes:

> On Mittwoch, 17. Oktober 2012, Ferenc Wagner wrote:
>
>> Would you please consider fixing this in squeeze, even though upstream
>> seems rather uninterested?
>
> you mean wheezy? in squeeze we wont fix this for sure.

Oh yes, sorry!  You are right: I meant wheezy.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690727: linux-image-3.2.0-3-686-pae: user space serial console messages held back on HS20 blade until qla2xxx is loaded

[Ferenc Wagner]

Ben Hutchings  writes:

> On Tue, 2012-10-16 at 20:44 +0200, Ferenc Wagner wrote:
> 
>> This is an issue on IBM HS20 blades with serial over LAN console.  In short,
>> kernel messages get through all right, but user space messages are buffered
>> until the qla2xxx FC HBA driver module is loaded.  Everything is right if I
>> reverse the order of the two console parameters, making /dev/console refer
>> to the tty0 virtual console.  For debugging, I made the following changes:
>
> Please test Linux 3.5 (as packaged in experimental) or 3.6.

I tried the same in another IBM Bladecenter with slightly different
parts and firmware versions.  There loading qla2xxx does not fix the
user space console output.  Even worse (on a virtual console):

(initramfs) cat /proc/tty/driver/serial
[  225.538801] BUG: unable to handle kernel NULL pointer dereference at 009d
[  225.542505] IP: [] tty_ldisc_try+0xe/0x37
[  225.542505] *pdpt = 376f8001 *pde = 
[  225.642256] Oops:  [#1] SMP

and the machine freezes here (sometimes after printing two lines only).
Maybe http://thread.gmane.org/gmane.linux.kernel/1101432/focus=1303356?

On the other hand:
(initramfs) setserial -g /dev/ttyS0
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
(initramfs) cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:03F8 irq:4 tx:0 rx:0 DSR|CD
1: uart:16550A port:02F8 irq:3 tx:0 rx:0 CTS|DSR|CD
2: uart:unknown port:03E8 irq:4
3: uart:unknown port:03E8 irq:3

But setserial -g /dev/ttyS1 or S2 or S3 does not help like this.

(initramfs) echo hello >/dev/ttyS0

waits for 30 seconds then returns without printing anything.

(initramfs) echo '<2>hello' >/dev/kmsg

does not print to the serial console either, only to the VC (command
line: console=ttyS0,19200n8r console=tty0 loglevel=3 break=top).

User space console output appears on this machine after starting udev,
but I haven't yet found out which module does this.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#648686: Bug in bonding_err_ plugin

[Ferenc Wagner]

Marc Haber  writes:

> On Mon, Nov 14, 2011 at 10:03:06AM +0800, Jim Barber wrote:
>
>> --- bonding_err_.orig   2011-11-14 12:42:18.332577791 +1100
>> +++ bonding_err_2011-11-14 12:44:24.594788291 +1100
>> @@ -97,7 +97,7 @@
>>  grep "^Slave Interface:" ${PROCDIR}/${BONDINGIF} | while read a b if; do
>>fieldname=$(clean_fieldname "$if")
>>echo -n "if_${fieldname}.value "
>> -  grep -A 2 "^Slave Interface: ${if}" ${PROCDIR}/${BONDINGIF} | grep "Link 
>> Failure Count:" | cut -d " " -f 4
>> +  sed "0,/^Slave Interface: ${if}/d; /^\$/,\$d" ${PROCDIR}/${BONDINGIF} | 
>> grep "Link Failure Count:" | cut -d " " -f 4
>>  done
>
> I have forwarded this upstream.

Hi,

Would you please consider fixing this in squeeze, even though upstream
seems rather uninterested?
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690727: linux-image-3.2.0-3-686-pae: user space serial console messages held back on HS20 blade until qla2xxx is loaded

[Ferenc Wagner]

Ben Hutchings  writes:

> On Tue, 2012-10-16 at 20:44 +0200, Ferenc Wagner wrote:
> 
>> This is an issue on IBM HS20 blades with serial over LAN console.  In short,
>> kernel messages get through all right, but user space messages are buffered
>> until the qla2xxx FC HBA driver module is loaded.  Everything is right if I
>> reverse the order of the two console parameters, making /dev/console refer
>> to the tty0 virtual console.  For debugging, I made the following changes:
>
> Please test Linux 3.5 (as packaged in experimental) or 3.6.

Forgot to say that I've already partially tested 3.6 (minimal config, no
modules, no qla2xxx driver): no user space console at all.  I couldn't
test whether loading the module eventually activates it, but the problem
definitely seems to be there.  I'll fully test the packaged 3.5 shortly.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690727: linux-image-3.2.0-3-686-pae: user space serial console messages held back on HS20 blade until qla2xxx is loaded

[Ferenc Wagner]

Ben Hutchings  writes:

> On Tue, 2012-10-16 at 20:44 +0200, Ferenc Wagner wrote:
> 
>> This is an issue on IBM HS20 blades with serial over LAN console.  In short,
>> kernel messages get through all right, but user space messages are buffered
>> until the qla2xxx FC HBA driver module is loaded.  Everything is right if I
>> reverse the order of the two console parameters, making /dev/console refer
>> to the tty0 virtual console.  For debugging, I made the following changes:
>
> Please test Linux 3.5 (as packaged in experimental) or 3.6.

3.5 from experimental behaves the exact same way.
-- 
Thanks,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690727: linux-image-3.2.0-3-686-pae: user space serial console messages held back on HS20 blade until qla2xxx is loaded

[Ferenc Wagner]

Package: src:linux
Version: 3.2.23-1
Severity: normal

Dear Maintainer,

This is an issue on IBM HS20 blades with serial over LAN console.  In short,
kernel messages get through all right, but user space messages are buffered
until the qla2xxx FC HBA driver module is loaded.  Everything is right if I
reverse the order of the two console parameters, making /dev/console refer
to the tty0 virtual console.  For debugging, I made the following changes:

$ diff -u /usr/share/initramfs-tools/init.orig /usr/share/initramfs-tools/init
--- /usr/share/initramfs-tools/init.orig2012-09-21 11:00:57.0 
+0200
+++ /usr/share/initramfs-tools/init 2012-10-16 19:20:27.847481927 +0200
@@ -2,6 +2,8 @@
 
 echo "Loading, please wait..."
 
+ls -l /dev
+
 [ -d /dev ] || mkdir -m 0755 /dev
 [ -d /root ] || mkdir -m 0700 /root
 [ -d /sys ] || mkdir /sys
@@ -23,6 +25,10 @@
[ -e /dev/console ] || mknod -m 0600 /dev/console c 5 1
[ -e /dev/null ] || mknod /dev/null c 1 3
 fi
+
+# devtmpfs provides /dev/ksmg here
+ls -l /dev | while read line; do echo "<2>1;$line"; done >/dev/kmsg
+
 mkdir /dev/pts
 mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true
 mount -t tmpfs -o "nosuid,size=20%,mode=0755" tmpfs /run
@@ -33,6 +39,18 @@
 . /conf/arch.conf
 
 # Set modprobe env
+cat >/firmware_loader <<"EOF"
+#!/bin/sh
+[ $ACTION = add ] || exit 0
+[ $SUBSYSTEM = firmware ] || exit 0
+echo 1 > /sys/$DEVPATH/loading
+cat /lib/firmware/$FIRMWARE >/sys/$DEVPATH/data
+echo 0 > /sys/$DEVPATH/loading
+EOF
+chmod +x /firmware_loader
+echo /firmware_loader >/proc/sys/kernel/hotplug
+echo "<2>Loading qla2xxx" | tee /dev/kmsg
+modprobe qla2xxx
 export MODPROBE_OPTIONS="-qb"
 
 # Export relevant variables

When I boot with the command line below I get the following output on the
SoL console:

[1.372747] 1;total 0
[1.386604] 1;crw---1 00   5,   1 Oct 16 17:32 
console
[1.430066] 1;crw---1 00  10,  62 Oct 16 17:32 
cpu_dma_latency
[1.477674] 1;crw-rw-rw-1 00   1,   7 Oct 16 17:32 full
[...]
[5.253934] 1;crw---1 00   7, 129 Oct 16 17:32 vcsa1
[5.296328] 1;crw---1 00  10,  63 Oct 16 17:32 
vga_arbiter
[5.341881] 1;crw-rw-rw-1 00   1,   5 Oct 16 17:32 zero
[5.390701] Loading qla2xxx
[9.844731] qla2xxx [:02:02.1]-0050:1: No matching ROM signature.
Loading, please wait...
total 0
crw---1 00   5,   1 Oct 16 17:32 console
<2>Loading qla2xxx
Spawning shell within the initramfs
[...]

As can be seen, the output of the echo and ls commands is delayed until the
qla2xxx module is loaded.  Consequently, if I don't load the module I can't
even get a command prompt, because the user space console does not work.
It's not a (recent) regression, even 2.6.18 exhibited this strangeness.  It's
also hardware dependent, the same kernel and initrd works fine in QEMU.

If I boot with loglevel=7 qla2xxx.ql2xextended_error_logging=0x7fff, then
the appearance of user space console output is positioned as:

[7.841217] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 
8.03.07.12-k-debug.
[7.893460] qla2xxx [:02:02.0]-0808: : Bars=67.
[7.922728] qla2xxx :02:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[7.964985] qla2xxx [:02:02.0]-080a: : Memory allocated for ha=f750f800.
[8.007281] qla2xxx [:02:02.0]-080b: : device_type=0x9008 port=1 
fw_srisc_address=0800.
[8.061515] qla2xxx [:02:02.0]-0814: : PIO address=2400.
[8.097534] qla2xxx [:02:02.0]-081c: : MSIX Count:2.
[8.129420] qla2xxx [:02:02.0]-001d: : Found an ISP2312 irq 18 iobase 
0xf81fe000.
[8.176374] qla2xxx [:02:02.0]-081e: : mbx_count=32, req_length=2048, 
rsp_length=512, max_loop_id=2047, init_cb_size=96, gid_list_info_size=6, 
optrom_size=131072, nvram_npiv_size=0, .
[8.276393] qla2xxx [:02:02.0]-081f: : isp_ops=f82ef4d4, 
flash_conf_off=-1, flash_data_off=-1, nvram_conf_off=-1, nvram_data_off=-1.
[8.349901] qla2xxx [:02:02.0]-0820: : 64 Bit addressing is disable.
[8.390104] qla2xxx [:02:02.0]-0822: : init_cb=f7511000 
gid_list=f750e000, srb_mempool=f746a780 s_dma_pool=f7455780.
[8.455270] qla2xxx [:02:02.0]-0827: : ms_iocb=f7513000 ct_sns=f7514000.
[8.497837] qla2xxx [:02:02.0]-082c: : req=f74f4000 req->length=2048 
req->ring=f754 rsp=f7455700 rsp->length=512 rsp->ring=f753.
[8.573405] qla2xxx [:02:02.0]-082f: : async_pd=f7513100.
[8.607934] qla2xxx [:02:02.0]-0841:0: Allocated the host=f750f000 
hw=f750f800 vha=f750f3bc dev_name=:02:02.0
[8.670469] qla2xxx [:02:02.0]-0832:0: can_queue=2176, req=f74f4000, 
mgmt_svr_loop_id=254, sg_tablesize=128.
[8.732616] qla2xxx [:02:02.0]-0833:0: max_id=512 this_id=255 
cmd_per_len=3 unique_id=0 max_cmd_len=16 max_channel=0 max_lun=65535 
transportt=f750d800, v

Bug#646900: [multipath-tools] Errors when Boot On SAN (IBM DS4700)

[Ferenc Wagner]

Ritesh Raj Sarraf  writes:

> On Thursday 27 September 2012 06:14 PM, Ferenc Wagner wrote:
>> From the patch referred in the changelog (43d3f10d):
>> 
>> +HW_HANDLERS=""
>> +
>> +verbose && log_begin_msg "Loading multipath hardware handlers"
>> +for module in ${HW_HANDLERS}; do
>> +  if modprobe --syslog "$module"; then
>> 
>> How should one populate HW_HANDLERS with the appropriate modules?  On
>> the other hand, loading modules before the HBA driver is possible by
>> configuring modprobe, for example by dropping
>
> Looks like I missed the /etc/initramfs/conf.d/ part of it where the user
> could define the hardware handlers.

Thanks for the quick explanation.

> I am busy now. If you have the resource to modify and test it, please
> do. We can then see if it could be pushed in for Wheezy.

Well, actually, my point was that this code doesn't help me with the 3.2
(wheezy) kernel, and there's another right way to achieve its aim under
squeeze, where it does help.  So as far as I'm concerned, this code
should be removed, but I wonder what others think.
-- 
Cheers,
Feri.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org