perl-interpreter does not depend on perl-macros any longer

2020-09-24 Thread Petr Pisar
Hello,

I'd like to inform Fedora packagers that I removed the long-overlooked and
useless post-install dependency from perl-interpreter on perl-macros package
(effective since perl-interpreter-5.32.0-463.fc34). I don't forsee any
consequences, but here are the details:

perl-macros delivers RPM macros that are sometimes used in spec files when
packaging Perl software. Because perl-macros is transitively required by
perl-generators per FPC decision
, only
packages that do not build-require perl-generators and perl-macros, but that
use the macros will be affected. I believe that there is no such package.

Nevertheless, if you happen that some of the macros from
 become
undefined for you, build-requiring perl-macros should fix it.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

2020-09-18 Thread Petr Pisar
On Fri, Sep 18, 2020 at 12:21:15PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 18 September 2020 at 11:22, Petr Pisar wrote:
> > On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> > > So: RH Java packagers, what if you build these packages as non-modular
> > > (maybe using some scripting to make it happen at the same time as modular
> > > builds?) and add a readme explaining their maintenance state?
> > 
> > Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
> > directory? That won't work, because nobody looks there.
> 
> I do. :)
> 
> What about https://src.fedoraproject.org/rpms//blob/master/f/README.md ?
> 
Do you think that package users consult dist-git before reporting a bug?
I think the idea with a template in Bugzilla was better.

Moreover that file was supposed to display a source package description on all
possible places (and originally was supposed to automatically updated from SRPM
packages, but that was never implemented).

At the end a packager can put the notice into %description of the spec file.
I sometimes document there how the files are distributed among the subpcackages.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Shouldn't we have process for removing zombie packages?

2020-09-18 Thread Petr Pisar
On Fri, Sep 18, 2020 at 10:42:00AM +0200, Vít Ondruch wrote:
> This is not about nagging maintainer for the purpose of nagging them.
>
Filing the requests en mass is exactly nagging for nagging. But

> I feel exhausted seeing again and again packages which are very likely
> broken,

if the package is broken, then file a bug. That's a completely different
case.

> serving no purpose.

That's a strong assertion. I hope that you know that a non-existance is not
getting proved by claiming "I think there is none". But again, if you don't
like the package, file a bug with the explanation why you think it should be
removed.

> I feel exhausted seeing that these packages pull in dependency chains which
> are not possible to be updated or removed due to them.
>
If you need to update the dendency, then update the dependency and report
a bug against the then broken package. See openssl package for an example.

All I want to say that these issues should be handled case by case. There
should be a reason for each of them and the bug report should be tailored to
that case. But pushing the work of a responsible bug report from the reporter
to the assignee is wrong.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

2020-09-18 Thread Petr Pisar
On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> So: RH Java packagers, what if you build these packages as non-modular
> (maybe using some scripting to make it happen at the same time as modular
> builds?) and add a readme explaining their maintenance state?

Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
directory? That won't work, because nobody looks there.

Either the package should be moved into a separate repository that an end user
have to explicitly enable and later can inspect an origin of the package with
"dnf info $PACKAGE", or the package should not be distributed at all. Pungi
tool that produces the distribution composes supports it. It's only a matter
of configuration.

(Or we can invent a new RPM tag for a support level of the package.)

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Shouldn't we have process for removing old packages?

2020-09-18 Thread Petr Pisar
On Thu, Sep 17, 2020 at 09:09:51PM +0200, Vít Ondruch wrote:
> Dne 17. 09. 20 v 18:29 Kevin Fenzi napsal(a):
> > Well, many maintainers don't touch packages that keep working and don't
> > need updates or bugfixes.
> 
> That is perfectly fine and I expect that in such cases, the maintainer
> would step up and responded to BZ, explained situation and intentions,
> everything would be documented and we could move on. But maintainers
> also does not touch packages, because the keep building and that is
> different situation.
>
I think that nagging maintainers with "Do you want to keep your package in
Fedora" question is too burdensome for the maintainers and a disservice for
the users.

> > So, if we know the package doesn't work, we
> > should file a bug on it. If not, I am not sure if we should try and
> > remove such packages. 
> 
> Just out of curiosity, I filed this bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1880144
> 
> I used to see a lot of similar packages in Ruby land. Nowadays, they are
> finally gone, because somebody used the non-responsive maintainer policy
> in the end. But I don't want to use non-responsive maintainer policy,
> because I think some package does not serve it purpose anymore.
> 
How exactly does a presence of that package offend you? That relengs have to
rebuild it twice a year? That you have to download the few kilobytes in
repodata? That when you change Ruby packaging standards, you have to patch the
spec file?

I think that a package should be removed for a real issue that it causes. Not
because of its age.

> Actually, maintaining 200 packages myself, it might happen that some of
> them are in zombie state. I would not mind if they were called out via
> this process.
> 
Then start with yourself. Go and file bugs for your 200 packages. Then review
whether they are used by Fedora users. Be ware that Fedora packager is not
a Fedora user. And then close the bugs or retire the packages. And then come
and tell us how much fruitful it was and how much productive you were.

If you feel exhausted by maintaingin the 200 packages, then orphan them.
Fedora already has a process for dealing with unmaintained packages.
A spoiler: Eventually they will be removed from the distribution.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: LTO is broken in Rawhide/33 containers

2020-09-17 Thread Petr Pisar
On Thu, Sep 17, 2020 at 01:24:26AM -0400, Elliott Sales de Andrade wrote:
> When using Fedora's containers, LTO appears to be broken. I'm not sure
> who to report this to, the container builder or gcc.
>
> $ podman run --pull=always --rm -it registry.fedoraproject.org/fedora:rawhide
> # dnf install -y gcc
> # echo 'int main(void) { int class=0; return class; }' > sanitycheck.c
> # gcc -flto=auto sanitycheck.c -o sanitycheck
> lto-wrapper: fatal error: execvp: No such file or directory
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> 
> The test file is what Meson compiles as a check. This also fails on
> fedora:33. For good measure, you can throw in a `dnf update -y`, but
> it does not update/fix anything.
> 
> Running a similar check in `mock -r fedora-rawhide-x86_64` --shell works fine.
> 
This looks like . Please
use Bugzilla for reporting bugs in a packaging.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-11 Thread Petr Pisar
On Thu, Sep 10, 2020 at 09:59:05PM +, Zbigniew Jędrzejewski-Szmek wrote:
> For Maven packaging the appeal of Modularity is clearly the privatization of
> the dependency tree, which obviously undercuts the ecosystem of packages.
> 
You are right that bundling is one of the features of Modularity and that this
freedom undermines an integration effort on the Fedora distribution level.

But bundling is not the only appeal for Maven maintainers. If I can speek for
Mikolaj, then another appeal is sharing a module among multiple Fedora
releases. Because byte-compiled Java code is portable, it is possible to build
a module on Fedora 31 and have the same module build available on Fedora 34.
This saves the module maintainers from the burden of rebuilding the Java
packages for each Fedora and Modularity is the first place that actuallty can
leverage this Java feature.

> If there wasn't Modularity and instead Maven would bundle it's deps into
> one huge srpm, the effect on the ecosystem would be the same.

Not really. Modules are collections of packages and various modules can share
the sources of the same packages. That means that Modularity does not prevent
from sharing a maintenance cost of the packages. It only makes it more
difficult, because of worse discoverbility and a wider selection of the
choice.

> Modularization gives short-term relief at a very high long-term
> cost. We should avoid modularization like we avoid bundling.

Sarcasm: I really like how other one people order other ones that they have to
maintain the packages for them.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-10 Thread Petr Pisar
On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> 
> > 4.  The benefit we want to preserve from modules is to maintain packages 
> > with varying expectation of quality, specifically separating the 
> > build-time-only vs runtime dependencies.  e.g. in that case that a web 
> > server like Eclipse Jetty is required as a dep for testing another 
> > component during the build, we want to be able to use and build that 
> > component, without being indefinitely on the hook for security errata.  
> > (The build dependency tree is particularly complex for Maven and 
> > involves many examples of packages with frequent and high severity 
> > vulnerabilies)
> 
> What are you doing different in terms of supporting deps in the module
> that reduces the security errata burden, compared to non-modular builds ?
> 
> It feels like if we have some policy that is creating unsustainable
> maint burden wrt non-modular packaging, we should re-examine this
> policy rather than trying to workaround it by going modular, which
> creates a different kind of maint burden.
> 
In non-modular Fedora all packages that we have in Fedora build system (Koji)
are tagged into Fedora repositories and made available to all users on their
computers for any purpose. That implies that all packages in Fedora build system
must be fully supported including addressing all security issues.

In modular Fedora that's (effectively) not true. Packages that only exist
for the sake of building other packages (i.e. build-only dependencies) can be
retained in the Fedora build system and never left it. That means those
packages are never made available to Fedora users and thus a service level for
them is significantly lower. E.g. no security fixes, not bug fixes, no
integration, not tests, no API/ABI stability. The only requirement is that
they can be built and used for building other packages.

I wrote that it was not effectively true. There is probably no such policy
that would de jure allowed lowering the service level for the build-only
packages. But at the same time there is nobody who could enforce it. Users do
not have the packages, security team does know about them, they cannot break
a compose, and they do not intefere with packages from other modules. The only
place where they are visible is dist-git and Koji. Thus they only need to pass
a review (a legal requirement).

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: proposal: EPEL 8 Next

2020-09-09 Thread Petr Pisar
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> To solve this problem, I am proposing that we create a new repository called
> EPEL 8 Next.
> 
> - built against CentOS 8 Stream
> - opt-in for packagers (must request epel8-next dist-git branch)
> - opt-in for users (part of epel-release but disabled by default)
> - used *with* epel8, not *instead of*
> 
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it
is to be use with Stream, why don't we call it EPEL 8 Stream? I think the
meaning of the repository would be easier to understand.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: /etc/localtime is not a symlink on koji?

2020-09-08 Thread Petr Pisar
On Tue, Sep 08, 2020 at 04:00:14AM -0400, Elliott Sales de Andrade wrote:
> I'm debugging an issue in  a FTBFS, which appears caused by unexpected
> warnings during a build [1]. These warnings come from R and complain
> that /etc/localtime is not a symlink.
> 
> According to `man 5 localtime` [2], /etc/localtime cannot be a normal
> file or hard link.
> Is this something wrong in koji, or its builders?
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=50987042
> [2] https://www.freedesktop.org/software/systemd/man/localtime.html

I hit this issue many years ago and tzdata maintainer claimed
 that it was a fault
of a mock tool. (Mock tool is used when building a package in Koji). I asked
a maintainer of mock to fix it
 and he "fixed" it by not
creating /etc/localtime at all. In the mean time I implemented a work around
in one of mine affected packages and has not seen any issue like that. (Except
of a user who complained that the Fedora package survives longer before
reporting an error than an upstream's code.)

What's your issue now? Is /etc/localtime a normal file again, or is the error
message wrong and the file is missing completely?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: About the Future of Communishift

2020-09-04 Thread Petr Pisar
On Fri, Sep 04, 2020 at 11:13:19AM +0100, Aoife Moloney wrote:
> However, the General Data Protection Regulation (GDPR) [3] and the California
> Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure team
> (and thus Red Hat) responsible for the content hosted by any services running 
> in
> our infrastructure. In other words, the Fedora Infrastructure team would be
> responsible to answer all GDPR/CCPA related requests and requirements for any
> and all services running in communishift (services that the team has 0 
> knowledge
> about, that's the whole goal of communishift).
> 
Is Fedora Project going to shut down ? Or what's
the key difference between hosting data and hosting applications from GDPR and
CCPA point of view?

I'm not a lawyer, I but I think your interpretation of GDPR is somewhat
exagarated. Otherwise everybody would close his cloud services, and that's not
what I can observe.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: python2-jsonschema update

2020-09-03 Thread Petr Pisar
On Thu, Sep 03, 2020 at 08:21:38AM +, TREHIOU Paul wrote:
> I am using the python2-jsonschema package but noticed it is out of date on
> EPEL (2.5.1). On Fedora the latest version is available (3.2.0). Is it
> possible to backport the latest Fedora version into EPEL ?
> 
I recommend you to follow a similar request in Bugzilla
.

> This message and any attachments are confidential and intended for the named
> addressee(s) only.

This mailing list is public. Do not send confidentatial messages here.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

2020-09-01 Thread Petr Pisar
On Fri, Aug 28, 2020 at 01:47:14PM -, Martin Gansser wrote:
> when I want to do a review with:  fedora-review -m fedora-rawhide-x86_64 -b 
> 1873407
> i get this error message:
> 
> warning: line 16: Possible unexpanded macro in: Requires:   
> vdr(abi)(x86-64) = %{vdr_apiversion}

It means the %{vdr_apiversion} macro is not defined

> Building target platforms: x86_64
> Building for target x86_64
> setting SOURCE_DATE_EPOCH=1598313600
> Wrote: /builddir/build/SRPMS/vdr-skinelchihd-0.5.0-1.fc34.src.rpm

when building the source package.

> How can i solve this ?
> 
Requires tags are evaluated when building a source package, although they are
not used at this stage in any way. This is a deficiency in a rpmbuild tool.
Until (if ever) it is fixed in rpmbuild, you need to work around it in the
spec file.

First, the macro is not available in a minimal build root used for build
source packages. Thus you need to check its definess and use it only if it is
defined:

Requires:   vdr(abi)(%{_isa}) = %{?vdr_apiversion:%{vdr_apiversion}}

But that's not all. The Requires tag value must be a valid dependency value
after the expansion. In that form it would yield an invalid dependency value
"vdr(abi)(x86-64) = ". Thus you need either to supply a dummy value after the
equal sign if the macro is not defined, or better just do not generate the
dependency at all:

%if %{defined vdr_apiversion}
Requires:   vdr(abi)(%{_isa}) = %{vdr_apiversion}
%endif

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Galera FTBFS in f33, but same build passes in f32

2020-08-27 Thread Petr Pisar
On Thu, Aug 27, 2020 at 02:21:03PM +0200, Lukas Javorsky wrote:
> I've run into the compilation problem in the Galera package
> This problem occurs only on f33 and higher tho.
> 
> Here is build performed on Fedora 32:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504
> 
> And here is the same build, but on Fedora 33:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232498
> 
> Does anyone know what could cause this?

On of these changed build-dependencies 
.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


perl-Digest-MD5 license corrected

2020-08-25 Thread Petr Pisar
Fedora recognizes RSA license now, so I corrected a perl-Digest-MD5 license
from "(GPL+ or Artistic) and BSD" to "(GPL+ or Artistic) and RSA".

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Proposed Modular Policy for Fedora ELN

2020-08-24 Thread Petr Pisar
On Fri, Aug 21, 2020 at 07:55:57PM +0200, Miro Hrončok wrote:
> On 21. 08. 20 10:07, Zbigniew Jędrzejewski-Szmek wrote:
> > > Josh listed some of the key reasons behind default streams: that
> > > enterprise customers don't like to learn new commands. So default
> > > streams allowed us to package content with shorter-than-RHEL-lifetime
> > > and still `yum install foo` would install something the customer could
> > > use.
> > I guess that "shorter-than-RHEL-lifetime" is the big differentiator, i.e.
> > normal rpms cannot be yanked from the distribution, but a module can be.
> 
> Actually AFAIK modules shipped at GA cannot be yanked from the distribution
> either. Certainly not in Fedora.
> 
Modules are not removed from RHEL repositories either. The difference is that
in RHEL they stop being supported. That's something what Fedora has not yet
experienced.

Bedides EPEL. I think that packages in EPEL are sometimes rebased to
incompatible versions and what happen with the unneded dependencies of the old
versions is not clear to me. I think they are marked as a dead package in
dist-git and blocked from Koji. But do they disappear from the repository? If
the stable repository is based on Koji blocked status, then then should the
removed.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Questions about the 'request-branch' experience

2020-08-19 Thread Petr Pisar
On Tue, Aug 18, 2020 at 11:15:14PM -0400, Christopher wrote:
> I was recently asked to provide an EPEL8 version of one of my packages
> (python-keyring) in a bugzilla, so I did:
> fedpkg request-branch epel8
> 
> This opened up two pagure tickets, one each for two branches:
> epel8
> epel8-playground
> 
> After the branches were created, an extra commit was added to the
> epel8 branch to create a package.cfg file (with a log message that had
> extra double-quotes around it, for some reason).
> 
> I have several questions:
> 
> 1. Why did my request for a single branch automatically result in two
> separate tickets for two separate branches?
> 2. What is this '-playground' branch for?
> 3. Why was an extra commit added to the empty branch that was requested?
> 4. What is a package.cfg file? Do I need it?
> 5. (unimportant, but curious) How did the extra quotes get in the
> commit message that added the package.cfg file?
>
https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/KXMMLYSAXAVHDKFFBVEFYYZHPJBWXOQQ/

-- Petr



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?

2020-08-07 Thread Petr Pisar
On Thu, Aug 06, 2020 at 05:12:10PM -0700, PGNet Dev wrote:
> i'm attempting to build a MaxMind GeopIP2 DB reader perl module
> 
>   MaxMind::DB::Reader::XS
> 
>   ( https://metacpan.org/pod/MaxMind::DB::Reader::XS
>  )
> 
> on Fedora 32.
> 
> 
> the build fails on F32 with Errors:
> 
>   "/usr/bin/ld: unrecognized option '-Wl,-z,relro'"
>
'-Wl,-z,relro' is a linker flag. But not for /usr/bin/ld, but for
/usr/bin/gcc.

> I've filed a bug at the module upstream
> 
>   uninstallable on Fedora32, errors: "/usr/bin/ld: unrecognized option 
> '-Wl,-z,relro'" & "Unsupported compile language "C"" ?
>   https://github.com/maxmind/MaxMind-DB-Reader-XS/issues/32
> 
> the build fails only with Fedora's distro perl, which _includes_ the ldflags
> 
>   perl -V | grep -i " ldflags"
>   ldflags ='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong 
> -L/usr/local/lib'
> 
I think the build script does not use Perl configuration consistently. It uses
ldflags value for the linker flags, but it does not use ld value for the linker
exectable:

$ perl -MConfig -E 'say $Config{ldflags}'
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong 
-L/usr/local/lib
$ perl -MConfig -E 'say $Config{ld}'
gcc

> but is _successful_ on opensuse, where distro perl's ldflags do NOT include 
> '-Wl,-z,relro',
> 
>   perl -V | grep -i " ldflags"
>   ldflags =' -L/usr/local/lib64 -fstack-protector-strong'
>
If your /usr/bin/ld is the binutils ld, then -fstack-protector-strong is also
an invalid option for ld (see ld manual page) and it should also fail. I think
something tricks you.

> Is this^ a problem with Fedora's perl build flags "incorrectly" _including_
> relro?

Fedora mandates all packaged code to be built with relro. Therefore perl is
also built with relro.

> I've found/followed some of the perl hardening threads @ Fedora;
> IIUC, it's intentional ...
> 
It's not intentional, but it's how perl works.

When you build perl, the linker flags are modified by a perl build script and
built into the perl interpreter. Later when a third-party XS module is built,
the built-in linker flags are reused. That's because the XS module must be
binary compatible with the perl interpreter and having the same flags ensures
it. (Some flags, especially compiler flags, changes ABI.) As a result, the
third-party module is also built rerlo.

We would like to change it, but perl build script is a giant mess. When I asked
perl authors for explaining the mess, it turned out that they do not fully
understand it and, more imporatantly, that they do not want to touch it
all because they fear breaking a compatibility.

> Or likely an issue with the module not correctly dealing with it?

I think that's the case. It should use gcc program for linking.

-- Petr


signature.asc
Description: PGP signature
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: Proposing a new Perl Module Versioning Scheme

2020-08-07 Thread Petr Pisar
On Thu, Aug 06, 2020 at 07:09:37PM +0200, Tina Müller wrote:
> I'm working at SUSE,
[...]
> As you probably know, the versioning scheme of Perl modules differs from rpm.

We have the same issue in Fedora. We had a discussion about it in the past,
and the result was that while few packagers wanted to fix it, most of them
rejected the change, therefore Fedora did not move.

I saw that Gentoo managed it. Probably because of fewer interested people.

> The correct way to translate the versions for the spec would be:
> 
> perl -wE'say version->parse($ARGV[0])->normal;' 0.23
> v0.230.0
> 
> and then we just have to cut off the 'v' at the beginning.

At that time I implemented the conversion in pure Perl
 and as
a C library and a program .

$ fvsp -l 0.23
0.230.0

The motivation was keep rpm tool free from Perl and support bootstrapping
Perl when XS version module implementation is binary incompatible with the new
Perl.

Have you thought about an underscore character in the version string? While
modern version module ignores the underscore (0.1_2 is 0.12), there used to be
a guide line that the underscore designates a prerelease (0.1_2 is the second
prerelease of 0.1) and thus should be ordered before the stable release (0.1).
I remember I saw such releases on CPAN. I came to a conclusion that there is
no correct (in the meaning of compatibility) way of handling the undersore.
Maybe it's not a problem anymore.

> # Problem
> 
> As it is impossible to just change all modules in the distributions at the 
> same
> time, we need backwards compatibility.
> 
It depends on how you understand the "distribution". If you mean only the latest
version of the distribution (e.g. Fedora 33 in constrast to Fedora 32), then
Fedora is able to switch the versioning for all packages delivered by Fedora
in one week. (On the assumption that Fedora people agree on it).

> # Proposal
> 
> I discussed this on IRC #opensuse-factory. A suggestion came up how to avoid
> having to be backward compatible.
> 
> The versions of each module inside a CPAN distribution are usually generated
> at build time with perl.prov
> (https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.prov).
> 
> Some distributions also use
> https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.req
> but openSUSE doesn't. The dependencies are extracted at the time when the spec
> file is generated.
> 
Please note that in Fedora we do not use any of them. We moved them from RPM 
tool
to an independent tool maintained by Fedora Perl folks. I want to say that
I value that you share your opinion with Fedora people, but whatever changes
you do in upstream RPM, it won't have any direct effect on packaging of Perl
code in Fedora.

> We could add a new capability additionally to perl(). Maybe cpan(). This can
> use the new versioning scheme.
> The packages could be built with both capabilities.
> As soon as all packages are rebuilt, we can start to adjust the Requires
> lines to use the new capability.
> 
That's a nice plan. Would you remove perl() at the end? Or would you mirror
cpan() to perl() and then remove cpan() in order to get back to perl() name
space. I want to say that cpan() is not the best name, because not all Perl
code comes from CPAN.

I don't know packaging in SuSE. But in Fedora we have a problem with legacy. 
Some
packagers want to share one spec file among multiple Fedora (or even RHEL)
releases. That means once you rewrite Requires from the decimal perl() to the
normalized cpan(), the spec files become incompatible with the older
distributions. And that was the fact that shut down my previous attempt in
Fedora. (I proposed to hide the difference in a %perl_v() RPM macro
, but that was 
also
opposed as making the packaging less legible. In general there was opposition
to any change that would require packaging in any new way. But some time
passed, maybe the mood has changed since then. I can try it again.)

> However, there is also the package version, and instead of
> 
> Require: perl(A::B) >= x.y
> 
> one can do
> 
> Require: perl-A-B >= x.y
> 
> so for those package versions we need backward compatibility.
> 
In Fedora we banned depending on Perl package names for the purpose of
installing the Perl modules. Packagers must use perl() for that purpose. As
for normalizing RPM package versions, you can bump RPM Epoch value.

> My idea is to take a snapshot of all CPAN modules we have in our repository
> and save the package id and the version.
> 
> The migration strategy to the new versioning scheme would be:
> 
> All modulues having 1, 2 or 3 decimals can update to the new scheme whenever
> a new version is uploaded.
> 
> Let's take module A as the example again. The current (CPAN) version would be
> 0.23.
> 
> When a new version 0.3 is 

Re: Proposed Modular Policy for Fedora ELN

2020-08-06 Thread Petr Pisar
On Wed, Aug 05, 2020 at 10:50:59PM -0400, Stephen Gallagher wrote:
> On Wed, Aug 5, 2020 at 6:17 PM James Cassell 
> wrote:
> >
> > On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote:
> > > * If a stream of a module has build-time-only components, all such
> > > components *MUST* be marked as `buildonly: True` in the module
> > > metadata to avoid shipping them to users and polluting their
> > > repository.
> > >
> >
> > Can these be directed to a disabled-by-default build-dep repo of some kind
> > for those trying to do local builds?
> >
> 
> That's not really a policy question, but it's *possible* that we could
> do that as part of the compose. I don't see a lot of reason to do so,
> since a local MBS build will handle it for you and as we establish
> later on, the use of these should be a last resort, not a common
> practice.
> 
These build-only components are handy for running tests after the build.

E.g. a non-build component has upstream tests. They are run at build-time, and
thus the module contains build-only components for performing the test. The
tests are also packaged into a subpackage and the subpackage is filtered from
the module. ("buildonly: true" is only a different form of "filter" modulemd
section.) Later a CI may want to install the subpackage and reproduce the
tests.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied

2020-08-04 Thread Petr Pisar
On Mon, Aug 03, 2020 at 10:46:33PM +0100, Richard W.M. Jones wrote:
> On Mon, Aug 03, 2020 at 10:42:01PM +0100, Richard W.M. Jones wrote:
> > I can't reproduce this locally but it happens in Koji reliably enough:
> > 
> > + /usr/lib/rpm/brp-strip /usr/bin/strip
> > /usr/bin/strip: unable to copy file 
> > '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake';
> >  reason: Permission denied
> > error: Bad exit status from /var/tmp/rpm-tmp.5A3ApT (%install)
> 
> After updating to more Rawhide I _am_ able to reproduce it.  It seems
> to be caused because the binary is installed 0555:
> 
>   -r-xr-xr-x. 1 rjones rjones 8042912 Aug  3 22:41 
> /home/rjones/rpmbuild/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake
> 
> However nothing has changed in this package for years (last rebase was
> in Nov 2017) but apparently strip didn't have a problem before now.
> 
> I was able to work around it by adding an explicit
> 
>%install
>make install \
>  INSTALL_ROOT=$RPM_BUILD_ROOT
>   +chmod 0755 $RPM_BUILD_ROOT%{_bindir}/omake
> 
> so I guess that "fixes" it, but why?
> 
I saw a similar randomly occuring issue when a spec Source file was copied
into the %buildroot. It turned out that the Source file was created without
a write bit when unpacking a source package. Probably due to an unexpected
umask on a builder. My solution was using "install -m" instead of "cp -a".

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


diffmark license corrected

2020-07-29 Thread Petr Pisar
I corrected diffmark license from "diffmark and GPLv2+ and (GPL+ or Artistic)"
to "diffmark and (GPL+ or Artistic)".

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


perl-Boost-Geometry-Utils license corrected

2020-07-27 Thread Petr Pisar
I corrected perl-Boost-Geometry-Utils package license from "GPL+ or Artistic"
to "(GPL+ or Artistic) and Boost".

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaned perl-Boost-Geometry-Utils, perl-Data-Rmap, perl-Math-Expression-Evaluator

2020-07-27 Thread Petr Pisar
On Fri, Jul 24, 2020 at 03:06:39PM +0200, Miro Hrončok wrote:
> Hello, I've orphaned:
> 
> perl-Boost-Geometry-Utils
> perl-Data-Rmap
> perl-Math-Expression-Evaluator
> 
> The packages used to be needed by slic3r, but apparently no longer are, they
> are leafs.
> 
I took all of them.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


perl-Math-Expression-Evaluator license corrected

2020-07-24 Thread Petr Pisar
perl-Math-Expression-Evaluator license was correted from "GPL+ or Artistic"
to "(GPL+ or Artistic) and Public Domain".

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Modularity Improvements Objective

2020-07-24 Thread Petr Pisar
On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote:
> There's a Modularity Improvements Objective draft available[1].
> 
> The Objective summarizes the work that is in progress already as well as
> highlights our plans for Fedora 34.
> 
> We're planning to fix the current modularity in Fedora 33 and 34.
> We may look into alternatives or bigger design changes in Fedora 35 and
> later.
> 
> You can find more details in the Objective document[1].
> 
> - Daniel
> 
> [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020

I hope that you find resources to properly maintain MBS. Currently (last two
weeks) it cannot build the modules
.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Very strange compiler/linker related build failures in rawhide

2020-07-24 Thread Petr Pisar
On Fri, Jul 24, 2020 at 10:31:11AM +0200, Fabio Valentini wrote:
> Other failures I've seen end up with linker failures, line these, from
> postgresql:
> 
> ld: undefined reference to `postgresql_subtrans__checkpoint__start_semaphore'
>
.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

2020-07-23 Thread Petr Pisar
On Thu, Jul 23, 2020 at 11:29:17AM +0200, Remi Collet wrote:
> Le 09/07/2020 à 20:00, Ben Cotton a écrit :
> > https://fedoraproject.org/wiki/Changes/ModularPolicy
> 
> > There is a preview of the new policy available at
> > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/
> 
> 
> I think this part may be confusing
> 
> Packages provided at runtime by the default stream of a module MUST
> depend only on packages provided by packages from default module
> streams or the non-modular package set. By extension, default streams
> of a module MUST NOT have a dependency on any non-default stream.[3]
> 
> I think if should be possible, and modularity have been designed for
> such usage, to depend on "all" versions of a dependant stream
> 
> Example,
> 
> LANG as a module with version 1, 2, 3
> 
> APP using LANG build using each version
> 
> So in metadata
> 
> data
> name: APP
> dependencies:
> - buildrequires:
> LANG: []
> - requires
> LANG: []
> 
> And documentation seems to forbid this usage.
> 
I believe that an intention of the documentation is that if APP is a default
stream, then exactly one of LANG streams must be default. That assures that
when installing a package (non-modular, or from a default stream), no
non-default stream becomes enabled.

I agree that the documentation could be understood in the other way, you
pointed, and that is that every package of a default stream _regardless of
a context_ must not depend on a non-default stream.

The documentation could be clarified like this:

Packages provided at runtime by at least one context of a default stream
of a module MUST depend only on packages provided by packages from default
module streams or the non-modular package set. By extension, at least one
context of the default streams of a module MUST NOT have a dependency on
any non-default stream on each platfrom.

But it becomes less comprehensive.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Branch creation for unretired package

2020-07-22 Thread Petr Pisar
On Wed, Jul 22, 2020 at 10:18:39PM +0200, Andy Mender wrote:
> On Wed, 22 Jul 2020 at 22:14, Mohamed El Morabity 
> wrote:
> 
> > Hello,
> >
> > I'm the maintainer of the nicotine+ package. This package was retired
> > before F32 branching last year (no Python 3 support at this time) and
> > I unretired it after a review request and a unretirement request
> > ticket to releng.
> > I requested a branch creation for f32 using "fedpkg request-branch",
> > as suggested in the reply to my unretirement ticket. The SCM ticket is
> > at https://pagure.io/releng/fedora-scm-requests/issue/27217
> > As replied on the ticket, I'm supposed to create by myself the branch
> > using git (git branch -b f32/git push -u origin f32), since "The
> > branch in PDC already exists" (sic). And I have no right to perform
> > the branch creation as suggested:
> >
> > Am I missing something? Is there a particular procedure for unretired
> > packages?
> >
> >
> I was in a similar situation recently. Please, have a look here:
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
> 
> In order to unretire a package you need to claim its maintainership and all
> already existing branches.
> 
There is nothing like maintainership of a particular branch. You either own
the package, or you don't.

The package is already owned by "melmorabity" user, according to Pagure:

$ wget -q -O - https://src.fedoraproject.org/api/0/rpms/nicotine+
{
  "access_groups": {
"admin": [], 
"commit": [], 
"ticket": []
  }, 
  "access_users": {
"admin": [], 
"commit": [], 
"owner": [
  "melmorabity"
], 
"ticket": []
  }, 
  "close_status": [], 
  "custom_keys": [], 
  "date_created": "1501871308", 
  "date_modified": "1595407922", 
  "description": "The nicotine+ rpms", 
  "fullname": "rpms/nicotine+", 
  "id": 10857, 
  "milestones": {}, 
  "name": "nicotine+", 
  "namespace": "rpms", 
  "parent": null, 
  "priorities": {}, 
  "tags": [], 
  "url_path": "rpms/nicotine+", 
  "user": {
"fullname": "Mohamed ElMorabity", 
"name": "melmorabity", 
"url_path": "user/melmorabity"
  }
}

If dist-git refuses pushing f32 branch as quoted in 
:

$ git push -u origin f32
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Unspecified ref refs/heads/f32 is blocked
remote: Denied push for ref 'refs/heads/f32' for user 'melmorabity'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/nicotine+
 ! [remote rejected] f32 -> f32 (pre-receive hook declined)
error: failed to push some refs to 
'ssh://melmorab...@pkgs.fedoraproject.org/rpms/nicotine+'

Then the problem is that a synchrization of permissions between Pagure and
dist-git got broken. I recommend you asking for help rel-engs
.
 SCM requests are
maintained by a robot that won't help you.

I think relengs' advice will be log out and log in on Pagure web page
.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[rpms/perl-XML-Parser] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar closed without merging a pull-request against the project: 
`perl-XML-Parser` that you
are following.

Closed pull-request:

``
Use make macros
``

https://src.fedoraproject.org/rpms/perl-XML-Parser/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[rpms/perl-XML-Parser] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar commented on the pull-request: `Use make macros` that you are following:
``
Thank you for the hint. I did larger changes.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-Parser/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[rpms/perl-Unicode-Normalize] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar closed without merging a pull-request against the project: 
`perl-Unicode-Normalize` that you
are following.

Closed pull-request:

``
Use make macros
``

https://src.fedoraproject.org/rpms/perl-Unicode-Normalize/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[rpms/perl-Unicode-Normalize] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar commented on the pull-request: `Use make macros` that you are following:
``
Thank you for the hint. I did larger changes.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Unicode-Normalize/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[rpms/perl-MIME-Base64] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar closed without merging a pull-request against the project: 
`perl-MIME-Base64` that you
are following.

Closed pull-request:

``
Use make macros
``

https://src.fedoraproject.org/rpms/perl-MIME-Base64/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[rpms/perl-MIME-Base64] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar commented on the pull-request: `Use make macros` that you are following:
``
Thank you for the hint. I did larger changes.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-MIME-Base64/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[rpms/perl-Digest-MD5] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar commented on the pull-request: `Use make macros` that you are following:
``
Thank you for the hint. I did a larger chaneges.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Digest-MD5/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[rpms/perl-Digest-MD5] PR #1: Use make macros

2020-07-21 Thread Petr Pisar

ppisar closed without merging a pull-request against the project: 
`perl-Digest-MD5` that you
are following.

Closed pull-request:

``
Use make macros
``

https://src.fedoraproject.org/rpms/perl-Digest-MD5/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: Removing packages from module

2020-07-20 Thread Petr Pisar
On Fri, Jul 17, 2020 at 02:14:49PM -0700, Aleksei Bavshin wrote:
> The real question is how to do the change in f33 considering that f32
> and f33 modules must be built from the same modulemd file.

You wrap a %files section of the package you want to remove with a condition
based on the Fedora version:

%if %{fedora} < 33
%files
...
%end

This will cause the when building the module component, rpmbuild won't produce
the unwanted binary package on F33, but it will produce it on F32.

The only problem is if that is the only binary package produced by the spec
file. Then rpmbuild would report an error, because it would consider it
a packaging mistake. But it can be worked around by produced a dummy package
instead:

%if %{fedora} < 33
%files
...
%else
%files -n dummy
%end

and filtering out the dummy package from the module on modulemd level with
/data/filetr/rpms/dummy entry.

> And now I'm curious what would happen if I specify `platform: [-f33]`
> and publish new module build. Would that remove previously published
> metadata from rawhide?

No. Rawhide repository is composed from the latest builds tagged into
a rawhide tag. That means Rawhide would still contain the last module built
from f33 platform.

> I guess the right answer is somewhere around servicelevels and `eol`
> specification.
> 
Theoretically yes. You can file a releng request
 of moduel_eol type to shorten the EOL.
But I worry that a compose process does not respect the EOL dates and instead
the EOLed modules are removed from a compose configuration by relengs
manually once before branching a new Fedora release (33 is the next one).

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal

2020-07-15 Thread Petr Pisar
On Tue, Jul 14, 2020 at 08:09:22PM +0200, Fabio Valentini wrote:
> On Tue, Jul 7, 2020 at 9:17 PM Ben Cotton  wrote:
> > == Contingency Plan ==
> >
> > Modules will provide the functional version of PostgreSQL 12,
> > available to all users.
> 
> As Miro said - this is not a contingency plan.
> We can't just ship a broken version of postgresql by default.
> 
Default streams are not allowed in Fedora. Thus whatever content is shipped as
a module, it won't affect users by default. I cannot see a problem in shipping
a broken PostgreSQL in a module, since it's always an explicit user's choice
to enable, and install it. I understand the proposed contingency plan as
providing the broken server as an experimental stream.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: PSA: dnf autoremove cleans fedora-repos-modular

2020-07-13 Thread Petr Pisar
On Fri, Jul 10, 2020 at 02:35:05PM -0700, John M. Harris Jr wrote:
> On Friday, July 10, 2020 4:39:21 AM MST Miro Hrončok wrote:
> > On 09. 07. 20 14:24, Petr Pisar wrote:
> > 
> > > On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
> > > 
> > >> One just noticed that `dnf autoremove` is trying to remove `fedora-
> > >> repos-modular` and `fedora-repos-rawhide-modular`.
> > >>
> > >>
> > >>
> > > [...]
> > > 
> > >> I don't know where / which the fix should be: DNF, comps or both.
> > >> Simply putting the fedora-repos-modular in comps won't help since DNF
> > >> is only using them when running `group install/update/remove`.
> > >>
> > >>
> > >>
> > > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action
> > > on a system upgrade, because we want that package to be prensented on
> > > the system. However I worry that DNF does not possess a capability for
> > > doing it. (Except of injecting that command into some externally executed
> > > script.)
> > 
> > 
> > Can we amend dnf system-upgrade to do this?
> 
> Wouldn't that install modular repos on systems that end users have removed it 
> from? Is there a way around that?
> 
It won't. If a package is not installed, the command will fail.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: PSA: dnf autoremove cleans fedora-repos-modular

2020-07-10 Thread Petr Pisar
On Thu, Jul 09, 2020 at 02:15:03PM -0400, Matthew Miller wrote:
> On Thu, Jul 09, 2020 at 11:09:57AM -0700, Adam Williamson wrote:
> > What we're dealing with now is awkward consequences of this change for
> > existing installs, where we'd probably want to *keep* modular repos,
> > especially if any modules are actually enabled.
> 
> Is it a terrible idea to suggest that MBS insert a "Requires:
> fedora-repos-modular" into all of the packages built in that system?
> 
Does rpmbuild have such capability?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: PSA: dnf autoremove cleans fedora-repos-modular

2020-07-09 Thread Petr Pisar
On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
> One just noticed that `dnf autoremove` is trying to remove `fedora-
> repos-modular` and `fedora-repos-rawhide-modular`.
>
[...]
> I don't know where / which the fix should be: DNF, comps or both.
> Simply putting the fedora-repos-modular in comps won't help since DNF
> is only using them when running `group install/update/remove`.
>
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on
a system upgrade, because we want that package to be prensented on the system.
However I worry that DNF does not possess a capability for doing it. (Except
of injecting that command into some externally executed script.)

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Perl 7 in Fedora

2020-07-08 Thread Petr Pisar
Hello packagers,

have you noticed an announcement about Perl 7

on a Perl5 Porters list? Saywer X presented an idea that now, when Perl 6 is
called Raku, Perl 5 can resume using the higher numbers and that the next Perl
will be Perl 7.

That part of the announcement wouldn't be exciting at all if there wasn't
the second part that Perl since now will be more aggressive in adding new
features and removing old ones and that Perl will enable all the new
stabilized features by default (without "use v7;").

To comfort conservative users there was a third part that Perl 5 will move
into a maintance mode and it will be supported for the next 5 (up to 10)
years.

That second part provoked many reactions. Especially about a feasibility of
such undertaking. The third part raised questions about compatibility with
a third-party code, especially CPAN, and a coexistence of two Perls on one
system.

A similarity with Python upgrading from version 2 to version 3 is extensive.
Because I observered the Python move in Fedora from a close proximity, I can
tell you that I do not want to experience it again. (It took many years,
cost at least 5 full-time Red Hat employes, and meant significant overhaul in
packaging.)

Then Sawyer X sent an update

that addressed the people's reactions. It introduced a mandatory Perl API
versioning ("use v5", "use v7", "use v8") in every Perl script, a prospect
that each perl release will support at most 3 APIs (old, current, future) and
that the interpreter executable will be called /usr/bin/perl7 while
/usr/bin/perl will be kept unused.

In the mean time, core-p7 branch was revelead in the Perl git tree that
started migrating Perl 5 sources to Perl 7 version and introduced "use p5" and
"use p7"

for enforcing Perl 5 and Perl 7 compatibility mode in the interpreter.

Yesterday Perl 5.33.0

was released with an unclear prospect whether it will lead to 5.34 or 7.0. So
far it seems it will contain changes from core-p7 branch that assure
core modules compatibility among both Perl 5 and Perl 7 mode.


My question four you is what and how you want to package in Fedora.

In my humble opinion, Perl 7 interpreter won't diverge from Perl 5 too far in
the next year (or two years) and many prominent CPAN distributions will be
promptly updated to preserve compatibility with both of the languages (it
actually already happens, see perl-Socket-2.030). Thus I'm for upgrading
Perl 5 to Perl 7 as soon as possible in Fedora. That means when stable Perl 7 is
released and keep it up-to-date and all Perl packages rebuilt against it as we
were used with Perl 5.

I can imagine that some people will insist of having Perl 5 available next to
Perl 7. I can package it either as a module or as a normal package (but keep in
mind that Perl would conflict on /usr/bin scripts and manual pages; we could
strip the manuals and rename the scripts).

But I'm not sure it's worth of repackaging all the CPAN distributions we have
twice for both Perls. Either as a subpackage of one spec file. (Few years back
I proposed few macros  that
would make the packaging agnostic of perl version and they were rejected as
unneeded. I don't know whether the mood has has changed since then.) Or
as a completely independend source packages (that would had the benefit that
a breakage in one language would not affect the other language). There is still
a possibility of using modularity, but that does not bring parallel
installability and recently Fedora banned default streams which makes all
modules a second-class citizen.

So what do you want? Will you be fine with only having the latest Perl (i.e.
Perl 7 next year)? 

-- Petr


signature.asc
Description: PGP signature
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

2020-07-02 Thread Petr Pisar
On Thu, Jul 02, 2020 at 10:35:27AM +0200, Vít Ondruch wrote:
> I just met something which might be of similar nature. Recent FF
> 78.0-1.fc33.x86_64 fails to start with older glibc:
> 
> 
> ~~~
> 
> $ firefox
> XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
> /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
> version GLIBC_2.32
> Couldn't load XPCOM.
> 
> ~~~
> 
> 
> Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to
> glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless
> issues like this are unexpected. There should be something, what would
> force glibc update if FF requires more recent one.
> 
There is nothing like that. This issue is not specific to glibc. If a library
adds a symbol, it does not have to bump its soname. Thus on RPM level there
won't be any change. If another executable starts using the new symbol, there
won't be again no change on the RPM level. Therefore RPM finds a match at
installation, but the dynamic linker finds a dissonance at run time.

ELF RPM dependency generator could promote these linker symbol dependencies to
RPM level, but I worry that most people will complain about growing YUM
repository metadata.

I don't think it's realistic to expect from the packagers that they will check
and add these new dependencies manually. Teoretically, rpminpsect run in CI
could catch these changes and warn the packager. But I worry that many people
won't understand it and just keep ignoring it.

-- Petr



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 08:14:39AM -0400, Stephen Gallagher wrote:
> On Wed, Jun 24, 2020 at 3:38 AM Petr Pisar  wrote:
> >
> > On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > Yes. Putting the "stream identification" into the package name is the
> > > most natural solution, and has been floated various times.
> >
> > This already happens. But not in Fedora. In RHEL, modular packages have
> > Modularitylabel RPM tag that carries the module name and stream.
> >
> 
> The ModularityLabel RPM tag is also present in Fedora.

Interesting. I checked the first modular package for the first module "dnf
module list" gives in Fedora 33
(ant-0:1.10.5-3.module_f28+4207+d722d224.noarch), and it does not contain the
tag. I did not checked other ones. Thus I wrote that it was not in Fedora.

Now I see that the package was built on Fedora 28 platform. When I check the
latest build in Koji,  ant-1.10.7-2.module_f31+7074+f8e1675d.noarch, the tag
is there.

My apology. Probably the new tag was enabled sometime in between and nobody
cared to rebuild the module after that (although relengs mass-rebuild modules
on branching) and nobody cared to submit to latest build to stable.

> However, it's documented as *not* reliable for reverse lookups. It only
> lists the NSVCA of the build it first occurred in, which may not be what
> you're looking for if the package was unchanged and has been reused for
> subsequent builds. (Though I *think* you can rely on the name and stream
> being the same right now, since we don't yet have cross-module component
> reuse in MBS, but that's coming.)

Exactly. We do not reuse components across modules. I cannot see how reliable
it could be considering every module can have a different build root resulting
into incompatible builds. So the fact that it "is coming" is news for me.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 12:48:07PM +0200, Daniel Mach wrote:
> > My idea was that DNF could discriminate the same-name package using the
> > ModularityLabel tag instead of relying on modulemd documents delivered in 
> > the
> > repository metadata.
> > 
> The "modularitylabel" is not going to help.
> It's designed as a boolean flag.
> If it holds any value, it indicates that the RPM is part of a module.
> If it's empty, then the RPM is non-modular.
> If you're looking for any sense of the header, it's probably closest to a
> reference to the module build it comes from.
> 
> RPMs are supposed to be re-used among modules/contexts and for that reason
> we cannot hardcode this relation directly to them.

I know all this things, but:

ModularityLabel tag can be interpreted not only as a boolean. It was added to
recognize a modular package for a case when a repository with modulemd
metadata disappears. This is where the interpretatinon as a boolean type comes
from. But here we discuss a new modularity that does not have to align to the
current implementation of modularity.

The ModularityLabel tag carry name:stream:version:context of a module build
where the RPM package was built. I know that a package can be reused in a new
module version and then the ModularityLabel won't match exactly. But that's
not a problem, because nobody cares about a version of the module. E.g.
current DNF implementation puts all modular packages from a single
name:stream:context onto one heap. The version is ignored. The same would
apply to the ModularityLabel tag.

Referring to modulemd data that are not available on RPM level when this
mental excercise is about blending modularity into RPM level defies the
purpose.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 12:03:05PM +0200, Nicolas Mailhot via devel wrote:
> Le mercredi 24 juin 2020 à 11:56 +0200, Petr Pisar a écrit :
> > I see. I focused on having the stream information on RPM level. Then the
> > answer is no, the package name does not contain the information.
> > 
> > My idea was that DNF could discriminate the same-name package using the
> > ModularityLabel tag instead of relying on modulemd documents delivered in
> > the repository metadata.
> 
> One problem of having it a tag (which we do not even have in Fedora)

I believe having it in Fedora is only a matter of changing MBS configuration.

> is that it requires rewriting dependency resolution logic at dnf level,

DNF has a steadfast idea that an upgrade path is only based on a package name.
Without changes in DNF, DNF will either switch a stream just because a package
from a concurrent stream has a higher version, or will complain that it cannot
upgrade to the lastest version. Neither of the options is a desired behavior.
Thus I believe that changing DNF is inevitable.

> and a Tag does not come with all the dependency manipulation verbs we
> have evolved over the years for Provides and Requires.
> 
ModularityLabel designates an affilation to a stream. That can be reduced to
"Requires: module(name:stream)" or "Requires: module(name) = stream". I'm not
agaist abusing Requires for that purpose. But it alone won't fix the issue with
enforcing a presence of a stream I drafted above.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 11:01:55AM +0200, clime wrote:
> On Wed, 24 Jun 2020 at 10:35, Petr Pisar  wrote:
> >
> > On Wed, Jun 24, 2020 at 10:22:38AM +0200, clime wrote:
> > > On Wed, 24 Jun 2020 at 09:40, Petr Pisar  wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek 
> > > > wrote:
> > > > > Yes. Putting the "stream identification" into the package name is the
> > > > > most natural solution, and has been floated various times.
> > > >
> > > > This already happens. But not in Fedora. In RHEL, modular packages have
> > > > Modularitylabel RPM tag that carries the module name and stream.
> > >
> > > Does "ModularityLabel" actually propagates to rpm package name or is
> > > it just a "hidden" rpm attribute?
> > >
> > It's a RPM tag as well as a package name or a package version are the RPM
> > tags. I don't understand your question.
> 
> Well, the original sentence was: "Putting the "stream identification"
> into the package *name* is the most natural solution".
> 
> And the answer was: "This already happens. But not in Fedora. In RHEL, ..."
> 
> But my question was answered, thank you.
>
I see. I focused on having the stream information on RPM level. Then the
answer is no, the package name does not contain the information.

My idea was that DNF could discriminate the same-name package using the
ModularityLabel tag instead of relying on modulemd documents delivered in the
repository metadata.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 04:36:06AM -0400, James Cassell wrote:
> 
> On Wed, Jun 24, 2020, at 3:37 AM, Petr Pisar wrote:
> > On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > Yes. Putting the "stream identification" into the package name is the
> > > most natural solution, and has been floated various times.
> > 
> > This already happens. But not in Fedora. In RHEL, modular packages have
> > Modularitylabel RPM tag that carries the module name and stream.
> > 
> 
> It's too bad this isn't exposed in `rpm -qi` output. Is there a way to query
> the Modularitylabel RPM tag on an installed system?
> 
rpm -q --qf '%{Modularitylabel}\n' PACKAGE

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 10:22:38AM +0200, clime wrote:
> On Wed, 24 Jun 2020 at 09:40, Petr Pisar  wrote:
> >
> > On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > Yes. Putting the "stream identification" into the package name is the
> > > most natural solution, and has been floated various times.
> >
> > This already happens. But not in Fedora. In RHEL, modular packages have
> > Modularitylabel RPM tag that carries the module name and stream.
> 
> Does "ModularityLabel" actually propagates to rpm package name or is
> it just a "hidden" rpm attribute?
>
It's a RPM tag as well as a package name or a package version are the RPM
tags. I don't understand your question.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Yes. Putting the "stream identification" into the package name is the
> most natural solution, and has been floated various times.

This already happens. But not in Fedora. In RHEL, modular packages have
Modularitylabel RPM tag that carries the module name and stream.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-24 Thread Petr Pisar
On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote:
> I think there's some fear that "name mangling" is not a general
> solution, and we'd have cases where names conflict. I think the
> concern is realistic, but not a big issue in practice. With some
> careful naming guidelines we are able to resolve naming conflicts, and
> I'm sure we could extend the guidelines to multiple versions of language
> stacks or whatever. We'd probably have slightly longer names or packages,
> but that's not the end of the world.
>
Namespacing RPM package names is only a tip of the iceberg. You need to
namespace RPM requires, provides, shared library sonames, shared library
symbols, header files, header file symbols, pkg-config files, manual pages,
cross references in the manual pages, executable names etc. You need to
namespace everything if you aim for a parallel installability. That's the
reason why modularity does not tackle it and instead conflicts the concurent
versions by filtering the packages from the concurent streams.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-22 Thread Petr Pisar
On Mon, Jun 22, 2020 at 11:08:14AM +0200, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Mon, 2020-06-22 at 09:19 +0200, Petr Pisar wrote:
> > On Fri, Jun 19, 2020 at 02:53:56PM -0400, David Cantrell wrote:
> > > Around the idea and concept of modularity... what are the benefits
> > > to Fedora,
> > > Fedora developers, and Fedora contributors?  Through the various
> > > discussions
> > > on modularity, nothing solid in this regard has been presented.  If
> > > I am
> > > Fedora contributor now, what can modularity do for me?
> > > 
> > It can define a build order among packages of a module.
> 
> For that you don't actually have to design some special format. The
> buildsystem should figure this out on its own. And there are such
> buildsystems that do that - Open Build Service.
> 
> > It can change RPM macros in a build root (including SRPM build root).
> 
> I think this is not really good idea, but again - you don't have to
> invent new format for this. Open Build Service allows you to do that in
> a project configuration.
> 
> > It can use transient build dependencies (a package is built, only
> > used as a build
> > dependency of a consquitive package, and then dropped and never
> > shipped).
> 
> Same here.
> 
> > It can build and deliver a package against multiple exclusive
> > dependencies
> > (e.g. for different Fedora releases).
> 
> The same thing.
> 
> > It can build a package from dist-git sources that do not depend on a
> > Fedora
> > release.
> 
> Again, same.
> 
Igor, the question was about modularity. Not about Open Build Service.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Modules building for Fedora 30

2020-06-22 Thread Petr Pisar
On Sat, Jun 20, 2020 at 10:32:48AM -0700, Kevin Fenzi wrote:
> On Sat, Jun 20, 2020 at 09:45:15AM -0400, Stephen John Smoogen wrote:
> > On Fri, 19 Jun 2020 at 23:16, Orion Poplawski  wrote:
> > >
> > > I just noticed that my openmpi module build is building for Fedora 30.
> > > This seems like a mistake.  Where do I report that?
> > >
> > 
> > I think it should be reported here: https://pagure.io/releng/issues
> 
> Yeah, thats fine, or infrastructure. 
> 
> I'm not sure however where that is configured, so it might be some
> digging before we can fix it. None of: '30' 'fedora-30' 'platform:f30' 
> appear in the mbs configuration. ;( 
> 
An end of life of any module stream, including platform, should be stored in
PDC. But I suspect that platform is a special case.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

2020-06-22 Thread Petr Pisar
On Fri, Jun 19, 2020 at 05:11:43PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
> 
> == Summary ==
> This change will update all spec files in Fedora that use make and replace
> the make invocations with either the %make_build or %make_install macros.
> 
This a great oportunity to speak about an implicit dependency on make covered
by RPM macros. What package should define the dependency explicitly? A spec
file that calls %make_build, or rpm package that defines the macro?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-22 Thread Petr Pisar
On Fri, Jun 19, 2020 at 02:53:56PM -0400, David Cantrell wrote:
> Around the idea and concept of modularity... what are the benefits to Fedora,
> Fedora developers, and Fedora contributors?  Through the various discussions
> on modularity, nothing solid in this regard has been presented.  If I am
> Fedora contributor now, what can modularity do for me?
> 
It can define a build order among packages of a module.
It can change RPM macros in a build root (including SRPM build root).
It can use transient build dependencies (a package is built, only used as a 
build
dependency of a consquitive package, and then dropped and never shipped).
It can build and deliver a package against multiple exclusive dependencies
(e.g. for different Fedora releases).
It can build a package from dist-git sources that do not depend on a Fedora
release.
(Teoretically you can build a module from non-RPM components; I've never tried
it.)

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RHEL 9 and modularity

2020-06-22 Thread Petr Pisar
On Fri, Jun 19, 2020 at 05:44:37PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jun 19, 2020 at 11:16:33AM -0400, Stephen Gallagher wrote:
> > On Fri, Jun 19, 2020 at 9:08 AM Martin Jackson  wrote:
> > 
> > 
> > > I use flatpaks on Fedora (Discord and okular), and I've really enjoyed
> > > the experience with them.  I'm not sure how well that would translate to
> > > the server environment though, but that general approach seems to do a
> > > good job of preserving user experience while isolating potentially
> > > troublesome conflicts in a way that doesn't mess up the "base system".
> > >
> > 
> > I love how people hold up "containers" as a solution to these problems
> > without considering for a moment how exactly the container itself gets
> > built. If you were to look into the flatpak build system in Fedora,
> > you'd see that they are using Modularity to construct them.
> >
> > One of the reasons for Modularity is that we agree that containers are
> > one "right" way to handle parallel-installability. But we also know
> > from past experience (SCLs) that having content in unusual locations
> > like /opt means that applications have to be modified. By using
> > modules to put the version of software you want into the standard
> > location and then using a container to isolate it and/or provide
> > parallel-installability, you also get the assurance of knowing the the
> > content in your container is just as trusted as your standard RPM
> > deployments.
> 
> IIUC from the docs, when using Modularity to build Flatpaks, the
> prefix is changed to /app instead of /usr, which makes it much
> closers to SCL:
> 
The relocation to /app brings exactly the same issues as SCL
,
.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: New protobuf blocked by old protobuf from module [f32]

2020-06-15 Thread Petr Pisar
On Mon, Jun 15, 2020 at 11:31:09AM +0100, Daniel P. Berrangé wrote:
> I'm trying to install gmic on my Fedora 32 system, which requries opencv,
> which requires protobuf 3.11
> 
> DNF refuses to install any of them though, because protobuf 3.11 is blocked
> by modularity:
> 
>   - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular filtering
>   - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular filtering
> 
> All I can see with "dnf list" is a seriously outdated  version from an unknown
> module:
> 
> protobuf.x86_64
> 3.6.1-6.module_f32+6163+c0e6dcb2 
> fedora-modular   
> protobuf.x86_64
> 3.6.1-6.module_f32+6163+c0e6dcb2 
> updates-modular  
> 
> What is the right way to fix this ?  dnf module list shows me loads of
> modules, but I'm not seing how to determine which of them are enabled vs
> disabled,

"dnf module list" marks enabled streams with "[e]" in a Stream column. (There
also used to be "[d]" for the default streams that were active (read
"pre-enabled") by default, but default streams are now banned and should not
exist in Fedora repositories (since Fedora 32?).)

"dnf module list --enabled" restricts the list to enabled modules only.

> and more importantly which is providing this bogus outdated
> protobuf ?
>

"dnf module provides protobuf-3.6.1-6.module_f32+6163+c0e6dcb2" returns
eclipse:2019-06:3220190902131726:a48fff9b:x86_64 module. Thus you need to
unenable eclipse:2019-06 stream ("dnf module reset eclipse:2019-06"), or
disable the eclipse module completely ("dnf module disable eclipse").

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Something weird with modules in kernel-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64

2020-06-09 Thread Petr Pisar
On Tue, Jun 09, 2020 at 03:06:27PM +0100, Richard W.M. Jones wrote:
> On Tue, Jun 09, 2020 at 03:05:05PM +0100, Richard W.M. Jones wrote:
> > I've installed kernel-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64 but
> > not rebooted (still running 5.6.0-0.rc5.git0.1.fc33.x86_64 on the host).
> > 
> > However /lib/modules/5.8.0-[...] has not been fully created in some way.
> > In particular there are no *.ko files at all under that directory:
> > 
> > $ ls /lib/modules/5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64/
> > bls.conf   modules.builtinmodules.drm  source
> > build  modules.builtin.alias.bin  modules.modesetting  
> > symvers.gz
> > config modules.builtin.binmodules.networking   
> > System.map
> > kernel modules.builtin.modinfomodules.orderupdates
> > modules.alias  modules.depmodules.softdep  vdso
> > modules.alias.bin  modules.dep.binmodules.symbols  vmlinuz
> > modules.block  modules.devnamemodules.symbols.bin  
> > weak-updates
> > $ find /lib/modules/5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64/ 
> > -name '*.ko'
> > 
> > Using virt-rescue to examine the new kernel also fails as you'd expect
> > when it tries to load any module.
> > 
> > Any idea where to begin debugging this, or if there's an existing bug?
> 
> I forgot to add that it's not just on my machine.  The reason I'm
> looking at this is because it caused a build failure in Koji, where
> again it seems like a module (vfat.ko) doesn't exist:
> 
The file (vfat.ko.xz) is delivered with a kernel-core package.

> https://koji.fedoraproject.org/koji/taskinfo?taskID=45575240
> 
kernel-core-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64.rpm was
installed according to the root.log and the package contains the file
according to my "rpm -qlp". If the file is not on the system, then something
has deleted it.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Adding Obsoletes to generated -debuginfo packages ?

2020-06-04 Thread Petr Pisar
On Wed, Jun 03, 2020 at 07:29:54PM +0200, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Wed, 2020-06-03 at 18:42 +0200, Vít Ondruch wrote:
> > Other possibility is to modify DNF to not touch such packages. Not
> > sure
> > if that would be better. Or is there already some functionality which
> > would exclude the package from dnf transaction, something like:
> > 
> > ~~~
> > # This package won't be installed, but will obsolete other packages
> > Provides: libsolv-self-destruct-pkg()
> > 
> > ~~~
> > 
> > we use in fedora-obsolete-packages?
> 
> Since they do not block the upgrades, does it really matter? However, I
> agree that DNF removing packages that are not present in upgrade repo
> and blocking the upgrade, should be removed automatically.
> 
That's the distinction between upgrade and distro-sync.

-- Petr



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Update on Rough Draft Implementation of KangarooTwelve

2020-06-02 Thread Petr Pisar
On Tue, Jun 02, 2020 at 07:58:15AM +0200, tsalim--- via devel wrote:
> At this point, I am working on adding support for numbers as large as 2^255
> as required by the length_encode function detailed on page 9 of the RFC.
> 
> The C Programming Language does not support large numbers greater than
> 2^63-1 as Java does.
> 
> So I am working on making a small library for supporting numbers larger than
> the constant mentioned above by storing the large number in an array.
> 
There are plenty of arbitrary precission arithmetics libraries that provide
a support for the big integers. E.g. gmp. I believe that once you try to plug
your implementation into any cryptographic library, you will be coerced to use
that library primitives for the big integers.

I want to say that implementing these primitives is a nice excercise, but it
won't survive any real use case.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


perl-Statistics-Basic license corrected to "LGPLv2 and LGPLv2+"

2020-05-29 Thread Petr Pisar
I corrected perl-Statistics-Basic license from "LGPLv2+" to "LGPLv2 and 
LGPLv2+".

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

2020-05-28 Thread Petr Pisar
On Wed, May 27, 2020 at 05:22:04PM -0400, Mukundan Ragavan wrote:
> Scratch build of gtkhash does not appear to pull in libb2-0.98.1. Has
> the buildroot override expired?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45077601
> 
It did not expire:

$ bodhi overrides query --builds libb2-0.98.1-2.fc31

 libb2-0.98.1-2.fc31

  Submitter: fschwarz
  Expiration Date: 2020-05-29 00:00:00
  Notes: updating borgbackup due to libb2 update
  Expired: False


Use the following to ensure the override is active:

$ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31

1 overrides found (1 shown)

So what libb2 build is in the build root?

$ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31
Warning: nvr libb2-0.98.1-2.fc31 is not current in tag f31-build
  latest build in f31-build is libb2-0.98-4.20171225git60ea749.fc31
^C


How is it possible? What happened with the libb2-0.98.1-2.fc31 build:

$ koji list-history --build libb2-0.98.1-2.fc31
Fri May 22 20:48:12 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-candidate 
by sagitter
Fri May 22 20:54:19 2020 libb2-0.98.1-2.fc31 tagged into f31-signing-pending by 
bodhi
Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 untagged from f31-signing-pending 
by autopen
Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 tagged into 
f31-updates-testing-pending by autopen
Fri May 22 23:00:35 2020 libb2-0.98.1-2.fc31 tagged into f31-override by bodhi
Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 untagged from 
f31-updates-candidate by bodhi
Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-testing by 
bodhi
Sat May 23 04:52:04 2020 libb2-0.98.1-2.fc31 untagged from 
f31-updates-testing-pending by bodhi
Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from f31-updates-testing 
by bodhi
Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from f31-override by bodhi
Tue May 26 15:15:48 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-candidate 
by bodhi [still active]

It was untagged from override by bodhi user on 2020-05-26. That's 3 days before 
the
expiration. It looks like a bug in Bodhi service.

You can try to submit it into override again.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

2020-05-28 Thread Petr Pisar
On Wed, May 27, 2020 at 05:22:04PM -0400, Mukundan Ragavan wrote:
> Scratch build of gtkhash does not appear to pull in libb2-0.98.1. Has
> the buildroot override expired?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45077601
> 
It did not expire:

$ bodhi overrides query --builds libb2-0.98.1-2.fc31

 libb2-0.98.1-2.fc31

  Submitter: fschwarz
  Expiration Date: 2020-05-29 00:00:00
  Notes: updating borgbackup due to libb2 update
  Expired: False


Use the following to ensure the override is active:

$ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31

1 overrides found (1 shown)

So what libb2 build is in the build root?

$ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31
Warning: nvr libb2-0.98.1-2.fc31 is not current in tag f31-build
  latest build in f31-build is libb2-0.98-4.20171225git60ea749.fc31
^C


How is it possible? What happened with the libb2-0.98.1-2.fc31 build:

$ koji list-history --build libb2-0.98.1-2.fc31
Fri May 22 20:48:12 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-candidate 
by sagitter
Fri May 22 20:54:19 2020 libb2-0.98.1-2.fc31 tagged into f31-signing-pending by 
bodhi
Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 untagged from f31-signing-pending 
by autopen
Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 tagged into 
f31-updates-testing-pending by autopen
Fri May 22 23:00:35 2020 libb2-0.98.1-2.fc31 tagged into f31-override by bodhi
Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 untagged from 
f31-updates-candidate by bodhi
Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-testing by 
bodhi
Sat May 23 04:52:04 2020 libb2-0.98.1-2.fc31 untagged from 
f31-updates-testing-pending by bodhi
Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from f31-updates-testing 
by bodhi
Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from f31-override by bodhi
Tue May 26 15:15:48 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-candidate 
by bodhi [still active]

It was untagged from override by bodhi user on 2020-05-26. That's 3 days before 
the
expiration. It looks like a bug in Bodhi service.

You can try to submit it into override again.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: The price of FHS

2020-05-25 Thread Petr Pisar
On Fri, May 22, 2020 at 09:14:14PM -0400, Przemek Klosowski via devel wrote:
> The scheme you are proposing is kind-of used for Java and Go, and is
> sometimes known as 'vendoring' because it allows publishing software in
> complete dependency bundles independent of anything else. It works as long
> as the vendor is diligent about keeping up with it, but it just doesn't
> scale and leads to a fragmented and redundant setup, with decaying software
> all over teh place in those package bundles.

Here the vendor is Fedora. Fedora would have to track all these old versions
and activelly remove them by rebuilding them against the new dependencies.
Users would not notice.

But you are right that the possibility of vendoring makes a huge temptetion to
upstreams to abuse and postponing porting to a new versions ad infinitum and
that's the bitrotting you talk about, because distributions do not have a man
power to overtake all the inactive upstreams. At the end, Fedora would remove
the abandonded software.

It's also the same reason, which the original poster noticed, why NixOS tries
to only keep one version of a package in the system whenever possible.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The price of FHS

2020-05-25 Thread Petr Pisar
On Fri, May 22, 2020 at 07:48:53PM -0500, Parker Gibson wrote:
> The issue I see is that no package management system I know of handles
> multiple so versions, they explicitly state packages conflict with
> each-other even if in principle the so versioning means they would not.

Gentoo portage when updating a package that changes a soname of a library
installs the new package, but keeps the old library in the file system and
remembers the reverse dependencies of the old library. Once all reverse
dependencies are updates/rebuilt to use the new library, the old library is
deleted from the file system.

Of course this is only a partial workaround because the old and new libraries
can expect different (e.g. configuration) files and than the old library
could malfunction. But in reality it almost never happen and the reverse
dependencies are rebuilt sooner than somebody notices it.


> Some repositories can handle multiple major so versions and I do think this
> may provide enough flexibility. I suppose the place of ultimate conflict is
> the devel packages as multi-version headers would always be in conflict, and
> I can’t imagine the nonsense one would have to go through to tell
> autoconf/pkg-config “no wait I want this specific version” in a shared
> library environment.

Why not? If an ELF executable can request a specific library version, then
a build system could request the specific header or pkg-config files. Wrapping
everything (a library and the headers) into a dedicated directory only papers
out the real problem. The fact that nobody was bodered to implement
a versioning into pkg-config files only shows that always building against the
latest version is good enough. Technically a library can version pkg-config
files on the name level (foo-1.pc, foo-2.pc) and projects that undergo a major
API change do that. At the end if a library changes API, then the library
user must be patched. Thus changing foo-1 into foo-2 in the user's code is the
least problem.

> But in principle there is nothing FHS related limiting multiple versions of
> a library. It’s an artificial limitation that probably helps ease the lives
> of package maintainers, it is not a technical limitation imposed by FHS.

Yes. E.g. DNF could keep more package versions installed (provided they do not
conflict). It probably does not happen because the gains do not outweigh the
expenses.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Location of executable code

2020-05-25 Thread Petr Pisar
On Fri, May 22, 2020 at 09:31:25PM -0400, Steve Grubb wrote:
> My question now is how can we determine what is meant to be 
> executable by system applications vs examples and other cruft? (This might be 
> relevant to people minimizing systems/containers.)

Theoretically the examples are a documentation, and a documentation should be
marked in an RPM database with a documentation flag. RPM even has an ability
to remove the documentation files when installing an RPM package.

But the reality is that only the manual pages and the files packaged with
a %doc RPM macro are marked so. E.g. Perl POD files are not marked, because
there is no easy way of programming rpm-build to handle a custom files as
a documentation.
 
Of course these is the "other cruft" that has no flags.

Another approach is the executable bit in a file mode. But it's not applied
evenly. E.g. ELF shared libraries get the bit set, but static libraries are
missing it. Also various languages (like Perl) do not mark their libraries
(modules) with the bit. The meaning of the bit is that the file is a program
with an entry point understood by the kernel program loader. You can e.g.
program Linux to execute Windows executables by configuring binfmt_misc
properly.

So I guess you are after a yet another classification of files.

> Could we ask that all of the executable code live inside a libexec dir and
> examples under something else?

Possible, but tedious. We would need to get a consensus among muplitple
distributions and major upstreams. A decades long project. Installing files
into the unexpected paths is questionable.

Do you know about software collections (RHSCL product)? We packaged some
software under /opt at the expense that users had to set the environment
variables (PATH, LD_LIBRARY_PATH, MANPATH) to get them accessible. It was
backslahed as too obtrusive way of using a software. Here we talk about
patchnig every software to be eable to locate its files on a new location.

I think maintaining a database of files, path prefixes, files name patterns,
or some file flags in an the RPM database or extended attributes in the file
system is an easier approach. Actually extended attributes are used by
SELinux. Maybe augmenting SELinux would make sense. It already has tools for
labeling files.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Petr Pisar
On Fri, May 22, 2020 at 01:28:14PM +0200, Aleksandra Fedorova wrote:
> On Fri, May 22, 2020 at 9:29 AM Petr Pisar  wrote:
> >
> > I'd like to point out that there is a difference in the enviroments between
> > these two approaches.
> >
> > While the manual procedure only installs a binary package (and its
> > dependencies), the OSCI procedure installs all binary packages produced by 
> > the
> > source package (and their depenencies).
> 
> You are right here. Jenkins pipeline tries to install all packages
> from the koji build before running the test.
> 
> And this approach has already hit us many times: there are packages
> where binary subpackages conflict with each other (as in curl), or
> where different tests require different subpackages to be installed.
> There is also a case for reverse dependency check, where we would like
> to run test suite from a package A to test the package B, where the
> koji build we are installing is different from what is expected by the
> test.
> 
> In Fedora CI SIG we are discussing if we should just disable this
> functionality and make it mandatory to specify all packages explicitly
> in the tests.yml under "required_packages" tag, as in [1]
> 
> The downside is:
>  you would need to maintain list of required packages in the tests.yml
> 
> We haven't brought this topic to a wider audience yet, but we should.
> 
I don't have the statistics, but I believe that most of Fedora packages only
produce one binary package.

With that assumption, I would recommend defaulting to installing all of the
binary packages of the build. If there were a conflict, the installation would
fail, and a maintainer would fix the test by specifying the required_packages
explicitly. I.e. the required_packages tag should change a semantacs. Instead
of "the additional packages" it would mean "install these package only". In
other words the required_packages tag would default to the list of binary
packages produced by the build being tested.

That's my ideal approach from point of view of a package maintainer. Of course
I have no idea how difficult the implement is. Maybe it conflicts with the
currecnt OSCI design.

Regarding the case when a test of reverse dependcy fails because the build has
changed, I think it is a standard situation of breaking a compatibility and
the test should fail and the maintainer should decide what to do. E.g. to
move the update into a side tag and adjust the reverse dependency there.

> > In case of freecad, it does not matter, because the freecad component has 
> > only
> > one binary package. But in general it's not true.
> >
> > And here I'd like to ask Aleksandra whether the same applies to modules or
> > not. In general case, a module build produces two binary modules - a 
> > non-devel
> > module and a devel module. Does OSCI install components from both of them? 
> > And does
> > it install the components explicitly, or does it rather install a default
> > profile of the module ("dnf module install" command)?
> 
> We don't have test for modules yet in Fedora CI.

The thing is that producing the devel modules is a matter of MBS
configuration and I feel that Fedora does not produce them in contrast to
CentOS.

> So I would say the question here is:
> 
> how do you like it to work?
> 
> We can do "dnf module install" but then the same issues would appear:
> if you need additional flexibility to test parts of the module, you
> would need to revert this default behavior somehow.
> Or we can do nothing and only provide environment with repositories
> with the updates. So that configuration of the environment is done in
> the test metadata.
> 
The devel modules very often contain the pacakges that are only used for
building the non-devel module and building very often includes running unit
tests. That means that running tests for a module, will very probably need
packages from the devel module. Especially when the tests try to
reproduce the unit tests from the build time.

Since the non-devel module is supposed to work without the devel module, it
makes sense to run the tests by default without the devel module. To get to
the production environment as close as possible. On the other hand there will
be a need for having an acccess to the devel module packages.

I would not install the devel module by default, but provide a way of enabling
the devel module when needed.

Your question can also be understand as whether to preinstall all packages
produced by a module. Regardless of the mythical (in Fedora) devel modules.

On the one hand, modules are perceived as a cohesive group of packages. On the
other hand, I cannot preclude that somebody will create a modu

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

2020-05-22 Thread Petr Pisar
On Thu, May 21, 2020 at 07:29:35PM +0200, Aleksandra Fedorova wrote:
> On Thu, May 21, 2020 at 7:04 PM Richard Shaw  wrote:
> >
> > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova  
> > wrote:
> >>
> >> To run the command above as the integration test you need to put
> >> tests/tests.yml file in dist-git repo with the following content:
> >>
> >> - hosts: localhost
> >>   roles:
> >>   - role: standard-test-basic
> >> tags:
> >> - classic
> >> tests:
> >> - simple:
> >> dir: .
> >> run: "FreeCAD -t 0"
> >>
> >> Note how here you will be using the install FreeCAD binary, not the local 
> >> one.
> >
> >
> > Is this only run on "real" builds, or is it possible to run locally or for 
> > scratch builds?
> 
> We run it for pull-requests and for "real builds.
> 
> It runs in the following way:
> 
> 1) we take latest Fedora Rawhide qcow image,
> 2) we run virtual machine via qemu-kvm from it,
> 3) inside the vm we install the package,
> 4) we run the command defined by "run" key in that YAML file.
> 
> And it is all orchestrated by Ansible.
> 
> It is possible to reproduce the test locally with all the CI wrappers
> around it, but I wouldn't recommend it. To debug the test I would just
> run the VM with the same Rawhide image [1], install the package and
> run the test command manually.

I'd like to point out that there is a difference in the enviroments between
these two approaches.

While the manual procedure only installs a binary package (and its
dependencies), the OSCI procedure installs all binary packages produced by the
source package (and their depenencies).

In case of freecad, it does not matter, because the freecad component has only
one binary package. But in general it's not true.

And here I'd like to ask Aleksandra whether the same applies to modules or
not. In general case, a module build produces two binary modules - a non-devel
module and a devel module. Does OSCI install components from both of them? And 
does
it install the components explicitly, or does it rather install a default
profile of the module ("dnf module install" command)?

-- Petr



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


web-assets

2020-05-20 Thread Petr Pisar
I took web-assets to prevent from braking many packages. If there is somebody
interested in web applications (not my case), I can give the package to him.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: Modules again

2020-05-20 Thread Petr Pisar
On Wed, May 20, 2020 at 09:03:39AM +0100, Paul Howarth wrote:
> What host system are you running that on?

x86_64 Fedora 31 with updates-testing enabled.

After mock finishes bootstrapping DNF, it installs buildrooot and just before
it, it enables the modules:

Complete!
Finish(bootstrap): dnf install
Start(bootstrap): creating root cache
Finish(bootstrap): creating root cache
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 2.2
INFO: Mock Version: 2.2
Start: dnf install
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
   499 kB/s | 2.2 MB 00:04
CentOS-8 - AppStream
   1.0 MB/s | 7.0 MB 00:06
CentOS-8 - PowerTools   
   516 kB/s | 2.0 MB 00:03
CentOS-8 - Extras   
   6.5 kB/s | 5.9 kB 00:00
epel
   555 kB/s | 6.6 MB 00:12
Dependencies resolved.
===
 Package  ArchitectureVersion   
RepositorySize
===
Enabling module streams:
 mariadb  10.3  
  
 mariadb-devel10.3  
  

Transaction Summary
===

Complete!
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
11 kB/s | 3.9 kB 00:00
CentOS-8 - AppStream
11 kB/s | 4.3 kB 00:00
CentOS-8 - PowerTools   
   9.9 kB/s | 4.3 kB 00:00
CentOS-8 - Extras   
   3.5 kB/s | 1.5 kB 00:00
epel
   4.4 kB/s | 4.7 kB 00:01
epel
   726 kB/s | 6.6 MB 00:09
Dependencies resolved.
===
 Package  ArchitectureVersion   
  Repository  Size
===
Installing:
 bash x86_64  4.4.19-10.el8 
  BaseOS 1.5 M

After installing the buildroot, it installs the Judy-devel package.

I cannot speak much about a mock configuration, because I had my own changes
in the defaults.cfg and site-defaults.cfg, but when mock introduced the
templates I thrown my configuration away. I don't have any changes in
epel-8-x86_64.cfg and the templates.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: Lots of systemctl segfaults in Koji Rawhide

2020-05-20 Thread Petr Pisar
On Tue, May 19, 2020 at 08:24:34PM -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 18:32 -0700, Adam Williamson wrote:
> > 
> > The most suspicious change between the two build envs that I can see is
> > openssl. GOOD has openssl-1.1.1g-1.fc33.x86_64 , and BAD has
> > openssl-1.1.1g-2.fc33.x86_64 . I'm gonna try doing an openssl build
> > with the patch from -2 reverted and see where that gets us.
> 
> OK, I think that did the trick. nbdkit's x86_64 build succeeded this
> time, and the log shows no systemctl crashes:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/7666/44717666/root.log
> 
> I'll file a bug on openssl to let tmraz know about the problem.
> Hopefully between the two fixes, the next Rawhide may also be fixed...

Nice detective work. You could have save your work with Koschei.

 nbdkit history,
 first failure with this test
failure on x86_64:

supermin: exception: 
Sys_error("/lib/modules/5.7.0-0.rc5.20200515git1ae7efb38854.1.fc33.x86_64/modules.dep:
 No such file or directory")

with only 5 source packages changed and openssl going from 1:1.1.1g-1.fc33 to
1:1.1.1g-2.fc33 being one of them.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: Modules again

2020-05-20 Thread Petr Pisar
On Wed, May 20, 2020 at 08:10:42AM +0200, Petr Pisar wrote:
> Now you can ask why enabling mariadb-devel:10.3 does not enable mariadb:10.3
> automatically. Especially when mariadb-devel:10.3 run-requires mariadb:10.3
> according to "dnf module info mariadb-devel:10.3" command. The answer is a bug
> in DNF. I think I recall the bugs has already been fixed, but apparantly it's
> still (or again) there.
> 
https://bugzilla.redhat.com/show_bug.cgi?id=1837841

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Modules again

2020-05-20 Thread Petr Pisar
On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote:
> On Tue, 19 May 2020 09:07:30 -0400
> Stephen John Smoogen  wrote:
> 
> > On Tue, 19 May 2020 at 06:05, Paul Howarth  wrote:
> > 
> > > On Mon, 18 May 2020 22:29:54 -0600
> > > Orion Poplawski  wrote:
> > >  
> > > > On 5/17/20 6:34 AM, Paul Howarth wrote:  
> > > > > I'm trying to do a local build of gtkwave for EPEL-8.
> > > > >
> > > > > A koji scratch build somehow works:
> > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
> > > > >
> > > > > But a local build does not:
> > > > >
> > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm
> > > > > ...
> > > > > Error:
> > > > >   Problem: conflicting requests
> > > > >- package
> > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded
> > > > >- package
> > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is
> > > > > excluded
> > > > >
> > > > > Adding a repo with a local build of Judy doesn't help; that gets
> > > > > excluded too.
> > > > >
> > > > > Any clues?
> > > > >
> > > > > Paul.  
> > > >
> > > > Judy-devel appears to be part of the mariadb-devel module.
> > > > Locally I can do:
> > > >
> > > > dnf module enable mariadb-devel
> > > > dnf install Judy-devel
> > > >
> > > > This was discovered with:
> > > >
> > > > dnf module provides Judy-devel
> > > >
> > > > on RHEL 8.2, though that does not appear to work on CentOS 8.1.
> > > >
> > > > For mock, this seems to work:
> > > >
> > > > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel
> > > > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm  
> > >
> > > I tried that and it didn't make any difference for me (building on
> > > F-31). Maybe I need to wait for CentOS 8.2?
> > >
> > >  
> > Hmm do you have the Powertools enabled in that Mock? I see Judy-devel
> > in the CentOS-8.1 tree in Powertools.
> 
> Yes, I'm using vanilla configs straight from mock-core-configs for
> this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl,
> which has the PowerTools repo defined and not disabled.
> 
> (I generally use my own configs and don't touch the original ones, so I
> know that if I try the original ones from upstream then they should
> work as intended)
> 
> Note that the error message doesn't say it can't find Judy-devel, it
> says that it (and Judy) is/are excluded. I don't know why that is.
> 
The message means that the Judy-devel package exists in a repository, but is
not available for an installation, because a module it belongs to is not
active (i.e. not enabled nor default). The correct procedure is enable
the module it belongs to.

"dnf module provides Judy-devel" command returns mariadb-devel:10.3 module.
After enabling that module you get another error message that Judy package is
excluded. That's because Judy package belongs to mariadb:10.3 module. You also
need to enable that module. Then it works. It also works in mock:

$ mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel --config-opts 
module_enable=mariadb install Judy-devel
[...]
INFO: installing package(s): Judy-devel
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
   539 kB/s | 2.2 MB 00:04
CentOS-8 - AppStream
   1.3 MB/s | 7.0 MB 00:05
CentOS-8 - PowerTools   
   442 kB/s | 2.0 MB 00:04
CentOS-8 - Extras   
   5.7 kB/s | 5.9 kB 00:01
epel
   5.2 kB/s | 4.7 kB 00:00
Dependencies resolved.
===
 PackageArchitecture   Version  
  Repository  Size
===
Installing:
 Judy-devel x86_64 
1.0.5-18.module_el8.1.0+217+4d875839   PowerTools   
   76 k
Installing dependencies:
 Judy   x86_64 
1.0.5-18.module_el8.1.0+217+4d875839   AppStream
  131 k

Transaction Summary
===
Install  2 Packages
[...]
Installed:
  Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64  
Judy-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 


Re: i3wm for EPEL8

2020-05-19 Thread Petr Pisar
On Tue, May 19, 2020 at 10:47:57AM -0400, Eric Mesa wrote:
> So...what is the proper path to get the perl folks to create epel8 branches
> in their repos

The same as with any other package: File a bug into Bugzilla.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: how to explicitly disable rawhide while building a spin/remix

2020-05-18 Thread Petr Pisar
On Mon, May 18, 2020 at 12:07:38AM +, Globe Trotter via devel wrote:
>  Thanks! Adding  "--releasever=32" to the command addresses that problem.
> Btw, how do I get around a disk requirement? What causes an error like this?
> 
> Error Summary-
> Disk Requirements:
>    At least 137MB more space needed on the / filesystem.
> 
DNF returns this error when the file system is read-only.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)

2020-05-18 Thread Petr Pisar
On Sat, May 16, 2020 at 12:56:06PM +0200, Dominique Martinet wrote:
> How should I go about with that? Open bz bugs to all the packages I
> listed? strongly suggesting to get things to move to /usr/share (17) and
> flatpak (suggest some kind of cache? not sure they'll be interested...)
> and environment-modules (not sure what to suggest there, I only have
> environment-modules because I need to test something with openmpi from
> time to time and it comes with it...)
> 
> 
> It might also make sense to have a packaging guideline suggesting to
> avoid /etc/bash_completion.d in favor of the /usr/share variant, I
> couldn't find anything here[1] but I might not have looked thoroughly
> enough...
> [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/
> 
When you are at fixing a packaging of the completion scripts, please make the
dependency on bash-completion optional (Recommends: bash-completion). It used
to be a good habit to weaken the dependency because not everyone is willing to
pay the slow-down tax if he has no use of the completion:

# dnf repoquery --whatrequires 'bash-completion' | grep -v bash-completion
frama-c-0:20.0-3.fc33.x86_64
hashcat-0:5.1.0-7.fc33.i686
hashcat-0:5.1.0-7.fc33.x86_64
kiwi-cli-0:9.20.5-1.fc33.noarch
perl-Config-Model-Itself-0:2.020-2.fc32.noarch
snapd-0:2.43.3-1.fc33.x86_64
toolbox-experience-0:0.0.18-3.fc33.noarch
votca-csg-bash-0:1.6-1.fc33.noarch

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: Documentation for EPEL modules?

2020-05-18 Thread Petr Pisar
On Sat, May 16, 2020 at 11:43:00AM +0200, Antonio Trande wrote:
> On 15/05/20 14:57, Stephen Gallagher wrote:
> > On Fri, May 15, 2020 at 7:57 AM Petr Pisar  wrote:
> >>
> >> On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> >>> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> >>>
> >>>> On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> >>>>> Shortly (Martin is in Cc to confirm):
> >>>>>
> >>>>> 1) Make a module:
> >>>>>
> >>>>> $ fedpkg clone cmake3
> >>>>> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> >>>>> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> >>>>>
> >>>> This will request for creating "cmake3-latest" module and "cmake3-latest"
> >>>> repository and "epel8" stream and "epel8" branch. I don't know if you
> >>>> really
> >>>> want to create "cmake3-latest:epel8" module stream.
> >>>>
> >>>
> >>> Since this is a module, is there any point in using the cmake3 namespace
> >>> over just cmake?
> >>>
> >> I cannot see any point. Maybe if there were cmake-2 or cmake-4 
> >> incompatible to
> >> cmake-3 but installable in parallel, then it would make sense. (Like 
> >> Python.)
> >> Because you cannot install more streams of the same module at the same 
> >> time.
> >> Otherwise I would also go with plain "cmake" module name.
> > 
> > 
> > It turns out, cmake already has a presence[1] in the modules namespace
> > of dist-git. It is a relic of the Modularity 1.0 effort, but it's
> > already there and that will make this easier.
> 
> Petr, can you take care of this module for epel8, too?
> 
I cannot because of a lack of time and interest in CMake. But I can transfer
an ownership of the module to whoever wants it. Also please note that at that
time CMake bundled various libraries and a second build-only cmake-bootstrap
module was needed to build the cmake module properly. I will include it into
the gift.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: [EPEL-devel] Re: Documentation for EPEL modules?

2020-05-18 Thread Petr Pisar
On Sat, May 16, 2020 at 11:43:00AM +0200, Antonio Trande wrote:
> On 15/05/20 14:57, Stephen Gallagher wrote:
> > On Fri, May 15, 2020 at 7:57 AM Petr Pisar  wrote:
> >>
> >> On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> >>> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> >>>
> >>>> On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> >>>>> Shortly (Martin is in Cc to confirm):
> >>>>>
> >>>>> 1) Make a module:
> >>>>>
> >>>>> $ fedpkg clone cmake3
> >>>>> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> >>>>> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> >>>>>
> >>>> This will request for creating "cmake3-latest" module and "cmake3-latest"
> >>>> repository and "epel8" stream and "epel8" branch. I don't know if you
> >>>> really
> >>>> want to create "cmake3-latest:epel8" module stream.
> >>>>
> >>>
> >>> Since this is a module, is there any point in using the cmake3 namespace
> >>> over just cmake?
> >>>
> >> I cannot see any point. Maybe if there were cmake-2 or cmake-4 
> >> incompatible to
> >> cmake-3 but installable in parallel, then it would make sense. (Like 
> >> Python.)
> >> Because you cannot install more streams of the same module at the same 
> >> time.
> >> Otherwise I would also go with plain "cmake" module name.
> > 
> > 
> > It turns out, cmake already has a presence[1] in the modules namespace
> > of dist-git. It is a relic of the Modularity 1.0 effort, but it's
> > already there and that will make this easier.
> 
> Petr, can you take care of this module for epel8, too?
> 
I cannot because of a lack of time and interest in CMake. But I can transfer
an ownership of the module to whoever wants it. Also please note that at that
time CMake bundled various libraries and a second build-only cmake-bootstrap
module was needed to build the cmake module properly. I will include it into
the gift.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [EPEL-devel] Re: Documentation for EPEL modules?

2020-05-15 Thread Petr Pisar
On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> 
> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > > Shortly (Martin is in Cc to confirm):
> > >
> > > 1) Make a module:
> > >
> > > $ fedpkg clone cmake3
> > > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> > >
> > This will request for creating "cmake3-latest" module and "cmake3-latest"
> > repository and "epel8" stream and "epel8" branch. I don't know if you
> > really
> > want to create "cmake3-latest:epel8" module stream.
> >
> 
> Since this is a module, is there any point in using the cmake3 namespace
> over just cmake?
> 
I cannot see any point. Maybe if there were cmake-2 or cmake-4 incompatible to
cmake-3 but installable in parallel, then it would make sense. (Like Python.)
Because you cannot install more streams of the same module at the same time.
Otherwise I would also go with plain "cmake" module name.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: Documentation for EPEL modules?

2020-05-15 Thread Petr Pisar
On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> 
> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > > Shortly (Martin is in Cc to confirm):
> > >
> > > 1) Make a module:
> > >
> > > $ fedpkg clone cmake3
> > > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> > >
> > This will request for creating "cmake3-latest" module and "cmake3-latest"
> > repository and "epel8" stream and "epel8" branch. I don't know if you
> > really
> > want to create "cmake3-latest:epel8" module stream.
> >
> 
> Since this is a module, is there any point in using the cmake3 namespace
> over just cmake?
> 
I cannot see any point. Maybe if there were cmake-2 or cmake-4 incompatible to
cmake-3 but installable in parallel, then it would make sense. (Like Python.)
Because you cannot install more streams of the same module at the same time.
Otherwise I would also go with plain "cmake" module name.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: [EPEL-devel] Re: Documentation for EPEL modules?

2020-05-15 Thread Petr Pisar
On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> Shortly (Martin is in Cc to confirm):
> 
> 1) Make a module:
> 
> $ fedpkg clone cmake3
> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> 
This will request for creating "cmake3-latest" module and "cmake3-latest"
repository and "epel8" stream and "epel8" branch. I don't know if you really
want to create "cmake3-latest:epel8" module stream.

In Fedora, a name of a module must match the name of the repository, and
a name of a stream must match the name of the branch.

(Technically, it's possible to diverge, but Fedora's infrastructure enforces
it.)

If what you want is "cmake3:latest" module stream, then you need:

$ fedpkg request-repo --namespace modules cmake3
$ fedpkg request-branch --namespace modules --repo cmake3 latest

Also please note that modules undergo a review. So for a new module, you need
an approved review first and the "--exception" argument should not be used.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: Documentation for EPEL modules?

2020-05-15 Thread Petr Pisar
On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> Shortly (Martin is in Cc to confirm):
> 
> 1) Make a module:
> 
> $ fedpkg clone cmake3
> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> 
This will request for creating "cmake3-latest" module and "cmake3-latest"
repository and "epel8" stream and "epel8" branch. I don't know if you really
want to create "cmake3-latest:epel8" module stream.

In Fedora, a name of a module must match the name of the repository, and
a name of a stream must match the name of the branch.

(Technically, it's possible to diverge, but Fedora's infrastructure enforces
it.)

If what you want is "cmake3:latest" module stream, then you need:

$ fedpkg request-repo --namespace modules cmake3
$ fedpkg request-branch --namespace modules --repo cmake3 latest

Also please note that modules undergo a review. So for a new module, you need
an approved review first and the "--exception" argument should not be used.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Updating CMake in EPEL-8: How to create a module?

2020-05-15 Thread Petr Pisar
On Fri, May 15, 2020 at 08:58:21AM -, Alexander Korsunsky wrote:
> Hi there,
> 
> the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11,
> which is becoming more and more outdated. Me (and a few other people,
> judging by bug report participation) would quite like to have a newer
> version of CMake on their systems.
> 
> Now, if I understand correctly, according to the EPEL policies,
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy, it is
> prohibited to replace packages from the base distribution. It is, however,
> allowed to replace these packages in modules that are not enabled by
> default.
> 
> Unfortunately, nobody really seems to know how to build modules for EPEL.
> There is documentation for Fedora:
> https://docs.fedoraproject.org/en-US/modularity/making-modules/ . However,
> being not very familiar with modularity, I have no clue which parts of the
> documentation apply to EPEL, and I could not find EPEL-specific
> documentations and recommendations. I have seen some threads on this list
> *discussing* these, but it's hard for me to discern the consensus and best
> practices from mailing list threads.
> 
> Would the Modularity magicians be so kind as to reply with some pointers on
> how to create modules for EPEL? If that already exists, my apologies, I hope
> you can direct me to that resource.
> 
I replied to the same question yesterday on Fedora devel list
.
 

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: Documentation for EPEL modules?

2020-05-14 Thread Petr Pisar
On Thu, May 14, 2020 at 06:46:29AM -0500, Richard Shaw wrote:
> So this happened:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ad02b27ee3
> https://bugzilla.redhat.com/show_bug.cgi?id=1830748
> 
> TLDR; So we need an updated version of CMake in EPEL 8 but RHEL/CentOS
> already provide a "3" version. Worse both the Fedora and EL versions
> provide "cmake3" packages and binaries so it's not possible to install the
> cmake3 package in EL 8.
> 
> So here's a great use case for modularity but I have no idea how it works
> and there doesn't seem to be any EPEL specific documentation even though
> it's obviously getting used:
> 
> https://bodhi.fedoraproject.org/releases/EPEL-8M
> 
> Do we need a epel8 branch? Or is the EL module created from master?
> 
I believe modules in EPEL are similar to modules in Fedora. I'm not aware
about a documentation for modules in EPEL. There were some attempts to draft
the guide lines like forbiding default streams and mandating stream prefixes,
but I do not remember any output.

Let's look at real examples.
 lists 
avocado-latest-820200512173744.9edba152 module. That's this
 module build
in Koji. The Source field reads 
.

Theat means "fedpkg clone modules/avocado" and there these branches:

* latest
  remotes/origin/52lts
  remotes/origin/69lts
  remotes/origin/HEAD -> origin/latest
  remotes/origin/f29
  remotes/origin/latest
  remotes/origin/master
  remotes/origin/stable

The module stream is called "latest", let us check "latest" branch:

commit 12e2140e759fdb0a4477ab2432c411a4452d8efc (HEAD -> latest, origin/latest, 
origin/HEAD)
Author: Merlin Mathesius 
Date:   Tue May 12 12:37:44 2020 -0500

Rebuild with avocado 79.0.

Signed-off-by: Merlin Mathesius 

So you can see the module is built from a non-epel8 branch. An avocado.yaml
file lists these dependencies:

  dependencies:
  - buildrequires:
  platform: []
requires:
  platform: []

So "platform" is left empty to expand it by MBS on all available platforms. If
you look at koji listing
, there are
five modules avocado-latest-*20200512173744 builds of from the same sources.
That probably means that Koji attempts to build the module for all Fedoras and
EPEL 8. Technically, it's possible to override the platform with "fedpkg
module-build" command, but I cannot see any trace of it in the logs.

That buld was performed by "merlinm" users. You can ask him for more details.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

2020-05-12 Thread Petr Pisar
On Tue, May 12, 2020 at 12:47:51PM +, virgo wrote:
> > I recommend you to ask the question about v2 support on Fedora Bugzilla for=
> > 
> >  the
> > 
> > libcgroup package
> >  > =3Dlibcgroup=3DFedora_format=3Dadvanced>.
> Prior to the top post, I went through the Bugzilla tickets, with these 
> parameters:
> 
> * component=libcgroup
> * order=changeddate DESC
> * product=Fedora
> * query_format=advanced
> 
> and the hits dating back to 2015[fn:1] were just a dozen, none making mention 
> of v2. So, I am not sure whether opening feature requests would help.

Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
compatible with cgroup v2, then libcgroup package is not compatible with
Fedora and this is a bug and should be reported to the Fedora's Bugzilla.

> By the way, what would you and (and others) recommend as a replacement for 
> libcgroup-tools?[fn:2]

No idea. I don't use cgroups for anything on purpose. As far as I know,
cgroups membership in Fedora is defined by systemd's logind. Whether it suits
your needs, I have no idea. I also think it's possible to manage the
membership manually by editing files in cgroup2 pseudo file system.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

2020-05-12 Thread Petr Pisar
On Tue, May 12, 2020 at 09:03:22AM +, virgo wrote:
> The issue is that I upgraded my computer to Fedora 32 from version 30, and 
> broke some scripts in the process; they were relying on cgroup v1.
[...]
> how to use the `cgcreate` command and the like under libcgroup v2?

cgcreate tool comes from libcgroup-tools-0:0.42.2-1.fc32 package that comes
from libcgroup project sources, and libcgroup does not yet support cgroup v2.

A quick search of WWW shows that
:

30 October 2019, 04:38:42
The libcgroup devs are currently discussing plans to implement v2 cgroup
support

 project had a last release on 2014-01-13.
A thread on its devel list
 from 2019-10-14
still discusses v2 support as in-progress.

Fedora packages a fork (or a new upstream) from 
.
I recommend you to ask the question about v2 support on Fedora Bugzilla for the
libcgroup package
.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-10 Thread Petr Pisar
On Fri, May 08, 2020 at 09:39:58AM -0600, Ken Dreyer wrote:
> In Ceph we do this at a slightly different point of time. We use
> "rdopkg tag-patches" to save each of the "patches" refs that we've
> translated into patch series in dist-git. Each Git tag is the NVR of
> the package.
> 
> We rebase and force-push our "patches" branches frequently, so a
> patches branch is one "history", and dist-git becomes a "history of
> histories".
> 
> It's critical to have this flexibility + auditability so we can move
> fast and still go back and reproduce everything.
> 
How do you backport fixes? Do apply the fixes directly to dist-git? Or do you
apply the fixes to a corresponding patches branch that you occur to have
around till needed (e.g. till the hitorical code is supported) for the purpose
of backporting?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8

2020-05-05 Thread Petr Pisar
On Tue, May 05, 2020 at 04:00:28PM +0200, Petr Pisar wrote:
> On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote:
> > On Tue, May 5, 2020 at 12:23 AM Petr Pisar  wrote:
> > >
> > > On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
> > > > I have not created any bugzila's for these yet.  I have not checked to
> > > > see if these are in -testing already.  This is just a list showing
> > > > what packages currently do not install from EPEL 7.
> > > >
> > > > perl-Image-SubImageFind
> >   - nothing provides libMagickCore.so.5()(64bit) needed by
> > perl-Image-SubImageFind-0.03-1.el7.x86_64
> >   - nothing provides libMagick++.so.5()(64bit) needed by
> > perl-Image-SubImageFind-0.03-1.el7.x86_64
> > 
> > > > perl-X11-GUITest
> > perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind),
> > but none of the providers can be installed
> > 
> > >
> > > I can install these two packages. They were built 6 years ago. Can you 
> > > provide
> > > more details.
> > >
> > 
> > If you are running RHEL or CentOS 7.8 then you cannot install them due
> > to the updated ImageMagick.
> > 
> I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to
> install them because RHEL does not remove old packages from repositories and
> my package manager simply chose the older compatible build (because I did not
> have installed ImageMagick before).
> 
> > It looks like you just need to rebuild perl-Image-SubImageFind and
> > both packages should be able to install.
> > 
> I will rebuild them.
> 
Fixed with perl-Image-SubImageFind-0.03-2.el7.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8

2020-05-05 Thread Petr Pisar
On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote:
> On Tue, May 5, 2020 at 12:23 AM Petr Pisar  wrote:
> >
> > On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
> > > I have not created any bugzila's for these yet.  I have not checked to
> > > see if these are in -testing already.  This is just a list showing
> > > what packages currently do not install from EPEL 7.
> > >
> > > perl-Image-SubImageFind
>   - nothing provides libMagickCore.so.5()(64bit) needed by
> perl-Image-SubImageFind-0.03-1.el7.x86_64
>   - nothing provides libMagick++.so.5()(64bit) needed by
> perl-Image-SubImageFind-0.03-1.el7.x86_64
> 
> > > perl-X11-GUITest
> perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind),
> but none of the providers can be installed
> 
> >
> > I can install these two packages. They were built 6 years ago. Can you 
> > provide
> > more details.
> >
> 
> If you are running RHEL or CentOS 7.8 then you cannot install them due
> to the updated ImageMagick.
> 
I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to
install them because RHEL does not remove old packages from repositories and
my package manager simply chose the older compatible build (because I did not
have installed ImageMagick before).

> It looks like you just need to rebuild perl-Image-SubImageFind and
> both packages should be able to install.
> 
I will rebuild them.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-05 Thread Petr Pisar
On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
> Petr, I should have probably stressed that our target is Fedora (or
> even all Red Hat operating systems). Yes, there are hundreds of
> distributions and we cannot solve their problems. We are open for
> collaboration though - we cannot drive changes in distributions which
> we don't know or use.
> 
If you only target Fedora, then it means that the same amount of Fedora
maintainers will maintain twofold amount of repositories. Does it indeed save
work? What's the benefit of maintaining more repositories?

Therefore I assumed you had targeted more distribution to share and
externilize the maintenance.

Maybe my problem is that I don't buy your argument that if Fedora dist-git
looks as Github, then Fedora will attract new packagers.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8

2020-05-05 Thread Petr Pisar
On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
> I have not created any bugzila's for these yet.  I have not checked to
> see if these are in -testing already.  This is just a list showing
> what packages currently do not install from EPEL 7.
> 
> perl-Image-SubImageFind
> perl-X11-GUITest

I can install these two packages. They were built 6 years ago. Can you provide
more details.

The only issue with them I can see is that they were retired in Fedora master.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-05 Thread Petr Pisar
On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> Over the years there have been multiple tools created to improve the
> development experience:
> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
> the way Fedora kernel developers work on kernel [k]).
> 
> In the packit project, we work in source-git repositories. These are
> pretty much upstream repositories combined with Fedora downstream
> packaging files.

And then come another distribution with a request to combine its dist-git into
the upstream. Fedora is not the only distribution. Do you know how many
distributions exist? From my point of view as a upstream it's one big NO.

>From point of view of a Fedora packager, it's just moving Fedora bits into
another repository with the burden of synchronizing that repository with
dist-git (and back because of what an authoritative source for Fedora is).

If you want to introduce an intermediary third repository between the upstream
and the distribution, a repository that would normalize (read git-ify) the
upstream and overlay downstream patches and metadata, then, ehm, it's a nice
project for exploration how far we go with unification among the
distributions. But I'm quite sceptical regarding it's adoption. But don't take
my prognosis seriously. I can be mistaken. There are some positive prior arts
like release-monitoring.org.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Node.js 14.x by default

2020-05-04 Thread Petr Pisar
On Sat, May 02, 2020 at 02:01:43AM +0200, Miro Hrončok wrote:
> On 01. 05. 20 22:21, Ben Cotton wrote:
> > == Detailed Description ==
> > Fedora 33 will ship with the latest LTS version of Node.js by default.
> > This will either be the `nodejs:14` module stream or else replicated
> > to the non-modular repository, depending on the status of other
> > release engineering work around supporting modular content in the
> > non-modular buildroots.
> 
> Since default modular streams are banned,

Indeed? I thought that they are not banned, they only need a FESCo approval.

Maybe a related issue: Where did Module packaging guidelines disappear?
I remember they were reachable from
.
(Home → Packaging Guidelines navigation at
 does not work.)

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: Broken %python_provide macro for Koji's epel8-playground target?

2020-05-01 Thread Petr Pisar
On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote:
> Generally speaking (I can make this a separate thread if that helps) - do we
> expect every package in EPEL8 to also be built for EPEL8-playground, either
> through package.cfg or by building directly from the epel8-playground
> branch?

There is no such rule, but in my opinion, it is welcomed for exactly the 
terrible
experience anybody gets when he tries to use epel8-playground.

The purpose of epel8-playground is to diverge when needed. That's why the epel8
branch contains package.cfg by default.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-30 Thread Petr Pisar
On Thu, Apr 30, 2020 at 10:43:51AM +0200, Petr Šabata wrote:
> On Tue, Apr 28, 2020 at 8:55 AM Petr Pisar  wrote:
> >
> > On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> > > On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar  wrote:
> > > > (2) Is it possible to override them on a per-package basis?
> > > >
> > > > E.g. I have ncurses in global.yaml:
> > > >
> > > > - name: ncurses
> > > >   description: Add support for ncurses.
> > > >   enabled: true
> > > >
> > > > and I have plenty of packages that use the ncurses feature in my 
> > > > module. What
> > > > should I write to my modulemd so that "ncurses" feature for "pcre" 
> > > > package is
> > > > disabled, but all the other packages have it enabled? Or is it a 
> > > > completelly
> > > > illed request to have the same feature enabled at one package and 
> > > > disabled on
> > > > another one?
> > >
> > > It is and that's actually how the local is implemented. It extends the
> > > basic definitions with %{name} checks like this:
> > >
> > > %_use_ncurses %{lua:
> > > if rpm.expand("%{name}") == "yourpackage1"
> > >   or rpm.expand("%{name}") == "yourpackage2" then
> > >   print(rpm.expand("%{bcond_with foo}%{with foo}"))
> > > else
> > >   print(rpm.expand("%{bcond_without foo}%{with foo}"))
> > > end
> > > }
> > >
> > > I know it's not very user friendly. Maybe there's a better way that
> > > doesn't blow up on recursive macro definition.
> > >
> > Do I understand it correctly that modules should reimplement the 
> > %_use_ncurses
> > macro? That's really clumsy and I'd like to avoid it. Not speaking about the
> > issues with recursion you are aware and I was hoping you found a solution.
> > Modules would have to simply redefine the macro covering all packages built 
> > in
> > the module.
> 
> Yes, it is clumsy and you're correct here.
> 
> MBS also just extends the macro definitions so I'm not sure how to
> work around the recursion problem even if we introduced a new modulemd
> section just for this (which wouldn't feel right either).  Would you
> have any suggestions?
> 
Unfortunately I have no suggestion. I agree that the new modulemd section
would be an overkill.

> > Actually if the generation of the macros was postponed to a spec file, there
> > would not have to exist any local.yaml file. That way the spec file would be
> > be self-contained. I agree with others that separating the local overrides
> > into local.yaml maintained in a different package is not handy and slows the
> > packager's work flow.
> 
> But it also defeats the idea of these being set by the system, leaving
> package repos untouched.
> 
You are right. I forgot this use case.

Probably because local.yaml is a misnomer. local.yaml is a distribution-wide
configation like global.yaml. It's only per-package configuration. In Gentoo,
"local" use flags are indeed defined next to the ebuild. But in Fedora their
definition would be separated from the packages. local.yaml is more alike to
a Gentoo profile.

Technically local.yaml (it's actually a set of locale.%{name}.yaml files)
could be merged into the global.yaml file. But the syntax would be horrible
because there would be a tension whether to collate them by a feature and then
by a package name, or vice versa. Not speaking about an inflation by
the descriptions. I miss the Gentoo brevity:

* ncurses
pcre -ncurses

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-30 Thread Petr Pisar
On Wed, Apr 29, 2020 at 03:39:20PM -0400, Colin Walters wrote:
> On Mon, Apr 27, 2020, at 7:19 AM, Petr Šabata wrote:
> 
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
> 
> How about s/use/globalbuildopt/ ?
> 
It's awfully long concatenation of two words and an abbreviation. No.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: epel8-playground target ignores build overrides?

2020-04-29 Thread Petr Pisar
On Tue, Apr 28, 2020 at 09:22:56PM -0700, Michel Alexandre Salim wrote:
> My epel8 build for python-extras succeeded just fine (using python-testtools
> from a build override as a dependency -
> https://bodhi.fedoraproject.org/overrides/python-testtools-2.4.0-3.el8), but
> the epel8-playground build claims python-testtools is not available:
> 
> epel8:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1499241
> 
> epel8-playground:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43889481
> 
> DEBUG util.py:600:  No matching package to install: 'python3-testtools'
> DEBUG util.py:600:  Not all dependencies satisfied
> DEBUG util.py:600:  Error: Some packages could not be found.
> 
> Does the playground setup not take overrides into account?
> 
playground is an independent build target and thus overrides in epel8 and
epel8-playground are independent. But you don't need to create overrides in
epel8-playground because builds there appears in a build root automatically
on next repository regeneration.

However, your problem is not in overrides. Your problem is that
python-testtools package has never been successfully built for
epel8.playground: 

https://koji.fedoraproject.org/koji/packageinfo?packageID=11850

That's probably because of Carl George  deleted the
package.cfg configuration from epel8 branch to mirror the builds into
epel8-buildroot:

commit dd46fcc88a92241e2aa776208cf7ef0dddbab541
Author: Carl George 
Date:   Fri Apr 24 01:06:33 2020 -0500

Revert ""Adding package.cfg file""

This reverts commit 6a8c5775eb802cc8acfb93dfbe7e00d8e92a24a3.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-28 Thread Petr Pisar
On Mon, Apr 27, 2020 at 04:33:52PM +0200, Petr Šabata wrote:
> On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar  wrote:
> > (2) Is it possible to override them on a per-package basis?
> >
> > E.g. I have ncurses in global.yaml:
> >
> > - name: ncurses
> >   description: Add support for ncurses.
> >   enabled: true
> >
> > and I have plenty of packages that use the ncurses feature in my module. 
> > What
> > should I write to my modulemd so that "ncurses" feature for "pcre" package 
> > is
> > disabled, but all the other packages have it enabled? Or is it a completelly
> > illed request to have the same feature enabled at one package and disabled 
> > on
> > another one?
> 
> It is and that's actually how the local is implemented. It extends the
> basic definitions with %{name} checks like this:
> 
> %_use_ncurses %{lua:
> if rpm.expand("%{name}") == "yourpackage1"
>   or rpm.expand("%{name}") == "yourpackage2" then
>   print(rpm.expand("%{bcond_with foo}%{with foo}"))
> else
>   print(rpm.expand("%{bcond_without foo}%{with foo}"))
> end
> }
> 
> I know it's not very user friendly. Maybe there's a better way that
> doesn't blow up on recursive macro definition.
> 
Do I understand it correctly that modules should reimplement the %_use_ncurses
macro? That's really clumsy and I'd like to avoid it. Not speaking about the
issues with recursion you are aware and I was hoping you found a solution.
Modules would have to simply redefine the macro covering all packages built in
the module.

Since you use Lua (because RPM conditions are not allowed there), wouldn't
be better to export the mapping from a package name to a feature as a Lua
associative array? Modules would then just added/rewrote a tuple there and
than call a Lua function to regenerate the %_use macros?

Actually if the generation of the macros was postponed to a spec file, there
would not have to exist any local.yaml file. That way the spec file would be
be self-contained. I agree with others that separating the local overrides
into local.yaml maintained in a different package is not handy and slows the
packager's work flow.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Pisar
On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
>
I'm very interested in overriding the global settings:

(1) Is it possible to override them from a modulemd when building a module?

I guess the asnswer is define %_with_ and %_without_ macros in
a buildopts/rpms/macros section of the module. Could elaborate more
the "Compatibility with RPM's --with & --without options" section?

Please note hat the RPM options and the macros have three states (true, false,
undefined) and %_with_foo 0 does not turn %bcond_without foo into false.
I don't ask about preserving a compatibility with this silly semantics, but
some clarification will be needed if this proposal becomes approved.

(2) Is it possible to override them on a per-package basis?

E.g. I have ncurses in global.yaml:

- name: ncurses
  description: Add support for ncurses.
  enabled: true

and I have plenty of packages that use the ncurses feature in my module. What
should I write to my modulemd so that "ncurses" feature for "pcre" package is
disabled, but all the other packages have it enabled? Or is it a completelly
illed request to have the same feature enabled at one package and disabled on
another one?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


  1   2   3   4   5   6   7   8   9   10   >