Re: [Rpm-maint] [rpm-software-management/rpm] add support for premacros.d, complementing --predefine (#304)
Yeah, it feels weird. -- 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/304#issuecomment-323503177___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Static code analysis task for make (#306)
I don't think we need to run any checks on python/shell code... Although we do run static analyser from time to time locally. -- 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/306#issuecomment-323503146___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: extract changelog to file, include as %doc automatically and put stub in actual binary and source RPMs. (#305)
@mattdm wrote: > In these days of version control, I think we've outlived the usefulness of > having full changelogs in RPM files. Yet, it's still useful to have them in > the specfile for workflows and build systems which haven't adapted to using > version control changelogs. This is absolutely silly. Changelogs play an important role in allowing people to see how the package changed. There are plenty of places that have a private VCS but enter useful changelog information (e.g. Red Hat with Red Hat Enterprise Linux). Others don't really have a VCS in the normal sense and use a separate file as a source for changelog entries (SUSE/openSUSE). And of course, there are those who use the VCS as the changelog (e.g. Mageia with its Dist-SVN). Maybe you don't see the usefulness of them, but I think they need to be in the spec. It's perfectly fine to limit the entries in the binary packages for history, but that should really only apply to Fedora packages. In my opinion, it shouldn't even apply to people who build packages on Fedora systems. And Fedora's Dist-Git is full of dumb commits that aren't helpful (like "oops" or "forgot sources") that are irrelevant to changelogs, and with no way to make changelog entries nice from VCS to spec, all you're left with is maintaining a changelog file. In the end, you go nowhere with this. -- 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/305#issuecomment-323501092___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: extract changelog to file, include as %doc automatically and put stub in actual binary and source RPMs. (#305)
Um ... its not that simple, and the idea of mapping out changelings to a file that is then retrofitted to "rpm --changelog" pretends to a silly legacy compatibility (and adds complexity for not much gain other than not having to justify the change). You are more than a little late to the discussion: iirc, PLD got rid of changelog entries (by mapping to cvs --log) in 2002. And Mandriva (R.I.P.) did the same with subversion log messages more than a decade ago. FWIW, RPM has had the ability to limit changelog entries by number or date for like 10 years. You (as Fedora spokesperson) can certain;y advocate a change to Fedora's Packaging Policies using existing functionality to limit changes;dog's to, say, 3 entries or the last 3 months. Meanwhile -- just like the i686 w/o SSE2 support -- there is simply no way get rid of ancient hysteria in FL/OSS software. Good luck getting rid of tcp_wrappers! And python2! ;-) -- 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/305#issuecomment-323499950___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Static code analysis task for make (#306)
I want to add `make style-check` task for static code analysis as a dependency task of `make check` in `Makefile`. Because it helps to maintain, keeping the code clean. Candidate tools - C file: I do not know which tool is good. - Python file: `flake8` [1]. - Shell (bash) file: `sh -n`, `bashate` [2], `shellcheck` [3] I have used the tool [1], [2], [3]. and I think those are helpful. [1] https://pypi.python.org/pypi/flake8 [2] https://pypi.python.org/pypi/bashate [3] https://www.shellcheck.net/ -- 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/306___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [Proposal] Adding style and pytest environment on tox for rpm python bindings module. (#303)
I would close this PR to change the approach. -- 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/303#issuecomment-323445795___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [Proposal] Adding style and pytest environment on tox for rpm python bindings module. (#303)
Closed #303. -- 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/303#event-1212471133___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: extract changelog to file, include as %doc automatically and put stub in actual binary and source RPMs. (#305)
In these days of version control, I think we've outlived the usefulness of
having full changelogs in RPM files. Yet, it's still useful to have them in the
specfile for workflows and build systems which haven't adapted to using version
control changelogs.
My suggestion is:
1. Changelog entries in specfile remain as they are.
2. At build time, the changelog is extracted to a file named
`name-version-release.rpm-changelog` (so for example,
`rpm-4.13.0.1-5.fc26.rpm-changelog`).
3. That file automatically treated as a `%doc` and either included in the
`/usr/share/doc/packagename` directory or maybe all collected in
`/usr/share/doc/rpm-changelogs`.
4. In the package itself, the latest changelog entry included
5. Every older changelog entry _not_ included in the source or binary RPM
6. The line `- Older changelog information can be found at {path to wherever
the changelog is installed}` added to the end of the one included changelog
entry.
This will:
1. Let people keep doing whatever they want with RPM changelog in spec files
2. Shrink the size of /var/lib/rpm/Packages
3. Provide latest changelog entry in the way everyone is used to
4. Make older changelog entries easily available on-system for people who want
them
5. In fact, improve things since those can be indexed and searched with grep or
whatever even more trivially than currently
6. Make it possible to just not include the files by using `nodocs`
As a fancy additional possibility, `rpm --changelog` could read and output
these files in preference to the embedded information. (I guess if that
direction is taken, skip the idea of adding the `Older changelog information`
line.)
The only downside I can think of is increased complexity in RPM when _maybe_ we
should just deprecate RPM changelogs entirely. But, I think we're not really
ready for that yet and this is a good intermediate approach.
--
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/305___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Yup, that version did not complained about recursive macros. The increased limit would be nice. -- 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/127#issuecomment-323380570___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
It's easy to cause a recursive definition by mistake, but after seeing the jdk spec... the macros nest deeper than anything else I've seen in rpm macro usage. It's quite possible that you're running into the artificial limit of 16 nesting levels. I initiated a scratch-build where the limit is raised to 64 if you want to try it out: https://koji.fedoraproject.org/koji/taskinfo?taskID=21305568 -- 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/127#issuecomment-323361629___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
hmmm. Moving in that, and started to slowly get in same maze where I was when deffine was used instead of global - error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. -- 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/127#issuecomment-323350739___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
I consider the \\ syntax as easy to make an error and easy to oferlook when readed. So i would prefer matching bracket rather. Thanx. hmm, the build failed. %1 leaked in again. Looks my small steps do not work as I hoped... -- 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/127#issuecomment-323346235___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Not really, the surrounding %{ ... } will end up in the macro body literally
which is unlikely to be what you want. It's not a general block construct in
the sense you'd find in eg C. Use the line-continuations instead, eg
```
%define sdkbindir()\
%{_jvmdir}/%{sdkdir %1}/bin\
%{_jvmdir}/%{sdkdir %1}/bin
```
--
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/127#issuecomment-323344835___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
The:
%define sdkbindir() %{
%{_jvmdir}/%{sdkdir %1}/bin
%{_jvmdir}/%{sdkdir %1}/bin
}
Is correct right?
--
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/127#issuecomment-323340280___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
> I'd recommend trying to eliminate those leftover %expand's and double %%-s > necessiated by %global use, those only make reading Thats plan to do. But in small steps. It may be easy to cause some really hard to find issues. > and understanding the whole thing more difficult. Thats long term goal! With rpm development in progress and some hidden stuff documentation not exactly easy t find... neverending goal:) -- 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/127#issuecomment-323339947___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Yes, things actually become more natural when empty arguments are handled as such. But even positive change can be a major PITA if it comes at the wrong time, know the feeling... I'd recommend trying to eliminate those leftover %expand's and double %%-s necessiated by %global use, those only make reading and understanding the whole thing more difficult. -- 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/127#issuecomment-323336778___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Thank you. They can be nil, so ? approach is clear way. Now building withmost direct: https://src.fedoraproject.org/rpms/java-9-openjdk/c/abdb6134df8fd6e458e41d9a020274dd441ed2e7?branch=f27 lets see again. The approach, once tuned here, will need to be backport to jdk8 -- 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/127#issuecomment-323334867___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
```
%define mymacro() \
echo foo\
echo bar
```
...is the line-continuation syntax.
As for the rest, it depends on what you need to do with it. If the arguments
are always non-%{nil} then there's nothing you need to do. If arguments can be
%{nil} (or otherwise empty), then you have two choices:
1) escape the argument in the *caller*, eg "%sdkbindir %%{nil}". If you need to
pass unexpanded macros through several layers of macros as seems to be the
case, then you need to escape them at each caller. So in the sdkbindir() case,
you'd use %%{1} in the calls to %sdkdir.
2) handle the "missing" argument in the parametric macro (ie callee, instead of
caller, basically), by using ?-conditionals.
--
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/127#issuecomment-32471___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Revert "Only build bundled fts if system has a bad version that doesn't handle LFS"
On Fri, Aug 18, 2017 at 08:22:23AM +0300, Panu Matilainen wrote: > On 08/17/2017 11:28 PM, Dmitry V. Levin wrote: > > On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote: > >> On 08/16/2017 11:51 PM, Dmitry V. Levin wrote: > >>> On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen wrote: > The subtle test is too subtle for its own good, this patch breaks > thirty six testcases on 32bit architectures. > > This reverts commit 1eadabe4453ef32eb6c3bc837094e1ca998affcc. > > [leaving non-technical part aside for a while] > >> But as the > >> revert commit message says, the test is way too subtle for my liking, I > >> never liked it at all because of that. In retrospective, that distrust > >> combined with the clock-is-ticking situation ... I don't think I ever > >> actually thought to suspect fakechroot in this case. > > > > Sorry but your distrust of AC_CHECK_HEADERS([fts.h]) looks rather > > irrational. > > What kind of doubts do you have wrt this very basic test? > > > > Do you have any doubts about AC_CHECK_HEADERS documented behaviour, e.g. > > that it uses the compiler to test header usability, and it is affected > > by the arrangements made by AC_SYS_LARGEFILE? > > > > Even the memorable 8-year-old change of AC_CHECK_HEADERS behaviour > > described in [1] shouldn't affect this case because glibc's fts.h used > > to issue an "#error" in case of _FILE_OFFSET_BITS==64 thus breaking > > the preprocessor test, too. > > > > There are plenty of AC_CHECK_HEADERS invocations in configure.ac - > > do they also look doubtful to you? > > Meh. > > "Any technology, no matter how primitive, is magic to those who don't > understand it." > > The "earlier configure.ac foo hidden side-effects cause this to do > something else" that somehow ends up being completely counter-intuitive > and magic to me. You hardly can call them hidden because they are clearly documented, e.g. https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/html_node/System-Services.html#index-AC_005fSYS_005fLARGEFILE-1102 says "Define _FILE_OFFSET_BITS and _LARGE_FILES if necessary". > I'm still deep in the superstition phase when in comes to autoconf ;) You know, this can be fixed, too. ;) -- ldv signature.asc Description: PGP signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Sorry, to clarify again:
%global sdkbindir() %{expand:
%{_jvmdir}/%{sdkdir %%1}/bin
%{_jvmdir}/%{sdkdir %%1}/bin
}
==
%define sdkbindir() %{expand:
%{_jvmdir}/%{sdkdir %%1}/bin
%{_jvmdir}/%{sdkdir %%1}/bin
}
==
%define sdkbindir()\
%{_jvmdir}/%{sdkdir %1}/bin \
%{_jvmdir}/%{sdkdir %1}/bin
==
%define sdkbindir() %{
%{_jvmdir}/%{sdkdir %1}/bin
%{_jvmdir}/%{sdkdir %1}/bin
}
where the initial global is missused
right?
--
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/127#issuecomment-323330018___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
No, you just need to use trailing ```\``` to indicate line-continuation which
is not necessary inside %{...} "block scope".
--
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/127#issuecomment-323327478___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
I see. I guess when macro is multiline, I still need to use %{expand
}
oook?
--
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/127#issuecomment-323325762___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
The crucial difference is right there in the part you quoted:
```
%global does not work correctly with parametric macros in any version of rpm,
since the body is expanded at the time of definition instead of time of use as
is the case with %defines.
```
So basically you *can* use %global instead of %define, but doing that requires
an extra escaping all the macros that are used. And then you need the %expand{}
around them because it was already expanded. So lots of unnecessary work and
complexity in the spec because of that wholly unnecessary switch to %global.
AFAICS the general pattern is:
```
%global sdkbindir() %{expand:%{_jvmdir}/%{sdkdir %%1}/bin}
```
...which is the rather hard way to say:
```
%define sdkbindir() %{_jvmdir}/%{sdkdir %1}/bin
```
For most cases both will work fine with the new rpm too. The biggest difference
is the case where %1 might expand to nothing, in which case you need to either
escape it with an extra % (so in %global case, there would now be three
%-characters!) or have the relevant macro(s) handle the case where %1 is
effectively not passed, ie %{?1}.
--
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/127#issuecomment-323323618___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
O, and thank you very much for helping me out! -- 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/127#issuecomment-323321338___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
"%global does not work correctly with parametric macros in any version of rpm,
since the body is expanded at the time of definition instead of time of use as
is the case with %defines. And the spec is full of those, combined with some
strange %{expand}s and whatnot. This is a sad example of what the misguided
"%define is evil and must be replaced by %global" campaign in Fedora has done
:("
I see. Originally there was deffined, and yes, based on that campaign I put
global everywhere. What are the crucial differences then?
What change will be achived when simply replacing or expandable %global var()
by %deffine() var?
--
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/127#issuecomment-323321239___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Thats baa... Very bad.You killed dinamic specfiles.
What I have is:
for suffix in %{build_loop} ; do
mkdir -p %{buildoutputdir $suffix}
pushd %{buildoutputdir $suffix}
done
You see that expansion as is odnenow killed it.
--
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/127#issuecomment-323320201___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
So... start by changing the %global's of parametric macros to %define().
Many/most of the accompanying %{expand:}s are likely unnecessary and unwanted
too.
--
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/127#issuecomment-323318856___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
%{?1} is the same as %{?1:%1}, yes. And sure it works, eg:
```
[pmatilai@sopuli ~]$ rpm --define "foo() %{?1}" --eval "%foo %{nil}"
[pmatilai@sopuli ~]$ rpm --define "foo() %{?1}" --eval "%foo %{_lib}"
lib64
```
However looking at
https://src.fedoraproject.org/rpms/java-9-openjdk/blob/6dd07923a5203651059e28f4c1422a2d862e2d84/f/java-9-openjdk.spec...
```
%global post_headless() %{expand:
```
%global does not work correctly with parametric macros in any version of rpm,
since the body is expanded at the time of definition instead of time of use as
is the case with %defines. And the spec is full of those, combined with some
strange %{expand}s and whatnot. This is a sad example of what the misguided
"%define is evil and must be replaced by %global" campaign in Fedora has done :(
--
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/127#issuecomment-323318485___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
