@pmatilai The project was started in late 2011, like many such things it was a
bit slow to gain traction — between needing plugins or integrated support to be
developed for various editors, and needing to convince users it was worth
bothering with.1 But it's really started to pick up steam in
Each library targets exported `INTERFACE_INCLUDE_DIRECTORIES` list, as
written into the `rpm-targets.cmake` export file, is controlled by the `PUBLIC`
arguments supplied to `target_include_directories()` for the library target.
* Directories scoped with the `$BUILD_INTERFACE` generator
Whoops. Actually, ignore that first patch, I typo'd a `%{buildroot}` as
`${buildroot}`.
_Fixed_ updated patch:
[pkcs11-provider_spec.patch.txt](https://github.com/user-attachments/files/16428873/pkcs11-provider_spec.patch.txt)
--
Reply to this email directly or view it on GitHub:
Note that the diff above is no longer valid, as the spec has been converted to
build with meson, so it won't apply cleanly (or even uncleanly).
Updated patch:
[pkcs11-provider_spec.patch.txt](https://github.com/user-attachments/files/16428678/pkcs11-provider_spec.patch.txt)
(No idea why I had
Tested locally (with `cmake --build _build --target ci`), seems to pass
reliably.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3221#issuecomment-2258204216
You are receiving this because you are subscribed to this thread.
Message ID:
@ferdnyc pushed 1 commit.
82e03b12622f5b579ff4376199a18ecc33c7e808 Add .editorconfig, and note in
CONTRIBUTING doc
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3219/files/32e5c98305d72d5da25b9627c12d4918598e0fd5..82e03b12622f5b579ff4376199a18ecc33c7e808
You are
@ferdnyc commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/usr/bin/python
+
+# Query a single installed package by its name.
+# A Python equivalent for `rpm -q hello`
+
+import rpm
+
+name = "hello"
+ts = rpm.TransactionSet()
+mi = ts.dbMatch("name", name)
+hdr = next(mi, None)
+if hdr:
@ferdnyc commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/usr/bin/python
+
+# Query a single installed package by its name.
+# A Python equivalent for `rpm -q hello`
+
+import rpm
+
+name = "hello"
+ts = rpm.TransactionSet()
+mi = ts.dbMatch("name", name)
+hdr = next(mi, None)
+if hdr:
@ferdnyc commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/usr/bin/python
+
+# Query a single installed package by its name.
+# A Python equivalent for `rpm -q hello`
+
+import rpm
+
+name = "hello"
+ts = rpm.TransactionSet()
+mi = ts.dbMatch("name", name)
+hdr = next(mi, None)
+if hdr:
If "real-world" examples are the goal, mightn't it be better to mine _actual
real-world code_ that uses the Python API for examples? DNF comes to mind, as a
blindingly-obvious source of existing, working code based on the RPM Python
bindings. :grin:
(The examples can be simplified/sanitized
After reading the formatting instructions in [CONTRIBUTING](/CONTRIBUTING.md),
I realized that the repo was crying out for an `.editorconfig` file to define
the appropriate settings.
[EditorConfig](https://editorconfig.org/) enjoys _wide_ support across all text
editors commonly used for
This PR, in separate commits, updates the macros documentation to fix one
formatting issue Id noticed on the docs site, reformats two code blocks
into markdown tables, and updates the formatting of all other tables in the doc.
1. **Unindent fenced code blocks** — I noticed on the docs page that
> With the new ME_QUOTED support added end of last year we could make this work
> correctly. So the question is if we want `%-x**` or not.
Speaking of `ME_QUOTED`: On a somewhat related note, am I doing something wrong
or does `%{quote}` seem to not play nicely with `%{**}`?
```console
$ rpm
@rhabacker
> shows that the quoting is done by the shell and not by getopt itself. The
> conclusion is that something similar must be done before calling getopt in
> rpm to process macro parameters with quotes.
Isn't that `%quote`, like @pmatilai mentioned? Going back to your experiments
Note that the CMake developers are aware of the issue, and have addressed it
for the next release with [a patch to
CPack](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9005) that
avoids default-quoting pathnames unless they contain spaces.
--
Reply to this email directly or view it
This is basically a revisiting of #2649, because there _does_ seem to be a
problem with the new code.
Specifically, I was attempting to upgrade graphviz's CI to fedora 39, and found
that their CMake-based build was failing to generate an RPM.
The problem is, CPack (CMake's packaging utility)
@ferdnyc commented on this pull request.
> @@ -1349,5 +1349,14 @@ end
end
}
+# example autobuild macros for autotools
+%autobuild_autotools_prep() %autosetup -p1
I'm not sure I understand `%prep` being part of this. It's not going to differ
from one build system to another, and
Actually, a question this brings up for me, because it's not clear from the
docs: Do `%{?!foo}` and `%{!?foo}` mean different things? That section of the
docs only documents `%{?!foo:value}` (as the negation to `%{?foo:value}`), but
then goes on to use `%{!?foo:value}` in the examples without
The Macros documentation claimed that
```spec
0%{!?with_python3:1}
```
was a shorthand for
```spec
%{?with_python3:1}%{!?with_python3:0}
```
which is expanded to 1 if with_python3 is defined and 0
otherwise.
Thats true of the latter, but not the former, which would expand to `1`
(actually `01`)
@pmatilai
> I don't have a strong opinion either, this was just a statistical observation
>
And therefore technically correct. (["The best kind of
correct!"](https://www.youtube.com/watch?v=hou0lU8WMgo))
--
Reply to this email directly or view it on GitHub:
One thing I noticed, in building and browsing the documentation website locally
(see #2259) is that there's some inconsistency in how the MarkDown source for
the man pages is formatted. It slightly affects the manpage files themselves as
they're output from `pandoc`, but it's far more
@ffesti Thanks, that's a great start!
For completeness it might also need to mention that the extra packages (listed
in `docs/_config.yml`, namely `jekyll-titles-from-headings` and
`jekyll-relative-links`) also need to be installed, in order to to launch
`jekyll`.
It might be possible to
Re: Your commit message note about consistency...
Well, I won't claim that things are perfectly consistent. (The difference
between `find_program()` outputting `CACHE` variables vs. `pkg_check_modules()`
defining (or not) regular local variables is a big part of it. There are no
undefined
@ferdnyc commented on this pull request.
> +…where `` is a legal macro name and `` is the body of the macro.
+Multiline macros can be defined by shell-like line continuation, ie ``\``
I've created #2259 for the above.
--
Reply to this email directly or view it on GitHub:
I responded:
^ Another option would be to have GitHub Actions regenerate the website
automatically on every push to the master branch. (Or, every push that touches
the docs/ subdir. GitHub Actions' job triggers are capable of that level of
precision.)
The Action could either export the
> On a related note, we should have docs/README explaining how to test-render
> locally for rpm.org...
_Originally posted by @pmatilai in
https://github.com/rpm-software-management/rpm/pull/2251#discussion_r1010414825_
--
Reply to this email directly or view it on GitHub:
@ferdnyc commented on this pull request.
> +…where `` is a legal macro name and `` is the body of the macro.
+Multiline macros can be defined by shell-like line continuation, ie ``\``
(I'm assuming the site is pre-rendered to static HTML. If rpm.org runs directly
off the `.md` files and
@ferdnyc commented on this pull request.
> +…where `` is a legal macro name and `` is the body of the macro.
+Multiline macros can be defined by shell-like line continuation, ie ``\``
^ Another option would be to have GitHub Actions regenerate the website
automatically on every push to the
@ferdnyc commented on this pull request.
> @@ -49,14 +49,14 @@ At the end of invocation of a parameterized macro, the
> above macros are
Within the body of a macro, there are several constructs that permit
testing for the presence of optional parameters. The simplest construct
-is "%{-f}"
@ferdnyc pushed 1 commit.
67a0fa39919fca7875d672d5cd2b131370724433 Docs: macros: Add some missing
fencing, fix grammar
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2251/files/865fe590f0335a804f177f04236f77bcd7eecc20..67a0fa39919fca7875d672d5cd2b131370724433
You
@ferdnyc commented on this pull request.
> +`%{?!macro_name:value}` is the negative variant. It is expanded to "value"
+if "macro_name" not is defined. Otherwise it is expanded to the empty string.
Here, by the same logic, "value" wouldn't be fenced -- but `macro_name`
probably should be.
@ferdnyc commented on this pull request.
> @@ -49,14 +49,14 @@ At the end of invocation of a parameterized macro, the
> above macros are
Within the body of a macro, there are several constructs that permit
testing for the presence of optional parameters. The simplest construct
-is "%{-f}"
@ferdnyc commented on this pull request.
> @@ -49,14 +49,14 @@ At the end of invocation of a parameterized macro, the
> above macros are
Within the body of a macro, there are several constructs that permit
testing for the presence of optional parameters. The simplest construct
-is "%{-f}"
@ferdnyc commented on this pull request.
> @@ -71,57 +71,57 @@ to perform useful operations. The current list is
%getconfdir expand to rpm "home" directory (typically /usr/lib/rpm)
%dnldiscard to next line (without expanding)
%verboseexpand to 1
I've updated the PR without the ellipsis change, it should be ready to go now.
Though if we do get info on generating the website content, I'll happily test
whether my changes fix the fencing issue with `\`.
--
Reply to this email directly or view it on GitHub:
@ferdnyc commented on this pull request.
> @@ -71,57 +71,57 @@ to perform useful operations. The current list is
%getconfdir expand to rpm "home" directory (typically /usr/lib/rpm)
%dnldiscard to next line (without expanding)
%verboseexpand to 1
@ferdnyc commented on this pull request.
> -All whitespace surrounding \ is removed. Name may be composed
-of alphanumeric characters, and the character `_' and must be at least
-3 characters in length. A macro without an (opts) field is "simple" in that
-only recursive macro expansion is
@ferdnyc commented on this pull request.
> +…where `` is a legal macro name and `` is the body of the macro.
+Multiline macros can be defined by shell-like line continuation, ie ``\``
I'm not sure if this will work, it depends on the renderer. Currently the
website is showing \`\\\`
This started life with the realization that the RPM website Markdown formatter
was combining double dashes into an en dash, in the docs. (See, for example,
near the end of the second paragraph in the section [Defining a
Macro](https://rpm-software-management.github.io/rpm/manual/macros.html)):
This is _relatively_ minor, but: There's a long-standing convention --
laziness, really -- in the CMake world, of doing out-of-source builds in a
directory named `build`, often located (for convenience) in the top level of
the repo dir. `rpmbuild` living in `/build` screws with that convention.
> For some stats, out of 22000+ packages in Fedora, about 6300 have Patch
> declarations, of which roughly 3500 are still using the `%patch1` style
> syntax. and a whopping 25 are using other variants, including defaulting to 0
> and using a combo of -P and positional arguments etc. The rest
Doesn't help that [the only
example](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_support)
(end of that section) of `%patch` usage that I can find in the Fedora
Packaging Guidelines still uses `%patch0`. Seems this memo really hasn't been
distributed widely enough.
42 matches
Mail list logo
