Bug#1011113: Additional (minor) patch
I figured I should also send along my other, much older, patch.
This one fixes a fprintf() with no trailing newline, which is merely
annoying.
From 70f3ceea4b3baf3191512b6f3734db7d7cbfa430 Mon Sep 17 00:00:00 2001
From: "FeRD (Frank Dana)"
Date: Sat, 13 Nov 2021 01:08:10 -0500
Subject: [PATCH] End stderr output with a newline
---
chrpath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/chrpath.c b/chrpath.c
index 207e369..c8580d8 100644
--- a/chrpath.c
+++ b/chrpath.c
@@ -186,7 +186,7 @@ chrpath(const char *filename, const char *newpath, int convert)
if ((int)SHDR_O(sh_size) < rpathoff)
{
-fprintf(stderr, "%s string offset not contained in string table",
+fprintf(stderr, "%s string offset not contained in string table\n",
elf_tagname(DYNSS(rpath_dyns_index, d_tag)));
free(strtab);
free(dyns);
--
2.31.1
Bug#1011113: chrpath: misreads, damages shared libraries with unexpected structure
6_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-104-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chrpath depends on:
ii libc6 2.31-0ubuntu9.9
chrpath recommends no packages.
chrpath suggests no packages.
>From 389098510c9edc4020ac9fb38c7ed6027848426f Mon Sep 17 00:00:00 2001
From: "FeRD (Frank Dana)"
Date: Sun, 24 Apr 2022 19:12:19 -0400
Subject: [PATCH] Fix lookup of string table
Previously, the code assumed the first SHT_STRTAB section it
encountered was the dynamic string table. However, this is not
always the case.
Two new functions, read_section_names() and get_section_name(),
are responsible for reading the table of section names from the
ELF file, and retrieving section names from the imported table.
The search for the dynamic string table is now augmented by a
check that the section name is ".dynstr", before applying the
rpath offset to retrieve the rpath string.
---
chrpath.c | 76 +--
protos.h | 3 +++
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/chrpath.c b/chrpath.c
index 207e369..06920a8 100644
--- a/chrpath.c
+++ b/chrpath.c
@@ -50,6 +50,61 @@ Peeter
#include
#include "protos.h"
+
+/**
+ * Reads the section names table from an ELF file into memory
+ */
+char*
+read_section_names(int fd, Elf_Ehdr ehdr)
+{
+ Elf_Shdr shdr;
+
+ const size_t sz_shdr = is_e32() ? sizeof(Elf32_Shdr) : sizeof(Elf64_Shdr);
+ const size_t sh_off = EHDRWU(e_shoff);
+ const size_t sections_off = EHDRWU(e_shstrndx) * sz_shdr;
+
+ if (lseek(fd, sh_off + sections_off, SEEK_SET) == -1)
+ {
+perror ("positioning for section table");
+return NULL;
+ }
+
+ if (read(fd, , sz_shdr) != (ssize_t)sz_shdr)
+ {
+perror ("reading section header");
+return NULL;
+ }
+
+ /* +1 for forced trailing null */
+ char* strtab = (char *)calloc(1, SHDR_O(sh_size)+1);
+ if (strtab == NULL)
+{
+ perror ("allocating memory for string table");
+ return NULL;
+}
+
+ if (lseek(fd, SHDR_O(sh_offset), SEEK_SET) == -1)
+ {
+perror ("positioning for string table");
+return NULL;
+ }
+ if (read(fd, strtab, SHDR_O(sh_size)) != (ssize_t)SHDR_O(sh_size))
+ {
+perror ("reading string table");
+return NULL;
+ }
+ strtab[SHDR_O(sh_size)] = 0; /* make sure printed string is null terminated
*/
+ return strtab;
+}
+
+/**
+ * Looks up the name for a section, using its offset in the table
+ */
+char*
+get_section_name(int name_off, char* section_names) {
+ return section_names + name_off;
+}
+
/**
* Reads an ELF file, and reads or alters the RPATH setting.
*
@@ -128,31 +183,44 @@ chrpath(const char *filename, const char *newpath, int
convert)
return 2;
}
+ char* section_names = read_section_names(fd, ehdr);
+ if (section_names == NULL) {
+free(dyns);
+elf_close(fd);
+return 1;
+ }
+
if (lseek(fd, EHDRWU(e_shoff), SEEK_SET) == -1)
{
perror ("positioning for sections");
free(dyns);
+free(section_names);
elf_close(fd);
return 1;
}
+ const size_t sz_shdr = is_e32() ? sizeof(Elf32_Shdr) : sizeof(Elf64_Shdr);
for (i = 0; i < EHDRHU(e_shnum); i++)
{
-const size_t sz_shdr = is_e32() ? sizeof(Elf32_Shdr) : sizeof(Elf64_Shdr);
if (read(fd, , sz_shdr) != (ssize_t)sz_shdr)
{
perror ("reading section header");
free(dyns);
+ free(section_names);
elf_close(fd);
return 1;
}
-if (SHDR_W(sh_type) == SHT_STRTAB)
+if (SHDR_W(sh_type) != SHT_STRTAB)
+ continue;
+char* name = get_section_name(SHDR_W(sh_name), section_names);
+if (strcmp(name, ".dynstr") == 0)
break;
}
if (i == EHDRHU(e_shnum))
{
fprintf (stderr, "No string table found.\n");
free(dyns);
+ free(section_names);
elf_close(fd);
return 2;
}
@@ -162,6 +230,7 @@ chrpath(const char *filename, const char *newpath, int
convert)
{
perror ("allocating memory for string table");
free(dyns);
+ free(section_names);
elf_close(fd);
return 1;
}
@@ -171,6 +240,7 @@ chrpath(const char *filename, const char *newpath, int
convert)
perror ("positioning for string table");
free(strtab);
free(dyns);
+free(section_names);
elf_close(fd);
return 1;
}
@@ -179,6 +249,7 @@ chrpath(const char *filename, const char *newpath, int
convert)
perror ("reading string table");
free(strtab);
free(dyns);
+free(section_names);
elf_close(fd);
return 1;
}
@@ -190,6 +261,7 @@ chrpath(const char *filename, const char *newpath, int
convert)
Bug#993347: [Pkg-samba-maint] Bug#993347: samba: recent systemd update (DSA-4942-1) makes samba-ad-dc complain about PID's.
I became aware of this report via the open bug in Samba bugzilla. NotifyAccess=all was actually only recently (well, around 2 years ago) removed from the Samba systemd unit files. So that was a deliberate change, as implemented in this commit: https://gitlab.com/samba-team/samba/-/commit/d1740fb3d5a72cb49e30b330bb0b01e7ef3e09cc However, that did have some residual fallout that was subsequently addressed. It appears that this particular issue should have been resolved by: https://gitlab.com/samba-team/samba/-/merge_requests/1813 That code was merged on 2021-03-01, a few days before the Samba 4.14.0 release, so it should be in both 4.14 and 4.15. Can anyone confirm whether NotifyAccess=all is still required with more recent Samba releases (4.14.x / 4.15.x)?
Bug#971327: libopenshot dependency on libavresample
Greetings, one of the libopenshot maintainers here. libopenshot not only supports swresample, but uses it in place of avresample for all LIBAVFORMAT_VERSION_MAJOR >= 57 (which corresponds to slightly before the ffmpeg 3.0 release). The dependency on libavresample in those cases is completely superfluous. Please do remove it from the package configuration.
Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio
On Fri, May 15, 2020 at 6:42 PM John Scott wrote: > On Sat, 25 Apr 2020 21:40:14 -0400 FeRD wrote: > > If Debian maintains JUCE as a distro package, and it would be a > compatible > > alternative to our JUCE-based "libopenshot-audio", I don't see any > reason we > > can't add an option to libopenshot's CMake configuration that tells it to > > just > > use those libs, completely replacing libopenshot-audio ? which would > > become entirely superfluous in that scenario. > Looking at the https://salsa.debian.org/multimedia-team/juce repo, along with https://packages.debian.org/source/sid/juce, the impression I get is that Debian JUCE now has the form of a module-source package, to be used when building JUCE-dependent software, in keeping with the norms for how JUCE applications are typically used. (It looks like there used to be a libjuce until 5.2.0, since juce-module-source "Replaces: libjuce-dev (<< 5.2.0~)".) Given that, it seems we'd still want to build libopenshot-audio, still using our config headers and JuceLibraryCode/include_.cpp wrappers, but with the include path set to /usr/share/juce/modules/ instead of using the bundled JuceLibraryCode/modules/. That made things even simpler than I expected, honestly. So, to that end, I've already both submitted and merged two PRs: https://github.com/OpenShot/libopenshot-audio/pull/97 https://github.com/OpenShot/libopenshot/pull/515 ...Which, taken together, allow libopenshot-audio to be configured with a CMake command line specifying an alternate path to the JUCE modules: cmake -DJUCE_MODULES_PATH=/usr/share/juce/modules Configured that way, it'll use that directory to build the modules and install the necessary headers. The JuceLibraryCode/modules dir in the distribution could even be deleted. (The outer JuceLibraryCode directory and its contents are still needed, as it contains ProJucer-generated files that aren't part of Debian's package.) The libopenshot PR was necessary because we were previously patching JUCE to work around an issue building our Ruby bindings. To make libopenshot-audio compatible with Debian's unpatched sources, I had to figure out the CORRECT way to work around that issue from the libopenshot end. I did, and PR 515 applied it. But if not building the Ruby bindings, libopenshot-0.2.5 release sources should build just fine against a libopenshot-audio built from non-bundled JUCE module sources. libopenshot-audio commit 25ca2d0 merged[1] the changes to our CMake setup, obviously this hasn't been incorporated into a release yet. If that's a problem, I can start banging the drum to roll an 0.2.1 release with JUCE_MODULES_PATH support. [1]: https://github.com/OpenShot/libopenshot/commit/25ca2d0dd83e9a0ecc961df8b2fa87a69ba2cd36
Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio
On Sat, Apr 25, 2020 at 4:41 PM John Scott wrote: > On Fri, 24 Apr 2020 23:33:59 -0400 FeRD wrote: > > What version of libopenshot is that result from? The Clang namespacing > was > > fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included > in > > both libopenshot-0.2.4 and libopenshot-0.2.5. > I used version 0.2.2+dfsg1-1 which is the current version in unstable. I'm > not > the maintainer; upgrading it is outside of my domain (esp. in light of the > following). > Ah, gotcha. Yeah, libopenshot 0.2.2's *tests* not building with Clang is a known issue, which has been fixed since 0.2.4. > Right, I know what'll pull it all together. It seems that the source for > libopenshot includes embedded code copies of JUCE, and code copies are > strongly discouraged in Debian, even if they don't make it into the > binaries. > That file is a Debian-specific README mostly addressed to developers that > says > to replace bundled copies of JUCE and use the code in package juce-modules- > source instead. This approach seems to have not been taken. > Understood. Well, looking at things from that direction, fortunately the bundled code is all sequestered into a separate package, libopenshot-*audio*, which libopenshot depends on. Really there's nothing to libopenshot-audio OTHER than a customized build of JUCE, to be honest. (Customized == pared down, mostly. We don't use any of the GUI components. So it's "JUCE but only these six modules: core, events, data_structures, audio_basics, audio_devices, and audio_formats.") If Debian maintains JUCE as a distro package, and it would be a compatible alternative to our JUCE-based "libopenshot-audio", I don't see any reason we can't add an option to libopenshot's CMake configuration that tells it to just use those libs, completely replacing libopenshot-audio — which would become entirely superfluous in that scenario. This is the perfect time to do it, too, as I've been gutting and reworking large parts of libopenshot's build system recently — sticking in a "USE_SYSTEM_JUCE" option would be no trouble at all. Is there an importable CMake configuration for the distro JUCE package, by any chance, or should I put together a find module as well? > > I hope this makes clear the nature of the obstacles ahead. It makes the *situation* much clearer, yes thanks — but so far I'm still optimistic that this is pretty easily solvable, really. Then again, I rarely see obstacles until I barrel into them at 50 MPH, so I guess we'll see how things go. ¯\_(ツ)_/¯
Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio
Sorry, I realized I might have sent this reply to the wrong bug. -- Forwarded message - From: FeRD Date: Tue, Apr 21, 2020 at 5:31 PM Subject: Re: Fixed in newer release of libopenshot / libopenshot-audio To: <925...@bugs.debian.org> On Tue, 21 Apr 2020 15:04:59 -0400 John Scott wrote: > > libopenshot-audio builds with Clang without any modifications. Using this > OpenShot (again with Clang) gets a bit farther: > /usr/include/libopenshot-audio/JuceLibraryCode/modules/juce_audio_basics/../juce_core/unit_tests/juce_UnitTest.h:73:17: note: candidate found by name lookup is 'juce::UnitTest' > class JUCE_API UnitTest > ^ > /<>/tests/Cache_Tests.cpp:50:2: error: reference to 'UnitTest' is ambiguous > > I've seen this is fixed in a commit upstream, and I think cherrypicking it > helped, but the -audio Debian package uses the Juce embedded code copies > instead of the ones in juce-modules-source as best as I can tell. What version of libopenshot is that result from? The Clang namespacing was fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included in both libopenshot-0.2.4 and libopenshot-0.2.5. That's a merge commit and it touches a bunch of files, but basically all of our headers now qualify juce symbols with the juce:: namespace prefix, and the test sources now #define DONT_SET_USING_JUCE_NAMESPACE which prevents JUCE from exporting its symbols into the global namespace. AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing over ambiguous 'UnitTest' symbols. But all this should have been solved months ago. > I'm uneasy about this and hope that a new release of OpenShot made with the > practices described in /usr/share/doc/juce-modules-source/README.Debian will > make an elegant solution. Is there a copy of that file online somewhere? It's not part of the JUCE distribution as far as I can tell, and it's definitely not located at that path on my Fedora machine. [1]: https://github.com/OpenShot/libopenshot/commit/2a1fe80
Bug#925755: Fixed in newer release of libopenshot / libopenshot-audio
On Tue, 21 Apr 2020 15:04:59 -0400 John Scott wrote: > > libopenshot-audio builds with Clang without any modifications. Using this > OpenShot (again with Clang) gets a bit farther: > /usr/include/libopenshot-audio/JuceLibraryCode/modules/juce_audio_basics/../juce_core/unit_tests/juce_UnitTest.h:73:17: note: candidate found by name lookup is 'juce::UnitTest' > class JUCE_API UnitTest > ^ > /<>/tests/Cache_Tests.cpp:50:2: error: reference to 'UnitTest' is ambiguous > > I've seen this is fixed in a commit upstream, and I think cherrypicking it > helped, but the -audio Debian package uses the Juce embedded code copies > instead of the ones in juce-modules-source as best as I can tell. What version of libopenshot is that result from? The Clang namespacing was fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included in both libopenshot-0.2.4 and libopenshot-0.2.5. That's a merge commit and it touches a bunch of files, but basically all of our headers now qualify juce symbols with the juce:: namespace prefix, and the test sources now #define DONT_SET_USING_JUCE_NAMESPACE which prevents JUCE from exporting its symbols into the global namespace. AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing over ambiguous 'UnitTest' symbols. But all this should have been solved months ago. > I'm uneasy about this and hope that a new release of OpenShot made with the > practices described in /usr/share/doc/juce-modules-source/README.Debian will > make an elegant solution. Is there a copy of that file online somewhere? It's not part of the JUCE distribution as far as I can tell, and it's definitely not located at that path on my Fedora machine. [1]: https://github.com/OpenShot/libopenshot/commit/2a1fe80
Bug#925754: Fixed in newer release of libopenshot / libopenshot-audio
On Wed, 29 Jan 2020 10:08:55 +0100 Matthias Klose wrote: > libopenshot-audio 0.1.8 still fails to build Quite right, sorry. libopenshot-audio-0.1.8 fixed building with GCC *less than* 9, but GCC9 coming along broke it again. On Fedora / RPM Fusion we were building with commit 7001b68[1], which was at the time an unreleased commit on the development branch. However, since then both 0.1.9 and 0.2.0 have been released, including fixes to build with GCC 9 and 10 respectively, IIRC. (I know 0.2.0 builds with GCC 10 for sure, since I've done it myself.) Current releases: libopenshot-audio-0.2.0: https://github.com/OpenShot/libopenshot-audio/archive/v0.2.0.tar.gz libopenshot-0.2.5: https://github.com/OpenShot/libopenshot/archive/v0.2.5.tar.gz OpenShot 2.5.1 (openshot-qt): https://github.com/OpenShot/openshot-qt/archive/v2.5.1.tar.gz [1]: https://github.com/OpenShot/libopenshot-audio/commit/7001b68787c0881a44bcafba98cccae509a31644
Bug#925754: Fixed in newer release of libopenshot / libopenshot-audio
This issue was fixed with the simultaneous release of libopenshot-0.2.3 and libopenshot-audio-0.1.8 on 2019-03-22. The new releases use an upgraded and streamlined build of the Juce library sources, removing the problematic modules which were causing FTBFS issues with GCC 9. See upstream issue https://github.com/OpenShot/libopenshot-audio/issues/33 . libopenshot-audio-0.1.8 release: https://github.com/OpenShot/libopenshot-audio/releases/tag/v0.1.8 libopenshot-0.2.3 release: https://github.com/OpenShot/libopenshot/releases/tag/v0.2.3 (The OpenShot application also released version 2.4.4 at that time: https://github.com/OpenShot/openshot-qt/releases/tag/v2.4.4 )
Bug#69728: Kings had big ones
Pop this twice a day to increase your lenght and girth considerably. if your lady tells you that size is of no importance, she is lying to you. studies clearly show that the intimate life of couples whose man has a smaller one is a lot less active than their counterparts who have big sizes. So think about it again. http://wesresen.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
