Bug#845538: FTBFS: missing Build-Depends: python-tornado (>= 4.0)

[Goswin von Brederlow]

Source: pyzmq
Version: 15.4.0-1
Severity: normal

The testsuite for tornado event loops uses ZMQIOLoop.call_later. The
call_later method was added only in tornado 4.0 so it fails with:

self = , delay = 0.1
callback = 

def _call_later(self, delay, callback):
"""Schedule a function to be called later

Override for different IOLoop implementations

Tornado and asyncio happen to both have ioloop.call_later
with the same signature.
"""
>   self.io_loop.call_later(delay, callback)
E   AttributeError: 'ZMQIOLoop' object has no attribute 'call_later'

MfG
Goswin

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#791997: zeromq3: git repository is no longer updated

[Goswin von Brederlow]

Source: zeromq3
Version: 4.0.4+dfsg-1
Followup-For: Bug #791997

Hi,

it's been over a year now that this bug has been open, over 2 years
and 16 uploads since the maintainer change.

How hard is it to fix 2 lines in debian/control?

Note: The bug has been reported twice and not been merged. 

MfG
Goswin

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set 
to C)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#830788: RFS: ifstat/1.1-9

[Goswin von Brederlow]

On Tue, Oct 04, 2016 at 09:56:35AM +, Gianfranco Costamagna wrote:
> Hi,
> 
> 
> >It's using it indirectly for the crypto support. I've added the
> 
> >Build-Depends to make the use more explicit and asked the upstream
> >author to add the linking exception for ssl. He agreed about adding it
> 
> >but I don't know when that will officially happen.
> 
> 
> so, closing this RFS until the NMU is merged and the other points are 
> addressed?
> 
> G.

I would like the bug to be closed by the package being sponsored.

MfG
Goswin

Bug#830788: RFS: ifstat/1.1-9

[Goswin von Brederlow]

On Sat, Sep 24, 2016 at 04:26:32PM +0200, Tobias Frost wrote:
> Hi Goswin,
> 
> Am Montag, den 11.07.2016, 15:44 +0200 schrieb Goswin von Brederlow:
> 
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "ifstat"
> > 
> >  Package name: ifstat
> >  Version : 1.1-9
> >  Upstream Author : Gal Roualland <gael.rouall...@dial.oleane.com>
> >  URL : http://gael.roualland.free.fr/ifstat/
> >  License : GPL
> >  Section : net
> > 
> > It builds those binary packages:
> > 
> > ifstat- InterFace STATistics Monitoring
> > libifstat-dev - Ifstat Development Files
> > 
> > To access further information about this package, please visit the
> > following URL:
> > 
> > https://mentors.debian.net/package/ifstat
> > 
> > 
> > Alternatively, one can download the package with dget using this
> > command:
> > 
> >   dget -x https://mentors.debian.net/debian/pool/main/i/ifstat/ifstat
> > _1.1-9.dsc
> > 
> > More information about hello can be obtained from https://www.example
> > .com.
> > 
> > Changes since the last upload:
> > 
> > ifstat (1.1-9) unstable; urgency=low
> > 
> >   * Update to debhelper version 9 (Closes: #817499, #828348).
> >   * Add multiarch support.
> >   * Fix bandwidth spelling in manpage (Closes: #617336).
> >   * Use dpkg-buildflags for hardening.
> > 
> >  -- Goswin von Brederlow <goswin-...@web.de>  Mon, 11 Jul 2016
> > 12:03:29 +0200
> > 
> > 
> > The changes are purely packaging (except the spelling) related and a
> > straight
> > update from the old rules file to dh. It blocks some transitions so
> > it's
> > mildly important to get uploaded soon.
> > 
> > Regards,
> >  Goswin von Brederlow
> > 
> 
> any news on your package?
> 
> What I also noticed is that you have added a B-D on libssl-dev,
> but I cannot find any reference that the source is actually using it.
> Using Openssl on GPL'ed code without explicit license grant would be
> bad... Can you expand?
> 
> (Note that I did a NMU on the current version in sid to fix only the
> compat level 4 bug)
> 
> -- 
> tobi

It's using it indirectly for the crypto support. I've added the
Build-Depends to make the use more explicit and asked the upstream
author to add the linking exception for ssl. He agreed about adding it
but I don't know when that will officially happen.

MfG
Goswin

Bug#817499: ifstat: diff for NMU version 1.1-8.1

[Goswin von Brederlow]

Hi,

On Sat, Sep 24, 2016 at 04:14:44PM +0200, Tobias Frost wrote:
> Control: tags 817499 + patch
> Control: tags 817499 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for ifstat (versioned as 1.1-8.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.

> diff -u ifstat-1.1/debian/changelog ifstat-1.1/debian/changelog
> --- ifstat-1.1/debian/changelog
> +++ ifstat-1.1/debian/changelog
> @@ -1,3 +1,10 @@
> +ifstat (1.1-8.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Bump d/compat to 9 (Closes: #817499)
> +
> + -- Tobias Frost <t...@debian.org>  Sat, 24 Sep 2016 16:13:19 +0200
> +
>  ifstat (1.1-8) unstable; urgency=low
>  
>* New maintainer address.
> diff -u ifstat-1.1/debian/control ifstat-1.1/debian/control
> --- ifstat-1.1/debian/control
> +++ ifstat-1.1/debian/control
> @@ -2,13 +2,13 @@
>  Section: net
>  Priority: optional
>  Maintainer: Goswin von Brederlow <goswin-...@web.de>
> -Build-Depends: debhelper (>= 4), libsnmp-dev
> +Build-Depends: debhelper (>= 9), libsnmp-dev
>  Standards-Version: 3.7.2.2
>  
>  Package: ifstat
>  Section: net
>  Architecture: any
> -Depends: ${shlibs:Depends}
> +Depends: ${shlibs:Depends}, ${misc:Depends}
>  Description: InterFace STATistics Monitoring
>   ifstat is a tool to report network interfaces bandwidth just like 
>   vmstat/iostat do for other system counters. It can monitor local

Sorry for coming back so late. Why didn't you just sponsor the updated
ifstat package from mentors.debian.net?

https://mentors.debian.net/package/ifstat

Please upload that instead to properly transition ifstat to the new
debhelper and dh. The old debian/rules file will randomly break with
parallel builds, like in #828348. debian/control also is missing a
Build-Depends on libssl-dev.

MfG
Goswin

Bug#836826: FTBFS: cp: cannot stat '/usr/src/gtest/src': No such file or directory

[Goswin von Brederlow]

Source: protobuf
Version: 3.0.0-7
Severity: normal

Hi,

it looks like protobuf is missing a Build-Depends on libgtest-dev:

BUILD SUCCESSFUL
Total time: 0 seconds
mh_clean || true
make[1]: Leaving directory `/source/brederlo/protobuf/protobuf-3.0.0'
   dh_autoreconf_clean -O--parallel
   debian/rules override_dh_clean
make[1]: Entering directory `/source/brederlo/protobuf/protobuf-3.0.0'
rm -f -rv gmock
dh_clean
make[1]: Leaving directory `/source/brederlo/protobuf/protobuf-3.0.0'
 debian/rules build
dh build --with autoreconf,python2 --parallel
   dh_testdir -O--parallel
   debian/rules override_dh_autoreconf
make[1]: Entering directory `/source/brederlo/protobuf/protobuf-3.0.0'
cp -rv debian/gmock ./
'debian/gmock' -> './gmock'
'debian/gmock/gtest' -> './gmock/gtest'
'debian/gmock/gtest/Makefile.am' -> './gmock/gtest/Makefile.am'
'debian/gmock/gtest/configure.ac' -> './gmock/gtest/configure.ac'
'debian/gmock/configure.ac' -> './gmock/configure.ac'
'debian/gmock/Makefile.am' -> './gmock/Makefile.am'
cp -rv /usr/src/gmock/src gmock/
'/usr/src/gmock/src' -> 'gmock/src'
'/usr/src/gmock/src/gmock-internal-utils.cc' -> 
'gmock/src/gmock-internal-utils.cc'
'/usr/src/gmock/src/gmock_main.cc' -> 'gmock/src/gmock_main.cc'
'/usr/src/gmock/src/gmock-spec-builders.cc' -> 
'gmock/src/gmock-spec-builders.cc'
'/usr/src/gmock/src/gmock.cc' -> 'gmock/src/gmock.cc'
'/usr/src/gmock/src/gmock-cardinalities.cc' -> 
'gmock/src/gmock-cardinalities.cc'
'/usr/src/gmock/src/gmock-matchers.cc' -> 'gmock/src/gmock-matchers.cc'
'/usr/src/gmock/src/gmock-all.cc' -> 'gmock/src/gmock-all.cc'
cp -rv /usr/src/gtest/src gmock/gtest/
cp: cannot stat '/usr/src/gtest/src': No such file or directory
make[1]: *** [gmock] Error 1

MfG
Goswin

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#836821: Please support python3

[Goswin von Brederlow]

Source: protobuf
Version: 3.0.0-7
Severity: important

There seems to be only a python-protobuf but no python3-protobuf.
Please add support for python3.

MfG
Goswin

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#830788: RFS: ifstat/1.1-9

[Goswin von Brederlow]

On Sat, Jul 30, 2016 at 07:12:24PM +0200, Laurent Bigonville wrote:
> On Mon, 11 Jul 2016 15:44:39 +0200 Goswin von Brederlow <goswin-...@web.de>
> wrote:
> 
> > Dear mentors,
> >
> 
> Hi,
> 
> > I am looking for a sponsor for my package "ifstat"
> 
> I have a question, is the ifstat package really still needed? It seems to be
> dead upstream (last release is from 2004).
> 
> The iproute2 package (which is still maintained upstream) also has a ifstat
> binary, I've added that binary by mistake in the last upload I've made.
> 
> So I see two solutions here, either I'm removing that binary from the
> iproute2 package (and we are back to the situation before my boggus upload)
> or we are removing the ifstat package from debian. Note iproute2 is linux
> only though.
> 
> Any thoughts about this?
> 
> Regards,
> 
> Laurent Bigonville

How do they compare in functionality?

Ifstat upstream is alife and responsive. The command is just complete,
no new features have been added. So I guess we should keep ifstat, if
only for kfreebsd and hurd.

MfG
Goswin

Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload

[Goswin von Brederlow]

On Mon, Jul 18, 2016 at 07:41:54PM +0200, Andreas Metzler wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: britney
> 
> Hello,
> 
> I have been wondering why hugin 2016.2.0~rc1+dfsg-2 (urgency=low) will
> be considered for testing migration after only 5 days and I think I found
> the reason.
> 
> Testing has 2016.0.0+dfsg-1, which was followed by
> [2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low)
> [2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low)
> [2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium)
> 
> britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium
> urgency and chose to consider this urgency for sid->testing migration.
> 
> I think that is a bug, especially as dch uses medium by default for
> uploads to experimental.
> 
> cu Andreas

Does it remember or does it parse the changelog and use the highest
priority since the version in testing? The hugin changelog contains
the urgency=medium entry so this seems a valid urgency to use.

MfG
Goswin

Bug#830860: depends on base-file being configured

[Goswin von Brederlow]

On Mon, Jul 18, 2016 at 11:01:10AM +0200, Santiago Vila wrote:
> On Mon, 18 Jul 2016, Goswin von Brederlow wrote:
> 
> > Dear cdebootstrap maintainer:
> > 
> > This shouldn't be an issue in sid [...]
> 
> Hmm. We usually want bootstrapping programs like this in stable to be able
> to bootstrap the next stable.
> 
> If version currently in jessie does not work to bootstrap stretch,
> please consider an upload for stable-proposed-updates to be included
> in the next point release. (AFAIK, this was done with debootstrap).
> 
> Thanks.

But that's why fixing this in base-passwd was so great. Old bootstrap
tools just work because they get the fixed package when bootstraping
the next stable.

MfG
Goswin

Bug#830860: depends on base-file being configured

[Goswin von Brederlow]

On Thu, Jul 14, 2016 at 11:30:37AM +0200, Santiago Vila wrote:
> On Thu, 14 Jul 2016, Goswin von Brederlow wrote:
> 
> > Wether it's base-files fault or not we had to agree to disagree. And I
> > don't realy care.
> 
> This is a little bit contradictory.

I don't care because base-passwd has fixed the issue as mentioned. I
don't care if base-passwd or base-files is changed. Both are at the
source of the problem, meaning a single point to fix the issue.

> You keep saying that we have to fix things "at the source", but then
> you say that you don't really care if this is base-files fault or not.
> 
> As a reminder, I will tell you, once again, that base-files follows
> policy when it says that we don't add dependencies on essential
> packages. Therefore if cdebootstrap fails, then it is a bug in
> cdebootstrap. In this case, this is the source of the problem and it's
> where the problem should be fixed.
> 
> The fact that several packages may have similar bugs does not make
> those bugs not to be bugs in those packages.
> 
> Moreover, AFAIK, there are basically two debootstrap programs in Debian,
> debootstrap and cdebootstrap. Not a zillion of them, not even "many"
> of them. Only two.
> 
> Thanks.

Last time this question came up there were 5 of them.


Dear cdebootstrap maintainer:

This shouldn't be an issue in sid since base-passwd now creates passwd
in preinst. So one of two things need to happen:

1) base-passwd is configured before base-files

or

2) base-passwd and base-files are unpacked together so base-passwd
preinst is run before base-files postinst.

Since the second already happens there is nothing to do on your part I
believe.

MfG
Goswin

Bug#830860: depends on base-file being configured

[Goswin von Brederlow]

On Wed, Jul 13, 2016 at 11:03:31AM +0200, Santiago Vila wrote:
> On Tue, 12 Jul 2016, Goswin von Brederlow wrote:
> 
> > And now it occurs in cdebootstrap (again, happened before and went
> > away, now it's back),
> 
> So, if it happens again, why didn't you report it against cdebootstrap
> to begin with? This is the package having the bug, not base-files.
> 
> Please, feel free to reopen this report and reassign to whatever
> package is failing to properly bootstrap the system.
> 
> > and then the next bootstrap tool and again and again.
> 
> Not necessarily. It has been clearly established that base-files uses
> chown with Debian system users. It should be clear by now that base-passwd
> should be configured first by any bootstrapping tool.
> 
> > The sane solution is to fix the problem at the source, not in the
> > various bootstrap tools. Especially when you don't communicate the
> > need for a fix to other tools and only fix one.
> 
> Well, if you discover a bug in cdebootstrap and file a bug against
> base-files, I think it's you who don't communicate the need for a fix.
> 
> I can't be responsible for every bootstrapping tool out there.

But in the bugreport you noticed the problem, figured out its an
ordering problem that every bootstrap program has and then just told
debootstrap about it and nobody else. So yes, you are basically
repsonsible. And that is the problem of not fixing this at the source,
you get many bootstrap programs that need fixing.
 
> For the record, what base-files does is not new at all. If you read
> carefully the bug report I quoted before, you will see that last time
> this broke it was triggered by a subtle change in dpkg ordering.
> 
> Before that, base-passwd and base-files were installed in the same
> dpkg run, and as you rightly point out, this was a matter of luck that
> it worked. But this was never base-files fault.

And that is exactly what happened now. Some other package update
changed the ordering in dpkg here so cdebootstrap failed.

Wether it's base-files fault or not we had to agree to disagree. And I
don't realy care. Base-passwd added a fix to make passwd available
earlier so it is more of a core functionality. That fixed the problem
from the other end.

> > And the bug hits all the right arguments:
> > 
> > - base-passwd does not provide /etc/passwd when unpacked, it therefor
> >   can't be core functionality => base-files should Depends: base-passwd.
> 
> Sorry, I don't buy that line of reasoning. If base-passwd can't be
> essential then it should lose its essential flag, but then every
> package using chown in their postinst should have a Depends: base-passwd,
> not just base-files.
> 
> There may be zillions of packages using chown in their postinst, so this
> is not reasonable at all.

The difference is your package is essential. That makes the difference
during bootstrapping. It's a problem of bootstraping order.

I'm going to suggest a policy change to clarify on what core
functionality means for essential packages normally and for the
special case of essential packages depending on other essential
apckages during bootstrap. Bootstrap is a special case and in the
bugreport you said you wanted a plan to deal with bootstrap ordering.
So I'm going to do that.
 
> > [...]
> > the quick fix of adding "Depends: base-passwd".
> 
> I don't agree with your comparison "fix bootstrap -> difficult",
> "add an artificial dependency to base-files -> easy".
> 
> Configuring base-passwd first then base-files is also very quick. If
> you read the bug I quoted before the patch is usually a one-liner,
> which is also easy enough.
> 
> The only reason this was not a "quick fix" last time is that people
> insisted on killing the messenger (base-files) instead of fixing what
> was really broken (debootstrap).
> 
> Thanks.

And again: fix debootstrap and ALL THE OTHER BOOTSTRAP TOOLS. So a one
liner in a single package turns into many lines in several packages
which most not even knowing that they need fixing.

As this discussion shows cdeboostrap was never fixed. I bet neither
was crossbootstrap or that liveCD bootstrap tool. It's the not knowing
that is the biggest problem.

MfG
Goswin

Bug#830860: depends on base-file being configured

[Goswin von Brederlow]

Package: base-files
Version: 6.5
Severity: normal

The postinst of base-files tries to "chown root:root", which requires
/etc/passwd and /etc/groups to exist. This is not the case during
(c)debootstrap if base-passwd postinst has not yet been executed.

base-files should depend on base-passwd to ensure the postinst files
are executed in the right order. It's pure luck that it works out that
way most of the time.

MfG
Goswin

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.1.3+dfsg-0.1
ii  mawk [awk]  1.3.3-17

base-files recommends no packages.

base-files suggests no packages.

-- Configuration Files:
/etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18 [Errno 2] No such file or 
directory: u'/etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18'

-- no debconf information

Bug#830788: RFS: ifstat/1.1-9

[Goswin von Brederlow]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ifstat"

 Package name: ifstat
 Version : 1.1-9
 Upstream Author : Gal Roualland <gael.rouall...@dial.oleane.com>
 URL : http://gael.roualland.free.fr/ifstat/
 License : GPL
 Section : net

It builds those binary packages:

ifstat- InterFace STATistics Monitoring
libifstat-dev - Ifstat Development Files

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

https://mentors.debian.net/package/ifstat


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

  dget -x https://mentors.debian.net/debian/pool/main/i/ifstat/ifstat_1.1-9.dsc

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

Changes since the last upload:

ifstat (1.1-9) unstable; urgency=low

  * Update to debhelper version 9 (Closes: #817499, #828348).
  * Add multiarch support.
  * Fix bandwidth spelling in manpage (Closes: #617336).
  * Use dpkg-buildflags for hardening.

 -- Goswin von Brederlow <goswin-...@web.de>  Mon, 11 Jul 2016 12:03:29 +0200


The changes are purely packaging (except the spelling) related and a straight
update from the old rules file to dh. It blocks some transitions so it's
mildly important to get uploaded soon.

Regards,
 Goswin von Brederlow

Bug#828348: ifstat: FTBFS with openssl 1.1.0

[Goswin von Brederlow]

Hi,

this has nothing to do with openssl but is caused by building in parallel.
The dependencies in debian/rules are broken in the parallel case.

MfG
Goswin

PS: Feel free to sponsor ifstat from mentors.debian.net

Bug#819724: Please find a second maintainer

[Goswin von Brederlow]

On Tue, Apr 05, 2016 at 11:36:19PM +0200, Tormod Volden wrote:
> severity wishlist
> 
> On Fri, Apr 1, 2016 at 3:29 PM, Goswin von Brederlow  wrote:
> > Package: xscreensaver
> > Severity: important
> >
> > The xscreensaver package has 120 bugs going back over 9 years that are
> > just rotting in the BTS without attention. Some of them are tagged
> > security, some tagged patch. A lot of bugs have not been modified
> > since shortly after they were reported.
> 
> Hi Goswin,
> 
> The BTW can probably need some triaging. I am aware of (hopefully) all
> bugs there though, and there is nothing that really demands attention.
> There are a lot of wishes, patches that should go upstream or down the
> drain - we don't want to carry the support burden for them - and some
> are graphic drivers issues.
> 
> >
> > I sad to say but you are not doing as good a job maintaining the
> > package as you should. Maybe you aren't that interested in
> > xscreensaver anymore or you don't have the time or any number of other
> > valid reasons. But fact is that bugs are being left to rot in the BTS.
> 
> I am maintaining the package as I have been doing over many, many
> years. Security problems are taken care of immediately and upstream
> releases are packaged in due time. The number of bugs have been very
> stable over the years. I don't have any strong motivation to work much
> more intensive on it than I have done, that's for sure.
> 
> Some bugs can sure be closed, but why is that important to you? They
> are there mainly to help the maintainers, and people contributing.
> Granted, I am sure many bugs can be closed though, or moved to
> wishlist. It is just not the highest of my priorities, and nobody else
> has stepped up to do it. Hey wait - one guy mentioned some willingness
> a few weeks ago - maybe we are lucky, I will follow that up.

The BTS is not just for the maintainer. It also documents things for
users. Like what bugs are already known. 

When I see a package with lots of patches in the BTS my willingness to
patch something myself goes right down the drain. Who would want to
spend their time writing patches if the maintainer will just ignore
them for years?

I'm sure you handled all the security stuff as you say but you are the
only one that knows that. Everyone else looks at the BTS and sees bugs
tagged security. When I see a package in the BTS with bugs tagged
security then I start to worry. 
 
> > For example #403557 should have been tagged more-info and eventually
> > closed as unreproducible 9 years ago and is still there tagged
> > security.
> 
> Are you not able to tag it as more-info? If you are unable to help
> because of technical issues, we can probably figure that out. It is
> not like the maintainer has to do everything and nobody else can help.

That would be just a drive-by shooting. You won't get more info just
ebcause someone sets the more-info tag. One also has to track down the
submitter and at least test the issue itself too. Since I don't use
LDAP that would be rather a lot of work. And what for? If I write a
patch it's just going to rot in the BTS form all apearances. See my
point?

> > So I urge you to please find a new maintainer to either take over (in
> > the worst case) or simply work alongside yourself to help clean up the
> > backlog of bugs in this package.
> 
> This is not how it works in practice. Anyone interested in the package
> will help to maintain the package, sending patches against the VCS
> etc. I don't see why nobody can just help out triaging bugs. People
> helping out over time can become co-maintainers. If I don't do much
> useful any longer, I can pull out and the other people will remain
> maintainers. This is how I got into this. If they are not genuinely
> interested (and pop up by themselves) there are small changes they
> will stick around.

Saddly that is also not how it works. Usualy a package rots away for
years getting worse and worse before it finally blows and someone else
gets so fed up with it and steps up to take over. You are doing a too
good job for that to happen. Sometimes you have to get the word out
that help is needed or simply just wanted to attract someone.

> > If it is just that you left bugs open for so long (or inherited them
> > from a revious maintainer) that now you are swamped and can't catch up
> > then you could also contact the front desk to get some prospective new
> > DDs assigned to look over and triage bugs. It's good experience for
> > them and the package would hopefully get back on track.
> 
> Yes, it might be a good idea to get some people working on this. But
> it won't help me to get someone to just close bugs for the sake of
> closing bugs for then to disappear a

Bug#819724: Please find a second maintainer

[Goswin von Brederlow]

Package: xscreensaver
Severity: important

The xscreensaver package has 120 bugs going back over 9 years that are
just rotting in the BTS without attention. Some of them are tagged
security, some tagged patch. A lot of bugs have not been modified
since shortly after they were reported.

I sad to say but you are not doing as good a job maintaining the
package as you should. Maybe you aren't that interested in
xscreensaver anymore or you don't have the time or any number of other
valid reasons. But fact is that bugs are being left to rot in the BTS.
For example #403557 should have been tagged more-info and eventually
closed as unreproducible 9 years ago and is still there tagged
security.

So I urge you to please find a new maintainer to either take over (in
the worst case) or simply work alongside yourself to help clean up the
backlog of bugs in this package.

If it is just that you left bugs open for so long (or inherited them
from a revious maintainer) that now you are swamped and can't catch up
then you could also contact the front desk to get some prospective new
DDs assigned to look over and triage bugs. It's good experience for
them and the package would hopefully get back on track.

MfG
Goswin

PS: This is not a personal attack on you but an encouragement to make
the package the best it can be. 

Bug#808822: insufficient flags in pkgconfig --cflags

[Goswin von Brederlow]

Package: qtbase5-dev
Version: 5.5.1+dfsg-10
Severity: normal

When building a trivial test case the following error appears:

% g++ -O2 -W -Wall -g $(pkg-config --cflags Qt5Widgets) -c foo.cc 
In file included from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qcoreapplication.h:37:0,
 from 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:37,
 from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QApplication:,
 from foo.cc:1:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1067:4: error: #error "You 
must build your code with position independent code if Qt was built with 
-reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)."
 #  error "You must build your code with position independent code if Qt was bui
^

Why isn't -fPIC included in the cflags?

MfG
Goswin

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages qtbase5-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]10.6.7-1
ii  libglu1-mesa-dev [libglu-dev]  9.0.0-2.1
ii  libqt5concurrent5  5.5.1+dfsg-10
ii  libqt5core5a   5.5.1+dfsg-10
ii  libqt5dbus55.5.1+dfsg-10
ii  libqt5egldeviceintegration55.5.1+dfsg-10
ii  libqt5gui5 5.5.1+dfsg-10
ii  libqt5network5 5.5.1+dfsg-10
ii  libqt5printsupport55.5.1+dfsg-10
ii  libqt5sql5 5.5.1+dfsg-10
ii  libqt5test55.5.1+dfsg-10
ii  libqt5widgets5 5.5.1+dfsg-10
ii  libqt5xcbqpa5  5.5.1+dfsg-10
ii  libqt5xml5 5.5.1+dfsg-10
ii  libxext-dev2:1.3.3-1
ii  qt5-qmake  5.5.1+dfsg-10
ii  qtbase5-dev-tools  5.5.1+dfsg-10
ii  qtchooser  47-gd2b7997-2

Versions of packages qtbase5-dev recommends:
ii  libqt5opengl5-dev  5.5.1+dfsg-10

Versions of packages qtbase5-dev suggests:
pn  firebird-dev
pn  libegl1-mesa-dev
ii  libgl1-mesa-dev 10.6.7-1
pn  libmysqlclient-dev  
pn  libpq-dev   
pn  libsqlite3-dev  
pn  unixodbc-dev

-- no debconf information

Bug#777043: Shark / libshark packaging status

[Goswin von Brederlow]

On Sat, Nov 28, 2015 at 12:22:19PM +0100, Andreas Tille wrote:
> Hi,
> 
> from my outsiders perspective I would assume that if you checked whether
> Goswins work contains something that might be relevant for the packaging
> and is not yet in your repository and upload as team upload in Debian
> Science things should be fine.  I'd recommend to drop a note in the
> repository inside Debian Med about the new location.
> 
> Surely Goswin as owner of the ITP has a last word but from the Debian
> Med teams point of view any progress that leads to an upload of the
> package is welcome.
> 
> Kind regards
> 
>   Andreas.
> 
> On Sat, Nov 28, 2015 at 09:32:56AM +, Ghislain Vaillant wrote:
> > Dear all,
> > 
> > I recently pushed a candidate source package for Shark [1] to the d-science
> > package repositories [2]. After more careful reading of the different ITP /
> > RFP bugs filed for Shark [3][4], I just realized that someone had already
> > started working on it a while back (Goswin).
> > 
> > Please correct if I am wrong but it seems that no upload to the main archive
> > has been done so far for Shark. And rightfully so, since there are some
> > licensing issues in the distributed files (bug filed upstream) and quite a
> > bit of patching had to be done to fix the build system (PR sent upstream).
> > So as of today, I would advise against sponsoring an upload for it just yet,
> > although the packaging is ready (lintian-free, upstream metdata,
> > autopkgtest...).
> > 
> > I don't know how you guys want to handle the duplication, but I wanted to
> > confirm that I am happy to join force with Goswin should he want to
> > co-maintain this package with me.
> > 
> > [1] https://github.com/Shark-ML/Shark
> > [2] https://anonscm.debian.org/cgit/debian-science/packages/shark.git
> > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595485
> > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777043
> > 
> > Best regards,
> > Ghislain

Go ahead and work on. I packaged this as it was a dependency for
something one of our customers wanted but interest seems to have been
reduced since then. So I'm happy passing this on to someone else.

MfG
Goswin

Bug#180283: rrdtool: CDEF function PREV(name) timesteps far too mauch

[Goswin von Brederlow]

On Wed, Aug 26, 2015 at 09:26:42AM +, Jean-Michel Vourgère wrote:
> Control: tags -1 +moreinfo
> Control: noowner -1
> 
> Hello Goswin
> 
> I'm cleaning up the rrdtool bug list, and I dig a bit into this one
> submitted back in 2003!
> https://bugs.debian.org/180283
> 
> I'm sorry no one from the Debian project answered you since then.
> 
> 
> You listed the cgi source, but not the actual command used to create the
> rrd database.
> A cgi only works if a database is created first. This is almost
> impossible to answer to your bug report without that information.
> 
> I can only assume you are (were) using code from the original donitor
> whose source code is available at http://sourceforge.net/projects/donitor/
> There, in file /sbin/update_rrd.pl, in function create_rrd, the step is
> set to 120 seconds, and the heartbeat to 240 seconds:
> 
> > rrdcreate esel.rrd --step 120 DS:workload_down:GAUGE:240:U:U 
> > DS:workload_up:GAUGE:240:U:U DS:overhead_in:GAUGE:240:U:U 
> > DS:overhead_out:GAUGE:240:U:U DS:connections:GAUGE:240:U:U 
> > DS:ds1:GAUGE:240:U:U DS:ds2:GAUGE:240:U:U RRA:AVERAGE:0.5:1:360 
> > RRA:AVERAGE:0.5:4:360 RRA:AVERAGE:0.5:16:360 RRA:AVERAGE:0.5:64:360 
> > RRA:AVERAGE:0.5:256:360 RRA:MIN:0.5:4:360 RRA:MIN:0.5:16:360 
> > RRA:MIN:0.5:64:360 RRA:MIN:0.5:256:360 RRA:MAX:0.5:4:360 RRA:MAX:0.5:16:360 
> > RRA:MAX:0.5:64:360 RRA:MAX:0.5:256:360
> 
> Actually, your variable names are different (urate3 versus ds2) but I'll
> assume a moment you were using these settings.
> 
> This means you have:
> - A 2 minutes resolution for 12 hours (meaning if last value is "now",
> then first value is now-11h58)
> - A 8 minutes resolution for 48 hours
> - A 32 minutes resolution for 8 days
> - ...
> 
> 
> Also, you defined:
> CDEF:sdrate3=PREV(sdrate3)
> which is impossible. PREV must be applied to another value, not to
> itself! This may be the source of the problem.
> I'll assume you meant sdrate3=PREV(drate3)
> 
> 
> I may have been able to reproduce the issue, but not just for sdrate3,
> all the data is showing a 8 minutes resolution.
> 
> Therefore, it seems normal that PREV() is 8 minutes earlier. Is it
> possible you did not notice that everything has a 8 pixel horizontal
> resolution but only that the two lines were 8 pixels apart?
> 
> As far as I can tell, x=PREV(x) is not working any more, it doesn't show
> weird things and does not loop nor overflow any more. This may have been
> fixed upstream.
> 
> 
> Now why do we have a 8 minutes resolution?
> 
> It tried different values for --start.
> --start 'end-12h00' yield a 8 minutes resolution
> --start 'end-11h00' yield a 8 minutes resolution
> --start 'end-10h59' yield a 2 minutes resolution
> 
> I may dig a bit in that part. There may be two issues there. A time zone
> one (I'm UTC+1) and an interval one...
> 
> If you still have the data, know the way you created the rrd file,
> and/or how it's filled, it will help pin point that issue.
> 
> Thanks
> 
> -- 
> Nirgal

Sorry, after 12 years I have no idea how I did set that up anymore nor
do I still run it.

MfG
Goswin

Bug#531756: closed by Stéphane Glondu <glo...@debian.org> (Re: Bug#531756: [ocaml] code_of_unix_error available now)

[Goswin von Brederlow]

On Fri, Aug 28, 2015 at 12:27:25PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the ocaml package:
> 
> #531756: Add extern int code_of_unix_error (value error);
> 
> It has been closed by Stéphane Glondu .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Stéphane Glondu 
>  by
> replying to this email.

Thanks.

MfG
Goswin

Bug#796563: Please don't use /home/Debian-pxe as home

[Goswin von Brederlow]

Package: pxe
Version: 1.4.2-7
Severity: normal

Hi,

the pxe package creates a dummy user with

Debian-pxe:x:101:65534:Dummy user for Debian pxe 
package,,,:/home/Debian-pxe:/bin/false

Please don't use /home for this as this collides with having home
shared over NFS or automounted.

Most packages use /var/lib/package or /var/run/package (nowadays
/run/package) for their home staying out of the way of the real users homes.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pxe depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.19-17
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

Versions of packages pxe recommends:
ii  atftpd  0.7.git20120829-1
pn  dhcp3-server | dnsmasq  none
ii  syslinux3:6.03+dfsg-5

pxe suggests no packages.

-- Configuration Files:
/etc/pxe.conf changed [not included]

-- no debconf information

Bug#794765: Please provide debug build of pyside

[Goswin von Brederlow]

On Wed, Aug 12, 2015 at 08:29:28PM +0200, Didier 'OdyX' Raboud wrote:
 Le mercredi, 12 août 2015, 16.00:22 Goswin von Brederlow a écrit :
   Le jeudi, 6 août 2015, 14.40:10 Goswin von Brederlow a écrit :
every now and then pyside crashes with a segfault. Most often
because
it doesn't play nice with the python GC and widgets have to keep
python objects stored in C++ alive manually. But sometimes it
isn't obvious where and why pyside segfaults. For those it would
be nice if one could use python3-dbg and get better gdb backtraces
for the application. But this requires a debug build of pyside.

Please provide a debug build of pyside.
   
   Since 1.0.9-2, debug packages are not built anymore, as they were
   huge to build and resulted in insanely big binary packages, see
   http://snapshot.debian.org/package/pyside/1.0.9-1/ .
 
  The -dbg build got  1% tests passed, 405 tests failed out of 408.
  Lots of failures in refrence counts, tests/QtGui/qmainwindow_test.py
  and tests/QtWebKit/shouldInterruptjavascript_test.py hang and need to
  be manually killed, lots of segfaults in the tests and finally:
 
 Yes. This was the other problem with debug builds: there is something 
 fishy going on with python-dbg builds and tests. Upstream is basically 
 unresponsive and I'm reaching my limits (in terms of competences, as 
 well as motivation).
 
 Frankly, I'm only a PySide maintainer because I was initially interested 
 in it in the context of debian-mobile, but I'm not at all using PySide 
 (although I like the idea of doing Qt in python). So the status is not 
 actively involved, but welcoming patches. I'm happy to hand 
 maintainership over too, only staying because I feel responsible 
 (although less and less).
 
  When was the last time you did a debug build?
 
 For 1.0.9-2, apparently.
 
  PS: That's why I want debug packages from the start no matter how big
  they are. If they aren't autobuild then by the time you need them they
  don't work.
 
 I welcome patches though??? :) I know it's an easy answer, but that's the 
 best one I can offer.
 
 Cheers,
 OdyX

If I get a spare hour somewhere I can send patches for the control
file and .install file fixes easy enough. The test suite failures get
ignored so that isn't a stopper. I tested the resulting debs with
python3-dbg and they work fine. So it's something fishy in the test
suite itself as you suggest. I would suggest not running them for
-dbg package because like you I don't care enough to fix something
that complicated and fishy. I would suggest not running them for
-dbg package because like you I don't care enough to fix something
that complicated and fishy.

The blocking tests are the main problem. I don't know why but I see
that in basically every single test suite out there. None of them seem
to come with a default timeout out of the box so any hanging test will
hang forever. And usualy the test suite frameworks are hugely complex
that adding that feature is not trivial. I'm not sure if I will find
the time and motivation to delve that deep into it any time soon.

I didn't check the build log closely but since PySide autobuilds
without debug it seems likely that the test cases only hang for debug
packages. So disabling the test suite for them might be a quick fix
for that problem too. That's probably easy enough to try.

MfG
Goswin

Bug#795260: Please consider downgrading when calling apt-get -f install

[Goswin von Brederlow]

Package: apt
Version: 1.0.9.1
Severity: normal

Lets say the following packages are installed:

Package: foo
Version: 1.0
Depend: bar | baz

Package: bar
Version: 1.0+broken
Depends: broken

and the default repository has the following packages:

Package: foo
Version: 1.0
Depend: bar | baz

Package: bar
Version: 1.0

Package: baz
Version: 1.0

Trying to install anything with apt tells you to try apt-get -f
install to fix the broken dependency. But apt-get -f install will
then suggest removing bar and installing baz.

Instead I think the less intrusive fix would be to suggest
downgrading bar but apt-get does not seem to consider that at all.

MfG
Goswin


-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages apt depends on:
ii  debian-archive-keyring  2012.4
ii  gnupg   1.4.16-1.1
ii  libapt-pkg4.12  1.0.9.1
ii  libc6   2.19-17
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

apt recommends no packages.

Versions of packages apt suggests:
ii  apt-doc 1.0.2
ii  aptitude0.6.10-1
ii  dpkg-dev1.17.18
pn  python-apt  none

-- no debconf information


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

Bug#794765: Please provide debug build of pyside

[Goswin von Brederlow]

On Thu, Aug 06, 2015 at 05:51:59PM +0200, Didier 'OdyX' Raboud wrote:
 Control: found -1 1.0.9-2
 
 Le jeudi, 6 août 2015, 14.40:10 Goswin von Brederlow a écrit :
  every now and then pyside crashes with a segfault. Most often because
  it doesn't play nice with the python GC and widgets have to keep
  python objects stored in C++ alive manually. But sometimes it isn't
  obvious where and why pyside segfaults. For those it would be nice if
  one could use python3-dbg and get better gdb backtraces for the
  application. But this requires a debug build of pyside.
  
  Please provide a debug build of pyside.
 
 Since 1.0.9-2, debug packages are not built anymore, as they were huge 
 to build and resulted in insanely big binary packages, see 
 http://snapshot.debian.org/package/pyside/1.0.9-1/ .
 
 You can still build these yourself, see:
   http://sources.debian.net/src/pyside/1.2.2-1/debian/README.source
 
 Is this enough for you? I really don't want to add the debug packages 
 back (and don't plan much PySide work at all, btw).
 
 Cheers,
 OdyX

Pyside should at least the standard -dbg packages with the striped
symbols so gdb backtraces make sense. 

It would be nice to have everything for python3-dbg because it's a
pain to build debug packages when you need them. Esspecially when more
packages start not shiping them. But if the size is preventing that
for PySide then there isn't much to do there.

Problem is that recompiling pyside might not show the bug anymore
since the toolchain and build dependencies will have changed. Makes it
real hard to debug memory/stack corruption bugs.


Last building debug packages according to README.source does not work:

dpkg-source: error: syntax error in pyside-1.2.1/debian/control at line 383: 
duplicate field Package found

There is an empty line missing before Package: python-pyside-dbg.
Either debian/control.in needs to end in an empty line or
debian/control.dbg-packages needs to start with one.

MfG
Goswin


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

Bug#794765: Please provide debug build of pyside

[Goswin von Brederlow]

On Thu, Aug 06, 2015 at 05:51:59PM +0200, Didier 'OdyX' Raboud wrote:
 Control: found -1 1.0.9-2
 
 Le jeudi, 6 août 2015, 14.40:10 Goswin von Brederlow a écrit :
  every now and then pyside crashes with a segfault. Most often because
  it doesn't play nice with the python GC and widgets have to keep
  python objects stored in C++ alive manually. But sometimes it isn't
  obvious where and why pyside segfaults. For those it would be nice if
  one could use python3-dbg and get better gdb backtraces for the
  application. But this requires a debug build of pyside.
  
  Please provide a debug build of pyside.
 
 Since 1.0.9-2, debug packages are not built anymore, as they were huge 
 to build and resulted in insanely big binary packages, see 
 http://snapshot.debian.org/package/pyside/1.0.9-1/ .
 
 You can still build these yourself, see:
   http://sources.debian.net/src/pyside/1.2.2-1/debian/README.source
 
 Is this enough for you? I really don't want to add the debug packages 
 back (and don't plan much PySide work at all, btw).
 
 Cheers,
 OdyX

Some hours of building later:

The -dbg build got  1% tests passed, 405 tests failed out of 408.
Lots of failures in refrence counts, tests/QtGui/qmainwindow_test.py
and tests/QtWebKit/shouldInterruptjavascript_test.py hang and need to
be manually killed, lots of segfaults in the tests and finally:

# Do the legacy install for the rest
dh_install -ppython-pyside-dbg --sourcedir=debian/tmp-dbg
dh_install -ppython3-pyside-dbg --sourcedir=debian/tmp-dbg
dh_install: python3-pyside-dbg missing files 
(usr/lib/*/cmake/PySide-*/*dmu.cmake), aborting
make[1]: *** [override_dh_install_2] Error 255
make[1]: Leaving directory `/build/brederlo/pyside/pyside-1.2.1'
make: *** [binary] Error 2


When was the last time you did a debug build?

MfG
Goswin

PS: That's why I want debug packages from the start no matter how big
they are. If they aren't autobuild then by the time you need them they
don't work.

Bug#794869: debuild: Please clean up locale settings if broken

[Goswin von Brederlow]

Package: devscripts
Version: 2.14.10
Severity: minor
File: /usr/bin/debuild

When building in a chroot or remotely it easily happens that the
locale settings of the local host don't match the chroot or remote
host. This results in a million errors like this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_MESSAGES = POSIX,
LC_CTYPE = de_DE,
LANG = en_US.UTF-8
are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).

Debuild should check the local settings and unset any that don't work.
Or even better: To get reproducible builds always unset them.

MfG
Goswin

-- Package-specific info:

--- /etc/devscripts.conf ---
DEBUILD_ROOTCMD=fakeroot
DEBUILD_PREPEND_PATH=/usr/lib/ccache

--- ~/.devscripts ---
Not present

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages devscripts depends on:
ii  dpkg-dev 1.17.18
ii  libc62.19-17
ii  perl 5.20.1-5
ii  python3  3.3.4-1
pn  python3:any  none

Versions of packages devscripts recommends:
ii  at  3.1.14-1
ii  dctrl-tools 2.23
ii  debian-keyring  2014.04.25
ii  dupload 2.7.0
ii  equivs  2.0.9
ii  fakeroot1.20-3
ii  file1:5.18-1
ii  gnupg   1.4.16-1.1
pn  libdistro-info-perl none
ii  libencode-locale-perl   1.03-1
pn  libjson-perlnone
ii  liblwp-protocol-https-perl  6.04-2
ii  libparse-debcontrol-perl2.005-4
ii  libsoap-lite-perl   1.10-1
ii  liburi-perl 1.60-1
ii  libwww-perl 6.06-1
ii  lintian 2.5.22.1
ii  man-db  2.6.7.1-1
ii  patch   2.7.1-5
ii  patchutils  0.3.3-1
pn  python3-debian  none
pn  python3-magic   none
ii  sensible-utils  0.0.9
ii  strace  4.5.20-2.3
ii  unzip   6.0-12
ii  wdiff   1.2.1-3
ii  wget1.15-1
ii  xz-utils5.1.1alpha+20120614-2

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20131005cvs-1
ii  build-essential  11.6
pn  cvs-buildpackage none
pn  devscripts-elnone
ii  gnuplot  4.6.6-2
ii  gpgv 1.4.16-1.1
pn  libauthen-sasl-perl  none
pn  libfile-desktopentry-perlnone
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perlnone
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perlnone
ii  mailx1:20081101-2
ii  mutt 1.5.23-1
ii  openssh-client [ssh-client]  1:6.6p1-5
ii  svn-buildpackage 0.8.5
ii  w3m  0.5.3-15

-- no debconf information


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

Bug#794765: Please provide debug build of pyside

[Goswin von Brederlow]

Source: pyside
Severity: important

Hi,

every now and then pyside crashes with a segfault. Most often because
it doesn't play nice with the python GC and widgets have to keep
python objects stored in C++ alive manually. But sometimes it isn't
obvious where and why pyside segfaults. For those it would be nice if
one could use python3-dbg and get better gdb backtraces for the
application. But this requires a debug build of pyside.

Please provide a debug build of pyside.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


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

Bug#794217: socketpair: unclear where the SOCK_NONBLOCK and SOCK_CLOEXEC flags go

[Goswin von Brederlow]

Package: manpages-dev
Version: 3.74-1
Severity: minor
File: socketpair

Hi,

reading 'man 2 socketpair' it is unclear where the new SOCK_NONBLOCK
and SOCK_CLOEXEC flags go in the function call. One has to read
through man 2 socket to discover that the type argument now also
serves as flags.

I recommend making this a bit clearer by changing the Notes from:

   Since   Linux  2.6.27,  socketpair()  supports  the  SOCK_NONBLOCK  and
   SOCK_CLOEXEC flags described in socket(2).

to:

   Since   Linux  2.6.27,  socketpair()  supports  the  SOCK_NONBLOCK  and
   SOCK_CLOEXEC flags in the _type_ argument as described in socket(2).

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages manpages-dev depends on:
ii  manpages  3.61-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.6.7.1-1

-- no debconf information


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

Bug#792399: seed breaks with extra newlines

[Goswin von Brederlow]

Package: electrum
Version: 1.9.8-4
Severity: important

When creating a wallet electrum displays a random sequence of words as
seed. It then asks the user to enter said seed to make sure it was
saved. This breaks when extra newlines are entered. The input mask
should strip any extra newline from the seed.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages electrum depends on:
ii  python   2.7.5-5
ii  python-electrum  1.9.8-4

electrum recommends no packages.

electrum suggests no packages.

-- no debconf information


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

Bug#786564: Please add option for extra precision human readable output

[Goswin von Brederlow]

On Fri, May 22, 2015 at 05:37:04PM -0400, Michael Stone wrote:
 On Fri, May 22, 2015 at 11:24:03PM +0200, Goswin von Brederlow wrote:
 when using df -h the output will use the largest unit that doesn't
 have a leading 0. This often results in quite imprecise output, e.g.
 1.1T or 1.8G. It would be nice if instead it cout use the smallest
 unit that use 4 or less characters (maybe even 5 if a . is involved).
 
 I'm struggling to think of a use case that requires 4 digits of precision on
 a terabyte filesystem. If you need to know the exact size, then get the size
 in bytes. Otherwise, it's probably close enough.
 
 Mike Stone

4 chars for the number, which would only be 1-2 digits of precision.
As in 11.7G instead of 12G or 1750M instead of 1.8G. 4 digits of
precision would indeed be too much.

MfG
Goswin


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

Bug#786563: df: undocumented option -m

[Goswin von Brederlow]

Package: coreutils
Version: 8.21-1.2
Severity: minor
File: /bin/df

Hi,

I just noticed that the df manpage is not mentioning -m.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-1
ii  libattr1 1:2.4.47-1
ii  libc62.19-17
ii  libselinux1  2.3-1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


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

Bug#786564: Please add option for extra precision human readable output

[Goswin von Brederlow]

Package: coreutils
Version: 8.21-1.2
Severity: wishlist
File: /bin/df

Hi,

when using df -h the output will use the largest unit that doesn't
have a leading 0. This often results in quite imprecise output, e.g.
1.1T or 1.8G. It would be nice if instead it cout use the smallest
unit that use 4 or less characters (maybe even 5 if a . is involved).

So the output would go

0 -     0 -  
10.0k - k  or  10.00k - k
10.0M - M  10.00M - M
10.0G - G  or  10.00G - G

and so on. Extra points for adding a --precision=num chars instead
of hardcoding 4/5 chars.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-1
ii  libattr1 1:2.4.47-1
ii  libc62.19-17
ii  libselinux1  2.3-1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


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

Bug#785703: ITP: python-oath -- implementation of the three main OATH specifications

[Goswin von Brederlow]

Package: wnpp
Severity: wishlist
Owner: Goswin von Brederlow brede...@q-leap.de

* Package name: python-oath
  Version : 1.4.0
  Upstream Author : Benjamin Dauvergne benjamin.dauver...@gmail.com
* URL : https://github.com/bdauvergne/python-oath
* License : BSD
  Programming Lang: Python
  Description : implementation of the three main OATH specifications

 Oath includes 3 modules implementing the three main OATH specifications:
 - HOTP, an event based one-time password standard using HMAC signatures,
 - TOTP, a time based OTP,
 - OCRA, a mixed OTP / signature system based on HOTP for complex use cases.

 Supports python 2.x and python 3.x.


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

Bug#785703: Packaging for ITP

[Goswin von Brederlow]

Packaging for python-oath can be checked out from

https://github.com/Q-Leap-Networks/python-oath/

MfG
Goswin


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

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

[Goswin von Brederlow]

Hi,

3.17-34 didn't make it into jessie. Could you please upload a fixed
package to stable-proposed-updates or maybe even security?

MfG
Goswin


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

Bug#783702: Does not support large disks

[Goswin von Brederlow]

Package: e2fsprogs
Version: 1.42.12-1.1
Severity: normal
File: /sbin/badblocks

I'm trying to test a zfs volume:

# badblocks -b 4096 -c 4096 -s -s -w  /dev/test/test
badblocks: Value too large for defined data type invalid end block 
(8650752000): must be 32-bit value

# zfs list
NAMEUSED  AVAIL  REFER  MOUNTPOINT
test   33.2T   988G   153K  /test
test/test  33.2T  34.2T  6.32G  -

So yeah, the volume is big. But seriously? Who uses a 32bit variable
to store the number of blocks of a disk on a 64bit system? Who then
checks for it to overflow instead of simply changing it to 64bit (at
least on 64bit systems)?

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.42.9-3
ii  libblkid1   2.25.2-6
ii  libc6   2.19-17
ii  libcomerr2  1.42.9-3
ii  libss2  1.42.9-3
ii  libuuid12.20.1-5.7
ii  util-linux  2.20.1-5.7

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  none
pn  gpart  none
ii  parted 2.3-20

-- no debconf information


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

Bug#781904: [Pkg-dia-team] Bug#781904: Export to png gets text width wrong

[Goswin von Brederlow]

On Sat, Apr 04, 2015 at 12:27:33PM -0700, Octavio Alvarez wrote:
 On 04/04/2015 08:59 AM, Goswin von Brederlow wrote:
 
  In the PNG export some boxes are too small for the text they contain.
 
 Hi. Can you please provide a sample diagram (in Dia format) and its
 exported PNG version? [*] Also, which of all the available PNG export
 filters is the one showing this behavior?

I already did attach them to the original report. What boxes I mean
should be clear from the png where the text exceeds the surrounding
box.

I used exporting by extension. So whatever is the default png export
filter or *.png.
 
 You mention some boxes. Can you identify what kind of boxes are the
 ones that get exported too small? Or, seen from another perspective,
 what font, size and weight is the one being rendered too wide? Can you
 narrow it down as if it is a specific kind of box or a specific kind of
 font?

I didn't do anything fancyfull so it should be all default font, size,
weight. It does seem to only happen to one kind of box (that I used so
far), the UML Large Package. See provided sample files.
 
 All this info will help find the root cause for the bug and be able to
 fix it.
 
 [*] Please remember that your sample document will be made publicly
 available, so you may need to create a version that does not containt
 sensitive information.
 
 Thanks.

MfG
Goswin


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

Bug#782430: wheezy - jessie update fails, missing pre-depends on py3clean

[Goswin von Brederlow]

Source: python3-apt
Version: 0.9.3.11
Severity: normal

Doing a wheezy - jessie update fails with:

Preparing to unpack .../python3-apt_0.9.3.11_amd64.deb ...
/var/lib/dpkg/info/python3-apt.prerm: 6: /var/lib/dpkg/info/python3-apt.prerm: 
py3clean: not found
dpkg: warning: subprocess old pre-removal script returned error exit status 127
dpkg: trying script from the new package instead ...
/var/lib/dpkg/tmp.ci/prerm: 6: /var/lib/dpkg/tmp.ci/prerm: py3clean: not found
dpkg: error processing archive 
/var/cache/apt/archives/python3-apt_0.9.3.11_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 127
/var/lib/dpkg/info/python3-apt.postinst: 6: 
/var/lib/dpkg/info/python3-apt.postinst: py3compile: not found

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


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

Bug#781904: Export to png gets text width wrong

[Goswin von Brederlow]

Package: dia
Version: 0.97.3-1
Severity: normal

In the PNG export some boxes are too small for the text they contain.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages dia depends on:
ii  dia-common   0.97.3-1
ii  dia-libs 0.97.3-1
ii  libart-2.0-2 2.3.21-2
ii  libatk1.0-0  2.12.0-1
ii  libc62.19-17
ii  libcairo21.12.16-2
ii  libfontconfig1   2.11.0-5
ii  libfreetype6 2.5.2-1
ii  libgdk-pixbuf2.0-0   2.30.7-1
ii  libglib2.0-0 2.40.0-3
ii  libgtk2.0-0  2.24.24-1
ii  libpango-1.0-0   1.36.3-1
ii  libpangocairo-1.0-0  1.36.3-1
ii  libpangoft2-1.0-01.36.3-1
ii  libpng12-0   1.2.50-1
ii  libxml2  2.9.1+dfsg1-3
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages dia recommends:
ii  dia-shapes   0.6.0-1
ii  gsfonts-x11  0.22

dia suggests no packages.

-- no debconf information


Moose.dia
Description: application/gzip

Bug#780583: bashisms in rules template

[Goswin von Brederlow]

Package: cross-gcc-dev
Version: 13
Severity: normal
File: /usr/share/cross-gcc/template/rules.generic

The rules.generic files uses $(shell source ). That is a bashism
and fails when /bin/sh is dash. Setting SHELL := bash at the start
fixes that.

There is a second minor bug there when creating debian/control:

awk: fatal: cannot open file `debian/control' for reading (No such file or 
directory)

The rules files tries to parse debian/control to set PACKAGES before
it is created.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages cross-gcc-dev depends on:
ii  make  4.0-8

cross-gcc-dev recommends no packages.

cross-gcc-dev suggests no packages.

-- no debconf information


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

Bug#780585: Mysterious failure to update/install packages

[Goswin von Brederlow]

Package: dpkg
Version: 1.17.23
Severity: normal

I had to test something quickly in an older sid chroot (hence the many
not updated packages) and updating libgcc1 + libc6 failed without
clear reason why. Running dpkg --configure -a configured the 2
packages just fine.

I'm unsure what went wrong there. Is dpkg screwing up the order in
which packages get configured or is apt-get? Or what ios going on there?

MfG
Goswin

% sudo apt-get install libc6-dev:armel linux-libc-dev:armel libgcc1:armel 
binutils-arm-linux-gnueabi libcloog-isl-dev systemtap-sdt-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libbotan-1.10-0 libdv4 libiec61883-0 libpthread-stubs0-dev libqt5core5a
  libxcb-icccm4 libxcb-image0 libxcb-render-util0 libxcb-xkb1 qtcreator-data
  x11proto-kb-dev xorg-sgml-doctools xtrans-dev
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  binutils cpp-4.9 g++-4.9 gcc-4.9 gcc-4.9-base gcc-4.9-base:armel  
  gcc-4.9-base:i386 libasan1 libatomic1 libc-dev-bin libc6 libc6:i386
  libc6:armel libc6-dbg libc6-dev libcilkrts5 libgcc-4.9-dev libgcc1
  libgcc1:i386 libgfortran3 libgomp1 libitm1 liblsan0 libquadmath0  
  libstdc++-4.9-dev libstdc++6 libstdc++6:i386 libtsan0 libubsan0   
  linux-libc-dev locales locales-all
Suggested packages:
  gcc-4.9-locales g++-4.9-multilib libstdc++6-4.9-dbg gcc-4.9-multilib
  libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg libasan1-dbg  
  liblsan0-dbg libtsan0-dbg libubsan0-dbg libcilkrts5-dbg libquadmath0-dbg
  glibc-doc glibc-doc:i386 glibc-doc:armel manpages-dev:armel
  libstdc++-4.9-doc
Recommended packages:
  libc6-i686:i386
The following NEW packages will be installed:
  binutils-arm-linux-gnueabi gcc-4.9-base:armel libc6:armel libc6-dev:armel
  libcloog-isl-dev libgcc1:armel linux-libc-dev:armel systemtap-sdt-dev
The following packages will be upgraded:
  binutils cpp-4.9 g++-4.9 gcc-4.9 gcc-4.9-base gcc-4.9-base:i386 libasan1
  libatomic1 libc-dev-bin libc6 libc6:i386 libc6-dbg libc6-dev libcilkrts5
  libgcc-4.9-dev libgcc1 libgcc1:i386 libgfortran3 libgomp1 libitm1 liblsan0
  libquadmath0 libstdc++-4.9-dev libstdc++6 libstdc++6:i386 libtsan0 libubsan0
  linux-libc-dev locales locales-all
30 upgraded, 8 newly installed, 0 to remove and 1323 not upgraded.  
Need to get 74.0 MB/74.1 MB of archives.
After this operation, 41.7 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
...
Fetched 74.0 MB in 9s (7666 kB/s)
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 193728 files and directories currently installed.)
Preparing to unpack .../libc-dev-bin_2.19-17_amd64.deb ...
Unpacking libc-dev-bin (2.19-17) over (2.19-13) ...
Preparing to unpack .../libc6-dev_2.19-17_amd64.deb ...
Unpacking libc6-dev:amd64 (2.19-17) over (2.19-13) ...
Preparing to unpack .../libc6-dbg_2.19-17_amd64.deb ...
Unpacking libc6-dbg:amd64 (2.19-17) over (2.19-13) ...
Preparing to unpack .../locales-all_2.19-17_amd64.deb ...
Unpacking locales-all (2.19-17) over (2.19-1) ...
Preparing to unpack .../locales_2.19-17_all.deb ...
Unpacking locales (2.19-17) over (2.19-1) ...
Preparing to unpack .../libc6_2.19-17_amd64.deb ...
De-configuring libc6:i386 (2.19-13) ...
Unpacking libc6:amd64 (2.19-17) over (2.19-13) ...
Preparing to unpack .../libc6_2.19-17_i386.deb ...
Unpacking libc6:i386 (2.19-17) over (2.19-13) ...
Preparing to unpack .../linux-libc-dev_3.16.7-ckt7-1_amd64.deb ...  
Unpacking linux-libc-dev:amd64 (3.16.7-ckt7-1) over (3.14.2-1) ...  
Preparing to unpack .../gcc-4.9-base_4.9.2-10_amd64.deb ...
De-configuring gcc-4.9-base:i386 (4.9.2-2) ...
Unpacking gcc-4.9-base:amd64 (4.9.2-10) over (4.9.2-2) ...
Preparing to unpack .../gcc-4.9-base_4.9.2-10_i386.deb ...
Unpacking gcc-4.9-base:i386 (4.9.2-10) over (4.9.2-2) ...
Preparing to unpack .../libgcc1_1%3a4.9.2-10_i386.deb ...
De-configuring libgcc1:amd64 (1:4.9.2-2) ...
Unpacking libgcc1:i386 (1:4.9.2-10) over (1:4.9.2-2) ...
Preparing to unpack .../libgcc1_1%3a4.9.2-10_amd64.deb ...
Unpacking libgcc1:amd64 (1:4.9.2-10) over (1:4.9.2-2) ...
Selecting previously unselected package libgcc1:armel.
Preparing to unpack .../libgcc1_1%3a4.9.2-10_armel.deb ...
Unpacking libgcc1:armel (1:4.9.2-10) ...
Setting up gcc-4.9-base:amd64 (4.9.2-10) ...
Setting up gcc-4.9-base:i386 (4.9.2-10) ...
dpkg: dependency problems prevent configuration of libc6:amd64:
 libc6:amd64 depends on libgcc1; however:
  Package libgcc1:amd64 is not configured yet.

dpkg: error processing package libc6:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libgcc1:i386:
 libgcc1:i386 depends on libc6 (= 2.2.4); however:
  Package libc6:i386 is not configured yet.

dpkg: error processing package libgcc1:i386 (--configure):
 dependency problems - leaving unconfigured
Errors were 

Bug#678696: Event based block device handling (fixes USB and nested devices problem)

[Goswin von Brederlow]

On Wed, Mar 11, 2015 at 06:09:50PM +, Ben Hutchings wrote:
 On Tue, 2015-03-10 at 12:47 +0100, Goswin von Brederlow wrote:
  On Wed, Mar 04, 2015 at 09:30:24PM +, Ben Hutchings wrote:
   Thanks for your work on this bug.  I ended up with a somewhat different
   implementation as I don't think it's necessary to duplicate the
   information that udev provides, and as we may now need to mount more
   than one filesystem.  But I should have credited you in the changelog
   for prototyping this, and I forgot to do so.
   
   Ben.
  
  The idea with the udev rule was to wait up to ROOTDELAY seconds
  without a new device apearing before giving up. Now you wait ROOTDELAY
  seconds in total, which then can depend on the number of devices.
 
 It's now max(rootdelay, 30) because the rootdelay kernel parameter
 wasn't meant for this purpose at all.
 
  Add  new disk and you have to increase the ROOTDELAY.
 
 I hope not!

On one system the PSU isn't big enough to spin up all disks at once.
So the SCSI controler is set to not start them on power on. Instead
they come up sequentially. So one disk takes 5s, 2 disks 10s, 3 disks
15s, ... accordingly you have to set the delay. Add another disk and
the total time goes up.
 
  Also it was ment so that block scripts could specifically target the
  new devices instead of having to scan all devices every time. For
  example say you have a crypt device and you forgot the password. Now I
  think you will be asked 30 times for the password before the initramfs
  gives up.
 
 True, but so far as I could see you didn't send scripts that made use of
 that.  We could still implement that later, I think.

 And now that we potentially have to mount /usr (and possibly other
 filesystems), not just root and swap, lvm2's script needed to be told
 which device we're looking for, not which devices appeared.
 
 Ben.

That isn't realy new. Debian already had root and swap. Adding a third
doesn't realy change anything. LVM should already have known what
devices to activate for root and swap.

The problem I see there is detecting what devices to bring up. The
/usr filesystem might be in a ZPOOL that uses a crypt device on a LVM
logical volume on a raid. Or any other complex nesting. Could be any
number of devices that are needed for /usr to become available. Again
nothing new for /usr, / and swap already have that problem.

Note: LVM has persistent metadata that tell it wether to bring up a
device or not. So I'm not sure it makes much sense to guess what
devices are needed and limiting lvm to only start those. The metadata
already has this functionality and is more reliable than guessing what
devices may be needed.

MfG
Goswin


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

Bug#678696: Event based block device handling (fixes USB and nested devices problem)

[Goswin von Brederlow]

On Wed, Mar 04, 2015 at 09:30:24PM +, Ben Hutchings wrote:
 Thanks for your work on this bug.  I ended up with a somewhat different
 implementation as I don't think it's necessary to duplicate the
 information that udev provides, and as we may now need to mount more
 than one filesystem.  But I should have credited you in the changelog
 for prototyping this, and I forgot to do so.
 
 Ben.

The idea with the udev rule was to wait up to ROOTDELAY seconds
without a new device apearing before giving up. Now you wait ROOTDELAY
seconds in total, which then can depend on the number of devices. Add
a new disk and you have to increase the ROOTDELAY.

Also it was ment so that block scripts could specifically target the
new devices instead of having to scan all devices every time. For
example say you have a crypt device and you forgot the password. Now I
think you will be asked 30 times for the password before the initramfs
gives up.

MfG
Goswin


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

Bug#778405: wrong version used for BUILD_USING lookup

[Goswin von Brederlow]

Package: gcc-arm-none-eabi
Version: 4.8.3-9+11
Severity: normal

Hi,

I'm trying to build gcc-arm-none-eabi using gcc-4.9-source. The
debian/rules files nicely defines GCC_VERSION at the top and I thought
that would be all that I need to change. But a few lines later the
BUILT_USING lookup has gcc-4.8-source hardcoded instead of using
gcc-$(GCC_VERSION)-source. The attached patch fixes that.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-arm-none-eabi depends on:
ii  binutils-arm-none-eabi  2.24.51.20140604-3+5
ii  libc6   2.19-13
ii  libcloog-isl4   0.18.2-1+b2
ii  libgcc1 1:4.9.2-2
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.2-2
ii  libmpfr43.1.2-3
ii  libstdc++6  4.9.2-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gcc-arm-none-eabi recommends:
pn  libnewlib-arm-none-eabi  none

gcc-arm-none-eabi suggests no packages.

-- no debconf information
--- debian/rules.old	2015-02-14 15:57:48.452778015 +0100
+++ debian/rules	2015-02-14 15:57:17.524797134 +0100
@@ -19,7 +19,7 @@
 deb_version := $(source_version)+$(shell dpkg-parsechangelog | sed -ne s/^Version: \(.*\)/\1/p)
 deb_upstream_version := $(shell echo $(deb_version) | cut -d- -f1)
 base_version := $(shell echo $(deb_version) | sed -e 's/\([1-9]\.[0-9]\).*-.*/\1/')
-BUILT_USING := $(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W gcc-4.8-source)
+BUILT_USING := $(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W gcc-$(GCC_VERSION)-source)
 
 upstream_dir=gcc-$(deb_upstream_version)
 

Bug#776735: error: no alternatives for gobby

[Goswin von Brederlow]

On Mon, Feb 09, 2015 at 11:55:58PM +0100, Philipp Kern wrote:
 On Sat, Jan 31, 2015 at 11:15:22PM +0100, Goswin von Brederlow wrote:
  Updating gobby from 0.4.13-1 to 0.5.0-4 fails with:
  
  Preparing to unpack .../gobby_0.5.0-4_amd64.deb ...
  update-alternatives: error: no alternatives for gobby
  dpkg: error processing archive 
  /var/cache/apt/archives/gobby_0.5.0-4_amd64.deb (--unpack):
   subprocess new pre-installation script returned error exit status 2
 
 Did this legitimally happen upon upgrade? Because I would've expected
 gobby-0.4 and gobby-0.5 to have been around. (Of course one can force
 this to appear using dpkg -i and not satisfying dependencies, just
 wondering if that happened here.)
 
 I'll fix it anyhow, just trying to figure out if that needs to go into
 jessie.
 
 Kind regards and thanks for the report
 Philipp Kern

It was a normal update of a seldomly used (and therefore sparingly
updated) laptop running sid.

As a side node the old, unconditional removal of the alternatives
violates the idempotency of the script. The installation can fail,
which I think happened in my case due to other packages failing, or be
aborted after the preinst has run. Then when the installation is tried
again removing the alternative fails because it is already gone.

MfG
Goswin


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

Bug#777043: ITP: libshark -- Shark Machine Learning Library

[Goswin von Brederlow]

On Wed, Feb 04, 2015 at 08:04:20PM +0100, Christian Kastner wrote:
 Control: merge 595485 777043
 
 Hi Goswin,
 
 On 2015-02-04 13:37, Goswin von Brederlow wrote:
  * Package name: libshark
Version : 3.0.11
Upstream Author : Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum
  * URL : http://image.diku.dk/shark/
  * License : GPL-3.0+
Programming Lang: C++
Description : Shark Machine Learning Library
 
 I filed an ITP for this a while ago, but let it revert to an RFP, and
 haven't refiled for ITP since.
 
 I actually still have the repo with the work I did so far, you can find
 it here if it helps (although it is woefully obsolete)
 
 http://code.kvr.at/git/?p=pkg-libshark.git;a=summary
 
 I don't recall why I never finished this ITP. IIRC, I was having a hard
 time tracking contributions for debian/copyright, and this was followed
 period where my involvement in Debian declined for personal reasons. But
 I don't think there were any showstoppers.
 
 Regards,
 Christian

That was over 4 years ago, so yes, somewhat obsolete.

Comparing against your packaging there are some important and
encouraging changes:

- upstream version 2.3.2 - 3.0.11
- upstream has a debian dir which is at least a starting point
  (includes a debian/copyright)
- non-free image seem to be gone
- non-free xmlparser (Fuzzy) no longer in trunk
- standard TeX styles no longer included
- compiles out of the box

It looks like upstream is in a far better state now then it was back then.

MfG
Goswin


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

Bug#777043: ITP: libshark -- Shark Machine Learning Library

[Goswin von Brederlow]

Package: wnpp
Severity: wishlist
Owner: Goswin von Brederlow goswin-...@web.de

* Package name: libshark
  Version : 3.0.11
  Upstream Author : Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum
* URL : http://image.diku.dk/shark/
* License : GPL-3.0+
  Programming Lang: C++
  Description : Shark Machine Learning Library

 SHARK is a modular C++ library for the design and
 optimization of adaptive systems. It provides methods for linear and
 nonlinear optimization, in particular evolutionary and gradient-based
 algorithms, kernel-based learning algorithms and neural networks, and
 various other machine learning techniques. SHARK serves as a toolbox
 to support real world applications as well as research indifferent
 domains of computational intelligence and machine learning. The
 sources are compatible with the following platforms: Windows, Solaris,
 MacOS X, and Linux.


- libshark is a dependency of sailfish
- the package will be maintained under the Debian-Med team


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

Bug#776735: error: no alternatives for gobby

[Goswin von Brederlow]

Package: gobby
Version: 0.5.0-4
Severity: normal

Updating gobby from 0.4.13-1 to 0.5.0-4 fails with:

Preparing to unpack .../gobby_0.5.0-4_amd64.deb ...
update-alternatives: error: no alternatives for gobby
dpkg: error processing archive /var/cache/apt/archives/gobby_0.5.0-4_amd64.deb 
(--unpack):
 subprocess new pre-installation script returned error exit status 2

MfG
Goswin

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

Versions of packages gobby depends on:
ii  libatkmm-1.6-1 2.22.7-2.1
ii  libavahi-glib1 0.6.31-4+b2
ii  libc6  2.19-13
ii  libgcc11:4.9.2-10
ii  libglib2.0-0   2.42.1-1
ii  libglibmm-2.4-1c2a 2.42.0-1
ii  libgnomevfs2-0 1:2.24.4-6+b1
ii  libgtk2.0-02.24.25-1
ii  libgtkmm-2.4-1c2a  1:2.24.4-1.1
ii  libgtksourceview2.0-0  2.10.5-2
ii  libnet6-1.3-0  1:1.3.14-2
ii  libobby-0.4-1  0.4.8-1
ii  libpangomm-1.4-1   2.34.0-1.1
ii  libsigc++-2.0-0c2a 2.4.0-1
ii  libstdc++6 4.9.2-10
ii  libxml++2.6-2  2.36.0-2.1

gobby recommends no packages.

Versions of packages gobby suggests:
pn  avahi-daemon  none

-- no debconf information


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

Bug#776633: alternative libblas.so.3gf can't be slave of libblas.so.3: it is a master alternative

[Goswin von Brederlow]

Package: libblas3
Version: 1.2.20110419-10
Severity: grave

Updating libblas3 fails with:

Setting up libblas3 (1.2.20110419-10) ...
update-alternatives: error: alternative libblas.so.3gf can't be slave of 
libblas.so.3: it is a master alternative
dpkg: error processing package libblas3 (--configure):
 subprocess installed post-installation script returned error exit status 2

MfG
Goswin

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libblas3 depends on:
ii  libblas-common  1.2.20110419-10
ii  libc6   2.19-13
ii  libgcc1 1:4.9.2-10
ii  libgfortran34.6.2-9
ii  libquadmath04.9.2-10

libblas3 recommends no packages.

libblas3 suggests no packages.

-- no debconf information


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

Bug#776634: alternative liblapack.so.3gf can't be slave of liblapack.so.3: it is a master alternative

[Goswin von Brederlow]

Package: liblapack3
Version: 3.5.0-4
Severity: grave

Updating liblapack3 fails with:

Setting up liblapack3 (3.5.0-4) ...
update-alternatives: error: alternative liblapack.so.3gf can't be slave of 
liblapack.so.3: it is a master alternative
dpkg: error processing package liblapack3 (--configure):
 subprocess installed post-installation script returned error exit status 2

The package used to provide liblapack.so.3gf as master alternative and
never removes it on upgrade. This might also need to break with other
providers of that alternative.

MfG
Goswin

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages liblapack3 depends on:
ii  libblas3 [libblas.so.3]  1.2.20110419-10
ii  libc62.19-13
ii  libgcc1  1:4.9.2-10
ii  libgfortran3 4.6.2-9
ii  libquadmath0 4.9.2-10

liblapack3 recommends no packages.

liblapack3 suggests no packages.

-- no debconf information


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

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

[Goswin von Brederlow]

On Fri, Dec 12, 2014 at 12:10:10AM +, Mark Brown wrote:
 On Thu, Dec 11, 2014 at 08:00:28PM +0100, Goswin von Brederlow wrote:
  On Tue, Dec 09, 2014 at 03:34:43PM +, Mark Brown wrote:
 
   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.
 
  1) What system? The segfault always happens on every system. You simply
  can not change your nis password at all.
 
 The normal thing I've seen is to have people log onto the master server
 (or make some similar arrangement) and make the change there.

I think you can have a setup where nis exports the /etc/passwd of one
master server or something. But at least that isn't the setup we use.
Trying to change the password on the server just gives:

# passwd test
passwd: Authentication token manipulation error
passwd: password unchanged

And normal users aren't allowed to login on the server in any case.
yppasswd is the only way to change a users password here.
 
  2) And it hasn't been a decade. It was reported a bit over a year ago.
 
  3) I first noticed this failing on Ubuntu recently while the nis
  upstream version is indeed been around for ages. It used to work
  previously with near identical version. So unless you changed
  yppasswd.c in one of the debian revisions this probably is triggered
  by a change in the crypt() implementation that is more recent, one
  that validates the salt properly.
 
 There's definitely not been any substantial change in nis for some
 considerable time, the last non-packaging change I'm seeing in the
 changelog is about five years old and is in wheezy.

But that's the thing. yppasswd works fine in wheezy and precise but
segfaults in jessie and trusty.
 
  4 ) This is a security issue so raising the severity is not pointless.
  Users need to be able to change their password. Especially the initial
  one set by the admin on account creation.
 
 It's not clear to me that this is something that has been newly
 introduced (as opposed to something people have always dealt with when
 using NIS, the version mentioned is the one in wheezy) - using shadow
 files with NIS is obviously a bit of a corner case given how meaningless
 NIS makes the extra security they add.  If it's something that's just
 broken in this version and people would see regress on upgrades that's a
 bit different.

It is a regression on upgrade. As said above I think it is a change in
the crypt function that now exposes the bug in nis. Probably been
there for decades but now crypt returns NULL for a 1 character salt.
 
 I could probably go for important but given both the failure mode and
 the fact that it looks like this was an issue on the prior release it
 seems it does more harm than good to remove the package.

Think about the usual use case of nis. You have a number of systems
with an admin staff and a ton of users. Admins create new users, usualy
with some dummy password, and users are supposed to change it when they
first login. Now they can't anymore and are stuck with the dummy
password. At university I had accounts with user: algo17, pass:
algo17. Guess what user/pass the person to my left and right had.
 
  5) There has been a trivial 1 line patch for the bug for the whole
  time.
 
 Right, it's unfortunate that I didn't see that on the original filing
 (looking at the mail it appears it got hidden as a signature by the
 mail client I used to read the original submission, the mail is sadly a
 bit malformed which doesn't help).

MfG
Goswin


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

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

[Goswin von Brederlow]

On Tue, Dec 09, 2014 at 03:34:43PM +, Mark Brown wrote:
 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.

1) What system? The segfault always happens on every system. You simply
can not change your nis password at all.

2) And it hasn't been a decade. It was reported a bit over a year ago.

3) I first noticed this failing on Ubuntu recently while the nis
upstream version is indeed been around for ages. It used to work
previously with near identical version. So unless you changed
yppasswd.c in one of the debian revisions this probably is triggered
by a change in the crypt() implementation that is more recent, one
that validates the salt properly.

4 ) This is a security issue so raising the severity is not pointless.
Users need to be able to change their password. Especially the initial
one set by the admin on account creation.

5) There has been a trivial 1 line patch for the bug for the whole
time.

MfG
Goswin


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

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

[Goswin von Brederlow]

Not being able to change the password is a security problem. Raising severity
to grave.


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

Bug#770028: Please skip to the found bugs when clicking search

[Goswin von Brederlow]

On Wed, Nov 19, 2014 at 08:20:47AM +0100, Christophe Siraut wrote:
 tags -1 moreinfo
 thanks
 
 Hi Goswin,
 
  When I search for bugs on http://udd.debian.org/bugs/ I have to scroll
  quite far down to the search button.
 
 There is another search button/link in the navigation bar, it has the
 same effect and is always reachable.
 
  When I click it the page reloads and is at the begining again. So I
  have to scroll a long way down again to see my search results.
 
 It works fine here. I suppose you have javascript disabled, is it an
 option to enable it? Can you give more information about the browser(s)
 you use?

Yes, I'm using iceweasel with noscript and that is indeed the problem.
Enabling scripts makes it skip down properly. Isn't there a way to
make it go for the #results tag without scripts?
 
  It would be better if the page would load and skip diorectly to the
  results (using the #results tag).
 
 The #results tags is reached using javascript in order to reach the
 right position, after columns.js modifications.
 
 Cheers,
 Christophe

MfG
Goswin


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

Bug#770027: Please add udd.debian.org to other list

[Goswin von Brederlow]

Package: reportbug
Version: 6.5.0
Severity: wishlist

Hi,

I want to report a bug concerning udd.debian.org but the service is
not listed under other. Please add it there. This might need a
pseudo package created on bugs.d.o or something. Please forward the
bug as needed.

MfG
Goswin

-- Package-specific info:
** Environment settings:
EDITOR=xemacs
EMAIL=goswin-...@web.de
INTERFACE=text

** /home/mrvn/.reportbugrc:
reportbug_version 1.99.31
mode expert
ui text
realname Goswin von Brederlow
email goswin-...@web.de
no-cc
header X-Debbugs-CC: goswin-...@web.de

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages reportbug depends on:
ii  apt   1.0.9.1
ii  python2.7.5-5
ii  python-reportbug  6.5.0

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail none
pn  debconf-utils  none
pn  debsumsnone
pn  dlocatenone
ii  emacs23-bin-common 23.4+1-4.1+b1
ii  exim4  4.82-8
ii  exim4-daemon-heavy [mail-transport-agent]  4.82-8
ii  file   1:5.18-1
ii  gnupg  1.4.16-1.1
ii  python-gtk22.24.0-3+b1
pn  python-gtkspellnone
pn  python-urwid   none
pn  python-vte none
ii  xdg-utils  1.1.0~rc1+git20111210-7

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.1
ii  python2.7.5-5
ii  python-debian 0.1.21+nmu2
ii  python-debianbts  1.11
ii  python-support1.0.15

python-reportbug suggests no packages.

-- no debconf information


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

Bug#770028: Please skip to the found bugs when clicking search

[Goswin von Brederlow]

Package: udd.debian.org
Severity: wishlist

When I search for bugs on http://udd.debian.org/bugs/ I have to scroll
quite far down to the search button. When I click it the page reloads
and is at the begining again. So I have to scroll a long way down
again to see my search results.

It would be better if the page would load and skip diorectly to the
results (using the #results tag).

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


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

Bug#768791: Default to 'make -O' for sane output on parallel builds please

[Goswin von Brederlow]

Package: debhelper
Version: 9.20140228
Severity: wishlist

On parallel builds the output from multiple targets gets all mixed up
making them basically impossible to read. In make 4 there is a new
option that helps with this:

   -O[type], --output-sync[=type]
When  running multiple jobs in parallel with -j, ensure the output
of each job is collected together rather  than  interspersed  with
output from other jobs.  If type is not specified or is target the
output from the entire recipe for each target is grouped together.
If  type is line the output from each command line within a recipe
is grouped together.  If type is recurse  output  from  an  entire
recursive  make  is grouped together.  If type is none output syn-
chronization is disabled.

This uses tempfiles to buffer the output so it does use some extra
resources. But anyone doing parallel builds should have enough ram for
the whole output to stay in ram and the overhead to be inconsequential.

Please add -O to the make options in debhelper (if make 4 is used).

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages debhelper depends on:
ii  binutils2.24.51.20140704-1
ii  dpkg1.17.9
ii  dpkg-dev1.17.18
ii  file1:5.18-1
ii  man-db  2.6.7.1-1
ii  perl5.18.2-2+b1
ii  po-debconf  1.0.16+nmu2

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  0.63

-- no debconf information


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

Bug#612447: have the problems been addressed?

[Goswin von Brederlow]

On Mon, Nov 03, 2014 at 09:09:31PM +0100, Tomas Pospisek wrote:
 Hello,
 
 in #612447 [1] you are describing a few problems with the back then new
 design of the Debian page.
 
 I have tried to reproduce them and as far as I can see there have been
 addressed (maybe I didn't understand a few of them?).
 
 Could you please recheck and possibly close the bug report?
 *t
 
 [1] http://bugs.debian.org/612447

Looks fine to me.

MfG
Goswin


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

Bug#766874: @PACKAGE_AND_VERSION@ in manpage

[Goswin von Brederlow]

Package: iptables
Version: 1.4.21-1
Severity: minor
File: /sbin/xtables-multi

The manpage ends in:
   This manual page applies to iptables/ip6tables @PACKAGE_AND_VERSION@.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages iptables depends on:
ii  libc6  2.19-1
ii  libnfnetlink0  1.0.1-3
ii  libxtables10   1.4.21-1

iptables recommends no packages.

iptables suggests no packages.

-- no debconf information


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

Bug#765410: [Pkg-zsh-devel] Bug#765410: ulimit broken if it fails once

[Goswin von Brederlow]

On Wed, Oct 15, 2014 at 10:56:54AM +0200, Axel Beckert wrote:
 Control: tag -1 + confirmed upstream
 Control: retitle -1 zsh: ulimit broken as root if it fails once
 Control: found -1 4.3.17-1
 Control: found -1 5.0.6-3
 Control: found -1 4.3.10-14
 
 Hi Goswin,
 
 thanks for the report.
 
 Goswin von Brederlow wrote:
  Package: zsh
  Version: 5.0.5-2
 
 JFTR: That version is no more anywhere in Debian. Testing has 5.0.6-3.

Earliest I had at hand to test.
 
  root@frosties:~# ulimit -n 1000   
  root@frosties:~# ulimit -n 1000
  limit: setrlimit failed: operation not permitted
  root@frosties:~# ulimit -n 1000   
  limit: setrlimit failed: operation not permitted
  
  Once setting a limit with ulimit fails all further attempts to set a
  limit will also fail. But only in zsh. Works fine in bash.
 
 Interestingly this only happens if zsh is used as root. It does not
 happen if zsh is used as non-root user. Retitling accordingly.
 
 I've found this behaviour in at least Squeeze, Wheezy and Testing/Sid.
 Will test Experimental later today, too. If I find it there, too, I'll
 forward it to upstream.

I believe that as non root there first is a check that the limit is
not raised above the current value. Only root is allowed to do that.
So it fails at a different place, maybe even already in zsh.

MfG
Goswin


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

Bug#765410: ulimit broken if it fails once

[Goswin von Brederlow]

Package: zsh
Version: 5.0.5-2
Severity: normal

root@frosties:~# ulimit -n 1000   
root@frosties:~# ulimit -n 1000
limit: setrlimit failed: operation not permitted
root@frosties:~# ulimit -n 1000   
limit: setrlimit failed: operation not permitted

Once setting a limit with ulimit fails all further attempts to set a
limit will also fail. But only in zsh. Works fine in bash.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages zsh depends on:
ii  libc6   2.19-1
ii  libcap2 1:2.22-1.2
ii  libtinfo5   5.9+20140913-1
ii  zsh-common  5.0.5-2

Versions of packages zsh recommends:
ii  libncursesw5  5.9+20140913-1
ii  libpcre3  1:8.31-5

Versions of packages zsh suggests:
pn  zsh-doc  none

-- debconf information excluded


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

Bug#754567: rtorrent: new upstream release (0.9.4)

[Goswin von Brederlow]

Package: rtorrent
Version: 0.9.2-1
Followup-For: Bug #754567

Version 0.9.4 fixes an incompatibility with utorrent 3.x that causes
chunks to be downloaded and ignored. The effect is that a lot more
data is downloaded than is used and peers stall, not downloading
anything anymore despite them offering.

Please update rtorrent and libtorrent.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages rtorrent depends on:
ii  libc6   2.19-1
ii  libcurl37.38.0-2
ii  libgcc1 1:4.9.0-9
ii  libncursesw55.9+20140913-1
ii  libsigc++-2.0-0c2a  2.2.11-4
ii  libstdc++6  4.9.0-9
ii  libtinfo5   5.9+20140913-1
ii  libtorrent140.13.2-1
ii  libxmlrpc-core-c3   1.33.14-0.1

rtorrent recommends no packages.

Versions of packages rtorrent suggests:
ii  screen  4.2.0-2

-- no debconf information


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

Bug#763757: apt-get: regression in command line parser

[Goswin von Brederlow]

Package: apt
Version: 1.0.1
Severity: normal

The following works in 0.8.16~exp12 but fails in 1.0.1 and later:

mrvn@frosties:~% sudo apt-get install -y -- acl
E: Command line option 'y' [from -y] is not known.

The trigger for this is the --. Please bring support for -- back.

MfG
Goswin

-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt depends on:
ii  debian-archive-keyring  2012.4
ii  gnupg   1.4.16-1.1
ii  libapt-pkg4.12  1.0.9.1
ii  libc6   2.19-1
ii  libgcc1 1:4.9.0-9
ii  libstdc++6  4.9.0-9

apt recommends no packages.

Versions of packages apt suggests:
ii  apt-doc 1.0.2
ii  aptitude0.6.10-1
ii  dpkg-dev1.17.9
pn  python-apt  none

-- no debconf information


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

Bug#763080: Fails to assemble a reshaping raid after disk hickup

[Goswin von Brederlow]

Package: mdadm
Version: 3.3-2
Followup-For: Bug #763080

Hi,

attached a patch to make --force work with my reshaping array. The
problem seems to be that load_devices fills in the best array only for
every second slot (and makes it 4 times as big as needed):

mdadm: best[0] = 0
mdadm: best[1] = -1
mdadm: best[2] = 1
mdadm: best[3] = -1
mdadm: best[4] = 2
mdadm: best[5] = -1
mdadm: best[6] = 3
mdadm: best[7] = -1
mdadm: best[8] = 4
mdadm: best[9] = -1
mdadm: best[10] = 5
mdadm: best[11] = -1
mdadm: best[12] = -1
mdadm: best[13] = -1
mdadm: best[14] = -1
mdadm: best[15] = -1
mdadm: best[16] = -1
mdadm: best[17] = -1
mdadm: best[18] = -1
mdadm: best[19] = -1

And then when force_array only checks up to the number of disks in the
array it misses half of them. In my case exactly those it should be
forcing.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages mdadm depends on:
ii  debconf  1.5.53
ii  initscripts  2.88dsf-53
ii  libc62.19-1
ii  lsb-base 4.1+Debian12
ii  makedev  2.3.1-93
ii  udev 204-10

Versions of packages mdadm recommends:
ii  exim4-daemon-heavy [mail-transport-agent]  4.82-8
ii  module-init-tools  16-2

mdadm suggests no packages.

-- debconf information excluded
Description: Fix --force option for a reshaping array
 On a reshaping array the --force option can't find a suitable drive to
 force because it does not test all the available drives in the best array.
 For some reason only every second entry is filled in and only the first
 half gets tested when going by disk count instead of bestcnt.
 .
 This might also happen with normal arrays, I've only tested it on the one
 broken array I have here.
Author: Goswin von Brederlow goswin-...@web.de

---
--- mdadm-3.3.orig/Assemble.c
+++ mdadm-3.3/Assemble.c
@@ -803,7 +803,7 @@ static int force_array(struct mdinfo *co
 		int chosen_drive = -1;
 		int i;
 
-		for (i = 0; i  content-array.raid_disks  i  bestcnt; i++) {
+		for (i = 0; i  bestcnt; i++) {
 			int j = best[i];
 			if (j=0 
 			!devices[j].uptodate 
@@ -813,8 +813,10 @@ static int force_array(struct mdinfo *co
 			  devices[chosen_drive].i.events))
 chosen_drive = j;
 		}
-		if (chosen_drive  0)
+		if (chosen_drive  0) {
+			pr_err(couldn't choose a drive to force\n);
 			break;
+		}
 		current_events = devices[chosen_drive].i.events;
 	add_another:
 		if (c-verbose = 0)

Bug#763080: Fails to assemble a reshapning raid after disk hickup

[Goswin von Brederlow]

Package: mdadm
Version: 3.3-2
Severity: normal

Hi,

during a raid reshape, growing a raid5 from 5 to 6 disks, the onboard
SATA controler must have crashed taking 2 disks offline. After reboot
the raid did not come back (obviously) and I tried to assemble it
manually:

root@nas1:/root# mdadm -A /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf 
/dev/sda 
mdadm: too-old timestamp on backup-metadata on device-5
mdadm: If you think it is should be safe, try 'export MDADM_GROW_ALLOW_OLD=1'
mdadm: /dev/md0 assembled from 4 drives - not enough to start the array.

root@nas1:/root# MDADM_GROW_ALLOW_OLD=1 mdadm -A /dev/md0 /dev/sdb /dev/sdc 
/dev/sdd /dev/sde /dev/sdf /dev/sda
mdadm: accepting backup with timestamp 1411799455 for array with timestamp 
141184
mdadm: /dev/md0 assembled from 4 drives - not enough to start the array.

root@nas1:/root# MDADM_GROW_ALLOW_OLD=1 mdadm -A --force /dev/md0 /dev/sdb 
/dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sda
mdadm: accepting backup with timestamp 1411799455 for array with timestamp 
141184
mdadm: /dev/md0 assembled from 4 drives - not enough to start the array.

mdadm simply doesn't accept the 2 drives that went offline despite
being told to ignore the timestamp difference.

The raid wasn't being written to during reshape so it should be
perfectly safe to resume. How do I get that raid started again so it
can finish its reshape? 


MfG
Goswin

### mdadm -E /dev/sdb ###
/dev/sdb:
  Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
 Array UUID : 3486be91:bc31bbb5:c10e4570:2530f4e7
   Name : nas1:0  (local to host nas1)
  Creation Time : Tue Sep  9 04:01:34 2014
 Raid Level : raid5
   Raid Devices : 6

 Avail Dev Size : 11721043120 (5589.03 GiB 6001.17 GB)
 Array Size : 29302607360 (27945.14 GiB 30005.87 GB)
  Used Dev Size : 11721042944 (5589.03 GiB 6001.17 GB)
Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1960 sectors, after=176 sectors
  State : clean
Device UUID : cb8c6368:69fabeb3:30e368a0:bb3056f4

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 5280002560 (5035.40 GiB 5406.72 GB)
  Delta Devices : 1 (5-6)

Update Time : Sat Sep 27 17:55:34 2014
  Bad Block Log : 512 entries available at offset 72 sectors
   Checksum : bddf8cdc - correct
 Events : 3922

 Layout : left-symmetric
 Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAA..A ('A' == active, '.' == missing, 'R' == replacing)

### mdadm -E /dev/sdc ###
/dev/sdc:
  Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
 Array UUID : 3486be91:bc31bbb5:c10e4570:2530f4e7
   Name : nas1:0  (local to host nas1)
  Creation Time : Tue Sep  9 04:01:34 2014
 Raid Level : raid5
   Raid Devices : 6

 Avail Dev Size : 11721043120 (5589.03 GiB 6001.17 GB)
 Array Size : 29302607360 (27945.14 GiB 30005.87 GB)
  Used Dev Size : 11721042944 (5589.03 GiB 6001.17 GB)
Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1960 sectors, after=176 sectors
  State : clean
Device UUID : 8d794606:81e23fe3:d75bf196:a32e9b79

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 5280002560 (5035.40 GiB 5406.72 GB)
  Delta Devices : 1 (5-6)

Update Time : Sat Sep 27 17:55:34 2014
  Bad Block Log : 512 entries available at offset 72 sectors
   Checksum : 710d846 - correct
 Events : 3922

 Layout : left-symmetric
 Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAA..A ('A' == active, '.' == missing, 'R' == replacing)

### mdadm -E /dev/sdd ###
/dev/sdd:
  Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
 Array UUID : 3486be91:bc31bbb5:c10e4570:2530f4e7
   Name : nas1:0  (local to host nas1)
  Creation Time : Tue Sep  9 04:01:34 2014
 Raid Level : raid5
   Raid Devices : 6

 Avail Dev Size : 11721043120 (5589.03 GiB 6001.17 GB)
 Array Size : 29302607360 (27945.14 GiB 30005.87 GB)
  Used Dev Size : 11721042944 (5589.03 GiB 6001.17 GB)
Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1960 sectors, after=176 sectors
  State : clean
Device UUID : 2391b641:fc3ded21:d038ce0d:24b56a5c

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 5280002560 (5035.40 GiB 5406.72 GB)
  Delta Devices : 1 (5-6)

Update Time : Sat Sep 27 17:55:34 2014
  Bad Block Log : 512 entries available at offset 72 sectors
   Checksum : dadaaed0 - correct
 Events : 3922

 Layout : left-symmetric
 Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAA..A ('A' == active, '.' == missing, 'R' == replacing)

### mdadm -E /dev/sde ###
/dev/sde:
  Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
 Array UUID : 3486be91:bc31bbb5:c10e4570:2530f4e7
   Name : nas1:0  (local to host nas1)
  Creation Time : Tue Sep  9 

Bug#762923: dhclient-script uses bash, allowing remote bash exploits

[Goswin von Brederlow]

Package: isc-dhcp-client
Version: 4.2.4-7
Severity: normal
File: /sbin/dhclient-script
Tags: security

dhclient puts unchecked strings into environment variables for the
dhclient-script and dhclient-script uses #!/bin/bash. This allows the
recently found bash bugs to be exploited from remote.

There seem to be 2 places where dhclient-script uses bashism:

% checkbashisms /sbin/dhclient-script 
possible bashism in /sbin/dhclient-script line 58 (sourced script with 
arguments):
. $script $@
possible bashism in /sbin/dhclient-script line 181 (should be 'b = a'):
if [ $new_subnet_mask == 255.255.255.255 ]; then

The second one is trivial to fix leaving a single bashism.

Would it be possible to rewrite that in a POSIX sh compatible way?


That would leave the dhclient hook scripts to worry about:

possible bashism in /etc/dhcp3/dhclient-enter-hooks.d/debug line 24 (${!name}):
echo $i=\'${!i}\'  /tmp/dhclient-script.debug

possible bashism in /etc/dhcp3/dhclient-exit-hooks.d/debug line 23 (${!name}):
echo $i=\'${!i}\'  /tmp/dhclient-script.debug

possible bashism in /etc/dhcp3/dhclient-exit-hooks.d/rfc3442-classless-routes 
line 8 (should be 'b = a'):
if [ x$reason == xBOUND ]; then
possible bashism in /etc/dhcp3/dhclient-exit-hooks.d/rfc3442-classless-routes 
line 11 (bash arrays, ${name[0|*|@]}):
for(( i=0; i  ${#rfc_routes[@]}; )); do
+10 more array uses



Given the many eyes now turning towards findings bugs in bash and
building exploits with them it might be safer to fix those bashisms
and switch dhclient-script over to #!/bin/sh.

What do you think?

MfG
Goswin


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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages isc-dhcp-client depends on:
ii  debianutils  4.4
ii  iproute  1:3.14.0-1
ii  isc-dhcp-common  4.2.4-7
ii  libc62.19-1

isc-dhcp-client recommends no packages.

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd  none
pn  resolvconf none

-- no debconf information


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

Bug#762923: dhclient-script uses bash, allowing remote bash exploits

[Goswin von Brederlow]

On Fri, Sep 26, 2014 at 03:53:39PM +0200, Yves-Alexis Perez wrote:
 On Fri, Sep 26, 2014 at 12:47:39PM +0200, Goswin von Brederlow wrote:
  Package: isc-dhcp-client
  Version: 4.2.4-7
  Severity: normal
  File: /sbin/dhclient-script
  Tags: security
  
  dhclient puts unchecked strings into environment variables for the
  dhclient-script and dhclient-script uses #!/bin/bash. This allows the
  recently found bash bugs to be exploited from remote.
  
 [snip]
 
  Given the many eyes now turning towards findings bugs in bash and
  building exploits with them it might be safer to fix those bashisms
  and switch dhclient-script over to #!/bin/sh.
  
  What do you think?
  
 
 Actually, if you go that road, you would need to drop anything ever
 calling python, perl, ruby or whatever language somehow remotely. Some
 scripts might have good reasons to uses bash and bashisms (I'm not
 saying that's the case here, but still).
 
 What I find more concerning is to pass unchecked environment variable
 directly from remote (or any input, actually).
 
 Regards,
 -- 
 Yves-Alexis Perez

Feel free to patch dhclient to sanitize the stgrings before passing
them to the dhclient-script.

MfG
Goswin


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

Bug#743508: libzmq3: upgrading from 3.2.3 to 4.0.4 breaks python-pytango

[Goswin von Brederlow]

Source: zeromq3
Version: 4.0.3
Followup-For: Bug #743508

Hi,

do we realy need a libzmq.so.3 in Jessie? Upstream is preparing a new
stable version now with libzmq.so.4. Given that the breakage between 3
and 4 is minimal (easy to port your software, most just works) do we
need to maintain 2 versions of zeromq?

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


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

Bug#678696: Event based block device handling (fixes USB and nested devices problem)

[Goswin von Brederlow]

On Sun, Aug 31, 2014 at 10:14:18AM +0200, Michael Prokop wrote:
 Hi,
 
 f'up to our recent discussion we had on IRC
 
 * Goswin von Brederlow [Sat Jun 23, 2012 at 09:25:28PM +0200]:
 
  the attached patch adds an event based loop for block devices to the
  init script. New blockdevices are recorded in
  /run/initramfs/block-events by an udev rule as they appear. The init
  script repeadately waits for that and then calls
  /scripts/local-block/* with a list of new devices storedin NEWDEVS
  until $ROOT and $resume (if set) exists or a timeout is reached.
 
  This fixes the problem that USB devices take too long to be
  discovered and crypto, raid, lvm or multipath can't be started on
  them. It also adds support for arbitrary nestings of them, e.g. raid5
  over raid1.
 [...]
 
 First of all thanks again for the patch and your helpful feedback on
 IRC.
 
 I've tested your patch based on top of current i-t git master
 (v0.116) with a setup like:
 
   BOOT_IMAGE=/boot/vmlinuz-3.14-2-amd64 root=/dev/mapper/vg0-root ro quiet
 
 but it sadly fails to work as intended (it boots but doesn't find
 the block devices until the timeout is kicking in). I didn't
 investigate closer yet, but AFAICS it seems to be related to the
 fact that /dev/mapper/vg0-root doesn't exist at that time yet.

If it boots after the timeout then the device must exist. So either
the test for it is wrong or the device only gets created after the
timeout.
 
 If you or someones else finds time to try and possibly further
 investigate I'd very much welcome and appreciate that.
 
 regards,
 -mika-

Questions:

Does your system boot without the patch? If not then you also need the
lvm patch to provide the hook script that scans for a VG when new
block devices are detected.

Do you see any messages about vg0 being activated before the timeout
or after?

MfG
Goswin


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

Bug#758544: nfsdrpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied)

[Goswin von Brederlow]

Package: nfs-kernel-server
Version: 1:1.2.8-9
Severity: important

Updating from wheezy breaks nfs-kernel-server (and updating again
today doesn't fix it):

Do you want to continue? [Y/n] y
Get:1 http://ftp.de.debian.org/debian/ jessie/main nfs-common amd64 1:1.2.8-9 
[206 kB]
Get:2 http://ftp.de.debian.org/debian/ jessie/main nfs-kernel-server amd64 
1:1.2.8-9 [115 kB]
Get:3 http://ftp.de.debian.org/debian/ jessie/main libtirpc1 amd64 0.2.4-2.1 
[77.8 kB]
Fetched 398 kB in 0s (1015 kB/s)   
Reading changelogs... Done
(Reading database ... 59958 files and directories currently installed.)
Preparing to unpack .../nfs-common_1%3a1.2.8-9_amd64.deb ...
Unpacking nfs-common (1:1.2.8-9) over (1:1.2.8-6) ...
Preparing to unpack .../nfs-kernel-server_1%3a1.2.8-9_amd64.deb ...
Unpacking nfs-kernel-server (1:1.2.8-9) over (1:1.2.8-6) ...
Preparing to unpack .../libtirpc1_0.2.4-2.1_amd64.deb ...
Unpacking libtirpc1:amd64 (0.2.4-2.1) over (0.2.3-2) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up libtirpc1:amd64 (0.2.4-2.1) ...
Setting up nfs-common (1:1.2.8-9) ...
insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `nfs-common' 
overrides LSB defaults (S).
[ ok ] Stopping NFS common utilities: idmapd statd.
[ ok ] Starting NFS common utilities: statd idmapd.
Setting up nfs-kernel-server (1:1.2.8-9) ...
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon
[ ok ] Exporting directories for NFS kernel daemon
[] Starting NFS kernel daemon: nfsdrpc.nfsd: writing fd to kernel failed: 
errno 13 (Permission denied)
rpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied)
rpc.nfsd: unable to set any sockets for nfsd
 failed!
Processing triggers for libc-bin (2.19-7) ...


### syslog ###
Aug 18 19:33:28 nas0 kernel: [42001389.592506] RPC: server localhost requires 
stronger authentication.
Aug 18 19:33:28 nas0 kernel: [42001389.592512] svc: failed to register nfsaclv2 
RPC service (errno 13).
Aug 18 19:33:28 nas0 kernel: [42001389.592563] RPC: server localhost requires 
stronger authentication.
Aug 18 19:33:28 nas0 kernel: [42001389.592614] RPC: server localhost requires 
stronger authentication.
Aug 18 19:33:28 nas0 kernel: [42001389.592664] RPC: server localhost requires 
stronger authentication.
Aug 18 19:33:28 nas0 kernel: [42001389.592714] RPC: server localhost requires 
stronger authentication.
Aug 18 19:33:28 nas0 kernel: [42001389.592771] RPC: server localhost requires 
stronger authentication.
Aug 18 19:33:28 nas0 kernel: [42001389.592809] nfsd: last server has exited, 
flushing export cache

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  50566  status
1000241   tcp  56743  status
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=--manage-gids
NEED_SVCGSSD=
RPCSVCGSSDOPTS=
-- /etc/exports --
/mnt/nas0-lva *(rw,fsid=7,no_subtree_check)
/mnt/nas0-p2p *(rw,fsid=6,no_subtree_check)
-- /proc/fs/nfs/exports --
# Version 1.1
# Path Client(Flags) # IPs

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

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-kernel-server depends on:
ii  libblkid1 2.20.1-5.8
ii  libc6 2.19-7
ii  libcap2   1:2.24-4
ii  libsqlite3-0  3.8.5-2
ii  libtirpc1 0.2.4-2.1
ii  libwrap0  7.6.q-25
ii  lsb-base  4.1+Debian13
ii  nfs-common1:1.2.8-9
ii  ucf   3.0030

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information


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

Bug#752507: Hangs in splash screen

[Goswin von Brederlow]

Package: eric
Version: 5.4.3-1
Severity: grave

When I start eric the splash screen opens saying Generating Main
Window... and then nothing else happens.

I've tried pugring eric, deleting all ~/.eric* dirs and reinstalling
but no change.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages eric depends on:
ii  bicyclerepair0.9-6.1
ii  python-chardet   2.2.1-1
ii  python3-pygments 1.6+dfsg-1
ii  python3-pyqt44.10.3+dfsg1-1+b1
ii  python3-pyqt4.qsci   2.8.1-2
ii  python3-pyqt4.qtsql  4.10.3+dfsg1-1+b1

Versions of packages eric recommends:
pn  eric-api-files  none

Versions of packages eric suggests:
ii  pyqt4-dev-tools   4.11+dfsg-1+b1
pn  pyqt5-doc none
ii  python [python-profiler]  2.7.5-5
pn  python-docnone
pn  python-kde4-doc   none
pn  python-qt4-docnone
ii  qt4-designer  4:4.8.6+dfsg-1
ii  qt4-dev-tools 4:4.8.6+dfsg-1
pn  qt4-doc-html  none
pn  qt5-doc   none
pn  ruby  none

-- no debconf information


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

Bug#752527: Upgrading libc6:i386 on amd64 restarts services

[Goswin von Brederlow]

Package: libc6
Version: 2.19-1
Severity: normal

The check for services affected by an upgrade does not consider the package
architecture. So it restarts the 64bit sshd for a 32bit libc upgrade. This
is uneccessarily disruptive to the system.

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6:i386 depends on:
ii  libgcc1  1:4.9.0-1

Versions of packages libc6:i386 recommends:
pn  libc6-i686  none

Versions of packages libc6:i386 suggests:
ii  debconf [debconf-2.0]  1.5.53
pn  glibc-doc  none
ii  locales2.19-1
ii  locales-all [locales]  2.19-1

-- debconf information excluded


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

Bug#749122: ld.so crashes when sections are placed at different addresses

[Goswin von Brederlow]

Package: libc6
Version: 2.18-7
Severity: normal
File: /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Hi,

I want to mmap a large file to 0x1 because the data contains
pointers and was originally at that offset. Mapping somewhere else and
relocating all the pointers is impossible. Unfortunately on amd64
binaries are normaly mapped at 0x0040 and 0x0060a000 onwards,
conflicting with mapping the file. So I tried to link my binary to be
at a different address. But that makes ld.so crash with SIGSEGV or
SIGILL.

--
echo 'int main() { return 0; }' | gcc-4.8 
-Wl,--section-start=.interp=0x7000 -x c -
gdb ./a.out

Program received signal SIGSEGV, Segmentation fault.
dl_main (phdr=phdr@entry=0x6fe00040, phnum=phnum@entry=8, 
user_entry=user_entry@entry=0x7fffe3c8, auxv=optimized out)
at rtld.c:1169
1169rtld.c: No such file or directory.
(gdb) bt
#0  dl_main (phdr=phdr@entry=0x6fe00040, phnum=phnum@entry=8, 
user_entry=user_entry@entry=0x7fffe3c8, auxv=optimized out)
at rtld.c:1169
#1  0x77df2215 in _dl_sysdep_start (
start_argptr=start_argptr@entry=0x7fffe480, 
dl_main=dl_main@entry=0x77dde670 dl_main) at ../elf/dl-sysdep.c:249
#2  0x77de19f6 in _dl_start_final (arg=0x7fffe480) at rtld.c:332
#3  _dl_start (arg=0x7fffe480) at rtld.c:558
#4  0x77dde188 in _start () from /lib64/ld-linux-x86-64.so.2
#5  0x0001 in ?? ()
#6  0x7fffe6fd in ?? ()
#7  0x in ?? ()
--
echo 'int main() { return 0; }' | gcc-4.8 -Wl,--section-start=.interp=0x4 
-x c -
gdb ./a.out 

During startup program terminated with signal SIGKILL, Killed.
(gdb) bt
No stack.
--
Surprisingly the following works again:

echo 'int main() { return 0; }' | gcc-4.8 
-Wl,--section-start=.interp=0x7200 -x c -

The difference seems to be where the section headers are placed in the
output file.

Working:   Start of section headers:  2528 (bytes into file)
Crashing:  Start of section headers:  2099168 (bytes into file)

MfG
Goswin

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6:amd64 depends on:
ii  libgcc1  1:4.9.0-1

libc6:amd64 recommends no packages.

Versions of packages libc6:amd64 suggests:
ii  debconf [debconf-2.0]  1.5.53
pn  glibc-doc  none
ii  locales2.18-5

-- debconf information excluded


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

Bug#745722: Please use distro-info-data to map suits to distributions

[Goswin von Brederlow]

Package: cdebootstrap
Version: 0.5.9
Severity: normal

Hi,

every new release cdebootstrap has to be patched for the new suite.
But there already is a package, distro-info-data, that has a list of
all debian and ubuntu releses that could be used for this.

This would only require 2 small changes to cdebootstrap:

1) add a debian and ubuntu suite to the config. All recent suites
use the same config anyway.

2) The suite given on the command line should be searched for in
/usr/share/distro-info/debian.csv and
/usr/share/distro-info/ubuntu.csv. That then gives a suite-config of
debian or ubuntu depending on which file contains the suite.

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages cdebootstrap depends on:
ii  debian-archive-keyring  2012.4
ii  gpgv1.4.12-4+b1
ii  libbz2-1.0  1.0.6-3
ii  libc6   2.18-4
ii  libdebian-installer-extra4  0.81
ii  libdebian-installer40.81
ii  liblzma55.1.1alpha+20120614-2
ii  wget1.14-2
ii  zlib1g  1:1.2.8.dfsg-1

cdebootstrap recommends no packages.

cdebootstrap suggests no packages.

-- no debconf information


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

Bug#745630: Missing dependency on libdigest-sha1-perl

[Goswin von Brederlow]

Package: ddclient
Version: 3.8.1-1.1
Severity: normal

~% sudo /etc/init.d/ddclient start
[] Starting Dynamic DNS service update utility: ddclient
FATAL:Error loading the Perl module Digest::SHA1 needed for freedns update.
FATAL: On Debian, the package libdigest-sha1-perl must be installed.
 failed!

MfG
Goswin

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

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0]1.5.49  Debian configuration management sy
ii  initscripts  2.88dsf-12  scripts for initializing and shutt
ii  lsb-base 4.1+Debian8 Linux Standard Base 4.1 init scrip
ii  perl [perl5] 5.14.2-21   Larry Wall's Practical Extraction 

Versions of packages ddclient recommends:
ii  libio-socket-ssl-perl 1.76-2 Perl module implementing object or

ddclient suggests no packages.

-- debconf information excluded


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

Bug#745632: PATCH: libdigest-sha1-perl problem

[Goswin von Brederlow]

Package: ddclient
Version: 3.8.1-1.1
Severity: normal
Tags: patch

Hi,

sorry for the second bugreport about this but the BTS seems slow today and
I want to send this before I go home.

libdigst-sha1-perl was in squeeze but was then merged into perl as part
of Digest::SHA (not Digest::SHA1). It is also only used in ddclient with
the freedns protocol. The attached patch tries to open Digest::SHA first,
then tries Digest::SHA1 and gives an error message if that also fails.

MfG
Goswin


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

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0]1.5.49  Debian configuration management sy
ii  initscripts  2.88dsf-12  scripts for initializing and shutt
ii  lsb-base 4.1+Debian8 Linux Standard Base 4.1 init scrip
ii  perl [perl5] 5.14.2-21   Larry Wall's Practical Extraction 

Versions of packages ddclient recommends:
ii  libio-socket-ssl-perl 1.76-2 Perl module implementing object or

ddclient suggests no packages.

-- debconf information excluded
--- ddclient.old	2014-04-23 17:02:21.0 +0200
+++ ddclient	2014-04-23 17:11:24.0 +0200
@@ -1783,14 +1783,21 @@
 ## load_sha1_support
 ##
 sub load_sha1_support {
-my $sha1_loaded = eval {require Digest::SHA1};
-unless ($sha1_loaded) {
-fatal(EOM);
+my $sha1_loaded = eval {require Digest::SHA};
+if ($sha1_loaded) {
+import  Digest::SHA (qw/sha1_hex/);
+} else {
+$sha1_loaded = eval {require Digest::SHA1};
+if ($sha1_loaded) {
+import  Digest::SHA1 (qw/sha1_hex/);
+} else {
+fatal(EOM);
 Error loading the Perl module Digest::SHA1 needed for freedns update.
-On Debian, the package libdigest-sha1-perl must be installed.
+On Debian Squeeze, the package libdigest-sha1-perl must be installed.
+Newer perl versions provide this as part of Digest:SHA.
 EOM
+}
 }
-import  Digest::SHA1 (qw/sha1_hex/);
 }
 ##
 ## geturl

Bug#742033: Support for extended attributes causes errors on ls

[Goswin von Brederlow]

Package: unionfs-fuse
Version: 0.24-2.1
Severity: normal
Tags: patch upstream

Hi,

I've compiled unionfs-fuse with extended attribute support and now I'm
getting errors on ls:

ls -lh union/
ls: union/stats: No such file or directory
total 4.0K
-rw-rw-r-- 1 brederlo users4 Mar 18 14:43 foo
-r--r--r-- 1 root root  2.0K Jan  1  1970 stats

The reason is that the lgetxattr() callback doesn't handle the stats
file. This is simple to fix with the patch below.

MfG
Goswin

--

Index: unionfs-fuse-0.24/src/unionfs.c
===
--- unionfs-fuse-0.24.orig/src/unionfs.c2014-03-18 15:08:54.526796991 
+0100
+++ unionfs-fuse-0.24/src/unionfs.c 2014-03-18 15:09:01.703071796 +0100
@@ -639,6 +639,10 @@
 static int unionfs_getxattr(const char *path, const char *name, char *value, 
size_t size) {
DBG_IN();
 
+   if (uopt.stats_enabled  strcmp(path, STATS_FILENAME) == 0) {
+   return -ENODATA;
+   }
+
int i = find_rorw_branch(path);
if (i == -1) return -errno;
 


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

Bug#737143: Please add patch for module loading

[Goswin von Brederlow]

Package: fuse
Version: 2.9.2-4
Severity: normal
Tags: patch

Hi,

loading modules in fuse filesystems is broken when fuse is compiled
with -O2. Please add the patch for this from the fuse mailinglist:

http://sourceforge.net/mailarchive/forum.php?thread_name=CAB6Q1a8ER1O%2B8NaQEQg7vzaVdNC0EShGO4sbKj%2BbYJVPyeASmw%40mail.gmail.comforum_name=fuse-devel

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages fuse depends on:
ii  adduser   3.113+nmu3
ii  libc6 2.17-92+b1
ii  libfuse2  2.9.0-2+deb7u1
ii  makedev   2.3.1-91
ii  mount 2.20.1-5.1
ii  sed   4.2.1-10
ii  udev  175-7.2

fuse recommends no packages.

fuse suggests no packages.

-- Configuration Files:
/etc/fuse.conf changed [not included]

-- no debconf information


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

Bug#418199: Fwd: Re: segfault with exceedingly long path [origin: schae...@brasslantern.com]

[Goswin von Brederlow]

On Sat, Jan 18, 2014 at 10:19:39AM +0100, Axel Beckert wrote:
 Control: tag -1 + wontfix
 
 Hi,
 
 upstream said, this is an issue which is unlikely ever to be fixed.
 Marking as such.
 
 - Forwarded message from Bart Schaefer schae...@brasslantern.com -
 Date: Fri, 17 Jan 2014 17:49:02 -0800
 From: Bart Schaefer schae...@brasslantern.com
 To: zsh-work...@zsh.org
 Subject: Re: segfault with exceedingly long path
 
 On Jan 18,  1:20am, Axel Beckert wrote:
 }
 } this is a forward of http://bugs.debian.org/418199
 
 This is a known issue and unlikely ever to be fixed.  Various parts
 of the shell rely on system limits such as PATH_MAX which cannot be
 dynamically changed.  There's a comment with some explanation around
 lines 109-137 of Src/compat.c.
 
 The upshot is that if you try hard enough you can always create a path
 that will exceed some limit or other.
 - End forwarded message -
 
 (Online archived at
 http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=32277)
 
   Regards, Axel

Could you fix that in Debian even if upstream doesn't care? A segfault
is never right. If zsh can't handle the long path then it must check
the length and give an error. Not fixing a segfault is imho
unacceptable.

MfG
Goswin


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

Bug#719984: Adding... dialog pops up after every bug making multitasking impossible

[Goswin von Brederlow]

Package: calibre
Version: 0.9.41+dfsg-1
Severity: critical
File: /usr/bin/calibre

Hi,

I'm using calibre for the first time so I'm adding a large number of books
all at once. Given that it takes rather long per book, 5-30s per book, I
would realy like to do something else with my computer while it scans books.
But every time a book is added the Adding... dialog pops to the front
obscuring other windows, stealing the focus (because my mouse happens to be
where the dialog is) and making it impossible to work.

It, at least temporary, breaks the system.

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages calibre depends on:
ii  calibre-bin   0.9.41+dfsg-1
ii  fonts-liberation  1.07.2-7
ii  imagemagick   8:6.7.7.10-2
ii  libjs-mathjax 2.2-1
ii  poppler-utils 0.18.4-3
ii  python-beautifulsoup  3.2.1-1
ii  python-chardet2.0.1-2
ii  python-cherrypy3  3.2.2-2
ii  python-cssselect  0.8-1
ii  python-cssutils   0.9.10~b1-2
ii  python-dateutil   1.5-1
ii  python-dbus   1.2.0-2+b1
ii  python-feedparser 5.1.2-2
ii  python-imaging1.1.7-4
ii  python-lxml   3.2.0-1+b1
ii  python-markdown   2.3.1-1
ii  python-mechanize  1:0.2.5-3
ii  python-netifaces  0.8-2
ii  python-pkg-resources  0.6.49-2
ii  python-pyparsing  1.5.7+dfsg1-2
ii  python-qt44.10.2-2
ii  python-routes 1.13-2
ii  python2.7 2.7.3-1
ii  xdg-utils 1.1.0~rc1+git20111210-6

Versions of packages calibre recommends:
pn  python-dnspython  none

calibre suggests no packages.

-- no debconf information


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

Bug#719997: Adding duplicate books should allow merging

[Goswin von Brederlow]

Package: calibre
Version: 0.9.41+dfsg-1
Severity: wishlist

Hi,

when I add books sometimes I get a duplicate. But, for example, the
existing book is in mobi format while the new book is in epub format.
Now the only option are to create a duplicate book or to skip the new
one.

Instead I would like to merge the new format into the existing book.
Please add an option for that.

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages calibre depends on:
ii  calibre-bin   0.9.41+dfsg-1
ii  fonts-liberation  1.07.2-7
ii  imagemagick   8:6.7.7.10-2
ii  libjs-mathjax 2.2-1
ii  poppler-utils 0.18.4-3
ii  python-beautifulsoup  3.2.1-1
ii  python-chardet2.0.1-2
ii  python-cherrypy3  3.2.2-2
ii  python-cssselect  0.8-1
ii  python-cssutils   0.9.10~b1-2
ii  python-dateutil   1.5-1
ii  python-dbus   1.2.0-2+b1
ii  python-feedparser 5.1.2-2
ii  python-imaging1.1.7-4
ii  python-lxml   3.2.0-1+b1
ii  python-markdown   2.3.1-1
ii  python-mechanize  1:0.2.5-3
ii  python-netifaces  0.8-2
ii  python-pkg-resources  0.6.49-2
ii  python-pyparsing  1.5.7+dfsg1-2
ii  python-qt44.10.2-2
ii  python-routes 1.13-2
ii  python2.7 2.7.3-1
ii  xdg-utils 1.1.0~rc1+git20111210-6

Versions of packages calibre recommends:
pn  python-dnspython  none

calibre suggests no packages.

-- no debconf information


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

Bug#719607: [dch]: Ignored DEBFULLNAME, NAME, DEBEMAIL, EMAIL when -m is used

[Goswin von Brederlow]

Package: devscripts
Version: 2.12.6+ql.1
Severity: normal
File: /usr/bin/debchange

Calling

DEBFULLNAME=foo dch -i

uses foo as name in the changelog entry. BUT

DEBFULLNAME=foo dch -i -m bla

uses the current user name.

MfG
Goswin

-- Package-specific info:

--- /etc/devscripts.conf ---
DEBUILD_CHANGES_SUFFIX=wheezy

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: 7.1
Architecture: amd64 (x86_64)

Kernel: Linux 3.5.0-27-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages devscripts depends on:
ii  dpkg-dev  1.16.10+ql.1
ii  libc6 2.13-38
ii  perl  5.14.2-21
ii  python2.7.3-4

Versions of packages devscripts recommends:
ii  at3.1.13-2
ii  dctrl-tools   2.22.2
ii  debian-keyring2013.04.21
ii  dput  0.9.6.3+nmu2
ii  equivs2.0.9
ii  fakeroot  1.18.4-2
ii  gnupg 1.4.12-7+deb7u1
ii  libcrypt-ssleay-perl  0.58-1
ii  libdistro-info-perl   0.10
ii  libjson-perl  2.53-1
ii  libparse-debcontrol-perl  2.005-3
ii  libsoap-lite-perl 0.714-1
ii  liburi-perl   1.60-1
ii  libwww-perl   6.04-1
ii  lintian   2.5.10.4
ii  man-db2.6.2-1
ii  patch 2.6.1-3
ii  patchutils0.3.2-1.1
ii  python-debian 0.1.21
ii  python-magic  5.11-2
ii  sensible-utils0.0.7
ii  strace4.5.20-2.3
ii  unzip 6.0-8
ii  wdiff 1.1.2-1
ii  wget  1.13.4-3
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages devscripts suggests:
ii  build-essential  11.5
pn  cvs-buildpackage none
pn  devscripts-elnone
pn  gnuplot  none
ii  heirloom-mailx [mailx]   12.5-2
pn  libauthen-sasl-perl  none
ii  libfile-desktopentry-perl0.04-3
pn  libnet-smtp-ssl-perl none
ii  libterm-size-perl0.207-1
ii  libtimedate-perl 1.2000-1
pn  libyaml-syck-perlnone
pn  mutt none
ii  openssh-client [ssh-client]  1:6.0p1-4
pn  svn-buildpackage none
pn  w3m  none

-- no debconf information


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

Bug#716860: [Pkg-ia32-libs-maintainers] Bug#716860: Info received ( Bug#716860: I have the same issue)

[Goswin von Brederlow]

On Fri, Jul 26, 2013 at 08:23:32AM +0200, Rafa?? Pietrak wrote:
 The core library (e.g. libc6) installed correctly, but I think,
 the new multiarch set of packages is still missing something:
 
 root@defaultvps:/opt/firebird# apt-get install libncurses5
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 libncurses5 is already the newest version.
 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 root@defaultvps:/opt/firebird# find /lib  /usr/lib/ -name 'libncurs*'
 /lib/x86_64-linux-gnu/libncurses.so.5
 /lib/x86_64-linux-gnu/libncursesw.so.5.9
 /lib/x86_64-linux-gnu/libncursesw.so.5
 /lib/x86_64-linux-gnu/libncurses.so.5.9
 root@defaultvps:/opt/firebird# find /lib  /usr/lib/ -name 'libpthre*'
 /lib/x86_64-linux-gnu/libpthread.so.0
 /lib/x86_64-linux-gnu/libpthread-2.13.so
 /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
 /lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so
 /lib/i386-linux-gnu/libpthread.so.0
 /lib/i386-linux-gnu/libpthread-2.13.so
 --
 
 meaning:
 1. libncurses reports as installed

libncurses:amd64 is installed but not libncurses:i386.

http://packages.debian.org/search?searchon=contentskeywords=libncurses.so.5mode=pathsuite=stablearch=any

libncurses is fully multiarch. The old lib32ncurses 5 and lib64ncurses5 are
just there for gcc on non-multiarch systems. Please ignore them.

 2. while there is no i386-linux-gnu variant of it.
 
 I've installed the libncursesw5:i386 package, but that does not
 provide not-W variant of the library:
 ---
 root@defaultvps:/opt/firebird# find /lib  /usr/lib/ -name 'libncurs*'
 /lib/x86_64-linux-gnu/libncurses.so.5
 /lib/x86_64-linux-gnu/libncursesw.so.5.9
 /lib/x86_64-linux-gnu/libncursesw.so.5
 /lib/x86_64-linux-gnu/libncurses.so.5.9
 /lib/i386-linux-gnu/libncursesw.so.5.9
 /lib/i386-linux-gnu/libncursesw.so.5
 root@defaultvps:/opt/firebird# /opt/firebird/bin/fbmgr.bin -shut
 /opt/firebird/bin/fbmgr.bin: error while loading shared libraries:
 libncurses.so.5: cannot open shared object file: No such file or
 directory
 -
 
 So something is still missing from packages set of the new
 multiarch-framework. (pls. note that there *is* a not-W variant of
 the library for x86_64 architecture).
 
 Does this qualify as an actual bug in the new framework  or it's
 already resolved by some other package, which I'm still missing?
 
 -R

Libncurses was never part of ia32-libs so this isn't a regression on
the part of ia32-libs. And libncurses5:i386 is there. If you had
installed a debian package instead of installing firebird manually apt
would have pulled in the require lib. But with manual installs you
have to install the dependencies yourself.

MfG
Goswin


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

Bug#717288: Debian Description Translation Project links are dead

[Goswin von Brederlow]

Package: www.debian.org
Severity: normal

Hi,

the links to the Debian Description Translation Project
(http://ddtp.debian.net/) on

http://www.debian.org/international/l10n/ddtp

are dead. This could be a server outage or something worse (hopefully
not). Anyone know what the status of the DDTP server is?

MfG
Goswin

PS: If there is a better package to address this outage please forward
this bug there.


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

Bug#716871: Sdlevent.MOUSEBUTTONDOWN reports buttons 1-off causing segfaults on wheeldown

[Goswin von Brederlow]

Package: ocamlsdl
Version: 0.9.0-1
Severity: normal
Tags: patch

I noticed that in MOUSEBUTTONDOWN and MOUSEBUTTONUP events the wrong button
is reported. The problem is that SDL starts counting at 1 but the ocaml
type starts at 0. This further causes segfaults when trying to process a
wheel down event since that int is outside the range allowed for mbe_button.

Patch to correct the one-off error attached.

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Description: Fix value_of_mouse_button()
 SDL numbers buttons starting at 1 while the ocaml variant starts at 0.
 This causes the left button to be reported as middle, middle as right
 and so on. Wheeldown finaly returns an invalid value causing segfaults
 on use.
Author: Goswin von Brederlow goswin-...@web.de
Bug-Debian: http://bugs.debian.org/bugnumber
Last-Update: 2013-07-13

---

--- ocamlsdl-0.9.0.orig/src/sdlevent_stub.c
+++ ocamlsdl-0.9.0/src/sdlevent_stub.c
@@ -114,10 +114,10 @@ static value value_of_mouse_button(Uint8
 {
   value r;
   if (SDL_BUTTON_LEFT = b  b = SDL_BUTTON_WHEELDOWN)
-r = Val_int(b);
+r = Val_int(b - 1);
   else {
 r = caml_alloc_small(1, 0);
-Field(r, 0) = Val_int(b);
+Field(r, 0) = Val_int(b - 1);
   }
   return r;
 }

Bug#656719: Please provide xvmc and vdpau Gallium3D video acceleration drivers (libg3dvl-mesa package)

[Goswin von Brederlow]

Package: mesa
Version: 9.1.4
Followup-For: Bug #656719

The dependency on linux-firmware-nonfree should be firmware-linux-nonfree
instead.

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


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

Bug#716728: E: Invalid_argument(String.create)

[Goswin von Brederlow]

Package: oasis
Version: 0.3.0-2
Severity: normal

When I try to use oasis with my project I get the following error:

mrvn@frosties:~/src/lightspeed% oasis setup
Raised by primitive operation at file string.ml, line 31, characters 2-26
Called from file src/oasis/OASISRecDescParser.ml, line 404, characters 29-49
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 355, characters 23-47
Re-raised at file src/oasis/OASISRecDescParser.ml, line 365, characters 17-29
Called from file src/oasis/OASISRecDescParser.ml, line 83, characters 11-18
Called from file list.ml, line 86, characters 24-34
Called from file src/oasis/OASISRecDescParser.ml, line 138, characters 4-11877
Called from file src/oasis/OASISAst.ml, line 38, characters 4-57
Called from file src/oasis/OASISParse.ml, line 33, characters 4-49
Called from file src/cli/Setup.ml, line 70, characters 6-95
Called from file src/cli/Setup.ml, line 62, characters 4-312
Called from file src/cli/Main.ml, line 61, characters 6-13
E: Invalid_argument(String.create)

I've added some printf debugging to the source around
OASISRecDescParser.ml, line 404 showing me this:

diff = 0, lvl =14, lvl_ref = 14, str = (C) 2012 Goswin von Brederlow
diff = 0, lvl =2, lvl_ref = 2, str = Game in the style of the Master of Orion 
but with the speed of light
diff = 0, lvl =2, lvl_ref = 2, str = introducing a time lag for distant star 
systems.
diff = -1, lvl =1, lvl_ref = 2, str = 

The problem seems to be a line with justafter the description. So my
_oasis file is buggy but it would be nice to get an error from the parser.
For testing purposes here a shortened version of my _oasis file:

--
OASISFormat:  0.1
Name: lightspeed
Version:  0.0.0
#LicenseFile:  ?
License:  GPL-3+ with OCaml linking exception
Authors:  Goswin von Brederlow goswin-...@web.de
Copyrights:
  (C) 2012 Goswin von Brederlow
#Homepage: http://???/
BuildTools:   ocamlbuild
Plugins:  DevFiles (0.2), META (0.2)

Synopsis: Turn based strategy game in a galaxy with lightspeed limit
Description:
  Game in the style of the Master of Orion but with the speed of light
  introducing a time lag for distant star systems.
  
Flag strict
  Description: Strict compile-time checks
  Default: true

Executable server
  Path: .
  Install: true
  CompiledObject: best
  MainIs: server.ml
  BuildDepends: bigarray, extunix, unix
--

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages oasis depends on:
ii  libfindlib-ocaml [libfindlib-ocaml-ozcu3]  1.3.3-1
ii  liboasis-ocaml [liboasis-ocaml-yvun8]  0.3.0-2+ocaml4
ii  liboasis-ocaml-dev 0.3.0-2+ocaml4
ii  libodn-ocaml [libodn-ocaml-gzti0]  0.0.9-1+ocaml4
ii  ocaml-base-nox [ocaml-base-nox-4.00.1] 4.00.1-1

oasis recommends no packages.

Versions of packages oasis suggests:
ii  liboasis-ocaml-doc  0.3.0-2+ocaml4

-- no debconf information


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

Bug#710336: Please drop -O3

[Goswin von Brederlow]

-O3 should be used sparingly and selectively only for code that actualy
benefits from it. In general -O3 often generates slower and bigger code and
sometimes buggy code.

MfG
Goswin


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

Bug#706989: Please add support for Ubuntu saucy

[Goswin von Brederlow]

On Mon, May 06, 2013 at 10:52:30AM -0600, Adam Conrad wrote:
 Package: debootstrap
 Version: 1.0.49
 Severity: normal
 
 Subject says it all, really.  Please add support for saucy, by adding
 it as a symlink to gutsy, like previous Ubuntu releases.
 
 Thanks,
 
 ... Adam

Please don't do it that way.

That most (all?) release are links to the same config shows that there
isn't a need for individual configs for each codename. Instead any
Ubuntu release that doesn't have a specific config should fall back to
a default ubuntu config.

Similary any Debian release should have a fallback to a default Debian
config.

That way debootstrap wouldn't need an update every time a new codename
is added and wouldn't need backports jsut to add a single link.

MfG
Goswin


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

Bug#671720: economy options are ignored by some buildings

[Goswin von Brederlow]

Hi,

maybe I misunderstood how the economy options are supposed to work. From what
you wrote it sounds like a building will stop producing output if the output
has reached the target goal but the input has not. But if both the output
and input have reached the target goal the building will start producing again?

MfG
Goswin


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

Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

[Goswin von Brederlow]

On Thu, Apr 25, 2013 at 07:09:04PM +0200, Alessandro Ghedini wrote:
 On gio, apr 25, 2013 at 06:36:39 +0200, Julian Taylor wrote:
  On 25.04.2013 18:01, Alessandro Ghedini wrote:
   * Package name: libzmq-libzmq2-perl
 Version : 1.07
 Upstream Author : Daisuke Maki dais...@endeworks.jp
   * URL : https://metacpan.org/release/ZMQ-LibZMQ2/
   * License : Artistic or GPL-1+
 Programming Lang: Perl
 Description : Perl bindings to the libzmq 2.x library
  
   [...]
 
  what is the difference to libzeromq-perl that we already have in unstable?
 
 The ZeroMQ module (libzeromq-perl) is deprecated in favour of ZMQ::LibZMQ2
 (libzmq-libzmq2-perl), ZMQ::LibZMQ3 and ZMQ. My intention would be to have
 libzeromq-perl removed at some point soon (this is why it's not in wheezy, 
 also
 see #690680) but it's been taking me a long time (mostly because of a lack of
 free time from my part).
 
 Cheers

So is this a rename of the old package, a fork using the new namespace
or a rewrite?

MfG
Goswin


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

Bug#706063: btrfs-convert: missing --verbose or --progress option

[Goswin von Brederlow]

Package: btrfs-tools
Version: 0.19+20120328-7.1
Severity: wishlist

Hi,

btrfs-convert takes a long time creating metadata. Wouldn't it be
possible to give a progress every few seconds? E.g. converting inode
123/456789 ... or similar?

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


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

Bug#706064: btrfs-convert: multi-core support wanted

[Goswin von Brederlow]

Package: btrfs-tools
Version: 0.19+20120328-7.1
Severity: wishlist

Hi,

according to top the btrfs-convert is cpu bound on my system:

  PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND
 5784 root  20   0  307m 295m  868 R  99.6 10.2  13:34.00 btrfs-convert

But it uses only about half the possible disk IO. Using multiple cores
could multiply its speed.

MfG
Goswin

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


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

Bug#705879: moreinfo

[Goswin von Brederlow]

On Tue, Apr 23, 2013 at 12:09:49AM +1000, Dmitry Smirnov wrote:
 On Mon, 22 Apr 2013 17:50:37 Holger Levsen wrote:
  ah! thanks for summarizing why this is not a bug, but rather a feature 
  (UUIDs 
  for partitions) made for this situation not being used!
 
 For the record about a year ago when I tried to use UUID for
 external journal on ext4 it didn't work because (I think) it was not
 implemented.
 Probably it still doesn't work although I could miss something in recent
 changelogs.
 
 Although UUID is very useful for partitions I didn't mention UUID because I
 knew it wouldn't work for ext4 external journal.
 
 
  see eg http://wiki.debian.org/Part-UUID or debian-u...@lists.debian.org for 
  more info.
 
 Thanks for the link.
 
 Cheers,
  Dmitry Smirnov
  GPG key : 4096R/53968D1B

If UUID doesn't work then I think you are left with LVM as the only
option to get a reliable device name.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130423125219.GD26534@frosties


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

Bug#704277: receive should move files within a filesystem

[Goswin von Brederlow]

Package: sendfile
Version: 2.1b.20080616-5.2
Severity: wishlist
File: /usr/bin/receive

My spool directory is on the same filesystem as the current dir. But still
receive copies files instead of simply moving them.

MfG
Goswin

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

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages sendfile depends on:
ii  libc6  2.11.2-6+squeeze1 Embedded GNU C Library: Shared lib
ii  libdpkg-perl   1.16.10   Dpkg perl modules
ii  libreadline6   6.1-3 GNU readline and history libraries
ii  openbsd-inetd [inet-su 0.20091229-2  OpenBSD Internet Superserver
ii  perl [perl5]   5.14.2-12 Larry Wall's Practical Extraction 
ii  update-inetd   4.43  inetd configuration file updater

sendfile recommends no packages.

Versions of packages sendfile suggests:
pn  pgp-i none (no description available)

-- Configuration Files:
/etc/sendfile.cf changed [not included]

-- no debconf information


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

Bug#700818: [Pkg-ia32-libs-maintainers] Bug#700818: Bug#700818: ia32-libs: not installable

[Goswin von Brederlow]

On Mon, Feb 18, 2013 at 09:28:53AM +0100, Thijs Kinkhorst wrote:
 Hi Lucas,
 
 On Sun, February 17, 2013 22:07, Lucas Nussbaum wrote:
  While testing the installation of all packages in wheezy, I ran
  into the following problem:
 
  The following packages have unmet dependencies:
  ia32-libs : Depends: ia32-libs-i386 but it is not installable
  E: Unable to correct problems, you have held broken packages.
 
 This is documented in the release notes:
 http://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.en.html#ia32libs
 
 Does it work for you when following those teps?
 
 
 Cheers,
 Thijs

It is also mentioned in the package description. Is there something
that would make it clearer without overly bloating the long
description?

MfG
Goswin


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

Bug#698945: [Pkg-ia32-libs-maintainers] Bug#698945: ia32-libs(20120926) works - ia32-libs1.0:4 does not !

[Goswin von Brederlow]

On Mon, Jan 28, 2013 at 09:51:02AM +, Holger Weiss wrote:
 
 
 Hi,
 I see that I have a hard time to understand the new multiarch 
 usage/architecture. I searche the web for some information about it, but did 
 not find good descriptions.
 Previously, the /usr/lib32 contained all 32-bit libs.
 I think I need a liitle support from you to understand the new multiarch:

Under multiarch libraries are located under

/usr/lib/$(DEB_HOST_MULTIARCH)/

on all archs. There is no special casing of lib32, libn32, libo32 or
lib64 for some archs anymore. The i386 package of a library can
therefore be used on amd64 as well while previously it had to be
recompiled to use /usr/lib32. DEB_HOST_MULTIARCH is mostly identical
to the GNU triplet for the architecture, except where that isn't
unique enough. For i386 packages libraries are found under

/usr/lib/i486-linux-gnu/

Since libraries are usualy loaded by the dynamic linker and that knows
about the new location the location change is usualy transparent to
the program. But since you need to fix your symlink hack you have to
know about it.
 
 Ia32-libs is only a transitional meta package. You shouldn't need that
 at all. What you need are the 32bit libraries that ADS2012 requires.
 The simplest would be to simply install an ADS2012 debian package for
 i386.
 
 
 
 That does not exist ! Its a proprietary installer using java.

I would recommend creating at least a dummy package with the right
dependencies using equivs to ensure you have the right libraries
installed and that they stay installed.

Or to make it simpler to install it next time on a different system.
 
  If that doesn't exist then you need to install the i386 package
 for required libraries. You can do that under multiarch by appending
 :i386 to the package name.
 
 
 
 
 What do you mean with using multiarch ? Is this a special program ?
 So far I understood, that multiarch is just a package containing libraries 
 only ?
 Can you give me a short example please.

apt-get install libmotif4:i386 
 
 Debian does not have a libXm.so.3 at all, only libXm.so.2 and libXm.so.4,
 which are in lesstif2 and libmotif4 respectively.
 
 MfG
 Goswin
 
 
 That is correct, but so far a symbolic link to the existing libs made it work 
 !
 
 
 
 Lets get the problem solved  - I will be online !
 

MfG
Goswin


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

Bug#698945: [Pkg-ia32-libs-maintainers] Bug#698945: The working settings on machine 1

[Goswin von Brederlow]

On Mon, Jan 28, 2013 at 11:05:34AM +, Holger Weiss wrote:
 
 
 Debian does not have a libXm.so.3 at all, only libXm.so.2 and libXm.so.4,
 which are in lesstif2 and libmotif4 respectively.
 
 
 
 I understand, that using multiarch is refering to apt-get and can be used 
 as apt-get install package:arch .
 Here is what happens with multiarch:
 
 # dpkg --print-foreign-architectures
 i386
 # dpkg --print-architecture
 amd64
 # apt-get install libmotif4:i386
 .
 Die folgenden Pakete werden ENTFERNT: (removed)
   libmotif4
 Die folgenden NEUEN Pakete werden installiert: (installed)
   libmotif4:i386
 0 aktualisiert, 1 neu installiert, 1 zu entfernen und 24 nicht aktualisiert.
 Es müssen noch 0 B von 1.332 kB an Archiven heruntergeladen werden.
 Nach dieser Operation werden 602 kB Plattenplatz freigegeben.
 Möchten Sie fortfahren [J/n]?
 
 I cannot have both versions i386 and amd64 libs at the same time on my 
 system, is this correct ?

That is correct. libmotif4 has not been multiarchified, which means it
has not been changed so that libmotif4:amd64 and libmotif4:i386 can be
installed in parallel. You have to pick one or the other until it is.

That also means all package depending on libmotif4 need to be either
all i386 or all amd64. But in you case that seems to be only your 3rd
party 32bit program. So there is no problem with having only
libmotif4:i386.

MfG
Goswin


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

Bug#698945: [Pkg-ia32-libs-maintainers] Bug#698945: ia32-libs(20120926) works - ia32-libs1.0:4 does not !

[Goswin von Brederlow]

On Fri, Jan 25, 2013 at 03:14:57PM +, Holger Weiss wrote:
 
 Package: ia32-libs
 Version: 1:0.4
 Severity: important
 
 Dear Maintainer,
 I have 2 machine with identical hardware: machine1 and machine2, both with the
 Debian wheezy amd64 release.
 
 Machine1 got the last update in October 2012 and it is using ia32-libs
 Version 20120926. On this machine the software works !
 
 Machine 2 was reinstalled 2 days ago and uses ia32-libs in Version 1:0.4.
 This machine shows the error:
 hpeesofhelp: error while loading shared libraries: libXm.so.3: wrong ELF
 class: ELFCLASS64
 Gemx error, error code = 11

Did you link the 64bit libXm instead of the 32bit one?
 
 On both machines I need to run the software which is using both 32bit and 
 64bit
 libmotif libs. Especially the libXm.so.3 (I had to create a symbolic link
 to libXm.so.4 on both machines to make it work, because the file did not
 exist!).
 
 I also found that the folder /usr/lib32 doesnot exist on machine 2 !
 
 I expected the software to work as smooth as on machine 1.
 
 Is there any significant change in handling the ia32-libs between this
 versions ?

Ia32-libs uses multiarch now.
 
 How can I make my software working with ia32-libs (1:0.4) ?
 
 The software I am using is ADS2012 (and ADS2011) from Agilent.

Ia32-libs is only a transitional meta package. You shouldn't need that
at all. What you need are the 32bit libraries that ADS2012 requires.
The simplest would be to simply install an ADS2012 debian package for
i386. If that doesn't exist then you need to install the i386 package
for required libraries. You can do that under multiarch by appending
:i386 to the package name.

MfG
Goswin


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