Re: [Rpm-maint] [rpm-software-management/rpm] debugedit: Fix missing relocation of .debug_types section. (#1323)
It looks to me as reviewed: http://lists.rpm.org/pipermail/rpm-maint/2020-August/014792.html http://lists.rpm.org/pipermail/rpm-maint/2020-August/014797.html -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1323#issuecomment-670825178___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugedit: Fix missing relocation of .debug_types section. (#1323)
On Fri, 07 Aug 2020 13:55:35 +0200, Mark Wielaard wrote: > But I pulled > that branch and reviewed the actual commits (1d080e02 and c804a960). git clone -b types g...@github.com:jankratochvil/rpm.git rpm-types commit 8b5bbcc6d586be50b6a251256c39c3b0332b1f2b debugedit: Fix missing relocation of .debug_types section. commit 1d080e02409d181169d3aec2a19192418f253fd3 [NFC] debugedit: Move code from edit_dwarf2() to edit_info(). > It would be better to have a separate RPM_DEBUGEDIT_TYPES_SETUP that > does that and leave RPM_DEBUGEDIT_SETUP as is. Otherwise we change the > existing tests too. done as: RPM_DEBUGEDIT_SETUP([-fdebug-types-section]) > The only change I would like, as explained above, is to have a separate > RPM_DEBUGEDIT_TYPES_SETUP. With that it should be good to commit to the > main branch. Thanks, Jan ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] how to cross compile fedora source rpm for RISC-V architecture (#1327)
Closed #1327. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1327#event-3633734263___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] how to cross compile fedora source rpm for RISC-V architecture (#1327)
This is the ticket system for rpm development and not a support forum. General question on using rpm can go on the rpm mailing list or the #rpm.org IRC channel. See http://rpm.org/community.html for details. About your question: Bootstrapping a distribution like Fedora is a non trivial task that involved lots of Fedora specific things. Some packages need to be build by hand with a crosscompiler or on another operating system. Some packages may require multiple rebuilds with different dependencies available. You are therefore probabably better of asking this question on the fedora-devel list. AKFAIK there is no longer a secondary arch group in Fedora still there should be a lot of people with actual experience from bootstrapping other architectures. As we are concerned with developing rpm itself we here have very limited knowledge about the details of such process. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1327#issuecomment-670577005___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Can not parse CHANGELOGTEXT from the specfile (#1301)
Well, there's not really a way to fix the behaviour of _changelog_trimtime. We could amend it to keep a minimum number of entries even if they are older. If we want to keep entries based on a time frame we basically need a new macro. This of course raises the question of how these features should interact. Probably keeping any entries that would be added by either of the macros...? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1301#issuecomment-670572581___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] how to cross compile fedora source rpm for RISC-V architecture (#1327)
Dear all, Can anyone please help me out, how to cross compile fedora source rpm for RISC-V. Thanks Billa Surendra -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1327___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugedit: Fix missing relocation of .debug_types section. (#1323)
Hi Jan,
On Sat, 2020-08-01 at 11:23 +0200, Jan Kratochvil wrote:
> debugedit: Fix missing relocation of .debug_types section.
> https://github.com/rpm-software-management/rpm/pull/1323
I believe our mail review comments don't make it to that website. And
given that there are some forced updates to that pull branch. It is
sometimes hard to see which version we are discussing. But I pulled
that branch and reviewed the actual commits (1d080e02 and c804a960).
> > But here is a review inline:
> > If it is for the same lines that are moved from edit_dwarf2 () to
> > edit_info () below then it is fine, but if you do it in a separate
> > commit maybe also factor out edit_info () already? To make the next
> > commit easier to read.
>
> Yes, that was my original intention but I made a mistake, fixed now.
commit 1d080e02 (after checking with diff -u -w) looks reasonable.
I would check that into the main branch as is.
> > This will only work for executables or shared librareis, not for
> > (ET_REL) object files (or kernel modules) because those come with more
> > than 1 (comdat) .debug_types section. This is probably fine. But if you
> > expect that .debug_types will also appear in relocatable files, then
> > you might want to look at what edit_dwarf2() does for .debug_macro,
> > which might also appear multiple times.
>
> done
commit c804a960
Looks good. Thanks.
> > You do include a testcase for the relocatable object case:
>
> done
>
>
> > I would suggest extending the testcase a little to have multiple
> > larger
> > structs, plus some small field names. e.g. add another struct in
> > foobar.h:
>
> done
The test cases loook pretty comprehensive now. Nice.
One request though. In commit c804a960 you adjust RPM_DEBUGEDIT_SETUP
as follows:
> diff --git a/tests/debugedit.at b/tests/debugedit.at
> index cae3f4384..aa878d6fb 100644
> --- a/tests/debugedit.at
> +++ b/tests/debugedit.at
> @@ -36,11 +36,11 @@ cp "${abs_srcdir}"/data/SOURCES/foobar.h subdir_headers
> cp "${abs_srcdir}"/data/SOURCES/baz.c .
>
> # First three object files (foo.o subdir_bar/bar.o and baz.o)
> -gcc -g3 -Isubdir_headers -c subdir_foo/foo.c
> +gcc -g3 -Isubdir_headers -fdebug-types-section -c subdir_foo/foo.c
> cd subdir_bar
> -gcc -g3 -I../subdir_headers -c bar.c
> +gcc -g3 -I../subdir_headers -fdebug-types-section -c bar.c
> cd ..
> -gcc -g3 -I$(pwd)/subdir_headers -c $(pwd)/baz.c
> +gcc -g3 -I$(pwd)/subdir_headers -fdebug-types-section -c $(pwd)/baz.c
>
> # Then a partially linked object file (somewhat like a kernel module).
> # This will still have relocations between the debug sections.
It would be better to have a separate RPM_DEBUGEDIT_TYPES_SETUP that
does that and leave RPM_DEBUGEDIT_SETUP as is. Otherwise we change the
existing tests too. And I believe we want to make sure we test those
with the default debug flags.
> > Maybe we can just remove that warning.
>
> done
Looks good. Thanks.
> > This looks OK. But just before this the sections that have been changed
> > are marked "dirty", you probably want to mark DEBUG_TYPES also dirty if
> > it has been updated in any way (otherwise it isn't guaranteed the data
> > is written to disk, although it often will be).
>
> done
Nice catch on the dirty_section () having to follow secp->next (that
was a latent bug for the DEBUG_MACRO case).
> > To make sure you test the case where there are multiple debug line
> > table offsets in your .debug_type sections, you might want to add
> > something like the following to bar.c:
>
> done
Nice work on the tests.
I read the whole commit c804a960 and it looks good.
The only change I would like, as explained above, is to have a separate
RPM_DEBUGEDIT_TYPES_SETUP. With that it should be good to commit to the
main branch.
Thanks,
Mark
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Can not parse CHANGELOGTEXT from the specfile (#1301)
Ehm, except that of course the trimtime is in the *past* so that "logic" is completely flawed. Better not touch anything serious today, clearly :joy: -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1301#issuecomment-670468231___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
@Conan-Kudo commented on this pull request. > @@ -761,9 +778,9 @@ AC_ARG_WITH([lua], [AS_HELP_STRING([--with-lua], [build > with lua support])], AS_IF([test "$with_lua" != no],[ PKG_CHECK_MODULES([LUA], -[lua >= 5.1], +[lua >= 5.2], Hah, I thought we actually dropped Lua 5.2 support as well. Okay then... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#discussion_r466969467___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Can not parse CHANGELOGTEXT from the specfile (#1301)
Of course, that's incompatible with the existing implementation that takes an absolute timestamp as the cut-off point. That design is not one of our brighter moments... Perhaps we could do a little heuristic and determine any changelog_trimtime value earlier than "now" as a delta, and if later, calculate the trimdelta as trimtime - now. And then always use the delta for actual trimming. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1301#issuecomment-670458238___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpm --delsign changes the arch element of the lead (#1326)
Judging from commit 3255273ae0fabd03c9738249a29c9c1e15f28f64 which broke this you may not care about this. Opening this issue anyway for documentation purposes: rpm no longer copies over the lead data verbatim when creating or deleting signatures, but recreates it from the header. This does not seem to work for the arch element, which is set to the architecture of the host where rpm --delsign is called. Oh, I just saw that rpmLeadFromHeader() has a FIXME comment about that that references RhBug:717898 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1326___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
@dmnks commented on this pull request. > @@ -761,9 +778,9 @@ AC_ARG_WITH([lua], [AS_HELP_STRING([--with-lua], [build > with lua support])], AS_IF([test "$with_lua" != no],[ PKG_CHECK_MODULES([LUA], -[lua >= 5.1], +[lua >= 5.2], Heh, it's funny how easy is to misread the subject line of that commit message when shown in a popup box after hovering over it. It says "drop support for Lua < 5.2" with a line break after the "<" symbol which is then easy to miss :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#discussion_r466893351___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
> Sometimes it's better to test for specifics features, sometimes for versions. > I don't know how the OpenMP landscape looks like, but sometimes > implementations only support a subset of a newer standard in which case > testing for specific features is the friendlier way. My impression after skimming through a couple of random discussion threads and stackoverflow posts is very much this; while the API is well-defined, the reality is that compilers may only have partial support for certain features. With GCC, I think it's safe to assume it's fully supported, but I agree that testing for the particular feature is always the safest option. > OTOH the simplicity of being able to say "we require version X of standard Z" > can be a bliss - for example we generally require POSIX.1 >= 2001 and that > makes it fairly easy to cross-check portability issues and to say "no" to > obscure stuff that doesn't fulfil that basic requirement. Yup, I basically had the same mindset and just went with the version check, instead of checking for the priority feature alone. That also "scales" better in case we adopt some other OpenMP features in the future; instead of adding another convoluted compilation test to the configure script, we would just bump the version. That being said, especially given the nature of the non-100% compiler support, doing something like you suggested above with a custom `HAVE_OMP_PRIORITY` flag which we would set in a compilation test in `configure.ac` seems to be the best solution here. It just doesn't feel right to mandate version 4.5 (being "too new" in terms of RPM as you noted) just because of that damn priority thing which the world can live without just fine. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-670390942___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
Just for a data point, OpenMP 4.5 is supported in clang >= 7 and gcc >= 6, both from 2018. Which is brand new software barely off its wrappings in terms of rpm software requirements :smile: -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-670377085___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
> A more user-friendly way of dealing with this would actually be the opposite, > i.e. making the use of the priority keyword conditional at preprocessing, > based on the detected OpenMP version (which is trivial to do as shown in the > patch) because as you say, all that the keyword really does is it improves > load balance a tiny little bit in specific circumstances, but its absence has > no effect on the correctness of the code. We could even avoid doing a > `qsort()` on the package list as part of that conditional. The less code is covered by conditionals the better. Another option would be to specifically test for priority support in OpenMP, and just do something like this in pack.c: ``` #ifndef HAVE_OMP_PRIORITY #define priority(x) #endif ``` Sometimes it's better to test for specifics features, sometimes for versions. I don't know how the OpenMP landscape looks like, but sometimes implementations only support a subset of a newer standard in which case testing for specific features is the friendlier way. OTOH the simplicity of being able to say "we require version X of standard Z" can be a bliss - for example we generally require POSIX.1 >= 2001 and that makes it fairly easy to cross-check portability issues and to say "no" to obscure stuff that doesn't fulfil that basic premist. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-670372444___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
@pmatilai commented on this pull request. > @@ -761,9 +778,9 @@ AC_ARG_WITH([lua], [AS_HELP_STRING([--with-lua], [build > with lua support])], AS_IF([test "$with_lua" != no],[ PKG_CHECK_MODULES([LUA], -[lua >= 5.1], +[lua >= 5.2], Because 5.2 is the actually required minimum? See commit 6d4c68ba10b9713f3e599cf20c2455eb80e9bfe1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1325#discussion_r466860173___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] pythondistdeps: Switch to importlib.metadata (#1317)
Any updates on the test suite investigation? Is there anything I can do to help? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1317#issuecomment-670355509___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
