Re: [atomic-announce] Fedora Atomic Host Two Week Release Announcement: 29.20191013.0

[Sinny Kumari]

On Mon, Oct 14, 2019 at 11:00 PM  wrote:

>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 29.20191013.0
> Commit(x86_64):
> 1766b4526f1a738ba1e6e0a66264139f65340bcc28e7045f10cbe6d161eb1925
> Commit(aarch64):
> e2081395bb82ba1653da77e28e69448dd508613db1855ef52834087c67e67c05
> Commit(ppc64le):
> 06199fc2df5f3edbbcfbf2867662bdd7ce6eae6fbc31b9123ee6f57244b84be0
>
>
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
>
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
>
> Corresponding image media for new installations can be downloaded from:
>
> https://getfedora.org/en/atomic/download/
>
> Alternatively, image artifacts can be found at the following links:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191013.0.aarch64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191013.0.aarch64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20191013.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191013.0.ppc64le.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191013.0.ppc64le.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20191013.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191013.0.x86_64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191013.0.x86_64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191013.0.x86_64.vagrant-libvirt.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191013.0.x86_64.vagrant-virtualbox.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20191013.0.iso
>
> Respective signed CHECKSUM files can be found here:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191013.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20191013.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191013.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20191013.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191013.0-x86_64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20191013.0-x86_64-CHECKSUM
>
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
>
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
>
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filenam

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-10-15 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting).



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

___
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: Modules in Non-Modular Buildroot

[Kevin Kofler]

Joe Orton wrote:
> I find myself a bit reluctant to write this mail because the language
> others are using in this thread is fairly ugly for a technical
> discussion in an open source project - about "forcing" people to develop
> packages in a certain way, "teaching them a lesson" etc.  Please calm it
> down & have some respect for technical decisions of other developers.

I am sorry if my wording irritated you. However, I would like to point out 
that…

> For some people here it is clear they don't want to develop modules and
> that will always be fine.  Others see a benefit (whether small or large)
> from developing as modules, and that should also be fine and I want
> Fedora to allow that.  Allowing modules in buildroots prevents the
> conflict between packagers who make different choices (e.g. non-modular
> Eclipse can't use module-only Maven) so seems like a good compromise.

… this is not a complete solution, because it is taking the end users 
entirely out of the equation. Allowing modules in buildroots will have no 
impact on the end user.

The net result of this proposed Change for the end user is still the same as 
the status quo: They have to use modules whether they want to or not, the 
choice is taken away from them. And while the default stream approach tries 
to hide Modularity from the users (and with this proposed Change, also from 
the packagers of dependent packages), the abstraction is leaky, as 
evidenced, e.g., by the libgit2 upgrade blocker.

I think it is not fair to force modules onto all users of the distribution 
just because it is the technical preference of a few individual developers. 
Because, in the end, it is the developers who choose to make their packages 
module-only who are forcing their way onto all users (and other developers, 
too). My proposal would only "force" the developers to give the choice back 
to the users. So I do not see myself as being the one forcing their way onto 
others. I am sorry if my suboptimal wording gave you that unfortunate 
impression.

If the user wishes to use a non-default version of a package, sure, 
Modularity can help them. But otherwise, modules should not be a requirement 
to use the distribution. There is no technical necessity for that.

Requiring packages to have a non-modular version in the non-modular 
repository does in no way preclude providing alternate versions in modules, 
so I do not see how that proposal would impede developing modules if the 
maintainer wishes to do that.

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: FreeCAD required updates (PySide2 & Coin4)

[Richard Shaw]

Just following up if there is a consensus here. If I'm not moving FreeCAD
to Coin4 on F30/31 then I'm going to at least rebuilt with PySide2.

Thanks,
Richard
___
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: Packaging graph-tool: help speeding up build

[Ankur Sinha]

On Mon, Oct 14, 2019 21:02:49 +0200, Christopher Engelhard wrote:
> Hi,

Hello,

> On 14.10.19 19:59, Ankur Sinha wrote:
> >> Is the documentation using parallel builds?
> > 
> > They don't say.
> 
> Seems unlikely, see below
> 
> > It uses configure/make/make install. I had run the build with make -j1
> > too, but that had seemed to run even slower.. I hadn't checked the
> > resource usage though, so maybe I'll run that again.
> 
> Using a single thread (by setting using %make_build -j1 or
> RPM_BUILD_NCPUS=1) takes ages but seems to work at least locally.
> 
> Still the RAM usage is nowhere near the 3GB your graph shows.
> 
> - Mostly gcc uses around 2GB, with assembler adding up to 4GB on
> occasion, very briefly.
> 
> - Some of the make steps are insane:
> Biggest offenders so far seem to be graph_blockmodel_imp.lo with 10GB
> for gcc + 4GB assembler, followed by graph_assortativity.lo with 6GB gcc
> + 4GB assembler, and a few others with 4-5GB gcc + 3-4GB assembler.
> Throw multi-threading into the mix and this will easily add up to the
> memory usage you're seeing (It totally killed my test server, that's for
> sure.
> 
> I have no idea what hardware koji is using, so even single-threaded,
> this might be an issue, but I'd still give it a try.

Thank you for investigating. I'm running a local mock build with a
single thread, and that seems to be ticking along at the moment.
Hopefully that'll do with Koji too.

Out of curiosity, how long did the build take on your machine there?

> 
> Christopher
> 
> P.S.: The linked spec file only works for me if I use
> %autosetup -S git -n %{modname}-%{version}
> because the archive doesn't unpack to packagename-version.ext

Ugh, yes! I renamed the spec to "python-graph-tool" form "graph-tool"
and forgot to update the autosetup command there. Corrected that now.


-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Packaging graph-tool: help speeding up build

[Christopher Engelhard]

Hi,

On 14.10.19 19:59, Ankur Sinha wrote:
>> Is the documentation using parallel builds?
> 
> They don't say.

Seems unlikely, see below

> It uses configure/make/make install. I had run the build with make -j1
> too, but that had seemed to run even slower.. I hadn't checked the
> resource usage though, so maybe I'll run that again.

Using a single thread (by setting using %make_build -j1 or
RPM_BUILD_NCPUS=1) takes ages but seems to work at least locally.

Still the RAM usage is nowhere near the 3GB your graph shows.

- Mostly gcc uses around 2GB, with assembler adding up to 4GB on
occasion, very briefly.

- Some of the make steps are insane:
Biggest offenders so far seem to be graph_blockmodel_imp.lo with 10GB
for gcc + 4GB assembler, followed by graph_assortativity.lo with 6GB gcc
+ 4GB assembler, and a few others with 4-5GB gcc + 3-4GB assembler.
Throw multi-threading into the mix and this will easily add up to the
memory usage you're seeing (It totally killed my test server, that's for
sure.

I have no idea what hardware koji is using, so even single-threaded,
this might be an issue, but I'd still give it a try.

Christopher

P.S.: The linked spec file only works for me if I use
%autosetup -S git -n %{modname}-%{version}
because the archive doesn't unpack to packagename-version.ext


> ___
> 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: Packaging graph-tool: help speeding up build

[Ankur Sinha]

On Mon, Oct 14, 2019 10:54:40 -0500, Richard Shaw wrote:
> On Mon, Oct 14, 2019 at 10:51 AM Ankur Sinha  wrote:
> 
> Hello,
> 
> I'm working on packaging up graph-tool[1] for SciTech/NeuroFedora. The
> spec file is a WIP here[2].  I've not yet managed to complete a
> build---it managed to get my F31 server machine to go completely
> unresponsive when I had tried last evening---used up all the memory
> (32G) and most of the swap (15G). Upstream documents that they make
> heavy use of templates[3], and so the builds take quite a bit of time.
> 
> My scratch build here has been running for ~7 hours now[4]. Any
> tips/tricks on speeding up the build?
> 
> 
> Is the documentation using parallel builds?

They don't say.

> Can you patch to to use a single thread? 

It uses configure/make/make install. I had run the build with make -j1
too, but that had seemed to run even slower.. I hadn't checked the
resource usage though, so maybe I'll run that again.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Fedora Atomic Host Two Week Release Announcement: 29.20191013.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20191013.0
Commit(x86_64): 1766b4526f1a738ba1e6e0a66264139f65340bcc28e7045f10cbe6d161eb1925
Commit(aarch64): 
e2081395bb82ba1653da77e28e69448dd508613db1855ef52834087c67e67c05
Commit(ppc64le): 
06199fc2df5f3edbbcfbf2867662bdd7ce6eae6fbc31b9123ee6f57244b84be0


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191013.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191013.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20191013.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191013.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191013.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20191013.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191013.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191013.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191013.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191013.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20191013.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191013.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20191013.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191013.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20191013.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191013.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191013.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20191013.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam

Re: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 14. 10. 19 18:39, Vojtěch Trefný wrote:



On 2019-10-14 18:06, Miro Hrončok wrote:

The following packages are orphaned and will be retired when they



weeks ago
sl    orphan   1
weeks ago


Taken, we can't have distribution without sl :-)


I was really worried that would happen, but you've saved us all!

--
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: Orphaned packages looking for new maintainers

[Vojtěch Trefný]

On 2019-10-14 18:06, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they

> weeks ago
> sl    orphan   1
> weeks ago

Taken, we can't have distribution without sl :-)

--
vtrefny
___
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: Modules in Non-Modular Buildroot

[Miro Hrončok]

On 10. 10. 19 0:46, Miro Hrončok wrote:> What I miss in the description is:


1. How does this thing actually work? is there an additional repository composed 
from the default streams available in Koji only?


2. How are conflicts between packages from the default streams and ursine 
package be handled?


3. What is the local experience if the packager is using mock. What if they are 
using rpmbuild directly?


4. How are we handling default streams with dependencies on non-default streams 
of other modules?


I realize that the discussion got side tracked because of my other higher level 
concerns, but I'd still like to know about this.


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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-10-14.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

PyRTF orphan   5 weeks ago
RackTablesorphan   5 weeks ago
TeXamator orphan   5 weeks ago
XmlSchema msimacek, orphan 5 weeks ago
alacarte  alexl, caillon, caolanm, 4 weeks ago
  johnp, mbarnes, orphan,
  rhughes, ssp
anyremote orphan   5 weeks ago
apache-commons-launcher   orphan   5 weeks ago
audio-convert-mod orphan   4 weeks ago
batti orphan   4 weeks ago
bios_extract  orphan   5 weeks ago
bzr   orphan   2 weeks ago
captcporphan   5 weeks ago
cassandra acaringi, hhorak, jjanco,3 weeks ago
  orphan, rimolive
castor-maven-plugin   orphan   2 weeks ago
cbi-plugins   eclipse-sig, kdaniel, orphan,3 weeks ago
  rgrunber
certmasteralikins, orphan, robert, 5 weeks ago
  wakko666
check-mk  orphan   5 weeks ago
chm2pdf   orphan   4 weeks ago
comedilib orphan   5 weeks ago
concurrentunitorphan   5 weeks ago
diffuse   cicku, fab, orphan   1 weeks ago
drobo-utils   imntreal, orphan 5 weeks ago
eclipse-dtp   eclipse-sig, galileo, kdaniel,   3 weeks ago
  mbooth, orphan
eclipse-ecf   eclipse-sig, kdaniel, orphan,3 weeks ago
  rgrunber
eclipse-eclemma   eclipse-sig, jerboaa, kdaniel,   3 weeks ago
  orphan, rgrunber
eclipse-egit-github   eclipse-sig, orphan  3 weeks ago
eclipse-linuxtoolseclipse-sig, jjohnstn, orphan,   3 weeks ago
  rgrunber
eclipse-moreunit  jerboaa, orphan  3 weeks ago
eclipse-mpc   eclipse-sig, kdaniel, orphan,3 weeks ago
  rgrunber
eclipse-mylyn arobinso, eclipse-sig,   3 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-packagekiteclipse-sig, jerboaa, kdaniel,   3 weeks ago
  orphan, rgrunber
eclipse-pydev eclipse-sig, jjohnstn, orphan3 weeks ago
eclipse-swtboteclipse-sig, orphan  3 weeks ago
eclipse-tm-terminal   eclipse-sig, orphan  3 weeks ago
epydocorphan, thias5 weeks ago
euca2ools orphan   4 weeks ago
felix-mainorphan   5 weeks ago
fishpoll  marionline, orphan   5 weeks ago
freemedforms  nobrakal, orphan 3 weeks ago
freenx-server orphan   5 weeks ago
func  alikins, orphan, robert, 4 weeks ago
  wakko666
fuse-python   moezroy, orphan  5 weeks ago
gadgeto

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Miro Hrončok]

On 14. 10. 19 15:44, Joe Orton wrote:

I find myself a bit reluctant to write this mail because the language
others are using in this thread is fairly ugly for a technical
discussion in an open source project - about "forcing" people to develop
packages in a certain way, "teaching them a lesson" etc.  Please calm it
down & have some respect for technical decisions of other developers.


I completely agree with this message.

I don't agree with where modularity is going in Fedora, but it doesn't mean I 
don't like the people involved ;)


On the technical side, iff we decide to ban default modular stream, I don't 
think we should force people or teach them a lesson, I think we need to 
coordinate a huge effort to make everything work again - together.


--
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: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Miro Hrončok]

On 14. 10. 19 12:16, Kevin Kofler wrote:

Enable module default streams in the buildroot repository for modular
and non-modular RPMs.

== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
"traditional") RPMs.

== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com
* Responsible WG: Modularity WG


I have already stated this multiple times in other threads, but just so that
nobody claims that I have not given feedback to this change (which has been
claimed for some other changes in a similar situation), I am going to state
this again:

I oppose this change because I believe Miro's proposal to require all
packages to have a non-modular version (i.e., to ship the default stream as
non-modular packages) is the much better approach to the issue and makes
this change proposal entirely moot.

...
* The fedora-modular repository SHOULD be disabled by default on user
   machines, matching the current build system behavior. This also helps
   enforcing the above policies.


As long as we enforce the policy of no default streams, this is actually 
unnecessary. Modules will only be used when people do "dnf module ...".


Regardless whether this is a good or a wrong idea, just makign clear that I have 
never proposed to disable modular repos by default.


OTOH I propose that disabling modular repos must be considered a legitimate 
action and the distro must remain it's core functionality.



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

Packaging graph-tool: help speeding up build

[Ankur Sinha]

Hello,

I'm working on packaging up graph-tool[1] for SciTech/NeuroFedora. The
spec file is a WIP here[2].  I've not yet managed to complete a
build---it managed to get my F31 server machine to go completely
unresponsive when I had tried last evening---used up all the memory
(32G) and most of the swap (15G). Upstream documents that they make
heavy use of templates[3], and so the builds take quite a bit of time.

My scratch build here has been running for ~7 hours now[4]. Any
tips/tricks on speeding up the build?

[1] https://graph-tool.skewed.de/
[2] https://pagure.io/neuro-sig/graph-tool/blob/master/f/python-graph-tool.spec
[3] 
https://git.skewed.de/count0/graph-tool/wikis/installation-instructions#memory-requirements-for-compilation
[4] https://koji.fedoraproject.org/koji/taskinfo?taskID=38289031

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Modularity and the system-upgrade path

[Stephen John Smoogen]

On Sun, 13 Oct 2019 at 16:28, Matthew Miller  wrote:
>
> On Fri, Oct 11, 2019 at 05:53:26PM -0400, Stephen John Smoogen wrote:
> > There has been a shrinking packager problem for years due to multiple 
> > problems
>
> Has there? I'm not really seeing a significant change in the number of
> people making changes in dist-git over time. See attached svg. Maybe a
> little down from 2013-2016, but seems mostly flat 2016-2019.
>
> It's not significantly growing, which may be a problem itself, but let's not
> get over-dramatic without evidence.
>
> https://mattdm.org/fedora/fedora-contributor-trends/git.user.count.svg
>

I think we are talking about 2 different things, and I should have
been clearer in my first reply to explain that.

You are showing we have a constant number of contributors. I was
thinking about active contributors per artifact. Using the charts you
provided, a conservative number would be we have had a near constant
300 active maintainers from 2012 to 2019. There have been dips and
peaks but that seems to be about what we keep.

On this day in 2012, there were 3 releases 16, 17, 18 that these 300
maintainers would have been covering.

16: 10929 src.rpms
17: 11614 src.rpms
18: 12614 src.rpms

(10929+11614+12614) / 300 avg active git users = 117 packages per
active git user. If we assume 16 and 17 were not getting much
attention as 18 was trying to get out the door, we have 42 packages
per active participant.

On this day (2019-10-14) in 2019, there are 3 releases which look like
the following:

29: 21847 (Everything Srpms) 708 modular srpms
30: 21292 (Everything Srpms) 472 modular srpms
31: 21191 (Everything Srpms) 911 modular srpms

(21847+21292+21191+708+472+911) / 300 avg active git users = 221
packages per active git user. Again assuming people are just looking
at 31, it is 73 packages / active git user. If we had a steady state
growth in maintainers we would need 226 more active git contributors
at the moment.

If we look at instead of src.rpms but looking at how many deliverables
(aka how many arch.rpm/noarch.rpm) we have in F18 we had 40156
packages in x86_64. In F31 we have 89218 rpms + 3188 mod-rpms (92406).
So we moved from 133 rpms per active git maintainer to 308 rpms per
active git maintainer. In this case we would currently be at 670
active participants.

So from that perception it "feels" like we have a shrinking packager
problem. If we had a growing packager set then either we would be
still near 133 rpms or less. And again I realize that this isn't a
rational count. We would need to work out how many packages get
changed per release, what the average amount of packages are for the
actual active people per time.. someone might have taken 100 packages
in 2015, worked really hard until 2017 and now is no longer involved.
Other factors change what the count means as packages are broken down
and remerged into different things (aka TeX)





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

Fedora-31-20191014.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 6/153 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20191013.n.0):

ID: 469384  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/469384
ID: 469401  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/469401
ID: 469471  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/469471
ID: 469477  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/469477
ID: 469485  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/469485

Old failures (same test failed in Fedora-31-20191013.n.0):

ID: 469343  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/469343
ID: 469405  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/469405

Soft failed openQA tests: 10/153 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-31-20191013.n.0):

ID: 469369  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/469369

Old soft failures (same test soft failed in Fedora-31-20191013.n.0):

ID: 469382  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/469382
ID: 469432  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/469432
ID: 469433  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/469433
ID: 469452  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/469452
ID: 469453  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/469453
ID: 469454  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/469454
ID: 469455  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/469455
ID: 469461  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/469461
ID: 469491  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/469491

Passed openQA tests: 137/153 (x86_64)

New passes (same test not passed in Fedora-31-20191013.n.0):

ID: 469392  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/469392

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Average CPU usage changed from 6.80476190 to 19.2333
Previous test data: https://openqa.fedoraproject.org/tests/468715#downloads
Current test data: https://openqa.fedoraproject.org/tests/469374#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.57 to 0.37
Previous test data: https://openqa.fedoraproject.org/tests/468598#downloads
Current test data: https://openqa.fedoraproject.org/tests/469376#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 712 MiB to 887 MiB
System load changed from 0.51 to 2.43
Average CPU usage changed from 1.70952381 to 32.08095238
Previous test data: https://openqa.fedoraproject.org/tests/468611#downloads
Current test data: https://openqa.fedoraproject.org/tests/469389#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used mem changed from 973 MiB to 867 MiB
System load changed from 2.20 to 1.15
Previous test data: https://openqa.fedoraproject.org/tests/468613#downloads
Current test data: https://openqa.fedoraproject.org/tests/469391#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used swap changed from 7 MiB to 6 MiB
System load changed from 0.79 to 0.59
Previous test data: https://openqa.fedoraproject.org/tests/468629#downloads
Current test data: https://openqa.fedoraproject.org/tests/469407#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Used swap changed from 7 MiB to 3 MiB
Previous test data: https://openqa.fedoraproject.org/tests/468631#downloads
Current test data: https://openqa.fedoraproject.org/tests/469409#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used mem changed from 779 MiB to 898 MiB
System load changed from 0.26 to 0.41
Average CPU usage changed from 1.84761905 to 20.08095238
Previous test data: https://openqa.fedoraproject.org/tests/468704#downloads
Current test data: https://openqa.fedoraproject.org/tests/469482#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose

Fedora 31 compose report: 20191014.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20191013.n.0
NEW: Fedora-31-20191014.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   4
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   64.83 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -39.23 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-31-20191014.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  fedora-release-31-1
Old package:  fedora-release-31-0.11
Summary:  Fedora release files
RPMs: fedora-release fedora-release-cinnamon fedora-release-cloud 
fedora-release-common fedora-release-container fedora-release-coreos 
fedora-release-iot fedora-release-kde fedora-release-matecompiz 
fedora-release-server fedora-release-silverblue fedora-release-snappy 
fedora-release-soas fedora-release-workstation fedora-release-xfce
Size: 188.44 KiB
Size change:  -466 B
Changelog:
  * Thu Oct 10 2019 Mohan Boddu  31-1
  - Setup for F31 Final


Package:  fedora-repos-31-1
Old package:  fedora-repos-31-0.6
Summary:  Fedora package repositories
RPMs: fedora-gpg-keys fedora-repos fedora-repos-ostree 
fedora-repos-rawhide
Size: 126.59 KiB
Size change:  217 B
Changelog:
  * Thu Oct 10 2019 Mohan Boddu  - 31-1
  - Setup for F31 Final


Package:  gnome-control-center-3.34.1-4.fc31
Old package:  gnome-control-center-3.34.1-3.fc31
Summary:  Utilities to configure the GNOME desktop
RPMs: gnome-control-center gnome-control-center-filesystem
Size: 27.60 MiB
Size change:  2.70 KiB
Changelog:
  * Thu Oct 10 2019 Adam Williamson  - 3.34.1-4
  - Add patch to fix crash when selecting display with no modes (rhbz#1756553)


Package:  grub2-1:2.02-100.fc31
Old package:  grub2-1:2.02-97.fc31
Summary:  Bootloader with support for Linux, Multiboot and more
RPMs: grub2-common grub2-efi-aa64 grub2-efi-aa64-cdboot 
grub2-efi-aa64-modules grub2-efi-arm grub2-efi-arm-cdboot grub2-efi-arm-modules 
grub2-efi-ia32 grub2-efi-ia32-cdboot grub2-efi-ia32-modules grub2-efi-x64 
grub2-efi-x64-cdboot grub2-efi-x64-modules grub2-emu grub2-emu-modules grub2-pc 
grub2-pc-modules grub2-ppc64le grub2-ppc64le-modules grub2-tools 
grub2-tools-efi grub2-tools-extra grub2-tools-minimal
Size: 36.92 MiB
Size change:  -41.69 KiB
Changelog:
  * Fri Oct 04 2019 Javier Martinez Canillas  - 2.02-98
  - Don't add a class option to menu entries generated for ppc64le
Resolves: rhbz#1758225

  * Wed Oct 09 2019 Javier Martinez Canillas  - 2.02-99
  - 99-grub-mkconfig: Disable BLS usage for Xen DomU guests
Resolves: rhbz#1703700

  * Thu Oct 10 2019 Javier Martinez Canillas  - 2.02-100
  - 99-grub-mkconfig: Fix script condition to exit and remove ppc64 BE check
Related: rhbz#1703700



= DOWNGRADED PACKAGES =
___
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: tmt, a tool for testing

[Miroslav Suchý]

Dne 14. 10. 19 v 14:56 Petr Šplíchal napsal(a):

The easiest way how to start experimenting with the latest bits is
to install the tool directly from the git repo as it contains also
a set of real life tests/plans/stories for instant experimenting:

 mkvirtualenv tmt # use [3] to install virtualenvwrapper
 git clonehttps://github.com/psss/tmt
 cd tmt
 pip install -e .


This can even more easy if you provide Copr repository. Then it can be:
  dnf copr enable FOO
  dnf install BAR
Especially when Packit is already able to build it in Copr.
--
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

Re: Recommending proprietary software in Fedora

[mcatanzaro]

On Mon, Oct 14, 2019 at 4:19 PM, John M. Harris Jr 
 wrote:

And proprietary software, in your opinion, does not?


The requirements for including proprietary software are spelled out 
just two paragraphs above the section on legal requirements:


"""
Software not deemed "free" by Fedora standards, for instance Google 
Chrome, would be labelled both "third party" and "nonfree" for not 
conforming to Fedora's definition of free. Over time further labels may 
be introduced to further inform users. For the Workstation edition, 
this labelling will be clearly visible in GNOME Software, the primary 
software installer for the desktop. For other editions and tools, the 
maintainers of said installers would need to work with FESCo to decide 
how to provide this labelling information in the relevant tools.

"""

It should be beyond doubt that proprietary software was considered when 
writing the policy. Then we have one paragraph on "Principles," which 
I'll skip. Then we have the legal requirements:


"""
Just as with any software hosted by Fedora, third party software must 
not contain material that poses undue legal risk for the Fedora Project 
or its sponsors. This includes, but is not limited to, software with 
known patent issues, copyright issues or software tailored for 
conducting illegal activities. The Fedora working groups will evaluate 
if a proposed addition or provider poses a significant risk, and if in 
doubt confer with Fedora Legal for advice.

"""

It only requires legal approval for software with known patent issues, 
copyright issues, or software tailored for conducting illegal 
activities (which means penetration testing tools).


The rules require that repos containing proprietary software not be 
searchable by default, only upon opt-in user consent. Furthermore, 
after consent, the installed repos are still disabled; they are used 
only for metadata to present search results. A repo will only be 
enabled once software from that repo is installed. The point of this 
policy was to make it easier for users to install software like the 
NVIDIA proprietary driver, Google Chrome, etc. It was a difficult 
compromise between keeping Fedora itself fully free, but also making 
sure users who want certain popular software don't feel like it would 
be easier to just use other distros instead.


Steam has already been included since Fedora 28 [1].

Michael

[1] 

___
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: Schedule for Mondays's FESCo Meeting (2019-10-14)

[Zbigniew Jędrzejewski-Szmek]

I forgot to add:
sorry for sending this out so late. I composed the mail but forgot to
actually send it ;(

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: Recommending proprietary software in Fedora

[John M. Harris Jr]

On Monday, October 14, 2019 6:12:18 AM MST mcatanz...@gnome.org wrote:
> On Mon, Oct 14, 2019 at 11:49 AM, John M. Harris Jr
> 
>  wrote:
> > It's good that we can
> > reference external repositories such as rpmfusion-free, in my opinion.
> 
> We actually cannot do that. It is prohibited because it would entail
> significant risk.

And proprietary software, in your opinion, does not?

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

Schedule for Mondays's FESCo Meeting (2019-10-14)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-10-14 15:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

= Followups =

= New business =

#2241 F32 Self-Contained Change: Better Thermal Management for the Workstation 
https://pagure.io/fesco/issue/2241

#2246 Create a rule to get newly Fedora branched composes sooner
https://pagure.io/fesco/issue/2246

https://bugzilla.redhat.com/show_bug.cgi?id=1747408
We don't have any ticket for this, but I think FESCo should weigh in on the
proposed solution.

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
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: Modules in Non-Modular Buildroot

[Joe Orton]

On Wed, Oct 09, 2019 at 04:46:52PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> 
> Enable module default streams in the buildroot repository for modular
> and non-modular RPMs.
> 
> == Summary ==
> This Change (colloquially referred to as "Ursa Prime") enables the
> Koji build-system to include the RPM artifacts provided by module
> default streams in the buildroot when building non-modular (or
> "traditional") RPMs.
> 
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
> * Responsible WG: Modularity WG

Thanks for writing this up Stephen, I fully support this.

For some people here it is clear they don't want to develop modules and 
that will always be fine.  Others see a benefit (whether small or large) 
from developing as modules, and that should also be fine and I want 
Fedora to allow that.  Allowing modules in buildroots prevents the 
conflict between packagers who make different choices (e.g. non-modular 
Eclipse can't use module-only Maven) so seems like a good compromise.

I find myself a bit reluctant to write this mail because the language 
others are using in this thread is fairly ugly for a technical 
discussion in an open source project - about "forcing" people to develop 
packages in a certain way, "teaching them a lesson" etc.  Please calm it 
down & have some respect for technical decisions of other developers.

Regards, Joe
___
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: Recommending proprietary software in Fedora

[mcatanzaro]

On Mon, Oct 14, 2019 at 11:49 AM, John M. Harris Jr 
 wrote:

It's good that we can
reference external repositories such as rpmfusion-free, in my opinion.


We actually cannot do that. It is prohibited because it would entail 
significant risk.


___
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

tmt, a tool for testing

[Petr Šplíchal]

Hi!

With a couple of qe & devel guys who are involved in the CI
effort we've started work on creating tmt, a tool for testing.
Why? We've got a bunch of dreams [1] and we would like to:

* run, debug and develop tests in much more comfortable way [2]
* open source more tests and run them closer to the upstream
* make creating and enabling tests in the CI more user friendly

We've put together the first proof-of-concept which outlines the
command line syntax. We would like to ask for early feedback and
invite anybody who would like to collaborate on this to join us:

https://github.com/psss/tmt

The easiest way how to start experimenting with the latest bits is
to install the tool directly from the git repo as it contains also
a set of real life tests/plans/stories for instant experimenting:

mkvirtualenv tmt # use [3] to install virtualenvwrapper
git clone https://github.com/psss/tmt
cd tmt
pip install -e .
tmt
tmt test ls
tmt plan show
tmt story show create
tmt story coverage --implemented
...

By creating the tool we aim to implement the L1 and L2 metadata
specification [4] and cover user stories [5] which we've gathered
so far. Feel free to review existing stories and provide feedback
or create new stories which are not covered yet.

Also note, that the repository has enabled Packit / Testing Farm
integration [6] which shows how you can automatically get test
results on copr builds directly in your pull requests, e.g. [7].

We are looking for any feedback.

psss...

[1] https://tmt.readthedocs.io/en/latest/dreams.html
[2] https://pagure.io/fedora-ci/general/issue/4
[3] dnf install -y python3-virtualenvwrapper && bash
[4] https://pagure.io/fedora-ci/metadata
[5] https://tmt.readthedocs.io/en/latest/stories.html
[6] https://packit.dev/testing-farm/
[7] https://github.com/psss/tmt/pull/9
___
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

Fedora rawhide compose report: 20191014.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191013.n.0
NEW: Fedora-Rawhide-20191014.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:61
Upgraded packages:   44
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:49.60 MiB
Size of upgraded packages:   332.00 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -27.74 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: access-modifier-annotation-1.7-9.fc31
Summary: Java annotation for custom access modifiers
RPMs:access-modifier-annotation access-modifier-annotation-javadoc 
access-modifier-checker
Size:80.38 KiB

Package: acegisecurity-1.0.7-12.fc31
Summary: Java/J2EE application security framework
RPMs:acegisecurity acegisecurity-javadoc
Size:1.01 MiB

Package: akuma-1.10-9.fc31
Summary: Embeddable daemonization library for Java
RPMs:akuma akuma-javadoc
Size:59.81 KiB

Package: annotation-indexer-1.9-10.fc31
Summary: Jenkins annotation-indexer library
RPMs:annotation-indexer annotation-indexer-javadoc
Size:47.03 KiB

Package: apache-commons-csv-1.7-2.fc31
Summary: Utilities to assist with handling of CSV files
RPMs:apache-commons-csv apache-commons-csv-javadoc
Size:107.79 KiB

Package: apache-commons-discovery-2:0.5-24.fc31
Summary: Apache Commons Discovery
RPMs:apache-commons-discovery apache-commons-discovery-javadoc
Size:170.28 KiB

Package: apache-commons-el-1.0-43.fc31
Summary: The Apache Commons Extension Language
RPMs:apache-commons-el apache-commons-el-javadoc
Size:196.34 KiB

Package: apache-mina-2.0.9-11.fc31
Summary: Apache MINA
RPMs:apache-mina apache-mina-javadoc apache-mina-mina-core 
apache-mina-mina-filter-compression apache-mina-mina-http 
apache-mina-mina-statemachine
Size:1.29 MiB

Package: apache-sshd-1:2.2.0-2.fc31
Summary: Apache SSHD
RPMs:apache-sshd apache-sshd-javadoc
Size:3.04 MiB

Package: arptools-1.0.2-19.fc31
Summary: Collection of libnet and libpcap based ARP utilities
RPMs:arptools
Size:139.59 KiB

Package: bridge-method-injector-1.14-11.fc31
Summary: Evolve Java classes without breaking compatibility
RPMs:bridge-method-annotation bridge-method-injector 
bridge-method-injector-javadoc
Size:62.95 KiB

Package: bundling-detection-java-0.1-0.13.20150611git.fc31
Summary: Bundling detection tool for Java
RPMs:bundling-detection-java
Size:34.06 KiB

Package: bytecode-compatibility-transformer-1.7-8.fc31
Summary: Evolve modular codebase without losing compatibility
RPMs:bytecode-compatibility-transformer 
bytecode-compatibility-transformer-javadoc
Size:60.94 KiB

Package: c3p0-0.9.5.4-2.fc31
Summary: JDBC DataSources/Resource Pools
RPMs:c3p0 c3p0-javadoc
Size:732.89 KiB

Package: constant-pool-scanner-1.2-14.fc31
Summary: Java constant pool scanner
RPMs:constant-pool-scanner constant-pool-scanner-javadoc
Size:72.35 KiB

Package: dwdiff-2.0.9-21.fc31
Summary: Front end to diff for comparing on a per word basis
RPMs:dwdiff
Size:395.09 KiB

Package: emma-2.0.5312-23.fc31
Summary: Code Coverage Tool
RPMs:emma emma-javadoc
Size:791.53 KiB

Package: fsniper-1.3.1-25.fc31
Summary: A tool that monitors directories for new files and invokes scripts on 
them
RPMs:fsniper
Size:246.03 KiB

Package: geronimo-jaspic-spec-1.1-19.fc31
Summary: Java Authentication SPI for Containers
RPMs:geronimo-jaspic-spec geronimo-jaspic-spec-javadoc
Size:93.36 KiB

Package: glassfish-jsp-2.3.3-0.15.b02.fc31
Summary: Glassfish J2EE JSP API implementation
RPMs:glassfish-jsp glassfish-jsp-javadoc
Size:738.69 KiB

Package: gmavenplus-plugin-1.5-8.fc31
Summary: Integrates Groovy into Maven projects
RPMs:gmavenplus-plugin gmavenplus-plugin-javadoc
Size:164.83 KiB

Package: gpars-1.2.1-14.fc31
Summary: Groovy Parallel Systems
RPMs:gpars
Size:565.00 KiB

Package: groovy-2.4.8-10.fc31
Summary: Dynamic language for the Java Platform
RPMs:groovy groovy-ant groovy-bsf groovy-console groovy-docgenerator 
groovy-groovydoc groovy-groovysh groovy-jmx groovy-json groovy-jsr223 
groovy-lib groovy-nio groovy-servlet groovy-sql groovy-swing groovy-templates 
groovy-test groovy-testng groovy-xml
Size:14.27 MiB

Package: groovy-sandbox-1.8-10.fc31
Summary: Groovy sandbox for executing untrusted Groovy scripts safely
RPMs:groovy-sandbox groovy-sandbox-javadoc
Size:121.60 KiB

Package: jBCrypt-0.4-10.fc31
Summary: Strong password hashing for Java
RPMs:jBCrypt
Size:21.45 KiB

Package: jboss-connector-1.7-api-1.0.1-1.fc32
Summary: Connector Architecture 1.7 API
RPMs:jboss-connector-1.7-api jboss-connector-1.7-api-javadoc
Size:222.71 KiB

Package: jboss-websocket-1.0-api-1.0.0-11.fc31
Summary: JSR-356: Java WebSocket 1.0 API
RPMs:jboss-websocket-1.0-api jboss-websocket

Fedora-Rawhide-20191014.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 45 required tests failed, 2 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

Failed openQA tests: 4/143 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20191013.n.0):

ID: 469039  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/469039
ID: 469076  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/469076
ID: 469123  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/469123

Old failures (same test failed in Fedora-Rawhide-20191013.n.0):

ID: 468991  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/468991
ID: 469053  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/469053

Soft failed openQA tests: 5/143 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Rawhide-20191013.n.0):

ID: 469030  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/469030
ID: 469045  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/469045
ID: 469092  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/469092
ID: 469097  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/469097
ID: 469099  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/469099

Passed openQA tests: 134/143 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20191013.n.0):

ID: 469040  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/469040
ID: 469049  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/469049

Skipped non-gating openQA tests: 1 of 145

Installed system changes in test x86_64 Server-boot-iso install_default: 
1 services(s) added since previous compose: pcscd.service
Previous test data: https://openqa.fedoraproject.org/tests/468414#downloads
Current test data: https://openqa.fedoraproject.org/tests/468985#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.04 to 0.21
Previous test data: https://openqa.fedoraproject.org/tests/468449#downloads
Current test data: https://openqa.fedoraproject.org/tests/469020#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.47 to 0.68
Previous test data: https://openqa.fedoraproject.org/tests/468453#downloads
Current test data: https://openqa.fedoraproject.org/tests/469024#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
1 services(s) added since previous compose: pcscd.service
System load changed from 2.52 to 2.63
Average CPU usage changed from 1.92380952 to 73.50952381
Previous test data: https://openqa.fedoraproject.org/tests/468466#downloads
Current test data: https://openqa.fedoraproject.org/tests/469037#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
1 services(s) removed since previous compose: pcscd.service
Previous test data: https://openqa.fedoraproject.org/tests/468549#downloads
Current test data: https://openqa.fedoraproject.org/tests/469120#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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

SONAME bump for libntirpc coming soon in f32/rawhide

[Kaleb Keithley]

I don't believe anything except nfs-ganesha uses libntirpc, but on the
off-chance that there is—

libntirpc will bump from 1.8 to 3.0

--

Kaleb
___
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: Modules in Non-Modular Buildroot

[Vitaly Zaitsev via devel]

On 14.10.2019 12:16, Kevin Kofler wrote:
> To be clear, I propose the following:
> * All packages MUST have a default version in any given Fedora release.
> * The default version MUST be shipped as non-modular (not as a modular
>   default stream).
> * It follows that packages cannot be module-only.
> * This applies to ALL packages including build tools. In particular,
>   packages must not be hidden from users through constructs such as
>   buildroot-only modules or non-API packages in modules. If a package is in
>   a module, no matter in what function, there MUST be a default version in
>   the non-modular repository.
> * The fedora-modular repository SHOULD be disabled by default on user
>   machines, matching the current build system behavior. This also helps
>   enforcing the above policies.

I totally agree with this proposals.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Defining the future of the packager workflow in Fedora

[Vít Ondruch]

Dne 11. 10. 19 v 23:34 Adam Williamson napsal(a):
> On Fri, 2019-10-11 at 17:10 -0400, Randy Barlow wrote:
>> On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
>>> No. Resolving conflicts implies that you need to do an actual merge,
>>> NOT a 
>>> fast forward. Fast-forwarding means that I am shipping the SAME
>>> commit on 
>>> all branches, so the changelog must be identical (unless I play games
>>> with 
>>> %if in the changelog, which is not going to happen).
>> The same commit is in all branches, there's just also a merge commit.
>> Subsequent commits that don't conflict do fast-forward.
>>
>>> In addition, resolving conflicts is extra work compared to a
>>> conflict-free 
>>> merge or ideally a fast-forward.
>> It's less work than the mental overhead of working in a spec file with
>> %if statements.
> That seems like a personal call, really. I very much like being able to
> keep branches in sync without merge commits as it means I can do stuff
> like:
>
> for i in el6 epel7 f29 f30 f31 master; do fedpkg switch-branch $i; git
> pull; git merge master; fedpkg push; fedpkg build --nowait; done


This is all nice, but it makes changes on all packages in Fedora a lot
harder. Therefore removing no longer used cruft etc is nearly
impossible. It prohibits Fedora to move forward. In general, %if
statements are causing just technical dept.

Also, during prepartion of RHEL8, I saw a lot of places where there were
conditions such as `%if 0%{?rhel} == 7` and in my experience, these were
not helpful at all. From condition like this, nobody can tell if it was
applied due to RHEL6 or RHEL7 or RHEL8. One typically need to start from
scratch and just test if it works or not.


Vít


> and I don't find it particularly onerous to deal with sensible
> conditionals. It all depends a lot on what you prefer as an individual
> and exactly how much difference there needs to be between branches.
___
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: Modules in Non-Modular Buildroot

[John M. Harris Jr]

On Monday, October 14, 2019 3:16:27 AM MST Kevin Kofler wrote:
> > Enable module default streams in the buildroot repository for modular
> > and non-modular RPMs.
> > 
> > == Summary ==
> > This Change (colloquially referred to as "Ursa Prime") enables the
> > Koji build-system to include the RPM artifacts provided by module
> > default streams in the buildroot when building non-modular (or
> > "traditional") RPMs.
> > 
> > == Owner ==
> > * Name: [[User:Sgallagh| Stephen Gallagher]]
> > * Email: sgall...@redhat.com
> > * Responsible WG: Modularity WG
> 
> 
> I have already stated this multiple times in other threads, but just so that
>  nobody claims that I have not given feedback to this change (which has
> been claimed for some other changes in a similar situation), I am going to
> state this again:
> 
> I oppose this change because I believe Miro's proposal to require all 
> packages to have a non-modular version (i.e., to ship the default stream as
>  non-modular packages) is the much better approach to the issue and makes
> this change proposal entirely moot.
> 
> To be clear, I propose the following:
> * All packages MUST have a default version in any given Fedora release.
> * The default version MUST be shipped as non-modular (not as a modular
>   default stream).
> * It follows that packages cannot be module-only.
> * This applies to ALL packages including build tools. In particular,
>   packages must not be hidden from users through constructs such as
>   buildroot-only modules or non-API packages in modules. If a package is in
> a module, no matter in what function, there MUST be a default version in
> the non-modular repository.
> * The fedora-modular repository SHOULD be disabled by default on user
>   machines, matching the current build system behavior. This also helps
>   enforcing the above policies.
> 
> I believe that the above proposal is essentially identical to Miro's 
> proposal from the other thread, which I support. The exact wording can be 
> discussed, but it is important that the essence of the proposal (module-only
>  = no go) is retained.
> 
> 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

That seems to be the best approach to this situation.

-- 
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: Modules in Non-Modular Buildroot

[Fabio Valentini]

On Mon, Oct 14, 2019, 12:47 Pierre-Yves Chibon  wrote:

> On Mon, Oct 14, 2019 at 12:02:46PM +0200, Kevin Kofler wrote:
> > Aleksandar Kurtakov wrote:
> > > You seem to totally miss the point - there is no one even trying to
> ship
> > > Maven as a traditional package so what should we do give up on having
> > > anything built with Maven in the distro?
> >
> > If module-only packages finally get banned (as they should have been
> from
> > the onset), the Maven maintainers will HAVE TO maintain the non-modular
> > version if they want to maintain Maven at all.
>
> You're assuming they will want to.
> I agree with Kevin Fenzi's email that the here the input from the people
> who
> have made the choice to go full-modular would be nice.
>
> If we follow your hard rule we may end up choosing between:
> - java/maven being available as module
> - no java/maven at all in Fedora
>   (this modulo the heroic efforts of the stewardship SIG - itself modulo
> the
>   fact that the SIG defines itself has a temporary solution [1])
>

FWIW, since I don't see the Java SIG rising from the ashes that were left
by it burning to the ground anytime soon, we definitely *will continue* to
maintain critical packages for the foreseeable future. So maven and all
its dependencies are safe. I also have early plans to update it to the 3.6
branch for f32.

I will later update the wiki page to reflect the current reality. The
documents in our pagure project should be up to date though.

Fabio


> You say that modularity is making people leave but this applies to any
> changes,
> including the one you are proposing here.
>
>
> Pierre
>
>
> [1] https://fedoraproject.org/wiki/SIGs/Stewardship
> ___
> 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: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Pierre-Yves Chibon]

On Mon, Oct 14, 2019 at 12:02:46PM +0200, Kevin Kofler wrote:
> Aleksandar Kurtakov wrote:
> > You seem to totally miss the point - there is no one even trying to ship
> > Maven as a traditional package so what should we do give up on having
> > anything built with Maven in the distro?
> 
> If module-only packages finally get banned (as they should have been from 
> the onset), the Maven maintainers will HAVE TO maintain the non-modular 
> version if they want to maintain Maven at all.

You're assuming they will want to.
I agree with Kevin Fenzi's email that the here the input from the people who
have made the choice to go full-modular would be nice.

If we follow your hard rule we may end up choosing between:
- java/maven being available as module
- no java/maven at all in Fedora
  (this modulo the heroic efforts of the stewardship SIG - itself modulo the
  fact that the SIG defines itself has a temporary solution [1])

You say that modularity is making people leave but this applies to any changes,
including the one you are proposing here.


Pierre


[1] https://fedoraproject.org/wiki/SIGs/Stewardship
___
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: Modules in Non-Modular Buildroot

[Pavel Raiskup]

On Thursday, October 10, 2019 5:59:16 PM CEST Miro Hrončok wrote:
> On 10. 10. 19 17:46, Igor Gnatenko wrote:
> > On Thu, Oct 10, 2019 at 12:52 AM Miro Hrončok  wrote:
> >>
> >> On 09. 10. 19 22:46, Ben Cotton wrote:
> >>> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> >>>
> >>> Enable module default streams in the buildroot repository for modular
> >>> and non-modular RPMs.
> >>>
> >>> == Summary ==
> >>> This Change (colloquially referred to as "Ursa Prime") enables the
> >>> Koji build-system to include the RPM artifacts provided by module
> >>> default streams in the buildroot when building non-modular (or
> >>> "traditional") RPMs.
> >>>
> >>> == Owner ==
> >>> * Name: [[User:Sgallagh| Stephen Gallagher]]
> >>> * Email: sgall...@redhat.com
> >>> * Responsible WG: Modularity WG
> >>>
> >>> == Detailed Description ==
> >>> As a major part of the Modularity design, we have a concept of default
> >>> module streams. These streams are built as modules, but the RPM
> >>> artifacts they deliver are intended to be used just like non-modular
> >>> RPMS. The aspirational goal is that a user of the system who never
> >>> executes a module-specific command (such as `dnf module install
> >>> nodejs:8`) should experience no meaningful changes in behavior from
> >>> how they would interact with a completely non-modular system. In
> >>> practice, this may mean that the informational output of package
> >>> managers may indicate that modules are being enabled and used, but a
> >>> user that does not have a specific reason to interact with the
> >>> selection of a module stream should have that managed on their behalf.
> >>
> >> If this is the goal of default modular streams, wouldn't it be in fact much
> >> easier to keep the default versions as urisne packages?
> > 
> > That means, you have 2 different workflows: for default version and
> > for an additional one.
> > When branching happens, instead of just updating one file which points
> > to the new default, you would have to create new stream, retire the
> > one which is about to become default and update package in
> > non-modular.
> 
> 
> Yes. It puts additional (arguably fairly trivial) work for the modular 
> maintainers. Other than that, it makes lives of every other maiantainar, of 
> the 
> dnf maintainers and of Fedora users easier.
> 
> I call it a good deal.

+1, that's pattern we decided to do in case of PostgreSQL.

Pavel


___
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: CGAL soname "bump" in rawhide

[Ankur Sinha]

On Sun, Oct 13, 2019 17:11:08 +0200, Till Hofmann wrote:
> You probably need to compile with `-DCGAL_HEADER_ONLY`, we had the same
> problem in fawkes. Here is the fawkes patch that fixed it:
> https://src.fedoraproject.org/rpms/fawkes/blob/master/f/fawkes.cgal-header-only.patch

That seems to have done the trick. Thanks very much. :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

RE: Recommending proprietary software in Fedora

[Kevin Kofler]

mcatanz...@gnome.org wrote:
> John, the third-party software policy was approved after a long and
> contentious debate:
> 
> https://pagure.io/Fedora-Council/tickets/issue/121

That policy is still completely at odds with the Fedora objectives. 
Recommending proprietary software is entirely incompatible with the Freedom 
goal and actively works against it. So this policy needs to be revisited to 
exclude proprietary software or repealed entirely.

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: Modules in Non-Modular Buildroot

[Kevin Kofler]

> Enable module default streams in the buildroot repository for modular
> and non-modular RPMs.
> 
> == Summary ==
> This Change (colloquially referred to as "Ursa Prime") enables the
> Koji build-system to include the RPM artifacts provided by module
> default streams in the buildroot when building non-modular (or
> "traditional") RPMs.
> 
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
> * Responsible WG: Modularity WG

I have already stated this multiple times in other threads, but just so that 
nobody claims that I have not given feedback to this change (which has been 
claimed for some other changes in a similar situation), I am going to state 
this again:

I oppose this change because I believe Miro's proposal to require all 
packages to have a non-modular version (i.e., to ship the default stream as 
non-modular packages) is the much better approach to the issue and makes 
this change proposal entirely moot.

To be clear, I propose the following:
* All packages MUST have a default version in any given Fedora release.
* The default version MUST be shipped as non-modular (not as a modular
  default stream).
* It follows that packages cannot be module-only.
* This applies to ALL packages including build tools. In particular,
  packages must not be hidden from users through constructs such as
  buildroot-only modules or non-API packages in modules. If a package is in
  a module, no matter in what function, there MUST be a default version in
  the non-modular repository.
* The fedora-modular repository SHOULD be disabled by default on user
  machines, matching the current build system behavior. This also helps
  enforcing the above policies.

I believe that the above proposal is essentially identical to Miro's 
proposal from the other thread, which I support. The exact wording can be 
discussed, but it is important that the essence of the proposal (module-only 
= no go) is retained.

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: Modules in Non-Modular Buildroot

[Kevin Kofler]

Aleksandar Kurtakov wrote:
> You seem to totally miss the point - there is no one even trying to ship
> Maven as a traditional package so what should we do give up on having
> anything built with Maven in the distro?

If module-only packages finally get banned (as they should have been from 
the onset), the Maven maintainers will HAVE TO maintain the non-modular 
version if they want to maintain Maven at all.

It is just not acceptable to move packages as central as Maven to module-
only and leave everything depending on them in the cold. This has been 
pointed out (by me and others) to the Maven maintainers ever since they 
first announced their plan, and was blatantly ignored. So we really need a 
policy to enforce social common sense (i.e., module-only = no go).

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: Add a rule to have a compose when Fedora branched

[jkonecny]

FYI: FESCO ticket was created

https://pagure.io/fesco/issue/2246

On Tue, 2019-09-17 at 15:58 +0200, jkone...@redhat.com wrote:
> Hello everyone,
> 
> I'm Anaconda developer and I'm also taking care about our
> infrastructure and this Fedora release brought me a plenty of
> "unnecessary" work thanks to the fact that compose for Fedora 31 was
> not available until a week before beta freeze. That is too late. 
> I wasn't the only one who had these problems, copr had issues for
> Fedora 31 and couldn't enable chroot so they had to do changes to
> correct these broken things. And I'm not talking about Fedora QA team
> which couldn't test almost anything before beta freeze.
> 
> The problem is that when we don't have a compose we don't have
> packages
> for testing and then more and more changes are getting in but we are
> not able to check if they are working. If we don't have packages the
> mock can't properly work and you are not able to do a system upgrade.
> The only test point is compose but that is just a small portion. Not
> being able to test Fedora for a few weeks is situation which should
> not
> happen.
> 
> To make things even worse there was a switch to python 3.8 on Rawhide
> which wasn't really prepared (pylint did not worked). So for a few
> days
> we were with broken Fedora 31 and Rawhide too, so most of our tests
> were not working. I would really said that we were programming in the
> dark. No tests, no check that changes are working. It took me almost
> a
> week to make everything working again not talking about time spend
> waiting for the compose to be available.
> 
> I want to ask for an improvement here. Ideal solution for me would be
> to add rule that there have to be compose to do the branching and if
> the compose fails then the branching won't happen. Not sure if this
> is
> doable or how hard it would be to implement a similar rule, however,
> it
> would be an ultimate solution. Then, the compose blocker bugs had to
> be
> solved on Rawhide where they should be solved. 
> 
> Please tell me what should I do next. Should I file a FESCO ticket to
> add this rule?
> 
> Best Regards,
> Jirka
> 
___
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 the system-upgrade path

[Kevin Kofler]

Zbigniew Jędrzejewski-Szmek wrote:
> Based on those graphs, I'd say there's slow shrinking. It appears to be
> linear since ~2016. But what is interesting, is that the shrinking mostly
> affects "the occasional contributor": the green top 1% appear unchanged,
> the yellow top 10% barely budge, but the last 50% is clearly shrinking.

That is because your recent changes such as Modularity, Silverblue, 
endorsement of Flatpak, etc., are driving new packagers away.

Some changes (e.g., Silverblue and the more or less related rush to Flatpaks 
for everything) falsely make potential new contributors believe that RPM 
packaging skills are no longer needed or wanted here. Others such as 
Modularity actively make it harder for potential RPM packagers to 
contribute. (Modules add complexity and cause problems when a dependency is 
module-only.)

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: Recommending proprietary software in Fedora

[John M. Harris Jr]

On Monday, October 14, 2019 2:29:49 AM MST mcatanz...@gnome.org wrote:
> John, the third-party software policy was approved after a long and
> contentious debate:
> 
> https://pagure.io/Fedora-Council/tickets/issue/121
> 
> We request review from Fedora Legal when we believe software may
> present significant risk, such as the recent addition of OpenH264, in
> accordance with the legal policy:
> 
> https://fedoraproject.org/wiki/Workstation/Third_party_software_policies#Leg
> al_requirements
> 
> Michael

I don't have a disagreement with the third-party software policy. However, 
that policy does not include proprietary software. It's good that we can 
reference external repositories such as rpmfusion-free, in my opinion.

-- 
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 the system-upgrade path

[jkonecny]

On Thu, 2019-10-10 at 16:40 +0200, Lukas Ruzicka wrote:
> 
> > 
> > So despite providing zero feedback here, this was voted at the
> > modularity meeting:
> > 
> > 
> > 
> > * Tagging Module Defaults into non-modular repo  (sgallagh,
> > 15:41:37)
> > 
> >* AGREED: We disagree with merging default streams into the main
> > repo
> > 
> >  as non-modular packages. Our approach is to implement a
> > mechanism of
> > 
> >  following default streams to give people the experience they
> > want.
> > 
> >  (+4 0 -0)  (asamalik, 16:07:40)
> 
> Well, 
> based on this discussion, pushing content in modular defaults is not
> the experience that people want. I have been a bit ill
> for some time and before I could add my point to the discussion,
> everything has been more or less said.
> Just for illustration, this is what I wanted to say about it:
> Modularity should stay away from my system until I call for it -> now
> it is not the case, because modularity sneaks into users' computer
> through modular defaults that overcome the non-modular packages. Gimp
> is the first such "horse" that jumps into almost everybody's desktop
> and they are modular without even knowing it.Modularity should
> provide alternative content, if I need it and when I need it. Modules
> should be installable only through "dnf module" command and not
> through the regular dnf command, so that I explicitely need to allow
> modularity on my system.The naming conventions of the streams should
> be obligatory for every module packager. So, if we decide that we
> want a "latest" stream, then all modules should have a "latest"
> stream for rolling updates. Currently, they all have various names of
> streams, from which I cannot tell anything. If there should be a
> "slow" path, then again, all modules should have a "slow" path.Non-
> modular Fedora must be a valid use case and remain an option.

I can imagine to not having the non-modular content at all. Everything
be packaged as modules but it has to be in a different shape than it is
now. That approach would simplify things by other direction.
I don't care that I'm using modules as long as it works as expected and
I'm not dealing with broken upgrade paths or conflicts thanks to this
feature. It would be even interesting to have (as someone mentioned
here) fast and slow streams. So if you are running Fedora-Server you
can default to slow one and if you like rolling updates distributions
(but fear the Rawhide) then go to the fast stream.
> If I decide to go modular, there must be a way to go non-modular
> again, without breaking the system. Or, if modular is the only
> option, so if I go into specific streams, there must be a way to go
> to defaults without breaking the system. With non-modular defaults,
> this seems easy. With modules? I am not sure.We need to expect that
> once there are hundreds of modules, people will install all possible
> combinations and they all will need to work. I am not sure, we will
> be able to test something like that.
> Seeing the reaction of the Modularity WG ... I do not understand how
> it is possible that such important decisions are taken by 4 people
> without any Fedora wide discussions like this. And yet, it seems a
> little bit that even opinions on this list will not fall on fertile
> grounds.
>  
> I wish the communication improved in the first place. Community means
> togetherness.
> 
>  
>  
> > should aim for solution 1. if solution 2. is not negotiable by the
> > modularity WG.
> 
> +1
> 
> 
> 
> 
> 
> ___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: Recommending proprietary software in Fedora

[mcatanzaro]

John, the third-party software policy was approved after a long and 
contentious debate:


https://pagure.io/Fedora-Council/tickets/issue/121

We request review from Fedora Legal when we believe software may 
present significant risk, such as the recent addition of OpenH264, in 
accordance with the legal policy:


https://fedoraproject.org/wiki/Workstation/Third_party_software_policies#Legal_requirements

Michael

___
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: Modules in Non-Modular Buildroot

[Aleksandar Kurtakov]

On Mon, Oct 14, 2019 at 12:06 PM Fabio Valentini 
wrote:

> On Mon, Oct 14, 2019 at 10:43 AM Aleksandar Kurtakov
>  wrote:
> >
> >
> >
> > On Mon, Oct 14, 2019 at 10:13 AM John M. Harris Jr 
> wrote:
> >>
> >> On Sunday, October 13, 2019 11:42:41 PM MST Aleksandar Kurtakov wrote:
> >> > On Mon, Oct 14, 2019 at 9:00 AM John M. Harris Jr <
> joh...@splentity.com>
> >> >
> >> > wrote:
> >> > > On Wednesday, October 9, 2019 1:46:52 PM MST Ben Cotton wrote:
> >> > > >
> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> >> > > >
> >> > > > Enable module default streams in the buildroot repository for
> modular
> >> > > > and non-modular RPMs.
> >> > > >
> >> > > > == Summary ==
> >> > > > This Change (colloquially referred to as "Ursa Prime") enables the
> >> > > > Koji build-system to include the RPM artifacts provided by module
> >> > > > default streams in the buildroot when building non-modular (or
> >> > > > "traditional") RPMs.
> >> > > >
> >> > > > == Owner ==
> >> > > > * Name: [[User:Sgallagh| Stephen Gallagher]]
> >> > > > * Email: sgall...@redhat.com
> >> > > > * Responsible WG: Modularity WG
> >> > > >
> >> > > > == Detailed Description ==
> >> > > > As a major part of the Modularity design, we have a concept of
> default
> >> > > > module streams. These streams are built as modules, but the RPM
> >> > > > artifacts they deliver are intended to be used just like
> non-modular
> >> > > > RPMS. The aspirational goal is that a user of the system who never
> >> > > > executes a module-specific command (such as `dnf module install
> >> > > > nodejs:8`) should experience no meaningful changes in behavior
> from
> >> > > > how they would interact with a completely non-modular system. In
> >> > > > practice, this may mean that the informational output of package
> >> > > > managers may indicate that modules are being enabled and used,
> but a
> >> > > > user that does not have a specific reason to interact with the
> >> > > > selection of a module stream should have that managed on their
> behalf.
> >> > > >
> >> > > > Similarly, the experience for package maintainers of non-modular
> >> > > > packages should be unaffected by an RPM dependency moving from the
> >> > > > non-modular repository into a default module stream. Up to the
> >> > > > present, this has not been the case; no module stream content has
> been
> >> > > > available in the non-modular buildroot for other packages to
> consume.
> >> > > > Koji builds of non-modular RPMs have had only the other
> non-modular
> >> > > > RPMs from that release available to their buildroots. In contrast,
> >> > > > building on local systems has access to both the non-modular RPMs
> and
> >> > > > the RPMs from any of the default module streams. With this Change,
> >> > > > Koji builds will have the same behavior and be able to depend on
> >> > > > content provided by default module streams. It also enables the
> same
> >> > > > behavior for Modular builds: the `platform` stream will now
> include
> >> > > > the contents of the default module streams for each release and
> do not
> >> > > > need to be explicitly specified in the modulemd `buildrequires`.
> >> > > >
> >> > > > Note: This Change does not address the other major Modularity
> issue we
> >> > > > are facing around distribution upgrades with differing default
> >> > > > streams. When discussing this Change, please keep that topic
> separate.
> >> > > >
> >> > > > == Benefit to Fedora ==
> >> > > >
> >> > > > This will simplify the lives of package maintainers in Fedora in
> two
> >> > > > primary ways. I'll use a hypothetical example of the Node.js
> >> > > > interpreter and a JSApp package which is capable of running on
> Node.js
> >> > > > 10 or 12 (but requires newer features than are provided by
> Node.js 8).
> >> > > > Additionally, the JSApp package requires the same versions of
> Node.js
> >> > > > at build-time.
> >> > > >
> >> > > > * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> >> > > > streams. The `nodejs:10` stream is set as the default stream.
> >> > > > * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> >> > > > streams. The `nodejs:10` stream is set as the default stream.
> >> > > > * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
> >> > > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
> >> > > > stream will likely become available during the F31 lifetime.
> >> > > > * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
> >> > > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
> >> > > > stream will likely become available during the F32 lifetime.
> >> > > >
> >> > > > On Fedora 29 through 31, the Node.js package maintainer needs to
> build
> >> > > > the `nodejs:10` package both as a module and as a non-modular RPM
> in
> >> > > > the distribution so that the JSApp package can be built. With this
> >> > > > Change, the Node.js package maintainer in Fedora 32+ 

RE: Recommending proprietary software in Fedora

[John M. Harris Jr]

On Monday, October 14, 2019 2:10:56 AM MST you wrote:
> catanzaro commented on the pull-request: `Add a filtered flathub remote`
> that you are following: ``
> John, I linked you to the section of the policy that describes what
> third-party software would present unacceptable risk. I further explained
> the intent of the filter is to hide software that we know would present
> such risk. I do not believe Steam is a significant risk.
 
> Since you have chosen not to accept the intention of the third-party
> software policy, which is to make it easier for users to install certain
> proprietary software not distributed by Fedora, I don't think further
> discussion here will be productive. ``
> 
> To reply, visit the link below
> https://src.fedoraproject.org/rpms/fedora-workstation-repositories/pull-requ
> est/7

Has anyone taken a look at this to see if it's actually alright to have this 
in Fedora? In my opinion, this presents a huge risk, especially as a package, 
and the third party software policy doesn't seem to apply to this use case.

-- 
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: Modules in Non-Modular Buildroot

[Fabio Valentini]

On Mon, Oct 14, 2019 at 10:43 AM Aleksandar Kurtakov
 wrote:
>
>
>
> On Mon, Oct 14, 2019 at 10:13 AM John M. Harris Jr  
> wrote:
>>
>> On Sunday, October 13, 2019 11:42:41 PM MST Aleksandar Kurtakov wrote:
>> > On Mon, Oct 14, 2019 at 9:00 AM John M. Harris Jr 
>> >
>> > wrote:
>> > > On Wednesday, October 9, 2019 1:46:52 PM MST Ben Cotton wrote:
>> > > > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
>> > > >
>> > > > Enable module default streams in the buildroot repository for modular
>> > > > and non-modular RPMs.
>> > > >
>> > > > == Summary ==
>> > > > This Change (colloquially referred to as "Ursa Prime") enables the
>> > > > Koji build-system to include the RPM artifacts provided by module
>> > > > default streams in the buildroot when building non-modular (or
>> > > > "traditional") RPMs.
>> > > >
>> > > > == Owner ==
>> > > > * Name: [[User:Sgallagh| Stephen Gallagher]]
>> > > > * Email: sgall...@redhat.com
>> > > > * Responsible WG: Modularity WG
>> > > >
>> > > > == Detailed Description ==
>> > > > As a major part of the Modularity design, we have a concept of default
>> > > > module streams. These streams are built as modules, but the RPM
>> > > > artifacts they deliver are intended to be used just like non-modular
>> > > > RPMS. The aspirational goal is that a user of the system who never
>> > > > executes a module-specific command (such as `dnf module install
>> > > > nodejs:8`) should experience no meaningful changes in behavior from
>> > > > how they would interact with a completely non-modular system. In
>> > > > practice, this may mean that the informational output of package
>> > > > managers may indicate that modules are being enabled and used, but a
>> > > > user that does not have a specific reason to interact with the
>> > > > selection of a module stream should have that managed on their behalf.
>> > > >
>> > > > Similarly, the experience for package maintainers of non-modular
>> > > > packages should be unaffected by an RPM dependency moving from the
>> > > > non-modular repository into a default module stream. Up to the
>> > > > present, this has not been the case; no module stream content has been
>> > > > available in the non-modular buildroot for other packages to consume.
>> > > > Koji builds of non-modular RPMs have had only the other non-modular
>> > > > RPMs from that release available to their buildroots. In contrast,
>> > > > building on local systems has access to both the non-modular RPMs and
>> > > > the RPMs from any of the default module streams. With this Change,
>> > > > Koji builds will have the same behavior and be able to depend on
>> > > > content provided by default module streams. It also enables the same
>> > > > behavior for Modular builds: the `platform` stream will now include
>> > > > the contents of the default module streams for each release and do not
>> > > > need to be explicitly specified in the modulemd `buildrequires`.
>> > > >
>> > > > Note: This Change does not address the other major Modularity issue we
>> > > > are facing around distribution upgrades with differing default
>> > > > streams. When discussing this Change, please keep that topic separate.
>> > > >
>> > > > == Benefit to Fedora ==
>> > > >
>> > > > This will simplify the lives of package maintainers in Fedora in two
>> > > > primary ways. I'll use a hypothetical example of the Node.js
>> > > > interpreter and a JSApp package which is capable of running on Node.js
>> > > > 10 or 12 (but requires newer features than are provided by Node.js 8).
>> > > > Additionally, the JSApp package requires the same versions of Node.js
>> > > > at build-time.
>> > > >
>> > > > * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
>> > > > streams. The `nodejs:10` stream is set as the default stream.
>> > > > * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
>> > > > streams. The `nodejs:10` stream is set as the default stream.
>> > > > * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
>> > > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
>> > > > stream will likely become available during the F31 lifetime.
>> > > > * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
>> > > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
>> > > > stream will likely become available during the F32 lifetime.
>> > > >
>> > > > On Fedora 29 through 31, the Node.js package maintainer needs to build
>> > > > the `nodejs:10` package both as a module and as a non-modular RPM in
>> > > > the distribution so that the JSApp package can be built. With this
>> > > > Change, the Node.js package maintainer in Fedora 32+ will only need to
>> > > > build the various Node.js streams and make one of them the default
>> > > > stream. The packages from it will then be added to the buildroot for
>> > > > non-modular packages. This will also make the packaging process
>> > > > somewhat more efficient, as the maintain

Re: Modularity and the system-upgrade path

[Miro Hrončok]

On 13. 10. 19 23:01, Fabio Valentini wrote:

On Sun, Oct 13, 2019 at 10:48 PM Kevin Fenzi  wrote:


On Sun, Oct 13, 2019 at 08:01:45PM +0200, Miro Hrončok wrote:

On 13. 10. 19 19:38, Kevin Kofler wrote:

Ben Rosser wrote:

Before things are rolled out further, I'd like to see some policies
agreed upon for what modularity is and isn't allowed for in Fedora:
what are the rules for default streams, buildroot only modules,
modularizing non-leaf packages, etc.


So, to start that discussion, I think all 3 of those should be no gos in
Fedora. In other words, I propose the following rules:
* no default streams, use "ursine" (non-modular) packages for the default
versions instead (you may ALSO ship the same version as a module, if that
makes it easier for you, i.e., if it means you don't have to retire and
unretire module versions at every release, but the "ursine" version must
exist),
* no buildroot-only modules nor buildroot-only packages in modules,
everything used to build packages must be shipped along with them,
* no non-leaf modules, since those unavoidably lead to version hell due to
the non-parallel-installability of different versions of the same module.


The third rule is unnecessary with the first. We can keep the integrity of
the default and provide non-defaults that may violate it if properly
documented (you might want to enable a nondefault modular stream to install
libfoo:0.27 in a container, even if it makes various packages you don't need
noninstallable).


I was hoping to have some of the folks who would be saddled with tons
more work if this policy was enacted chime in, but I don't think any of
them have. (ie, the people who have moved their packages to modules and
have or are going to retire their non modular versions). We may want to
ask them directly what they would do if this policy is enacted.

I understand that people want to go back to the last known "good" state
for them and regroup, but keep in mind that has it's price also. One
that I don't think too many in this thread will have to pay, so it's
easy to just say 'revert it all'.


 From what I can tell, the only two package groups that are really
affected by a move to "modules only" are java and eclipse.
If that's correct, "revert it all" would only affect eclipse so far,
because it now has broken dependencies in non-modular fedora.


Don't forget rust, but rust is covered by https://pagure.io/releng/issue/8767 
where the maintainer have asked the modules to be retired a month ago and 
https://pagure.io/releng/issue/8265.


--
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: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Aleksandar Kurtakov]

On Mon, Oct 14, 2019 at 10:13 AM John M. Harris Jr 
wrote:

> On Sunday, October 13, 2019 11:42:41 PM MST Aleksandar Kurtakov wrote:
> > On Mon, Oct 14, 2019 at 9:00 AM John M. Harris Jr 
> >
> > wrote:
> > > On Wednesday, October 9, 2019 1:46:52 PM MST Ben Cotton wrote:
> > > >
> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> > > >
> > > > Enable module default streams in the buildroot repository for modular
> > > > and non-modular RPMs.
> > > >
> > > > == Summary ==
> > > > This Change (colloquially referred to as "Ursa Prime") enables the
> > > > Koji build-system to include the RPM artifacts provided by module
> > > > default streams in the buildroot when building non-modular (or
> > > > "traditional") RPMs.
> > > >
> > > > == Owner ==
> > > > * Name: [[User:Sgallagh| Stephen Gallagher]]
> > > > * Email: sgall...@redhat.com
> > > > * Responsible WG: Modularity WG
> > > >
> > > > == Detailed Description ==
> > > > As a major part of the Modularity design, we have a concept of
> default
> > > > module streams. These streams are built as modules, but the RPM
> > > > artifacts they deliver are intended to be used just like non-modular
> > > > RPMS. The aspirational goal is that a user of the system who never
> > > > executes a module-specific command (such as `dnf module install
> > > > nodejs:8`) should experience no meaningful changes in behavior from
> > > > how they would interact with a completely non-modular system. In
> > > > practice, this may mean that the informational output of package
> > > > managers may indicate that modules are being enabled and used, but a
> > > > user that does not have a specific reason to interact with the
> > > > selection of a module stream should have that managed on their
> behalf.
> > > >
> > > > Similarly, the experience for package maintainers of non-modular
> > > > packages should be unaffected by an RPM dependency moving from the
> > > > non-modular repository into a default module stream. Up to the
> > > > present, this has not been the case; no module stream content has
> been
> > > > available in the non-modular buildroot for other packages to consume.
> > > > Koji builds of non-modular RPMs have had only the other non-modular
> > > > RPMs from that release available to their buildroots. In contrast,
> > > > building on local systems has access to both the non-modular RPMs and
> > > > the RPMs from any of the default module streams. With this Change,
> > > > Koji builds will have the same behavior and be able to depend on
> > > > content provided by default module streams. It also enables the same
> > > > behavior for Modular builds: the `platform` stream will now include
> > > > the contents of the default module streams for each release and do
> not
> > > > need to be explicitly specified in the modulemd `buildrequires`.
> > > >
> > > > Note: This Change does not address the other major Modularity issue
> we
> > > > are facing around distribution upgrades with differing default
> > > > streams. When discussing this Change, please keep that topic
> separate.
> > > >
> > > > == Benefit to Fedora ==
> > > >
> > > > This will simplify the lives of package maintainers in Fedora in two
> > > > primary ways. I'll use a hypothetical example of the Node.js
> > > > interpreter and a JSApp package which is capable of running on
> Node.js
> > > > 10 or 12 (but requires newer features than are provided by Node.js
> 8).
> > > > Additionally, the JSApp package requires the same versions of Node.js
> > > > at build-time.
> > > >
> > > > * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> > > > streams. The `nodejs:10` stream is set as the default stream.
> > > > * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> > > > streams. The `nodejs:10` stream is set as the default stream.
> > > > * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
> > > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
> > > > stream will likely become available during the F31 lifetime.
> > > > * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
> > > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
> > > > stream will likely become available during the F32 lifetime.
> > > >
> > > > On Fedora 29 through 31, the Node.js package maintainer needs to
> build
> > > > the `nodejs:10` package both as a module and as a non-modular RPM in
> > > > the distribution so that the JSApp package can be built. With this
> > > > Change, the Node.js package maintainer in Fedora 32+ will only need
> to
> > > > build the various Node.js streams and make one of them the default
> > > > stream. The packages from it will then be added to the buildroot for
> > > > non-modular packages. This will also make the packaging process
> > > > somewhat more efficient, as the maintainer needs only to manage the
> > > > module stream and the MBS will build it for all configured platforms.
> > > >
> > > > Similarly, 

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[John M. Harris Jr]

On Sunday, October 13, 2019 11:42:41 PM MST Aleksandar Kurtakov wrote:
> On Mon, Oct 14, 2019 at 9:00 AM John M. Harris Jr 
> 
> wrote:
> > On Wednesday, October 9, 2019 1:46:52 PM MST Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> > > 
> > > Enable module default streams in the buildroot repository for modular
> > > and non-modular RPMs.
> > > 
> > > == Summary ==
> > > This Change (colloquially referred to as "Ursa Prime") enables the
> > > Koji build-system to include the RPM artifacts provided by module
> > > default streams in the buildroot when building non-modular (or
> > > "traditional") RPMs.
> > > 
> > > == Owner ==
> > > * Name: [[User:Sgallagh| Stephen Gallagher]]
> > > * Email: sgall...@redhat.com
> > > * Responsible WG: Modularity WG
> > > 
> > > == Detailed Description ==
> > > As a major part of the Modularity design, we have a concept of default
> > > module streams. These streams are built as modules, but the RPM
> > > artifacts they deliver are intended to be used just like non-modular
> > > RPMS. The aspirational goal is that a user of the system who never
> > > executes a module-specific command (such as `dnf module install
> > > nodejs:8`) should experience no meaningful changes in behavior from
> > > how they would interact with a completely non-modular system. In
> > > practice, this may mean that the informational output of package
> > > managers may indicate that modules are being enabled and used, but a
> > > user that does not have a specific reason to interact with the
> > > selection of a module stream should have that managed on their behalf.
> > > 
> > > Similarly, the experience for package maintainers of non-modular
> > > packages should be unaffected by an RPM dependency moving from the
> > > non-modular repository into a default module stream. Up to the
> > > present, this has not been the case; no module stream content has been
> > > available in the non-modular buildroot for other packages to consume.
> > > Koji builds of non-modular RPMs have had only the other non-modular
> > > RPMs from that release available to their buildroots. In contrast,
> > > building on local systems has access to both the non-modular RPMs and
> > > the RPMs from any of the default module streams. With this Change,
> > > Koji builds will have the same behavior and be able to depend on
> > > content provided by default module streams. It also enables the same
> > > behavior for Modular builds: the `platform` stream will now include
> > > the contents of the default module streams for each release and do not
> > > need to be explicitly specified in the modulemd `buildrequires`.
> > > 
> > > Note: This Change does not address the other major Modularity issue we
> > > are facing around distribution upgrades with differing default
> > > streams. When discussing this Change, please keep that topic separate.
> > > 
> > > == Benefit to Fedora ==
> > > 
> > > This will simplify the lives of package maintainers in Fedora in two
> > > primary ways. I'll use a hypothetical example of the Node.js
> > > interpreter and a JSApp package which is capable of running on Node.js
> > > 10 or 12 (but requires newer features than are provided by Node.js 8).
> > > Additionally, the JSApp package requires the same versions of Node.js
> > > at build-time.
> > > 
> > > * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> > > streams. The `nodejs:10` stream is set as the default stream.
> > > * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> > > streams. The `nodejs:10` stream is set as the default stream.
> > > * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
> > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
> > > stream will likely become available during the F31 lifetime.
> > > * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
> > > `nodejs:12` stream is set as the default stream. The `nodejs:14`
> > > stream will likely become available during the F32 lifetime.
> > > 
> > > On Fedora 29 through 31, the Node.js package maintainer needs to build
> > > the `nodejs:10` package both as a module and as a non-modular RPM in
> > > the distribution so that the JSApp package can be built. With this
> > > Change, the Node.js package maintainer in Fedora 32+ will only need to
> > > build the various Node.js streams and make one of them the default
> > > stream. The packages from it will then be added to the buildroot for
> > > non-modular packages. This will also make the packaging process
> > > somewhat more efficient, as the maintainer needs only to manage the
> > > module stream and the MBS will build it for all configured platforms.
> > > 
> > > Similarly, from the perspective of dependent maintainers, there will
> > > no longer be anxiety about needing to move their package to a module
> > > if one or more of their dependencies drops their non-modular version
> > > in favor of a default st