commit f3f763e54d introduced the use of 'read -d' which is bash
specific.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2757
-- Commit Summary --
* Switch brp-compress to bash
-- File Changes --
M scripts/brp-compre
@pmatilai found a much simpler solution as rpm can do printf style padding all
by itself. learned something new today!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2606#issuecomment-1672019918
You are receiving this because you are sub
@dirkmueller pushed 1 commit.
9b87d712b489bcfea6a35bfd39f00031231516ee Rewrite --last to just use sed for
formatting
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2606/files/f8d68011addf2e1ddebbaf7f7f68030bf7f6acd6..9b87d712b489bcfea6a35bfd39f00031231516ee
You are r
@pmatilai are there many users of rpm(1) outside a GNU environment? I do agree
that lua macros would be perfect but it was exceeding my available time for all
of this..
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2606#issuecomment-16
This is the only dependency on awk in the runtime commandline part of rpm,
which is bloating minimal container images a bit. We can rewrite that into a
single sed statement. We love you anyway, awk.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software
> > This is an orthogonal discussion. you can have multiple variants in both
> > suggestions of mine (also in the fragmet suffix)
>
> Maybe you din't notice but I've proposed not one but two variants. Main point
> which I've added is to use pk11 like csum format. From that point of view
> every
@kloczek I am fully aware of the autonumbering functionality for
sources/patches, but SourceCSum is not backward compatible with older rpm
versions, so you would have to do something like
```spec
%if %{with somecondition}
Source: file1
%if %rpm_is_new_enough
SourceCSum: sha256(checksum)
%endif
> I would like to see something more like pk11 format
>
> ```python
> SourceCSum: sha256://
```
I think that makes it really tricky with ordering (is it applying to the next
source or the previous one? and what if there are conditionals around source
lines?). imho really not very intuitive as i
> > Unfortunately the suggested format of `Source(sha256): format` is not
> > backward compatible with older rpm releases, and having the checksum as an
> > extra tag (with autonumbering) and if conditions could be error prone and
> > tricky.
> Is backward compatibility really an issue if we're
Unfortunately the suggested format of `Source(sha256): format` is not backward
compatible with older rpm releases, and having the checksum as an extra tag
(with autonumbering) and if conditions could be error prone and tricky. so
@mlschroe came up with an alternative proposal:
```
Source sha256
I like the idea and I came up with a similar syntax some time ago (just in my
head):
```
Source0: https://host/path/to/tarball.tar.gz
Source0(sha512):
Source0(sha1):
```
if any of those are set, rpm should (always, optionally?) check the checksum
before starting with %prep. potentia
If the main concern is the addition of assembly, there are options:
* https://github.com/anrieff/libcpuid which is packaged in many distributions
already for handling cpu feature detection via cpuid
* *cough* parsing /proc/cpuinfo for level determination
--
Reply to this email directly or view
@dirkmueller commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64
@dirkmueller commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64
@dirkmueller commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64
can you include in `macros.in` also a %x86_64 macro that covers this new family
of architectures?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-134264
You are receiving this because you are subscribed to this threa
16 matches
Mail list logo
