AArch64 has another common name for the architecture: `arm64`. And while
compilers and RPM use `aarch64`, the kernel and a number of language ecosystems
use `arm64`.
In addition, Debian packages use the `arm64` architecture name to refer to
`aarch64`, and AArch64 packages that are translated fr
Then you are stuck: it's your workload, not the rpmspec parser implementation,
that is the root cause.
--
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/392#issuecomment-36
If I would be querying them sequentially, then it would take hour or so
--
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/392#issuecomment-366439874_
> Since your program appears to be multithreaded, try splitting the 4000
> specfile queries across 10-20 worker threads.
That's exactly what it does.
--
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-so
Ok. So the issue isn't that rpmspec is particularly slow, just that you are
running thousands of queries.
Since your program appears to be multithreaded, try splitting the 4000 specfile
queries across 10-20 worker threads.
--
You are receiving this because you are subscribed to this thread.
Re
@n3npq it's not single spec.. Its 4000+ different specs.
What I wrote there if you run `rpmspec`, then tool is taking 2 minutes to do
the job. If you remove execution of rpmspec, then tool takes 3 seconds.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Um, that snippet of code reveals too little to understand anything.
Still: I am very surprised if any *single* spec file parse takes more than *two
minutes* to parse and retrieve EVR information.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
> Seeing an existing example would really help to justify the additional
> complexity.
As I said, I don't have such an example (and hope won't have for some time).
It's just the kind of things I see upstreams do.
> Such problem smells like equivalent to bootstrapping distro from scratch
> prob
> With git clone so easy nowadays I'm pretty sure some of the language
> upstreams will bake multi-phase BR solving in their tooling sooner or later
> (if not already done).
Seeing an existing example would really help to justify the additional
complexity.
Such problem smells like equivalent t
@n3npq believe me, it is slowest part in my tool ;)
```
287.25user 152.95system 2:11.94elapsed 333%CPU (0avgtext+0avgdata
68724maxresident)k
13648inputs+0outputs (53major+30349595minor)pagefaults 0swaps
```
```diff
diff --git a/src/main.rs b/src/main.rs
index 4b0f2ff..9306517 100644
--- a/src/ma
> I'm not sure calculating "fixed point" for build requires dependency graph is
> required in the first place. Having BuildRequires and then single-step
> dynamic build requires would be powerful enough I think, and easier to
> implement from buildsystem pov.
To be honest, I don't think I need
On Saturday, February 17, 2018 9:57:13 AM CET nim-nim wrote:
> > [snip, mock could ... ]
> > - does installroot and installs BuildRequires as usually
> > - runs %prep
> > - runs %foo_analyzer from %build_requires
> > - runs the rest of the build
> [snip]
>
> That would work too, as long as you tak
> Agreed. IMO rpm should just speficy "script" which prints build-requires to
> standard output. That can/could be: %build_requires # the script content
> /bin/awk ... do something or %build_requires -f
> or %build_requires -s . this way you don't
> have to adjust depsolver, only the build-sy
> Maybe I'm missing the point of the issue (OP to decide), but I think this has
> real and pretty trivial engineering solution for some languages: -
> distribution provides heuristic for language Foo in foo-build package -
> package Baz puts 'foo-build' into build requires - package Baz adds
>
> Theoretically yes, but I don't think we have to go that far. Btw. the set of
> build-requires wouldn't be "constant" for each build of particular package
> and that would be big -1 from me (at least if you consider bootstrapping
> scenario where everything isn't completed yet). Whatever the ca
> Contrarian examples are trivial to devise. Consider an autoconf based
> generated file that builds if (and only if) certain files are detected. None
> of those BuildRequires can be automated and generated during a spec file
> parse with a pipe/file redirection.
That's more or less the Go syst
16 matches
Mail list logo
