The recent developments in what used to be the freenode IRC network
force us to look for a new home for our IRC channels. As a result we -
as so many other projects - are moving to the Libera.chat network.
Discussion about the RPM tool and project itself can continue in the
#rpm channel there. Top
Ok, to translate this to a more generalized feature:
Something needs to create those package declarations during build. For
rust this may be done after %prep but the right time is probably after
%install (or after %check). This way everything there is to be known
about the build is on disk alread
On 5/14/19 5:18 PM, Stefano Simonelli wrote:
> HI everyone,
>
> during the creation of a RPM in the .spec file -
>
> is there a way to print a message if the RPM installation fails for some
> reasons, for example not able to solve the dependencies ?
Well, rpm (and all other tools dealing with rp
On 06/29/2018 01:09 PM, Jonathan Dieter wrote:
> Ok, I've put together an initial proposal at https://fedoraproject.org/
> wiki/Changes/Zchunk_Metadata.
In case you need another argument why this is important:
Fedora is still growing at a linear or may be slightly above linear
rate. So the amount
While I understand that this question is of some interest this is just
not something to be discussed here. Questions about Red Hat's product
policies and features of future RHEL releases or updates need to go
through the official channels.
I can only comment on the technical properties on the alr
Hi!
For quite a while it has become apparent that there are many scripts,
macro files and other rpm related pieces that all the different
distributions maintain on their own. We have been trying to get some of
this merged upstream but there is only so much that can be done there.
Some things are j
Hi!
We are currently pondering about #417 [1]. For adding a %optional file
attribute that would allow adding file to to %files sections that may
not be built under some circumstances (e.g. some architectures).
It is already perfectly legal to have files not listed explicitly if
they are within a
On 10/18/2016 05:23 PM, Pat Riehecky wrote:
> Can a link to http://rpm.org/wiki/PackagerDocs/BooleanDependencies be
> added to
> http://www.rpm.org/wiki/PackagerDocs/Dependencies ?
Good point. Done!
Florian
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial reg
On 10/06/2016 12:39 PM, Vít Ondruch wrote:
>
>
> Dne 6.10.2016 v 12:26 Florian Festi napsal(a):
>> On 10/06/2016 12:16 PM, Vít Ondruch wrote:
>>> Actually is this really DNF issue?
>>>
>>> DNF resolves the dependencies properly and installs what can
On 10/06/2016 12:16 PM, Vít Ondruch wrote:
> Actually is this really DNF issue?
>
> DNF resolves the dependencies properly and installs what can be
> installed. E.g. it keeps the kernel-core-4.6.1-1 which is compatible
> with the module on the system as long as the module is installed, while
> not
On 10/06/2016 12:01 PM, Florian Festi wrote:
> I wonder if this can be done with rich dependencies. It is a bit tricky
> as you cannot have variables in them. So you cannot say:
>
> Conflicts: kernel without matching module_foo
>
> But with the assumption that new kernels hav
I wonder if this can be done with rich dependencies. It is a bit tricky
as you cannot have variables in them. So you cannot say:
Conflicts: kernel without matching module_foo
But with the assumption that new kernels have a bigger version number it
should still work if we add to nvidia-kernel-modu
Changing the way + is treated in version compare is really a bad idea.
So this feature would need a new char that is currently not permitted in
versions. Candidates include: #, ^, @, §, $, ?
For now I have a weak leaning towards ^ (caret) as it indicates
bigger/up although it is used with the oppo
On 04/11/2016 08:30 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> I would shoot for idea where the bla.macros would just sit in git and
>> the packages would specify as sources the macros ie.:
>> Source99: https://github.com/rpm/rpm-macros/archive/python.macros
Yes. This is about what I had in mind wh
On 04/11/2016 08:30 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Apr 11, 2016 at 05:18:29PM +0200, Tomas Chvatal wrote:
>> Orion Poplawski píše v Po 11. 04. 2016 v 09:11 -0600:
>>> On 04/11/2016 07:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
On Fri, Apr 01, 2016 at 01:45:1
On 04/11/2016 10:28 PM, Zbigniew Jędrzejewski-Szmek wrote:
> Maybe ;) But even if they don't, I think the right venue for macro
> sharing between distros are SIGs and small nimble repos, not some
> centralized location to cover all macros.
While I agree I still think having a "central" repo as a s
Listening to the roaring sound of the crickets I guess the issue here is
that there is no such thing as "the rpm macros". There are just all kind
of different macros written, used and maintained by different people for
different purposes.
To get at least some of them synchronized I guess someone n
On 04/07/2016 11:17 AM, Michael Mraka wrote:
> Hi,
>
> while trying to fix bug 1303311 I found out that output of
> --whatrequires is not (very well) defined for rich dependencies.
> I've already discussed it with Lubos K. but we come with couple
> of different solutions not sure which one is the
On 03/04/2016 01:02 PM, Vít Ondruch wrote:
> I would prefer if the language specific macros are not part of RPM
> at all. For Ruby on Fedora, we keep them part of Ruby package and it
> works just fine. Not sure why it should not be case for other
> languages (and I hope that for example Fedora's Pe
Hi!
Looking at the pull requests #37 and #38 [1] for a while I came to the
conclusion that RPM macros are quite a mess. But I could not really come
up with a way to get things cleaned up without breaking existing packages.
In general it is clear that distros and possibly even single packages
with
On 03/01/2016 08:48 PM, Dave Johansen wrote:
> Aside from revision control and the current Fedora system for doing
> builds, it would be nice if the .spec and/or source .rpm had verifiable
> hashes of what the original/intended content is. My understanding is
> that a nefarious agent could easily r
On 03/01/2016 05:18 PM, Neal Gompa wrote:
> One important aspect that would make reproducible builds more
> trustworthy in the RPM world would be some capability to indicate
> checksums for sources and patches so that rpmbuild can verify them.
While this is an interesting topic it is a different o
Hi!
There are several RFEs and patches popping up that revolve around
reproducible builds. Some may have noticed the recent patch adding the
first pieces for supporting SOURCE_DATE_EPOCH[1].
>From the looks of it there is a quite active group within Debian working
on the topic[2] but this topic c
On 02/26/2016 05:19 PM, Nick Clifton wrote:
> Hi Guys,
>
> [I apologise if this is the wrong way to ask questions on this list - this
> is my first posting].
>
>
> I would like to suggest a change to the brp-strip-static-archive script so
> that in addition to stripping the debug inform
On 12/12/2015 02:54 PM, Igor Gnatenko wrote:
> Hi all,
>
> With OpenCL currently we have some implementations:
> * Beignet (Intel GPU)
> * POCL (Any CPU)
> * mesa-LibOpenCL (AMD GPU, probably something supported fro NVIDIA GPU)
>
> I am thinking how to make it user-friendly. Any ideas?
RPM upstr
Hi!
There is an issue in the behavior of the %setup macro. When combining
the -c and -b parameters the -b (drop file before changing into sub dir)
acts like -a (drop file after changing into sub dir). This is now fixed
in HEAD and will most likely be part of the next RPM release.
*Distributions
On 09/08/2015 02:31 PM, Neal Gompa wrote:
> Bumping this thread to again ask if more of the RPM ecosystem software
> could be brought into the rpm-software-management GitHub organization.
> While libsolv doesn't need to go into the organization, as it isn't
> really RPM specific, librepo, libcomps,
On 09/01/2015 02:20 AM, Neal Gompa wrote:
> On Mon, Aug 31, 2015 at 10:14 AM, Florian Festi <mailto:ffe...@redhat.com>>wrote:
>
> My thought after the discussion so far:
>
> May be no one really cares about the syntax.
> Still a lot of educating to
My thought after the discussion so far:
May be no one really cares about the syntax.
Still a lot of educating to do before rich deps go into production.
On 08/25/2015 02:11 PM, Florian Festi wrote:
> IF Operator
Guess we stay with (. IF . ELSE .) - even some people are more familiar
w
On 08/26/2015 11:23 PM, James Antill wrote:
> On Wed, 2015-08-26 at 10:29 +0200, Florian Festi wrote:
>> On 08/25/2015 06:12 PM, Pavel Odvody wrote:
>>> On Tue, 2015-08-25 at 18:01 +0200, Florian Festi wrote:
>>>> Well, as Requires are (logically) all connected with
On 08/26/2015 02:58 PM, Vít Ondruch wrote:
> Dne 26.8.2015 v 14:00 Florian Festi napsal(a):
>> On 08/26/2015 10:47 AM, Florian Festi wrote:
>>> Right now libsolv does not distinguish between different orders of the
>>> operands. But we have already discussed making the
On 08/26/2015 10:47 AM, Florian Festi wrote:
> Right now libsolv does not distinguish between different orders of the
> operands. But we have already discussed making the OR operator
> preferring the left most operand. This is something RPM does not really
> care about but
On 08/26/2015 12:13 PM, Vít Ondruch wrote:
> Dne 25.8.2015 v 17:16 Florian Festi napsal(a):
>> On 08/25/2015 02:50 PM, Vít Ondruch wrote:
>>> Dne 25.8.2015 v 14:11 Florian Festi napsal(a):
>>>> Hi!
>>>>
>>>> I have been visiting Michael Sc
On 08/25/2015 06:58 PM, Neal Gompa wrote:
> I consider the NOT evaluation to be useful for intent more than anything
> else.
>
> For example: "Requires: (pkgA IF NOT pkgB)" or "Requires: (IF NOT pkgB
> THEN pkgA)"
> That lines says two things to me:
>
> * The package prefers pkgB over pkgA
>
On 08/25/2015 06:06 PM, Pat Riehecky wrote:
> I'm mostly just kicking an idea around, but is
>
> Requires(IF lansupport-es): foo-lang-es
>
> at all interesting looking? It has the advantage of following the
> Requires(post, et all) syntax that currently exists.
No.
The new operators can be nest
On 08/25/2015 06:12 PM, Pavel Odvody wrote:
> On Tue, 2015-08-25 at 18:01 +0200, Florian Festi wrote:
>> On 08/25/2015 05:54 PM, Pavel Odvody wrote:
>>>> Technically a NOT operator should not be needed. So we are basically
>>>> looking for real life examples where
Ok, it looks like a lot of people are having trouble with the semantics
of the rich deps operators. I'll try a short introduction:
Requires, Recommends, Suggests, Supplements, Enhances and Conflicts are
all matched against the Provides.
With the new rich deps Provides stay the way they are (NAME
On 08/25/2015 05:54 PM, Pavel Odvody wrote:
>> Technically a NOT operator should not be needed. So we are basically
>> looking for real life examples where it would be really handy or even a
>> pain if it was missing. What would you do with a NOT operator?
>>
>
> Requires: (PkgA AND (PkgB IF NOT P
On 08/25/2015 02:50 PM, Vít Ondruch wrote:
> Dne 25.8.2015 v 14:11 Florian Festi napsal(a):
>> Hi!
>>
>> I have been visiting Michael Schröder discussing the syntax for the
>> rich deps [1]. There are still a few issues we like to get some
>> input from the wi
Hi!
I have been visiting Michael Schröder discussing the syntax for the rich
deps [1]. There are still a few issues we like to get some input from
the wider community:
IF Operator
===
We concluded that the most important question was what to do with the if
operator. There are two basic va
40 matches
Mail list logo
