Re: Meaning of "Checking build-dependency (indep) on amd64" excuse

[Ferenc Wágner]

Paul Wise  writes:

> On Tue, Jan 15, 2019 at 7:06 PM  wrote:
>
>> Could somebody please explain me the meaning of the "Checking
>> build-dependency (indep) on amd64" migration excuse as seen on
>> https://qa.debian.org/excuses.php?package=pacemaker?
>
> Looking at the code, I think it means that the migration scripts are
> verifying the Build-Depends-Indep packages are installable on amd64
> and probably ignoring installability on other arches. This is
> reasonable since all of Debian's arch:all buildds use amd64 right now.

Thanks, Paul, it makes sense indeed and I agree it's reasonable to do,
but how/why is this an excuse?  Is there any problem with that?

> https://salsa.debian.org/release-team/britney2/blob/britney2/policies/policy.py#L916

That gives 404 to me.

>> I think I understand the rest, although I don't know whether the
>> autopkgtest regression blocks migration indefinitely.  That would be
>> unfortunate, because unstable pcs needs unstable pacemaker, so they
>> deadlock...
>
> I think you will need to ask the release team to hint them in together.

OK, will do.
-- 
Regards,
Feri

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Ferenc Wágner]

Andreas Tille  writes:

> I explicitly added "Build-Depends: libnewlib-dev" und thus there is
>
> find /usr/include -name ieeefp.h
> /usr/include/newlib/ieeefp.h
> /usr/include/newlib/machine/ieeefp.h

Use #include  or pass -Inewlib to the compiler (I don't
know whether that's a good idea).

> I have no idea what check.h is seeked in src/CMakeLists.txt which has

Have you got the 'check' package installed?
-- 
Regards,
Feri

Re: Nonlinear git-buildpackage workflow?

[Ferenc Wágner]

Lumin  writes:

> The problem is, if I maintain the two releases in parallel, the
> dch would become a mess when moving the 1.0 release to sid.
> dch will contain duplicated changelog entries (e.g. fixing
> common problems found in both 0.7 and 1.0) and the timeline
> is also screwed up.

Do you know dpkg-mergechangelogs?  I think fixing common problems in the
experimental branch and periodically merging it into the unstable branch
would work out fairly well with its help.  Of course you'd still have to
fix up the version number after the merge.
-- 
Regards,
Feri

Re: Cleaning up after 'gbp buildpackage'

[Ferenc Wágner]

Andrey Rahmatullin  writes:

> gbp runs clean before the second build

Gbp runs clean before each build, but the default clean command was
changed to /bin/true in version 0.6.9.  You can try

gbp buildpackage --git-cleaner="debuild -- clean"

or something similar.
-- 
Feri

Explicit Autoconf disables

[Ferenc Wágner]

Dear Mentors,

When building packages in clean chroots many configure checks are
expected to fail not finding their dependencies.  This is fine.  Until
somebody tries to build the package in a not so clean chroot, where the
additional packages present satisfy some of these checks enabling extra
features.  Or even breaking the build by exposing bugs (see #874600 for
an example).

Is adding all possible --disable-whatever options to the configure call
a good practice?  It clutters debian/rules, isn't easy to do
exhaustively in an obviously correct way, but protects against some
changes in the build environment.  I'm interested in hearing your takes
on the issue.
-- 
Thanks,
Feri

Bug#890276: marked as done (RFS: wine/3.0-1~bpo9+1)

[Ferenc Wágner]

"Debian Bug Tracking System"  writes:

> For the sake of others who upload a backport-relying-on-backports, the
> incantation is:
>
> sbuild --build-dep-resolver=aptitude -s -d stretch-backports -c 
> stretch-amd64-sbuild wine_3.0-1~bpo9+1.dsc

You can leave out the -c option if you add
aliases=stretch-backports-amd64-sbuild to your stretch-amd64-sbuild
schroot config file (and of course APT in the chroot must know the
backports sources).
-- 
Regards,
Feri

Re: Fixing incorrect .orig

[Ferenc Wágner]

Wookey  writes:

> Is there a suffix typically used for this situation of essentially
> 're-done upstream source'

Hi,

$ grep "Version.*real" 
/var/lib/apt/lists/deb.debian.org_debian_dists_stretch_main_binary-amd64_Packages
 

reveals some other options like +real and (+)really, and I've seen .real
as well.
-- 
Regards,
Feri

Re: How to determine the filename for dlopen()

[Ferenc Wágner]

Guillem Jover <guil...@debian.org> writes:

> On Mon, 2017-11-13 at 13:23:01 +0100, Ferenc Wágner wrote:
>
>> I'm packaging a program which wants to dlopen() some library.  It finds
>> this library via pkg-config (PKG_CHECK_MODULES).  How to best determine
>> the filename to use in the dlopen() call?  It should work cross-distro,
>> for cross-compilation and whatnot.  Is it always safe to use the SONAME
>> as the filename?  I'm currently considering something like
>> 
>> ld -shared -o dummy.so $(my_LIBS)
>> objdump -p dummy.so | fgrep NEEDED
>> 
>> coded up properly for Automake.  I'd be grateful for any insight.
>
> IMO dlopen()ing an external library that is not part of the same
> project is a practice that should be very strongly discouraged, if
> not completely abolished.
>
> Please see this very nice mail from Simon McVittie [S], my reply [G],
> and Florian Weimer's [F], for several of the reasons why.
>
>  [S] https://lists.debian.org/debian-devel/2017/03/msg00164.html
>  [G] https://lists.debian.org/debian-devel/2017/03/msg00343.html
>  [F] https://lists.debian.org/debian-devel/2017/03/msg00346.html

Thanks for pointing out this discussion, Guillem.  Fortunately, most of
those points are already taken care of in upstream: they took my patches
exposing the full set of used symbols in throwaway binaries, which I can
process with dpkg-shlibdeps.  SONAMEs are also determined automatically
(though this seems somewhat fragile).  Portability beyond BSDs isn't a
concern either.  Still, the "pedantically correct" way has some appeal,
I'll probably look into implementing it.  At least I can't see any other
way to express alternative groups of library dependencies like ((libnss
and libnspr) or libssl), which would be needed for crypto plugins.
Symbol versioning is neglected as well, as pointed out by Florian.  The
downside is the proliferation of small plugin binary packages.

BTW what are "shared libraries that define themselves to the ABI and
SONAME level" you mention?  Do you mean libraries which expose their
SONAMEs like the various libc compnents do in lib-names.h?
-- 
Thanks,
Feri

Re: How to determine the filename for dlopen()

[Ferenc Wágner]

Christian Seiler  writes:

> Am 2017-11-13 13:23, schrieb wf...@niif.hu:
>
>> I'm packaging a program which wants to dlopen() some library.  It finds
>> this library via pkg-config (PKG_CHECK_MODULES).  How to best determine
>> the filename to use in the dlopen() call?  It should work cross-distro,
>> for cross-compilation and whatnot.  Is it always safe to use the SONAME
>> as the filename?
>
> The SONAME is the right thing to do here, as that is what's encoded in
> the DT_NEEDED field by the linker.
>
>> I'm currently considering something like
>>
>> ld -shared -o dummy.so $(my_LIBS)
>> objdump -p dummy.so | fgrep NEEDED
>
> That might work, but I'm not sure that's very stable.

Hi Christian,

The main problem with this is that my_LIBS as set by PKG_CHECK_MODULES
may contain multiple libraries, and nothing guarantees that I need the
first one.  But there's probably no cure for that.  And it failed badly
on FreeBSD for some reason...  So now I need a BSD machine to log on.

> find_library(PNG_LIBRARY_FILE NAMES png)

Yes, finding the library is what I wanted to offload to ld.  It's
somewhat hairy to scan the library path, or at least I haven't found the
appropriate tool.

> Important:

[Lots of interesting stuff, thanks!]

>  - If you do manage to write some relatively generic code, I would
>urge you to contribute that to CMake as a macro, so that other
>people could also profit from it.

That probably won't happen in the near future, as I've never used CMake,
just tried to parse your code based on English and common sense. :)
-- 
Regards,
Feri

How to determine the filename for dlopen()

[Ferenc Wágner]

Hi,

I'm packaging a program which wants to dlopen() some library.  It finds
this library via pkg-config (PKG_CHECK_MODULES).  How to best determine
the filename to use in the dlopen() call?  It should work cross-distro,
for cross-compilation and whatnot.  Is it always safe to use the SONAME
as the filename?  I'm currently considering something like

ld -shared -o dummy.so $(my_LIBS)
objdump -p dummy.so | fgrep NEEDED

coded up properly for Automake.  I'd be grateful for any insight.
-- 
Thanks,
Feri

Re: Packaging doxygen documentation

[Ferenc Wágner]

Dmitry Bogatov  writes:

> During my work on bglibs, I discovered following:
>
>  - new upstream release (2.03) include doxygen documentation into tarball
>  - unlike previous packageed release (1.06) it contains minified JS file
>  - Lintian warns about source package, containing prebuilt documentation
>and about file without source (JS one), so I repacked tarball.
>  - freshly rebuilt with doxygen at build time documentation again
>contain minified JS file and Lintian again complains about it.
>
> I have no clue about Doxygen, but is it any way to make it (from most
> preferred to least preferred):
>
>  - make built documentation refer to JS from libjs-jquery
>  - generate symlinks to apporiate libjs-jquery files instead
>of making copies
>  - do not combine several JS modules into single file
>  - do not minify JS
>
> Help or experience sharing are welcome.

See https://sources.debian.net/src/doxygen/1.8.8-5/debian/README.jquery/
for some background.  I usually add a Lintian override to my
documentation packages along the lines of:

# This file is installed by Doxygen and is more than just a minimized jQuery
# copy.  The Doxygen maintainers recommend against trying to replace it with
# a symlink to the version in libjs-jquery.
embedded-javascript-library usr/share/doc/*/api/html/jquery.js please use 
libjs-jquery
-- 
Regards,
Feri

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

[Ferenc Wágner]

Etienne Dysli-Metref <etienne.dysli-met...@switch.ch> writes:

> On 20/01/17 12:31, Ferenc Wágner wrote:
>
>> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says:
>> 
>> The postrm script is called after the package's files have been
>> removed or replaced. The package whose postrm is being called may
>> have previously been deconfigured and only be "Unpacked", at which
>> point subsequent package changes do not consider its dependencies.
>> Therefore, all postrm actions may only rely on essential packages
>> and must gracefully skip any actions that require the package's
>> dependencies if those dependencies are unavailable.
>> 
>> This is exactly what happens.  Shibboleth-sp2-utils is removed, then
>> init-system-helpers is removed, then shibboleth-sp2-utils is purged, but
>> it can't use init-system-helpers to fully clean up after itself.
>
> Ah I see! thanks for the reference :)
> Since init-system-helpers is not marked as essential in jessie and is
> installed as a dependency during the piuparts test, it gets removed.
>
>> But we'd still need the functionality of dh-systemd in our backport.
>> I'll look through #822670 and #837585 for hints.
>
> Just keeping dh-systemd (without version, like I added in commit
> 518aa2b) in the build dependencies is enough I think.

Yes, a straightforward merge into debian/jessie-backports should work.
That's what I did for testing this.  I don't think we could reasonably
fix this problem in the Shibboleth package.  Possibly worth reporting to
piuparts, though, so they can work out a general solution if necessary.

> piuparts with --warn-on-leftovers-after-purge does not report other
> problems. Will this piuparts error block the package from getting into
> jessie-backports?

No, it won't, because nobody watches, as far as I know.  Packages aren't
migrated into jessie-backports like they are into testing.  Shall I
upload the backport, or do you plan to add anything else?
-- 
Regards,
Feri

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

[Ferenc Wágner]

Etienne Dysli-Metref <etienne.dysli-met...@switch.ch> writes:

> On 19/01/17 23:46, Ferenc Wágner wrote:
>
>> I couldn't reproduce this on a real jessie system, only in a piuparts
>> chroot.  I think the reason is that piuparts removes init-system-helpers
>> (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm
>> could instruct it to clean up.  I'm not sure what we could do about
>> this.
>
> Indeed piuparts does remove init-system-helpers before
> shibboleth-sp2-utils. I hadn't noticed before but it's in the log:
> [...]
> Why would puiparts do it in this order? shibboleth-sp2-utils depends on
> init-system-helpers!

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says:

The postrm script is called after the package's files have been
removed or replaced. The package whose postrm is being called may
have previously been deconfigured and only be "Unpacked", at which
point subsequent package changes do not consider its dependencies.
Therefore, all postrm actions may only rely on essential packages
and must gracefully skip any actions that require the package's
dependencies if those dependencies are unavailable.

This is exactly what happens.  Shibboleth-sp2-utils is removed, then
init-system-helpers is removed, then shibboleth-sp2-utils is purged, but
it can't use init-system-helpers to fully clean up after itself.

>>> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709).
>> 
>> Why?  I mean, where did this version number come from?
>
> The version comes from debhelper's changelog in jessie-backports [1].
> It's when dh-systemd was moved to debhelper.

Got it, thanks.

> Since adding this version constraint was motivated by piuparts's report,
> it may not be necessary in the end...

But we'd still need the functionality of dh-systemd in our backport.
I'll look through #822670 and #837585 for hints.
-- 
Regards,
Feri

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

[Ferenc Wágner]

Etienne Dysli-Metref  writes:

> Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
> holidays, I'm now backporting it to jessie. So far there is nothing to
> change, however piuparts gives me the following error (which does not
> appear on stretch):
>
>> 0m34.6s ERROR: FAIL: Package purging left files on system:
>>   /etc/systemd/system/multi-user.target.wants/shibd.service -> 
>> /lib/systemd/system/shibd.service  not owned
>>   /etc/systemd/system/shibd.service -> /dev/null  not owned
>>   /var/lib/systemd/deb-systemd-helper-enabled/not owned
>>   /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/   
>>  not owned
>>   
>> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/shibd.service
>>not owned
>>   /var/lib/systemd/deb-systemd-helper-enabled/shibd.service.dsh-also  not 
>> owned
>>   /var/lib/systemd/deb-systemd-helper-masked/ not owned
>>   /var/lib/systemd/deb-systemd-helper-masked/shibd.servicenot owned
>
> It looked like dh-systemd wasn't properly cleaning up despite
> shibboleth-sp2-utils's postrm script looking like it would: [...]

I couldn't reproduce this on a real jessie system, only in a piuparts
chroot.  I think the reason is that piuparts removes init-system-helpers
(the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm
could instruct it to clean up.  I'm not sure what we could do about
this.

> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709).

Why?  I mean, where did this version number come from?
-- 
Feri

Copyright for Autoconf stuff

[Ferenc Wágner]

In #832941 Sean Whitton  writes:

> 6. config.guess, config.sub, configure, configure.in, Makefile.in and
> install-sh are not accounted for in d/copyright.

Hi,

The license and the copyright of these files is pretty much the same all
the time (some details can depend on the date).  However, tracking this
all properly in the copyright files of all packages using Autoconf takes
a huge amount of work.  Is there really no way to redirect all that
effort towards something productive?  For example by declaring at a
central place that these files have the usual license and copyright
unless specified otherwise in debian/copyright, and be done with them?
-- 
Regards,
Feri

Bug#834313: RFS: dh-text/1.0 ITP

[Ferenc Wágner]

Paul Wise  writes:

> On Wed, Aug 17, 2016 at 7:39 PM, Paul Wise wrote:
>
>> That sounds like the best option. I've pointed the dpkg maintainer at
>> your mail on IRC and asked for their thoughts on the matter.
>
> Guillem got enthusiastic about this and came up with this patch:
>
> https://www.hadrons.org/~guillem/tmp/0001-FIXME-Implement-source-stanza-sustvars.patch

There's a typo in the man page patch (standa instead of stanza).  It's
good to have this function in the core, but doesn't that exclude
backports?

> He was also talking about adding C: substvars for changelog fields.

Just out of curiosity: could you please describe a use case for this?
-- 
Thanks,
Feri

Bug#834313: RFS: dh-text/1.0 ITP

[Ferenc Wágner]

Hi,

I'd be more than happy to replace the custom recipes in my rules files
with your dh-text solution, it seems very neat.  Just let me point out a
copy mistake in the head of dh-text:

# dh_text --- debhelper to create system users

Please give it its own synopsis.
-- 
Thanks,
Feri

Re: create Debian Source from GIT repository without tag

[Ferenc Wágner]

Sean Whitton  writes:

> For example, support I'm packaging 0~git.abc123d.  This version number
> might be used because I'm basing my packaging on upstream git commit
> whose hash is uniquely identified by the string 'abc123d'.

Such version numbers won't order correctly.  Didn't you mean to include
a monotonically increasing component before the hash?
-- 
Regards,
Feri

Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]

[Ferenc Wágner]

Gianfranco Costamagna  writes:

> Hi Ferenc and Etienne,
>
>>> It'd probably make sense to start with a jessie backport, where
>>> this change is necessary, then branch off the wheezy backport from
>>> that, and do the PKG_INSTALLDIR change only.
>
> fully agree
> (do you mean, "the revert is necessary", right?)

Right.

>> Thank you Gianfranco and Ferenc for your inputs. I'll redo this as a
>> jessie backport first.
>
> so, Ferenc, if you agree I can sponsor as soon as you give me an ack :)
> Are you in the -backports ACL? in that case you might be able to upload
> by yourself after the first upload in backports-new.

Thanks, I'm in the backports ACL and I've become a DD on Wednesday, so I
should be able to handle this upload myself.  I've never sponsored an
upload yet, so we'll see.  If it does not work out or on occasions I'm
unavailable, your help (both review and upload) will be much
appreciated.
-- 
Thanks,
Feri

Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]

[Ferenc Wágner]

Gianfranco Costamagna  writes:

> the library has been renamed and conflicting with the non-v5 version, because
> of the libstdc++ transition.
>
> backporting to jessie and wheezy (where the transition didn't happen), means
> you have to revert that change, because otherwise the package will be 
> uninstallable
> with all of the reverse dependencies, because of:
>
> Package: libxml-security-c17v5
> Conflicts:
>  libxml-security-c17,
> Replaces:
>  libxml-security-c17,
>
> in this case, oldstable has the library with a different soname (c16),
> so I'm not sure if the rename is worth the effort or not, please ask
> on -mentors, -devel or wherever you find more appropriate.

It'd probably make sense to start with a jessie backport, where this
change is necessary, then branch off the wheezy backport from that, and
do the PKG_INSTALLDIR change only.

> also, can the new patch be added to the package in unstable too?
> -  * [aba87f7] New patch 
> Remove-PKG_INSTALLDIR-to-build-with-older-pkg-config.patch

In principle it could, but it was added in the latest revision with the
very purpose of getting it tested before upstreaming.
-- 
Feri

Re: same upstream version but different orig.tar.gz

[Ferenc Wágner]

Herbert Fortes  writes:

>> You can work around this locally by rewriting your .changes files; the
>> changestool utility in the reprepro packages can help with that.  But
>> you won't be able to upload different files with the same name.  The
>> usual solution is adding a numeric part to the version after +dfsg, like
>> +dfsg1, and incrementing that on each change to the tarball.
>
> The version in experimental[0] now is 7.2.0+dfsg-2.
>
> https://buildd.debian.org/status/package.php?p=webcamoid=experimental
>
> The next upload will be 7.2.0+dfsg1-1 ?

$ dpkg --compare-versions 7.2.0+dfsg-2 \< 7.2.0+dfsg1-1 && echo yes
yes

, that would be a valid choice.
-- 
Feri

Re: same upstream version but different orig.tar.gz

[Ferenc Wágner]

Herbert Fortes  writes:

> So I did a new Debian revision after the +dfsg.orig.tar.gz file be
> replaced.
>
> I just did a 'debdiff' to check the differences between the Debian
> revisions, and of course, the output is:
>
> dpkg-source: error: file webcamoid/webcamoid_7.2.0+dfsg.orig.tar.gz
> has size 3160998 instead of expected 3148208
> [...]
>
> Is this a big problem ? (replace a +dfsg.orig.tar.gz file
> with the same upstream version)

You can work around this locally by rewriting your .changes files; the
changestool utility in the reprepro packages can help with that.  But
you won't be able to upload different files with the same name.  The
usual solution is adding a numeric part to the version after +dfsg, like
+dfsg1, and incrementing that on each change to the tarball.
-- 
Feri

Re: backport questions

[Ferenc Wágner]

Etienne Dysli-Metref  writes:

> I would like to backport Shibboleth packages [1] to jessie and wheezy.
>
> - What branch name should I use?
> Documentation for git-buildpackage [2] says "debian/" so that
> would yield "debian/jessie-backports-sloppy", but I've seen
> "backports/" earlier so I'm unsure.

I recommend debian/jessie-backports.

> - Can I push the backport branches to the repositories in [1]?

Yes, please do so.  Please discuss the necessary changes on our mailing
list beforehand, I'd like to keep the delta small.

> - What should the changelog entry look like? "Backport to "?

Start with what dch --bpo proposes, then add new bullets for your
backporting changes (if needed).

> - Are older "backport" changelog entries kept or removed when a new
> version is backported?
> The Backports contribution doc [3] says:
>
>> Backports of an updated version of a package that was backported 
>> before may have a changelog that merges entries of backports of 
>> previous versions, but this is not required.
>
> but I can't make sense out of this...

I think it means that you can keep them (interleaved by the unstable
entries), or you can merge them into a single entry at the tip.  The
former is probably easier to generate, while the latter is easier to
grasp.
-- 
Feri

Re: Git-buildpackage question: tracking upstream git and tarballs

[Ferenc Wágner]

Raphaël Halimi  writes:

> I'm trying to fully understand the git-buildpackage workflow and I'm
> kind of stuck on a specific part of the process, regarding the handling
> of the upstream branch when upstream uses git but the maintainer still
> wants to use pristine-tar to commit upstream tarballs.
>
> If I understand [1] and [2] correctly, one would need two upstream
> branches : one originating from upstream, with the full commit history,
> and one managed by gbp import-orig, which would contain upstream sources
> imported as single tarballs commits.
>
> [1] http://www.eyrie.org/~eagle/notes/debian/git.html#combine
> [2] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
>
> I don't understand the reason for having two separate upstream branches.
> Is there a specific reason against having a single upstream branch,
> which would contain the full upstream commit history, and maintaining
> the pristine-tar branch with a plain old "pristine-tar commit 
> "

The content of the upstream development branch usually does not match
exactly the content of the distributed tarballs: for example, the latter
often contains autotool intermediate files, which are not present in the
upstream development branch.  These differences matter, especially when
the maintainer is upstreaming patches.  Thus it's handy to have these on
separate branches, and this also reduces the size of the pristine-tar
delta files.

> (since gbp import-orig would want to import the tarball files and
> create a new tag, which both may conflict with the upstream
> branch/tags) ?

See http://dep.debian.net/deps/dep14/ for namespacing ideas.

> Would it make sense to file a wishlist bug report against
> git-buildpackage to ask for a new option to gbp import-orig, which would
> manage the pristine-tar branch without importing anything in the
> upstream branch, and without creating a second upstream tag ? The
> advantage over plain old "pristine-tar  "
> would be to rely on gbp.conf for the upstream branch name instead of
> specifying it every time, and automatic tarball download with the
> --uscan option, whereas plain old pristine-tar needs running uscan
> manually beforehand to download the tarball.

If you use gbp, you seldom invoke pristine-tar directly, if ever.

> Or maybe I didn't understand correctly how --upstream-vcs-tag is
> supposed to work ?

It links the upstream development branch with your upstream tarball
branch by making the tarball commits merges from the provided tag.
-- 
Regards,
Feri

Bug#772004: RFS: openldap/2.4.40-3.1 NMU -- smooth upgrade for partial replicas

[Ferenc Wágner]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package openldap

  Package name: openldap
  Version : 2.4.40-3.1
  Upstream Author : The OpenLDAP Project
  URL : http://www.openldap.org/
  License : OpenLDAP Public License
  Section : net

It builds those binary packages:

  ldap-utils - OpenLDAP utilities
  libldap-2.4-2 - OpenLDAP libraries
  libldap-2.4-2-dbg - Debugging information for OpenLDAP libraries
  libldap2-dev - OpenLDAP development libraries
  slapd - OpenLDAP server (slapd)
  slapd-dbg  - Debugging information for the OpenLDAP server (slapd)
  slapd-smbk5pwd - Keeps Samba and Kerberos passwords in sync within slapd.

To access further information about this package, please visit the following 
URL:
  http://mentors.debian.net/package/openldap

Alternatively, one can download the package with dget using this command:
  dget -x 
http://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.40-3.1.dsc

Changes since the last upload:

  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).

Though technically it's an NMU, please don't delay the upload too much, as
the unblock pre-approval expires on Monday the 8th of December (#771962).
The issue and the various options for fixing it have been discussed on the
BTS, and this seems like the best solution for now.

Regards,
  Ferenc Wágner


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141204100326.11271.99780.report...@lant.ki.iif.hu

Bug#676646: RFS: sblim-wbemcli/1.6.2-4 [ITP #675232] through the BTS this time

[Ferenc Wágner]

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-4
   Upstream Author : Tyrel Datwyler tyr...@us.ibm.com
   URL : 
http://sourceforge.net/apps/mediawiki/sblim/index.php?title=Wbemcli
   License : Eclipse Public License -v 1.0
   Programming Lang: C++
   Section : misc

It builds those binary packages:

  sblim-wbemcli - WBEM Command Line Interface
  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-4.dsc

As an introduction, let me quote its long description from the homepage
of the sblim SourceForge project (http://sblim.wiki.sourceforge.net):

 The WBEM Command Line Interface is a standalone, convenient systems
 management utility for CIMOM access. Invocation and output syntax are
 problem-oriented and well suited for interactively inclusion in Shell
 and Perl scripts. It is especially suited for administrators writing
 their own management scripts or for WBEM developers that want to test
 their providers.

WBEM (Web-Based Enterprise Management) is a successor of SNMP and the
basis of SMI-S (Storage Management Initiative), a standard interface to
storage devices.  WBEM itself has a much wider scope, thus more
ambitious projects like OpenPegasus exist, but the single wbemcli module
of the sblim project is enough to monitor disk and RAID states in SMI-S
compatible storage products for example.  This is also my actual use-
case and reason for packaging it: using an OS-component in our
monitoring system is much easier than carrying along custom binaries.

wbemcli is also part of the Ubuntu WBEM stack; see for example
https://wiki.ubuntu.com/WBEMStackSpec for evaluation of the
alternatives.

Comments, questions and sponsors are much appreciated.  Actually, I'm
rather uncertain about the header format of the patch gcc4.7-fixes,
which could use two Origin fields due to CVS' inability to export
patches touching multiple files, but DEP-3 does not seem to allow such
construction...

Also, the admin, net and utils sections all seem more appropriate than
the current misc.  Which one should I choose?
-- 
Thanks,
Feri.



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871ulpg9p8@szonett.ki.iif.hu