Package: xserver-xspice
Version: 0.1.6-1
Severity: grave
Justification: renders package unusable
See #1038648.
As I wrote there, 0.1.6-1 doesn't fix the problem, but this was
ignored, so I'm sending a new bug report.
The buggy patch is now upstream, but that doesn't make it correct.
I've
Doesn't fix the problem.
Control: tags patch
I think I found the problem. It seems to be
Fix-a-build-error-with-Xorg-master.patch
To be honest, I don't really understand the patch. According to the
comment, instead of just changing one renamed parameter, it changes
the calling conventions at the cost of an unnecessary
Package: xserver-xspice
Version: 0.1.5+git20200331-3
Severity: grave
Justification: renders package unusable
Since upgrading to bookworm, Xspice always crashes when I try to
start it:
Xspice --config xspice.1.conf :25
(EE) Caught signal 6 (Aborted). Server aborting
Full log: xspice.1.log
Siep Kroonenberg wrote:
> The problem was that the test was specifically for a file rather
> than for any filesystem item.
>
> In the updated TL package, the test has been removed altogether
> since there was already a later test for successful generation of a
> temp subdirectory.
>
> The
Package: texlive-pictures
Version: 2020.20210202-3
Severity: grave
File: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu
Classic /tmp write vulnerability: function dir_writable writes to
"/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient
checks.
Harmless demonstration:
%
Hi Salvatore,
> > Thanks for the quick fix!
>
> Just in avoidance of doubt, thanks goes to Matthias, I just fixed the
> BTS metadata as the bug was not closed along with the upload.
Thanks to Matthias then! :)
> >From a security team perspective, we do not plan to release the fix as
> a DSA
Thanks for the quick fix!
However, it's not clear to me if the fix will go to
bullseye-security or at least bullseye-updates or only to testing.
(Is there some way to find this out on the web site or so?)
I need to know because now I have to either wait for the bullseye
package or backport it
Package: bash
Version: 5.1-2+b3
Severity: critical
Justification: breaks unrelated software
Tags: patch upstream l10n
I've reported this bug on bug-bash:
https://lists.gnu.org/archive/html/bug-bash/2022-01/msg0.html
only to learn that it's known and not fixed for months (it was known
before
Package: command-not-found
Version: 20.10.1-1
Severity: grave
Justification: renders package unusable
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917455
Bug #917455 was closed with:
Marked as fixed in versions 20.10.1-1
This is *NOT* the case!
After upgrading to bullseye, which
Package: command-not-found
Version: 18.04.5-1
Severity: critical
Justification: breaks unrelated software
% apt-get update
Hit:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:2 http://archive.raspberrypi.org/debian buster InRelease
Traceback (most recent call last):
File
> On Fri, 29 May 2020 at 09:21, Frank Heckenbach
> wrote:
> > killall fails to kill processes with names longer than 15
> > characters.
> Actually it does. But the comm length has increased for some kernels.
>
> If you're asking it to kill something with anot
Package: psmisc
Version: 23.2-1
Severity: serious
killall fails to kill processes with names longer than 15
characters.
According to the manpage:
-e, --exact
Require an exact match for very long names. If a command
name is longer than 15 characters, the full name may be
> > > Hmm, simply "./autogen.sh && ./configure && make -j" does build it
> > > for me (though with some warnings), using stretch. Does that work
> > > for you? If so, it must be something in the Debian rules; otherwise
> > > it seems to be difference between stable and testing which may be
> > >
> I checked and everything looks all right, but I've been fighting for
> 1+ hours because it cannot generate the ftgl.pdf documentation.
Hmm, simply "./autogen.sh && ./configure && make -j" does build it
for me (though with some warnings), using stretch. Does that work
for you? If so, it must be
> The idea of using both RenderDefault() and RenderBasic() as well as
> the flag, would equally work if you have just Render() and the
> behaviour of one render or the other nested in an "if/else" based on
> the flag. Whatever makes more sense to you. I suggested it because
> in that way it is
> > My suggestion of 2018-11-25 still stands. But if you want me to do
> > my part of it, please do your review quickly and tell me soon
> > (or, if it's indeed necessary for the soft freeze, immediately) to
> > avoid running out of time.
>
> Your plan sounds OK. Changing packages after the
> Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
> escreveu:
> >
> > According to https://release.debian.org/buster/freeze_policy.html:
> >
> > 2019-01-12 - Transition freeze
> >
> > Is there still time yet to get a fix in, or is it FUBAR already
According to https://release.debian.org/buster/freeze_policy.html:
2019-01-12 - Transition freeze
Is there still time yet to get a fix in, or is it FUBAR already?
Frank
Hi Manuel,
> > That seems to me the best solution indeed. So I can offer this:
> >
> > - I add these two new versions for all functions involved (quite a
> > few); we'd just need to agree about naming ("old" and "new" won't
> > do, since in this complicated situation it's not even clear which
Hi,
coming back to my own mail, after thinking about it some more:
: > And I think that the default would have to be the old behaviour, yes,
: > because after many years behaving in that way the applications must
: > have learned to adapt or cope, and no one knows that they have to use
: > a
Hi,
> Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach
> escreveu:
> >
> > > I think that we should revert this change for the time being, though,
> > > because if it was working in this way for about a decade and the
> > > programs using FTG
Hi,
> I think that we should revert this change for the time being, though,
> because if it was working in this way for about a decade and the
> programs using FTGL worked "fine" despite having some bug there,
Sorry, they did *NOT* all work fine, see my bug report. And if we
apply my patch from
> It's not yet in the upstream git repository (I submitted the patch
> through their bug tracker, but someone from upstream has to check it and
> apply it), but in our (the Debian package's) git repository.
>
> You can find the patch here:
>
>
> I debugged it and found the problem. It was a simple indexing problem
> that seemed to have slipped away during quite some time because of a
> lucky memory layout: The pointer resulting from the wrong indexing
> points to the stack and therefore to valid memory (in terms of memory
>
Package: vorbis-tools
Version: 1.4.0-6
Severity: grave
File: /usr/bin/vcut
Justification: renders package unusable
Sorry for the brief description, but for what I can tell, that's
really it. I tried various cases, and vcut always seems to just
segfault. Here's one example:
% head -c 50
I believe that it should do something saner instead of overwriting.
I must disagree. If resolvconf is absent, overwriting is the most sane, or
least insane thing to do. There just is not a lot that can be done without
mediation for writing the resolver configuration.
Here I must
Control: severity -1 normal
# mkdir 1 2 3
# unionfs-fuse 1:2 3
fuse: warning: library too old, some operations may not not work
According to the dependencies it requires libfuse2 = 2.8.1.
I have 2.9.0-2 installed, so how can it be too old?
But indeed some operations don't work. In
Package: unionfs-fuse
Version: 0.24-2.2
Justification: renders package unusable
Severity: grave
# mkdir 1 2 3
# unionfs-fuse 1:2 3
fuse: warning: library too old, some operations may not not work
According to the dependencies it requires libfuse2 = 2.8.1.
I have 2.9.0-2 installed, so how can it
Package: fgo
Version: 1.3.1-2
Justification: breaks unrelated software
Severity: critical
The version in wheezy contains:
Recommends: flightgear (= 2.0.0)
But flightgear does not exist in wheezy.
I tried to get its sources from testing to build it myself, but it
didn't work:
% apt-get source
Akim Demaille wrote:
Indeed, if you want both to be in the same namespace, %define api.prefix
should do what you want.
Note that the C++ output supports %define namespace, in
which the generated code is put.
Thanks, seems like we have several viable options here. (Though I'd
have to check
PS:
Bill Allombert wrote:
When you allow to compile C files with a C++ compiler, it is customary to use
extern C, otherwise you ABI depend on the compiler.
It probably does, but for us that's not relevant since we compile
everything with GCC anyway.
Frank
--
To UNSUBSCRIBE, email to
Bill Allombert wrote:
A way to fix the problem could be to add
#ifdef __cplusplus
extern C {
#endif
...
#ifdef __cplusplus
}
#endif
in the generated parse.tab.h.
This is not correct for people who do not want this guy to be
in extern C.
I agree, but I
Bill Allombert wrote:
On Thu, Oct 18, 2012 at 06:52:41PM +0200, Frank Heckenbach wrote:
Bill Allombert wrote:
We do compile our Bison output with g++ (yes, we should probably use
the C++ skeleton, but we haven't gotten around to it yet), and we
don't use extern C -- in fact we use two
34 matches
Mail list logo
