Bug#1070854: clc-intercal FTBFS: dpkg-genbuildinfo: error: binary build with no binary artifacts found

[Mark Brown]

On Fri, May 10, 2024 at 05:25:35PM +0300, Adrian Bunk wrote:

> chmod +x `pwd`/debian/clc-intercal/usr/bin/*
>  dpkg-genbuildinfo --build=any 
> -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo
> dpkg-genbuildinfo: error: binary build with no binary artifacts found; 
> .buildinfo is meaningless
> dpkg-buildpackage: error: dpkg-genbuildinfo --build=any 
> -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo subprocess returned exit 
> status 25

I can't reproduce this, and nothing about the build I'm seeing in the
log looks meaningfully different to what I get when I build locally.
AFAICT there are .so files being installed among the various perl things
and dpkg-genbuildinfo runs happily.


signature.asc
Description: PGP signature

Bug#1060768: pdudaemon: Missing dependency on python3-aiohttp

[Mark Brown]

Package: pdudaemon
Version: 0.0.8.58.g597052b-1
Severity: serious

Attempting to use pdudaemon without python3-aiohttp installed results in
a traceback:

# pdudaemon
Traceback (most recent call last):
  File "/usr/sbin/pdudaemon", line 33, in 
sys.exit(load_entry_point('pdudaemon==0.1', 'console_scripts', 
'pdudaemon')())
 ^^
  File "/usr/sbin/pdudaemon", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/pdudaemon/__init__.py", line 32, in 

from pdudaemon.httplistener import HTTPListener
  File "/usr/lib/python3/dist-packages/pdudaemon/httplistener.py", line 24, in 

from aiohttp import web
ModuleNotFoundError: No module named 'aiohttp'

but there is no dependency declared in the package.  Installing the
python3-aiohttp resolves this issue.

-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages pdudaemon depends on:
ii  python3   3.11.2-1+b1
pn  python3-hid   
pn  python3-paramiko  
ii  python3-pexpect   4.8.0-4
ii  python3-pyasn10.4.8-3
ii  python3-pysnmp4   4.4.12-2
ii  python3-requests  2.28.1+dfsg-1
ii  python3-serial3.5-1.1
pn  python3-systemd   
pn  python3-usb   

Versions of packages pdudaemon recommends:
ii  inetutils-telnet [telnet]  2:2.4-2
ii  openssh-client 1:9.2p1-2

pdudaemon suggests no packages.

Bug#1059165: [Pkg-javascript-devel] Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues

[Mark Brown]

On Wed, Dec 20, 2023 at 10:14:44PM +0100, Jérémy Lal wrote:

> BURP wrong zlib version check in the failing test - this could be NMUed

> DOLFIN has a single test failure, that is odd and unrelated as well - this
> could be NMUed

For non-technical reasons I can't do these NMUs myself if they're
warranted/needed.


signature.asc
Description: PGP signature

Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues

[Mark Brown]

clone 1059165 -1
reassign -1 nodejs
retitle -1 autopkgtest failures on i386
found -1 18.19.0+dfsg-6
block 1059165 by -1
kthxbye

On Wed, Dec 20, 2023 at 08:15:31PM +0100, Paul Gevers 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:zlib has been trying to migrate for 32 days [2].
> Hence, I am filing this bug. The version in unstable triggers autopkgtest
> failures in multiple packages (although I suspect that the current dolfin
> issues are due to it being flaky). The failure for burp has already a bug
> report against that package, which leaves nodejs on i386.

...

> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.

Not sure that's likely in the case of zlib?

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

There are non-technical issues with me doing active work on nodejs
package but from a quick glance the log does not seem particularly
plausibly related to zlib, and I note that the failures are

   not ok 498 parallel/test-debugger-heap-profiler
   not ok 962 parallel/test-fs-utimes-y2K38 # TODO : Fix flaky test 

the second of which especially doesn't inspire confidence that this is
due to zlib rather than general updates to unstable setting off an
already flaky test (eg, the kernel changed timing?).  Full log is:

   https://ci.debian.net/packages/n/nodejs/testing/i386/41176091/

and looking at:

   https://ci.debian.net/packages/n/nodejs/testing/i386/

there seem to be a number of packages triggering what from spot checks
look to be the same or similar issues in nodejs in testing.

I frankly don't really know what I'm supposed to do with this, the test
results look like noise as far as zlib is concerned so I don't see
anything to fix or investigate in the package itself.  AFAICT bugs don't
get filed for autopkgtest failures like they do for build failures so
perhaps this was just missed up until now?


signature.asc
Description: PGP signature

Bug#1012674: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Wed, Jul 27, 2022 at 09:00:09PM +0200, vollan...@gmail.com wrote:

> There is no licence on this code, it is juste free!!

If that's the goal they should have a clear statement that they're in
the public domain, without an explicit license grant of some kind the
default is that things are copyrighted and all rights reserved.


signature.asc
Description: PGP signature

Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Mon, Jul 11, 2022 at 06:54:13PM +0200, Bastian Germann wrote:
> Am 11.07.22 um 18:40 schrieb Mark Brown:
> > On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote:

> > > I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to 
> > > DELAYED/3.

> > Why?  Please drop this.

> Okay. When are you going to address this bug then?
> It has been a month not reacting to the RC bug.
> I think this is not acceptable for a key package such as zlib.

I'm not sure what there is to react to here other than doing an upload;
it's a packaging thing more than something causing active breakage for
users and we're nowhere near to doing a release yet so there didn't seem
a huge sense of urgency here so I'd been going to roll it into packaging
the new upstream release.  The bug gives the air of being from an audit
and in those cases you do have to balance keeping people up to date with
creating noise for submitters and there's been no followup requests for
status or anything.

I have been hoping that we're going to get another upstream release
which rolls in some of the fixes for the string of problems that people
have been having with the security fix release that was recently done
though that is looking depressingly unlikely and so I need to figure out
what needs backporting.  Given the release schedule startng to kick off
at the beginning of next year it'll be some time this year, I'd guess
some time this quarter.

In any case this upload isn't a targetted fix for the individual issue,
it's got a whole bunch of other unrelated changes including a new
upstream release which are clearly out of scope.  Like I say I have
substantial concerns about the new upstream release so that having been
rolled in is especially worrying.


signature.asc
Description: PGP signature

Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote:

> I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to DELAYED/3.

Why?  Please drop this.  


signature.asc
Description: PGP signature

Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate

[Mark Brown]

On Fri, Mar 25, 2022 at 10:50:51PM +0100, Salvatore Bonaccorso wrote:

> Here is a preliminary debdiff to address this.

Thanks, that's roughly what I uploaded - it looks like your mail
raced with my own update.


signature.asc
Description: PGP signature

Bug#999155: ping

[Mark Brown]

On Mon, Jan 24, 2022 at 05:51:43PM +0100, Thorsten Alteholz wrote:

> In order have some activity on this bug and to avoid autoremoval of
> dependencies, this is a reminder of outstanding things to do ...

Please don't send content free pings, they just add noise and make it
likely that it's going to take longer (since I remember that I did
something but forget that it was just handling the ping).


signature.asc
Description: PGP signature

Bug#999155: RC bug in mm and zlib

[Mark Brown]

On Wed, Jan 05, 2022 at 12:57:47PM +0100, Thorsten Alteholz wrote:

> are you already working on an update of mm and zlib? Or do you need some
> help?

They're utterly trivial, I'll get round to them at some point when I do
a batch run through all my packages.  It'd be more effort to integrate
something.


signature.asc
Description: PGP signature

Bug#992089: xemacs21-packages: contains a file with a non-free "disparaging to Sun" license

[Mark Brown]

On Wed, Aug 11, 2021 at 02:38:48PM +0200, Pierre Gruet wrote:

> Source: xemacs21-packages
> Version: 2009.02.17.dfsg.2-4
> Severity: serious
> Tags: stretch buster bullseye sid

...

> The file
> xemacs-packages/jde/java/src/jde/debugger/expr/LValue.java
> incorporates a non-free license, stating 

This bug has been present for several decades now, it is *extremely*
late for the buster release at this point and fixing this will require
an upload of a new source version to pull out the file.  I therefore
propose that we ignore this bug for the upcoming release to avoid the
minor but still present risk of disruption at this point in the cycle.


signature.asc
Description: PGP signature

Bug#952257: xemacs21-packages: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Mark Brown]

On Sun, Feb 23, 2020 at 02:22:15PM +0100, Lucas Nussbaum wrote:

> Relevant part (hopefully):
> > make[3]: Entering directory '/<>/xemacs-packages/edit-utils'

Not sure how these are generated but there's over 1000 lines of
log here, most of it irrelevant.  This makes it hard to both find
the actual problem and reply to this mail.  The only relevant
part of the log is:

> > cd . && makeinfo  -o edit-utils.info edit-utils.texi
> > cd . && makeinfo  -o tempo.info tempo.texi
> > utf8 "\xE5" does not map to Unicode at 
> > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796,  line 22.
> > Malformed UTF-8 character: \xe5\x67\x65 (unexpected non-continuation byte 
> > 0x67, immediately after start byte 0xe5; need 3 bytes, got 1) in pattern 
> > match (m//) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
> > Malformed UTF-8 character (fatal) at 
> > /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.
> > make[3]: *** [../../XEmacs.rules:310: tempo.info] Error 25


signature.asc
Description: PGP signature

Bug#915190: xemacs21-support: infinite loop in /etc/xemacs21/site-start.d

[Mark Brown]

On Sun, Dec 02, 2018 at 02:20:17PM +0900, Tatsuya Kinoshita wrote:
> reassign 909381 xemacs21-support
> forcemerge 915190 909381
> tags 915190 + patch
> thanks
> 
> See the following patch to fix this bug.

Which I didn't see because the mail only went to the control bot and the
pre-merged bug - it isn't even visble in the web view of the bug unless
you explicitly expand the message :(  It's better to add an explicit CC
to the maintainer to make sure the BTS does the right thing, the
defaults really aren't altogether helpful for reassignments and control
mail.  I'll just apply this just now, thanks...

> 
> ```
> --- a/debian/00debian.el
> +++ b/debian/00debian.el
> @@ -94,8 +94,4 @@
> )
> load-path))
>  
> -;; should now load from one of the /etc dirs since they are first in
> -;; the path now.
> -(load "site-start" t)
> -
>  ;;; end 00debian.el
> ```
> 
> This `(load "site-start" t)` was intended to load `/etc/emacs/site-start.el`,
> but unneeded now (dropped by emacsen-common 3.x).
> 
> cf. https://lists.debian.org/debian-emacsen/2018/06/msg00093.html
> > Date: Sat, 16 Jun 2018 11:04:27 -0500
> > From: Rob Browning 
> > Subject: [PATCH 3/4] Given new policy and emacsXY unversioning drop shared 
> > dirs
> > To: debian-emac...@lists.debian.org
> > Cc: Mark Brown 
> > 
> > ---
> >  debian/00debian.el | 7 +--
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> > 
> > diff --git a/debian/00debian.el b/debian/00debian.el
> > index 87508d5..fd06986 100644
> > --- a/debian/00debian.el
> > +++ b/debian/00debian.el
> > @@ -83,10 +83,6 @@ starting with a '.'"
> > (dir-and-all-good-subs
> >  (expand-file-name "~/.xemacs/packages"))
> > (list (concat "/etc/xemacs" debian-xemacs-major-version))
> > -   '("/etc/emacs")
> > -   (list (concat "/usr/local/share/emacs/xemacs-" debian-xemacs-version
> > - "/site-lisp"))
> > -   '("/usr/local/share/emacs/site-lisp")
> > `(,@(dir-and-all-good-subs "/usr/local/lib/xemacs/site-lisp")
> > ,@(dir-and-all-good-subs
> >(concat "/usr/share/xemacs/site-lisp-"
> > @@ -96,8 +92,7 @@ starting with a '.'"
> >(concat "/usr/share/xemacs" debian-xemacs-major-version
> >"/site-lisp/"))
> > )
> > -   load-path
> > -   '("/usr/share/emacs/site-lisp")))
> > +   load-path))
> >  
> >  ;; should now load from one of the /etc dirs since they are first in
> >  ;; the path now.
> > -- 
> > 2.15.1
> 
> Thanks,
> -- 
> Tatsuya Kinoshita




signature.asc
Description: PGP signature

Bug#897573: You need to install the extra package

[Mark Brown]

On Mon, May 07, 2018 at 03:01:23PM +0200, Bastien ROUCARIES wrote:
> hi,
> 
> It is a feature you need to depends on extra package

It would have been rather more helpful if you were to mention which
package this is.  It would also have been helpful to have made some
effort to communicate this change to packages that build depend on yours
when making the change rather than just letting them break with zero
communication.

Please also note that -done mails only go to the submitter of a bug,
with duplicated bugs like this one 


signature.asc
Description: PGP signature

Bug#897551: usbview: FTBFS: convert-im6.q16: unable to open file `/tmp/magick-20115vbmutCN0nGsV': No such file or directory @ error/constitute.c/ReadImage/544.

[Mark Brown]

clone 897551 -1
reassign -1 imagemagick
retitle -1 imagemagic: Errors converting SVG to PNG causing build failures
thanks

On Wed, May 02, 2018 at 10:55:01PM +0200, Lucas Nussbaum wrote:

> > make[2]: Entering directory '/<>'
> > convert -geometry $(basename $(dirname $(dirname 
> > hicolor/64x64/apps/usbview_icon.xpm))) usbview_icon.svg 
> > hicolor/64x64/apps/usbview_icon.xpm
> > convert-im6.q16: delegate failed `'rsvg-convert' -o '%o' '%i'' @ 
> > error/delegate.c/InvokeDelegate/1919.
> > convert-im6.q16: unable to open file `/tmp/magick-20115vbmutCN0nGsV': No 
> > such file or directory @ error/constitute.c/ReadImage/544.
> > convert-im6.q16: no images defined `hicolor/64x64/apps/usbview_icon.xpm' @ 
> > error/convert.c/ConvertImageCommand/3258.
> > make[2]: *** [Makefile:964: hicolor/64x64/apps/usbview_icon.xpm] Error 1

> The full build log is available from:
>
> http://aws-logs.debian.net/2018/05/02/usbview_2.0-21-g6fe2f4f-1_unstable.log

This appears to be triggered by some internal bug in ImageMagick, the
"delegate failed" messsage doesn't appear to be an intentional error
message and I can't see any obvious indication that there's been an
intentional change in the ImageMagick CLI.


signature.asc
Description: PGP signature

Bug#853714: yp-tools_3.3-5.1_source.changes ACCEPTED into unstable

[Mark Brown]

On Wed, Mar 28, 2018 at 12:27:03PM +0100, James Cowgill wrote:
> On 28/03/18 02:56, Mark Brown wrote:

> > bugs are useful for keeping it out of releases.

> I emailed the BTS with the diff on Thursday last week. The BTS says it
> forwarded the email to you:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853714#21

I'm seeing no sign of that mail having arrived on my systems.  No idea
what happened there...

> If you don't want the package in the next release, you should file a
> separate RC bug for it or at minimum email the bug explaining why it is
> still open.

I wasn't specifically using these bugs to keep the package out of
testing (it does no harm there, it's just not useful), the problem is
more that every out of tree patch added to the package makes it harder
to work with and make useful.


signature.asc
Description: PGP signature

Bug#853714: yp-tools_3.3-5.1_source.changes ACCEPTED into unstable

[Mark Brown]

On Tue, Mar 27, 2018 at 08:51:30PM +, Debian FTP Masters wrote:

>* Non-maintainer upload.
>* debian/patches:
>  - Add patch to fix FTBFS with GCC 7. (Closes: #853714)
>  - Add patch to fix FTBFS on architectures with strict alignment
>requirements. (Closes: #836021)

Please don't send unnanounced non-maintainer uploads - note that this
package can't ever be usefully installed or used at the moment as the
rest of the NIS suite isn't split out into separate packages, the RC
bugs are useful for keeping it out of releases.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sat, Jan 07, 2017 at 11:15:51AM +0100, Matthias Klose wrote:

> multiarch is not yet ready; you can't build it on the buildds, you can't 
> depend
> on foreign architectures on the buildds.  If you want to spend some time 
> working
> on this, it would be appreciated, but until then I think it's better to make
> these packages working.

Right, but as I said before it doesn't seem like anyone is doing that
with programs written in D and it also doesn't seem likely that they'll
start soon.  I'm just not seeing the users here.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Fri, Jan 06, 2017 at 08:48:06AM +0100, Matthias Klose wrote:
> On 05.12.2016 18:50, Mark Brown wrote:

> > As we have been discussing it is still not clear to me if I should fix
> > or remove the multilib packages since it is still not clear to me that
> > there is a sensible use case for them.  As things stand I'm still not
> > seeing much of a use case here so it seems like the best thing to do
> > would be to remove the multilibs.

> If this didn't become clear, may I suggest to fix the packages for the release
> instead of removing them?

I got that, what I still don't have a handle on is why that's a good
idea - it was a worrying struggle to understand what was going on and
even now that I think I've got that figured out it feels like something
that's just being done by default and I am concerned that the packages
will do more harm than good given the confusion they can cause with
respect to multiarch.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Mon, Dec 05, 2016 at 06:24:46PM +0100, Matthias Klose wrote:
> On 05.12.2016 18:14, Mark Brown wrote:

> > I am suggesting that since nothing except for the multlib D runtime
> > packages needs a multilib zlib and there seems to be a very limited use
> > case for them it seems better to just not ship the multilib runtime for
> > D and instead have people who want to build or run non-native D code use
> > multiarch.  That's where we want to get to anyway.

> >> PS: I pinged about a) moving back zconf.h to /usr/include and b) running
> >> dh_makeshlibs for the 64bit multilib variant. Any update on this?

> > I saw your content free pings.

> If the ping should have been content free, than the content should be in the 
> PS.
>  Or please could you tell me what you are missing?

As we have been discussing it is still not clear to me if I should fix
or remove the multilib packages since it is still not clear to me that
there is a sensible use case for them.  As things stand I'm still not
seeing much of a use case here so it seems like the best thing to do
would be to remove the multilibs.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Mon, Dec 05, 2016 at 04:40:29PM +0100, Matthias Klose wrote:
> On 05.12.2016 11:29, Mark Brown wrote:
> > On Wed, Nov 30, 2016 at 03:31:59PM +0100, Matthias Klose wrote:

> >> it's available in the GCC packages for a while now.

> > Sure, but there's a bunch more stuff needed.

> sorry, I don't understand what you mean.

Getting full x32 support is going to require more than just the
compiler.

> Well, there are less requirements for the C and C++ runtime libraries 
> (basically
> glibc), but the D runtime library requires one more, zlib. I'm not sure what 
> you
> are arguing here.

I am suggesting that since nothing except for the multlib D runtime
packages needs a multilib zlib and there seems to be a very limited use
case for them it seems better to just not ship the multilib runtime for
D and instead have people who want to build or run non-native D code use
multiarch.  That's where we want to get to anyway.

> PS: I pinged about a) moving back zconf.h to /usr/include and b) running
> dh_makeshlibs for the 64bit multilib variant. Any update on this?

I saw your content free pings.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Wed, Nov 30, 2016 at 03:31:59PM +0100, Matthias Klose wrote:
> On 30.11.2016 13:45, Mark Brown wrote:

> > Well, there's a bunch of questions there - people seem generally
> > negative on x32 and the use cases for multilib with tooling for early
> > boot and so on don't seem to apply in any case.  I'd really have
> > expected that it'd just be added as a new architecture at this point.

> it's available in the GCC packages for a while now.

Sure, but there's a bunch more stuff needed.

> > install the multiarch runtime?  The motivation I'm aware of for still
> > having the multilib packages is to allow other multilib packages to be
> > built with them but I'm not seeing any packages written in D (and it'd
> > be pretty surprising TBH given the narrow use case) so I'm not seeing
> > the use case.

> If we remove everything where "people seem generally negative on FOO", we'll 
> end
> up with a really small distro. We still require the multilibs for 32bit
> architectures needing to build 64bit kernels, and I'd rather not ask people to
> work around issues when they can be fixed.

These are good reasons for having multilib for C and (to a bit of a
lesser extent) C++ but this is D which is a different thing - it's a new
language which is much less widely used.  It is much more difficult to
see the use case for D, as far as I can tell the applications don't
really need multilibs.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Tue, Nov 29, 2016 at 02:00:48PM +0100, Matthias Klose wrote:
> On 28.11.2016 19:42, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote:

> > Which apparently changed at some point in the toolchain, probably quite
> > some time ago, but fortunately we'd actually managed to remove all the
> > users before that happened so it didn't affect anyone.

> Wrong. Until the zconf.h header was moved from /usr/include to
> /usr/include/ these packages found the *wrong* header in
> /usr/include, now they don't find anything anymore.

So that'll be what changed.  But really this is a bug in the multiarch
support, zconf.h isn't at all architecture specific within the context
of Debian (there's a few things that change but they're all related to
completely non-Unix OSs).

> > Right now as far as I can tell there's been some change in the GNU D
> > compiler that's attempting to add usage of the multilib zlib versions
> > for some reason which is not at all clear to me.  You said something
> > about moving the GDC runtime to a shared library but I'm finding that
> > confusing as the issue with the header file as should also affect static
> > usage so it seems like there must be something else in the mix
> > somewhere.

> The libphobos configury falls back to the zlib copy shipped within the GCC
> sources, when the system zlib cannot be used. So sure, dropping the build
> dependencies on the multilib zlib packages does use the embedded copy, but
> that's not what you usually want to do.

OK, so this makes at least that part of things clearer.  It's not a
result of linking against the DSO but rather a result of not using an
embedded copy of the source.

> > It seems there's also something going on with x32 but as far as I can
> > tell that's orthogonal though it does seem to be related to changes in
> > GDC as well somehow.

> that's just the third multilib on amd64 and i386.

Well, there's a bunch of questions there - people seem generally
negative on x32 and the use cases for multilib with tooling for early
boot and so on don't seem to apply in any case.  I'd really have
expected that it'd just be added as a new architecture at this point.

> > Shouldn't people building i386 D programs on amd64 (or other similar
> > builds that would historically have been done with multilib) just be
> > using multiarch to install the 32 bit runtime?  Please bear in mind
> > that I'm not at all familiar with D here.

> there's nothing you need to understand with D, just that it tries to use zlib 
> as
> a dependency.

No, it's trying to use a multilib zlib as a dependency.  That's still
really unclear to me here - to repeat my question above why aren't we
asking people who want to build non-native D applications to just
install the multiarch runtime?  The motivation I'm aware of for still
having the multilib packages is to allow other multilib packages to be
built with them but I'm not seeing any packages written in D (and it'd
be pretty surprising TBH given the narrow use case) so I'm not seeing
the use case.

> So removing these packages is fine with me too; in this case, please wait with
> the removal and I'll prepare a new source package to build these multilib
> libraries for the stretch release.

No, that's obviously not a good solution as it just ends up duplicating
the source.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sun, Nov 27, 2016 at 06:39:22PM +0200, Sami Liedes wrote:

> It seems to me that Mark is saying that this is not even supposed to
> work with lib32z1-dev installed, but rather you should have
> zlib1g-dev:i386 installed (and not doing so is user error).

Right, that's now the expected way for users to get an i386 version on
amd64.

> I found this surprising (and wonder what lib32z1-dev is actually for
> then), but as I don't know how these packages are supposed to work, I
> won't take a position. I am happy enough that I got things working by
> installing zlib1g-dev:i386.

In the past before Debian supported coinstallation of packages from
multiple architectures on one system (multiarch) some packages like zlib
were built specially to provide binaries for one architecture in
packages for another architecture (so lib32z1 is a 32 bit version of
zlib built as a package for a 64 bit architecture for example).  This
was called multilib and the goal has been to phase it out in favour of
using multiarch.

It appears that there have been changes in the toolchain that mean that
broke the multilib packages (I'm guessing that it was some of the
multiarch implementation) but given the availability of multiarch which
supports all libraries rather than just ones that have been specially
built people should be using that instead.  There are some cases where
the infrastructure isn't able to cope yet which may be what's going on
here but they definitely don't apply to end users.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sat, Nov 26, 2016 at 08:59:34PM +0100, Matthias Klose wrote:
> On 26.11.2016 20:35, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote:
> >> On 26.11.2016 19:42, Mark Brown wrote:
> >>> On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote:

> >> This exactly is the correct issue, not "some random bug".

> > I'm afraid I'm still unclear what you are trying to do or why.

> well, you removed the example from your reply and didn't comment on it.

That is one of several different things you've been talking about which
seem to be related somehow to at least one underlying goal.  I'm still
trying to figure out that underlying goal here to work out what the most
sensible thing to do is.

> The example fails because the zconf.h header is not found. You can see the 
> list
> of the standard include paths when calling gcc with the -v option.

Which apparently changed at some point in the toolchain, probably quite
some time ago, but fortunately we'd actually managed to remove all the
users before that happened so it didn't affect anyone.

Right now as far as I can tell there's been some change in the GNU D
compiler that's attempting to add usage of the multilib zlib versions
for some reason which is not at all clear to me.  You said something
about moving the GDC runtime to a shared library but I'm finding that
confusing as the issue with the header file as should also affect static
usage so it seems like there must be something else in the mix
somewhere.

It seems there's also something going on with x32 but as far as I can
tell that's orthogonal though it does seem to be related to changes in
GDC as well somehow.

As things stand it seems like the best thing to do just looking at this
issue by itself is remove the multilib zlib packages since they've been
broken for some time without anyone noticing and we have multiarch so
there shouldn't be any need for new users.  However I don't want to just
upload that right now since you're looking to add new users though I'm a
bit confused as to why, it seems like a step backwards.

Shouldn't people building i386 D programs on amd64 (or other similar
builds that would historically have been done with multilib) just be
using multiarch to install the 32 bit runtime?  Please bear in mind
that I'm not at all familiar with D here.


signature.asc
Description: PGP signature

Bug#787956: raising the severity, prevents usage of the multilib packages

[Mark Brown]

On Sat, Nov 26, 2016 at 07:52:26PM +0100, Matthias Klose wrote:
> On 26.11.2016 19:42, Mark Brown wrote:
> > On Sat, Nov 26, 2016 at 03:56:21PM +0100, Matthias Klose wrote:

> > Please allow at least a little time for a response, I've no real idea
> > what you're even asking for here.

> well, I asked you in private before, without getting replies on all messages 
> and
> proposals.

You sent me a mail last week asking for some additional multilib
packages for x32 ABI which seemed a bit strange at this point in the
release cycle and not that urgent as a new ABI would be at most
wishlist.  I'd been intending to have a look to try to work out what's
going on with x32 over the weekend.  I'm having a hard time relating
that to what you're talking about here though I do see you mentioned
that this was for "libgphobos (gdc runtime)" in both.

> This exactly is the correct issue, not "some random bug".

I'm afraid I'm still unclear what you are trying to do or why.  This is
a bug about trying to use the lib32z1-dev package, your private mails
were about adding x32 multilib packages and I'm really confused about
how either of these things relates to the shared libgphobos you keep
mentioning.  The proposed changes below don't have anything to do with
x32 either so I'm just completely confused now.

Can you please provide a clear, from first steps description of what's
needed and why?

> attaching the diff for the proposed changes

Please do not upload this, I will be back at home on Monday and can do
an upload then and...

> +  * Non-maintainer upload.
> +  * Install the zconf.h header file for the multilib packages. Closes: 
> #787956.
> +  * Use the target prefixed ar, available since binutils 2.26.
> +  * Run dh_makeshlibs for the 64bit multilib library.
> +  * Add ${misc:Depends} to zlib1g-dbg's dependencies.
> +  * Support nobiarch build profile (Johannes Schauer). Closes: #709623.

...this clearly isn't just fixing the bug and there are a bunch of
additional changes not mentioned in the changelog.  

I need to investigate what's going on here as I'm unconvinced that this
doesn't introduce further problems (will this break multiarch for
example, I appear to be able to build with -m32...).  This might be a
lot clearer with split out incremental patches and really seems
inappropriate for a zero notice NMU.

> -Standards-Version: 3.9.4
> +Standards-Version: 3.9.8

If you're making changes like this they ought to be mentioned in the
changelog.

> -Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) 
> [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc 
> ppc64 s390 sparc s390x], dpkg-dev (>= 1.16.1)
> +Build-Depends: debhelper (>= 9), gcc-multilib [amd64 i386 kfreebsd-amd64 
> mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1)

Not sure why the debhelper dependency got changed or why we dropped the
binutils dependency.

Bug#812532: files with the same name installed in / and /usr

[Mark Brown]

On Sun, Oct 23, 2016 at 02:06:29AM +0200, Marco d'Itri wrote:
> On Oct 23, Mark Brown <broo...@debian.org> wrote:

> > I'd have expected to at least have seen something going round saying
> > that the transition was mostly complete and that there were only a few
> > packages blocking it prior to just dumping a new version of deboostrap
> > in unstable and rendering everything instabuggy.  Most similar

> I did this in *february* for the other packages, but not this one since 
> you had recently suggested that it was not ready anyway.

Telling other package maintainers doesn't help me know that this is a
transition that's actually happening, and one of the things that would
tell me that there might be some sense of urgency would be an indication
that the transition was actually happening.  I do remember you asking me
about my plans to fix it but there was no context that this was anything
more than a "hey, it'd be nice sometime".  For things like this even if
people aren't working on something now if there's a bigger picture it's
good to tell people about it, something like "OK, but please note that
we're actively working on this transition and expect it to be done for
stretch" would've really helped here in avoiding surprise with sudden RC
bugs out of nowhere.

> > I didn't ask for help because I just don't care about this transition,
> > in part because as I indicated there's no way to really use yp-tools at
> > present so it's the least of anyone's worries so when I'm spending time

> Maybe then the package should not be in testing anyway?

It's not impossible that someone could use it, it's just not as useful
as it could be.


signature.asc
Description: PGP signature

Bug#812532: files with the same name installed in / and /usr

[Mark Brown]

On Sun, Oct 23, 2016 at 01:18:54AM +0200, Marco d'Itri wrote:
> On Oct 23, Mark Brown <broo...@debian.org> wrote:

> > Which was uploaded yesterday without warning which isn't exactly
> > helpful, there's not even been a proposal from anyone working on this
> > for how to fix it.  I would expect that if something like this were
> > going to be imposed it'd be imposed towards the start of the release
> > cycle rather than at the very end.

> We have been discussing switching to merged /usr for over two years and 
> there are just five broken packages left, all of them rarely used.

My expectation is that the people working on a transition like this
would be pushing it forwards - things get talked about for a long time
often (and Debian is quite big so the fact that some people have been
talking about it doesn't mean everyone knows), there's a difference
between talking about something and it actually happening.  In the case
of merging / and /usr it's been talked about for pretty much as long as
I've been involved in Debian but the change in bug severity was the
first indiciation I'd had that there was a chance of it actually being
implemented.

I'd have expected to at least have seen something going round saying
that the transition was mostly complete and that there were only a few
packages blocking it prior to just dumping a new version of deboostrap
in unstable and rendering everything instabuggy.  Most similar
transitions have come along with patches (usually quite early on in the
process) though it's not always possible, in this case I suspect it is.

> This bug has been open since january and you never asked for help 
> (actually you hinted that yp-tools was useless anyway as is).

I didn't ask for help because I just don't care about this transition,
in part because as I indicated there's no way to really use yp-tools at
present so it's the least of anyone's worries so when I'm spending time
on these packages it'd be on the things that are required to make the
package more practically useful.

> We (people interested in merged /usr) are not going to waste another 
> release cycle.

That doesn't mean it's a good idea to just implement the transition
quite late in the release cycle without making any effort to coordinate
with the affected packages.  Some advance warning would have made all
the difference here.


signature.asc
Description: PGP signature

Bug#812532: files with the same name installed in / and /usr

[Mark Brown]

severity 812532 serious

On Sun, Oct 23, 2016 at 12:36:18AM +0200, Marco d'Itri wrote:
> Control: severity -1 grave

Please don't play severity games, it's not at all helpful.  

> On Jan 24, Marco d'Itri  wrote:

> > which have the same name of file installed by the hostname package in 
> > /bin/, so this breaks the package when installed on a marged /usr system.

> Merged /usr is the default since debootstrap 1.0.85, so the package
> is uninstallable on new systems.

Which was uploaded yesterday without warning which isn't exactly
helpful, there's not even been a proposal from anyone working on this
for how to fix it.  I would expect that if something like this were
going to be imposed it'd be imposed towards the start of the release
cycle rather than at the very end.


signature.asc
Description: PGP signature

Bug#837712: Processed: severity of 837712 is serious

[Mark Brown]

On Fri, Oct 21, 2016 at 05:45:39PM +0200, Lucas Nussbaum wrote:
> On 21/10/16 at 16:32 +0100, Mark Brown wrote:

> > > Bug #837712 [src:xemacs21] xemacs21: FTBFS with bindnow and PIE enabled
> > > Severity set to 'serious' from 'important'

> > I've still not seen any usable reproduction instructions.

> Well it fails to build in a standard, up-to-date unstable chroot here.
> That was what I implied with the '# now fails in unstable' comment in my
> BTS control message.

> You cannot reproduce it? Could you send a build log so that we could
> diff it with mine?

Oh, someone uploaded these compilers to unstable?  Nice :(  I'll go take
a look.  Comments in the BTS messages really aren't visible, the
messages are very noisy so it's hard to spot them.


signature.asc
Description: PGP signature

Bug#837712: Processed: severity of 837712 is serious

[Mark Brown]

On Fri, Oct 21, 2016 at 02:08:47PM +, Debian Bug Tracking System wrote:

> Bug #837712 [src:xemacs21] xemacs21: FTBFS with bindnow and PIE enabled
> Severity set to 'serious' from 'important'

I've still not seen any usable reproduction instructions.


signature.asc
Description: PGP signature

Bug#837225: xemacs21: FTBFS: Can't locate var_file.pl in @INC

[Mark Brown]

On Sat, Sep 10, 2016 at 09:30:31AM +0200, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build on
> amd64.

FFS, why did this suddenly break and if it's due to the perl include
transition why did it not get reported in the mass bug filing for this?


signature.asc
Description: PGP signature

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Mark Brown]

On Fri, Jan 22, 2016 at 01:47:36PM -0800, Nye Liu wrote:

> > It should eventually figure things out?

> No, but I have a patch for nis script, attached...

I can't tell what this patch is supposed to do, sorry.

> --- dist/nis2016-01-20 16:18:24.171239577 -0800
> +++ nis 2016-01-22 13:08:19.532968676 -0800
> @@ -43,24 +43,38 @@
> 
> if [ "`ypwhich 2>/dev/null`" = "" ]
> then
> +   running=""
> bound=""
> log_action_begin_msg "binding to YP server"
> -   for i in 1 2 3 4 5 6 7 8 9 10
> +   for i in `seq 10`
> do
> sleep 1
> -   log_action_cont_msg "."
> -   if [ "`ypwhich 2>/dev/null`" != "" ]
> +   # make sure ypbind started; rpcbind might not be 
> ready yet
> +   if [ -n "$( pidofproc ${NET}/ypbind )" ]
> then
> -   echo -n " done] "
> -   bound="yes"
> -   break
> +   log_action_cont_msg "."
> +   running="yes"
> +   if [ "`ypwhich 2>/dev/null`" != "" ]
> +   then
> +   echo -n " done] "
> +   bound="yes"
> +   break
> +   fi
> +   else
> +   running=""
> +   # try to start ypbind again
> +   log_action_cont_msg "x"
> +   ypbind_start
> fi
> done
> # This should potentially be an error
> if [ "$bound" ] ; then
> log_action_end_msg 0
> -   else
> +   elif [ "$running" ] ; then
> log_action_end_msg 1 "backgrounded"
> +   else
> +   log_action_end_msg 1 "failed"
> +   exit 1
> fi
> fi
>  }


signature.asc
Description: PGP signature

Bug#754121: AICCU not starting on boot in Debian

[Mark Brown]

On Wed, Feb 17, 2016 at 05:46:53PM +0100, Jeroen Massar wrote:
> On 2016-02-17 17:00, Mark Brown wrote:

> > Right, but I do think AICCU can deal better with this situation.  Not
> > dealing with it makes system integration much harder as there are a
> > range of options that users have for configuring their network in most
> > distributions

> Which 'options' are not properly handled? What is the real actual
> problem you are trying to solve?

The case that is most difficult for me to eliminate in my system is that
where both the router and the modem (which are separate devices) are
being started at the same time.  AICCU is running on the router, it will
most likely have a connection to the modem prior to the modem uplink
being ready.  I am particularly concerned about this for unattended
boots (for example, after power loss) but it'd be nice if it worked in
general.

> > including off-system network connectivity like
> > routers which the distribution has little chance to integrate with).

> You know this Internet thing, it is rather big, lots of routers are
> involved in a typical connection, only few a user has control over, let

I am aware of this, thanks.

> alone zero that AICCU can do anything about.

I'd argue that AICCU can do things to help.

> > I disagree here.  While it is true that AICCU can not resolve this issue
> > for itself I think it can handle it more gracefully, it can sit and keep 
> > trying so that when the situation is resolved then AICCU will recover.

> How long should it keep on hammering on services for the situation to
> resolve itself?

I'd expect it to try indefinitely.  I'd not expect it to hammer on
things but rather to try periodically.

> > This is more in line with what other services like mail servers

> You mean a mail client (MUA) like Thunderbird I hope.

> Guess what that does, indeed, it shows an error to the user that the
> connection fails.

> Mail servers are a quite different kind of beast, they do not sit at a
> user end.

I actually mean both (basically, anything that maintains a queue could
have such behaviour - there are simple MTAs specifically designed for
centralizing the mail queue on a system, this is useful as it allows
utilities to do e-mail without requiring configuration duplication or
wheel reinvention).  The text mail clients I use use a central MTA and
just return as soon as they've handed over to it, Evolution just
silently queues things for sending at a later time unless you've started
an explicit sync operation (or did last time I checked anyway).

> > or things like ypbind

> ypbind also nicely bails out when there is no connectivity. No need to
> keep on trying something it cannot resolve.

No, it doesn't - it will just sit there in in the background and retry
periodically.  Distro init scripts will tend to wait for it to bind in
order to support other things that might want to use the binding but the
daemon itself will happily sit there.  At least in the Debian case we
wait for a while and then just carry on, leaving ypbind running in the
background.

> > do - they start up, attempt to perform their
> > functions and retry if those fail.  It's also more in line with what
> > happens if there is a connectivity interruption after the daemon has
> > started.

> I'll repeat it again AICCU handles connectivity failures AFTER start
> (fetching the config from TIC) perfectly fine

Right, and what I'm saying is that it would be much more helpful if it
were able to handle failures at startup in a similar fashion.  It is
normal to do some rate limiting (eg, retry at some interval rather than
constantly) and to have options to control that behaviour for cases
where there are concerns about resource usage.


signature.asc
Description: PGP signature

Bug#754121: AICCU not starting on boot in Debian

[Mark Brown]

On Wed, Feb 17, 2016 at 04:03:22PM +0100, Jeroen Massar wrote:
> On 2016-02-17 13:47, Mark Brown wrote:

> > Let me try to provide that...  We now no longer have the problems in the
> > original report with the boot hanging but we still don't have AICCU
> > coming up reliably at boot.

> You should start AICCU when you have proper connectivity (time synced,
> DNS resolving works, and you can actually can make connections outbound).

> Doing it to early is not the way to do it.

> This is not something that AICCU can do, as it does not know when your
> system is "connected to the Internet", only the user behind the machine
> knows this.

Right, but I do think AICCU can deal better with this situation.  Not
dealing with it makes system integration much harder as there are a
range of options that users have for configuring their network in most
distributions (and of course network connectivity may appear and
disappear at any point, including off-system network connectivity like
routers which the distribution has little chance to integrate with).

> > There's probably some init based fix for this but I'd also expect AICCU
> > to handle this more gracefully by retrying resolver failures, it seems
> > like this is something that is reasonably likely to happen during the
> > startup process.

> As AICCU cannot resolve your DNS issue and only an administrator of the
> machine, or the DNS service, or the connectivity provider etc can, AICCU
> cannot resolve this and thus restarting it or letting it retry does not
> resolve the problem.

I disagree here.  While it is true that AICCU can not resolve this issue
for itself I think it can handle it more gracefully, it can sit and keep 
trying so that when the situation is resolved then AICCU will recover.
If nothing changes the user is no worse off, and if the external factors
that were causing connectivity issues are resolved then things will
start working.

This is more in line with what other services like mail servers or
things like ypbind do - they start up, attempt to perform their
functions and retry if those fail.  It's also more in line with what
happens if there is a connectivity interruption after the daemon has
started.


signature.asc
Description: PGP signature

Bug#754121: AICCU not starting on boot in Debian

[Mark Brown]

Hi,

There's a bug open in Debian about AICCU not starting when used with
systemd (though it's most likely not that specifically).  One of the
last things in the bug log is:

| Actually, a concise problem statement would be a good thing to have, as
| it seems completely lost in the bug report.

Let me try to provide that...  We now no longer have the problems in the
original report with the boot hanging but we still don't have AICCU
coming up reliably at boot.  The problem seems to be that AICCU is
started before the network is available (this is with the network
managed via NetworkManager) and can't cope with that:

Feb 17 12:19:11 slippershell aiccu[517]: Couldn't resolve host tic.sixxs.net, 
service 3874
Feb 17 12:19:11 slippershell aiccu[517]: Couldn't connect to the TIC server 
tic.sixxs.net
Feb 17 12:19:11 slippershell aiccu[517]: Couldn't retrieve first tunnel for the 
above reason, aborting

There's probably some init based fix for this but I'd also expect AICCU
to handle this more gracefully by retrying resolver failures, it seems
like this is something that is reasonably likely to happen during the
startup process.

Restarting after boot does seem to work perfectly happily, it's just the
above issue.  I'm guessing that this is what the ifup.d script that was
there in earlier package versions was intended to fix.

Thanks,
Mark


signature.asc
Description: PGP signature

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Mark Brown]

reassign 812371 rpcbind

On Fri, Jan 22, 2016 at 01:03:00PM -0800, Nye Liu wrote:
> Package: nis
> Version: 3.17-34
> Severity: critical
> Justification: breaks the whole system

> For some reason, even though $portmap is mentioned in /etc/init.d/nis as a
> start prereq, ypbind is started BEFORE rpcbind.

That sounds like an issue with the sysetmd conversion there, or possibly
with the systemd/sysvinit integration.  Note that I'm in the middle of
repackaging the nis programs, I just got the core yp-tools package in so
we should get that sometime next month hopefully. 

> This causes ypbind to NEVER properly start, and the bind_wait obviously cannot
> ever succeed.

It should eventually figure things out?


signature.asc
Description: PGP signature

Bug#800305: nis: Please migrate a supported debhelper compat level

[Mark Brown]

On Thu, Dec 31, 2015 at 01:59:42PM +0100, Petter Reinholdtsen wrote:

> I believe the attached patch will solve this issue.

The packaging is being redone with separate packages matching the
upstream release.  Since there seems to be quite a bit of latency
through new at the minute I'm currently hoping for the transition to be
done by March.


signature.asc
Description: PGP signature

Bug#778180: xemacs21: ftbfs with GCC-5

[Mark Brown]

On Thu, Oct 08, 2015 at 02:31:55PM +0800, YunQiang Su wrote:

> Any progress of this bug?
> It blocks some packages in to build for mips64el port.

I'm part way through upgrading to the latest upstream version.


signature.asc
Description: Digital signature

Bug#799326: zlib-bin: miniunzip unzips paths starting with ../

[Mark Brown]

clone 799326 -1
reassign minizip -1
kthxbye

Assigining a copy to minizip which is the package containing minizip in
current distributions, not deleting context as a result.

On Thu, Sep 17, 2015 at 11:27:36PM +0200, Marc Lehmann wrote:
> Package: zlib-bin
> Version: 1:1.2.7.dfsg-13
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Dear Maintainer,
> 
> I'm using miniunzip as replacement for info zip, as miniunzip seems
> to be the only program in debian gnu/linux that can properly unpack
> international filenames (presumably by treating them as binary, which is
> better than info-zip, which mangles them so the original names are lost).
> 
> Unfortunately, miniunzip contains at least one big security problem,
> namely it unpacks filenames starting with ../ (and presumably filenames
> with embedded /../ components).
> 
> That means a malicious zip file containing e.g. ../../home/user/.profile
> or ../../../../../etc/passwd could overwrite files not intended for 
> overwriting.
> 
> I haven't tested wether miniunzip also unpacks filenames starting with /.
> 
> In these cases, miniunzip should remove the initial ../ or /, and probably
> fail when it ecounters embedded /../ components.
> 
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 
> 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.1.4-040104-generic (SMP w/12 CPU cores)
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages zlib-bin depends on:
> ii  libc6   2.19-18+deb8u1
> ii  zlib1g  1:1.2.8.dfsg-2+b1
> 
> zlib-bin recommends no packages.
> 
> zlib-bin suggests no packages.
> 
> -- no debconf information
> 
> -- debsums errors found:
> prelink: /opt/bin/leaplogin: Could not find one of the dependencies
> prelink: /opt/bin/gvpectrl.n900: Dependency tracing failed
> prelink: /opt/bin/netscape: Could not find one of the dependencies
> prelink: /opt/bin/cem: Could not find one of the dependencies
> prelink: /opt/bin/shgenSBRDF: Could not find one of the dependencies
> prelink: /opt/bin/Grimrock: Could not find one of the dependencies
> prelink: /opt/bin/cadaverserver: Could not find one of the dependencies
> prelink: /opt/bin/catrats: Could not find one of the dependencies
> prelink: /opt/bin/pakx: Could not find one of the dependencies
> prelink: /opt/bin/cadaverspyboss: Could not find one of the dependencies
> prelink: /opt/bin/shrike: Could not find one of the dependencies
> prelink: /opt/bin/shgenmap: Could not find one of the dependencies
> prelink: /opt/bin/ccgo: Could not find one of the dependencies
> prelink: /opt/bin/shgencubemap: Could not find one of the dependencies
> prelink: /opt/bin/ndump: Could not find one of the dependencies
> prelink: /opt/bin/pakc: Could not find one of the dependencies
> prelink: /opt/bin/nstats: Could not find one of the dependencies
> prelink: /opt/bin/v4l2info: Could not find one of the dependencies
> prelink: /opt/bin/shsparse: Could not find one of the dependencies
> prelink: /opt/bin/gtkpak: Could not find one of the dependencies
> prelink: /opt/sbin/gvpe.n900: Dependency tracing failed
> prelink: /opt/sbin/ssldecode: Could not find one of the dependencies
> prelink: /opt/bin/leaplogin: Could not find one of the dependencies
> prelink: /opt/bin/gvpectrl.n900: Dependency tracing failed
> prelink: /opt/bin/netscape: Could not find one of the dependencies
> prelink: /opt/bin/cem: Could not find one of the dependencies
> prelink: /opt/bin/shgenSBRDF: Could not find one of the dependencies
> prelink: /opt/bin/Grimrock: Could not find one of the dependencies
> prelink: /opt/bin/cadaverserver: Could not find one of the dependencies
> prelink: /opt/bin/catrats: Could not find one of the dependencies
> prelink: /opt/bin/pakx: Could not find one of the dependencies
> prelink: /opt/bin/cadaverspyboss: Could not find one of the dependencies
> prelink: /opt/bin/shrike: Could not find one of the dependencies
> prelink: /opt/bin/shgenmap: Could not find one of the dependencies
> prelink: /opt/bin/ccgo: Could not find one of the dependencies
> prelink: /opt/bin/shgencubemap: Could not find one of the dependencies
> prelink: /opt/bin/ndump: Could not find one of the dependencies
> prelink: /opt/bin/pakc: Could not find one of the dependencies
> prelink: /opt/bin/nstats: Could not find one of the dependencies
> prelink: /opt/bin/v4l2info: Could not find one of the dependencies
> prelink: /opt/bin/shsparse: Could not find one of the dependencies
> prelink: /opt/bin/gtkpak: Could not find one of the dependencies
> prelink: /opt/sbin/gvpe.n900: Dependency tracing failed
> prelink: /opt/sbin/ssldecode: Could not find one of the dependencies
> 


signature.asc
Description: Digital signature

Bug#778180: xemacs21: ftbfs with GCC-5

[Mark Brown]

On Fri, Jul 10, 2015 at 03:57:40PM -0600, Brett Johnson wrote:

 gcc5 changes the semantics of inline function declarations, causing some
 inline functions in xemacs to be considered extern, and thus cause

In what way does it change the semantics - this seems like a very
surprising and counterintuitive thing to do?


signature.asc
Description: Digital signature

Bug#778180: xemacs21: ftbfs with GCC-5

[Mark Brown]

tag 778180 - patch
kthxbye

 --- xemacs21-21.4.22.orig/configure.in
 +++ xemacs21-21.4.22/configure.in
 @@ -1941,6 +1941,8 @@ if test $cflags_specified = no; then
  CFLAGS=-g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes
  dnl Yuck, bad compares have been worth at least 3 crashes!
  CFLAGS=$CFLAGS -Wsign-compare
 +dnl Use old gnu inline semantics because we're too lazy to fix the source
 +CFLAGS=$CFLAGS -fgnu89-inline
  dnl XEmacs is known not to be strict-aliasing-safe.
  case `gcc -v --help 21` in
*-fstrict-aliasing* ) CFLAGS=$CFLAGS -fno-strict-aliasing ;;

The other thing here is that if we're overriding CFLAGS we should do it
in the packaging, not by editing configure - I've done this locally.


signature.asc
Description: Digital signature

Bug#778180: xemacs21: ftbfs with GCC-5

[Mark Brown]

On Thu, Aug 13, 2015 at 11:33:36AM -0400, Martin Michlmayr wrote:
 * Mark Brown broo...@debian.org [2015-08-13 12:51]:
   gcc5 changes the semantics of inline function declarations, causing some
   inline functions in xemacs to be considered extern, and thus cause

  In what way does it change the semantics - this seems like a very
  surprising and counterintuitive thing to do?

 Basically, GCC 5 changed the default from GNU89 inline semantics to
 C99 inline semantics.

 You can find more background here:
 https://gcc.gnu.org/gcc-5/porting_to.html
 see section Different semantics for inline functions

That doesn't seem to correspond to what is happening, AFAICT the
relevant things are static inline and this claims to affect only extern
inline functions.


signature.asc
Description: Digital signature

Bug#778180: xemacs21: ftbfs with GCC-5

[Mark Brown]

On Thu, Aug 13, 2015 at 09:39:09AM -0600, Brett Johnson wrote:

 I agree that it would be better to make the change in the packaging,
 rather than in configure.in. If you've already done this, would you
 mind submitting a patch?

Who would I submit a patch for the packaging to?!


signature.asc
Description: Digital signature

Bug#775733: Processed: unarchiving 775733

[Mark Brown]

On Mon, Jul 27, 2015 at 01:09:14PM +, Debian Bug Tracking System wrote:

  unarchive 775733
 Bug #775733 {Done: Mark Brown broo...@debian.org} 
 [src:xemacs21,xemacs21-gnome-mule,xemacs21-gnome-nomule,xemacs21-gnome-mule-canna-wnn]
  xemacs21-gnome-*: hangs during upgrade from squeeze - wheezy - jessie
 Unarchived Bug 775733
  thanks
 Stopping processing here.

I'm not sure what you're trying to do here but can you *please* stop
faffing around with this bug, it's been fixed for a while now and you're
making a lot of noise here.  I've also just seen an upload notification
for some version of this package I've never heard of - can you explain
what's going on here, this is the first I've heard of any planned
upload?


signature.asc
Description: Digital signature

Bug#775733: fixed in xemacs21 21.4.22-12

[Mark Brown]

On Mon, Jul 27, 2015 at 03:56:03PM +0200, Andreas Beckmann wrote:
 On 2015-06-06 09:59, Andreas Beckmann wrote:
  On 2015-04-27 14:43, Andreas Beckmann wrote:
  On 2015-04-26 10:43, Debian Bug Tracking System wrote:
  #775733: xemacs21-gnome-*: hangs during upgrade from squeeze - wheezy - 
  jessie

  Thanks for getting this fixed in sid, please fix this in jessie, too.
  If you need help there, please let me know.

  I've now filed jessie-pu request http://bugs.debian.org/787904
  for backporting the recent fixes to jessie.

 This was approved, and after doing thorough upgrade checking in piuparts
 I've now uploaded 21.4.22-14~deb8u1 to jessie-pu via DELAYED/10.

This is the first I've heard of the above backport request!  Please at
least CC the maintainer of the package when asking to backport things.


signature.asc
Description: Digital signature

Bug#783704: xemacs21-support: fails to install: ln: failed to create symbolic link '/usr/lib/xemacs-21.4.22/etc': No such file or directory

[Mark Brown]

On Wed, Apr 29, 2015 at 01:20:37PM +0200, Andreas Beckmann wrote:

 xemacs21-support needs to ship the empty directory /usr/lib/xemacs-21.4.22
 Ship, don't mkdir!

This is what the circular dependency was for wasn't it (dpkg didn't used
to cope I believe)?

Again, *please* provide reproduction instructions when reporting things
- extremely long command lines (especially system specific ones) buried
in the middle of logs are not really doing that.

 The maintainer scripts could probably be simplified regarding these symlinks,
 but right now I don't have the time to look into this.

I'm not sure it's a useful use of time for anyone not doing automated
testing.

 Or are the compat symlinks in /usr/lib/xemacs-21.4.22 now obsolete?

IIRC they're used by the binaries.

 I'm curious that this didn't show up in my earlier tests I did with my
 patch you applied recently. Did something else change in the meantime?

I at least had to rewrite the changelog.  Are you *positive* you tested
every case here fully from a clean system with your modifications?

In any case I've added the empty directory.


signature.asc
Description: Digital signature

Bug#775733: xemacs21-gnome-*: hangs during upgrade from squeeze - wheezy - jessie

[Mark Brown]

On Fri, Mar 27, 2015 at 11:58:01PM +0100, gregor herrmann wrote:
 On Tue, 24 Mar 2015 10:18:44 -0700, Mark Brown wrote:

  Actually having opened the logs I'm not seeing the command lines, the
  logs appear to start with displaying output from the commend.

 And the output shows the used command lines very close to the top:

 % grep -n Command line xemacs21-gnome-mule* 

Near, but not actually at, the top where one would expect to find them
(and frankly the lines are so long that if I did see them I'm pretty
sure I'd just have skipped over them).


signature.asc
Description: Digital signature

Bug#775733: xemacs21-gnome-*: hangs during upgrade from squeeze - wheezy - jessie

[Mark Brown]

On Wed, Mar 18, 2015 at 12:41:56AM +0100, Andreas Beckmann wrote:
 On 2015-03-17 11:21, Mark Brown wrote:

  OK, thanks for the command lines.  How about the analysis for the patch?
  I'm not keen on just applying random changes without understanding.

Actually having opened the logs I'm not seeing the command lines, the
logs appear to start with displaying output from the commend.

 As I understood #735268, the strict dependency xemacs21-support -
 xemacs21 is no longer needed, so I removed that as well to break the
 circular dependency and always have a deterministic configuration order
 of the xemacs21 packages - that would simplify further debugging (which
 luckily was not needed). All xemacs21* packages passed my piuparts tests
 after applying this patch - no more hangs :-)

So you made this additional change in the hope that it might be
useful rather than as a targetted part of the same fix?  It is bad
practice to mix unrelated changes into a single patch since it makes
things harder to follow, means that review issues from unrelated changes
can mean that good parts of the change can't be applied or directed
appropriately.


signature.asc
Description: Digital signature

Bug#775733: xemacs21-gnome-*: hangs during upgrade from squeeze - wheezy - jessie

[Mark Brown]

On Tue, Mar 17, 2015 at 01:56:34AM +0100, Andreas Beckmann wrote:
 Package: 
 src:xemacs21,xemacs21-gnome-mule,xemacs21-gnome-nomule,xemacs21-gnome-mule-canna-wnn
 Followup-For: Bug #775733
 
 Attached are two new piuparts logs:
 * failure due to deadlock and timeout
 * success after patching xemacs
 
 The logfiles contain the piuparts command lines used.

OK, thanks for the command lines.  How about the analysis for the patch?
I'm not keen on just applying random changes without understanding.


signature.asc
Description: Digital signature

Bug#775733: Processed: reassign 775733 to src:xemacs21,xemacs21-gnome-mule,xemacs21-gnome-nomule,xemacs21-gnome-mule-canna-wnn ...

[Mark Brown]

On Mon, Mar 16, 2015 at 04:27:48PM +0100, Andreas Beckmann wrote:

 I can deterministically reproduce this bug in piuparts, haven't tried
 other means to get it reproduced.
 Please check the bug log for details and a patch.
 https://bugs.debian.org/775733

I can't see instructions for reproducing this in the report, all I can
see there is the statement that this is reproducible using piuparts but
there's nothing saying how exactly you tested (the piuparts logs aren't
enough since they don't obviously show how piuparts was invoked).

Looking at the patch there the changelog isn't sufficient for me to tell
how it's supposed to work.  As far as I can tell what it's saying is
that adding conflicts is supposed to fix the problem and you decided to
remove one of the dependencies in the patch as well?  At least that's
what the changelog in the patch says...  I'm not seeing any clear
analysis in the accompanying mail either - it basically just says I
changed these things and it seemed to go away.

I *suspect* that one of the things you mean to say is that the
dependency is no longer required due to the abstraction via the
emacsen-common package which is fair enough though not obviouly
something release critical.


signature.asc
Description: Digital signature

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Mark Brown]

On Sat, Feb 21, 2015 at 10:31:19AM +, Ian Campbell wrote:
 On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote:

  Neither of these appears to have disrupted the
  boot partition though so I'm not sure what's been doing that :/ .

 Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall
 grub-efi-amd64 trigger the bad behaviour?

No.  How frustrating.  I guess it's possible some old version had this
issue and I didn't notice due to lack of reboots?  Or some other package
perhaps?


signature.asc
Description: Digital signature

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Mark Brown]

On Fri, Feb 20, 2015 at 09:25:52AM +, Ian Campbell wrote:
 On Fri, 2015-02-20 at 14:21 +0900, Mark Brown wrote:

 This sounds, if I'm interpreting the paths correctly, like it relates
 somehow to the stuff Steve was doing in #708430, in as much as it sounds
 like your system is one which would benefit from enabling that new
 workaround (grub2/force_efi_extra_removable in debconf).

Yes, that looks like the same thing.  For some reason this system had
previously worked with the currently released installer, it's only had
issues with the jessie stuff.  

This is a 1st gen Lenovo Yoga, the other machine that's broken with a
fresh install is an Acer Aspire E11 (with BIOS 1.13 IIRC).  I can supply
more specific data on both if you tell me what you're looking for (I see
some talk of a blacklist in the bug though I'm not sure that made it
into the code).  The blacklist *would* be very nice.

 Do you have that new option enabled or disabled?

It appears to be set to false in my configuration.

 That said, even with the workaround disabled for some reason removing an
 existing boot/bootx86.efi doesn't sound right to me. Not that I have any
 how or why it would be happening :-/.

Yes, and me either.

 Looking at the code the only things I see which touch boot/bootx86.efi
 are behind the new force_efi_extra_removable option which attempts to
 update the binary -- I wonder if it is possible to fail half way and
 actually only remove the old one? (Some sort of weird vfat interaction?)

Tha shouldn't be happening from the sounds of it since the debconf
variable is set false and therefore the workaround shouldn't have been
kicking in (I'll go off and figure out how to set it though since I
appear to need it).

  Apologies if this is filed against the wrong package, I'm not 100% clear
  what is responsible for installing these files.

 It might actually be grub-efi-amd64, but I think you were close
 enough ;-).

I did ask Steve on IRC (but wasn't that specific about the bug I was
intendeding to file) so any credit is his.


signature.asc
Description: Digital signature

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Mark Brown]

Package: grub-efi-amd64-bin
Version: 2.02~beta2-20
Severity: critical

On a couple of occasions recently my system has been updated to remove
boot/bootx86.efi from the EFI boot partition, and on a new install on a
separate machine this file was not installed at all.  Instead
debian/grubx86.efi was left installed.  Unfortunately on both systems my
BIOS ignores this file and will only boot boot/bootx86.efi so these
updates make the system unbootable.

Severity critical due to the deletion of existing boot/bootx86.efi - one
on occasion this caused my system to boot into the Windows recovery
partition which proceeded to unconditionally start repartitioning the
system destroying data and without recovery media to hand it renders the
system unusuable even without that.

Apologies if this is filed against the wrong package, I'm not 100% clear
what is responsible for installing these files.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/disk/by-uuid/6424c5eb-8fa3-46fd-af94-8a581aa54f14 / ext4 
rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ ${next_entry} ] ; then
   set default=${next_entry}
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default=0
fi

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
6424c5eb-8fa3-46fd-af94-8a581aa54f14
else
  search --no-floppy --fs-uuid --set=root 6424c5eb-8fa3-46fd-af94-8a581aa54f14
fi
font=/usr/share/grub/unicode.pf2
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_GB
  insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
6424c5eb-8fa3-46fd-af94-8a581aa54f14
else
  search --no-floppy --fs-uuid --set=root 6424c5eb-8fa3-46fd-af94-8a581aa54f14
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-6424c5eb-8fa3-46fd-af94-8a581aa54f14' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  
6424c5eb-8fa3-46fd-af94-8a581aa54f14
else
  search --no-floppy --fs-uuid --set=root 
6424c5eb-8fa3-46fd-af94-8a581aa54f14
fi
echo'Loading Linux 3.18.0-trunk-amd64 ...'
linux   /boot/vmlinuz-3.18.0-trunk-amd64 
root=UUID=6424c5eb-8fa3-46fd-af94-8a581aa54f14 ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-3.18.0-trunk-amd64
}
submenu 'Advanced 

Bug#773359: Unauthorised activity surrounding tbb package

[Mark Brown]

On Sun, Jan 18, 2015 at 10:09:34AM +0100, Andreas Tille wrote:
 On Fri, Jan 16, 2015 at 04:48:33PM +, Steven Capper wrote:

  we have had no discussion
  over #773359; your response is effectively placing words in my mouth
  and I will not tolerate that. To confound matters, I wasn't even CC'ed
  in on the response!

 Usually it is expected that the maintainer receives every posting to the
 bugs of the package he maintains.  So there was no real point to add an
 additional CC.

The followups were sent to -submitter which unfortunately explicitly
doesn't CC the maintainer (I guess the main intended use case is for the
maintainer to talk to the submitter), an extra CC needs to be added to
include the maintainer.


signature.asc
Description: Digital signature

Bug#721737: nis: segfault in yppasswd when using shadow

[Mark Brown]

severity 721737 normal
kthxbye

On Tue, Dec 09, 2014 at 02:18:52PM +0100, Goswin von Brederlow wrote:
 Not being able to change the password is a security problem. Raising severity
 to grave.

Please don't inflate severities pointlessly; there are simple solutions
to this like changing passwords by logging into a specific system to do
so which people will doubtless have adopted in the decade or so this has
been present if they are affected.


signature.asc
Description: Digital signature

Bug#768669: xemacs21-packages: FTBFS in jessie: build hangs

[Mark Brown]

tag 768669 + unreproducible moreinfo
thanks

On Sun, Nov 09, 2014 at 08:17:54AM +0100, Lucas Nussbaum wrote:

 During a rebuild of all packages in jessie (in a jessie chroot, not a
 sid chroot), your package failed to build on amd64.
 
 Relevant part (hopefully):
# bind (error-data)
normal-top-level()
# (condition-case ... . error)
  make[2]: *** wait: No child processes.  Stop.

I can't reproduce this on amd64 with pbuilder; can you provide more
information on the build setup here, for example the image you used in
EC2?  It looks awfully like something might've been deleted underneath
the build process...


signature.asc
Description: Digital signature

Bug#763566: horst build depends on sparse which is in non-free

[Mark Brown]

retitle 763566 horst: Build dep on sparse which has not yet moved from non-free
block 763566 524319 
kthxbye

Horst has a build dependency on sparse which is currently in non-free so
creating a RC bug in horst until it is moved to contrib.  However sparse
has been relicensed under a MIT license so could be moved to main
meaning that a better fix for the bug in horst would be to move sparse
into main.


signature.asc
Description: Digital signature

Bug#765685: linux-image-3.16-2-amd64: Kernel lockups with r8723au

[Mark Brown]

Package: src:linux
Version: 3.16.3-2
Severity: serious

The staging driver r8723au is enabled in the kernel but there appear to
be very good reasons why it's in staging - when it loads it routinely
locks up my system (hard with no output unfortunately).  It seems to
make sense to disable the driver.

-- Package-specific info:
** Version:
Linux version 3.16-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 
(Debian 4.8.3-11) ) #1 SMP Debian 3.16.3-2 (2014-09-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16-2-amd64 
root=UUID=1c8b372e-5478-46fe-84d9-efc496b4a0ce ro init=/bin/systemd quiet

** Tainted: WC (1536)
 * Taint on warning.
 * Module from drivers/staging has been loaded.

** Kernel log:
[  557.489458] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  557.489463] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  557.494527] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  557.494530] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  558.501325] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  558.501338] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  558.506380] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  558.506383] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  559.515171] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  559.515183] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  559.520204] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  559.520206] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  560.527936] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  560.527939] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  560.532991] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  560.532994] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  561.543521] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  561.543525] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  561.548556] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  561.548560] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  562.557183] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  562.557188] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  562.562215] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  562.562220] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  563.571309] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  563.571314] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  563.576374] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  563.576377] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  564.585412] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  564.585424] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  564.590447] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  564.590450] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  565.599700] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  565.599703] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  565.604736] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  565.604740] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  566.613028] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  566.613033] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  566.618109] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  566.618116] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  567.627585] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  567.627588] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  567.632636] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  567.632640] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  568.640977] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe 
on isa0060/serio0).
[  568.640981] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  568.646030] atkbd serio0: Unknown key released (translated set 2, code 0xbe 
on isa0060/serio0).
[  568.646034] atkbd serio0: Use 'setkeycodes e03e keycode' to make it known.
[  569.656338] atkbd 

Bug#761320: kicad: depends on zlib-bin, which has been dropped from zlib-bin

[Mark Brown]

On Fri, Sep 12, 2014 at 10:13:34PM +0200, Cyril Brulebois wrote:

 I'm filing this as a serious bug to make sure it's tracked, either by
 kicad maintainers or by zlib maintainers (in x-debbugs-cc). Looking at
 kicad's BTS page, it looks like there might have been some lack of
 coordination, but hopefully that's easily resolved now that involved
 parties are aware of the issue.

Yes, there was a lack of coordination - the split out minizip package
was uploaded before telling anyone.  I have to confess that I'd assumed
that the minizip maintainers had notified everyone rather than just me.


signature.asc
Description: Digital signature

Bug#747719: FTBFS: configure: error: The pkg-config script could not be found or is too old

[Mark Brown]

reassign 747719 mkvtoolnix
found 747719 6.9.1-1
severity 747719 serious
kthxbye

On Sun, May 11, 2014 at 03:46:08PM +0200, Christian Marillat wrote:
 Christian Hofstaedtler z...@debian.org writes:

  Control: affects 747719 mkvtoolnix

  severity 747719 normal

  I must disagree with this severity change; mkvtoolnix does FTBFS,
  which is certainly severiy serious.

  Also it appears the `configure` script shipped in the mkvtoolnix
  source is the one calling and expecting `pkg-config`, so I'm not
  sure if reassigning to zlib is the correct thing to do here.
  (There are probably other means of finding zlib other than
  pkg-config.)

 No the only way to find zlib is to call pkg-config.

This is just not the case, while zlib does provide a .pc file for
pkg-config it is entirely up to whatever is trying to build against zlib
how it discovers zlib.  If it chooses to use pkg-config it can, but
other methods such as just assuming that zlib is available in the
standard system paths (as it is on most systems) work just as well.

As far as I can tell from the backtrace of this in the BTS this has been
reassigned to zlib in the mistaken belief that zlib must depend on
pkg-config, assuming that this is the issue I'm moving the bug back to
the mkvtoolnix since pkg-config is entirely optional for users of zlib.
Please when reassigning bugs include a direct explanation of why the
reassignment has been done.

 Anyway I'm doing a new mkvtoolnix package who add pkg-config
 in Build-Depends.

This bug should be closed by whatever version included that change.


signature.asc
Description: Digital signature

Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}

[Mark Brown]

On Tue, Apr 08, 2014 at 01:41:38AM +0200, John Paul Adrian Glaubitz wrote:
 This bug is still present in the current version of xemacs21 in the
 archives, therefore re-opening.

You've reopened several bugs, have you verified all of them are actually
present?


signature.asc
Description: Digital signature

Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}

[Mark Brown]

On Tue, Apr 08, 2014 at 02:10:30PM +0200, John Paul Adrian Glaubitz wrote:

 In particular, xemacs21 still hasn't properly made the libpng
 transition, the piuparts bug which showed xemacs21-nomule removing
 files which belong to xemacs21-support is still present and several
 other issues in the control file have to be fixed.

Could you be more specific as to what you believe the issues in the
control file are?  Is it just the hard coded architectures thing, that's
the only reported issue and there's nothing terribly obvious to
inspection?  

I guess you might be thinking of stuff like the patch system which is
definitely annoying but isn't really a control file thing?

 Please, for the sake of Debian's quality, re-open all bugs which
 have not been fixed or have the package removed from testing.

There doesn't seem to be any particularly useful way of discovering what
they might be, and I rather suspect that 90% of them are just never
going to be looked at usefully anyway - there's no point in having so
many old things nobody cares about floating around and obscuring the
listings, it's a similar problem to things like KDE.

 xemacs21 should not be released under these circumstances.

That seems like a substantial overreaction, we only have the one RC
issue that I wasn't able to find in the closed bugs for some reason
(which TBH looks to have been present for something like a decade
without anyone caring outside of explicit testing).  


signature.asc
Description: Digital signature

Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}

[Mark Brown]

On Tue, Apr 08, 2014 at 01:57:50PM +0100, Mark Brown wrote:

 I guess you might be thinking of stuff like the patch system which is
 definitely annoying but isn't really a control file thing?

Oh, actually I did fix the patch system but left the build dep hanging.
Ho hum.


signature.asc
Description: Digital signature

Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}

[Mark Brown]

On Tue, Apr 08, 2014 at 03:25:30PM +0200, John Paul Adrian Glaubitz wrote:
 On 04/08/2014 02:57 PM, Mark Brown wrote:

  Could you be more specific as to what you believe the issues in the
  control file are?  Is it just the hard coded architectures thing, that's
  the only reported issue and there's nothing terribly obvious to
  inspection?  

 xmeacs21 is still missing the libpng transition which is something very
 important you should have done with the first upload.

Frankly I just didn't see the bug because it was buried in a list of
other closed non-RC bugs; the first priority with the initial upload was
to close all the RC issues (the symlink one was obviously missed, that
was a mistake).  I've now uploaded a fix for that and a few other
things.

 Further things I can find:

 - standards version is still 3.8.4

Right, but I'm not sure there's any actual changes to go with that -
I've not been through the list.  It's useful to do the check every once
in a while but it's hardly critical stuff, the overwhelming majority of
standards version updates are noops.

 - package still uses dpatch

It doesn't actually use it, that was fixed in the initial upload - I
just forgot to remove the build dep when I moved over.  Now gone.

 - debhelper version is 5

That's not a control file issue really; that will go away when the
package stops autogenerating files during the build (or at least does so
in a more controlled fashion).

 - missing Vcs-* fields

There's nothing to put in them - the package isn't in version control
yet.  I've been experimenting with what to use, dgit looks interesting
there, and the autogeneration is annoying.

 - missing homepage fields

Yeah, should do that.  This is the only one with a user visible impact.

  There doesn't seem to be any particularly useful way of discovering what
  they might be, and I rather suspect that 90% of them are just never
  going to be looked at usefully anyway - there's no point in having so
  many old things nobody cares about floating around and obscuring the
  listings, it's a similar problem to things like KDE.

 There are at least two bugs which result in xemacs21 crashing or
 freezing [2] [3]. Do you really want people to continue using
 xemacs21 knowing that these issues exist?

I think most users don't care; they're definite bugs but they're on the
edges of the functionality not in the mainstream.  Yes, they should be
fixed but saying that people need to stop using the program when they
don't use that functionality isn't constructive.

  xemacs21 should not be released under these circumstances.

  That seems like a substantial overreaction, we only have the one RC
  issue that I wasn't able to find in the closed bugs for some reason

 I am having trouble believing that. It took me around half an hour to
 dig up all these bugs. xemacs21 was accepted by the FTP team under
 the premise that you would take proper care of the package and
 addressing those issues, yet the vast majority of them are still
 present.

My goal here is to keep the packaging reasonably modern and avoid
disrupting anything else so people can continue to use the program and
it doesn't get in the way; unfortunately there's quite a bit of cruft to
unpick which isn't helping make progress as fast as I'd like.  Fixing
Bill's circular dependency thing will help a lot, aside from the symlink
issue it's probably the most urgent thing (and AFAICT the circularity is
half the reason the symlink bug exists).

The libpng transition and the symlink removal definitely need to be
fixed urgently, no question about that - I just hadn't been aware of
either issue.  Like I say libpng is already done.

  (which TBH looks to have been present for something like a decade
  without anyone caring outside of explicit testing).  

 Just because a bug has been there for a long time doesn't mean it
 shouldn't be fixed.

Sure, of course - but it does impact the urgency.

 We have high quality standards in Debian and I am working very hard to
 keep these standards up. Packages like xemacs21 which slip through
 the testing make us look bad. These issues are there and the bugs should
 therefore still be open and the high severity should prevent xemacs21
 from entering testing.

The only bug that's RC is the one with the symlink cleanup and like I
say I agree that is RC.  For the rest of it my call would be that while
they should be fixed having the program available is useful enough to
keep it around.  I'm not saying they're irrelevant, I'm just saying
let's keep things in proportion.


signature.asc
Description: Digital signature

Bug#720652: tua: fails to upgrade from wheezy: needs to add empty prerm script

[Mark Brown]

On Sat, Aug 24, 2013 at 12:40:54PM +0200, Andreas Beckmann wrote:

 To fix this, you need to add a dummy empty prerm script like this:

   #/bin/sh
   set -e
   # dummy empty prerm to ensure clean upgrades from wheezy, see #xx
   # this file can be reoved after jessie was released
   #DEBHELPER#

Why is the best fix here not for debhelper to do this for us?  I'll
upload this soon but it seems updating debhelper and doing binNMUs for
affected packages?


signature.asc
Description: Digital signature

Bug#681747: pulseaudio: Fails to upgrade

[Mark Brown]

Package: pulseaudio
Version: 1.1-3.2
Severity: serious

Attempting to upgrade PulseAudio I get:

(Reading database ... 323691 files and directories currently installed.)
Preparing to replace pulseaudio 1.1-3.2 (using .../pulseaudio_2.0-3_amd64.deb) 
...
/etc/init.d/pulseaudio: 23: .: Can't open /lib/lsb/init-functions
invoke-rc.d: initscript pulseaudio, action stop failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 2
dpkg: trying script from the new package instead ...
/etc/init.d/pulseaudio: 23: .: Can't open /lib/lsb/init-functions invoke-rc.d: 
initscript pulseaudio, action stop failed.
dpkg: error processing
 /var/cache/apt/archives/pulseaudio_2.0-3_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 2
/etc/init.d/pulseaudio: 23: .: Can't open /lib/lsb/init-functions
invoke-rc.d: initscript pulseaudio, action start failed.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit
status 2
Errors were encountered while processing:
 /var/cache/apt/archives/pulseaudio_2.0-3_amd64.deb
Error: GDBus.Error:org.freedesktop.DBus.Error.Spawn.PermissionsInvalid:
The permission of the setuid helper is not correct


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

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

Versions of packages pulseaudio depends on:
ii  adduser 3.113+nmu3
ii  consolekit  0.4.5-3
iu  libasound2  1.0.25-3
iu  libasound2-plugins  1.0.25-2
ii  libc6   2.13-34
iu  libcap2 1:2.22-1.1
iu  libdbus-1-3 1.6.2-2
iu  libfftw3-3  3.3.2-3
ii  libice6 2:1.0.8-2
iu  libltdl72.4.2-1.1
ii  liborc-0.4-01:0.4.16-2
iu  libpulse0   2.0-3
iu  libsamplerate0  0.1.8-5
ii  libsm6  2:1.2.1-2
iu  libsndfile1 1.0.25-5
iu  libspeexdsp11.2~rc1-6
iu  libtdb1 1.2.10-2
ii  libudev0175-3.1
iu  libx11-62:1.5.0-1
iu  libx11-xcb1 2:1.5.0-1
ii  libxcb1 1.8.1-1
ii  libxtst62:1.2.1-1
ii  lsb-base4.1+Debian7
ii  udev175-3.1

Versions of packages pulseaudio recommends:
iu  gstreamer0.10-pulseaudio  0.10.31-3
iu  pulseaudio-esound-compat  2.0-3
iu  pulseaudio-module-x11 2.0-3
ii  rtkit 0.10-2

Versions of packages pulseaudio suggests:
pn  paman none
pn  paprefs   none
pn  pavucontrol   none
pn  pavumeter none
iu  pulseaudio-utils  2.0-3

-- 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#681747: pulseaudio: Fails to upgrade

[Mark Brown]

reassign 681747 systemd
kthxbye

On Mon, Jul 16, 2012 at 08:02:51AM +0100, Mark Brown wrote:

 Attempting to upgrade PulseAudio I get:
 
 (Reading database ... 323691 files and directories currently installed.)
 Preparing to replace pulseaudio 1.1-3.2 (using 
 .../pulseaudio_2.0-3_amd64.deb) ...
 /etc/init.d/pulseaudio: 23: .: Can't open /lib/lsb/init-functions
 invoke-rc.d: initscript pulseaudio, action stop failed.

which on further investigation appeared to be due to a diversion
installed by systemd which moved init-functions without providing a
replacement.  I guess this is an error caused during some upgrade which
didn't clean up properly.


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

Bug#642403: Looks like a combination of multiarch and GCC 4.7

[Mark Brown]

I think if it's just a case of adding extra include paths that ought to
be trivial to fix...  generally all these issues have been pretty basic
and easy to update for.

(notice how the total lack of context makes it harder to understand the
mail?)



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

Bug#678511: zlib: FTBFS on s390x

[Mark Brown]

reassign 678511 libc6-dev
kthxbye

On Fri, Jun 22, 2012 at 12:12:25PM +0100, Jonathan McCrohan wrote:

 Your package FTBFS on s390x. s390x is now a release architecture [1], hence 
 the
 RC status.

Please make *some* effort to read the buildd logs when reporting bugs
like this.

If you'd looked at the error (which it would have been good practice to
include in your report) you'd have seen that all zlib is doing here is
including limits.h which obviously should work but doesn't because s390x
is trying to include an internal header which it didn't install.
There's a good reason why the buildds don't file FTBFS bugs
automatically.



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

Bug#662658: Reply

[Mark Brown]

On Thu, Mar 08, 2012 at 12:22:39AM +0100, Robert Millan wrote:
 El 7 de mar?? de 2012 21:40, Mark Brown broo...@debian.org ha escrit:
  Where is that?

 http://www.freshports.org/sysutils/x86info/

Is there anywhere one can actually download the source of the package,
perhaps even somewhere which identifies the fix?  All I can see for
source is a particularly illegible cvsweb installation.



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

Bug#662658: Reply

[Mark Brown]

Where is that?



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

Bug#662658: x86info: FTBFS(kfreebsd): fatal error: asm/mtrr.h: No such file or directory

[Mark Brown]

On Mon, Mar 05, 2012 at 03:51:01PM +0100, Christoph Egger wrote:

 gcc -g -O2 -Werror -Wall -Wshadow -Wextra -Wmissing-declarations 
 -Wdeclaration-after-statement -Wredundant-decls   -c -o mtrr.o mtrr.c
 mtrr.c:11:22: fatal error: asm/mtrr.h: No such file or directory
 compilation terminated.
 make[1]: *** [mtrr.o] Error 1
 make[1]: Leaving directory 
 `/build/buildd-x86info_1.30-1-kfreebsd-amd64-fQtF1K/x86info-1.30'
 make: *** [build-stamp] Error 2

This is *really* FreeBSD specific, have you looked into how FreeBSD
provides this functionality now?



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

Bug#662658: x86info: FTBFS(kfreebsd): fatal error: asm/mtrr.h: No such file or directory

[Mark Brown]

tag 662658 - wheezy
tag 662658 + help
kthxbye



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

Bug#662658: x86info: FTBFS(kfreebsd): fatal error: asm/mtrr.h: No such file or directory

[Mark Brown]

On Mon, Mar 05, 2012 at 05:33:59PM +0100, Christoph Egger wrote:
 Mark Brown broo...@debian.org writes:

  On Mon, Mar 05, 2012 at 03:51:01PM +0100, Christoph Egger wrote:
 
  gcc -g -O2 -Werror -Wall -Wshadow -Wextra -Wmissing-declarations 
  -Wdeclaration-after-statement -Wredundant-decls   -c -o mtrr.o mtrr.c
  mtrr.c:11:22: fatal error: asm/mtrr.h: No such file or directory

  This is *really* FreeBSD specific, have you looked into how FreeBSD
  provides this functionality now?

   As I definitely don't have the time to care for all kfreebsd-specific
 build failures on my on (I get all of the failures due to being buildd
 admin) I'd be happy if you can keep your questions on debian-bsd@ and
 not relying on me personally.

You in this context is the porters - for an obviously platform
specific thing like this I'd assumed you'd included them in the
discussion somehow (eg, by having the list automatically pick up the
usertag).



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

Bug#659681: Bug#659680: texlive-xetex: xelatex error: ``(Fatal format file error; I'm stymied)

[Mark Brown]

On Mon, Feb 13, 2012 at 01:09:27PM +0900, Norbert Preining wrote:

 Assigning to zlib, maintainers of zlib, what is your plan here?
 Should we patch xetex (and probably many other packages have to be
 fixed, too), or do you intend to fix this misbehaviour?

I've no intention to diverge from upstream on this, maintaining a
different interface to upstream doesn't seem like a smart move.  Given
that the TeX upstream appears to have already changed their code for the
new zlib upstream it seems like they're not expecting any change in zlib
and will be updated to use the new interface with their next release.

I can add a Breaks to the package to help handle partial upgrade cases.

A brief look at what's installed on my particular system suggests that
this isn't a terribly widely used function, I'm actually only seeing
users from TeX but that's not exactly a full archive scan.



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

Bug#659681: Bug#659680: texlive-xetex: xelatex error: ``(Fatal format file error; I'm stymied)

[Mark Brown]

On Tue, Feb 14, 2012 at 08:00:39AM +0900, Norbert Preining wrote:
 On Mo, 13 Feb 2012, Mark Brown wrote:

  that the TeX upstream appears to have already changed their code for the
  new zlib upstream it seems like they're not expecting any change in zlib
  and will be updated to use the new interface with their next release.

 Yes, but you missed the point, namely breaking unrelated software.
 Anyway, I will upload new texlive-binaries with just this fix.

No, I totally understand that point - I'm just saying that in this case
it seems like the way to deal with the issue is to stick with the two
upstreams rather than try to come up with a different fix locally.

  I can add a Breaks to the package to help handle partial upgrade cases.

 I just checked, it seems to *NOT* be necessary. During upgrades 
 xetex will be called only in -ini mode, and that still works.
 Only a normal run to process a document, which loads the format,
 will not work.

I was thinking for the case where someone upgrades zlib but for whatever
reason doesn't upgrade TeX at all - it's not exactly going to be common
but it's simple enough to do.

  A brief look at what's installed on my particular system suggests that
  this isn't a terribly widely used function, I'm actually only seeing
  users from TeX but that's not exactly a full archive scan.

 Huuu, I would expect that a function like *eof() will be used in more
 than xetex place... but anyway.

Most of the gzio users are pretty noddy, the pattern is more usually to
just read until error or something similar rather than having detailed
error checking.



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

Bug#659681: Bug#659680: texlive-xetex: xelatex error: ``(Fatal format file error; I'm stymied)

[Mark Brown]

On Tue, Feb 14, 2012 at 08:49:29AM +0900, Norbert Preining wrote:
 On Mo, 13 Feb 2012, Mark Brown wrote:

  I was thinking for the case where someone upgrades zlib but for whatever
  reason doesn't upgrade TeX at all - it's not exactly going to be common
  but it's simple enough to do.

 Ok, yeah, I agree, that might be necessary. I am preparing texlive-binaries
 -12 revision just now, this version should be fine, so before -12
 it should break.

Great, I'll do an upload for that once I'm back in the UK next week -
currently I'm travelling without access to my key (unless the keyring
maintainers push the update to switch over to my new key which has a on
a GnuPG stick before then in which case I'll do it sooner).



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

Bug#650174: pcscd: Fails to configure

[Mark Brown]

Package: pcscd
Version: 1.8.1-1
Severity: serious

Attempting to configure pcscd fails for me with no useful diagnostic
output being produced:

| Setting up pcscd (1.8.1-1) ...
| dpkg: error processing pcscd (--configure):
|  subprocess installed post-installation script returned error exit status 1
| configured to not write apport reports

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

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

Versions of packages pcscd depends on:
ii  adduser 3.113  
ii  libc6   2.13-21
ii  libccid [pcsc-ifd-handler]  1.4.5-1
ii  libpcsclite11.8.1-1
ii  libudev0175-2  
ii  lsb-base3.2-28 

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  37-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#650174: pcscd: Fails to configure

[Mark Brown]

On Sun, Nov 27, 2011 at 08:21:04PM +0100, Ludovic Rousseau wrote:

 What is the output of:
 $ apt-cache policy systemd

 and of:
 $ systemctl status pcscd.socket

I'm not actually running systemd now, I just happen to have it
installed.

$ apt-cache policy systemd
systemd:
  Installed: 37-1
  Candidate: 37-1
  Version table:
 *** 37-1 0
500 ftp://ftp.uk.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status

$ systemctl status pcscd.socket
Failed to get D-Bus connection: No connection to service manager.




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

Bug#642403: tendra ftbfs on i386

[Mark Brown]

On Thu, Sep 22, 2011 at 10:56:54AM +0200, Matthias Klose wrote:

 /home/packages/tmp/u/tendra-4.1.2/src/lib/libtdf/abstract.pl
 tld: Error: cannot open library file 'target_tok': No such file or directory
 tld: Error: cannot open library file 'ansi': No such file or directory
 make[1]: *** [INT64.o] Error 1
 make[1]: Leaving directory
 `/home/packages/tmp/u/tendra-4.1.2/work/linux/2.6.38-8-server/80x86/tdf'
 compilation failed ...

Please provide a build log; you should always do this with such reports.



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

Bug#608179: tendra: FTBFS: mv: cannot stat `debian/tendra/usr/share/man/man1/tcc.1': No such file or directory

[Mark Brown]

On Sun, Jan 09, 2011 at 07:00:31PM +, Simon McVittie wrote:

 Hopefully the patch below is better? It's also available from
 http://git.debian.org/?p=users/smcv/qa/tendra.git which also has some
 minor lintian fixes as separate commits.

Yes, that's a lot less hideous.  I've actually got an equivalent fix
sitting locally, I'm just waiting for my i386 chroot to gurn through
stuff (actually I'm going to have dinner and hopefully it'll be done
before I get back but hey).

 (I can't help wondering how useful this compiler remains without support for
 non-i386 architectures, though; perhaps it's time to consider removing it
 from testing?)

It's useful as a lint tool even without the backends; one of these days
I may actually get around to getting it to build without the compiler
bit.



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

Bug#608179: tendra: FTBFS: mv: cannot stat `debian/tendra/usr/share/man/man1/tcc.1': No such file or directory

[Mark Brown]

On Sun, Jan 09, 2011 at 07:00:31PM +, Simon McVittie wrote:

 Hopefully the patch below is better? It's also available from
 http://git.debian.org/?p=users/smcv/qa/tendra.git which also has some
 minor lintian fixes as separate commits.

BTW, some things regarding the git tree:

- You need to say which branch to look at; things like git pull need
  this.
- Please always share changes via e-mail as well as git; this allows for
  code review.
- Please don't mix release critical bug fixes in with random other
  changes.

Thanks,
Mark



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

Bug#608179: tendra: FTBFS: mv: cannot stat `debian/tendra/usr/share/man/man1/tcc.1': No such file or directory

[Mark Brown]

On Mon, Jan 03, 2011 at 09:48:38PM +0100, Jakub Wilk wrote:

 Or, better, stop using dh_installmanpages. It's been deprecated for over  
 6 years for very good reasons.

It wasn't visibly deprecated immediately, I think the warnings have only
been on for this release or something.

 See the attached patch.

Err...

 - dh_installmanpages -a
 + dh_installman -a $(shell find -type f -name '*.[0-9]')

...if you're going to do the conversion why not do it properly?



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

Bug#608179: tendra: FTBFS: mv: cannot stat `debian/tendra/usr/share/man/man1/tcc.1': No such file or directory

[Mark Brown]

clone 608179
reassign -1 file
retitle -1 file: Fails to identify some man pages correctly
block 608179 -1
kthxbye

Clearly this used to work in the past. Putting the block in place so the bugs 
are linked, but clearly we can bodge around this. If we're going to bodge, 
though, it's probably more useful to look at the man page and figure out how to 
tune it to make file happy as that's likely to involve figuring out the 
ultimate bug with file.

In any case, I'll look at this tomorrow.

On 31 Dec 2010, at 17:36, Cyril Brulebois wrote:

 tag 608179 patch
 thanks
 
 Mark Brown broo...@debian.org (28/12/2010):
 Thanks.  This looks like debhelper messed up and hasn't copied the man
 page for the compiler in.
 
 It looks like that's due to dh_installmanpages's relying on “file -z”
 to check it's indeed a manpage, which seems to fail here for that
 file:
 | nob...@kitty:~/tendra-4.1.2$ file -z src/tools/tcc/tcc.1
 | src/tools/tcc/tcc.1: FORTRAN program
 
 The attached patch seems to work around this issue, tagging
 accordingly.
 
 KiBi.
 tendra+608179.diff




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

Bug#608179: tendra: FTBFS: mv: cannot stat `debian/tendra/usr/share/man/man1/tcc.1': No such file or directory

[Mark Brown]

On Tue, Dec 28, 2010 at 12:31:53PM +0100, Jakub Wilk wrote:

 tendra fails to build from source in a clean sid i386 chroot. Tail of  
 the build log:

It would be helpful to provide the full build log; in general when
reporting build issues you should always link to the full build log in
the report.



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

Bug#608179: tendra: FTBFS: mv: cannot stat `debian/tendra/usr/share/man/man1/tcc.1': No such file or directory

[Mark Brown]

On Tue, Dec 28, 2010 at 04:59:17PM +0100, Jakub Wilk wrote:
 * Mark Brown broo...@debian.org, 2010-12-28, 15:25:

 It would be helpful to provide the full build log

 Attached.

Thanks.  This looks like debhelper messed up and hasn't copied the man
page for the compiler in.



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

Bug#589896: [Pkg-alsa-devel] Bug#589896: openarena: segfaults when using pulse-via-ALSA output and PulseAudio capture

[Mark Brown]

On Fri, Aug 20, 2010 at 11:56:02PM +0200, Elimar Riesebieter wrote:
 forwarded 589896 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2124
 forwarded 589896 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4426
 thanks

  Thoughts from the ALSA/VoIP teams?

 There are already bugs in thet ALSA-BTS. So what do you expect?
 Another forward? I've tested openarena on my ppc-box and can't
 reproduce.

The ALSA BTS is essentially totally abandoned, to forward ALSA stuff
upstream you really need to post to alsa-devel.



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

Bug#589896: [Pkg-alsa-devel] Bug#589896: Bug#589896: openarena: segfaults when using pulse-via-ALSA output and PulseAudio capture

[Mark Brown]

On Sat, Aug 21, 2010 at 09:11:44PM +0100, Simon McVittie wrote:
 forwarded 589896 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2124
 tags 589896 + patch
 thanks

 On Sat, 21 Aug 2010 at 19:07:03 +0100, Simon McVittie wrote:
  I suggested removing the call to snd_dlobj_cache_cleanup(); I've now tested
  this and confirmed that it works, see attached (trivial) patch.

 Now forwarded to https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2124,
 please add Forwarded: yes if you use the patch as-is :-)

Didn't see you'd been dropped from previous mails so repeating:

The ALSA BTS is essentially abandoned upstream, you need to contact the
developers via e-mail (alsa-de...@alsa-project.org) to bring things to
their attention.



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

Bug#575089: gnash: Crippling memory leak

[Mark Brown]

On 17 Aug 2010, at 20:40, Petter Reinholdtsen wrote:

 I've talked with upstream on #gnash (irc.freenode.net), and they had a
 look at URL: http://www.last.fm/user/broonie  to try to reproduce
 this.  There is no media player on this page when upstream and me test
 it.  Do one need to log in to be able to see the memory leak problem
 you are seeing?  Do you have a test page exposing this memory leak
 that do not require to log in?  Do you have other test pages for
 upstream to use?

You may need to be logged in. Presumably any last.fm user account will have a 
player, though in the considerable time between me reporting this bug and now 
it appears that last.fm have changed their player so perhaps other web pages 
will need to be checked out. The last.fm player was far from unique when I last 
tried installing gnash.


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

Bug#575089: gnash: Crippling memory leak

[Mark Brown]

On 17 Aug 2010, at 20:48, Petter Reinholdtsen wrote:

 [Mark Brown]
 You may need to be logged in. Presumably any last.fm user account
 will have a player, though in the considerable time between me
 reporting this bug and now it appears that last.fm have changed
 their player so perhaps other web pages will need to be checked
 out. The last.fm player was far from unique when I last tried
 installing gnash.
 
 Right.  I do not have a last.fm account (do not like their user
 agreement), so I can't test that.
 
 Are you able to reproduce the problem now with any site?

I would need to go and install gnash on a system where I'm happy to restart my 
web browsers which may take a little while. If I remember correctly the ads on 
The Register were pretty good at triggering this stuff also.


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

Bug#589821: Kills systems ypbind when installing in chroot

[Mark Brown]

severity 589821 important
kthxbye

On Wed, Jul 21, 2010 at 02:07:45PM +0200, Goswin von Brederlow wrote:
 Package: nis
 Version: 3.17-17
 Severity: critical

Please be realistic in the severity of your reports; this is a fairly
obscure use case (it's been present for something in the region of ten
years now...) for advanced users which is most likely going to fail
anyway due to the two competing ypbinds trying to run simultaneously.

This is in no way serious enough to justify blocking the release of the
package.

 I beliefe the problem is the following in postinst:

   # And start the service.
   if [ $2 !=  -a $2 !=  ]  dpkg --compare-versions $2 le 3.9-1
   then
   killall ypbind /dev/null 21 || true
   fi

 which kills not just the ypbind in the chroot (of which there is none)
 but also any other ypbind including the systems one.

Yes, that's going to be the case.



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

Bug#575089: gnash: Crippling memory leak

[Mark Brown]

Package: gnash
Version: 0.8.7-2
Severity: critical

With current versions of gnash there appears to be a very severe memory
leak when running with at least some sites (I believe including the
media player on last.fm user pages such as http://www.last.fm/user/broonie
which appears to leak at approximately 10M/second).

Severity set to critical since this rapidly results in the system
becoming almost totally unresponsive to interactive use due to heavy
swap usage.  Given that I'm not browsing obscure web sites when this
happens I strongly expect this is a bug in gnash rather than in the
flash applications being run, or at least a lack of compatibility with
Adobe flash player.

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

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

Versions of packages gnash depends on:
ii  gnash-common  0.8.7-2free Shockwave Flash (SWF) movie p
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  libgcc1   1:4.4.3-3  GCC support library
ii  libglib2.0-0  2.22.4-1   The GLib library of C routines
ii  libgstreamer0.10-00.10.28-1  Core GStreamer libraries and eleme
ii  libgtk2.0-0   2.18.7-1   The GTK+ graphical user interface 
ii  libstdc++64.4.3-3The GNU Standard C++ Library v3

gnash recommends no packages.

gnash 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

Bug#568518: Aix 5.3 nis-client crashs ypserv[2358]: segfault

[Mark Brown]

severity 568518 important
kthxbye

On Fri, Feb 05, 2010 at 01:51:18PM +0100, 
thomas.lefringhau...@witte-automotive.de wrote:
 Severity: grave
 Justification: renders package unusable

Please file bugs with realistic severities, inflating the severity is
unhelpful.  In this case the problem only affects people trying to
interoperate with AIX, which leaves a rather large set of users
unaffected.

 We are using Debian as a NIS-Server since 3 years,
 with up to 100 clients on serveral locations.
 With Etch we had no problems all the years.

 Now we have upgraded the system to Lenny and the problem is as follow:

Please try with the current package from unstable to see if this issue
has been fixed subsequently.

 To bring the yp-server in normal operation, you now must shutdown all 
 IBM-workstations, start the yp-server and after
 that you can start the IBM's again and hope that you have no network 
 problems during they start.

Could you please also:
 - capture the network traffic that occurs during startup.
 - start ypserv via gdb and obtain a backtrace (with the 'bt' command)
   when it crashes.



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

Bug#562757: Apparent portmap to rpcbind transition?

[Mark Brown]

On Mon, Jan 04, 2010 at 02:45:27PM +, Mark Brown wrote:
 As discussed by a number of people in bug #562757 it appears that
 nfs-kernel-server has kicked off a transition to the use of rpcbind - at
 least, nfs-kernel-server has switched to needing rpcbind and we can't
 have two things claiming the portmap port.  Since a number of packages
 currently rely on portmap (list based on rdepends below) this is likely
 to require a transition of some kind.

 I've not seen any discussion of how this is supposed to work, or any
 mention of the planned transition before it broke my systems.  There's
 quite a few bugs in ONCRPC related packages related to the current state
 but none of them seem to have a summary of what the intention is - does
 anyone have any information here?

Any updates on this?  Are we switching portmappers, and if we are how
are we doing so?



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

Bug#565823: zlib1g: Breaking ABI? {update-mime-database.real, xsltproc, xmllint} start segfaulting

[Mark Brown]

reassign 565823 libxml2
kthxbye

On 19 Jan 2010, at 00:20, Cyril Brulebois k...@debian.org wrote:


Package: zlib1g
Version: 1:1.2.3.5.dfsg-1
Severity: serious
Justification: ABI break?

Hi,

context: kfreebsd-* experimental buildds were not properly configured
and pulled more stuff from experimental than actually needed. We  
started

to see many FTBFSes (in particular on kfreebsd-amd64) due to:
- update-mime-database.real
- xsltproc
- xmllint
which started to segfault, core dump, etc. One can notice all of them
have a NEEDED on libxml2.so.2, which in turn pulls libz.so.1


This is actually a bug (already filed, I'll merge them later when I  
have a proper network). It is relying on zlib internals which have  
been changed but where never exposed in a header file, much less part  
of the API.



I'm also able to reproduce this error on sid/(linux-)amd64, by just
pulling zlib1g from experimental. Before pulling it, this runs fine:
 sudo update-mime-database.real /usr/share/mime
After having pulled it, this segfaults.

Sounds like a possible ABI breakage? Since symbols look like okay-ish,
maybe a signature change? Upstream's diff is quite huge since build
system changed and so on, so I'll leave that up to you/upstream. ;)

Mraw,
KiBi.







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

Bug#562757: Apparent portmap to rpcbind transition?

[Mark Brown]

As discussed by a number of people in bug #562757 it appears that
nfs-kernel-server has kicked off a transition to the use of rpcbind - at
least, nfs-kernel-server has switched to needing rpcbind and we can't
have two things claiming the portmap port.  Since a number of packages
currently rely on portmap (list based on rdepends below) this is likely
to require a transition of some kind.

I've not seen any discussion of how this is supposed to work, or any
mention of the planned transition before it broke my systems.  There's
quite a few bugs in ONCRPC related packages related to the current state
but none of them seem to have a summary of what the intention is - does
anyone have any information here?

Daniel Baumann dan...@debian.org
   doodle (U)

Mark Brown broo...@debian.org
   nis

Tim Cutts t...@chiark.greenend.org.uk
   am-utils

Debian QA Group packa...@qa.debian.org
   unfs3

Alberto Gonzalez Iniesta a...@inittab.org
   netkit-bootparamd
   netkit-rusers
   netkit-rwall

No??l K??the n...@debian.org
   drac

Chuan-kai Lin ck...@debian.org
   fam

Robert Luberda rob...@debian.org
   rlinetd

Ola Lundqvist o...@debian.org
   harden

Debian GNUnet Maintainers gnu...@lists.debian-maintainers.org
   doodle

Michael Meskes mes...@debian.org
   quota

Anibal Monsalve Salazar ani...@debian.org
   nfs-utils
   rstatd

Miquel van Smoorenburg miqu...@cistron.nl
   nis (U)

Geert Stappers stapp...@debian.org
   p3nfs




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

Bug#562518: zlib1g 1:1.2.3.4.dfsg-1 hangs(?)

[Mark Brown]

On Fri, Dec 25, 2009 at 11:33:05AM +0100, Lucas Nussbaum wrote:

 If, in a clean minimal chroot, I install zlib1g from testing first, then
 install man-db, it works fine.

 My guess is that it is related to the fixing of #301283.

As far as I can tell zlib is performing correctly here, the man-db
process doing the decompression exits correctly having detected EOF and
closed the file, then exits.  The read() that's spinning with zero bytes
is certainly not a zlib one, it reads data in 16384 byte chunks but
that's a read of 65535 bytes (and the man-db debug output says the
process that's spinning is a manconv one.

That said, I can't immediately spot a problem in the man-db code and
reverting the explict reporting of EOF in zlib makes man-db stop falling
over so I'll upload a package just now.



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

Bug#562518: how to reproduce

[Mark Brown]

On Fri, Dec 25, 2009 at 06:41:16PM +0100, Joern Heissler wrote:

 you can reproduce the problem with this little program, more or less copied 
 from man-db source.

That's one of the tests I used (plus using man-db itself).

 Upgrading to zlib_1.2.3.4.dfsg-2 seems *NOT* to fix the problem.

Works for me.  Are you postive you are running against that version of
zlib, and when you say the problem what exactly do you mean?

 I don't know what other files makes problem or if you're allowed to gzopen 
 not compressed files at all.

Yes, you are.  There is also a difference in the handling of EOF for
uncompressed files, but I can't reproduce any effect on man-db or any
problem.



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

Bug#562518: zlib1g 1:1.2.3.4.dfsg-1 hangs(?)

[Mark Brown]

On Fri, Dec 25, 2009 at 03:05:12PM +, Mark Brown wrote:

 As far as I can tell zlib is performing correctly here, the man-db
 process doing the decompression exits correctly having detected EOF and
 closed the file, then exits.  The read() that's spinning with zero bytes
 is certainly not a zlib one, it reads data in 16384 byte chunks but
 that's a read of 65535 bytes (and the man-db debug output says the
 process that's spinning is a manconv one.

 That said, I can't immediately spot a problem in the man-db code and
 reverting the explict reporting of EOF in zlib makes man-db stop falling
 over so I'll upload a package just now.

Having looked further there was a problem with zlib truncating output
which should now be fixed with the change I made, however this shouldn't
explain the spin in man-db so there may still be a latent bug there
that's worth looking into.



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