On 23.07.24 21:09, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the pax-utils package:
>
> #1076816: pax-utils: pspax crashes with a seccomp violation
Happy to see this getting fixed so fast. Will there be a fix for
book
Package: pax-utils
Version: 1.3.7-1
Severity: important
Tags: patch
X-Debbugs-Cc: mini...@grsecurity.net
Dear Maintainer,
since the switch to meson and enabling seccomp along the way in [1],
pspax is no longer functional and dies with SIGSYS. The cause is a
missing seccomp entry for socket(), as
Package: libxxf86vm1
Version: 1:1.1.4-1+b2
Severity: normal
X-Debbugs-Cc: mini...@grsecurity.net
Dear Maintainer,
After investigating ELF binaries and libraries on Debian systems, I
noticed that libxxf86vm1 uses an overly huge alignemnt for its segments.
This will lead to an unnecessary ASLR degr
Package: libxshmfence1
Version: 1.3-1
Severity: normal
X-Debbugs-Cc: mini...@grsecurity.net
Dear Maintainer,
After investigating ELF binaries and libraries on Debian systems, I
noticed that libxshmfence1 uses an overly huge alignemnt for its segments.
This will lead to an unnecessary ASLR degrada
Package: libxdmcp6
Version: 1:1.1.2-3
Severity: normal
X-Debbugs-Cc: mini...@grsecurity.net
Dear Maintainer,
After investigating ELF binaries and libraries on Debian systems, I
noticed that libxdmcp6 uses an overly huge alignemnt for its segments.
This will lead to an unnecessary ASLR degradation
Package: libatasmart4
Version: 0.19-5
Severity: normal
X-Debbugs-Cc: mini...@grsecurity.net
Dear Maintainer,
After investigating ELF binaries and libraries on Debian systems, I
noticed that libatasmart4 uses an overly huge alignemnt for its
segments. This will lead to an unnecessary ASLR degradat
On Thu, 23 Aug 2018 16:31:37 -0300 Henrique de Moraes Holschuh
wrote:
> Yes, it is much better to wait for a new download to be made available,
> with the mcu-path-license-2018 version of the distribution license
> inside.
>
> The text of this license is the same (or very close to) the older
> li
The plugin package still fails here because it cannot find mpc.h,
included, e.g., from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/builtin.h. That file is
provided by libmpc-dev which, IMHO, gcc-5-plugin-dev should depend on.
Regards,
Mathias
I also do vote for adding gtk2-engines-pixbuf as a dependency to
freeciv-client-gtk as it brings back the old theming the freeciv
client had before my last update. One of the updates in wheezy a few
weeks ago broke the theming and I couldn't figure out why .. until
now. Installing gtk2-engines-pixb
Current upstream version of ike-scan is 1.9 and can be downloaded at:
http://www.nta-monitor.com/tools/ike-scan/download/ike-scan-1.9.tar.gz
It would be nice if this package could be updated to match that version.
Sincerely,
Mathias Krause
signature.asc
Description: OpenPGP digital
Martin Schulze wrote:
> Package: polymer
> Version: current
> Severity: minor
>
> - Description: a port of the KDE style Plastik depending on QT only
> + Description: Port of the KDE style Plastic depending on Qt only
>
> Sorry for the second bug report, but the final ispell run discovered
> that
Johannes Kloos wrote:
> The package description for polymer states that polymer is a port of
> plastik, but it doesn't describe what polymer actually *does*.
>
> Please add a short description.
Quoting the short/long description: it's "a port of the KDE *style*
Plastik". So I would say, it is men
for
`#include ".."' directives or -I- should get undeprecated since no other
option exists to trigger this behavior.
For an example why this is a problem take a look at bug #352859.
Yours sincerely,
Mathias Krause
-- System Information:
Debian Release: testing/unstable
APT prefers
Jeremy Nimmer wrote:
>>The preprocessor from gcc 4.0.x behaves wrong when using the "-iquote"
>>option as recommended by a warning when using "-I-".
>
> The documentation states:
>
> In addition, `-I-' inhibits the use of the directory of the current
> file directory as the first search
7;s available at [1].
I also took a look at the bug mailing list at gcc.gnu.org but haven't
found this bug there. Maybe I'm the only one using this feature to
separate the order of header file inclusion.
I hope this information helps to get this bug fixed soon.
Yours sincerely,
Mathias
15 matches
Mail list logo
