Benjamin Barenblat wrote:
> On Wednesday, July 16, 2025, at 3:49 PM +0200, Frank Heckenbach wrote:
> > I do wonder if this fine-grained splitting is really necessary --
> > shouldn't -Wl,--as-needed already take care of only linking what's
> > needed?
>
>
> On Sunday, July 6, 2025, at 12:50 AM +0200, Frank Heckenbach wrote:
> > Could libabsl be built with ABSL_USES_STD_STRING_VIEW,
> > ABSL_OPTION_USE_STD_OPTIONAL, ABSL_OPTION_USE_STD_VARIANT and
> > similar settings?
>
> Yes, but it's not going to happen i
Package: libbctoolbox-dev
Version: 5.3.105-1
Severity: normal
Tags: patch
/usr/include/bctoolbox/logging.h: In function "pumpstream&
operator<<(pumpstream&&, _Tp&&)":
/usr/include/bctoolbox/logging.h:392:16: error: cannot bind non-const lvalue
reference of type "pumpstream&" to an rvalue of type
Package: imagemagick-7.q16
Version: 8:7.1.1.43+dfsg1-1
Severity: normal
File: /usr/bin/convert-im7.q16
% cat test.svg
% convert test.svg x.png
** (inkscape:2240392): WARNING **: 23:09:23.167: Failed to wrap object of type
'PangoFT2FontMap'. Hint: this error is commonly caused by failing to call
Package: pkgconf
Version: 1.8.1-4
Severity: important
Tags: patch
% time pkgconf --cflags --libs re2 > /dev/null
real0m2,902s
user0m2,884s
sys 0m0,008s
re2 uses libabsl which is quite a monster, yet it only has some 100
.pc files. Processing them shouldn't take nearly as long.
This p
Package: libabsl-dev
Version: 20240722.0-4
Severity: normal
Could libabsl be built with ABSL_USES_STD_STRING_VIEW,
ABSL_OPTION_USE_STD_OPTIONAL, ABSL_OPTION_USE_STD_VARIANT and
similar settings?
// ABSL_OPTION_USE_STD_STRING_VIEW
//
// This option controls whether absl::string_view is implemented
Package: file
Version: 1:5.46-5
Severity: normal
I got some MP3 files which were apparently created by LAME that
"file" detects only as "data".
I'm not completely sure if the files are valid, but apparently they
are generated like this, and "ffprobe" and "mpv" do recognize them.
I can't attach t
Package: libc-bin
Version: 2.36-9+deb12u4
Severity: normal
File: /usr/bin/iconv
% printf '\xc3\xa4' | iconv -futf8 -tascii
iconv: illegal input sequence at position 0
- First, according to the FSF's own coding standards
(https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html),
it shoul
Hello Georges,
> thank you for your response.
I was busy otherwise recently. I suppose, this is still open, isn't it?
> cron is a key command for UNIX systems, and it is supposed to remain
> lightweight and efficient. This is why it does not implement the mailing
> features, and relies on other
Package: librsvg2-bin
Version: 2.54.7+dfsg-1~deb12u1
Severity: normal
File: /usr/bin/rsvg-convert
% cat test.svg
ABC
% rsvg-convert -f pdf -o test.pdf test.svg
The resulting pdf has the outline (stroke) correctly, but the filled
letters are spaced without respecting the scale, see attached
scre
Hello,
> I am the new maintainer for cron package, since a few months. Please can
> one elaborate a little longer about use cases where too long lines are a
> problem?
Thanks for picking up this issue again. I'm not the original
reporter, but also effected, as I wrote in my comment last year.
SM
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 already
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 "s
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
https
> > You added a "Requires.private" in the .pc, but that doesn't help.
> > "Requires" is required (sic!) because a program that links to ortp
> > apparently must also link to bctoolbox.
>
> Dude, did you not see that the string "bctbx_set_log_level_mask" does
> not occur anywhere in your program?
Package: libortp-dev
Version: 1:5.1.64-2
Severity: normal
> This is an automatic notification regarding your Bug report
> which was filed against the libortp-dev package:
>
> #994437: libortp: missing -lbctoolbox
>
> It has been closed by Debian FTP Masters
> (reply to Bernhard Schmidt ).
>
> Th
Package: lintian
Version: 2.116.3
Severity: normal
I get the warning "build-depends-on-versioned-berkeley-db
Build-Depends:libdb5.3-sql-dev"
My package used to depend on libdb-sql-dev, but this package doesn't
exist anymore in bookworm, so I think I have to depend on
libdb5.3-sql-dev now, don't
Package: coreutils
Version: 8.32-4+b1
Severity: normal
===
% install -C -p x y
install: options --compare (-C) and --preserve-timestamps are mutually exclusive
Try 'install --help' for more information.
% install --help
Usage: install [OPTION]... [-T] SOURCE DEST
or: install [OPTION]... SOURCE
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 update
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:
% mkfi
Forwarded: https://jira.mariadb.org/browse/MDEV-30046
spamprobe-1.4d/src/parser/MbxMailMessageReader.cc
@@ -85,6 +85,7 @@ bool MbxMailMessageReader::readMBXRecord
cerr << "MBX: SKIPPED DELETED MESSAGE" << endl;
}
}
+ return true;
}
OWNED MailMessage *MbxMailMessageReader::readMessage()
Index: spamprobe-1.4d/src/p
Package: mariadb-server-core-10.5
Version: 1:10.5.15-0+deb11u1
Severity: important
Using the MySQL interface, these statements:
DROP TABLE IF EXISTS t;
CREATE TABLE t (s BLOB, n INT, UNIQUE (s));
INSERT INTO t VALUES ('Hrecvx_0004ln-00',1), ('Hrecvx_0004mm-00',1);
INSERT INTO t VALUES ('Hrecvx_00
Package: spamprobe
Version: 1.4d-14+b2
Severity: important
Tags: upstream
I posted this upstream at https://sourceforge.net/p/spamprobe/bugs/40/, but as
expected got no reaction there.
Is anyone here maintaining spamprobe anymore, or am I on my own?
---
I had used spamprobe for many years with
The limit according to RFC 2822 is 998 characters.
Current versions of exim4, e.g., enforce this limit.
So if you do wrapping, you might as well use the correct limit.
Of course, wrapping slightly alters the content.
If this is deemed inacceptable, you might need to MIME encode the
message (QP o
Package: gdb
Version: 10.1-1.7
Severity: normal
>From a coomplicated gdb session
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003638):
(gdb) p (float*)$2
$29 = (float *) 0x556e612bd530
(gdb) watch *(float*)$29
Hardware watchpoint 10: *(float*)$29
(gdb) d 10
[...]
(gdb) watch *(float*)$30
W
Package: swh-plugins
Version: 0.4.17-2+fh1
Severity: important
Tags: upstream patch
mbeq_1197.xml:
float coefs[FFT_LENGTH / 2];
[...]
coefs[0] = 0.0f;
for (bin=1; bin < (FFT_LENGTH/2-1); bin++) {
coefs[bin] = ((1.0f-bin_delta[bin]) * gains[bin_base[bin]])
+ (bin_de
Package: libre2-dev
Version: 20210201+dfsg-1
Severity: normal
re2.pc contains "-std=c++11". This conflicts with other "-std"
options, especially if one wants to use a newer standard (which
otherwise works with libre2, as indicated by its support for
string_view, e.g.).
In order to make sure it's
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 via
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 mys
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 b
Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal
File: /usr/bin/rsvg-convert
Text with small font-size is rendered incorrectly. In the attached
exmples, letters are rendered on top of each other instead of next
to each other.
It was rendered correctly under buster (see font-tiny-2.44
I wrote:
: Still broken in stable and testing.
Still broken in current stable, testing and unstable.
: upstream 4.1 still works out of the box.
Still does.
: Does anyone read these bug reports at all?
Apparently not. :(
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 inc
Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal
% cat a.svg
% rsvg-convert -f pdf -o a.pdf a.svg
%
The resulting PDF (attached) contains a thin line across the part of
the path that should not be drawn.
-- System Information:
Debian Release: 11.0
APT prefers stable-security
Package: libortp-dev
Version: 1:4.4.13-2
Severity: normal
File: libortp
% cat a.c
#include
int main ()
{
ortp_init ();
ortp_set_log_level_mask (ORTP_LOG_DOMAIN, ORTP_FATAL);
}
% gcc a.c `pkg-config --cflags --libs ortp`
/usr/bin/ld: /tmp/ccnMlrim.o: undefined reference to symbol
'bctbx_set
Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal
% cat bogus.svg
% rm -f bogus.pdf
% rsvg-convert -f pdf -o bogus.pdf bogus.svg
Error reading SVG:XML parse error: error code=201 (3) in (null):1:71: Namespace
prefix xlink for href on use is not defined
% ls -la bogus.*
-rw--- 1
Package: exim4
Version: 4.92-8+deb10u5
Severity: normal
When I tried to send a mail, exim sent me this bounce:
Subject: Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one
Hi Marc,
> Is it ok for you if I close this bug?
Sure.
> > Most likely unrelated, but one thing I did notice when checking the
> > code is that sudo_mkdir_parents might UB if path is an empty string,
> > since it first does "char *slash = path; strchr (slash + 1, '/');".
> >
> > Now I don't kno
> > On a system with disk errors, which had therefore remounted its
> > file systems read-only, I tried to sudo in order to do further
> > diagnostics as root, but sudo crashed with a segfault.
>
> I tried reproducing this with sudo 1.8.27-1+deb10u3, on a clean file
> system, mounted read-only, on
> This was a bug in X server 1.19 fixed in 1.19.4 with
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/d8f63717e05ae8d820ceae74216916ebd180441d
>
> Unfortunately this bug is in the X server in stretch and won't get fixed
> there now that stretch is LTS, but the versions in buster and later
> You seem to forget that
What you (and apparently many other maintainers) seem to forget is:
> a) we are all volunteers
Most bug reporters (including me) are volunteers too.
Well managed projects treat good bug reports as a valuable resource
to increase the quality of the project. Others consi
Package: sudo
Version: 1.8.27-1+deb10u2
Severity: normal
On a system with disk errors, which had therefore remounted its
file systems read-only, I tried to sudo in order to do further
diagnostics as root, but sudo crashed with a segfault.
I think it should be possible (perhaps with a special opti
> you have reported a bug against Linhone 3.12 or earlier. This version
> has been deprecated upstream for a couple of years
Well, I did report the bug many years ago, so ...
> We are sorry we could not deal with your bug report in time.
s/could not/did not choose to/ !
You certainly could have
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 "/usr/li
> It's a minor issue of a missing database that fixes itself the
> next time you run apt update.
I now found out, it does *NOT* fix itself. In contrast, it unfixes
itself! Even when I correct the permissions manually, they're wrong
some time later (probably after the next upgrade).
So the bug sti
Still broken in stable and testing.
upstream 4.1 still works out of the box.
Does anyone read these bug reports at all?
> 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 an
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
Package: swh-plugins
Version: 0.4.17-2
Severity: normal
Tags: upstream patch
The bug from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781997
has reappeared!
The same test program as given there fails again, even though my
patch from then has been applied.
I suppose this is due to more aggr
Package: gpg
Version: 2.2.12-1
Severity: normal
Tags: upstream
I got a number of "invalid signatures" recently, and when I
investigated, I found that the "--textmode" option apparently has no
effect during verify operations, unlike what I expected, so I had to
manually convert the input to CR/LF t
Can confirm. Present version in buster doesn't work,
upstream 4.1 works out of the box.
> ack. I misremembered. It's funny that it works fine for its
> entire lifetime in Ubuntu, and only Debian users seem to be
> using different umasks for root. Kind of a niche thing.
Though it's getting off-topic, a reason may be that Ubuntu is used
more often on personal desktops (where, honestly,
> It's a minor issue of a missing database that fixes itself the
> next time you run apt update.
1. If it's so easy, why wasn't it mentioned before?
2. Didn't work for me, neither "apt update", nor "apt-get update"
(which I normally use).
3. After some digging, I found a solution that actuall
I get the same crash every time!
Is there any workaround? Otherwise, it seems the package is totally
broken. Shouldn't this be "grave" then?
And why include it in the stable release at all if it doesn't work?
I've seen packages banned for less severe reasons.
Apparently, the problem has been kno
Package: dvb-apps
Version: 1.1.1+rev1500-1.1
Severity: normal
File: /usr/bin/alevt
Tags: patch upstream
The font size of alevt is very small on modern display sizes and
resolutions.
The same problem was reported on another distribution over 10 years
ago (https://bugzilla.redhat.com/show_bug.cgi?i
Package: libreoffice
Version: 1:5.2.7-1+deb9u5
Severity: normal
This is the same bug as #853149 which was closed on a formality
(reported against the wrong package due to confusing naming -- a
base is a base and a database is a database, isn't it ... anyway).
How to reproduce:
- Start libreoffic
> > > 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
> > > wo
> 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 s
> 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 ea
> > 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 relea
> 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 diff
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 FTGL work
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 7
Hi Evgeny,
> >After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text
> >rendering in Megaglest is broken. Text is shown correctly in menus, but text
> >displayed in the game itself is replaced by white rectangles.
>
> Thanks for the report.
>
> Any idea of what's going on, F
Package: xserver-xorg-input-elographics
Version: 1:1.4.1-1
Severity: normal
Tags: patch
When reading from the touchscreen device returns 0 (EOF), the driver
goes into an endless loop of poll and read. This locks up the Xorg
server, and when trying to kill it with -9, it hangs the whole
system (no
Package: xserver-xorg-input-elographics
Version: 1:1.4.1-1
Severity: normal
Tags: patch
See subject.
Reason: ELO_MAX_WAIT is microseconds, but xf86WaitForInput expects
milliseconds.
Patch (line numbers after #776990):
--- src/xf86Elo.c
+++ src/xf86Elo.c
@@ -459,7 +459,7 @@
* timeout and e
I wrote:
> Manuel A. Fernandez Montecelo wrote:
>
> > Now, what I can offer is that if you are interested in the package, want
> > to take responsability for the changes, and want to fix the problems in
> > the long term (including maybe switching to the fork in github, which
> > seems more lively
Manuel A. Fernandez Montecelo wrote:
> So basically the package has been unmaintained all these years, and
> still is. Sorry that your patches were ignored, but it seems that the
> maintainers are simply not available, and the rest of the Debian folks
> don't always take a look to packages unless
Package: flightgear
Version: 1:2016.4.4+dfsg-3+deb9u1
File: /usr/games/fgfs
Severity: normal
When receiving UDP data too early, fgfs segfaults after giving the
message:
AI error: updating aircraft without traffic record at ...
I've traced the segfault to trafficcontrol.cxx:984
At this point,
FYI, my drive that triggered this bug has now broken down, probably
just the optical/mechanical part (not worth investigating); it's
still seen by the computer and can probably be used to debug it if
someone's interested. (So far it doesn't seem so to me, and I won't
care about this bug now either.
Package: bash
Version: 4.3-11+deb8u1
Severity: normal
In the following program, bash hangs when interrupting (Ctrl-C) the
read. It seems to depend on all the previous statements, including
"wait -n" and the pipe.
#!/bin/bash
: &
wait -n
: | :
read
strace shows the following:
read(0, 0x6fe4c0, 1
> 3) incompatible VOC files: upstream denies that there is a problem here.
> also i agree with upstream that the error message is pretty clear:
> "Error in VOC file, incompatible VOC sections" doesn't say "your VOC
> file is broken" but instead "it is incompatible with my notion of VOC
> files due
I got the same problem, only on some channels though, e.g. ZDF using
this input:
[CH34]
DELIVERY_SYSTEM = DVBT2
FREQUENCY = 57800
BANDWIDTH_HZ = 800
MODULATION = QAM/16
*** Error in `dvbv5-scan': malloc(): memory corruption: 0x00fe13c0 ***
I did some debugging with gdb and valgri
> On Wed, 21 Sep 2016, Frank Heckenbach wrote:
> > I've just experienced another such case after gcc-4.9 was "removed"
> > (#785249, which was reported upstream, and probably a whole more,
> > some of which are probably lost now).
>
> These all sti
I've just experienced another such case after gcc-4.9 was "removed"
(#785249, which was reported upstream, and probably a whole more,
some of which are probably lost now).
PS: It's quite ironic that a bug report in which I also complained
about so many Debian bug reports sitting idly in the bug da
Hi,
> On Sat, Sep 03, 2016 at 10:57:13PM +0200, Frank Heckenbach wrote:
> >
> > Will this fix be pushed by security.debian.org as well now, or will
> > I have to install it manually?
>
> It will be pushed via security.debian.org archive "soon", since we
>
Hi,
> On 02/09/16 06:31, Salvatore Bonaccorso wrote:
> > On Thu, Sep 01, 2016 at 12:14:02PM +0100, Robert Shearman wrote:
> >> Alternatively, I'm pretty sure that adding the resulting changes to skel.c
> >> in 0006-CVE-2016-6354.patch would work too.
> >
> > I uploaded new varaiants of the builds
> I suppose
> https://github.com/ImageMagick/ImageMagick/commit/f6242e725c819a69bee2a444f8e4a3c7718b2b3f
>
> Fix it. If so plezse merge this bug with the other one régression about pdf
Yes, this seems to fix my problem, thanks.
Frank
> On Wed, Aug 31, 2016 at 8:42 AM, Bastien ROUCARIES
> wrote:
>
> > Patches are needed for a security point of view but it is likely a
> > problem of backport intereaction.
> >
> > Could you help by pin point the problem.
> >
> > as root install a few package needed for imagemagick compilation:
>
Package: flex
Version: 2.5.39-8+deb8u1
Severity: normal
After this update, I get the following warning when compiling the
flex generated code with gcc, which I didn't get before:
scan.cpp: In function âint yy_get_next_buffer(yyscan_t)â:
scan.cpp:758:18: error: comparison between signed and un
Package: dvb-apps
Version: 1.1.1+rev1500-1+fh1
Severity: normal
File: /usr/bin/alevt
Tags: patch
progtbl has a size of 16 (actually, only 15 are used due to the
check "progcnt >= sizeof(progtbl)/sizeof(progtbl[0])"; maybe this
should be ">", unless the last entry is needed as a terminator).
Anywa
Hi Martin,
> Thank you for your bug report!
>
> Judging from the code that reproduces the bug (two subsequent seeks to
> 0) and from the related vorbis code you are mentioning, this sounds a
> lot like #782831, which was fixed in 1.3.4-3. Could you confirm or
> refute that theory by testing yo
Package: libvorbisfile3
Version: 1.3.4-2
Severity: important
ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes. I've
observed it in some situations, below is a very simple one to
reproduce. It's an important problem to me, because (unless fixed or
you can tell me exactly when seeking will
> On 28 March 2016 at 12:18, Frank Heckenbach wrote:
> > Felipe Sateler wrote:
> >
> >> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> >> Could you please upgrade to that version and try using the
> >> After=swap.target workar
Felipe Sateler wrote:
> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> Could you please upgrade to that version and try using the
> After=swap.target workaround?
Actually, I'm not sure if it works. I could not reproduce the bug
now (but it wasn't 100% reproducible anyway)
Package: bash
Version: 4.3-11+b1
Severity: normal
% cat bash-bug
#!/bin/bash
if true; then
$[()]
exit
fi
echo "Should not get here."
% ./bash-bug
./bash-bug: line 4: (): syntax error: operand expected (error token is ")")
Should not get here.
The error is correct, but after that it should c
> Nicht genügend Hauptspeicher verfügbar
>
> at shutdown time.
>
> Thanks for the reporting and analysis so far!
>
> @Frank Heckenbach: I would love to give the "workaround" a try, but I
> don't fully understand, what will be achieved by
>
> > ExecStop
> 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
> management
> 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:
>
> https://anonscm.debian.org/cgit/pkg-xiph/vorbis-tool
Package: libspice-server1
Version: 0.12.5-1+deb8u2
Severity: normal
Tags: patch
When running KDE in Xspice, the cursor disappears.
To reproduce, I start the server like this:
#!/bin/sh
set -e
export DISPLAY=:30
zcat /usr/share/doc/xserver-xspice/spiceqxl.xorg.conf.example.gz >
/tmp/xspice.conf
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 /dev/z
Hi Jort,
> Great comment and recommendation. I was using SB04 and experienced the 90
> second boot delay. Workaround was functioning as described before, however
> udev rules might easily get overwritten so it's not an ideal solution.
>
> I have a dual boot OS.
> What I did:
> Booted to windows a
> > This seems to work. However, given that this single line is now >1
> > KB and more than 3 times as long as my work-around service, and
> > heavily depends on the system configuration, I doubt whether it's
> > actually less hackish. (I do occasionally change my swap partitions.
> > I also build
> Due to the other bug I linked, this may not be sufficient. Please list
> all the swap units listed in
>
> % systemctl list-units '*.swap'
>
> You'll see that there are multiple units each of the different ways
> you can access the underlying partition (by uuid, did, wwm and sdX
> name).
>
> I
> What if instead of this service, you add an:
>
> After=swap.target
>
> To your tmp.mount ?
Doesn't work. Also, systemctl still lists tmp.mount before the swap
targets, which means (I suppose) it will be stopped after them.
I thought maybe swap.target is just a virtual target that depends on
t
1 - 100 of 239 matches
Mail list logo
