Re: [Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)
A testing spec file that I used to benchmark this patch:
```
%global _smp_build_nthreads 2
Name: foo
Version:1.0
Release:1%{?dist}
Summary:testing package for parallel building
License:GPL
%description
%package light1
Summary:light subpackage 1
%description light1
%package light2
Summary:light subpackage 2
%description light2
%package light3
Summary:light subpackage 3
%description light3
%package light4
Summary:light subpackage 4
%description light4
%package heavy1
Summary:heavy subpackage 1
%description heavy1
%install
mkdir -p %{buildroot}/%{_libdir}
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light1.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light2.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light3.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light4.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_heavy1.so count=120 bs=10M
%files light1
%{_libdir}/libfoo_light1.so
%files light2
%{_libdir}/libfoo_light2.so
%files light3
%{_libdir}/libfoo_light3.so
%files light4
%{_libdir}/libfoo_light4.so
%files heavy1
%{_libdir}/libfoo_heavy1.so
%changelog
* Mon Mar 2 2020 Michal Domonkos
-
```
On my laptop, the total build time is `~1:35s` and `~1:20s` before and after
the patch, respectively. Not a huge difference here, but thread utilization is
be a bit better now and should help with the really-big packages like the
kernel (haven't tried that yet).
--
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/1180#issuecomment-613631284___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Order Packages by size during build (#1045)
A testing spec file that I used to benchmark this patch:
```
%global _smp_build_nthreads 2
Name: foo
Version:1.0
Release:1%{?dist}
Summary:testing package for parallel building
License:GPL
%description
%package light1
Summary:light subpackage 1
%description light1
%package light2
Summary:light subpackage 2
%description light2
%package light3
Summary:light subpackage 3
%description light3
%package light4
Summary:light subpackage 4
%description light4
%package heavy1
Summary:heavy subpackage 1
%description heavy1
%install
mkdir -p %{buildroot}/%{_libdir}
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light1.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light2.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light3.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_light4.so count=30 bs=10M
dd if=/dev/urandom of=%{buildroot}/%{_libdir}/libfoo_heavy1.so count=120 bs=10M
%files light1
%{_libdir}/libfoo_light1.so
%files light2
%{_libdir}/libfoo_light2.so
%files light3
%{_libdir}/libfoo_light3.so
%files light4
%{_libdir}/libfoo_light4.so
%files heavy1
%{_libdir}/libfoo_heavy1.so
%changelog
* Mon Mar 2 2020 Michal Domonkos
-
```
On my laptop, the total build time is `~1:35` and `~1:20` before and after the
patch, respectively. Not a huge difference here, but thread utilization is be a
bit better now and should help with the really-big packages like the kernel
(haven't tried that yet).
--
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/1045#issuecomment-613630451___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)
Binary packages come in different sizes and so their build time can vary greatly. Dynamic scheduling, which we currently use for parallel building, is a good strategy to combat such differences and load-balance the available CPU cores. That said, knowing that the build time of a package is proportional to its size, we can reduce the overall time even further by cleverly ordering the task queue. As an example, consider a set of 5 packages, 4 of which take 1 unit of time to build and one takes 4 units. If we were to build these on a dual-core system, one possible unit distribution would look like this: TIME ---> CPU 1 * * * * * * # package 1, 3 and 5 CPU 2 * * # package 2 and 4 Now, compare that to a different distribution where the largest package 5 gets built early on: TIME ---> CPU 1 * * * * # package 5 CPU 2 * * * * # package 1, 2, 3 and 4 It's obvious that processing the largest packages first gives better results when dealing with such a mix of small and large packages (typically a regular package and its debuginfo counterpart, respectively). Now, with dynamic scheduling in OpenMP, we cannot directly control the task queue; we can only generate the tasks and let the runtime system do its work. What we can do, however, is to provide a hint to the runtime system for the desired ordering, using the "priority" clause. So, in this commit, we use the clause to assign a priority value to each build task based on the respective package size (the bigger the size, the higher the priority), to help achieve an optimal execution order. Indeed, in my testing, the priorities were followed to the letter (but remember, that's not guaranteed by the specification). Interestingly, even without the use of priorities, simply generating the tasks in the desired order resulted in the same execution order for me, but that's, again, just an implementation detail. Also note that OpenMP is allowed to stop the thread generating the tasks at any time, and make it execute some of the tasks instead. If the chosen task happens to be a long-duration one, we might hit a starvation scenario where the other threads have exhausted the task queue and there's nobody to generate new tasks. To counter that, this commit also adds the "untied" clause which allows other threads to pick up where the generating thread left off, and continue generating new tasks. Resolves #211. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1180 -- Commit Summary -- * build: prioritize large packages -- File Changes -- M build/pack.c (30) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1180.patch https://github.com/rpm-software-management/rpm/pull/1180.diff -- 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/1180 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.16.0a regression in rpmbuild: "Tag takes single token only" (#1167)
@soig As an aside, we really should fix that typo... `%_vendor` not being `mageia` bites me in a lot of surprising places... :( -- 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/1167#issuecomment-613490745___ 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: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
Lets just say I'm not at all convinced those copies should be visible in queries at all, seems to me more like an internal implementation detail that should be hidden away in the tooling. Also thinking that dealing with it runtime allows far more flexibility in what to do with them and works with all existing packages without rebuilds for content that already is there. -- 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/1178#issuecomment-613483372___ 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: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
Regarding doing the copies at install time: The nice thing about having them as normal files in the header is that we get automatic de-dup and refcounting. I.e. we can do a 'rpm -qf ...' to find out the owners of a config file and they get automatically removed if nobody owns them anymore. We can opt to have them as ghosts in the header and do some magic at install time, but I'm not sure if it's worth the trouble as config files tend to be small. -- 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/1178#issuecomment-613447480___ 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: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
FWIW, I'm not hot about debconf at all, and rpm needs to stay true to its non-interactive design. However the ability to compare with and restore pristine configuration are highly useful capabilities, it's almost embarrassing that rpm doesn't support them. -- 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/1178#issuecomment-613442159___ 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: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
That all depends... /var would be more appropriate for runtime created files, /usr for packaged content. -- 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/1178#issuecomment-613440516___ 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: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
So this sounds like the beginnings of wanting to support something like debconf on RPM. Interesting idea... That said, I dispute putting it in `/usr/lib/rpm/config`. The standard location for this stuff to exist should be in `/var/lib/rpm/config`. Basically, wherever the rpmdb is, that's where this should be 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/1178#issuecomment-613389156___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove nss backend from rpm (#1175)
At least can it be deprecated like beecrypt is? -- 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/1175#issuecomment-613382185___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
@pmatilai commented on this pull request.
> @@ -1,4 +1,28 @@
-%__python_provides %{_rpmconfigdir}/pythondeps.sh --provides
-%__python_requires %{_rpmconfigdir}/pythondeps.sh --requires
+%__python_provides() %{lua:
+-- Match buildroot/payload paths of the form
+--/PATH/OF/BUILDROOT/usr/bin/pythonMAJOR.MINOR
+-- generating a line of the form
+--python(abi) = MAJOR.MINOR
+-- (Don't match against -config tools e.g. /usr/bin/python2.6-config)
+local path = rpm.expand('%1')
+if path:match('/usr/bin/python%d+%.%d+$') then
In the meanwhile:
https://github.com/rpm-software-management/rpm-web/commit/b34c9a9c5db052acf64334913bd87e73e6e8ef79
(but that doc is in desperate need of a full overhaul...)
--
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/1153#discussion_r408052888___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove nss backend from rpm (#1175)
In time, sure. Right now seems a bit premature for our glacial nature though. When it eventually does go, it belongs to a mausoleum to forever remind us of the the pain. -- 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/1175#issuecomment-613367635___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
@hroncok commented on this pull request.
> @@ -1,4 +1,28 @@
-%__python_provides %{_rpmconfigdir}/pythondeps.sh --provides
-%__python_requires %{_rpmconfigdir}/pythondeps.sh --requires
+%__python_provides() %{lua:
+-- Match buildroot/payload paths of the form
+--/PATH/OF/BUILDROOT/usr/bin/pythonMAJOR.MINOR
+-- generating a line of the form
+--python(abi) = MAJOR.MINOR
+-- (Don't match against -config tools e.g. /usr/bin/python2.6-config)
+local path = rpm.expand('%1')
+if path:match('/usr/bin/python%d+%.%d+$') then
https://github.com/rpm-software-management/rpm/pull/1179
--
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/1153#discussion_r408038618___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Adjust %__python_path (#1179)
- sync with Fedora - only match direct Python sitedir, no /opt/.../lib/python3.7 stuff - prep for multiple digits Python major releases (e.g. 12.1) - use the value of %_prefix See also: https://src.fedoraproject.org/rpms/python-rpm-generators/c/8eef42cbaa6ff0e5c006959fc06ec115ed5ca37b https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/UFKUM5UKCTNGIT3KJVYEI5VXPI23QMBN/ https://github.com/rpm-software-management/rpm/pull/1153#discussion_r407997958 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1179 -- Commit Summary -- * Adjust %__python_path -- File Changes -- M fileattrs/python.attr (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1179.patch https://github.com/rpm-software-management/rpm/pull/1179.diff -- 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/1179 ___ 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: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
We could also create such copies at runtime to avoid duplicated content in packages - most %config is small of course, but shipping dupes just seems ugly. I've been dreaming of a git plugin for rpm config files for quite some time... -- 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/1178#issuecomment-613361580___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
If a file is marked as config file, rpmbuild could automatically create a copy and store it in `/usr/lib/rpm/config/first-digest-byte/file-digest`. We can then make use of this to: - allow to display the changes done by the user - use a three-way merge algorithm - handle digest algorithm changes more gracefully To support this, we just need to change the build part. No incompatibilities arise. -- 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/1178___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
@hroncok commented on this pull request.
> @@ -1,4 +1,28 @@
-%__python_provides %{_rpmconfigdir}/pythondeps.sh --provides
-%__python_requires %{_rpmconfigdir}/pythondeps.sh --requires
+%__python_provides() %{lua:
+-- Match buildroot/payload paths of the form
+--/PATH/OF/BUILDROOT/usr/bin/pythonMAJOR.MINOR
+-- generating a line of the form
+--python(abi) = MAJOR.MINOR
+-- (Don't match against -config tools e.g. /usr/bin/python2.6-config)
+local path = rpm.expand('%1')
+if path:match('/usr/bin/python%d+%.%d+$') then
Will open another PR.
> the classifier regex is applied on a path without %{buildroot} so the ^ is
> fine
I've verified this (as the `^` wuold obviously brek it otherwise).
>However the %{1} argument does include the %{buildroot}
That's why the `^` is only applied here and not in the generator code. I think
it works well like this.
> This point probably deserves a clear note in the generator docs.
Indeed, it would be helpful if this is a documented behavior and not just
implementation detail.
> It also does make me wonder if this should be configurable somehow: many/most
> generators will look at the file contents, in which case they do need the
> buildroot prepended, but there are generators operate on the path alone, and
> in those cases it'd be somewhat easier to have the path as packaged without
> the buildroot. Such as here.
The current behavior is fine. You can safely ignore the beginning of the path
if you don't need it - as does this generator.
--
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/1153#discussion_r408030639___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle manually specified debuginfo package more gracefully (#1177)
Merged #1177 into master. -- 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/1177#event-3230486935___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] ndb: do not mmap the index database read-write all the time (#1176)
Merged #1176 into master. -- 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/1176#event-3230474973___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle manually specified debuginfo package more gracefully (#1177)
@mlschroe approved this pull request. -- 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/1177#pullrequestreview-392794740___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
@pmatilai commented on this pull request.
> @@ -1,4 +1,28 @@
-%__python_provides %{_rpmconfigdir}/pythondeps.sh --provides
-%__python_requires %{_rpmconfigdir}/pythondeps.sh --requires
+%__python_provides() %{lua:
+-- Match buildroot/payload paths of the form
+--/PATH/OF/BUILDROOT/usr/bin/pythonMAJOR.MINOR
+-- generating a line of the form
+--python(abi) = MAJOR.MINOR
+-- (Don't match against -config tools e.g. /usr/bin/python2.6-config)
+local path = rpm.expand('%1')
+if path:match('/usr/bin/python%d+%.%d+$') then
I don't see any problems with that.
BTW as for the %{buildroot} part: the classifier regex (`%__python_path` here)
is applied on a path without %{buildroot} so the ^ is fine. However the %{1}
argument *does* include the %{buildroot} - the situation is the same with
"traditional" generators. This point probably deserves a clear note in the
generator docs.
It also does make me wonder if this should be configurable somehow: many/most
generators will look at the file contents, in which case they do need the
buildroot prepended, but there *are* generators operate on the path alone, and
in those cases it'd be somewhat easier to have the path as packaged without the
buildroot. Such as here.
--
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/1153#discussion_r408027905___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Handle manually specified debuginfo package more gracefully (#1177)
In todays' "look ma what crawled from under the bed" episode, we have encounter a subpackage whose name is not derived from the main package name, and a manually specified debuginfo package on that. This particular combo manages to evade all our checks for duplicate package names, and in the right phase of the moon actually creates corrupt packages due to two threads end up writing to the same output file simultaneously. Which is what happened in https://pagure.io/fedora-infrastructure/issue/8816 Catch the case and use the spec-defined variant (because getting rid of it would be harder) but issue a warning because most likely this is not what they really wanted. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1177 -- Commit Summary -- * Handle manually specified debuginfo package more gracefully -- File Changes -- M build/files.c (12) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1177.patch https://github.com/rpm-software-management/rpm/pull/1177.diff -- 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/1177 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] ndb: do not mmap the index database read-write all the time (#1176)
Use read-only mapping for the index databases if the user only requested read-only database access. Also map the xdb database header read-only and only switch to a read-write mapping if an operation is done that needs write access. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1176 -- Commit Summary -- * ndb: also copy the mapped pointer when keeping a slot * ndb: do not map the index databases read-write all the time * ndb: do not map xdb's header read-write all the time * ndb: unmap xdb's header when closing the xdb database * Add an index sync call at the end of a database rebuild * ndb: make rpmxdbWriteHeader a void function -- File Changes -- M lib/backend/ndb/glue.c (11) M lib/backend/ndb/rpmidx.c (8) M lib/backend/ndb/rpmidx.h (2) M lib/backend/ndb/rpmxdb.c (67) M lib/rpmdb.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1176.patch https://github.com/rpm-software-management/rpm/pull/1176.diff -- 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/1176 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
@hroncok commented on this pull request.
> @@ -1,4 +1,28 @@
-%__python_provides %{_rpmconfigdir}/pythondeps.sh --provides
-%__python_requires %{_rpmconfigdir}/pythondeps.sh --requires
+%__python_provides() %{lua:
+-- Match buildroot/payload paths of the form
+--/PATH/OF/BUILDROOT/usr/bin/pythonMAJOR.MINOR
+-- generating a line of the form
+--python(abi) = MAJOR.MINOR
+-- (Don't match against -config tools e.g. /usr/bin/python2.6-config)
+local path = rpm.expand('%1')
+if path:match('/usr/bin/python%d+%.%d+$') then
So in Fedora, we now have this:
https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/10
```
%__python_path
^((%{_prefix}/lib(64)?/python[[:digit:]]+\\.[[:digit:]]+/.*\\.(py[oc]?|so))|(%{_bindir}/python[[:digit:]]+\\.[[:digit:]]+))$
```
Is this applicable to upstream, or shall be keep our own regex?
--
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/1153#discussion_r407997958___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
Thanks for being helpful. -- 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/1153#issuecomment-613332075___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert few simple generators for a parametric ones + fix for parametric generators (#1163)
> Related to this, I have not seen your opinion on moving these things to a > rpm-extras and start actually releasing those things and inform > distributions. WDYT? To put it in words of Finnish F1-champions: "Yes." Sorry, couldn't resist :rofl: Seriously though, debuginfo certainly belongs to rpm itself as rpm is what generates them to begin with. Metainfo and desktop are both quite ubiquitous and used across language domains, so dunno, maybe. If/when rpm-extras is properly integrated etc there wouldn't be any big difference where things live, but atm... -- 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/1163#issuecomment-613327497___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
Oh and while I did compliment on the job, I didn't thank for it. So here goes: thanks! :grin: -- 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/1153#issuecomment-613321549___ 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: Reimplement pythondeps.sh as parametric macro generators (#1152)
Closed #1152 via #1153. -- 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/1152#event-3230195638___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
Okay, no news is good news and nothing heard from Fedora in the 10 days this has been enabled there, lets just merge. -- 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/1153#issuecomment-613320020___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reimplement pythondeps.sh as parametric macro generators (#1153)
Merged #1153 into master. -- 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/1153#event-3230195629___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
