Bug#1054568: breezy - broken rust regex build-dependency

[Jelmer Vernooij]

Hi Peter,

Please do go ahead and NMU this. Thanks!

Cheers,

Jelmer

On Thu, Oct 26, 2023 at 04:19:28AM +0100, Peter Green wrote:
> Package: breezy
> Version: 3.3.4-1
> Severity: serious
> Tags: patch
> 
> Breezy build-depends on librust-regex+aho-corasick-dev which is no longer
> provided (in either physical or virtual form) by rust-regex.
> 
> Looking at the Cargo.toml files I belive the correct build-dependency is
> librust-regex-1+default-dev (>= 1.5.4), after changing the build-dependency
> I was able to get a succesful build.
> 
> If there are no objections I will likely NMU this in the not too distant
> future.

> diff -Nru breezy-3.3.4/debian/changelog breezy-3.3.4/debian/changelog
> --- breezy-3.3.4/debian/changelog 2023-09-04 17:39:38.0 +
> +++ breezy-3.3.4/debian/changelog 2023-10-26 02:55:52.0 +
> @@ -1,3 +1,12 @@
> +breezy (3.3.4-1.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Replace broken build-dependency on "librust-regex+aho-corasick-dev"
> +with build-dependency on "librust-regex-1+default-dev (>= 1.5.4)"
> +based on the contents of Cargo.toml.
> +
> + -- Peter Michael Green   Thu, 26 Oct 2023 02:55:52 
> +
> +
>  breezy (3.3.4-1) unstable; urgency=low
>  
>* New upstream release.
> diff -Nru breezy-3.3.4/debian/control breezy-3.3.4/debian/control
> --- breezy-3.3.4/debian/control   2023-09-04 17:39:38.0 +
> +++ breezy-3.3.4/debian/control   2023-10-26 02:55:40.0 +
> @@ -31,7 +31,7 @@
> debhelper-compat (= 13),
> librust-pkg-version-dev,
> librust-pyo3-dev,
> -   librust-regex+aho-corasick-dev,
> +   librust-regex-1+default-dev (>= 1.5.4),
> rustc
>  Standards-Version: 4.6.2
>  Rules-Requires-Root: no

Bug#1026331: closing 1026331

[Jelmer Vernooij]

close 1026331 
thanks

Bug#948077: possible licensing issues

[Jelmer Vernooij]

Package: php-smbclient
Severity: serious
Usertags: license-violation

php-smbclient links against both libsmbclient (which is GPLv3) and php
(licensed under the PHP3.01 license).

According to both the FSF
(https://www.gnu.org/licenses/license-list.en.html#PHP-3.01) and the
guidance from the ftp-masters (https://ftp-master.debian.org/php-license.html)
these licenses are incompatible.

Bug#948076: possible licensing issues

[Jelmer Vernooij]

Package: php-smbclient
Severity: serious
Usertags: license-violation

php-smbclient links against both libsmbclient (which is GPLv3) and php
(licensed under the PHP3.01 license).

According to both the FSF
(https://www.gnu.org/licenses/license-list.en.html#PHP-3.01) and the
guidance from the ftp-masters (https://ftp-master.debian.org/php-license.html)
these licenses are incompatible.

Bug#948075: possible licensing issues

[Jelmer Vernooij]

Package: php-smbclient
Severity: serious
Usertags: license-violation

php-smbclient links against both libsmbclient (which is GPLv3) and php
(licensed under the PHP3.01 license).

According to both the FSF
(https://www.gnu.org/licenses/license-list.en.html#PHP-3.01) and the
guidance from the ftp-masters (https://ftp-master.debian.org/php-license.html)
these licenses are incompatible.

Bug#940283: Removing python-testtools breaks many packages

[Jelmer Vernooij]

Package: src:python-testtools
Version: 2.3.0-6
Severity: serious

The current upload drops the python 2 packages, which are still used by e.g. 
bzr and python-subunit, python-fixtures, python-testscenarios, python-daemon, 
python-fastimport.

Bug#909017: tweet-auth doesn't work with recent versions of bzr

[Jelmer Vernooij]

Package: bzr-tweet
Version: 1.3.0-1
Severity: serious
Tags: upstream

It looks like bzr-tweet doesn't deal well with newer versions of the Bazaar
credentials API:

bzr: ERROR: exceptions.TypeError: 'NoneType' object has no attribute 
'__getitem__'

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 930, in 
exception_to_return_code
return the_callable(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1121, in 
run_bzr
ret = run(*run_argv)
  File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 673, in 
run_argv_aliases
return self.run(**all_cmd_args)
  File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 697, in run
return self._operation.run_simple(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 136, in 
run_simple
self.cleanups, self.func, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in 
_do_with_cleanups
result = func(*args, **kwargs)
  File "/home/jelmer/.bazaar/plugins/tweet/cmds.py", line 104, in run
twitter_consumer_sec)
  File "/home/jelmer/.bazaar/plugins/tweet/cmds.py", line 57, in auth
owner_key = credentials.get("oauth_token")[0]
TypeError: 'NoneType' object has no attribute '__getitem__'

bzr 2.8.0dev1 on python 2.7.15 (Linux-4.18.0-1-amd64-x86_64-with-debian-
buster-sid)
arguments: ['/usr/bin/bzr', 'tweet-auth']
plugins: bash_completion[2.8.0dev1], builddeb[2.8.6], bzrtools[2.6.0],
changelog_merge[2.8.0dev1], fastimport[0.14.0dev], grep[2.8.0dev1],
launchpad[2.8.0dev1], netrc_credential_store[2.8.0dev1],
news_merge[2.8.0dev1], po_merge[2.8.0dev1], tweet[1.3.0],
weave_fmt[2.8.0dev1], webdav[2.5.0]
encoding: 'utf-8', fsenc: 'UTF-8', lang: 'en_GB.UTF-8'

*** Bazaar has encountered an internal error.  This probably indicates a
bug in Bazaar.  You can help us fix it by filing a bug report at
https://bugs.launchpad.net/bzr/+filebug
including this traceback and a description of the problem.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bzr-tweet depends on:
pn  bzr 
ii  python  2.7.15-3
pn  python-twitter  

bzr-tweet recommends no packages.

bzr-tweet suggests no packages.

Bug#836885: Re-add heimdal-multidev?

[Jelmer Vernooij]

On Sun, Dec 25, 2016 at 01:03:15PM -0800, Ryan Tandy wrote:
> On Sun, Dec 25, 2016 at 09:05:15PM +0100, Michael Fladischer wrote:
> > Now that heimdal has some upstream activity again and 7.1.0 has been
> > uploaded to unstable, is there a chance that openldap will reenable
> > support for "krb5" in "olcSmbK5PwdEnable"?
> 
> I really hope we can, but right now I'm reluctant to change anything until
> heimdal actually migrates to testing.
> 
> My understanding is since heimdal was removed it will be subject to the
> freeze on new packages entering testing (Jan 5th); and given the mips*
> builds currently appear to be blocked by #844357 or something resembling it,
> that doesn't look guaranteed. :/
> 
> If the new version of heimdal does enter testing I will for sure do my best
> to enable support for it in smbk5pwd again promptly.

FWIW Heimdal wasn't actually removed from testing - the new upstream version
happened before all the packages that depended on it were removed from testing
- but we can't really release with what's currently in testing.

Jelmer

Bug#834654: heimdal 7.0.1 test failures

[Jelmer Vernooij]

Yes, on those tests are indeed fixed. See the builds on 
builldd.debian.org/heimdal.

There are still a number of other test failures. Unfortunately I haven't had 
any time to look into those yet, any help debugging those would be greatly 
appreciated.

Jelmer

On 19 December 2016 16:40:45 CET, Sergio Gelato  
wrote:
>The i386 failures, at least, should be fixed in 7.0.2 and later.
>Issue #220 upstream, affecting all platforms where time()+0x7fff
>overflows time_t. I haven't tried your 7.0.2+dfsg1, only my own
>packaging of 7.0.3.
>
>Not sure about the hppa/powerpcspe and m68k failures, and I'm not in a
>position to test those architectures. I've found that debugging is a
>lot
>easier if one can see the detailed logs of the failing tests, as well
>as
>strace/ltrace output for the relevant command invocations.

Bug#822749: Heimdal FTBFS on 32-bit architectures

[Jelmer Vernooij]

Thanks for the patch. Please note that we're in the process of removing Heimdal
from testing, and possibly unstable; see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728

Jelmer

On Wed, Sep 28, 2016 at 03:36:31PM +0200, Sergio Gelato wrote:
> tag 822749 +patch
> thanks
> 
> The attached patch (against the current tip of the Heimdal master branch)
> fixes the problem for me.

> From 9772490720b7007b4d50fb062fb0d3e776ddb907 Mon Sep 17 00:00:00 2001
> From: Sergio Gelato 
> Date: Wed, 28 Sep 2016 15:15:12 +0200
> Subject: [PATCH] Add missing type cast in lib/kadm5/log.c
> 
> On 32-bit architectures with _FILE_OFFSET_BITS=64,
>  sizeof(off_t) > sizeof(size_t) .
> 
> LOG_HEADER_SZ is #define'd as an expression of type size_t, so in order
> to get the sign extension right we need -(off_t)LOG_HEADER_SZ instead of
> (off_t)(-LOG_HEADER_SZ).
> 
> Fixes Debian bug #822749, PR 175.
> ---
>  lib/kadm5/log.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/kadm5/log.c b/lib/kadm5/log.c
> index efe1f78..1f1fcc3 100644
> --- a/lib/kadm5/log.c
> +++ b/lib/kadm5/log.c
> @@ -2337,7 +2337,7 @@ load_entries_cb(kadm5_server_context *server_context,
>   * Seek back to the start of the record poayload so we can read the
>   * whole record.
>   */
> -if (krb5_storage_seek(sp, -LOG_HEADER_SZ, SEEK_CUR) == -1)
> +if (krb5_storage_seek(sp, -(off_t)LOG_HEADER_SZ, SEEK_CUR) == -1)
>  return errno;
>  
>  /*
> -- 
> 2.1.4
> 

Bug#836881: X509 card-based logins fail with SIGSEGV

[Jelmer Vernooij]

tags 836881 +moreinfo
thanks

On Tue, Sep 06, 2016 at 01:52:49PM -0500, Timothy Pearson wrote:
> Package: libhx509-5-heimdal
> Version: 1.7~git20160703+dfsg-1
> Severity: grave
> 
> Heimdal's X509 PAM authentication plugin crashes with the following
> backtrace when attempting to use a cryptographic card to log in:

> Program received signal SIGSEGV, Segmentation fault.
> 0x7f5c0f30e38d in _hx509_match_keys (c=0x18e2ed0, key=0x18e0960) at
> crypto.c:3018
> 3018crypto.c: No such file or directory.
> (gdb) bt
> #0  0x7f5c0f30e38d in _hx509_match_keys (c=0x18e2ed0, key=0x18e0960)
> at crypto.c:3018
Are you sure the version listed above is correct?

lib/hx509/crypto.c only has 2734 lines in 1.7~git20160703+dfsg.

Jelmer

Bug#836881: X509 card-based logins fail with SIGSEGV

[Jelmer Vernooij]

On Tue, Sep 06, 2016 at 01:52:49PM -0500, Timothy Pearson wrote:
> Package: libhx509-5-heimdal
> Version: 1.7~git20160703+dfsg-1
> Severity: grave
> 
> Heimdal's X509 PAM authentication plugin crashes with the following
> backtrace when attempting to use a cryptographic card to log in:
> 
Thanks for the bug report. Please note that we're in the process of removing
Heimdal from testing. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834654 for details.

Bug#834654: no upstream releases; severe bugs open

[Jelmer Vernooij]

Source: heimdal
Severity: serious

There have been no upstream releases of Heimdal in over 4 years and there is no 
current
release management or QA upstream. After 1.6RC2, prior to which releases were
fairly frequent (every month or so), no new releases have happened.

The last full feature release was 1.5 (September 2011). 

Debian has packaged snapshots of Heimdal for a while, mostly because Samba
(which bundles Heimdal) uses it, and it needs specific features to be
compatible with AD. However, Samba turned out too be too closely coupled
to a specific Heimdal version; using a different Heimdal snapshot than what
upstream Samba was using caused subtle bugs, in part because the extensive
QA that happened upstream didn't happen in Debian. Since then, the Samba
package has changed to use the bundled Heimdal. 
See also 
https://lists.alioth.debian.org/pipermail/pkg-samba-maint/2015-April/017277.html

Upstream Heimdal is still somewhat active; most contributors just seem
to run Git snapshots in their own environments. There is a long open bug
in master that makes Heimdal unusable on 32 bit platforms (#822749) and
at the moment of writing, ./configure doesn't run in master on Debian unstable.

At this point it seems very unlikely that upstream will release a 1.7 before
Debians next soft freeze. As maintainers, we don't want to package a 4 year old
Heimdal 1.5 or have Debian support a git snapshot for the next couple of years.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#825437: [Pkg-samba-maint] Bug#825437: talloc fails building on very clean system.

[Jelmer Vernooij]

tags 825437 +moreinfo
thanks

On Thu, May 26, 2016 at 11:18:14PM +0200, Louis van Belle wrote:
> Source: talloc
> Version: 2.1.6
> Severity: serious
> Tags: patch
> Justification: fails to build from source
> 
> Talloc fails builing when you install debian in expert mode and deselect all 
> defaults,
> installed ssh only. 

> 
> The build errors missing pyversions.
> 
> Installing pyton-minimal fixes the problem.

Have you installed the build dependencies of talloc? The build depends include
python-dev, which depends on python, which pre-depends on python-minimal.

Jelmer

Bug#822116: bzr: FTBFS in testing (test fail)

[Jelmer Vernooij]

On Thu, Apr 21, 2016 at 01:12:02PM +0200, Santiago Vila wrote:
> Package: src:bzr
> Version: 2.7.0-4
> Severity: serious
> 
> Dear maintainer:
> 
> This package currently fails to build from source in stretch.
> 
> --
> Traceback (most recent call last):
>   File 
> "/<>/build/lib.linux-x86_64-2.7/bzrlib/plugins/weave_fmt/test_bzrdir.py",
>  line 426, in te
> st_lock_file
> b = branch.Branch.open(self.get_url())
>   File "/<>/build/lib.linux-x86_64-2.7/bzrlib/branch.py", line 
> 186, in open
> possible_transports=possible_transports, _unsupported=_unsupported)
>   File "/<>/build/lib.linux-x86_64-2.7/bzrlib/controldir.py", 
> line 689, in open
> _unsupported=_unsupported)
>   File "/<>/build/lib.linux-x86_64-2.7/bzrlib/controldir.py", 
> line 718, in open_from_transport
> find_format, transport, redirected)
>   File 
> "/<>/build/lib.linux-x86_64-2.7/bzrlib/transport/__init__.py", 
> line 1719, in do_catching_
> redirections
> return action(transport)
>   File "/<>/build/lib.linux-x86_64-2.7/bzrlib/controldir.py", 
> line 706, in find_format
> probers=probers)
>   File "/<>/build/lib.linux-x86_64-2.7/bzrlib/controldir.py", 
> line 1151, in find_format
> return prober.probe_transport(transport)
>   File "/<>/build/lib.linux-x86_64-2.7/bzrlib/bzrdir.py", line 
> 1237, in probe_transport
> format_string = transport.get_bytes(".bzr/branch-format")
>   File 
> "/<>/build/lib.linux-x86_64-2.7/bzrlib/transport/sftp.py", line 
> 422, in get_bytes
> f = self.get(relpath)
>   File 
> "/<>/build/lib.linux-x86_64-2.7/bzrlib/transport/sftp.py", line 
> 414, in get
> f.prefetch()
> TypeError: prefetch() takes exactly 2 arguments (1 given)
> --
> 
> I can send the full build log if required, or you can also get the one
> from reproducible builds, as it fails in the same way:
> 
> https://reproducible.debian.net/rbuild/testing/amd64/bzr_2.7.0-4.rbuild.log

This is caused by an API change in paramiko's public API, making the file_size 
argument to prefetch() mandatory.

Jelmer

Bug#816210: marked as pending

[Jelmer Vernooij]

tag 816210 pending
thanks

Hello,

Bug #816210 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=098d9d3

---
commit 098d9d36bdec460a71d469021cc4eaa3c047dc0e
Author: Jelmer Vernooij <jel...@samba.org>
Date:   Sun Mar 6 22:52:14 2016 +

Move strict ldb dependency to samba-dsdb-modules package, which actually 
contains the modules. Closes: #816210

diff --git a/debian/changelog b/debian/changelog
index 711e8e8..e50d051 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+samba (2:4.3.5+dfsg-2) UNRELEASED; urgency=medium
+
+  * Move strict ldb dependency to samba-dsdb-modules package, which
+actually contains the modules. Closes: #816210
+
+ -- Jelmer Vernooij <jel...@debian.org>  Sun, 06 Mar 2016 22:51:53 +
+
 samba (2:4.3.5+dfsg-1) unstable; urgency=medium
 
   * New upstream release.

Bug#814539: [Pkg-bazaar-maint] Bug#814539: bzrtools: Uninstallable with current sid bzr and python-bzrlib (2.7.0-2)

[Jelmer Vernooij]

On Fri, Feb 12, 2016 at 09:34:03PM +0100, Vincent Ladeuil wrote:
> > Agustin Martin  writes:
> 
> > Package: bzrtools
> > Version: 2.6.0-2
> > Severity: serious
> > Justification: uninstallable in sid
> 
> > Dear Maintainer,
> 
> > Seems that bzrtools needs upgrading for newer bzr package (2.7.0-2),
> 
> Fix pushed at
> https://anonscm.debian.org/bzr/pkg-bazaar/bzrtools/unstable/ as revno
> 761
> 
> patch attached.
> 
> Tested locally with adt-run .// -U --- lxc -es adt-sid
> 
> Please upload ;)
Unfortunately we do have to rely on Depends. DEP8 failures don't prevent users
from installing an incompatible combination of bzr and bzrtools.

Cheers,

Jelmer

Bug#810990: libxmlrpcpp-dev: /usr/include/base64.h already shipped by heimdal-dev

[Jelmer Vernooij]

On Tue, Jan 19, 2016 at 09:38:35AM +0100, Jochen Sprickerhof wrote:
> Hi,
> 
> I've pushed changes to libxmlrpcpp-dev to move the base64.h to
> /usr/include/xmlrpcpp [1]. Would it be ok if I reassign this to
> libxmlrpcpp-dev and close it, or should we split it, to leave one open
> for heimdal-dev?
> 
> * Wookey  [2016-01-16 03:26]:
> > Debian now has this xmplrpc c++ implementation: 
> > https://tracker.debian.org/pkg/xmlrpc-c
> > maybe ros-ros-comm could just use that? I've not looked to see how well the 
> > APIs match up. 
> 
> ROS upstream is currently working on ROS2, replacing most of the core
> system, so I hope this gets resolved with that.

Heimdal already ships a package (heimdal-multidev) that moves these files into
/usr/include/heimdal. 

heimdal-dev currently merely ships symlinks to these files in /usr/include
for backwards compatibility reasons. I'll see if we can remove the backwards
compatibility symlinks.

Cheers,

Jelmer

Bug#807331: [Pkg-samba-maint] Bug#807331: samba: Fails to build from source when not being able to download docbook.xsl

[Jelmer Vernooij]

On Mon, Dec 07, 2015 at 02:54:57PM +0100, John Paul Adrian Glaubitz wrote:
> Package: samba
> Version: 2:4.1.21+dfsg-2
> Severity: serious
> Justification: fails to build from source (sometimes)
> 
> Hello!
> 
> The samba package fails to build from source when it can't download the 
> external
> stylesheet docbook.xsl which is downloaded from sourceforge.net:
> 
> Checking for stylesheet 
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl : not 
> found
> 
> and consequently won't build the manpages which then results in:
> 
> #Remove unused vfstest manpage as there is no more vfstest apparently
> rm /<>/samba-4.1.21+dfsg/debian/tmp/usr/share/man/man1/vfstest.1
> rm: cannot remove 
> '/<>/samba-4.1.21+dfsg/debian/tmp/usr/share/man/man1/vfstest.1': No 
> such file or directory
> debian/rules:93: recipe for target 'override_dh_install' failed
> make[1]: *** [override_dh_install] Error 1
> make[1]: Leaving directory '/<>/samba-4.1.21+dfsg'
> debian/rules:69: recipe for target 'binary' failed
> make: *** [binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
> 
> I'm not sure why exactly the download of the stylesheet fails. It fails on the
> sparc64 and x32 buildds and on my personal sbuild amd64 chroot, all of them
> are up-to-date. Since I can download the stylesheet from the very same machine
> I am using for amd64 builds:

Are you sure that it is actually attempting to download the file from a remote
server? The docbook-xsl package should make sure that it is just using a local
copy of that file, even when Samba is referencing the URL.

The root cause is probably this bug: http://bugs.debian.org/750593

Cheers,

Jelmer

Bug#807331: [Pkg-samba-maint] Bug#807331: Bug#807331: samba: Fails to build from source when not being able to download docbook.xsl

[Jelmer Vernooij]

On Mon, Dec 07, 2015 at 03:23:00PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/07/2015 03:03 PM, Jelmer Vernooij wrote:
> > The root cause is probably this bug: http://bugs.debian.org/750593
> 
> That could explain the problem on sparc64 and x32, but it doesn't
> segfault on my amd64 machine, yet the download fails. I can run xsltproc
> with the URL in my sbuild chroot and it is able to download and parse
> the file. However, when I sbuild samba, it still fails. I can't really
> wrap my head around what happens here.
Do you have /dev/shm available in your sbuild chroot, per that bug?

Have you tried building the Samba manpages in your schroot, e.g. smb.conf.5?
That's the one that actually needs it.

Cheers,

Jelmer

Bug#807331: [Pkg-samba-maint] Bug#807331: Bug#807331: samba: Fails to build from source when not being able to download docbook.xsl

[Jelmer Vernooij]

On Mon, Dec 07, 2015 at 04:07:40PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/07/2015 03:38 PM, Jelmer Vernooij wrote:
> >> That could explain the problem on sparc64 and x32, but it doesn't
> >> segfault on my amd64 machine, yet the download fails. I can run xsltproc
> >> with the URL in my sbuild chroot and it is able to download and parse
> >> the file. However, when I sbuild samba, it still fails. I can't really
> >> wrap my head around what happens here.
> > Do you have /dev/shm available in your sbuild chroot, per that bug?
> 
> Ok, this *does* fix the problem actually. I have to bind-mount dev
> into my chroot and set the permissions to 777. Vry strange that
> xsltproc does not fail when I chroot into my sbuild environment and
> call it directly, but it fails when the samba Python scripts call it.
> 
> In any case, thanks a lot for helping me to pin-point the issue. This
> is indeed a bug in xsltproc then and we can therefore close this bug
> again!
> 
> I will make the necessary modifications to all buildds in question!

You're welcome. Thank you for fixing the buildds, much appreciated!

Cheers,

Jelmer

Bug#805176: marked as pending

[Jelmer Vernooij]

tag 805176 pending
thanks

Hello,

Bug #805176 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=2b4d651

---
commit 2b4d65137783643d7582aa80a16e7d18e4d25a50
Author: Jelmer Vernooij <jel...@samba.org>
Date:   Sun Nov 15 15:15:46 2015 +

Rebuild aginst newer ldb. Closes: #805176

diff --git a/debian/changelog b/debian/changelog
index 74c78e0..fa0298d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ samba (2:4.1.21+dfsg-1) UNRELEASED; urgency=medium
 
   * New upstream release.
   * Fix epoch for dependency on ldb. Closes: #800331
+  * Rebuild aginst newer ldb. Closes: #805176
 
  -- Jelmer Vernooij <jel...@debian.org>  Sun, 27 Sep 2015 21:56:30 +
 

Bug#801568: Resolving tevent.h name conflict

[Jelmer Vernooij]

Hi Colin,

tevent has been shipping tevent.h for a long time, and various
dependencies include this header (samba, ldb, openchange).

Would it be possible for linpac to change the name of this file?

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#804388: FTBFS: TypeError: _delta_to_float() takes exactly 3 arguments (2 given)

[Jelmer Vernooij]

Package: bzr-stats
Version: 0.1.0+bzr51-1
Severity: serious

Dear Maintainer,

bzr-stats currently FTBFS:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/tmp/bzr-stats-0.1.0+bzr51'
BZR_PLUGINS_AT=stats@/tmp/bzr-stats-0.1.0+bzr51 /usr/bin/bzr selftest -s 
bp.stats \
-v --parallel=fork
running 0 tests...
bzr selftest: /usr/bin/bzr
   /usr/lib/python2.7/dist-packages/bzrlib
   bzr-2.7.0dev1 python-2.7.10 
Linux-4.2.0-1-amd64-x86_64-with-debian-stretch-sid

bzrlib.plugins.stats.test_classify.TestClassify.test_classify_codebzrlib.plugins.stats.test_classify.TestClassify.test_classify_codebzrlib.plugins.stats.test_classify.TestClassify.test_classify_doc_hardcodedbzrlib.plugins.stats.test_classify.TestClassify.test_classify_doc_hardcodedbzrlib.plugins.stats.test_classify.TestClassify.test_classify_artbzrlib.plugins.stats.test_classify.TestClassify.test_classify_artbzrlib.plugins.stats.test_classify.TestClassify.test_classify_documentationbzrlib.plugins.stats.test_classify.TestClassify.test_classify_documentationbroken-runnerbroken-runnerException
 in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/dist-packages/testtools/testsuite.py", line 112, in 
_run_test
case.run(process_result)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 780, in 
run
outcome(self, details=self._details)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
1133, in addError
return self.decorated.addError(test, err)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
1008, in addError
test, err, details=details)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
999, in _add_result_with_semaphore
method(test, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
1133, in addError
return self.decorated.addError(test, err)
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 451, 
in addError
self.report_error(test, err)
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 719, 
in report_error
% (self._testTimeString(test),
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 372, 
in _testTimeString
return self._elapsedTestTimeString()
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 365, 
in _elapsedTestTimeString
self._now() - self._start_datetime))
TypeError: _delta_to_float() takes exactly 3 arguments (2 given)

broken-runnerbroken-runnerException in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/dist-packages/testtools/testsuite.py", line 112, in 
_run_test
case.run(process_result)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 780, in 
run
outcome(self, details=self._details)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
1133, in addError
return self.decorated.addError(test, err)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
1008, in addError
test, err, details=details)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
999, in _add_result_with_semaphore
method(test, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/testtools/testresult/real.py", line 
1133, in addError
return self.decorated.addError(test, err)
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 451, 
in addError
self.report_error(test, err)
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 719, 
in report_error
% (self._testTimeString(test),
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 372, 
in _testTimeString
return self._elapsedTestTimeString()
  File "/usr/lib/python2.7/dist-packages/bzrlib/tests/__init__.py", line 365, 
in _elapsedTestTimeString
self._now() - self._start_datetime))
TypeError: _delta_to_float() takes exactly 3 arguments (2 given)

broken-runnerbroken-runnerException in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/dist-packages/testtools/testsuite.py", line 112, in 
_run_test
case.run(process_result)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 780, in 
run
outcome(self, details=self._details)
  File 

Bug#799840: marked as pending

[Jelmer Vernooij]

tag 799840 pending
thanks

Hello,

Bug #799840 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=a2253a9

---
commit a2253a9df8b69358e29c22f2c879ed2b01ea24a4
Author: Jelmer Vernooij <jel...@samba.org>
Date:   Thu Oct 1 21:38:55 2015 +

Remove libpam-smbpasswd, which is broken and slated for removal upstream. 
Closes: #799840

diff --git a/debian/changelog b/debian/changelog
index f5ccd69..2054b38 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+samba (2:4.3.0+dfsg-3) UNRELEASED; urgency=medium
+
+  * Remove libpam-smbpasswd, which is broken and slated for removal
+upstream. Closes: #799840
+
+ -- Jelmer Vernooij <jel...@debian.org>  Thu, 01 Oct 2015 21:37:48 +
+
 samba (2:4.3.0+dfsg-2) experimental; urgency=medium
 
   * Re-enable cluster support.

Bug#799076: Reproducing

[Jelmer Vernooij]

Hey Chris,

On Sat, Sep 19, 2015 at 08:03:18PM +0100, Chris Lamb wrote:
> > Ah, thanks. I've managed to reproduce it now - I had to enable the
> > translation strings for ch_FR.UTF-8 for C git.
> Great stuff. And other locales? I just tried that one.
Dulwich runs some tests against C git (to verify compatibility) and
then greps its output for certain output. This is not ideal, but
the best way I've found so far to verify we produce files that C git
can handle.

I've modified the code to always pass LANG=C to C git when invoking
it, so that should cover all locales.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jel...@debian.org>
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#799076: Reproducing

[Jelmer Vernooij]

On Sat, Sep 19, 2015 at 12:18:13PM +0100, Chris Lamb wrote:
> Hey,
> 
> > Can you reproduce it?
> 
> I always can reproduce issues before filing! :)
> 
> > How is the locale set exactly?
> 
> I installed the locales package, selected fr_CH.UTF-8, exported this as
> LANG, then rebuilt. Nothing crazy, just as if I was running this locale
> everyday.
Ah, thanks. I've managed to reproduce it now - I had to enable the
translation strings for ch_FR.UTF-8 for C git.

> Saying *that* I can't actually reproduce right this second in current
> sid even under a "vanilla" locale as I'm FTBFS with:
> 
>   running build_ext
>   building 'dulwich._objects' extension
>   creating build-pypy/temp.linux-x86_64-2.7
>   creating build-pypy/temp.linux-x86_64-2.7/dulwich
>   cc -O2 -fPIC -Wimplicit -D_FORTIFY_SOURCE=2 -g -O2
>   -fstack-protector-strong -Wformat -Werror=format-security
>   -I/usr/lib/pypy/include -c dulwich/_objects.c -o
>   build-pypy/temp.linux-x86_64-2.7/dulwich/_objects.o
>   dulwich/_objects.c:20:20: fatal error: Python.h: No such file or
>   directory
>   compilation terminated.
> 
> I'm sure this is unrelated, but a bit of a blocker :)
This is a regression in pypy-dev 2.6.1+dfsg-1.  I've filed
http://bugs.debian.org/799485

Cheers,

Jelmer

-- 
Jelmer Vernooij <jel...@debian.org>
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#799076: Reproducing

[Jelmer Vernooij]

Hi Chris,

Do you have any suggestions on how to reproduce this? I'm somewhat
surprised that this would fail on a different locale, and am having
trouble reproducing it (by setting LC_ALL=fr_CH.UTF-8).

How is the locale set exactly? Can you reproduce it?

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#790777: [Pkg-samba-maint] Bug#790777: Bug#790777: Building with sbuild?

[Jelmer Vernooij]

On Tue, Sep 01, 2015 at 09:03:49PM +1200, Andrew Bartlett wrote:
> On Tue, 2015-08-25 at 20:25 +0000, Jelmer Vernooij wrote:
> > On Tue, Aug 25, 2015 at 12:21:10PM -0400, Martin Michlmayr wrote:
> > > * Jelmer Vernooij <jel...@debian.org> [2015-08-22 22:45]:
> > > > Are you building with sbuild?
> > > > 
> > > > You are possibly hitting http://bugs.debian.org/750593
> > > 
> > > I was using sbuild but I also see it in a normal chroot.  Are you
> > > saying you don't see it?
> > 
> > Building locally, I can't reproduce this.
> > 
> > Is this a normal chroot where /dev/shm is available and writeable for
> > all users?
> 
> We can reproduce this at will on i686 Ubuntu images on the Catalyst
> cloud. 
> 
> Douglas chased it as far as the kernel page layout!  It seems to come
> down to differences in opinion on how deep a nested stack should be
> able to go.

The workaround is to make /dev/shm available (which I guess allows for extra
stack space?). Proper fix would be to avoid the extra nesting in the
stylesheets.

Cheers,

Jelmer

Bug#790777: [Pkg-samba-maint] Bug#790777: Building with sbuild?

[Jelmer Vernooij]

On Tue, Aug 25, 2015 at 12:21:10PM -0400, Martin Michlmayr wrote:
 * Jelmer Vernooij jel...@debian.org [2015-08-22 22:45]:
  Are you building with sbuild?
  
  You are possibly hitting http://bugs.debian.org/750593
 
 I was using sbuild but I also see it in a normal chroot.  Are you
 saying you don't see it?

Building locally, I can't reproduce this.

Is this a normal chroot where /dev/shm is available and writeable for
all users?

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#795661: Regression in subversion

[Jelmer Vernooij]

This is caused by a regression in subversion, which means it is no
longer possible to pass a nonexistant path to svn_fs_is_dir() or
svn_fs_is_file(). Doing so causes a segfault.

I'll remove these tests for, so the package will build again. The
docstring for these functions doesn't technically say that you can
pass nonexistant paths to them, though crashing seems unnecessary.


signature.asc
Description: Digital signature

Bug#790777: Building with sbuild?

[Jelmer Vernooij]

Hi Michael,

Are you building with sbuild?

You are possibly hitting http://bugs.debian.org/750593

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#793866: marked as pending

[Jelmer Vernooij]

tag 793866 pending
thanks

Hello,

Bug #793866 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=9a8912d

---
commit 9a8912d9621921c2e1383708744d68325a843908
Author: Jelmer Vernooij jel...@samba.org
Date:   Mon Jun 22 22:53:02 2015 +

Move ownership of var/lib/samba and var/lib/samba/private to samba-common, 
remove obsolete samba4.dirs. Closes: #793866

diff --git a/debian/changelog b/debian/changelog
index 9d004ed..35b91fa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,8 @@ samba (2:4.2.1+dfsg-1) UNRELEASED; urgency=medium
   * Add patch no_wrapper: avoid dependencies on
 {nss,uid,socket}_wrapper.
   * Move some libraries around.
+  * Move ownership of var/lib/samba and var/lib/samba/private to samba-
+common, remove obsolete samba4.dirs. Closes: #793866
 
   [ Mathieu Parent ]
   * Merge ctdb source package

Bug#776094: dovecot-imapd: corrupts mailbox after trying to retrieve it

[Jelmer Vernooij]

Hi Santiago,

On Mon, May 25, 2015 at 01:43:10PM +0200, Santiago Vila wrote:
 Jaldhar, Jelmer:
 
 This is serious data corruption bug, and we have a fix for it since 12
 days ago. Is there any hope that a fix for this bug is included in
 Debian 8.1? Release managers say the queue for fixes will be frozen
 next weekend.
Agreed that we should really try to get this fixed for 8.1.

I've just uploaded 2.2.18. I will try to do a stable update as well, but
am unfortunately low on Debian time. Help welcome.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#780958: squeeze update of dulwich?

[Jelmer Vernooij]

Hi Raphael,

I'd prefer if somebody from the lts team could look at this. If you
prefer, I'm happy to review a debdiff but feel free to upload without
my review. Dulwich has an extensive testsuite, and the fixes for these
bugs include tests to verify they are fixed.

Thanks for your work on Debian LTS! 

Cheers,

Jelmer

On Fri, Apr 10, 2015 at 11:24:51PM +0200, Raphael Hertzog wrote:
 Hello Jelmer,
 
 the Debian LTS team would like to fix the security issues which are
 currently open in the Squeeze version of dulwich:
 https://security-tracker.debian.org/tracker/CVE-2014-9706
 https://security-tracker.debian.org/tracker/CVE-2015-0838
 (CVE-2014-9390 is also open but it's lower priority and can be ignored)
 
 Would you like to take care of this yourself? We are still understaffed so
 any help is always highly appreciated.
 
 If yes, please follow the workflow we have defined here:
 http://wiki.debian.org/LTS/Development
 
 If that workflow is a burden to you, feel free to just prepare an
 updated source package and send it to debian-...@lists.debian.org
 (via a debdiff, or with an URL pointing to the the source package,
 or even with a pointer to your packaging repository), and the members
 of the LTS team will take care of the rest. Indicate clearly whether you
 have tested the updated package or not.
 
 If you don't want to take care of this update, it's not a problem, we
 will do our best with your package. Just let us know whether you would
 like to review and/or test the updated package before it gets released.
 
 Thank you very much.
 
 Raphaël Hertzog,
   on behalf of the Debian LTS team.
 
 PS: A member of the LTS team might start working on this update at
 any point in time. You can verify whether someone is registered
 on this update in this file:
 https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
 -- 
 Raphaël Hertzog ◈ Debian Developer
 
 Support Debian LTS: http://www.freexian.com/services/debian-lts.html
 Learn to master Debian: http://debian-handbook.info/get/

-- 
Jelmer Vernooij jel...@debian.org
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#776316: [Pkg-samba-maint] Bug#776316: samba: failed to build on mips

[Jelmer Vernooij]

On Mon, Jan 26, 2015 at 01:42:51PM -0500, Michael Gilbert wrote:
 package: src:samba
 version: 2:4.1.13+dfsg-4
 severity: serious
 
 The latest upload failed to build on the mips buildd:
 https://buildd.debian.org/status/package.php?p=samba

See the comment in the build log:

21:17:20 runner /usr/bin/gcc -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -fPIC -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fstack-protector -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -DSTATIC_python_irpc_MODULES=NULL
-DSTATIC_python_irpc_MODULES_PROTO= -MD -fno-strict-aliasing
-D_FORTIFY_SOURCE=2 -Idefault/source4/librpc -I../source4/librpc
-Idefault/include/public -I../include/public -Idefault/source4
-I../source4 -Idefault/lib -I../lib -Idefault/source4/lib
-I../source4/lib -Idefault/source4/include -I../source4/include
-Idefault/include -I../include -Idefault/lib/replace -I../lib/replace
-Idefault -I../../../../usr/include -Idefault -I.. -Idefault/lib/param
-I../lib/param -Idefault/libcli/ldap -I../libcli/ldap -Idefault/librpc
-I../librpc -Idefault/source4/dsdb -I../source4/dsdb -Idefault/python
-I../python -Idefault/libcli/auth -I../libcli/auth -Idefault/lib/addns
-I../lib/addns -Idefault/auth/gensec -I../auth/gensec
-Idefault/auth/credentials -I../auth/credentials
-Idefault/lib/krb5_wrap -I../lib/krb5_wrap -Idefault/lib/ldb-samba
-I../lib/ldb-samba -Idefault/libcli/dns -I../libcli/dns
-Idefault/libcli/util -I../libcli/util -Idefault/source4/auth/kerberos
-I../source4/auth/kerberos -Idefault/source4/param -I../source4/param
-Idefault/lib/socket -I../lib/socket -Idefault/lib/util/charset
-I../lib/util/charset -Idefault/source4/libcli -I../source4/libcli
-Idefault/source4/lib/events -I../source4/lib/events
-Idefault/lib/async_req -I../lib/async_req
-Idefault/source4/auth/gensec -I../source4/auth/gensec
-Idefault/auth/kerberos -I../auth/kerberos -Idefault/source4/auth
-I../source4/auth -Idefault/lib/dbwrap -I../lib/dbwrap
-Idefault/source3 -I../source3 -Idefault/source3/include
-I../source3/include -Idefault/source3/lib -I../source3/lib
-Idefault/lib/tdb_compat -I../lib/tdb_compat -Idefault/lib/iniparser
-I../lib/iniparser -Idefault/source3/librpc -I../source3/librpc
-Idefault/source4/cluster -I../source4/cluster
-Idefault/libcli/netlogon -I../libcli/netlogon
-Idefault/libcli/security -I../libcli/security -Idefault/libcli/nbt
-I../libcli/nbt -Idefault/libcli/drsuapi -I../libcli/drsuapi
-Idefault/lib/tsocket -I../lib/tsocket -Idefault/source4/lib/tls
-I../source4/lib/tls -Idefault/libds/common -I../libds/common
-Idefault/source4/libcli/smb2 -I../source4/libcli/smb2
-Idefault/source4/lib/messaging -I../source4/lib/messaging
-Idefault/auth/ntlmssp -I../auth/ntlmssp
-Idefault/source4/heimdal_build -I../source4/heimdal_build
-Idefault/libcli/cldap -I../libcli/cldap -Idefault/source4/lib/socket
-I../source4/lib/socket -Idefault/auth -I../auth -Idefault/libcli/smb
-I../libcli/smb -Idefault/libcli/lsarpc -I../libcli/lsarpc
-Idefault/source4/libcli/ldap -I../source4/libcli/ldap
-Idefault/dynconfig -I../dynconfig -Idefault/lib/compression
-I../lib/compression -Idefault/source4/lib/stream
-I../source4/lib/stream -Idefault/lib/crypto -I../lib/crypto
-I/usr/local/include -I/usr/include/et -I/usr/include/heimdal
-I/usr/include/python2.7 -I/usr/include/mips-linux-gnu/python2.7
-D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
-D_XOPEN_SOURCE_EXTENDED=1 default/source4/librpc/gen_ndr/py_irpc.c -c
-o default/source4/librpc/gen_ndr/py_irpc_81.o
The bug is not reproducible, so it is likely a hardware or OS problem.

Cheers,

Jelmer

-- 
Jelmer Vernooij jel...@debian.org
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#773016: [Pkg-samba-maint] Bug#773016: closed by Jelmer Vernooij jel...@debian.org (Bug#773016: fixed in ctdb 2.5.4+debian0-2)

[Jelmer Vernooij]

On Sun, Dec 14, 2014 at 08:22:02AM +1100, Martin Schwenke wrote:
 On Sat, 13 Dec 2014 16:09:23 +, ow...@bugs.debian.org (Debian Bug
 Tracking System) wrote:
 
  This is an automatic notification regarding your Bug report
  which was filed against the ctdb package:
  
  #773016: ctdb: Starting CTDB fails with Unable to open 
  /var/lib/run/ctdb/.socket_lock
  
  It has been closed by Jelmer Vernooij jel...@debian.org.
  
  Their explanation is attached below along with your original report.
  If this explanation is unsatisfactory and you have not received a
  better one in a separate message then please contact Jelmer Vernooij 
  jel...@debian.org by
  replying to this email.
 
 Why not --localstatedir=/var ?  To me that looks like the simplest and
 most correct fix.  It defaults to PREFIX/var and the standard thing to
 do when building packages to install in /usr is to set
 --localstatedir=/var.
Yeah, that's a good point.

The bug report just mentioned this path, whereas all the files under
/var were actually broken.

Fixed and uploaded -3.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#771991: [Pkg-samba-maint] Bug#771991: fixed in samba 2:4.1.13+dfsg-3

[Jelmer Vernooij]

On Wed, Dec 10, 2014 at 03:18:30PM +0100, Alexander Hofbauer wrote:
 I ran into an issue today where libldb1 was updated to 1.1.18 and samba now
 complains about mismatching versions at startup, refusing to run.
 
 Could this be addressed by a rebuild?
Please install 2:4.1.13+dfsg-3, which allows samba to be used with ldb 1.1.18.

Jelmer


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

Bug#771991: marked as pending

[Jelmer Vernooij]

tag 771991 pending
thanks

Hello,

Bug #771991 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=1fc7a76

---
commit 1fc7a76b905d665bdbbed080816f317b9fa3a363
Author: Jelmer Vernooij jel...@samba.org
Date:   Wed Dec 10 18:13:45 2014 +

Revert previous patch, since ldb has an active module version check. 
Instead, just depend on ldb 1.1.18.

Change-Id: Ibc73bd7fed13b810a04e9c23abf2f9117b22779b

diff --git a/debian/changelog b/debian/changelog
index 525bed2..87c930c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+samba (2:4.1.13+dfsg-4) UNRELEASED; urgency=medium
+
+  * Revert previous patch, since ldb has an active module version check.
+Instead, just depend on ldb 1.1.18. Closes: #771991
+
+ -- Jelmer Vernooij jel...@debian.org  Wed, 10 Dec 2014 18:13:42 +
+
 samba (2:4.1.13+dfsg-3) unstable; urgency=medium
 
   * Update debian/rules to allow support for multiple upstream ldb


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

Bug#769259: Not important for jessie

[Jelmer Vernooij]

golang-testify (and golang-raft) were packaged because it is a dependency of
etcd. It would be nice to fix this bug for jessie, but since etcd has not made
it into the archive yet for various reasons, it is probably fine if
golang-testify was removed from testing.


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

Bug#771991: samba-libs dependencies are too strict

[Jelmer Vernooij]

Sorry, I should have clarified in the changelog that this new
upstream release is bug-fix only: it fixes a segfault in
pyldb, clarifies some documentation and adds a missing include to one
of the public headers.

I hadn't thought of the strict dependency in samba-libs on a specific
upstream samba version.

LDB has a stable public ABI, but does not promise anything about the
interface it provides for plugins (for reasons I won't go into here).
Because of this, Samba binary packages depend on a specific upstream
of ldb so that we know future versions of ldb aren't going to break
our plugins.

I'll upload a new version of Samba that relaxes the run time
dependency to allow both ldb 1.1.17 and 1.1.18, since there are no
difference in the plugin interface for those versions.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#771991: marked as pending

[Jelmer Vernooij]

tag 771991 pending
thanks

Hello,

Bug #771991 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=cede370

---
commit cede370ddccb21b65e48051387ea9a32ed3633d9
Author: Jelmer Vernooij jel...@samba.org
Date:   Thu Dec 4 21:11:49 2014 +

Add bug#.

Change-Id: Ia84038fcb40de9536a16ada75a1f3d0603ea9357

diff --git a/debian/changelog b/debian/changelog
index 2cdd465..bcfe399 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,7 @@
 samba (2:4.1.13+dfsg-3) UNRELEASED; urgency=medium
 
   * Update debian/rules to allow support for multiple upstream ldb
-versions, when verified.
+versions, when verified. Closes: #771991
 
  -- Jelmer Vernooij jel...@debian.org  Thu, 04 Dec 2014 21:03:54 +0100
 


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

Bug#765567: Patch by Peter de Wachter

[Jelmer Vernooij]

tags 765567 +patch
thanks

Peter de Wachter wrote a patch for this bug, though it was attached to
the related bug against xsltproc.
Description: use EXSLT replace function when available
 A recursive implementation  of string.subst is problematic,
 long strings with many matches will cause stack overflows.
Author: Peter De Wachter pdewa...@gmail.com
Bug-Debian: https://bugs.debian.org/750593

--- docbook-xsl-1.78.1+dfsg.orig/docbook-xsl/lib/lib.xsl
+++ docbook-xsl-1.78.1+dfsg/docbook-xsl/lib/lib.xsl
@@ -10,7 +10,10 @@
  This module implements DTD-independent functions
 
   --
-xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0
+xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
+xmlns:str=http://exslt.org/strings;
+exclude-result-prefixes=str
+version=1.0
 
 xsl:template name=dot.count
   !-- Returns the number of . characters in a string --
@@ -56,6 +59,9 @@
   xsl:param name=replacement/
 
   xsl:choose
+xsl:when test=function-available('str:replace')
+  xsl:value-of select=str:replace($string, string($target), string($replacement))/
+/xsl:when
 xsl:when test=contains($string, $target)
   xsl:variable name=rest
 xsl:call-template name=string.subst

Bug#750593: [Pkg-samba-maint] Bug#769242: Bug#769242: Bug#769242: samba: FTBFS in jessie/i386

[Jelmer Vernooij]

On Sat, Nov 15, 2014 at 09:51:49AM +0100, Ivo De Decker wrote:
 On Fri, Nov 14, 2014 at 01:53:00PM +0100, Jelmer Vernooij wrote:
  Ivo, are you sure that bug should be jessie-ignore?
 
 The release team decided to mark 750593 as jessie-ignore, because it doesn't
 seem likely that this can be fixed without invasive changes, while there is a
 workaround for the build failure in samba.
There is a patch attached to that bug by Peter De Wachter that is quite small
and doesn't appear to be too intrusive.

It would be good to get this fixed properly rather than with a workaround in
the Samba package, not in the least because a fixed docbook-xsl would allow
people to do Samba documentation work on jessie.

Cheers,

Jelmer


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

Bug#769259: golang-testify: FTBFS in jessie/i386: dh_auto_test: go test -v github.com/stretchr/testify github.com/stretchr/testify/assert github.com/stretchr/testify/http github.com/stretchr/testify/m

[Jelmer Vernooij]

Hi Lucas,

On Wed, Nov 12, 2014 at 11:46:23AM +0100, Lucas Nussbaum wrote:
 Source: golang-testify
 Version: 0.0~git20140717-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20141112 qa-ftbfs
 Justification: FTBFS in jessie on i386
 
 Hi,
 
 During a rebuild of all packages in jessie (in a jessie chroot, not a
 sid chroot), your package failed to build on i386.

Are you able to reproduce this locally? The buildds didn't have any problem 
with this
version of the package earlier, and I'm also having trouble reproducing it with
the current state of the archive.

Cheers,

Jelmer


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

Bug#750593: [Pkg-samba-maint] Bug#769242: Bug#769242: samba: FTBFS in jessie/i386

[Jelmer Vernooij]

On Wed, Nov 12, 2014 at 07:32:25PM +0100, Ivo De Decker wrote:
 Hi,
 
 On Wed, Nov 12, 2014 at 10:57:53AM +0100, Lucas Nussbaum wrote:
  During a rebuild of all packages in jessie (in a jessie chroot, not a
  sid chroot), your package failed to build on i386.
 
   rm: cannot remove 
   '/«BUILDDIR»/samba-4.1.13+dfsg/debian/tmp/usr/share/man/man1/vfstest.1': 
   No such file or directory
   make[1]: *** [override_dh_install] Error 1
 
 The problem is caused by this part of the waf configure:
 
 Checking for stylesheet 
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl : not 
 found
 
 I'm not sure what's causing it, but it happened a number of times on the
 buildds on different architectures.

This is caused by a bug in the docbook-xsl stylesheets, the same one
we were hitting elsewhere - http://bugs.debian.org/750593

Ivo, are you sure that bug should be jessie-ignore?

Jelmer


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

Bug#765473: Change defaults in testing/unstable?

[Jelmer Vernooij]

This bug is tagged squeeze and users can of course manually disable SSLv3 in 
newer
versions of Dovecot. We should also change the default value of ssl_protocols in
newer versions to be !SSLv2 !SSLv3 to protect them by default.

Suggested fix attached.

Jelmer
commit b074edee64fadc172c72fed62fbd664c9770a0d0
Author: Jelmer Vernooij jel...@debian.org
Date:   Sun Nov 9 16:33:11 2014 +

Disable SSLv3 by default because of CVE-2014-3566.

diff --git a/debian/dovecot-core.NEWS b/debian/dovecot-core.NEWS
index 62252f3..f4c478c 100644
--- a/debian/dovecot-core.NEWS
+++ b/debian/dovecot-core.NEWS
@@ -1,3 +1,14 @@
+dovecot (1:2.2.13-6) unstable; urgency=medium
+
+  The SSLv3 protocol is now disabled by default because of CVE-2014-3566.
+  To go back to the old default value for ssl protocols, set:
+
+ssl_protocols = !SSLv2
+
+  in /etc/dovecot/conf.d/10-ssl.conf
+
+ -- Jelmer Vernooij jel...@debian.org  Sun, 09 Nov 2014 16:35:45 +
+
 dovecot (1:2.1.7-7) unstable; urgency=high
 
   If you are upgrading from stable or the earlier 2.1.7 packages in testing,
diff --git a/debian/patches/series b/debian/patches/series
index 762771b..70adb7d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ exampledir.patch
 mboxlocking.patch
 dovecot_name.patch
 bye_logout_not_sent.patch
+sslv3-disable.patch
diff --git a/debian/patches/sslv3-disable.patch b/debian/patches/sslv3-disable.patch
new file mode 100644
index 000..c754693
--- /dev/null
+++ b/debian/patches/sslv3-disable.patch
@@ -0,0 +1,31 @@
+Author: Jelmer Vernooij jel...@debian.org
+Date: Sun 9 Nov 16:26:36 GMT 2014
+Description: Disable SSLv3 by default
+Bug-Debian: http://bugs.debian.org/765473
+
+diff --git a/doc/example-config/conf.d/10-ssl.conf b/doc/example-config/conf.d/10-ssl.conf
+index 7ae6b7a..e77667b 100644
+--- a/doc/example-config/conf.d/10-ssl.conf
 b/doc/example-config/conf.d/10-ssl.conf
+@@ -46,7 +46,7 @@ ssl_key = /etc/ssl/private/dovecot.pem
+ #ssl_dh_parameters_length = 1024
+ 
+ # SSL protocols to use
+-#ssl_protocols = !SSLv2
++#ssl_protocols = !SSLv2 !SSLv3
+ 
+ # SSL ciphers to use
+ #ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
+diff --git a/src/lib-master/master-service-ssl-settings.c b/src/lib-master/master-service-ssl-settings.c
+index e033e07..90beb8d 100644
+--- a/src/lib-master/master-service-ssl-settings.c
 b/src/lib-master/master-service-ssl-settings.c
+@@ -43,7 +43,7 @@ static const struct master_service_ssl_settings master_service_ssl_default_setti
+ 	.ssl_key = ,
+ 	.ssl_key_password = ,
+ 	.ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL,
+-	.ssl_protocols = !SSLv2,
++	.ssl_protocols = !SSLv2 !SSLv3,
+ 	.ssl_cert_username_field = commonName,
+ 	.ssl_crypto_device = ,
+ 	.ssl_verify_client_cert = FALSE,

Bug#760804: serf: FTBFS: Directory /usr/include/mit-krb5 found where file expected.

[Jelmer Vernooij]

On Thu, Oct 23, 2014 at 05:06:49PM -0400, Sam Hartman wrote:
 I actually think getting packages to build at high warning levels is a
 significant benefit to the distribution, and so I'm not really open to
 rolling back the change.
I agree.

 It's possible that we could accomplish this with a pragma in the header
 files.  I'm not sure I'd be comfortable taking that patch for Jessie,
 but if someone wanted to prepare a patch that used pragmas rather than
 -isystem I'd review that patch and apply if it was reasonable.
With James' patch for scons to properly handle -isystem I think this bug is 
resolved. As far as I can tell there's nothing blocking that from going in
for jessie.

Cheers,

Jelmer


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

Bug#750593: xsltproc: bus error on some architectures

[Jelmer Vernooij]

On Mon, Oct 06, 2014 at 11:05:57AM +0200, Nick Wellnhofer wrote:
 On Oct 6, 2014, at 06:21 , Jelmer Vernooij jel...@samba.org wrote:
 
  Nick, which bug in the GNOME bug tracker are you referring to?
 
 https://bugzilla.gnome.org/show_bug.cgi?id=736077
 
  Even if this is a bug in docbook-xsl, it would still be good if
  xsltproc printed an error rather than crashing - though perhaps that
  wouldn't need to be priority serious.
 
 It’s not that easy. Actually, it’s not really a bug in libxslt or docbook-xsl 
 but a memory issue (stack overflow). libxslt doesn’t optimize tail calls, so 
 recursive templates should be used with great care because after a couple of 
 hundred recursions, stack space runs out.
It can still find out the maximum allowed size of the stack and use that to 
e.g. set a reasonable default for --maxdepth.

 If you set the --maxdepth option of xsltproc to a value that’s low enough, 
 you’ll get an error message instead of a crash, but finding a suitable value 
 depends on stack size and the actual stylesheet.
While we can certainly do that, it's one more option we have to pass and keep 
up to date that is independent of our control. Anybody else hitting this issue 
will also not know about this option until they discover the cause.

Jelmer


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

Bug#750593: xsltproc: bus error on some architectures

[Jelmer Vernooij]

Nick, which bug in the GNOME bug tracker are you referring to?

Even if this is a bug in docbook-xsl, it would still be good if
xsltproc printed an error rather than crashing - though perhaps that
wouldn't need to be priority serious.


signature.asc
Description: Digital signature

Bug#760804: serf: FTBFS: Directory /usr/include/mit-krb5 found where file expected.

[Jelmer Vernooij]

On Mon, Sep 08, 2014 at 10:07:38PM -0700, Russ Allbery wrote:
 James McCoy james...@debian.org writes:
  On Tue, Sep 09, 2014 at 12:48:11AM -0400, Benjamin Kaduk wrote:
 
  krb5 has started supplying pkgconfig files in 1.12; would it be easier for
  serf to use gssapi.pc instead of parsing krb5-config's output?
 
  No, since the issue is the lack of understanding of the -isystem flag,
  which is still going to be emitted by pkg-config, twice in fact:
 
  $ pkg-config --cflags krb5-gssapi
  -isystem /usr/include/mit-krb5 -isystem /usr/include/mit-krb5
 
 I suspect Ben's hope was that, if using pkgconfig, scons would not make an
 attempt to parse the flags and split them apart, and would instead just
 use them as-is in the compiler invocation.
 
 I must say that I've come to consider build systems that think they know
 more than I do about what compiler flags mean to be a latent bug.  Libtool
 has had no ends of problems and irritating behavior because it likes to
 think that it knows what all the compiler and linker flags are and how to
 rearrange them.  Given that one of scons's goals was to be simpler and
 more predictable than the Autotools, it's unfortunate it fell into the
 same trap in this specific instance.  (That said, this is also partly
 pkgconfig's fault for not separating CFLAGS and CPPFLAGS.)

One workaround might be to include an equals sign in between
-isystem and the path to prevent scons from splitting it. gcc, tcc and clang all
seem happy with this.

I'll do some more tests this week to see if that works with serf.

Cheers,

Jelmer


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

Bug#760054: Introduced by python-configobj 5.0.6-1

[Jelmer Vernooij]

tags 760054 +confirmed
thanks

This regression is caused by a new version of python-configobj (5.0.6-1), which
has altered behaviour for non-ascii strings.

We should patch bzr rely on the new configobj behaviour, and then update its
dependencies to python-configobj = 5.0.6.

I don't think I'll have time for this in the next couple of weeks, and I've
actually been trying to step away from bzr maintenance for the last year or two
(and failing) so any help would be welcome.


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

Bug#759793: Fixed, but another issue has come up

[Jelmer Vernooij]

This has been fixed, but builds on the build hosts are still failing
because they have a custom policy that causes e.g. mysql to not start
after installation.

This breaks the openchange testsuite during build.

I'll have a look at this later this week.


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

Bug#759932: Actual fix available in upstream bzr

[Jelmer Vernooij]

On Tue, Sep 02, 2014 at 10:03:03PM -0300, dequis wrote:
 This is marked as fixed because it succeeded to build apparently, but
 i tested it and still fails for me (clean debian sid VM with systemd)
 
 There's an actual fix for this exact issue in upstream bzr, also
 included in the released 3.2.2
 
 http://bugs.bitlbee.org/bitlbee/changeset/devel,1022/devel/
 
 Diff link at the bottom

Yeah, I think we just need an upload of 3.2.2 (or release 3.2.3). :)

Jelmer

-- 
Jelmer Vernooij jel...@debian.org
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#755910: (no subject)

[Jelmer Vernooij]

I've uploaded a new version of bzr to unstable. It conflicts with paramiko 
1.14.1 only.

Jelmer


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

Bug#755910: [paramiko] TypeError: Expected unicode or bytes, got read-only buffer for 0x10fb7e120, size 5242880, offset 0 at 0x10fb79eb0 (#285)

[Jelmer Vernooij]

(CC: debian bugs)

On Mon, Aug 25, 2014 at 08:50:17AM -0700, Jeremy T. Bouse wrote:
 @hlieberman Even if I (the python-paramiko maintainer) get this patch 
 included and uploaded in a fixed version bzr will still conflict because the 
 bzr maintainer team decided to put a Conflicts: python-paramiko ( 1.12.0) 
 into the debian/control which doesn't help matters just exacerbates the 
 problem. I'm sitting here in the DC14 Hacklab working on packaging issues and 
 have discussed that move with several other DDs who think it was a poor move 
 on the part of the bzr team.  

This is a regression in paramiko, and this fix is a trivial and
non-risky change. Why can't this bug be fixed in the paramiko package
directly for the time being, why does it have to wait to be fixed in
upstream? I submitted a patch for this in June.

That would have allowed the bug to be fixed in a timely manner
without, preventing the removal of bzr and a lot of other packages
from testing without any intervention from us:

% apt-cache rdepends bzr python-bzrlib | grep -v | | uniq | wc -l
49

A Conflict was the quickest way in which I could unbreak bzr for its
users considering the paramiko Debian bug was stalled. I agree this is
not an ideal workaround - but I was hoping paramiko would soon be
fixed, after which I could remove the conflict.

An alternative workaround for me is to patch bzr to disable its paramiko
support if it finds a broken version of paramiko. If this paramiko
bug stays open for much longer then I'll see if I can do that instead.

If there's anything further I can do to help get this bug fixed in paramiko
(upstream or in Debian), please let me know.

Jelmer

-- 
Jelmer Vernooij jel...@samba.org - https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#755910: collides with python-bzrlib

[Jelmer Vernooij]

On Thu, Jul 31, 2014 at 11:38:55AM -0400, Jeremy T. Bouse wrote:
 tag +755910 wontfix
 thanks
 
 This bug report is useless to paramiko as the Conflict/Build-Conflict is in
 python-bzrlib which I have absolutely no control of and if the maintainer
 has decided this route than even when I upload a new version of paramiko
 that addresses the underlying issue which is already reported as #750517 and
 has been forwarded to the paramiko upstream python-bzrlib will still be
 uninstallable until it uploads a new version. I'm therefore tagging as
 wontfix and will be closing it unless you want to re-assign it to
 python-bzrlib.

There already is a bug open against bzr:
http://bugs.debian.org/752386

I'll remove the conflicts when bzr no longer breaks when newer
versions of paramiko are installed.

This regression in paramiko was causing a FTBFS (a RC bug) in bzr,
which would have caused it (and its two dozen build dependencies) to be removed
from testing mid-July.

Since there was no movement on the side of the paramiko package
(http://bugs.debian.org/750517) this seemed like the most sensible
thing to do in the short term.

Another alternative would have been to patch out paramiko support in
bzrlib until paramiko is fixed, but that would have been a much more
complex change.

Cheers,

Jelmer

 
 On 24.07.2014 09:15, Michael Biebl wrote:
 Package: python-paramiko
 Version: 1.14.0-2
 Severity: serious
 
 python-paramiko is no longer installable once bzr is installed, since
 the latest python-bzrlib has a Conflicts against python-paramiko = 1.12.
 
 The python-bzrlib changelog suggests that python-paramiko needs an
 update:
 
   * Conflict and build-conflict with newer versions of paramiko that no
 longer accept 'buffer' objects. This is a stop-gap until paramiko is
 fixed. Closes: #750347
 
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (200, 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages python-paramiko depends on:
 ii  python 2.7.8-1
 ii  python-crypto  2.6.1-5+b1
 ii  python-ecdsa   0.11-1
 
 python-paramiko recommends no packages.
 
 python-paramiko suggests no packages.
 
 -- no debconf information
 
 -- 
 To unsubscribe, send mail to 755910-unsubscr...@bugs.debian.org.

-- 
Jelmer Vernooij jel...@debian.org
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#482528: closed by Jelmer Vernooij jel...@debian.org (Bug#482528: fixed in heimdal 1.6~rc2+dfsg-7)

[Jelmer Vernooij]

On Thu, Jun 12, 2014 at 06:45:39PM +0200, Bastian Blank wrote:
 On Wed, Jun 11, 2014 at 10:24:51PM +0200, Jelmer Vernooij wrote:
  On Wed, Jun 11, 2014 at 09:50:51PM +0200, Bastian Blank wrote:
   kadmin is _not_ compatible, neither in the command-line interface nor in
   the protocol.
  See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213316 for the
  discussion leading up to this change.
 This is #482528, not #213316.  It asks for co-installability of kadmin,
 as this tool is specific to a particular implementation.  It is not
 needed, or better dangerous, for anything else.
This does make them coinstallable, and both runnable (kadmin.heimdal and
kadmin.mit).

  These binaries do provide similar functionality, even if their
  interface isn't compatible.
 
 Please show me that you can connect with a heimdal kadmin to a MIT
 kadmind.  This kind of compatible is needed.
Why is network-level compatibility the bar for similar functionality ?

  What is the justification for severity
  serious?
 
 Now it provides the same name for different CLI interfaces, which other
 packages already use.  Did you check each and every reverse-dependency
 of krb5-user if it still works with the different interface that heimdal
 provides?
Yes, I could not find any existing callers for Heimdal's kadmin. krb5-user
is not using alternatives yet. If there is something that requires the MIT
kadmin specifically, it can call out to kadmin.mit.

These tools are not just used by scripts. There are lots of alternatives on a
Debian system that don't have the exact same user interface. 

Cheers,

Jelmer


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

Bug#482528: closed by Jelmer Vernooij jel...@debian.org (Bug#482528: fixed in heimdal 1.6~rc2+dfsg-7)

[Jelmer Vernooij]

On Wed, Jun 11, 2014 at 09:50:51PM +0200, Bastian Blank wrote:
 Control: reopen -1
 Control: severity -1 serious
 
 On Wed, Jun 11, 2014 at 03:51:25AM +, Debian Bug Tracking System wrote:
 * Use alternatives for kpasswd, ksu, kdestroy, kswitch, kadmin and 
  ktutil.
   + Allows installation together with krb5-user. Closes: #482528
 
 kadmin is _not_ compatible, neither in the command-line interface nor in
 the protocol.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213316 for the
discussion leading up to this change.

These binaries do provide similar functionality, even if their
interface isn't compatible. What is the justification for severity
serious?

Cheers,

Jelmer

-- 
Jelmer Vernooij jel...@debian.org
Debian Developer   http://samba.org/~jelmer/


signature.asc
Description: Digital signature

Bug#750347: Regression in paramiko

[Jelmer Vernooij]

This is a regression in paramiko, caused by their effort to support
Python 3.

We can work around this in bzr if there is no other way, but that
likely has performance consequences - we'd have to materialize
every buffer as a bytestring before passing it in.


signature.asc
Description: Digital signature

Bug#748832: package does not work at all: Unable to load subvertpy extensions: cannot import name client

[Jelmer Vernooij]

tags 748832 +moreinfo
severity 748832 normal
thanks

Hi Martin,

On Wed, May 21, 2014 at 08:24:38AM +0200, Martin Pitt wrote:
 I was investigating current autopkgtest failures and I stumbled over
 http://ci.debian.net/#package/subvertpy which fails with
 
 File subvertpy/__init__.py, line 131, in module
   raise ImportError(Unable to load subvertpy extensions: %s % e)
   ImportError: Unable to load subvertpy extensions: cannot import name client
 
 Indeed the test is quite right: In a clean sid schroot, I tried:
 
   # apt-get install python-subvertpy
   # python -c 'import subvertpy'
   Traceback (most recent call last):
 File string, line 1, in module
 File subvertpy/__init__.py, line 131, in module
   raise ImportError(Unable to load subvertpy extensions: %s % e)
   ImportError: Unable to load subvertpy extensions: cannot import name client
 
 I get the same error with the one from the examples:
 
   python -c 'from subvertpy.ra import RemoteAccess'
 
 (Same on Ubuntu)
 
 So it looks to me that the current package is completely broken :-(
I can't reproduce this unless I run those commands from an unbuilt
source tree. This is true from from two of my own unstable/testing
systems as well as from a clean sid chroot.

If I run it in an unbuilt source tree (as retrieved by apt-get
source), I get the same error you get.

With the source tree built (make), it works again.

 BTW, if you do a new upload, would you mind dropping the unnecessary
 Restrictions: build-needed from debian/tests/control?
 python-subvertpy already ships the test suite, and even if you would
 run it from the source tree there's no need to build anything as you
 are testing the installed package.
You stumbled upon the reason I added it - without building (in place,
not in dist/) first, they fail.

Obviously this is a sign that we're testing the source tree binaries
rather than the installed binaries, which is not the intention of
debian/tests/. 

I really like the idea of autopkgtest but it's still a pain to run
these tests locally. For subvertpy we're just running the standard
testsuite - installed - that already runs as part of the build anyway,
so autopkgtest is just not worth the trouble at the moment for me.
I'll disable or remove the autopkgtests with the next upload.

Cheers,

Jelmer
-- 
Jelmer Vernooij jel...@debian.org
Debian Developer   http://samba.org/~jelmer/


signature.asc
Description: Digital signature

Bug#745683: heimdal: FTBFS on hppa -- check-iprop test fails

[Jelmer Vernooij]

On Thu, Apr 24, 2014 at 08:29:00AM -0400, John David Anglin wrote:
 On 23-Apr-14, at 9:07 PM, Jelmer Vernooij wrote:
 
 Can you provide the tests/kdc/test-suite.log file from the builder?
 
 It seems the failure is somewhat intermittent.  I had a successful build
 outside buildd last night.
 So, it looks like I will need to try grab the log from the chroot before it
 is purged.
Thanks! I'm guessing this is some sort of timing issue, but it would
help to know where exactly to start debugging.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#745683: heimdal: FTBFS on hppa -- check-iprop test fails

[Jelmer Vernooij]

On Wed, Apr 23, 2014 at 08:25:23PM -0400, John David Anglin wrote:
 Justification: fails to build from source (but built successfully in the past)
 
 Since 1.6~rc2+dfsg-3, heimdal fails to build on hppa:
 http://buildd.debian-ports.org/status/fetch.php?pkg=heimdalarch=hppaver=1.6%7Erc2%2Bdfsg-3stamp=1398141349
 
 The check-iprop test fails causing build to fail.
 
 Same error also seems to occur on ppc64.
Can you provide the tests/kdc/test-suite.log file from the builder?

Thanks,

Jelmer


signature.asc
Description: Digital signature

Bug#742770: extprograms not installed in correct directory

[Jelmer Vernooij]

severity 742770 important
tags 742770 +confirmed
thanks

This is happening because the sieve_plugins setting is used, which
causes the sieve plugin to look for plugins in
/usr/lib/dovecot/modules/sieve.


signature.asc
Description: Digital signature

Bug#737890: Tries to lookup 'localhost'

[Jelmer Vernooij]

Hello,

This test is relying on the fact that the local system knows the ip
address for 'localhost'. Is there not even a /etc/hosts file and
loopback device on these machines?

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#737111: [Pkg-samba-maint] Bug#737111: Update

[Jelmer Vernooij]

severity -1 normal
thanks

On Thu, Jan 30, 2014 at 12:17:43PM +0100, Lorin Weilenmann wrote:
 I just noticed that it must have something to do with my old smb.conf.
 Although I did not change it and it used to run in older versions of
 samba4, samba works fine with the default config.
If this is reproducible, can you post a gdb backtrace of this crash?

Thanks!

Jelmer


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

Bug#737111: Same bug?

[Jelmer Vernooij]

Hi Adrien,

That looks like a fairly generic backtrace, not related to the crash
Lorin posted. I don't think it's related to this bug report.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#736405: marked as pending

[Jelmer Vernooij]

tag 736405 pending
thanks

Hello,

Bug #736405 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=254639d

---
commit 254639dd4bd2fd52a15faa49f127996470fcac34
Author: Jelmer Vernooij jel...@samba.org
Date:   Fri Jan 24 23:43:37 2014 +

Move samba.dckeytab module to samba package, as it relies on hdb. Closes: 
#736405, #736430

diff --git a/debian/changelog b/debian/changelog
index 2047a00..e93b141 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+samba (2:4.1.4+dfsg-3) UNRELEASED; urgency=medium
+
+  * Move samba.dckeytab module to samba package, as it relies on hdb.
+Closes: #736405, #736430
+
+ -- Jelmer Vernooij jel...@debian.org  Fri, 24 Jan 2014 23:35:14 +
+
 samba (2:4.1.4+dfsg-2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]


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

Bug#736430: marked as pending

[Jelmer Vernooij]

tag 736430 pending
thanks

Hello,

Bug #736430 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=254639d

---
commit 254639dd4bd2fd52a15faa49f127996470fcac34
Author: Jelmer Vernooij jel...@samba.org
Date:   Fri Jan 24 23:43:37 2014 +

Move samba.dckeytab module to samba package, as it relies on hdb. Closes: 
#736405, #736430

diff --git a/debian/changelog b/debian/changelog
index 2047a00..e93b141 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+samba (2:4.1.4+dfsg-3) UNRELEASED; urgency=medium
+
+  * Move samba.dckeytab module to samba package, as it relies on hdb.
+Closes: #736405, #736430
+
+ -- Jelmer Vernooij jel...@debian.org  Fri, 24 Jan 2014 23:35:14 +
+
 samba (2:4.1.4+dfsg-2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]


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

Bug#732342: marked as pending

[Jelmer Vernooij]

tag 732342 pending
thanks

Hello,

Bug #732342 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=5b2ba2b

---
commit 5b2ba2b989354334f6b8343dc2a512836c2e74a2
Author: Jelmer Vernooij jel...@samba.org
Date:   Sun Jan 19 17:16:29 2014 +

* Fix compatibility with newer versions of the Heimdal HDB API.
  + Update 26_heimdal_compat: Fix initialization of HDB plugin. Thanks Jeff
Clark. Closes: #732342
  + Add dependency on specific version of the Heimdal HDB API.
Closes: #732344

diff --git a/debian/changelog b/debian/changelog
index 3602774..f19f4b2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,11 @@ samba (2:4.1.4+dfsg-2) UNRELEASED; urgency=medium
   * Bump standards version to 3.9.5 (no changes).
   * Move libpac, db_glue and hdb module from samba-libs to samba package
 to reduce size and dependency set of libs package.
+  * Fix compatibility with newer versions of the Heimdal HDB API.
++ Update 26_heimdal_compat: Fix initialization of HDB plugin. Thanks Jeff
+  Clark. Closes: #732342
++ Add dependency on specific version of the Heimdal HDB API.
+  Closes: #732344
 
  -- Jelmer Vernooij jel...@debian.org  Sat, 18 Jan 2014 20:26:35 +
 


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

Bug#732344: marked as pending

[Jelmer Vernooij]

tag 732344 pending
thanks

Hello,

Bug #732344 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=5b2ba2b

---
commit 5b2ba2b989354334f6b8343dc2a512836c2e74a2
Author: Jelmer Vernooij jel...@samba.org
Date:   Sun Jan 19 17:16:29 2014 +

* Fix compatibility with newer versions of the Heimdal HDB API.
  + Update 26_heimdal_compat: Fix initialization of HDB plugin. Thanks Jeff
Clark. Closes: #732342
  + Add dependency on specific version of the Heimdal HDB API.
Closes: #732344

diff --git a/debian/changelog b/debian/changelog
index 3602774..f19f4b2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,11 @@ samba (2:4.1.4+dfsg-2) UNRELEASED; urgency=medium
   * Bump standards version to 3.9.5 (no changes).
   * Move libpac, db_glue and hdb module from samba-libs to samba package
 to reduce size and dependency set of libs package.
+  * Fix compatibility with newer versions of the Heimdal HDB API.
++ Update 26_heimdal_compat: Fix initialization of HDB plugin. Thanks Jeff
+  Clark. Closes: #732342
++ Add dependency on specific version of the Heimdal HDB API.
+  Closes: #732344
 
  -- Jelmer Vernooij jel...@debian.org  Sat, 18 Jan 2014 20:26:35 +
 


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

Bug#730011: Set random master key on empty password?

[Jelmer Vernooij]

So, the underlying issue is that we're trying to set an empty master
key - which doesn't really make sense anyway.

There are two solutions I can think of; either we can just skip calling
kstash at all here, or we can generate a random key.

The latter seems like a better idea, since it means we won't be
setting an empty key by default (the priority for the
heimdal-kdc/password question is medium).

Does that seem reasonable?

Jelmer
commit e5927d013dc5a156f9e24858ad8f5714ab9b5b60
Author: Jelmer Vernooij jel...@samba.org
Date:   Sun Dec 1 13:53:40 2013 +

Set random master key if no explicit password was specified. Closes: #730011

diff --git a/debian/changelog b/debian/changelog
index 0d4e176..9b0f851 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,8 @@ heimdal (1.6~git20131117+dfsg-3) UNRELEASED; urgency=low
 to prevent conflicts with libkrb5-multidev. Closes: #730267
   * Rename login.1 to login.heimdal.1 to support installing together
 with login. Closes: #729946
+  * Set random master key if no explicit password was specified. Closes:
+#730011
 
  -- Jelmer Vernooij jel...@debian.org  Sun, 24 Nov 2013 14:59:33 +
 
diff --git a/debian/heimdal-kdc.postinst b/debian/heimdal-kdc.postinst
index 5e66361..335da42 100644
--- a/debian/heimdal-kdc.postinst
+++ b/debian/heimdal-kdc.postinst
@@ -70,9 +70,13 @@ then
 DST=/etc/heimdal-kdc/kadmind.acl
 cp -a /usr/share/heimdal-kdc/kadmind.acl $DST
 
-kstash --master-key-fd=0 EOF
+if [ -z $PASSWORD ]; then
+kstash --random-key
+else
+kstash --master-key-fd=0 EOF
 $PASSWORD
 EOF
+fi
 
 kadmin  -l init --realm-max-ticket-life=unlimited --realm-max-renewable-life=unlimited $REALM
 


signature.asc
Description: Digital signature

Bug#730011: Set random master key on empty password?

[Jelmer Vernooij]

On Mon, Dec 02, 2013 at 11:24:17AM +1100, Brian May wrote:
 On 2 December 2013 00:58, Jelmer Vernooij jel...@samba.org wrote:
 
  So, the underlying issue is that we're trying to set an empty master
  key - which doesn't really make sense anyway.
 I would argue it shouldn't crash, it should come up with a reasonable
 error. Not to mention, I think this use to work.
I agree kstash shouldn't crash on an empty password - I've filed an
upstream bug report about that. That's orthogonal though - even if
that would work, setting an empty master key password is suboptimal.

  There are two solutions I can think of; either we can just skip calling
  kstash at all here, or we can generate a random key.
 
  The latter seems like a better idea, since it means we won't be
  setting an empty key by default (the priority for the
  heimdal-kdc/password question is medium).
 Yes, that seems reasonable to me.
Okay, I'll upload a fix to unstable with that.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#730011: Set random master key on empty password?

[Jelmer Vernooij]

On Mon, Dec 02, 2013 at 12:52:31PM +1100, Brian May wrote:
 On 2 December 2013 12:31, Russ Allbery r...@debian.org wrote:
 
  It's never been clear to me why you would ever care to have a known master
  key password, as opposed to just using kstash --random-key.  The only
  reason I can think of would be to recover the Kerberos KDC database when
  you have a copy of the database but not the master key, but I'm not sure
  why you would be in that state.  It's just as easy to back up the master
  key file along with the database.
 
 
 Yes, agreed. It seemed a good idea at the time...
 
 Maybe --random-key wasn't available when I initially wrote that stuff. Or
 maybe I just didn't know about it.

I can't think of a good reason either; I figured that since the question
was there, there would probably be a reason for it. Perhaps it's time
to downgrade the priority of the password question to low ?

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#730011: Empty password

[Jelmer Vernooij]

It seems like this is triggered by any empty password specified to
kstash.


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

Bug#730011: Problem with debconf?

[Jelmer Vernooij]

This appears to be happening in the debconf frontend.

# /usr/share/debconf/frontend /var/lib/dpkg/info/heimdal-kdc.postinst install 
1.6~git20131117+dfsg-3
Floating point exception


signature.asc
Description: Digital signature

Bug#730011: Problem with debconf?

[Jelmer Vernooij]

On Mon, Nov 25, 2013 at 09:20:04AM +1100, Brian May wrote:
 On 25 November 2013 02:37, Jelmer Vernooij jel...@samba.org wrote:
 
  This appears to be happening in the debconf frontend.
 
  # /usr/share/debconf/frontend /var/lib/dpkg/info/heimdal-kdc.postinst
  install 1.6~git20131117+dfsg-3
  Floating point exception
 
 
 Does:
 
 export DEBCONF_DEBUG=developer
 /usr/share/debconf/frontend /var/lib/dpkg/info/heimdal-kdc.postinst install
 1.6~git20131117+dfsg-3
 
 show anything?

debconf (developer): frontend started
debconf (developer): frontend running, package name is heimdal-kdc
debconf (developer): starting /var/lib/dpkg/info/heimdal-kdc.config configure 
debconf (developer): -- TITLE Heimdal KDC
debconf (developer): -- 0
debconf (developer): -- GET krb5-config/default_realm
debconf (developer): -- 0 REALM.NL
debconf (developer): -- FGET heimdal/realm seen
debconf (developer): -- 0 false
debconf (developer): -- SET heimdal/realm REALM.NL
debconf (developer): -- 0 value set
debconf (developer): -- SUBST heimdal/realm default_realm REALM.NL
debconf (developer): -- 0
debconf (developer): -- INPUT medium heimdal/realm
debconf (developer): -- 30 question skipped
debconf (developer): -- GO 
debconf (developer): -- 0 ok
debconf (developer): -- INPUT medium heimdal-kdc/password
debconf (developer): -- 30 question skipped
debconf (developer): -- GO 
debconf (developer): -- 0 ok
debconf (developer): starting /var/lib/dpkg/info/heimdal-kdc.postinst
configure 
debconf (developer): -- GET heimdal/realm
debconf (developer): -- 0 REALM.NL
debconf (developer): -- GET heimdal-kdc/password
debconf (developer): -- 0 
debconf (developer): -- SET heimdal-kdc/password 
debconf (developer): -- 0 value set
Floating point exception

Jelmer


signature.asc
Description: Digital signature

Bug#730267: libkrb5-dev: file conflict with heimdal-multidev: /usr/lib/x86_64-linux-gnu/pkgconfig/k{adm, rb5}*.pc

[Jelmer Vernooij]

On Sun, Nov 24, 2013 at 10:44:23PM -0500, Sam Hartman wrote:
 I assume we're agreed that the -multidev packages should not conflict
 with the libkrb5-dev or heimdal-dev packages.
 That is, you can have both multidevv packages and one of the lib*-dev
 packages installed?

 So it's fine to have some mit-specific .*pc files in krb5-multidev, and
 some heimdal-specific in heimdal-multidev, but not to have generic *.pc
 files in either of the multidevs?
Yep, exactly.


signature.asc
Description: Digital signature

Bug#730267: libkrb5-dev: file conflict with heimdal-multidev: /usr/lib/x86_64-linux-gnu/pkgconfig/k{adm, rb5}*.pc

[Jelmer Vernooij]

Symlinks make sense I think. I'll have a look at fixing this in Heimdal.

Jelmer


signature.asc
Description: Digital signature

Bug#726472: [Pkg-samba-maint] Bug#726472: share passwords not working after upgrade from samba3

[Jelmer Vernooij]

On Mon, Oct 28, 2013 at 10:00:12PM +0100, Ivo De Decker wrote:
 Hi,
 
 On Mon, Oct 21, 2013 at 10:37:49PM +1300, Andrew Bartlett wrote:
   Ok.  I think we need to undo this /var/lib/samba/private nonsense.  It is 
   a
   pointless and imperfect migration (as shown by this bug report), and the
   only rationale upstream ever gave for keeping these files in a separate
   private directory is some stupid and ancient target OS that couldn't
   properly set per-file permissions.  Debian users have been using
   /var/lib/samba exclusively for the better part of a decade; migrating to
   this private/ directory adds no value for our users.
  
  In the alternate, the only reason this happened now is because we are
  finally having the Debian packages follow where upstream has decided to
  put the files.  Having different packages moving files around to
  different places only increases user confusion, and creates 'only on
  Debian' bugs.  
  
  For example, a significant number of issues came about as folks tried to
  divine if a particular TDB was short, medium or long-term, when no such
  separation existed in the code. 
  
  We (upstream) have gone to significant effort to integrate the FHS
  changes that have been proposed via Debian, I can only ask that having
  got to a mutually agreed state, that Debian not change it again, having
  once more Debian packages special and different. 
 
 I had a long talk with Jelmer yesterday about this bug. Here are a number of
 considerations from that discussion:
 
 
 First of all, it certainly isn't clear that the issue is caused by a mistake
 in unstable some time ago. I haven't been able to find any indication for that
 (yet) in any of the samba versions available on snapshot.debian.org. We've
 been using /etc/samba as private dir from the first 3.2 upload to the last 3.6
 upload and there is no apparent usage of /var/lib/samba/private anywhere in
 the code of any of these versions.
 
 It is quite possible that the issue is triggered by a race condition in the
 tdb-handling (especially for passdb.tdb), which can result in the creation of
 the wrong tdb file during the upgrade, which messes up our move. This could be
 caused by the usage of the 'smbpasswd' command or the pam-smbpass pam module.
 I haven't had the time yet to create a situation where I can trigger the race
 condition.
 
 There are a number of ways to work around these possible race conditions
 during at the time of the move. An incomplete list of ideas (some of these
 would have to be combined to get to a complete fix):
 
 - Patch the passdb tdb module to do the move, instead of having it in
   samba.postinst. This isn't completely unprecedented, as the move of
   MACHINE.SID was supported by the samba code.
 
 - Track the fact that the move was done, by adding some field to the new tdb
   file. This might cause issues in tools that don't handle unknown fields. The
   samba4 upgrade script might be one of those.
 
 - Track the fact that the move was done, by making sure the old tdb can't be
   used anymore. This could be done by changing the version number of the old
   tdb to something non-existent.
 
 - Do some kind of merge of both tdb files, if they both exist.
 
 - When both tdb files exist, have a debconf question that gives some
   information about both (eg number of users), and ask the user to choose
   between them.
 
 Any decent implementation will require some careful planning and probably
 quite some discussion as well. It is clear that the new samba 4.x packages
 provide a nice step forward compared to the samba 3.6 packages, and these
 changes shouldn't be blocked by this problem. Therefore we are proposing to
 postpone this move for now.
 
 Moving the private dir to /var/lib/samba would cause an issue with the files
 kept by samba4 in /var/lib/samba/private. So the only obvious way forward
 would be to have a new version of our previous patch, which moves the 4
 affected files back to /var/lib/samba. I really regret having to propose this,
 as I very much would like to avoid reintroducing a patch like that, but at
 this point, I don't really see any other short term options.

 So the proposal is to reintroduce something like the old patch, and try to get
 that version into shape for testing/jessie. After that, we can figure out how
 to get this move done the right way.

An alternative solution might be to just move those four files that
already existed back in 3.x back from privatedir to sysstatedir and
to not revert the entire move to privatedir.

That'll also cause some confusion though, as those files will be in
sysstatedir on debian but in privatedir on other systems...

Cheers,

Jelmer


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

Bug#726472: share passwords not working after upgrade from samba3

[Jelmer Vernooij]

On Tue, Oct 29, 2013 at 10:10:58AM +1300, Andrew Bartlett wrote:
 On Mon, 2013-10-28 at 22:00 +0100, Ivo De Decker wrote:
  Hi,
  
  On Mon, Oct 21, 2013 at 10:37:49PM +1300, Andrew Bartlett wrote:
Ok.  I think we need to undo this /var/lib/samba/private nonsense.  It 
is a
pointless and imperfect migration (as shown by this bug report), and the
only rationale upstream ever gave for keeping these files in a separate
private directory is some stupid and ancient target OS that couldn't
properly set per-file permissions.  Debian users have been using
/var/lib/samba exclusively for the better part of a decade; migrating to
this private/ directory adds no value for our users.
   
   In the alternate, the only reason this happened now is because we are
   finally having the Debian packages follow where upstream has decided to
   put the files.  Having different packages moving files around to
   different places only increases user confusion, and creates 'only on
   Debian' bugs.  
   
   For example, a significant number of issues came about as folks tried to
   divine if a particular TDB was short, medium or long-term, when no such
   separation existed in the code. 
   
   We (upstream) have gone to significant effort to integrate the FHS
   changes that have been proposed via Debian, I can only ask that having
   got to a mutually agreed state, that Debian not change it again, having
   once more Debian packages special and different. 
  
  I had a long talk with Jelmer yesterday about this bug. Here are a number of
  considerations from that discussion:
  
  
  First of all, it certainly isn't clear that the issue is caused by a mistake
  in unstable some time ago. I haven't been able to find any indication for 
  that
  (yet) in any of the samba versions available on snapshot.debian.org. We've
  been using /etc/samba as private dir from the first 3.2 upload to the last 
  3.6
  upload and there is no apparent usage of /var/lib/samba/private anywhere in
  the code of any of these versions.
  
  It is quite possible that the issue is triggered by a race condition in the
  tdb-handling (especially for passdb.tdb), which can result in the creation 
  of
  the wrong tdb file during the upgrade, which messes up our move. This could 
  be
  caused by the usage of the 'smbpasswd' command or the pam-smbpass pam 
  module.
  I haven't had the time yet to create a situation where I can trigger the 
  race
  condition.
  
  There are a number of ways to work around these possible race conditions
  during at the time of the move. An incomplete list of ideas (some of these
  would have to be combined to get to a complete fix):
  
  - Patch the passdb tdb module to do the move, instead of having it in
samba.postinst. This isn't completely unprecedented, as the move of
MACHINE.SID was supported by the samba code.
  
  - Track the fact that the move was done, by adding some field to the new tdb
file. This might cause issues in tools that don't handle unknown fields. 
  The
samba4 upgrade script might be one of those.
  
  - Track the fact that the move was done, by making sure the old tdb can't be
used anymore. This could be done by changing the version number of the old
tdb to something non-existent.
  
  - Do some kind of merge of both tdb files, if they both exist.
  
  - When both tdb files exist, have a debconf question that gives some
information about both (eg number of users), and ask the user to choose
between them.
  
  Any decent implementation will require some careful planning and probably
  quite some discussion as well. It is clear that the new samba 4.x packages
  provide a nice step forward compared to the samba 3.6 packages, and these
  changes shouldn't be blocked by this problem. Therefore we are proposing to
  postpone this move for now.
  
  Moving the private dir to /var/lib/samba would cause an issue with the files
  kept by samba4 in /var/lib/samba/private. So the only obvious way forward
  would be to have a new version of our previous patch, which moves the 4
  affected files back to /var/lib/samba. I really regret having to propose 
  this,
  as I very much would like to avoid reintroducing a patch like that, but at
  this point, I don't really see any other short term options.
  
  So the proposal is to reintroduce something like the old patch, and try to 
  get
  that version into shape for testing/jessie. After that, we can figure out 
  how
  to get this move done the right way.
  
  Any thoughts, comments?
  
   Or in the alternate, propose such changes upstream. 
  
  Moving the files upstream would inflict all this pain on other 
  distributions,
  so someone would still have to sort this all out.
 
 I strongly oppose both proposals.  The upgrade to Samba 4.0 is the time
 to correct this silly business of having files in different paths to
 what upstream has, rightly or wrongly, chosen.  

What approach would you suggest for 

Bug#725592: [Pkg-bazaar-maint] Bug#725592: bzr-git: FTBFS: Tests failed

[Jelmer Vernooij]

On Sun, Oct 06, 2013 at 08:09:34PM +0200, David Su??rez wrote:
 Source: bzr-git
 Version: 0.6.12-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20131006 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part (hopefully):
  ==
  ERROR: 
  bzrlib.plugins.git.tests.test_pristine_tar.ReadPristineTarData.test_read_pristine_tar_data
  --
  _StringException: Empty attachments:
log
  
  Traceback (most recent call last):
File /?PKGBUILDDIR?/tests/test_pristine_tar.py, line 84, in 
  test_read_pristine_tar_data
  ref='refs/heads/pristine-tar')
File /usr/lib/python2.7/dist-packages/dulwich/repo.py, line 1208, in 
  do_commit
  committer = self._get_user_identity()
File /usr/lib/python2.7/dist-packages/dulwich/repo.py, line 1162, in 
  _get_user_identity
  config.get((user, ), name),
File /usr/lib/python2.7/dist-packages/dulwich/config.py, line 354, in 
  get
  raise KeyError(name)
  KeyError: 'name'

Urgh, I think this might be a regression. Didn't we fix this previously?

Cheers,

Jelmer


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

Bug#719681: [Pkg-samba-maint] Bug#719681: Bug#719681: libsamdb0: uninstallable in sid: Depends: libldb1 ( 1:1.1.7~) but 1:1.1.16-1 is to be installed

[Jelmer Vernooij]

On Sun, Sep 08, 2013 at 02:28:53AM +0200, Michael Biebl wrote:
 Hi,
 
 On Wed, Aug 14, 2013 at 10:06:27PM +, Jelmer Vernooij wrote:
  Since the package is no longer installable anyway, I wonder if it
  would make sense to remove the samba4 package from sid. Would anybody
  object if I asked for its removal?
 
 I'm currently preparting the evolution/evolution-data-server 3.8
 transition.
 One of the rdeps is evolution-mapi, which build-depends on samba4-dev.
 Would be great having a working/installable samba4 package, so we can
 actually build evolution-mapi.
 Otherwise the only alternative I see for evolution-mapi is to remove it
 from testing when starting the transition

When would you like to do the actual uploads? I'd rather focus on
fixing the samba package than trying to patch up the broken and outdated
samba4 package.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#719681: [Pkg-samba-maint] Bug#719681: Bug#719681: Bug#719681: libsamdb0: uninstallable in sid: Depends: libldb1 ( 1:1.1.7~) but 1:1.1.16-1 is to be installed

[Jelmer Vernooij]

On Sun, Sep 08, 2013 at 09:53:27PM +0200, Michael Biebl wrote:
 Hi,
 
 Am 08.09.2013 15:56, schrieb Jelmer Vernooij:
  On Sun, Sep 08, 2013 at 02:28:53AM +0200, Michael Biebl wrote:
 
  When would you like to do the actual uploads?
 
 As soon as somehow possible. I think the transition is ready and I'd
 like to proceed with the upload within a matter of days, not weeks
 (still pending an ack from the RT, though).
 If you think it's too much work to fix up samba4 in unstable, then I'll
 just request the (temporary) removal of evo-mapi from testing.
I think that would be better for the moment.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#719681: [Pkg-samba-maint] Bug#719681: Bug#719681: libsamdb0: uninstallable in sid: Depends: libldb1 ( 1:1.1.7~) but 1:1.1.16-1 is to be installed

[Jelmer Vernooij]

On Thu, Aug 15, 2013 at 12:00:54AM +0200, Ivo De Decker wrote:
 Control: tags -1 wontfix
 
 Hi Andreas,
 
 On Wed, Aug 14, 2013 at 11:00:09AM +0200, Andreas Beckmann wrote:
  during a test with piuparts I noticed your package is no longer
  installable in sid:
  
The following packages have unmet dependencies:
 libsamdb0 : Depends: libldb1 ( 1:1.1.7~) but 1:1.1.16-1 is to be 
  installed
E: Unable to correct problems, you have held broken packages.
  
  While a binNMU should be sufficient to fix up the dependency, this
  cannot be done due to the FTBFS #713097
 
 The samba4 source package will go away, as it will be merged into the
 (re)unified samba package (which is version 4.x). As this bug is about the old
 samba4 source package in sid, I'm tagging it as wontfix.
 
 There are, however, a number of remaining issues with the samba package
 currently in experimental, which is why the new version is not in unstable
 yet.
Since the package is no longer installable anyway, I wonder if it
would make sense to remove the samba4 package from sid. Would anybody
object if I asked for its removal?

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#719261: [Pkg-bazaar-maint] Bug#719261: bzr-git: FTBFS in sid pbuilder with test failures

[Jelmer Vernooij]

On Tue, Aug 13, 2013 at 10:07:34PM -0400, Andrew Starr-Bochicchio wrote:
 On Fri, Aug 9, 2013 at 4:05 PM, Jelmer Vernooij jel...@debian.org wrote:
  This is FTBFS for me in a sid [amd64] pbuilder. Full log attached.
  I'm having trouble reproducing this outside of a pbuilder. The
  breakage might depend on the fact that there is no .gitconfig in your
  build chroot.
 
  It shouldn't be too hard to fix I think, but I'm not planning to work
  on this bug.
 
 Totally understandable. If I could get some advice though, I'd greatly
 appreciate it.
 
 Passing a committer and an author to the two tests that call do_commit
 (from dulwich) directly fixes the problem. The third failing commit
 calls store_git_pristine_tar_data (from bzr-git). I don't see a way to
 fix this without adding a committer and/or an author parameter to the
 function. That would be simple enough it seems, as it is a wrapper
 around do_commit. Does that sound like the right approach, or am I
 missing something in my cursory look at the code?
Sure, that sounds quite reasonable.

Note that while this is the most pressing issue breaking
bzr-git at the moment, there are a couple of other problems that will
need addressing for it to actually be usable in the long wrong. In
particular, without signed tag and mergetag support it won't be usable
on repositories with tags in the future.

It's probably possible to patch it up in the short run, but it really
needs a long term maintainer to take over.

Cheers,

Jelmer



signature.asc
Description: Digital signature

Bug#719261: [Pkg-bazaar-maint] Bug#719261: bzr-git: FTBFS in sid pbuilder with test failures

[Jelmer Vernooij]

On Fri, Aug 09, 2013 at 02:45:39PM -0400, Andrew Starr-Bochicchio wrote:
 Package: bzr-git
 Version: 0.6.11-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 This is FTBFS for me in a sid [amd64] pbuilder. Full log attached.
I'm having trouble reproducing this outside of a pbuilder. The
breakage might depend on the fact that there is no .gitconfig in your
build chroot.

It shouldn't be too hard to fix I think, but I'm not planning to work
on this bug.

Cheers,

Jelmer


signature.asc
Description: Digital signature

Bug#710911: bzr: init-repo fails: ImportError: cannot import name CommittedQueue

[Jelmer Vernooij]

reassign 710911 bzr-svn
thanks

What version of bzr-svn are you using?

On Mon, Jun 03, 2013 at 03:21:16PM +0200, Thorsten Glaser wrote:
 Package: bzr
 Version: 2.6.0~bzr6574-1
 Severity: serious
 Justification: cannot use the package at all, like that
 
 I just tried to clone an svn repo (URI changed):
 
 tglase@tglase:~ $ bzr co svn+ssh://r...@foo.tarent.de/scmrepos/svn/foo/trunk
 Initialising Subversion metadata cache in 
 /home/tglase/.bazaar/svn-cache/----.
 bzr: broken pipe
This is a bug in bzr-svn no longer working with newer versions of subvertpy 
(because of API changes in svn  1.7).
bzr-svn has been removed from the archive, partially for this reason.

Jelmer


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

Bug#710911: bzr: init-repo fails: ImportError: cannot import name CommittedQueue

[Jelmer Vernooij]

On Mon, Jun 03, 2013 at 04:31:54PM +, Thorsten Glaser wrote:
 Jelmer Vernooij dixit:
 What version of bzr-svn are you using?
 See below.
 
 This is a bug in bzr-svn no longer working with newer versions of
 subvertpy (because of API changes in svn  1.7). bzr-svn has been
 removed from the archive, partially for this reason.
 
 ??? oh.
 
 bzr-svn:
   Installed: 1.2.1-1
   Candidate: 1.2.1-1
   Version table:
  *** 1.2.1-1 0
 100 /var/lib/dpkg/status
 
 Indeed. I see.
 
 Okay, nothing one can do, then??? I worked around by using a
 chroot with an older version.

Another workaround might be to install an older version of subvertpy and an
older version of libsvn1.

Cheers,

Jelmer


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

Bug#709326: Uses removed .get_ancestry()

[Jelmer Vernooij]

Package: trac-bzr
Severity: serious

trac-bzr still uses Repository.get_ancestry(), which has been removed from
newer versions of bzr. This means it can not be used with the bzr that is
currently in unstable.

-- 


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

Bug#696149: [Pkg-samba-maint] Bug#696149: samba4: deletes directories owned by samba-common during purge: /var/{cache, lib, log}/samba

[Jelmer Vernooij]

Hi Ivo,

On Sun, 2012-12-23 at 21:21 +0100, Ivo De Decker wrote:
 Hi Jelmer,
 
 On Mon, Dec 17, 2012 at 11:45:48AM +0100, Andreas Beckmann wrote:
  From the attached log (scroll to the bottom...):
  
  0m48.7s ERROR: FAIL: After purging files have disappeared:
/var/cache/samba/  owned by: samba4-common-bin, samba-common
/var/lib/samba/owned by: samba4, samba-common
/var/log/samba/owned by: samba-common
  
  In this test only the samba4 package was purged, all dependencies are
  still installed.
  
  samba4.postrm purge performs:
  
  # Remove Samba's state files, both volatile and non-volatile
  rm -Rf /var/run/samba/ /var/cache/samba/ /var/lib/samba
  
  # Remove log files
  rm -Rf /var/log/samba/
  
  (the debconf db_purge is run twice, there is no need to add this
  manually to the maintainer script as dh_installdebconf already adds it)
 
 I had a look at the samba4 package in wheezy, and tried to solve this bug by
 limiting the removal to files that are created by samba4 (not by other
 samba related packages).
 
 A patch that implements this is attached. With this patch, samba4 doesn't hit
 the piuparts issues listed above.
Thanks!

 However, I encountered 2 issues:
 
 - samba4 logs to /var/log/samba/log.%m
 
 The removal of this file is easy to solve, but I can't imagine the name of
 this logfile is intentional. Obviously this is the result of changes in samba4
 (it seems %m is sadly no longer allowed in logfile names).
I would argue that this is in fact a bug in samba-common; we'll have
this problem as well when we merge the samba and samba4 source packages.
Please file a bug about this.

 - the piuparts log also complains about:
   0m48.7s ERROR: FAIL: After purging files have been modified:
 /etc/samba/smb.confnot owned
 
 Samba4 changes smb.conf (adds 2 parameters and 2 shares), but smb.conf is
 owned by samba-common, not by samba4. Maybe this should be solved in
 samba-common by allowing other packages to add config files (this is more or
 less what was asked in #675906).
I guess purge should ideally remove these 2 parameters again; they are
only used by Samba 4. I'm not entirely sure about the shares.

That said, this problem will go away when we merge the samba and samba4
source packages so I'm not sure if it is worth spending much time on,
unless it is for wheezy.

Cheers,

Jelmer


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

Bug#695710: adplug: diff for NMU version 2.2.1+dfsg2-1.1

[Jelmer Vernooij]

tags 695710 + patch
tags 695710 + pending
thanks

Dear maintainer,

I've prepared an NMU for adplug (versioned as 2.2.1+dfsg2-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru adplug-2.2.1+dfsg1/debian/changelog adplug-2.2.1+dfsg2/debian/changelog
--- adplug-2.2.1+dfsg1/debian/changelog	2011-05-25 17:37:59.0 +0200
+++ adplug-2.2.1+dfsg2/debian/changelog	2012-12-16 14:31:32.0 +0100
@@ -1,3 +1,13 @@
+adplug (2.2.1+dfsg2-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Repack upstream tarball to exclude GFDL documentation 
+(doc/{fdl.texi,libadplug.texi,libadplug.info} with
+unmodifiable sections. Closes: #695710
+   + Add 04-no-gfdl-docs.diff to skip building of GFDL docs.
+
+ -- Jelmer Vernooij jel...@debian.org  Sun, 16 Dec 2012 14:08:10 +0100
+
 adplug (2.2.1+dfsg1-1) unstable; urgency=low
 
   * New maintainer (closes: #454268).
diff -Nru adplug-2.2.1+dfsg1/debian/patches/04-no-gfdl-docs.diff adplug-2.2.1+dfsg2/debian/patches/04-no-gfdl-docs.diff
--- adplug-2.2.1+dfsg1/debian/patches/04-no-gfdl-docs.diff	1970-01-01 01:00:00.0 +0100
+++ adplug-2.2.1+dfsg2/debian/patches/04-no-gfdl-docs.diff	2012-12-16 14:15:38.0 +0100
@@ -0,0 +1,62 @@
+Description: Don't build libadplug.texi as that file has been stripped from the tarball.
+Forwarded: not-needed
+Bug-Debian: http://bugs.debian.org/695710
+Author: Jelmer Vernooij jel...@debian.org
+Last-Update: 2012-12-16
+
+--- a/doc/Makefile.in	2012-12-16 14:14:36.454319112 +0100
 b/doc/Makefile.in	2010-04-06 05:12:22.0 +0200
+@@ -48,9 +48,9 @@ SOURCES =
+ DIST_SOURCES =
+-INFO_DEPS = 
++INFO_DEPS = $(srcdir)/libadplug.info
+ am__TEXINFO_TEX_DIR = $(srcdir)
+-DVIS = 
+-PDFS = 
+-PSS = 
+-HTMLS = 
+-TEXINFOS = 
++DVIS = libadplug.dvi
++PDFS = libadplug.pdf
++PSS = libadplug.ps
++HTMLS = libadplug.html
++TEXINFOS = libadplug.texi
+ TEXI2DVI = texi2dvi
+@@ -207,9 +207,10 @@ top_builddir = @top_builddir@
+ top_srcdir = @top_srcdir@
+-info_TEXINFOS = 
+-libadplug_TEXINFOS = 
++info_TEXINFOS = libadplug.texi
++libadplug_TEXINFOS = fdl.texi
+ man_MANS = adplugdb.1
+ EXTRA_DIST = adplugdb.1.in
+-MOSTLYCLEANFILES = stamp-vti
++MOSTLYCLEANFILES = stamp-vti libadplug.info libadplug.info-1 \
++	libadplug.info-2
+ 
+-CLEANFILES = 
++CLEANFILES = libadplug.cps libadplug.fns libadplug.vrs
+ DISTCLEANFILES = adplugdb.1
+@@ -306,4 +307,10 @@ clean-libtool:
+ 	fi
++$(srcdir)/libadplug.info: libadplug.texi $(srcdir)/version.texi $(libadplug_TEXINFOS)
++libadplug.dvi: libadplug.texi $(srcdir)/version.texi $(libadplug_TEXINFOS)
++libadplug.pdf: libadplug.texi $(srcdir)/version.texi $(libadplug_TEXINFOS)
++libadplug.html: libadplug.texi $(srcdir)/version.texi $(libadplug_TEXINFOS)
+ $(srcdir)/version.texi: @MAINTAINER_MODE_TRUE@ $(srcdir)/stamp-vti
+-$(srcdir)/stamp-vti: $(top_srcdir)/configure
++$(srcdir)/stamp-vti: libadplug.texi $(top_srcdir)/configure
++	@(dir=.; test -f ./libadplug.texi || dir=$(srcdir); \
++	set `$(SHELL) $(srcdir)/mdate-sh $$dir/libadplug.texi`; \
+ 	echo @set UPDATED $$1 $$2 $$3; \
+@@ -406,4 +413,10 @@ dist-info: $(INFO_DEPS)
+ mostlyclean-aminfo:
++	-rm -rf libadplug.aux libadplug.cp libadplug.cps libadplug.fn libadplug.fns \
++	  libadplug.ky libadplug.kys libadplug.log libadplug.pg \
++	  libadplug.pgs libadplug.tmp libadplug.toc libadplug.tp \
++	  libadplug.tps libadplug.vr libadplug.vrs
+ 
+ clean-aminfo:
++	-test -z libadplug.dvi libadplug.pdf libadplug.ps libadplug.html \
++	|| rm -rf libadplug.dvi libadplug.pdf libadplug.ps libadplug.html
+ 
diff -Nru adplug-2.2.1+dfsg1/debian/patches/series adplug-2.2.1+dfsg2/debian/patches/series
--- adplug-2.2.1+dfsg1/debian/patches/series	2011-03-17 15:29:11.0 +0100
+++ adplug-2.2.1+dfsg2/debian/patches/series	2012-12-16 14:15:49.0 +0100
@@ -1 +1,2 @@
 03-no-tests.diff
+04-no-gfdl-docs.diff
diff -Nru adplug-2.2.1+dfsg1/doc/Makefile.in adplug-2.2.1+dfsg2/doc/Makefile.in
--- adplug-2.2.1+dfsg1/doc/Makefile.in	2010-04-06 05:12:22.0 +0200
+++ adplug-2.2.1+dfsg2/doc/Makefile.in	2012-12-16 14:14:36.0 +0100
@@ -46,13 +46,13 @@
 CONFIG_CLEAN_VPATH_FILES =
 SOURCES =
 DIST_SOURCES =
-INFO_DEPS = $(srcdir)/libadplug.info
+INFO_DEPS = 
 am__TEXINFO_TEX_DIR = $(srcdir)
-DVIS = libadplug.dvi
-PDFS = libadplug.pdf
-PSS = libadplug.ps
-HTMLS = libadplug.html
-TEXINFOS = libadplug.texi
+DVIS = 
+PDFS = 
+PSS = 
+HTMLS = 
+TEXINFOS = 
 TEXI2DVI = texi2dvi
 TEXI2PDF = $(TEXI2DVI) --pdf --batch
 MAKEINFOHTML = $(MAKEINFO) --html
@@ -205,14 +205,13 @@
 top_build_prefix = @top_build_prefix@
 top_builddir = @top_builddir@
 top_srcdir = @top_srcdir@
-info_TEXINFOS = libadplug.texi
-libadplug_TEXINFOS = fdl.texi
+info_TEXINFOS = 
+libadplug_TEXINFOS = 
 man_MANS = adplugdb.1
 EXTRA_DIST = adplugdb.1.in
-MOSTLYCLEANFILES = stamp-vti libadplug.info libadplug.info-1 \
-	libadplug.info-2
+MOSTLYCLEANFILES = stamp-vti
 
-CLEANFILES = libadplug.cps libadplug.fns libadplug.vrs
+CLEANFILES

Bug#695215: breaks with newer versions of bzr

[Jelmer Vernooij]

Package: bzr-loom
Version: 2.2.0-2
Severity: grave
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 
'BzrBranch5'

Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 930, in 
exception_to_return_code
return the_callable(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 1121, in 
run_bzr
ret = run(*run_argv)
  File /usr/lib/python2.7/dist-packages/bzrlib/plugins/loom/commands.py, line 
259, in run_argv_aliases
super(cmd_switch, self).run_argv_aliases(list(argv), alias_argv)
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 673, in 
run_argv_aliases
return self.run(**all_cmd_args)
  File /usr/lib/python2.7/dist-packages/bzrlib/commands.py, line 697, in run
return self._operation.run_simple(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/cleanup.py, line 136, in 
run_simple
self.cleanups, self.func, *args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/cleanup.py, line 166, in 
_do_with_cleanups
result = func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/bzrlib/plugins/loom/commands.py, line 
239, in run
tree = LoomTreeDecorator(tree)
  File /usr/lib/python2.7/dist-packages/bzrlib/lazy_import.py, line 116, in 
__call__
obj = object.__getattribute__(self, '_resolve')()
  File /usr/lib/python2.7/dist-packages/bzrlib/lazy_import.py, line 85, in 
_resolve
obj = factory(self, scope, name)
  File /usr/lib/python2.7/dist-packages/bzrlib/lazy_import.py, line 200, in 
_import
module = __import__(module_python_path, scope, scope, [member], level=0)
  File /usr/lib/python2.7/dist-packages/bzrlib/plugins/loom/tree.py, line 36, 
in module
from branch import EMPTY_REVISION
  File /usr/lib/python2.7/dist-packages/bzrlib/plugins/loom/branch.py, line 
747, in module
class LoomBranch(LoomSupport, bzrlib.branch.BzrBranch5):
AttributeError: 'module' object has no attribute 'BzrBranch5'

bzr 2.6.0dev3 on python 2.7.3 (Linux-3.6-trunk-amd64-x86_64-with-debian-
wheezy-sid)
arguments: ['/usr/bin/bzr', 'switch', '-b', 'trunk']
plugins: bash_completion[2.6.0dev3], builddeb[2.8.5dev],
changelog_merge[2.6.0dev3], etckeeper[unknown], fastimport[0.13.0],
git[0.6.9], grep[2.6.0dev3], launchpad[2.6.0dev3], loom[2.2.0],
netrc_credential_store[2.6.0dev3], news_merge[2.6.0dev3],
po_merge[2.6.0dev3], qbzr[0.23.0], rewrite[0.6.4dev], stats[0.2.0dev],
svn[1.2.3dev], weave_fmt[2.6.0dev3]
encoding: 'utf-8', fsenc: 'UTF-8', lang: 'en_IE.UTF-8'

*** Bazaar has encountered an internal error.  This probably indicates a
bug in Bazaar.  You can help us fix it by filing a bug report at
https://bugs.launchpad.net/bzr/+filebug
including this traceback and a description of the problem.


- -- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.6-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bzr-loom depends on:
ii  python 2.7.3-3
ii  python-bzrlib  2.6.0~bzr6571-1
ii  python2.6  2.6.8-1
ii  python2.7  2.7.3-5

Versions of packages bzr-loom recommends:
ii  bzr  2.6.0~bzr6571-1

bzr-loom suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQv2LwAAoJEACAbyvXKaRX29QP/iIXKG1XbK0mjjjuBhhzrJGM
EeqRYpHhiWOK1kPTqTjv/zoeywmJgNPYw3NVYRJNssAjPDnLZxSxPRQV9lNnAOHt
HsilAHjifXRVCaYKTDrXLELrHgEGrhN8YVV0aC1YXARn9u/LL0XjZwYk+bvHfu0r
RBMscBogG9lFFBw4hLPV4fycif0JwTR3jPiZOf79FsrffuMDA9kgimP8rnjNR6NC
o5sqLw+BVknOISBzFPXRLJOFC+k4gW5LEHpL5UCGHv65190WIojYYqVGJP1HTh2x
jPMLv6qkiohG9zM0FruKxw7SldJbrK8HNyJ4GEz4T3p0A453v/MkhjNFSy5CjIpV
9ssIhSAVLwMGBZ29kjrzWuBNBNOilUy1eZPaAQPu4X+nCJE5BEzpxRUo2PUSoEQR
jvaN+DwJeC46vmzVe8VU1Xxh8m6hmsq0WBqY1wAD4Jh9sEB+fg+pNSwqvt9wtkSN
TWVeorLu4QBSlNNy9S2MO7NVKuF3x801haApOl4UhNLchk3ckc15c4/8xMyzT9Mv
6uEF2N+f8MkbBmFnqQXukosS16LdCIQEfEJNczhbk9a1SRP/y6YczYIDqvpHn7Lv
pxI/IJ5f9zduPE6SYn9TIJfyGkEvyEIHbwdTlUL+H3/9YptNtxiMY6jhI8M8lr1y
FhSyyytxXftc560QOyL0
=m3Ye
-END PGP SIGNATURE-


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

Bug#695137: [Pkg-samba-maint] Bug#695137: samba4-common-bin: failed drs replication

[Jelmer Vernooij]

On Tue, 2012-12-04 at 18:51 +0400, Matyashov Andrey wrote:
 Package: samba4-common-bin
 Version: 4.0.0~rc5+dfsg1-1
 Severity: grave
 Tags: upstream
 Justification: causes non-serious data loss
Thanks for the bug report. The error message could indeed be clearer. 

However, I don't understand why this causes data loss. The third
argument doesn't look like a naming context to me.

Cheers,

Jelmer


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

Bug#694697: [Pkg-samba-maint] Bug#694697: samba4 is missing smbd binary

[Jelmer Vernooij]

tags 694697 +moreinfo
severity 694697 important
thanks

On Thu, 2012-11-29 at 11:01 +0100, Franz z wrote:
 Package: samba4
 Version: 4.0.0~rc5+dfsg1-1
 Severity: serious
 
 The latest samba4 package in experimental is missing the important
 binary /usr/sbin/smbd. Without this binary the samba daemon does not
 even start, which makes this package completely useless.
smbd is packaged in the 'samba' package - it's an older version of it
though.

However, the Debian package sets up Samba4 in a way so that it doesn't
need the smbd binary. What fails exactly - and what error message do you
get?

Cheers,

Jelmer


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

Bug#684852: python-greenlet: diff for NMU version 0.3.1-2.1

[Jelmer Vernooij]

On Sun, 2012-11-04 at 19:00 +0100, gregor herrmann wrote:
 On Sat, 27 Oct 2012 21:46:37 +0100, Adam D. Barratt wrote:
 
I've uploaded Laszlo's NMU for python-greenlet (versioned as
0.3.1-2.1) and uploaded it to DELAYED/5. Please feel free to tell me
if I should delay it longer.
   That's the last entry in the bug log, but I don't see a -2.1 package
   in the PTS -- just curious what happened :)
  http://packages.qa.debian.org/p/python-greenlet/news/20121015T104745Z.html
  is the top entry on the package's PTS page from here.
 
 Right; I swear it wasn't when I sent the original mail :)
 
 Jelmer, does this mean the bug should be closes with 0.3.1-2.1?
python-eventlet should probably be updated to depend on the newer
version of python-greenlet (which hasn't yet migrated to wheezy AFAIK).

It would also be nice to make some of the changes that Jakub suggested
in http://lists.debian.org/debian-python/2012/02/msg00023.html, making
sure python-eventlet doesn't accidentally download from the internet.

Cheers,

Jelmer


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

Bug#684852: python-greenlet: diff for NMU version 0.3.1-2.1

[Jelmer Vernooij]

I've uploaded Laszlo's NMU for python-greenlet (versioned as
0.3.1-2.1) and uploaded it to DELAYED/5. Please feel free to tell me
if I should delay it longer.

Cheers,

Jelmer
diff -Nru python-greenlet-0.3.1/debian/changelog python-greenlet-0.3.1/debian/changelog
--- python-greenlet-0.3.1/debian/changelog	2011-08-23 00:33:20.0 +0200
+++ python-greenlet-0.3.1/debian/changelog	2012-08-25 16:05:43.0 +0200
@@ -1,3 +1,12 @@
+python-greenlet (0.3.1-2.1) wheezy-proposed-updates; urgency=low
+
+  * Non-maintainer upload.
+  * Add missing .egg-info file for Wheezy.
+  * Fix packaging SCM browser location.
+  * Fix copyright use template lintian error.
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.hu  Sat, 25 Aug 2012 15:52:00 +0200
+
 python-greenlet (0.3.1-2) unstable; urgency=low
 
   * Build for architecture any (Closes: #607805).
diff -Nru python-greenlet-0.3.1/debian/control python-greenlet-0.3.1/debian/control
--- python-greenlet-0.3.1/debian/control	2011-08-23 00:33:20.0 +0200
+++ python-greenlet-0.3.1/debian/control	2012-08-25 15:59:04.0 +0200
@@ -7,7 +7,7 @@
 Standards-Version: 3.9.1
 Section: python
 Homepage: http://pypi.python.org/pypi/greenlet
-Vcs-Browser: http://git.42mm.org/?p=python-greenlet
+Vcs-Browser: http://git.42mm.org/?p=python-greenlet.git
 Vcs-Git: git://git.42mm.org/git/python-greenlet
 
 Package: python-greenlet-dbg
diff -Nru python-greenlet-0.3.1/debian/copyright python-greenlet-0.3.1/debian/copyright
--- python-greenlet-0.3.1/debian/copyright	2011-08-23 00:33:20.0 +0200
+++ python-greenlet-0.3.1/debian/copyright	2012-08-25 16:03:48.0 +0200
@@ -4,7 +4,7 @@
 
 It was downloaded from http://pypi.python.org/pypi/greenlet
 
-Upstream Author(s):
+Upstream Authors:
 
 Kyle Ambroff k...@ambroff.com
 Armin Rigo ar...@ulb.ac.be
diff -Nru python-greenlet-0.3.1/debian/python-greenlet.install python-greenlet-0.3.1/debian/python-greenlet.install
--- python-greenlet-0.3.1/debian/python-greenlet.install	2011-08-23 00:33:20.0 +0200
+++ python-greenlet-0.3.1/debian/python-greenlet.install	2012-08-25 15:54:37.0 +0200
@@ -1 +1,2 @@
 usr/lib/python*/*-packages/*[!_][!_].so
+usr/lib/python*/*-packages/*.egg-info


signature.asc
Description: Digital signature

Bug#681048: Please attach smb.conf

[Jelmer Vernooij]

Hi,

Do you happen to still have the original smb.conf file that originally
caused this bug?

The postinst script should update smb.conf to insert the realm from
debconf, so I'm curious why that's not happening here.

Cheers,

Jelmer



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

Bug#680800: Caused by newer libsvn1 which has some behaviour changes

[Jelmer Vernooij]

forwarded 680800 https://bugs.launchpad.net/subvertpy/+bug/887749
tags 680800 +confirmed +upstream
tags 680792 +confirmed
block 680792 by 680800
thanks

This is caused by svn 1.7, which landed in unstable (17
June) a couple of weeks ago. svn 1.7 has fairly
significant changes in its behaviour for working copies (the ABI
hasn't technically changed, but passing the same arguments now
yields different results for some arguments).


signature.asc
Description: Digital signature

Bug#680792: (no subject)

[Jelmer Vernooij]

Should this be tagged wheezy? subversion 1.7 is not in wheezy so these
two FTBFS issues technically shouldn't affect wheezy.

I guess it might make sense to have the existing packages explicitly
require an older version of svn?

Jelmer


signature.asc
Description: Digital signature