Bug#710924: bug still exists

[Michael Vogt]

On Sun, Sep 28, 2014 at 11:21:29AM +0800, 積丹尼 Dan Jacobson wrote:
> # aptitude update
[..]
> Err http://ftp.tw.debian.org experimental/main i386 Packages
>   406  Not Acceptable
> Err http://ftp.tw.debian.org experimental/contrib i386 Packages
[..]
> E: Some index files failed to download. They have been ignored, or old ones 
> used instead.
> E: Couldn't rebuild package cache

Thanks for your bugreport. What version of apt are you using? And how
can we reproduce it (i.e. is using your sources.list enough in a clean
chroot, does that trigger the bug for you as well?).

Thanks,
 michael 


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

Bug#762689: [Pkg-bluetooth-maintainers] Bug#762689: missing bluez-alsa package in unstable (arch i386, amd64)

[Nobuhiro Iwamatsu]

Hi,

Thanks for your report.

bluez already not support ALSA plugins.
And Bluez5 is only supported by Pulseaudio, and support ALSA.

If you want to sound over bluetooth, please use pulseaudio base.

Best regards,
  Nobuhiro


2014-09-24 21:21 GMT+09:00 Milan Kocian :
> Package: bluez-alsa
>
> Hello,
>
> is there any valid reason for absence of this package in unstable
> (archs i386, amd64) ? I lacking libasound_module_pcm_bluetooth.so library:
>
> $ aplay -D btheadset test.wav
> ALSA lib dlmisc.c:252:(snd1_dlobj_cache_get) Cannot open shared library 
> /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_bluetooth.so
> aplay: main:722: audio open error: No such device or address
>
>
> Many thanks for reply.
>
> Best regards,
>
> --
> Milan Kocian
>
> ___
> Pkg-bluetooth-maintainers mailing list
> pkg-bluetooth-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bluetooth-maintainers



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


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

[Michael Tokarev]

29.09.2014 06:56, NeilBrown wrote:
> On Sun, 28 Sep 2014 17:52:52 +0200 Goswin von Brederlow 
> wrote:
> 
> 
>> 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.
> 
> This is fixed by upstream patch
> 
> commit f81a2b56c4b437f66aaf5582a9c6b7f5ab2103c4
> Author: NeilBrown 
> Date:   Tue Oct 22 09:55:04 2013 +1100
> 
> Assembe: fix bug in force_array - it wasn't forcing properly.
> 
> which is in mdadm-3.3.1.

Ow.  I overlooked this.  Thank you Neil for pointing it out.

I've 3.3.2 (with some more changes) ready to be releases in debian,
but I'm afraid it will be difficult due to udeb freeze.  Let's see...

Thanks,

/mjt


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

[Michael Tokarev]

Control: severity -1 important
[]
> Ow.  I overlooked this.  Thank you Neil for pointing it out.
> 
> I've 3.3.2 (with some more changes) ready to be releases in debian,
> but I'm afraid it will be difficult due to udeb freeze.  Let's see...

And since this bug has a good potential to make your system unbootable,
I'm raising severity - probably should be raised even higher than
'important'...

Thanks,

/mjt


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

Bug#761042: libgit2: SSH-enabled build.

[Dmitry Smirnov]

Now it should be safe to enable SSH support in libgit2. Thanks.

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


signature.asc
Description: This is a digitally signed message part.

Bug#763308: Acknowledgement (Cannot tune volume anymore in system tray)

[Erwan David]

Sorry, it was only a problem of dead kded... AFter relogin it now works.

The bug may be closed.

   


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

Bug#763058: nmu: doxygen_1.8.7-3

[Julien Cristau]

On Mon, Sep 29, 2014 at 02:26:11 +0100, Steven Chamberlain wrote:

> So AIUI Sylvestre needs to remove that symlink in a new upload, but
> all reverse-deps must be NMUd to use the new, versioned library name
> e.g. libclang-3.5.so.1.  Except I think the package name needs to be
> changed in order to do that, so perhaps a soname bump to
> libclang-3.5.so.2 provided by libclang2-3.5?
> 
I don't think the package name and SONAME changes are necessary;
libclang-3.5.so.1 is unambiguous, and libclang1-3.5 is not in wheezy.

But that's still assuming the ABIs are different, so I'll wait for
confirmation on that before doing anything else.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#756593: busybox's switch_root makes read-only NFS root read/write

[Michael Tokarev]

[Rehashing a somewhat old thread...]
08.08.2014 14:55, Zimmermann, Alexander wrote:

> So here is the full output. Vanilla Linux 3.16. No patches. There is 
> definitely something
> broken in the userland. I will set up a new image via debootstrap next week.

So, Alexander, did you succeed in finding what turns your root
read-write?  Since you confirm the bug is not in busybox, I'm
about to close this bugreport, or maybe we should reassign it
to some other package instead, because it contains quite some
useful debugging information and it'd be sad if this info will
be lost...

I still can't reproduce the problem you describe.

Thanks,

/mjt


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

Bug#730059: busybox-syslogd conflicts with systemd

[Michael Tokarev]

Control: tag -1 - moreinfo + wontfix
11.09.2014 09:49, Trent W. Buck wrote:
> In fact busybox-syslogd is the *only* package with
>   Provides: klogd
> the others seem to
>  Provides: linux-kernel-log-daemon
> 
> I don't understand why this is the case.
> Does the difference signify a different interface,
> or is it just an oversight?
> 
> The point is probably moot since journalctl replaces it, but couldn't
> the busybox-syslogd init script say "if pid1 is systemd, start syslogd
> but not klogd" ?

It is not the init script, it is the busybox syslog implementation.
For simplicity, it is one applet that does both syslog function and
klogd function, and klogd function is not optional.  In order to
stop providing klogd, someone should write a patch for busybox
(upstream, because I for one don't want to make debian-specific
changes to busybox) to make klogd function optional, after which
it will be possible to adjust initscript to run syslogd without
klogd if systemd is running.

Tagging as wontfix for now.

Thanks,

/mjt


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

Bug#761807: libvirt-bin: No PCI buses available on qemu-system-arm

[Guido Günther]

On Tue, Sep 16, 2014 at 07:06:13PM +0400, Илья Русьянов wrote:
> I think this one could be closed, or changed because the problem is not
> connected with the particular version of libvirt and affects only restore
> feature of the library. Here's bug report to upstream
> https://bugzilla.redhat.com/show_bug.cgi?id=1142288

As far as I read this the problem isn't related to the update but to
saving/restoring arm based VMs? Can you reproduce this 100% of the time?

Is the image referenced in you configuration the officially available
rasberrian image?

Cheers,
 -- Guido


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

Bug#731441: nmu for xutlis-dev

[Julien Cristau]

On Mon, Sep 29, 2014 at 08:19:14 +0200, Julien Cristau wrote:

> So I'd like not to carry yet another patch.  Has this, or a similar
> patch, been forwarded to xorg-devel?
> 
And, would it be enough to define SharedXpLibrary NO in a
Debian-specific section?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#760061: [Pkg-zsh-devel] Bug#760061: "5 seconds to fail"

[Bart Schaefer]

On Sep 29,  3:51am, Axel Beckert wrote:
}
} 1) Hangs in the static build at
} 
} ../../Test/A04redirect.ztst: starting.

This doesn't mean very much; none of the tests in A04 produce any output
(unless they fail) so it could be stuck anywhere.

To refine, the "make check" need to be run with ZTST_verbose=1 in the
environment.  See Test/ztst.zsh for more.

} 2) Hangs in the static build at
} 
} This test takes 5 seconds to fail...

This is the only one to which my previous discussions apply.

I've since reproducesd this several times, never intentionally but it
always happens immediately after recompiling the binaries.

} 3) Hangs in the static build at
} 
} ../../Test/A05execution.ztst: starting.

Again this could be in any test, if possible retry with ZTST_verbose=1
 
} 4) Hangs in the non-static build at
} 
} ../../Test/X02zlevi.ztst: starting.

Once more, anywhere.  X02 manipulates zpty terminals to emulate an
interactive session, so is a likely place for race conditions.

} 5) Hangs in the non-static build at
} 
} This test takes 5 seconds to fail...

See (2).

} 6) Hangs in the non-static build at
} 
} ../../Test/A05execution.ztst: starting.

See (3).


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

Bug#731441: nmu for xutlis-dev

[Julien Cristau]

On Sun, Sep 28, 2014 at 19:13:12 -0400, Michael Gilbert wrote:

> On Sun, Sep 28, 2014 at 7:06 PM, Julien Cristau wrote:
> > On Sun, Sep 28, 2014 at 19:00:22 -0400, Michael Gilbert wrote:
> >
> >> control: tag -1 patch, pending
> >>
> >> Hi, I've uploaded an nmu dropping support for libxp to delayed/10.
> >> Please let me know if I should delay longer.
> >>
> > Please do.
> 
> Cancelled.
> 
> It would be kind to get actual feedback.
> 
> The other option is manual overriding the stuff coming out of
> xutils-dev in other packages.  That is not supposedly not the right
> solution for libxp going away:
> http://bugs.debian.org/733209#26
> 
So I'd like not to carry yet another patch.  Has this, or a similar
patch, been forwarded to xorg-devel?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#688551: python3-dateutil: Fresh release (2.1) is available for a while (since 2012-03-28)

[Guido Günther]

On Sun, Sep 28, 2014 at 08:13:58PM +0200, Etienne Millon wrote:
> * Guido Günther  [140928 19:41]:
> > I've uploaded a python-dateutil that ships a python2 and python3
> > version to experimental. Could you check if it works for you?
> > 
> > I'm cc'ing the python3-dateutil maintainers on this one since we
> > would need to remove python3-dateutils from sid then.
> 
> Hi Guido,
> 
> With the package from experimental I can build the new version of
> guessit with no problems.

Awesome. Thanks for testing. Let's give the python3-dateutil
maintainer a couple of days before uploading to unstable.
Cheers,
 -- Guido


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

Bug#763308: Cannot tune volume anymore in system tray

[Erwan David]

Package: kmix
Version: 4:4.14.0-1
Severity: normal

I used to be able, with a right click on knix system tray icon, to
change volume. It is not possible anymre I only get a menu this way. I
must left click and open the main window for mixer, which is not as
convenient


-- System Information:
Debian Release: jessie/sid
  APT prefers testing-proposed-updates
  APT policy: (900, 'testing-proposed-updates'), (900, 'testing'), (600, 
'stable'), (500, 'proposed-updates'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-2-amd64 (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 kmix depends on:
ii  kde-runtime  4:4.14.1-1
ii  libasound2   1.0.28-1
ii  libc62.19-11
ii  libcanberra0 0.30-2.1
ii  libkdecore5  4:4.14.1-1
ii  libkdeui54:4.14.1-1
ii  libplasma3   4:4.14.1-1
ii  libpulse-mainloop-glib0  5.0-6
ii  libpulse05.0-6
ii  libqt4-dbus  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-xml   4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtcore4   4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtgui44:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libsolid44:4.14.1-1
ii  libstdc++6   4.9.1-15

kmix recommends no packages.

kmix 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#756572: Found the issue

[Peter Chubb]

I've finally caught polipo while it's still alive.  It has 1022 open
sockets in state FIN_WAIT2 from itself to various ipv6 clients.

This could be a kernel isssue then... there doesn't seem to be a
fin_wait timeout parameter for ipv6 in the kernel.

--
Dr Peter Chubb  peter DOT chubb AT nicta.com.au
http://www.ssrg.nicta.com.au Software Systems Research at NICTA
A university is a non-profit organisation only in the sense that it
spends everything it gets  ... Luca Turin.


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

Bug#763304: texlive-bin: please remove the build-dependency on libxp-dev

[Norbert Preining]

tag 763304 + pending
thanks

Hi Graham,

On Mon, 29 Sep 2014, Graham Inggs wrote:
> use an Xprint server.  Since we've gotten rid of xprint, one could argue
> it makes sense to get rid of libxp as well. Please see bug #657253 [1].

Removed build-dep, I don't think that the headers in TeX Live actually
need them at the moment.

Committed to our git repo.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



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

Bug#758548: cmake 3.0 in unstable

[Tom Lee]

Fix is in git master, waiting for blessing from the package sponsor.
Hopefully see this ticket closed soon. Thanks!

On Sun, Sep 14, 2014 at 2:25 PM, Felix Geyer  wrote:

> Control: severity -1 important
>
> I have just uploaded cmake 3.0.2-1 to unstable so the Find*.cmake files
> in /usr/share/cmake-2.8/Modules are not used anymore.
>
> Please provide a symlink/copy of those in /usr/share/cmake-3.0/Modules.
>
> Cheers,
> Felix
>



-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#585559: Bug #58559: mutt: tokyocabinet is slower than gdbm

[Jon DeVree]

Apparently this bug is still a thing, I thought the maintainer closed
it. I'm glad to hear I am not crazy and other people saw this, cause I
was pretty skeptical of my own benchmarks at one point. Which is part of
why I had benchmarks, because by all logic gdbm should have been faster!

At some point in the past 4 years I discovered this fixed it:
set header_cache_compress=no

But I also just disabled that line and did some tests. With an 800k
message box, TC is about 2x faster with compression. (25s v. 50s)
I did not time creating the cache. At 80k folder size I'm not sure I
measured a statistically significant difference. But at the timescale of
about 2-3s, the no compression was marginally faster by ~1s. If I simply
double my original numbers in the first messsage to reflect a mailbox
twice as big, TC is basically compariable to the originnal GDBM times.

(Note: the 800k message box is completely unreasonable and I really need
to prune my copy of LKML...)

Back when I opened this it was *really* distinct that TC was slower than
GDBM and then turning off compression fixed it. I don't see that
anymore, so I can only assume there was something fixed somewhere in the
past 4 years. I'm not really interested in rebuilding against GDBM just
to benchmark it and be sure.

Not sure how to close bug, but as the OP I have to say this was probably
a problem with TC w/ compression and it was probably fixed years ago.
-- 
Jon
Kernel Archaeologist
X(7): A program for managing terminal windows. See also screen(1).


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

Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

Hi,

Raphael Geissert:
> On Friday 26 September 2014 18:48:37 Matthias Urlichs wrote:
> [...]
> > In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
> > good idea. Shall we add a Lintian check for this?
> 
> No.
> 
… and why not? 

Importing random functions from the environment is a misfeature which will
bite us again in the future.

The alternate solution is to disable this code entirely. Fine with me;
I seriously doubt that anybody needs this code, let alone would notice.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Bug#736066: Allow encfs into jessie?

[Matthias Urlichs]

Hi,

Christian PERRIER:
> >  According to a security audit by Taylor Hornby (Defuse Security), the 
> > current
> >  implementation of Encfs is vulnerable or potentially vulnerable to multiple
> >  attacks on the encrypted data. This especially affects use cases where the
> >  attacker has read/write access to the encrypted directory or has enough
> >  knowledge of the unencrypted file system contents.
> >  .
s/especially/only/, AFAIK.

> >  In the current situation encfs should not be considered a safe home for
> >  sensible data. This package should be only used to retrieve information 
> > from

s/sensible/sensitive/

> >  previously encrypted sources, and even this action contains some risk of
> >  receiving compromised data.
> 
To recap the security analysis, as I understood it: There's a problem if
somebody has, or had, access to the encrypted files _and_ can store random
data of their choosing there (by manipulating either the encrypted or the
unencrypted files). The notice should unequivocally state exactly that,
instead of the current level of (IMHO) panic mongering.

In most scenarios (encrypt some personal or corporate data stored on NFS,
use reverse mode to store an encrypted backup of sensitive stuff to the
cloud, whatever) this is a non-problem.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Bug#763307: gnome-mines: file conflict with gnome-accessibility-themes < 3.14

[Pino Toscano]

Package: gnome-mines
Version: 1:3.14.0-1
Severity: serious
Tags: patch
Justification: Policy 7.6.1, Policy 10.1

Hi,

when upgrading gnome-mines to 1:3.14.0-1 (i.e. today's upgrade in
testing) while gnome-accessibility-themes is still at 3.12.0-1, a file
conflict is reported:

Preparing to unpack .../gnome-mines_1%3a3.14.0-1_amd64.deb ...
Unpacking gnome-mines (1:3.14.0-1) over (1:3.12.2-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/gnome-mines_1%3a3.14.0-1_amd64.deb (--unpack):
 trying to overwrite 
'/usr/share/icons/HighContrast/24x24/apps/gnome-mines.png', which is also in 
package gnome-accessibility-themes 3.12.0-1

It seems like the HighContrast icons of gnome-mines moved in 3.14 from
gnome-accessibility-themes to gnome-mines itself, so Breaks+Replaces is
missing here. Patch attached for it.

Thanks,
-- 
Pino
--- a/debian/control.in
+++ b/debian/control.in
@@ -23,8 +23,8 @@ Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Recommends: yelp
-Breaks: gnomine (<< 1:3.7.2)
-Replaces: gnomine (<< 1:3.7.2)
+Breaks: gnomine (<< 1:3.7.2), gnome-accessibility-themes (<< 3.14.0)
+Replaces: gnomine (<< 1:3.7.2), gnome-accessibility-themes (<< 3.14.0)
 Description: popular minesweeper puzzle game for GNOME
  Mines is a puzzle game where you locate mines floating in an ocean
  using only your brain and a little bit of luck.

Bug#736066: Allow encfs into jessie?

[Christian PERRIER]

Quoting Eduard Bloch (e...@gmx.de):

> Template: encfs/security-information
> Type: note
> _Description: Encfs Security Information

Besides using an Evil Debconf Note (;-) ), is there a reason for
capitalizing every noun in the note title ?

BTW, that might be a use case for the debconf "error" datatype which
will emphasize the note even more on some frontends.

>  According to a security audit by Taylor Hornby (Defuse Security), the current
>  implementation of Encfs is vulnerable or potentially vulnerable to multiple
>  attacks on the encrypted data. This especially affects use cases where the
>  attacker has read/write access to the encrypted directory or has enough
>  knowledge of the unencrypted file system contents.
>  .
>  In the current situation encfs should not be considered a safe home for
>  sensible data. This package should be only used to retrieve information from
>  previously encrypted sources, and even this action contains some risk of
>  receiving compromised data.

A call for translation would be appreciated too, of course.




signature.asc
Description: Digital signature

Bug#762755: bind 9.9.5-4.1: assertion failure

[Jon DeVree]

I have this and poked around monitoring everything while it happened
repeatedly. I stumbled onto a reliable means of reproduction:

dig -t  ocsp.verisign.net.

Happens with dnssec enable and disabled, so its not that. I tried it
with a pretty stripped down to the original bind config and it still
happened.

https://www.cloudshark.org/captures/56802b91286a

Its presumably the reply from verisign that kills it, but I'm not sure
why.
-- 
Jon
Kernel Archaeologist
X(7): A program for managing terminal windows. See also screen(1).


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

Bug#763305: linux-image-3.16-2-amd64: debian patch of linux kernel radeon driver erroneously prevents firmware loading

[Colin Worth]

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

Dear Maintainer,

In order to use the radeon free driver with my HD6xxx series Radeon card on my 
EFI boot laptop, I downloaded a fresh kernel from kernel.org and built it with 
the following config, in order to add the required firmware for the Radeon card 
into the kernel, as required.

CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
CONFIG_EXTRA_FIRMWARE="radeon/ARUBA_me.bin radeon/ARUBA_pfp.bin 
radeon/ARUBA_rlc.bin {}"


After this, the driver loaded successfully:
Sep 28 22:28:30 worthlaptop kernel: [4.972516] [drm] radeon kernel 
modesetting enabled.
Sep 28 22:28:30 worthlaptop kernel: [4.976621] [drm] initializing kernel 
modesetting (TURKS 0x1002:0x6741 0x106B:0x00E2)

However, recently I decided to build the kernel the Debian way, to get the 
latest kernel patches. In particular, I got:
https://github.com/BlankOn/linux-debian/blob/master/debian/patches/bugfix/all/radeon-firmware-is-required-for-drm-and-kms-on-r600-onward.patch

After this patch was applied, I got this error when trying to boot:
Sep 28 15:47:12 worthlaptop kernel: [2.668496] [drm] radeon kernel 
modesetting enabled.
Sep 28 15:47:12 worthlaptop kernel: [2.668560] [drm:radeon_pci_probe] 
*ERROR* radeon kernel modesetting for R600 or later requires 
firmware-linux-nonfree.

The purpose of the patch seems to have been to provide a quick fix to mitigate 
the number of bug reports related to missing firmware, by issuing a helpful 
message in the kernel log.

But this didn't work - I have firmware in the correct location, and loaded into 
the kernel, but I still get the error messsage, and the driver fails to load, 
simply due to the patch. So the effect is to wrongly prevent the driver from 
loading. This led to a several hour wild-goose-chase looking into Xorg, kernel 
versions, and the propriatary fglrx driver ** spoiler alert, off-topic: the 
latest Catalyst driver still doesn't work for EFI systems - there was a bug 
report in 2013 about needing to load firmware from the kernel, but it was never 
addressed, and eventually closed this year because it pertained to an "old 
version" of the driver **

Back to the kernel patch: the source of the problem is that the patch uses the 
call __ kern_path("/lib/firmware/radeon", LOOKUP_DIRECTORY) __ to try to check 
whether the user has firmware installed. I am not familiar with how the 
kern_path call works, but since I have this directory, and the call failed, it 
is definitely not checking the hard drive (probably obvious).  Perhaps if I had 
set the kernel config CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/radeon", it 
would work as intended?

Since the purpose of the patch is to advise radeon users to install 
firmware-linux-nonfree, not to prevent their radeon drivers from working, why 
not change the behavior to simply issuing a warning message. Edit to patch:

67+ DRM_ERROR("radeon DRM requires firmware-linux-nonfree.\n");
68+ return -ENODEV;
...
...
84+ DRM_ERROR("radeon kernel modesetting for R600 or later requires 
firmware-linux-nonfree.\n");
85+ return -ENODEV;

=>

67+ DRM_INFO("radeon DRM requires firmware-linux-nonfree.\n");
68+ // Remove this line: return -ENODEV;
...
...
84+ DRM_INFO("radeon kernel modesetting for R600 or later requires 
firmware-linux-nonfree.\n");
85+ // Remove this line: return -ENODEV;




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

** Command line:
\vmlinuz root=UUID=925e6684-f119-4b3e-ba81-c55d38171e7c ro i915.modeset=0 
radeon.dpms=1 initrd=\initrd.img



** Kernel log:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.3 (root@worthlaptop) (gcc version 4.9.1 (Debian 
4.9.1-15) ) #4 SMP Sun Sep 28 17:11:16 EDT 2014
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.3 
root=UUID=925e6684-f119-4b3e-ba81-c55d38171e7c ro
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008dfff] usable
[0.00] BIOS-e820: [mem 0x0008e000-0x0008] reserved
[0.00] BIOS-e820: [mem 0x0009-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000b] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0x8ad33fff] usable
[0.00] BIOS-e820: [mem 0x8ad34000-0x8ad5efff] ACPI NVS
[0.00] BIOS-e820: [mem 0x8ad5f000-0x8ad6] usable
[0.00] BIOS-e820: [mem 0x8ad700

Bug#750519: closed by Michal Čihař (Bug#750519: fixed in phpmyadmin 4:4.2.9-1)

[Filipus Klutiero]

reopen 750519
thanks

On 2014-09-22 06:27, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the phpmyadmin package:

#750519: [phpmyadmin] "Cannot load or save configuration": Misleading 
instruction from setup script

It has been closed by Michal Čihař .

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 Michal Čihař 
 by
replying to this email.




I cannot see any difference with 4.2.9. I still see the misleading instruction, 
and not the proper one.

--
Filipus Klutiero
http://www.philippecloutier.com


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

Bug#763304: texlive-bin: please remove the build-dependency on libxp-dev

[Graham Inggs]

Source: texlive-bin
Version: 2014.20140512.33982-1

The xprint package has been removed from Debian.  A related library is
libxp, which provides an API that enables client programs to access and
use an Xprint server.  Since we've gotten rid of xprint, one could argue
it makes sense to get rid of libxp as well. Please see bug #657253 [1].

[1] https://bugs.debian.org/657253


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

Bug#745135: RFS: mariadb-10.0/10.0.13-1 [ITP] -- Latest version of worlds most popular non-Oracle database)

[Arnaud Fontaine]

Hello,

Tobias Frost  writes:

> To avoid a collision: I suggest that Arnaud Fontaine and either agree on
> who will upload, or that both of us announces on the BTS *before* we
> start looking at the package.. Arnau -- is this ok with you? 

Sure. Actually, I saw the comments you sent on the mailing list and then
did further comments on IRC (probably better to use the BTS or the ML
next time though). Do you want to upload this time or the one available
after Otto fixed all the reported issues upload?

Cheers,
-- 
Arnaud Fontaine


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

Bug#762417: vinagre: cannot connect - libgrypt error?

[Norbert Preining]

Hi Andreas,

On Sun, 28 Sep 2014, Andreas Henriksson wrote:
> Judging from the library files in your backtrace it seems like
> you're attempting a VNC connection, is that right?

Correct.

> Could you please try to get a backtrace with debugging symbols?

Is attached, I have installed the debug version of libgvnc and
libgcrypto for completeness.

Hope that helps.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Starting program: /usr/bin/vinagre 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe32df700 (LWP 13779)]
[New Thread 0x7fffe1da5700 (LWP 13780)]
[New Thread 0x7fffe15a4700 (LWP 13781)]
[New Thread 0x7fffe08dd700 (LWP 13784)]
[New Thread 0x7fffc3fff700 (LWP 13785)]
[Thread 0x7fffe08dd700 (LWP 13784) exited]

Program received signal SIGABRT, Aborted.
0x738ba077 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x738ba077 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x738bb458 in __GI_abort () at abort.c:89
#2  0x7fffe7481f74 in lock_fsm () at fips.c:235
#3  0x7fffe7482291 in fips_new_state 
(new_state=new_state@entry=STATE_FATALERROR) at fips.c:759
#4  0x7fffe74827aa in _gcry_fips_signal_error 
(srcfile=srcfile@entry=0x7fffe7519310 "misc.c", srcline=srcline@entry=140, 
srcfunc=srcfunc@entry=0x7fffe7519420 <__FUNCTION__.7980> "_gcry_logv", 
is_fatal=is_fatal@entry=1, description=description@entry=0x7fffe751935b 
"internal error (fatal or bug)") at fips.c:732
#5  0x7fffe748288f in _gcry_fips_signal_error 
(srcfile=srcfile@entry=0x7fffe7519310 "misc.c", srcline=srcline@entry=140, 
srcfunc=srcfunc@entry=0x7fffe7519420 <__FUNCTION__.7980> "_gcry_logv", 
is_fatal=is_fatal@entry=1, description=description@entry=0x7fffe751935b 
"internal error (fatal or bug)") at fips.c:728
#6  0x7fffe747b08a in _gcry_logv (level=level@entry=40, 
fmt=fmt@entry=0x7fffe7537108 "failed to create the RNG lock: %s\n", 
arg_ptr=arg_ptr@entry=0x7fffd1b13af0) at misc.c:140
#7  0x7fffe747b4a1 in _gcry_log_fatal (fmt=fmt@entry=0x7fffe7537108 "failed 
to create the RNG lock: %s\n") at misc.c:230
#8  0x7fffe750daa5 in basic_initialization () at random-fips.c:201
#9  0x7fffe750e861 in _gcry_rngfips_initialize (full=1) at random-fips.c:746
#10 _gcry_rngfips_randomize (buffer=0xaf4730, length=3, 
level=GCRY_STRONG_RANDOM) at random-fips.c:835
#11 0x7fffe750c0a0 in _gcry_random_bytes (nbytes=nbytes@entry=3, 
level=GCRY_STRONG_RANDOM) at random.c:324
#12 0x7fffe7516cae in _gcry_mpi_randomize (w=0xbf74e0, nbits=, level=) at mpiutil.c:586
#13 0x7fffe9f3bd83 in vnc_dh_gen_secret (dh=0xbf34a0) at 
../../../src/dh.c:78
#14 0x7fffe9f4be72 in vnc_connection_perform_auth_ard (conn=) at ../../../src/vncconnection.c:3517
#15 vnc_connection_perform_auth (conn=) at 
../../../src/vncconnection.c:4501
#16 vnc_connection_initialize (conn=) at 
../../../src/vncconnection.c:4973
#17 vnc_connection_coroutine (opaque=0xa4ab90) at 
../../../src/vncconnection.c:5186
#18 0x7fffe9f4e03b in coroutine_trampoline (cc=0xa47030) at 
../../../src/coroutine_ucontext.c:55
#19 0x738caed0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#20 0x00a473f8 in ?? ()
#21 0x in ?? ()
A debugging session is active.

Inferior 1 [process 13775] will be killed.

Quit anyway? (y or n) 

Bug#763303: pari-gp: GET_SEP_SIZE is too small

[Jerome Benoit]

Package: pari-gp
Version: 2.7.2-1
Severity: normal

Dear Maintainer,

 by manipulating some absolute filenames withing gp scripts to
 write precious data in some files, it appears that their
 lenght must be rather short, below 128 char_s.

 I get the message:

 get_sep: argument too long (< 128 chars)

 This (small) upperbound is set in src/language/default.c
 via GET_SEP_SIZE. An uperbound about 512 sounds more reasonnable,
 if not 1024.

hth,
Jerome


-- System Information:
Debian Release: Wheezy*
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pari-gp depends on:
ii  libc6 2.13-38+deb7u4
ii  libgmp10  2:6.0.0+dfsg-1
ii  libreadline6  6.2+dfsg-0.1
ii  libx11-6  2:1.5.0-1+deb7u1

Versions of packages pari-gp recommends:
ii  pari-doc  2.7.2-1
pn  pari-elldata  
pn  pari-galdata  
pn  pari-seadata  

Versions of packages pari-gp suggests:
pn  pari-galpol  
pn  pari-gp2c

-- 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#731441: nmu for xutlis-dev

[Graham Inggs]

On 29 September 2014 01:13, Michael Gilbert  wrote:
> The other option is manual overriding the stuff coming out of
> xutils-dev in other packages.  That is not supposedly not the right
> solution for libxp going away:
> http://bugs.debian.org/733209#26

That should be:
http://bugs.debian.org/733290#26


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

Bug#763207: mdadm: kernel segfault related to software RAID5 rebuild

[NeilBrown]

On Sun, 28 Sep 2014 19:15:09 +0200 Petr Slansky  wrote:

> Package: mdadm
> Version: 3.2.5-5
> Severity: normal
> 
> Dear Maintainer,
> 
> I run OpenMediaVault 1.0 that is based on Debian 7.6.
> I noticed a segfault in dmesg output related to md device. I think it happend 
> when I tried to add a disk to degraded RAID5 array (4/5).


> [12634.575584] irq 11: nobody cared (try booting with the "irqpoll" option)
> [12634.575619] Pid: 176, comm: md0_raid5 Not tainted 3.2.0-4-686-pae #1 
> Debian 3.2.60-1+deb7u3
> [12634.575628] Call Trace:

This is not a "segfault", it is an uncaught interrupt.
There is no evidence that it is related to md except by pure co-incidence.

 11: 60XT-PIC-XT-PICsata_via

Presumably problem  is related to 'via' SATA driver.

NeilBrown


pgpJ6rbaBrIEj.pgp
Description: OpenPGP digital signature

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

[NeilBrown]

On Sun, 28 Sep 2014 17:52:52 +0200 Goswin von Brederlow 
wrote:


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

This is fixed by upstream patch

commit f81a2b56c4b437f66aaf5582a9c6b7f5ab2103c4
Author: NeilBrown 
Date:   Tue Oct 22 09:55:04 2013 +1100

Assembe: fix bug in force_array - it wasn't forcing properly.

which is in mdadm-3.3.1.

NeilBrown


pgp7CNgR9NaGZ.pgp
Description: OpenPGP digital signature

Bug#761422: Crash in gtk

[dai]

Control: tags -1 unreproducible

can you provide reproducing procedure?
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: Digital signature

Bug#744876: [pkg-php-pear] Bug#744876: Status of phpunit 4

[David Prévot]

Hi Prach,

On Mon, Sep 08, 2014 at 03:07:20PM +0700, Prach Pongpanich wrote:
> On Sun, Sep 7, 2014 at 12:06 AM, David Prévot  wrote:
> > On Fri, Jul 25, 2014 at 12:25:31PM -0400, David Prévot wrote:

> > The freeze will start in less than two months, should we aim at
> > releasing phpunit 4 with Jessie? If so, can we help?

> Sure, PHPUnit4 (4.2.x)  should release with Jessie (now I have free time.).

Some new dependencies made it out of NEW (please note that packages
waiting in NEW should not have stopped us from uploading to experimental
anyway), and AFAICT, there is no documented blockers anymore.

Sorry for being pushy, but we’re now about a month from the freeze, and
such a new version (3.7 -> 4.2) may be pretty disruptive. There is a
handful of dependencies against phpunit in the archive, but there are
over 50 build-dependencies! We must have some time to discover any
actual pitfall, and some time to fix the eventual regressions. One month
for that is already pretty short, I wouldn’t be comfortable to wait any
longer to upload a new version (the alternative would be to live with
the 3.7 version for Jessie).

If there is any way we can help now, please do not hesitate to provide
pointers. If you have work in progress, do not hesitate to push it in a
temporary branch so we may be able to shim in.

Regards

David


signature.asc
Description: Digital signature

Bug#763287: Ignore Original Email Address

[David L. Craig]

Odd--reportbug asked for and received my current
email address, yet From: went out with the old and 
non-existent address.  Please use the email address
for this addition.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_


signature.asc
Description: Digital signature

Bug#762376: xserver-xorg-video-radeon: kaffeine not working woth radeon but with intel graphics

[Michel Dänzer]

On 29.09.2014 04:02, M G Berberich wrote:

Am Montag, den 22. September schrieb Michel Dänzer:

On 22.09.2014 01:24, M G Berberich wrote:

Package: xserver-xorg-video-radeon
Version: 1:7.4.0-2
Severity: normal

Dear Maintainer,

on a Intel Core i7 4770 system with a Radeon R7 240 graphics card,

That’s a Radeon R7 250 – sorry.

kaffeine does not work properly when the displays are connected to the
radeon. In this case kaffeine does not show video.

If the displays are connected to the Intel HD onboard-graphics
kaffeine works fine and shows video.


[...]


VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th 
Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Oland XT [Radeon HD 8670 / R7 250] [1002:6610]


[...]


Any terminal output from kaffeine would be interesting as well.


Attached.


[...]


vo_vdpau: vdpau API version : 1
vo_vdpau: vdpau implementation description : G3DVL VDPAU Driver Shared Library 
version 1.0
vo_vdpau: maximum video surface size for chroma type 4:2:2 is 16384x16384
vo_vdpau: maximum video surface size for chroma type 4:2:0 is 16384x16384
vo_vdpau: VideoSurface doesn't support yuy2, sorry.


Looks like kaffeine tries to use VDPAU with the Radeon GPU, but fails. 
Can you clarify with someone knowledgeable about kaffeine whether it 
falls back to XVideo in that case, or how you can explicitly choose XVideo?




X Error: BadMatch (invalid parameter attributes) 8
  Extension:151 (Uknown extension)
  Minor opcode: 17 (Unknown request)
  Resource id:  0x3f


What does

xdpyinfo -queryExtensions|grep 'opcode: 151'

say?


--
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer


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

Bug#760061: [Pkg-zsh-devel] Bug#760061: "5 seconds to fail"

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> This means the issue occurred while running the test suite against the
> static build of the test suite.
> 
> I'll tomorrow check the other failed builds if that was the case
> there, too.

I was too curious, so I checked all buildd logs with hanging test
suites immediately after my last mail. We seem to have either a bunch
of different cases or (IMHO more likely) rather non-deterministic
places where in the test-suite it happens (which again would be more
in line with Bart's findings a month ago).

1) Hangs in the static build at

../../Test/A04redirect.ztst: starting.

https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=armhf&ver=5.0.6-1&stamp=1409479814
https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=armhf&ver=5.0.6-2&stamp=1411273633

2) Hangs in the static build at

This test takes 5 seconds to fail...

https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=kfreebsd-amd64&ver=5.0.6-1&stamp=1409578643

This is the type I have currently here for debugging. It's on amd64
Linux, i.e. not Debian GNU/kFreeBSD on amd64 as the log mentioned
above.

3) Hangs in the static build at

../../Test/A05execution.ztst: starting.

https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=mipsel&ver=5.0.6-1&stamp=1409529387

4) Hangs in the non-static build at

../../Test/X02zlevi.ztst: starting.

https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=amd64&ver=5.0.5-dev-3-1&stamp=1409099297

5) Hangs in the non-static build at

This test takes 5 seconds to fail...

https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=kfreebsd-amd64&ver=5.0.5-dev-2-1&stamp=1407974756
https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=kfreebsd-amd64&ver=5.0.5-dev-2-1&stamp=1407936338

6) Hangs in the non-static build at

../../Test/A05execution.ztst: starting.

https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=kfreebsd-amd64&ver=5.0.6-1&stamp=1409502508

So it's clearly not always the test suite of the static build. But I
plan to disable the test suite run on the statically build zsh for now
anyways to reduce the probability to run into that issue -- as we
ignore its result currently.

Additionally, I've got some more information about the hanging process
in case that helps:

Console output:

HOME="/home/abe/zsh/zsh/obj-static/testhome" dh_auto_test -B obj-static 
--parallel || true
make[1]: Entering directory '/home/abe/zsh/zsh/obj-static'
cd Test ; make check
make[2]: Entering directory '/home/abe/zsh/zsh/obj-static/Test'
if test -n ""; then \
  cd .. && DESTDIR= \
  make MODDIR=`pwd`/Test/Modules install.modules > /dev/null; \
fi
if ZTST_testlist="`for f in ../../Test/*.ztst; \
   do echo $f; done`" \
 ZTST_srcdir="../../Test" \
 ZTST_exe=../Src/zsh \
 ../Src/zsh +Z -f ../../Test/runtests.zsh; then \
 stat=0; \
else \
 stat=1; \
fi; \
sleep 1; \
rm -rf Modules .zcompdump; \
exit $stat
../../Test/A01grammar.ztst: starting.
This test hangs the shell when it fails...
../../Test/A01grammar.ztst: all tests successful.
../../Test/A02alias.ztst: starting.
This test hangs the shell when it fails...
../../Test/A02alias.ztst: all tests successful.
../../Test/A03quoting.ztst: starting.
../../Test/A03quoting.ztst: all tests successful.
../../Test/A04redirect.ztst: starting.
../../Test/A04redirect.ztst: all tests successful.
../../Test/A05execution.ztst: starting.
Unable to change MONITOR option
This test takes 5 seconds to fail...


Open files, again latest child first:

~ # lsof -p 23664
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
zsh 23664  abe  cwdDIR  253,3 4096  1053779 
/home/abe/zsh/zsh/obj-static/Test/command.tmp
zsh 23664  abe  rtdDIR  253,1 40962 /
zsh 23664  abe  txtREG  253,3  5567456  1053778 
/home/abe/zsh/zsh/obj-static/Src/zsh
zsh 23664  abe  memREG  253,1   151984   942005 
/usr/lib/locale/C.UTF-8/LC_CTYPE
zsh 23664  abe  memREG  253,1   50   942004 
/usr/lib/locale/C.UTF-8/LC_NUMERIC
zsh 23664  abe  memREG  253,1 2454   942993 
/usr/lib/locale/C.UTF-8/LC_TIME
zsh 23664  abe  memREG  253,1  1501202   941630 
/usr/lib/locale/C.UTF-8/LC_COLLATE
zsh 23664  abe  memREG  253,1  270   942576 
/usr/lib/locale/C.UTF-8/LC_MONETARY
zsh 23664  abe  memREG  253,1   48   942574 
/usr/lib/locale/C.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES
zsh 23664  abe  memREG  253,1   34   941654 
/usr/lib/locale/C.UTF-8/LC_PAPER
zsh 23664  abe  memREG  253,1   62   938215 
/usr/lib/locale/C.UTF-8/LC_NAME
zsh 23664  abe  memREG  253,1  131   938217 
/usr/lib/locale/C.UTF-8/LC_ADDRESS
zsh 23664  abe  memREG  253,1   47   942270 
/usr/lib/locale/C.UTF-8/LC_TELEPHONE
zsh 23664  abe  memREG  253,1   23   942273 
/usr/lib/locale/C.UTF-8/LC_MEASUREMENT
zsh 23664  abe  memREG  253,126258  1010059 
/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
zsh 23664  abe  memREG  253,1  168   942571 
/usr/lib/loca

Bug#761165: vlc: segmentation fault with VDPAU

[Arthur Marsh]

Package: vlc
Version: 2.2.0~pre3-1
Followup-For: Bug #761165

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I'm still seeing the problem with this version of VLC and can't provide a 
legal sample as it's from a commercial DVD.

Should this problem be assigned to mesa-vdpau-drivers?

*** End of the template - remove these template lines ***


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

Kernel: Linux 3.16.0 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages vlc depends on:
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-43
ii  libavcodec566:11-1
ii  libavutil54 6:11-1
ii  libc6   2.19-11
ii  libcaca00.99.beta19-2
ii  libegl1-mesa [libegl1-x11]  10.3.0~rc3-3
ii  libfreetype62.5.2-2
ii  libfribidi0 0.19.6-2
ii  libgcc1 1:4.9.1-15
ii  libgl1-mesa-glx [libgl1]10.3.0~rc3-3
ii  libgles1-mesa [libgles1]10.3.0~rc3-3
ii  libgles2-mesa [libgles2]10.3.0~rc3-3
ii  libice6 2:1.0.9-1
ii  libpulse0   5.0-6
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libsdl-image1.2 1.2.12-5+b2
ii  libsdl1.2debian 1.2.15-10
ii  libsm6  2:1.2.2-1
ii  libstdc++6  4.9.1-15
ii  libva-drm1  1.3.1-3
ii  libva-x11-1 1.3.1-3
ii  libva1  1.3.1-3
ii  libvlccore8 2.2.0~pre3-1
ii  libvncclient0   0.9.9+dfsg-6+b1
ii  libx11-62:1.6.2-3
ii  libxcb-composite0   1.10-3
ii  libxcb-keysyms1 0.3.9-2
ii  libxcb-randr0   1.10-3
ii  libxcb-render0  1.10-3
ii  libxcb-shape0   1.10-3
ii  libxcb-shm0 1.10-3
ii  libxcb-xfixes0  1.10-3
ii  libxcb-xv0  1.10-3
ii  libxcb1 1.10-3
ii  libxext62:1.3.2-1
ii  libxinerama12:1.1.3-1
ii  libxpm4 1:3.5.11-1
ii  vlc-nox 2.2.0~pre3-1
ii  zlib1g  1:1.2.8.dfsg-2

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.2.0~pre3-1
ii  vlc-plugin-samba   2.2.0~pre3-1
ii  xdg-utils  1.1.0~rc1+git20111210-7.1

Versions of packages vlc suggests:
ii  videolan-doc  20070626-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#727073: ifupdown: current version somehow brings the ifaces up too late

[Christoph Anton Mitterer]

On Fri, 2014-09-26 at 22:36 +0200, Andrew Shadura wrote: 
> It is definitely severity normal. I have already explained how it
> works.
Well you have explained that here, but this is nothing that a admin
necessarily reads before upgrading... he would only read it once his
stuff already starts to fail.
So as along as the default is still to have allow-hotplug on eth
interfaces (which is still the case, AFAIK) and as long as there is no
NEWS.Debian entry or other measure to warn people that update their
ifupdown, that it will likely fail with IPv6 and their current setup -
the issue still fully exists and is therefore still as severe (namely
critical) as it was on the first day.
Justification: it breaks unrelated software


> If you want synchronous operation, don't use allow-hotplug. By
> its definition, it means asynchronous, which means your servers can't
> rely on those interfaces.
Okay but as said before, I don't quite understand what hotplug means,
respectively what async/sync means in this case?

Does it mean that ifupdown brings the interface up once the link comes
up, even if this is at a later point?


But, still,... what's the appropriate solution?
Shall we change the default from allow-hotplug to allow-auto? Shall we
try to find a solution with systemd?

Cheers,
Chris.



smime.p7s
Description: S/MIME cryptographic signature

Bug#762757: gdm3: please don't depend on gnome-shell

[Christoph Anton Mitterer]

On Thu, 2014-09-25 at 10:59 +0100, Simon McVittie wrote: 
> Yes. gdm's current user interface is just GNOME Shell running in a
> special mode: the fallback non-Shell greeter (which was used by default
> in Debian 7) was removed between 3.8 and 3.10. I suspect this should be
> closed as "not a bug", but for now I'm just tagging it wontfix.
> 
> For non-GNOME environments, you might be better off with lightdm.

Well one should probably leave it open and forward it upstream, since
this is quite clearly a design-error then.

Either you have the concept of a display manager, which should be then
pretty agnostic towards the desktop environment used... and especially
it shouldn't be what it is just expected to start.
Or you don't have a DM and (in the case of GNOME) there should be just
gnomeshell.


Cheers,
Chris.


btw: I also worry about about popcon numbers. I mean these are not
rarely used to "prove"/advertise someone's point or to "assist" decide
things in our countless discussions, be it about systemd[0] or about the
default desktop environment.
Now most people use gdm (IIRC comes even per default), so for that
reason nearly everyone will have gnomeshell installed, which in turn can
be used as (wrong) arguments in aforementioned discussion.


[0] I'm in favour of it, just miss some important things :(


smime.p7s
Description: S/MIME cryptographic signature

Bug#763058: nmu: doxygen_1.8.7-3

[Steven Chamberlain]

Hi,

[I'm trying to learn to understand this kind of thing, as well try to
elaborate on what Julien said, so please correct me if I'm wrong].

On 01:19, Julien Cristau wrote:
> On Sun, Sep 28, 2014 at 21:25:07 +0200, Andreas Barth wrote:
> 
> > * Andreas Barth (a...@ayous.org) [140928 14:32]:
> > What works in practice, and seems to be ok-ish from a theoretical POV
> > is to create a symlink from libclang-3.5.so.1 to
> > /usr/lib/`dpkg-architecture -qDEB_BUILD_MULTIARCH`/libclang.so.1
> > during build time (as part of the deb file). This allows doxygen to
> > work again.
> > 
> That seems wrong.  If wheezy's libclang1 and jessie's libclang1-3.5
> aren't binary-compatible, the latter shouldn't provide a libclang.so.1.

Assuming they're not meant to be binary-compatible:

It looks like libclang.so.1 has been provided by different versions of
the LLVM toolchain since wheezy, and that was wrong.

I don't think the LLVM 'default version' transition itself caused this,
but merely exposed an existing problem, one that can't be reverted.
Already some packages were built with libclang-3.4-dev (e.g. mesa,
vim-youcompleteme) or libclang-3.5-dev (e.g. doxygen).

So doxygen for example expects libclang.so.1 to be provided by
libclang1-3.5.  When that file was (rightly) removed from libclang1-3.5
it was left broken.  Restoring a symlink from libclang.so.1 may fix it
temporarily but is not a correct thing to do;  some other package (now,
or in the future) may expect libclang.so.1 to come from a different LLVM
version and may have been subtly broken for some time already.

So AIUI Sylvestre needs to remove that symlink in a new upload, but
all reverse-deps must be NMUd to use the new, versioned library name
e.g. libclang-3.5.so.1.  Except I think the package name needs to be
changed in order to do that, so perhaps a soname bump to
libclang-3.5.so.2 provided by libclang2-3.5?

The existing transition bug and tracker could possibly be repurposed
for this?
https://release.debian.org/transitions/html/llvm-defaults-3.html

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


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

Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Christoph Anton Mitterer]

On Thu, 2014-09-25 at 21:56 +0200, Joerg Jaspert wrote: 
> It also sounds quite stupid that suddenly all users have no working
> mirror anymore, should there be an outage of ftp-master or
> security-master longer than the signing time.
Well I don't see why this must necessarily happen.
Even if ftp-master and or the signing services went down for a longer
time period, then nothing has really changed,... of course the Release
files will no longer be valid, but what then should happen is simply
this:

1) Programs that use secure APT fail if nothing else has been specified
manually by the user/admin - and this is exactly what we (should) want.

If a critical hole, like the shellshock comes out and we fix it quickly,
than no attacker should be able to keep some systems from reacting
either by our current long validity times OR by simply [D]DoSing
ftp-master.

If the secure APT is used manually, than the user/admin will immediately
see that something is fishy an can react appropriately.
If secure APT is somehow used automatically, than a properly configured
system should send the user/admin notifications that updates/upgrades no
longer work, and again, appropriate measures can be taken.


Now to deal with your concern of larger outages:
2) Just because there are no valid [In]Release* files, it doesn't mean
that those mirrors and their repositories can't be used any longer. The
data is still there as it was before.
An application like apt/aptitude/etc. could simply give the user an
error, telling that the files have expired for hh:mm and could give the
user and option to nevertheless trust them.
And the same options could be provided for batch modes.

The only difference is, that now users can notice and can decide
themselves (like trusting files expired for 1 hour, but not for 29 days)
or can take appropriate measures (like looking around in the news or
debian.org/security, whether anything big is going on).


I mean the validity is just a like a flag, that allows software to
decide - but the default should be that - if something is fishy - the
software gives an error/warning  and the validity periods should be
short enough to match the typical package update cycle for each repo.


> Or a release going on, during which we commonly turn off the archive
> and ALL cronjobs. Until we are sure that it is all fine again.
> No, a full release doesn't go through in less than a dinstalls time.
> 
> Even down to two dinstall intervals is short and would require us to add
> one more level of complexity to our working.
Well don't fully understand this, to my understanding, it would be
mainly security and sid archives, which should have very short validity
periods of a few hours, since those are the archives where people expect
their security updates on a fast track.


Apart from that:
The validity-period should IMHO be mainly considered as a
security-related property and not related to the technical periods of
how the repo data is distributed.
And the apropriate value should be aligned to the typical time that it
needs for updates to go into that repo (on master - not on all mirrors).
I.e. that means if our security team is so fast that it sometimes
provides updates within 1 hour of a hole becoming public, that should
mean that the appropriate validity time is that.

If this leads technical problems, than either there is a design problem
in the current distribution model,... or we simply need our clients
(apt/aptitude) to notice the user and leave the choice up to him.



IMHO it's quite dangerous if people start to negotiate security for
technical reasons, the wellness-factor of users or for historical
reasons.  Attackers simply don't care about this.

And yes, security always comes at price, also for the end-user (like in
our case that he could sometimes face expired meta-data and would have
to decide what to do),...
This is why we have a lousy X.509 based security infrastructure in the
web instead of a properly meshed PKI like e.g. OpenPGP would provide it.
This is why Debian still enables network services per default after
installing them, even though this is quite stupid from a security POV.
And I'm sure that there were already people in the past who wondered
about the stupid "features" that bash provides, but for sure they would
have failed to convince upstream to remove them.

Security is not negotiable.



Cheers,
Chris.


btw: I did some PoCs on some of my own servers (respectively such which
are under my control under the university) with shellshock.
As soon as you can MitM, you can do such downgrade attack, and hide any
updates to bash from the systems (which in our case run check_apt via
Icinga)... so noone would notice and take appropriate actions.
Okay that this works, was probably clear to everyone.

But you even don't need to be able for a direct MitM.
Many systems netselect-apt, so all you need to do is: run a mirror that
is considered the closest to your attack-target, wait for a suitable
security hole, st

Bug#760061: "5 seconds to fail"

[Axel Beckert]

Hi again,

On Sat, Aug 30, 2014 at 04:25:45PM -0700, Bart Schaefer wrote:
> On Aug 27,  6:28pm, Axel Beckert wrote:
> } On Sun, Aug 24, 2014 at 06:39:09PM +0100, Peter Stephenson wrote:
> } > I think the only remaining open matter (excluding longer term issues
> } > that aren't going to be dealt with immediately) is test failures in
> } > some automated tests.
> } 
> } We again got a few build-failures on the build daemons, but this time
> } on different architectures than with 5.0.5-dev-2, namely amd64 (Linux)
> } and s390x while kfreebsd-amd64 worked fine this time:
> } 
> } https://buildd.debian.org/status/package.php?p=zsh&suite=experimental
> } 
> } On amd64 (aka x86_64) the testsuite was hanging and killed after 150
> } minutes:
> } 
> https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=amd64&ver=5.0.5-dev-3-1&stamp=1409099297
> } 
> } On s390x, gcc was killed after 150 minutes of inactivity:
> } 
> https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=s390x&ver=5.0.5-dev-3-1&stamp=1409118602
> 
> I was able by accident to reproduce this in a foreground build on CentOS.

Thanks for the confirmation that this is likely not debian-specific.

I though still don't understand why this happens way more often on the
buildds than outside of the buildds.

Since we ran into the issue again with the upload one week ago, and we
have to do another upload again before the upcoming freeze for
Debian's next stable release, I did another run of building the zsh
package again and again (without connected terminal by using "ssh
localhost" without "-t" to get closer to the buildd environment) until
I run into the issue.

And this time I had some luck after something like 70 to 100
successful package builds in one row, but interestingly, with
different results as Bart:

> Can't say for sure it's exactly the same thing, but here's the stack trace
> I got:
> 
> (gdb) where
> #0  0x0086e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x009611ce in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
> #2  0x008efc0b in _L_mutex_lock_4191 () from /lib/tls/libc.so.6
> #3  0x0801 in ?? ()
> #4  0x in ?? ()
> 
> That's literally all of it, no zsh source files at all, so I suspect
> the job has already exited and is a zombie stuck on that mutex.

~ # ps auxwwwf | fgrep -B10 -A2 Src/zsh
abe  18988  0.0  0.1  41920  9216 ?SNs  01:53   0:00  \_ 
/usr/bin/perl /usr/bin/debuild -uc -us -B -j5
abe  19029  0.0  0.0   8964  1388 ?SN   01:53   0:00  
\_ tee ../zsh_5.0.6-2_amd64.build
abe  19030  0.0  0.1  41788 11232 ?SN   01:53   0:00  
\_ /usr/bin/perl /usr/bin/dpkg-buildpackage -rfakeroot -D -us -uc -i -j3 -B -j5
abe  13060  0.0  0.0  22632  3220 ?SN   01:54   0:00
  \_ /bin/bash /usr/bin/fakeroot debian/rules binary-arch
abe  13075  0.0  0.0  13444  2424 ?SN   01:54   0:00
  \_ /usr/bin/make -f debian/rules binary-arch
abe  22865  0.0  0.0   8476   808 ?SN   01:55   0:00
  \_ /bin/sh -c HOME="/home/abe/zsh/zsh/obj-static/testhome" 
dh_auto_test -B obj-static --parallel || true
abe  22866  0.0  0.1  47996 13312 ?SN   01:55   0:00
  \_ /usr/bin/perl -w /usr/bin/dh_auto_test -B obj-static --parallel
abe  22875  0.0  0.0  13444  2464 ?SN   01:55   0:00
  \_ make -j5 test
abe  22876  0.0  0.0   8476   828 ?SN   01:55   0:00
  \_ /bin/sh -c cd Test ; make check
abe  22877  0.0  0.0  13444  2284 ?SN   01:55   0:00
  \_ make check
abe  22879  0.0  0.0   8476   924 ?SN   01:55   0:00
  \_ /bin/sh -c if ZTST_testlist="`for f in 
../../Test/*.ztst; \do echo $f; done`" \  ZTST_srcdir="../../Test" 
\  ZTST_exe=../Src/zsh \  ../Src/zsh +Z -f ../../Test/runtests.zsh; then \  
stat=0; \ else \  stat=1; \ fi; \ sleep 1; \ rm -rf Modules .zcompdump; \ exit 
$stat
abe  22881  0.0  0.0   7428  2120 ?SN   01:55   0:00
  \_ ../Src/zsh +Z -f ../../Test/runtests.zsh
abe  23664  0.0  0.0   8084  2812 ?SN   01:55   0:00
  \_ ../Src/zsh +Z -f ../../Test/ztst.zsh 
../../Test/A05execution.ztst

This means the issue occurred while running the test suite against the
static build of the test suite.

I'll tomorrow check the other failed builds if that was the case
there, too. If so, I'll disable the test suite for the static build
completely and hope that's the fix for now. (We currently ignore the
result for the static build anyways since C02cond.ztst always fails
there. See some other mail from me several months if not a year ago.)

So what's different to Bart's case are the backtraces, latest children
first:

Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Christoph Anton Mitterer]

On Fri, 2014-09-26 at 11:20 +0800, Paul Wise wrote: 
> snapshot is a read-only (modulo cosmic rays and removal of
> non-redistributable things) historical record, files in it will not be
> modified to re-sign with newer keys nor to update Valid-Until.
So what would you do now, when one of the past keys was compromised or
got simply too weak to be trustworthy anymore? This would mean that
stuff shipped by snapshot.d.o is no longer secure (in the sense of
preventing MitM during the download, not in the sense that the package
themselves would be secured otherwise).

Actually, having another APT key for just snapshot.d.o sounds somehow
appealing to me from a design POV.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#623649: nmu for matlab-support

[Michael Gilbert]

On Sun, Sep 28, 2014 at 9:05 PM, Yaroslav Halchenko wrote:
>
> On Sun, 28 Sep 2014, Michael Gilbert wrote:
>
>> control: tag -1 patch, pending
>
>> Hi, I've uploaded an nmu to delayed/10 remove the libxp dependency.
>> matlab versions have not required this for 4 years now, and this is
>> one of two packages remaining with the dependency.
>
> I am not the main maintainer of this package but having experience with
> it,  Would you mind just moving it into Recommends so we would not need
> backport-specific patches:  we are providing this package across wide
> range of Debian/Ubuntu releases (so libxp6 would be present) and
> some people might still use elderly Matlabs.  So with it in Recommends
> we would please Debian gods and make users of older Matlabs happy.

Unfortunately that won't really work since the recommends will become
a policy violation once libxp is removed.  I would recommend adding
some info to the docs or providing a fetching script to help users
that are insistent on using old versions.

Best wishes,
Mike


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

Bug#623649: nmu for matlab-support

[Yaroslav Halchenko]

On Sun, 28 Sep 2014, Michael Gilbert wrote:

> control: tag -1 patch, pending

> Hi, I've uploaded an nmu to delayed/10 remove the libxp dependency.
> matlab versions have not required this for 4 years now, and this is
> one of two packages remaining with the dependency.

I am not the main maintainer of this package but having experience with
it,  Would you mind just moving it into Recommends so we would not need
backport-specific patches:  we are providing this package across wide
range of Debian/Ubuntu releases (so libxp6 would be present) and
some people might still use elderly Matlabs.  So with it in Recommends
we would please Debian gods and make users of older Matlabs happy.

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


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

Bug#762626: fixing it ...

[Marco d'Itri]

On Sep 29, lee  wrote:

> IMO that's arguable.  The idea is to be able to run a script when a
> connection is established and another one when a connection is
> terminated.  A modem is mentioned in the man page merely as an example.
No, it's not. The idea is to run chat to do things to your modem.

> Anyway, how do I get informed when the connection is terminated or
> established?  If there's a better way to achieve this than fixing pppd,
> I might just go that way.  I looked for one without success.
ip-up/ip-down.

> OTOH, fixing the bug seems to make sense.  Suppose I'd fix it to the
> point that I'd be happy with it, would the fix make it into Debian?  Or
Not unless you can persuade the upstream maintainer, which I highly 
doubt.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#697002: [PATCH initramfs-tools 4/5] init: Only mount /usr if the real init is systemd

[Ben Hutchings]

initscripts doesn't work with /usr already mounted.  Other init
systems might not either.

Closes: #763157
Signed-off-by: Ben Hutchings 
---
 init | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/init b/init
index 670fabf..ca5926d 100755
--- a/init
+++ b/init
@@ -258,7 +258,8 @@ if ! validate_init "$init"; then
done
 fi
 
-if read_fstab_entry /usr; then
+# Mount /usr only if init is systemd (after reading symlink)
+if [ "${checktarget##*/}" = systemd ] && read_fstab_entry /usr; then
log_begin_msg "Mounting /usr file system"
mountfs /usr
log_end_msg


-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Bug#697002: [PATCH initramfs-tools 3/5] init: Resolve both absolute and relative symlinks in validate_init

[Ben Hutchings]

This is limited to a single level of symlinks, but that should be
good enough.

Remove the use of chroot - that makes no difference to reading a
symlink; it would only be useful if applied to the [ -x ].

Related-to: #763157
Signed-off-by: Ben Hutchings 
---
 init | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/init b/init
index b47bf7a..670fabf 100755
--- a/init
+++ b/init
@@ -225,8 +225,12 @@ validate_init() {
 
# Work around absolute symlinks
if [ -d "${rootmnt}" ] && [ -h "${rootmnt}${checktarget}" ]; then
-   case $(readlink "${rootmnt}${checktarget}") in /*)
-   checktarget="$(chroot ${rootmnt} readlink 
${checktarget})"
+   checktarget="$(readlink "${rootmnt}${checktarget}")"
+   case "$checktarget" in
+   /*)
+   ;;
+   *)
+   checktarget="${1%/*}/$checktarget"
;;
esac
fi


-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Bug#697002: [PATCH initramfs-tools 2/5] init: Fix validation of the real init program

[Ben Hutchings]

If /sbin/init is executable then we would ignore that $init was
invalid, without actually setting init=/sbin/init.

$init is initialised to /sbin/init, so don't skip the error
message if it's empty.

Related-to: #763157
Signed-off-by: Ben Hutchings 
---
 init | 29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/init b/init
index 05394c2..b47bf7a 100755
--- a/init
+++ b/init
@@ -242,25 +242,16 @@ validate_init() {
fi
 }
 
-# Check init bootarg
-if [ -n "${init}" ]; then
-   if ! validate_init "$init"; then
-   echo "Target filesystem doesn't have requested ${init}."
-   init=
-   fi
-fi
-
-# Common case: /sbin/init is present
-if [ ! -x "${rootmnt}/sbin/init" ]; then
-   # ... if it's not available search for valid init
-   if [ -z "${init}" ] ; then
-   for inittest in /sbin/init /etc/init /bin/init /bin/sh; do
-   if validate_init "${inittest}"; then
-   init="$inittest"
-   break
-   fi
-   done
-   fi
+# Check init is really there
+if ! validate_init "$init"; then
+   echo "Target filesystem doesn't have requested ${init}."
+   init=
+   for inittest in /sbin/init /etc/init /bin/init /bin/sh; do
+   if validate_init "${inittest}"; then
+   init="$inittest"
+   break
+   fi
+   done
 fi
 
 if read_fstab_entry /usr; then


-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Bug#697002: [PATCH initramfs-tools 5/5] debian/control: Add Breaks: systemd-sysv (<< 186)

[Ben Hutchings]

If the kernel command line has 'ro' then the init system must
remount /usr read-write, but systemd did not do this until
version 186.

Related-to: #763157
Signed-off-by: Ben Hutchings 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 4dda02d..5256670 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Depends: klibc-utils (>= 2.0-1~), cpio, kmod | 
module-init-tools, udev, ${misc:D
 Suggests: bash-completion
 Provides: linux-initramfs-tool
 Conflicts: usplash (<< 0.5.50)
-Breaks: cryptsetup (<< 2:1.1.0-2.1), elilo (<< 3.12-3.1~), lilo (<< 
22.8-8.2~), s390-tools (<< 1.8.3-2~), console-setup (<< 1.72)
+Breaks: cryptsetup (<< 2:1.1.0-2.1), elilo (<< 3.12-3.1~), lilo (<< 
22.8-8.2~), s390-tools (<< 1.8.3-2~), console-setup (<< 1.72), systemd-sysv (<< 
186)
 Description: generic modular initramfs generator
  This package contains tools to create a bootable initramfs for Linux kernel
  packages. The initramfs is a compressed cpio archive. At boot time, the

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Bug#697002: [PATCH initramfs-tools 1/5] init: Decide what the real init is immediately before mounting /usr

[Ben Hutchings]

Unfortunately, it appears we will need to know this to decide
whether or not to mount /usr.

Related-to: #763157
Signed-off-by: Ben Hutchings 
---
 init | 68 ++--
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/init b/init
index 90a2ba1..05394c2 100755
--- a/init
+++ b/init
@@ -220,37 +220,6 @@ mount_premount
 mountroot
 log_end_msg
 
-if read_fstab_entry /usr; then
-   log_begin_msg "Mounting /usr file system"
-   mountfs /usr
-   log_end_msg
-fi
-
-# Mount cleanup
-mount_bottom
-nfs_bottom
-local_bottom
-
-maybe_break bottom
-[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/init-bottom"
-run_scripts /scripts/init-bottom
-[ "$quiet" != "y" ] && log_end_msg
-
-# Preserve information on old systems without /run on the rootfs
-if [ -d ${rootmnt}/run ]; then
-   mount -n -o move /run ${rootmnt}/run
-else
-   # The initramfs udev database must be migrated:
-   if [ -d /run/udev ] && [ ! -d /dev/.udev ]; then
-   mv /run/udev /dev/.udev
-   fi
-   # The initramfs debug info must be migrated:
-   if [ -d /run/initramfs ] && [ ! -d /dev/.initramfs ]; then
-   mv /run/initramfs /dev/.initramfs
-   fi
-   umount /run
-fi
-
 validate_init() {
checktarget="${1}"
 
@@ -292,11 +261,42 @@ if [ ! -x "${rootmnt}/sbin/init" ]; then
fi
done
fi
+fi
+
+if read_fstab_entry /usr; then
+   log_begin_msg "Mounting /usr file system"
+   mountfs /usr
+   log_end_msg
+fi
+
+# Mount cleanup
+mount_bottom
+nfs_bottom
+local_bottom
 
-   # No init on rootmount
-   if ! validate_init "${init}" ; then
-   panic "No init found. Try passing init= bootarg."
+maybe_break bottom
+[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/init-bottom"
+run_scripts /scripts/init-bottom
+[ "$quiet" != "y" ] && log_end_msg
+
+# Preserve information on old systems without /run on the rootfs
+if [ -d ${rootmnt}/run ]; then
+   mount -n -o move /run ${rootmnt}/run
+else
+   # The initramfs udev database must be migrated:
+   if [ -d /run/udev ] && [ ! -d /dev/.udev ]; then
+   mv /run/udev /dev/.udev
fi
+   # The initramfs debug info must be migrated:
+   if [ -d /run/initramfs ] && [ ! -d /dev/.initramfs ]; then
+   mv /run/initramfs /dev/.initramfs
+   fi
+   umount /run
+fi
+
+# No init on rootmount
+if ! validate_init "${init}" ; then
+   panic "No init found. Try passing init= bootarg."
 fi
 
 maybe_break init


-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Bug#697002: [PATCH initramfs-tools 0/5] Only mount /usr if the real init is systemd

[Ben Hutchings]

Currently initscripts will not work correctly if /usr is mounted by
initramfs-tools.  Firstly, fsck will fail and the boot process will
stop.  If you press Ctrl-D to continue, the boot process will succeed
but /usr will not be remounted read-write if necessary.

upstart (or mountall) and wheezy's version of systemd also fail to
remount /usr as read-write.

This issue *must* be fixed *now*.  I am extremely annoyed that this
delicate change has been handled so badly and I intend to upload some
kind of fix by the end of this week.

My current ugly fix is to mount /usr if init is systemd, and add a
versioned Breaks to ensure systemd is upgraded if necessary.  The actual
fix might not look quite like this:

* If there is a fixed initscripts and/or util-linux available then the
check for systemd can be replaced with a versioned Breaks on
initscripts.

* As for upstart, since it installs /sbin/init I don't see a way to
distinguish it from sysvinit.  So if initscripts is fixed and upstart is
not then I'm afraid I may have to add an unversioned Breaks: upstart.
If they are both fixed, then that can be another versioned Breaks:.

* If anyone can present a better solution (not an idea, not a plan, but
an actual implementation), I would be very happy because this one is not
at all nice.  (Aside from 'init: Fix validation of the real init
program' which is a bug fix in its own right.)

Ben.

Ben Hutchings (5):
  init: Decide what the real init is immediately before mounting /usr
  init: Fix validation of the real init program
  init: Resolve both absolute and relative symlinks in validate_init
  init: Only mount /usr if the real init is systemd
  debian/control: Add Breaks: systemd-sysv (<< 186)

 debian/control |  2 +-
 init   | 90 --
 2 files changed, 44 insertions(+), 48 deletions(-)


-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Bug#761072: nginx-full: php5-fpm does not work

[Jaime Alberto Silva]

Yep! it was the problem, it is working now.

Thanks a lot Christos!

Now I know I must check for the NEWS file.

Jaime Alberto Silva Colorado
http://jaimealsilva.com


On Wed, Sep 24, 2014 at 2:49 AM, Christos Trochalakis 
wrote:

> Hello Alberto,
>
> On Wed, Sep 10, 2014 at 09:07:52AM -0500, Jaime Alberto Silva wrote:
>
>> Package: nginx-full
>> Version: 1.6.1-2
>> Severity: important
>>
>> When calling a PHP file the browser returns WSOD immediately while nginx
>> log says it is still working, after a few seconds log says "client closed
>> connection while waiting for request":
>>
>>
> In 1.6.1-2 we synced fastcgi_params with upstream nginx, There is a NEWS
> entry about that (/usr/share/doc/nginx-common/NEWS.Debian.gz).
>
> I think that switching to fastcgi.conf instead of fastcgi_params will work
> for you.
>
> We are sorry for the inconvenience.
>
>
>

Bug#763266: codespell: "Trying next encoding: utf-8"

[Paul Wise]

Control: tags -1 + patch upstream
Control: forwarded -1 codesp...@googlegroups.com

On Sun, 2014-09-28 at 19:56 +0200, Jakub Wilk wrote:

> Package: codespell
> Severity: minor
> 
> $ printf '\xff' > test
> $ codespell test
> WARNING: Decoding file test
> WARNING: using encoding=utf-8 failed.
> WARNING: Trying next encoding: utf-8
> 
> 
> Of course if encoding=utf-8 failed, there is no point trying utf-8 
> again. The last line should instead read:
> 
> WARNING: Trying next encoding: iso-8859-1

The attached patch fixes this issue.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

From 1527cb3899e5b488906056391191b4f42929c898 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Mon, 29 Sep 2014 08:11:30 +0800
Subject: [PATCH] Print the correct next encoding when falling back to other
 encodings

Fixes: https://bugs.debian.org/763266
Signed-off-by: Paul Wise 
---
 codespell.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/codespell.py b/codespell.py
index 332bf4a..1eb53aa 100755
--- a/codespell.py
+++ b/codespell.py
@@ -171,8 +171,11 @@ class FileOpener:
 print('WARNING: using encoding=%s failed. '
 % encodings[curr],
 file=sys.stderr)
-print('WARNING: Trying next encoding: %s' % encodings[curr],
-file=sys.stderr)
+try:
+print('WARNING: Trying next encoding: %s' % encodings[curr+1],
+file=sys.stderr)
+except IndexError:
+pass
 
 curr += 1
 
-- 
2.1.0



signature.asc
Description: This is a digitally signed message part

Bug#763301: xul-ext-zotero: broken with iceweasel 31.1.0esr-1 | Version 4.0.22.SOURCE works

[derMaria]

Package: xul-ext-zotero
Version: 4.0.22-1
Followup-For: Bug #763301

Dear Maintainer,

just found out, that in another instance of Iceweasel I have Zotero Version
4.0.22.SOURCE installed which actually works. Don't exactly know why...

Live long and prosper!
Rafael Maria R.



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

Kernel: Linux 3.16-2-486
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xul-ext-zotero depends on:
ii  iceweasel  31.1.0esr-1

xul-ext-zotero recommends no packages.

xul-ext-zotero 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#739605: pm-utils: sudo pm-hibernate does hibernate but when trying to wake it reboots

[Cameron Norman]

On Thu, 20 Feb 2014 08:37:26 -0300 Mariano Ignacio Baragiola 
 wrote:

> Package: pm-utils
> Version: 1.4.1-13
> Severity: grave
> Justification: causes non-serious data loss
>
> When trying to pm-hibernate being root, there's no problem. But when 
you sudo
> it, it hibernates; but then when trying to wake it crashes and 
reboots.


Is there any sort of error message? What size swap do you have, how 
much RAM, and do you use a swap file or swap partition?


Best regards,
--
Cameron Norman

Bug#763302: ITP: ruby-rspec-its -- Provides "its" method for RSpec 3 extracted from rspec-core 2.x

[KURASHIKI Satoru]

Package: wnpp
Severity: wishlist
Owner: KURASHIKI Satoru 

* Package name: ruby-rspec-its
  Version : 1.0.1
  Upstream Author : Peter Alfvin
* URL : https://github.com/rspec/rspec-its
* License : MIT
  Programming Lang: Ruby
  Description : Provides "its" method for RSpec 3 extracted from rspec-core 
2.x

RSpec::Its provides the its method as a short-hand to specify the expected 
value of an attribute.

This gem is required for ruby-serverspec package to fix #761729.


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

Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Paul Wise]

Package: snapshot.debian.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

On Sun, Sep 28, 2014 at 4:34 AM, Peter Palfrader wrote:
> On Fri, 26 Sep 2014, Paul Wise wrote:
>
>> On Thu, Sep 25, 2014 at 11:21 PM, Christoph Anton Mitterer wrote:
>>
>> > Well I think snapshot is it's own construction site, isn't it?
>>
>> snapshot is a read-only (modulo cosmic rays and removal of
>> non-redistributable things) historical record, files in it will not be
>> modified to re-sign with newer keys nor to update Valid-Until.
>
> That doesn't mean one couldn't consider providing an overlay of sorts,
> that provides re-signed release files if the original ones verified.
> Under a different path obviously.  We could look at patches if they
> somehow appeared.

Excellent idea, documenting it in the bug tracker.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#763300: (no subject)

[Joe Gumbosky]

Subject: clamav: --remove option causes segmentation fault
Package: clamav
Version: 0.98.4+dfsg-0+deb7u2
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- Package-specific info:
--- configuration ---
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogRotate true
LogTime true
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav
DNSDatabaseInfo current.cvd.clamav.net
AllowSupplementaryGroups false
PidFile /var/run/clamav/freshclam.pid
ConnectTimeout 30
ReceiveTimeout 30
TestDatabases yes
ScriptedUpdates yes
CompressLocalDatabase no
SafeBrowsing false
Bytecode true
NotifyClamd /etc/clamav/clamd.conf
# Check for new database 24 times a day
Checks 24
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net

--- data dir ---
total 136172
-rw-r--r-- 1 clamav clamav74230 Sep 28 00:57 bytecode.cvd
-rw-r--r-- 1 clamav clamav 74634752 Sep 28 19:01 daily.cld
-rw-r--r-- 1 clamav clamav 64720632 Sep 28 00:55 main.cvd
-rw--- 1 clamav clamav  364 Sep 28 19:01 mirrors.dat

-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 clamav depends on:
ii  clamav-freshclam [clamav-data]  0.98.4+dfsg-0+deb7u2
ii  libc6   2.13-38+deb7u4
ii  libclamav6  0.98.4+dfsg-0+deb7u2
ii  libcurl37.26.0-1+wheezy10
ii  libssl1.0.0 1.0.1e-2+deb7u12
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages clamav recommends:
ii  clamav-base  0.98.4+dfsg-0+deb7u2

Versions of packages clamav suggests:
pn  clamav-docs  

-- no debconf information
 I'm a user, not a maintainer.  I've tried running as root 
and user.  No luck.  I've posted to Debian Forum
http://forums.debian.net/viewtopic.php?f=10&t=117439
I've reinstalled.


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

Bug#760397: pcmanfm: mounting removable media fails

[Andrej N. Gritsenko]

control: reassign -1 policykit-1

If you have lxpolkit just installed but not running it will not solve the
issue. And I'm not sure now if I can help you with that. All I can say the
file /usr/share/dbus-1/system-services/org.freedesktop.PolicyKit1.service
should define the service (which is done by policykit-1 package) and then
it should work, but your "Not Authorized" might mean it is not configured
correctly. I'll reassign this issue to policykit-1 package, I think their
maintainers can help you more. If you don't use lxsession then lxpolkit is
not help for you. Thank you very much.


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

Bug#763301: xul-ext-zotero: broken with iceweasel 31.1.0esr-1

[derMaria]

Package: xul-ext-zotero
Version: 4.0.22-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after I made an upgrade (Debian testing) which installed iceweasel with version
31.1.0esr-1 xul-ext-zotero refuses to start showing message "Es gab einen
Fehler beim Start von Zotero." (There was an error at the start of Zotero.) My
last upgrade was quite long ago, so I can't tell anymore, which Version of
Iceweasel I had before.

I tried to downgrade Iceweasel to the versions 30.0-2 and 24.5.0esr-1 with no
effect. But after downgrading to Iceweasel 24.5.0esr-1 suddenly Zotero-
Standalone worked, which did not before (but this might have been to to
xulrunner, because in the downgrade process it installed xulrunner-24). The
standalone still works after upgrading back to Iceweasel 31.1.0esr-1. But xul-
ext-zotero still doesn't work.

I am working on an IBM Thinkpad X32 with Debian testing and XFCE.

Thanks for your help and support - live long and prosper!
Rafael Maria R.



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

Kernel: Linux 3.16-2-486
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xul-ext-zotero depends on:
ii  iceweasel  31.1.0esr-1

xul-ext-zotero recommends no packages.

xul-ext-zotero 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#763119: misinterprets old-style GNU headers

[Steinar H. Gunderson]

On Sun, Sep 28, 2014 at 01:49:52AM +0200, Steinar H. Gunderson wrote:
> I've attached a simple patch to fix this; it doesn't give access to all the
> other fields, but at least it fixes th_get_pathname() (which seems to be
> pretty much the only place the prefix field is actually interpreted) so that
> it does not return these bogus paths.

I'm sorry, this wasn't well enough tested; it only works with -H oldgnu,
not --incremental (which was what I intended to fix), so it's all wrong,
and the logic is inverted to boot. This one should be much better;
tested with a regular tarball, -H oldgnu and -g.

/* Steinar */
-- 
Homepage: http://www.sesse.net/
Index: libtar-1.2.20/lib/decode.c
===
--- libtar-1.2.20.orig/lib/decode.c
+++ libtar-1.2.20/lib/decode.c
@@ -69,7 +69,14 @@ th_get_pathname(TAR *t)
 			return NULL;
 	}
 
-	if (t->th_buf.prefix[0] == '\0')
+	/*
+	 * Old GNU headers (also used by newer GNU tar when doing incremental
+	 * dumps) use the POSIX prefix field for many other things, such as
+	 * mtime and ctime. New-style GNU headers don't, but also don't use the
+	 * POSIX prefix field. Thus, only honor the prefix field if the archive
+	 * is actually a POSIX archive. This is the same logic as GNU tar uses.
+	 */
+	if (strcmp(t->th_buf.magic, TMAGIC) != 0 || t->th_buf.prefix[0] == '\0')
 	{
 		sprintf(t->th_pathname, "%.100s", t->th_buf.name);
 	}

Bug#763073: partman-md places first line of mdadm.conf to wrong file

[Cyril Brulebois]

Control: tag -1 pending

Michael Tokarev  (2014-09-27):
> Package: partman-md
> Version: 70
> Severity: normal
> Tags: patch
> 
> finish-install.d/65partman-md reads:
> 
>  CF=/target/etc/mdadm/mdadm.conf
>  if ... then
> mkdir -p /target/etc/mdadm
> echo "# Autogenerated by partman-md. See mdadm.conf(5) for more 
> details on this file." > /etc/mdadm.conf
> echo "DEVICE partitions" >> $CF
> ...
> 
> and all subsequent lines adds information to $CF.
> But the very first line, the "Autogenerated.." header
> line, is put into d-i filesystem, where it is not used.
> The intention was, obviously, to put it to target
> mdadm.conf, ie, to $CF.
> 
> Appended patch does just that.  While at it, it also
> replaces argument of mkdir to be ${CF%/*}, to keep
> path info in only one place, in CF variable assignment
> ( ${var%pattern} construct works with dash too).

Thanks, pushed to master.

Not a blocker for Jessie Beta 2, but testing/uploading shouldn't hurt
due to the udeb freeze; nothing too dramatic anyway, that it needs to
be fixed urgently…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#695211: lxde: Debian 6.0 doesn't sort by name if name starts with "_"

[Andrej N. Gritsenko]

I believe this issue was fixed long time ago by upstream and any current
versions (1.x) sort files perfectly fine. Check it, please. In any case
this issue should be closed as fixed and obsolete. Thank you very much.


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

Bug#689022: lxde: Debian wallpaper distorted on 4:3 monitor

[Andrej N. Gritsenko]

control: reassign -1 lxde-common

This is very interesting issue because the default background image for
the pcmanfm is set to /etc/alternatives/desktop-background by the package
lxde-common and that image, in fact, does not exist, therefore the patch
02-desktop-background.patch should be removed. And also original default
background image is 1024x768 but it isn't set until you select it. Which
brings my first sentence - it is very interesting where have you got your
image at all in such case, you should have no desktop image background at
all with initial LXDE setup. That is definitely a bug which have to be
fixed.


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

Bug#656008: nmu for pcre3

[Michael Gilbert]

Hi, I've uploaded an nmu enabling build hardening flags for pcre3 to
delayed/5.  Please let me know if I should delay longer.

Best wishes,
Mike
diff -Nru pcre3-8.35/debian/changelog pcre3-8.35/debian/changelog
--- pcre3-8.35/debian/changelog	2014-07-23 20:24:30.0 +
+++ pcre3-8.35/debian/changelog	2014-09-28 23:03:27.0 +
@@ -1,3 +1,10 @@
+pcre3 (1:8.35-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable build hardening flags (closes: #656008).
+
+ -- Michael Gilbert   Fri, 19 Sep 2014 01:48:23 +
+
 pcre3 (1:8.35-3) unstable; urgency=medium
 
   Thanks to Simon McVittie for all of the work on this:
diff -Nru pcre3-8.35/debian/rules pcre3-8.35/debian/rules
--- pcre3-8.35/debian/rules	2014-07-23 20:06:54.0 +
+++ pcre3-8.35/debian/rules	2014-09-28 23:03:27.0 +
@@ -11,18 +11,12 @@
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_MULTIARCH  ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-CFLAGS = -Wall -g
 INSTALL = install
 INSTALL_FILE= $(INSTALL) -p-o root -g root  -m  644
 INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
 
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -O0
-else
-CFLAGS += -O2
-endif
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 INSTALL_PROGRAM += -s
 endif
@@ -31,14 +25,15 @@
 	dh_testdir
 	# Add here commands to configure the package.
 	dh_autoreconf
-	CC_FOR_BUILD=cc CFLAGS="$(CFLAGS)" ./configure \
+	CC_FOR_BUILD=cc ./configure \
 		--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) \
 		--prefix=/usr --mandir=\$${prefix}/share/man \
 		--infodir=\$${prefix}/share/info \
 		--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
 		--enable-utf8 --enable-unicode-properties \
 		--disable-silent-rules \
-		$(shell . debian/jit-test)
+		$(shell . debian/jit-test) \
+		$(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --export=configure)
 	touch configure-stamp
 
 build: build-arch build-indep

Bug#763058: nmu: doxygen_1.8.7-3

[Julien Cristau]

On Sun, Sep 28, 2014 at 21:25:07 +0200, Andreas Barth wrote:

> * Andreas Barth (a...@ayous.org) [140928 14:32]:
> > I also have an idea for an ugly hack but I need to think a bit more
> > about it. From package POV it might be the "niciest", but I'm not sure
> > if it works (which is a precondition for everything). I'll update this
> > mail tonight.
> 
> What works in practice, and seems to be ok-ish from a theoretical POV
> is to create a symlink from libclang-3.5.so.1 to
> /usr/lib/`dpkg-architecture -qDEB_BUILD_MULTIARCH`/libclang.so.1
> during build time (as part of the deb file). This allows doxygen to
> work again.
> 
That seems wrong.  If wheezy's libclang1 and jessie's libclang1-3.5
aren't binary-compatible, the latter shouldn't provide a libclang.so.1.
And if they are, then there shouldn't be two different package names.
I fear we're just adding hacks on top of hacks here, somebody please
clarify.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#731441: nmu for xutlis-dev

[Michael Gilbert]

On Sun, Sep 28, 2014 at 7:06 PM, Julien Cristau wrote:
> On Sun, Sep 28, 2014 at 19:00:22 -0400, Michael Gilbert wrote:
>
>> control: tag -1 patch, pending
>>
>> Hi, I've uploaded an nmu dropping support for libxp to delayed/10.
>> Please let me know if I should delay longer.
>>
> Please do.

Cancelled.

It would be kind to get actual feedback.

The other option is manual overriding the stuff coming out of
xutils-dev in other packages.  That is not supposedly not the right
solution for libxp going away:
http://bugs.debian.org/733209#26

Best wishes,
Mike


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

Bug#731441: nmu for xutlis-dev

[Julien Cristau]

On Sun, Sep 28, 2014 at 19:00:22 -0400, Michael Gilbert wrote:

> control: tag -1 patch, pending
> 
> Hi, I've uploaded an nmu dropping support for libxp to delayed/10.
> Please let me know if I should delay longer.
> 
Please do.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#731441: nmu for xutlis-dev

[Michael Gilbert]

control: tag -1 patch, pending

Hi, I've uploaded an nmu dropping support for libxp to delayed/10.
Please let me know if I should delay longer.

Best wishes,
Mike
diff -Nru xutils-dev-7.7+3/debian/changelog xutils-dev-7.7+3.1/debian/changelog
--- xutils-dev-7.7+3/debian/changelog	2014-05-21 19:46:36.0 +
+++ xutils-dev-7.7+3.1/debian/changelog	2014-09-28 22:48:40.0 +
@@ -1,3 +1,10 @@
+xutils-dev (1:7.7+3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop support for libxp (closes: #731441).
+
+ -- Michael Gilbert   Sun, 28 Sep 2014 22:35:00 +
+
 xutils-dev (1:7.7+3) unstable; urgency=medium
 
   * gccmakedep 1.0.3.
diff -Nru xutils-dev-7.7+3/xorg-cf-files/X11.tmpl xutils-dev-7.7+3.1/xorg-cf-files/X11.tmpl
--- xutils-dev-7.7+3/xorg-cf-files/X11.tmpl	2014-05-21 19:01:41.0 +
+++ xutils-dev-7.7+3.1/xorg-cf-files/X11.tmpl	2014-09-28 22:46:59.0 +
@@ -2900,28 +2900,6 @@
 ProjectUnsharedLibReferences(OLDX,oldX,$(OLDXLIBSRC),XBuildLibDir)
 #endif
 
-#ifndef SharedLibXp
-#define SharedLibXp HasSharedLibraries
-#endif
-#ifndef NormalLibXp
-#define NormalLibXp (!SharedLibXp | ForceNormalLib)
-#endif
-#ifndef DebugLibXp
-#define DebugLibXp  NO  /* debugged Xp library */
-#endif
-#ifndef ProfileLibXp
-#define ProfileLibXpNO  /* profiled Xp library */
-#endif
- XPLIBSRC = $(LIBSRC)/Xp
-#if SharedLibXp
-#ifndef SharedXpRev
-#define SharedXpRev 6.2
-#endif
-SharedLibReferences(XP,Xp,$(XPLIBSRC),SOXPREV,SharedXpRev)
-#else
-ProjectUnsharedLibReferences(XP,Xp,$(XPLIBSRC),XBuildLibDir)
-#endif
-
 #ifndef SharedLibXt
 #define SharedLibXt HasSharedLibraries
 #endif

Bug#762614: stop preseeding desktop

[Cyril Brulebois]

Control: tag -1 pending

Joey Hess  (2014-09-23):
> Package: debian-installer
> Severity: normal
> Tags: patch
> 
> Once tasksel 3.27 is in testing, but not before, d-i should stop
> preseeding desktop=xfce for kfreebsd and hurd. This version of tasksel
> defaults to xfce for those architectures and will handle any other
> architecture variations in a single place.

Thanks, pushed to master.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#762377: closed by Sebastian Ramacher (Re: Bug#762377: vlc: Videos over HTTP stream very slowly in 2.2.0-pre3)

[Andoru Ekkusu]

> Thanks. I can confirm the issue.
>
> It looks a lot like #7186 in vlc's trac to me. At least I see the
> same problem with the stream mentioned there.

That bug seems to be over 2 years old.
What are the next steps that I should take?

Bug#742561: [pkg-wine-party] Bug#742561: Status of these bugs

[Jens Reyer]

On 09/28/2014 04:13 AM, Michael Gilbert wrote:
> On Sat, Sep 27, 2014 at 9:56 PM, jre wrote:
>> the bugs #742561 and #762058 are marked as pending in reportbug, however
>> I see no trace of this in their bug logs. Is this some bug in bugs.d.o?
> 
> Not sure how you're seeing that.  I don't see it in reportbug, but if
> that's true, that's more of a bug in reportbug itself.

I posted a screenshot at https://dumpyourphoto.com/photo/icj4EIDyid

I reported #763178 against reportbug. There's a Tag and a Status column,
the latter shows pending. No idea what this should indicate. For me it
looked like an indication that someone was working actively on these bugs.

Greets
jre


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

Bug#763299: systemctl: Failed to get D-Bus connection: Unknown error -1

[Cyril Roelandt]

Package: systemd
Version: 215-5
Severity: normal

Dear Maintainer,

After systemd somehow managed to become PID1 again, despite my previous efforts
to restore sysV as my init system, I realised that closing the lid of my laptop
would cause my computer to disconnect from the network. I tried to fix this by
editing /etc/systemd/logind.conf, as shown below. I then tried to restart the
systemd-logind service:

# systemctl restart systemd-logind
Failed to get D-Bus connection: Unknown error -1

Even just "systemctl" fails:

# systemctl
Failed to get D-Bus connection: Unknown error -1

Even though dbus seems to be running:

# /etc/init.d/dbus status
[ ok ] dbus is running.

Restarting dbus did not solve the issue.

I'd be happy to be able to either restart the systemd-logind service, or manage
to get sysv back as my init system once and for all.


Thanks,
Cyril Roelandt.


-- Package-specific info:

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

Kernel: Linux 3.14-2-amd64 (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 systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-53.4
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1
ii  libblkid1   2.20.1-5.9
ii  libc6   2.19-11
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-1
ii  libgcrypt11 1.5.4-3
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-5
ii  sysv-rc 2.88dsf-53.4
ii  udev215-5
ii  util-linux  2.20.1-5.9

Versions of packages systemd recommends:
ii  dbus1.8.8-1
ii  libpam-systemd  215-5

Versions of packages systemd suggests:
pn  systemd-ui  

-- Configuration Files:
/etc/systemd/logind.conf changed:
[Login]
HandleLidSwitch=ignore


-- 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#763071: devscripts: [uscan] allow setting download compression ordering (prefer xz over gz)

[James McCoy]

On Sat, Sep 27, 2014 at 06:50:06PM +0200, Andreas Metzler wrote:
> Given this watch file ...
> 
> -
> version=3
> opts=pgpsigurlmangle=s/$/.sig/ \
> ftp://ftp.gnu.org/gnu/autogen/rel([\d\.]+)/autogen-([\d\.]+)\.tar\.(?:xz|bz2|gz)
> -
> 
> ... uscan finds both .gz and .xz but selects the gzip version for
> download. Switching the two alternatives in the regex does not change
> this.

uscan debug: requesting URL ftp://ftp.gnu.org/gnu/autogen/rel5.18.4/
uscan debug: received content:
-rw-r--r--1 3003 3002  1797980 Aug 30 17:55 autogen-5.18.4-5.src.rpm
-rw-r--r--1 3003 3002  198 Aug 30 17:55 
autogen-5.18.4-5.src.rpm.sig
-rw-r--r--1 3003 3002   830780 Aug 30 17:55 
autogen-5.18.4-5.x86_64.rpm
-rw-r--r--1 3003 3002  198 Aug 30 17:55 
autogen-5.18.4-5.x86_64.rpm.sig
-rw-r--r--1 3003 3002  1794375 Aug 30 17:56 autogen-5.18.4.tar.gz
-rw-r--r--1 3003 3002  198 Aug 30 17:56 
autogen-5.18.4.tar.gz.sig
-rw-r--r--1 3003 3002  1017936 Aug 30 17:56 autogen-5.18.4.tar.xz
-rw-r--r--1 3003 3002  198 Aug 30 17:56 
autogen-5.18.4.tar.xz.sig

The ordering actually comes from the ftp listing.  That being said, why
not just remove the bz2/gz parts of the regex if you know upstream is
shipping xz?  I don't see the benefit of matching the other extensions
(especially the bz2), when you know upstream already provides the
extension you want.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Bug#733290: nmu for xtel

[Michael Gilbert]

On Sun, Sep 28, 2014 at 6:17 PM, Samuel Thibault wrote:
> Michael Gilbert, le Sun 28 Sep 2014 18:09:30 -0400, a écrit :
>> +#define XmClientLibs -lXm
>
> Ah, sorry, I hadn't seen that you had used the patch redefining XmClientLibs.
> I'd really avoid that: the bug really is in xutils-dev, it should much rather 
> be
> fixed there first.

I agree.  I'll take a look at that.

Best wishes,
Mike


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

Bug#623649: nmu for matlab-support

[Michael Gilbert]

control: tag -1 patch, pending

Hi, I've uploaded an nmu to delayed/10 remove the libxp dependency.
matlab versions have not required this for 4 years now, and this is
one of two packages remaining with the dependency.

Best wishes,
Mike
diff -Nru matlab-support-0.0.19/debian/changelog matlab-support-0.0.19+nmu1/debian/changelog
--- matlab-support-0.0.19/debian/changelog	2013-02-13 07:02:55.0 +
+++ matlab-support-0.0.19+nmu1/debian/changelog	2014-09-28 22:16:27.0 +
@@ -1,3 +1,10 @@
+matlab-support (0.0.19+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Eliminate libxp dependency (closes: #623649).
+
+ -- Michael Gilbert   Fri, 19 Sep 2014 04:38:34 +
+
 matlab-support (0.0.19) unstable; urgency=low
 
   * Debconf translation updates and additions
diff -Nru matlab-support-0.0.19/debian/control matlab-support-0.0.19+nmu1/debian/control
--- matlab-support-0.0.19/debian/control	2013-02-13 07:01:49.0 +
+++ matlab-support-0.0.19+nmu1/debian/control	2014-09-28 22:16:27.0 +
@@ -12,7 +12,7 @@
 Package: matlab-support
 Section: contrib/devel
 Architecture: all
-Depends: debconf (>=1.3.22) | cdebconf (>= 0.43), ${misc:Depends}, libxp6, sudo
+Depends: debconf (>=1.3.22) | cdebconf (>= 0.43), ${misc:Depends}, sudo
 Recommends: libstdc++6-4.4-dev | libstdc++-dev
 Conflicts: matlab (<= 0.0.14~)
 Replaces: matlab (<= 0.0.14~)

Bug#736066: Allow encfs into jessie?

[Philip Hands]

Eduard Bloch  writes:

> Hallo,
> * Eduard Bloch [Thu, Sep 11 2014, 04:55:14PM]:
>> > (What would be the right way to do that? Lower the severtiy of the bug?
>> > Add a jessie-ignore tag?)
>> > 
>> > To notify users about the potential security issue, a NEWS file could
>> > be added, or one could add a warning to the output of the encfs command.
>> 
>> In fact, that is what I considered as workaround, and even harder: add a
>> debconf message with priority critical telling exactly those details.
>> 
>> Unless someone cries out loudly I will continue with this plan in a
>> couple of days.
>
> So, here is what I came up with. Does it sound scarry enough, does it
> sound generally acceptable?
>
> Template: encfs/security-information
> Type: note
> _Description: Encfs Security Information
>  According to a security audit by Taylor Hornby (Defuse Security), the current
>  implementation of Encfs is vulnerable or potentially vulnerable to multiple
>  attacks on the encrypted data. This especially affects use cases where the
>  attacker has read/write access to the encrypted directory or has enough
>  knowledge of the unencrypted file system contents.
>  .
>  In the current situation encfs should not be considered a safe home for
>  sensible data. This package should be only used to retrieve information from
      
   |  |
That should be "sensitive"|
  |
  +
and that should be "only be used", or perhaps "be used only for the retrieval 
of..."


>  previously encrypted sources, and even this action contains some risk of
>  receiving compromised data.

This last sentence seems unclear to me.  Are you saying that the act of
reading the data increases the chance of it being compromised?  If so,
perhaps it should read:

  ... previously encrypted sources, and even performing this action carries
  with it an increased risk of compromise.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


pgpvNkuAjcyNt.pgp
Description: PGP signature

Bug#763298: Bug report about the package grass-gui 6.4.4-1 : function i.class does not run properly

[Etienne MAHE]

Package: grass-gui
Version: 6.4.4-1
Severity: Normal
Justification: some functionnality does not run properly


Good day,

When I try to start the module i.class in graphical mode, located in the
Imagery menu, I get the following message in the terminal :

=
If you wish to resize the X monitor, do so now. Window size is
locked while interactive modules are running.
=

/usr/lib/grass64/etc/grass-run.sh: 32: /usr/lib/grass64/etc/grass-run.sh:
i.class: not found

ERROR: "i.class" exited abnormally. Press  to continue.

I don't know how to resolve the problem. The module needs Xterm but it
functions properly on my XFCE desktop. I have tried to reinstall both grass
gis and Xterm but it does not resolve the problem.

Sincerely,
Etienne MAHE

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

Kernel: Linux 3.16.2 amd64

Bug#763297: transition: libsystemd

[Michael Biebl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

in systemd v209, the various libsystemd-* libraries were merged into a
single libsystemd0 library. We still build the old libraries to not
break existing packages, though.
The libsystemd-(daemon|journal|login|id128)-dev package now point to
-lsystemd0, i.e. packages once rebuilt will link against libsystemd0 not
the old library names and we want all packages to link against the new
libsysemd0 library so we can eventually drop the compat library
packages.

Please schedule a round of binNMUs so affected packages will be rebuilt
against libsystemd0. Afaics this doesn't qualify as library transition
but it's probably easiest to find affected packages via a transition
tracker.

The ben file for it should look something like this:

title = "libsystemd";
is_affected = .depends ~ "libsystemd-(daemon|journal|login|id128-)0," | 
.depends ~ "libsystemd0";
is_good = .depends ~ "libsystemd0";
is_bad = .depends ~ "libsystemd-(daemon|journal|login|id128-)0,";


The binNMU could be something like "Rebuild against libsystemd0"

Thanks for considering,

Michael

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
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#733290: nmu for xtel

[Samuel Thibault]

Michael Gilbert, le Sun 28 Sep 2014 18:09:30 -0400, a écrit :
> +#define XmClientLibs -lXm

Ah, sorry, I hadn't seen that you had used the patch redefining XmClientLibs.
I'd really avoid that: the bug really is in xutils-dev, it should much rather be
fixed there first.

Samuel


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

Bug#733290: nmu for xtel

[Michael Gilbert]

On Sun, Sep 28, 2014 at 6:15 PM, Samuel Thibault wrote:
> Michael Gilbert, le Sun 28 Sep 2014 18:09:30 -0400, a écrit :
>> Hi, I've uploaded a patch fixing this issue to delayed/10.  Please let
>> me know if I should delay longer.
>
> Err, but #731441 is still not fixed!

The patch I came up with doesn't require that :)

Best wishes,
Mike


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

Bug#733290: nmu for xtel

[Samuel Thibault]

Michael Gilbert, le Sun 28 Sep 2014 18:09:30 -0400, a écrit :
> Hi, I've uploaded a patch fixing this issue to delayed/10.  Please let
> me know if I should delay longer.

Err, but #731441 is still not fixed!

Samuel


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

Bug#733290: nmu for xtel

[Michael Gilbert]

control: tag -1 patch, pending

Hi, I've uploaded a patch fixing this issue to delayed/10.  Please let
me know if I should delay longer.

Best wishes,
Mike
diff -u xtel-3.3.0/Imakefile xtel-3.3.0/Imakefile
--- xtel-3.3.0/Imakefile
+++ xtel-3.3.0/Imakefile
@@ -14,4 +14,6 @@
 #include "Motif.tmpl"
 
+#define XmClientLibs -lXm
+
 BITMAPSDIR= bitmaps
 PIXMAPSDIR= pixmaps
diff -u xtel-3.3.0/debian/changelog xtel-3.3.0/debian/changelog
--- xtel-3.3.0/debian/changelog
+++ xtel-3.3.0/debian/changelog
@@ -1,3 +1,10 @@
+xtel (3.3.0-17.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Eliminate libxp-dev build dependency (closes: #733290).
+
+ -- Michael Gilbert   Fri, 19 Sep 2014 04:20:50 +
+
 xtel (3.3.0-17) unstable; urgency=low
 
   * Build-depend on libmotif-dev instead of lesstif2-dev.
diff -u xtel-3.3.0/debian/control xtel-3.3.0/debian/control
--- xtel-3.3.0/debian/control
+++ xtel-3.3.0/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Samuel Thibault 
 Standards-Version: 3.9.3
-Build-Depends: libmotif-dev,libx11-dev,libxmu-dev,libxpm-dev,libxp-dev,libxt-dev,x11proto-core-dev,xbitmaps,libxaw7-dev,debhelper (>= 5.0.31),imagemagick,xfonts-utils,xutils-dev,libjpeg-dev, doc-base, xfonts-utils, hardening-wrapper
+Build-Depends: libmotif-dev,libx11-dev,libxmu-dev,libxpm-dev,libxt-dev,x11proto-core-dev,xbitmaps,libxaw7-dev,debhelper (>= 5.0.31),imagemagick,xfonts-utils,xutils-dev,libjpeg-dev, doc-base, xfonts-utils, hardening-wrapper
 Homepage: http://pficheux.free.fr/xtel/
 
 Package: xtel

Bug#763209: general: laptop panel no longer powers off

[Tomasz Nitecki]

tags 763209 + moreinfo
thanks


Hey,

On 28/09/14 19:33, allan grossman wrote:
> Up until this morning's updates my monitor powered off after 10 minutes of
> inactivity.  DPMS can no longer power the monitor off, even using 'xset dpms
> force off'
> 
> Attaching /var/log/apt/history.log


Allan, can you please attach the output of 'dmesg' command? You should
run it after the problem occurred (so running it after 'xset dpms force
off' should do the trick).

Your history log shows that you have also updated xserver-xorg-core. Can
you confirm that when running on an older kernel DPMS works fine? Or at
least are you 100% sure that the problem begun only after you reloaded
your system with a new kernel?

When responding, please remember to cc 763...@bugs.debian.org (your
response will be visible on the public, web browsable bug tracker at [1]).

Package 'general' isn't meant for kernel bugs so when I got your answer
I'll reassign it to the correct package.

Thanks for your report!


Regards,
T.

[1] https://bugs.debian.org/763209



signature.asc
Description: OpenPGP digital signature

Bug#763157: initramfs-tools: Mounting /usr by initramfs-tools breaks checkfs.sh

[Ben Hutchings]

On Sun, 2014-09-28 at 20:20 +0100, Ben Hutchings wrote:
> On Sun, 2014-09-28 at 19:44 +0100, Roger Leigh wrote:
> > On Sun, Sep 28, 2014 at 06:49:49PM +0100, Ben Hutchings wrote:
> > > Roger, please can you look at this?
> > > 
> > > Ben.
> > > 
> > > On Sun, 2014-09-28 at 11:41 +0200, Robert Luberda wrote:
> > > > Package: initramfs-tools
> > > > Version: 0.117
> > > > Severity: critical
> > > > Justification: breaks the whole system
> > > > 
> > > > Hi
> > > > 
> > > > After /usr is being mounted from initramfs, system is no longer
> > > > bootable, because checkfs.sh script fails with:
> > > > 
> > > >   [] Checking file systems...fsck from util-linux 2.20.1
> > > >   /home2: clean, 166826/610800 files, 2350575/2441880 blocks
> > > >   /home: clean, 120720/1831424 files, 3611320/3662820 blocks
> > > >   /dev/sda5 is mounted.
> > > >   e2fsck: Cannot continue, aborting.
> > > > 
> > > > 
> > > >   fsck exited with status code 8
> > > >   [] File system check failed. A log is being saved in
> > > >   /var/log/fsck/checkfs if that location is writable. Please repair the
> > > >   f[FAILystem manually. ... failed!
> > > >
> > > > The contents of /var/log/fsck/checkfs is:
> > > > 
> > > >   Log of fsck -C -R -A -a 
> > 
> > Has there been an update to util-linux to make the above -R option
> > skip checking /usr in addition to the rootfs?  That was a
> > prerequisite for mounting /usr in the initramfs.
> 
> Argh.  No.  And that doesn't fix the problem because we have to
> support partial upgrades.
[...]

Also, wheezy's systemd and both versions of initscripts do not
remount /usr as read-write if the initramfs mounts it read-only.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.


signature.asc
Description: This is a digitally signed message part

Bug#763212: kxd: FTBFS: Tests failures

[Alberto Bertogli]

On Sun, Sep 28, 2014 at 07:02:30PM +0200, David Suárez wrote:
> Source: kxd
> Version: 0.12-2
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20140926 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/«PKGBUILDDIR»'
> > go build -o ./out/kxd ./kxd
> > go build --tags netgo -a -o ./out/kxc ./kxc
> > python tests/run_tests -b
> > .F.
> > ==
> > FAIL: test_server_cert (__main__.TrickyRequests)
> > --
> > Traceback (most recent call last):
> >   File "tests/run_tests", line 408, in test_server_cert
> > self.assertTrue(sock.cipher()[2] > 128)
> > AssertionError: False is not true

Hi! I am traveling this week without a laptop so I won't be able to look
at this properly until next Monday or so.

However, looking at the output and the test itself, it is very likely
that this is an issue with the test and not the code.

Thanks!
Alberto


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

Bug#763054: pcre3: FTBFS on hurd because of stack size problem

[Samuel Thibault]

Samuel Thibault, le Sun 28 Sep 2014 23:37:30 +0200, a écrit :
> What we can do is simply make the hurd's libpthread default 8192KiB like
> Linux, to avoid differing too much from the Linux defaults and get such
> bugs just due to differing defaults.

I have committed it to glibc.

I'll build pcre3 by hand with it.

Samuel


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

Bug#763269: upgrade-system: Want to remove required package in Debian Edu

[Martin-Éric Racine]

2014-09-28 21:32 GMT+03:00 Petter Reinholdtsen :
>
> Package: upgrade-system
> Version: 1.7.0.0
> Severity: wishlist
> User: debian-...@lists.debian.org
> Usertags: debian-edu
>
> Hi.  I've tested upgrade-system in Debian Edu Jessie, and am surprised
> it want to remove education-common, which is a package we want to have
> installed on all Debian Edu systems.
>
> But I am unable to figure out why it want to remove it.  Can
> upgrade-system be changed to keep the education-common package?
>
> Here is a test run:
>
> root@skolelinuxtest:~# upgrade-system
> 1) Updating package lists:
> I: Package lists updated.
> 2) Checking for upgradable packages:
> I: No upgradable package to install.
> 3) Checking for orphan packages:
> I: Purging orphan packages...
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be REMOVED:
>   attr* education-common* libboost-iostreams1.54.0* libhdb9-heimdal*
>   libkdc2-heimdal* python-dnspython*
>   samba* samba-dsdb-modules* samba-vfs-modules* tdb-tools*
> 0 upgraded, 0 newly installed, 10 to remove and 0 not upgraded.
> After this operation, 15.0 MB disk space will be freed.
> Do you want to continue? [Y/n] n
> Abort.
> 4) Cleaning package cache.
> I: System upgrade completed.
> root@skolelinuxtest:~#
>
> How can this problem be debugged?

By manually running 'deborphan' with the default options found in
/etc/upgrade-system.conf and adjusting those options according to your
own needs.

Martin-Éric


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

Bug#763054: pcre3: FTBFS on hurd because of stack size problem

[Ólafur Jens Sigurðsson]

On Sun, Sep 28, 2014 at 11:37:30PM +0200, Samuel Thibault wrote:
> Samuel Thibault, le Sun 28 Sep 2014 22:22:47 +0200, a écrit :
> > Ólafur Jens Sigurðsson, le Sat 27 Sep 2014 15:10:47 +, a écrit :
> > > The package fails to build on hurd because the pthread stack size in
> > > only 2024 kb instead of the 8192 kb that linux has.
> > 
> > Well, ideally hurd should be made to get its stack size for ulimit -s
> > too. It should be a matter of using getrlimit in libpthread for the
> > stack size, and defaulting to the default 2MiB if ulimit -s is not
> > defined.
> 
> I have now commited this. However, http://savannah.gnu.org/bugs/?43320
> prevents it from working.
> 
> What we can do is simply make the hurd's libpthread default 8192KiB like
> Linux, to avoid differing too much from the Linux defaults and get such
> bugs just due to differing defaults.

If there are no really good reasons to keep the stack size small then
that would be a good solution.

Cheers, Oli


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

Bug#762621: efibootmgr: Please build efivar + efibootmgr for armel

[Ian Campbell]

Hi Daniel,

On Tue, 23 Sep 2014 20:49:51 +0100 Ian Campbell  wrote:
> As of version 2.02~beta2-13 the grub-efi-arm-bin package now depends on
> efibootmgr. Since grub-efi-arm-bin is built for armel as well as armhf that
> means we need efibootmgr there too.

Since this is going to start blocking grub at some point I was planning
to spend some time in the coming week preparing an NMU upload to DELAYED
+5 or so for both efivar and efibootmgr with armel added to the
Architecture field. Please let me know if I shouldn't do this.

I will of course file the nmudiff in the BTS etc as usual.

Cheers,
Ian.


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

Bug#757384: Build-Depends on outdated liblcms1, should move to liblcms2

[Michael Gilbert]

control: tag -1 patch

On Fri, Aug 8, 2014 at 3:04 PM, Michael Gilbert wrote:
> icc2ps was renamed to psicc between lcms1 and lcms2.  So, this should
> be easily fixed via s/foo2zjs-icc2ps/psicc/g, dropping foo2zjs-icc2ps
> from make, and adding a liblcms2-utils dependency.

Hi, I've uploaded an nmu with these changes.  Please see attached patch.

Best wishes,
Mike
diff -Nru foo2zjs-20140519dfsg0/debian/changelog foo2zjs-20140519dfsg0/debian/changelog
--- foo2zjs-20140519dfsg0/debian/changelog	2014-08-01 15:02:19.0 +
+++ foo2zjs-20140519dfsg0/debian/changelog	2014-09-28 21:47:37.0 +
@@ -1,3 +1,10 @@
+foo2zjs (20140519dfsg0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use psicc from lcms2 (closes: #757384).
+
+ -- Michael Gilbert   Sun, 28 Sep 2014 21:34:38 +
+
 foo2zjs (20140519dfsg0-2) unstable; urgency=medium
 
   * Add autopkgtest suite
diff -Nru foo2zjs-20140519dfsg0/debian/control foo2zjs-20140519dfsg0/debian/control
--- foo2zjs-20140519dfsg0/debian/control	2014-08-01 15:02:19.0 +
+++ foo2zjs-20140519dfsg0/debian/control	2014-09-28 21:47:37.0 +
@@ -8,7 +8,7 @@
  foomatic-filters,
  foomatic-db-engine,
  libcups2-dev,
- liblcms1-dev,
+ liblcms2-utils,
  dc,
  time,
  pyppd (>= 1.0.2-1~),
@@ -21,7 +21,7 @@
 
 Package: printer-driver-foo2zjs
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${ubuntu:mscompress}, foomatic-filters, dc, printer-driver-foo2zjs-common (>= ${source:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${ubuntu:mscompress}, foomatic-filters, dc, printer-driver-foo2zjs-common (>= ${source:Version}), liblcms2-utils
 Recommends: wget, unzip, ${debian:mscompress}, cups, cups-client
 Suggests: psutils, hannah-foo2zjs
 Breaks: udev (<< 136-1), cups (<< 1.5.0-3~), foo2zjs (<< 20111023dfsg0-1~)
diff -Nru foo2zjs-20140519dfsg0/debian/patches/99-system-lcms.patch foo2zjs-20140519dfsg0/debian/patches/99-system-lcms.patch
--- foo2zjs-20140519dfsg0/debian/patches/99-system-lcms.patch	1970-01-01 00:00:00.0 +
+++ foo2zjs-20140519dfsg0/debian/patches/99-system-lcms.patch	2014-09-28 21:47:37.0 +
@@ -0,0 +1,99 @@
+Description: don't build icc2ps (instead use psicc from liblcms2-utils)
+Author: Michael Gilbert 
+
+--- a/Makefile
 b/Makefile
+@@ -184,13 +184,6 @@ FILES	=	\
+ 		foomatic-db/*/*.xml \
+ 		foomatic-test \
+ 		getweb.in \
+-		icc2ps/*.[ch] \
+-		icc2ps/*.1in \
+-		icc2ps/Makefile \
+-		icc2ps/AUTHORS \
+-		icc2ps/COPYING \
+-		icc2ps/README \
+-		icc2ps/README.foo2zjs \
+ 		osx-hotplug/Makefile \
+ 		osx-hotplug/*.m \
+ 		osx-hotplug/*.1in \
+@@ -371,7 +364,7 @@ JBGOPTS=-m 16 -d 0 -p 92	# Equivalent op
+ # The usual build rules
+ #
+ all:	all-test $(PROGS) $(BINPROGS) $(SHELLS) getweb \
+-	all-icc2ps all-osx-hotplug man doc \
++	all-osx-hotplug man doc \
+ 	all-done
+ 
+ all-test:
+@@ -593,7 +586,7 @@ command2foo2lava-pjl.o: command2foo2lava
+ #
+ # Installation rules
+ #
+-install: all install-test install-prog install-icc2ps install-osx-hotplug \
++install: all install-test install-prog install-osx-hotplug \
+ 	install-extra install-crd install-foo install-ppd \
+ 	install-gui install-desktop install-filter \
+ 	install-man install-doc
+@@ -1109,7 +1102,6 @@ uninstall:
+ 	-rm -f $(MANDIR)/man1/foo2hbpl*.1 $(MANDIR)/man1/hbpldecode.1
+ 	-rm -f $(MANDIR)/man1/gipddecode.1
+ 	-rm -f $(MANDIR)/man1/arm2hpdl.1 $(MANDIR)/man1/usb_printerid.1
+-	-rm -f $(MANDIR)/man1/foo2zjs-icc2ps.1
+ 	-rm -rf /usr/share/foo2zjs/
+ 	-rm -rf /usr/share/foo2hp/
+ 	-rm -rf /usr/share/foo2oak/
+@@ -1134,7 +1126,6 @@ uninstall:
+ 	-rm -f /usr/bin/hbpldecode
+ 	-rm -f /usr/bin/opldecode
+ 	-rm -f /usr/bin/rodecode
+-	-rm -f /usr/bin/foo2zjs-icc2ps
+ 	-rm -f /usr/bin/foo2zjs-pstops
+ 	-rm -f /usr/bin/command2foo2lava-pjl
+ 	-rm -f /usr/lib/cups/filter/command2foo2lava-pjl
+@@ -1177,7 +1168,6 @@ clean:
+ 	-rm -f *.zjs *.zm *.zc *.zc? *.zc?? *.oak *.pbm *.pksm *.cmyk
+ 	-rm -f pksm2bitcmyk
+ 	-rm -f *.icm.*.ps
+-	cd icc2ps; $(MAKE) $@
+ 	cd osx-hotplug; $(MAKE) $@
+ 
+ #
+@@ -1327,7 +1317,7 @@ pprtest-3.oak: FRC
+ #
+ #	icc2ps regression tests
+ #
+-ICC2PS=./icc2ps/foo2zjs-icc2ps
++ICC2PS=/usr/bin/psicc
+ icctest:
+ 	for g in *.icm; do \
+ 	for i in 0 1 2 3; do \
+@@ -1424,7 +1414,7 @@ oldppd:
+ # Manpage generation.  No, I am not interested in "info" files or
+ # HTML documentation.
+ #
+-man: $(MANPAGES) man-icc2ps man-osx-hotplug
++man: $(MANPAGES) man-osx-hotplug
+ 
+ $(MANPAGES): macros.man includer-man
+ 
+@@ -1491,7 +1481,6 @@ install-man: man
+ 	$(INSTALL) -c -m 644 arm2hpdl.1 $(MANDIR)/man1/
+ 	$(INSTALL) -c -m 644 usb_printerid.1 $(MANDIR)/man1/
+ 	$(INSTALL) -c -m 644 printer-profile.1 $(MANDIR)/man1/
+-	cd icc2ps; $(MAKE) install-man
+ ifeq ($(UNAME),Darwin)
+ 	cd osx-hotplug; $(MAKE) install-man
+ endif
+@@ -1512,10 +1501,9 @@ install-doc: doc
+ 
+ GROFF=/usr/local/test/bin/groff
+ GROFF=groff
+-manual.pdf: $(MANPAGES) icc2ps/foo2zjs-icc2ps.1 osx-hotplug/osx-hplj-hotplug.

Bug#736066: Allow encfs into jessie?

[Eduard Bloch]

Hallo,
* Eduard Bloch [Thu, Sep 11 2014, 04:55:14PM]:
> > (What would be the right way to do that? Lower the severtiy of the bug?
> > Add a jessie-ignore tag?)
> > 
> > To notify users about the potential security issue, a NEWS file could
> > be added, or one could add a warning to the output of the encfs command.
> 
> In fact, that is what I considered as workaround, and even harder: add a
> debconf message with priority critical telling exactly those details.
> 
> Unless someone cries out loudly I will continue with this plan in a
> couple of days.

So, here is what I came up with. Does it sound scarry enough, does it
sound generally acceptable?

Template: encfs/security-information
Type: note
_Description: Encfs Security Information
 According to a security audit by Taylor Hornby (Defuse Security), the current
 implementation of Encfs is vulnerable or potentially vulnerable to multiple
 attacks on the encrypted data. This especially affects use cases where the
 attacker has read/write access to the encrypted directory or has enough
 knowledge of the unencrypted file system contents.
 .
 In the current situation encfs should not be considered a safe home for
 sensible data. This package should be only used to retrieve information from
 previously encrypted sources, and even this action contains some risk of
 receiving compromised data.

Regards,
Eduard.


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

Bug#640997: Upstream

[Filipus Klutiero]

tags 640997 upstream
thanks

I forwarded this upstream : https://bugs.kde.org/show_bug.cgi?id=339490

--
Filipus Klutiero
http://www.philippecloutier.com


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

Bug#762791: laptop-mode-tools: At boot eth0 fails

[Stefano Callegari]

Il dom, set 28, 2014 at 11:35:42 +0530, Ritesh Raj Sarraf scrisse:
> Once your machine has booted up, you can then do a restart of the laptop
> mode service. It will print all the debug logs onto the console. You can
> then copy paste the logs

Only the last lines (shift+pageup can't show more):


# Handle Speed Throttling
ret=`$ETHTOOL -s $DEVICE speed $MAX_SPEED 2>&1`
exit_status=$?;
log "VERBOSE" "$ret";
if [ $exit_status -eq 0 ]; then
log "VERBOSE" "Restored speed to $MAX_SPEED 
Mbit for $DEVICE"
else
log "VERBOSE" "Could not restore speed for 
$DEVICE"
fi
fi

# Shut down interface
if [ x$DISABLE_ETHERNET = x1 ]; then
if $IPTOOL link show $DEVICE | grep -q NO-CARRIER; then
log "VERBOSE" "ethernet: Disabling ethernet 
device $DEVICE"
$IPTOOL link set dev $DEVICE down
else
log "VERBOSE" "ethernet: Not disabling ethernet 
device $DEVICE with active carrier."
fi
elif [ x$DISABLE_ETHERNET = x0 ]; then
$IPTOOL link set dev $DEVICE up
log "VERBOSE" "ethernet: Re-enabling ethernet device 
$DEVICE"
fi

done
else
log "VERBOSE" "Ethernet module is disabled."
fi
++ '[' x1 = x1 ']'
++ '[' -x /sbin/ethtool ']'
++ ETHTOOL=/sbin/ethtool
++ '[' -x /sbin/mii-tool ']'
++ MIITOOL=/sbin/mii-tool
++ '[' -x /bin/ip ']'
++ IPTOOL=/bin/ip
++ '[' 1 -eq 1 ']'
++ '[' 0 -eq 1 ']'
++ THROTTLE_ETHERNET=0
++ '[' x0 = x1 ']'
++ DISABLE_ETHERNET=2
++ for DEVICE in '$ETHERNET_DEVICES'
++ log VERBOSE 'ethernet: eth0'
++ '[' x1 = x1 ']'
++ '[' -x /usr/bin/logger -a VERBOSE '!=' STATUS ']'
++ '[' VERBOSE = MSG ']'
++ '[' VERBOSE = ERR ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' x0 = x1 ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' 1 = 0 ']'
++ '[' x1 = x1 ']'

$ETHTOOL -s $DEVICE wol d 2>&1
+++ /sbin/ethtool -s eth0 wol d
++ ret=
++ exit_status=0
++ log VERBOSE ''
++ '[' x1 = x1 ']'
++ '[' -x /usr/bin/logger -a VERBOSE '!=' STATUS ']'
++ '[' VERBOSE = MSG ']'
++ '[' VERBOSE = ERR ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' x0 = x1 ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' 1 = 0 ']'
++ '[' 0 -eq 0 ']'
++ log VERBOSE 'Enabled wakeup-on-LAN for eth0'
++ '[' x1 = x1 ']'
++ '[' -x /usr/bin/logger -a VERBOSE '!=' STATUS ']'
++ '[' VERBOSE = MSG ']'
++ '[' VERBOSE = ERR ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' x0 = x1 ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' 1 = 0 ']'
$MIITOOL -v $DEVICE 2>/dev/null | grep capabilities | tr ' ' '\n' | 
sort -n | sed -ne '/^1.*/p' | cut -d "b" -f1
+++ cut -d b -f1
+++ sed -ne '/^1.*/p'
+++ /sbin/mii-tool -v eth0
+++ sort -n
+++ tr ' ' '\n'
+++ grep capabilities
++ speed='10
10
100
100
1000
1000'
++ '[' -z '10
10
100
100
1000
1000' ']'
++ max_s=0
++ min_s=10
++ for s in '$speed'
++ '[' 10 -gt 0 ']'
++ max_s=10
++ '[' 10 -lt 10 ']'
++ min_s=10
++ for s in '$speed'
+++ sed -ne '/^1.*/p'
+++ /sbin/mii-tool -v eth0
+++ grep capabilities
+++ sort -n
+++ cut -d b -f1
++ speed='10
10
100
100
1000
1000'
++ '[' -z '10
10
100
100
1000
1000' ']'
++ max_s=0
++ min_s=10
++ for s in '$speed'
++ '[' 10 -gt 0 ']'
++ max_s=10
++ '[' 10 -lt 10 ']'
++ min_s=10
++ for s in '$speed'
++ '[' 10 -gt 10 ']'
++ '[' 10 -lt 10 ']'
++ for s in '$speed'
++ '[' 100 -gt 10 ']'
++ max_s=100
++ '[' 100 -lt 10 ']'
++ for s in '$speed'
++ '[' 100 -gt 100 ']'
++ '[' 100 -lt 10 ']'
++ for s in '$speed'
++ '[' 1000 -gt 100 ']'
++ max_s=1000
++ '[' 1000 -lt 10 ']'
++ for s in '$speed'
++ '[' 1000 -gt 1000 ']'
++ '[' 1000 -lt 10 ']'
++ MAX_SPEED=1000
++ case "$THROTTLE_SPEED" in
++ THROTTLE_SPEED=10
++ '[' x0 = x1 ']'
$ETHTOOL -s $DEVICE speed $MAX_SPEED 2>&1
+++ /sbin/ethtool -s eth0 speed 1000
++ ret='Cannot advertise speed 1000'
++ exit_status=0
++ log VERBOSE 'Cannot advertise speed 1000'
++ '[' 10 -gt 10 ']'
++ '[' 10 -lt 10 ']'
++ for s in '$speed'
++ '[' 100 -gt 10 ']'
++ max_s=100
++ '[' 100 -lt 10 ']'
++ for s in '$speed'
++ '[' 100 -gt 100 ']'
++ '[' 100 -lt 10 ']'
++ for s in '$speed'
++ '[' 1000 -gt 100 ']'
++ max_s=1000
++ '[' 1000 -lt 10 ']'
++ for s in '$speed'
++ '[' 1000 -gt 1000 ']'
++ '[' 1000 -lt 10 ']'
++ MAX_SPEED=1000
++ case "$THROTTLE_SPEED" in
++ THROTTLE_SPEED=10
++ '[' x0 = x1 ']'
$ETHTOOL -s $DEVICE speed $MAX_SPEED 2>&1
+++ /sbin/ethtool -s eth0 speed 1000
++ ret='Cannot advertise speed 1000'
++ exit_status=0
++ log VERBOSE 'Cannot advertise speed 1000'
++ '[' x1 = x1 ']'
++ '[' -x /usr/bin/logger -a VERBOSE '!=' STATUS ']'
++ '[' VERBOSE = MSG ']'
++ '[' VERBOSE = ERR ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' x0 = x1 ']'
++ '[' VERBOSE = VERBOSE ']'
++ '[' 1 = 0 ']'
++ '[' 0 

Bug#762876: re: bind 9 crash / assertion failure

[S. R. Wright]

On Sat, 27 Sep 2014 23:48:10 -0400 Michael Gilbert  
wrote:

> control: tag -1 moreinfo
>
> Could someone experiencing this please attach configuration files?
> I'm not able to reproduce it with a vanilla installation.
>
> Best wishes,
> Mike
>
>

It pretty reliably crashed for me with the simplest of caching-only name 
servers;  all I needed to do was start bind,  then start web browsing 
and it would trip the assertion failure very quickly.  -- sRw



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

Bug#763005: installation-guide-amd64: website for wheezy leads to jessie installation guide

[Cyril Brulebois]

David Prévot  (2014-09-28):
> Right. There is currently nothing magic to handle what release the
> installation-guide is targeted to, so webmaster@d.o has to update one
> cron script to install it where it belongs when the release changes. If
> there is an in-advance notice before the upload, that’s smooth. If not,
> one has to dig in, and fix the stuff that had been broken (of course, it
> takes more time if nobody sends a notice at all).
> 
> The Jessie manual should be rebuilt and available tomorrow where it belongs.
> 
> Feel free to send patches to avoid the manual handling that has to be
> done every two years, and as such, is well expected to be often forgotten:
> 
> http://anonscm.debian.org/cgit/debwww/cron.git/tree/lessoften-parts/1installation-guide

There are several places where you can find the release name:

kibi@arya:~/debian-installer/manual$ ack-grep jessie
build/buildone.sh
59:manual_release="jessie"

build/build.sh
8:manual_release=${manual_release:=jessie}

build/buildweb.sh
8:manual_release=${manual_release:=jessie}

build/entities/common.ent
14:


I think we tend to update those all at once, but I think I'd go for
common.ent

> (And yes CVS-haters, this one is on Git ;-).

Hah. :)

Busy with d-i things right now, so won't be sending a patch. Maybe later
if nobody beats me to it.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#763054: pcre3: FTBFS on hurd because of stack size problem

[Samuel Thibault]

Samuel Thibault, le Sun 28 Sep 2014 22:22:47 +0200, a écrit :
> Ólafur Jens Sigurðsson, le Sat 27 Sep 2014 15:10:47 +, a écrit :
> > The package fails to build on hurd because the pthread stack size in
> > only 2024 kb instead of the 8192 kb that linux has.
> 
> Well, ideally hurd should be made to get its stack size for ulimit -s
> too. It should be a matter of using getrlimit in libpthread for the
> stack size, and defaulting to the default 2MiB if ulimit -s is not
> defined.

I have now commited this. However, http://savannah.gnu.org/bugs/?43320
prevents it from working.

What we can do is simply make the hurd's libpthread default 8192KiB like
Linux, to avoid differing too much from the Linux defaults and get such
bugs just due to differing defaults.

Samuel


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