Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies

[Wouter Verhelst]

Package: mariadb-server
Version: 1:10.11.7-3
Severity: serious

I did a 2G "apt dist-upgrade" to get my way through the time_t
transition. This failed halfway through with the following messages:

Uitpakken van .../10-mariadb-server_1%3a10.11.7-3_amd64.deb wordt voorbereid...
systemctl: error while loading shared libraries: libcrypto.so.3: cannot open 
shared object file: No such file or directory
dpkg: waarschuwing: subproces van het verouderd pakket mariadb-server het 
script pre-removal gaf de foutwaarde 127 terug
dpkg: script uit het nieuwe pakket wordt geprobeerd als alternatief...
systemctl: error while loading shared libraries: libcrypto.so.3: cannot open 
shared object file: No such file or directory
dpkg: fout bij verwerken van archief 
/tmp/apt-dpkg-install-IuQoIO/10-mariadb-server_1%3a10.11.7-3_amd64.deb 
(--unpack):
 subproces van het nieuwe pakket mariadb-server het script pre-removal gaf de 
foutwaarde 127 terug

Here, the Dutch terms translate (approximately) to:

"Unpacking .../10-mariadb-..."

dpkg: warning: subproces of the old package mariadb-server pre-removal script 
return error value 127
dpkg: trying script from the new package as alternative...

i.e., the prerm script tries to call systemctl, which fails because
libcrypto.so.3 is not on the filesystem. The new package's prerm script
tries the same, which fails for the same reason.

Checking dpkg.log, I see:

2024-03-22 12:12:24 remove libssl3:i386 3.1.5-1 
2024-03-22 12:12:24 status half-configured libssl3:i386 3.1.5-1
2024-03-22 12:12:24 status half-installed libssl3:i386 3.1.5-1
2024-03-22 12:12:24 status config-files libssl3:i386 3.1.5-1
2024-03-22 12:12:24 status not-installed libssl3:i386 
2024-03-22 12:12:24 remove libssl3:amd64 3.1.5-1 
2024-03-22 12:12:24 status half-configured libssl3:amd64 3.1.5-1
2024-03-22 12:12:24 status half-installed libssl3:amd64 3.1.5-1
2024-03-22 12:12:24 status config-files libssl3:amd64 3.1.5-1
2024-03-22 12:12:24 status not-installed libssl3:amd64 
2024-03-22 12:12:24 startup archives unpack
2024-03-22 12:12:25 install libssl3t64:i386  3.1.5-1.1
2024-03-22 12:12:25 status half-installed libssl3t64:i386 3.1.5-1.1
2024-03-22 12:12:25 status unpacked libssl3t64:i386 3.1.5-1.1

[...]

2024-03-22 12:18:20 upgrade mariadb-server:amd64 1:10.11.7-1 1:10.11.7-3
2024-03-22 12:18:20 status half-configured mariadb-server:amd64 1:10.11.7-1
2024-03-22 12:18:20 status installed mariadb-server:amd64 1:10.11.7-1
2024-03-22 12:18:20 upgrade mariadb-server-core:amd64 1:10.11.7-1 1:10.11.7-3
2024-03-22 12:18:20 status half-configured mariadb-server-core:amd64 1:10.11.7-1
2024-03-22 12:18:20 status unpacked mariadb-server-core:amd64 1:10.11.7-1
2024-03-22 12:18:20 status half-installed mariadb-server-core:amd64 1:10.11.7-1
2024-03-22 12:18:21 status unpacked mariadb-server-core:amd64 1:10.11.7-3

Full dpkg.log of this run attached.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server depends on:
ii  adduser3.137
ii  debconf [debconf-2.0]  1.5.86
ii  galera-4   26.4.16-2+b1
ii  gawk   1:5.2.1-2
ii  init-system-helpers1.66
ii  iproute2   6.8.0-1
ii  libc6  2.37-15.1
ii  libdbi-perl1.643-4+b1
ii  libpam0g   1.5.3-6
ii  libssl3t64 3.1.5-1.1
ii  libstdc++6 14-20240315-1
ii  lsof   4.95.0-1
ii  mariadb-client 1:10.11.7-3
ii  mariadb-common 1:10.11.7-3
ii  mariadb-server-core1:10.11.7-3
ii  passwd 1:4.13+dfsg1-4
ii  perl   5.38.2-3.2
ii  procps 2:4.0.4-4
ii  psmisc 23.7-1
ii  rsync  3.2.7-1+b1
ii  socat  1.8.0.0-4
ii  zlib1g 1:1.3.dfsg-3.1

Versions of packages mariadb-server recommends:
ii  libhtml-template-perl   2.97-2
ii  mariadb-plugin-provider-bzip2   1:10.11.7-3
ii  mariadb-plugin-provider-lz4 1:10.11.7-3
ii  mariadb-plugin-provider-lzma1:10.11.7-3
ii  mariadb-plugin-provider-lzo 1:10.11.7-3
ii  mariadb-plugin-provider-snappy  1:10.11.7-3
ii  pv  1.8.5-2

Versions of packages mariadb-server suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  mailutils [mailx]  1:3.17-1.1+b1
pn  mariadb-test   
ii  netcat-openbsd 1.226-1

-- debconf information excluded


dpkg.log.gz
Description: application/gzip

Bug#1062821: ola: NMU diff for 64-bit time_t transition

[Wouter Verhelst]

On Wed, Feb 07, 2024 at 09:47:10AM +0200, Wouter Verhelst wrote:
> Hi Lucas,
> 
> On Sat, Feb 03, 2024 at 02:39:49PM -0300, Lucas Kanashiro wrote:
> > Source: ola
> > Version: 0.10.9.nojsmin-4
> > Severity: serious
> > Tags: patch pending sid trixie
> > Justification: library ABI skew on upgrade
> > User: debian-...@lists.debian.org
> > Usertags: time-t
> > 
> > NOTICE: these changes must not be uploaded to unstable yet!
> > 
> > Dear maintainer,
> > 
> > As part of the 64-bit time_t transition required to support 32-bit
> > architectures in 2038 and beyond
> > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> > ola as a source package shipping runtime libraries whose ABI
> > either is affected by the change in size of time_t, or could not be
> > analyzed via abi-compliance-checker (and therefore to be on the safe
> > side we assume is affected).
> 
> Would it make sense for me to contact upstream and ask if they do
> certain things? They're quite knowledgeable and might know.
> 
> If not, then no worries, but I thought I'd ask.

nvm, just read the d-d-a mail :-)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1062821: ola: NMU diff for 64-bit time_t transition

[Wouter Verhelst]

Hi Lucas,

On Sat, Feb 03, 2024 at 02:39:49PM -0300, Lucas Kanashiro wrote:
> Source: ola
> Version: 0.10.9.nojsmin-4
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> ola as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).

Would it make sense for me to contact upstream and ask if they do
certain things? They're quite knowledgeable and might know.

If not, then no worries, but I thought I'd ask.

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression

[Wouter Verhelst]

On Sun, Jan 07, 2024 at 08:19:40AM +0100, Paul Gevers wrote:
> Hi Wouter,
> 
> On 06-01-2024 20:51, Wouter Verhelst wrote:
> > > The Release Team considers packages that are out-of-sync between testing 
> > > and
> > > unstable for more than 30 days as having a Release Critical bug in testing
> > > [1]. Your package src:extrepo has been trying to migrate for 33 days [2].
> > 
> > This should have been fixed with the recent upload of extrepo-offline-data?
> 
> Doesn't that mean that there is a versioned relation or a Breaks needed
> somewhere?

Not really. The issue is that the old version of extrepo-offline-data
did not have the "debian_official" repository for trixie yet, and the
test tries to use that; and as of extrepo 0.12, the default is to enable
trixie, not bookworm.

Things work as expected, even with extrepo-offline-data, it's just that
the test suite expects a repository to be there which is not there
(yet).

I don't think that's worthy of a Breaks relationship, but it is an
oversight on my side.

To muddle the waters a bit more, I also uploaded extrepo 0.13 now, which
adds a few features, but the test is now failing because it got
entangled in the perl migration... I guess things will have to wait.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression

[Wouter Verhelst]

Hi Paul,

On Sat, Jan 06, 2024 at 01:58:53PM +0100, Paul Gevers wrote:
> Source: extrepo
> Version: 0.11
> Severity: serious
> Control: close -1 0.12
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:extrepo has been trying to migrate for 33 days [2].

This should have been fixed with the recent upload of extrepo-offline-data?

If that didn't happen yet, can you try to trigger another autopkgtest run?

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1042424: src:ola: fails to migrate to testing for too long: uploader built arch:all binaries

[Wouter Verhelst]

Hi Paul,

On Fri, Jul 28, 2023 at 08:18:56AM +0200, Paul Gevers wrote:
> Your package is only blocked because the arch:all binary package(s) aren't
> built on a buildd. Unfortunately the Debian infrastructure doesn't allow
> arch:all packages to be properly binNMU'ed. Hence, I will shortly do a
> no-changes source-only upload to DELAYED/15, closing this bug. Please let me
> know if I should delay or cancel that upload.

Thanks. I forgot about this one, and yes, a no-changes source-only
upload was still required. The delay is unnecessary; I've just uploaded
-4 which is essentially the same, directly to the upload queue.

Thanks for nudging me.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1042431: libmedia-convert-perl: autopkgtest regression with ffmpeg 6.0

[Wouter Verhelst]

Control: retitle -1 libmedia-convert-perl: autopkgtest fails

On Fri, Jul 28, 2023 at 09:51:06AM +0200, Sebastian Ramacher wrote:
> Source: libmedia-convert-perl
> Version: 1.0.4-3
> Severity: serious
> Tags: sid trixie
> X-Debbugs-Cc: sramac...@debian.org
> 
> libmedia-convert-perl's autopkgtest fail with ffmpeg 6.0:

Actually, it just fails ;-) I've got a fix upcoming.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1006915: 2 security issues in nbd-server

[Wouter Verhelst]

Source: nbd
Version: 1:3.23-3
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Two security issues exist in NBD: CVE-2022-26495 and CVE-2022-26496.

The former exists since a very long time; the latter only exists since
the introduction of NBD_OPT_INFO and NBD_OPT_GO in NBD 3.16.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, riscv64, armhf

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE:nl
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#1002210: adapt: diff for NMU version 1.0.0-1.1

[Wouter Verhelst]

Thanks!

The delay is absolutely not necessary; feel free to redirect to a direct upload.
-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

Bug#1004156: src:adapt: fails to migrate to testing for too long: FTBFS

[Wouter Verhelst]

Hi Paul,

On Fri, Jan 21, 2022 at 10:22:43PM +0100, Paul Gevers wrote:
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.

No, that's not it; I've just not been able to look at the problem, due
to being too busy with other things[1].

I'll get around that early next month, hopefully.

Thanks for caring,

[1] e.g., https://fosdem.org/2022/, which I help organizing.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#1000503: nbd FTBFS: configure.ac:371: error: required file 'man/nbd-client.8.sh.in' not found

[Wouter Verhelst]

Version: 1:3.23-3

On Wed, Nov 24, 2021 at 01:20:21PM +0200, Adrian Bunk wrote:
> Source: nbd
> Version: 1:3.23-2
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=nbd=1%3A3.23-2
> 
> 
> configure.ac:371: error: required file 'man/nbd-client.8.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-server.5.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-server.1.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-trdump.1.sh.in' not found
> configure.ac:371: error: required file 'man/nbdtab.5.sh.in' not found
> autoreconf: error: automake failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> 

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#990026: Aaargh!

[Wouter Verhelst]

Whoever wrote that patch should be slapped around the head with a copy
of RFC3696.

Go read it. Now, please. Understand it. Internalize it. Then update your
data verification code so that all valid email addresses will be
accepted.

But first remove the "save_p" function from the cron implementation. It
is broken, and the fix may otherwise take too long, I suppose.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#964496: libjson-validator-perl: URL is gone, this is now RC

[Wouter Verhelst]

Control: tags -1 + pending
thanks

Hi Andrius,

On Wed, Dec 09, 2020 at 09:29:01AM +0200, Andrius Merkys wrote:
> Hi Wouter,
> 
> I have uploaded libjson-validator-perl with cache links for OpenAPI
> schemas. Please upload sreview-web 0.6.1-2 without the obstructing cache
> files.

Yeah. That was meant as a temporary local hack so I could test my
package. I never intended to upload it... *blush*.

I've actually already fixed it
(https://salsa.debian.org/debconf-video-team/sreview/-/commit/a0f09046da82cd5319f71708343b8db0fc3192c8),
but there's still a few unrelated issues that I need to try and get
resolved before I can upload.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#964496: libjson-validator-perl: URL is gone, this is now RC

[Wouter Verhelst]

Hi Andrius,

On Mon, Nov 30, 2020 at 01:00:46PM +0200, Andrius Merkys wrote:
> Hello,
> 
> On 2020-11-29 18:59, Wouter Verhelst wrote:
> > This bug is still present. Additionally, the URL for the OpenAPI JSON
> > scheme now returns a 404 error, which means that any software using
> > OpenAPI on Debian with this bug present will fail to function correctly.>
> > Please fix this bug before the release of bullseye.
> 
> While I agree that this is an important issue, I do not think severity
> "serious" is appropriate here. It is true that the upstream provides
> caching mechanism, but any URL may become offline, and a general
> approach to prevent failures in such cases is to use Debian-packaged
> files.

... which is exactly what this bug report is talking about, so I don't
understand?

> With OpenAPI schemas provided in openapi-specification binary
> package, this is as simple as replacing OpenAPI URLs with
> /usr/share/openapi-specification/schemas/$VERSION/schema.json in the
> using code.

Unfortunately, that doesn't work very if the code in question is also
packaged (because upgrades would blow those changes away, yada yada).

> The upstream caching mechanism could indeed be employed, but as said
> before [1], preferable way to use it needs transparency of cache hashes.
> 
> By the way, could you please provide OpenAPI URL that returns 404 now?

That would be https://spec.openapis.org/oas/3.0/schema/2019-04-02

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#925793: marked as pending in ola

[Wouter Verhelst]

Control: tag -1 pending

Hello,

Bug #925793 in ola reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/wouter/ola/-/commit/a5fe685026c18dab8260704fe828560b322b8a9c


Changelog entry for upstream merge. Closes: #944927, #925793


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/925793

Bug#937186: marked as pending in ola

[Wouter Verhelst]

Control: tag -1 pending

Hello,

Bug #937186 in ola reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/wouter/ola/-/commit/a157460e2c42abcc557cd2bceaefdfcd7a5c46b1


ola-python, ola-rdm-tests: switch to python3, from python2. Closes: #937186.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/937186

Bug#937186: Being worked on upstream

[Wouter Verhelst]

control: forwarded 937186 https://github.com/OpenLightingProject/ola/issues/1506
thanks

ola currently doesn't have Python3 support yet. This is being worked on 
upstream.

Once the python3 support is available, I will upload a new package which
drops python2 and replaces it with the python3 equivalents.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Bug#946630: openstack-cluster-installer-agent: syntax error

[Wouter Verhelst]

Source: openstack-cluster-installer
Version: 21
Severity: grave
Justification: makes the package unusable

The agent contains the following on line 29:

ETH_SPEED=$(( $(lshw -class network 2>/dev/null -json | jq '.[] | 
select(.serial|test("'${MAC_ADDR}'")) | .capacity') / 100))

The shell redirect ("2>/dev/null") means the shell stops passing
command-line arguments from there on, which means the "-json" is never
seen by lshw, which in turn means the "jq" command doesn't get any JSON
data.

This results in an error message of the type

bash: / 100 : syntax error: operand expected (error token is "/ 100")

upon which the agent stops working, and nothing is added to oci's
database.

(this may be fixed in later versions, didn't check, but this is what's in
stable...)

Bug#945127: extrepo: YAML_PARSE_ERR_INCONSISTENT_INDENTATION error on extrepo update

[Wouter Verhelst]

Version: 0.4
thanks

Hi Leandro,

This is due to a mismatch between the YAML and YAML::XS perl modules. A
fixed package is available in incoming already, should be on a Debian
Mirror Near You(TM) soon.

On Wed, Nov 20, 2019 at 09:30:15AM +, Leandro Lisboa Penz wrote:
> Package: extrepo
> Version: 0.3
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Running "extrepo update" produced the following output:
> 
> $ extrepo update
> gpgv: Signature made Tue 19 Nov 2019 12:09:16 PM GMT
> gpgv:using RSA key 7A8502E9FF4765B162A964171283BEE904FB0E04
> gpgv: Good signature from "Debian external repositories signing key 
> (experimental)"
> 
> 
> YAML Error: Inconsistent indentation level
>Code: YAML_PARSE_ERR_INCONSISTENT_INDENTATION
>Line: 9
>Document: 1
>  at /usr/share/perl5/YAML/Loader.pm line 804.
>   ...propagated at /usr/bin/extrepo line 101.
> 
> This is the first time I'm running it.
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (520, 'testing'), (510, 'stable'), (150, 'unstable'), (120, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en (charmap=UTF-8) (ignored: LC_ALL set 
> to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages extrepo depends on:
> ii  gpgv2.2.17-3
> ii  libcryptx-perl  0.066-1
> ii  libwww-perl 6.41-1
> ii  libyaml-perl1.29-1
> ii  perl5.30.0-9
> 
> extrepo recommends no packages.
> 
> extrepo suggests no packages.
> 
> -- no debconf information
> 

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#945047: marked as pending in extrepo

[Wouter Verhelst]

Control: tag -1 pending

Hello,

Bug #945047 in extrepo reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/extrepo-team/extrepo/commit/186af85fbe96e9142554f07693cc5581c1b4eea4


debian/control: add dependency on libcryptx-perl. Closes: #945047.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/945047

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:
> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

Thanks; somehow I missed that, sorry.

> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.

The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.

It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.

> Even ignoring that, it would not bring any improvement over the current 
> plan:

This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).

Changing this through a policy change, as we've always done, would not
have those problems:

- Maintainers are expected to move their own package to merged-/usr, so
  they would be aware of issues that might ensue and would be able to
  deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
  the same time; instead, we'll be gradually moving towards a
  merged-/usr situation.
- We don't end up with packages' files being moved from under them.

> even if your idea were executed perfectly and quickly then the 
> conversion program would still be in the same exact situation as it is 
> now:

Yes, obviously, that's the whole point.

[...]
> So this would make the transition unacceptably slow while providing no 
> benefit at all,

I don't agree with both these statements.

> but it would also cost a huge amount of work to change many packages.

Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Wed, Nov 28, 2018 at 01:49:45PM +, Ian Jackson wrote:
> Control: reassign -1 tech-ctte
> 
> Dear Technical Committee.  I don't know if you are all aware of the
> discussion surrounding this, so I will recap:
> 
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
> 
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
> 
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
> 
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
> 
> So I believe that this change should be immediately reverted in sid
> and buster, so that we do not prejudge the situation by increasing the
> number of buster installs in the field which generate packages which
> are broken on non-merged-/usr systemss.

One thing that has not been answered yet in this discussion (and if the
TC is to make a decision about it, I think it should be) is "why are we
doing this". That is, what is the problem that usrmerge is meant to
solve, and how does it attempt to solve it? As far as I know, the reason
usrmerge exists is so that no files will be installed in /bin anymore;
but that seems like an XY problem.

Also, I would like to ask why the traditional solution in Debian -- make
a policy change that says no package can ship anything in /bin except
for a compatibility symlink, and make that rule RC at some point in the
future -- is not being considered. That seems like a solution that would
cause far less pain than what we're going through right now.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Wouter Verhelst]

On Fri, Nov 30, 2018 at 06:01:26PM +0200, Jan Groenewald wrote:
> Hi
> 
> On Fri, 30 Nov 2018 at 16:43, Holger Levsen  wrote:
> 
> On Fri, Nov 30, 2018 at 07:39:20PM +0530, Pirate Praveen wrote:
> > >Backports are *always* from testing because a backport is
> > >supposed to be replaced by the regular stable version of
> > >the subsequent release.
> > That is indeed the current definition.
> 
> Me too is very happy with it.
> 
> > Another option could be to have personal package archive for gitlab.
> 
> That. And if you don't want to wait until they arrive in Debian proper,
> I'd suggest you'd host such an archive yourself.
> 
> 
> There is  https://packages.gitlab.com/gitlab/gitlab-ce
> 
> (deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ stretch main)

That "omnibus package" which contains everything and the kitchen sink is
awful.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#912713: Incorrect filename for jquery-ui makes rdm test server not work properly

[Wouter Verhelst]

Package: ola-rdm-tests
Version: 0.10.3.nojsmin-2
Severity: serious

The replacement of the jquery-ui code by the Debian-packaged version was
done incorrectly; as a result, jquery-ui is not found by the rdm test
server's HTML interface. This means that nothing works the way it
should.

Bug#901136: can't remove if install fails

[Wouter Verhelst]

On Thu, Jun 14, 2018 at 08:08:02AM +0300, kact...@gnu.org wrote:
> 
> [2018-06-14 00:32] Wouter Verhelst 
> > Hi,
> 
> Hi!
> 
> > On Wed, Jun 13, 2018 at 03:21:11AM +0300, kact...@gnu.org wrote:
> > > I never worked with NSS, but how did it happen, that useradd {in postinst}
> > > created user in a way, that userdel {in prerm} could not find?
> > 
> > That's not what happened.
> > 
> > The sreview user already existed before the sreview-common package was
> > installed, but it did not exist in /etc/passwd; instead, it existed in a
> > different location, configured through an NSS module.
> 
> Am I correct, some time ago it was created by previous version of maintainer 
> script,
> when I did not use dh-sysuser?

No.

It was created in Debian's LDAP directory.

> > The easiest way for you to test this is probably to install libnss-db,
> > change the value of ETC in /etc/default/libnss-db to some other
> > directory and cull the DBS value so it contains just passwd, then create
> > a file called "passwd" in the directory that you pointed ETC to, run
> > "make -C /var/lib/misc", and add "db" to /etc/nsswitch.conf on the
> > "passwd" line.
> > 
> > Meanwhile, I'm going to have to implement it properly and remove
> > dh_sysuser from my build-depends. Ah well.
> 
> So sad. Maybe you could suggest what should I use instead of 'useradd/userdel'
> in sysuser-helper to make dh-sysuser also work with NSS?

You generally cannot modify users from the command line (or from a
maintainer script) that are created through any NSS module that is not
libnss-compat (note: I said "unix" before, but that was obviously
wrong).

There's nothing wrong with useradd, but you should be prepared for the
possibility that the user already exists or cannot be modified.

Alternatively, you can just use adduser.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#901136: can't remove if install fails

[Wouter Verhelst]

Hi,

On Wed, Jun 13, 2018 at 03:21:11AM +0300, kact...@gnu.org wrote:
> I never worked with NSS, but how did it happen, that useradd {in postinst}
> created user in a way, that userdel {in prerm} could not find?

That's not what happened.

The sreview user already existed before the sreview-common package was
installed, but it did not exist in /etc/passwd; instead, it existed in a
different location, configured through an NSS module.

The easiest way for you to test this is probably to install libnss-db,
change the value of ETC in /etc/default/libnss-db to some other
directory and cull the DBS value so it contains just passwd, then create
a file called "passwd" in the directory that you pointed ETC to, run
"make -C /var/lib/misc", and add "db" to /etc/nsswitch.conf on the
"passwd" line.

Meanwhile, I'm going to have to implement it properly and remove
dh_sysuser from my build-depends. Ah well.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#901136: can't remove if install fails

[Wouter Verhelst]

Control: reassign -1 sysuser-helper,sreview-common
Control: retitle -1 sysuser-helper fails in terrible ways if users exist 
through NSS modules that are not libnss-unix

On Sat, Jun 09, 2018 at 09:53:53AM +, Peter Palfrader wrote:
> Package: sreview-common
> Version: 0.3.0-1~bpo.1
> Severity: grave
> User: debian-ad...@lists.debian.org
> Usertags: needed-by-DSA-Team
> 
> 
> sreview-common failed to configure.
> 
> | Setting up sreview-common (0.3.0-1~bpo.1) ...
> | usermod: user 'sreview' does not exist in /etc/passwd
> | dpkg: error processing package sreview-common (--configure):
> |  subprocess installed post-installation script returned error exit status 6
> | dpkg: dependency problems prevent configuration of sreview-encoder:
> |  sreview-encoder depends on sreview-common; however:
> |   Package sreview-common is not configured yet.
> | 
> | dpkg: error processing package sreview-encoder (--configure):
> 
> 
> Now we can't get rid of it anymore
> | vittoria:~# apt-get purge sreview-detect sreview-master sreview-encoder 
> sreview-web sreview-common
> | 
> | [..]
> | After this operation, 165 kB disk space will be freed.
> | Do you want to continue? [Y/n] 
> | (Reading database ... 77344 files and directories currently installed.)
> | Removing sreview-common (0.3.0-1~bpo.1) ...
> | passwd: user 'sreview' does not exist in /etc/passwd
> | dpkg: error processing package sreview-common (--remove):
> |  subprocess installed pre-removal script returned error exit status 1
> | usermod: user 'sreview' does not exist in /etc/passwd
> | dpkg: error while cleaning up:
> |  subprocess installed post-installation script returned error exit status 6
> | Errors were encountered while processing:
> |  sreview-common
> | E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#862531: stretch update for nbd

[Wouter Verhelst]

Control: found -1 1:3.15.2-3
thanks

Hi Adrian,

On Tue, Feb 27, 2018 at 10:20:55PM +0200, Adrian Bunk wrote:
> On Wed, Sep 13, 2017 at 03:12:07PM +, Debian Bug Tracking System wrote:
> >...
> >  nbd (1:3.16.2-1) unstable; urgency=medium
> >...
> >* Add missing After=network-online.target to nbd@ systemd unit.
> >  Closes: #862531.
> >...
> 
> Thanks a lot for fixing this bug for unstable.
> 
> It is still present in stretch, could you also fix it there?
> Alternatively, I can fix it for stretch if you don't object.

Thanks for reminding me. I had intended to let the patches simmer in
unstable for a while before asking for an update to stable, but forgot
to do that, and it got off my radar because it's now marked as "closed"
and doesn't have the correct version information to know that it's still
in stable...

Annotated this bug now so it is marked as still present in stable (I
hope). I'll try to fix it in stable ASAP, then.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#888251: does not allow certain characters in filenames

[Wouter Verhelst]

On Wed, Jan 24, 2018 at 08:21:00PM +, Niels Thykier wrote:
> (Technically, you can also escape the brace as a work around for
> debhelper - but I suspect it will still cause breakage as dh-exec then
> might create the file with a literal backslash).

Been there, done that. It did :-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#876251: typo in initscript makes rdm_test_server fail to start

[Wouter Verhelst]

Package: ola-rdm-tests
Version: 0.10.3.nojsmin-1
Severity: serious
Tags: patch

There is a typo in the rdm_test_server initscript. The line

DAEMON_ARGS="--world-writable"

should be

DAEMON_ARGS="--world-writeable"

without this fix, the daemon fails to start and the init script is
useless.

This is a regression from jessie.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

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

Versions of packages ola-rdm-tests depends on:
ii  libjs-jquery 3.2.1-1
ii  libjs-jquery-ui  1.12.1+dfsg-5
ii  lsb-base 9.20170808
ii  ola  0.10.5.nojsmin-2
ii  ola-python   0.10.5.nojsmin-2
ii  python   2.7.14-1
ii  python-numpy 1:1.13.1-1

ola-rdm-tests recommends no packages.

Versions of packages ola-rdm-tests suggests:
ii  bash-completion  1:2.1-4.3

-- Configuration Files:
/etc/init.d/rdm_test_server changed [not included]

-- no debconf information

Bug#862531: Bug#862530: aoetools: provide a systemd service to allow proper shutdown of AoE mounts

[Wouter Verhelst]

Control: tags -1 + help

On Thu, May 18, 2017 at 06:41:59PM +0200, Christoph Biedl wrote:
> (At least) AoE devices are handled properly if mounted with the _netdev
> mount option.

... but NBD devices are not. I'm not sure what changed, have been trying
to figure that out for the past week or so. With a line like the
following in fstab...

/dev/nbd0 /mnt _netdev 0 0

...the system will boot properly in jessie, but not in stretch. It used
to work properly in stretch too, at least during dc16 when I wrote the
systemd support.

Not sure what changed, but this is a serious regression from jessie, and
I'd like to see it resolved before the release.

-release: This bug is currently marked as Grave. Not sure whether that's
appropriate, but I do think that "serious" is. However, I don't think
it's my bug, since this used to work.

Anyone have any clue what's happening, or what has changed? I've got no
clue, and I don't think I'll be able to fix this today anymore...

-- 
Help me, off-by-one kenobi. You're my only nought.

Bug#862531: nbd-client: provide a systemd service to allow proper shutdown of NBD mounts

[Wouter Verhelst]

On Sun, May 14, 2017 at 12:21:47PM +0200, Guus Sliepen wrote:
> Users with filesystems mounted over NBD are surprised that these mount
> points are not unmounted before the network is shutdown.

As with any network mount that isn't an explicit network file system
(like NFS), you should add a _netdev option to the nbd fstab entry. Did
you do that?

> This can cause data loss. The documentation should be updated to tell
> users how to make mounts properly depend on the network (for example
> using filesystem options in fstab).

I'm not sure where that documentation would have to go; suggestions are
welcome.

> I see there is currently a nbd@.service that replaces the SysV init
> script. However, it does not declare a dependency on
> network-online.target.

That could be added, but I don't think it will fix this issue; I could
be wrong though

> There is a Before=dev-%i.device. I assume that should provide the
> necessary dependencies? However, I don't see a generator being created
> for such .device files, and no documentation in the package anywhere
> how to make those.

.device units are internal virtual units only; they are created as soon
as a /dev node is marked as ready to be used by udev (hence the fact
that udev and systemd are in the same source tree these days). There is
no actual .device unit file in your systemd configuration directory.

The Before= is placed so that, *at shutdown time*, the nbd@nbdX unit is
ordered correctly relative to the .device unit, and whatever depends on
that .device unit (e.g., .mount units for mount points). You still need
to add the _netdev option, however.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#749991: Wrong kernel in debian-installer package

[Wouter Verhelst]

On Thu, Apr 06, 2017 at 10:01:41AM +0700, Alexander Sosedkin wrote:
> On Thu, 6 Apr 2017 00:05:17 +0200
> Cyril Brulebois  wrote:
> 
> > That's unfortunate, yes, but there's no easy way to keep old packages
> > around in a given repository.
> 
> That's one way to think about it. Got it, keeping old modules is hard.
> But I wasn't asking about keeping old modules, I see no point in this.
> I was asking about generating and publishing a matching
> dists/testing/main/installer-/current on kernel upload.
> Why is _that_ hard?
> 
> I'm asking less of "why isn't it equal to
> https://d-i.debian.org/daily-images tree",
> and more of "why not d-i stretch rc 2 rebuilt with new kernel".
> And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749991#59
> doesn't quite cut it. Triggering is hard? Maybe, why not cron then?

We actually do cron. That's what daily-images is.

What's in the repository, however, is a whole different beast, and
"cron" is so far away from the solution that it's not funny.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#858046: logtool: uninstallable

[Wouter Verhelst]

On Tue, Mar 28, 2017 at 12:46:41AM +0300, Adrian Bunk wrote:
> I'm able to reproduce it:

Yes, I had found that, too.

The problem is that logtool wants a database of regular expressions, and
ships (an empty) one. Originally, when I packed it (over a decade ago)
you could replace conffiles by a symlinks to something else, but
nowadays you can't anymore. For good reason, obviously, but the bug
didn't trigger for seven years because dpkg only balks about that
situation at upgrade, and there wasn't any reason for an update to the
package for seven years...

I'm currently in the process of fixing things so the shipped conffiles
are directories rather than files, and so that we install symlinks as
directories in those conffiles. Will require some preinst creativity and
a few other things, but I'll get there. I hope.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#858046: logtool: uninstallable

[Wouter Verhelst]

Control: severity -1 normal
thanks

On Fri, Mar 17, 2017 at 06:21:31PM +0100, Cristian Ionescu-Idbohrn wrote:
> Package: logtool
> Version: 1.2.8-8+b2
> Severity: normal
> 
> dpkg: warning: logtool: conffile '/etc/logtool/exclude' is not a plain file 
> or symlink (= '/etc/logcheck/ignore.d.workstation')
> dpkg: error processing archive 
> /var/cache/apt/archives/logtool_1.2.8-8+b2_amd64.deb (--unpack):
>  unable to open '/etc/logtool/exclude.dpkg-new': No such file or directory
>  Errors were encountered while processing:
>   /var/cache/apt/archives/logtool_1.2.8-8+b2_amd64.deb

I can't reproduce this, and neither can Evgeni.

Can you provide a bit more details on how you managed to do this? If
not, I'm going to close the bug. For now, marking as normal, since an
unreproducible bug means it can't be totally useless, so it's not grave.

Regards,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#849504: Data corruption with copy-on-write and multiple threads

[Wouter Verhelst]

Hi Niels,

On Sat, Feb 25, 2017 at 08:40:00AM +, Niels Thykier wrote:
> Ok, please go ahead with the upload.

Done today. Sorry about the delay, I was out of the country.

> The only question I have is about this bit here:
> 
> > +  if (s->hostname && *s->hostname)
> > +{
> > +  if (!gnutls_x509_crt_check_hostname (cert, s->hostname))
> > +   {
> > + debugout (s,
> > +   "The certificate's owner does not match hostname '%s'\n",
> > +   s->hostname);
> > + return GNUTLS_E_CERTIFICATE_ERROR;
> > +   }
> > +}
> 
> When is the "s->hostname" is blank / NULL ?

s->hostname may be set on the command line to override the autodetected
hostname. If that's the case, this is only a sanity check to ensure that
the client certificate matches the client's hostname as specified. The
server has other checks for ensuring these names are valid.

It should not have any security impact on the client.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#849504: Data corruption with copy-on-write and multiple threads

[Wouter Verhelst]

On Tue, Feb 14, 2017 at 04:41:00PM +, Niels Thykier wrote:
> Wouter Verhelst:
> > Hi Niels,
> > 
> > On Sun, Feb 12, 2017 at 08:52:00AM +, Niels Thykier wrote:
> >> Any news on this bug?
> > 
> > I'm going to release (upstream) nbd 3.15.2 later this week (probably on
> > thursday), which contains the fix:
> > 
> > https://github.com/NetworkBlockDevice/nbd/compare/nbd-3.15.1...master
> > 
> > This patch series includes:
> > 
> > - The fix for this bug, commit a43a2d8;
> > - Several minor documentation fixes (e.g., fixed the sorting of a listing 
> > in a
> >   man page);
> > - A better fix for the issue of nbd-client-udeb being compiled against 
> > GnuTLS
> >   that does not break the build on kFreeBSD etc;
> > - The ability to change the GnuTLS priority string, to follow TLS best
> >   practices and allow people to lock down the TLS configuration
> > 
> > I would like to update nbd to that version; but if the release team
> > prefers, I can cherry-pick a43a2d8 onto 3.15.1 and upload that instead.
> > 
> 
> Thanks for getting back to me on this.
> 
> On the note of the actual changes, could you please provide a (source)
> debdiff, so I know what we are looking at?

Attached.

Unfortunately, there's a bit of churn because I forgot to rename
nbd-3.15.1.tar.gz to nbd_3.15.1.orig.tar.gz, thereby causing it to be
uploaded as a native package, with a bit of stuff that shouldn't have
been in there. At least it didn't contain random junk like in the past,
but a .gitignore, some autotools metadata files, as well as a few files
that are meant to be shipped as symlinks rather than copies of files
from elsewhere in the tree (e.g., tests/run/buffer.c) do show up in the
debdiff.

If you ignore those, what remains is the changelog entry plus the
changes that I pointed to earlier.

Thanks for looking at this,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12
diff -Nru nbd-3.15.1/debian/changelog nbd-3.15.2/debian/changelog
--- nbd-3.15.1/debian/changelog 2016-12-20 20:36:11.0 +0100
+++ nbd-3.15.2/debian/changelog 2017-02-22 09:10:22.0 +0100
@@ -1,3 +1,12 @@
+nbd (1:3.15.2-1) unstable; urgency=medium
+
+  * New upstream release
+- Fixes data corruption with multiple threads and copyonwrite enabled;
+  Closes: #852288, #849504. Why did I create multiple bugs for this?
+  Ah well, no matter.
+
+ -- Wouter Verhelst <wou...@debian.org>  Wed, 22 Feb 2017 00:09:31 +0100
+
 nbd (1:3.15.1-2) unstable; urgency=medium
 
   * Build nbd-client a second time with GnuTLS disabled, and install
diff -Nru nbd-3.15.1/.deps/libcliserv_la-cliserv.Plo 
nbd-3.15.2/.deps/libcliserv_la-cliserv.Plo
--- nbd-3.15.1/.deps/libcliserv_la-cliserv.Plo  2016-12-20 20:36:11.0 
+0100
+++ nbd-3.15.2/.deps/libcliserv_la-cliserv.Plo  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-# dummy
diff -Nru nbd-3.15.1/.deps/libnbdsrv_la-nbdsrv.Plo 
nbd-3.15.2/.deps/libnbdsrv_la-nbdsrv.Plo
--- nbd-3.15.1/.deps/libnbdsrv_la-nbdsrv.Plo2016-12-20 20:36:11.0 
+0100
+++ nbd-3.15.2/.deps/libnbdsrv_la-nbdsrv.Plo1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-# dummy
diff -Nru nbd-3.15.1/.deps/libnbdsrv_la-treefiles.Plo 
nbd-3.15.2/.deps/libnbdsrv_la-treefiles.Plo
--- nbd-3.15.1/.deps/libnbdsrv_la-treefiles.Plo 2016-12-20 20:36:11.0 
+0100
+++ nbd-3.15.2/.deps/libnbdsrv_la-treefiles.Plo 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-# dummy
diff -Nru nbd-3.15.1/.deps/make-integrityhuge.Po 
nbd-3.15.2/.deps/make-integrityhuge.Po
--- nbd-3.15.1/.deps/make-integrityhuge.Po  2016-12-20 20:36:11.0 
+0100
+++ nbd-3.15.2/.deps/make-integrityhuge.Po  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-# dummy
diff -Nru nbd-3.15.1/.deps/nbd_client-buffer.Po 
nbd-3.15.2/.deps/nbd_client-buffer.Po
--- nbd-3.15.1/.deps/nbd_client-buffer.Po   2016-12-20 20:36:11.0 
+0100
+++ nbd-3.15.2/.deps/nbd_client-buffer.Po   1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-# dummy
diff -Nru nbd-3.15.1/.deps/nbd_client-crypto-gnutls.Po 
nbd-3.15.2/.deps/nbd_client-crypto-gnutls.Po
--- nbd-3.15.1/.deps/nbd_client-crypto-gnutls.Po2016-12-20 
20:36:11.0 +0100
+++ nbd-3.15.2/.deps/nbd_client-crypto-gnutls.Po1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-# dummy
diff -Nru nbd-3.15.1/.deps/nbd_client-nbd-client.Po 
nbd-3.15.2/.deps/nbd_client-nbd-client.Po
--- nbd-3.15.1/.deps/nbd_client-nbd-client.Po   2016-12-20 20:36:11.0 
+0100
+++ nbd-3.15.2/.deps/nbd_client-nbd-client.Po   1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-# dummy
diff -Nru nbd-3.15.1/.deps/n

Bug#760414: [ola] Source package includes non-source files without corresponding source

[Wouter Verhelst]

Hi Ben,

Sorry for the late reply; I've been fighting a viral infection for the past
week+

On Wed, Feb 15, 2017 at 12:21:53AM +1100, Ben Finney wrote:
> Control: reassign -1 src:ola
> Control: retitle -1 ola: Source package includes non-source files without 
> corresponding source
> 
> On 14-Feb-2017, Wouter Verhelst wrote:
> > If the FTP team explains to me why that is a DFSG violation, I'll
> > add the "missing" files. If they don't, things will remain as they
> > are (and if they don't but do change severities, I'll ask the TC to
> > rule).
> 
> This surprises me. Do you mean to imply that only the FTP Master team
> can bring reasoned argument to convince you?

At this point in the release, yes.

> That you would reject such reasons if they came from different people?

I would not reject them if they were well presented.

> I ask because I am confident you're amenable to rational discussion
> about bugs, regardless of who presents those reasons. I hope that's
> right.

That's certainly right.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#849504: Data corruption with copy-on-write and multiple threads

[Wouter Verhelst]

On Tue, Feb 14, 2017 at 04:41:00PM +, Niels Thykier wrote:
> Wouter Verhelst:
> > Hi Niels,
> > 
> > On Sun, Feb 12, 2017 at 08:52:00AM +, Niels Thykier wrote:
> >> Any news on this bug?
> > 
> > I'm going to release (upstream) nbd 3.15.2 later this week (probably on
> > thursday), which contains the fix:
> > 
> > https://github.com/NetworkBlockDevice/nbd/compare/nbd-3.15.1...master
> > 
> > This patch series includes:
> > 
> > - The fix for this bug, commit a43a2d8;
> > - Several minor documentation fixes (e.g., fixed the sorting of a listing 
> > in a
> >   man page);
> > - A better fix for the issue of nbd-client-udeb being compiled against 
> > GnuTLS
> >   that does not break the build on kFreeBSD etc;
> > - The ability to change the GnuTLS priority string, to follow TLS best
> >   practices and allow people to lock down the TLS configuration
> > 
> > I would like to update nbd to that version; but if the release team
> > prefers, I can cherry-pick a43a2d8 onto 3.15.1 and upload that instead.
> > 
> 
> Thanks for getting back to me on this.
> 
> On the note of the actual changes, could you please provide a (source)
> debdiff, so I know what we are looking at?

Will do. This will probably be for the weekend.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#849504: Data corruption with copy-on-write and multiple threads

[Wouter Verhelst]

Hi Niels,

On Sun, Feb 12, 2017 at 08:52:00AM +, Niels Thykier wrote:
> Any news on this bug?

I'm going to release (upstream) nbd 3.15.2 later this week (probably on
thursday), which contains the fix:

https://github.com/NetworkBlockDevice/nbd/compare/nbd-3.15.1...master

This patch series includes:

- The fix for this bug, commit a43a2d8;
- Several minor documentation fixes (e.g., fixed the sorting of a listing in a
  man page);
- A better fix for the issue of nbd-client-udeb being compiled against GnuTLS
  that does not break the build on kFreeBSD etc;
- The ability to change the GnuTLS priority string, to follow TLS best
  practices and allow people to lock down the TLS configuration

I would like to update nbd to that version; but if the release team
prefers, I can cherry-pick a43a2d8 onto 3.15.1 and upload that instead.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#760414: [ola] This a serious bug

[Wouter Verhelst]

control: severity -1 wishlist

On Sun, Feb 12, 2017 at 03:50:15PM +0100, Bastien ROUCARIÈS wrote:
> Package: ola
> control: severity -1 serious
> 
> This a serious  bug. See ftpmaster statement

You are not a member of the ftpmaster team. I have explained my opinion
on this matter, and unless someone who is a member of the ftpmaster team
changes the severity of this bug, it is going to remain as wishlist. If
they do, all I'll be doing at this stage of the release is to just pick
the relevant upstream non-minified javascript libraries and add them to
the diff.gz.

Just to reiterate, this is my position:

- The javascript libraries in question *are* free (whether in source or
  minified form);
- They are shipped by (ola's) upstream as unmodified convenience copies
  of the (javascript library's) upstream minified versions of said
  javascript libraries;
- They are *also* shipped by Debian in the relevant libjs-* packages;
- The relevant libjs-* packages are what is in fact being used by the
  ola package.

I have yet to see a convincing argument how all of the above *combined*
constitutes either a DFSG violation, or something that fails SC#4.

If the FTP team explains to me why that is a DFSG violation, I'll add
the "missing" files. If they don't, things will remain as they are (and
if they don't but do change severities, I'll ask the TC to rule).

Alternatively, if someone can convince me that it fails SC#4 in some
way, I'll consider "fixing" this bug.

Meanwhile, please stop playing BTS severity pingpong.

Thanks.


-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#849504: Data corruption with copy-on-write and multiple threads

[Wouter Verhelst]

Hi,

On Sun, Jan 29, 2017 at 12:59:35PM +, Jonathan Wiltshire wrote:
> Hi,
> 
> On Wed, Dec 28, 2016 at 12:33:51AM +0100, Wouter Verhelst wrote:
> > We should not release Debian with this bug present; however, I don't
> > want to fix this right now, or 1:3.15.1-1 will miss the freeze cutoff.
> > I'll upload a package as soon as that version migrates to testing.
> 
> nbd 1:3.15.1-1 and then 1:3.15.1-2 migrated on 2016-12-31, so that should
> leave the way clear to fixing this.

Yes; a fix has been committed upstream. I was waiting for the reporter
to help check it, but haven't gotten any response so far.

I'm currently swamped with helping organize FOSDEM (which is next
weekend), but I'll do those tests myself after that if it hasn't
happened yet, and then do the upload.

(I'm also an idiot, in that I filed this bug again, but ah well, I'll
just merge them before uploading)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#852288: Data corruption when multiple threads are allowed and copyonwrite is enabled

[Wouter Verhelst]

Package: nbd-server
Version: 1:3.12-0
Severity: grave
Tags: upstream
Forwarded: https://github.com/NetworkBlockDevice/nbd/issues/43

There's a data corruption bug in nbd which has existed since the
upstream release of 3.12. We should not release nbd in stretch with that
bug.

I have a preliminary fix, but it needs some testing. However, I'm
currently swamped with other work, and this has gone to the backburner a
bit. Since I don't want to forget about this issue, filing a bugreport
in the Debian BTS should help.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

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

Versions of packages nbd-server depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.60
ii  libc6  2.24-9
ii  libglib2.0-0   2.50.2-2
ii  libgnutls303.5.8-1
ii  ucf3.0036

nbd-server recommends no packages.

nbd-server suggests no packages.

-- debconf information excluded

Bug#849504: Data corruption with copy-on-write and multiple threads

[Wouter Verhelst]

Package: nbd-server
Version: 1:3.12-1
Severity: serious
Forwarded: https://github.com/NetworkBlockDevice/nbd/issues/43

A bug was reported upstream in nbd upstream when combining copy-on-write
and multiple threads. The latter was a new feature for nbd 3.12, and the
bug was always present since that implementation of multiple threads, so
filing this bug on the version that introduced it into Debian.

We should not release Debian with this bug present; however, I don't
want to fix this right now, or 1:3.15.1-1 will miss the freeze cutoff.
I'll upload a package as soon as that version migrates to testing.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

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

Versions of packages nbd-server depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  libglib2.0-0   2.50.2-2
ii  libgnutls303.5.7-3
ii  ucf3.0036

nbd-server recommends no packages.

nbd-server suggests no packages.

-- debconf information excluded

Bug#848862: nbd-client-udeb: no longer installable: depends on non-udeb libgnutls30

[Wouter Verhelst]

On Tue, Dec 20, 2016 at 10:49:27AM +0100, Cyril Brulebois wrote:
> Package: nbd-client-udeb
> Version: 1:3.15-1
> Severity: grave
> Tags: d-i
> Justification: renders package unusable
> 
> Hi,
> 
> Our dose d-i checker[1] detected this regression: nbd-client-udeb is no
> longer installable since it now depends on a deb (not udeb) package:
> libgnutls30.

Oops -- sorry about that.

> Please keep debian-b...@lists.debian.org (X-D-Cc'd) in the loop when
> replying.

The proper fix here is to build nbd-client twice; once with gnutls enabled,
once without -- and to package the latter in the udeb. I've just done
that, will upload ASAP.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#836383: FTBFS on mips*

[Wouter Verhelst]

Package: ola
Version: 0.10.2-2
Severity: serious
Tags: upstream
Control: forwarded -1 https://github.com/OpenLightingProject/ola/pull/1116

ola currently FTBFS on mips* due to some include mixups. This has been
reported upstream, and a fix is pending

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#835477: depends on libnotmuch3, not available in unstable

[Wouter Verhelst]

Package: mutt
Version: 1.6.2-3
Severity: serious

Hi,

My system wants to update mutt to 1.6.2-3, but that depends on
libnotmuch3, whereas in unstable, that should now be libnotmuch4
instead.

As such, it tries to install libnotmuch3 from jessie, which wants to
pull in libxapian22 (conflicting with libxapian22v5), resulting in
things not going so well.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

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

Versions of packages mutt is related to:
ii  mutt  1.6.2-2

Bug#815004: Engine is installed at wrong location

[Wouter Verhelst]

Package: libengine-pkcs11-openssl
Version: 0.2.1-1
Severity: grave
Justification: makes the package in question unusable

Hi,

After installing libengine-pkcs11-openssl, the following happens:

wouter@gangtai:~$ openssl engine pkcs11 -t
139772252497552:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
the shared 
library:dso_dlfcn.c:187:filename(/usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libpkcs11.so):
 /usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libpkcs11.so: cannot open 
shared object file: No such file or directory
139772252497552:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:232:
139772252497552:error:260B6084:engine routines:DYNAMIC_LOAD:dso not 
found:eng_dyn.c:465:
139772252497552:error:2606A074:engine routines:ENGINE_by_id:no such 
engine:eng_list.c:390:id=pkcs11

This is because libengine-pkcs11-openssl writes its engine files to
/usr/lib/ssl/engines rather than the location where current OpenSSL
looks for engines.

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

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

Versions of packages libengine-pkcs11-openssl depends on:
ii  libc62.21-8
ii  libp11-2 0.3.1-1
ii  libssl1.0.2  1.0.2f-2

libengine-pkcs11-openssl recommends no packages.

libengine-pkcs11-openssl suggests no packages.

-- no debconf information

Bug#813164: This is, in fact, dangerous

[Wouter Verhelst]

On Tue, Feb 16, 2016 at 10:32:48AM +0100, Ansgar Burchardt wrote:
> Wouter Verhelst <w...@uter.be> writes:
> > With the ls version before this change, J. Random Inexperienced Hacker
> > would see that there are multiple file names on a single line in the
> > output of ls, decide that ls output is too difficult to parse, and move
> > on to something else (probably find or some such).
> >
> > With the ls version after this change, J. Random Inexperienced Hacker
> > might decide that the quoted nature of the ls output is *ideal* for
> > parsing, add something along the lines of
> > INPUT=$(ls /path/to/input/directory)
> > to his script, and think he's safe against filenames with spaces in them
> > ("because ls quotes output").
> 
> J Random Inexperienced Hacker already does this in the present day
> though.

Well, yes, possibly.

> > The default enabling of the -C option when ls is connected to a terminal
> > doesn't do harm (and in fact discourages this kind of unsafe behaviour).
> > However, showing characters that aren't part of a filename in ls output
> > *by default* is confusing and (as the above shows) potentially
> > dangerous.
> 
> ls already showed characters that aren't part of a filename *before*
> this change:
> 
>   $ ls /tmp/a
>   a  a
> 
> Neither filename contains a question mark, and the filenames are
> actually not identical.

True, but that's because you created the file name in one locale and
tried to access it from another. I doubt that's going to happen to our
inexperienced hacker.

Even so, that actually reinforces my argument. My point was not about
adding random characters or changing some out, but about adding quoting
(forgive me for the imprecise wording, I hadn't had my coffee yet).

> One could argue that "ls" should give an error when it encounters any
> character that might need quoting instead of enabling quoting by
> default. (And this is probably also true when output does not go to a
> terminal: at least printing \n as part of a filename is pretty much
> always broken.)

Indeed.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#813164: This is, in fact, dangerous

[Wouter Verhelst]

A change like this invites security bugs:

J. Random Inexperienced Hacker writes a shell script.

He doesn't know that there is such a thing as the isatty() system call,
and therefore doesn't realize that it is even *possible* to change the
output of a command based on whether standard output refers to a
terminal (I know this described me for about two or three years after I
first started using Unix-like systems).

With the ls version before this change, J. Random Inexperienced Hacker
would see that there are multiple file names on a single line in the
output of ls, decide that ls output is too difficult to parse, and move
on to something else (probably find or some such).

With the ls version after this change, J. Random Inexperienced Hacker
might decide that the quoted nature of the ls output is *ideal* for
parsing, add something along the lines of
INPUT=$(ls /path/to/input/directory)
to his script, and think he's safe against filenames with spaces in them
("because ls quotes output").

The default enabling of the -C option when ls is connected to a terminal
doesn't do harm (and in fact discourages this kind of unsafe behaviour).
However, showing characters that aren't part of a filename in ls output
*by default* is confusing and (as the above shows) potentially
dangerous.

Please revert this change.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#813164: alias ls='ls -N' is not a solution

[Wouter Verhelst]

On Wed, Feb 03, 2016 at 05:41:14PM -0800, Pádraig Brady wrote:
> On 03/02/16 06:05, Adam Borowski wrote:
> > Also, the proposed workaround, "alias ls='ls -N'" doesn't act reasonably.
> > It disables _all_ quoting, including nasty unprintable characters.  When the
> > output goes to the terminal, it is meant to be read by a human.  Humans can
> > read spaces and apostrophes just fine, they can't read \1 or broken UTF-8.
> 
> `ls -N` does revert to the previous behaviour.
> I.E. weird chars are replaced with ?

In that case, the documentation is wrong. From the man page:

   -N, --literal
  print raw entry names (don't treat e.g. control characters 
specially)

That's not what this does. Printing a control character as '?' *is*
treating it specially. Currently, -N behaves as I would expect -q to
behave. Apparently there's no way to ask ls to not process filenames *at
all*. That's just wrong.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#813479: file conflicts without conflicts: header

[Wouter Verhelst]

Package: alsa-utils
Version: 1.0.29-1+b1
Severity: serious

Hi,

A recent version of the alsa-utils package apparently introduced a new binary,
which conflicts with bacula-console-qt:

root@gangtai:~# LC_ALL=C apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  alsa-utils
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/998 kB of archives.
After this operation, 41.0 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Reading changelogs... Done
(Reading database ... 339977 files and directories currently installed.)
Preparing to unpack .../alsa-utils_1.1.0-1_amd64.deb ...
Unpacking alsa-utils (1.1.0-1) over (1.0.29-1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/alsa-utils_1.1.0-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/bat.1.gz', which is also in package 
bacula-console-qt 7.0.5+dfsg-4
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/alsa-utils_1.1.0-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@gangtai:~# 


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

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

Versions of packages alsa-utils depends on:
ii  dialog  1.2-20150920-1
ii  kmod22-1
iu  libasound2  1.1.0-1
ii  libc6   2.21-7
ii  libncursesw56.0+20151024-2
ii  libsamplerate0  0.1.8-8
ii  libtinfo5   6.0+20151024-2
ii  lsb-base9.20160110
ii  whiptail0.52.18-2

alsa-utils recommends no packages.

alsa-utils suggests no packages.

-- no debconf information

Bug#728441: Now FTBFS everywhere

[Wouter Verhelst]

Source: mozart
Followup-For: Bug #728441

Hi,

Mozart now fails to build on all architectures, since it build-depends
on emacs23, which is no longer a thing (at least not in Debian).

Please update it to build-depend on modern emacs versions.

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

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

Bug#778038: Will be fixed soon

[Wouter Verhelst]

This has been reported and fixed upstream. I'm currently waiting for the
0.9.6 release, which upstream tells me is imminent; once that has
happened, I'll do an upload.

It feels silly to do an upload of 0.9.5 today and to another upload of
0.9.6 next week.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


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

Bug#785642: queue runner dies with uncaught UnicodeDecodeError

[Wouter Verhelst]

Package: mailman
Version: 1:2.1.18-2
Severity: grave
Justification: causes data loss

Hi,

I received a message from one of my list admins that he couldn't send a
mail to his list. Investigating turned up the following in
/var/log/mailman/error:

May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't decode 
byte 0xe9 in position 18: invalid continuation byte
May 17 15:32:20 2015 (981) Traceback (most recent call last):
  File /var/lib/mailman/Mailman/Queue/Runner.py, line 119, in _oneloop
self._onefile(msg, msgdata)
  File /var/lib/mailman/Mailman/Queue/Runner.py, line 190, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
  File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 130, in _dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 153, in 
_dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
  File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 239, in process
i18ndesc = uheader(mlist, mlist.description, 'List-Id', maxlinelen=998)
  File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 65, in uheader
return Header(s, charset, maxlinelen, header_name, continuation_ws)
  File /usr/lib/python2.7/email/header.py, line 183, in __init__
self.append(s, charset, errors)
  File /usr/lib/python2.7/email/header.py, line 267, in append
ustr = unicode(s, incodec, errors)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 18: invalid 
continuation byte

May 17 15:32:20 2015 (981) SHUNTING: 
1431869540.389822+156779307d54473d0eb732994bb67eee95733285

I'm not sure why mailman needs to decode the data in the mail as part of
running the queue, but at any rate that shouldn't case the mail to get
lost...

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mailman depends on:
ii  apache2 [httpd]  2.4.10-10
ii  apache2-mpm-prefork [httpd]  2.4.10-10
ii  cron 3.0pl1-127
ii  debconf [debconf-2.0]1.5.56
ii  libc62.19-18
ii  logrotate3.8.7-1+b1
ii  lsb-base 4.1+Debian13+nmu1
ii  python-dnspython 1.12.0-1
pn  python:any   none
ii  ucf  3.0030

Versions of packages mailman recommends:
ii  exim4-daemon-heavy [mail-transport-agent]  4.84-8

Versions of packages mailman suggests:
pn  listadmin none
pn  lynx  none
ii  spamassassin  3.4.0-6

-- debconf information:
* mailman/create_site_list:
* mailman/used_languages: en fr nl
* mailman/gate_news: false
* mailman/default_server_language: fr
  mailman/queue_files_present: abort installation
* mailman/site_languages: fr, en, nl


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

Bug#767676: ola-rdm-tests: fails to install: subprocess installed post-installation script returned error exit status 10

[Wouter Verhelst]

On Sat, Nov 22, 2014 at 11:00:18AM +0100, Jean Baptiste Favre wrote:
 Hello,
 Please find attached a new version of the patch.
 
 This time, I:
 - added a debian/repack.sh script to rebuild orig.tar.gz file removing
 tools/rdm/static/jquery-1.7.2.min.js and
 tools/rdm/static/jquery-ui-1.8.21.custom.min.js
 - Added a debian/README.source to explain how to get source tree ready
 
 This closes #760414.

Please hold on that part until the discussion with ftpmaster is over.

Everything else is fine.

Thanks for your work,

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


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

Bug#767676: ola-rdm-tests: fails to install: subprocess installed post-installation script returned error exit status 10

[Wouter Verhelst]

On Thu, Nov 20, 2014 at 10:42:23PM +0100, Helmut Grohne wrote:
 Hi Wouter and Jean Baptiste,
 
 On Wed, Nov 19, 2014 at 11:35:50PM +0100, Wouter Verhelst wrote:
  On Tue, Nov 18, 2014 at 01:48:04PM +0100, Jean Baptiste Favre wrote:
   * Remove debconf calls from ola-rdm-tests postinst. (Closes: #767676)
   * Fix other seriouys issues:
 - Provides missing /etc/default/ola from ola postinst script to allow
   olad service control in the same way rdm_test_server is
  
  NAK. /etc/default/* to manage service status is a menace, and should be
  forbidden.
 
 Wouter, please bear in mind, that it is not the proposed NMU that is
 adding the need for an /etc/default/ola file. The current init script
 (debian/ola.olad.init) sources /etc/default/ola and doesn't start at all
 when it does not exist. This puts you in a bad position to demand
 otherwise.

Yes, I had missed that, sorry.

 Given the other things you said, I assume that it is not your intention
 for the init script to check for $RUN_DAEMON at all. (The issue is
 duplicated in the init script of ola-rdm-tests.)
 
 I suggest the following approach then:
 
  * Remove the check for $RUN_DAEMON from both init scripts (olad and
rdm_test_server).
  * Do not ship the default files in either package.
  * Keep sourcing /etc/default/ola{,-rdm-tests} so users can change e.g.
$DAEMON_ARGS.
 
 Optionally:
  * During upgrade, check whether the default files were unmodified (by
comparing their md5sum to known values) and if they are unmodified,
remove them.
 
 Wouter, do you agree with this approach?

Certainly.

[...]
-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


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

Bug#767676: ola-rdm-tests: fails to install: subprocess installed post-installation script returned error exit status 10

[Wouter Verhelst]

On Tue, Nov 18, 2014 at 01:48:04PM +0100, Jean Baptiste Favre wrote:
 Hello Helmut,
 
 Please find attached anew version for the patch.
 
 Here is what I fixed:
 
 * Remove debconf calls from ola-rdm-tests postinst. (Closes: #767676)
 * Fix other seriouys issues:
   - Provides missing /etc/default/ola from ola postinst script to allow
 olad service control in the same way rdm_test_server is

NAK. /etc/default/* to manage service status is a menace, and should be
forbidden.

(it isn't currently, so I'm not filing bugs on other packages, but I
think it's *wrong*, and I don't want it in mine)

This is why I removed the debconf and /etc/default stuff from the
package provided by upstream before I uploaded to Debian (or at least,
tried to ;-). What's still there can remain, but will probably be
dropped for jessie+1. As long as your fixes are applied, of course.

   - Update init scripts to change advice to enable olad 
 drm_test_server services (dpkg-reconfigure won't work without debconf)
   - add postrm scripts for packages ola  ola-rdm-tests to fully remove
 configuration files  dirs so that piuparts tests can pass
 
 As you asked:
 
 - I didn't changed configuration file names. I thought this was a bit
 out of scope, you confirmed :)
 - packages pass piuparts tests (I tested .changes file with
 --no-upgrade-test since jessie package fails to install)
 
 I also documented verbosely changes in changelog as requested by [1]
 
 Please let me know wheter the work is satisfying or I need to iterate more.
 
 Regards,
 Jean Baptiste
 
 [1] https://release.debian.org/jessie/freeze_policy.html
 
 On 18/11/2014 08:15, Helmut Grohne wrote:
  On Mon, Nov 17, 2014 at 11:42:54PM +0100, Jean Baptiste Favre wrote:
  Thanks for your advice. I'm working on a new version of the patch.
  In the meantime, what should I do with my already uploaded NMU (on
  mentors.debian.net). Maybe I should delete it just to be sure nobody
  will upload it ?
  
  You can do that.
  
  I also noticed that init scripts ask for dpkg-reconfigure package to
  enable service start, which is disabled by default. I guess this was OK
  when debconf handles /etc/default/package content, but obviously it
  won't work anymore.
  I can change the init script to display another message.
  
  This sounds like a documentation fix. Currently, this should be covered
  by the freeze policy. So fixing it should be ok for now.
  
  Finally, I'm considering shipping /etc/default/ola which is not shipped
  currently, in the same way as /etc/default/ola-rdm-tests. It controls
  whether olad service is enabled or not.
  
  This sounds like a functional change. While it looks like an
  improvement, I do not yet see why this should be release critical. So
  better skip this for the upload targeting jessie, but you can prepare a
  separate .debdiff for Wouter to apply later if you like. (Better create
  a new bug report at lower severity then.)
  
  And, last question, speaking about /etc/default files, I wonder which
  are the best practices:
  - name /etc/default/xxx file according to the init script which will use
  them
  - name /etc/default/xxx file according to the package which provide them
 
  In my case, /etc/default/ola is provided by ola package but controls
  olad service. Same with /etc/default/ola-rdm-tests which is provided by
  eponym package to control rdm_test_server service.
 
  All these would indeed increase the overall package quality, but I
  wonder if this is not a bit out of scope work considering Jessie freeze.
  
  You are rightly wondering. These changes are likely not acceptable for
  jessie.
  
  It looks to me that you are looking a bit too far at the moment. This
  bug was found using piuparts. After applying your initial .debdiff,
  piuparts still rightfully complains (about other things). This is why I
  asked you to reiterate. Nothing more.
  
  Helmut
 

 diff -Nru ola-0.9.1/debian/changelog ola-0.9.1/debian/changelog
 --- ola-0.9.1/debian/changelog2014-08-17 10:07:29.0 +0200
 +++ ola-0.9.1/debian/changelog2014-11-18 09:47:02.0 +0100
 @@ -1,3 +1,17 @@
 +ola (0.9.1-1.1) unstable; urgency=medium
 +
 +  * Non-maintainer upload.
 +  * Remove debconf calls from ola-rdm-tests postinst. (Closes: #767676)
 +  * Fix other seriouys issues:
 +- Provides missing /etc/default/ola from ola postinst script to allow
 +  olad service control in the same way rdm_test_server is
 +- Update init scripts to change advice to enable olad  drm_test_server
 +  services (dpkg-reconfigure won't work without debconf)
 +- add postrm scripts for packages ola  ola-rdm-tests to fully remove
 +  configuration files  dirs so that piuparts tests can pass
 +
 + -- Jean Baptiste Favre deb...@jbfavre.org  Sun, 16 Nov 2014 17:44:18 +0100
 +
  ola (0.9.1-1) unstable; urgency=low
  
* New upstream release
 diff -Nru ola-0.9.1/debian/ola.olad.init ola-0.9.1/debian/ola.olad.init
 --- 

Bug#767676: ola-rdm-tests: fails to install: subprocess installed post-installation script returned error exit status 10

[Wouter Verhelst]

On Sun, Nov 16, 2014 at 06:12:56PM +0100, Jean Baptiste Favre wrote:
 Hello,
 I had a look on it during Debian BSP in Paris.
 
 Problem is located into ola-rdm-test.postinst script:
 - It uses debconf, for variable ola-rdm-tests/daemon, without providing
 any template file
 - It uses db_get and never db_input, thus ola-rdm-tests/daemon is never set
 - debconf is not mentioned as dependency
 
 Please find attached a patch which removes debconf usage from postinst
 script.

Thanks.

Feel free to NMU; I do need to talk to debian-release about some other things,
but this should be straightforward enough that it shouldn't interfere with
that.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


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

Bug#769670: ola-rdm-tests: FTBFS in a sid chroot with pbuilder (no network)

[Wouter Verhelst]

On Sat, Nov 15, 2014 at 02:46:10PM +0100, Pitamila wrote:
 Package: ola-rdm-tests
 Version: 0.9.1-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 Dear Maintainer,
 
 see pbuilder log below:
 
 InterfacePickerTest.cpp:67:Assertion
 Test name: InterfacePickerTest::testGetInterfaces
 assertion failed
 - Expression: interfaces.size()  0
 
 Failures !!!
 Run: 21   Failure total: 1   Failures: 1   Errors: 0
 FAIL: NetworkTester

Can you give some detail on what the network looked like for this build?

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


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

Bug#760414: [ola] Some sources are not included in your package

[Wouter Verhelst]

severity 760414 wishlist
tags 760414 + wontfix
thanks

Hi Bastien,

On Wed, Sep 03, 2014 at 10:24:44PM +, bastien ROUCARIES wrote:
 Hi,
 
 Your package seems to include some files that lack sources
 in prefered forms of modification:
 
 tools/rdm/static/jquery-1.7.2.min.js
 tools/rdm/static/jquery-ui-1.8.21.custom.min.js

These are not used. Instead, the package replaces them with symlinks to
the same files from the jquery package, and depends on them.

In my reading of the DFSG, this satisfies DFSG#2.

 According to Debian Free Software Guidelines [1] (DFSG) #2:
  The program must include source code, and must allow distribution 
   in source code as well as compiled form..

Correct.

That does not say the program must not include convenience copies of
other free software which is shipped without source. I see no problem
here.

jquery is _used by_ ola, in very much the same way that libc and
libstdc++ are used by it as well. The source to jquery is therefore not
part of the source to ola, and I see no need to either ship its source,
or remove it from the package.

I agree that would be necessary in case jquery were non-free software.
That is not the case, however.

 This could also constitute a license violation for some copyleft
 licenses such as the GNU GPL.

JQuery has the MIT license as an alternate option, according to its
copyright file, so that's not relevant.

[...]

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Bug#757448: Trademark status

[Wouter Verhelst]

On Sat, Aug 09, 2014 at 10:46:28AM +0900, mejiko wrote:
 Pong:
 
 http://tsdr.uspto.gov/#caseNumber=76148525caseType=SERIAL_NOsearchType=statusSearch
 
 
 Matrix:
 
 http://tsdr.uspto.gov/#caseNumber=85243232caseType=SERIAL_NOsearchType=statusSearch
 
 http://tsdr.uspto.gov/#caseNumber=78135234caseType=SERIAL_NOsearchType=statusSearch
 
 
 Pacman:
 
 http://tsdr.uspto.gov/#caseNumber=76638049caseType=SERIAL_NOsearchType=statusSearch

Jamie did not contest that these are trademarks. He claimed that it's fair use.

http://en.wikipedia.org/wiki/Fair_use_(US_trademark_law)

If you believe otherwise, you should point out why the use of these
trademarks is not fair use in this content, not that they are trademarks
(which nobody is contesting).

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Bug#735258: tests fail on all 32bit architectures

[Wouter Verhelst]

tags 735258 + upstream fixed-upstream
thanks

Fix is in

http://sourceforge.net/p/nbd/code/ci/4f3b3efef0ec259afc65c5ebc6d260e60721adec/ 
and
http://sourceforge.net/p/nbd/code/ci/a3edeb4d4ee4a387fe2a5b08268c0e99c0df4c30/

On Tue, Jan 14, 2014 at 08:07:21AM +0100, Matthias Klose wrote:
 Package: src:nbd
 Version: 1:3.6-1
 Severity: serious
 Tags: sid jessie
 
 see https://buildd.debian.org/status/package.php?p=nbd
 

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


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

Bug#665199: slapd: fails to install, remove, distupgrade, and install again

[Wouter Verhelst]

On Mon, Feb 11, 2013 at 11:59:34PM +0100, Andreas Beckmann wrote:
 Still reproducible when installing 2.4.31-1 over 2.4.23-7.2 in
 config-files-remaining state.

Yes, but only because you used -7.2. With -7.3 (which, with the new
point release out, now finally is available in stable), you won't have
that problem.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


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

Bug#681227: Can anyone reproduce #681227: installation-reports: grub-install tries to install to a nonsense string?!

[Wouter Verhelst]

retitle 681227 does not validate free-form input
thanks

On Mon, Jan 07, 2013 at 05:54:03PM +, Steven Chamberlain wrote:
 Hi Matthew,
 
 On 07/01/13 17:15, Matthew Vernon wrote:
  Jul 10 16:48:43 in-target: grub-common is already the newest version.
  Jul 10 16:48:43 in-target: 0 upgraded, 0 newly installed, 0 to remove
  and 0 not upgraded.
  Jul 11 07:56:28 grub-installer: info: Installing grub on '/dev/sdb 
  w33sxs34rfvbg789iokm·']'
 
  On 02/01/13 22:49, Steven Chamberlain wrote:
  To the original submitter of the bug report:  do you have a cat?
  
  No. The machine is my work desktop. I do have a QWERTY keyboard
  [...] I don't know how one might
  have gotten a middot out of it!
 
 I've just learned that at least with my keyboard layout (gb), AltGr +
 period will type the interpunct/middot, in Xorg or from a Linux
 terminal.  Those keys are more or less adjacent too.
 
  That said, I cannot eliminate the
  possibility that a cleaner was overzealous or similar, but it seems
  unlikely...?
 
 I'm convinced this is the explanation.  The installer was stuck at a
 GRUB prompt for boot devices overnight;  then at 07:56 (usually
 'accurate', but might not be in the local timezone) GRUB proceeded
 trying to install to:
 
 w33 sxs 34rfvbg ... 789iokm ·']
 
 This seems to fit with down/up sweeps across a QWERTY keyboard with
 one's cleaning cloth, proceeding from the left to right (so I would even
 guess that he/she is right-handed...).
 
 [The split on an ergo keyboard would be between the ...vbg and 789...
 sequences of keystrokes, and the closing square bracket is adjacent to
 the carriage return key].
 
 So I think this can be closed.

Almost.

 What to do with the workaround added by Wouter in grub-installer/1.84?

The workaround tried to eliminate the possibility of invalid data coming
from somewhere in the installer. I hadn't noticed the long delay in
the log; I had noticed the possibility of invalid input, but didn't
think you'd be silly enough to enter such a long string and not notice.
Of course, if the installer was running overnight, that changes matters.

So what I think needs to be done to fix this properly is to move the
check from where it is located right now to where we do the db_get for
the installer device. If what's been entered by the user doesn't look
like a hard disk device, we should display an error message and allow
the user to try again.

However, given we're this late in the freeze, and given that we've
already got the workaround in place (which should allow a retry by going
through the main menu), I'm not sure it's appropriate anymore to do this
right now.

I'll leave that decision to the d-i RM.

 It did trigger a couple of regressions initially, but those are fixed
 now in Git.
 
 Silently ignoring a failure seems risky when we know that it should not
 happen.  (Someone may want to specify multiple targets, and if one of
 them is typo'd it would be silently skipped in this case).

That's indeed the only case that isn't caught by the current code.
Still, first, this is a highly unusual installation type; and second,
even were it to occur, an easy workaround is to use the installer in
rescue mode and fix the boot set-up -- or fix it from the installed
system.

Again, it's not a perfect situation, but I'm not sure this is RC
anymore.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


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

Bug#696841: same for upload_queues

[Wouter Verhelst]

On Fri, Dec 28, 2012 at 02:49:58PM +, Thorsten Glaser wrote:
 Hi,
 
   $upload_queues = […];
 must also be changed into

What do you mean by changed? The example in my previous mail, as well
as on wiki.debian.org, shows that you need to use (), not [], to
construct the options...

if you misread and/or miscopy things, obviously they won't work ;-)

   @upload_queues = (…);
 otherwise one gets an error instead of an uploader:
 
 Can't call method get on unblessed reference at 
 /usr/share/perl5/Buildd/Uploader.pm line 69.

That's because you're passing an anonymous array reference rather than a
list as an array initializer, which doesn't work.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


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

Bug#677883: Package still not buildable

[Wouter Verhelst]

reassign 677883 ftp.debian.org
retitle 677883 RM: build-depends on removed package libtrilinos-dev

Hi,

This package still isn't buildable, because libtrilinos still isn't there yet.

Since this situation has been open for more than 6 months now, I think it's
time to remove this package from the archive as well. If libtrilinos is ever
re-uploaded, the maintainer can probably upload a new version of deal.ii, too.

Thanks,

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


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

Bug#665199: NMU diff for 2.4.23-7.3 uploaded to DELAYED/7

[Wouter Verhelst]

tags 665199 + pending
thanks

Hi,

As part of the BSP in Mechelen, I've just uploaded openldap 2.4.23-7.3
to DELAYED/7, targetted at stable. I've tested it by installing that
package in a stable chroot, and then upgrading it to unstable; the
database was successfully dumped and later restored by the version in
unstable.

I'll make sure to talk to the SRM and the release notes editors to take
appropriate action, but this should close this bug.

The diff that was applied is the following:

diff -u openldap-2.4.23/debian/slapd.preinst 
openldap-2.4.23/debian/slapd.preinst
--- openldap-2.4.23/debian/slapd.preinst
+++ openldap-2.4.23/debian/slapd.preinst
@@ -4,17 +4,6 @@
 
 . /usr/share/debconf/confmodule
 
-# This will be replaced with debian/slapd.scripts-common which includes
-# various helper functions and $OLD_VERSION and $SLAPD_CONF
-#SCRIPTSCOMMON#
-
-# If we are upgrading from an old version then stop slapd and attempt to
-# slapcat out the data so we can use it in postinst to do the upgrade
-
-if [ $MODE = upgrade ]; then
-   dump_databases
-fi
-
 #DEBHELPER#
 
 exit 0
diff -u openldap-2.4.23/debian/slapd.prerm openldap-2.4.23/debian/slapd.prerm
--- openldap-2.4.23/debian/slapd.prerm
+++ openldap-2.4.23/debian/slapd.prerm
@@ -4,6 +4,17 @@
 
 . /usr/share/debconf/confmodule
 
+# This will be replaced with debian/slapd.scripts-common which includes
+# various helper functions and $OLD_VERSION and $SLAPD_CONF
+#SCRIPTSCOMMON#
+
+# If we are upgrading from an old version then stop slapd and attempt to
+# slapcat out the data so we can use it in postinst to do the upgrade
+
+if [ $MODE = upgrade ]; then
+   dump_databases
+fi
+
 #DEBHELPER#
 
 exit 0
diff -u openldap-2.4.23/debian/changelog openldap-2.4.23/debian/changelog
--- openldap-2.4.23/debian/changelog
+++ openldap-2.4.23/debian/changelog
@@ -1,3 +1,10 @@
+openldap (2.4.23-7.3) stable; urgency=low
+
+  * Non-maintainer upload targeted at stable
+  * Dump the database in prerm if we're upgrading. Closes: #665199
+
+ -- Wouter Verhelst wou...@debian.org  Sun, 16 Dec 2012 12:44:59 +0100
+
 openldap (2.4.23-7.2) stable; urgency=low
 
   * Non-maintainer upload targeted at stable.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


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

Bug#681227: some analysis

[Wouter Verhelst]

On Sat, Dec 15, 2012 at 06:24:46PM +0100, Wouter Verhelst wrote:
 At this point, I'm tempted to add a check to the for loop that starts on
 line 650 in the current HEAD (commit 062ddbcb66150) for something along
 the lines of:
 
 if [ ! -b $bootdev ]; then
   # jump to the next loop iteration here
 fi

I've done that, but also added a check so that if this means we don't
actually install grub to any boot device, grub-installer will fail.

It's not a proper fix, so I didn't mark the change as closing this bug;
but I do plan to downgrade the severity (since it now no longer causes
the installation to fail) once it's been built everywhere.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


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

Bug#681227: some analysis

[Wouter Verhelst]

Hi,

I just spent a few hours trying to analyse this bug, but so far I
haven't found what could cause this.

The message 'Installing grub on ' is generated by this line:

info Installing grub on '$bootdev'

Obviously, this bootdev variable is what the entire rest of the script
is built to do, so figuring out where the garbage is coming from is
non-trivial.

I found two possibilities. The first is a line that looks like this:

mappedbootdev=$(mapdevfs $bootdev) || true

mapdevfs is part of debian-installer-utils, and is a fairly short file
which just calls a C function from libdebian-installer. I audited the
code which would seem to be called, but could not find any constructs
that might be suspicious or that could cause a C buffer overflow or
anything similar (which doesn't mean it doesn't exist, just that I
couldn't find one).

The second is the fact that grub-probe is called a few times, which is
also written in C. I didn't audit that code, but did find that when
called with invalid input, grub-probe would just segfault. For instance:

grub-probe '(hd0)'

segfaults with my current version of grub-probe (I filed a separate bug
on that). I didn't investigate its code, but it's not unfathomable that
some invalid input to grub-probe could generate garbage such as in this
bugreport. I don't know for sure, however, and ran out of time.

At this point, I'm tempted to add a check to the for loop that starts on
line 650 in the current HEAD (commit 062ddbcb66150) for something along
the lines of:

if [ ! -b $bootdev ]; then
# jump to the next loop iteration here
fi

which will not only protect against garbage, but also against trying to
install to devices that don't exist on this system.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


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

Bug#688639: sip no longer works since security upgrade

[Wouter Verhelst]

Package: asterisk
Version: 1:1.6.2.9-2+squeeze7
Severity: serious

Hi,

Since upgrading asterisk running on a guruplug to the above-referenced
version, trying to load the chan_sip.so module results in the following error
message:

salsa*CLI module load chan_sip.so 
Unable to load module chan_sip.so
Command 'module load chan_sip.so ' failed.
[Sep 24 13:43:02] WARNING[21332]: loader.c:435 load_dynamic_module: Error 
loading module 'chan_sip.so': /usr/lib/asterisk/modules/chan_sip.so: undefined 
symbol: sip_pvt_lock_full
[Sep 24 13:43:02] WARNING[21332]: loader.c:801 load_resource: Module 
'chan_sip.so' could not be loaded.

downgrading to 1:1.6.2.9-2+squeeze5 fixes the problem (but of course
reintroduces the security problem...)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


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

Bug#680100: libatomic-ops/powerpc: FTBFS: eats all disk space in the known universe (almost, anyway)

[Wouter Verhelst]

Package: libatomic-ops
Version: 7.3~alpha1+git20120701-1
Architecture: powerpc
Severity: serious

Hi,

Your package's failed to build on powerpc. The build itself actually
succeeded, but then in the test suite something went wrong:

Testing test_and_set
Succeeded
PASS: test_atomic
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
Testing store_release_write/load_acquire_read
Succeeded
Testing test_and_set
Succeeded
PASS: test_atomic_pthreads
Found duplicate list element 7
Found duplicate list element 7
Found duplicate list element 7
Found duplicate list element 7
Found duplicate list element 7
Found duplicate list element 7
Found duplicate list element 7

These final lines were repeated over and over again, until the log used
up all available diskspace on the buildd home directory. The result:

wouter@praetorius:/srv/home/buildd/logs$ ls -lh 
libatomic-ops_7.3~alpha1+git20120701-1-powerpc-20120702-0541 
-rw-r--r-- 1 buildd buildd 4,1G jul  2 08:17 
libatomic-ops_7.3~alpha1+git20120701-1-powerpc-20120702-0541

I've attached the start of the logfile (up until about the above point,
with most of the duplicate lines removed), so you can investigate.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a
sbuild (Debian sbuild) 0.61.0 (23 Feb 2011) on praetorius.debian.org

╔══╗
║ libatomic-ops 7.3~alpha1+git20120701-1 (powerpc)   02 Jul 2012 05:41 ║
╚══╝

Package: libatomic-ops
Version: 7.3~alpha1+git20120701-1
Source Version: 7.3~alpha1+git20120701-1
Architecture: powerpc
Get:1 http://ftp.se.debian.org unstable InRelease [238 kB]
Get:2 http://ftp.se.debian.org unstable/main Sources [6427 kB]
Get:3 http://incoming.debian.org unstable InRelease [238 kB]
Get:4 http://ftp.se.debian.org unstable/contrib Sources [55.4 kB]
Get:5 http://ftp.se.debian.org unstable/non-free Sources [98.9 kB]
Get:6 http://ftp.se.debian.org unstable/main powerpc Packages [6021 kB]
Ign http://incoming.debian.org  InRelease
Get:7 http://incoming.debian.org unstable/main Sources [6427 kB]
Get:8 http://ftp.se.debian.org unstable/contrib powerpc Packages [38.0 kB]
Get:9 http://incoming.debian.org unstable/contrib Sources [55.4 kB]
Get:10 http://incoming.debian.org unstable/non-free Sources [98.9 kB]
Get:11 http://incoming.debian.org unstable/main powerpc Packages [6021 kB]
Get:12 http://incoming.debian.org unstable/contrib powerpc Packages [38.0 kB]
Get:13 http://incoming.debian.org  Release.gpg [836 B]
Get:14 http://incoming.debian.org  Release [1601 B]
Get:15 http://incoming.debian.org  Sources [15.8 kB]
Get:16 http://incoming.debian.org  Packages [409 kB]
Fetched 26.2 MB in 20s (1247 kB/s)
Reading package lists...

┌──┐
│ Fetch source files   │
└──┘


Check APT
─

Checking available source versions...

Download source files with APT
──

Reading package lists...
Building dependency tree...
Reading state information...
Need to get 416 kB of source archives.
Get:1 http://incoming.debian.org/buildd-unstable/  libatomic-ops 
7.3~alpha1+git20120701-1 (dsc) [1234 B]
Get:2 http://incoming.debian.org/buildd-unstable/  libatomic-ops 
7.3~alpha1+git20120701-1 (tar) [404 kB]
Get:3 http://incoming.debian.org/buildd-unstable/  libatomic-ops 
7.3~alpha1+git20120701-1 (diff) [10.2 kB]
Fetched 416 kB in 1s (295 kB/s)
Download complete and in download only mode

Check arch
──


┌──┐
│ Install core build dependencies (internal resolver)  │
└──┘

Build-Depends: build-essential, fakeroot
Checking for already installed dependencies...
build-essential: already installed (11.5)
fakeroot: already installed (1.18.4-2)
Checking for dependency 

Bug#673497: nbd-client: error on connect: E: Server does not support listing exports

[Wouter Verhelst]

tags 673497 + upstream fixed-upstream
thanks

On Fri, May 18, 2012 at 07:54:12PM -0700, Vagrant Cascadian wrote:
   sudo nbd-client 192.168.43.181 -N /opt/ltsp/i386 /dev/nbd0
   Negotiation: ..
   E: Server does not support listing exports

Whoops, that's silly:

diff --git a/nbd-client.c b/nbd-client.c
index 4338bf5..0e62821 100644
--- a/nbd-client.c
+++ b/nbd-client.c
@@ -432,7 +432,7 @@ int main(int argc, char *argv[]) {
int c;
int nonspecial=0;
char* name=NULL;
-   uint32_t needed_flags;
+   uint32_t needed_flags=0;
uint32_t cflags;
uint32_t opts;
struct option long_options[] = {

I'll do a 3.1-2 ASAP with that fix.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



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

Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity

[Wouter Verhelst]

tags 653653 + upstream fixed-upstream
thanks

Thanks, this was applied upstream; should be part of the next upstream upload
(when it occurs, which will be before the release).

On Sat, Apr 14, 2012 at 11:47:42PM +0100, peter green wrote:
 tags 653653 +patch
 thanks
 
 peter green wrote:
 Unfortunately the test still fails with a bus error and I can't
 seem to figure out how to run the test manually to get a new
 backtrace. The executable ./integrity simply doesn't seem to
 exist after the build process ends.
 Ok fixed that issue too (thanks jurij for the help getting a new
 backtrace), and the package now builds successfully.
 
 Patch is attatched.

 diff -ur nbd-3.0/nbd-tester-client.c nbd-3.0.new/nbd-tester-client.c
 --- nbd-3.0/nbd-tester-client.c   2011-10-01 10:28:58.0 +
 +++ nbd-3.0.new/nbd-tester-client.c   2012-04-14 22:31:20.0 +
 @@ -714,8 +714,8 @@
  }
   
  static inline int checkbuf(char *buf, uint64_t seq, uint64_t blknum) {
 - char cmp[512];
 - makebuf(cmp, seq, blknum);
 + uint64_t cmp[64]; // 512/8 = 64
 + makebuf((char *)cmp, seq, blknum);
   return memcmp(cmp, buf, 512)?-1:0;
  }
  
 @@ -1100,13 +1100,15 @@
   goto err_open;
   }
   
 - prc = g_hash_table_lookup(handlehash, rep.handle);
 + uint64_t handle;
 + memcpy(handle,rep.handle,8);
 + prc = g_hash_table_lookup(handlehash, handle);
   if (!prc) {
   retval=-1;
   snprintf(errstr, errstr_len, Unrecognised 
 handle in reply: 0x%llX, *(long long unsigned int*)(rep.handle));
   goto err_open;
   }
 - if (!g_hash_table_remove(handlehash, rep.handle)) {
 + if (!g_hash_table_remove(handlehash, handle)) {
   retval=-1;
   snprintf(errstr, errstr_len, Could not remove 
 handle from hash: 0x%llX, *(long long unsigned int*)(rep.handle));
   goto err_open;


-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



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

Bug#662217: /usr/share/doc/vlc is empty

[Wouter Verhelst]

Package: vlc
Version: 2.0.0-6
Severity: serious

Subject says it all, really.

There's no changelog, no copyright, no nothing, just an empty directory.

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

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages vlc depends on:
ii  libaa11.4p5-39
ii  libavcodec53  4:0.8-1+b1
ii  libavutil51   4:0.8-1+b1
ii  libc6 2.13-26
ii  libfreetype6  2.4.8-1
ii  libfribidi0   0.19.2-2
ii  libgcc1   1:4.6.2-12
ii  libgl1-mesa-glx [libgl1]  7.11.2-1
ii  libice6   2:1.0.7-2
ii  libqtcore44:4.7.4-2
ii  libqtgui4 4:4.7.4-2
ii  libsdl-image1.2   1.2.12-1
ii  libsdl1.2debian   1.2.15-1
ii  libsm62:1.2.0-2
ii  libstdc++64.6.2-12
ii  libtar0   1.2.11-8
ii  libva-x11-1   1.0.14-1
ii  libva11.0.14-1
ii  libvlccore5   2.0.0-6
ii  libx11-6  2:1.4.4-4
ii  libxcb-composite0 1.8-2
ii  libxcb-keysyms1   0.3.8-1
ii  libxcb-randr0 1.8-2
ii  libxcb-render01.8-2
ii  libxcb-shape0 1.8-2
ii  libxcb-shm0   1.8-2
ii  libxcb-xfixes01.8-2
ii  libxcb-xv01.8-2
ii  libxcb1   1.8-2
ii  libxext6  2:1.3.0-3
ii  libxinerama1  2:1.1.1-3
ii  libxpm4   1:3.5.9-4
ii  ttf-freefont  20100919-1
ii  vlc-nox   2.0.0-6
ii  zlib1g1:1.2.6.dfsg-1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.0.0-6
ii  vlc-plugin-pulse   2.0.0-6
ii  xdg-utils  1.1.0~rc1+git20111210-6

Versions of packages vlc suggests:
pn  videolan-doc  none

-- no debconf information



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

Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity

[Wouter Verhelst]

tags 653653 + help
thanks

On Fri, Dec 30, 2011 at 12:40:09AM +0100, Jakub Wilk wrote:
 Source: nbd
 Version: 1:2.9.25-2
 Severity: serious
 Justification: fails to build from source
 User: debian-sp...@lists.debian.org
 Usertags: sparc
 
 nbd FTBFS on sparc:
 | ./integrity
 | 28870: Seq 0002 Queued: 0001 Inflight:  Done: 
 | Bus error (core dumped)
 | FAIL: integrity
 
 Full build log:
 https://buildd.debian.org/status/fetch.php?pkg=nbdarch=sparcver=1%3A2.9.25-2stamp=1325194394

So, I had a look at this on the porter machines a while back, and I have
to say I'm a bit stumped as to what's wrong. There's some stack
corruption going on inside nbd-tester-client (the test suite client that
tests whether nbd-server runs correctly), which makes things a bit
harder; but I can't see why there should be any such stack corruption.
Running this inside valgrind (on amd64) also doesn't flag anything
suspicious.

Help from anyone familiar with SPARC would be appreciated.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



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

Bug#660399: FTBFS: FALLOC_FL_PUNCH_HOLD undeclared

[Wouter Verhelst]

tags 660399 + upstream fixed-upstream
thanks

On Sat, Feb 18, 2012 at 08:31:49PM +, Sam Morris wrote:
 make[3]: Entering directory `/tmp/nbd-2.9.25'
 gcc -std=gnu99 -DHAVE_CONFIG_H -I.  -DSYSCONFDIR='/etc'  -g -O2 
 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -g -O2 
 -c -o nbd_server-nbd-server.o `test -f 'nbd-server.c' || echo 
 './'`nbd-server.c
 nbd-server.c: In function ‘exptrim’:
 nbd-server.c:1477:28: error: ‘FALLOC_FL_PUNCH_HOLE’ undeclared (first use in 
 this function)
 nbd-server.c:1477:28: note: each undeclared identifier is reported only once 
 for each function it appears in
 make[3]: *** [nbd_server-nbd-server.o] Error 1
 make[3]: Leaving directory `/tmp/nbd-2.9.25'
 
 Fixed by the following patch:
 
 - --- /tmp/nbd-server.c   2012-02-18 20:30:10.399561659 +
 +++ nbd-server.c  2012-02-18 20:29:14.975848442 +
 @@ -1461,7 +1461,7 @@
   * file to resparsify stuff that isn't needed anymore (see NBD_CMD_TRIM)
   */
  int exptrim(struct nbd_request* req, CLIENT* client) {
 - -#ifdef HAVE_FALLOC_PH
 +#if HAVE_FALLOC_PH
   FILE_INFO prev = g_array_index(client-export, FILE_INFO, 0);
   FILE_INFO cur = prev;
   int i = 1;

Has already been fixed upstream, actually. I just need to get around to
doing a new upstream release.

(and tracking down the FTBFS on sparc, which is a bit worrisome).

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



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

Bug#658229: should not migrate

[Wouter Verhelst]

Package: pmw
Version: 4.23-1
Severity: serious
Tags: upstream

Upstream informed me that due to a mistake on his part, the test suite
is non-functional currently (I'd missed that before uploading, because a
failure in the test suite does not currently make pmw fail to build,
which is also an upstream thing). This means that pmw may or may not
fail to work at all on some architectures currently, but I wouldn't know
because it's not tested.

Upstream has released a new version which fixes these issues, but I
won't have time to upload it before the weekend. Hence, this bug is here
to prevent it from migrating, until I upload the new upstream version.

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

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

Versions of packages pmw depends on:
ii  libc6  2.13-24

Versions of packages pmw recommends:
ii  ghostscript  9.04~dfsg-3

Versions of packages pmw suggests:
ii  pmw-doc  4.23-1

-- no debconf information



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

Bug#648032: No longer works since this morning's update

[Wouter Verhelst]

Package: chromium
Version: 15.0.874.106~r107270-1
Severity: grave

Hi,

Since this morning's update, starting chromium as 'chromium' or
'chromium-browser' does not as expected. Sometimes it just shows a blank
page; sometimes it shows the 'unhappy browser' blue screen. In both
cases, trying to browse to a webpage does not work.

I tried producing a backtrace, but it doesn't seem to be segfaulting or
anything; it just sits there, doing nothing.

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

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

Versions of packages chromium depends on:
ii  chromium-inspector  15.0.874.106~r107270-1 
ii  libasound2  1.0.24.1-4 
ii  libavcodec534:0.7.2-1+b1   
ii  libavformat53   4:0.7.2-1+b1   
ii  libavutil51 4:0.7.2-1+b1   
ii  libbz2-1.0  1.0.5-7
ii  libc6   2.13-21
ii  libcairo2   1.10.2-6.1 
ii  libcups21.5.0-10   
ii  libdbus-1-3 1.4.16-1   
ii  libdbus-glib-1-20.98-1 
ii  libevent-1.4-2  1.4.14b-stable-1   
ii  libexpat1   2.0.1-7.2  
ii  libflac81.2.1-6
ii  libfontconfig1  2.8.0-3
ii  libfreetype62.4.7-2
ii  libgcc1 1:4.6.2-4  
ii  libgconf2-4 2.32.4-1   
ii  libgcrypt11 1.5.0-3
ii  libgdk-pixbuf2.0-0  2.24.0-1   
ii  libglib2.0-02.28.8-1   
ii  libgtk2.0-0 2.24.7-1   
ii  libjpeg88c-2   
ii  libnspr4-0d 4.8.9-1
ii  libnss3-1d  3.13.1.with.ckbi.1.88-1
ii  libpango1.0-0   1.29.4-2   
ii  libpng12-0  1.2.46-3   
ii  libspeex1   1.2~rc1-1  
ii  libstdc++6  4.6.2-4
ii  libvpx0 0.9.7.p1-2 
ii  libwebp20.1.3-1
ii  libx11-62:1.4.4-2  
ii  libxext62:1.3.0-3  
ii  libxml2 2.7.8.dfsg-5   
ii  libxrender1 1:0.9.6-2  
ii  libxslt1.1  1.1.26-8   
ii  libxss1 1:1.2.1-2  
ii  xdg-utils   1.1.0~rc1-2
ii  zlib1g  1:1.2.3.4.dfsg-3   

chromium recommends no packages.

Versions of packages chromium suggests:
ii  chromium-l10n  15.0.874.106~r107270-1

-- no debconf information



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

Bug#626745: nbd: FTBFS: Test suite failure

[Wouter Verhelst]

Hi,

On Sun, May 15, 2011 at 12:55:51AM +0200, Christoph Egger wrote:
 Hi!
 
 nbd now fails to build on kfreebsd-* due to some test suite failures:
 
 4194304 bytes (4.2 MB) copied, 0.122858 s, 34.1 MB/s
 ../cfgnew
 kill: 113: No such process
 
 FAIL: cfgnew
 4096+0 records in
 4096+0 records out
 4194304 bytes (4.2 MB) copied, 0.0725825 s, 57.8 MB/s
 ../cfgsize

I just made some time to debug this.

One thing that's changed since lenny is that nbd-server now always tries
to open the same port, for a new-style negotiation. This is on an
IANA-assigned port number, and it opens it with the SO_REUSADDR socket
option set, but it looks as though that might not be enough; when I
repeatedly run the failing checks manually with a custom-built nbd that
writes its error messages to stdout rather than syslog, it looks as
though it fails because it can't open that one port.

Do you have any idea whether that might be the case? Does the FreeBSD
kernel have issues with restarting a network server less than a second
after it was last started? If so, I've found the problem...

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



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

Bug#584337: xdotool: FTBFS: build hangs

[Wouter Verhelst]

On Tue, Jun 15, 2010 at 08:16:51AM -0400, Daniel Kahn Gillmor wrote:
 Wouter, you seem to be offering assistance in getting access to a build
 directory (meaning to a live buildd itself?  or something else?)  -- can
 i take you up on that?  I'm not sure what my next steps should be otherwise.

I can tar up the build directory as it results on the buildd. It
requires some setup and for me to retry the build, but that should not
be too hard. If you think that might help, I can put it up on another
host in my home directory or some such.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#584337: xdotool: FTBFS: build hangs

[Wouter Verhelst]

On Thu, Jun 03, 2010 at 10:30:22AM -0400, Daniel Kahn Gillmor wrote:
 On 06/03/2010 06:15 AM, Lucas Nussbaum wrote:
  Source: xdotool
  Version: 1:1.20100318.2737-1
  Severity: serious
  Tags: squeeze sid
  User: debian...@lists.debian.org
  Usertags: qa-ftbfs-20100602 qa-ftbfs
  Justification: FTBFS on amd64
  
  Hi,
  
  During a rebuild of all packages in sid, your package failed to build on
  amd64.
  
  Relevant part:
  make[3]: Entering directory 
  `/build/user-xdotool_1.20100318.2737-1-amd64-O1p0dQ/xdotool-1.20100318.2737/t'
  ./run.sh
  Setting up keymap on new server as us
  Loaded suite alltests
  Started
  .Skipping _NET_ACTIVE_WINDOW features (current wm does not support it)
  Skipping _NET_NUMBER_OF_DESKTOPS features (current wm does not support it)
  Skipping _NET_WM_DESKTOP features (current wm does not support it)
  Skipping _NET_CURRENT_DESKTOP features (current wm does not support it)
  Defaulting to search window title, class, and name
  xterm Xt error: Can't open display: :5
  make: *** wait: No child processes.  Stop.
  make: *** Waiting for unfinished jobs
  make: *** wait: No child processes.  Stop.
  make[2]: *** [test-xvfb] Terminated
  make[1]: *** [test] Terminated
  make[3]: *** [test] Terminated
  E: Caught signal 'Terminated': terminating immediately
  ...EBuild killed with signal TERM after 60 minutes of 
  inactivity

This is a check in sbuild to avoid hung builds; I guess you're not
really searching for those.

 I'm aware of these intermittent test suite failures on the autobuilders
 and have been working with upstream (Cc'ed here) to get them fixed.
 
 Unfortunately, the latest version of xdotool (2.20100602.2915, which has
 a substantially overhauled test suite geared to address these concerns)
 *also* FTBFS on the buildd network:
 
   
  https://buildd.debian.org/fetch.cgi?pkg=xdotoolarch=amd64ver=1%3A2.20100602.2915-1stamp=1275566388file=log
   
  https://buildd.debian.org/fetch.cgi?pkg=xdotoolarch=ia64ver=1%3A2.20100602.2915-1stamp=1275566969file=log
   
  https://buildd.debian.org/fetch.cgi?pkg=xdotoolarch=powerpcver=1%3A2.20100602.2915-1stamp=1275568171file=log
 
 However, the same package builds fine for me in both:
 
  * an up-to-date amd64 sid cowbuilder environment, and
  * on an i386 workstation running mostly testing with some packages from sid
 
 Any assistance in sorting out the cause of these FTBFS would be welcome.
  Where should i look?

Those build logs don't really reveal anything to me; it doesn't look
like it's a known issue. It does say something about pkill: not found,
which could point to a missing build-dep, but as that happens upon
trying to finalize a test from the test suite that has failed, I guess
that's not the actual problem.

If you don't manage to find the issue, I might be able to get you a
build directory. I would hope

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#575196: libbeidlibopensc2-dev and libbeidlib3-dev: error when trying to install together

[Wouter Verhelst]

reassign 575196 ftp.debian.org
retitle 575196 [ROM, NVIU] Please remove belpic
thanks

On Wed, Mar 24, 2010 at 08:51:33AM +0100, Ralf Treinen wrote:
 automatic installation tests of packages that share a file and at the
 same time do not conflict by their package dependency relationships has
 detected the following problem:
[...]

Actually, the plan is for belpic to be thrown out.

I thought I filed a bug on that one, but apparently not, so here goes.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#573672: beid: FTBFS: rm: cannot remove `_src/eidmw/bin/eidmw_*.qm': No such file or directory

[Wouter Verhelst]

On Sun, Mar 14, 2010 at 12:52:03AM +0100, Cyril Brulebois wrote:
 retitle 573672 FTBFS in various ways.
 thanks
 
 Lucas Nussbaum lu...@lucas-nussbaum.net (13/03/2010):
   rm: cannot remove `_src/eidmw/bin/eidmw_*.qm': No such file or directory
 
 That was the original title, but not the actual issue. :)
 
 Apparently two ways of failing:
 | # Build 3.5 version of middleware
 | cd _src/eidmw  ./configure --prefix=/usr CFLAGS=-Wall -g -O2 
 CXXFLAGS=-Wall -g -O2
 | /bin/sh: ./configure: Permission denied
 
 | # Build 2.6 version of middleware
 | cd _src/beid-2.6  scons -j --cache-disable prefix=/usr confdir=/etc/
 | usage: scons [OPTION] [TARGET] ...
 |
 | SCons error: option -j: invalid integer value: '--cache-disable'
 | make: *** [stampdir/build-arch-stamp] Error 2
 
 Build logs:
   https://buildd.debian.org/status/package.php?p=beid

Yes, I know -- I'm working on those issues already. Should be an upload
early next week.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#565262: gnome-menus depends on non-essential software in prerm

[Wouter Verhelst]

Package: gnome-menus
Version: 2.28.0.1-2
Severity: serious

Hi,

malo:~# dpkg --purge gnome-menus
(Reading database ... 14512 files and directories currently installed.)
Removing gnome-menus ...
find: `/usr/share/gnome/applications': No such file or directory
dpkg: error processing gnome-menus (--purge):
 subprocess installed pre-removal script returned error exit status 1
/var/lib/dpkg/info/gnome-menus.postinst: /usr/sbin/gnome-menus-blacklist: 
/usr/bin/python: bad interpreter: No such file or directory
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 126
Errors were encountered while processing:
 gnome-menus

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#563215: belpic: diff for NMU version 2.6.0-7.2

[Wouter Verhelst]

Hi Tim,

On Fri, Jan 01, 2010 at 03:00:15AM +, Tim Retout wrote:
 tags 563215 + patch pending
 thanks
 
 Dear Wouter,
 
 (Happy New Year!)
 
 I've prepared an NMU for belpic (versioned as 2.6.0-7.2) and
 uploaded it to DELAYED/5. Please feel free to tell me if I
 should delay it longer.

No, that's fine (and it would be too late now anyway). However, I'm
actually working on a new upstream release which is completely and
utterly different from the one you just NMU'ed. I'm afraid it's been a
bit of a waste of your time.

Oh well. Thanks for your NMU, at any rate.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#552952: nbd: FTBFS: tests blocked

[Wouter Verhelst]

On Sun, Nov 29, 2009 at 03:56:19PM +0100, Lucas Nussbaum wrote:
 On 28/11/09 at 09:38 +0100, Wouter Verhelst wrote:
  On Wed, Oct 28, 2009 at 11:57:21AM +0100, Lucas Nussbaum wrote:
   Source: nbd
   Version: 1:2.9.14-1
   Severity: serious
   User: debian...@lists.debian.org
   Usertags: qa-ftbfs-20091028 qa-ftbfs
   Justification: FTBFS on amd64
   
   Hi,
   
   During a rebuild of all packages in sid, your package failed to build on
   amd64.
  
  I haven't been able to reproduce this on my system (also an amd64), and
  I haven't seen it happen on any of the buildd hosts that built
  1:2.9.14-2.
  
  Since the particular test that fails has a test client connect to the
  server on localhost, network-specific strangeness might be the reason
  why it failed. Therefore, could you explain the details of how stuff is
  supposed to be functioning?
 
 Well, I use netfilter to reject most accesses to the outside world. This
 does not affect local communications.
 
 Does it connect to localhost or 127.0.0.1? DNS resolution might not
 work completely.

localhost.

However, in the mean time, the alpha buildd has failed the build with
the same problem.

I think I'm beginning to understand what's going wrong, and that would
mean that this is a false negative for the test. Since false negatives
are rarely useful, I'm going to make failing the test not a fatal error,
until I've come up with a proper fix (which is going to be somewhat less
trivial)

Thanks,

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#552952: nbd: FTBFS: tests blocked

[Wouter Verhelst]

On Wed, Oct 28, 2009 at 11:57:21AM +0100, Lucas Nussbaum wrote:
 Source: nbd
 Version: 1:2.9.14-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20091028 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.

I haven't been able to reproduce this on my system (also an amd64), and
I haven't seen it happen on any of the buildd hosts that built
1:2.9.14-2.

Since the particular test that fails has a test client connect to the
server on localhost, network-specific strangeness might be the reason
why it failed. Therefore, could you explain the details of how stuff is
supposed to be functioning?

Thanks,

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#538122: libclass-mop-perl_0.90-1(powerpc/unstable):

[Wouter Verhelst]

On Thu, Jul 23, 2009 at 02:09:24PM +0200, gregor herrmann wrote:
 On Thu, 23 Jul 2009 11:39:47 +0200, Ansgar Burchardt wrote:
 
  wou...@debian.org writes:
   The reason is that libtest-simple-perl is a virtual package. You cannot
   have a versioned dependency on a virtual package.
 
 Not exactly -- libtest-simple-perl is both a virtual package
 (provided by perl-modules) and a real package. That's a bit unlucky
 but there are a few dual-lifed modules in the Perl world.
 
 Details in the mentioned bug report:
  
  sbuild should handle this correctly since 0.57.4-1, see #395271 and the
  kfreebsd-i386 build log [1].
 
 Wouter, since you are an experienced buildd maintainer:

Mmm, maybe I shouldn't have done a certain specific blog post ;-)

 is there a way to get a recent version of sbuild (this bug is closed
 since over a year) installed on all buildds?

There's some work on this, yes, but it'll take a while. Short story:
it's currently very much a mess, with some buildd hosts having local
patches, etc. Fleshing this out is part of pkern's Google Summer of Code
program.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#537843: tftpd-hpa: broken in multiple RC ways

[Wouter Verhelst]

Package: tftpd-hpa
Version: 5.0-2
Severity: serious

Hi,

Recent versions of tftpd-hpa fail on my system:

wou...@celtic:~$ LC_ALL=C sudo dpkg --configure -a
Setting up tftpd-hpa (5.0-2) ...
tftpd user (tftp) is already existing, doing nothing.

tftpd-hpa directory (/srv/tftp) is already existing, doing nothing.
Starting HPA's tftpd: in.tftpdinvoke-rc.d: initscript tftpd-hpa, action start 
failed.
dpkg: error processing tftpd-hpa (--configure):
 subprocess installed post-installation script returned error exit status 71
Errors were encountered while processing:
 tftpd-hpa
wou...@celtic:~$ 

Postinst should deal properly with initscripts failing to run; this
postinst does not

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

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages tftpd-hpa depends on:
ii  adduser   3.110  add and remove users and groups
ii  debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii  libc6 2.9-21 GNU C Library: Shared libraries
ii  libwrap0  7.6.q-18   Wietse Venema's TCP wrappers libra

tftpd-hpa recommends no packages.

Versions of packages tftpd-hpa suggests:
ii  syslinux-common2:3.82+dfsg-1 Kernel loader which uses a FAT, ex

-- debconf information:
  tftpd-hpa/directory: /srv/tftp
  tftpd-hpa/username: tftp
  tftpd-hpa/use_inetd: true



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

Bug#537846: tftpd-hpa: wipes /etc/default config file without permission

[Wouter Verhelst]

Package: tftpd-hpa
Version: 5.0-2
Severity: serious

Hi,

The tftpd-hpa package blows away any change a user made to
/etc/default/tfpd-hpa. This is not allowed by policy, and a warning
message that tells you not to edit the file directly does not solve
this.

You have several options:

- Allow the user to set a variable in the config file that, if set, will
  prevent the package to blow it away;
- Read the config file in your tftpd-hpa.config script, and use it (with
  db_set) to seed the defaults of your debconf configuration. If you
  take this option, you should take care not to remove any additional
  customization the user might have made (for instance by using sed to
  edit the file);
- Combine the above two (which is the preferable option)

For an example of the last option, see the nbd-client package.

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

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages tftpd-hpa depends on:
ii  adduser   3.110  add and remove users and groups
ii  debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii  libc6 2.9-21 GNU C Library: Shared libraries
ii  libwrap0  7.6.q-18   Wietse Venema's TCP wrappers libra

tftpd-hpa recommends no packages.

Versions of packages tftpd-hpa suggests:
ii  syslinux-common2:3.82+dfsg-1 Kernel loader which uses a FAT, ex

-- debconf information:
  tftpd-hpa/directory: /srv/tftp
  tftpd-hpa/username: tftp
  tftpd-hpa/use_inetd: true



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

Bug#537843: Acknowledgement (tftpd-hpa: broken in multiple RC ways)

[Wouter Verhelst]

retitle 537843 init script fails, making postinst fail too
thanks

I forgot to change the title after I realized this should be three bugs,
not one. Sorry.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#508406: Intend to create an -fPIC library package...

[Wouter Verhelst]

On Tue, Jul 21, 2009 at 12:40:17AM +0200, Christian Hammers wrote:
 Am Mon, 20 Jul 2009 23:18:23 +0100
 schrieb Roger Leigh rle...@codelibre.net:
  If other libraries are including this library, then why is libmysqld
  not being provided as a properly-versioned shared object?
 
 Upstream, in this case Monty himself, seems to explicitly want it to be
 a static library for performance reasons as I read from the discussion
 in: http://lists.mysql.com/internals/35950

In that case, and if we do indeed want to support this static library
interface, indirect users of libmysqld.a should link to it when they
compile their software. Shared libraries can in fact use symbols from
the 'main' program if they're compiled in like that -- except that, of
course, these shared libraries then depend on the assumption that the
static library does not change its ABI, and they have no way at all to
ensure that.

Adding a -fPIC static library obviously does not fix that problem; it
only makes the ABI management of those libraries that link in the -fPIC
static library infinitely more complex. Additionally, you introduce a
serious problem that may only be fixed by requiring that any library
which includes this -fPIC static library needs to use either symbol
versions or linker tricks to avoid multiple versions of the same symbol
from stumping on eachother's toes.

Whether we should recommend using static libraries is another matter
entirely; indeed performance does go down a teeny weeny bit when using
shared libraries, but the difference shouldn't be *that* large; if it
is, that probably means they're using a twisty maze of function calls,
all alike, that they probably shouldn't be doing. In my opinion, the
advantages gained by not doing shared libraries do not, by far, outweigh
the serious problems it introduces.

All this really sounds like a cop-out in that mysql upstream doesn't
want to deal with *real* performance optimizations. Not that I'd
expected something much different from MySQL. But I digress.

  I am not convinced that compiling with -fPIC is appropriate here--it's
  working around the fact that mysql isn't providing a properly
  reusable shared library.  Linking an -fPIC static library (a) with a
  shared library (b) will make the contents of (a) part of the exported
  interface of (b) because it will by default be added to the dynamic
  symbol table unless you take special action with linker scripts.
  
  There are obvious issues with security updates if people are linking
  against libmysqld.a, since all libraries linking against it will need
  rebuilding if there's a security update.  If it's shared, that won't
  normally be required.
 
 At least RedHat and Gentoo already have experimented with building their
 own shared libraries from libmysqld.a:
 https://bugzilla.redhat.com/show_bug.cgi?id=149829
 https://bugs.gentoo.org/attachment.cgi?id=186606
 
 So I try to get this working on Debian, too, and create a libmysqld0
 package with a shared library instead. Speaking of it, which soname
 version should I give it? 0.0.0? Or something like 0.5137.0 to somehow
 encode a version as I cannot promise that *I* know when
 they make API changes? .so.5.1.37 seems not to be a good idea in case
 MySQL somewhen starts to ship a libmysqld.so.5 themselves.

Don't just blindly use 'version of the server package' unless you really
really know what you're doing.

A SONAME should be bumped (i.e., the number after the .so. bit of the
filename and before the next dot increased) when the ABI changes
incompatibly. This may be when upstream changes the API incompatibly
(probably indeed only happens on an upstream major update), but there
are other cases where this might be the case (say, they add a variable
to a struct in a way so that the offsets change, or rely on users to use
malloc(sizeof(struct)) to allocate a new one, or a number of other
things) that might change at a minor (i.e., 5.1 - 5.2) update. If that
happens, and you rely on the major upstream version number (5 in the
example) to change, then you've just created a shared object which
claims it is compatible with previous versions of itself but isn't, and
things will go kaboom all over the place.

Basically, I guess the only proper answer to your question is either
audit upstream's ABI and bump the SONAME when required or slap
upstream in the face and demand they provide a proper shared library.
Except without the rudeness.

If you don't want to do either, then the only safe option you have is to
use libtool's -release option (or an equivalent of that which does not
use libtool). This, however, will mean that every time you do an
upstream update, even a minor one, you have a library transition on your
hands.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: 

Bug#508406: Intend to create an -fPIC library package...

[Wouter Verhelst]

On Tue, Jul 21, 2009 at 09:17:28AM -0500, Peter Samuelson wrote:
 
 [Wouter Verhelst]
  Whether we should recommend using static libraries is another matter
  entirely; indeed performance does go down a teeny weeny bit when using
  shared libraries, but the difference shouldn't be *that* large; if it
  is, that probably means they're using a twisty maze of function calls,
  all alike, that they probably shouldn't be doing.
 
 As I understand it, the performance drawbacks of a shared library are:
 
 1) The PIC code and its use of a GOT.  Given that we're talking about a
PIC static library, this is not relevant.

The argument was that a shared library is 'too slow'. Reading the
discussion thread that Christian pointed to, it appears that Monty
doesn't actually know what he's talking about, but read on some random
IBM website that shared libraries are slower. Well, yes they are, but
not by much, and the pain static libraries introduce outweighs that by
much.

Note also that shared libraries are only slower on x86 hardware due to
the fact that they don't natively do PC-relative addressing, which needs
to be emulated; x86_64 has dealt with this, and most other architecture
(including m68k, for those following along at home) properly support it.

 2) Runtime linking.  This is overhead at application startup time.
Something that embeds an SQL engine should not, I think, start up too
frequently.  Am I wrong?

Frankly, I'd hope not.

 So what is the real performance advantage of this -fPIC static library?
 To me it looks like a different, less desirable, way to implement the
 'prelink' optimization.

Looks like it, indeed.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Bug#537316: [Pkg-libvirt-maintainers] Bug#537316: libvirt_0.6.5-2(powerpc/unstable): broken build-deps

[Wouter Verhelst]

On Sun, Jul 19, 2009 at 05:01:16PM +0200, Guido Günther wrote:
 On Wed, Jul 15, 2009 at 10:07:29PM +0200, wou...@debian.org wrote:
  If you want to build-conflict on a specific version of a build-essential
  package, you should also build-depend on the working version; otherwise
  sbuild will try to remove the package, rather than upgrade it. Not what
  we want :-)
 Hmm...isn't that a problem in sbuild then?

No, it's not. Build-Conflict means I'd rather you remove this package
than allow me to build against it. The version just means if it's this
version, I'd rather you remove it. If you want it to upgrade to a
specific version, you need to tell it to build-depend on it.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#525593: Processing of belpic_2.6.0-6.1_amd64.changes

[Wouter Verhelst]

Please don't do random NMU's without getting approval from the
maintainer.

Belpic has serious issues in that some builds work, while others don't,
depending on the state of the build-deps; the only way to defend against
this is by extensive testing, which you _cannot_ have done since you
don't have a Belgian eID card.

Also, I'm currently working on packaging an upstream code update, which
I hope to have done by the end of DebConf9. If this build causes
problems, then that works directly against that goal.

If DebConf9 is over and the belpic upstream update isn't ready for
upload, I'll do an update of the current codebase myself. For now, I
have cancelled your upload. Please don't touch it without my explicit
approval.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Bug#525593: Processing of belpic_2.6.0-6.1_amd64.changes

[Wouter Verhelst]

On Sun, Jul 19, 2009 at 05:48:04PM +0200, Cyril Brulebois wrote:
 Wouter Verhelst wou...@debian.org (19/07/2009):
  Please don't do random NMU's without getting approval from the
  maintainer.
 
 That's why it's in DELAYED and can be cancelled.

The procedure, last I checked, was still 'use DELAYED/7 or ask for
explicit approval'.

  Belpic has serious issues in that some builds work, while others
  don't, depending on the state of the build-deps; the only way to
  defend against this is by extensive testing, which you _cannot_ have
  done since you don't have a Belgian eID card.
 
 Thanks for letting people now by replying to the RC bug that got
 reported.

Sorry, I thought I had done that before; apparently I haven't. There are
other bugs mentioning the new upstream version, however.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#536290: nbd-server: Unknown error reading config file

[Wouter Verhelst]

On Wed, Jul 08, 2009 at 11:00:42PM +0200, Jaap Eldering wrote:
 Package: nbd-server
 Version: 1:2.9.11-3
 Severity: grave
 Justification: renders package unusable

No it doesn't.

 Running nbd-server results in an error that a configuration file cannot 
 be parsed or found:
 
 $ nbd-server 1234 /some/file
 
 ** (process:9399): WARNING **: Could not parse config file: Could not open 
 config file.

It's a *warning*, not an error. nbd-server will happily continue with
the command-line specified configuration if it can't parse the config
file, but will give you a warning message that the config file could not
be read.

Since you specified a port and a filename, nbd-server should be running
and waiting for a client to connect at this point.

 $ nbd-server 1234 /some/file -C /usr/share/nbd-server/nbd-server.conf.tmpl
 
 ** (process:9401): WARNING **: Could not parse config file: Unknown error

That is an incomplete template file to be used by the debconf
configuration scripts. By itself, it indeed is an invalid configuration
file.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#536290: nbd-server: Unknown error reading config file

[Wouter Verhelst]

On Thu, Jul 09, 2009 at 10:48:35AM +0200, Jaap Eldering wrote:
 Still, I think that there's something to be improved here: nbd-server
 gives this warning without any other message that it has started. This
 message looks pretty serious, especially since the man-page explicitly
 states that a non-existent or empty config file can be specified
 without problem. I'd suggest to make it clear in the warning message
 that nbd-server is still started and/or update the documentation about
 this message.

http://github.com/yoe/nbd/commit/46fe6de2e07a927b77941cbbea2da4d3f0aec696

Already done ;-)

 Or maybe add a default configuration file which nbd-server can parse
 and which removes this warning message?

An empty config file will still produce a warning. I'd have to create a
'default' config file with a working configuration, which would export
things the user may not want to export. Bad idea :-)

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



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

Bug#526225: does not start

[Wouter Verhelst]

Package: eclipse
Version: 3.2.2-6.1
Severity: grave

Hi,

Starting eclipse produces the following output:

searching for compatible vm...
  testing /usr/lib/jvm/java-6-openjdk...found
Could not create /usr/local/lib/eclipse/.eclipseextension. Please run as root:
touch /usr/local/lib/eclipse/.eclipseextension
chmod 2775 /usr/local/lib/eclipse/.eclipseextension
chown root:staff /usr/local/lib/eclipse/.eclipseextension
/usr/lib/jvm/java-6-openjdk/bin/java: symbol lookup error: 
/home/wouter/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/bundles/98/1/.cp/libswt-mozilla-gtk-3236.so:
 undefined symbol: _ZN4nsID5ParseEPKc

This is on a clean install (I've never even tried eclipse before; this
isn't a very good first impression ;-)

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

Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages eclipse depends on:
ii  eclipse-jdt   3.2.2-6.1  Java Development Tools plug-ins fo
ii  eclipse-pde   3.2.2-6.1  Plug-in Development Environment to
ii  eclipse-source3.2.2-6.1  Eclipse source code plug-ins
ii  libc6 2.9-8  GNU C Library: Shared libraries
ii  libglib2.0-0  2.20.1-1   The GLib library of C routines
ii  libgtk2.0-0   2.16.1-2   The GTK+ graphical user interface 
ii  zenity2.24.1-1   Display graphical dialog boxes fro

Versions of packages eclipse recommends:
ii  eclipse-gcj   3.2.2-6.1  Native Eclipse run with GCJ

eclipse suggests no packages.

-- no debconf information



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