Bug#1056569: libbrotli-dev: libbrotlidec.a corrupted due to c-p error in 0001-build-static-libraries-by-default.patch
Package: libbrotli-dev
Version: 1.1.0-1
Severity: normal
Dear Maintainer,
libbrotlidec.a is unusable in brotli 1.1.0-1 since it is identical to
libbrotlicommon.a
This happened because patch 0001-build-static-libraries-by-default.patch seems
to contain
a copy paste error:
+add_library(brotlicommon-static STATIC ${BROTLI_COMMON_SOURCES})
+add_library(brotlidec-static STATIC ${BROTLI_COMMON_SOURCES})
+add_library(brotlienc-static STATIC ${BROTLI_ENC_SOURCES})
I rebuild the package with the line of brotlidec-static changed to
BROTLI_DEC_SOURCES
and the library is usable again.
I caught the problem because I tried to link libfreetype statically
which required libbrotlidec.a
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libbrotli-dev depends on:
ii libbrotli1 1.1.0-1
libbrotli-dev recommends no packages.
libbrotli-dev suggests no packages.
-- no debconf information
Bug#970419: lilyterm: No longer starts (likely related to VTE changes)
Had the same assertion in vte_terminal_spawn_sync, happens in Upstream too. Dug around the envv Pointer, _vte_pty_check_envv does not like empty entries. src/notebook.c is constructing the envv Pointer in environ_str and later copies it to new_environs. Around line 150 there is a '\t' being pushed into environ_str but the following append of the TERM envvar is eventually ifdef'ed. When COLORTERM is forced-pushed into environ_str another '\t' will be prefixed without checking environ_str again. So unless you compile with ENABLE_SET_EMULATION there will be a lone '\t' in environ_str which will later be translated into an empty envv entry. I supposed the check for non-empty environ_str should be within the ifdef as well before the COLORTERM append. I attached a quick'n'dirty patch. But now that I look at it again (7 hours later), it would also work to leave the code as is but hardcode a '\t' after the TERM append and remove the hardcoded '\t' from COLORTERM instead. E.g.: g_string_append_printf (environ_str, "TERM=xterm"); to g_string_append_printf (environ_str, "TERM=xterm\t"); etc and g_string_append_printf (environ_str, "\tCOLORTERM=lilyterm"); to g_string_append_printf (environ_str, "COLORTERM=lilyterm"); I'll leave that for upstream to figure out ;-) Hope this helps someone. Description: Prevent empty environ_str entry Author: Philipp Wolski Bug-Debian: https://bugs.debian.org/970419 Last-Update: 2020-10-14 Index: lilyterm-0.9.9.4+git20150208.f600c0/src/notebook.c === --- lilyterm-0.9.9.4+git20150208.f600c0.orig/src/notebook.c +++ lilyterm-0.9.9.4+git20150208.f600c0/src/notebook.c @@ -148,14 +148,14 @@ struct Page *add_page(struct Window *win environ_str = g_string_append(environ_str, "\t"); g_string_append_printf (environ_str, "%s", user_environ); } + +#ifdef ENABLE_SET_EMULATION #ifdef SAFEMODE if (environ_str && environ_str->len) #else if (environ_str->len) #endif environ_str = g_string_append(environ_str, "\t"); - -#ifdef ENABLE_SET_EMULATION # ifdef SAFEMODE if (win_data->emulate_term == NULL) g_string_append_printf (environ_str, "TERM=xterm"); @@ -163,8 +163,15 @@ struct Page *add_page(struct Window *win # endif g_string_append_printf (environ_str, "TERM=%s", win_data->emulate_term); #endif + +#ifdef SAFEMODE + if (environ_str && environ_str->len) +#else + if (environ_str->len) +#endif + environ_str = g_string_append(environ_str, "\t"); // set colorterm - g_string_append_printf (environ_str, "\tCOLORTERM=lilyterm"); + g_string_append_printf (environ_str, "COLORTERM=lilyterm"); // Setting the VTE_CJK_WIDTH environment //
Bug#904749: make: patch of arscan.c fails dependency testing
Hi, the new patch looks good. It also passes the se_main compile and an entire rebuilt of the project. Thank you ! > Although alloca(INT_MAX) is not going to well! Reminds me of a popular song: "(Don't) Fear the OOM-Reaper" with the background vocals singing "just add more hardware"... Philipp Wolski
Bug#904749: make: patch of arscan.c fails dependency testing
(pulled the gmail joker to get rid of the signature) Sorry me again, It just so came to me: name_len notwithstanding, name_off==0 might actually be valid as a pointer offset (since the if is denying name_off<1) ---- Philipp Wolski
Bug#904749: make: patch of arscan.c fails dependency testing
(I hope this mail is sent as text, the corporate mailserver is kinda wonky and the signatures are applied by administrative rule, though I do my best to tinker with the clients settings to remove it.) Hi, I tested your patch and although it looks logically fine it would not work. I'm sorry for not including an example but I frankly don't know how to reproduce this but I suspect you need to create an a file with filenames>16 chars and get ar to map them. It happens only with one of eight libraries and the whole built system is ancient legacy stuff. The lib is the largest of course, 252 objects with an average filename length of 20 chars. Actually I tinkered around and finally added a printf and got this in your name_len check (line 678): name_len=18 name=DlfRemoveControl.o name_off=18 ARNAME_MAX=16 name_off is probably a coincidence. ARNAME_MAX is 16 due to ar_hdr.ar_name[16] in ar.h (strangely on Android ARNAME_MAX is hardcoded to 255 by the original patch in arscan.c) After reading the comments in this ifdef riddled code I'm not convinced that checking the name_len againt ARNAME_MAX ist correct in the is_mapped part. An earlier part above line 652 comments how traditionally the names are only 14 characters, while the namemap part sets long_name=1 and the comment hints to a GNU addition. This goes for the later(BSD?) code as well where name is actually alloc'ed to a potentially larger size than namebuf can hold. I don't believe (yeah "believe", no idea how this works) namebuf nor ar_name are actually used for those mapped names. Therefore I question that name_len should check against the max size a "mapped name" is allowed to be instead of ar_hdr size. Any idea where this can be found? Or am I completely off? (can't find any reference to ar being limited to 16 chars per se though, and removing the name_len check still works without segfault) I admit I haven't looked up the cause for the original name_len check patch since the upstream tar does not check it, so I might be noisy, sorry. Fun fact, make actually quits with "no rule to make target ../gen/gnmt.a(EnMeasOrig.o)" right after the above printf, These are the first lines of the dep file: se_main: //usr/lib/x86_64-linux-gnu/libm-2.27.a se_main: ../gen/gnmt.a(EnMeasOrig.o) se_main: ../gen/gnmt.a(EnMeasType.o) se_main: ../gen/gnmt.a(EnTapType.o) se_main: ../gen/gnmt.a(gnmt.o) [this goes on for a lot more .o, though se_main does not even use the A to D files like DlfRemoveControl ] -------- Philipp Wolski - KISTERS AG - Haselriege 13 - 26125 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -158 | Fax: +49 441 93602 -222 | E-Mail: philipp.wol...@kisters.de | WWW: http://www.kisters.de Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Bug#904749: make: patch of arscan.c fails dependency testing
Package: make Version: 4.2.1-1.1 Severity: important Dear Maintainer, we are using dependency files when static linking .a file build with ar -U. I noticed that some libraries failed with "no rule to make target xxx.a(yyy.o)" which would change when I moved the o-files around within the lib. It did not happen with the upstream make-4.2.1 tar-ball By bisecting the patches applied I found a patch to arscan.c to be the culprit. Around line 669 of the patched arscan.c file it reads: int name_off = atoi (name + 1); if (name_off < 1 || name_off > ARNAME_MAX) goto invalid; name = namemap + name_off; I recon name_off is a pointer index which is added to the namemap pointer. In this case, the check for name length violation does/should not apply here, or must be safeguarded differently. Removing the if let us compile again. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages make depends on: ii libc6 2.27-5 make recommends no packages. Versions of packages make suggests: pn make-doc -- no debconf information -------- Philipp Wolski - KISTERS AG - Haselriege 13 - 26125 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -158 | Fax: +49 441 93602 -222 | E-Mail: philipp.wol...@kisters.de | WWW: http://www.kisters.de Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Bug#867175: Supplied Patch for tigervncserver wrapper does not handle rfbport
Did crawl through the code and kind of figured out how it is supposed to work.
Turns out rfbport was passed through as misc option and not used in the wrapper
at all.
Attached a debdiff Patch for tigervncserver to include rfbport.
Not a Perl programmer mind you...
Hopefully the attachment works, never tried this from shell before.
Philipp Wolski - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters |
Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -158 | Fax: +49 441 93602 -222 | E-Mail:
philipp.wol...@kisters.de | WWW: http://www.kisters.de
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.diff -Nru tigervnc-1.7.0+dfsg/debian/changelog tigervnc-1.7.0+dfsg/debian/changelog
--- tigervnc-1.7.0+dfsg/debian/changelog 2017-04-09 16:38:13.0 +0200
+++ tigervnc-1.7.0+dfsg/debian/changelog 2017-07-14 15:38:26.0 +0200
@@ -1,3 +1,12 @@
+tigervnc (1.7.0+dfsg-8) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Added rfbport to supported commandline arguments for
+tightvncserver wrapper (closes: #867175)
+
+ -- Philipp Wolski <philipp.wol...@kisters.de> Fri, 14 Jul 2017 15:38:26 +0200
+
tigervnc (1.7.0+dfsg-7) unstable; urgency=high
[ Joachim Falk ]
diff -Nru tigervnc-1.7.0+dfsg/debian/helpers/usr/bin/tigervncserver tigervnc-1.7.0+dfsg/debian/helpers/usr/bin/tigervncserver
--- tigervnc-1.7.0+dfsg/debian/helpers/usr/bin/tigervncserver 2017-04-09 16:38:13.0 +0200
+++ tigervnc-1.7.0+dfsg/debian/helpers/usr/bin/tigervncserver 2017-07-14 15:26:40.0 +0200
@@ -691,7 +691,11 @@
my $vncPort= 5900 + $options->{'displayNumber'};
my $desktopLog = ($options);
my $pidFile= ($options);
-
+
+ if ($options->{'rfbport'}) {
+$vncPort = $options->{'rfbport'};
+ }
+
# Make sure the user has a password if required.
($options);
# Make sure the user has a x509 certificate if required.
@@ -791,7 +795,7 @@
{
my $i = 300;
for (; $i >= 0; $i = $i-1) {
- last if (5900 + $options->{'displayNumber'});
+ last if ($vncPort);
if ($xvncServerPid == waitpid($xvncServerPid, WNOHANG)) { $i = -2; last; }
usleep 10;
}
@@ -947,6 +951,7 @@
$prefix."[-xdisplaydefaults]Get geometry and pixelformat from running X\n".
$prefix."[-wmDecoration ] Shrink geometry from xdisplaydefaults by dim\n".
$prefix."[-localhost yes|no]Only accept VNC connections from localhost\n".
+$prefix."[-rfbport port]TCP port to listen for RFB protocol\n".
$prefix."[-httpPort port] Port of internal http server\n".
$prefix."[-baseHttpPort port] Calculate http port from base port + display nr\n".
$prefix."[-fg] No daemonization and\n".
@@ -1039,6 +1044,7 @@
pixelformat => undef,
getDefaultFrom => undef,
rfbwait => 3,
+ rfbport => undef,
localhost => undef,
SecurityTypes =>
undef, # later derived depening on localhost setting
@@ -1213,6 +1219,7 @@
'X509Key=s' => \$opts{'X509Key'},
'X509Cert=s' => \$opts{'X509Cert'},
'I-KNOW-THIS-IS-INSECURE' => \$options->{'I-KNOW-THIS-IS-INSECURE'},
+ 'rfbport=i' => \$options->{'rfbport'},
);
(!$rc) if (!$rc || $opts{'help'});
@@ -1265,6 +1272,7 @@
push @cmd, "-xstartup", $opts{'vncStartup'} if !$opts{'noxstartup'} && defined $opts{'vncStartup'};
push @cmd, "-autokill" if $opts{'autokill'};
push @cmd, "-httpPort", $options->{'httpPort'} if ($options->{'httpPort'});
+push @cmd, "-rfbport", $options->{'rfbport'} if ($options->{'rfbport'});
push @cmd, "-baseHttpPort", $options->{'baseHttpPort'} if ($options->{'baseHttpPort'});
push @cmd, "-localhost", $options->{'localhost'} if defined $options->{'localhost'};
push @cmd, "-useold" if $opts{'useold'};
Bug#867175: tigervnc-standalone-server: tigervncserver wrapper does not handle rfbport when waiting for child
Package: tigervnc-standalone-server
Version: 1.7.0+dfsg-7
Severity: normal
Dear Maintainer,
the tigervncserver wrapper helper will not find its child when
it is invoked with -rfbport.
Example: vncserver :3 -rfbport 5913
~$ vncserver :3 -rfbport 5913 &
~$ netstat -tanp | grep 5913
tcp 0 0 127.0.0.1:5913 0.0.0.0:* LISTEN 13410/Xtigervnc
tcp6 0 0 ::1:5913 :::* LISTEN 13410/Xtigervnc
~$
vncserver: /usr/bin/Xtigervnc did not start up, please look into
'/home/pwolski/.vnc/kitsune:3.log' to determine the reason! -1
Killing Xtigervnc process ID 13410... success!
~/.vnc$ tail -3 kitsune:3.log
vncext: VNC extension running!
vncext: Listening for VNC connections on local interface(s), port 5913
vncext: created VNC server for screen 0
The problem lies in line 794 where it says:
checkTCPPortUsed(5900+$options->{'displayNumber'})
The rfbport option is handled in the fork branch and pushed to $vncPort (and
Xvnc)
but the wait loop will instead look for the default port.
I'm not versed enough in perl to include a patch, but I believe it should read
something
like checkTCPPortUsed($vncPort).
Of course vncPort must be set to rfbport when used in cmdline, the push from the
fork will not be visible for the parent.
It defaults to 5900+$options->{'displayNumber'} anyway in line 691.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8),
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages tigervnc-standalone-server depends on:
ii libaudit1 1:2.7.7-1+b1
ii libbsd0 0.8.5-1
ii libc6 2.24-12
ii libgcc1 1:7.1.0-8
ii libgcrypt20 1.7.8-1
ii libgl1-mesa-glx [libgl1] 17.1.3-2
ii libgnutls30 3.5.13-2
ii libjpeg62-turbo 1:1.5.1-2
ii libpam0g 1.1.8-3.6
ii libpixman-1-0 0.34.0-1
ii libselinux1 2.6-3+b2
ii libstdc++67.1.0-8
ii libsystemd0 233-9
ii libx11-6 2:1.6.4-3
ii libxau6 1:1.0.8-1
ii libxdmcp6 1:1.1.2-3
ii libxfont2 1:2.0.1-3
ii libxshmfence1 1.2-1+b2
ii perl 5.24.1-4
ii x11-xkb-utils 7.7+3+b1
ii xauth 1:1.0.9-1+b2
ii xkb-data 2.19-1
ii zlib1g1:1.2.8.dfsg-5
Versions of packages tigervnc-standalone-server recommends:
ii libgl1-mesa-dri17.1.3-2
ii tigervnc-common1.7.0+dfsg-7
ii x11-xserver-utils 7.7+7+b1
ii xfonts-base1:1.0.4+nmu1
Versions of packages tigervnc-standalone-server suggests:
ii xfonts-100dpi1:1.0.4+nmu1
ii xfonts-75dpi 1:1.0.4+nmu1
ii xfonts-scalable 1:1.0.3-1.1
-- no debconf information
----
Philipp Wolski - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters |
Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -158 | Fax: +49 441 93602 -222 | E-Mail:
philipp.wol...@kisters.de | WWW: http://www.kisters.de
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
