Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Miroslav Suchý]

Dne 13. 11. 19 v 0:21 Kevin Kofler napsal(a):

But the wasted space will be even more, because now you have libpython, the
dynamic python3 linked against it, AND the python3-static binary. So it does
not address the issue at all.


+1

"Requires: /path/to/my/python3" is no go. Because no maintainer knows what an user prefers. Speed or space. And you may 
end up in mixed environment where you waste both space and cpu.


Both packages should provides "python3" and it should be an user responsibility which python flavor will be installed on 
system.


--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1744690



--- Comment #7 from Emmanuel Seyman  ---
(In reply to Xavier Bachelot from comment #6)
> 
> Sorry, I didn't realize the missing deps were all yours.

Actually, they're Ralf's, not mine. But since Ralf doesn't like being assigned
EPEL bugs, I decided to file the bugs so that I could assign them to myself,
not to him.

But, because requesting a branch doesn't give you commit access to it, I can't
push changes. So I've handed over the whole thing to Paul.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

R-testit license change: GPLv2+ to GPLv3

[Elliott Sales de Andrade]

Hello,

Upstream has changed the license metadata for testit from 'GPL' to
'GPL-3', resulting in the consequential change of the Fedora package
license from GPLv2+ to GPLv3.

-- 
Elliott
___
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: The Official Complaint Thread

[Miro Hrončok]

On 13. 11. 19 6:17, Aleksandar Kurtakov wrote:



On Wed, Nov 13, 2019 at 3:17 AM Kevin Kofler > wrote:


Aleksandar Kurtakov wrote:
 > So people would prefer no packages at all over packages in modules?

I see 2 reasons so far why some packages are module-only:
1. because a dependency of the package is module-only. That is exactly what
    we want to prevent by proposing a ban on module-only packages.
2. because the maintainer wants to maintain only one version and chose the
    modular one. Banning module-only packages will hopefully get the
    maintainer to either maintain the non-modular version instead or to
    maintain both versions after all.


Here you seem to be missing the third option packager may choose - maintain none 
of them and say bye to Fedora. Which IMHO is the most likely outcome of all this.


It is certainly a valid case.

However, using the same logic, doing the module-only thing might have driven 
other maintainers away as well. Already.


In my opinion, we better ban default modular streams sooner, when the number of 
maintainers who are affected is low. And we must be very very careful to explain 
ourselves to them. To apologies to them. To coordinate with them. To make them 
feel like they are part of this project. We would not be doing this because we 
don't want them. We should be doing this, because retrospectively, going to 
modular-only was not a good decision. Something that might not be clear to them 
at the beginning, when all the messaging was about how modularity is good and 
when the voices of naysayers were drown out by the cheering for the new thing.


We are in an unfortunate situation. And we may activate a contingency plan that 
is indeed not ideal for everybody. Or we may choose to ignore this and continue 
to make the situation worse. Every step forward we take makes the contingency 
more painful in the future.


I'm so sorry.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a
écrit :
> 
> Fedora modules are an horrifically complex way to pretend those basic
> three constrains  do not exist, while actually implementing them
> (except in a broken non-working way, because the *pretence* is that
> the constrains do not exist).

And anyway, if anyone feels the module design is actually needed (I
don’t, because the problems are elsewhere), it could have been *easily*
implemented within existing tools, without adding new infra to the mix,
just with

1. packages contained in modulename are named -usual-name

2.  packages contained in modulename should include in their spec

%global module modulename 

3. in-module (Build)deps are declared with

(Build)Requires: (usual-depname with module(modulename))

and then you add some rather trivial logic in rpm to provide
module(modulename)
when the module variable is declared, and to inhibit
auto(Build)Requires for foo
when the same is already present as
(Build)Requires (foo module(modulename))

There are *no* drawbacks, except forcing packagers to be explicit about
modules, to think about what they want to take in a module and what
they want to take elsewhere, to think about conflicts.

Not thinking about all those parts is why current Fedora modules do not
play well with one another or with the rest of the distribution. The
module system can not invent info packagers didn't provide explicitely.

But no, people wanted to play with a NiH start-from-scratch design.

Regards,

-- 
Nicolas Mailhot
___
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: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mercredi 13 novembre 2019 à 06:43 +0100, Nicolas Mailhot via devel a
écrit :
> 
> The native Go component format (also, confusingly, named
> module) handles those 3 constrains and won't present any core
> difficulty in rpm packaging once it is finished upstream.

And, BTW, we added auto-builderequires in rpm 4.15 so you can automate
the mapping between well-behaved language component systems and rpm,
and individual packagers do not have to care about this mapping in each
and every package, when upstream has already made the effort to manage
its component versionning.

It effectively gives us the same capabilities as modules in rpm proper,
in a working reliable way, without all the tech complexity invented
module-side.

-- 
Nicolas Mailhot
___
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: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mercredi 13 novembre 2019 à 00:19 +0200, Aleksandar Kurtakov a
écrit :
> 
> 
> On Wed, Nov 13, 2019 at 12:02 AM John M. Harris Jr <
> joh...@splentity.com> wrote:
> > On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova
> > wrote:
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > 
> > This is not actually the case. We have several major packages which
> > are ONLY 
> > available as modules, for example.
> 
> So people would prefer no packages at all over packages in modules? I
> ask this as the traditional rpm way of doing is simply not working
> and that's the reason why many of us (old time Java packagers) just
> gave up, it's purely impossible to satisfy the needs of multiple
> "major" packages with same set of dependencies. This is not Java
> problem only for sure - look at Rust, Go, etc. 

Having spend a lot of time Go-side this past year, there is *no* way in
which traditional rpm packaging limits us.

Traditional rpm packaging has always permitted packaging as many
component versions as was needed.

It *does* require that an ecosystem that can not settle down on a
single component version, actually tracks what version each build uses.

It *does* require defining an upgrade path once multiple versions are
allowed to exist.

It *does* require that multiple versions, expected to exist
simultaneously on the filesystem, use different file paths (and thus
requires defining those paths to be sure they do not collide).

All of those are inescapable consequences of multi-versionning and
parallel install.

The native Go component format (also, confusingly, named
module) handles those 3 constrains and won't present any core
difficulty in rpm packaging once it is finished upstream.

Fedora modules are an horrifically complex way to pretend those basic
three constrains  do not exist, while actually implementing them
(except in a broken non-working way, because the *pretence* is that the
constrains do not exist).

And, having spent a lot of time packaging Java software 20 years ago, I
can tell you that the Java language is no different from Go.

*However* the Java ecosystem has spent a lot of time and energy,
refusing to ackowledge it needs to track component versions, refusing
to ackowledge  it needs to define upgrade paths, refusing to
ackowledge it needs to define version-specific file paths.

*That* is your core problem, not packaging tech (rpm, module, maven
osgi, or anything else).

The reason you’re attracted to modules is that on *short* deployment
time windows, you can pretend the constrains do not exist, and just use
whatever component version is available. That is why ignoring the
constrains works dev-side – everything is ephemeral, nothing is
supposed to survive long after a dev build., nothing is shared with
other builds. And modules allowed you to get rid of the past, ie reduce
the time window, for a short while.

The reason the result fell over, in rpm, and in modules, is that on
*long* distro-scale deployment time windows, you can *not* ignore those
constrains.

Anything you do in modules, containers, or whatever, without taking the
long-term versioning constrains into account, will only work for a
short period of time.

Unicorns do not exist in real life.

Regards,

-- 
Nicolas Mailhot
___
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: The Official Complaint Thread

[Aleksandar Kurtakov]

On Wed, Nov 13, 2019 at 3:17 AM Kevin Kofler  wrote:

> Aleksandar Kurtakov wrote:
> > So people would prefer no packages at all over packages in modules?
>
> I see 2 reasons so far why some packages are module-only:
> 1. because a dependency of the package is module-only. That is exactly what
>we want to prevent by proposing a ban on module-only packages.
> 2. because the maintainer wants to maintain only one version and chose the
>modular one. Banning module-only packages will hopefully get the
>maintainer to either maintain the non-modular version instead or to
>maintain both versions after all.
>

Here you seem to be missing the third option packager may choose - maintain
none of them and say bye to Fedora. Which IMHO is the most likely outcome
of all this.


>
> > I ask this as the traditional rpm way of doing is simply not working and
> > that's the reason why many of us (old time Java packagers) just gave up,
> > it's purely impossible to satisfy the needs of multiple "major" packages
> > with same set of dependencies.
>
> It is very much possible, just ship parallel-installable compatibility
> packages. For Java JARs, you can simply ship the non-default versions as
> name-version.jar (which is actually how most upstreams ship their binaries
> as well) rather than just name.jar, then they won't conflict. (Of course,
> the package name has to be suffixed with the version as well, as for all
> compatibility packages.)
>
> Using modules for that purpose is broken by design because you are just
> pushing the problem from the packager to the end user, who will not be
> able
> to install the 2 unrelated packages on the same machine due to conflicting
> dependencies.
>
> Kevin Kofler
> ___
> 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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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

[Bug 1770717] Upgrade perl-Module-Load-Conditional to 0.70

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1770717



--- Comment #8 from Fedora Update System  ---
perl-Module-Load-Conditional-0.70-1.fc31 has been pushed to the Fedora 31
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-5ab1f07403

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1770718] Upgrade perl-Net-DAVTalk to 0.17

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1770718



--- Comment #7 from Fedora Update System  ---
perl-Net-DAVTalk-0.17-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-e57eb4c32c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1770716] Upgrade perl-Module-CoreList to 5.20191110

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1770716



--- Comment #7 from Fedora Update System  ---
perl-Module-CoreList-5.20191110-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-c32aff9ca1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[389-devel] 389 DS nightly 2019-11-13 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/11/13/report-389-ds-base-1.4.2.3-20191113git2b8750d.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:
> Modular builds have metadata that can indicate to consumers which
> subpackages in this module should be considered "API". If a module
> produces a package artifact and does not list it thusly, it is meant
> to be treated as an internal implementation detail of the module (and
> that the maintainer is not committing to maintaining that particular
> package for any purpose other than supporting the API content of this
> module).
> 
> We also have "filters" which are intended for allowing module
> packagers to build and use build-time-only packages. They are built
> and added to the module buildroot as part of the build process, but
> they are filtered out so they don't end up in the final composed
> repository. (This is useful if, for example, your package used a small
> subset of some other package only at build-time and you don't want to
> have to maintain that package for everyone in the distro just to build
> yours).

Both of these should be equally disallowed by policy in Fedora (and in ALL 
module streams, not just in default streams). Filtering packages is even 
worse than declaring them non-API. It even interferes with installing non-
modular versions of the filtered packages (reportedly a common issue on 
RHEL). And it is just an anti-social thing to do and against the goals of 
Fedora (it conflicts with at least the following ideals that I would have 
believed we all share: transparency, cooperation rather than duplication, 
self-hosting). If your build-time dependency does not logically belong into 
your module, then you should get it into Fedora proper and ask for 
comaintainers, not take it private by filtering it from your module.

Kevin Kofler
___
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: The Official Complaint Thread

[Kevin Kofler]

Aleksandar Kurtakov wrote:
> So people would prefer no packages at all over packages in modules?

I see 2 reasons so far why some packages are module-only:
1. because a dependency of the package is module-only. That is exactly what
   we want to prevent by proposing a ban on module-only packages.
2. because the maintainer wants to maintain only one version and chose the
   modular one. Banning module-only packages will hopefully get the
   maintainer to either maintain the non-modular version instead or to
   maintain both versions after all.

> I ask this as the traditional rpm way of doing is simply not working and
> that's the reason why many of us (old time Java packagers) just gave up,
> it's purely impossible to satisfy the needs of multiple "major" packages
> with same set of dependencies.

It is very much possible, just ship parallel-installable compatibility 
packages. For Java JARs, you can simply ship the non-default versions as
name-version.jar (which is actually how most upstreams ship their binaries 
as well) rather than just name.jar, then they won't conflict. (Of course, 
the package name has to be suffixed with the version as well, as for all 
compatibility packages.)

Using modules for that purpose is broken by design because you are just 
pushing the problem from the packager to the end user, who will not be able 
to install the 2 unrelated packages on the same machine due to conflicting 
dependencies.

Kevin Kofler
___
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: dnf unable to download source due to rpmfusion-free-source

[James Cassell]

On Tue, Nov 12, 2019, at 7:50 PM, Adam Williamson wrote:
> On Mon, 2019-11-11 at 12:07 +0100, Kevin Kofler wrote:
> > Samuel Sieb wrote:
> > 
> > > On 11/10/19 1:52 PM, Neal Becker wrote:
> > > > Well it does work if you do
> > > > 
> > > > dnf --disablerepo=rpmfusion-free,rpmfusion-nonfree download --
> > > > enablerepo=rawhide --source mercurial
> > > > 
> > > > But that is not exactly obvious, so I think it's something dnf could
> > > > handle better (I hesitate to call it a bug).
> > > 
> > > Wow, that is very non-obvious.
> > 
> > How is it non-obvious? --source enables the source repositories 
> > corresponding to the binary repositories you have enabled, so if you don't 
> > want it to enable rpmfusion-free-source, you have to disable the
> > rpmfusion-free (not rpmfusion-free-source) repository. Sounds quite obvious 
> > to me.
> 
> But the user's intent is clear and the code almost certainly *could*
> interpret it, it just doesn't right now. All it has to do is (re-
> )consider the repo(s) that were disabled via user config *after* the
> "infer the source repos to enable from the enabled binary repos" flow
> has happened. I'd call it a bug, or at least a reasonable feature
> request.

I agree it's s feature request. It's a case of "I recognize the correct answer 
when it's shown to me"... after seeing this thread, it's obvious that/why/how 
it works, but I wouldn't have necessarily thought of it myself.

V/r,
James Cassell
___
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: The Official Complaint Thread

[Kevin Kofler]

Aleksandar Kurtakov wrote:
> The way Eclipse is treated makes me really sad and kind of regret the time
> spent on Fedora over the years! Being forced to be a module but blocked to
> be default stream by FESCo arguing over whether it wants modularity
> (sorry, this is how it looks) is the best way for Fedora to show to
> project and people they are not wanted in the community!

You should not blame the people arguing over whether more and more default 
streams are a good thing for your trouble, but the people who caused your 
trouble to begin with by modularizing the Java stack.

Java needs to be demodularized. Completely. As a platform (i.e., a 
programming language and/or a set of libraries, Java is both), it is 
absolutely not suited for modules, because they are version conflicts 
waiting to happen. Platforms need to be treated the traditional way, 
shipping one system version, and if that is not enough, parallel-installable 
compatibility packages in addition.

The lack of parallel installability makes modules only suitable for leaf 
packages.

Kevin Kofler
___
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: dnf unable to download source due to rpmfusion-free-source

[Adam Williamson]

On Mon, 2019-11-11 at 12:07 +0100, Kevin Kofler wrote:
> Samuel Sieb wrote:
> 
> > On 11/10/19 1:52 PM, Neal Becker wrote:
> > > Well it does work if you do
> > > 
> > > dnf --disablerepo=rpmfusion-free,rpmfusion-nonfree download --
> > > enablerepo=rawhide --source mercurial
> > > 
> > > But that is not exactly obvious, so I think it's something dnf could
> > > handle better (I hesitate to call it a bug).
> > 
> > Wow, that is very non-obvious.
> 
> How is it non-obvious? --source enables the source repositories 
> corresponding to the binary repositories you have enabled, so if you don't 
> want it to enable rpmfusion-free-source, you have to disable the
> rpmfusion-free (not rpmfusion-free-source) repository. Sounds quite obvious 
> to me.

But the user's intent is clear and the code almost certainly *could*
interpret it, it just doesn't right now. All it has to do is (re-
)consider the repo(s) that were disabled via user config *after* the
"infer the source repos to enable from the enabled binary repos" flow
has happened. I'd call it a bug, or at least a reasonable feature
request.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: The Official Complaint Thread

[Kevin Kofler]

Stephen Gallagher wrote:

> On Tue, Nov 12, 2019 at 12:31 PM Aleksandra Fedorova 
> wrote:
>> Ursa Prime effort achieves the same goal. It removes the "viral" part
>> of Modularity I think.
> 
> That is absolutely its purpose. If we fall short of that, it's a bug
> and we will fix it as soon as possible.

Unfortunately, Ursa Prime is a build-time-only workaround and does not help 
end users at all.

>> Again I fail to see the _technical_ difference between the ursine rpm
>> package and a package which was built as a part of default stream. It
>> is the same rpm spec from the same dist-git sources, which is built by
>> the same rpmbuild command. Thus I think it is a process/policy
>> difference, which we should resolve.
> 
> I'll acknowledge that there may be subtle differences (such as the
> different "release" tag), but none (offhand) that should have a
> meaningful impact as long as other policy is in place.

There are major technical differences in how DNF processes the package 
(which is technically mostly related to repository metadata rather than to 
the RPM itself, which is indeed not all that different, but that changes 
nothing for the end user), when it comes to choice of preferred version, 
upgrade paths, etc. And the behavior for ursine repositories is much more 
user-friendly than the one for modules (where the default stream trumps even 
local packages, ignoring the EVR entirely, where the upgrade path from 
release to release is still an unsolved problem, where you can only choose a 
version to upgrade or downgrade to for the entire module vs. individual 
packages, where a module can hard-require a version of the entire 
distribution, forcing its removal when you upgrade Fedora, independently of 
the actual package-level dependencies, etc.).

If you were to implement something like Ursa Prime for the end user repos 
and enable the resulting non-modular repository by default instead of 
fedora-modular (i.e., Miro's alternate proposal), I would probably complain 
a lot less about Modularity. But as it stands, I support Miro's preferred 
proposal, i.e., to simply stop using default streams, which I think gives us 
essentially the same effect with much less efrort.

Kevin Kofler
___
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: The Official Complaint Thread

[Kevin Kofler]

Igor Gnatenko wrote:
> You say we need to improve tooling and iterate fast, fine. But why then
> https://pagure.io/releng/issue/7662 is still not implemented? I understand
> that it is opensource And everyone can contribute, but the fact is that
> people who work on Modularity tooling is entirely paid by RH and those
> people are "responsible" to bring it to Fedora and make it work. However,
> as written in the ticket "it is not a priority for that team".

Building a module on Fedora n and shipping it on Fedora m (where n≠m) is 
something that should not be allowed to begin with. We don't do that for 
normal packages for a reason.

Kevin Kofler
___
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: The Official Complaint Thread

[Kevin Kofler]

Aleksandra Fedorova wrote:
> 1) I don't think Modularity is about being LTS and "enterprisy".
> Lifecycle differences are not the only feature Modularity provides.
> 
> I see Modularity as a tool which bridges the gap between container
> world and a packaged distribution.
> 
> Without modularity we have a base system with its limitations and the
> explosion of containerized solutions which currently go through their
> teen-age phase, denying the good old known practices and reinventing
> wheels in terms of packaging, sharing, deduplication of effort and
> security audit.

This is not a property of not using modularity, but of using containers. 
Generating containers from modular repositories also only partly solves 
these issues. In particular, you still have to regenerate the entire 
container for a security fix in any included library.

The best approach to avoid the drawbacks of containers is not to start using 
modules, but to stop using containers. :-)

In addition, due to their non-parallel-installable nature, modules actually 
push more container use, and thus more duplication, more complex security 
updates, etc. So I think they actually have the opposite effect than what 
you claim.

> Modularity allows us to use packaging approaches in a more flexible
> but still controlled and maintained way. It creates building blocks
> for containerized environments.
> I think it is the way to go for Flatpacks, cloud images and other
> layered solutions to use runtimes built on top of packaged streams,
> rather than custom configurations.

I also don't see why the containers cannot simply be built from a common 
tested platform (a non-modular Fedora release) rather than from arbitrarily 
mixed together streams. If your goal is sharing and deduplication of 
efforts, then that should actually be the goal. Adding module streams to the 
mix actually goes the opposite way.

> And I think it is in scope of Fedora to drive this process to
> normalize the currently chaotic container world.

I think Fedora would be better off avoiding the container world altogether. 
It is a horribly inefficient way to deliver software compared to RPM 
packages.

> 2) I don't think Modularity is a failure in its current state.
> 
> Yes, we do have a problem of default streams. There are several
> reasons for that.
> 
> One thing i find interesting is that: we were very cautious on tech
> implementation side, delaying certain technical tools and solutions,
> while we were not cautious enough on the process and policy.
> And it feels like we should have done it the opposite way: iterate
> (and sometimes fail) on the tooling faster, but have a much more
> restrictive approach to the policy.

Well yes, allowing people to abuse stable Fedora releases as a place on 
which to experiment with modules was a huge mistake. Those experiments 
should have been done in an optional opt-in repository. (And I would even 
argue that modules should always remain optional and opt-in, but in their 
current state, that is most definitely the case.)

> And now we are trying to evaluate Modularity without actually giving
> it a chance to be implemented _for real_.

That is the part I disagree with. Already too much was implemented in 
production releases. We are seeing exactly the failure modes that I had 
already warned about right after reading the design documents.

> Anyway, default streams is just one side of a story. It did get into
> the critical path of Fedora and did create upgrade problems and
> certain UX issues, but I think we can restrict and resolve it.

And what is wrong with the obvious solution, which is to just not use 
default streams at all? Why can the default version not be shipped in the 
tried and true non-modular way, so that people who do not need or want 
modules are not forced to use them against their will?

> For that we need to focus on the issue, which is, from my point of
> view: default streams and their differences from the ursine packages.
> 
> One is caused by the lack of Ursa Prime, another is the upgrade
> functionality,

And both are complex technical mechanisms, which will certainly come with 
their own bugs and drawbacks, all just to emulate a world without default 
streams while shipping default streams. I see no practical benefits 
whatsoever of that approach over the straightforward KISS approach of just 
not using default streams anymore.

> and I guess the third one is the non-api and filtered packages in the
> module.

That one is something that just needs to be banned in Fedora altogether.

Kevin Kofler
___
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: 

[Bug 1771739] [RFE] EPEL8 branch of perl-Test-Time

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771739

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-dec8d5ca8e has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dec8d5ca8e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[John M. Harris Jr]

On Tuesday, November 12, 2019 4:21:03 PM MST Kevin Kofler wrote:
> But the wasted space will be even more, because now you have libpython, the
>  dynamic python3 linked against it, AND the python3-static binary. So it
> does not address the issue at all.

Yes, that would be the case if something in one of the installer images used 
that python3-static package, which I admittedly did not consider.

-- 
John M. Harris, Jr.
Splentity

___
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: thunderbird-enigmail: help needed to restrict available architectures

[Kevin Kofler]

Felix Schwarz wrote:
> Currently I have these lines in thunderbird-enigmail's .spec file:
> ,-
> BuildArch:  noarch
> # Thunderbird is not available on all supported platforms
> ExcludeArch: armv7hl
> ExcludeArch: s390x
> `-

That should be good.

But the thing is, ExcludeArch on top of BuildArch: noarch is a bit of a 
hack, it is not really processed by RPM, but only by the tooling on top of 
it (e.g., Koji will not use those architectures to build the RPM, and the 
tools that compose the repositories will not include the RPM on the excluded 
architectures). It looks like Taskotron does not know about this, so this 
needs to be fixed in Taskotron. (Taskotron needs to also do this ExcludeArch 
processing. This has to be done in Taskotron, RPM cannot do more than 
propagate the information from the specfile into the noarch package.)

Kevin Kofler
___
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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Kevin Kofler]

John M. Harris Jr wrote:
> However, I believe there's a third option here. It could be as simple as
> providing a python3-static in addition, and NOT using `alternatives`. This
> way, packages and scripts that actually need the performance improvements
> can directly call python3-static, and everything else just continues to
> work as it does now.

But the wasted space will be even more, because now you have libpython, the 
dynamic python3 linked against it, AND the python3-static binary. So it does 
not address the issue at all.

Kevin Kofler
___
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: The Official Complaint Thread

[Nico Kadel-Garcia]

You mean like quota-devel?

Sent from my iPhone

> On Nov 12, 2019, at 4:14 PM, Dominik 'Rathann' Mierzejewski 
>  wrote:
> 
> On Tuesday, 12 November 2019 at 22:07, Stephen Gallagher wrote:
>>> On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
>>>  wrote:
>>> 
 On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
>>> [...]
 I agree with Aleksandra here. And we *did* establish that our policy
 going forward is that we will forbid any default stream from providing
 non-API content. (Filtered out packages are orthogonal to this.)
>>> 
>>> What does that even mean?
>>> 
>> 
>> Modular builds have metadata that can indicate to consumers which
>> subpackages in this module should be considered "API". If a module
>> produces a package artifact and does not list it thusly, it is meant
>> to be treated as an internal implementation detail of the module (and
>> that the maintainer is not committing to maintaining that particular
>> package for any purpose other than supporting the API content of this
>> module).
>> 
>> We also have "filters" which are intended for allowing module
>> packagers to build and use build-time-only packages. They are built
>> and added to the module buildroot as part of the build process, but
>> they are filtered out so they don't end up in the final composed
>> repository. (This is useful if, for example, your package used a small
>> subset of some other package only at build-time and you don't want to
>> have to maintain that package for everyone in the distro just to build
>> yours).
> 
> OK. Let's say one of those is a static library that doesn't get exposed
> in the final composed repository. Suppose there's a security bug in that
> exact version but that bug doesn't occur in the traditionally-maintained
> package in Fedora (perhaps because the vulnerable version was skipped).
> How do you detect that and know which packages (modules?) need to be
> rebuilt?
> 
> Regards,
> Dominik
> -- 
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
>-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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
___
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: The Official Complaint Thread

[Lukas Ruzicka]

Again, no one forces you or any other packager to use modularity
> tooling right now.
>
> As Fedora developer you have a choice to join the effort, bring your
> input and use cases, try and test (and revert if it doesn't work) or
> you can stay away from it and keep using same tools as before.
>

Well, noone forces you *right now. *That is an important thing to notice.
Someone will force you to use it later.
And, by the way, some people were forced to use it, because they installed
an application whose dependencies were
modularized, so they were force onto modularity without wishing for it.

I, personally, do not have anything against modularity except that *it is
forced upon us. *
My preference is that anybody could choose whether they want to go modular
or stay ursine -
do I really want that much, when I want that Fedora is for everybody?


FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Miro Hrončok]

On 12. 11. 19 23:21, John M. Harris Jr wrote:

If that software was to be packaged, in this case, you'd simply:
Requires: python3

change the shebang to /path/to/my/python3


I am strongly against any proposals that involve /path/to/my/python3.


However, I believe there's a third option here. It could be as simple as
providing a python3-static in addition, and NOT using `alternatives`. This
way, packages and scripts that actually need the performance improvements can
directly call python3-static, and everything else just continues to work as it
does now.


The idea here was to speed up Python for the benefit of the entire distro, not 
for those who choose to use it.


If a software is written in python and the maintaioners want to speed it up, 
there are more explicit actions they can take.


We don't want to invest our energy into this for the couple packages that will 
opt in. We want to invest our energy into making all Fedora software that 
happens to run on Python be generally faster.


And it is completely understandable that some trade-offs are OK for somebody and 
not OK for somebody else. We are reading this thread and I will urge FESCo to 
pay special attention to the negative responses.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[Kevin Kofler]

David Timms wrote:
> And this usage can be the impetus that allows library development to be
> well tested by multiple real applications and issues
> known/fixes/improvements in place before the library hardens it's
> ABI/API interfaces at the release.

But why would you want to abuse renowned applications such as Audacity in 
stable releases of Fedora for that purpose?

Feel free to ship wxGTK 3.1 and an Audacity built against it in a Copr, for 
people deliberately opting in to testing such a build. But please do not 
force it onto users of stable releases, who have not opted in to becoming 
beta testers.

> In this case extending this idea to also make other Fedora packaged,
> wxGTK3 using applications [1] built with the (hopefully soon) to be
> released library would allow more thorough testing of the library, and
> give us ahead of time the things that need work - in either the library
> or the applications.

Sure, but that is what Copr is for. Please put up a wxGTK 3.1 Copr and start 
rebuilding applications against it there (if rebuilding is actually needed).

> Given it would be me doing the work - although I'll need some guidance -
> are any guidelines etc. actually being broken if I was to do the
> modularity thing for wxGTK/Audacity ?

Not sure, but what is sure is that it would make your build of Audacity much 
less useful compared to using the stable wxGTK that ships in stable Fedora 
and to which all other wxGTK applications are linked by default.

Kevin Kofler
___
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: The Official Complaint Thread

[Miro Hrončok]

On 12. 11. 19 18:25, Aleksandra Fedorova wrote:

On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:


On 12. 11. 19 17:02, Aleksandra Fedorova wrote:

Again, no one forces you or any other packager to use modularity
tooling right now.

As Fedora developer you have a choice to join the effort, bring your
input and use cases, try and test (and revert if it doesn't work) or
you can stay away from it and keep using same tools as before.



Unfortunately, this is not true. It is not possible to ignore modularity, if the
dependencies are modularized. It is not possible to ignore modularity, if the
dependents are modularized. It is not possible to ignore modularity, if the
packages I wish to use are modularized.

I wish Fedora packagers and users cold "stay away". But that is currently not
possible. My proposal to keep all defaults as non-modular packages would make it
exactly so.


Ursa Prime effort achieves the same goal. It removes the "viral" part
of Modularity I think.


Ursa Prime effort puts module sin the buildroot. I'm still waiting to hear about 
how it deals with conflicts with non-modular packages, how it works with mock 
and what it actually does.


Not getting those answers was one of the many reasons I voted against the change 
proposal. Yet every time I point out my reasons, people seem to only see the one 
that says I think we should not have default streams at all. And I kinda get 
that, but the other reasons are equally important.


Before I get the answers, I cannot agree or disagree with you, because I don't 
know what it achieves or not.


However, and I speculate here, IMHO it only gives me the ability to buildrequire 
a modular (meeting certain criteria) package from a non-modular package. It 
doesn't give me a "stay away" card. I still need to deal with modules if my 
package depends on them or if they depend on my package.


As an example, if I choose to depend on module and the modular maintainer 
chooses not to care about the module,  it gets broken or insecure and I have no 
way to fix it other than learning how to do modules.


As an example, I've asked months ago what should I do with modules when we do 
mass Python 3.8 rebuilds. The answer was... it's complicated. (I can search the 
devel list if you want details.)


As an example, if I want to see what requires python2 on rawhide, I don't see 
any modules there (this was couple months ago, the situation may have changed 
now but will repeat when f32 branches).


So, no, I don't believe Ursa Prime achieves the goal. But I might just be not 
informed well, because the Ursa Prime change proposal is not informational 
enough in this regard. In that case, sorry for spreading panic.



As well as policy which restricts the set of default modules, which I
think we need to change from "FESCo approves new default modules" to
"each request for new default module should be treated as a
System-Wide Change".


And I think it needs to change to: no default modular streams.
Yes, once all the concerns that I and our community members I choose to 
represent have are settled, we can revisit this. But that doesn't mean we should 
explicitly treat it as a temporary policy.



Again I fail to see the _technical_ difference between the ursine rpm
package and a package which was built as a part of default stream.


The _technical_ difference is that it's built differently, from a different 
place, in a different way, with different rules. And if we "fix" that, we no 
longer have default modular streams.


To clarify: Another _technical_ difference are broken upgrades, but that can be 
fixed, so I treat that behavior as a bug and will not use it as an argument. 
However, if it is proven that we are not able to fix it, it may become an 
argument as well.



It
is the same rpm spec from the same dist-git sources, which is built by
the same rpmbuild command.


It is some kind of spec file, build from some arbitrary dist-git branch built by 
the same rpmbuild command in an alien environment.



Thus I think it is a process/policy
difference, which we should resolve.


It is. And you know what I think the policy should be. No default modular 
streams.


And I will support a hard block on creating new default streams, until
it is resolved.


We don't agree on what "is resolved" means here.


(With the exception of eclipse probably, which is in a broken state
already, and for which we need to find a solution.)


As a hypothetical example, if we grant eclipse an exception based on the fact 
that it is broken and eclipse gets a modular default stream and another software 
is broken by the same way eclipse was broken because of that, do we give it an 
exception as well? And another? And another?


As a second (even more) hypothetical example, if a maintainer decides they 
really really want their default modular stream, could they just choose to not 
solve all the FTBFS bugzillas and orphan their packages and ask for default 
modular stream based on the fact 

[Bug 1771746] [RFE] EPEL8 branch of perl-Test-Name-FromLine

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771746

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-4721096129 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4721096129

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Bodhi Outage Ongoing - Deploying 5.0

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 12, 2019 at 05:28:23PM +0100, Remi Collet wrote:
> Le 12/11/2019 à 10:45, Clement Verna a écrit :
> > We will be upgrading bodhi to its 5.0 release. This release comes in with
> > few UI changes but also task scheduling system (rabbitmq/celery based)
> > allowing to offload some of the tasks currently performed in the front-end
> > to distributed workers. This should results in the users experiencing a
> > faster bodhi in some requests.
> 
> Sorry, but IMHO looks much slower
> 
> Especially the "builds" input which REQUIRES another damned javascript
> query...

Seems to work nicely here. I think the new UI might require some getting
used to, and possibly some adjustments like with the radio buttons, but
in general it seems to be much more useful.

Zbyszek
___
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: The Official Complaint Thread

[Zbigniew Jędrzejewski-Szmek]

> On Tue, Nov 12, 2019 at 10:26 AM Igor Gnatenko
>  wrote:
> > You say we need to improve tooling and iterate fast, fine. But why then
> > https://pagure.io/releng/issue/7662 is still not implemented?

On Tue, Nov 12, 2019 at 03:15:06PM -0500, Stephen Gallagher wrote:
> To be clear, the team that rejected that was the Bodhi team, not the
> Modularity team. We do need to re-examine that; it just kind of fell
> off the radar due to higher-priority issues.

Actually, I think it is OK that this is not implemented, at least when
we're discussing producing packages *in and for Fedora*. While it is might seem
attractive to have "build-once-install-everywhere" packages, I think it
an important part of our process that we build packages for each release
separately, even if they have the same sources and they even might
happen to be binary identical. Rust packages are special in this regard
because of the very tight ecosystem, for most other packages we do want
to rebuild them for each release.

If we turn to the bigger picture and look at externally produced packages,
build-once-run-everywhere is more useful. But still, I think copr-like
send-once-build-everywhere mode is better. If it can be combined with
automatic rebuilds when new releases of Fedora come into being (not
sure if copr implements that today), and a bit of tooling around that,
that would give the best of both worlds: freshly built packages with the
latest toolchain, with no extra work from the packagers (as long as the
packages do build everywhere).

Zbyszek
___
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: The Official Complaint Thread

[John M. Harris Jr]

On Tuesday, November 12, 2019 3:19:59 PM MST Aleksandar Kurtakov wrote:
> So people would prefer no packages at all over packages in modules? I ask
> this as the traditional rpm way of doing is simply not working and that's
> the reason why many of us (old time Java packagers) just gave up, it's
> purely impossible to satisfy the needs of multiple "major" packages with
> same set of dependencies. This is not Java problem only for sure - look at
> Rust, Go, etc. I would being proved wrong but modularity at least gives an
> option for RPMs to continue to be viable option. With all it's weirdness so
> far no one gave better solution working to that extend at least.

I'm sorry, but I don't know the exact issue you're describing here. I'd be 
glad to give a go at solving this particular issue, using traditional RPMs 
alone.

-- 
John M. Harris, Jr.
Splentity

___
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 and all the things

[John M. Harris Jr]

On Tuesday, November 12, 2019 7:24:16 AM MST Matthew Miller wrote:
> We have a big company _investment_, but I don't think it's a divide.
> That's the one I live in. 

This is clearly not the case, though I understand why, as the FPL, you would 
want to say such a thing.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[John M. Harris Jr]

On Tuesday, November 12, 2019 6:18:00 AM MST Miro Hrončok wrote:
> On 12. 11. 19 14:00, Miroslav Suchý wrote:
> 
> > Dne 05. 11. 19 v 16:03 Ben Cotton napsal(a):
> > 
> >> == Summary ==
> >> Python 3 traditionally in Fedora was built with a shared library
> >> libpython3.?.so and the final binary was dynamically linked against
> >> that shared library. This change is about creating the static library
> >> and linking the final python3 binary against it, as it provides
> >> significant performance improvement, up to 27% depending on the
> >> workload. The static library will not be shipped. The shared library
> >> will continue to exist in a separate subpackage. In essence, python3
> >> will no longer depend on libpython.
> > 
> > 
> > It seems that we have one group of people who prefer speed and another
> > group of  people who prefer saved space.
> > 
> > Instead of focusing on a swiss-knife to satisfy everybody (which will not
> > work),  can we have python3-static **and** python3-dynamic (*) packages
> > and let users decide which one will be installed and handle
> > `/usr/bin/python3` using `alternatives(8)`?
> > Then FESCO can "only" decide which one will be the default. And that is
> > far less  controversial than deciding whether you will be forced to use
> > a time-saving or space-saving solution.
> 
> 
> While I realize that this might actually be a clever thing to do, as the
> Python  maintainer, I don't want this for various reasons. Most
> importantly, it means we need to to "support" twice that many Python
> interpreters.
> 
> It would also create a problem in RPM requirements.
> 
> Suppose a package need /usr/bin/python3.8 to be dynamically linked. How do I
>  express that? It would need to harcode some kind of
> /usr/libexec/python3.8-dynamic? Would this require custom shebangs... etc.?
> I  really don't want to go that way. It's bad on RHEL 8 already, with
> "platform-python".
> 
> Note that this is my personal opinion, not a team opinion.
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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

If that software was to be packaged, in this case, you'd simply:
Requires: python3

change the shebang to /path/to/my/python3

However, I believe there's a third option here. It could be as simple as 
providing a python3-static in addition, and NOT using `alternatives`. This 
way, packages and scripts that actually need the performance improvements can 
directly call python3-static, and everything else just continues to work as it 
does now.

-- 
John M. Harris, Jr.
Splentity

___
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: The Official Complaint Thread

[Aleksandar Kurtakov]

On Wed, Nov 13, 2019 at 12:02 AM John M. Harris Jr 
wrote:

> On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova wrote:
> > Again, no one forces you or any other packager to use modularity
> > tooling right now.
>
> This is not actually the case. We have several major packages which are
> ONLY
> available as modules, for example.
>

So people would prefer no packages at all over packages in modules? I ask
this as the traditional rpm way of doing is simply not working and that's
the reason why many of us (old time Java packagers) just gave up, it's
purely impossible to satisfy the needs of multiple "major" packages with
same set of dependencies. This is not Java problem only for sure - look at
Rust, Go, etc. I would being proved wrong but modularity at least gives an
option for RPMs to continue to be viable option. With all it's weirdness so
far no one gave better solution working to that extend at least.


>
> --
> John M. Harris, Jr.
> Splentity
>
> ___
> 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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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: thunderbird-enigmail: help needed to restrict available architectures

[Felix Schwarz]

Am 12.11.19 um 14:49 schrieb Fabio Valentini:

On Tue, Nov 12, 2019 at 1:44 PM Felix Schwarz wrote:


Am 12.11.19 um 13:37 schrieb Fabio Valentini:

There's a specific section about this issue in the Packaging Guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unported_dependencies

So, in your case, I think you'd have to use something like this:
BuildArch: noarch
ExclusiveArch: x86_64 %{ix86} aarch64 ppc64le noarch


I read this paragraph but it also says:
"You can limit both the architectures used to build a noarch package, and the
repositories to which the built noarch package will be added, by using either
the ExcludeArch: or ExclusiveArch: tags:"

English is not my first language but I understood this as if I could use also
"ExcludeArch" (which I did as it matches Thunderbird better).


It's not my first language either ;)

I used ExclusiveArch in my example though, because you don't want to
*exclude* noarch, but *include* it.


I'm sorry but I still don't get it.

Currently I have these lines in thunderbird-enigmail's .spec file:
,-
BuildArch:  noarch
# Thunderbird is not available on all supported platforms
ExcludeArch: armv7hl
ExcludeArch: s390x
`-

To me that means: Package can be built with "noarch" but should not be 
available on "armv7hl"/"s390x".


1) How do I exclude "noarch" here?
2) How is "ExclusiveArch" better?
   Do I really have to list all "other" Fedora architectures (as
   "ExclusiveArch" requires)?

Especially given the text in the packaging guidelines I'd expect that both 
approaches should work.


Felix
___
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: The Official Complaint Thread

[James Cassell]

On Tue, Nov 12, 2019, at 3:35 PM, Stephen Gallagher wrote:
> On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen  
> wrote:
> >
> > On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  
> > wrote:
> > > Again I fail to see the _technical_ difference between the ursine rpm
> > > package and a package which was built as a part of default stream. It
> > > is the same rpm spec from the same dist-git sources, which is built by
> > > the same rpmbuild command. Thus I think it is a process/policy
> > > difference, which we should resolve.
> >
> > Do you view provides/requires/conflicts in an RPM spec and their
> > equivalent in modules to be technical or policy differences. If wrote
> > a policy which says I built X and X-devel but only want to ship X in
> > the module.. is that a policy difference or a technical one?
> 
> The technology allows you to do this. The policy can restrict this. Of
> course, this particular example can be true of a non-modular RPM too;
> you don't *have* to build the X-devel subpackage.
> 
> > If the
> > policy says I can't even install a newer X/X-devel that I built with
> > NEVR because modules always win and it isn't a module.. is that a
> > technical difference or a policy one?
> >
> 
> That would be a technical difference. Your statement, however, is not
> entirely true. You can trivially override it by using RPM instead of
> DNF to update it. Or you can run `createrepo_c` and then add
> `module_hotfix = 1` to the repo file you add to DNF.
> 

I've been following the discussion, and this compels me to jump in.  If you're 
installing things using RPM rather than DNF, you're bypassing the DNF database, 
and that's completely broken in my opinion.  I've been teaching folks that you 
should only ever use YUM/DNF to perform package transactions, except for very 
special cases such as `rpm --setugids` or other very special RPM commands.  I 
also can't (with clear conscience) start teaching folks to run createrepo_c 
just to install an updated RPM.

(Side note: you still can't properly query the DNF database like you can with 
the YUM database; this is still broken from the YUM->DNF transition.)


V/r,
James Cassell
___
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] hitch is broken in epel7, fix in fedora may or may not break production systems (bz #1731420)

[Ingvar Hagelund]

Hello 

hitch is a TLS terminating network proxy, made to be lean and mean and do 
nothing else than terminating TLS. It fits hand-in-glove with varnish cache. I 
maintain hitch in Fedora and EPEL. 

There is a bug in the current epel7 config that is fixed in the latest rawhide 
update. In short, the bug is that with the default config, hitch forks a 
daemon, while the systemd hitch service says Type=simple. See Bugzilla bug 
#1731420. 

The fedora update fixes the problem by changing the systemd service to 
Type=forking. 

There were two ways to get around the bug: 

- Set daemon=off in hitch.conf. That file is marked with noreplace, so the 
update will not overwrite this fix. As this does not match the updated 
Type=forking in hitch.service, hitch will not start after the update. 

- Set Type=forking in hitch.service. This is the same fix as in the update, so 
this should be safe. 

Also, the Fedora update adds a systemd limits.conf including LimitNOFILE=10240 
that is important, as the default value (1024) would trig network problems on a 
medium busy site (true story). 

Is it safe to push this update to epel7? 

Ingvar 

___
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: Modularity: The Official Complaint Thread

[John M. Harris Jr]

On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova wrote:
> Again, no one forces you or any other packager to use modularity
> tooling right now.

This is not actually the case. We have several major packages which are ONLY 
available as modules, for example.

-- 
John M. Harris, Jr.
Splentity

___
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: The Official Complaint Thread

[John M. Harris Jr]

On Tuesday, November 12, 2019 7:49:06 AM MST Vít Ondruch wrote:
> > 1) I don't think Modularity is about being LTS and "enterprisy".
> > Lifecycle differences are not the only feature Modularity provides.
> > 
> > I see Modularity as a tool which bridges the gap between container
> > world and a packaged distribution.
> > 
> > Without modularity we have a base system with its limitations and the
> > explosion of containerized solutions which currently go through their
> > teen-age phase, denying the good old known practices and reinventing
> > wheels in terms of packaging, sharing, deduplication of effort and
> > security audit.

I must disagree. As I see it, Red Hat sees this as a potential solution to 
some perceived issue that their customers have, whether that issue actually 
exists or not.

I honestly have no issue with Modules having a place in Fedora as well, and 
maybe that's actually the best place for them: As an optional repository that 
must be enabled before it can be used, and nothing more.

Perhaps we could:
1) Disallow default modules, require that all defaults must be traditional 
packages.

2) Have modules disabled by default, with the option to enable them if you 
wish, perhaps even transparently by installing package:moduleversion?

-- 
John M. Harris, Jr.
Splentity

___
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

[Bug 1771739] [RFE] EPEL8 branch of perl-Test-Time

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771739

Emmanuel Seyman  changed:

   What|Removed |Added

 Depends On||1771746




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1771746
[Bug 1771746] [RFE] EPEL8 branch of perl-Test-Name-FromLine
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771746] New: [RFE] EPEL8 branch of perl-Test-Name-FromLine

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771746

Bug ID: 1771746
   Summary: [RFE] EPEL8 branch of perl-Test-Name-FromLine
   Product: Fedora
   Version: rawhide
Status: ASSIGNED
 Component: perl-Test-Name-FromLine
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
Blocks: 1771739
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19611
https://pagure.io/releng/fedora-scm-requests/issue/19612


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1771739
[Bug 1771739] [RFE] EPEL8 branch of perl-Test-Time
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1744690



--- Comment #6 from Xavier Bachelot  ---
(In reply to Emmanuel Seyman from comment #5)
> (In reply to Xavier Bachelot from comment #4)
> >
> > Emmanuel, do you want me to file bugs for them ?
> 
> No, I'll do this tonight.

Sorry, I didn't realize the missing deps were all yours.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 4:17 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Tuesday, 12 November 2019 at 22:07, Stephen Gallagher wrote:
> > On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
> >  wrote:
> > >
> > > On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
> > > [...]
> > > > I agree with Aleksandra here. And we *did* establish that our policy
> > > > going forward is that we will forbid any default stream from
> providing
> > > > non-API content. (Filtered out packages are orthogonal to this.)
> > >
> > > What does that even mean?
> > >
> >
> > Modular builds have metadata that can indicate to consumers which
> > subpackages in this module should be considered "API". If a module
> > produces a package artifact and does not list it thusly, it is meant
> > to be treated as an internal implementation detail of the module (and
> > that the maintainer is not committing to maintaining that particular
> > package for any purpose other than supporting the API content of this
> > module).
> >
> > We also have "filters" which are intended for allowing module
> > packagers to build and use build-time-only packages. They are built
> > and added to the module buildroot as part of the build process, but
> > they are filtered out so they don't end up in the final composed
> > repository. (This is useful if, for example, your package used a small
> > subset of some other package only at build-time and you don't want to
> > have to maintain that package for everyone in the distro just to build
> > yours).
>
> OK. Let's say one of those is a static library that doesn't get exposed
> in the final composed repository. Suppose there's a security bug in that
> exact version but that bug doesn't occur in the traditionally-maintained
> package in Fedora (perhaps because the vulnerable version was skipped).
> How do you detect that and know which packages (modules?) need to be
> rebuilt?
>

A few points:

* Static libraries are forbidden by Fedora policy already.

* If you are bundling into one of the produced RPMs, the same “Provides:
bundled(foo)” rule applies as it would for a non-modular RPM.

* The build artifacts are still present in Koji, they just don’t end up in
the final composed repos. So we can always query Koji for the version
corresponding to a module build.
___
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: The Official Complaint Thread

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 12 November 2019 at 22:07, Stephen Gallagher wrote:
> On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
> > [...]
> > > I agree with Aleksandra here. And we *did* establish that our policy
> > > going forward is that we will forbid any default stream from providing
> > > non-API content. (Filtered out packages are orthogonal to this.)
> >
> > What does that even mean?
> >
> 
> Modular builds have metadata that can indicate to consumers which
> subpackages in this module should be considered "API". If a module
> produces a package artifact and does not list it thusly, it is meant
> to be treated as an internal implementation detail of the module (and
> that the maintainer is not committing to maintaining that particular
> package for any purpose other than supporting the API content of this
> module).
> 
> We also have "filters" which are intended for allowing module
> packagers to build and use build-time-only packages. They are built
> and added to the module buildroot as part of the build process, but
> they are filtered out so they don't end up in the final composed
> repository. (This is useful if, for example, your package used a small
> subset of some other package only at build-time and you don't want to
> have to maintain that package for everyone in the distro just to build
> yours).

OK. Let's say one of those is a static library that doesn't get exposed
in the final composed repository. Suppose there's a security bug in that
exact version but that bug doesn't occur in the traditionally-maintained
package in Fedora (perhaps because the vulnerable version was skipped).
How do you detect that and know which packages (modules?) need to be
rebuilt?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: The Official Complaint Thread

[Stephen John Smoogen]

On Tue, 12 Nov 2019 at 15:36, Stephen Gallagher  wrote:
>
> On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen  
> wrote:
> >
> > On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  
> > wrote:
> > > Again I fail to see the _technical_ difference between the ursine rpm
> > > package and a package which was built as a part of default stream. It
> > > is the same rpm spec from the same dist-git sources, which is built by
> > > the same rpmbuild command. Thus I think it is a process/policy
> > > difference, which we should resolve.
> >
> > Do you view provides/requires/conflicts in an RPM spec and their
> > equivalent in modules to be technical or policy differences. If wrote
> > a policy which says I built X and X-devel but only want to ship X in
> > the module.. is that a policy difference or a technical one?
>
> The technology allows you to do this. The policy can restrict this. Of
> course, this particular example can be true of a non-modular RPM too;
> you don't *have* to build the X-devel subpackage.
>

I am asking these questions this way because of 20 years of RPM fights
of people arguing over things because a spec file is a combination of
a policy document and a technical document but people like to treat it
as one or the other in the conversations. Getting it clear when you
are speaking about the technical implementation of policy or the
political implementation of technology up front gets that out of the
way. Not being clear is where people start building their own mind
castles to send armies of strawmen against.

I have 0 interest for or against modularity. It is a technology which
tries to solve a problem and has good sides and negatives. What I have
an interest is getting people to be clear where they have
disagreements versus spending their time talking past each other and
getting more and more pissed because of it.

-- 
Stephen J Smoogen.
___
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: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 4:03 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
> [...]
> > I agree with Aleksandra here. And we *did* establish that our policy
> > going forward is that we will forbid any default stream from providing
> > non-API content. (Filtered out packages are orthogonal to this.)
>
> What does that even mean?
>

Modular builds have metadata that can indicate to consumers which
subpackages in this module should be considered "API". If a module
produces a package artifact and does not list it thusly, it is meant
to be treated as an internal implementation detail of the module (and
that the maintainer is not committing to maintaining that particular
package for any purpose other than supporting the API content of this
module).

We also have "filters" which are intended for allowing module
packagers to build and use build-time-only packages. They are built
and added to the module buildroot as part of the build process, but
they are filtered out so they don't end up in the final composed
repository. (This is useful if, for example, your package used a small
subset of some other package only at build-time and you don't want to
have to maintain that package for everyone in the distro just to build
yours).
___
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

[Bug 1771702] [RFE] EPEL8 branch of perl-Cookie-Baker

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771702

Emmanuel Seyman  changed:

   What|Removed |Added

 Depends On||1771739




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1771739
[Bug 1771739] [RFE] EPEL8 branch of perl-Test-Time
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771739] New: [RFE] EPEL8 branch of perl-Test-Time

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771739

Bug ID: 1771739
   Summary: [RFE] EPEL8 branch of perl-Test-Time
   Product: Fedora
   Version: rawhide
Status: ASSIGNED
 Component: perl-Test-Time
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
Blocks: 1771702
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19609
https://pagure.io/releng/fedora-scm-requests/issue/19610


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1771702
[Bug 1771702] [RFE] EPEL8 branch of perl-Cookie-Baker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Modularity: The Official Complaint Thread

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 12 November 2019 at 21:15, Stephen Gallagher wrote:
[...]
> I agree with Aleksandra here. And we *did* establish that our policy
> going forward is that we will forbid any default stream from providing
> non-API content. (Filtered out packages are orthogonal to this.)

What does that even mean?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[Bug 1771703] [RFE] EPEL8 branch of perl-Devel-StackTrace-AsHTML

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771703

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1744690




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771702] [RFE] EPEL8 branch of perl-Cookie-Baker

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771702

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1744690




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771715] [RFE] EPEL8 branch of perl-Stream-Buffered

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771715

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1744690




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771705] [RFE] EPEL8 branch of perl-HTTP-Entity-Parser

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771705

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1744690




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771707] [RFE] EPEL8 branch of perl-HTTP-Server-Simple-PSGI

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771707

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1744690




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1744690

Emmanuel Seyman  changed:

   What|Removed |Added

 Depends On||1771702, 1771703, 1771705,
   ||1771707, 1771711, 1771715,
   ||1771717




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1771702
[Bug 1771702] [RFE] EPEL8 branch of perl-Cookie-Baker
https://bugzilla.redhat.com/show_bug.cgi?id=1771703
[Bug 1771703] [RFE] EPEL8 branch of perl-Devel-StackTrace-AsHTML
https://bugzilla.redhat.com/show_bug.cgi?id=1771705
[Bug 1771705] [RFE] EPEL8 branch of perl-HTTP-Entity-Parser
https://bugzilla.redhat.com/show_bug.cgi?id=1771707
[Bug 1771707] [RFE] EPEL8 branch of perl-HTTP-Server-Simple-PSGI
https://bugzilla.redhat.com/show_bug.cgi?id=1771711
[Bug 1771711] [RFE] EPEL8 branch of perl-LWP-Protocol-http10
https://bugzilla.redhat.com/show_bug.cgi?id=1771715
[Bug 1771715] [RFE] EPEL8 branch of perl-Stream-Buffered
https://bugzilla.redhat.com/show_bug.cgi?id=1771717
[Bug 1771717] [RFE] EPEL8 branch of perl-WWW-Form-UrlEncoded
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771711] [RFE] EPEL8 branch of perl-LWP-Protocol-http10

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771711

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1744690




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771717] [RFE] EPEL8 branch of perl-WWW-Form-UrlEncoded

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771717

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1744690




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
[Bug 1744690] [RFE] EPEL8 branch of perl-Plack
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 3:29 PM Neal Gompa  wrote:
>
> On Tue, Nov 12, 2019 at 3:20 PM Stephen Gallagher  wrote:
> >
> > On Tue, Nov 12, 2019 at 11:10 AM Neal Gompa  wrote:
> > >
> > > On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  
> > > wrote:
> > > >
> > > > Again, no one forces you or any other packager to use modularity
> > > > tooling right now.
> > > >
> > >
> > > This is not true. Once content is modularized, things that were able
> > > to depend on it in the normal form can no longer do so unless they too
> > > modularize.
> >
> > This is true *currently*, but as I've been saying for months now: this
> > is only true because we've not been allowed to land Ursa Prime (and,
> > before that, Ursa Major) to allow us to have modules in the buildroot.
> >
> > That *finally* started to change with FESCo's decision yesterday. They
> > gave us permission to put two reasonably-contained modules into the
> > available buildroot to prove it out.
> >
>
> I am watching that experiment carefully. I'm doing something similar
> for my own work as an experiment into pulling in modular content into
> my build environments...
>
> > > This is an important consequence that I think people
> > > championing for modularity keep forgetting. Everything from how the
> > > build system works to how DNF implements modularity makes it so that
> > > modular and non-modular content do not have an even footing. If they
> > > did, I think we'd have less problems.
> >
> > I think "even footing" is a poor choice of words, because it implies
> > that one is "higher" than the other. It's true that things are built
> > and managed *differently*. We've been trying to close that gap as much
> > as possible.
>
> Technically, one is "higher" than the other. Modular content
> automatically disables the non-modular counterparts. You don't have
> the ability to select to install and follow content fron the
> non-modular source instead of the modular one, especially with
> fedora-modular enabled by default.
>
> If there is a path for me to freely switch back and forth between
> equivalent modular and non-modular variants, I'd definitely be
> happier, personally.

`dnf module disable foo` *should* be able to do this. If that doesn't
work in all cases, there are bugs. I just tested myself that I could
do `dnf module disable meson && dnf downgrade meson` and I got the
non-modular package on my F31 system. (If the non-modular one had been
a higher ENVR, I would have been able to do `dnf update meson`.)
___
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: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 1:32 PM Aleksandra Fedorova  wrote:
>
> On Tue, Nov 12, 2019 at 7:03 PM Aleksandar Kurtakov  
> wrote:
> >
> >
> >
> > On Tue, Nov 12, 2019 at 7:55 PM Aleksandra Fedorova  
> > wrote:
> >>
> >> Hi, Aleksandar,
> >>
> >> On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov  
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova  
> >> > wrote:
> >> >>
> >> >> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  
> >> >> wrote:
> >> >> >
> >> >> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> >> >> > > Again, no one forces you or any other packager to use modularity
> >> >> > > tooling right now.
> >> >> > >
> >> >> > > As Fedora developer you have a choice to join the effort, bring your
> >> >> > > input and use cases, try and test (and revert if it doesn't work) or
> >> >> > > you can stay away from it and keep using same tools as before.
> >> >> >
> >> >> >
> >> >> > Unfortunately, this is not true. It is not possible to ignore 
> >> >> > modularity, if the
> >> >> > dependencies are modularized. It is not possible to ignore 
> >> >> > modularity, if the
> >> >> > dependents are modularized. It is not possible to ignore modularity, 
> >> >> > if the
> >> >> > packages I wish to use are modularized.
> >> >> >
> >> >> > I wish Fedora packagers and users cold "stay away". But that is 
> >> >> > currently not
> >> >> > possible. My proposal to keep all defaults as non-modular packages 
> >> >> > would make it
> >> >> > exactly so.
> >> >>
> >> >> Ursa Prime effort achieves the same goal. It removes the "viral" part
> >> >> of Modularity I think.
> >> >>
> >> >> As well as policy which restricts the set of default modules, which I
> >> >> think we need to change from "FESCo approves new default modules" to
> >> >> "each request for new default module should be treated as a
> >> >> System-Wide Change".
> >> >>
> >> >> Again I fail to see the _technical_ difference between the ursine rpm
> >> >> package and a package which was built as a part of default stream. It
> >> >> is the same rpm spec from the same dist-git sources, which is built by
> >> >> the same rpmbuild command. Thus I think it is a process/policy
> >> >> difference, which we should resolve.
> >> >>
> >> >> And I will support a hard block on creating new default streams, until
> >> >> it is resolved.
> >> >> (With the exception of eclipse probably, which is in a broken state
> >> >> already, and for which we need to find a solution.)
> >> >
> >> >
> >> > The way Eclipse is treated makes me really sad and kind of regret the 
> >> > time spent on Fedora over the years! Being forced to be a module but 
> >> > blocked to be default stream by FESCo arguing over whether it wants 
> >> > modularity (sorry, this is how it looks) is the best way for Fedora to 
> >> > show to project and people they are not wanted in the community!
> >> > The net effect for me personally is to totally move my eyes away as I 
> >> > get really pissed off.
> >>
> >> I am sorry that it looks this way for you, but you are misinterpreting it.
> >>
> >> FESCo was willing to enable the default stream for eclipse the moment
> >> it was requested given by the fact that it actually solves the
> >> problem. But it wasn't the case.
> >
> >
> > Would you please elaborate how this was not the case? There was the 
> > glassfish package provided by two streams issue which has been fixed in 
> > maven module but eclipse still is not approved as default package. What am 
> > I missing?
>
> You can check the logs from the FESCo meeting.
>
> To make a proper decision FESCo needs to understand which problem we
> are solving, what is the proposed solution what is the impact of this
> solution and what are the alternatives.
> The IRC meeting format is not the best way to discuss complex things
> that is why it usually needs a preparation in advance in a form of
> ticket to FESCo via Pagure which provides a common context for the
> conversation.
>
> The previous decision on eclipse was
>
>   AGREED: Drop the unmaintained eclipse from the non-modular
> repositories and ship module streams of eclipse. Whenever the
> conflicts are resolved later, we can make a default stream available
> (+6, 0, 0)
>   zbyszek to add eclipse to fedora-obsolet-packages
>   mbooth to drive the retirement of non-modular eclipse
>   The bug about eclipse not being installable is approved as FESCo FE (+6, 0, 
> 0)
>
> To move forward we need at least to get a status update on it.
>
> 1) status of retirement of non-modular eclipse packages
> 2) status of conflict between maven and eclipse modules
> 3) status of the module - is it verified that enabling eclipse module
> explicitly now solves the problem?
> - will "dnf install eclipse" work on new Fedora with all updates?
> - will "dnf install eclipse" work on Fedora with updates and maven
> module installed previously?
> - .. maybe some other cases?
>
> We didn't get all of this information during the meeting, there 

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 12:40 PM Aleksandar Kurtakov
 wrote:
> The way Eclipse is treated makes me really sad and kind of regret the time 
> spent on Fedora over the years! Being forced to be a module but blocked to be 
> default stream by FESCo arguing over whether it wants modularity (sorry, this 
> is how it looks) is the best way for Fedora to show to project and people 
> they are not wanted in the community!
> The net effect for me personally is to totally move my eyes away as I get 
> really pissed off

Eclipse has definitely had a rough ride here. There's no question
about that. And while it may be small comfort to the Eclipse
maintainers, it has been invaluable in showing us which policies we
need to put in place to avoid making the same mistakes in the future.
Being "forced to be a module" was somewhat outside our control, as the
Java team went running off and delivered their version of a finished
product and you got caught in the crossfire. We are doing everything
we can to sort this out.

I do apologize for how hard your project has gotten hit. It was unfair
to the Eclipse team.
___
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: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 12:40 PM Stephen John Smoogen  wrote:
>
> On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  wrote:
> > Again I fail to see the _technical_ difference between the ursine rpm
> > package and a package which was built as a part of default stream. It
> > is the same rpm spec from the same dist-git sources, which is built by
> > the same rpmbuild command. Thus I think it is a process/policy
> > difference, which we should resolve.
>
> Do you view provides/requires/conflicts in an RPM spec and their
> equivalent in modules to be technical or policy differences. If wrote
> a policy which says I built X and X-devel but only want to ship X in
> the module.. is that a policy difference or a technical one?

The technology allows you to do this. The policy can restrict this. Of
course, this particular example can be true of a non-modular RPM too;
you don't *have* to build the X-devel subpackage.

> If the
> policy says I can't even install a newer X/X-devel that I built with
> NEVR because modules always win and it isn't a module.. is that a
> technical difference or a policy one?
>

That would be a technical difference. Your statement, however, is not
entirely true. You can trivially override it by using RPM instead of
DNF to update it. Or you can run `createrepo_c` and then add
`module_hotfix = 1` to the repo file you add to DNF.


> I can see where those are technical because it is built into the
> technology of modules/dnf/etc and I can also see it as policy as the
> 'spec' file is more about setting up policies for a package needing
> certain things and including/excluding other things.
>
> [I am asking this because if we spend a lot of time arguing because
> people think X is technical and others think it is policy.. the
> argument will spiral for hundreds of messages about definitions that
> people thought they agreed on and not about the change itself.]

Let's leave it at "technical differences are things where the inputs
and outputs of packaging differ" and "policy is what we as Fedora have
decided to allow, disallow or mandate".
___
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

limb pushed to perl-WWW-Form-UrlEncoded (epel8). ""Adding package.cfg file""

[notifications]

Notification time stamped 2019-11-12 20:33:39 UTC

From 7f5beee2647246a511c134b58100f4583614a6fd Mon Sep 17 00:00:00 2001
From: Gwyn Ciesla 
Date: Nov 12 2019 20:33:32 +
Subject: "Adding package.cfg file"


---

diff --git a/package.cfg b/package.cfg
new file mode 100644
index 000..66ea79d
--- /dev/null
+++ b/package.cfg
@@ -0,0 +1,2 @@
+[koji]
+targets = epel8 epel8-playground
\ No newline at end of file



https://src.fedoraproject.org/rpms/perl-WWW-Form-UrlEncoded/c/7f5beee2647246a511c134b58100f4583614a6fd?branch=epel8
___
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: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 12:31 PM Aleksandra Fedorova  wrote:
>
> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:
> >
> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > >
> > > As Fedora developer you have a choice to join the effort, bring your
> > > input and use cases, try and test (and revert if it doesn't work) or
> > > you can stay away from it and keep using same tools as before.
> >
> >
> > Unfortunately, this is not true. It is not possible to ignore modularity, 
> > if the
> > dependencies are modularized. It is not possible to ignore modularity, if 
> > the
> > dependents are modularized. It is not possible to ignore modularity, if the
> > packages I wish to use are modularized.
> >
> > I wish Fedora packagers and users cold "stay away". But that is currently 
> > not
> > possible. My proposal to keep all defaults as non-modular packages would 
> > make it
> > exactly so.
>
> Ursa Prime effort achieves the same goal. It removes the "viral" part
> of Modularity I think.
>

That is absolutely its purpose. If we fall short of that, it's a bug
and we will fix it as soon as possible.

> As well as policy which restricts the set of default modules, which I
> think we need to change from "FESCo approves new default modules" to
> "each request for new default module should be treated as a
> System-Wide Change".
>

I'm fine with that.

> Again I fail to see the _technical_ difference between the ursine rpm
> package and a package which was built as a part of default stream. It
> is the same rpm spec from the same dist-git sources, which is built by
> the same rpmbuild command. Thus I think it is a process/policy
> difference, which we should resolve.
>

I'll acknowledge that there may be subtle differences (such as the
different "release" tag), but none (offhand) that should have a
meaningful impact as long as other policy is in place.

> And I will support a hard block on creating new default streams, until
> it is resolved.
> (With the exception of eclipse probably, which is in a broken state
> already, and for which we need to find a solution.)

This is already in place.
___
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: The Official Complaint Thread

[Neal Gompa]

On Tue, Nov 12, 2019 at 3:20 PM Stephen Gallagher  wrote:
>
> On Tue, Nov 12, 2019 at 11:10 AM Neal Gompa  wrote:
> >
> > On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  
> > wrote:
> > >
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > >
> >
> > This is not true. Once content is modularized, things that were able
> > to depend on it in the normal form can no longer do so unless they too
> > modularize.
>
> This is true *currently*, but as I've been saying for months now: this
> is only true because we've not been allowed to land Ursa Prime (and,
> before that, Ursa Major) to allow us to have modules in the buildroot.
>
> That *finally* started to change with FESCo's decision yesterday. They
> gave us permission to put two reasonably-contained modules into the
> available buildroot to prove it out.
>

I am watching that experiment carefully. I'm doing something similar
for my own work as an experiment into pulling in modular content into
my build environments...

> > This is an important consequence that I think people
> > championing for modularity keep forgetting. Everything from how the
> > build system works to how DNF implements modularity makes it so that
> > modular and non-modular content do not have an even footing. If they
> > did, I think we'd have less problems.
>
> I think "even footing" is a poor choice of words, because it implies
> that one is "higher" than the other. It's true that things are built
> and managed *differently*. We've been trying to close that gap as much
> as possible.

Technically, one is "higher" than the other. Modular content
automatically disables the non-modular counterparts. You don't have
the ability to select to install and follow content fron the
non-modular source instead of the modular one, especially with
fedora-modular enabled by default.

If there is a path for me to freely switch back and forth between
equivalent modular and non-modular variants, I'd definitely be
happier, personally.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 11:10 AM Neal Gompa  wrote:
>
> On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  
> wrote:
> >
> > Again, no one forces you or any other packager to use modularity
> > tooling right now.
> >
>
> This is not true. Once content is modularized, things that were able
> to depend on it in the normal form can no longer do so unless they too
> modularize.

This is true *currently*, but as I've been saying for months now: this
is only true because we've not been allowed to land Ursa Prime (and,
before that, Ursa Major) to allow us to have modules in the buildroot.

That *finally* started to change with FESCo's decision yesterday. They
gave us permission to put two reasonably-contained modules into the
available buildroot to prove it out.

> This is an important consequence that I think people
> championing for modularity keep forgetting. Everything from how the
> build system works to how DNF implements modularity makes it so that
> modular and non-modular content do not have an even footing. If they
> did, I think we'd have less problems.

I think "even footing" is a poor choice of words, because it implies
that one is "higher" than the other. It's true that things are built
and managed *differently*. We've been trying to close that gap as much
as possible.
___
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: The Official Complaint Thread

[Stephen Gallagher]

On Tue, Nov 12, 2019 at 10:26 AM Igor Gnatenko
 wrote:
>
> The question arises, what people are supposed to do when they modularized 
> content because modularity is (was?) good tool to have "buildroot-only 
> packages," "separate lifecycle from Fedora" and "no difference from normal 
> packages."
>
> Second was rightfully prohibited by FESCo, first is making people not happy. 
> Third one is not true.
>
> I basically had to go back, remove 28 out of 52 Fedora modules because 
> tooling is not improving and policies are being more restrictive.
>
> You say we need to improve tooling and iterate fast, fine. But why then 
> https://pagure.io/releng/issue/7662 is still not implemented? I understand 
> that it is opensource And everyone can contribute, but the fact is that 
> people who work on Modularity tooling is entirely paid by RH and those people 
> are "responsible" to bring it to Fedora and make it work. However, as written 
> in the ticket "it is not a priority for that team".
>

To be clear, the team that rejected that was the Bodhi team, not the
Modularity team. We do need to re-examine that; it just kind of fell
off the radar due to higher-priority issues.

> So is it really about making tooling (writing new, or making existing better) 
> or about making those people to implement Fedora needs?
>
>> For that we need to focus on the issue, which is, from my point of
>> view: default streams and their differences from the ursine packages.
>>
>> One is caused by the lack of Ursa Prime, another is the upgrade
>> functionality, and I guess the third one is the non-api and filtered
>> packages in the module.
>>
>> P.S. I am not a member of Modularity team.

I agree with Aleksandra here. And we *did* establish that our policy
going forward is that we will forbid any default stream from providing
non-API content. (Filtered out packages are orthogonal to this.)
___
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

[Bug 1771717] New: [RFE] EPEL8 branch of perl-WWW-Form-UrlEncoded

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771717

Bug ID: 1771717
   Summary: [RFE] EPEL8 branch of perl-WWW-Form-UrlEncoded
   Product: Fedora
   Version: rawhide
Status: ASSIGNED
 Component: perl-WWW-Form-UrlEncoded
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19607
https://pagure.io/releng/fedora-scm-requests/issue/19608

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

limb pushed to perl-Cookie-Baker (epel8). ""Adding package.cfg file""

[notifications]

Notification time stamped 2019-11-12 20:00:58 UTC

From ab0db7ecb8a50abb3ca59d50207b2984c90a509c Mon Sep 17 00:00:00 2001
From: Gwyn Ciesla 
Date: Nov 12 2019 20:00:52 +
Subject: "Adding package.cfg file"


---

diff --git a/package.cfg b/package.cfg
new file mode 100644
index 000..66ea79d
--- /dev/null
+++ b/package.cfg
@@ -0,0 +1,2 @@
+[koji]
+targets = epel8 epel8-playground
\ No newline at end of file



https://src.fedoraproject.org/rpms/perl-Cookie-Baker/c/ab0db7ecb8a50abb3ca59d50207b2984c90a509c?branch=epel8
___
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

[Bug 1771715] New: [RFE] EPEL8 branch of perl-Stream-Buffered

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771715

Bug ID: 1771715
   Summary: [RFE] EPEL8 branch of perl-Stream-Buffered
   Product: Fedora
   Version: rawhide
Status: ASSIGNED
 Component: perl-Stream-Buffered
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19605
https://pagure.io/releng/fedora-scm-requests/issue/19606

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[EPEL-devel] Re: Missing Python 3 bindings for C libraries in EL7

[Neal Gompa]

On Tue, Nov 12, 2019 at 1:44 PM Mike DePaulo  wrote:
>
> On Tue, Nov 12, 2019 at 5:05 AM Miro Hrončok  wrote:
> >
> > On 12. 11. 19 7:52, Mike DePaulo wrote:
> > > Hi everyone,
> > >
> > > Background:
> > > The Pulp 3 upstream project is written in Python 3.
> > > Our installer normally uses PyPI for pure python packages, and OS
> > > packages for C libraries & their python bindings.
> > >
> > > Problem:
> > > With RHEL7/CentOS7, we often run into the following thorny situation:
> > > - Package libjuicy, written in C, exists in EL7 (main, optional, or 
> > > extras).
> > > - Subpackage python2-libjuicy with python2 bindings exists in EL7.
> > > - Subpackage python3-libjuicy does not exist at all for EL7.
> > >
> > > Note: libjuicy is a made up name :)
> >
> > If you post the actual libraries, I would bring that up with my team (Python
> > Maint @ Red Hat).
>
> I'm mostly certain this is only this one we strictly "need" right now:
> libcomps
>
> We might need this in the future:
> dnf
>
> This would be helpful, but the current EL7 version is too old for
> Pulp's needs (and we currently have a workaround: a C-compiling
> package on PyPI [1] [2]):
> createrepo_c
>

There are already bugs requesting these things:

* https://bugzilla.redhat.com/show_bug.cgi?id=1672102
* https://bugzilla.redhat.com/show_bug.cgi?id=1719977

They were closed as WONTFIX, but feel free to reopen with your own
justification to add to them to get that changed.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Modularity and all the things

[Matthew Miller]

On Tue, Nov 12, 2019 at 02:09:10PM -0500, Randy Barlow wrote:
> > Have the same opportunity to participate in leadership.
> Only two of the council seats are elected. The rest are appointed, and
> some of those appointed only by specific Red Hat employees.
> 
> Thus, I don't think it's exactly the same opportunities to participate
> in leadership.
> 
> https://docs.fedoraproject.org/en-US/council/

It's true that there are roles that Red Hat funds full-time. Red Hat
generally hires from the community for those positions. And, I am
absolutely certain that those hiring decisions do not have anything to
do with the desktop environment that the person in question uses or
works on.

(It's true that I switched from Xfce to GNOME after I got this job, but
it was of my own free will, I swear.)


-- 
Matthew Miller

Fedora Project Leader
___
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

[Bug 1771711] New: [RFE] EPEL8 branch of perl-LWP-Protocol-http10

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771711

Bug ID: 1771711
   Summary: [RFE] EPEL8 branch of perl-LWP-Protocol-http10
   Product: Fedora
   Version: rawhide
Status: ASSIGNED
 Component: perl-LWP-Protocol-http10
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19601
https://pagure.io/releng/fedora-scm-requests/issue/19602

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

limb pushed to perl-HTTP-Entity-Parser (epel8). ""Adding package.cfg file""

[notifications]

Notification time stamped 2019-11-12 20:02:23 UTC

From 9440fc7db5e35506515c4c15a24d8f989dcc0980 Mon Sep 17 00:00:00 2001
From: Gwyn Ciesla 
Date: Nov 12 2019 20:02:16 +
Subject: "Adding package.cfg file"


---

diff --git a/package.cfg b/package.cfg
new file mode 100644
index 000..66ea79d
--- /dev/null
+++ b/package.cfg
@@ -0,0 +1,2 @@
+[koji]
+targets = epel8 epel8-playground
\ No newline at end of file



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/9440fc7db5e35506515c4c15a24d8f989dcc0980?branch=epel8
___
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

[Bug 1771707] New: [RFE] EPEL8 branch of perl-HTTP-Server-Simple-PSGI

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771707

Bug ID: 1771707
   Summary: [RFE] EPEL8 branch of perl-HTTP-Server-Simple-PSGI
   Product: Fedora
   Version: rawhide
Status: ASSIGNED
 Component: perl-HTTP-Server-Simple-PSGI
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19599
https://pagure.io/releng/fedora-scm-requests/issue/19600

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771705] New: [RFE] EPEL8 branch of perl-HTTP-Entity-Parser

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771705

Bug ID: 1771705
   Summary: [RFE] EPEL8 branch of perl-HTTP-Entity-Parser
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-Entity-Parser
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19597
https://pagure.io/releng/fedora-scm-requests/issue/19598

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771703] New: [RFE] EPEL8 branch of perl-Devel-StackTrace-AsHTML

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771703

Bug ID: 1771703
   Summary: [RFE] EPEL8 branch of perl-Devel-StackTrace-AsHTML
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-StackTrace-AsHTML
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19595
https://pagure.io/releng/fedora-scm-requests/issue/19596

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1771702] New: [RFE] EPEL8 branch of perl-Cookie-Baker

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771702

Bug ID: 1771702
   Summary: [RFE] EPEL8 branch of perl-Cookie-Baker
   Product: Fedora
   Version: rawhide
Status: ASSIGNED
 Component: perl-Cookie-Baker
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



https://pagure.io/releng/fedora-scm-requests/issue/19593
https://pagure.io/releng/fedora-scm-requests/issue/19594

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Modularity and all the things

[Randy Barlow]

On Tue, 2019-11-12 at 09:24 -0500, Matthew Miller wrote:
> Have the same opportunity to participate in leadership.

Only two of the council seats are elected. The rest are appointed, and
some of those appointed only by specific Red Hat employees.

Thus, I don't think it's exactly the same opportunities to participate
in leadership.

https://docs.fedoraproject.org/en-US/council/


signature.asc
Description: This is a digitally signed message part
___
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: Missing Python 3 bindings for C libraries in EL7

[Mike DePaulo]

On Tue, Nov 12, 2019 at 5:05 AM Miro Hrončok  wrote:
>
> On 12. 11. 19 7:52, Mike DePaulo wrote:
> > Hi everyone,
> >
> > Background:
> > The Pulp 3 upstream project is written in Python 3.
> > Our installer normally uses PyPI for pure python packages, and OS
> > packages for C libraries & their python bindings.
> >
> > Problem:
> > With RHEL7/CentOS7, we often run into the following thorny situation:
> > - Package libjuicy, written in C, exists in EL7 (main, optional, or extras).
> > - Subpackage python2-libjuicy with python2 bindings exists in EL7.
> > - Subpackage python3-libjuicy does not exist at all for EL7.
> >
> > Note: libjuicy is a made up name :)
>
> If you post the actual libraries, I would bring that up with my team (Python
> Maint @ Red Hat).

I'm mostly certain this is only this one we strictly "need" right now:
libcomps

We might need this in the future:
dnf

This would be helpful, but the current EL7 version is too old for
Pulp's needs (and we currently have a workaround: a C-compiling
package on PyPI [1] [2]):
createrepo_c

- Mike

[1] https://pypi.org/project/createrepo-c/
[2] https://github.com/rpm-software-management/createrepo_c/pull/103





>
> > I am not sure how to provide the python3 bindings .
> >
> > Solutions I've thought of:
> >
> > 1. I see that for pure python packages ("chardet" being an example I
> > stumbled upon), there's often a python2 package in EL7, but a python3
> > package in EPEL7. Often at different versions. And I found guidelines
> > for this. [1]
> >
> > However, I am worried about robustness (& feasibility) of a
> > python3-libjuicy bindings-only source package in EPEL7 for an EL7
> > libjuicy. What if there's a libjuicy update and it breaks the bindings
> > until we (Pulp / Fedora contributors) update them? And would it be
> > permissible in EPEL 7?
>
> You would need to be ready to update the package every time it updates in EL.
> That is usually not very often.
>
> It would be permissible. See for example:
>
> https://src.fedoraproject.org/rpms/python3-rpm
>
> > 3. We can request that RHEL7 provides an updated libjuicy with the
> > python3-libjuicy subpackage.
> >
> > However, even if they say yes, it would take too long for upstream
> > release schedule.
>
> Also note that RHEL 7 is slowly getting to a phase where feature request might
> end up being denied. Here is a potentially successful one, but it already took
> half a year:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1719978
>
> > Suggestions?
> >
> > BTW, thank you for all the hard work on EPEL7 Python 3 support. I've
> > been following the RHEL 7.7 situation.
>
> Thanks for the kind words!
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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 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: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

On Tue, Nov 12, 2019 at 7:03 PM Aleksandar Kurtakov  wrote:
>
>
>
> On Tue, Nov 12, 2019 at 7:55 PM Aleksandra Fedorova  
> wrote:
>>
>> Hi, Aleksandar,
>>
>> On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov  
>> wrote:
>> >
>> >
>> >
>> > On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova  
>> > wrote:
>> >>
>> >> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:
>> >> >
>> >> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
>> >> > > Again, no one forces you or any other packager to use modularity
>> >> > > tooling right now.
>> >> > >
>> >> > > As Fedora developer you have a choice to join the effort, bring your
>> >> > > input and use cases, try and test (and revert if it doesn't work) or
>> >> > > you can stay away from it and keep using same tools as before.
>> >> >
>> >> >
>> >> > Unfortunately, this is not true. It is not possible to ignore 
>> >> > modularity, if the
>> >> > dependencies are modularized. It is not possible to ignore modularity, 
>> >> > if the
>> >> > dependents are modularized. It is not possible to ignore modularity, if 
>> >> > the
>> >> > packages I wish to use are modularized.
>> >> >
>> >> > I wish Fedora packagers and users cold "stay away". But that is 
>> >> > currently not
>> >> > possible. My proposal to keep all defaults as non-modular packages 
>> >> > would make it
>> >> > exactly so.
>> >>
>> >> Ursa Prime effort achieves the same goal. It removes the "viral" part
>> >> of Modularity I think.
>> >>
>> >> As well as policy which restricts the set of default modules, which I
>> >> think we need to change from "FESCo approves new default modules" to
>> >> "each request for new default module should be treated as a
>> >> System-Wide Change".
>> >>
>> >> Again I fail to see the _technical_ difference between the ursine rpm
>> >> package and a package which was built as a part of default stream. It
>> >> is the same rpm spec from the same dist-git sources, which is built by
>> >> the same rpmbuild command. Thus I think it is a process/policy
>> >> difference, which we should resolve.
>> >>
>> >> And I will support a hard block on creating new default streams, until
>> >> it is resolved.
>> >> (With the exception of eclipse probably, which is in a broken state
>> >> already, and for which we need to find a solution.)
>> >
>> >
>> > The way Eclipse is treated makes me really sad and kind of regret the time 
>> > spent on Fedora over the years! Being forced to be a module but blocked to 
>> > be default stream by FESCo arguing over whether it wants modularity 
>> > (sorry, this is how it looks) is the best way for Fedora to show to 
>> > project and people they are not wanted in the community!
>> > The net effect for me personally is to totally move my eyes away as I get 
>> > really pissed off.
>>
>> I am sorry that it looks this way for you, but you are misinterpreting it.
>>
>> FESCo was willing to enable the default stream for eclipse the moment
>> it was requested given by the fact that it actually solves the
>> problem. But it wasn't the case.
>
>
> Would you please elaborate how this was not the case? There was the glassfish 
> package provided by two streams issue which has been fixed in maven module 
> but eclipse still is not approved as default package. What am I missing?

You can check the logs from the FESCo meeting.

To make a proper decision FESCo needs to understand which problem we
are solving, what is the proposed solution what is the impact of this
solution and what are the alternatives.
The IRC meeting format is not the best way to discuss complex things
that is why it usually needs a preparation in advance in a form of
ticket to FESCo via Pagure which provides a common context for the
conversation.

The previous decision on eclipse was

  AGREED: Drop the unmaintained eclipse from the non-modular
repositories and ship module streams of eclipse. Whenever the
conflicts are resolved later, we can make a default stream available
(+6, 0, 0)
  zbyszek to add eclipse to fedora-obsolet-packages
  mbooth to drive the retirement of non-modular eclipse
  The bug about eclipse not being installable is approved as FESCo FE (+6, 0, 0)

To move forward we need at least to get a status update on it.

1) status of retirement of non-modular eclipse packages
2) status of conflict between maven and eclipse modules
3) status of the module - is it verified that enabling eclipse module
explicitly now solves the problem?
- will "dnf install eclipse" work on new Fedora with all updates?
- will "dnf install eclipse" work on Fedora with updates and maven
module installed previously?
- .. maybe some other cases?

We didn't get all of this information during the meeting, there was no
feedback in the relevant BZ with the verification either, and the
attempt to verify the solution during the meeting provided
contradicting results. Thus we asked to provide the data
asynchronously via FESCo ticket.

--
Aleksandra Fedorova
bookwar
___

Re: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

Hi Stephen,

On Tue, Nov 12, 2019 at 6:40 PM Stephen John Smoogen  wrote:
>
> On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  wrote:
> >
> > On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:
> > >
> > > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> > > > Again, no one forces you or any other packager to use modularity
> > > > tooling right now.
> > > >
> > > > As Fedora developer you have a choice to join the effort, bring your
> > > > input and use cases, try and test (and revert if it doesn't work) or
> > > > you can stay away from it and keep using same tools as before.
> > >
> > >
> > > Unfortunately, this is not true. It is not possible to ignore modularity, 
> > > if the
> > > dependencies are modularized. It is not possible to ignore modularity, if 
> > > the
> > > dependents are modularized. It is not possible to ignore modularity, if 
> > > the
> > > packages I wish to use are modularized.
> > >
> > > I wish Fedora packagers and users cold "stay away". But that is currently 
> > > not
> > > possible. My proposal to keep all defaults as non-modular packages would 
> > > make it
> > > exactly so.
> >
> > Ursa Prime effort achieves the same goal. It removes the "viral" part
> > of Modularity I think.
> >
> > As well as policy which restricts the set of default modules, which I
> > think we need to change from "FESCo approves new default modules" to
> > "each request for new default module should be treated as a
> > System-Wide Change".
> >
> > Again I fail to see the _technical_ difference between the ursine rpm
> > package and a package which was built as a part of default stream. It
> > is the same rpm spec from the same dist-git sources, which is built by
> > the same rpmbuild command. Thus I think it is a process/policy
> > difference, which we should resolve.
>
> Do you view provides/requires/conflicts in an RPM spec and their
> equivalent in modules to be technical or policy differences. If wrote
> a policy which says I built X and X-devel but only want to ship X in
> the module.. is that a policy difference or a technical one? If the
> policy says I can't even install a newer X/X-devel that I built with
> NEVR because modules always win and it isn't a module.. is that a
> technical difference or a policy one?
>
> I can see where those are technical because it is built into the
> technology of modules/dnf/etc and I can also see it as policy as the
> 'spec' file is more about setting up policies for a package needing
> certain things and including/excluding other things.
>
> [I am asking this because if we spend a lot of time arguing because
> people think X is technical and others think it is policy.. the
> argument will spiral for hundreds of messages about definitions that
> people thought they agreed on and not about the change itself.]

You are right, I am using the terms very loosely here.

I don't really plan to have a detailed discussion on default modules
in this thread, so I am hand-waiving to set the context for that
discussion.

What I'd like to see is a separate thread or probably better a
separate document where we list all differences between ursine package
and a package coming from default stream and identify which
differences we want to have and which we need to restrict by the
policy.

And once we have this restricted policy we may recheck again, if we
actually have package maintainers, who would like to use default
streams under those restrictions, and what are their use cases.

-- 
Aleksandra Fedorova
bookwar
___
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: The Official Complaint Thread

[Aleksandar Kurtakov]

On Tue, Nov 12, 2019 at 7:55 PM Aleksandra Fedorova 
wrote:

> Hi, Aleksandar,
>
> On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov 
> wrote:
> >
> >
> >
> > On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova 
> wrote:
> >>
> >> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok 
> wrote:
> >> >
> >> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> >> > > Again, no one forces you or any other packager to use modularity
> >> > > tooling right now.
> >> > >
> >> > > As Fedora developer you have a choice to join the effort, bring your
> >> > > input and use cases, try and test (and revert if it doesn't work) or
> >> > > you can stay away from it and keep using same tools as before.
> >> >
> >> >
> >> > Unfortunately, this is not true. It is not possible to ignore
> modularity, if the
> >> > dependencies are modularized. It is not possible to ignore
> modularity, if the
> >> > dependents are modularized. It is not possible to ignore modularity,
> if the
> >> > packages I wish to use are modularized.
> >> >
> >> > I wish Fedora packagers and users cold "stay away". But that is
> currently not
> >> > possible. My proposal to keep all defaults as non-modular packages
> would make it
> >> > exactly so.
> >>
> >> Ursa Prime effort achieves the same goal. It removes the "viral" part
> >> of Modularity I think.
> >>
> >> As well as policy which restricts the set of default modules, which I
> >> think we need to change from "FESCo approves new default modules" to
> >> "each request for new default module should be treated as a
> >> System-Wide Change".
> >>
> >> Again I fail to see the _technical_ difference between the ursine rpm
> >> package and a package which was built as a part of default stream. It
> >> is the same rpm spec from the same dist-git sources, which is built by
> >> the same rpmbuild command. Thus I think it is a process/policy
> >> difference, which we should resolve.
> >>
> >> And I will support a hard block on creating new default streams, until
> >> it is resolved.
> >> (With the exception of eclipse probably, which is in a broken state
> >> already, and for which we need to find a solution.)
> >
> >
> > The way Eclipse is treated makes me really sad and kind of regret the
> time spent on Fedora over the years! Being forced to be a module but
> blocked to be default stream by FESCo arguing over whether it wants
> modularity (sorry, this is how it looks) is the best way for Fedora to show
> to project and people they are not wanted in the community!
> > The net effect for me personally is to totally move my eyes away as I
> get really pissed off.
>
> I am sorry that it looks this way for you, but you are misinterpreting it.
>
> FESCo was willing to enable the default stream for eclipse the moment
> it was requested given by the fact that it actually solves the
> problem. But it wasn't the case.
>

Would you please elaborate how this was not the case? There was the
glassfish package provided by two streams issue which has been fixed in
maven module but eclipse still is not approved as default package. What am
I missing?


> So the delay of the decision on Eclipse has nothing to do with the
> generic Modularity trouble, it is based solely on the fact that we
> need a working solution, and there was a certain miscommunication and
> lack of coordination in providing it.
>
> And this is exactly what I said in my previous mail. We treat eclipse
> as exceptional case and it is not affected by this conversation.
>
> --
> Aleksandra Fedorova
> bookwar
> ___
> 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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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] [Fedocal] Reminder meeting : EPEL Steering Co

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2019-11-13 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the 
following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9364/

___
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: Modularity: The Official Complaint Thread

[Aleksandra Fedorova]

Hi, Aleksandar,

On Tue, Nov 12, 2019 at 6:40 PM Aleksandar Kurtakov  wrote:
>
>
>
> On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova  
> wrote:
>>
>> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:
>> >
>> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
>> > > Again, no one forces you or any other packager to use modularity
>> > > tooling right now.
>> > >
>> > > As Fedora developer you have a choice to join the effort, bring your
>> > > input and use cases, try and test (and revert if it doesn't work) or
>> > > you can stay away from it and keep using same tools as before.
>> >
>> >
>> > Unfortunately, this is not true. It is not possible to ignore modularity, 
>> > if the
>> > dependencies are modularized. It is not possible to ignore modularity, if 
>> > the
>> > dependents are modularized. It is not possible to ignore modularity, if the
>> > packages I wish to use are modularized.
>> >
>> > I wish Fedora packagers and users cold "stay away". But that is currently 
>> > not
>> > possible. My proposal to keep all defaults as non-modular packages would 
>> > make it
>> > exactly so.
>>
>> Ursa Prime effort achieves the same goal. It removes the "viral" part
>> of Modularity I think.
>>
>> As well as policy which restricts the set of default modules, which I
>> think we need to change from "FESCo approves new default modules" to
>> "each request for new default module should be treated as a
>> System-Wide Change".
>>
>> Again I fail to see the _technical_ difference between the ursine rpm
>> package and a package which was built as a part of default stream. It
>> is the same rpm spec from the same dist-git sources, which is built by
>> the same rpmbuild command. Thus I think it is a process/policy
>> difference, which we should resolve.
>>
>> And I will support a hard block on creating new default streams, until
>> it is resolved.
>> (With the exception of eclipse probably, which is in a broken state
>> already, and for which we need to find a solution.)
>
>
> The way Eclipse is treated makes me really sad and kind of regret the time 
> spent on Fedora over the years! Being forced to be a module but blocked to be 
> default stream by FESCo arguing over whether it wants modularity (sorry, this 
> is how it looks) is the best way for Fedora to show to project and people 
> they are not wanted in the community!
> The net effect for me personally is to totally move my eyes away as I get 
> really pissed off.

I am sorry that it looks this way for you, but you are misinterpreting it.

FESCo was willing to enable the default stream for eclipse the moment
it was requested given by the fact that it actually solves the
problem. But it wasn't the case.
So the delay of the decision on Eclipse has nothing to do with the
generic Modularity trouble, it is based solely on the fact that we
need a working solution, and there was a certain miscommunication and
lack of coordination in providing it.

And this is exactly what I said in my previous mail. We treat eclipse
as exceptional case and it is not affected by this conversation.

-- 
Aleksandra Fedorova
bookwar
___
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: The Official Complaint Thread

[Aleksandar Kurtakov]

On Tue, Nov 12, 2019 at 7:31 PM Aleksandra Fedorova 
wrote:

> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:
> >
> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > >
> > > As Fedora developer you have a choice to join the effort, bring your
> > > input and use cases, try and test (and revert if it doesn't work) or
> > > you can stay away from it and keep using same tools as before.
> >
> >
> > Unfortunately, this is not true. It is not possible to ignore
> modularity, if the
> > dependencies are modularized. It is not possible to ignore modularity,
> if the
> > dependents are modularized. It is not possible to ignore modularity, if
> the
> > packages I wish to use are modularized.
> >
> > I wish Fedora packagers and users cold "stay away". But that is
> currently not
> > possible. My proposal to keep all defaults as non-modular packages would
> make it
> > exactly so.
>
> Ursa Prime effort achieves the same goal. It removes the "viral" part
> of Modularity I think.
>
> As well as policy which restricts the set of default modules, which I
> think we need to change from "FESCo approves new default modules" to
> "each request for new default module should be treated as a
> System-Wide Change".
>
> Again I fail to see the _technical_ difference between the ursine rpm
> package and a package which was built as a part of default stream. It
> is the same rpm spec from the same dist-git sources, which is built by
> the same rpmbuild command. Thus I think it is a process/policy
> difference, which we should resolve.
>
> And I will support a hard block on creating new default streams, until
> it is resolved.
> (With the exception of eclipse probably, which is in a broken state
> already, and for which we need to find a solution.)
>

The way Eclipse is treated makes me really sad and kind of regret the time
spent on Fedora over the years! Being forced to be a module but blocked to
be default stream by FESCo arguing over whether it wants modularity (sorry,
this is how it looks) is the best way for Fedora to show to project and
people they are not wanted in the community!
The net effect for me personally is to totally move my eyes away as I get
really pissed off
 .

>
> --
> Aleksandra Fedorova
> bookwar
> ___
> 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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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: The Official Complaint Thread

[Stephen John Smoogen]

On Tue, 12 Nov 2019 at 12:26, Aleksandra Fedorova  wrote:
>
> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:
> >
> > On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> > > Again, no one forces you or any other packager to use modularity
> > > tooling right now.
> > >
> > > As Fedora developer you have a choice to join the effort, bring your
> > > input and use cases, try and test (and revert if it doesn't work) or
> > > you can stay away from it and keep using same tools as before.
> >
> >
> > Unfortunately, this is not true. It is not possible to ignore modularity, 
> > if the
> > dependencies are modularized. It is not possible to ignore modularity, if 
> > the
> > dependents are modularized. It is not possible to ignore modularity, if the
> > packages I wish to use are modularized.
> >
> > I wish Fedora packagers and users cold "stay away". But that is currently 
> > not
> > possible. My proposal to keep all defaults as non-modular packages would 
> > make it
> > exactly so.
>
> Ursa Prime effort achieves the same goal. It removes the "viral" part
> of Modularity I think.
>
> As well as policy which restricts the set of default modules, which I
> think we need to change from "FESCo approves new default modules" to
> "each request for new default module should be treated as a
> System-Wide Change".
>
> Again I fail to see the _technical_ difference between the ursine rpm
> package and a package which was built as a part of default stream. It
> is the same rpm spec from the same dist-git sources, which is built by
> the same rpmbuild command. Thus I think it is a process/policy
> difference, which we should resolve.

Do you view provides/requires/conflicts in an RPM spec and their
equivalent in modules to be technical or policy differences. If wrote
a policy which says I built X and X-devel but only want to ship X in
the module.. is that a policy difference or a technical one? If the
policy says I can't even install a newer X/X-devel that I built with
NEVR because modules always win and it isn't a module.. is that a
technical difference or a policy one?

I can see where those are technical because it is built into the
technology of modules/dnf/etc and I can also see it as policy as the
'spec' file is more about setting up policies for a package needing
certain things and including/excluding other things.

[I am asking this because if we spend a lot of time arguing because
people think X is technical and others think it is policy.. the
argument will spiral for hundreds of messages about definitions that
people thought they agreed on and not about the change itself.]

-- 
Stephen J Smoogen.
___
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: Fonts packaging policy rewrite proposal

[Nicolas Mailhot via devel]

Le mardi 12 novembre 2019 à 09:00 +0100, Nicolas Mailhot a écrit :
> Hi,
> 
> A fonts packaging policy rewrite proposal has been pushed to FPC
> today:
> https://pagure.io/packaging-committee/pull-request/934
> 
> It is based on the new fonts-rpm-macros project for automation:

https://pagure.io/fonts-rpm-macros/

(it seems the link got omited while copying from pagure, I apologize
for the bother, that was not intentional)

Regards,

-- 
Nicolas Mailhot
___
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: The Official Complaint Thread

[Aleksandra Fedorova]

On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok  wrote:
>
> On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
> > Again, no one forces you or any other packager to use modularity
> > tooling right now.
> >
> > As Fedora developer you have a choice to join the effort, bring your
> > input and use cases, try and test (and revert if it doesn't work) or
> > you can stay away from it and keep using same tools as before.
>
>
> Unfortunately, this is not true. It is not possible to ignore modularity, if 
> the
> dependencies are modularized. It is not possible to ignore modularity, if the
> dependents are modularized. It is not possible to ignore modularity, if the
> packages I wish to use are modularized.
>
> I wish Fedora packagers and users cold "stay away". But that is currently not
> possible. My proposal to keep all defaults as non-modular packages would make 
> it
> exactly so.

Ursa Prime effort achieves the same goal. It removes the "viral" part
of Modularity I think.

As well as policy which restricts the set of default modules, which I
think we need to change from "FESCo approves new default modules" to
"each request for new default module should be treated as a
System-Wide Change".

Again I fail to see the _technical_ difference between the ursine rpm
package and a package which was built as a part of default stream. It
is the same rpm spec from the same dist-git sources, which is built by
the same rpmbuild command. Thus I think it is a process/policy
difference, which we should resolve.

And I will support a hard block on creating new default streams, until
it is resolved.
(With the exception of eclipse probably, which is in a broken state
already, and for which we need to find a solution.)

-- 
Aleksandra Fedorova
bookwar
___
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: The Official Complaint Thread

[Nicolas Mailhot via devel]

Le mardi 12 novembre 2019 à 17:02 +0100, Aleksandra Fedorova a écrit :
> Hi, Igor,
> 
> On Tue, Nov 12, 2019 at 4:20 PM Igor Gnatenko
>  wrote:
> > > 
> > > On Tue, Nov 12, 2019 at 10:50 AM Dominik 'Rathann' Mierzejewski
> > >  wrote:
> > > > 
> > So is it really about making tooling (writing new, or making
> > existing better) or about making those people to implement Fedora
> > needs?
> 
> "those people implementing Fedora needs" is a really bad way to put
> it. The fact that people are paid by Red Hat doesn't exclude them
> (us) from Fedora community. We are working on Fedora needs
> altogether, even when we disagree what those needs exactly are.

The intrinsic difficulty of internal Red Hat projects, is that they
don’t need strong community buy-in to get into the distribution.

While that saves time, and insures dev funding, it also means it is
easier to go full power on things that end up requiring deep changes to
get non Red Hat adoption.

It's not anyone's fault, it's the inherent nature of internal and
external dev paths.

Regards,

-- 
Nicolas Mailhot
___
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: Bodhi Outage Ongoing - Deploying 5.0

[Remi Collet]

Le 12/11/2019 à 10:45, Clement Verna a écrit :
> We will be upgrading bodhi to its 5.0 release. This release comes in with
> few UI changes but also task scheduling system (rabbitmq/celery based)
> allowing to offload some of the tasks currently performed in the front-end
> to distributed workers. This should results in the users experiencing a
> faster bodhi in some requests.

Sorry, but IMHO looks much slower

Especially the "builds" input which REQUIRES another damned javascript
query...

Please restore old behavior

Package: => input raise a query, allowing to select among new builds
Builds: => allow free input

Which was great when update is created DURING the build, when nothing
tagged yet.

I also dislike the need to open a popup to see the preview.


Remi



P.S. https://github.com/fedora-infra/bodhi/issues/3707
___
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: Bodhi Outage Ongoing - Deploying 5.0

[Mattia Verga via devel]

Il 12/11/19 16:46, Jerry James ha scritto:
> On Tue, Nov 12, 2019 at 8:27 AM Jerry James  wrote:
>> 2. It is not possible to create a newpackage update with the GUI.
>> I've got a brand new package, gap-pkg-fining, with a brand new build
>> for F31.  I type "gap-pkg-fining" into the "Name" field, and it tells
>> me that it cannot find the package [1].  Okay, I will just paste the
>> build into the "Builds" field like I've done before.  Except I can't.
>> That field is not selectable.  I can't click into it, I can't tab into
>> it, and I can't paste into it.
> The problem seems to be that I typed in the "Name" field first, then
> erased it when no results were returned.  I closed the browser tab
> completely and started over.  Then I could click into the "Builds"
> field and do a search, which succeeded.  That typing into, then
> erasing the contents of, the "Name" field should affect the ability to
> select the "Builds" field is nonobvious and confusing.
> --

I can't reproduce this odd behavior, the "Name" field has nothing to do 
with the query performed in the "Builds" field.

When typing in the "Builds" field a search is performed directly over 
Koji for builds which have the {*-updates-candidate} tag, so new 
packages should appear as soon as Koji tags them.

Mattia

___
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: Bodhi Outage Ongoing - Deploying 5.0

[Pierre-Yves Chibon]

On Tue, Nov 12, 2019 at 08:46:03AM -0700, Jerry James wrote:
> On Tue, Nov 12, 2019 at 8:27 AM Jerry James  wrote:
> > 2. It is not possible to create a newpackage update with the GUI.
> > I've got a brand new package, gap-pkg-fining, with a brand new build
> > for F31.  I type "gap-pkg-fining" into the "Name" field, and it tells
> > me that it cannot find the package [1].  Okay, I will just paste the
> > build into the "Builds" field like I've done before.  Except I can't.
> > That field is not selectable.  I can't click into it, I can't tab into
> > it, and I can't paste into it.
> 
> The problem seems to be that I typed in the "Name" field first, then
> erased it when no results were returned.  I closed the browser tab
> completely and started over.  Then I could click into the "Builds"
> field and do a search, which succeeded.  That typing into, then
> erasing the contents of, the "Name" field should affect the ability to
> select the "Builds" field is nonobvious and confusing.

Could you make tickets for your issues on https://github.com/fedora-infra/bodhi/
so we can track them?
Mailing list are really bad for tracking issues :)

Thanks for your feedback and sorry for the inconvenience :(

Pierre
___
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

[Bug 1771576] New: perl-HTTP-Cookies-6.06 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1771576

Bug ID: 1771576
   Summary: perl-HTTP-Cookies-6.06 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-Cookies
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.06
Current version/release in rawhide: 6.05-1.fc32
URL: http://search.cpan.org/dist/HTTP-Cookies/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2974/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 12. 11. 19 17:02, Aleksandra Fedorova wrote:

Again, no one forces you or any other packager to use modularity
tooling right now.

As Fedora developer you have a choice to join the effort, bring your
input and use cases, try and test (and revert if it doesn't work) or
you can stay away from it and keep using same tools as before.



Unfortunately, this is not true. It is not possible to ignore modularity, if the 
dependencies are modularized. It is not possible to ignore modularity, if the 
dependents are modularized. It is not possible to ignore modularity, if the 
packages I wish to use are modularized.


I wish Fedora packagers and users cold "stay away". But that is currently not 
possible. My proposal to keep all defaults as non-modular packages would make it 
exactly so.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The Official Complaint Thread

[Neal Gompa]

On Tue, Nov 12, 2019 at 11:03 AM Aleksandra Fedorova  wrote:
>
> Again, no one forces you or any other packager to use modularity
> tooling right now.
>

This is not true. Once content is modularized, things that were able
to depend on it in the normal form can no longer do so unless they too
modularize. This is an important consequence that I think people
championing for modularity keep forgetting. Everything from how the
build system works to how DNF implements modularity makes it so that
modular and non-modular content do not have an even footing. If they
did, I think we'd have less problems.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: The Official Complaint Thread

[Aleksandra Fedorova]

Hi, Igor,

On Tue, Nov 12, 2019 at 4:20 PM Igor Gnatenko
 wrote:
>
> On Tue, Nov 12, 2019, 14:13 Aleksandra Fedorova  wrote:
>>
>> Hi,
>>
>> On Tue, Nov 12, 2019 at 10:50 AM Dominik 'Rathann' Mierzejewski
>>  wrote:
>> >
>> > Hi.
>> > I've been silent so far, while mostly agreeing with the "let's just drop
>> > Modularity" proposal. This post hit a nerve, so I felt compelled to reply.
>> >
>> > On Monday, 11 November 2019 at 19:24, Stephen Gallagher wrote:
>> > > On Mon, Nov 11, 2019 at 1:15 PM Robbie Harwood  
>> > > wrote:
>> > [...]
>> > > > It's really frustrating to be repeatedly told we're not arguing in good
>> > > > faith and then see things like this (from today's fesco meeting [1]):
>> > > >
>> > > > 15:48:07  Can we please stop pretending like "start over
>> > > > from scratch" is a real option?
>> > > >
>> > > > Starting from scratch should be an option.  Removing modularity 
>> > > > entirely
>> > > > should be an option.  Of course, so should be using modularity as it
>> > > > exists (or modifying it), but if we don't have those first two as
>> > > > options when there are proponents, this isn't a real technical
>> > > > discussion.
>> > >
>> > > That quote is not fully in context, but that's entirely fair because I
>> > > didn't include enough context during the FESCo meeting. I apologize
>> > > for that. (Also, as you can tell from the rest of the log, I was
>> > > getting frustrated by that point).
>> > >
>> > > When I said it's not a real option, I did not include any of my
>> > > reasoning (thus Begging the Question as you rightly point out). My
>> > > reasoning is basically this:
>> > >
>> > > * Everyone on the Modularity Team is being paid by Red Hat to work on
>> > > Modularity.
>> > > * Red Hat Enterprise Linux 8 shipped with Modularity.
>> > > * The Modularity Team is responsible for maintaining that in RHEL 8
>> > > regardless of what happens in Fedora.
>> >
>> > None of the above should matter for the purpose of selecting the best
>> > technical solution to the current issues, even if it means admitting
>> > that Modularity as currently implemented is causing too many issues that
>> > can't be fixed in reasonable time and abandoning it altogether.
>> >
>> > > * A full redesign in Fedora is not realistically possible with the
>> > > people and resources we have available to us while also maintaining
>> > > the current implementation for ten years.
>> >
>> > Then just drop it. SCLs are an example of a Red Hat-only solution.
>> > Modularity tried to do better and failed in Fedora, so let it remain Red
>> > Hat-only, too, while an even better solution is invented. Or, perhaps,
>> > as various folks have been saying, maybe Fedora just doesn't need SCLs,
>> > Modularity or any similar solutions. Let Red Hat cater to its corporate
>> > customers and experiment with Red Hat-specific solutions in CentOS and
>> > let Fedora not be constrained by what makes sense only in a LTS enterprise
>> > distribution.
>> >
>> > > * Therefore we are focused on trying to get the current implementation
>> > > into better shape (and/or finding a safe migration strategy to a new
>> > > solution) rather than start from an entirely green field.
>> >
>> > If you mean "we, the Modularity team" then I can understand, but still
>> > the option to just drop the whole thing from Fedora looks more appealing
>> > than just wasting more time and effort on piling up technical debt.
>> > Sound arguments were made against some of the stated goals of Modularity
>> > like private buildroot packages and the rest can be implemented using
>> > the existing tools. I fail to see what advantages Modularity has brought
>> > us so far, while the disadvantages are pretty clear.
>>
>> I am going to disagree on several points here:
>>
>> 1) I don't think Modularity is about being LTS and "enterprisy".
>> Lifecycle differences are not the only feature Modularity provides.
>>
>> I see Modularity as a tool which bridges the gap between container
>> world and a packaged distribution.
>>
>> Without modularity we have a base system with its limitations and the
>> explosion of containerized solutions which currently go through their
>> teen-age phase, denying the good old known practices and reinventing
>> wheels in terms of packaging, sharing, deduplication of effort and
>> security audit.
>>
>> Modularity allows us to use packaging approaches in a more flexible
>> but still controlled and maintained way. It creates building blocks
>> for containerized environments.
>> I think it is the way to go for Flatpacks, cloud images and other
>> layered solutions to use runtimes built on top of packaged streams,
>> rather than custom configurations.
>>
>> And I think it is in scope of Fedora to drive this process to
>> normalize the currently chaotic container world.
>>
>> 2) I don't think Modularity is a failure in its current state.
>>
>> Yes, we do have a problem of default streams. There are several
>> reasons for that.
>>
>> One thing 

Re: Bodhi Outage Ongoing - Deploying 5.0

[Jerry James]

On Tue, Nov 12, 2019 at 8:27 AM Jerry James  wrote:
> 2. It is not possible to create a newpackage update with the GUI.
> I've got a brand new package, gap-pkg-fining, with a brand new build
> for F31.  I type "gap-pkg-fining" into the "Name" field, and it tells
> me that it cannot find the package [1].  Okay, I will just paste the
> build into the "Builds" field like I've done before.  Except I can't.
> That field is not selectable.  I can't click into it, I can't tab into
> it, and I can't paste into it.

The problem seems to be that I typed in the "Name" field first, then
erased it when no results were returned.  I closed the browser tab
completely and started over.  Then I could click into the "Builds"
field and do a search, which succeeded.  That typing into, then
erasing the contents of, the "Name" field should affect the ability to
select the "Builds" field is nonobvious and confusing.
-- 
Jerry James
http://www.jamezone.org/
___
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: Bodhi Outage Ongoing - Deploying 5.0

[Jerry James]

On Tue, Nov 12, 2019 at 7:42 AM Neal Gompa  wrote:
> I think you're underestimating how different the UI is with 5.0. I
> don't know where anything is yet... It looks slick, but it'll take
> some getting used to...

It does look slick, but here are two issues I've already run into with it.

1. The type, severity, and suggestion used to be radio buttons.  That
meant 1 mouse click was needed for each.  Now they are drop-down
menus, which means 2 mouse clicks are needed for each, with mouse
motion in between.  This is less friendly to those with physical
limitations (e.g., those suffering from carpal tunnel syndrome).  I,
personally, would like those to go back to radio buttons, please.

2. It is not possible to create a newpackage update with the GUI.
I've got a brand new package, gap-pkg-fining, with a brand new build
for F31.  I type "gap-pkg-fining" into the "Name" field, and it tells
me that it cannot find the package [1].  Okay, I will just paste the
build into the "Builds" field like I've done before.  Except I can't.
That field is not selectable.  I can't click into it, I can't tab into
it, and I can't paste into it.

Footnotes:
[1] This is nothing new.  There has been significant lag between
creation of a new package and bodhi becoming able to find it since the
retirement of pkgdb.  I recently (end of October) created an update
for a package that was initially created in late February, 8 months
earlier, and bodhi still couldn't find it.  I can understand that 30
seconds is too little time for a database update after creation of a
package.  I can even understand that 5 minutes might not be enough.
But why isn't 1 hour sufficient?  Eight months strikes me as utterly
ridiculous.  Those working on the initiative to improve the packager
experience: please look at doing something about this.  Slick tools
that autocomplete on package names are significantly less useful if
they're drawing from a database that is the better part of a year out
of date.
-- 
Jerry James
http://www.jamezone.org/
___
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