Re: [Rpm-maint] [rpm-software-management/rpm] debugedit.c patches (#171)

Another issue that might make debugedit.c more portable is similar to inlining DW_FORM* instead of `#include ` Instead of using EU version dependent #defines for strtab_init() etc (which needs -lebl), it may be more "portable" to just inline the routines and maintain a copy in debugedit.c.

Re: [Rpm-maint] [rpm-software-management/rpm] debugedit.c patches (#171)

Re: https://patchwork.openembedded.org/patch/46887 The bug and related information are available at: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4089 I am currently working through this to see if the current rpm (4) version suffers from the same failure. I will update this if it does or

Re: [Rpm-maint] [rpm-software-management/rpm] debugedit.c patches (#171)

Yes all the patches were reversed. Meanwhile I just sorted the first patch with Mark Hatle (aka "fray"). The segfault is not reproducible with EU-0.168. The hex printing was an attempt to avoid pgpHexStr() which differs between rpm.org and rpm5.org. You explained away the valid_file() check

Re: [Rpm-maint] [rpm-software-management/rpm] Allow SOURCE_DATE_EPOCH to override file timestamps (#144)

on the semi-offtopic python .pyc timestamp issue see: https://github.com/python/cpython/pull/296 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [PATCH] debugedit: Support String/Line table rewriting for larger/smaller paths.

On 03/06/2017 01:15 PM, Mark Wielaard wrote: On Sat, 2017-03-04 at 11:28 +0200, Panu Matilainen wrote: I dont feel qualified to really review this, and perhaps others are feeling the same way since it's been out there for a week now with no comments at all. Because this seems quite awesome

Re: [Rpm-maint] [rpm-software-management/rpm] debug edit build generation is endian dependent when cross-compiling? (#171)

On Sun, 2017-03-05 at 09:58 -0800, Jeff Johnson wrote: > Portability of debugedit.c on systems that do not support #include > (solaris, *BSD) can be achieved by duplicating certain DWARF > standard constants: I think you reversed the patch you are proposing again. I'll leave it to others to say

Re: [Rpm-maint] [rpm-software-management/rpm] debug edit build generation is endian dependent when cross-compiling? (#171)

On Sun, 2017-03-05 at 09:48 -0800, Jeff Johnson wrote: > For rpm portability with older versions of elfutils, this harmless sanity > check might be useful: > > (excuse the different hash functions in use in the patch snippet below) > @@ -1533,40 +1493,12 @@ >/* Now format the build ID bits

Re: [Rpm-maint] [rpm-software-management/rpm] debug edit build generation is endian dependent when cross-compiling? (#171)

On Sun, 2017-03-05 at 09:09 -0800, Jeff Johnson wrote: > rpm5.org carries this patch from Yocto: > https://patchwork.openembedded.org/patch/46887 > which likely should be added when updating debug edit.c soon. It is slightly hard to review a patch to a patch. Could you extract the precise

Re: [Rpm-maint] [PATCH] debugedit: Support String/Line table rewriting for larger/smaller paths.

On Sat, 2017-03-04 at 11:28 +0200, Panu Matilainen wrote: > I dont feel qualified to really review this, and perhaps others are > feeling the same way since it's been out there for a week now with no > comments at all. > > Because this seems quite awesome (even if also a bit scary), to avoid >

Re: [Rpm-maint] [PATCH] debugedit: Support String/Line table rewriting for larger/smaller paths.

On 4 March 2017 at 10:28, Panu Matilainen wrote: >> From: Mark Wielaard >> >> debugedit --base to --dest rewriting of debug source file paths only >> supported dest paths that were smaller or equal than the base path >> (and the size should differ more